Document Versioning

THIS PAGE HAS BEEN MIGRATED TO THE SDWG CONFLUENCE SITE HERE.

Document Versioning could mean one of two things:

1. Different versions of a clinical document in terms of content (e.g. a replacement document)
2. Different versions of the structure of CDA documents within a single release.

Versioning of the structure of CDA documents

There is currently no version attribute which can be used to convey the infrastructure version (CMETs, datatypes, vocabulary) used by a document instance.

Example:

• Schemaset 1 = CDA R2 schema from the Normative Edition 2005 (NE2005), with voc.xsd and datatypes schema from that same edition.
• Schemaset 2 = CDA R2 schema from the Normative Edition 2005 (NE2006). This is the same R-MIM as in NE2005, using the same version of the XML ITS. with voc.xsd and datatypes schema from NE2006.

An instance that complies with schemaset 2 need not be compliant with schemaset 1 - for example if a new structural code has been added to voc.xsd or a data type has been extended with a new component.

For messages we have the following: Message(or Batch).versionCode: infrastructure versioning (CMETs, datatypes, vocabulary, transports) is communicated using the versionCode attribute and has values such as "2006NormativeEdition". The versionCode indicates "all infrastructure stuff that was normative as of the point and time the normative edition was released". For early adopters, it could be one of the development editions or an equivalent "packaged release" by a particular realm. See Interaction Versioning for details.

CDA doesn't have an explicit "Infrastructure Version". Possible solutions:

• One is only allowed to use the NE2005 schema (the normative edition in which CDA R2 has been inititially published), until such a time that R3 becomes normative. There can then be no updates of voc.xsd or datatypes between releases. Note: this is the current thinking of the strucdoc committee, although a formal motion hasn't been made.
  • This excludes a lot of enhancements (e.g. in the area of datatypes) one may want to adopt between R2 and R3. On the other hand adopting changes before the release of R3 leads to a requirement for versioning, and to backwards compatibility issues.
  • Note related to the number of versions/releases: after a couple of years it forces receivers to support a whole bunch of versions/releases for a single interaction/document.. which will certainly be true for CDA, documents are persistent and sometimes have to be stored (for legal reasons) for 110 years. This means that all those that process documents have to support a max of 110 infrastructure versions. This pleads for a mechanism that creates a minimal number of versions/releases.
  • This option seems to have been the intent of the committee, and is favoured by Bob Dolin.
• Somehow support different/later versions of infrastructure (voc and datatypes) in one and the same CDA Relase
  • InfrastructureRoot.typeCode is used (mandatory) by CDA R2 documents to identify the MT that the instance corresponds with. If the MT artefact ID is properly versioned (in this case the MT versioning should include the infrastructure version in a precoordinated fashion) this can be used as well. v3 interactions don't have such a precoordinated versioning mechanism however, so it would be kludgy to do so for a document.
    • Alternatively, create a new CDA Release every time the underlying "infrastructure version" changes. Effectively this is the same solution.
  • Introduce a new attribute in ClinicalDocument.