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.

Open GPT as John Moehrke on Privacy Consent

I have played with Open GPT Chat for a couple of weeks. Mostly being scared at how good it is, laughing at the mistakes, and having it write FHIR code. I have seen other bloggers asking Open GPT to write in their voice, so I gave it a try... I didn't know I had a style, let me know if you agree with the style. I will continue to write blog articles myself...

Note the FHIR code was the worst, first because it was trained on the internet long ago so it only knows only about FHIR STU3, and it clearly doesn't understand the FHIR model as when I asked for how to expire a Consent it just added json element - `expires`.

Write a blog on Healthcare Privacy Consent in the voice of John Moehrke.

As a healthcare professional, I am well aware of the importance of protecting patient privacy. This means not only safeguarding sensitive medical information, but also obtaining the proper consent before sharing that information with others. In this blog, I want to talk about healthcare privacy consent and why it is so crucial.

First, let's define what we mean by healthcare privacy consent. This refers to the process by which a patient gives their permission for their personal medical information to be shared with others. This could include healthcare providers, insurance companies, or even family members.

Obtaining healthcare privacy consent is not just a matter of good manners, it is also required by law. The Health Insurance Portability and Accountability Act (HIPAA) sets strict guidelines for how and when personal medical information can be shared. Failure to obtain the proper consent can result in fines and other penalties for both the healthcare provider and the individual who disclosed the information.

But why is obtaining healthcare privacy consent so important? For one thing, it gives patients control over their own medical information. They get to decide who gets access to their records and who doesn't. This is especially important in cases where the information could be sensitive or embarrassing, such as mental health or sexual health records.

In addition, obtaining healthcare privacy consent helps to build trust between patients and their healthcare providers. When patients know that their information will only be shared with others who have their permission, they are more likely to be open and honest with their healthcare provider. This, in turn, can lead to better care and better health outcomes.

Obtaining healthcare privacy consent can also help to prevent medical errors. When multiple healthcare providers are involved in a patient's care, it's important that they have access to all the relevant information. Without the proper consent, some information may be withheld, leading to gaps in the patient's medical history. This could result in the provider making decisions based on incomplete information, which could have serious consequences.

So, what can healthcare providers do to ensure that they are obtaining the proper healthcare privacy consent? The first step is to make sure that patients are informed about their rights and the importance of consent. This can be done through informational materials, such as pamphlets or posters, or through verbal communication during the patient's visit.

Next, it's important to have a clear and concise consent form that is easy for patients to understand. The form should clearly state who will have access to the patient's information, why they will have access, and how long the consent will remain in effect. It should also give the patient the option to withdraw their consent at any time.

Finally, healthcare providers should make sure that they are keeping accurate records of when and how consent was obtained. This will help to ensure that they are in compliance with HIPAA and other relevant laws, and will also provide a record in case there are any disputes about consent later on.

In conclusion, obtaining healthcare privacy consent is crucial for protecting patient privacy and ensuring that they receive the best possible care. As a healthcare professional, it's my responsibility to make sure that I am obtaining the proper consent before sharing a patient's information with others. By doing so, I can help to build trust, prevent medical errors, and ensure that my patients receive the best care possible.

Privacy Consent on FHIR - looking for initial feedback

IHE has agreed to work on the Privacy Consent on FHIR implementation guide. This is the work that I hinted at in IHE FHIR Privacy Consent IG. I am so happy that it won't be called BPPCm, although I am not all that happy with "FHIR" in the name as the name should invoke an understanding of the problem being solved, not the solution. But we tried out many alternatives and "PCF" seemed best.

I have started work on the implementation guide. You can follow the github repo, or the CI build. There is not much to look at right now, but by the time you read this article I might be much further along.

I have some questions and request some feedback...

Stepping Stone Maturity Levels

I have often considered Privacy Consent to be something for which one approaches with some stepping stones. The ultimate Privacy Consent features are actually very complex, and truthfully impossible to reach. Certainly impossible to reach in one step. So I have built in some "stepping stones", I have heard others ask for "maturity levels". However you call it, there are simple use-cases and increasingly more complex. The simple use-case "should not" be acceptable to anyone, but starting simple gets the infrastructure started and ready for the next step.

