Support setid and versionNumber on Structured Body & NonXMLBody

Return to SDTC page; Return to CDA R3 Formal Proposals page.

See CDA R3 Formal Proposals for instructions on using this form. Failure to adhere to these instructions may result in delays. Editing of formal proposals is restricted to the submitter and SDTC co-chairs. Other changes will be undone. Comments can be captured in the associated discussion page.

Submitted by: <<Calvin Beebe>>	Revision date: <<April 18, 2010>>
Submitted date: <<April 18, 2010>>	Change request ID: <<Change Request ID>>

Issue

Some clinical document management systems, do not force document content versioning when MDM status change messages RCMR_IN000005UV02 are sent (re: changes to (1) completionCode; (2) confidentialityCode; (3) availabilityTime; (4) storageCode) in practice, essentially any header content changes for fields currently defined in the CDA R2 standard. Remember, MDM supports messaging of document metadata (CDA R2 header data) without the need to send the document body.

These document management systems view these transactions as updates to data records in their implementation when no content (body) is provided, which preserve unchanged the body (contents) of the documents referenced and does not version them.

This allows medical records departments to provide what amount to as header updates without explicit document versioning and complicates the issue of maintaining documents via MDM messages when those documents are CDA based.

Recommendation

• Optionally supporting the use of setid and versionNumber at the body level; Structured Body & NonXMLBody.

Rationale

This would minimize the potential changes needed to support CDA in clinical document management systems based on designs supporting MDM messages without content. The essential problem is that MDM based document management systems considered the header data independent, so that signing a document or changing its status, gets recorded in their database, but not specifically recorded as a document revision. Without the ability to support the modeling of content (body) versioning, document management systems based on these designs, are forced to undertake major redesigns to support versioning of meta-data and content based CDA documents.

Discussion

I can't speak for every document management system, but my concern is that we might have placed versioning in the wrong location when we created the CDA standard. I will be interested to hear if other implementers have had similar issues managing CDA documents when only header elements change in incoming messages.

Resolution

versionNumber and setId are found in ContextStructure, but this would add these to DOCBODY, which descend from the ORGANIZER class structure, which means that we would likely need to make this change through harmonization.

Versioning is not necessarily dependent upon whether something is a document, all objects could be versioned.

The key problem is that the MDM Document Notification messages could indicate an update to metadata (e.g., the document was signed), that don't involve specific changes to content.

A suggestion was made to introduce a cautionary note in the MDM message rather than make this change. The requester withdrew this proposal given this recommendation.