Stream: argonaut
Topic: Argo R4/US Core Connectathon Track
Eric Haas (Jul 30 2019 at 17:26):
Argo R4/US Core Connectathon Track Orientation Webinar
There will be a track orientation webinar on Wed August 14th at 3-4 PM Eastern to provide an overview of the Connectathon Process and specifics on the Scenarios and Goals for this track.
Eric Haas (Jul 30 2019 at 17:26):
Webinar call coordinates:
GoToMeeting: https://global.gotomeeting.com/join/977233229
Audio: 1 866 899 4679
Access Code: 977-233-229
Karen Fairchild (Aug 22 2019 at 18:51):
We are a FHIR “requestor” and need to be able to pull patient data into a research databases. We have a back end server application that calls FHIR APIs and de-identifies patients for research. We are adding in OAuth2 Client Credentials and can use either Bulk Data APIs or the “traditional” APIs but from a back-end application (not a web app).
We are wondering if anyone attending this Argo/R4 US Core track at the Connectathon would be able to provide us the ability to try out some R4 code to access R4 FHIR servers to extract data on multiple patients at a time (using search parameters) and some clinical data (also using search parameters).
Grahame Grieve (Aug 22 2019 at 19:38):
sounds like the bulk data track to me
Eric Haas (Aug 22 2019 at 21:00):
We discussed on yesterday's call. there are user facing apps that may want to query across patients. They don't have system level scope. Right now the feedback was that they would need to query patients one by one. We will be adding some future based guidance on this including recognizing the bulk data approach.
Grahame Grieve (Aug 22 2019 at 21:01):
wouldn't provider level access do it?
Eric Haas (Aug 22 2019 at 21:04):
yes that is what we are talking about but is not been implemented that way by the servers. there is valid concern about non-performant query if provider asks for all patients observations for example.
Grahame Grieve (Aug 22 2019 at 21:04):
can you explain exactly what has not been implemented by the servers?
Eric Haas (Aug 22 2019 at 23:03):
if you have users scopes for 3 patients and you want to search for allergies for all three patients you can not do a :
Get [base]/AllergyIntolerance
nor
Get [base]/AllergyIntolerance?patient=123,345,456
but only this:
Get [base]/AllergyIntolerance?patient=123 Get [base]/AllergyIntolerance?patient=345 Get [base]/AllergyIntolerance?patient=456
Grahame Grieve (Aug 23 2019 at 00:18):
I don't understand this for several reasons. What does it mean to "have users scopes for 3 patients"? 3 different scopes, or 1 scope? But I asked about provider scope
Josh Mandel (Aug 23 2019 at 00:25):
I think the scenario is an app with scopes like user/AllergyIntollerance.read, where the user is a provider.
Grahame Grieve (Aug 23 2019 at 00:26):
yes that is what I am asking about
Josh Mandel (Aug 23 2019 at 00:26):
And with these scopes, several EHRs (Cerner and Epic at least, if I understood correctly) will permit queries that provider a singles patient id, but do not support the comma separates query (or the query where patient is omitted).
Grahame Grieve (Aug 23 2019 at 00:28):
ok thx
John Moehrke (Aug 23 2019 at 14:09):
I think this is a good implementation. Make the client be specific about what it wants. It is not uncommon for API to be restricted to only one Patient, vs other API that are focused on bulk. This very much makes Privacy and Security more achievable. I do understand the theoretical-desire for the alternative, but it is not compelling relative to the problems it brings.
Josh Mandel (Aug 23 2019 at 20:46):
Agreed, re: issuing 1 API call vs 3. Issuing 3 calls is no big deal, especially since you can do them in parallel. The much more important API issue, I think, is why you don't know which patients you're asking about (e.g. "tell me all out-of-range lab results over the last 30 min").
Karen Fairchild (Aug 23 2019 at 21:05):
Or, you are trying to get information about a group of patients that have a set of diagnoses you are studying for research. We have a research database and when he don't have bulk data APIs available, but have the basic ones, this would be very useful. The group of patients would not necessarily be for a single provider either. We would be going in as a back-end service.
Josh Mandel (Aug 23 2019 at 21:45):
Of course the standard FHIR REST API defines all this, and most "generic FHIR servers" (like you'd probably use for a research database) support it just fine.
Josh Mandel (Aug 23 2019 at 21:45):
The challenge has been in operational clinical systems, is "give me the most recent observations sorted by date, across patients" something they can/will support in production environments. That's where the US Core / Argonaut guidance comes into play.
Jenni Syed (Aug 26 2019 at 14:10):
I think it absolutely makes sense to support research, population, and realtime physician care use cases. I don't think anyone in the thread disagrees with that (correct?)
Jenni Syed (Aug 26 2019 at 14:11):
However, the performance needs, use cases, etc differ vastly between those use cases. I think it also may make sense to handle those separately - eg: many systems have population management as a separate platform
Josh Mandel (Aug 26 2019 at 14:16):
But generally these population health systems are not up to the minute for operational data like lab results. So organizations that want to get access to the most recent labs wind up using proprietary vendor-specific APIs or direct database calls.
John Moehrke (Aug 26 2019 at 14:16):
I think it absolutely makes sense to support research, population, and realtime physician care use cases. I don't think anyone in the thread disagrees with that (correct?)
I am willing to somewhat agree on research and population... but not fully because I dont think that the ramifications are completely understood. Privacy and Security can't be something we ignore until it is too late... You also brought in "realtime physician care" as an exception which is confusing.
Jenni Syed (Aug 26 2019 at 14:22):
I don't think any of them are exceptions. They're all primary use cases needed in different scenarios
Jenni Syed (Aug 26 2019 at 14:23):
"realtime physician/practitioner" is what I would categorize most of your daily care or what people use to think of as the traditional EHR
Jenni Syed (Aug 26 2019 at 14:24):
@Josh Mandel if it's most recent for a specific patient, they should be able to get that today via API calls - though they may need to do parallel calls as you mentioned
Jenni Syed (Aug 26 2019 at 14:24):
It's when they don't know the population, are trying to identify the population, or are looking for different research data that I think it starts to go closer to bulk access
Josh Mandel (Aug 26 2019 at 14:46):
Jenni Syed: @Josh Mandel if it's most recent for a specific patient, they should be able to get that today via API calls - though they may need to do parallel calls as you mentioned
Agreed; it's for things like "the patients in my ED right now," or "all patients with recent lab results" where current FHIR implementations don't work.
Last updated: Apr 12 2022 at 19:14 UTC
