IHE IT-Infrastructure Fall 2023

The IHE IT-Infrastructure committee has approved four milestones; sIPS, NPFS, DSUBm, and PDQm match alternative. This winter quarter will be a lighter load, recognizing the holidays: Patient Scheduling, prospective look at FHIR R5/6, and evaluating impact of Gender Harmony.  

This article is published before these are formally published, so I include a (will be at) link that likely won't be proper until later in November.

(updated to clarify the links and add YouTube presentation links)

Sharing IPS (sIPS)

Formal Publication -- https://profiles.ihe.net/ITI/sIPS

This Implementation Guide was out for Public-Comment and is now ready for Trial-Implementation.

The Sharing of IPS (sIPS) IHE Profile provides for methods of exchanging the HL7 International Patient Summary (IPS), using IHE Document Sharing Health Information Exchange but does not modify the HL7 IPS specification. 

The International Patient Summary (IPS) content,
as defined in the ISO 27269 data model specification, utilizes IHE’s document sharing infrastructure including cross-community, HIE, direct exchange models, and more. It has been designed specifically to remove barriers to adoption, by leveraging architectures that are currently implemented, well-established, and robust. 

The sIPS Profile provides implementation guidance to vendors and implementers and joins a growing suite of IPS standards artefacts contributed by a variety of Standards Development Organizations (SDOs) and coordinated by the Joint Initiative Council for Global Health Informatics Standardization (JIC).

YouTube presentation, long, and short.

Non-Patient File Sharing (NPFS)

Formal Publication -- https://profiles.ihe.net/ITI/NPFS

This Implementation Guide was converted from PDF form into the Implementation Guide form and is now transitioning to Trial-Implementation again.

The Non-Patient File Sharing (NPFS) Profile defines how to share non-patient files such as clinical workflow definitions, domain policies, and stylesheets. Those files can be created and consumed by many different systems involved in a wide variety of data sharing workflows.

YouTube presentation.

Document Subscription for Mobile (DSUBm)

Public-Comment -- https://profiles.ihe.net/ITI/DSUBm/1.0.0-comment 

This Implementation Guide is going to Public-Comment as a new specification that provides for subscriptions and notification mechanisms to Document Sharing publications.

The Document Subscription for Mobile (DSUBm) profile describes the use of document subscription and notification mechanisms for RESTful applications. In a similar way to the DSUB profile, a subscription is made in order to receive a notification when a document publication event matches the criteria expressed in the subscription.

This profile can be applied in a RESTful-only environment as MHDS but it can also be used with different non-mobile profiles as XDS.b and DSUB. This profile intends to grant the same functionality as the DSUB profile and its supplements regarding Document subscription but also adding some other functionalities (e.g. Subscription Search).

YouTube presentation.

Patient Demographics for Mobile (PDQm)

Public-Comment -- https://profiles.ihe.net/ITI/PDQm/3.0.0-comment 

This Implementation Guide is going to Public-Comment with a new alternative for looking up a Patient using the FHIR $match operation. 

Patient Demographics Match is used by the Patient Demographics Consumer to request that the Patient Demographics Supplier identify Patient records that match the demographics supplied in the request message. The request is received by the Patient Demographics Supplier. The Patient Demographics Supplier processes the request according to its internal matching algorithm and returns a response in the form of demographics information for the matching patients.

YouTube presentation.

Winter Quarter

The winter quarter we will continue working on:

• Scheduling -- a vendor agnostic specification providing FHIR APIs and guidance for access to and booking of appointments for patients by both patient and practitioner end users, including cross-organizational workflows. This specification is based on FHIR Version 4.0.1, and references the Schedule, Slot, and Appointment resources. This workflow profile defines transactions that allow a scheduling client to obtain information about possible appointment opportunities based on specific parameters, and, based on that information, allow the client to book an appointment.
• Evaluating FHIR R5 to improve FHIR core for R6 -- The workgroup will look at what it might take to convert the current set of FHIR R4 implementation guides to R5, with the goal to uncover concerns with FHIR core that IHE should recommend be remediated in FHIR core R6. There is no intention by IHE to publish these FHIR R5 implementation guides as market demand is very low.
• Evaluating the impact of Gender Harmony on IHE Profiles -- HL7 has published a set of implementation guides covering the Gender Harmony use-cases including HL7 v2, CDA, and FHIR. The workgroup will be evaluating the potential to update existing IHE Profiles to add these capabilities. 

