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.