Wednesday, December 16, 2020

Actual Consent is more important than more standards for Consent

I interact with many Patient Advocates, Privacy Advocates, and individual Patients that are frustrated at the state of Privacy Consent today. I am too, but potentially in a different way.  

Interoperable Consent Standards

My main focus is on enabling Health Information to flow given proper Security and Privacy. Thus one of my focuses is on the interop standards that enable Privacy Consent to function properly. Enabling data to flow when it should, and blocking data from flowing when it should not. This involves simple consents like Allow or Deny. This involves a patient not yet having made a choice (default rules). This involves a patient changing their mind. This involves a patient explicitly authorizing a given kind of access by a given kind of user... etc

These Consent needs are very itemizable. I have been involved (sometimes lead) the efforts to define an Interoperable Standard for these use-cases in IHE for Document Sharing Exchanges (BPPC, APPC, XUA), and in CDA (CDA Consent), and in FHIR (FHIR Consent). The application of security vocabulary as request context (purposeOfUse), response obligations (do not re-disclose), and data tags (confidential and sensitive). The creation of a Consent Service using User Managed Access functionality of OAuth (HEART).

I have been engaged by some of the nationwide exchanges to customize these for their needs, which turn out to look much like the IHE solutions. They mostly look for a reasonable subset of full capability of these standards that minimally meet their needs. This minimal view is important as building a trust domain requires that you get everyone within that domain to all equally implement the same thing. Thus a minimal subset that hits the realistic need (not theory) is more likely to get implemented fully.

Reality is that Consent is Local

Most of these situations, the consent is a local thing. That is to say that a custodial organization obtains consent, manages consent, and enforces consent with no visibility to the exchange beyond the enforcement of releasing documents or not. Thus the majority of situations have no need for an “Interoperable” consent, as they need only achieve it functionally. Thus most trust-frameworks make it clear that data released is released for the given context (purposeOfUse) and then falls under the custodial rules of the recipient.

The dominant Consent failure is also Local

This is where the biggest failures around Privacy Consent happen. They are NOT offered, or too few choices are offered, or too many exceptions to the Patient desire are embedded. Thus the patient data flows in cases that the Patient does not want it to flow. The patient data does NOT flow when the patient does want it to flow. And the Patient often has no visibility into when it did flow, or when it was denied to flow (traceability). These failures are local functionality (policy). Fixing these failures will not be aided by more Interop standards on the topic. Fixing these failures is only driven by Patient demand, Government backing of that demand, and Businesses having an interest in satisfying the patient, and/or their government. In the absence of this interest, Businesses will do what optimizes the Business bottom line... which is data-blocking to keep Patients from leaving, data-analytics on the data for benefit of the Business, etc. 

But Interoperable Consents are needed

I am not happy with this state of Consent fact. I am comfortable with it, but I see so much more that could be done beyond what is happening today.   The vast majority of use-cases today are “Treatment” purpose of use… a very narrow and well defined domain with simple trust framework needs.

A demonstration of this Consent for Treatment has been done at HIMSS multiple times, and reality is… no one cared to watch it. I say no one, but we all realize that is just a statement of percentage of people that care vs total HIMSS population. Likely hundreds of people care, and 20% of them showed up. The audience is just so small that it is not worth the energy needed to setup the presentation. This is why I blog, and also why my blog gets so few visitors. The math is just not very big.

Non-heterogeneous PurposeOfUse networks

There is an emerging force in HealthIT approaching, the Payer community that also want and need access to the data. The very data that we have enabled in the exchanges so far. This would be a "Payment" purpose of use.  But this does not really stress the minimal implementation much at all, as the PurposeOfUse mechanism is something that was kept in the minimal set. And consent is still local when it comes to billing requests. Most healthcare, especially in the USA, get a consent that is effectively on Treatment, Payment, and normal hospital operations (maintenance).

There are some Government use-cases for population health that have used the exchanges. These are beyond Treatment, Payment, and Normal hospital operations. But are also a specific defined purpose of use. 

The more important force is that the Patient wants to interact with these nationwide exchanges. This means a PurposeOfUse of "Patient. The Patient might choose to request their data move in ways not yet defined.

If we had a more comprehensive consent system, might that enable data to flow more freely and more broadly than today? Yes, but... Most of these consent rules could still be local. What is important for non-heterogeneous networks is a method of identifying the purpose(s) for which the data are requested, and for which the data are released. This is baked into the standards, but everyone must use these consistently and accurately.

