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 profiles contained within the above documents may be available for testing at subsequent IHE Connectathons. The documents are available for download at https://www.ihe.net/resources/technical_frameworks. Comments on these and all IT Infrastructure documents are welcome at any time and can be submitted at ITI Public Comments.
I have given a tutorial on FHIR Security and Privacy at a couple of HL7 events, and some HL7 distance learning. These recordings are available on the HL7 Education on Demand site. It is not clear when I will be asked to give the tutorial again.
My slides are freely available on google sheets at this easy to type address http://bit.ly/FHIR-SecPriv. Each time I give the tutorial I update these master slides. So each time you go there you will see the latest set of slides. Some slides do have notes, and there are additional detail in slides that I don't cover during the tutorial.
I would prefer to give this tutorial in three parts, but typically only have two. If I could give it in three parts this would be the agenda
Part 1 - Basics
Security Principles
Privacy Principles
Basic Security and Privacy Considerations
Anonymous Read
Business Sensitive
Individual Sensitive
Patient Sensitive
Not Classified
HTTP[S] - TLS
Authentication & Authorization
SMART on FHIR
IUA
Mutual-Authenticated TLS
Access Denied Responses
Part 2 - FHIR capability
Provenance
Basic
Digital Signature
Audit Logging
Audit Reporting
Audit Purging
Consent - for Privacy
HEART
Attribute Based Access Control
Security Tags
Compartments / Clearance
Obligations
Break-Glass
De-Identification
Part 3 - Practical application
Multiple Organization Provider Directory
using relational linking
Multiple Organization Profile Directory
using security tags as compartments with clearance
I have been asked to moderate the afternoon Track 3 on Monday (1:00-2:30 pm Eastern Time)
Track 3: API Standards and Innovation
Advancing Trust of Third-Party Applications: Issues and software solutions
The 21st Century Cures Act Final Rule requires that Health IT Modules provide a standardized API for patient services, including the ability for patients to use third-party applications of their choice. This session will explore industry implications of direct-to-consumer health IT products, privacy and security policies and considerations for the future.
As a moderator I will be guiding the content and questions to the participants. So anyone that wants me to ask their question can feed their question to me via this blog article or email.
The panelists are made up of people who are very active in the API security space. I am very happy to have them be the focus of the topic.
ITI Tech has 5 projects happening and each have made progress in the past few weeks. I encourage participation, even if you are not a typical IHE participant. All of our projects are using GitHub, so let me know if you want to engage and have not yet gotten assigned to the proper GitHub teams. I need your GitHub username.
IHE use of IG Build tool (not exclusively ITI, but we do dominate active members)
* example of the SANER project using FSH/sushi authoring and Keith magic (NOTE this is an HL7 project, but Keith offers this layout as inspired by the IHE supplement layout) http://build.fhir.org/ig/HL7/fhir-saner/
* Note we are experimenting here with using Github page publication
* Main goal at this point is to promote this to get feedback on interest in developing this further
ATNA profile specific patterns using Gazelle
* There has not been much work, but the idea is to leverage the fact that Gazelle has and needs the ATNA Audit Message patterns to enable testing.
* Future (likely the above html publications) publications of supplements and technical framework will not include the ATNA audit message pattern table inline, but rather this pattern will be defined in Gazelle and that instance will be pointed to by the IHE specification.
I am a standards geek, and as such I am a strong advocate for standards developed and maintained by experts in their field. HL7 and IHE are where I focus my personal standards development. In the space of things that are special in Health IT.
I resist when projects are brought to IHE or HL7 that want a standard developed or a profile developed in a technology space that is foundational to Healthcare, but where the specialization for healthcare is not needed. The following are some pointers to "Standards" that healthcare should use as is. This is not to say that there could be no specialization for healthcare, but rather that the fundamentals of these standards need to be followed first before anything special for healthcare is ever needed.
This document describes best current security practice for OAuth 2.0.
It updates and extends the OAuth 2.0 Security Threat Model to
incorporate practical experiences gathered since OAuth 2.0 was
published and covers new threats relevant due to the broader
application of OAuth 2.0.
In the USA there is a project called Patient Unified Lookup System for Emergencies (PULSE). It is an exemplar of functionality that can quickly enable healthcare treatment use-cases that are within the purpose of a Health Information Exchange, yet are also dynamically deployed as necessary.
The video gives a good background that is important. I will let the video describe it.
Essentially it is a very thin web front-end that enables authorized users to gain READ-ONLY access to health information on patients for Treatment use only. It thus needs to
manage authorized sites using the access system. These sites need to be carefully managed to be quickly deployed, yet there needs to be confidence that when one site is deployed that it is authorized.
manage users at that site. where these users are often temporary workers that have migrated to the disaster area to help out. Thus the system needs to provision user accounts, while making sure that policy and procedures assure that the users are all legitimate users
track all users actions so that there is traceability and accountability
patient discovery mechanism
document discovery of list of documents
display of user selected document
Putting it together using Interoperability
When the system makes a request to the network for patient discovery (IHE-XCPD), document lookup (IHE-XCA), and retrieval of a document (IHE-XCA); the request must be recognized as coming from an authorized site and an authorized individual recognized at that site (IHE-XUA). This authorization confidence is what is the hardest part for a system like this. That is it is hard to express to ALL of the participants in a health network, especially a very large one like the USA nationwide network as a collaboration of thousands of participant organizations. Especially given that the PULSE is a temporary site created just yesterday.
The method should leverage the certificate management system that is used to manage trust within the network. The new site would be issued a new certificate within the Certificate Authority, and it would be given attributes that make it clear it is a Disaster provisioned site, and that it is authorized under a broader authority. These certificates naturally are trusted through the normal certificate authority chain.
This likely needs to be part of a regular testing of the network, where a short-term certificate gets provisioned and each participant is tested that it would respond. This test does not need to expose patient data, as a Patient Discovery of a test patient would return Zero-Results-Found if the trust was working, vs Authorization-Failure if that partner was not handling the certificates appropriately. This regular testing is necessary as failure demurring a disaster is unacceptable.
PurposeOfUse
Certificates are important for trust, but don't convey the intended purpose. It is possible to embed the purpose in the certificate, but there is a more dynamic mechanism already available in the IHE-XUA profile, which is a specification for how SAML would be used in a network of networks. There is a PurposeOfUse element that carries the purpose for which the request is being initiated for, and for which is promised to be the only use for which results will be used. Thus any data released is released only for the explicit purposeOfUse requested.
Treatment
Seems logical to me that these requests are clearly for the purposes of Treatment (TREAT). There would not be use of this kind of a system for Payment (HPAYMT) or Operations (HOPERAT); where as these would be typical of a normal organization requests of the network.
plus Disaster
But it seems that these requests should also include another PurposeOfUse value that indicates the specific urgency of the care setting. I recommend that the Disaster (DISASTER) PurpoeOfUse be added to the Treatment. In this way the custodian organization has better knowledge that it can use for Access Control purposes and for Audit Logging. For example with the addition of Disaster to Treatment, the organization could have special handling within their Privacy Policy that authorizes access for Disaster access. This would be important as the Disaster site could not have been recognized during normal times, so the patient could not have had the ability to explicitly permit or deny authorization. Thus this would be a recognized authorization implicitly.
UPDATED: I think Disaster PurposeOfUse could also be a signal that the retention of any data returned is only for the duration of the episode/encounter and no longer than the declared Disaster. If this is not folded into the PurposeOfUse of Disaster, then it needs to be addressed in the Disaster Site Certificate policy. Somehow retention is different, and as such needs to be expressed as different.
Write access
Today PULSE is just READ-ONLY, and that is likely all that is needed. However with COVID-19 there is a potential need for some results (Positive or Negative) to be published so that future treatment settings can be aware. This likely would be done today through a recognized normal healthcare treatment organization. That is to say that these Disaster settings are often (always?) associated with some formal treatment organization. So there is methods available today. It is not clear this needs to be changed. But it is a use-case that must be supported somehow.
I am impressed by @PeppPtPrivacy-Preserving Proximity Tracing for use in situations like #COVID19 -- Impressive #PbD Privacy by Design. Their detailed design document with Privacy Considerations, and Security Considerations is available here.
The use-case they are addressing is discovering who someone has been close to, when later that individual is found to be positive COVID-19 infected; while maintaining everyone's privacy. Their documentation shows good design thinking and transparency of risks, mitigation, and residual. It shows that when one includes Privacy-By-Design from the beginning of a project, that one can preserve privacy while creating a system that meets needs. There is further FAQ on issues Not only is this a good design of a system, it is excellent exemplar of a specification that includes Privacy Considerations and Security Considerations. These sections outline the persona of attackers, motivations of attackers, and methods these attackers might use. They then go into the design mechanisms that they have included to thwart these attacks. They do also include references to regulation/law that would be used against successful attackers. I like this inclusiveness of technical design and policy enforcement. Some concerns I did not see addressed, although these seem small. These are more operational issues than privacy risks:
They never express the storage usage on the mobile device. It seems that someone in a very populated area would harvest many EphID. So it is not clear how much storage space is needed. The nice part is that this is stored on the device. They do hint at this in a FAQ that asks about upload, where they express that some might need to upload 600MB daily, which tells me that I might need to store on my device 600MB * 14 day window = 8.5Gig. And this is with compression they outline. FAQ
They did not address the risk that a mobile device will have some backup (or storage space harvesting) that might expose the data to those beyond the individual using the mobile device. They seem to expect that everyone has perfect control over their own device, which many flashlight applications have proven is a fallacy.
They don't explain how the end-user is convinced that they have a distributed model of the solution and assured that there is not a centralized exposure. The security and privacy features they have put into place are hard to explain to a typical end-user. I think this is mitigated by the very nature that there is an application that must be installed for this to work. That application will be scrutinized by privacy and security professionals. And further if it is found to be not following the design, it can be revoked from the app-store.
They don't address well the case where an attacker has motivation to monitor one individual. In this case the attacker can grab EphID for a very short time, where it is known only the targeted individual is present. Then monitor positive individuals looking only at that one targeted individual. Likely a high-value individual, so that kind of an individual should be careful in using this kind of an app. Note that high-value might be overall high-value, such as a sports figure; or may be a local high-value individual, like an estranged spouse.
They indicate some location data would be recorded, but I couldn't find what that is. They only indicate that the EphID and gross time is captured. I think this is all that is needed, but it is not clear that is all they keep.
Their proximity detection is only for proximity of the two humans. It does not address when an infected individual leaves virus behind that is picked up much later. The virus can survive in the air for a period of time, and on surfaces much much longer. So there will be many false-negatives.
