Stream: implementers
Topic: CCDA DocumentReference Category
Hayden Bader (Apr 20 2021 at 21:00):
I hope this is the right place. Also, forgive me if I use some of the wrong terminology for CCDA docs - I'm still kind of learning in that area.
In the US Core DocumentReference spec, the category field has "clinical-note" as the only code option with a binding level of extensible.
We are using this category code for "handwritten" progress notes at the moment, but were looking to represent CCDA documents as well. I'm not sure whether CCDA documents actually would fall under the "clinical-note" category or not. The sticking point for me right now is that these documents are essentially generated on request based on existing data, but are not actually "written" by providers/professionals. However, they do still end up essentially containing clinical data about a patient.
This is further complicated by the class code / type code associated with these CCDA documents. The documents I'm looking to map have the same class codes and type codes. These codes are 11506-3 and 34133-9 which are also listed in the valuesets for category/type in standard DocumentReference. But 11506-3 is also explicitly called out in the DocumentReference US Core type binding (though 34133-9 is not, and 11506-3 is not listed as a category option)
There's a lot to unpack here, but any insights? I think I can break this down into more straightforward questions
1) Should CCDA documents be categorized as "clinical-notes"
1) a) If so, could I use the associated LOINC class codes I have as additional codings on that category?
1) b) If not, I imagine I'd want to use the existing class codes as the category, right?
https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-documentreference.html
https://build.fhir.org/ig/HL7/US-Core-R4/ValueSet-us-core-documentreference-category.html
Cooper Thompson (Apr 20 2021 at 21:09):
@Eric Haas - should we add a code to the DocRef.category valueset in US Core for the documents generated by the $docref operation on DocumentReference? The example response doesn't include a category. US Core doesn't have a DocRef profile for the CCDA container, so I guess we could just omit the category property completely for DocRefs for CCDAs?
Eric Haas (Apr 20 2021 at 22:08):
@Brett Marquard ?
my answers:
1) Should CCDA documents be categorized as "clinical-notes"
yes
1) a) If so, could I use the associated LOINC class codes I have as additional codings on that category?
Category element is 1..* so you could have additional category schemes if you want
I would discourage using additional codings to refine the category - its intent is to be a coarse grouping element. The type is where you define the document. (e.g. Progress Note)
1) b) If not, I imagine I'd want to use the existing class codes as the category, right?
see above answer, a fine grained categorization blurs into the type element and I would stick to type.
Eric Haas (Apr 20 2021 at 22:14):
Cooper Thompson said:
Eric Haas - should we add a code to the DocRef.category valueset in US Core for the documents generated by the $docref operation on DocumentReference? The example response doesn't include a category. US Core doesn't have a DocRef profile for the CCDA container, so I guess we could just omit the category property completely for DocRefs for CCDAs?
I don't know what you mean by "US Core doesn't have a DocRef profile for the CCDA container," but In the next version of US Core we have relaxed the constraint on $docref so there is only a recommendation that the server SHOULD return a US Core Docref Profile.
Brett Marquard (Apr 21 2021 at 11:36):
If your system tracks a generic 'Progress Note', and very specific progress notes - 'Dialysis and Therapeutic apheresis Progress note' then fine to use Category = Progress Note.
Brett Marquard (Apr 21 2021 at 11:36):
It still should be a relatively course grouping.
Cooper Thompson (Apr 21 2021 at 13:40):
@Eric Haas - you really think C-CDA documents would be considered a clinical-note? That seems very odd to me. C-CDA documents could contain some note information, but it doesn't make sense to me to consider the C-CDA itself a note. I'll admit I'm not a C-CDA expert though, so if that does actually make sense, I'd be interested in learning the specifics around why.
John Moehrke (Apr 21 2021 at 13:47):
There is a mapping between CDA and DocumentReference in the FHIR core spec -- http://hl7.org/fhir/documentreference-mappings.html#cda
John Moehrke (Apr 21 2021 at 13:49):
@Emma Jones @Keith Boone @Tone Southerland @Lisa Nelson -- is there general guidance in C-CDA or an IHE profile using C-CDA that would answer this?
Emma Jones (Apr 21 2021 at 18:19):
There is general guidance about C-CDA use of clinical notes in the C-CDA Companion Guide Release 2 - see section 2.7
http://www.hl7.org/ccdasearch/pdfs/Companion_Guide.pdf
Cooper Thompson (Apr 21 2021 at 18:27):
I think that is the other way around. That is about how to represent clinical notes in a C-CDA. The question we have is what DocRef category should be used to describe a C-CDA. For example, if we have an CCD in C-CDA format, what DocRef.category should that have. "clinical-note" doesn't seem like the right category to describe a CCD.
Gay Dolin (Apr 21 2021 at 21:52):
While it may be a stretch to call CCD a "Clinical Note", once its created it is most certainly a "clinical document". Many of the other Documents in C-CDA are "true" Clinical Notes (Discharge Summary, Transfer Summary, Referral Note, Consultation Note, or Progress Note). The most valuable aspect when referencing a document is the reference to the actual documentType anyway - and all of the documentTypes in C-CDA are in that set (and more of course (scale-type = "doc")). In US Core, the binding is to DocumentReferenceCategory is extensible - so you could just repeat the 34133-9" Summarization of Episode Note" if you wanted, if you don't want to consider it a clinical-note and therefore "there is no applicable concept in value set (based on human review)" and it adds value to you document management system to do so
John Moehrke (Apr 22 2021 at 11:49):
having everything called a clinical-note is not helpful. Surely there is a different category for summary than clinical-note.
How about SNOMED-CT 422735006 "Summary clinical document"?
Cooper Thompson (Apr 23 2021 at 18:59):
My reservation with using that SNOMED is that we'll then have two codes for DocRef.category: clinical-notes and 422735006. Conceptually those make sense, but just visually they are so very different. Using a code like summary-document just makes it more consistent.
Hayden Bader (May 06 2021 at 17:32):
Sorry for the long hiatus - I'm back to this question.
In general, what I've picked up is the intent of category and type are to filter DocumentReference by a coarse-grained grouping and a finer-grained grouping respectively.
From what I know about our C-CDAs we are usually using them to summarize information - like a patient's information or what happened in an encounter. These documents are definitely clinical information as @Gay Dolin mentioned, but don't really align with my understanding of "clinical-note" at least, so I'd also hope that we could update the US Core category profile to allow something like "summary-document" as @Cooper Thompson mentioned.
I think that would give an added benefit to the US Core profile in that it would appear a little more flexible. Right now, it kind of looks like everything in the US Core profile will be a "clinical-note". Now, that's not really the case because the binding on category is extensible. I'd just like to note that with only one example, the use-cases for category can give the appearance that all everything that would be a US Core note would be a clinical-note - which others noted wouldn't be super helpful when attempting to search/filter for certain pieces of data.
Short version:
Our CCDAs do contain clinical data but that appears to me to run towards a potential problem where too many DocumentReferences are called "clinical-notes". For our use-case, our CCDAs are usually used to summarize other clinical information, so I think using something along those lines as a broad category that can be drilled down on using type would be the most desirable.
@Eric Haas does this change your answer to the previous question?
Last updated: Apr 12 2022 at 19:14 UTC
