Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • At least one use case SHALL be described
    • The requirements of the use case SHALL be represented as constraints in the profiles
    • The profiles SHALL NOT contain constraints that are not required for the IG use case(s) 
  • Use cases SHALL include
    • Actors
    • User story
    • Message flows including a list of message profiles used An IG SHALL include fully defined choreography describing the message flows and profiles to fulfill the use casecases.
      • This SHALL be expressed either graphically or textually.


Technical requirements

General

  • Any An IG SHALL follow the rules defined in the conformance methodology specification. <<link here >>
  • An IG SHOULD be based on the most relevant version of the standard, and avoid "pre-adoption".
  • Conformance statements SHALL be testable or SHALL be sufficiently defined that a computable statement can be derived from it.
  • Declared conditional elements SHALL have a predicate that is machine computable given the contents of the message
  • Each conformance statement SHALL have a unique ID
    • Conformance statement IDs need not be meaningful or in alphabetical/numeric order
    • Conformance statement IDs SHOULD  be consistent between releases of the same IG
    • Conformance statement IDs SHALL NOT  be reused for different requirements within the document or between releases of the same IG
      • Conformance statements MAY be reused within a document if the requirement is 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")
  • An STU IG SHALL have the same technical requirements as a Normative IG.

...

  • Each message SHALL be associated with a Profile ID for use to be placed in MSH-21.
  • Each profile SHALL require MSH-21 to be valued with at least one profile identifier as defined in the conformance methodology specification<<link here>>.
  • Each message definition SHOULD include a narrative description regarding the role of the message in one or more use cases

...

  • Segments and Segment Groups in the message SHALL have a Usage and a Cardinality
  • Segments not defined in the base standard for the trigger event being used SHALL NOT be included in the IG.
  • Segments with a Usage of R, RE or C SHOULD  defined in the IG SHALL 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)

...