Just in time Consent

The most interesting Interoperable Consent that I have come across is the Just-in-time Consent, other wise known as "Point of Care Consent". This is a setting where the patient has not pre-arranged a Consent, thus initial requests for data are denied. But one where the two (requesting and responding) have a trust-framework such that the responding organization trusts the requesting organization to get a Consent from the Patient, provide proof of that consent, and then the responding organization will release the data for the consented purpose. This Consent is mostly for Treatment, I have not seen it for other. This Consent tends to be a blanket PERMIT, no quilting of exceptions or stipulations. Thus this consent tends to be a simple binary "Interoperability" need. But it could be more complex. It could include the same features as any Consent. And THAT is when the Consent needs to be more than a binary, when it needs to have these conditions, clauses, expiration, etc all in a structured and coded form. 

This is baked into the IHE-XUA (SAML), and IHE-IUA (OAuth) profiles. What is needed is a policy based trust-framework, a policy based vocabulary. and traceability for the evidence and terms of the consent. Care Quality has set these up. The vocabulary and evidence could use simple (BPPC), or comprehensive (APPC), or FHIR Consents. 

And Interoperable Consents will happen

The standards organizations (IHE, HL7, ISO, etc) have done as much as they can at this point. They are not done, but the next steps for these standards organizations is not in the core standards space. The problem is in implementation guides and market demand.

Here is my best-case plan… I want to see the SAMHSA defined  "Consent to Share" Implementation Guide, come back to HL7 to be balloted, published, and maintained. I see this happening next year. I do NOT see this being driven by security workgroup or CBCP. I see this being driven by Patient Empowerment workgroup with security and CBCP as interested parties (not co-sponsors). I think this has the best chance to succeed. 

Do I think that security couldn’t make it happen? No. But if security (or CBCP) did the project, no one outside of our workgroups would care. A specification that is ignored is not useful.

Why next year, and not now? Because Patient Empowerment workgroup is deep in two other projects at this time. Both of which have a high interest and strong engagement. PLUS these have gotten the attention of Argonaut, and thus the EHR vendors.  I want to see these succeed (so don’t overload them with yet another project). And once they succeed, consent will take off with the momentum.

Conclusion

The most important point is that consent is mostly a local thing, that results in data being withheld to an external request or allowed. There are very few use-cases where a consent must be anything more than that. Fewer than that where that consent must be in an interoperable format. And fewer than that where there is a trust-framework to make an interoperable consent work. And fewer where the recipient has different custodial rules than the original custodian.  Yes we design things like Consent Resource and Consent Service to these needs. But we must recognize that they are not actually compelling.

See my other articles on Consent

Thursday, December 3, 2020

IHE releases IUA, HIE-Whitepaper, and html published Technical Framework

Big day for me, and the IHE team. I am so pleased at the way the IHE ITI workgroup membership, and IHE support personal, worked on all of this. I would say this is the biggest impacting release that IHE has done since XDS. This is bittersweet as we recently lost the father of XDS, Bill 

Today IHE releases three very important products:
  1. An update of IUA, the profile of OAuth that IHE has defined. This is an alternative to SMART-on-FHIR, and not intended to be conflicting. Each cover unique spaces with some overlap.

  2. An update to the HIE-Whitepaper, bringing in the newly build FHIR based profiles. Profiles like MHD, MHDS, mXDE, QEDm, PMIR, SVCM, mCSD, ATNA, and IUA.

  3. Brand new publication method for the ITI Technical Framework using html. This is just the final-text, does not include trial-implementation supplements, although they are included in the publication framework.
These three publications are all using the html publication framework, and they cross-link into the technical framework. see https://profiles.ihe.net/. This is the new home for html published works from IHE.

I will be writing more articles pointing out specific things of each of these publications. coming soon, right here, and possibly elsewhere...

IHE IT Infrastructure Technical Framework Documents Published.
Is this email not displaying correctly?
View it in your browser.

Important IHE IT Infrastructure Technical Publication News:

The IHE IT Infrastructure (ITI) Domain has been working towards the goal of publishing some ITI documents in HTML versus the current PDF format. Their efforts have produced the following:
  • An updated public comment version of the Internet User Authorization (IUA) supplement 
  • An updated public comment version of the Enabling Document Sharing Health Information Exchange Using IHE Profiles white paper
  • An HTML version of the complete IHE IT Infrastructure Technical Framework
