Apple opens up its core health records API to US developers
Technology giant Apple has announced it is opening its Health Records application programming interface (API) to developers in the US.
The move allows US iPhone users to share their health record data with third-party apps from autumn.
Developers could use this shared medical data to personalise apps tailored for medication tracking, disease management, nutrition planning and medical research.
Apple’s Health Record, which features in the health app, was launched in the US, in January 2018.
The new feature, which was introduced during the iOS 11.3 update, allows patients of more than 500 hospitals and clinics to access medical information on their phone.
Jeff Williams, Apple’s chief operating officer, said: “Medical information may be the most important personal information to a consumer, and offering access to Health Records was the first step in empowering them.
“Now, with the potential of Health Records information paired with HealthKit data, patients are on the path to receiving a holistic view of their health.
“With the Health Records API open to our incredible community of developers and researchers, consumers can personalize their health needs with the apps they use every day.”
Health Records data is encrypted on iPhone and protected with the consumer’s iPhone passcode.
When consumers choose to share their health record data with trusted apps, the data flows directly from HealthKit to the third-party app and is not sent to Apple’s servers.
5 Comments
Some points missing from the article. Apple are able to do this because a large number of US hospitals and providers have provided US FHIR Data Query API, more commonly known as Argonaut.
Apple gets authorised via OAuth2 (as mentioned in another reply), so the Patient gives permission for the Apple App to access the data. The provider also has to authorise this access (I think this is done via a trust agreement with Apple??).
Apple DOES NOT store any patient records (technically it may do for a very short amount of time). This means it can’t work with HL7v2 event messaging and all the GPDR, IG issues that would entail for Apple. HL7v2 (and equivalent FHIR event) messaging has it’s place but mobile and web apps isn’t it.
In the UK we do have an equivalent of the Argonaut data query but it’s using a more modern version of FHIR. This is part of INTEROPen Care Connect.
I think the credit really needs to go to US hospitals and system suppliers rather than Apple (and I believe Google is doing the same).
Agreed Apple doesn’t look to be storing that information, it’s an on demand pull, but while they are opening up API’s to pull Health data then a next (more useful) step would be to accept incoming HL7 v2 data and then push or hold for an interval long enough to allow 3rd party authorized health apps to pull it in and store. Could be a real game changer, especially considering how low adoption of FHIR is even among US hospitals.
If you don’t recognise #disruption; this is one such example !
Good decisions utilizing FHIR as the message standard and OAuth2.0 for a SSO experience. Would have really liked to see a push model included utilizing HL7 v2 event based messaging. This would drive adoption at scale (not just FHIR enabled hospitals) as well as real-time patient prompting to interact with their record.
Wrong way around, again!
The HealthKit app might be great, and it’s a welcome addition to viewing records, but the phone is not the place to sit an information sharing mechanism. It needs a record, in the cloud, that developers including the Apple App can plug into. This is a nice gimmick, but that’s about it.
Comments are closed.