- Fields in the message SHALL have a Usage and Cardinality which SHALL NOT be in conflict with the base standard.
- 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 Usage of R, RE or C Which have a coded data type (CWE, CNE, ID, IS, etc) SHOULD be bound to a value set or code system described elsewhere in the document as defined in the conformance specification<<link here>>
- Fields not defined in the base standard SHALL NOT be included in the IG. If a new field is needed, it SHOULD be added through HL7 V2 processes.
- Where possible, standardized data type flavors should be use (see data type flavor project).
- Data types SHALL NOT be extended with additional components.
- 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 SHOULD have an OID
- Each value set should 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 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 IGShould value sets have gone through the harmonization process?Need to talk to Vocab about this
- 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 SHOULD NOT be used for the purposes of coding and are only for the purposes of better understanding the requirements
Discussed on 2019-03-14 telcon.
Discussed at 2019-ATLANTA WGM