Wednesday, May 1, 2013

Classifying Documents in XDS

IHE defines in the XDS metadata, numerous different codes that are associated with the documents it indexes.

  • typeCode
  • classCode
  • eventCode
  • practiceSettingCode
  • authorSpecialty
  • authorRole
  • specialtyCode
  • formatCode
  • mimeTypeCode

typeCode is a single detailed code that classifies documents at a very detailed level and can be used for other sorts of analytics and decision support by automated systems. It's really intended for machine, rather than human use. LOINC is the most commonly used system for this classifier.

classCode is intrinsically tied to typeCode. Both codes classify documents, and typical implementations take a high level slice of the LOINC typeCode hierarchy to implement classCode.

A document with a class code indicating it was a discharge summary could appear as simple text, rtf, pdf in or CDA. A physician would who needs to see what happened to a patient in a recent hospital visit is not concerned about who wrote it, the detailed classification of the content, or what specifications it conforms to. They want to know what happened in the hospital. The classCode supports those sorts of queries.

The purpose of classCode when originally envisioned was to allow providers to identify the documents they need by what they contain: e.g.: X-Ray report, Discharge Summary, Lab Report, but not go into a detailed classification like Hospital Physician Discharge Summary.

However, even X-Ray report and Discharge Summary go just a bit further than what classCode intends, because they overlap with other classifiers.

eventCode captures information about the event or events which are relevant to the document.  It's been used as a bag to code various different events of interest in different profiles.  But it can also simply identify the kind of service that was performed, e.g, a consultation, or surgery.

healthCareFacilityType captures information about the kind of facility where the care was given, so that Discharge Summary is simple a combination of rfacilty type = Hospital, and thus, classCode could simply addressed as Summary. I've seen different value sets used here, from the Healthcare Provider Taxonomy (which includes both setting and specialty) to SNOMED.

practiceSetting addresses the medical specialty of the practice where the report was produced, e.g., radiology, and so X-Ray report becomes report, where the practice setting is radiology.  Practice setting and and authorSpecialty are often assigned to the same coding system.  That's because the practice setting could be more general, while the author training is more specific.

authorRole addresses the role of the author in creating the document. Is this a document created by the patient, their attending physician, their nurse, et cetera.

Those who understand how LOINC classifies documents will understand the axes used above.  If typeCode = the document LOINC code, the five axes of type in LOINC:
Kind of Document = class
Service Event = event
Setting = healthcare facility
Subject Matter Domain = practice setting / author specialty
Role Description = author role.

This was no mistake.  Two other code systems are left.

mimeType is used to identify the IETF mime type registered with IANA used for the content. We also note that at the time XDS was created, text/xml was overloaded to support things like CDA and CCR and other XML formats. These days, separate mime types are being created for different standards (and HL7 is in the process of finishing registration of mime types for CDA finally). Even so, mime type is still insufficient to determine what specification the content conforms to.

formatCode requires more explanation. The purpose of formatCode is to identify a specification that the content conforms to, over and above what is supported by mime type. For example, a document conforming to PDF/A has the same mime type as a document using PDF. While PCC has in the past used distinct formatCode values to distinguish between different document content profiles, we recently decided that because formatCode and classCode and typeCode provided the capability within a profile to distinguish content, that we could just assign a single formatCode to a profile supplement. This is because different documents in a profile have different codes describing them, and we expect that the affinity domain would be configured to support that distinction.

   Keith

6 comments:

  1. A nice, concise overview, Keith. You're a fountain of useful information, and always willing to share it. Thanks.

    ReplyDelete
  2. you forgot confidentialityCode, which is used to classify the personal sensitivity risk that the document content represents. Where "N" is used for classic normal healthcare information, which is recognized in healthcare as typical but clearly on the grand scheme is very sensitive. Where "R" represents a higher than normal risk typically due to some sensitive health topic or patient instruction. etc.

    ReplyDelete
  3. I am currently engaged in a project to send XDS messages from and EMR to and HIE using the HL7Connect Interface Engine. Your blog has provided a great overview for supporting documentation. Thank you

    ReplyDelete
    Replies
    1. Dear Keith,
      Very useful information. Is there a standard metadata field for intended recipient -doctor medicolegally responsible for reading & acting on the report.
      Thanks,
      Neelam

      Delete
  4. Keith,

    Has IHE or HL7 identified a classCode or typeCode to be used in the XDS metadata that would differentiate between a C32 CCD and the CCD within CCDA? For instance, classCode could be 34133-9 and typeCode would be some other LOINC code to identify the new CCD, or some combination. Or a LOINC code other than the Summarization of Episode to identify the new CCD based on CCDA?

    Thanks,

    Doug

    ReplyDelete
  5. Great post! Been reading a lot about different systems for handling medical records. Thanks for the info here!

    ReplyDelete