Alix Goss
Bob Dieterle
Rick Geimer
Ed Martin
Danielle Friend
Karl Davis
Patrick Murta
One Pager - Apple (Ed Martin)
- Apple primarily focuses on the consumer market, with entry to healthcare via iPhone and software/hardware ecosystem (e.g. Healthkit & Researchkit)
- May not be as relevant to Directory Tiger Team due to consumer-focus
- Ability for patient/caregiver to use iPhone to pull/store EHR records based on the Common Clinical Data Set
- Owner of the iPhone can determine which other apps can access the stored records
- Healthkit is a consumer of FHIR API services, does not provide API services of its own
- Does include healthkit SDK for app developers to use to support local access
- Custom data model based on FHIR DSTU2
- Does not participate in a trust framework; privacy is consumer-mediated – patient supplies credentials (typically to a patient portal) to download data to the iPhone
- Apple provides guidance in SDK for developers to manage consent for local access
- Primary POC – Dr. Ricky Bloomfield (Clinical & Health Informatics Lead)
- As of December, Apple is connected to 150+ EHR instances
- UCSF recently went live with Apple Healthkit connectivity (all 5 campuses), and HealthKit is the most frequent FHIR API user
- largest hurdles involved privacy/legal issues, such as understanding liabilities/responsibilities involved w/releasing the data to a patient’s phone
- Point-to-point connectivity to each EHR
Karl – rumors/hope that Apple Health may eventually support a consumer claims data set as well
- Bob – CARIN Alliance is working on making commercial claims data available (similar to BlueButton 2.0 for Medicare FFS data); both use FHIR Explanation of Benefits resource. One Da Vinci use case involves making similar information (minus data about financial obligations) available to providers
Bob – in Healthkit, is data maintained discretely or is it represented as a document?
- Ed – it is available discretely, however it is segregated based on the source system rather than aggregated. Stored as a JSON object, which is also available to the user
Bob – what can this Tiger Team learn from Apple’s work? Anything re: scaling?
- Ed – technical connectivity is relatively straightforward b/c it is based on a single standard (FHIR DSTU2). Privacy/legal implications of the exchange are more difficult hurdles
- Bob – Apple is essentially providing the model of a clearinghouse, i.e. when a user wants their data they are accessing it through Apple’s infrastructure
- Ed – No. Apple provides a limited directory service to identify a provider organization, but the app routes you to a login screen supplied by that organization. Once patient authenticates, the app/iPhone connect directly to the FHIR endpoint for the organization
- Karl – does Apple require an SLA?
- Ed – not that I have seen, can double check
Bob – how does the app manage updates?
- Ed – when you open the app, it refreshes data for any of the provider organizations you are connected to. Also refreshes in the background on a scheduled interval, although the interval gets longer the longer you haven’t opened the app.
Bob – hearing that Apple provides the ability to determine whether a particular endpoint is available…when you authenticate what happens?
- Ed – login page is displayed for the provider organization; uses OAuth 2.0 tokens to allow calls to the API
- Bob – who provides the OAuth service?
- Ed – usually provided by the EHR
- Bob – when does the application obtain the FHIR server endpoint?
- Ed – as part of SMART on FHIR, URL for endpoint is provided during authentication
- Danielle – For Epic, Apple has the base FHIR endpoints. Capability statement provides authentication/authorization endpoints. SMART on FHIR workflow provides the redirect to the appropriate login page/FHIR server API (one per installation)
- Ed – OAuth “dance” includes specific steps, e.g. authentication step takes you to a page to enter credentials, provides a list of resources that the credentials can access, endpoint determines validity of security token and where to redirect the client once the credentials are accepted
- Bob – Oauth’s ability to scale?
- Karl – OAuth is a three-way authentication system, most useful for when a user wants to send data from a data holder to another location. OAuth doesn’t necessarily apply to system-system connections
- Bob – if I am a consumer authorizing a provider to share with another provider, would OAuth apply?
- Karl – given a patient’s consent at Provider A, Provider B can pull data from Provider A
- Bob – so this is a way to do patient-mediated consent
- Ed – there is also a two-way flavor of OAuth that could support system-system use cases, but not as widely used
- Karl – a patient-driven consent model fundamentally isn’t that scalable, e.g. doesn’t support use cases like a patient presenting at an ER and is unable to remember or use their credentials
Ed – in addition to Apple, there are other apps that can provide access to EHR data via APIs (usually b/c of a MU measure). Some of these apps store the data on the app’s cloud-based servers rather than the device itself
- Danielle – the MU APIs are listed publicly for Epic clients
- Ed – one difference between healthkit and many other apps is that Apple provides a refresh token to continue accessing data in the background (due to partnership between Epic/Apple)
Bob – could Epic have chosen to have a single endpoint and use a security token to pass queries? (i.e. Epic provides a single endpoint and manages connections internally)
- Geimer – I believe that’s how Cerner does it
- Danielle – we don’t today, but could have. Prefer federated approach
- Ed – Some EHR vendors have implemented the SMART on FHIR standard slightly differently, although have not seen this cause any issues yet