This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Interaction and Versioning

From HL7Wiki
Revision as of 16:45, 3 October 2008 by Lmckenzi (talk | contribs)
Jump to navigation Jump to search

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.

Proposal

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.


Required Actions

  1. HL7 steps
    1. Deprecate the Transmission.versionCode attribute
    2. Deprecate the use of artifact version
    3. Register an OID for HL7 profiles
    4. Publish standards for how Normative edition and ballot editions are to be referenced as profiles
      1. Normative Edition: [YYYY]NE
      2. Ballot Edition: [YYYYMM]BE
    5. Add support to the PubDB to capture what datatypes version is to be used for a given interaction (default is 1.0)
    6. When publishing schemas, publish message types for both versions of the datatypes and interactions that reference the appropriate datatype definition
    7. Include in all artifacts a source control version to allow tracking to the "source" and "tooling" used to generate a particular version of artifacts
      1. In the MIF, this will go in the "rendering" section, in Visios in the entry-point comment
    8. 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
      1. 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.)
  2. Affiliate steps
    1. Register an OID for Affiliate level profiles (if any)
    2. Publish standardized profile ids for each "release" of affiliate-based specifications
    3. When publishing specifications that reference HL7 UV materials, reference the profileId that defines the version of the artifacts to be used
  3. Local implementation steps
    1. Register an OID for any 'local' profiles
    2. Publish standardized profile ids for each "release" of local specifications
    3. When publishing specifications that reference HL7 UV or affiliate materials, reference the profileId that defines the version of the artifacts to be used