The FHIR Consent gives us some easy ways to encode rules around Permit or Deny. The Consent is not really the complexity, more the enforcement is the complexity.

So I have come up with four levels, each builds upon the prior:

1. Implicit Consent -- simply that a system declares that it can handle a default policy to be used when there is no Consent on file. This default policy support would include: deny all, deny except for break-glass, permit for treatment only, permit for any otherwise authorized.
2. Explicit Basic Consent -- support for explicit Consent with a few patient specific parameters to enable the Consent to identify specific agents that can/can't access for a small number of purposeOfUse, and where the data to be protected can be identified directly or by timeframe of authorship. 
3. Explicit Intermediate Consent -- support for named PurposeOfUse research projects, data identified by author of that data, and data identified by relationship to identified objects such as an Encounter or CarePlan.
4. Explicit Advanced Consent -- Support for data sensitivity tagging. This requires implementation of a Security Labeling Service, but does not define an Actor for this. The expectation is that a Security Labeling Service is a more intimate systems-design, and would not likely be implemented as an abstract Actor. This approach allows for multiple architectures.

As I indicated in my proposal, I think there are maturity beyond this that eventually might be approachable. But at this time these far more advanced use-cases are not realistic. Most interesting to me are the ability to propagate residual obligations and refrains. So my intent is to focus on these approachable solutions, and work on the use-cases beyond later. I know that there are real use-cases that need more, I am just looking to make progress. 

Note that even these stepping stones might not be reasonable... so please let me know what you think.

Actor gymnastics

The Actors involved in capturing consent are very simple. This is simply a RESTful interface of Create, Read, Update, Delete, and Search. The Consent resource will be profiled for the stepping stones, but that is also rather simple FHIR profiling.

The hard part is diagramming how a participating FHIR Client application doing typical FHIR REST interactions with a participating FHIR Server can be enhanced such that the Client will not get any

data that it should not get. The systems design engineer in me wants to show the systems design, but this is not the diagram modeling of abstract actors. Add to this that the likely solution for this is to use OAuth, which is already very complex diagramming at the system level.

I tend to want to separate the Actor that will make the Access Control decision based on the Consent, from the Actor that will enforce that decision. This is a typical abstraction in Access Control, and is also fundamental to oAuth. But it makes for really strange abstract Actors.

Further, these Consent Decisions are based upon predicate Access Control decisions that allow the client application to make a request, and the user to make the request based on a user identity. My understanding is that the term "Cascading oAuth" is used to explain this. Simple form of this in SMART-on-FHIR is that the SMART access control decision is based upon an oAuth interaction with the Open-ID-Connect. So adding in Consent Access Control is adding one more layer to this, or "cascade".

Help Me

So this is a request to help me out. Are these Maturity Levels useful and proper? How might I better diagram the enforcement side?

HL7 FHIR Security & Privacy tutorial - Vegas

 HL7 FHIR Security & Privacy

The HL7 FHIR Security & Privacy classroom tutorial describes how to protect a FHIR server (through access control and authorization), how to document what permissions a user has granted (consent), how to enable appropriate access by apps and users and how to keep records about what events have been performed (audit logging and provenance).

actual Classroom : January 17 afternoon at the HL7 Workgroup meeting in Vegas

This will be a refreshed version of the Tutorial I have given mostly annually to HL7. Each year I do update and enrich the content. More, if you ask questions.

My slides are freely available on google slides 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 is additional detail in slides that I don't cover during the tutorial.

I will have to compress these into just two parts, so look for some of this to not be covered

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 - Covered more by Rob on Monday Afternoon
• IUA
• Mutual-Authenticated TLS
• Access Denied Responses

Part 2 - FHIR capability

• Provenance
• Basic
• Digital Signature
• Audit Logging
• Audit Reporting
• Audit Purging
• Consent - for Privacy
• Permission 
• 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
• simple ABAC
• Extra-Sensitive Treatment
• Share with Protections
• Proxy server to multiple
• 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.

   

Notes and references that I posted after last years presentation

Note this is NOT a SMART-on-FHIR tutorial - See that one on Monday Afternoon

