Skip to end of metadata
Go to start of metadata


DRAFT

Team Make Up

Project teams should consider the following roles:

  • Project Facilitator - responsible for leading the project and serving as the liaison between the project team and the work group
  • Modeling Facilitator - responsible for leading methodology and design within the project team.  Should be familiar with HL7 development methodologies and any tooling that may be required.
  • Publishing Facilitator - responsible for the submission of content to HL7 on behalf of the project team.
  • Vocabulary Facilitator - responsible for vocabulary and terminology support within the project team.
  • Conformance Facilitator - responsible for ensuring that any project deliverables meet HL7 expectations and guidelines
  • Subject Matter Expert(s) - provide domain knowledge and business perspective to the project team.

Not all of these roles are needed for all projects and a single project team member may play more than one role.

Communication with the Work Group

It is expected that projects sponsored by the work group provide regular updates to the work group via:

  • communication via the Public Health work group listserv
  • updates during Public Health work group conference calls
  • updates during Public Health work group quarters at HL7 Working Group Meetings

Once the project is approved, the workgroup will assign a co-chair liaison to the project. This person will be responsible for the following:

  • Request periodic updates from the project team
  • Ensure that the project team has access to necessary documentation like templates, publishing calendars, etc.
  • Uploading STU comment dispositions to STU page
  • Facilitate necessary communications with headquarters

Key Approval Dates and Considerations

Projects should be aware of required committee/work group approvals in order for projects to be initiated.  These include:

  • US Realm Steering Division approval (for US realm projects)
  • Public Health Work Group approval
  • Approval of any co-sponsoring or interested party work groups

Once these have been granted, then: 

  • Family Management/Product-line Management approval
  • Clinical Steering Division approval
  • Architectural Review Board (ARB) approval- If the proposed materials include externally developed materials, then ARB approval is required.
  • Technical Steering Division approval

There are also approvals related to the publication of material for ballot - namely approvals for:

  • Project Scope Statement (PSS)*- for investigative projects, a limited version of the PSS may be used that just requires a subset of information for submission.
  • Notice of Intent to ballot (NIB)
  • FHIR Resource, Profile, and/or Implementation Guide proposals- It is important to check the FHIR Management Group processes and to stay engaged in their communications for the most up to date information.
  • Publication
  • Harmonization proposals

*A PSS can be used not only to start a project, but also to change or extend the length of the project.

Each of these approvals would need to occur prior to their submission deadlines as documented in the HL7 Publishing Calendars and schedules. The deadlines documented in the calendars are typically the last step for each milestone along the way.

The HL7 Publishing Calendar and Schedules are published here.  Templates can be found here.

US Realm Steering Committee Approval

Anything that is US Realm must get this approval and is typically the first approval before coming to the work group for sponsorship. All submissions to the Committee will require a minimum 7 day lead time before review on a regular Tuesday call. In practical terms, this means that any item submitted for US Realm review must be received by 10am ET Tuesday on the week prior to the targeted US Realm meeting.   

Please note this new policy and submit your documents accordingly to anne@hl7.org for inclusion on the agenda. A representative of the project will be expected to attend the meeting at which the submission will be discussed.

Ballot Reconciliation Process

All ballot comments must have a defined disposition and a disposition comment which clearly explains the changes that will be made. Where possible, the exact wording of any update should be given. Edits to a working version of the document(s) may be made during the ballot reconciliation process, however keep in mind that comments disposed of afterwards may affect the final text. The tracking of changes is recommended when the tools allow.

Where possible, block votes may be used to efficiently dispose of comments. Proposed dispositions must be distributed via the PH listserv at least 1 week in advance of proceeding with a block vote on a regularly scheduled call. No more than 50 comments may be included in a single block vote. This limitation is to allow enough time for interested parties to thoroughly review the dispositions in the week (or more) before the vote. Any person may request (in advance or at the time of the block vote) for comments to be removed from the block for individual discussion and resolution.

Standards for Trial Use (STU)-It is expected that comments on STU publications are monitored, dispositioned, reconciled, and reflected in the subsequent products either as an errata or a DOT release. Errata requests area logged on the TSC tracker. DOT releases are requested using the publication request template.

HL7 Product Family Expectations

All projects are expected to work closely with the Management Group for their product family. The Management Groups are responsible to maintaining a high quality of the products in their area. Management Groups may require steps or tools over and above the general HL7 expectations.

