Disaster use of HIE is a PurposeOfUse

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

1. 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.
2. 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
3. track all users actions so that there is traceability and accountability
4. patient discovery mechanism
5. document discovery of list of documents 
6. 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.

Privacy-Preserving Proximity Tracing -- well done #PbD

I am impressed by @PeppPt Privacy-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:

1. 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
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

IHE Public Comments

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?

• IHE - https://www.ihe.net/resources/public_comment/
• HL7 - http://www.hl7.org/participate/onlineballoting.cfm?ref=nav

How do you 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.

See  https://www.ihe.net/ITI_Public_Comments/

Here are some ballots from IHE that are ready right now. If you read my article after today, this list might be out of date. So go to https://www.ihe.net/resources/public_comment/

• ITI Infrastructure
• Mobile Health Document Sharing (MHDS) 
• https://youtu.be/CX8q4hThmII
• My Blog article introduction
• Sharing Valuesets, Codes, and Maps (SVCM) 
• Survey of Network Interfaces Form 
• Video introduction to SNIF
• Patient Care Coordination
• International Patient Summary (IPS) 
• Video introduction to IPS
• Dynamic Care Team Management (DCTM) 
•  Assessment Curation and Data Collection (ACDC) 
• Patient Care Devices
•  Personal Health Device Observation Upload (POU) 
• Quality, Research and Public Health
• Structured Data Capture (SDC)
• Opioid Epidemic: Integrating Electronic Medical Records and Prescription Drug Monitoring Programs to Limit Abuse of Controlled Substances 
• Radiology
•  AI Results (AIR) 

Note: IHE YouTube Channel https://www.youtube.com/user/IHEIntl

Public Health is a PurposeOfUse -- PUBHLTH

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.

Custodian access control decision differences between Clinical and Individual

There is a fundamental difference between access requests for Personally Identifiable Health Data when a PHR requests access vs when a Clinical application or other EHR asks for access.  The difference is keyed off of the Purpose Of Use (PurposeOfUse) in the request. Let me explain.

Too often networks today are single purpose. That is that the HIE is designed for ONE purpose. For example a Health Information Exchange (HIE) that is designed for supporting Treatment. When a network is single purpose, then this simplifies the access control decision. However this does not scale to Purposes beyond Treatment. Thus one needs to carefully design the security tokens in ALL requests so that they declare what Purpose is driving the request for data. This has been built into the IHE security token profiles from the beginning:

• Cross-Enterprise User Assertion (XUA) - a profile on SAML for use with SOAP and other network infrastructures like XDS and XCA
• Internet User Authorization (IUA) - a profile on OAuth for use with http REST network infrastructures like #FHIR and MHD

It is also built into the HEART specification from the start.

It is being considered to be added to SMART-on-FHIR, but is not fundamental there. Today a custodian trusting SMART-on-FHIR must presume Purpose from the indirect means. I encourage participation so that this is informed by an active consensus.

Why is PurposeOfUse so important?

It is the first critical attribute because it sets the context for the request and how the data will be used. This vector is critical to business concerns, and also critical to Privacy (e.g. Consent and Authorizations). It is also critical to recording the audit log, that might inform an accounting of disclosures.

How is PurposeOfUse used?

From a Security/Privacy perspective, the fundamental

difference between an EHR and a PHR with regards to authorization is that a PHR is accessing a patient record onbehalf of that patient, with the data accessible on that PHR only by that patient. Yes the patient can then provide access to others, but it is a assignment action by that patient.  YES one must know that the PHR is trustworthy to be upholding the desires of the Patient. The Patient must be the one responsible for holding the PHR accoutable for upholding their desires. Thus when the Patient wants only themselves to have access, it is the PHR that holds access to only that Patient.

An access by a PHR onbehalf of the patient, would use a PurposeOfUse of PATRQT (Patient Requested). There are some sub-codes that can be used for family, power of attorney and support network; but these are unusual.  Thus a Patient Requested request is explict to the Patient. The Access Control decision can then focus on proving that the USER is the Patient. If the USER is not the Patient, then access Deny. If the USER is the patient, then further checks can be done (for example often lab results are held for some number of hours to allow a clinician to address 'shock' concerns).

