Skip to end of metadata
Go to start of metadata

Table of Contents

The following criteria will be applied to HL7 Version 2 Implementation Guides (IG):

Document meta-data

  • Title SHALL match the official HL7 name for publication including:
    • Base version SHALL be specified
      • Any pre-adoption or post-adoption SHALL be clearly outlined
    • Realm SHALL be specified
    • Document type SHALL be (STU, Normative, etc)
  • Publication date SHALL be  specified
  • Title page SHALL BE  the official HL7 title page including official copyright text
  • Where appropriate, terminology text is included
  • Table of contents SHALL exist and include lists of tables and figures (note that message, segment, data type and value set "tables" MAY not be explicitly listed)
  • Authors and contributors SHALL be  listed
  • Sponsoring work group(s) SHALL be listed

Context

  • Purpose and audience of the document SHALL be  described
  • Scope (both in and out of scope) of the document SHALL be  clearly defined

Use Cases

  • At least one use case SHALL be described
  • Note that technical requirements that are not required for the IG use case(s) SHALL  not be required by the document
  • Use cases SHOULD include
    • Actors
    • User story
    • Message flows including a list of message profiles used to fulfill the use case

Technical requirements

General

  • Conformance statements SHALL be machine testable
  • Each conformance statement SHALL have a unique ID
  • Conformance statement IDs need not be meaningful or in alphabetical/numeric order
  • Conformance statement IDs SHALL NOT  be reused within the document or between releases of the same IG
  • Conformance statement IDs SHOULD  be consistent between releases of the IG
  • Conformance statements MAY be reused within a document if the requirement applied to multiple locations in the message
    • For example, if a conformance statement applies to a field in the OBX segment following both a PID and an OBR segment, then the conformance statement can be reused in both locations
  • An IG SHALL NOT use z-segments or custom data types (note that a constraint of a base data type is not a "custom data type")

Messages

  • Each message SHALL be associated with a Profile ID for use in MSH-21
  • Each message SHOULD include a narrative description regarding the role of the message in one or more use cases

Segments

  • Segments and Segment Groups in the message SHALL have a Usage and a Cardinality
  • Segments with a Usage of R, RE or C SHOULD  point to a constrained description of the segment elsewhere in the document
    • The exception to this is where a segment is required within an optional segment group (eg the Patient_Visit segment group is optional, but if included, the PV1 segment is required - in this case, the required PV1 segment does not need to be described in the document (it just defaults to the based standard definition)

Fields

  • Fields in the message SHALL have a Usage and Cardinality
  • Fields with a Usage of R, RE or C SHALL point to a constrained description of the field elsewhere in the document
  • Fields with a coded data type (CWE, CNE, ID, IS, etc) SHOULD be bound to a value set described elsewhere in the document


Data type

Where possible, standardized data type flavors should be use (see data type flavor project)

Value sets

  • Standard text describing the use and construction of value sets SHALL be included
    • We'd need to develop this (possibly starting with NIST text or text in the immunization IG)
  • Each value set should have an OID
  • Each value set should be declared as open or closed and static or dynamic
    • We'll need to provide a reference to definitions for these attributes
  • Each value in a value set should include Usage
  • Values should only be required when they are critical to the fulfilment of one or more use cases
  • Only value sets which are bound to a field, data type or co-constraint SHALL be included in the IG
  • Should value sets have gone through the harmonization process?
    • Need to talk to Vocab about this

Examples

  • Each use case SHALL contain at least one full example message for each profile
  •  "message snippets" SHALL NOT be used
    • segments that are non-relevant for the point being made may be abbreviated in the context of a full message
  • Example messages SHALL be prefaced with standardized text indicating that they should not be used for the purposes of coding and are only for the purposes of better understanding the requirements


  • No labels

7 Comments

  1. Should we add a document metadata bullet point to specify the sponsoring work groups, if applicable?

  2. Under Technical Requirements Segments I recommend adding "Additional fields not defined in the baseline Segment definition SHALL NOT be appended".

  3. Should we add a document metadata bullet point with a "SHOULD" recommendation to include the URL of the HL7.org web page containing the IG? People often pass around IGs as email attachments and then they end up with outdated copies. So I'd like everyone to know where to go to find more information and download the latest version.

    1. Good Idea.  Would be problematic unless we have HL7 create a permalink for each IG.

  4. We should state whether or not there are any differences between STU and Normative IGs. I suspect there won't be, but we should say so one way or the other.

  5. There needs to be language enjoining IG creators to make the document accessible to reviewers.   This includes not putting redundant content in.   I have seen that as an issue for documents created from IGAMT in which use of profile components ends up creating multiple dummy segment flavors which appear in the IG.