IHE FHIR Privacy Consent IG

 IHE IT-Infrastructure has agreed to start a new work item on the topic of Privacy Consent, using FHIR. This minimally would be a re-evaluation of the use-cases in BPPC for use with FHIR Consent, but likely will go beyond that scope simply because of modern needs, modern toolings, and ease at which the FHIR Consent can support them.

I really don't want to call this new IHE-Profile "BPPCm", the BPPC acronym is hard enough to say without tacking on an 'm'.   What should this implementation guide be called? The inclusion of the technical solution (FHIR) is discouraged as it indicates a solution before the problem is identified. The name could be very generic, like Privacy Consent IG, but we do tend to indicate in the title the scope limits in the use-cases. 

Proposed Scope

Much like BPPC does for XDS community. This Implementation Guide (IG) would do for FHIR community. This IG could be used with MHDS, which already has some of the framework for more specific Consents, but BPPCm would be more complete than what is indicated in MHDS. This IG could also be used for organization use or community use beyond MHD/XDS, which would include use-cases like QEDm, and IPA. This would leverage BasicAudit to record access control decisions and recording of consents.

This IG would

• Define a set of privacy policies with canonical URI and/or code.
• Define a set of Consent patterns that are foundational.
• Define actors for creation/update of Consent, Registry of Consents, Decision actor, and Enforcement actor.

See article - https://healthcaresecprivacy.blogspot.com/2022/05/explaining-fhir-consent-examples.html and - https://healthcaresecprivacy.blogspot.com/2019/11/fhir-consent-mapped-with-bppc.html

Use-cases

This section includes explanation of some example scenarios and points at example Consent resources for them. These example scenarios are provided for educational use only, they are not an endorsement of these scenarios.

Consent Policy

some policy URI could be defined for common consent terms. Not clear that these will be detailed enough to use in practice, but would be useful categorization of policy types.

• Explicit Permit (patient elects to have some information shared) is required which enables document sharing
• Explicit Deny (patient elects to not have information shared) stops all document sharing
• Implicit Permit allows for document sharing
• Explicit Deny of sharing outside of use in local care events, but does allow emergency override
• Explicit Deny of sharing outside of use in local care events, but without emergency override
• Explicit Permit authorization captured that allows specific research project
• Change the consent policy (e.g., change from Permit to Deny)

In each of these cases the provisions of the instance of Consent could further constrain.

Notice of Privacy Policy

Some realms only require that the patient be given access to the organizations privacy policy. In these realms the patient is not given the choice to accept, reject, or change the terms of privacy policy. The expectation is that the patient can stop the engagement with the healthcare provider if they don't like the privacy policy (yes, we know this is a fallacy in many situations).

Basic signed acknowledgement

This section covers the most basic of privacy consents, that simply records an acknowledgement to a given privacy policy permitting data sharing. This is only slightly different than the Notice of Privacy Policy, in that with this example, there is some evidence captured from the ceremony. Such as a patient initialing or signing a form indicating they have received the Privacy Policy. Similar to the Notice of Privacy Policy, the Patient is not given a choice to reject or change the terms of the privacy policy. The specific version of privacy policy recorded can also be helpful to know when a given patient needs to be presented with the new version of the privacy policy.

Change to deny sharing

This section covers the case where a basic permit has been used, but for some reason the authorization is revoked or rejected. An example might be where the organization does allow the patient to reject a previously permitted action, and the patient has expressed they want to deny sharing now. Another example might be where legal action has happened compelling an organization to revoke the consent.

Some patient specific provisions

Authorizing or Denying access to:

• who by a given Practitioner, CareTeam, RelatedPerson
• why by a given Purpose Of Event codeswhy by a given named Research projects
• data by Confidentiality class (Normal, but not Restricted) -- presumes a mature SLSdata by sensitivity class -- presumes a mature SLS
• data by authored timeframe
• data by authorship (authored by someone in organization XYZ)
• data by identifier (explicit reference)
• when specific period of time data can be accessed

Not likely to be in scope

These seem to be possible with Consent resource in R4, but not clear they are priority or even possible.

• Use of Consent besides Privacy (consent to treat, advanced directives)
• .action -- this is not well enough defined in Consent
• applied obligations or refrains -- no clear place where these go in Consent
• .class -- this is not well enough defined in Consent
• data related to an identified data resource (e.g. all data related to this Encounter)