Wednesday, June 22, 2016
More information on CCDA and HealthKit
Last week I reported that Apple is bringing support for CCDA to HealthKit, enabling users to download their medical records from any Meaningful Use Stage 2-compliant electronic health record system. At the time there wasn't much additional information available. Since that time, Apple has publicly posted the WWDC session on the topic, which can be viewed here. The portion on Health Records starts at the 17:20 mark.
From the presentation it is clear that Apple allows users to download and view their documents:
One question I've received, however, is what HealthKit does with the document once it has been downloaded, i.e., is it "parsed" in such a way that makes the discreet data elements available for use by other applications, or visible in HealthKit? For example, would blood pressure, weight, or glucose values be added automatically to the appropriate fields in HealthKit?
Currently, the answer appears to be "no." According to the limited documentation of the HKCDADocument Class, the class has 5 instance properties, one of which is the document data as a blob. The other 4 instance properties are parsed from the XML, and include: authorName, custodianName, patientName, and title. These 4 data elements appear to have been chosen to allow the consumer of the data to identify the document and compare with other health documents that might be saved to HealthKit.
At this point it's important to note that each CCDA document saved to HealthKit becomes a distinct entity, and that any de-duplication of data would need to be done by the consumer of the data. For example, if a user downloads a CCDA from their patient portal, then re-downloads the document a month later, those are saved as two, separate documents, and the second document would contain all the information from the first document, plus any additions from the past month.
So, if the user gives your shiny new health app access to these documents, you (as the developer) will need to decide whether you pull only the most recent document or whether you pull all of the documents and harmonize the data yourself (a good bit of work).
In speaking with some of my colleagues, it might also be helpful in a future version of this implementation to have access to additional HKCDADocument properties to facilitate positive patient identification, such as date of birth or phone number (which is increasingly becoming part of our identities!). This will be important because HealthKit does not limit a user to only import his or her own health records. Work on a national patient identifier would definitely be helpful here!
Despite these limitations, the importance of giving patients access to their own data in this way cannot be overstated. This is a watershed moment. Yes, it allows hospitals and users to fulfill the intent of the MU2 requirements, but more importantly, it empowers patients to be stewards of their own data, and to decide when and how it will be used to improve their health.