Teaching an AI/ML/LLM should be a distinct PurposeOfUse

I have been thinking about a specific need around AI/ML. That is, that when data are being requested/downloaded for the intent of feeding to a Machine Learning; this action should be distinguished from a request for Treatment.

This came up on a TEFCA/QTE call this week, where a question was posed as to how a patient could express that they wanted to forbid their data from being used to teach Machine Learning.

This use-case would need the above ability to understand when a data request could result in the data being used for Machine Learning. Note that data requests are encouraged to include ALL purposeOfUse values for which the data would be used. So in the USA, this would include Treatment, Payment, and Operations. (Note that it is known in the existing nationwide health exchange that many participants can't handle more than one, and thus in that exchange Treatment is presumed to be TPO. I don't like this, but reality is often less than perfect).

Thus, I think we need a specific PurposeOfUse to indicate these requests intend to be used for Machine Learning. I think that this PurposeOfUse would logically be a sub-concept of the existing Healthcare Operations. I argue this because it clearly is not about Treatment, or Payment; that is not to say that the resulting algorithms may not be used for Treatment or Payment; but the reason to ask/get data at this point in the data flow is to feed the Machine Learning. It might be argued that the Machine Learning Training PurposeOfUse would possibly be a new top level PurposeOfUse, but I don't think that is correct either as much of the data captured already today is presumed to be available for Machine Learning (best-practice is that it is consumed in de-identified form, but this topic is not about de-identification or not).

It is possible that we might need a new Obligation/Refrain code as well (thanks to Kathleen for pointing this out). Thus data could be communicated with an attached Obligation to not use it for Machine Learning Training (seems like a refrain). I don't mind putting this code in, but at this time Obligation/Refrain codes are not used, where PurposeOfUse is emerging as being used.

So a PurposeOfUse code specific to Machine Learning

1. can be used in a response (bundle) to indicate positively the intended purposeOfUse allowed
2. can be used in a request to indicate desired purposeOfUse -- which could be rejected if the responder disagrees
3. can be expressed in a security token to indicate authorized PurposeOfUse
4. can be used in policy rules to indicate permit/deny of that specific policy. In this way a data-use-agreement could state that the high level operations purpose of use is intended to enable all sub-concepts; and it could be used to indicate that the high level operations purpose of use is intended to ONLY speak to some sub-concepts such as eliminating the Machine Learning as being allowed or requested.
5. can be used in a Consent, where allowed, to allow an individual patient to express rules specific to that purposeOfUse.
6. can be placed on a dataset that has been properly gathered with that purposeOfUse
7. can be placed on a data item within a dataset to indicate that the data has been properly gathered with that purposeOfUse 
• note tagging the dataset is more common, as replicating the tag millions of times over at the data resource level is not adding value, but I express this one as a dataset might be a mixture of some data that was collected with authorization and some that were not. this would require tagging each data resource.

I would like to get wider consensus on this(these) concepts before we add a code. This consensus would also help inform what it is called, what it is described as, where it is placed, etc. I am confident that we have healthcare standards infrastructure to support this new use-case.

Test Interactions in a Production Environment

I covered how to include Test data in Production Environments using the HTEST tag. That article explained how data that is not real patient data, that is to say 'test' data, would be tagged with HTEST. This is a clear indication of what data in the Production Environment is test data vs not test data. Thus enabling clients to test while connected to the Production Environment, vs having a second environment just for testing. Where having a second environment may still be useful, but the switching from test server to production server can result in errors, usually configuration errors. So being able to do some form of testing in the Production Environment is useful, and testing with test data does not present Privacy concerns.

What that article did not cover is how a client indicates that it knows that it is testing. This has been part of some discussions lately.

Test Patients

First, there could simply be a list of well-known test patients. A request for a test patient is clearly a "test". However, agreeing on a list of well-known test patients is hard at a very large scale, like a nationwide exchange. So, this is possibly of limited use. It still should be attempted, even if other methos are also used.

Custom headers

Some have proposed that additional http headers be created for this 'testing' purpose. My worry about this is that the intention of testing in production is to get as close to exactly what would happen in production as one can get. Using well-known test patients is the least change. Adding headers seems to be very extreme. Further everyone would need to add to their infrastructure knowledge of these headers.

Getting everyone to add custom headers to indicate that a request is 'different' is not likely to succeed. Further, as custom headers it is less obvious when someone forgets to turn off testing mode.