Please see below for further details about these publications.
 

IHE IT Infrastructure Technical Framework Supplement Published for Public Comment

The ITI Technical Committee has published the following updated supplement for public comment from December 2, 2020 through January 15, 2021:

  • Internet User Authorization (IUA) - Rev. 2.0
Note: This revision of the IUA supplement, published as HTML, updates the IUA profile originally authored in 2013. This new version aligns IUA with the latest OAuth specifications and adds some new deployment options. A summary of changes is noted in the README on the GitHb repository.

This document is available at http://profiles.ihe.net/ITI/. Comments submitted by January 15, 2021 will be considered by the ITI Technical Committee in developing the Trial Implementation version of the supplement. Comments can be submitted via traditional methods at ITI Public Comments or by creating a GitHub Issue.
 

IHE IT Infrastructure White Paper Published for Public Comment

The ITI Technical Committee has published the following updated white paper for public comment from December 2, 2020 through January 15, 2021:
  • Enabling Document Sharing Health Information Exchange Using IHE Profiles - Rev. 2.0
Note: This revision of the HIE white paper, published as HTML, has been updated to include advancements in Document Sharing Health Information Exchange support, including the use of FHIR® infrastructure, and support for consuming FHIR® Resources.

This document is available at http://profiles.ihe.net/ITI/. Comments submitted by January 15, 2021 will be considered by the ITI Technical Committee in developing the subsequent version of the white paper. Comments can be submitted via traditional methods at ITI Public Comments or by creating a GitHub Issue.
 

IHE IT Infrastructure Technical Framework Published as an HTML document

The ITI Technical Committee has converted the complete ITI Technical Framework to HTML. It is available here.

Important Note: This HTML version of the IT Infrastructure Technical Framework is published in parallel with the current ITI Technical Framework (Revision 17.0) published in PDF format. Any discrepancies between the HTML and the PDF are unintended and the PDF shall take precedence. 

The ITI Domain expects that the next revision of the ITI Technical Framework will only be published in HTML form and the domain will stop producing PDF Technical Framework Volumes. A reader can use a browser to produce PDF extracts and IHE plans to provide more comprehensive functionality to extract PDF next year.

Comments on the HTML version of the IT Infrastructure Technical Framework are welcome at any time and can be submitted via traditional methods at ITI Public Comments or by creating a GitHub Issue.
 


Wednesday, December 2, 2020

XDS/MHD Community input needed - MHD move away from DocumentManifest

I have asked this on the various discussion lists for XDS and MHD. I have gotten positive response. I am very interested in concerns, and help.  I have started this work, IHE MHD Github Repo

Hi MHD implementer community 

As many of you know, I am the author of MHD and also part of the HL7 FHIR core team. 

ASK: Please consider this message and provide feedback. I want to represent the interests of the MHD community, but also need that community to be active in HL7 and IHE. I am especially interested in concerns with the approach described below. I am also eager to get engagement in the ITI-Tech work we are starting on MHD (see below).

I have been thinking about a maturity problem that is coming up in FHIR R5 related to the FHIR Resources used by MHD. 

Patient is already normative.

DocumentReference is likely to be pushed to be normative in FHIR R5. It is part of US-Core so has a group of people beyond MHD working on it.

List (MHD uses for Folder) is used by a couple of use-cases outside of MHD. So there is multiple groups working on it.

but DocumentManifest is not getting the proper attention to help move it to normative state. If that does not happen, then MHD will stay as Trial Implementation when it should be a consideration for Final Text.

Many of the MHD use-cases are recognized in US-Core, but they use only DocumentReference and don't have use-cases for DocumentManifest or List (Folder). I bring in US-Core only to express where the motivation is to push DocumentReference to normative. IHE is of course Internationally focused.

The only use of DocumentManifest is in MHD...
  1. We (IHE) can do what is necessary to make this normative. I will still need the IHE community to step forward within the HL7 community to push the workgroup owning DocumentManifest to do HL7 governance. Note that this is a big problem as well since DocumentManifest is still owned by Struct Doc WG; where DocumentReference has moved over to OO. Thus this pathway has many organizational challenges.
  2. We (IHE) can switch MHD away from DocumentManifest, using List. There would then be two kinds of list in MHD, one as the SubmisstionSet, the other as a Folder.
  3. We (IHE) can switch MHD away from DocumentManifest toward some other resource. 

