Discussions of Interoperability Exchange, Privacy, and Security in Healthcare by John Moehrke - CyberPrivacy. Topics: Health Information Exchange, Document Exchange XDS/XCA/MHD, mHealth, Meaningful Use, Direct, Patient Identity, Provider Directories, FHIR, Consent, Access Control, Audit Control, Accounting of Disclosures, Identity, Authorization, Authentication, Encryption, Digital Signatures, Transport/Media Security, De-Identification, Pseudonymization, Anonymization, and AI Transparency.
The report explicitly notes that no vulnerabilities were found or are documented in the EHR FHIR implementations themselves.
Nevertheless, lots of vulnerabilities were found. All of them are very basic house-keeping stuff well covered in the OWASP top ten risks.
Media Hype
Many media outlets did not get the facts right at all. Or even the impressions
Don’t trust the media, read the report
Basic failure to secure
Resource-Server not enforcing scopes in the OAuth token
Change the URL by the attacker (change the Patient id parameter)
Given a read-only token, able to change data (change a medication of another patient)
Client/Server architecture where all data is sent to the Client
A Patient Engagement App… the client was being used by a Patient on the Patients computer
Resource-Server not validating tokens
Intercept a legitimate client app request, extract out the OAuth token, put that token into a request from your hacking client - so enforce timeouts and refresh cycles
Clients with hardcoded API keys in the app
Not hard for a hacker to decompile your app and find keys
Hack yourself before someone else does it for you
Your API or App will be attacked, better that you prepare
Look to cybersecurity experts - this is both a skill and an attitude
Just updated the FHIR core spec Security and Privacy Module with a simple message, yellow highlight for the new text:
6.0.3 Security
FHIR is focused on the data access methods and encoding leveraging existing Security solutions. Security in FHIR needs to focus on the set of considerations required to ensure that data can be discovered, accessed, or altered only in accordance with expectations and policies. Implementation should leverage existing security standards and implementations to ensure that:
All communications can be encrypted to prevent unauthorized access.
No information leaks when errors occur
No active script content can be injected into narrative resources
Full audit trails can be constructed and used to detect anomalous access patterns
For general security considerations and principles, see Security. Please leverage mature Security Frameworks covering device security, cloud security, big-data security, service-to-service security, etc. See NIST Mobile Device Security and OWASP . These security frameworks include prioritized lists of most important concerns.
Recent evidence indicates lack of implementer attention to addressing common security vulnerabilities emphasized by OWASP top 10 API. Reviewing the OWASP Top Tenand OWASP mobile top 10 and ensuring those vulnerabilities are mitigated is important for good security.
13. Security / Privacy Event Reporting - Consider legal obligations and ethical obligations to provide a means for Security and/or Privacy Event Reporting such as security vulnerability, or breach.
--------------------------------- Revised to add these notes -----------------------------
Not on the FHIR standard, because it is a bit too prescriptive for HL7. These are the highest takeaways from the past month:
Bad API security
Take initiative, hack your own API before someone else does.
Resource-Server MUST enforce authorization tickets, don't just trust that a valid ticket is authorizing the request being made --
OWASP -API5:2019 Broken Function Level Authorization
The PIXm and PMIR implementation guides are intending on solving two very different models of managing Patient Identity. There is no expectation that a community would deploy both models.
PMIR model is one where a community wants to cooperate on a master Patient identity for each patient, a "golden" patient. This model has each authoritative party in the community cooperatively keeping the single Patient identity for a patient up-to-date. When a patient is seen one of the locations in the community, the master Patient identity is pulled from the PMIR Registry. If there is anything that needs to be updated, then that system will send the update back to the PMIR Registry. Thus there is only one Patient identity (demographics, addresses, phone numbers, national numbers, etc). This cooperation is what PMIR is all about.
There are additional features in PMIR that enable those that rely on this master Patient instance to be notified of changes. This is another use of the feed. This feed does enable the data custodians to be notified of important changes like when two master identifiers were determined to actually be about the same patient and thus have been merged. In this case the data custodian is expected properly update their data to represent the merge.
PIXm
PIXm model is one where a community wants to cooperate on Cross-References between each community members instance of the Patient identity as they know it. Where a cross-reference is simply a list of Patient.id and Patient.identifier (that is a patient identity such as MRN). The cross-reference is derived at using the other elements in the Patient resource, but a cross-reference does not expose on a query interface these other elements in the Patient resource. The PIXm query is just a set of identifiers (id and identifier) that are cross-referenced.
Each time a community participant updates their local instance of the Patient identity, they do feed those updates to the PIXm Manager. The Manager looks at the details with the ONLY output that the PIXm Manager updates the cross-references that it would return in the future when a PIXm client asks for the cross-references. It is very likely that the PIXm Manager does remember the demographics, addresses, phone numbers, national numbers, etc... but there is no effort to harmonize these at the element level.
PMIR uses PIXm
PMIR does include the PIXm Query transaction. This is useful when a client in the PMIR environment for a very few cases:
1. When the client does not want the whole Patient, just the .id so that it can record that value. There are plenty of client use-cases where it is not important to have access to the full, and sometimes sensitive, elements in the Patient resource. For example a weight scale wanting to record a new body-weight observation, where the scale knows the PMIR Registry and knows that the weight scale GUID is recorded as a Patient.identifier. Thus this device can do a PIXm Query given the scale GUID and get the Patient .id value. It can put that value into the Observation.subject element.
2. When the client does not want the whole Patient, just knows the Patient .id and wants a local MRN value. Not as clear why this client does not want to be exposed to the Patient Demographics, but it is possible.
PIXm and PMIR feed are not compatible
So the above should make it clear that PIXm and PMIR are solving different community models, and that those models would not exist in the same community. It is possible that a PMIR community would want to be a community participating in a broader PIXm community. Thus the PMIR Registry would participate as a PIXm Patient Identity Source.
The elephant in the room is... WHY did PIXm and PMIR feed choose totally different technical approaches at the FHIR interaction? If you didn't notice this, let me explain.
PMIR uses a "history" Bundle for the Feed.
PIXm uses more basic RESTful Create/Update/Delete (mostly)
Neither model is great. It is very possible that in the spring we update PMIR to more closely align with PIXm. I say "more closely" because the "expected actions" of the PMIR Registry are very different than the those of the PIXm cross-reference Manager. But the communication on the wire might be possible to be 'closer'...
Trial-Implementation
All this said... these implementation guides are both in "Trial-Implementation" state. This is the state used when IHE wants implementers to try it out, and give feedback to improve the future. So, please try them out, and give us feedback. Would prefer you join the ITI-Technical committee, but would also take input on the Public-Comment forum or GitHub for PIXm. I would also welcome comments on this blog article.
My father passed away this week, joining my mother. His health has been fading since his love of 70 years passed. He passed peacefully with his favorite nurse at his side, in the middle of the night.
During my life he was a Wisconsin State Trooper. He joined on a dare from his older brother who had joined in 1956, the next year my father joined the 6th recruit Class, badge #287. He retired after 28 years. There were plenty of stories of my father as a Trooper. Most of what I remember is that he had friends in every little city, truck-stop, gas-station, etc. I never caught the skill of making friends that he had.
I learned from my father (and mother) respect for others. I know that police do not have a good reputation today, and I suspect there were bad apples back then too. But I am confident of the stories I was taught regarding "perspective". I was taught to not judge someone by the first impression, to try very hard to look at their situation from their perspective. It is when you see their perspective you realize they are fighting trying times. This perspective exercise is what enables me to be comfortable with people that are "not like me", people who make life choices that I myself can't understand, people who are down on their luck and likely would benefit greatly from the smallest of help. Perspective is key, try to walk a mile in their shoes before you judge.
I learned from my father work-ethic. He would work hard when doing a job, with appropriate breaks. But he would also reserve recreation time. And of course sleep. He enjoyed odd-jobs, such as gathering up used tires to take them to the "re-tread" factory. We would fill the back of the pickup truck, nicely organized tires, three rows high. Learning how to get the rain water out of the tire without getting wet. I am sure this odd-job was never worth the income.
When I heard of his passing, I was relieved for him. I will miss the bi-weekly visits I had with him. I went for a walk, turned on classical music (my mothers favorite) and listened for sour-notes and clinkers (my father always would). Ended up sitting in a local church prayer garden, alone with the sunset.
Patient Identifier Cross-reference for Mobile (PIXm) -
Rev. 3.0.0. This revision was created using the Implementation Guide publisher. This is an update of PIXm that was previously published in PDF form. This new publication is published in HTML form with a full set of conformance resources and examples. New functionality has been added to support a patient identity feed to inform the Patient Identity Manager of changes to patient identities.
Patient Demographics Query for Mobile (PDQm) - Rev. 2.3.0. This revision was created using the Implementation Guide publisher. This is an update of PDQm that was previously published in PDF form. This new publication is published in HTML form with a full set of conformance resources and examples. No new features were added.
Mobile Access to Health Documents (MHD) - Rev. 4.0.2. This revision updated the publication to use the new Implementation Guide template. No new functionality was added.
These new publications are a part of the IHE family of Implementation Guide Profiles, and can be found at https://profiles.ihe.net
IHE is dedicated to the task of use-case driven Implementation Guide authoring, publication, maintenance, and testing. There is a long list of IHE Profiles (a form of Implementation Guide) supporting Healthcare IT workflows within and across the Healthcare space.
IHE Connectathon
These updated Implementation Guides will be available for formal product Interoperability testing at the upcoming IHE Connectathons https://www.ihe.net/participate/connectathon.
IHE ITI Tech met last week and had a very productive meeting. It seems we are getting the hang of virtual meetings. I will say that they are still about 50% as productive as a face-to-face. There are times at which we are more productive, but there are times when the virtualness gets in the way. This can be due to the lack of non-verbal queues (oh, you really didn't understand what I said), or inability to stand up and draw a picture on a whiteboard, or because everyone is multi-tasking.
Finished this meeting: (will take a week or two to be actually published on https://profiles.ihe.net )
mCSD Whitepaper
PIXm in IG format with Feed transaction - for Trial Implementation
PDQm in IG format - for Trial Implementation
Continuing Work Items:
Quality improvements to the HTML publication of the Technical Framework publications
Create Implementation Guide Profile ATNA auditEvent patterns for generic FHIR RESTful transactions with pattern informing IHE profile further specializing task-144
Convert Metadata Handbook to html publication without technical changes task-169
Convert MHDS to html publication without technical changes (not an IG yet) task-166
Alissa Knight did some invited and funded cyberSecurity research and found some good and some bad. No-one should be surprised by that conclusion. The point we should take from this research is that
EHRs are doing a good job of securing their FHIR implementations
FHIR is good and worthy
There is room for improvement in some implementations
There are included recommended improvements.
Some have take a very negative view of the research, most of this negativity is unfounded and driven by the fact that Alissa is excellent at marketing and drama. She has excellent presentation skills, excellent writing skills, excellent hacking skills, and excellent artwork.
This research was funded by a vendor that provides security frontend for APIs, so certainly there should be some consideration here. I, however, have good reason to believe that this funding did not influence the research. Alissa has a couple of decades of proving she knows what she is doing. This is not just fake research complaining about products that didn't use the vendors solution. Yes there is one mention that a product that did use that vendor solution was not found vulnerable, yes the vendor got mention at the bottom of the report for funding it.
This was not an attempt to bring down FHIR, but rather to challenge us all to be better. This report says nothing negative about the FHIR standard, it was focused on implementations.
There is some bad news, some implementations were specifically disgustingly bad at securing the data, and they had lots of data (aggregators). These services had signed up to be part of this research. They were informed of the problems. The report was expressing the trend, not the specific details. Alissa addressed this during the YouTube below, and also on twitter later.
Alissa hosted a Ask Me Anything on live YouTube, the recording here
Deeper dive
The report stands alone, and I have tried to come up with better ways to say what it says, but I just can't. The things that Alissa found were very remedial cyber security issues. Editing URLs in the browser to try to get at obvious other information. Using legitimate security tokens for things it was not intended to do. ... Alissa has so much deeper skills that she simply never needed to rely on. She goes into all of these details about as detailed as is reasonable without naming products.
Page 16 was critical for me. I literally was stunned. Not an exaggeration. I knew that there would likely be mistakes, hence why above I said we all should not be surprised she found issues. It was clear there would be issues found. But the class of issues found are just unexplainable. All of the issues failed to implement even the FIRST section on the FHIR Security page.
Data Aggregators were the worst offenders in my view. I know they provide a useful service, but they do it in ways that are not transparent, and they clearly don't take their responsibility seriously. They have been around for decades, so likely these same bad security implementations were just as bad on their previous proprietary "secret" APIs. The use of FHIR just makes them more obviously bad.
The last bullet on page 16 was the worse, quote:
With one patient engagement app,
the API endpoint sent me all the
patient and clinician records in its
database, indicating it was using
the mobile app to filter out just my
record.
NO WAY!!??? yup, that happened
mic drop
Conclusion:
I need to bring this back to positives... FHIR is good, the EHRs are good, many apps and services are good... but some are really NOT.
FHIR is a building block. It has so much to give to us humans (and animals). It will enable many things while it transitions from a "Standard for Trial Use" to something that is used to build CarePlans, Patient Engagement, Emergency Medicine, Disaster Management, Public Health, Artificial Intelligent clinical decision support aids, world wide COVID-19 tracking, and COVID-19 vaccine credentials... helping patients stay healthy rather than get unhealthy in the first place ...
FHIR is built upon http RESTful concepts, Document concepts, and messaging. These platforms have security and privacy layers available to be used. Healthcare does not need to invent security, we just need to implement it properly. Mostly apply the security layer to the interactions following good policies. Have bad policy, is bad. Have bad implementations, is bad. Have no security, is bad.
All systems that have access to health data need to be designed from the beginning with Privacy Principles which include Security and Security which is about (protecting risks to Confidentiality, Integrity, and Availability). Failing at "Access Control" makes me wonder about all the other opportunities to have forgotten Privacy and Security in the design.
Now is a good time to be reminded. We are not too far gone, we can do the right thing.
