Many in the USA are reviewing and preparing comments on HTI-1. I used to do this top to bottom, but don't really have a work driver to base my comments upon. So I now end up reviewing and commenting on very targeted sections.
As part of my advisory position on SHIFT
Shift (formerly Protecting Privacy to Promote Interoperability PP2PI) was founded in 2018 and formalized in 2020 with a mission to advance safe, equitable, and patient-empowered sharing of health information. To this end, the task force has gathered expert stakeholders across the industry with the purpose of maturing granular data segmentation standards and implementation guidance in order to sponsor patient-driven sharing of health information with informed consent and advance interoperability in a more equitable manner. Shift’s vision is to further a health care ecosystem in which better standards for clinical data sharing increase trust between patients, providers, and caregivers to improve quality of care and health equity.
I am reviewing "§ 170.315(d)(14) - Patient Requested Restrictions Certification Criterion" and providing comments. The total things said in HTI-1 is
(14) Patient requested restrictions.
(i) For any data expressed in the standards in § 170.213, enable a user to flag whether such data needs to be restricted from being subsequently used or disclosed as set forth in 45 CFR § 164.522; and
(ii) Prevent any data flagged pursuant to paragraph (d)(14)(i) of this section from being included in a use or disclosure.
However, I think that a regulation should focus on outcomes, not how to achieve those outcomes. Meaning the text in the regulation should be expressing the kinds of patient requested restrictions that must be allowed, and not expressing that a "flag" on data should be used. Why do I express this? Because systems design is very specific to the current systems design. Tagging all of the data in an EHR is non trivial, and there is not good advice on how to do that well, say nothing of how to do it without fail.
However, if we had expressions of the kinds of restrictions that are needed by Patients and express these in a prioritized listing; then creative systems designs can be done to achieve those goals. Some may choose to use data "flags", but some may find that their data already have attributes that they could leverage.
I have been working on a new Implementation Guide from IHE on this topic - Patient Consent on FHIR (PCF). And within that specification there is a set of steppingstones: Basic, Intermediate, and Advanced. The Basic is not easy, but is also not hard given many possible designs, and it is what is necessary to build both the Intermediate and Advanced alternatives. Advanced is using security sensitivity tagging, and is what is most of the time referred to as "Data Segmentation for Privacy (DS4P)". One can go directly to Advanced, and not implement the Intermediate. Intermediate is a set of use-cases that are high-value privacy consent needs, that do NOT require data to have security sensitivity tagging.
So, I would prefer that ONC change their (i) and (ii) clause to be expressing use-cases in terms of the resulting behavior and eliminate wording about how one must achieve that behavior.
I would be happy if ONC recognized the IHE-PCF, but it is just in Public-Comment right now, and thus is not ready to be referenced yet. It should be by the time they finish their comments.
Another read of the HTI-1 is that there around the definitions in HIPAA for Patient Requested Restrictions and a healthcare organizations requirements under medical records retention and safety. HIPAA is very careful to give the right to patients to Request Restrictions, but then indicates clearly that the healthcare organization (Covered Entity) is not compelled to accept the restriction request. This has been used to keep the current status Quo where no restrictions are supported. I read the new ONC text to express a need to accept some of these restrictions. As I indicated above, if that was more clearly defined as to the kinds of restrictions that must be implemented, then it would be far more clear what is needed to be done here.
Some other people have read the ONC text to demand that the healthcare organization must accept all restrictions without limits and without human intervention. I can understand this read, but I certainly hope it was not the intended read.
I have been working to express the distinction between the Patient Request, and the rules that an organization agrees to enforce. Where the Patient Request is referred to as "Privacy Preferences". Privacy Preferences would not be constrained by what is possible to constrain, although they might be in a structured and coded format. These Privacy Preferences could be taken as input to a workflow on Privacy Consent with an organization. The Organization here has responsibility to maintain the data, such as a treatment organization. The Organization has regulated responsibilities, like Medical Records Retention and Medical Safety. Thus the Organization has some limits on what they can restrict. The result is a Privacy Consent, where a Privacy Consent is a binding agreement between the Patient (or their delegate) and the Organization(s) holding data. The following diagram is in the IHE-PCF Appendix P
There is so much more in the IHE-PCF that I can't cover here. The maturity of this specification would likely put it outside the window of what the ONC could reference, however the fact that it is in development should be seen as a positive move toward a future that has this kind of support. The real request to ONC is to change the wording of the requirements to not include "how" one achieves support for Patient Requested Restrictions, but rather itemizes the high value use-cases and the outcome of a system that supports those use-cases. This focus on "outcomes" and less on "how" will result in the solution sooner rather than later.
The IHE IT-Infrastructure committee continues to produce new and improved specifications for HIE interoperability. This spring we are publishing a supplement that was out for public-comment, a whitepaper that was out for public-comment. We are placing into Public-Comment an IG publisher formatted Profile that was previously published, and a brand-new Implementation Guide supporting Privacy Consents and enforcement.
All of these can be found on the IHE publications site: https://profiles.ihe.net The publications listed below are from the IT-Infrastructure Domain where these publications and instructions can be found.
Cross-Community Patient Discovery (XCPD) Health Data Locator and Revoke Option - Rev. 3.1
The Cross-Community Patient Discovery (XCPD) Health Data Locator and Revoke Option Supplement enhances the existing IHE XCPD Integration Profile by adding two new capabilities. The first is the ability to exchange a list of health data locations, which enables Record Locator Services to interoperate with consumers wishing to discover the location of patient records within a health information exchange. The second is the ability to revoke a previously exchanged patient ID correlation, which is used in the case where patients in different health information communities were linked with XCPD, but must now be unlinked due to some circumstance such as patient merge.
This update is an editorial enhancement to the existing supplement which improves the layout of the standard by separating the Revoke interaction into a separate, isolated transaction. There are no functional changes in this update. Health IT Vendors should review this supplement and determine if the capabilities within meet their interoperability needs.
Document Sharing Across Network Topologies- Rev. 1.0 New!
The Document Sharing Across Network Topologies White Paper expands upon the concepts in the Health Information Exchange White Paper by providing additional guidance on how existing document sharing communities can be interconnected to form a unified federated exchange ecosystem. This type of ecosystem typically emerges in environments composed of several jurisdictions that each began developing their own health information exchange and now wish to become interconnected.
This white paper primarily illustrates how such a network could be represented in a Mobile Care Services directory. It is intended to be read by HIE and Healthcare IT Executives and Architects, Standards Development Architects, and health data exchange stakeholders in academia.
Mobile Cross-Enterprise Document Data Element Extraction (mXDE)
The Mobile Cross-Enterprise Document Data Element Extraction (mXDE) Profile provides the means to access data elements extracted from shared structured documents. The profile enables the deployment of health data exchange infrastructures where fine-grained access to health data coexists and complements the sharing of coarse-grained documents and the fine-grained data elements they contain.
This update is primarily a conversion from the PDF supplement form to using the IG Publisher. This conversion enabled better and more comprehensive definition of the Provenance linkage between the derived FHIR clinical Resources and the source documents from the HIE. This Provenance definition is now in mXDE along with examples and requirements CapabilityStatement. This update also leverages the other IHE implementation guides that profile FHIR, and specifically the Basic Audit Log Patterns (BALP) for security and privacy audit logging.
Privacy Consent on FHIR (PCF)
The Privacy Consent on FHIR (PCF) Profile provides support for patient privacy consents and access control where a FHIR API is used to access Document Sharing Health Information Exchanges. This profile includes both Consent profiling and access controls profiling of oAuth access token.
This first release to Public Comment includes both Consent profiling and Access Control decisions and enforcement. The Consent profiling supports many Basic, Intermediate, and Advanced needs. There are a rudimentary set of privacy policies, and an Appendix that discusses the various attributes and considerations one must consider when writing the privacy policies to be used. This Appendix also includes discussion about refrains and obligations, the FHIR Consent fundamentals, and Security Labeling Service models. The PCF includes technical profiling on the oAuth (IUA) access token to enable decisions to be based on Consent and to carry residual rules for the enforcement point to enforce. The PCF includes technical profiling of the Consent with various complexity represented in Options to enable basic systems to improve over time to add features in support of intermediary and advanced use-cases. The profile includes 21 examples of Consents using the profiling, and for each of them shows the oAuth access token impact.
I will write more about the PCF in the future, but I think the IG explains itself well.
Details on who IHE is and how to engage are available on their web site. Comments are always welcome from anyone regardless of if you are an IHE member or not.
May the 4th be with you.
I already have one proposal for the transition from the current Federated Health Information Exchange to supporting FHIR, that is based on a transition from CDA to FHIR-Documents. In that proposal, I make it clear that this is NOT an end-state, but rather a method to more smoothly transition. A key point of a smooth transition is that it does not stop what is working today, but provides methods of supporting the future for those early adopters. That proposal recognizes that today the communication pathway is XDS/XCA, and that communications pathway is content agnostic, meaning it can carry a FHIR-Document just as well as a CDA, PDF, JPEG, or TEXT document.
Note that just because the content being published is a "Document" does not mean that it must be consumed as a document. There are solutions such as the one from IHE (Mobile Cross-Enterprise Data Element Extraction - mXDE) that shows how to decompose documents into FHIR Resources, and provides for proper Provenance back to the source Documents.
In this article I am going to add another step to the smooth transition. In this article I am going to show how we can leverage much of the infrastructure that has been put into nationwide federation of health information exchanges, while enabling communication that is natively FHIR Query/Retrieve. In this proposal the data holder never creates a "Document", they provide a FHIR Server endpoint that can be queried. This idea of having a FHIR Server endpoint is not new, it is the fundamental first step of any data holder.
Note that "just use normal FHIR Query" is skipping the Security and Privacy aspects... I will get to those later. I mostly think that this is already addressed by the various security and privacy projects; they just haven't seen enough use to figure out where federation fits.
We already have a functioning Patient Record Location standard that is being used with XCA to find the patient identities and locations where data are. The standard is XCPD. This standard is mostly used between the various communities, so is not something that a client app needs to care about. Yes, it is based on HL7 v3, and uses SOAP. I recognize that this is a drawback. My point is more that this is functional today, and it gives us what we need. Further the HL7 v3 and SOAP standard better supports the scale of federation that we need, something that http REST does not.
So, if we accept that XCPD can continue to be used to discover patient identities and locations where data are, then how do we determine the FHIR Server address? This is an important question as XCPD provides a "homeCommunityID" as the location, and that is an OID.
Fortunately, we already have the solution to this problem.
It is the Endpoint resource that we need to further refine. Whereas it is understood how to define an XCA endpoint; we just need to have a flavor of Endpoint profiled to show a FHIR Server endpoint. Once we have that, then the normal FHIR Server processing progresses. Looking at the FHIR Server metadata endpoint, and oAuth well-known details.
There is a very important Whitepaper by IHE on "Document Sharing Across Network Topologies", that like this article clarifies is more than just Document Sharing, but also FHIR Server endpoint. Video introduction.
Now for the smooth transition:
Like with the previous proposal to transition from CDA to IPS; the transition here is driven more by those that want to consume data, supported by the infrastructure and the data holders.
Thanks to Joe Lamy (AEGIS) for dialog resulting in this article.
As FHIR systems get bigger and bigger, and support more and more clients... It is more and more important to have Test Data to use to assure that:
* meta.security = http://terminology.hl7.org/CodeSystem/v3-ActReason#HTEST
To perform one or more operations on information that is simulated or synthetic health data used for testing system capabilities outside of a production or operational system environment. *Usage Note:* Data marked with a HTEST security label enables an access control system to permit interfacing systems or end users provisioned with a clearance, which includes a HTEST purpose of use attribute, to test, verify, or validate that a system or application will operate in production as intended based on design specifications.
At a panel discussion at the IHE-Connectathon there was much discussion about the new IPS specification. This is a new FHIR specification that expresses what a International Patient Summary (IPS) would look like. This is a FHIR-Document, much like a CDA Document, but using FHIR fundamentals rather than the HL7 v3 model that is the basis of CDA. The IPS is further designed to support modern informatics and health use-cases, so it is really closer to the C-CDA
A question was asked of the panel... "Where do I get the IPS for a patient?"
The panel did an excellent job given an ad hoc question. I would like to further refine this.
There was one answer that was focused on an HIE architecture that collects all the data within a region, and thus can produce a current summary perspective of this collection of all that patients data within that region.
I think this approach to the question is missing a key point. The IPS is a specification of what a International Patient Summary would look like using the FHIR standard. The IPS is not a policy or procedure document for how the IPS data was acquired. Thus to ask this question is not really a question about IPS, but rather about policies and deployment decisions. The IPS specification did somewhat address the fact that the creator of the IPS might be human driven, or automated. The committee writing the IPS understood this scope focus.
This question did bring up that there is a perspective on the IPS that is being seen as critical. That is that the author has a perspective on why they are creating the IPS. That is that the consumer has a specific need and that there are a diverse set of consumers all with very different needs, needs that can be in conflict.
Note that the Document Sharing exchanges can handle very well this new FHIR-Document. The design of XDS/XCA/MHDS are content preserving but content format agnostic.
I suspect that some IPS will be created much like a C-CDA is created today. As a report from a healthcare organization representing what that organization knows about the patient. It might be created by a Patient managed application based on the collection of the health information that the patient has collected. It might be created by a regional or vendor driven organization that covers a larger domain of scope. And it might be created by organizations that pull from these authors and further refine a broader focused IPS.
Critical to this maturity is a strong need to maintain basic Provenance on all data elements to enable de-duplication. We must agree to always include business identifiers that have ever been assigned to data elements. I call this basic provenance, in that the global unique identifier enables de-duplication.
I have been invited to speak at the API Secure conference, a virtual event coming up in a few weeks.
UPDATED: 3/14/2023 -- Here is my slide deck
This is a virtual event, and I and Grahame spoke at last years API Secure conference.
I am also working on other events, such as one by HL7 on applying cybersecurity to FHIR I know that many are uncomfortable with talk of cybersecurity hacking and FHIR, but it is a reality. We either hack ourselves and improve our implementations, or our implementations WILL BE hacked and patient safety and privacy are harmed.