ITI-Tech has agreed to #2. That is to stop using DocumentManifest for SubmissionSet, and profile a use of List for SubmissionSet functionality. This might produce some update requests to List to add elements necessary for that use-case. Adding elements to List should not be seen as a problem. List maturity would be needed by MHD for Folder anyway, so putting our efforts toward the same resource would be helpful.

Yes there are functionality differences between a SubmissionSet and a Folder. These differences can easily be profiled into the same List resource.

Note that ITI-Tech is also going to formally move MHD out of supplement form, and into the IG Authoring form. Thus we would benefit from community engagement, such as providing examples and review.

Thursday, November 12, 2020

Open-Source Audit Log conversion

 I was made aware of an open-source project that has addressed converting classic DICOM Audit Messages into the new FHIR AuditEvent. This open-source project is managed on this github repository. I helped the authors with some background and understanding, but I take no credit for the work they have done. 

I am sure they welcome comments, suggestions, and assistance. 


My blog articles on Audit logging for Security, Privacy, and others



Wednesday, November 4, 2020

Patient Master Identity Registry

The Patient Maser Identity Registry is a new profile (Implementation Guide) from IHE. It is designed to address a new environment that has no existing HL7 v2 or v3 patient identity management solution, that needs a multiple organization Patient Identity Management. It defines the following actors. This is the typical IHE model of defining abstract actors, not systems. Thus these actors can be grouped in various ways inside a system that one might more typically understand.


At the center is the Patient Identity Manager, as described in the PMIR profile, this is a very simplistic actor that has no intelligence, it is just a FHIR Server that supports the transactions. Often times a real-world system would have intelligence to detect potential conflicts, or mistakes, or opportunities for linking. A system like that would defined that is is both a Patient Identity Manger, and a Patient Identity Source. This does not mean there are not other Patient Identity Source actors in a network.

There would likely be a Patient Identity Source at each organization. It would likely be in a system that is also a Patient Demographics Consumer. An example would be a Registration Desk.

There would also be typical client apps that would be Patient Demographics Consumers or Patient-Identity Cross-reference Consumers. Note that the Patient Identifier Cross-reference Consumer actor would typically be used in cases where national identifiers are issued to patients, thus a lookup is done using just an identifier. The Patient Demographics Consumer can lookup by identifier, but also can lookup by any of the demographics or identification characteristics.

The Patient Identity Subscriber and Patient Identity Consumer are used together by any system that would like to be notified of changes to a Patient Identity. This would be used by data holders (Data Servers), so that they could correct any data they have. Important is to correct the data when a Patient Identity is merged.


Patient Identity flow

The following shows the flow of these systems

First shown is that a Data Source (a typical FHIR Server) would subscribe to be notified.

Second shown is a flow at a Registration Desk

  • If there is only one Patient found, and all the demographics are correct, then there is nothing more needing to be done. That one Patient found can be used within the community. 
  • There are three alternatives shown: where one patient needs demographics or identifiers updated, where there is no patient found, and where more than one patient are found.  
    • In the first case after clarifying that there is a need to make the demographics or identifier change, the Registration desk informs the Patient Master Registry of the  update to the demographics, which causes the Patient Master Registry to record these changes AND inform all the interested parties such as the Data Services that has subscribed.
    • In the second case after confirming that no patient has found (e.g. a newborn, or new emigrant), the Registration desk informs the Patient Master Registry of the new patient with given demographics, which causes the Patient Master Registry to record this new Patient AND inform all the interested parties such as the Data Services that has subscribed.
    • In the third case after confirming that the patients found are indeed all the same human, the Registration desk determines which patient entry should be merged into the other. The Registration desk informs the Patient Master Registry of the merged patients with specific instructions on which identity should be used and which identity should not be used anymore, which causes the Patient Master Registry to record this merge Patients AND inform all the interested parties such as the Data Services that has subscribed.


This solution is not expected to work everywhere. It is designed for environments that don't have existing Patient Identity infrastructure, and it is designed for places that want to manage a master identity (golden) at the center of multiple organizations.

I do expect that variations will eventually be worked up as well.


Wednesday, October 28, 2020

Webinar on Document Sharing HIE on FHIR

