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