vs Treatment

Where as an EHR or clinical application requesting access to data will incorporate the results into the EHR (or clinical application) where role-based-access-control will allow others to access it for Treatment, Payment, and Operations. Under the treatment purposeOfUse the hope is that it is constrained to legitimate relationship (care Team) with appropriate 'safety' exceptions, etc. The reason is that once data has been used by a practicing clinician within an organization, then that data is part of the legal medical record of that organization. That organization has obligations they must uphold around medical records retention and health safety. 

Thus when a Treatment PurposeOfUse is asserted, the access control decision knows that the result is not going to be limited to the USER making the request, it is a request on behalf of the ORGANIZATION, and the retention expectation would be for the life of the medical record retention at that organization and the future access controlled by that organization policies. Thus a access control decision to release for Treatment (which should explicitly include Payment and Operations; but often these are implied), must be made based on the ORGANIZATION requesting, not the USER. 

The USER, ORGANIZATION, PurposeOfUse, etc... MUST be recorded in audit logs, as the request was triggering by a specific user for a specific purpose. 

These are NOT bright lines, they should be more bright than they are. But this is how I get to an understanding that an authorized Treatment PurposeOfUse is onBehalf of the organization requesting; where a Patient Request is onBehalf of THAT patient, not the PHR agent. Yes the PHR agent does need to be trusted, but that trust should be in the hands of the Patient, not in the hands of the custodian making the access control decision to release data. 

Note Research and PublicHealth PurposeOfUse are closer to EHR than they are PHR; but I expect them to be project specific within that broad purposeOfUse. Thus my overall statement that PurpseOfUse is critical vector in any request for data from a custodian.

When the custodian is a research data lake, or a PHR, or etc... the same rules apply, that PurposeOfUse is the primary access control vector.

PurposeOfUse is more important than data-link authentication?

No, not really; but that is handled usually automatically at a much lower level. So I presume you didn't get to any access control decision without passing link or message authentication.

GDPR requires PurposeOfUse declaration

GDPR is very clear that one must declare what purpose is being asked for, and that data released for a given purpose can not be repurposed.

PurposeOfUse is core principle of Privacy

I base these on the Privacy Principles

PurposeOfUse is not enough.

Many other vectors are important. I am just pointing out that PurposeOfUse is the FIRST vector, the primary vector. See Sensitive Health Topics, putting the patient at the center of an HIE, deep article on Controlled HIE, and all other Privacy topics.

My Mother

I lost my mother this week.

She lived a long and productive life. She is survived by my father. Both the ripe old age of 92, having been together from the age of 15.  A Lutheran and Catholic getting married back in the 40s. My brother, three sisters, and I are all very close. Yet we are also spread from east to west coast and many locations between; including a foreign exchange brother in Switzerland.

My mother was the inspiration for my technology, science, and healthcare views and goals. I was told that while in High-School she worked in the chemistry department, and after graduating, worked as a Lab tech in healthcare. She would tell of counting white blood cells, and other lab tasks.

As computers appeared, during my lifetime, she was always talking about them. So I worked hard to buy my own first computer, a Commodore 64 when they were first introduced to the market.  She always encouraged my technology interests.  She was active early and continually on the internet, with a desktop computer.  Using many services, email, and skype. Often doing video conference with her grand-children.

Equally she encouraged me to always have a scientific mind, always question why something is the way it is, to always build upon the advancement of others that came before me.

All of these very open perspectives while being a devoted Catholic. Helping me understand that these different perspectives do not necessarily need to conflict.  I am so glad I grew up in a very open community, understanding church, and welcoming family. Far more could be said about this, but I think I am leaving the scope of my blog, and getting teary-eyed. 

HIMSS 2020

