There's a big discussion on the FHIR list serve about formatCode, and how to model it in the DocumentReference resource. I thought I would take a few moments to explain its purpose.
There are a lot of different ways to classify clinical documents. The first of these is to describe the MIME type. This allows you to say that the document is in plain text (text/plain), RTF (text/rtf), HTML (text/html), XML (text/xml), PDF (application/pdf) and various other formats. Back when XDS was written, many of the XML based formats hadn't yet started using or registering the various +xml MIME types following the new conventions. So we had text/xml which wasn't distinct enough (and still today we have this problem with XML formats).
Document type (using LOINC), and document Class classifies documents in fine and coarse grained ways, the former for detailed classification, the latter for selection among pick lists. A discharge summary could be in any number of MIME types, and still have the same document type code.
The purpose of formatCode was to distinguish between the cases where type code and MIME type still didn't give you enough distinction. The problem back in 2004/2005 was very real, as a CDA and a CCR were using text/xml for MIME type, but the Schemas were very different. There are other cases where the Schema (big S) could be the same, but the schema (little s) is different, even when using CDA. Today we have CCD, and two versions of it, the one in CCD Release 1.0, and the other in CCD 1.1 found in the CCDA specification.
One of the challenges with format code is that while we understood the need for it in IHE, it took us a while to figure out the correct use. The correct use of formatCode is to present enough information to distinguish between two formats, but no more. In CCDA, there are nine different document types, eight of which are CDA Level 1/2/3 and one of which (the unstructured document) is CDA level 1 only.
For format code, we'd want to be able to distinguish that the document complied with one of the eight document types, and might also conform to the ninth (yes, formatCode could be many -- we restricted it to one in XDS because at the time it was the right thing to do, the concept was new enough that people would have understood it even less if we allowed for many). CCDA doesn't have a formatCode yet, and that's yet another discussion. CCDA is an HL7 document, and so HL7 should specify the format code for it.
My recommendation on what that should look like will likely come up on an HL7 SDWG call or on the list serve. The idea is that somewhere within it, it will distinguish two flavors of CCDA, that with structured content, and that with unstructured content. MIME type will already be the same, but typeCode is enough to distinguish between the nine varieties if we have format code, MIME type, and type code.
Is it in the 80% for formatCode (or profileCode if we rename it) to repeat in FHIR?
ReplyDeleteIf we rename it, I would encourage support for repetition. Within the use, we have several possible formatCodes that may be relevant for CCD. We can start with IHE's XPHR which every HITSP C32 conforming CCD should include, and that's the one that most everyone is using. However, HITSP C32 is more restricted, and in some scenarios, people might want to distinguish between the XPHR format, and the US variant of it if there are International connections to systems support XPHR but not HITSP C32. Within the US there are also flavors of the HITSP C32, one of which was developed by a consorium 17 states, and those folks want to be able to find and work with, and do MORE stuff with documents conforming to their specification, then they do with the HITSP C32, but they still need to interact with systems that support the HITSP C32. Right now, NOBODY does this because XDS doesn't allow for it.
DeleteI suspect this is going to come back up... I can have one DocumentReference (FHIR) that describes a Medical Summary, it points at one Binary resource. Where a GET request to that Binary will include http negotiate. I can negotiate a text/html, application/pdf, fhir/json, and fhir/xml. But all I get to use for CDA is text/xml, there is no way to indicate I specifically want CDA vs any-other-kind-of-xml, and no way to specify the specific kind of CDA I want (CDA core, C-CDA 1.1, or C-CDA 2.1)... Is this still what we want?
ReplyDelete