Stream: implementers
Topic: CDS Inferences
Andrew Ross (Jun 22 2016 at 19:38):
Let's say I have a service that is able to read in patient Observations/Conditions and infer new Observations/Conditions as a result, which it might want to send back to the EHR or expose to the doctor directly.
As a concrete example, imagine I'm given a series of hemoglobin concentration Observations, the most recent of which is a measurement of 8 g/dl (very low) made yesterday, from which our service infers that the patient is anemic. Let's also imagine we have other Observations that indicate the patient does not have an iron deficiency, meaning the anemia is due to other causes.
How do we then expose this information to a SMART app?
One option we're considering is:
- send two Conditions, one for iron deficiency and one for anemia
- iron deficiency has verificationStatus = refuted, anemia has verificationStatus = confirmed
- we reference the associated Observations as evidence
- we leave most of the fields blank, since we cannot reference our service as the asserter and the onset value might be ambiguous (if the condition was inferred from many different observations that were made at different times)
Another is:
- send two Observations, one asserting the patient is not iron deficient and one asserting the patient is anemic
- for their values, use a codeable concept meaning no and yes, respectively
- reference our own service as an Organization under performer, or perhaps as adevice.
- potentially set the method of observation to be something like algorithm
- reference the observations we used to infer them under related with type = derived-from
- maybe set the status to preliminary, since these observations are not registered in the EHR / canonical source of the patient's information.
The Observation case seems to be more applicable, since there is more explicit support for programmatic inferences, but the Condition case maps better to the boolean values.
Anyone have thoughts on this?
Kevin Shekleton (Jun 22 2016 at 19:42):
@Andrew Ross - have you heard of CDS Hooks?
Josh Mandel (Jun 22 2016 at 19:42):
Do you expect your changes to just immediately take effect (in which case, PUT to replace the bad Observation -- though I should say most EHRs don't and perhaps won't support this), or are they more like suggestions of things the user might do (in which CDS Hooks could be a good interface point)
Andrew Ross (Jun 22 2016 at 19:43):
We've definitely heard of CDS hooks, but this is in the context of a more-or-less readonly SMART app
Josh Mandel (Jun 22 2016 at 19:44):
If it's read-only, then how are you anticipating "sending" these results?
Andrew Ross (Jun 22 2016 at 19:45):
We don't necessarily even want to -- it's informational, and if anything would be sent back to the EHR, it would be a suggested action they opt to complete, not any fact-type resource
Andrew Ross (Jun 22 2016 at 19:47):
Essentially, we get a set of FHIR Observations and Conditions from one service, do mapping and inference to expand and/or transform that set, then display something to the doctor within our application
Josh Mandel (Jun 22 2016 at 19:47):
Hmm. Well, if you're really "read-only" the best you can do is display a message/suggestion to the clinician. If you can write data, the FHIR REST API is a good fit. If you want to insert concrete suggestions (with action buttons) into the EHR UI, CDS Hooks could help.
Andrew Ross (Jun 22 2016 at 19:47):
Right, unfortunately neither of those will work in our case, given the business/design requirements
Andrew Ross (Jun 22 2016 at 19:48):
the main question is whether there are any best practices for representing those inferences using FHIR in a way that distinguishes them from the raw/actually-measured observations we're getting from the EHR
Josh Mandel (Jun 22 2016 at 19:48):
If none of these 3 is a fit, what more precisely are you looking/hoping for?
Josh Mandel (Jun 22 2016 at 19:49):
I'm not clear on what this question means in the abstract (i.e. without understanding who is sending/receiving/consuming/requesting/displaying these inferred FHIR Resources).
Andrew Ross (Jun 22 2016 at 19:49):
Well, in concrete terms, let's say you have a service that determines whether a patient is anemic, and whether that anemia is chemotherapy-induced or due to other causes
Andrew Ross (Jun 22 2016 at 19:50):
The EHR only sends you basic observations of things like blood concentration measurements of various quantities
Josh Mandel (Jun 22 2016 at 19:50):
And you'd like the EHR to invoke this service in a back-end, automated way (no user involvement)?
Andrew Ross (Jun 22 2016 at 19:50):
This is in the context of a SMART on FHIR application that has its own UI
Kevin Shekleton (Jun 22 2016 at 19:50):
So you can't just show the suggestion in a textual manner in your SMART app UI?
Andrew Ross (Jun 22 2016 at 19:50):
the service is launched from within the EHR, but doctors interact with it in a separate screen
Josh Mandel (Jun 22 2016 at 19:50):
So when a user launches the app, the app can GET the relevant observations from the EHR.
Andrew Ross (Jun 22 2016 at 19:51):
Yes. Now technically we don't need to use FHIR to represent these resources in our SMART app, because it's not actually a part of the integration with the EHR anymore
Josh Mandel (Jun 22 2016 at 19:51):
Then doctors interact, and the app can display advice like "this patient doesn't have iron deficiency anemia. Consider eliminating the diagnosis."
Andrew Ross (Jun 22 2016 at 19:51):
Right
Andrew Ross (Jun 22 2016 at 19:52):
But we're interspersing inferences with other data we're getting directly from FHIR, and generally feel that it's best practice to represent patient data (actual measurements/diagnoses + programmatic inferences) in a common format
Andrew Ross (Jun 22 2016 at 19:53):
But it still feels important to distinguish the two
Andrew Ross (Jun 22 2016 at 19:53):
Ideally in a way that points back to us and makes it clear that a CDS service made those inferences, not a doctor
Andrew Ross (Jun 22 2016 at 19:54):
i think Observation supports all of that
Andrew Ross (Jun 22 2016 at 19:54):
but it's not a natural fit for patient facts that are more like diagnoses
Josh Mandel (Jun 22 2016 at 19:54):
But you're writing these inferred resources for your own app to consume?
Andrew Ross (Jun 22 2016 at 19:54):
Yes
Josh Mandel (Jun 22 2016 at 19:54):
Might just slap a tag on 'em
Andrew Ross (Jun 22 2016 at 19:54):
Right :) that definitely works
Andrew Ross (Jun 22 2016 at 19:55):
Basically I'm just wondering if this is a common use-case in other applications as well
Andrew Ross (Jun 22 2016 at 19:55):
and if so, how others do it
Andrew Ross (Jun 22 2016 at 19:55):
and/or validating that what we're doing isn't totally ad-hoc
Josh Mandel (Jun 22 2016 at 19:56):
Gotcha. I haven't heard of others applying a pattern to this problem, but let's see what we hear from the crowd!
Eric Haas (Jun 22 2016 at 20:14):
This use case sounds more like an Assessment ( the A in SOAP) why not use ClinicalImpression to convey the "anemia not due to iron deficiency" ? I am asking out of ignorance since perhaps CDS doesn't align with this at all.
Bryn Rhodes (Jun 22 2016 at 21:52):
I've seen this done with production rules that just produce a fact in the working memory of the rules engine. To expose those types of inferences through the CDS guidance operation, we would use a GuidanceResponse that proposed the creation of the Observation resource.
Bryn Rhodes (Jun 22 2016 at 21:53):
As far as distinguishing between a real vs an inferred observation, or other type of resource, that's a good use case, and we've talked about it in the context of CDS before, but don't have anything concrete to recommend at this point.
Bryn Rhodes (Jun 22 2016 at 21:54):
It seems like a good case for an extension though, that could be applied to any resource, and you could use it to say, "this resource was inferred by a device".
Bryn Rhodes (Jun 22 2016 at 21:54):
It's sort of like Provenance, except you want to know it directly on the resource.
Eric Haas (Jun 23 2016 at 14:25):
@Bryn Rhodes extension on what? Observation?
Bryn Rhodes (Jun 23 2016 at 14:38):
A generic extension that could be applied to any resource.
Eric Haas (Jun 23 2016 at 17:23):
@Bryn Rhodes Why not use Observation.device? for example I would think that would cover this use case instead of an extension. Device = CDS system
Bryn Rhodes (Jun 23 2016 at 18:36):
For Observation, you're right, I was thinking of something that could be handled the same way regardless of the resource type, so it would work for Condition as well.
Last updated: Apr 12 2022 at 19:14 UTC