Webinar recording is available that covers the Document Sharing Health Information Exchange (HIE) on FHIR. 

Covering topics of:
  • Document Sharing (concept, XDS, XCA, MHDS)
  • FHIR access to Documents
  • MHD as API
  • Support profiles: IUA, PDQm, PIXm, mCDS, …
  • MHDS as a full FHIR stack solution
  • Support profiles also include PMIR, SVCM
  • Consuming Elements/Resources (mXDE + QEDm)
  • Add Provenance – to get back to source documents


.

This is available on the IHE YouTube channel  The slide deck with embedded recording is in the IT-Infrastructure github repo 

The content for this presentation are baked into the IHE Mobile Health Documents Sharing (MHDS) profile.

Monday, October 26, 2020

Patient Generated Health Data

Some background on what the broader government (HHS) under the office of the national coordinator (ONC) is saying about Patient Generated Health Data (PGHD). This is not a very mature definition yet, mostly because of wildly divergent abilities given to patients among the 6000 healthcare provider organizations in the USA. However the details outline here have held up well. This is what we wanted 5 years ago, it is still what we want. This includes the risks outlined 5 years ago, they are still risks today. The details on this page are mostly from January 2018.

The bad news is that we have not progressed as much as we thought we would have 5 years ago.

https://www.healthit.gov/topic/scientific-initiatives/patient-generated-health-data

​The infographic is the most useful thing on this page. It covers the points quite nicely and clearly.

Wednesday, September 16, 2020

IHE-Connectathon in November to be Online

 Brussels face to face Connectathon transformed to ONLINE, 2-6 November

IHE-Europe Connectathon takes place online

After thorough consideration and evaluation of the current COVID-19 developments, we are urged to announce that the 2020 IHE-Europe Connectathon scheduled to take place on November 2-6 in Brussels, Belgium will be taking place online. IHE’s globally-developed, standards-based, open-source interoperability testing platform together with experienced monitors will support the testing event.

Abstract

When we made the decision to postpone IHE-Europe’s 2020 Connectathon Week from March to November 2020 due to COVID-19 imposed lockdowns, we had hoped that the global health environment would have improved sufficiently to hold a successful in-person event. While there have been successes and challenges managing COVID-19 impact across the world, at the moment travel warnings and restrictions are in place for many areas relevant to Connectathon participants, including Brussels. Since improving the health of people is at the heart of IHE, we do not think it is appropriate to bring together people from across Europe and other parts of the world together in-person for these IHE events at this time.

We will be collaborating with IHE domains from across the globe to hold the online IHE Connectathon utilizing IHE’s interoperability testing platform at the same dates as initially planned: 2-6 November. Current registrants' registration fees will be honored for the online event in case they register for it again, and will be refunded if they choose to not make use of this great opportunity to advance the interoperability of healthcare products and to shape the possibilities to test the interoperability of these products online.

All registrants will receive more detailed information soon on:

  • fees and registration dates
  • list of available IHE-profiles
  • vendor connectivity test session before the Connectathon week
  • instruction sessions

And more.

We look forward to receiving your registration for Europe’s first ever online IHE Connectathon, performed from November 2-6 in the European time zone, once the registration has opened. You may indicate your wish to participate in advance via secretariat@ihe-europe.net.

As announced in parallel by IHE USA, the IHE North American Connectathon in March of 2021 has been planned from the beginning as a fully online event, facilitating participants from the North American time zone. The NA Connectathon will build upon lessons learned in the European Connectathon and leverage an enhanced version of IHE’s online interoperability testing platform, Gazelle.

IHE World Summit postponed

We regretfully decided to postpone the IHE World Summit which was supposed to be held from 3 to 4 November during the IHE-Europe Connectathon week and to continue to monitor the COVID-19 global situation in order to determine a new date. We are currently aiming for a date in 2021, but this strongly depends on the development of the crisis. All World Summit participants will be refunded their fees. We thank you for understanding and we will keep you informed on the developments.

Monday, August 31, 2020

Patient Identity Management the IHE way

 Here are the IHE relevant works on the topic of Patient.

Most important, this is not an interoperability problem

Nationwide Patient Identity Management, especially in a federation like the USA, is a balance between quality, privacy, and safety. Where patient treatment is involved, mistakes in identity can kill. Where health data are involved, mistakes in identity can be a permanent privacy violation. These problems don't exist in environments outside of healthcare, like the financial / banking industry, where in those industries it is easy and effective to revoke an identity, protect an account, and issue a new identity. Further in these other industries a financial remedy is all that is needed to address damages, and thus insurance against damages is easy.

