Document Versioning

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 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 vox.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 vox.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.

Possible solutions:

• One is only allowed to use the NE2005 schema (when R2 was published), until such a time that R3 becomes normative. There can then be no updates of voc.xsd or datatypes. 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.
• InfrastructureRoot.typeCode can be used 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.
• Create a new CDA Release every time the underlying "infrastructure version" changes. Effectively this is the same as the previous option.
• Introduce a new attribute in ClincalDocument.