Stream: argonaut
Topic: Record discovery
John Grimes (Apr 29 2018 at 22:16):
Maybe a silly question... I am new to the Argonaut architecture.
How does one know where to go to get a patient's records, in the case of an app which is not launched from within an EHR (i.e. with context)?
Would you need to prompt the user to nominate the endpoints which their information lies within? Or is there some sort of central directory that points the way towards records for a patient identifier?
Grahame Grieve (Apr 29 2018 at 22:17):
the application must know the server to which it wants to connect, and the application must be registered with it.
Grahame Grieve (Apr 29 2018 at 22:17):
there's no support - at the moment - for auto-registration of an client application
Grahame Grieve (Apr 29 2018 at 22:18):
so the application would 'know' somehow - managed by whoever registers it - what servers it could connect to
Grahame Grieve (Apr 29 2018 at 22:19):
if argonaut defines a way to register applications on the fly - there are such specifications, and we've talked about it - then you'd either need to let the user enter a url on the fly, or there would have to be a central directory. Obviously the second would be much more convenient for a typical user, but it requires someone to curate it
John Grimes (Apr 29 2018 at 22:20):
Ok, thanks.
Are there currently any apps which currently exist outside of "EHR context"? That aggregate data across endpoints?
Grahame Grieve (Apr 29 2018 at 22:21):
apple healthkit? and others in US, though I don't have a list. someone else here might have a list
John Moehrke (Apr 30 2018 at 14:33):
There are two different things being discussed here. First is the fact that an application will not be given any access to data within a custodian without that app being approved to a level of trust at that custodian. This is the app registration factor Grahame brings up. It is a problem of trust, not a problem of discovery. Custodian organizations need to be able to have some reason to release any information, however small, to that app. In the absence of trust, I hope and expect every custodian will DENY access regardless of how persuasive the plea is.
John Moehrke (Apr 30 2018 at 14:34):
An app trustability would be a different vector from the specific patient data or the specific user rights.
John Moehrke (Apr 30 2018 at 14:37):
There are two different models for discovery today: First is the Patient initiated, like Apple Healthkit. Precondition is that the app is a trusted app. The Patient has a relationship with various healthcare organizations. Thus in this case the user is the Patient, and they have access to their own data alone. The Patient introduces that healthcare organization to their app, this enables the app to grab data that the patient has authorized, and that the custodian will release.
John Moehrke (Apr 30 2018 at 14:40):
The second is where the User is not the patient, but has some level of authorization. Typically a clinician, but could be a guardian, researcher, etc. In these cases broader queries can be done, again restricted to the rights of that user and authorizations given to the app. Remote clinician use-cases, similar to how nationwide or regional health exchanges (e.g. XDS/XCA) operate, could be enabled such that the user/app starts with a Patient query to find matching patient identities to the patient identity they know. Once a match is determined, then queries into that patient data would continue as expected...
John Moehrke (Apr 30 2018 at 14:41):
right?
Grahame Grieve (Apr 30 2018 at 20:06):
well, regulation in USA is that the institution trusts the patient, and has to trust their selection of an app - which is where auto-registration comes into play. There's no reason to think that apps will be able to register themselves for non-patient access
John Moehrke (Apr 30 2018 at 20:28):
I agree that would be useful flow... My point is that the trust of the app is a different factor from the authorization the user has. Both must align, but they are different vectors.
Michele Mottini (May 08 2018 at 21:51):
@John Grimes : we have a patient app that aggregate content across end points - search for myFHR in the Apple store or https://myfhr.careevolution.com for the Web version
Michele Mottini (May 08 2018 at 21:54):
..and record discovery is a big issue: we present a list of providers we know about and can connect to and the patient chose one (or more), but there is no way to discover all the available providers end point beside the ones from Epic - that are published at https://open.epic.com/MyApps/Endpoints
John Grimes (May 09 2018 at 06:09):
Ok, thanks @Michele Mottini
So if someone went to search for a provider that uses Cerner, they wouldn't find it in your list?
John Moehrke (May 09 2018 at 12:40):
The lack of a intergalactic provider directory is an operational issue, right? That is to say that the model for provider directory can support it. The problem that needs to be solved is motivation to build and run such a directory, motivation to participate in such a directory, and policy around who can be published and who can query. The motivation can be compelled by regulation. The policy is very important, else this become a fantastic tool for malicious intent.
Michele Mottini (May 09 2018 at 13:00):
@John Grimes : correct, to add providers using Cerner we have to contact them directly and have then white-list our app - and we do not even have a way to find out _which_ providers are out there with a live Cerner end point
Michele Mottini (May 09 2018 at 13:06):
@John Moehrke I don't know about intergalactic, US-wide would be enough....but if all EHR vendors simply did what Epic does the problem would be mostly solved
John Moehrke (May 09 2018 at 14:50):
An example of where this decision has been made is Sequoia. The directory is more focused on the patrner organizations within CareQuality and eHEX. It is using FHIR as the API to the Directory. They have participated in the FHIR Connectathon tracks on Provider Directory. See https://sequoiaproject.org/carequality/active-sites-search/
Julie Maas (May 16 2019 at 18:52):
A related item is endpoint security and assurances--e.g. being sure I am at the right FHIR endpoint for healthcare organization ABC, entering credentials at the right OAuth server. Is anyone working on a way to address this? Aware of the good work around provenance and that addresses this question in part.
Last updated: Apr 12 2022 at 19:14 UTC
