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