The idea of a "principal classification" is what is behind the XDS Document Class code metadata attribute. Not too long ago, on a call that I was on, a question came up about how to code the document type for a CDA document. The querant also wanted to understand the relationship of document types to the XDS Document Class Code.
There's a couple of principles for classifying clinical documents (CDA) that the HL7 Structured Documents workgroup and IHE have come to generally agree upon.
The preferred coding system for classification is LOINC®. HL7's Structured Documents workgroup picked LOINC in CDA Release 1.0, and has been working with LOINC for several years on document classification. IHE sticks with the HL7 recommendation.
Precoordinated codes are NOT the preferred way of coding a document. That's because CDA contains a number of different components in the CDA Header that can be used to classify a clinical document. These include:
- Service Performed (H&P, Consult, Surgical Procedure, et cetera)
- Type of Encounter (ED, Ambulatory, Inpatient)
- Author Specialty (Cardiology, Radiology, General Practice, Pediatrics, Oncology, et cetera)
- Facility Type (Skilled Nursing Facility, Home Health, Hospital, et cetera)
- Author Role (Attending Physician, Consultant, et cetera)
HL7 tends to pick a preferred code and allow the others with guidance that the other facets must not disagree. For example, you cannot use the Attending Physician Hospital Admission H&P and then show that it was authored by a nurse, or that the healthcare facility was something other than a hospital. IHE just picks the one least restrictive code to use and avoids the issue altogether. That code in LOINC most commonly refers to the type of service only (e.g., Admission H&P).
If you collect up all the types of services and make a short list of services, say less than 50 or so items long, then you have what IHE called document class. That way, types could be detailed and could be used to support more specific searches, but document class would support the "drop-down" list of things to query for, e.g., ED records, L&D records, Lab reports, imaging studies, H&P notes, consult notes, procedure notes, et cetera.
The question come up then, of how one could locate the {facility type} {specialty} {service} note using XDS. Actually, the question was more detailed than that, I just made it into a meta question for illustration. In XDS you have all of these different facets in the metadata, and you can combine this metadata either directly in your query, or in filtering steps after the query is finished to show only the relevant data. Combining class with the author specialty or facility type or other criteria could get you to the Cardiology Procedure note, or opthamology imaging study.
Using that criteria, I can readily find documents based on the type of service performed, which seems to be the most critical classification axis, just like I can find more of that author's books in the Science Fiction section of the bookstore. Or if need be, I can search by classification, author, specialty, et cetera.
Thanks for this post. It makes a lot of sense to have separate queryable metadata fields for these various attributes rather than combining them into a single field. I do have a question, however, concerning the support that XDS currently has for querying by {specialty} based on the IHE ITI TF profiles and specifically for XCA. XCA is based on the Registry Stored Query profile and it doesn't appear to me that a search by {authorSpecialty}. For instance, the parameters for the FindDocuments query (section 3.18.4.1.2.3.7.1 in the IHE ITI TF-2a revision 6.0) include "$XDSDocumentEntryAuthorPerson" which is mapped to the XDSDocumentEntry.author attribute, however, there is no parameter defined for "$XDSDocumentEntryAuthorSpecialty". Does this mean that the XCA query itself can only request filtering by {classCode} and the filtering by {authorSpecialty} must be done by the query initiator after receiving the list of all documents meeting the {classCode} criteria? That seems potentially inefficient although it is certainly straightforward to implement.
ReplyDeleteYou are correct. But $XDSDocumentEntryPracticeSettingCode would also work assuming authorSpecialty and practiceSetting used the same coding systems.
ReplyDeleteOn another note: IHE profiles set a floor, not a ceiling. So one could add support for $XDSDocumentEntryAuthorSpecialty -- it just wouldn't be defined by IHE.
Useful post - I was fascinated by the facts - Does someone know if I might access a template a form document to use ?
ReplyDelete