CDA R3 Proposal - Append, Edit, Correct Enhancements

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

Submitted by: Sondra Renly	Revision date: Dec 3, 2008
Submitted date: Dec 3, 2008	Change request ID: <<Change Request ID>>

Issue

IBM Research has been working with HL7v3 CDA R2 for public health laboratory reporting. Through this process we identified a hole in consistent machine markup for reports that are appended, edited, and corrected. These are frequent operations in the laboratory report setting. In some situations it may be sufficient to document in a comment what has changed between document versions, but policies and regulations can require greater documentation such as entire previous result documentation accompanying a new, updated result.

In conjunction with the IHE Lab Committee, we have identified the following use cases for CDA R3 work as we have not identified solutions in the current CDA R2:

• Use Case 1 – A laboratory report was issued on the wrong patient. Today two documents will be issued. For the correct patient, a new laboratory report shall be approved. For the wrong patient, the specification to represent the error in the CDA document and negate content has been left for future work.

• Use Case 2 – A laboratory report was issued with incomplete or incorrect non-result data, defined as the information found in the CDA Header or Specimen, such as the collection date and time. The results and result interpretation are unchanged by the addition, edit, or correction of non-result data. The specification to represent the change has been left for future work.

• Use Case 3 – A laboratory report was issued with incomplete or incorrect non-result data. In this case, the results and interpretation, defined as the information found in an observation, organizer, or media, are changed by the addition, edit, or correction of non-result data. The specification to represent the change and the interpretation impact has been left for future work.

• Use Case 4 – A laboratory report was issued with incomplete or incorrect result data. The specification to represent the change and the interpretation impact has been left for future work.

• Use Case 5 – A laboratory report was issued with incomplete or incorrect non-result and result data. The specification to represent the change and the interpretation impact has been left for future work.

Discussion

Bob Dolin 10/14/2008 - I think the RIM has what we need - we'd mainly want to add new actRelationship type codes into the EntryRelationship class.

Austin Kreisler 08/10/2009 - SDWG should consider consistency with the use of controlAct.

comments from Rene: How does document succession impact contained acts? For instance, in the case of a replacement document, one can use the RPLC relationship on a revised Act, so we could comment on this. In the case of a repudiation, all contained acts are impacted. [From Rene: I think that at least there should be some kind of warning or implementation guidance within the CDA standard. This need not be elaborate, but it could describe that those parties that extract data from CDA documents should consider the context of that data. The detailed rules may be as agreed upon at the affinity domain level. So I don't envision the CDA making normative statements about the application behaviour (HL7 shies away from that kind of statement anyway), but I expect it to remind users of the standard that this pitfall/implementation issue should be addressed - somehow. The exact policies have to be defined and agreed upon within or between organizations.]

Austin Kreisler 04/7/2010 - I reviewed the act relationship type codes to identify if there are any additional ones needed for relatedDocument.typeCode. Right now APND, RPLC and XFRM are supported. To handle item #1 below, we could consider adding REV (reverses). The RIM definition is:

• A relationship between a source Act that seeks to reverse or undo the action of the prior target Act.

We would be communicating the the current document reverses the prior document. One RIM constraint on the use of REV is that the target act mood must be the same as or more "actual" or real than the source act. Since both the current document and the target (parent document) are both in EVN, this isn't an issue.

One issue I did discover is that relatedDocument is not using the XFRM type code properly. The RIM definition of XFRM is:

• Used when the target Act is a transformation of the source Act. (For instance, used to show that a CDA document is a transformation of a DICOM SR document.)

In the CDA header, the current document is the source, and the parent document is the target. Semantically, this is saying that the parent is a transform of the current document. The CDA R2 documentation of XFRM states:

• The current document is a transformation of the ParentDocument.

This is in directly opposite of the RIM. In CDA R3, I think this means we will need to act relationships to the parent document from the current document, pointed in opposite directions. XFRM will be the one with the current document as target and parent as its source. The other, with current document as its source and parent as the target will carry the other type codes. Any additional ones we add need to be added to the semantically appropriate act relationship.

I also had a more detailed look at updateMode in both the Core Principles document and the ISO data types document. In both documents, update mode seems to be closely tied to a transactional model of data exchange (i.e., messaging). It allows the sender to leave out those parts of a message that have not changed since the previous message, sending only the delta's (i.e., what has changed). Its for use with tightly coupled systems. Core principles does talk about using update mode even if you re sending a complete snapshot, so that the receiver can use the update mode information to decide how to process elements of the transaction. One thing Core principles does indicate is that if any work group is planning on using update mode, they should consult with MnM regarding it's proper use in their models.

One strong piece of guidance on updateMode from the ISO data types document is:

• In more general use, such as clinical documents and EHRs, the use of such transaction based processing is inappropriate, so the updateMode attribute should generally be fixed to null in these contexts.

Resolution

April 06, 2010 SDWG: We agree with the requirements. Several things need to be done: [1] Ensure adequate relatedDocument.typeCode values. [2] We need to provide guidance - e.g. what is the expected behavior for a recipient when they receive a repudiation message; what is expected behavior for a recipient when they receive a document that supercedes another document (e.g. what do they do with the superceded document, what do they do with all the superceded acts). [3] Ensure we have the ability to manage changes at the individual object (e.g. act, entity) level (including the correct use of controlAct). [4] Correct use of updateMode may be necessary to explicitly indicate updates to CDA header components. abstain: 0; opposed: 0; in favor: 9.