The more accurate one can identify the patient, the more accurate the linkage to that same patient at other locations. Quality of identity can build upon other identifier numbers, like Drivers License, Passport numbers, social security number, etc.

Architectures
IHE includes two distinct architectures at the interoperability level.
1. Centralized - In this model, all the participating organizations feed their updates to a central service. Thus the central service is completely aware of all the information. It can cross-reference various identifiers into a virtual identity. This central authority 
2. Federated - In this model, all the participants agree to respond to queries from other participants. 

The intention is that regional exchanges that are all within a single policy domain could use the Centralized approach. Where as broader access beyond that regional exchange would be knit together using the Federated approach. 

Within an organization, there tends to be a scale of Centralized, but within an organization there could also be forms of Federated. The original PIX/PDQ model explained below was designed first for use within a healthcare treatment organization. 

This was extended to an XDS "Affinity Domain" when XDS needed an identity. In the case of XDS "Affinity Domain" there is a master identifier that is maintained centrally within the Affinity Domain, yet there is no defined centralized set of master identifier attributes. Within an Affinity Domain there is mechanics for fixing mistaken identity, but no mechanics to inform all participants when a patient changes attributes like name, address, phone number, etc. 

The Federated approach is what was designed for XCA, to enable communities to be self-contained, while enabling a patient discovery in a federated way. The XCPD profile is used in XCA to request that a patient match be discovered. This match is based on the policy, accuracy, and authorization at each responding community. 

The new IHE Profile below that manages a comprehensive identity for each patient. In this way the community participants agree to cooperate on a single identity for each patient. This would include cross-references to local medical record numbers where they exist, but more important includes mechanics for cooperating on updates as the patient changes their address, phone number, e-mail address, and name.

Interoperability solutions

