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
  • No labels