Harmonization is a key part of working with coding systems and value sets. Typically, harmonization happens 3 times per year (shortly after a WGM). Check with the Harmonization page (http://www.hl7.org/events/harmonization/index.cfm?ref=nav) for details of deadlines.

HL7 v2.x

Implementation Guides

New version 2 implementation guides (IG) are expected to investigate, and where appropriate, use standardized tools and best practices. The goal being to create a consistent feel across implementation guides and to aid developers and implementers by having consistent requirements and resuable elements between documents in different areas. The use of these tools is not absolutely required, but is strongly recommended.

Authoring tools and best practices include:

  • All IGs should include clear and complete examples of messages to help readers understand how the technical requirements translate into messages
    • The IG should also include wording indicating that examples should not be the basis for programming
    • Examples should include complete message examples when different concepts can be combined in a single message
  • The base standard which supports all the needs of the IG should be selected
    • The primary intent is to reduce the pre-adoption of structures and requirements from multiple base versions
  • NIST's IG authoring tool (IGAMT) to create technical and/or narrative content
    • The primary intent of this tool is to create more reliable and error free technical specifications through the use of an underlying database of the v2 base standard
    • The use of a standard authoring tool will lead to better standardized documents
    • This tool also opens the possibility for the creation of conformance testing tools based on the IG
    • Contact the NIST team, the v2 Management Group or the PH co-chairs for additional information on this tool
  • Harmonized value sets 
    • The primary intent is to follow HL7 processes across product families and institute a common set of terminologies where possible in order to reduce burden on system development and data capture workflows
    • Value sets should be published in a consistent format when possible
    • See note above regarding the Harmonization processes
    • Work with the PH vocabulary facilitator when needed
    • Contact the v2 Management Group for details on value set formats
  • Standardized data type flavors
    • The primary intent of standardized data type flavors is to reduce the burden on developers and implementers by requiring consistent data across IGs
    • A data type flavor library is still in ballot but contact the Conformance or PH co-chairs for more information on standardized data type flavors


HL7 CDA

Implementation Guides

CDA IG quality criteria

FHIR

Guidance on publishing FHIR artifacts can be found here.

Make sure to be engaged with the FHIR processes and sign up for the Zulip chat to follow communications.


Post Ballot Reconciliation & Publishing

Once ballot reconciliation is completed, the project team should complete the following steps for publication. Please work with the work group co-chairs throughout this process.

  1. Post completed ballot spreadsheet to the ballot desktop.
  2. Via the ballot desktop, request that negative votes be withdrawn.
  3. Once ballot approved edits have been made, post the updated version of the document to the members only website at http://www.hl7.org/Special/committees/pher/docs.cfm (making sure to  check members only flag). You will need to be signed in to do this. If you have problems, ask a co-chair.
  4. Send notice to the public health list serve (pher@lists.hl7.org) announcing that the updated pre-publication version has been posted to the member only website for review. This starts the clock for a 1-2 week review period.
    1. In the notice, the public health work group should be directed to send their comments to the project team.
    2. The project team should work with the review commenter to reconcile any perceived errors in the edits made.
    3. If changes are significant, the document may have to be reposted for review. Project team should consult the co-chairs in this situation.
  5. Upon completion of the 2 week review period, the project team can then come back to the workgroup for approval of the document, and approval of a publication request (https://www.hl7.org/documentcenter/public_temp_6AAC957B-1C23-BA17-0C3260F195208CB5/wg/tsc/HL7_Publication_Request_Template_2019APR.docx).
  6. Once workgroup approval has been achieved, the document and the publication request can be sent to the TSC (TSCPM@HL7.org and DTP@HL7.org), copying the co-chairs, for final approval prior to publishing.
    1. Project team members, in particular the publishing facilitator, should work with HL7 headquarters (Lynn specifically) to get the document ready for publishing. The publishing facilitator should review the document, once converted from word to PDF, to ensure readability.
  7. Once published, the standard/document will be available to members only for the first 90 days, and then open to anyone after the 90 day member only period. The documents can be accessed via the HL7 website- standards page , or for easier navigation and searching the master grid of standards.
    1. To access the standards, users will be expected to log in to the HL7 website, requiring a user account (username and password), which doesn't not require a membership (free of charge)


Standards Maintenance (SECTION UNDER DEVELOPMENT)

Once published, the standard/document should be maintained in accordance with official republication process.

Informative

Standard for Trial Use (STU)- formally DSTU

  1. Once published, the standard will receive an STU page for the collection of comments during the trail period (12 - 24 months depending on approval).
  2. The project team should monitor the associated STU page for comments collected and bring back to the WG for dispositioning.
    1. This process is similar to ballot reconciliation, however it is maintained and executed through the use of the webpage, as opposed to the formal ballot spreadsheet. Additionally, this occurs throughout the trial period and reconciliation is not subject to the traditional ballot reconciliation timelines.
    2. Once enough comments (either in number or importance) have accumulated, the project team can publish a new version. If all of the changes are smaller in nature, a “dot release” (eg Release 1.1) can be published. A dot release does not have to go back through an official ballot period but rather, the updated document is made available to the WG for a couple of weeks for informal comment and review.
    3. If the accumulated changes are more substantial, then a new release (eg Release 2) is created and put through the typical ballot process.
  3. As the standard approaches the end of the STU phase, the project team must determine the future of the standard. There are several possibilities, please work with the co-chairs to figure out the best course of action. Be sure to begin these proceedings well in advance of the STU expiration date so that there is no gap in the availability of the standard.
    1. If the standard has been broadly implemented and good feedback has been received, it may be appropriate to reballot the standard as normative
    2. If more feedback is required but significant changes are required a new round of STU balloting can be started
    3. If more feedback is required but there aren't enough significant changes to warrant a new ballot, an STU extension can be requested from TSC
      1. The process for this is to fill out the publication form (same one as for publishing the document in the first place) followed by WG approval and TSC approval
    4. The standard may be allowed to lapse
      1. Note that this may not be an option if the standard if mentioned in regulations

Normative

  • No labels