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.
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.
Now that everyone has more time on their hands, with no commute to work and no social hour over coffee, I want to remind you all about opportunity to provide YOUR comments to Healthcare Standards Organizations like IHE.
I am going to focus on IHE because they have stuff to comment on right now. HL7 will be coming up soon.
What is a ballot?
A ballot is the term we use to indicate a specification that we want comments on, and also your comments submitted are your ballot.
Who can comment?
IHE - ANYONE can comment, you do not need to be a member.
HL7 - you need to be a member or signup as a one-time participant
Where do I find things that are available for pubic comment?
Both organizations have slightly different, yet very similar methods. Generally a comment can be as simple as an observation there is a typo, to a complaint about a given sentence, to questions about concepts, to directions to other relevant standards we might have missed. The more specific the better. Even better if you recommend how you would like the text to change, you might be right.
Each of these would be an individually recorded comment, within a set of comments. You would submit the set of comments. In this way we can review each comment, along with others comments on that same sentence or concept. Thus we get a feel for not just your concerns, but also the concerns of the community consensus.
Can I provide Positive comments?
YES. We love it when people point out when they agree with specific things too. This helps us weigh positive comments against others who provide negative comments.
IHE Ballot comment submission?
IHE has a web form that you submit your comments. Best case is you use a spreadsheet to record your comments, and submit the whole spreadsheet as one electronic submission. You can also submit then via an email.
As I covered in yesterdays article, PurposeOfUse is a critical prime vector that a data custodian will use to make access control decisions. Where PurposeOfUse is the intended reason the data is needed, and equally the restriction on how the data can be used. When I indicate a restriction, I mean that data released under a specific set of PurposeOfUse must not be used for other purposes beyond that which was clear during the access control decision that released it.
Public Health is a defined PurposeOfUse -- PUBHLTH -- To Perform one or more operations on information for conducting public health activities, such as reporting of notifiable conditions.
Thus when data are requested for Public Health needs, the PurposeOfUse would be PUBHLTH. When this PurposeOfUse is seen, then the access control decision checks that the request is from an authorized Public Health authority. There would be the typical checks that the requested data is within the scope of the Public Health purpose, etc.
Public Health authorized access often is an exception to any Privacy Consent restrictions the patient might place upon their data. Thus in this case the access control decision, when starting with Public Health PurposeOfUse does not need to check a Patient specific Consent, or a Patient specific restriction.
During a declared National Health Emergency, such as we have now with COVID-19, the rules might be adjusted to include more organizations? or more kinds of data that can be requested? or more organizations?
This PurposeOfUse would be used with a FHIR Bulk Data access where the data are being gathered for Public Health monitoring.
This PurposeOfUse value would also be attached to messages (e.g. HL7 ADT, or FHIR Message Bundle) that are PUSHED rather than queried for. The indication of -- PUBHLTH -- is an indication to the recipient that the data is restricted to Public Health use, and shall not be repurposed for other uses beyond Public Health.
