Stream: implementers
Topic: Mapping to FHIR fields
Tri Do (Oct 15 2021 at 07:26):
I'm currently implementing an online health-care meeting between practitioner and patient, that occur during an life-cycle of Encounter resource. I have a box for practitioner to take his notes about observation or something else in this meeting, so which FHIR field/resource should I use to store this text?
Daniel Venton (Oct 15 2021 at 12:06):
Do you just want to capture the narrative of what the provider typed in? Sounds like you could just put that in the .text of the Encounter resource itself.
Do you want to capture a Condition? That would be a Condition.
Do you want to capture an Observation? Observation (only visual types I imagine).
Tri Do (Oct 15 2021 at 13:08):
Is this true if I use Observation to store diagnosis of doctor after provided symptoms by patient?
Lloyd McKenzie (Oct 15 2021 at 13:13):
Typically symptoms would be Observations and diagnoses would be Condition (though there's some fuzziness about how this happens in the real world).
If you're just capturing a whole collection of raw notes that don't have discrete information, you can look at DocumentReference - that's how "clinical notes" are typically captured.
Michele Mottini (Oct 15 2021 at 13:22):
I'd rather use DiagnosticReport for unstructured notes
Tri Do (Oct 15 2021 at 13:28):
Clinical notes is exactly what I want, I think DocumentReference is fit for my case.
Thank you all :smile:
Lloyd McKenzie (Oct 15 2021 at 14:25):
@Michele Mottini I understand, but that's not where the community landed.
Michele Mottini (Oct 15 2021 at 14:37):
Mhh, https://www.hl7.org/fhir/us/core/clinical-notes-guidance.html
Lloyd McKenzie (Oct 15 2021 at 14:44):
Hmm. Looks like things have evolved since I last looked. So DiagnosticReport and DocumentReference are both viable. Thanks @Michele Mottini
Michele Mottini (Oct 15 2021 at 14:48):
It's a case of 'the community cannot decide'!
Rik Smithies (Oct 15 2021 at 16:16):
Looking at that reference - specifically the diagram - it seems DiagnosticReport is for things to to do with diagnostics (either results or their interpretation), and that unstructured "clinical notes" (assuming not about a report) would be in the cyan section at the right. Should I be interpreting that differently?
Tri Do (Oct 27 2021 at 10:08):
Hello all, I'm currently implementing MedicationRequest resource, is there a field for storing the number of tablets/pills (the amount of medicines in one request)? Thanks for help.
Lloyd McKenzie (Oct 27 2021 at 13:21):
You mean dispenseRequest.quantity?
Tri Do (Oct 28 2021 at 02:39):
I saw this field but I didn't understand it at all, is it the amount of medicines that doctor prescribe for patient?
Lloyd McKenzie (Oct 28 2021 at 02:45):
It's the amount of medication to be provided in a single dispense event. For example, if a clinician prescribes 30 tablets, 5 refills, dispenseReqest.quantity would be the "30 tablets" and numberOfrepeatsAllowed would be 5 - for a total authorization of 180 tablets.
Akira Kakkar (Dec 14 2021 at 08:07):
Hello all, I am looking for a field to add practitioner's bio (background, short intro para, and etc). This is used when patient looks for a practitioner. Looks like practitioner resource does not have this field. Do I need to use extension for this? Anybody faced similar issue before?
René Spronk (Dec 14 2021 at 08:12):
The text data element could be used for this purpose.
Akira Kakkar (Dec 14 2021 at 09:08):
I could not find text data element in hl7.org. Do you mean original text(https://www.hl7.org/fhir/extension-originaltext.html)? or something else you are thinking?
Or I am suspecting this, https://www.hl7.org/fhir/narrative.html
René Spronk (Dec 14 2021 at 09:16):
Practitioner is a 'specialisation' of the DomainResoirce FHIR resource. See http://build.fhir.org/domainresource.html , this has the text data element which is present in almost all FHIR resources. See http://build.fhir.org/narrative.html for additional detail. Your 'bio' appears to be textual data, so text is a candidate.
Akira Kakkar (Dec 14 2021 at 09:18):
Thank you for the detailed explanation. It's clear to me now.
Lloyd McKenzie (Dec 14 2021 at 16:16):
Resource.text is expected to be a human-readable view of the whole resource. It couldn't just be a bio. My recommendation would actually be to use an extension. (And perhaps submit a change request for it to be added as a standard extension.)
Elliot Silver (Dec 14 2021 at 17:31):
Why not do a DocumentReference (or multiple document references) with the practitioner as a subject?
Lloyd McKenzie (Dec 14 2021 at 17:51):
You could, but that requires a separate resource. If the bio is just a 'property' of the Practitioner, a separate DocumentReference is kind of heavy.
Akira Kakkar (Dec 15 2021 at 02:51):
I see your point of using ext. btw, what is the case use case of text field then?
René Spronk (Dec 15 2021 at 07:29):
The text field acts as a summary of all of the content of a resource, in case a processing system doesn't support, or doesn't wish to support, the structured data in the data elements. For a Practitioner resource, text SHOULD (per the fhir spec) contain narrative which details the key demographics of the practitioner. This kind of narrative is often auto-generated by software. But that need not be the case, the narrative can be constructed by a human, and/or can be richer in detail than what's present in the structured/coded elements. So a 'bio' could be added to text as well.
Using an extension just for the bio would work as well, just keep in mind that you'll still have to (SHOULD) populate the narrative in text as well.
Lloyd McKenzie (Dec 15 2021 at 20:21):
Agree that a bio could be added to the text. But if your plan is to display Practitioner.text in a UI element called "bio", you're likely to get more than you bargained for. If you have a discrete element for 'bio' and want to retain its discreteness, use an extension. If the bio is important to someone looking at a human-rendered view of the Practitioner, then by all means stick it in the narrative too.
Last updated: Apr 12 2022 at 19:14 UTC