I made the mistake of not listening to good advice to NOT Watch the Movie "Contagion".  I am scheduled to go to HIMSS next week, and a wedding later this month. The Movie has some very obvious over-dramatized aspects, like the virus morphs on the timescale of days. But the Movie has so many points that are right-on, and specifically right-on in alignment with COVID-19. The in-real-life daily TV news actually over-dramatizes COVID-19 more.

I am not really more fearful, I already had a rational level of concern. I had changed my behavior as I have just finished 5 weeks on-the-road including Sydney. I am not feeling confident that I am immune. Each day is another opportunity to get sick, with all sorts of illnesses.

I am currently still planning on going to HIMSS. My biggest concern right now is that the HIMSS attendance will be next to zero, that the only people that will be there to talk to are other vendors or people demonstrating or speaking. That will make HIMSS less helpful than not having the event. I am not advocating for canceling, just hoping that people put on their big-boy-pants and come to HIMSS anyway. DON'T COME IF YOU ARE SICK!!!

I will be there, and have three speaking slots:

Promoting Safe Health Information Exchange Through Granular Privacy Protections

8:30am - 9:30am Wednesday, March 11
Session ID: 100
Orlando - Orange County Convention Center W207C

Description: Standards such as DS4P and C2S allow for granular tagging of sensitive data elements to support patient privacy preferences while promoting interoperability but have not been widely adopted and they do not address many common clinical pain points for providers and patients. A developing workgroup of multidisciplinary experts is building on work started by the DS4P/C2S standards in order to produce recommendations for future standards development and a consensus-driven implementation guide to facilitate industry-wide adoption. We have defined two use cases to frame relevant issues from various stakeholder perspectives. We seek input from relevant stakeholders as we identify ongoing leaders for this work and identify discrete deliverables and next steps for this project. Join us to advance the conversation with a broad stakeholder group so patients and families can benefit from accurate exchange of information with confidence that their wishes regarding data privacy are respected.

Learning Objectives

• Discuss current standards designed to promote the safe exchange of health data by allowing patients granular control over their data
• Recognize common clinical use cases not addressed by current granular data tagging standards
• Identify implementation challenges and opportunities for consensus-driven guidance from the industry

IHE USA and ONC's Cooperative Agreement to Advance Real-World Interoperability

4:00pm - 5:00pm Thursday, March 12
Session ID: 309
Orlando - Orange County Convention Center
W330A

Description IHE USA was awarded a 5 year cooperative agreement with the Office of the National Coordinator in September of 2019. The purpose of the agreement is to help accelerate the development of new and updated IHE profiles and associated real world testing that support advancing FHIR. Learn more from experts from IHE and ONC as they discuss the collaboration activities with ONC, new and upcoming IHE profiles that support FHIR, how these collaboration efforts will advance interoperability, accelerate the maturity of FHIR, and drive adoption throughout the industry. Session attendees will also learn how and where they can participate in ongoing efforts.

Learning Objectives

• Identify the key suite of IHE profiles that support emerging regulatory requirements and the use of FHIR
• Explain how IHE Connectathons support real world interoperability testing and adoption of standards and implementation guides
• Recognize and share important feedback and lessons learned by the standards community through profiling exercises and real world testing
• Outline how IHE and ONC will be working together in a cooperative agreement to advance the regulatory agenda

The Untethered PHR: The Journey Beyond Your Provider Organization

1:30pm - 2:30pm Thursday, March 12
Session ID: ISED22
Orlando - Orange County Convention Center
Hall E - Booth 8300 - Education Theater

Description In this session, learn how FHIR® and standards based on IHE on FHIR® profiles support bi-directional information exchange in veteran owned and controlled Personal Health Records (PHR) and comprehensive care management across multiple care providers.

Learning Objectives

• Understand how FHIR can be used to continually synchronize information with the Veterans Health Administration (VHA) bi-directionally.
• Demonstrate how organizations can engage providers using FHIR and FHIR-based apps.
• Recognize how information exchange impacts care delivery beyond the VHA, inclusive of all providers using FHIR.
• Define over a dozen different foundational profiles by IHE that support FHIR in the real world.