Apple is a beast. Usually, when they support something in iOS, it inevitably causes complete shifts in markets. Many businesses are born and others die. So, when Apple announced this…
Apple is a beast. Usually, when they support something in iOS, it inevitably causes complete shifts in markets. Many businesses are born and others die. So, when Apple announced this week that Health Records was launching in Beta with 12 prominent healthcare organizations already on board, it was a big deal in the industry.
Apple already had health data in HomeKit, right?
Well, kinda. Until now, the big claim for health data on iOS was supported CDA. That XML standard is brutally hard to work with and has little separated structure of health related resources. FHIR (Fast Healthcare Interoperability Resources) is a great first step in attempting to separate health data attributes into functions (patients, appointments, encounters, etc). This opens the door to interoperability of applications.
Apple only supported some healthcare data and basically it was only the data they wanted to invest development time in. The CDA format was bulky and not very clean.
What exactly does this new Health Records app function provide?
In short, for patients who go to one of the current supported healthcare facilities, they can get simple, consolidated, easy to read health information on their iPhone. Lab results, vitals, appointment information, or anything contained within the FHIR specification. A patient, lab, encounter, etc. in one system, can be translated to a related FHIR resource for use in HomeKit.
It is still a tough nut to crack, mostly because of inherited fear within the healthcare industry (patient confidentiality, data security, competition, etc) and the fractured data market within healthcare. Cerner, Epic and other EMR (Electronic Medical Record) systems all use and store data in different ways.
This is great news, however, for application developers who build health apps. The unification of Homekit standards into FHIR allows for quicker application development. This is fine for new apps but what about all those apps and websites already in the marketplace? Legacy apps are notoriously expensive to rebuild and users don’t want to have to learn something new. The solution for this is interoperability of healthcare data. Some companies translate from one format to another single format but its not true standardization and is not very scalable.
Taking data from one format (FHIR, CDA, custom) and pulling into a resource driven format and then building exportable tools that send data back in whatever you want is what we are doing. So, why not just use FHIR? Because it is still an ongoing specification and as a company, we want to create a more full featured standard of storing healthcare data plus add a service layer on top so that people building for apps like Health Records in HomeKit can use ANY format of data they want.
Build your healthcare application however you want, send that data directly to HomeKit in the format it expects.
List of organizations that support the BETA version of Health Records in HomeKit:
- Johns Hopkins Medicine – Baltimore, Maryland
- Cedars-Sinai – Los Angeles, California
- Penn Medicine – Philadelphia, Pennsylvania
- Geisinger Health System – Danville, Pennsylvania
- UC San Diego Health – San Diego, California
- UNC Health Care – Chapel Hill, North Carolina
- Rush University Medical Center – Chicago, Illinois
- Dignity Health – Arizona, California and Nevada
- Ochsner Health System – Jefferson Parish, Louisiana
- MedStar Health – Washington, D.C., Maryland and Virginia
- OhioHealth – Columbus, Ohio
- Cerner Healthe Clinic – Kansas City, Missouri