Stream: argonaut
Topic: US Core Clinical Notes - non-Path Lab DocumentReference
Cooper Thompson (Jul 31 2020 at 14:39):
Am I missing something in the US Core IG about how DocRefs for non-Pathology Laboratory Report Narratives should be represented? For example the scanned CBC report example in the 2.2.1.2 section. The DocRef.type binding doesn't have any good options for non-path lab, but the Future Work section in the notes guidance says servers SHALL expose laboratory report narratives via DocRef.
Drew Torres (Jul 31 2020 at 18:42):
Well I guess the profile technically doesn't apply to those type of reports.
Drew Torres (Jul 31 2020 at 18:43):
We have to expose them as both DiagnosticReports and DocumentReference, but when we expose them as DocumentReference we can't really follow the document reference profile
Drew Torres (Jul 31 2020 at 18:43):
since the value sets don't align well for labs.
Brett Marquard (Aug 03 2020 at 15:36):
@Cooper Thompson Are there specific LOINC codes you have in mind? We definitely intend to grow the minimum DocumentReference.type value set over time
John Moehrke (Aug 03 2020 at 15:40):
There is a resolved CR to add all LOINC codes of document type. this is for FHIR core.
John Moehrke (Aug 03 2020 at 15:43):
Drew Torres said:
since the value sets don't align well for labs.
OH, US-Core made the binding required... ouch. core has it preferred binding
Cooper Thompson (Aug 03 2020 at 16:18):
@Brett Marquard I hadn't looked into what LOINC codes might work. Ideally something super generic like "Lab Report", since for scanned reports we may not know what specific type of lab it is.
Cooper Thompson (Aug 03 2020 at 16:20):
Also, is the Future Work part of the IG? Are SHALL's in that section required according to the ONC Final Rule?
Brett Marquard (Aug 03 2020 at 18:13):
bummer, I wish would have cleaned up that section during the errata.
Brett Marquard (Aug 03 2020 at 18:14):
no, I wouldn't expect ONC/Inferno to interpret conformance verbs in the future work area as authoritative.
Yunwei Wang (Aug 04 2020 at 17:37):
That list is NOT exactly same as the one in ClinicalNote Guidance
Brett Marquard (Aug 05 2020 at 15:30):
It's close, Laboratory is not in both.
Yunwei Wang (Aug 05 2020 at 16:39):
Inferno tests the the requirement in ClinicalNote Guidance.
Cooper Thompson (Aug 05 2020 at 18:28):
What exactly is the Inferno test for non-pathology lab? I.e. how did Inferno interpret the ClinicalNote Guidance for non-path lab?
Yunwei Wang (Aug 05 2020 at 19:21):
Inferno tests these "SHALL" requirement specified in ClinicalNote Guidance:
Specifically, this implementation guide defines the exchange of the following five “Common Clinical Notes” which systems SHALL support.
Consultation Note (11488-4)
Discharge Summary (18842-5)
History & Physical Note (34117-2)
Procedures Note (28570-0)
Progress Note (11506-3)
and three DiagnosticReport categories which systems SHALL support.
Cardiology (LP29708-2)
Pathology (LP7839-6)
Radiology (LP29684-5)
and
In order to enable consistent access to scanned narrative-only clinical reports the Argonaut Clinical Note Server SHALL expose these reports through both DiagnosticReport and DocumentReference by representing the same attachment url using the corresponding elements listed below.
Robert McClure (Aug 11 2020 at 01:05):
@Yunwei Wang Those three LP codes should NOT be used to test conformance and that guidance has been a source of confusion since day one. There will never be a document identified with any of those codes and no one should ever use one in an instance of a document.
Swapna Abhyankar (Aug 11 2020 at 13:43):
@Robert McClure agree that those LP codes (or any LOINC Part codes) should never be used to identify a document, but they can be used to categorize documents as @Yunwei Wang described.
Josh Mandel (Aug 11 2020 at 14:00):
To make sure I understand Swapna, you're saying that LP codes would never appear as DocumentReference.identifier (indeed, since they're Codings and not Identifiers they couldn't), but might appear as a .code or .category (i.e., they might appear somewhere in an instance of a document).
Brett Marquard (Aug 11 2020 at 14:15):
Only in DiagnosticReport.category
Yunwei Wang (Aug 11 2020 at 14:29):
The guideline says that those LP codes are used in DiagnosticReport.category
Brett Marquard (Aug 11 2020 at 14:31):
eek, I typed too vast, thanks Yunwei.
Swapna Abhyankar (Aug 11 2020 at 15:31):
@Josh Mandel , LOINC terms are used for DiagnosticReport.code, and LOINC Parts can be used for DiagnosticReport.category. I'm not entirely certain about DocumentReference, but after reading the spec, I think LOINC terms can be used for DocumentReference.identifier, and LOINC Parts for DocumentReference.category. @Brett Marquard , do you agree?
I don't see an element called DocumentReference.code on this page - http://hl7.org/fhir/documentreference-definitions.html#. There's DocumentReference.relatesTo.code but that's defined as "The type of relationship that this document has with anther document."
Yunwei Wang (Aug 11 2020 at 15:46):
@Swapna Abhyankar DocumentReference.type binds to LOINC code
.
Brett Marquard (Aug 11 2020 at 16:18):
DocumentReference.identifier is for 'business identifiers'; LOINC belongs in DocumentRefernce.type
Swapna Abhyankar (Aug 11 2020 at 22:16):
DocumentReference.type is the "kind of document" - to me this is similar to category in that it's specifying the general class (H&P, Progress note, etc.), and not identifying the exact note itself. e.g., LOINC has more than 100 specific progress note terms (https://search.loinc.org/searchLOINC/search.zul?query=%22progress+note%22+scale%3Adoc) Type would be the general kind of note, and category would be the clinical domain (cardiology, oncology, etc.)
Robert McClure (Aug 11 2020 at 23:10):
@Swapna Abhyankar This is indeed confusing because DiagnosticReport.code (binding Extensible to US Core Diagnosticreport Report And Note Codes) seems to provide the same granularity of information expected in DocumentReference.type (binding REQUIRED to US Core DocumentReference Type). It is this REQUIRED binding that we are having issues with that has prompted the off-cycle meeting.
The .category elements for both these are bound extensible and are where "general type of document" is represented. What is odd is that for DiagnosticReport.category the binding is a value set of LOINC Parts noted before as US Core DiagnosticReport Category but for DocumentReference.category the binding (also Extensible) is to a single made-up code in US Core DocumentReference Category and not a set of proper LOINC part codes. I think we should look to improve this when we look at the "type" value set above.
John Moehrke (Aug 12 2020 at 13:27):
the category should be a small valueSet made up of big categories. There are interests in defining a valueSet, but it is hard to come up with one that is international and supports all the potential use-cases.
John Moehrke (Aug 12 2020 at 13:27):
I would expect the actual category valueSet used would be regional
Last updated: Apr 12 2022 at 19:14 UTC
