I think this touches upon one of the most important things Apple has done for its users: a convenient way to encrypt things. In every iPhone shipped today is a key and hardware to perform en/decryption. It's the dream that was never consumer-viable with smart cards. Shipping medical records to users is only one application.
Hold that P.R. there. Apple will sell your data out when compelled [1]. This is NOT a technology problem, it's a policy issue. And Apple isn't immune to governments & greed.
Totally false. It is a technology problem. Apple is at the forefront of engineering technical ways to make it impossible for them to decipher your data.
Specifically HealthKit data "is stored in Data Protection class Complete Protection, which means it is accessible only after a user enters their passcode or uses Touch ID or Face ID to unlock the device." Furthermore, "When configured for iCloud storage, Health data is synced between devices and secured by encryption that protects the data both in transit and at rest. Health data is only included in encrypted iTunes Backups. It is not included in either unencrypted iTunes backups or iCloud Backup."[1]
You also provide zero evidence that "Apple will sell your data" even if they could get it. Nothing in that citation about using China-based servers supports it.
That will give a clue about whether it is possible for Apple to decrypt the data or not...
It is impossible to trust a closed source system that cannot be audited independently. If Apple caved to the Chinese government, perhaps they will in the future cave to your local government too?
Or some insurance company too?
They're a business after all!
I'm playing devils advocate now. It may be securely stored today, but we cannot audit the system, and we cannot audit the updates to the system. If Apple wanted they could change this overnight without telling anyone.
When the data is in transit between devices, what encryption is being used? I mean I could speculate a manner in which it’s possible to restrict this between two devices and their respective secure enclaves, but is Apple doing that?
This would mean that when backed up in Apple’s servers l, they’d have to backup per device... maybe they do?
The white paper goes into some detail on the encryption and key exchange mechanisms. Basically devices exchange public keys so their private keys never have to (and physically can’t) leave the SEP.
Backups are different. Those are not encrypted with device keys because obviously you want to recover from loss of device and restore to a brand new one. But if you’re not comfortable with that, you can do local encrypted backups with your own password via iTunes. And as noted the most sensitive data like HealthKit is only included in encrypted backups. White paper also discusses a special escrow service for backing up your keychain, incidentally.
> White paper also discusses a special escrow service for backing up your keychain, incidentally.
My foggy understanding is that iCloud backups are encrypted with a key stored in iCloud Keychain, which is encrypted within the hardware security module escrow service they run, so after iOS 10 they can't actually decrypt your backup.
Edit: oh, I replied to you below as well. That video has the details but it's been awhile since I watched it.
It sounds like (although I'm not an expert) that it would still be impossible for them to encrypt files in higher data protection classes, since the iCloud backup keys are stored within iCloud Keychain, which is end-to-end encrypted.
Edit: and honestly if I'm misinterpreting that and it's an issue for a specific person, they should just use iTunes encrypted backups and not rely on iCloud.
They do all sorts of device key exchange, if you haven't watched the talk at Black Hat I'd highly recommend it: https://youtu.be/BLGFriOKz6U?t=6m55s (link goes to beginning of Secure Enclave content, and later on in the talk he discusses iCloud which uses the SEP keys)
iCloud backups cannot be decrypted by Apple. They use hardware security modules to encrypt that data and the keys are generated on-device and can't be read.
In particular a limited subset of data uses end-to-end encryption, none of which is super interesting:
These features and their data are transmitted and stored in iCloud using end-to-end encryption:
iCloud Keychain (Includes all of your saved accounts and passwords)
Payment information
Wi-Fi network information
Home data
Siri information
I probably could have been more tactful. However the substance of my comment is correct, and while I believe Apple do great things in security and promoting privacy rights, they don’t provide end-to-end backups for most data via iCloud.
They don’t claim to, but the same misinformation gets spread every time this topic comes up on HN. If you want end-to-end encrypted cloud based backups of photos and other data on iOS you presently need to use a third party app.
Could you point to more detail on that? I know they use HSM for keychain escrow security. But the security white paper just says backup set and key are stored in the iCloud “account”, not keychain.
I know they said they could have accessed that San Bernardino terrorist’s iCloud backup if only they had one. Not sure if they’ve change the security architecture since then.
> I know they said they could have accessed that San Bernardino terrorist’s iCloud backup if only they had one. Not sure if they’ve change the security architecture since then.
I actually think they have, the shooting was in 2015 and iOS 10 was released in 2016 and was first to have some of the features he talks about in the video.
Chill. You’re extrapolating incorrectly from that brief support document. It doesn’t say that Apple can read the other encrypted stuff. The security whitepaper notes that things like iCloud backups are encrypted with keys that are stuffed into the keychain, which is then transmitted end to end encrypted.
Would you care to link to the section of the security white paper that says that? There’s a small subset of data that is encrypted end-to-end. Your photos, notes, most and most other information is not include in that.
It’s pretty obvious really, they need to know the key for encrypted at rest data in order to be able to reset your password if you desire. They absolutely do don’t currently offset end-to-end encryption on the majority of data in iCloud backups.
Not obvious. p55: “changing the iCloud password won’t invalidate existing backups.“
But you’re right, the paper doesn’t say they do encrypted iCloud backups yet. The infrastructure is there to store encrypted backup keys in the keychain and escrow them so they’re recoverable yet Apple never has access. It’s probably the same foundation for iMessages in iCloud which they are just rolling out. That lets them store your very sensitive messages in the cloud and restore them to new devices and reset your password, all without them ever having access to your keys.
See the section on keychain escrow and recovery for more detail. It’s a game changer and makes storing data in adversarial clouds feasible.
Yes, they obviously have the infrastructure to do it. However, they don’t even optionally.
Part of the reason is that people sometimes forget their passwords and that would lock them out of their backups. So they want to allow email/other methods of resetting the password and giving access to data.
But it would be nice to have it as an option. It’s worrying though that even technical people seem to believe it is end-to-end encrypted. When it very obviously isn’t.
No, Apple doesn’t need to know your backup key to reset your password and retain backups. I explained why in my previous comment. If they’re not stuffing it in iCloud Keychain (yet) it’s not because the infrastructure can’t support it in principle. See: iCloud Keychain recovery. It’s probably just a matter of maturity; they still haven’t rolled out iMessages in iCloud which is a similar case.
In a simpler system yes. But they’ve developed a sophisticated system for syncing secrets called iCloud Keychain. Apple never knows your keychain. Once a new device joins your keychain circle it would in theory be able to sync backup keys and then restore, all without Apple ever knowing. They’re about to roll this out for iMessages which are also not readable by Apple. Backups are probably in the pipeline if they’re not doing it already.
Only if you have multiple devices... it would be nice if they supported this optionally (it would be nice if they supported any kind of end-to-end backup optionally).
"Health data can be stored in iCloud. When configured for iCloud storage, Health data is synced between devices and secured by encryption that protects the data both in transit and at rest. Health data is only included in encrypted iTunes Backups. It is not included in either unencrypted iTunes backups or iCloud Backup."
> Health data is only included in encrypted iTunes Backups. It is not included in either unencrypted iTunes backups or iCloud Backup.
Unless I’m misunderstanding you, your quote disagrees with your assertion. Health data is only included in encrypted iTunes backups. It is not included in unencrypted iTunes backups or in iCloud backups.
Of course, that’s just backups. It does say it can be configured to be stored and synced between devices via iCloud, where it is encrypted in transit and at rest. That appears to indicate it is stored pre-encrypted, and does not indicate there is any way to access it outside ones devices.
Right, but we’re talking about medical data. Which in lieu of further information I assume would be backed up in the same way as iCloud data. Unless there are statements to the contrary?
I don't know if you're naive or not aware of Chinese law. The government of China will block any service whose data they cannot read. Apple is FULLY compliant with Chinese law. They even bent over backwards to enable payments via WeChat, which they'd never allow outside China.
You’re throwing words like “naive” around but you don’t cite a shred of evidence. Apple’s encryption is at the device level, i.e. before it ever leaves the device. If they turned it off for China it would be easily observable and instantly reported everywhere.
By all account iMessage is one of the few end to end encrypted messaging systems that works in China. You are almost right about China’s general stance but, if you actually did some research, you’d see so far they have tolerated Apple.
iCloud users in China must agree to this: “understand and agree that Apple and G.C.B.D. will have access to all data that you store on this service, including the right to share, exchange and disclose all user data, including content, to and between each other under applicable law.”
There is Apple-accessible iCloud data, like anything accessible via iCloud.com. The “all” part of that is probably just over broad.
Like I said, technical people would be able to observe if Apple secretly changed their security architecture for China. Apple would also get sued if they didn’t disclose that your iMessages are no longer end to end encrypted when messaging someone in China. China just hasn’t cracked down on it because it’s not that popular.
Your mental gymnastics trying to mask the obvious regarding China and Apple is astounding. What about Apple makes you put so much faith in them, so as to taint the most logical explanation as "unlikely" especially whilst dealing with China?
China doesn't give two fucks about Apple or privacy. If you are in doubt, please travel there and experience the total blackout of services that refuse the share data with China. China DOESN'T need Apple, Apple needs China. And Apple needs to comply with their rules regardless of your delusions about Apple's piety. Be it health or selfies, the Chinese government shall have ALL data (on Chinese resents) accessible to them. Or Apple can get the fuck out of China - which Apple won't do because of it's fiduciary responsibilities colloquially called "greed". Welcome to reality
What device level do you speak of? How does one get medical records onto the device? Where does one backup the said data off the device, as is normal with all devices today.
I repeat - your argument is based on cherry picking Apple propaganda. It's like saying "emails stored on Apple devices are encrypted". Which they most certainly are, but if subject to Chinese law, even if Apple's email service were end-to-end encrypted, they'd have to provide encryption keys to the government. So all this "email is encrypted on the iPhone" is marketing fluff
Previous implementations have been crippled in ways that suggests that it could have been done on purpose. Limit the password to few characters and permit unlimited tries on the "secure" hardware. Data recovered in subseconds.
I suggest it was either done on purpose or they are incredibly incompetent. Which alternative do you believe to be true? Either way, why trust them?
Is the data transmitted from the phone in a format that Apple has the means (without grabbing further keys) to decrypt? Is there any reason, except commercial exploitation of the data, one would do that? So, ... I'd guess if the data never leaves your device unencrypted then Apple are clean, otherwise ...
> Is the data transmitted from the phone in a format that Apple has the means (without grabbing further keys) to decrypt?
I don't know for certain, but based on how Apple handles other sensitive user data I would hazard a guess of "no". Apple makes their money selling devices, not user data, so they tend to choose to implement solutions that protect user privacy first. (I am not claiming that this is always the case, nor am I claiming that they do not make any money from user data, but they do handle privacy very differently from the other major corporations.)
Chinese law. If you want to sell in China, hardware or software, the government needs to be able to read data. Period.
You can throw whatever fit, ethics, morals, yada yada, but China gives two full fucks for privacy, etc. Give data or get the fuck out of China. It applies to Chinese citizens/residents.
What are you talking about? Google bends over backwards to support China. I would hope that this comment is not informing you for the first time that the Great Firewall [1] exists and Google China [2] happily complies just like Apple, that is how law works.
Where are you getting this idea of "walked away with some dignity and authenticity left"?
Google China is outside the Great Firewall and is therefore both not subject to Chinese censorship rules and subject to getting blocked by the Great Firewall. That's the key distinction. Since Apple operates inside the Great Firewall, they have to do what the Chinese government asks.
How is what you're saying different from any other EMR company being compelled to hand over records?
People in the industry have seen this coming for a while. The convenience of having your own centralized medical record and using it wherever you go will be dramatically different from the model we have now.
Apple has no choice in the matter, PRC law is the law of the land. Like Apple can’t violate USA law in the USA, they can’t violate Chinese law in China either.
>The problem is not governments accessing this data.
Some people have a big problem with governments accessing this data. For example, the US government has used brute-force to access data and bully both citizens and non-citizens.
I can find more individualized cases if you'd like.
I, for one, do not trust the organization known to send people to offshore prisons to be tortured with no judicial overview to "do the right thing" regarding my data, especially when that organization gets penetrated by data breaches so often.
And, frankly speaking, we don't want them to refuse lawful orders to hand over data.
We might not have a well-functioning justice system, but the alternative--when corporations could feel empowered to ignore it because they themselves are big and powerful--is much, much, much worse.
> And, frankly speaking, we don't want them to refuse lawful orders to hand over data.
I actually do, but this would be quite unreasonable to ask. A practical middle-ground is making it so that any data they are forced to hand over is useless.
Probably talking about PRISM and the slide somewhere showing Apple participating. IIRC that was form 2008 or whereabouts when iPhone was a year old and had now secure enclave.
For some reason people assume nothing ever changes.
The law that allowed them to do this never got repealed, so you know it didn't get any better. Everything is changing... but it's not changing for the better, yet.
What dream? I think cloud providers should stay away from my data concerning health.
I trust my doctors and Belgium if something should happen, Apple should back off. If i want them to know my health, i'll install a heart monitor with bluetooth. Encrypted data is only one software update away from being unencrypted.
A doctor and a government are subject to intense public scrutiny; they have duties towards you they must respect. Also, there is no incentive for then to leak anything.
Apple on the other hand, is an organisation devoted to the sole purpose of making as much money as possible. Anything else is secondary. I think this is reason enough to be wary.
If a doctor is leaking data about their patients they will lose their license extremely fast, at least in Europe. Also, the doctor is one office with maybe 1000 patients. A cloud provider will store data for millions making it much more of a target to hack.
I'm not saying we are completely safe, there was a hospital here in Norway that used a foreign company to process health records and it was and still is a big scandal as data like that is is not allowed to leave the country.
My biggest regret today is that there’s not a 2nd device that I almost always have with me for doing 2FA. Watch may become that, or maybe there’s a future for jewelry.
I think Authy has a version of their app for the Apple Watch. Not sure how it works in practice, but you should be able to use it for 2FA on websites as you'd expect. Of course, it probably still depends on your phone, like most Apple Watch stuff seems to.
Speaking of authentication and watches, I like the approach Apple uses, where it stays unlocked until it stops sensing a pulse, and then requires the passcode again. So it's convenient as long as you're wearing it, but it locks up when it's taken off.
I use Authy, but the same exact app is running also on my phone (and it's needed to sync the accounts). This means that it's not really another device.
Also, totp can be phished in principle. I'd very much like a fido/u2f device.
The system decides when and what to encrypt and decrypt on it's own, how is any of that related to the user?
If the software can't be trusted it's not encryption, it's pointless. If you are going to pick a trust anchor, choose something that isn't also doing wireless updates, running third party apps, has a colorful interface that can trivially trick you into doing unintentional things..
Not quite. You actually have proper hardware security with Apple's implementation. Assuming no flaw is found in the silicon it doesn't mater what's going on on the CPU
But the android phones are from 5% of the price and up to about 85% without being locked to a particular network.
So you pay your money for an iPhone and get Pegasus malware anyway ... or get a far cheaper device and use reasonable, sensible, security practices (no 3rd party, don't view unexpected payloads, etc.) and get a similar level of probability of infection.
Yes, but that's the same in the Apple world. There seems no reason to believe mainstream apps are less vulnerable on Apple's or Google's app store. Nor that Firefox, say, is less likely to be exploited on one or the other.
Though granted the underlying OS might be more vulnerable once FF had been exploited. The homogeneity of Apple surely makes a greater target though, which I'd expect to balance it out.
Presumably you and the GP have done prior to the frugality claim - like people who don't just install any old shit get exploited in a financially more costly way on Android.
iPhone SE is the model for you. Top quality, small form, half price. Best value / £ on the market when it came out.
However: It’s dated now, almost two years, so keep an eye out for a potential successor. If they don’t release a successor, then they played their cards very well and roped tons of us into their system with a too-good-to-be-true model. There’s probably a name for this play in economy text books :p
If the hardware is done correctly, and used correctly. Previous Secure Enclave on iphones did not work even though Apple and its user said it was secure. Why trust them now?
My 90s PC ran Linux, which had the exact same sandboxing that iOS has, with a slightly different API. If you run each application with a different uid, you get the same result.
Two particularly exciting aspects of this announcement:
(1) Hospitals include more than one EHR vendor (both Epic and Cerner), which shows multi-vendor interoperability.
(2) Apple is using a leading healthcare standards organization (HL7)'s clinical data specification (FHIR, or Fast Healthcare Interoperability Resources), which is a huge win, and will hopefully increase adoption and usage of this open standard by provider organizations.
HL7 is such a monstrosity. Once you have used it you are forever sadder and that this became the default spec for everything in health is really disappointing.
Edit: for the uninitiated. Excuse the readable line breaks, this isn’t defined in the spec (or at least is done differently by all vendors). You won’t have to suffer long though as you’ll go blind reading the ||| and ^^ when debugging.
To be clear, HL7 is a not-for-profit organization which has created several sets of standards over its history (HL7-V1, V2, V3, etc)--those standards are what you are referring to above.
FHIR, which is what Apple is using, is its own standard, (created/managed through the HL7 organization) and is based on more modern representations of data (JSON, etc). (https://www.hl7.org/fhir/)
While I agree that HL7 is a "not-for-profit", it's important to remember that their membership is not composed of not-for-profit organizations and you must purchase that membership. While this may not be an out-of-the-ordinary way to organize a standards body, it hopefully highlights why the standard is so fractured and interoperability is such a problem: this is the preference of that membership.
I've had to work with the spec, specifically to integrate different products, and it was an ongoing battle with the vendors and their consultants at every step. It's uncharitable to say that they would deliberately mis-interpret what little specification was in place solely to make integration expensive, but that was my feeling. In fact, I believe that one purpose of the specification is to keep competition out of the field.
Looking around, I'm having trouble finding an EHR that implements both importing and exporting data in the FHIR format. Instead I'm seeing products that take the FHIR data and then (presumably) emit HL7 messages aimed at an organizations interface engine (i.e. Cloverleaf or something similar).[0] If none of the big EHR support it, then it will remain an expensive "custom" add-on that will be challenging (and expensive) to support and it will end up another dead initiative like the "Blue Button".[1] With every upgrade to systems in the organization, the FHIR translator app will need to be updated as well. Will it support every vendor? Likely not, and now you may also have to foot some portion of the bill to add support for that vendor.
My fear is that people will see FHIR and Apple and assume that some progress is being made. This is a battle we've been fighting for years and even now, people walk from one office to another with a CD or DVD of data in the hopes that it can be read.
FHIR is relatively new and still in draft form. It would be a bit unreasonable to expect vendors to put a huge amount of effort into supporting a standard that's still in rapid flux.
Most of the major EHR vendors do now support a significant subset of FHIR resources through read-only APIs. And several of them have publicly committed to start offering limited write APIs by the end of 2018. We have to be a little bit patient.
As for purchasing memberships, well HL7 needs some revenue to keep the lights on. A small company can purchase an annual membership for as little as $1450, and individuals can join for even less.
It is using JSON (or XML), but the underlying data model is largely carried over from V3 (or more specifically, the RIM). The problem with HL7 isn't the data format itself, but how information is encoded and the amount of variation that exists. The parent comment was a little misleading in posting a V2 message since that isn't what Apple is using, but as someone who works with HL7 on a regular basis V2 is actually more straightforward to work with a lot of the time.
FHIR is definitely a step in the right direction but it is plagued with the same issues as their other "standards" so I'm not holding my breath.
Very confusing. You say it uses JSON/XML (for data encoding) and also the "problem" is "how information is encoded". What is the encoding problem? And how could JSON/XML be the problem? These are fairly simple encoding formats and well understood.
Are you referring to the data model as the problem? How exactly?
The data model is a big part of the problem. There are lots of different ways to encode the same information within HL7. People refer to different "flavors" of HL7, different ones for different implementations (and implementations are not just vendor specific, but site specific — EHR software is very heavily customized for each health system). Add to that doctors and nurses entering information in their own ways within a given health system (since the software isn't very clear or usable), and the data that's getting transferred is a huge mess.
Beyond that, a lot of the most important information is encoded in free text fields, and so isn't directly analyzable. And even when information is mapped to codes from standard medical ontologies, there's no guarantee that when that information is transferred in HL7 formats it includes the code from the ontology.
It's not at all clear what the optimal way to structure medical information should be, so it's no surprise that there's a huge amount of variance out in the world. HL7 is quite old (v2 was made in 1989), and every new variant has to support the existing variants. EHRs were originally designed around billing and administrative workflows, so it's also not surprising that the data structures aren't great for analyzing data or treating patients.
Not the poster you were replying to, but I do healthcare data integration for my day job.
The problem is that HL7 is ostensibly a standardized interchange format, but there's enough ambiguity in the spec that literally every vendor implements things differently which leads to... my job existing.
Vendors implement the spec selectively. They may or may not support any given message trigger. They may have a different idea of what exactly constitutes something as basic as a patient account number and choose to send it in an unexpected field. Or send a piece of data you weren't expecting at all there. There may be a business case for capturing data that wasn't in the spec for a version of HL7 being used -- email addresses are common one today --
that lead to user-defined fields being added ad-hoc.
Honestly, working with HL7 v2 messages like posted above isn't really any substantially harder than working with CSVs. The real headache comes from actually integrating the underlying data.
Poster of the V2 message here. You describing the integration problem and that is the exact problem faced. As far as I understand it, isn't integration exactly what the format is for? It doesn’t do it well.
The standard will generally get you 80-90% of the way there.
There are a lot of factors that go into why the standard fails to be plug-and-play. The fact that v2 is essentially a glorified, somewhat standardized CSV instead of a prettier JSON has next to nothing to do with it.
troyastorino's sibling comment nails a lot of it. There's no standard model for the underlying data, which makes it incredibly difficult, if not impossible, to have a standard transmission format for the data. Literally every individual facility you'll look at is unique and will have their own registration workflows, code sets, etc.
The old V2 spec isn't what I'd call good, but it works. It's ugly to look at, but it's not difficult to work with, either.
The problems you're addressing, however, are far more fundamental to the industry itself and aren't going to be solved by an interchange format.
Maybe so, but I would argue a lot of the key information isn't that different for each type of medical event. (I'm leaving aside scheduling and insurance claims for now because I'm less familiar with things there but there are still probably some commonalities).
Each medical event should have:
- Patient it relates to
- Date it happened (possibly date it started and date it ended instead)
- Who did/prescribed/ordered it
- List of medical codes+coding system tuples that happened on that event
There's tons of other information of course, but these very basic things are universal and should always be in the same place (I refer to FHIR in this case, but format is somewhat irrelevant if the API is good). I understand they're not for historic reasons, and that some might complain because it doesn't exactly fit how they think about things, but a consistent API provides more value and I think will lead to better process down the line.
HL7 is moving along with FHIR, and I think it's a good start, I look forward to where it ends up.
>Maybe so, but I would argue a lot of the key information isn't that different for each type of medical event.
Well, I mean, that's pretty much the entire basis of the HL7 segment paradigm.
>- Patient it relates to
This is a much, much, much harder problem than you'd think.
Patients are going to have multiple identifiers attached to them and resolving them cleanly is literally an industry of its own within healthcare.
And that's precisely why it's a common problem during integrations - which identifier gets used how is generally a workflow and design decision made for a specific site-level implementation.
>- Date it happened (possibly date it started and date it ended instead)
>- Who did/prescribed/ordered it
These usually aren't sticking points for integration because they're the easy ones to get people to agree on.
>- List of medical codes+coding system tuples that happened on that event
These aren't really standardized at the industry level beyond ICD-10 diagnosis codes. Things like insurance provider codes, procedure codes, order codes, etc are individual to sites; even things like ethnicity and gender codes are variable by location.
I don't want it to sound like I'm down on FHIR or that I think HL7v2 is the greatest thing since sliced bread because I don't think either is the case.
The point I'm getting at is that there are huge problems with healthcare data interchange that just plain aren't going to be solved by a better interchange format.
That's inherent in the problem domain. The FHIR data model is distinct from the V3 RIM but clearly influenced by it. Health care has a high degree of irreducible complexity. If we oversimplify the model then it won't support important use cases and implementers will be forced to use proprietary extensions.
As a practical matter we can't rely on low-level standards to achieve real interoperability. Since there is often more than one way to model the same clinical information we also need high-level implementation guides with comprehensive examples to show everyone exactly what to do, along with automated conformance testing tools.
I work with FHIR extensively and find the standard to be decent but not great. Perhaps my biggest complaint is around naming strategies.
"What date did this event occur?", can be assertedDate or effectiveDateTime or performedDateTime or any number of things based on resources.
In the old versions it was even hard to know "What's the patient ID associated with this resource?", sometimes it was "patient" sometimes it was "subject". This has gotten better in STU3, and improvements have also been made to the way practitioners are identified as well.
I think there's a ton of irreducible complexity, but there are also common themes and common parts of medicine that should form the foundation of the API. It seems that instead of thinking, "What are the real commonalities here? Lets make them flexible enough to handle 90% of cases, but with a standard interface for extension." HL7 started from a current cumbersome standard and shoehorned it in.
I really am optimistic though, it's getting better all the time and FHIR is actually remarkably extensible to handle corner cases. I really hope it becomes the standard moving forward, especially as it smooths out the rough edges.
If you see a naming discrepancy then just go ahead and submit a tracker to fix it. None of the resources are normative yet and in my experience the work groups are quite willing to fix this kind of stuff as long as you provide sufficient justification. You might need to explain why the change is needed and ensure it doesn't get delayed. Don't sit back and expect someone else to identify and fix the problems; most implementers only work with a few specific resources so they might not even notice inconsistencies.
I’m not sure I agree with that. HL7 gets messages onto one system (eg the MRI) from the hospital info system (RIS). There is nothing billable in terms of insurers and while departments bill each other it’s all one system (public healthcare, New Zealand). I know we are small fry, but other places use HL7 in ways that have billing as a secondary concern too.
The system I currently use doesn’t bill with HL7 at all, it’s just to get identifying info onto the images and reports to referrers.
I've sat in on some conference calls for a standards org in healthcare. The reason these specifications are so shitty to implement became clear as day for me. There was not a single technical person on the call. To be honest the majority barely sounded computer literate.
Wow. I haven't worked with HL7 since ~2004 and I was hoping it had changed, but apparently not. With HIPAA everything starting moving to X12 formats which had smaller file sizes and were much easier for developers to work with.
I'd be curious to know why Apple went with HL7. Was it a limitation of the EHRs they're integrating with? A demand of the hospitals?
Everything uses HL7, every last bit of equipment that has patient details on it, and people are familiar with working with it. This will be why they do it I think. I don’t think it can change now as it’s so deeply entrenched.
We're certainly starting to see a gradual transition over to XML/JSON via FHIR, and I've even worked with a couple of vendors that are pushing RESTful web services as their preferred integration method, but agreed: there's absolutely massive inertia behind legacy HL7.
Implementation costs for a primary EMR are in the millions and most ancillary systems still cost hundreds of thousands of dollars to put in place. There's a lot of financial incentive for healthcare organizations to keep using what "works", even if it is ugly as hell.
This! If there is one thing to fix health data communications, its coming up with better spec than HL7. Nothing makes me more sad than dealing with HL7 messages.
I have worked in the field and I strongly disagree with this statement. The implication is that one can submit suggestions to the HL7 organization and hope to see improvement or changes in the spec. I would contend this is only the case for the larger vendors who are already established in the field, and quite happy with the current state of the (pretty much entirely non-interoperable) specification.
Well you can't just toss in a suggestion and hope that someone acts on it. Ideas by themselves are worthless. But anyone willing to be persistent and do the hard work of nailing down details can absolutely get their changes incorporated into the standards. I've done it several times, including when I worked for a very small vendor.
The various work groups aren't really controlled by vendors at all. Provider and payer organizations are also heavily represented.
I'm not sure what you mean by "readable line breaks". Segment terminators for HL7 V2.x messages are clearly defined in the standard and done the same way by all major vendors. The standard is also quite clear about how to represent visual line breaks inside formatted text reports.
HL7 V2.x messaging is a bit of a monstrosity since the most common ER7 encoding is based loosely on old EDI standards. There is also a standardized XML encoding for V2.x messages which is a little easier to parse, although it's poorly supported in the industry and the schema doesn't really follow XML best practices.
The HL7 standards body has developed many other standards including V3 and FHIR (which is effectively "V4", it just didn't get a new version number in the same series). Most vendors and provider organizations are now moving toward FHIR since it's based on modern open Internet standards and somewhat easier to implement.
Not the down voter but having recently battled different line break methods, I disagree about universal vendor support. My use case has been entirely limited to radiology - a very small subset.
> Apple is using a leading healthcare standards organization (HL7)'s clinical data specification
I'm very hesitant to use either the words "leading" or "standard" with respect to HL7. HL7 is an incredibly backwards and antiquated model. It's a disaster to try and work with or implement in any way.
And, to make matters worse, it's not even really a standard - at least not in the way web developers would use the word. You have a separate HL7/ADT feed for every combination of (hospital, vendor) because no two work exactly the same way.
To be clear, HL7 is a not-for-profit organization which has created several sets of standards over its history (HL7-V1, V2, V3, etc)--those standards are probably what you are referring to. HL7, as an organization, is very much a leader in this space.
FHIR, which is what Apple is using, is its own standard, (created/managed through the HL7 organization), and addresses most of your concerns (https://www.hl7.org/fhir/)
> To be clear, HL7 is a not-for-profit organization which has created several sets of standards over its history (HL7-V1, V2, V3, etc)--those standards are probably what you are referring to. HL7, as an organization, is very much a leader in this space.
I'm being sarcastic when I say HL7 isn't a leader. Obviously their psuedo-standards are widespread; they're just terrible.
I haven't dug much into FHIR because, when I last needed to implement any of this, literally nobody was actually using it. That said, based on everything else I've seen, I'm skeptical that it's actually a proper standard in the strict sense. Even the other message types that HL7 has produced are not properly specified, with ambiguous language that allows for multiple interpretations and "valid" (but incompatible) implementations.
It can't be 'properly specified' as that'd mean that there is a single interpretation of medical concepts across all users/customers. This has never been true and probably won't ever be.
There is lots of money in making HL7 systems talk to each other though. Getting dialects to actually communicate is quite easy to charge a lot for. However finding someone who will do it is considerably harder.
Yes. HL7 is sort of thing you can dip into a bit, and think, "Wow... whole rooms of contractors are racking up big bills dealing with this." For me, HL7 is the analog to chemistry's wonderful "Things I Won't Work With" blog.
apple is using a new standard from hl7 called FHIR which is bringing restful apis to healthcare. so its like the json you get from any other tech api. i have a startup (https://1up.health/dev/fhir) that uses it as the base of our healthcare api platform for app devs building products that need clinical data.
Given the centralization of the data in the Health app, I would like to see Apple make it easier to get Health data out of the iPhone for personal analysis.
The Export feature in the Health app currently exports all data as a large XML blob, which is not easy to load up into a spreadsheet. (for reference, I wrote a script to extract heart rate data from the XML and get it into a CSV: https://github.com/minimaxir/get-heart-rate-csv)
The workaround is to use a 3rd party app, which complicates privacy.
There are people working on decentralization of Health (Data) + AI like Synapse AI, Doc AI, Pandora, etc. State of Decentralized AI: https://imgur.com/mOWKrQE/
For my quick example, you'd have to change the key in the regex appropriately, and there may be other various metadata involved that has to be handled (i.e. whether the steps are from running or from walking). Again, there are 3rd party tools, but I do not want to use them.
The actual data filtering/aggregation/visualization is a different story, and beyond the scope of getting the data. (here's why I was getting the heart rate data in the first place: https://twitter.com/minimaxir/status/949306256874913792)
That link has some bizarre misconceptions about namespaces (just define the namespace URLs you’re interested in as constants, don’t depend on the particular short name/URL map you expect, as that guy does).
It also looks like it predates cElementTree, which has an identical API but is vastly faster.
But anyway, yes, iterparse will be much more reliable/flexible than a regular expression search of non-canonical XML data, and will likely be faster, too.
This is essentially what all "blockchain for healthcare" idealists are trying to advocate/accomplish. With buzzwords like "security" & "interoperability" ... Apple is really pushing for both here (though it would be centralized).
I think the absolute key is to win the users first, and force the industry to adopt a strategy that is best for users vs what is best for Hostpitals/EHRs/Health-Networks.
Interoperability is a beast of a problem to solve for healthcare, and it'll be interesting to see how far Apple is willing to push or disrupt (i.e. standardizing & forcing the adoption of their chosen data formats & integration)
I really do not know why a blockchain is necessary. If people have ownership over their own data, all that is really needed is a place to store it and some kind OAuth scheme to access and manage it. I mean, sure, smart contracts on a blockchain could do that, but so could hundreds of other architectures.
It's not a matter of what's possible but rather a matter of who has control and access to that data. Do you want a decentralized platform or Apple to protect your records. Fwiw I'm not advocating one way or the other.
Agreed -- I don't think blockchain introduces anything _entirely_ new to any type of application.
Blockchain in healthcare goes a lot further than user control/convenience though, and a "holy grail" success would mean complete interoperability across the industry in terms of security and data & knowledge sharing.
Also the whole "centralization" bit was already mentioned.
Apple Health already had the ability to view medical record documents, using the CDA standard. I think this is a huge step in the right direction for the Health app.
Here's a question for HN people: what do you use to manage your medical records on Android?
The last time I got medical records, it was a thick stack of papers (the images were on a CD at least). Another provider sent an "electronic" record, which was just a PDF of essentially the same stack of paper. This was way back in May 2017.
Why wouldn't you want to have a copy of all your medical records? Perhaps this isn't super useful if you've gone to the same doctor your entire life, but I've gone to multiple doctors (and I know I'll be going to more in my lifetime). It'll be nice to have the ability to pull up my full history if I needed to provide a new doctor with some (more accurate than memory) history.
For multiple reasons, but here's one that strikes close to home: not every person who you may wish to have access to information contained in those records will have it via the health care system.
E.g., I need a personal trainer to help me work around my back problems. It's useful to be able to answer his/her questions by referencing my records, instead of vague shrugging about some random disc.
Another e.g.: my aunt does a good job of sharing family medical records so that we know who in our past had conditions that may be relevant to our healthcare as well.
Manage a local copy. Every individual should be in possession and have a basic understanding of their medical records. Medical professionals are there to help you manage your health. As the manager, you need that information.
Not sure if you live in the US but my experience with the US healthcare system (I work adjacent to one of the top US research hospitals) is that there is a critical problem of patient identification between institutions. Because we have no national ID system, patient data is coded for individual institutions (with some limited exceptions). So, transporting your medical data between institutions is a headache that can result in lost information. Further, access to this information for your own knowledge, research or simple interest is quite limited if you don't have a healthcare provider using one of these established secure platforms Apple Health can pull from.
People are bad at managing themselves, especially when they are ill. It is a bad idea to expose patients to their health records. It will get lost, they will change things, they will fight with their doctor over what is put in the record, they'll want things clarified they don't understand putting undue burden on overworked doctors.
Health records need to be impartial and unbiased so future medical care can be given with the best possible information.
Patients just get a read-only copy of their records.
Also, providers don't use the patient as an intermediary when updating and exchanging medical records. That addresses most of your concerns.
- "they'll want things clarified they don't understand"
This is, by far and overwhelmingly, the reason it is a good idea to expose patients (and their defacto caregivers, AKA, their families) to their medical records. When it comes to preventative medicine and chronic conditions people have far more control over their health than the doctor does and the better they understand their health, the better they are able to do something positive about it.
The things that are in your medical record are technical and won't help you at all. "Patient's CD4+-T-Cell count reduce from 5^9/L to 5^6/L, advised increase Prolenaslezapam from 50mg to 75mg" (I'm making this up). Your doctor won't tell you this, instead they'll say "Your HIV is progressing and we're upping your dosage".
There's no benefit to reading the technical note, you'll just ask for the clarification... which the doctor already gave you. Or you're going to waste his time having him explain undergrad biology to you.
Think of it like this: Would you want your customers reading the comments you leave in your code? Probably not! They'll waste your time asking you about the comment you left saying "this could cause an error and bring the servers down". Or they completely misunderstand something and cancel the service. Or they'll complain that you left a swear word in. Etc. etc.
I'm reminded of a sad story about a kid, probably 10ish, who overdosed on prescription meds designed to help him not sleep so deeply (he had problems with bedwetting because his bladder wasn't noisy enough to wake him).
Failing to understand the purpose of the pills, he decided that if he just took all of them, his problem would go away.
Granted, adults (usually) have better judgment than a 10-year-old about things like that, but nonetheless patients almost inevitably are able to make better decisions when they understand why they're being asked to do things.
>they'll want things clarified they don't understand putting undue burden on overworked doctors.
People should be able to have things they don't understand about their body clarified. There's fewer things scarier than not understanding why your body isn't reacting the way you'd expect.
People can't be trusted to write their own records, but they can't not be allowed to see them. The consequences of that access have to be managed, for better or for worse.
Let's solve the issue of healthcare providers not playing nice with each other (will only communicate via fax, etc) before we worry about the very rare case of mentally ill patients falsifying records and such (which does happen, but not nearly on the scale of healthcare companies simply being difficult to wrangle.)
> Health records need to be impartial and unbiased
Sorry, but they're already neither. Medical records are also the same mechanism used to determine reimbursements, meaning the codes in them that represent diagnoses and treatments are subject to multiple incentive structures.
Care plans and diagnosis codes are very different things.
Just because a coder massages the specific codes in use doesn't mean the clinicians are altering care.
Honestly, there's a lot of new incentive structures on care givers and their institutions focused on so many things, like reducing readmissions (thereby reducing all forms of medical error in the process), or forming provider cohorts and using comprehensive comparison metrics between similar hospitals in similar areas and situations, to incentivize and reward those facilities which achieve the best care.
And, on the subject of the MR/EHR itself, of course most of it is unbiased! Do you think your lab results, prescriptions, vital signs, demographics are subject to bias? Your medical record isn't where a doctor leaves a long note about their opinion of you. It's where all that stuff above, and allergies, and outpatient care history, and inpatient history, and all kinds of factual unbiased things go.
You absolutely should own your records. In my view there should be a central location for all your records that is controlled by you. Then you should be able to give doctors access to them as needed. But the owner of your records is you, not the doctor, not the hospital.
If you are moving from one health care provider to their competitor, you will find it is difficult to get the data successfully (and entirely) moved from one organization to another. Typically you will need to personally gather the data from the one provider and physically move it to another. In some cases they may provide a CD, DVD or thumb drive but it's more likely you'll have piles of paper.
Having a copy of your medical record in a format that is easy to carry and, even more important, easy for your clinician to read will go a long way towards insuring your new doctor, etc. has enough information not to do you more harm.
Much confusion ensued when my pregnant wife and I arrived in the US. I translated the medical records and gave them to the obstetrician. She was quite worried and sure that I had left something out -- there were all these tests that are routine in France but in the US are only done when something goes wrong. Needless to say nothing was wrong.
> Most people do not want to manage their own health records
How do you know? This isn't a capability right now. I suspect that once people have their record and can plug it in wherever they want, they'll like having it.
I was previously the administrator of a "patient portal" that was connected to our health record system.
we had a hard time getting people interested in using it and signing up. and those who did sign up rarely used it after the first few weeks.
when talking to people, the primary reason seemed to be that they wanted to communicate with a person for most healthcare related needs b/c they had questions or wanted clarification/re-enforcement. They used the online portal so infrequently that they never felt confident they could quickly get what they needed accomplished.
The notable exception is parents managing the records of their children, which I don't think will be a feature of this v1 health records app.
its all about user experience though. i'm hopeful Apple can delivery something that is better than what is available and has come before.
i'm worried b/c I don't see it as a v1 and done feature. It will take consistent interaction and improvement as health record systems change and capabilities increase. hopefully apple is committed to it.
It seems like Apple's interest in health data is an important part of their unusual concern for user privacy. The less secure the phone, the more problems they'll have with something like HIPAA.
> It seems like Apple's interest in health data is an important part of their unusual concern for user privacy. The less secure the phone, the more problems they'll have with something like HIPAA.
Not really - I don't see a way in which any of Apple's statements or motions with regard to user privacy have any implications for HIPAA compliance.
HIPAA is a really arcane law, and it actually largely wouldn't even apply to the sorts of stuff being discussed here, because HIPAA doesn't cover anything that happens after the user receives the data. Broadly speaking: if it's encrypted in transit, once it reaches the phone, it doesn't matter if the phone is compromised or not; that wouldn't be a HIPAA violation either way.
It might matter if iCloud is breached (ie, their encryption is cracked).
But since HIPAA doesn’t apply to what patients do with their own data that is not as applicable. For example, if I add my medical record to Dropbox and it gets hacked, that isn’t a hipaa issue. But if my doctor puts my medical record in Dropbox and it gets hacked it is and either my doc or Dropbox have to handle the breach notification per hipaa.
Having experience with hospital IT working for an outside vendor before HIPAA had much impacted practice (though after it was adopted), yes, I think it's made them take it much more seriously. That's not to say it's good now, but if you hadn't experienced it you probably can't imagine how bad it used to be.
Yes--HIPAA provides a mechanism for fines to be levied against (most) healthcare organizations that suffer data breaches through the office of civil rights (OCR), with a public reporting of organizations that have been penalized.
> Yes--HIPAA provides a mechanism for fines to be levied against (most) healthcare organizations that suffer data breaches through the office of civil rights (OCR), with a public reporting of organizations that have been penalized.
Unfortunately, HIPAA is an incredibly rigid, incredibly broad law, and it's applied to a field in which security practices are incredibly inconsistent.
As a result, HIPAA violations are pretty commonplace, and the vast majority are never reported to HHS, let alone penalized.
the method they get data is patient mediated, so they are not beholden to hipaa laws. we use the same method at 1uphealth to bring clinical data from health system records to app developers and patients
This is great news if you or someone in your family has ever:
- Moved and had to come up with child vaccination records from another state (or multiple states) from 5+ years ago.
- Seen doctors across multiple health organizations who all want to run the same tests, or fill out a records request form that gets faxed and delays treatment by another month.
- Applied for disability or anything else that requires medical records and had to fax 10 different records request forms, wait a month or more, then pay printing fees for each.
I was really surprised by this. When I moved to the state I had to get immunization records for my kid’s school. My pediatrician was able to pull up some automatically, but it was missing some. She asked me about it, I told her that the kid got the shots didn’t know the exact day. The doc added that to the form that I gave to my school. I was shocked that there was no real data checks.
What’s even crazier is that I once had to travel on official business to some travel restricted regions that required a ton of vaccinations. My proof that was checked by immigration in lots of 1st World and 3rd world countries? A little yellow folded up piece of paper with checkboxes and initials from a doctor.
They currently accept a printout from Walgreens, so you'd probably be surprised what they would accept. But at the very least this is a great first step that will hopefully lead to a printout or some method of providing records that others will accept as valid.
It looks to be read-only at the moment, meaning you can't necessarily walk into one of those few health care systems with your iPhone and have the data sync with the EHR.
Syncing would be nice, but just being able to show that a test was already done and was negative means the doctor can move on to whatever is next instead of having to request that record and wait for it. I think there are already benefits like that, plus the potential for much more if syncing and printing of records can be added.
The "ceo" typo in the "apple-ceo-jeff-williams" fragment from your URL initially threw me off. For a moment I thought there had been a change of guard at the CEO level.
This is great that data are encrypted and solely accessible by user and sharing by user.
This does two things- puts patient in control of their health data as they are the only only able to pull together medical data from all their sources (try getting 5 hospitals to share data with each other) and it’s a sustainable business model since the device manages storage/backup/whatever.
There have been personal health records for a decade (remember Google Health) but they never made money and/or were oriented around research needs or clinical needs; not patient needs. So they shriveled up a bit because they lost money (eg, Google Health) or are hard to use (eg, HealthVault).
Excited for this. Like most, my Health Care Provider already has an app, well they use one of the standard ones that other providers use. It shows health records and all, but in a rather ugly interface even though it doest now support FaceID and some other latest tech.
Can't wait until that data will be in Apple Health which is more future proof (in case you leave your current health provider) and a far better UI experience.
I feel the correct solution to this problem is for legislation that forces hospitals to quickly, easily, and cheaply share patient information. If you go to one hospital and then go to another hospital up the street even though they probably both use epic they have to fax or mail records. Not for technical reasons but bureaucratic ones.
That legislation is in place. It just requires some leg work on the patient end (you have a right to ask for your entire medical record with a covered entity).
Sharing by default will never be a standard because it represents too many risks for data falling into the wrong hands.
You would be correct. The fix is to have the Department of Health and Human Services administer health records [1], and use Medicare funding as the stick to require its use.
[1] This requires public policy implementation, US Digital Service/18F levels of technical competency, along with ruthless transparency and governance.
But you would trust a single hospital (or hospital network) to run Epic securely (and all that entails from a security and risk management perspective)?
As someone affected by the OPM breach, I agree that it is bad. You can't paint the entire government with a broad brush though.
The entity with the most complete information about you is not the doctor with the EMR, it's the health insurance company that has every claim (i.e. drug prescription, hospital admission, doctor visit, specialist visit across all providers) with all your diagnosis/procedure codes on each claim.
After conquering the difficult feat of integrating LTE and GPS into the Apple Watch 3, the question is what's next? I personally love the iwatch3 for its ability to allow you to stay connected even when disconnected. (ie take a business call in the middle of an outdoor jog without your phone)
Nevertheless, I'm still not sure if there's anything else they can do that will be as groundbreaking as the watch3 is. Obviously, Apple feels there is a lot of potential for the watch and health, however.
IIRC, hospitals have been looking for something akin to encrypted "digital dogtags" which can be accessible by qualified medical personnel. Obviously a tricky proposition to both keep data secure while also accessible to those to whom this data should be accessible.
Perh their reputation for privacy combined with their market share can enable a viable solution to this dilemma.
And often lots of time and energy is wasted (on patients and doctors) onto restoring context. I can see that when they access your file on their computer. 5 minutes of catching up, with potential errors or mistakes.
If I can't add medical records manually myself, this is a useless feature. I'm seldom in the same country for very long, so get medical records from a motley collection of sources. I just want a single place to save all my records for easy access wherever I go.
Hopefully Apple entering the space will move things forward in terms of interoperability, but so far, this announcement doesn't really change the status quo. It seems like it's is coming out of Apple's participation in the Argonaut Project [1], which has been around for a few years and is (currently) the strongest vehicle for push FHIR and SMART on FHIR, but hasn't really seen wide participation.
They have 12 hospitals participating right now [2], which is in line with the ~10 systems that interoperability plays typically get on board. Apple has been moving on health records for a while, with their acquisition of Gliimpse [3] a couple years ago a clear indication, and I had hoped that Apple would have been able to get more systems participating before they made an announcement. 12 systems is a far cry from the 5,500 hospitals [4] and 230,000 practices [5] in the US.
In order to make medical records really useful for people, they needs to have all of their records. That means records from whatever system they've been seen at, and all of the information in those records. Every purely electronic approach to aggregating records that I've seen doesn't get doctors notes, procedure reports, pathology reports, radiology reports or medical imaging (x-rays, MRIs, CTs, etc). Sadly, it looks like Apple's attempt also won't address those issues.
Collecting medical records is an extremely hard problem. Technical integration is not only expensive and annoying (see many other comments about the shittiness of HL7, which FHIR is the latest, least-bad iteration of), but health systems don't have strong incentives to push interoperability. Health systems have way bigger IT problems facing them than aligning with interoperability standards (e.g., update the failing, 10-year-old software in the pediatric ICU), releasing records automatically could open them up to a lot ill-defined of legal risk (is a health system liable for what happens to information it releases to third parties?), and interoperability is kinda against business incentives (more interoperability => easier to lose patients). It doesn't look like Apple is taking a fundamentally different approach than Google Health did to any of these incentive problems (if we build, it they will come).
disclosure: I'm one of the founders of PicnicHealth (YC S14), and follow these things pretty closely. If you want to chat about the space, feel free to email me: troy{at}picnichealth{dot}com
> Does making the hardware HIPPA compliant give any special protections agains FBI requests unlock phone or other government regulations and requests?
Not in the least, and it's sort of a category error to say "make the hardware HIPAA-compliant".
Apple doesn't really have to do anything to make the hardware HIPAA-compliant. In fact, pretty much any phone that's on the market today could be used for accessing protected health information in full compliance with HIPAA. What happens at the software level is more relevant.
Just wait, my guess is that this is the beginning of all the blockchain nodes with every phone serving it’s part to process transactions and store data.
It’s probably something like in addition to your own record, you’ll store 10 other patients in an encrypted manner. And 10 other phones will store yours.