FHIR Profiles
Legacy Architecture Profiles
  •  [XCPDCross-Community Patient Discovery locates communities with electronic health records for a patient and translates patient identifiers across communities.  
  •  [PAMPatient Administration Management establishes the continuity and integrity of patient data in and across acute care settings, as well as among ambulatory caregivers.

  •  [PDQPatient Demographics Query queries by patient demographics for patient identity from a central patient information server.
  •  [PIXPatient Identifier Cross Referencing queries for patient identity cross-references between hospitals, sites, health information exchange networks, etc.
  •  [XPID] XAD-PID Change Management updates the relationship between XDS Affinity Domain patient identifiers and other patient identifiers.  


Whitepapers and Handbooks on HIE, each have sections on Patient Identity Management
  • Health Information Exchange: Enabling Document Sharing Using IHE Profiles – Published 2012-01-24
    • Section 4 Patient Identity Management
    • 4.1 Patient Identity Cross-Reference (PIX)
    • 4.2 Patient Demographics Query (PDQ)
    • 4.3 Cross-Community Patient Discovery (XCPD)
  • Template for XDS Affinity Domain Deployment Planning – Revised 2008-12-02
    • Defines policy decisions that a community needs to address. Specific to Patient:
      • Section A.8.2.2.7 XDS Patient Identity Source
      • Section A.8.2.2.8 PIX Patient Identity Source
      • Section A.8.2.2.9 PIX Manager
      • Section A.8.2.2.10 PIX Consumer
      • Section A.8.2.2.11 PDQ Patient Demographics Supplier
      • Section A.8.2.2.12 PDQ Patient Demographics Consumer
      • Section A.9.2.1 Example of Rules and Restrictions for Patient Demographics Data
  • Volume 2x (ITI TF-2x): Appendices A through X and Glossary (Rev. 15.1)
    • Appendix E: Patient Identifiers in HL7-based IHE Profiles
    • Appendix M: Using Patient Demographics Query in Multi-Domain Environments


      IHE focuses on Interoperability, not policy. This said, the interoperability needs are driven by a set of reasonable policies that are expected to be used. 

      Friday, August 28, 2020

      IHE ITI Supplements Updated

      Big set of new publications. This is not radical changes, but cleanups and approved Change Proposals

      IHE IT Infrastructure Technical Framework Supplements Published for Trial Implementation.
      Is this email not displaying correctly?
      View it in your browser.

      IHE IT Infrastructure Technical Framework Supplements Published for Trial Implementation

      The IHE IT Infrastructure Technical Committee has published the following updated supplements for trial implementation as of August 28, 2020:

      • Add RESTful ATNA (Query and Feed) - Rev. 3.2
      • Appendix Z on HL7® FHIR® - Rev. 2.2
      • Healthcare Provider Directory (HPD) - Rev. 1.8
      • Mobile Access to Health Documents (MHD) - Rev. 3.2
      • Mobile Care Services Discovery (mCSD) - Rev. 3.2
      • Patient Demographics Query for Mobile (PDQm) - Rev. 2.2
      • Patient Master Identity Registry (PMIR) - Rev. 1.2
      • Remove Metadata and Documents (RMD) - Rev. 1.3
      • Restricted Metadata Update (RMU) - Rev. 1.2
      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.
         

      Thursday, August 13, 2020

      FHIR Security and Privacy Tutorial

      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
      • Extra-Sensitive Treatment
        • Share with Protections
      • De-Identified Research

      Note that ALL of these topics have been covered in this blog. See Security Topics, Consent/Privacy, and FHIR for index to these articles.

      Thursday, July 30, 2020

      Panel Moderation: ONC Tech Forum - Advancing Trust of Third-Party Applications

      Coming up shortly is an ONC Tech Forum ( August 10-11) virtual event. There are many tracks that I would recommend engaging with. 

      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.


       

      Thursday, June 18, 2020

      IHE ITI Work Items summer 2020

      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)
      * kanban board for this project https://github.com/orgs/IHE/projects/3
      * github where we doing most of our work https://github.com/IHE/supplement-template
      * example of PIXm profile converted from word/pdf supplement to IG build   http://build.fhir.org/ig/JohnMoehrke/ITI.PIXm/branches/master/index.html 
      * example of MHD profile using FSH/sushi authoring http://build.fhir.org/ig/JohnMoehrke/MHD-fsh/branches/master/index.html
      * 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/

      HIE White paper update
      * kanban board for this project https://github.com/IHE/HIE-Whitepaper/projects/1
      * github where the work is happening https://github.com/IHE/HIE-Whitepaper
      * html rendering of current work for committee review (not proper external publication)  https://ihe.github.io/HIE-Whitepaper

      IHE publications in html
      * kanban has not been started as too much is in flux
      * publications github where we are doing our work https://github.com/IHE/publications
      * html rendering of current work for committee review (not proper external publication) https://ihe.github.io/publications/

      IUA upgrade 
      * strong use of github issues
      * Team is going forward editing in markdown for supplement publication (not word doc)

      SNIF White Paper promotion (more of an ITI Planning task)
      * Formally published at Survey of Network Interfaces Form – Published 2020-05-29
      * GitHub repo for experiment publish as html and use of GitHub Issue Tracking
      * html rendering of github markdown authored for committee review https://ihe.github.io/SNIF/SNIF-Whitepaper.html
      * 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.


      Tuesday, June 16, 2020

      Web API security as foundation for #FHIR

      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.

      Web API Security -- OWASP Top 10 Web Application Security Risks

      1. Injection. Injection flaws
      2. Broken Authentication. 
      3. Sensitive Data Exposure. 
      4. XML External Entities (XXE). 
      5. Broken Access Control. 
      6. Security Misconfiguration. 
      7. Cross-Site Scripting XSS.
      8. Insecure Deserialization. 
      9. Using Components with Known Vulnerabilities. 
      10. Insufficient Logging & Monitoring. 

      OAuth 2.0 Security Best Current Practice


      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.

      IETF Best Current Practice in security

      • BCP038 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
      • BCP046 Recommended Internet Service Provider Security Services and Procedures
      • BCP061 Strong Security Requirements for Internet Engineering Task Force Standard Protocols
      • BCP072 Guidelines for Writing RFC Text on Security Considerations
      • BCP106 Randomness Requirements for Security
      • BCP136 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)
      • BCP140 Preventing Use of Recursive Nameservers in Reflector Attacks
      • BCP188 Pervasive Monitoring Is an Attack
      • BCP194 BGP Operations and Security
      • BCP195 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
      • BCP199 DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers


      etc...

      Wednesday, April 8, 2020

      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.

      Tuesday, April 7, 2020

      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.