As Tom Jones has pointed out on Linked In, the idea of having digitally signed health records transferred to a smart phone is a major step forward. To me the point of having validated records is this:
The records (FHIR resources) have not been changed since the data entry into the EHR "in flight" over the network in a MITM attack to the Apple iPhone using Smart on FHIR design concepts.
That validity is verified like TLS (transport layer security) by Apple's digital certificates (but they don't really know about the validity of the data being transported), it is the transport endpoint validity of the FHIR Proxy that is verified, AFAIK.
Apple is ok with this since they have a business relationship with the healthcare provider and the EHR vendor ahead of time. So if it came from the real Epic Proxy server, then the data is assumed to be accurate based on what the Healthcare Provider entered.
Or to put it somewhat differently, accurate enough to meet the risk management requirements of avoiding an "in flight attack" or MITM to change the data which in turn arrives in Apple Health.
We don't want hackers altering our healthcare data over the network. So that is a win. Previously FHIR transferred data into Apple Health, but it was not validated. The connection was over TLS so the server identity was validated, but there was no claim that the data was valid, which accomplished via a digital signature.
From Apple Health, now on the phone, the data continues signed, (and thus unchanged) and is deposited in the patient's Apple Wallet with name, birthdate and a Jason Web token based QR code. There are currently discussions between the secure health card developers and the EU DGC developers to create interoperability.
That code can be scanned by a verifier. It is thus a verified health record that can be used as a verified credential wherever proof of vaccination is required.
This saved a lot of work at mass vaccination sites that could deposit the immunization record directly to the Apple Wallet instead of filling out paper cards. However when this was first implemented the data was not signed. Now with IOS15 it can be digitally signed.
Only in this case it comes from the EHR or a state Immunization Registry, (IIS) using FHIR. For those of us with paper CDC cards, a photograph can be uploaded to a patient portal with the data and then the EHR updated using any means within the HIPAA system to verify the data.
There are penalties for faking data relative to vaccine records but I am not aware of any HIPAA regulations that govern the accuracy of data once it is released to the patient and being managed by themself on their device for subsequent commercial and public health use. Note this exchange of data is governed by the Apple privacy policy and not some app's privacy policy. What an app developer does with your health data is an issue in itself, as any potential secondary use of the data by the verifier, so along the way there have been design requirements to limit the use of the data. The EU has declared an intention not to create a database of the vaccinated and unvaccinated that could be exploited.
So this is a new thing, transforming the data from paper to digital, (unless it is already in electronic form) putting it into an electronic health record, (defined already by HHS) storing it in a state IIS with access by a patient, digitally signing the data for integrity at a secure gateway, and then putting it in a smartphone wallet and then selectively exposing the card as a QR code to a verifier.
It is somewhat similar to "group consensus" regarding the validity of data on a block chain that may be entirely decentralized that also ends up in a wallet, except the participants are creating the signatures are regulated under HIPAA, compelled to release medical data to the patient, and there is a public health requirement that the immunization resource is accurate, and stays accurate from tampering.
Criminals have evaded these controls by bribing medical support people who have access to update the IIS, and issuing fake CDC cards with valid vaccine lot numbers.
While there have been some cases of fraud where fake CDC cards have been created and medical records employees entered fake vaccination records into state IIS registries, this is a different part of the supply chain and would definitely be prosecuted under HIPAA and HHS Office of Civil Rights since fake medical records (and related billing fraud) have a long history of abuse, especially in regards to CMS.
In fact that's why electronic signing of medical documents was proposed starting with durable medical goods like powered wheelchairs, but in general medical fraud is a huge financial problem and prosecuted by the DOJ. Medical billing and coding is complex to say the least.
In this case there are quite a few examples of fake CDC paper cards being printed in China and sold along with fake vaccination records. So considering the number of vaccinations taking place, and people who have smartphones, an accurate digital record that has signed validity has value.
The exact format, and how resistant it is to manipulation is the issue, but a card in a digital wallet works well since we are likely to have our smart phone anywhere we might need to prove vaccination status. And part of the puzzle is how it relates to digital identity. Some approaches prove a vaccination has taken place, but not the person who got the vaccination. Separating out these two data points is done to avoid tracking or a bread crumb trail of where the vaccination status was presented.
Individual records are not permanently signed in XML as I have proposed based on work with CMS, which would be a more difficult task of signing specific records, and still allowing them to be changed as necessary.
This is the difference between signing an entire document, or individual fields within a document and in order to do this the XML must be canonicalized. XML digital signatures are standardized by W3C and ETSI and known as XADES and have different flavors.
Pursuant to Adrian Gropper's design considerations how has the FHIR community fared in terms of hits and misses using this approach?
What about Good Health Pass? The Smart Card format came from the Vaccine Credential Initiative and in general follows the FHIR specification, and related legislation for access very closely, but does not necessarily align with other emergent efforts like Self Sovereign Identity Decentralized Identity, W3C validated credentials, and Linux Public Health. Nor does it map to the design for the EU Green Digital Certificate, which also uses encryption to create a different barcode coming from a health network that is tied back to individual countries who have national patient identifiers and their own IIS. There is no equivalent national IIS in the U.S. or a national patient identifier. While the DGC gets the data from a national IIS, it uses an opaque identifier to create uniqueness instead of the actual ID in order to prevent tracking and meet GDPR requirements.
One can look at the work of David Chadwick, who wrote the book on the x.500 Directory (which Wikipedia contrary to fact claims never existed...which is very odd since I managed it in the U.S. sometime after Marshall Rose in the PSINet White Pages Project) that deconstructs what is required to make a verified credential that meets the W3C document. In particular I like how he leverages FIDO2 which is a really good way to interact with web sites, but requires generally one purchase a Yubikey to make the process simple. I use a Yubikey and it's the highest level of authentication you can use with Google, etc. and it should get rid of socially engineered account phishing for the most part. Aside from the cost, 35-50$ it is extremely easy to use.
In my last and recent third vaccination I did not bring my CDC card, I filled out all the details online, got my jab, and downloaded the results as a PDF. The PDF was inaccurate in the injection site, a chirality error. Or in plain English they got the wrong arm. My healthcare provider fixed this error. I will ask the Pharmacy why the error happened and talk to their head of security whom I have worked with in the past. Was it a simple data entry glitch or a more serious IOC. I don't know, but the patient in this case fixed the error before it ever became a problem. That's really the point of looking at your own records, you don't want someone taking out the wrong kidney for example. Inaccurate, or invalid medical data is a common source of medical mistakes. One of my early motivations to debug medical errors was watching my wife go into shock while in the ER and require 3-4 units of blood due to a test processing glitch on a weekend. One could blame that on bad triage in the ER, but a proper supply chain on the test results not available in the 1980s would have gotten her to the ER way before it got that far because the bleeding was time sensitive.
What was interesting to me was that while the results were available as a PDF I was not able to import the data via FHIR. Other immunizations were available via FHIR.
This is data available for other business units of the same Pharmacy.
The first pharmacy where I got my two shot jab doesn't even have a way to download it, it goes right to a company that has their own covid-19 app, and if you want to use that app, the privacy policy says they own it in perpetuity.
Surprise, you didn't want to wait in line at a concert, use the app, and now they own your vaccination details! They make you consent and acknowledge you read the policy. And chances are, like others who also agreed to the privacy policy, it will end up like the famous episode of South Park with the human centipad.
This is independent of vaccination records, but vaccination records are now a current use case.
As a result there are many different ways to digitally represent this data, and different privacy policies that apply to those apps. Some apps want you to sign over all use of the data just to transfer the data from here to there. You don't need to do this and you should read the privacy notice. But you will not. And you will lie and say you did, just to use the app. This is normal.
Smart on FHIR is part of 21st Century Cures Act, and sort of a mushroom compared to the hyphae of the entangled set of medical records that exist worldwide. Patient Privacy Rights tracks this.
A lot of money is made in the aggregate transfer of medical records.
Medical professionals 10 years ago were blocking access to medical records, that is now prohibited, the issue is now how to preserve privacy when those records are released and not part of the HIPAA business layer which papers over security issues on a business layer rather than a math layer (say the difficulty of factoring primes in Public Key Encryption) regarding the confidentiality of records. This directly affects encryption.
HIPAA primarily relates to business associates and covered entities, but like the privacy policy no one in a hospital has actually read it except for the Privacy Officer. I once had my provider fail to provide requested digital information for "security reasons" which they finally admitted was simply a NDA on releasing data from the EHR vendor. This flat out lying and attempt to intimidate users is now criminal. Before it simply killed people when they failed to get the right information, because adherence to the doctor's treatment plan is incredibly important to prevent hospital re admission.
Sec. 4003
- Defines interoperability as HIT technology that: (a) enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user, (b) allows for the complete access, exchange, and use of all electronically accessible health information for authorized use under applicable state and federal laws and (c) does not constitute information blocking.
The flows of medical data are enormous, and largely out of control from the individual end user who clearly does not understand HIPAA, much less the relationship between HIPAA and network encryption!
How then to apply best apply security and thus understand risk?
Even with this obvious privacy breach, one can live a healthier life being aware of the data that reflects your current medical condition. This is situational awareness.
It's not just how many steps you have taken from a wellness perspective, (which is good data) but all other data which might require medical intervention that your primary care physician coordinates for you with various specialists. In general, things that would have killed you previously, like co-morbidities are treatable with the right interventions. Left untreated, such as in the current pandemic where wards are overflowing with unvaccinated covid patients, there is a much smaller chance of good outcomes for the non covid infected that need normal access.
FHIR lets you communicate with your Electronic Health Record maintained by your provider, so it is a good thing.
Literally one can get a blood panel lab lying in a hospital bed and see the results on your smartphone minutes after it was put in the EHR. You will know before any one else reads it.
Say for example you had internal GI bleeding after surgery and had some blood transfusions, you know what your hemoglobin was before surgery, and now it is much lower. What needs to be done to stop that bleed?
At that point you want a plan. There is going to be an awful lot of data that your care team will be analyzing before you are discharged.
In particular, before the vaccines were readily available, going to a rehab facility might have been questionable versus going home and getting a home care nurse. These are all decisions with a certain amount of risk during Covid-19, and especially different variants and age of the patient.
Needless to say there are some real penalties in countries like France for using fake health credentials. Some people have been fined at Canadian airports for fake paper CDC cards, but the digital versions are still quite new.
Some fake digital credentials will pass an inspector for the European Digital Green Certificate.
And just as likely be caught if someone is stupid enough to try and use one posted to the Internet. Because valid identity does matter even it the vaccination data is hidden behind a zero knowledge proof. Scanner says vaccination data is good, green check mark. Name is Adolph Hitler born in 1931, think it is fake? In Africa I read that 80% of the Yellow Fever cards are fake.
The immunization record has its own very specific history since the paper International Certificate used since air travel began, the FHIR immunization resource is a distinct use case but also the same as other medical records in that FHIR can be used to transfer the data and is largely secure, with some exceptions.
How can patient control of data be made actionable?
Putting medical data under patient control lines up with patient centricity and in the larger goal of actionable data directly under consumer/patient control which stems from Patient Privacy Rights and Adrian Gropper specifically. since that was published in May, it's interesting to take stock and see how we are doing so far because the design has tradeoffs. We should have a good idea how identity and consent work when this data is networked. We may need additional data to keep up with variants.
The idea of SMART on FHIR before having FHIR SMART card was to have an iPhone like application.
Except we have skipped that step presently with IOS 15 to practically have the concept (and thus privacy) built right into the IOS.
Digitally signed (and thus validated in terms of origin from a FHIR SSL proxy) health records that are patient usable in a simple way are a sea change in the Health Information Technology field.
My approach, which is different to sign the individual XML using ETSI standards has yet to be adopted. It's a much more granular approach and can express privacy restrictions on subsequent use of the data which can be linked back to privacy rights. It does not necessarily divorce identity from the vaccination record like the DGC which uses an opaque identifier. It more so says, here is validated data, this is me, here's a way to validate it and I require you to treat it according to policy. There is no attempt to achieve a Zero knowledge proof that says "fully vaccinated" or not.
Or reference to a rules engine to make decisions. Some approaches like Evernym do use this approach, and like the red/green don't reveal the actual data just the status work flow.
This flows back to 1990's concepts of identity versus anonymity, except in many cases, (Ever "Nym"), or say IBM's Excelsior covid pass, the app does not attempt to establish or verify identity. This is a philosophical design difference.
Linking that data is done externally, so one presents an anonymized health records (yes I have been vaccinated) according to a policy rules engine, but I still need to show external ID like a drivers license to prove I own that record on my Smart Phone.
So far the only time I have had to prove in Philly that I was vaccinated to eat breakfast inside, I showed the Apple Immunization Record from my digital wallet and no ID. (Actually I showed a screen grab of the record since I went back a version in the IOS and it made it disappear from the wallet, but it was still in Apple Health when I reverted back to the developer beta, and I just added it back in).
Will this work in NY without the Excelsior App? It will work in Los Angeles since they are Apple compatible.
I explain how this XML signing could have worked at Pahisp.org but in all practicality we have a lot of different apps, a stab at defining credential standards with Good Health Pass, which has some excellent requirements, and a now a practical application of a minimized FHIR immunization resource imported as Jason Web Token and barcode into Apple Health, and Apple Wallet.
CBOR versus JWT
That works very smoothly. It is however currently incompatible with 591 million European Digital Certificates that are generated by the European Health Network from Country Level Immunization Registries, "Tous Anti Covid" for example done by France which uses CBOR instead or JWT.
Each country has their own app. States in the US have apps, but there is no Federal certificate app. C=US could potentially resolve this interoperability problem but the EU allocated money to fix this and the U.S. government did not. So if you live in California you can use the FHIR Smart Card to create a wallet entry in Apple.
The difference is that Apple in IOS 15 integrates this into Apple Health, which is FHIR based and homes back to a list of approved healthcare providers.
Any HIPAA based messaging system can load an Immunization record onto Apple's wallet. This was done very early with LA county mass vaccination sites.
To contrast when I got interested in HIT networking in discussions that date back many years. I remember going to a conference for developers of "Connect" where a woman spoke about keeping records from different doctors in different systems in paper files in boxes in the back of a Volvo for her husband to avoid unnecessary testing and to keep various doctors informed without duplication. At that point we were only talking about a gateway between systems. Now we are talking about portals and phones that can publish records directly to a doctor. That's a lot of progress.
I intend to write a Medium article on a practical way to use a FHIR smart immunization record using Apple, it's very simple to scan the barcode in an Epic Patient Portal and import into an Apple Wallet. The FHIR Smart Card is not compatible with the European Digital Green Certificate. I have the Tous Anti Covid Apple App, and since the FHIR barcode is made as a Jason Web Token (and valid) the TAC will not scan it since it expects a record in CBOR signed by the French Health system. It probably would scan one of the fake entries currently existing on the Internet.
I mentioned in a meeting with Kaliya (identity woman) of Linux Public Health that I felt a lack of digitally signed health records on smartphones was a significant drawback to moving forward and this has now been addressed. It would appear with DGC that the signatures are not entirely bullet proof. I suspect they are ok with the JWT, but I don't think anyone has seriously tried to hack one.
In this case Apple addressed it using their own smartphone built in apps, namely Apple Health, which uses FHIR, and a selected list of providers. The list of approved providers is the "business layer" that holds it together, so there are prerequisites. It is a very specific way of applying standards, and obviously Linux Public Health and Good Health Pass have an ecosystem POV that does not require Apple, and a specific health care provider. FHIR itself is HL7 based, and thus agnostic, but the developer discussions took place in the FHIR discussion boards, and the security concerns are being currently addressed. Of course consumers have no idea regarding the scope of these discussions that are largely ongoing.
Once you get into the finer details on how you sign health records and the mode of transmitting the records, then standards as well as consumer behavior come into play. Of course there has been a lot of press recently regarding the white hat pen testing of FHIR API used by aggregators, and related insecurities exposing millions of patient records. Not the FHIR API itself, but as John Moerkhe has noted and Hl7 has announced, specifically the aggregators that pull down medication lists, etc in bulk.
I am still looking into that, I read the excellent FHIR API hacking report, and the Burpsuite Pen Test examples and will post what I learned.
No comments:
Post a Comment