Interaction and Versioning
This page is a placeholder for the topic of "How is versioning, and 'backwards compatibility' related to interaction version (in its name), profileId, etc."
See Interaction_Versioning and Interaction_Conformance_and_Versioning_-_Implementation_Issues for discussions / motions on this topic.
Discussion took place in January 2008 / MON Q2 & FRI Q2.
Versioning will be managed by asserting the specific publication package release being used to define the artifacts for an implementation rather than asserting an id on each one.
Adopt the use of profileId to convey all version information a given interaction is conformant with and what the expected receiver responsibilities are. This will include:
- Base RIM
- HL7 Vocabulary
- Datatype definition (based on the datatype verion declared by the interaction)
- Interaction definition
- Message definitions of all wrappers, payloads & CMETs
- Trigger Event
- Conformance rules
ProfileId would become mandatory but would continue to repeat to allow realm profiles and/or local profile ids to be specified. Affiliates and local organizations would need to register OIDs for their own profiles
Interaction instances would identify whatever profile ids they wished to claim conformance with and must claim conformance with at least one profile. To be considered "conformant", the application must declare conformance to a universal or affiliate profile.
- HL7 steps
- Deprecate the Transmission.versionCode attribute
- Deprecate the use of artifact version
- Register an OID for HL7 profiles - Done: 2.16.840.1.113883.1.9
- Publish standards for how Normative edition and ballot editions are to be referenced as profiles
- Declare a specific "version" (ballot) in which datatypes R2 will be adopted. This will be a big bang change. Everything published (including all historical artifacts) will be updated to reflect the new datatype specification.
- This is done to avoid the difficulty of having to publish a completely separate set of schemas for datatypes R1 and R2 with a given release and also ensures that normative and ballot edition plus interaction id remain sufficient to know the entire set of specifications.
- Include in all artifacts a source control version to allow tracking to the "source" and "tooling" used to generate a particular version of artifacts
- In the MIF, this will go in the "rendering" section, in Visios in the entry-point comment
- As part of the publication process, embed the profile id for the publication in all published artifacts (MIF files, schemas, etc.) as a comment or similar tag
- Add a MIF tag to be populated in the publication process to specifically capture the profile id. (Not to be included in MIF source files.)
- Ensure that ballot status is properly populated in MIF files and rendered with artifacts (so it's ok when we don't have 'vv' on the end of normative artifacts)
- Affiliate steps
- Register an OID for Affiliate level profiles (if any)
- Publish standardized profile ids for each "release" of affiliate-based specifications
- When publishing specifications that reference HL7 UV materials, reference the profileId that defines the version of the artifacts to be used
- Local implementation steps
- Register an OID for any 'local' profiles
- Publish standardized profile ids for each "release" of local specifications
- When publishing specifications that reference HL7 UV or affiliate materials, reference the profileId that defines the version of the artifacts to be used
MnM Discussion during the 2010 oct WGM
MOTION: Believe that the Conclusions listed in "Required Actions" are the correct ones and should be adopted and implemented as soon as possible. To that end moved that M&M Take formal action to adopt this at their next Conference Call (Oct 22) and approve a Project Proposal for the Required Actions. The proposal will be a joint proposal (MnM InM IC V3Pub) and forwarded to both the FnT SD (MnM InM IC) and SSSD (Publishing) for review and forwarding to TSC. 3-0-0