Tuesday, November 29, 2022

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?

Monday, November 14, 2022

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
  • 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 TopicsConsent/Privacy, and FHIR for index to these articles.

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