Stream: implementers
Topic: modelling with FHIR
Maxim Veksler (Sep 13 2018 at 06:56):
Hi all,
We're evaluating FHIR. I'm using a recent use case as a first step.
Here's a use case: Our doctors want to group patient positive symptoms into higher visual level groups.
Looking DiagnosticReport it's not clear that it can / is the correct place to model that one.
Suggestions about how I should go about this would be positivity appreciated :)
Img attached to serve as an example (non include, not adapted).
Screen-Shot-2018-09-13-at-9.51.18.png
Grahame Grieve (Sep 13 2018 at 06:59):
It sounds like Condition, and using Condition.category. Maybe - you could explain your requirement a little more
Maxim Veksler (Sep 13 2018 at 07:13):
sure.
We have a practitioner portal with which the doctor engages with the patient. We wish to create a UX that will be useful for the practicer when viewing the patient case.
A UX improvement idea our doctors had is to group the identified patient symptoms into organ system groupings.
I think I'm confused by the terminology, I'm talking about the symptoms (Headache, Fever, Fatigue and co..) not about the "root causes" that the practitioner treats. I think the Observation object is more fitting to describe this behaviour? Then again I might be misreading the spec as FHIR is new for us.
Essentially I would like the FHIR backend we're building to offer this "category" so that the UI can group the identified symptoms into logically UX useful display and I'm asking how should I model the "object" and also which "FHIR object" should I be using?
Maxim Veksler (Sep 13 2018 at 07:14):
I'd also add to this further question if I may - does FHIR uses a standard ontology the might be useful for modelling these things?
Grahame Grieve (Sep 13 2018 at 11:37):
well, perhaps Observation is better. I don't know what we have for grouping observations like this
Grahame Grieve (Sep 13 2018 at 11:38):
there are standard terminologies that convey some information that may help you. or not. Even when they are well defined, they are often used correctly. Do you know what terminologies are going to be used? we do not have agreement - everyone uses different terminologies
Brian Reinhold (Sep 13 2018 at 11:46):
sure.
We have a practitioner portal with which the doctor engages with the patient. We wish to create a UX that will be useful for the practicer when viewing the patient case.
A UX improvement idea our doctors had is to group the identified patient symptoms into organ system groupings.
I think I'm confused by the terminology, I'm talking about the symptoms (Headache, Fever, Fatigue and co..) not about the "root causes" that the practitioner treats. I think the Observation object is more fitting to describe this behaviour? Then again I might be misreading the spec as FHIR is new for us.
Essentially I would like the FHIR backend we're building to offer this "category" so that the UI can group the identified symptoms into logically UX useful display and I'm asking how should I model the "object" and also which "FHIR object" should I be using?
@Maxim Veksler Would it make sense to group the Observations into a composition Bundle or some other type of simpler Bundle that continues to exist on the server? Not a transaction bundle!
René Spronk (Sep 13 2018 at 11:50):
Maxim is UK based (looking at his Time zone), so we'd probably be talking SNOMED. Question is whether its ontological relationships are sufficient for this use case.
Question is whether one would a) tag observations somehow 'to which category they belong', or b) to create some UI-oriented grouper thing (List, or Basic) to reference the observations of a particular category.
Both could be made to work, as could relying on the ontologies of SNOMED.
Lloyd McKenzie (Sep 13 2018 at 15:21):
If the groupings are user-specific, List would be appropriate. It lets you create and maintain arbitrary groupings of records. If it's intended to be determined automatically based on the code, then you can either build the logic in to infer it as you consume the data and create an extension to use it in your local persistence; or you can try to convince all of your data sources to do the work for you and populate the extension before you get the data.
Maxim Veksler (Sep 14 2018 at 06:47):
@Grahame Grieve thank you for helping out. SNOMAD-CT seems reasonable, as well as ICD-10.
Could you please explain further your point about
we do not have agreement - everyone uses different terminologies
I was under the impression that FHIR goal of enabling medical discourse between systems mandates that a standard medical terminology would be defined and used. Have I got it wrong?
Regarding which ontologies (standard or proprietary or a mix of both) we are going to be using, it's a decision point. That's why I'm asking so many questions :)
Maxim Veksler (Sep 14 2018 at 06:57):
@Maxim Veksler Would it make sense to group the Observations into a composition Bundle or some other type of simpler Bundle that continues to exist on the server? Not a transaction bundle!
@Brian Reinhold yes it would, under this use case. I do think we're hoping to have the backend useful enough for other frontends, which is why I'd generally prefer the presentation logic to be within the smart client (no pun intending). Being new to FHIR, and since the standard is large and includes I haven't considered the Composition because I didn't know of it's existence. :)
Maxim Veksler (Sep 14 2018 at 07:05):
Maxim is UK based (looking at his Time zone), so we'd probably be talking SNOMED. Question is whether its ontological relationships are sufficient for this use case.
Question is whether one would a) tag observations somehow 'to which category they belong', or b) to create some UI-oriented grouper thing (List, or Basic) to reference the observations of a particular category.
Both could be made to work, as could relying on the ontologies of SNOMED.
@René Spronk thank you for helping out!
My time zone is IST, I'm from Tel Aviv. We've launched in US and IL.
I imagine that once a symptom has been recored it should be automatically self grouped by the system into the relevant groupings. I'm hoping to use standard ontology that intuitively I imagine could support this specific grouping request which is to group by organ system. My question is, since I'm looking mostly to learn from other experienced professional is Q1: which ontology likely provides these anatomical mappings, and Q2: is FHIR standardised support this use case.
Maxim Veksler (Sep 14 2018 at 07:07):
If the groupings are user-specific, List would be appropriate. It lets you create and maintain arbitrary groupings of records. If it's intended to be determined automatically based on the code, then you can either build the logic in to infer it as you consume the data and create an extension to use it in your local persistence; or you can try to convince all of your data sources to do the work for you and populate the extension before you get the data.
@Lloyd McKenzie by extension you mean a field that will be added to the Observation object?
Grahame Grieve (Sep 14 2018 at 08:25):
I was under the impression that FHIR goal of enabling medical discourse between systems mandates that a standard medical terminology would be defined and used. Have I got it wrong?
That's both wrong and right. To truly enable medical discourse, everyone would have to use a common medical terminology. And someone(s) would have to magically code all the trillions of existing records up as well, or we'd have to through them away. But we don't live in a world where either of these is an option, and people won't agree in principle anyway - there's no way to make them. For example, most countries in the world use LOINC for observations. but a few have government policy that LOINC is not used, something else is. We can't change that. So all we can do is encourage consistency, create infrastructure to deal with the lack of it (see terminology services) and allow for smaller groups to make such agreements (where it's easier, but not easy)
Lloyd McKenzie (Sep 14 2018 at 14:38):
For things like drugs there are often regulations that require national code systems. For clinical domains, some countries mandate SNOMED CT, but other countries don't have a license and prefer other code systems. Imagine trying to standardize all billing codes throughout the world across human and veterinary medicine and covering all disciplines. That will never happen because billing codes embed a great deal of culture and policy and both are highly variable.
Maxim Veksler (Sep 16 2018 at 08:34):
I was under the impression that FHIR goal of enabling medical discourse between systems mandates that a standard medical terminology would be defined and used. Have I got it wrong?
That's both wrong and right. To truly enable medical discourse, everyone would have to use a common medical terminology. And someone(s) would have to magically code all the trillions of existing records up as well, or we'd have to through them away. But we don't live in a world where either of these is an option, and people won't agree in principle anyway - there's no way to make them. For example, most countries in the world use LOINC for observations. but a few have government policy that LOINC is not used, something else is. We can't change that. So all we can do is encourage consistency, create infrastructure to deal with the lack of it (see terminology services) and allow for smaller groups to make such agreements (where it's easier, but not easy)
@Grahame Grieve Very insightful, thank you.
I understand the need for being able to translate between different terminologies, using terminology services (btw, any known implementations of these?).
My point (I think... still formalising the conceptual grasp) is that intuitively I assumed these should be have been a "core language" that enabled the communications (even between internal systems of the same vendor) and that this communication have been SHOULD recommended by FHIR standard.
I understand that this is not the case? Then could you please explain how FHIR enabled the communication without specifying the "meaning" of what is being expressed.
Please forgive me if this is getting too philosophical, I'm an intuitive thinker and trying to understand things from first principles.
Maxim Veksler (Sep 16 2018 at 08:38):
For things like drugs there are often regulations that require national code systems. For clinical domains, some countries mandate SNOMED CT, but other countries don't have a license and prefer other code systems. Imagine trying to standardize all billing codes throughout the world across human and veterinary medicine and covering all disciplines. That will never happen because billing codes embed a great deal of culture and policy and both are highly variable.
@Lloyd McKenzie yes I agree. But I think we've viewing at the problem from a different PoV. Let me try to cast it, I'm imagining a vendor (a startup in my case) that uses FHIR internally. I'm hoping that FHIR provides safe default. Then when billing / integration with 3rd parties (i.e. countries !!) a sort of bridge (i.e. terminology services) is created, per case. Long term strategy I'd think that is wise. This was my assumption about the goals of FHIR. Please correct me if I'm not getting it, because well... I want to be precise in my speech.
Lloyd McKenzie (Sep 16 2018 at 16:13):
Let's use an example. FHIR defines a MedicationRequest resource that can be used to represent drug prescriptions. However, most countries in the world use different terminologies to identify medications, typically tied to the drug regulation process which is generally managed along national boundaries. For example, the U.S. uses NDC codes and RXNorm, Canada uses DIN codes and CCDD. The UK (I believe) uses SNOMED-CT. So you're never going to get a U.S.-based system to fully support (decision support, costing decisions, claims submission, etc.) a prescription that comes from the UK. Nor will a Canadian system full support one that comes from the U.S.
However, we can still define very clearly where the "drug code" goes and what levels of granularity it will have. We can also define a lot of other discrete data elements around it such as dose quantity, does units, route, etc. And some of those coded elements are easier to impose expectations on (in part because the number of codes involved is more managable to translate). We can also define places where human-readable "string" versions of the drug code can be conveyed so that even if the computer systems don't recognize the code, humans can at least see something useful.
The reality is that most of the use-cases for interoperability don't involve data crossing borders, so the fact that the drug code systems are different doesn't impact a large percentage of care. And from a software vendor perspective, having the same data structure in different countries that only differs by terminology choice makes it much easier to design a single solution that can be leveraged in multiple jurisdictions. And if interoperability across national borders is deemed to be really important, then the parties involved can undertake the expense of developing and maintaining a mapping between the code systems.
The reality is that our objective isn't to "achieve interoperability" because we'll only get absolute interoperability when all data goes through one system and is sent and received by users with the same business processes, thought processes and culture. Our objective with FHIR (and other healthcare standards) is to improve interoperability. We drive greater consistency where we can and try to make it easier for systems to do things in a way that makes it more likely for useful data to flow between systems. It's a tremendous balancing act. If we get too tight, then the implementer community won't use the standard because it's too hard, because it doesn't meet the regulatory requirements of their implementation spaces and/or because their users won't tolerate it. If we make it too loose, then implementers just do whatever they've always done and call it "standard" and we get no improvement in interoperability. And of course, the underlying regulations and practice of medicine continue to evolve underneath the process, making it still more entertaining... :)
Grahame Grieve (Sep 16 2018 at 21:09):
could you please explain how FHIR enabled the communication without specifying the "meaning" of what is being expressed
What we do is incomplete; in order to make things 'work' additional agreements are needed. Both national agreements, and institutional/project based agreements. It would certainly be better if people would agree so that we could simplify the standard further, but we can't even agree about best practice.
Grahame Grieve (Sep 16 2018 at 21:12):
there are many terminology services - see http://wiki.hl7.org/index.php?title=Open_Source_FHIR_implementations for a start, but no one has assembled a complete list. I'd list Ontoserver, Apelon DTS, Terminz, Art Decor, VSAC, HAPI, fhir.loinc.org and my own server at http://healthintersections.com.au/FhirServer - but these are all different sorts of servers that are adaptable to some degree or other. Ontoserver is the best general purpose server
Last updated: Apr 12 2022 at 19:14 UTC