PurposeOfUse

Best case is that the HTEST be used as a PurposeOfUse. HTEST does exist in the PurposeOfUse vocabulary, so it is ready to be used as PurposeOfUse in a request. In the previous article, I don't make mention that HTEST is a PurposeOfUse, but that was for simplicity of explaining things in that article. Data should be tagged with the PurposeOfUse under which it was collected, and test data is collected for the PurposeOfUse of ... testing.

So, add to your requested PurposeOfUse HTEST, and you are now signaling your testing purpose to the authorization and server environments. The big benefit of this is that it is clearly part of the security infrastructure, and secondly it is just one more PurposeOfUse.

Use of PurposeOfUse also is tracked into AuditEvents naturally as it is part of the security layer.

Note that HTEST is ontologically within HOPERAT. This is because it is for the purposes of healthcare operations that you are testing. Testing is not for the purpose of treatment; it is explicitly not treating as it is using test patients. Testing is clearly not payment, one would hope that the test patients will not be billed (well testing billing end-to-end flows would be useful, but it is still testing).

And HTEST can be combined with the normal treatment, payment, and operations so that one can cover flows that would be distinguished. Even combined with BTG (Break the Glass), yes Break the glass is a PurposeOfUse.

PurposeOfUse concerns

There are issues that have been brought forward on this use of PurposeOfUse:

1. Not everyone supports multiple PurposeOfUse. It is understood that some systems were designed back in the day when we thought that only "TREAT" was needed. These systems are really not using PurposeOfUse properly. One really should be asking for Treatment, Payment, and Operations; as it is very likely that any data returned will be potentially used for those other purposes. 

2. SMART App Launch does not include PurposeOfUse. Well, this is a problem that I tried to point out at the first and second revision of the SMART specification. Their failure to recognize the importance of PurposeOfUse is simply wrong. The argument that I heard is that the PurposeOfUse is confirmed during the User Experience at application authorization; and from that point forward just implied by the app client configuration. The SMART specification continues to need formal security modeling.

Note that UDAP, IHE-XUA, and IHE-IUA do include PurposeOfUse... and recognize that PurposeOfUse is multiple values.

Conclusion

Arguments that changing PurposeOfUse is hard really are not compelling to me when the alternative is to invent something totally new. If a change needs to be made, then make that change using standards. There is no good justification to ignore legitimate standards.

PurposeOfUse concept has not been tested well.. adding in HTEST will help get PurposeOfUse the attention it needs. The order should not matter; TPO, OPT, POT, etc. Including adding purpose of use codes that clearly should not be accepted, like "foobar".

California Bill 352 - aka sex and gender sensitivity

The following question(s) were asked today, and I figure my response is informative to a broader audience.

Has anyone implemented anything pertaining to this?


Prevent the disclosure, access, transfer, transmission, or processing of medical information related to gender affirming care, abortion and abortion-related services, and contraception to persons and entities outside of this state in accordance to this part.https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202320240AB352

I'm trying to think through how to go about it and it seems challenging. These are some initial thoughts.Resources should use security labels. Which ones?
There should exist valuesets that define codes which are considered sensitive.. it doesn't seem like any exist
Access by a user/practitioner might not be as challenging because we may be able to determine the state in which the practitioner is practicing via an OIDC claim or a business identifier.. not totally sure about that
Access by a system is potentially more difficult... client registrations would need to contain some assurance about the locale of the application. Some may not segment application registrations in such a way
Access by a patient seems like it would be straightforward, but perhaps not. The patient has the unfettered right to see the data. But, what if a fhir-based app they use has server/architecture outside of ca?
Perhaps a scope could be introduced: "i-am-outside-of-ca", or "i-am-inside-ca"
Must we perform partial hydration of resources? For example, if a portion of the resource is sensitive. If the Patient resource cannot be accessed, the rest of the ecosystem can loose meaning
Documents, Binaries, eg CDAs - must generate a version "for CA" and another for "not CA"
HIEs, QHINs, ...

Mohammad Jafari and I have done work on this in DS4P and IHE-PCF; we continue to refine this as part of our technical advisory participation in SHIFT. -- https://www.drummondgroup.com/shift/

Grahame is correct that GENDER would be the most specific sensitivity policy code. This could be the code used to tag data that is sensitive to GENDER, although this is actually a policy code. A more general approach would be to use the SEX code which is a more proper sensitivity indicator. Whichever of these codes you use to tag data, would then be used in the Consent resource to indicate how those tagged data are to be protected.

