Stream: argonaut
Topic: Concerns around lack of support for List
Lloyd McKenzie (Jul 01 2019 at 04:58):
At the last WGM (or maybe it was DevDays? - all meetings sort of run together...), I chatted briefly with @Jenni Syed about my concerns around the lack of support for List in Argonaut, and more specifically about the presumption that APIs would only expose 'current' information. She suggested I write my thoughts down for discussion. I finally have. They can be found here: https://docs.google.com/document/d/1ya4FBfwcxYuRdAOblCgTxTBsGmINK60qQOuP1dUMXtg
Thoughts/opinions welcome.
Jenni Syed (Jul 01 2019 at 13:26):
Looks like access may be locked down and we need to request
Lloyd McKenzie (Jul 01 2019 at 14:12):
Fixed
Brett Marquard (Jul 01 2019 at 18:15):
I find it interesting you picked the Argonaut list to post this -- why isn't this in the implementer stream? how is the international community handling lists?
Brett Marquard (Jul 01 2019 at 18:16):
on the use of lists -- I feel like this is an 'invented standards approach' without clear implementer input. We would all benefit from starting with a clear problem statement
Josh Mandel (Jul 01 2019 at 19:58):
From my perspective, it's not at all clear that we'll want a single FHIR endpoint from a system of record to also expose (arbitrary, complete, unvetted) FHIR data from other systems directly alongside the source of truth. It seems just as likely to me that such systems will provide multiple FHIR endpoints to manage this complexity -- separating the stuff they vouch for from the archive of stuff that's just "here it is, as we received it."
Josh Mandel (Jul 01 2019 at 20:01):
From the pure standards/interop perspective, in theory there's a cheap thing Argonaut could to do avoid getting stuck in a possible future where EHRs do want to manage this complexity: just define (but don't actually use) a tag like external-data meaning "This data is not part of the system of record" and the Argonaut guide could say "clients should filter out any data with the external-data tag if present". In theory that would allow us to maintain a compatible API even in a possible future where multiple perspectives are all layered together alongside the system of record. But in practice it'd probably just confuse people. Kind of like wrapping everything in a List (but at least it wouldn't directly change how people used the API today).
Lloyd McKenzie (Jul 01 2019 at 21:04):
It's not just a question of external data. It's any "non-current" data. EHRs are respositories that contain all sorts of stuff - and there are use-cases for exposing all of that stuff via FHIR API. The challenge is the presumption that the API will only expose 'relevant' information as opposed to exposing wheat + chaff, with the expectation for the client to filter based on their particular definition of "chaff".
Lloyd McKenzie (Jul 01 2019 at 21:06):
List is a mechanism for a system (or particular users) to curate and identify what they currently consider to be "wheat" - where each List has a context that defines the intended purpose of the information within it. We could potentially come up with a different way.
Lloyd McKenzie (Jul 01 2019 at 21:08):
My base problem statement is that every Condition, AllergyIntolerance, MedicationStatement, etc. that an EHR has in its database needs to be retrievable from a single FHIR endpoint. At the same time, there needs to be a mechanism to filter such that a client who only wants to see the authoritative problem list, allergy list, medication list, etc. can get those. (I personally believe that the notion of a single 'problem list' is itself problematic, as we've spent lots of time in PatientCare talking about the notion that what's a problem for one clinician - and is on "their" list isn't necessarily relevant to others and those won't be on someone else's list)
Lloyd McKenzie (Jul 01 2019 at 21:09):
The issue isn't necessarily U.S.-specific, but Argonaut is where the trends seem to be set and where most of the major EHRs are doing their preliminary work. And it's where the initial decision to forego List was made. So it seemed the most appropriate place to start the discussion.
Jenni Syed (Jul 01 2019 at 21:15):
To be clear: it was made to bypass list because we don't attempt to formally define what "current" is to each consumer. We allow them to get the list based on their own requirements. Some consumers need the in errors to sync systems up
Jenni Syed (Jul 01 2019 at 21:16):
I believe if we went the way of the point in time or something other than "current" of X, Y, Z status, then it would be List
Jenni Syed (Jul 01 2019 at 21:16):
Though I hate List :) From a modeling side, it's just a way to wrap things up, but I never expose just "List" APIs... I expose a resource that may have a list of things :)
Jenni Syed (Jul 01 2019 at 21:17):
IE: In Java, it's not List.getMyFunObjects(param 1, param2). Its MyFunObjects.getSomeList()
Jenni Syed (Jul 01 2019 at 21:17):
but that is a separate thing :)
Jenni Syed (Jul 01 2019 at 21:23):
I will also clarify that Allergies, med history, and conditions have always been read/write in Cerner's FHIR implementation. As of today, what is written is part of the legal record, and is returned via the same APIs
Jenni Syed (Jul 01 2019 at 21:24):
We are getting ready to start exposing some of what you're referring to (the "pending" not "legal" record) and have been talking a bit about how to do this, both within HL7 and this chat, as well as in some of the patient empowerment channels
Jenni Syed (Jul 01 2019 at 21:25):
So far, consensus seems to be that much of this data is likely the security tag on the resource, which Josh is referring to above.
Jenni Syed (Jul 01 2019 at 21:26):
There is still a lot of discussion I feel needs to be had within FHIR about how this process should work from a standards method, eg: patient provided data
Jenni Syed (Jul 01 2019 at 21:26):
but as Lloyd alludes to, it's not just patients that provide this data.
Jenni Syed (Jul 01 2019 at 21:29):
However, I think perhaps the main point here is: right now, we do NOT take a stance to define every system's interaction as the "source of truth" for what statuses should be considered current, nor what an app may care about. IE: it's not a fully curated list in that the app calling has the control over understanding their workflow and what their user (or system) needs to know.
Jenni Syed (Jul 01 2019 at 21:40):
Which means that the argonaut use case as it's defined now doesn't seem to match with the List concept (others hopefully will weigh in, but this is why we call out that status parameters are required to be supported)
Lloyd McKenzie (Jul 02 2019 at 01:10):
We could absolutely define a generic "getSomeList" operation that could be run against arbitrary resources so you could say something like MedicationRequest/$inlist?code=activemeds or $AllergyIntolerance/$inlist?code=activeallergies or something like that if that were deemed useful.
Lloyd McKenzie (Jul 02 2019 at 01:11):
Using security seems an odd way to filter. meta.security is supposed to be about access control constraints, not information about where data came from. That said, meta.tag could be a candidate.
Lloyd McKenzie (Jul 02 2019 at 01:18):
It's true that patient-written data can be part of the current authoritative record. The bigger challenge is the data that comes in as part of other things. A patient-submitted allergy or med-statement would presumably be submitted in the context of what you've already got in the record, so adding another isn't a problem. However, if you receive a discharge summary, referral or similar collection that includes some stuff you've got in the current record but perhaps expressed differently (as well as some new things), there's a problem. From a medical record perspective, you need retain what was sent to you (as sent). And you probably want the 'new' stuff. But you don't want the other items to appear in the official list of allergies or meds.
John Moehrke (Jul 02 2019 at 13:18):
The meta.security might be a solution for some, but it can't cover the clinical assessment of 'relevant'... We do have tags for the integrity of the data (patient asserted, vs clinician asserted, etc)... and we now have CopyMark to be used to tag data that you are not the official repository of (like the paper world big rubber-ink stamp "COPY"). I think this CopyMark is what Josh was referring to as external-data. I don't think that this mark should be an indicator of being excluded from being locally 'relevant'.
Josh Mandel (Jul 02 2019 at 13:34):
"relevant" is going to be slippery and contextual. We can't solve problems that we can't state clesrly. (For what it's worth I was referring to Meta.tag rather than something security specific.)
John Moehrke (Jul 02 2019 at 14:48):
"relevant" is going to be slippery and contextual. We can't solve problems that we can't state clesrly. (For what it's worth I was referring to Meta.tag rather than something security specific.)
understood... I am just pointing out that we do have a security tag for CopyMark...
John Moehrke (Jul 02 2019 at 14:49):
isn't the topic of List all about "relevant"?
John Moehrke (Jul 02 2019 at 14:49):
as in this part of FHIR spec? http://build.fhir.org/list.html#query
Lloyd McKenzie (Jul 02 2019 at 14:53):
List is about identifying arbitrary subsets of a collection that are of interest for a particular purpose. The alternative is to embed information in the resources that can be used to perform the same sort of filtering. In either case, the challenge is that clients are being trained to not do any filtering at all...
Jenni Syed (Jul 02 2019 at 15:00):
@Lloyd McKenzie where are they being trained to not use any filtering?
Jenni Syed (Jul 02 2019 at 15:00):
in our server that meets the argonaut profile, if they pass nothing, they get everything. If they want just "current" they pass the statuses they need.
Jenni Syed (Jul 02 2019 at 15:01):
I know there were other conversations on making the language more clear/requiring status (which has drafts in progress), but that should be a completely different issue
Jenni Syed (Jul 02 2019 at 15:01):
The argonaut use case wasn't intended to be a manicured/maintained "current" defined by the server
Lloyd McKenzie (Jul 02 2019 at 15:11):
The trick is that they don't get "everything" - they don't get 15 versions of the same allergy or 50 versions of the same Condition (that reflect all of the different representations of the resources that have come in as part of referrals, discharge summaries, etc.)
Jenni Syed (Jul 02 2019 at 15:11):
At least, not as I understood it :)
Lloyd McKenzie (Jul 02 2019 at 15:12):
When the time comes where that data also gets exposed over the AllergyIntolerance, Condition and other endpoints, clients will be in for a rude surprise.
Jenni Syed (Jul 02 2019 at 15:15):
We are getting ready to expose that in our system, but not in the way it seems to be expected here. If there are "50 of the same" they are not duplicated (the provenance will track if the source is several systems)
Jenni Syed (Jul 02 2019 at 15:16):
There is a lot to it, but we are trying to take a large burden on our server where we can to make this simple for clients
Jenni Syed (Jul 02 2019 at 15:17):
So that it is harder to mess up, at least that is the goal
Jenni Syed (Jul 02 2019 at 15:23):
This is also what we try to do for internal apps, so that doctors don't see 50 of the same allergy
Lloyd McKenzie (Jul 02 2019 at 15:23):
"the same" doesn't necessarily mean identical. Each would have different provenance and might assert slightly different things - different granularity, different code, different description, different severity, different dates, etc. However, from a clinical perspective, they'd all be talking about the "same" issue
Lloyd McKenzie (Jul 02 2019 at 15:24):
How do you deal with reflecting accurately what data was actually received (where the variances would presumably matter) vs. reflecting a single consolidated view that is 'current' in the allergy or problem list?
Jenni Syed (Jul 02 2019 at 15:33):
It depends on the data domain
Jenni Syed (Jul 02 2019 at 15:33):
In our system, there has always been some level of dup checking
Jenni Syed (Jul 02 2019 at 15:34):
EG: you can't enter a problem more than once, the underlying apis determine that a "create" may actually be a modify of an existing problem (and track versions)
Jenni Syed (Jul 02 2019 at 15:34):
For things that aren't part of the legal record, or that may come in from other systems, it's more complex
Jenni Syed (Jul 02 2019 at 15:35):
The system does what it can to recommend and make the view for the clinician readable/understandable. There are automated ways something can become part of the legal record (and history is tracked to multiple CCDs as sources, for eg)
Jenni Syed (Jul 02 2019 at 15:36):
As well as manual ways. As a piece of data moves through that workflow, privs/security/etc comes into play on who can see that data
Jenni Syed (Jul 02 2019 at 15:37):
Once a clinician has reconciled data, and it is part of the legal record, history and provenance is updated to point to the source (or, if the clinician rejects it as unreliable, it is often deleted and that is audited for records)
Jenni Syed (Jul 02 2019 at 15:38):
But importantly: If there are 10 CCDs as source of 1 Condition, the Condition resource will NOT expose all 10 versions of that Condition. The provenance may point back to 10 CCDs if an app for some reason wanted that
Jenni Syed (Jul 02 2019 at 15:38):
But the FHIR call reflects the actual discrete data that was extracted or combined from those
Jenni Syed (Jul 02 2019 at 15:39):
Since that was determined to be the accurate representation of the Condition (allergy, etc)
Jenni Syed (Jul 02 2019 at 15:41):
Many feeds from external systems that are technically "part" of that system are sent straight to the legal record.
Jenni Syed (Jul 02 2019 at 15:41):
which all get exposed through Condition today
Jenni Syed (Jul 02 2019 at 15:44):
This is also what our underlying apps (and DB) see, so FHIR is reflecting the underlying system
John Moehrke (Jul 02 2019 at 15:45):
warms my heart to see excitement about Provenance as a tool in Reconcilliation... Your description seems to work well for when the source was not FHIR (CCD or even a v2 message). But what would your Provenance.entity point at if the source was originally sent to you in FHIR form?
Jenni Syed (Jul 02 2019 at 15:46):
If it is sent in as a raw condition, which happens today, it depends on the source
Jenni Syed (Jul 02 2019 at 15:47):
Today, the apps that integrate via FHIR are all trusted, clinicians are interacting directly (or B2B systems that are technically part of the same system are interacting), so hit immediately hits the legal record and is immediately accessible via FHIR
Lloyd McKenzie (Jul 02 2019 at 15:47):
What happens when the CCDs or Referrals come in as a FHIR Bundle? Will that data be queriable over the interface?
Jenni Syed (Jul 02 2019 at 15:48):
In the future, more trust structures are in place. If it is fed in from an untrusted source, it will be added as Unreliable initially (with provenance for source, which still could point to a CCD fed in through FHIR if that is the workflow, but could also just say "the patient created this" in provenance)
Jenni Syed (Jul 02 2019 at 15:48):
It will be available to the apps and/or users that have privs to see unreliable/non-legal record data
Jenni Syed (Jul 02 2019 at 15:49):
If it is determined to be unreliable and should not be part of the legal record, it is deleted (audited and provenance updated)
Jenni Syed (Jul 02 2019 at 15:50):
If it is accepted, it depends on what the clinician decided to do. Provenance and auditing will still be there no matter what. If they accept it, the unreliable tag is dropped, provenance is updated and it is now visible to anyone that can see the legal record
Jenni Syed (Jul 02 2019 at 15:51):
For "pending modifies" ... this is more fun, and is a thread that I think may have started on patient engagement :)
Lloyd McKenzie (Jul 02 2019 at 15:53):
Ok. And are your current interfaces exposing "unreliable/non-legal record" data? If so, how are you filtering? If not, how are you ensuring that clients are trained to do that filtering anyhow?
Lloyd McKenzie (Jul 02 2019 at 15:53):
(And interested in what other EHR vendors are doing too :>)
Jenni Syed (Jul 02 2019 at 15:54):
DSTU 2 does not do that today, but R4 will
Jenni Syed (Jul 02 2019 at 15:54):
Also the "non-legal record" didn't really fully exist until R4 :)
Jenni Syed (Jul 02 2019 at 15:54):
outside of you being able to read the CCD under the covers
Jenni Syed (Jul 02 2019 at 15:55):
IE: the system did not unpack the CCD (and none of this came in through FHIR) automatically.
Jenni Syed (Jul 02 2019 at 15:56):
and what did come in via FHIR was immediately part of the legal record and is exposed in current resources
Jenni Syed (Jul 02 2019 at 15:56):
Also the Argonaut work on provenance is helping to make sure we represent this correctly, which is another reason we're waiting until R4
Jenni Syed (Jul 02 2019 at 15:58):
I would say it was much tougher/less understood/less guidance on DSTU 2 itself how to handle some of this well, ignoring underlying system capabilities
Jenni Syed (Jul 02 2019 at 16:01):
To the filtering question: only certain apps and users will have privs to see unreliable data. That is enforced in the FHIR server
Jenni Syed (Jul 02 2019 at 16:01):
For those that can, we were going to expose an additional parameter that allows them to filter out unreliable data if they want
Jenni Syed (Jul 02 2019 at 16:02):
This is in addition to the normal status field
Michele Mottini (Jul 02 2019 at 16:05):
(And interested in what other EHR vendors are doing too :>)
Our system is not exactly an EHR - we typically aggregate data from other sources - with very little / no deduping, so that's all you get via FHIR - there is no curated or authoritative list of anything. We are adding Provenance so you can see where the data originally came from.
John Moehrke (Jul 02 2019 at 16:08):
For those that can, we were going to expose an additional parameter that allows them to filter out unreliable data if they want
so &_security:not=UNRELIABLE
Jenni Syed (Jul 02 2019 at 16:17):
yup :)
Brian Postlethwaite (Jul 02 2019 at 23:21):
I'd have expected that as a meta.Tag rather than meta.Security value.
Grahame Grieve (Jul 05 2019 at 22:37):
we already have the list functionality Lloyd proposed above ;-)
Grahame Grieve (Jul 05 2019 at 22:41):
I've followed this discussion but I'm not sure where it's landed. An EHR will have lots of conditions:
- the patient's curated problem list
- past conditions linked as causes/sources e.g. presenting diagnoses for past encounters - these are active but not part of the problem list, or reasons for prescriptions. They may turn out to be erroneous reasons, but they are the reasons the prescription was given
- conditions received as part of archiving information from other systems, including the patient, tagged with provenance.
The cause of the concern is that the Argonaut spec says it describes the use of "the Condition resource to record, search and fetch a list of problems and health concerns associated with a patient" - which is a subset of the valid reasons to access a condition
Grahame Grieve (Jul 05 2019 at 22:44):
consider this:
Grahame Grieve (Jul 05 2019 at 22:45):
Example:
GET https://fhir-open-api-dstu2.smarthealthit.org/Condition?patient=1032702&clinicalstatus=active,relapse,remissionSupport: Optional to support search by status.
Implementation Notes: Search for all active problems and health concerns for a patient
Grahame Grieve (Jul 05 2019 at 22:47):
what's the definition of active? - I'm fairly sure that clients will assume it means 'actively a problem now'. But a condition quoted as evidence for a prescription would be active at the time....
Last updated: Apr 12 2022 at 19:14 UTC
