Stream: implementers
Topic: ClinicalImpression for GP meeting note
Cristian Osorio Bretti (Mar 08 2021 at 10:56):
Hi! We at Kry/Livi are trying to model our "clinician notes" from a meeting with a GP in FHIR. In our case, clinician notes contain things like "reason for seeking care", different fields relating to anamnesis (e.g. previous diseases, allergies etc) and possible diagnosis codes. So from a SOAP perspective I guess it contains not only A but also some of S and O.
After looking through the available resources in FHIR, we found the ClinicalImpression seemed like the most suitable Resource, where we can put a lot of information under the investigation field, some as specific FHIR Resources (e.g. Allergies) but most of them as generic Observations.
I have looked through the Confluence page to try to get a better understanding, but the links to the storyboards unfortunately seem broken: https://confluence.hl7.org/display/PC/Clinical+Assessment. I also notice that the Resource is currently in Draft (FMM 0), but no updates seem to have happened since in the past few years.
So my current questions are:
- Are we using the Resource as intended, or is there a more suitable resource(s) that we have missed?
- We noticed in another message that the investigation element has been merged with the “supporting info”-field in R5. Are there any more changes discussed for R5? Is there a centralized place, mailing list, or suitable substream here in Zulip where we can receive updates regarding this Resource? As one of Europe's biggest digital GP practices we might be able to offer some valuable input towards future developments of the Resource.
Lin Zhang (Mar 08 2021 at 11:14):
As a broad category of Clinical Documents, a Clinical Note might be assembled using various Resources, such as Bundle, Compositon and Observations etc.
Rob Hausam (Mar 08 2021 at 13:48):
@Cristian Osorio Bretti Those are good questions, and a good offer, which I think should help as we have further discussion on this resource in the Patient Care WG (and you're right, there hasn't been much of that happening over at least the past couple of years, but we've recently started to bring it up again and hopefully can move it forward). @Michelle (Moseman) Miller?
Håkan MacLean (Mar 15 2021 at 15:46):
So a follow up question re. this topic. We currently want to store our "primary" and "secondary" diagnosis. The field "finding" seems relevant, but how do we encode the primary vs secondary part? What is the correct FHIR way to do this? Could you imply this relationship by using order of the list, i.e. primary diagnosis first? Another idea was to put "primary" in itemCodeableConcept and the actual diagnosis in "itemReference", but this feels wrong to me. I would expect itemCodeableConcept or itemReference to be populated, not both?
Lin Zhang (Mar 15 2021 at 15:58):
At least, LOINC Codes for such diagnoses and the Observation resource could be used to do it.
Håkan MacLean (Mar 15 2021 at 18:47):
Lin Zhang said:
At least, LOINC Codes for such diagnoses and the Observation resource could be used to do it.
Ah, I see that LOINC has Primary diagnosis, thanks. But does it make sense to set itemCodeableConcept to this value and the itemReference to the actual value (say an ICD-10 code). I would interpret the standard as you can use either CodeableConcept or Reference to define a Finding. Now we are somehow using them together but meaning different things, with one as the actual value and one as a qualifier. Is this really ok?
Lloyd McKenzie (Mar 15 2021 at 20:53):
Typically the notion of 'primary' vs. 'secondary' apply to the context of a Claim or an Encounter - they're not something that's intrinsic to the Condition itself. (A Condition that's 'primary' for one Claim might be 'secondary' for another.) Encounter and Claim both allow the Observations and Conditions they reference to be ordered by rank.
Håkan MacLean (Mar 15 2021 at 22:44):
Lloyd McKenzie said:
Typically the notion of 'primary' vs. 'secondary' apply to the context of a Claim or an Encounter - they're not something that's intrinsic to the Condition itself. (A Condition that's 'primary' for one Claim might be 'secondary' for another.) Encounter and Claim both allow the Observations and Conditions they reference to be ordered by rank.
Thanks for taking the time to respond. When you say that they allow the "references to be ordered by rank", how would I do this in practice?
Michele Mottini (Mar 15 2021 at 23:09):
Using http://hl7.org/fhir/encounter-definitions.html#Encounter.diagnosis.rank (in the case of Encounter)
Lloyd McKenzie (Mar 16 2021 at 05:23):
And Claim.diagnosis.sequence and Claim.diagnosis.type on Claim
Håkan MacLean (Mar 16 2021 at 08:16):
Thanks for both of your replies Michele and Lloyd! I have now solved it using a contained Encounter, which in turns references two contained Conditions, hehe. Would it make sense to have a an optional rank field for ClinicalImpression.finding?
Lloyd McKenzie (Mar 16 2021 at 13:43):
Not sure why you'd make them 'contained' - you're saying that these conditions are only meaningful and only have existence in the context of a particular encounter?
What would 'rank' mean in the case of a ClinicalImpression? What behavior would it drive?
Last updated: Apr 12 2022 at 19:14 UTC
