CSCR-062 Add reference to ActReference

From HL7Wiki
Jump to navigation Jump to search

Editing of Change Requests is restricted to the submitter and the co-chairs of the Clinical Statement Project. Other changes will be undone. Please add comments to the "discussion" page associated with this Change Request.

Back to Clinical Statement Change Requests page.

Submitted by: Harry Solomon Revision date: 2006/05/11
Submitted date: 2006/05/11 Change request ID: CSCR-062

Issue

The ActReference act needs to optionally have the attribute text:ED [0..1] to enable a reference pointer to the referenced act, and the attribute code:CD [0..1] to enable identification of the type of referenced act.

Recommendation

  • Add text:ED [0..1] to ActReference.
  • Add code:CD [0..1] to ActReference.

Rationale

While it is true that theoretically the Referenced Act Instance ID should be sufficient to locate and retrieve a referenced act, this requires a resource location service that has knowledge of every II in the world. In fact, this is unlikely to be true in the forseeable future.

As a practical approach, the creator of an external ActReference likely has knowledge of where the referenced act is stored, but the receiver of the clinical statement probably does not. As an example, a reference to an image stored in some PACS is used in a radiology report about a patient seen in an emergency situation while on vacation; that report is then sent to the patient's primary care physician, whose EMR system has no clue where that uniquely identified image is. That system could begin a search for the image - assuming that there are indeed resource location services attached to the PACS and available to the EMR that might be able to respond to the query. If instead the radiology report provided a URL to the referenced image, such a search would be unnecesssary.

It should therefore be optional for the ActReference to include text:ED to convey the location and access method to a referenced act external to the current message context.

Similarly, it is theoretically possible for the receiver of an external ActReference to retrieve the referenced act and see it in its full context. Again, however, as a practical matter it may not be feasible for the receiver to retrieve the referenced act, or to retrieve it in a timely manner, and the receiver is therefore completely in the dark about its nature and content (except its actClass and mood). While there are certainly strong arguments that in general the content of the referenced act should not be replicated into the ActReference, it would be extremely useful for at least the code attribute to be replicated for external ActReferences.

Discussion

16 June 2006 Consider using the mechanism used by CDA or pursuade CDA to use this mechanism. Consider including the CDA approach into Clinical Statement.

This has some fundamendal methodology issues associated with it. The ActReference Act (from an object instance perspective) is the exact equivalent of the Act it "references". There may be differences in version or richness of attributes describing the Act, but adding some resource location attribute to the Act Reference act is NOT the way to solve the issue. You'd need something akin to the Device custodian as modelled in the Master File / Registry control act wrapper. Suggest a different approach than the one suggested, and to take up with MnM. Rene spronk 07:16, 17 Jun 2006 (CDT)
See also Types of Identifiers and Datatypes R2 Issue 57 about II.useCode, which would allow for an II to be designated as a "Reference". The proposal is still under discussion. Rene spronk 09:14, 21 Jun 2006 (CDT)

21 June 2006 This proposal needs discussion not only in the context of the CDA, but also with regard to the II SIG CMETs A_DicomSequence minimal COCT_RM830110 and A_DicomCompositeObjectReference minimal COCT_RM830120. Those CMETs define a way to reference DICOM objects for both CDA documents and V3 messages.

Helmut Koenig, II SIG / DICOM WG20

29 June 2006 Agreed that at present will use refined versions of acts in the clinical statement choice box. Harry will review whethter this meets the DICOM use case.

Recommended Action Items

16 June 2006 Suggest for Harry to follow-up with CDA first to determine how their approach may fit and then ensure with Bob Dolin and Harry on the line we resolve this within Clinical Statement.

29 June 2006 Clinical statement group will contribute to II datatype discussion.

Resolution