Stream: patient empowerment
Topic: Patient Software API
Grahame Grieve (Apr 01 2019 at 05:30):
So we're starting to have standards communities proposing to create "patient focused APIs"
Grahame Grieve (Apr 01 2019 at 05:31):
That is, an APi that is expected to implemented by patient apps running in hand-held devices owned by the patient.
Grahame Grieve (Apr 01 2019 at 05:33):
There's a set of different functionalities this might entail:
- accessing patient summary data (e.g. USCDI by Us-core - argonaut)
- Gathering patient reported outcomes measures
- collecting wearable sourced data
- letting patient's make appointments + request / order services or supplies
- extending care into the home
- medications management at home
Grahame Grieve (Apr 01 2019 at 05:36):
By default, we're going to start having a lot of different IGs that make rules about this software (published by multiple different organizations). Should we trying and coalesce them so we only have one (or a few)?
René Spronk (Apr 01 2019 at 06:37):
@Alexander Henket @Ardon Toonstra MedMij ?
Grahame Grieve (Apr 01 2019 at 06:47):
is one of a number of related specs
Dave deBronkart (Apr 01 2019 at 09:05):
@Grahame Grieve who is the "we" starting to have these discussions?
Grahame Grieve (Apr 01 2019 at 09:09):
HL7 committees mainly, though I expect that overlapping discussions are also happening in IHE (@John Moehrke ) Carequality (@Didi Davis ) CarinHealth (@Ryan Howells ). and I know that some affiliaites are having them (a la MedMij in Netherlands as above) and Argonaut in Australia and nordic countries. Also, SPM and QS would be interested though I'm sure not discussing stuff yet
Dave deBronkart (Apr 01 2019 at 09:25):
SPM seriously needs to spin up a health IT team!
Grahame Grieve (Apr 01 2019 at 09:28):
I think so. That could be our patient representatives... but what would it look like?
Alexander Henket (Apr 01 2019 at 09:38):
Is this something that would be a weekly call basis? Do 'we' issue an IG? Do we require USCDI/MedMij and what not to conform to this IG? Are 'we' if only a little in IHEs backyard with this. Tradtionally IHE does not really include patients, but the notion of producing an IG for a world wide felt 'problem' sure feels like IHE territory
Grahame Grieve (Apr 01 2019 at 09:41):
all very good questions. I don't know the answer to any of them.
Grahame Grieve (Apr 01 2019 at 09:41):
obviously it's easier if we just all go ahead and produce chaos. Not producing chaos will take work - how much and is it worth it?
Grahame Grieve (Apr 01 2019 at 09:42):
I don't think it has to be IHE that produces a world wide implementation guide. It's well positioned in some ways to do it, and I wouldn't object - but it would require different thinking on the part of IHE
Grahame Grieve (Apr 01 2019 at 09:42):
for both jurisdictional and patient perspective reasons
Dave deBronkart (Apr 01 2019 at 10:58):
Dave deBronkart (Apr 01 2019 at 10:58):
Not being familiar with IHE, I googled it, and how amusing.
Dave deBronkart (Apr 01 2019 at 11:02):
Re SPM and a health IT team - SPM have always suffered from a void of middle management with rare exceptions. Let's not count on that unless we can come up with such a leader - someone who knows technically what needs to be done.
Focusing on care coordination, for kids and or elders, may strike paydirt.
Can someone spit out 2-5 sentences on what we hope to do, as what work is needed?
Grahame Grieve (Apr 01 2019 at 11:59):
for which? care coordination, or standards coordination?
Ryan Howells (Apr 01 2019 at 12:28):
Yes, CARIN is developing IGs for patient focused IGs along with other groups. Accessing patient summary data is the responsibility of Argonaut. They will be developing an R4 version of their IG which will include all of USCDI v1 as described in the ONC proposed rule. They are also developing an appointment IG. CARIN is developing IGs so patients can access all of their claims information from health plans so plans can be compliant with the CMS proposed rule. We are also developing a consumer-facing real time pharmacy benefit check capability for consumers to see their OOP pharmacy costs, and we are working with CMS on making the post-acute care assessment information available to consumers. We would welcome others thoughts in making more data available to patients.
Dave deBronkart (Apr 01 2019 at 12:37):
Hi Ryan! Hadn't seen you here in my limited rummaging.
Grahame, has anyone identified what-all needs to be included in care coordination? I imagine it would be limitless, but has anyone identified some worthy subsets?
Dave deBronkart (Apr 01 2019 at 12:44):
@Grahame Grieve my 2-5 sentences question was about the possible SPM topic, likely care coordination
Grahame Grieve (Apr 01 2019 at 12:57):
... will get back to this tomorrow....
John Moehrke (Apr 01 2019 at 14:09):
Good initiative, and I agree that the outcome is unclear. IHE (www.ihe.net) has some IG that are intended to have the patient engaged with them, but there is not logical place in IHE for a focus on the patient. This is not for lack of trying, but patients are hard to herd, they are worse than cats.
John Moehrke (Apr 01 2019 at 14:11):
I suspect that at best we can have a community of interest, made up of people that are participating in one or more of these initiatives. In this way we can share what is happening, and call upon our peers at specific points. As a community of interest it should be very approachable, far more approachable than any of those you mentioned.
John Moehrke (Apr 01 2019 at 14:12):
seems fhir foundation might be a good coordinator of this community?
Alexander Henket (Apr 02 2019 at 20:50):
@Grahame Grieve you may recall your talk with our Ministry of Health folks. I dropped this initiative with them and we agreed that being able to talk about this type of topic might just be the type of platform we need for scaling up - in my mind within HL7 not the FHIR Foundation but hadn't put too much thought into that part yet - John says that IHE may not be a natural fit for this; I'm still convinced we'd need IHE input. Patient focused APIs should, I think, be as much as possible be the same as provider APIs.
Sure enough there's stuff to flesh out, the questions I raised earlier for example, but probably more. Example: we have not yet decided whether or not we go to R4, so from where I currently stand I'm more interested in talking interaction patterns that work across FHIR versions than solutions that tie into "the latest version only". This may shift as internal R4 talks progress.
I hope this can be the start of a new level of interaction between similar initiatives that currently live in different project realms.
Mikael Rinnetmäki (Apr 03 2019 at 04:40):
As an implementer of patient-centric (or even citizen-centric) self-care apps, we (Sensotrend) have found the HL7 FHIR specification to include everything we need API-wise. We're doing everything on @Grahame Grieve's list, except USCDI access. I don't see the need to create new APIs. There probably is a need for Implementation Guides, though.
Lloyd McKenzie (Apr 03 2019 at 05:25):
It's not so much a question of creating new APIs as it is of standardizing/profiling them so that there's consistent data exposed to and access by patient-facing apps.
John Moehrke (Apr 03 2019 at 14:24):
I do agree that dominant work is just grouping existing profiles in a way that presents them around patient centric use-cases. Often the IG are very Provider, EHR, or Payer centric. This is simply a perspective shift, not a technical change.
I think the patient empowerment might uncover some APIs that are driven by patient desire to do something that Providers , EHR, and Payers are not interested in providing.
Abbie Watson (Apr 03 2019 at 14:27):
We (Symptomatic) are very much in this space also, and like @Mikael Rinnetmäki have also found the FHIR spec in general to cover 80% of what we need. The remaining 20% could be summarized in the following two challenges (imo):
1. Coordination of test patients between EHR vendors. We're finding that each EHR has a different set of test patients (Jason/Jessica Argonaut, Nancy SMART & family, Candace Salinas, etc). Which is nice, but doesn't help with use cases around patient matching, consolidating patient summary data, and otherwise. This is ostensibly what the Ring of FHIR project is hoping to address (I think), although the Synthea project is also relevant. It would be great to get an IG for a longitudinal patient record that encompases all the major EHR vendors. Register that longitudinal patient in Synthea, have the folks running Ring of FHIR register the patient in each of the participating EHR instances, fetch that patient across the Ring of FHIR, and get that reference in place so these patient centered apps can compare their results with the benchmark.
2. Secondly, it's the 'write data' use case. And specifically... how to track provenance? How is quality control performed? Are standards such as the Integrated Health Model Initiative (IHMI) and other evidence-based-medicine being supported? What does the workflow for return data look like? Is it fully automated or is it queued? And so forth. We have some ideas about how we want (hope) these processes to look like, but I suspect it's going to be cat-herding of different ideas. My worry is that the major EHRs are going to try to influence these IGs, and they're going to default to an assumption of keyboards, mice, and laptops because of intrenched investments; and ignore advanced/consumer haptics use cases involving NFC, geolocation, voice, IoT, etc.
Ron Roozendaal (Apr 03 2019 at 17:48):
@Grahame Grieve thanks for starting this! Agree with @Alexander Henket that provider and patient api's should be as much the same as possible. Would love to start bringing up all IG's already available and come to a first set of as much as possible (internationally) standardized api's.
Dave deBronkart (Apr 03 2019 at 17:59):
I'm totally puzzled about why a patient API (whatever THAT means) would be any different from a provider API. Is there an example of what a patient API would need to do that is not possible with (or not well suited to) a provider API?
Alexander Henket (Apr 03 2019 at 18:04):
The things we found solutions for in MedMij that may or may not be the same as Argonaut and other initiatives, and where I would like to have a proper conversation:
-
We implemented the patient summary using queries on the individual building blocks. Push to the Patient is not supported in MedMij anywhere. No document, no compartment, no operation, no graph. This serves some things really well and complicates others.
-
We looked at Argonaut for Appointments and found the method for canceling using PATCH too complicated. We used an operation instead
-
We looked at SDC for Questionnaire(Response) and found it lacked provisioning the Q to the patient. We added a Task construct for that. That solution is going to be balloted locally soon. We were not ready for the operations in SDC and decided not to include those currently. We did not address how to find where the QR goes.
It's these and other things like it, where we might support each others basic FHIR resources, likely do not understand each others code systems and extensions, but we might not be able get the basic flows running because we don't support the same interaction patterns.
I don't know at this point what a patient focused API is, but my interpretation would be that we try to harmonize how we leverage the existing FHIR API spec for certain use cases. So it is not so much the invention of something new, but rather how to constrain similarly.
John Moehrke (Apr 03 2019 at 18:54):
I'm totally puzzled about why a patient API (whatever THAT means) would be any different from a provider API. Is there an example of what a patient API would need to do that is not possible with (or not well suited to) a provider API?
Where are you getting the impression that it is fundamentally different? I read every message here as fully supportive. So I am puzzled at your puzzlement. I presume the puzzlement is from other communities, it would be good for us to understand where divergence is coming from too.
Dave deBronkart (Apr 03 2019 at 19:01):
Ha! @John Moehrke , the only reason I'm assuming it's different is because people are TALKING about a patient API, instead of just "the API." I ain't the one who added the modifier.
What IS, then, a patient API? What are y'all talking about?
John Moehrke (Apr 03 2019 at 19:04):
well, any specification of an API starts with use-cases... and there are some use-cases that are driving some FHIR API definitions that are not appropriate for a patient to be engaged in... like reporting on population health statistics... not that we are trying to hid something, just that an API has a defined use-case
Dave deBronkart (Apr 03 2019 at 19:07):
I will now return to the top of this stream, in which Grahame said:
So we're starting to have standards communities proposing to create "patient focused APIs" **That is, an APi that is expected to implemented by patient apps running in hand-held devices owned by the patient.** There's a set of different functionalities this might entail: * accessing patient summary data (e.g. USCDI by Us-core - argonaut) * Gathering patient reported outcomes measures * collecting wearable sourced data * letting patient's make appointments + request / order services or supplies * extending care into the home * medications management at home '''
Abbie Watson (Apr 03 2019 at 19:08):
I'm totally puzzled about why a patient API (whatever THAT means) would be any different from a provider API. Is there an example of what a patient API would need to do that is not possible with (or not well suited to) a provider API?
Think it through in terms of syntax and grammar. In English, we have nouns, verbs, direct objects, possessives, propositions, etc. The default FHIR API is pretty much just verbs (get/put/post/delete) acting on nouns (resources). SMART on FHIR then extends that model by introducing direct-objects via the provider launch context. No longer am I simply an abstract librarian fetching an abstract medical record; but now I'm a provider fetching the records of a specific somebody else.
The thing is... somewhere along the way, we began to assume that SMART on FHIR provider launch context is the default. From a business perspective, traditional billable activities for providers (and ROI) is all within the provider launch context. So implementors simply begin with the provider launch context, because that's where the money is. Patient launch context is still not implemented on some of the major EHR vendor systems.
But back to the syntax and grammar model… a Patient API would have a few things… a SMART on FHIR patient-launch context, at the very least. That would involve using the launch context to describe a sense of ‘self’. Basically a self-referential loopback, similar to 127.0.0.1, but at the application level. I suspect that will involve putting the patientId in some standardized place along with the OAuth access token, as it seems to differ between EHR implementations right now.
Once we can get that sense of ‘self’, then the grammar and syntax of the API can have meaningful possessive attributes. The most interesting of which is probably a $my operator, followed by $near,$recent and other prepositions. Get my procedures. Get my medication orders. Get providers near me. and so forth.
Compare that in contrast to the provider/EHR model of looking up a patient… name, age/date of birth, sex/gender? Why would any patient need or want to look up records in such a format? How often does that change? It's entirely premised on a many-to-one usecase, whereas the Patient API usecase is almost entirely one-to-one(self). Also, what value would a $my operator be to a provider? The patient doesn’t care about their doctor’s medical records. But as a patient you know what would be useful? POST $my Medications _history $to Providers $near $me. I'm using pseudocode to illustrate the point; and how that gets sorted out to REST API I'm not sure. But suffice it to say that there would be different usage patterns for Patient centric access.
tl;dr… Anyhow... much of what would be needed to satisfy the needs for a Patient API will probably involve SMART on FHIR and query/search parameters.
Dave deBronkart (Apr 03 2019 at 19:14):
I have a feeling I'm not the right person to sort out (yet) what the heck you guys are saying - John seems to be saying patient API is a subset of BHAGAPIOE (big hairy audacious generic API of everything), whereas Abigail is talking about adding direct objects (love the grammar metaphor, Abigail).
I'll let others decide when it's time to pursue this. For the moment I'm personally willing to step back to higher-order strategic topics.
Lloyd McKenzie (Apr 03 2019 at 19:15):
The only addition I'd make is that a patient API will almost certainly also want to extend to accessing the records of children or other family members the user has care responsibility for (and permission to access). So part of the API will be about how to manage such access requests
Lloyd McKenzie (Apr 03 2019 at 19:16):
The patient API might also have a higher priority need for being able to review Provenance - who's looked at or changed 'my' record. That tends to be a lower priority for sharing amongst providers.
Grahame Grieve (Apr 03 2019 at 19:22):
patient and provider have very different use cases, so the API differs. Also, the eco-system around patient is very different than that around provider. And inherent in my question is the idea that patient is core and worth more effort not to fractionate. For instance, I know of no reason to think that provider focused software should not be different in different counties, but no good reason why patent focused software should be
Grahame Grieve (Apr 03 2019 at 19:24):
@Ron Roozendaal indeed I would like them to be much the same as possible. I'm just not sure how to work on that (particularly once multiple languages come into play). @Alexander Henket I don't recall the MedMij issues being discussed with Argonaut / SDC?
Lloyd McKenzie (Apr 03 2019 at 19:31):
The differences in different countries would come down to legislation and culture, same as always. What providers are allowed/required to share may differ, expectations for proof of identity (and infrastructure to support it) will differ, rules around access to data for children will differ. And, of course, the standards mandated on the data itself (e.g. codes for drugs) will also differ. Can't insulate the patient API from those impacts.
Grahame Grieve (Apr 03 2019 at 19:37):
no you can't. but there are lots of other things that differ that we can and should minimise the differences. Like the differences between Argonaut and IPS - some of them are requirements based, but most are not
Alexander Henket (Apr 03 2019 at 19:46):
Alexander Henket I don't recall the MedMij issues being discussed with Argonaut / SDC?
They weren't to my knowledge. The Appointment stuff was produced in a pressure cooker situation, and we first took the outcome to a local PoC type of setup. The feedback was minimal so far. Secondly the framework (Afsprakenstelsel) around it was lacking functionality to really move forward on the use case, so we're a bit in between stations with that work.
Questionnaire(Response) is different. We are on the verge of a local ballot and the Task thing is no more than 2 months old so in between WGMs. I'm sure my colleagues meant to take that to SDC, but have not gotten to that yet.
Dave deBronkart (Apr 03 2019 at 19:49):
So I'll punt to a yet-higher level: do we have, yet, a human-friendly article about what an API is and does (or allows), but with enough specifics that one could get a feel for the decisions that must be made in specifying one?
I'd be quite happy with something that, instead of "starts with use cases" (which would scare away some family caregivers), says: (And I won't be surprised if some of these are stupid /impractical examples)
* I need to be able to check if there are interactions between Mom's new meds and the ones she's already taking * I need to be able to link Mom's WiFi scale's weight data (or step count data or...) so her HCPs can track it * I need to be able to fetch everything about Mom's knee history, for her new ortho to review * I need to pull up my notes about my random mild gout episodes, because it's getting annoying enough I finally want to talk to someone about it * I want to create an EMT Info sheet that summarizes what ambulance people will need to know, so they can view it while racing to the scene (home, car crash, restaurant...) and so that it AUTOMATICALLY STAYS UP TO DATE ''' Okay, y'all, throw darts at THAT. (I generated that list by thinking of things that would be compelling value props for caregivers I personally know - things they worry about) (Plus my gout, which my doc says probably isn't gout)
Alexander Henket (Apr 03 2019 at 19:49):
@Abigail Watson For some reason I have never been able to get the MedMij framework people in touch with the SMART on FHIR people. Secondly I've never quite grasped why SMART on FHIR was deemed unfit for the MedMij setup: I just know it has been. So for now your assumption that SMART on FHIR is the common starting point for any Patient centric app will not hold here.
Abbie Watson (Apr 03 2019 at 19:54):
Well, that's certainly interesting to know. SMART on FHIR basically specifies FHIR and OAuth (and OpenID). We might be able to refactor the patientId away from the OAuth scope and into a RESTful endpoint. /fetchMyPatientId or fetchMyIdentity or similar.
Dave deBronkart (Apr 03 2019 at 19:56):
One REALLY compelling use case for caregivers, btw, is defending against flipping STUPID UNDERPAID IDIOTS who work in some doctors' offices these days.
I'll drop in this true scare-bomb: when my mom saw a new eye doctor last year, an assistant interviewed her as usual (because of course her data couldn't flow in), and then in the doc's room he examined her and said "It looks like we're going to need to do surgery." She asked why (the symptom wasn't that bad) and he said "It's the best thing to do, since you're diabetic." "I am not," she said. He pointed to the chart, created minutes earlier.
It turns out the idiot assistant, reviewing meds, had seen one that's PRIMARILY for type 2 diabetes but has other indications. Stupid Idiot saw it and also wrote that Mom's diabetic! Without asking or even noting that she did.
Maybe this use case is dubbed SDAIMA - self-defense against idiot medical assistants.
OTOH, in this case clearly the doc himself is culpable for handing a medically critical task to someone he hasn't trained to handle the responsibility! My point stands.
Alexander Henket (Apr 03 2019 at 20:01):
Sure from experience in various studies we found that very large percentages of patients found errors in their records after gaining access. They also became frustrated rapidly if the processes were not in place to correct them.
Another area of fun is providers contradicting each others diagnoses. For example because you switched providers and data becomes outdated.
Grahame Grieve (Apr 03 2019 at 20:03):
They also became frustrated rapidly if the processes were not in place to correct them.
What processes do you have in place?
Dave deBronkart (Apr 03 2019 at 20:03):
Yes, @Alexander Henket , there are many reasons for the patient to become the "single source of truth." The complicating factor is patients who have truly ignorant beliefs, like my relative who honestly believes the government has poisoned the clouds so we must all dodge the raindrops. (This is a just plain stupid person, not someone with a mental health diagnosis.)
Dave deBronkart (Apr 03 2019 at 20:07):
Replying to self about SDAIMA: I know numerous vendors have for YEARS been stymied by lack of data streams, and it's wild to anticipate how many might blossom (and vary) when they finally have access to "fuel."
Alexander Henket (Apr 03 2019 at 20:11):
In the studies there were some experiments with MedicationStatements. Most was face2face though. At the very least the PHR should be able to let a patient mark faulty data so he isn't presented in the interface with that every time.
We intend to make MedicationStatements flow back electronically in general but aren't there yet. The patient did not appear to mind about the exact measures at his disposal for correction, as long as he could.
Abbie Watson (Apr 03 2019 at 20:19):
We're seeing that general sentiment also. As soon as we started pulling production records and showing them to people in a pilot, we had users identifying errors and corrections they wanted to make. Right now, we're looking at providing a phone number to the hospital, printing out a reconciled record in PDF (possibly with compare/contrast), and allowing the user to download/export the reconciled/modified record.
Once we have an updated Bundle (CCDA on FHIR) though... then what? Serialize to v2? POST to the /Bundle endpoint? POST updated resources individually? Post to some sort of other endpoint? That's maybe registered in /metadata? idk.
Alexander Henket (Apr 03 2019 at 20:25):
@Dave deBronkart We try to anticipate for patients with varying degrees of proficiency. The PHR is not to be a requirement for patients, but an option. We do not assume any singular app/platform for anything. Patient has choice. We are working on patient friendly terms for all common SNOMED CT concepts. We have talks with medication database owners so they can provide APIs for additional information, the PHR UIs shall comply with rules for vision impaired people.
Things we could not solve: between age 12-16 there is a consent issue, health guardians are in an official registry without public access so there's no way to know who's in there and various other specialized cases (prisoners, mental unstable people, bastard off-the-record children mentioned in your EHR, ...). A thing we did not scope: if the patient has so much app choice: how does data portability work when he moves from appA to appB
I for now would be happy if we could get harmonization on how to approach use cases without considering all aforementioned possible exceptions. I very much liked how @Abigail Watson framed it using the pseudo code.
Alexander Henket (Apr 03 2019 at 20:30):
Once we have an updated Bundle though... then what? Serialize to v2? POST to the
/Bundleendpoint? POST updated resources individually? Post to some sort of other endpoint? That's maybe registered in /metadata? idk.
We didn't come far enough to know if a Bundle is useful, or maybe just upload each MedicationStatement. In any case it would be a FHIR solution from the patient perspective. It might get translated into something else to be entered in the EHR. From there, some reconciliation process would need to start, with an outcome that somehow makes it way back to the patient.
Abbie Watson (Apr 03 2019 at 20:46):
Maybe we just throw on a _reconcile parameter to the POST url to trigger the reconciliation process? Also, the CapabilityStatement resource tracks interaction field. This may be a significant enough use case to justify a new top-level interaction. How about 'reconciliation' as a top level interaction? A system can register that it supports reconciliation writes in the Capability Statements, and if they do, the patient can POST to the various endpoints using a _reconcile parameter (similar workflow to _history). The receiving system can reconcile the receiving data however it wants.
Grahame Grieve (Apr 04 2019 at 00:40):
@Dave deBronkart here's my list or what I want to see (for your human friendly article):
I need to
- get medications sent to me so my own app has the list I'm supposed to be taking
- be able to check if there are interactions between Mom's new meds and the ones she's already taking
- share information from my wearables / scales / etc with my healthcare providers when they want it
- get my health history etc from my providers and build a single complete history
- keep a copy of my referrals
- share my history with providers and automatically fill out (pre-)admission forms from it (+ my meds)
- keep track of my own issues and share notes when appropriate
- maintain a summary sheet for EMT usage
- have a copy of my care plans and give access to them to my care team
- send secure messages to my care providers when I have problems with my care plan
- be able to choose / switch patient focus across those I have access to (family etc)
- choose other systems to share my data with to get care support or to support research
Bart Carlson (Apr 04 2019 at 03:19):
patient and provider have very different use cases, so the API differs. Also, the eco-system around patient is very different than that around provider. And inherent in my question is the idea that patient is core and worth more effort not to fractionate. For instance, I know of no reason to think that provider focused software should not be different in different counties, but no good reason why patent focused software should be
One reason patient focused software might be different from provider focused software in different countries ( assumed you meant countries, not counties) is the potential difference in laws across multiple countries.
Grahame Grieve (Apr 04 2019 at 04:20):
yes countries.
Alexander Henket (Apr 04 2019 at 06:01):
That last list seems like a fine starting point. It's easy to make that list grow fast but we also need some focus my tendency is towards smaller first.
What's next? Presumably we can all get access to IGs around the world from here http://hl7.org/fhir/. I see I have a task on my list to make MedMij known in the "Other" section. that currently only lists IHE. This might give us a hint here who we might have missed.
Organizationally: is this thread the best place until we've grown beyond practicality? We should probably have a Confluence page for note-keeping. For the short term this probably contains important fragments until we think we can have a stab at an IG? Somewhere a PSS is helpful to make us think about process/timelines/deliverables?
Grahame Grieve (Apr 04 2019 at 06:04):
I better change that link to point to here:
Grahame Grieve (Apr 04 2019 at 06:05):
http://www.fhir.org/guides/registry
Rien Wertheim (Apr 08 2019 at 13:19):
Would this (Patient APIs) be a topic for a popup session at DevDays in June?
Didi Davis (Apr 08 2019 at 18:42):
HL7 committees mainly, though I expect that overlapping discussions are also happening in IHE (John Moehrke ) Carequality (Didi Davis ) CarinHealth (Ryan Howells ). and I know that some affiliaites are having them (a la MedMij in Netherlands as above) and Argonaut in Australia and nordic countries. Also, SPM and QS would be interested though I'm sure not discussing stuff yet
@Grahame Grieve Carequality plans to point to work developed by other groups such as the CarinHealth Alliance, Argonaut, etc. with regards to patient focused APIs in general. However, Carequality does have several Consumer App implementers who are discussing the requirements for Authentication, Trust and Authorization in the FHIR Technical Workgroup. The Technical Workgroup is focused on creating an “implement once, connect
universally” ecosystem. This slide shows the current Carequality Connected Agreement Signees where you can note the listing for all the planned networks and the three consumer focused networks. pasted image
Dave deBronkart (Apr 08 2019 at 19:52):
Would this (Patient APIs) be a topic for a popup session at DevDays in June?
1. It would need to be led by someone who knows what's possible
2. Ideally it would involve people like Mike Morris and Kristina Sheridan who know in some detail what they want.
3. Or people who have a simpler (but valid & valuable) use case, solvable on the spot.
The following may be an insane statement, but it would be AWESOME (and I think genuinely worthy of attention) if a use case could be implemented on the spot. My (uninformed) goal here would be for it to be easy for lay people to understand, so that press coverage of it would ignite interest where appropriate in the lay press.
Do we have anywhere a list of existing smartphone apps that use FHIR, and the data objects ("resources," I believe) each can fetch or put?
Grahame Grieve (Apr 08 2019 at 21:43):
@Didi Davis this seems unconnected from , sat, this: https://chat.fhir.org/#narrow/stream/179190-united-states/topic/Publishing.20FHIR.20end.20points. how do we align all this work better? I'm sure we only one want one approach here? (and not confined to USA)
Michele Mottini (Apr 09 2019 at 08:04):
Do we have anywhere a list of existing smartphone apps that use FHIR
No. The EHR vendors (notably Cerner and Epic) have it - because the app have to register and specify the data they want, but it is not public
Dave deBronkart (Apr 09 2019 at 17:47):
Do we have anywhere a list of existing smartphone apps that use FHIR
No. The EHR vendors (notably Cerner and Epic) have it - because the app have to register and specify the data they want, but it is not public
?? Are there no FHIR apps yet that depend on connecting to EHRs?? Are there none that, for instance, merely connect to Apple and fetch / put data to/from there?? @Ricky Bloomfield or anyone?
Pascal Pfiffner (Apr 09 2019 at 17:49):
There are, there's an "Apps That Work with Health Records" collection in the US App Store under "Medical".
Pascal Pfiffner (Apr 09 2019 at 17:50):
The apps listed there connect to HealthKit to retrieve the FHIR data the Health App downloads.
Dave deBronkart (Apr 09 2019 at 18:12):
There are, there's an "Apps That Work with Health Records" collection in the US App Store under "Medical".
Thanks, Pascal, but I can't find any such thing - anyone got a link?
Ricky Bloomfield (Apr 09 2019 at 18:52):
Go to the App Store app -> Apps tab -> scroll to Top Categories and tap See All -> scroll to Medical -> See All.
Not ideal, but it’s there and it gets updated from time to time.
E64A9F26-B025-40E3-BF37-005B589FD112.png
Josh Mandel (Apr 09 2019 at 19:00):
Reviewing the thread here, I agree with everyone of the use cases Grahame included in the initial list. And given the discussion, I'm sure at all sure that bringing together a unified effort is possibly yet. That said, I'd be keen to support any efforts in this direction (whether formal or in-). Building guides or better, reference tools...
Dave deBronkart (Apr 09 2019 at 19:14):
Thanks, @Ricky Bloomfield . I'm surprised to see only 7 apps there, but then I ain't at all clear on what would be the dividing line between in and out. Is that an easy question to answer?
Michele Mottini (Apr 09 2019 at 19:19):
Are there no FHIR apps yet that depend on connecting to EHRs
Don't understand what you mean - there sure are...?
Ricky Bloomfield (Apr 09 2019 at 19:23):
@Dave deBronkart @Rien Wertheim FYI, we will be holding an interactive session at DevDays to review the Health Records API on iOS. We’ll have engineers there (including @Pascal Pfiffner!!) who can help you realize your patient empowerment dreams. It would totally be possible for someone to implement something “on the spot” if they so desired and have some iOS experience. Would also love to see that happen.
Dave deBronkart (Apr 09 2019 at 19:41):
We’ll have engineers there (including Pascal Pfiffner!!) who can help you realize your patient empowerment dreams.
Oh dude, you don't know what you're getting into, when you say help ME realize my empowerment dreams ....
It would totally be possible for someone to implement something “on the spot” if they so desired and have some iOS experience. Would also love to see that happen.
Hey, what a FABULOUS opportunity for Apple to sponsor an F-Prize!
(When I say "Careful what you wish for," and it's about MY desires, I mean really, be careful - or thrilled at the opportunity!)
Abbie Watson (Apr 10 2019 at 01:06):
The EHRs do in fact list the apps that are available in their stores:
https://apporchard.epic.com/Gallery
https://code.cerner.com/apps
https://allscriptsstore.cloud.prod.iapps.com/category/fhir-apps
You may also want to keep track of the HSPC Marketplace, which is purported to be a vender-neutral app store, to be launched sometime this year.
https://www.hspconsortium.org/
Josh Mandel (Apr 10 2019 at 02:17):
Well, and apps.fhir.org for that matter
Michele Mottini (Apr 10 2019 at 10:09):
https://apporchard.epic.com/Gallery lists the app in Epic App orchard, not the ones that use the free API, I don't know how the Allscripts registry works but our app does not show up there as well
Cooper Thompson (Apr 10 2019 at 20:12):
A result of open client registration is that we get a TOOOOOON of junk registrations. Without a vetting process, we have no idea which of the client registrations are real apps and which are folks playing in our sandbox using Postman or Fiddler. We have apps registrations with names like TestApp, Demo1, MyTestingApp, etc. We could filter to those that have production API usage, but that doesn't tell the whole story because developers who are patients at organizations using Epic can create a client registration and use Postman/Fiddler to make production API calls using their personal accounts. All this to say that one of the trade-offs of making client registration easier is that providing an accurate listing of real apps gets harder.
Abbie Watson (Apr 10 2019 at 20:35):
I don't envy you all in that regard. There's lots of folks who are quick to complain and criticize, but aren't thinking through the details of what all is involved. (The Nov upgrade was a good move forward though, imho.)
Dave deBronkart (Apr 12 2019 at 01:40):
Well, and apps.fhir.org for that matter
Thanks! Is there any significance to the fact that apps.fhir.org redirects to apps.smarthealthIT.org? (Remember, I'm still very foggy on differences between any flavors of this stuff.)
Man, that list is literally making me breathe heavy ... making me brain-horny. Somebody get me a day job where I get paid to explore that stuff. Thanks, @Josh Mandel - this is what I was looking for.
Dave deBronkart (Apr 12 2019 at 01:55):
Has anyone published reviews of FHIR apps?
Before long I'm going to need some guidance on what to tell Newbie-World out there about all of this. I'll need help.
Josh Mandel (Apr 12 2019 at 20:15):
Is there any significance to the fact that apps.fhir.org redirects to apps.smarthealthIT.org? (Remember, I'm still very foggy on differences between any flavors of this stuff.)
I think the main significance is that while ONC sponsored the work to put this SMART gallery together, there was strong interest in building it in a cross-community way (broader than just ONC stakeholders). As part of the proposal, the SMART team got buy-in from the FHIR Foundation to use the apps.fhir.org URL.
Alexander Henket (Apr 17 2019 at 02:02):
I think this thread has slowly derailed a little from its original intent, and I would like to get back to that intent or as far as I understood it to be.
So DevDays US will be having a session on one example of what a patient API could look like. That's great, wish I could be there, but I'm not: please repeat that session in DevDays Amsterdam. Most importantly: it is good to explore different examples, but what we need is to find common ground for common use cases. This way, we would see more chances for vendor implementation to work across different countries with limited effort.
Question remains: how do we organize this? Could this be part of an existing WG? Do we need a new one? So far we have national projects operating in national rooms where national participants may or may not look outside their project for how other people did the same thing.
Problem: interoperability between national projects is currently by accident, not by design. FHIR Core for as far as content is concerned would be a given, but whether or not you can get to that content depends on the workflow/API design.
Grahame Grieve (Apr 17 2019 at 04:44):
thanks for bringing us back to this. @Rien Wertheim note the call for DevDays Amsterdam.
Grahame Grieve (Apr 17 2019 at 04:44):
I don't really know the answer, actually. I don't know if HL7 is the best place for it. Maybe it is, but what partnerships do we need? GDPR? IHE? Vendors?
Rien Wertheim (Apr 17 2019 at 12:13):
We'd love to schedule a meeting for this at DevDays in the US and Europe, but I am still not sure if there is enough beef in this.
Alexander Henket (Apr 17 2019 at 12:52):
If HL7 is not the right place for this I'll at least run into funding questions for F2F meetings. I don't have that issue for WGM visits. You may still be right: I'm also in doubt. The whole notion of working on common ground for a broader use case really feels like IHE territory, even if the patient is not currently really in their scope.
To give the whole thing some body I'd like to see commitment from at least Argonaut, and HL7 IPS. I'd happily contribute for MedMij (NL). I've seen more patient oriented groups in this thread that I didn't know of before like CARIN: broader is better at least in startup phase.
What I think our deliverables could be is to extend from the basic guidance given here http://hl7.org/fhir/usecases.html and work on IGs containing (workflow) patterns around such use cases. We could also find there's spinoff work in spotting harmonization potential in local profiling (e.g. because there is or should be a core extension where a local extension is). From that spinoff work we could also work on more localization guidance e.g. here http://hl7.org/fhir/profiling.html. That last page is specific on what you MAY do, but less specific on what you SHOULD do.
Dave deBronkart (Apr 17 2019 at 14:10):
[Rien] I am still not sure if there is enough beef in this.
Am I a chicken in search of an egg, or vice versa?
More generally, are you saying that nobody has defined a patient use case yet that is at all interesting? (Has anyone?) Has anyone tried to gather a group of patient-centered apps from other universes, which should become interested in FHIR? Should I shut up until someone says it's consumer-time? ( @Grahame Grieve I thought that's why you chased me up at #HIMSS18)
I need to become unconfused or put myself to sleep for 18 months or something. Advice please (@Grahame Grieve @Rien Wertheim anyone)
Abbie Watson (Apr 17 2019 at 14:49):
It is good to explore different examples, but what we need is to find common ground for common use cases. This way, we would see more chances for vendor implementation to work across different countries with limited effort.
Question remains: how do we organize this? Could this be part of an existing WG? Do we need a new one? So far we have national projects operating in national rooms where national participants may or may not look outside their project for how other people did the same thing.
Problem: interoperability between national projects is currently by accident, not by design. FHIR Core for as far as content is concerned would be a given, but whether or not you can get to that content depends on the workflow/API design.
As mentioned above, the Ring of FHIR and Clinicians on FHIR project are maybe relevant attempts at coordinating such efforts. We could either set up a new group modeled after either of them, or we could submit Patient centric usecases to them, such as we (Symptomatic) did with the Clinician on FHIR and Blockchain on FHIR usecase PDFs.
I'm trying to be careful about marketing and soliciting, because our use case documentation is effectively also our product brochure... but we have documents that fairly clearly spell out use cases for Data Fetch, Longitudinal Timeline, Data Reconciliation, Medical Home Management, Remote Patient Monitoring, Health ID, and others. We also have the blockchain usecases, such as Health Passport, Patient Index, Organ Donor Registry, Consent Management, etc.
In the near term, one immediate thing that needs to be harmonized are default test patients between EHR systems. In effect, we need an IG that cross-pollinates some curated test patients across the different EHRs. Something I'm hoping to discuss at the Montreal Working Group.
Alexander Henket (Apr 17 2019 at 15:46):
Ring of FHIR: I can only find something at HIMSS Jan 2019, but apparently it's more than that?
I like your notion of "Patients on FHIR" similar to "Clinicians on FHIR". Maybe what we do could be practical first rather than theoretical. When we have solid Connectathon scripts around one or more use cases, and find enough backing implementers that take those experiences 'home' to their local projects for input then that could fuel things in the right direction without becoming a new 'meeting club'. Those same scripts, advertised properly, could lead to patterns that people find useful without venturing into an arbitrary number of local projects which is what I do today.
Alexander Henket (Apr 17 2019 at 15:50):
Best of all: we'd be tapping into the Connectathon community/schedule that already exists, hence less extra organizational overhead to be expected. Working on getting the right scripts with the right depth/breadth and eventually generalizing them into something of an IG would require additional effort, it just might work by starting small.
John Moehrke (Apr 17 2019 at 17:10):
It boils down to resources. We are all very busy with 'day-job' work. We would all love to carve out non-paid-for work, but there is not much time left in a day. I am not discouraged from working on patient centric use-cases, but there is only so much time left in a day. -- To be blunt, follow the money, there is money paying for all available resources to achieve business objectives, there is no money paying for patient objectives. Any movement you see on patient objectives is either influenced by business objectives (The VA has historically been a patient advocate), or is done out of the kindness of the individuals free-time.
Alexander Henket (Apr 17 2019 at 19:30):
Understood. MedMij certainly has funding and it solely concerns patients. I would hope any project has its funding worked out. What could be missing here and there is a project description that includes investing time in the community and/or a simple lack of awareness.
I certainly would not claim to know all projects around the world doing the same use cases we do. We look at things we know exist, use what we can, and adapt what we can't, work with the FHIR Core community on changes/additions to the core, but we don't normally go to Argonaut or SDC to ask for changes (tried once for SDC but SDC shifted to R4 and did not maintain STU3). We worked with you on MHD which was fruitful until (again) attention shifted to R4. Being a 'good local FHIR citizen' involves work with the international community. The less localization is needed, the better.
Dave deBronkart (Jun 08 2019 at 03:26):
Boy, it's been almost two months since this thread brewed up a storm, and now here we are, headed to Seattle.
Given the seven-part blog series I've done (#8 tomorrow) leading into Seattle, and leading directly into patient needs for data access, is it time to stir this stewpot again, and see what all the chunks look like today?
For those who haven't seen, I'll come back in a moment with a link to the blog thread (in the "Origin Story / blog posts" stream).
Dave deBronkart (Jun 08 2019 at 03:30):
Here's the thread ... I'm not facile enough with Zulip to link to the lower post that has the whole set of blog URLs
https://chat.fhir.org/#narrow/stream/179262-patient-empowerment/topic/e-Patient.20Dave's.20.22origin.20story.22.20-.20why.20patients.20need.20data
Last updated: Apr 12 2022 at 19:14 UTC