In IHE-PCF I have a use-case that shows how this is done using the advanced option
https://profiles.ihe.net/ITI/PCF/content.html#3584-advanced

As to the question on "There should exist a valueset that define codes which are considered sensitive..."
I will reference you to the Appendix P in the IHE-PCF
https://profiles.ihe.net/ITI/PCF/ch-P.html#p5-security-labeling-service-models

First, there was one attempt at creating these value-sets... they were done by SAMSA, they are quite old and are not currently maintained. The SHIFT project is looking for some proper organization and governance to take on the task of updating and maintaining these.

However, no matter how perfect a value-set is; it will always need local tweaking to your organizations use of codes, and will not address use-cases of second or third order relationships.

On blinding part of a resource... you are correct that this is dangerous area. It is an area that we chose in IHE to leave to later versions of the IHE-PCF; we needed basic profiling done first.... Partial resource redaction is likely to be a very specific thing, I expect that partial redaction will first appear in the Patient resource itself. That is to say that the gender extensions may be something that blinding might be seen as still useful for specific users (e.g. the food service doesn't need to see this). When doing blinding like this, there is also the policy on how to indicate that the resource itself is not complete, where we do have the SUBSETTED tag that is used for use-cases like _summary; but in the privacy blinding to indicate that data has been redacted is to send signal to recipient... POLICY is going to be the hard part, the technical implementation can be achieved once a policy is defined.

On the client is within CA or not... WOW, very dangerous territory.. I suspect that this is more risky than even sub resource redaction.

Note that the Gender Harmony workgroup did have some discussion on this, and also chose to defer solving it at this time.
https://build.fhir.org/ig/HL7/fhir-gender-harmony/#out-of-scope

Conclusion

The fact that this is not well described has nothing to do with the technical capability, we have that ready. The main problem is defining comprehensive policies and addressing the risks to privacy, security, safety, and effectiveness. 

Very likely that this bill could be used to get a bunch of people together to define policy and profile how to make it work. Forcing functions are always critical to change.

I think that the SHIFT workgroup is in the best position to address this. They have a very broad participation that can best see the whole picture... and I am on that project.

IHE Basic Audit Log Patterns using #FHIR AuditEvent

The Basic Audit Log Patterns (BALP) is a Content Profile that defines some basic and reusable AuditEvent patterns.

The Audit Log Patterns defined rely on the ATNA Profile for transport of the AuditEvent and query/retrieval of AuditEvents previously recorded. The patterns defined may be used as they are, or further refined to specific use-cases. Where a more specific audit event is defined, it should be derived off of these basic patterns. Thus, a more specific AuditEvent would be compliant with one or more of the AuditEvent patterns defined here.

This Implementation Guide is intended to be fully compliant with the HL7 FHIR specification, providing only use-case driven constraints to aid with interoperability, deterministic results, and compatibility with ATNA and other IHE Profiles.

ANY Secure Client and ANY Secure Server represent abstractions of any client/server actor grouped with an ATNA Secure Node or an ATNA Secure Application supporting the ATX: FHIR Feed Option, defined in the RESTful ATNA Supplement. Where ANY Secure Client and ANY Secure Server are involved in some communication that is an auditable event described in this Implementation Guide and for which some AuditEvent pattern is defined. The AuditEvent patterns defined here will be created and recorded [ITI-20] by the Secure Node or Secure Application that is grouped within the diagramed ANY Secure Client and the ANY Secure Server.

The double recording enables forensic analysis to detect failures better. Both audit events recorded will be different as the AuditEvent.source would identify the actor recording the event. Some actors will be able to populate the AuditEvent pattern given more fully, the lack of an element being populated is not a defect, but rather indicates that the actor did not have access to that data.
AuditEvent

AuditEvent Profiling

The AuditEvent resource is used to record that an auditable event has happened. These auditable events are usually security or privacy relevant, but may be for other purposes. The profiles of AuditEvent here are to support security and/or privacy use-cases. These profiles of AuditEvent can be used as is, or may be used to derive more specific profiles of AuditEvent for more specific use-cases.
Profiles

The following AuditEvent patterns are defined:

• RESTful activities (Create, Read, Update, Delete, Search)
• SAML Security Token
• OAuth Security Token
• Consent Authorized Decision Audit Message
• Privacy Disclosure Audit Message

Implemented in FHIR Servers

The following commonly used FHIR Servers have BALP implemented within them. You just need to turn it on. For more details:

• HAPI FHIR Server - https://hapifhir.io/hapi-fhir/docs/security/balp_interceptor.html 
• Firely FHIR Server - https://docs.fire.ly/projects/Firely-Server/en/latest/security/auditing.html
• Aidbox FHIR Repository - https://docs.aidbox.app/modules-1/logging-and-audit/audit-logging

HL7 Cyber Security Event - recordings available

 Announced this morning that HL7 and ONC are making available the recordings of the presentations given at the HL7 CyberSecurity Event. These presentations were very well done, and I encourage everyone to watch them all.

https://tinyurl.com/hl7sec

#HL7 #FHIR Security Education Event

Join me at the #HL7 #FHIR Security Education Event virtually this August 8 & 9! I'll be speaking on: 

1. 
   FHIR Security and Privacy for Developers
2. FHIR Security & Privacy Capabilities
3. FHIR Security Practical Application
4. FHIR Consent: How to record, assert, and evaluate: IHE Privacy Consents on FHIR

See the full agenda and register at: https://info.hl7.org/hl7-fhir-security-education-event

Patient Requested Restrictions

 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.

I have provided comments to SHIFT, and what they include is up to that organization. The following is purely my words.

First, I am very glad to see advancements in Patient ability to request and get the restrictions they desire. The state of the art in the USA is that Patients have next to nothing resembling Privacy Consent, all while their data are flowing to places that Patient would never imagine their data flowing.

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.

 Preferences vs Consent

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

Conclusion

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.

IHE IT-Infrastructure Spring 2023

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.

Publications of past Public-Comment:

These two specifications were in public-comment this summer, and now are published for use.

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.

New Public-Comment Supplements

These are new publications entering Public-Comment. We welcome comments from IHE members and those that are not IHE members. Both of these are very relevant to current developments in HealthIT.

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.

Transitioning Federated HIE from XCA to FHIR Query

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.

Federated FHIR Resource Servers

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.

What is missing is a federation mechanism that enables someone who needs data to find who has that data. We still need some way to discover the patient identity as known by the various parties participating in the federation, and determine which parties have data about that patient. Once you know the FHIR Server endpoints that have data, and the Patient identity at that endpoint; then you just use normal FHIR Query.

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.

Federated Patient Record Location

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.

Converting homeCommunityID into a FHIR Server address

Fortunately, we already have the solution to this problem. 

Today, with XCA, the homeCommunityID needs to be converted into the address of the XCA endpoint, and this done with a centrally managed Directory. This centrally managed Directory is already managed for the purposes of supporting XCA, so it is already in place. This centrally managed Directory is already founded on FHIR. Mostly the FHIR Resources: Organization, OrganizationAffiliation, Location, and Endpoint.

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.

Intermediate or Direct

Now for the smooth transition:

1. A data holder can express that they both have XCA and FHIR endpoints. They don't need to choose which one they support.
2. Value-Add intermediaries can be expressed in this Directory as the endpoint for a given set of Organizations. 
3. Value-Add intermediaries can also implement mXDE to provide the FHIR Server support on behalf of Organizations that are not yet ready to transition.
4. Those that want data simply use the Federation discovery methods to find the patient identities and locations for a given patient, then lookup in the directory the alternatives for how to get data from that location and choose the best solution for them.

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. 

Test Data - in production

 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:

1. Your client is connected to the right server
2. Your client is properly connected to the oAuth service
3. Your client understands the profiled data

This could be done with a sandbox server that contains only test data, but this only can address #3. 

There is a security tag available in the HL7 ValueSets for Security tagging. 

* meta.security = http://terminology.hl7.org/CodeSystem/v3-ActReason#HTEST

HTEST -- Healthcare Test Data -- 

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.

I use this tag in the Implementation Guides that I write to distinguish the examples I provide. In this way it is clear that this data is "know as example test data" and can't be confused with real patient data. I also expect that this tag is a clear flag to someone that might copy/paste these examples and pass them off as real data. I don't always use this tag, as sometimes it is a distraction from the message the example is trying to convey.

So, going back to the use-case above... If I have a production FHIR Server, I could include the test patients with test data in the real server. This does not mean you should not have a sandbox, you should still have sandboxes for testing prior to being an approved app. But once you have an app that is approved, this HTEST data would be used first to assure that they are well connected. Testing #1 and #2 in addition to #3.

This real server HTEST data can also be used on a regular basis to test connectivity. Might be used when the client or server system is booted, to make sure it is well connected. Or might be tested after the system is updated. Could be regularly tested. Could be used when there is a network failure detected. 

Note that HTEST is not just for server data, the client applications should also be testing their full CRUD abilities with test data. Thus creating new resources for the test patient, with the HTEST tag. Indeed, the Access Control should be sure that any data Created or Updated on test patients does have the HTEST tag. 

Note that HTEST data should also have full variability expected of real data. That is to say that if you support security/privacy sensitivity segmentation, then you should have variously distinguished sensitive data, and the test patient should have a complex Consent. If you have a real-time Security Labeling Service, it can be tested against this test data.

Note that Test Data should be reset on a regular and known schedule. Test Data is not just for sandboxes.

Where do I get 'the' IPS?

 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.

#FHIR up the API Secure community

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 

My goal is to inspire cybersecurity consulting organizations to help out the FHIR community secure their implementations. The cybersecurity community is a specialty knowledge base and has specialty tools to aid with the securing of APIs, and the proofing that the API implementation is secure. This specialty knowledge is really needed by the FHIR community.

This cybersecurity community is well aware of how to secure and validate RESTful APIs, what I intend to focus on is the opportunity presented by the FHIR specification. The value of the data is well worth making sure your implementation is provably secure. Understanding how the FHIR specification defines use of REST, can help focus appropriate use and possibility for abuse.

This event is hosted by Knight Events, as in Alissa Knight, who two years ago showed the FHIR community that there are plenty of ways in which implementers have failed to apply simple cybersecurity to their implementations of FHIR. Her research showed that there are well done implementations, especially the EHR vendors. 

I highly recommend those that are deploying FHIR products, especially servers but equally applications, involve cybersecurity experts. This might be a skill that you have within your organization but might not be. Even if you have cybersecurity experts, it is good to have occasional audits by other cybersecurity experts that might come with a different perspective and tools.

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.

References to Standards need to recognize that Standard's Governance about Errata

When pointing at a standard, do we expect that that standard organization governance on patch / errata / CP releases are followed? It might be common knowledge that when we reference a standard, that we do expect that standard governance applies and thus if that standard organization approves what they consider an effective erratum, that it is effective within IHE as well. However, this may not be common knowledge. I fear that there are many that are interpreting a reference to a standard to be NOT including errata.

The case for Errata or Patch, are when the change is not considered by THAT Standards Organization as being a change that would not be considered a major or minor change. These tend to be clarifications of text, fixing of spelling and grammar, and other clarifications that do not impact the meaning of that standard. Clearly there is some change happening, else the errata would not exist, but it is the governance of that standards organization that the change is simply an errata or patch. Thus, this discussion is about to what degree do we trust the governance of the standards organization from which the standard we are referring to operates within?

For example: IETF RFC 7540, has Errata. IETF is nice in that on their RFC 7540 they indicate that "Errata Exists", not all standards orgs do this.

Same is true of many standards (including internal to IHE references).

• IHE calls these Change Proposals
• DICOM calls these Change Proposals
• IETF calls these errata
• W3C calls these Errata
• OASIS-OPEN calls them Errata but I didn't find an obvious description
• HL7 has errata
• etc

This is NOT a discussion around when the standards organization makes a Major or Minor change; only when it is a patch or errata release. There are different arguments that a Minor change might be acceptable, but this is not the discussion and there are plenty of minor version changes that are not appropriate for automatic recognition.

Hacking #FHIR for the benefit of the FHIR community

I am co-chair of the HL7 Security, and IHE IT-Infrastructure working groups. The dominant topic in my scope over the past 5 years has been Privacy and Security of FHIR.  I have three events that are being discussed in three different organizations, each with a different audience, but all with similar needs and goal. Everyone wants to do whatever we can do to help those implementing and deploying FHIR to do an excellent job at securing from cyber-attack, and assuring patient privacy is preserved.

HL7 is looking to develop a cybersecurity 'event' (likely virtual) that covers explaining the world of cybersecurity in FHIR, covering many of my HL7 FHIR Privacy and Security tutorial topics with expansion and hopefully some implementer explanation. Day 2 would be more hands-on, putting theory to practice, hopefully lead by some who have implemented Privacy and/or Security in products. As part of Day 2 we would like to have some production class systems available for hacking exercises.

As part of this hacking exercise, I am actively working with Alissa Knight, of past Hacking FHIR fame, to have a similar thing done at her general API cybersecurity conference -- APIsecure Conference: The world's first and only API security conference. Last year I presented, this year we want to go more hands-on.  I am also working with IHE-USA/HIMSS for a similar event.  Alissa has agreed to help out with the HL7 and IHE/HIMSS events.

These three hacking exercises do have different audiences with different goals, where the APIsecure conference are mature hackers that don't know FHIR, the HL7 event will be mature FHIR people that don't know hacking, and the HIMSS/IHE-USA will be a broader audience. The goal is to enable the general cybersecurity professionals to be ready to help FHIR implementations, the FHIR implementers to understand the need and methods, and the executives an understanding of the risk and potential.

These three hacking exercises need volunteer FHIR implementations (similar to Alissa's last hacking FHIR exercise). Those that offer up their systems will get details of any problems found, but the details and attribution will not be made public.  So, I am looking for vendors that have a FHIR Server implementation that are willing to provide an instance that can be put before the attackers, preferably a VM that can be restarted easily.

I am also looking for people to sign up to present or help create/review content.

The APIsecure conference is in March; the other two have no set dates at this time.

 

Are there open-source implementations of IHE XCA and XCPD?

 Amazing how hard this is to figure out. So I asked Chat GPT OpenAI

Are there open-source implementations of IHE XCA and XCPD?

IHE (Integrating the Healthcare Enterprise) XCA (Cross-Community Access) is a set of standards for securely exchanging patient healthcare information across different healthcare organizations and systems. IHE XCPD (Cross-Community Patient Discovery) is a standard for finding and retrieving patient healthcare information from different systems.

There are several open-source implementations of IHE XCA and XCPD available. Some examples include:

XCA Adapter: This is an open-source implementation of the IHE XCA standard that has been developed by the University of Utah. It is written in Java and uses the HAPI library for HL7 messaging.


XCPD Adapter: This is an open-source implementation of the IHE XCPD standard that has been developed by the University of Utah. It is written in Java and uses the HAPI library for HL7 messaging.


OpenXCA: This is an open-source implementation of the IHE XCA standard that has been developed by the Open Health Tools project. It is written in Java and uses the HAPI library for HL7 messaging.


openxcpd: This is an open-source implementation of the IHE XCPD standard that has been developed by the Open Health Tools project. It is written in Java and uses the HAPI library for HL7 messaging.

These are just a few examples of open-source implementations of IHE XCA and XCPD that are available. There may be other options available as well.

are there links to that?

Certainly! Here are links to some open-source implementations of IHE XCA and XCPD that I mentioned earlier:

XCA Adapter: https://github.com/jamesagnew/xca-adapter


XCPD Adapter: https://github.com/jamesagnew/xcpd-adapter


OpenXCA: https://github.com/openhealthtools/openxca


openxcpd: https://github.com/openhealthtools/openxcpd

I hope these links are helpful! Let me know if you have any other questions.

are there others?

There may be other open-source implementations of IHE XCA and XCPD available. Here are a few additional resources that you might find helpful in your search for open-source implementations:

The IHE Wiki: This is a community-driven resource that provides information about IHE profiles, implementation guides, and technical frameworks. You can find more information about IHE XCA and XCPD, as well as links to open-source implementations, on the IHE Wiki.


Open Health Tools: This is a community of developers, users, and researchers who are working to create open-source tools and technologies for the healthcare industry. The Open Health Tools project includes several open-source implementations of IHE profiles, including XCA and XCPD.


OpenEMPI: This is an open-source enterprise master patient index (EMPI) system that has been developed as part of the IHE project. It includes support for IHE XCPD, as well as other IHE profiles such as XDS (Cross-Enterprise Document Sharing) and PIX (Patient Identifier Cross-Referencing).

I hope these resources are helpful in your search for open-source implementations of IHE XCA and XCPD. Let me know if you have any other questions.

are there links to that?

Certainly! Here are links to the resources I mentioned earlier:

The IHE Wiki: https://wiki.ihe.net/


Open Health Tools: https://www.openhealthtools.org/


OpenEMPI: https://openempi.github.io/

I hope these links are helpful! Let me know if you have any other questions.