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

Tuesday, October 25, 2022

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)

Monday, October 24, 2022

IT-Infrastructure Fall 2022

Releases 

Four publications released from IHE IT-Infrastructure, one in Public Comment

  • Release for Public-Comment -- Mobile access to Health Document (MHD) - Improvements
    • changed to AuditEvent profiling leveraging Basic Audit Log Patterns (BALP) Release 1.1
    • changes to RESTful type, and query subtype
    • Added new features
      • Add a Generate Metadata that adds the ITI-106 operation that allows for one structured/coded document to be published.
      • Add a Simplified Publish option that allows for one DocumentReference with the document in the .data element to be published, expecting the Document Recipient to create the SubmissionSet derived off of the DocumentReference and Community mapping policy.
      • Add an ITI-65 FHIR Documents Publish option with support in ITI-65 to include a FHIR Document Bundle as an alternative to Binary. This makes less the burden on the Document Source to serialize the content into an appropriate Binary format, as that requirement is moved to the Document Recipient. There are use-cases where the Document Recipient will use the FHIR Document Bundle directly, and there are requirements on the Document Recipient to serialize the FHIR Document Bundle when grouped with non-FHIR Actors like XDS/XDR/XDM.
      • Each of these new options may survive or may be removed. Please voice your interest, and sign up for IHE-Connectathon to test these options. Based on interest these Options may survive or be removed.
    • better clarity on types of Identifier 
    • a method has been added to support DocumentReference replace that is used by the Document Source to mark the old/replaced DocumentReference instance as superseded.
  • Patch release -- Basic Audit Log Patterns (BALP) Release 1.1.1
    • There are no functional changes or breaking changes. This release is primarily to address validation messages that have been made more strict by HL7 than when 1.1.0 was released.
    • clarify explanation of each structureDefinition profile
    • cleanup examples with explicit slice use to eliminate validation warnings
    • add some oAuth AuditEvent examples
    • fix the Actor definitions
    • switch to new IHE template
  • Trial Implementation - Sharing Valuesets, Codes, and Maps (SVCM) Release 1.5.0
    • Converted from PDF to a FHIR IG. 
    • Added in conformance resources and Basic AuditAudit events with examples. 
    • Clarified the use of business identifiers.
  • Trial Implementation - Secure Retrieve (SeR) Release 2.1
    • Expanded scope of services that can be secured beyond XDS Retrieve


These releases are continued improvement and advancement of the Document Sharing Health Information Exchange, and enabling of Community exchanges that are more than Document Sharing. Very focused on #FHIR, but also enabled by existing and successful XDS/XCA Health Information Exchange.

In development

The IT-Infrastructure committee is continuing to advance the state of the art. There are three specifications in development at this time.
  • New Implementation Guide on Scheduling (aka calendar). This work item is taking lessons learned from the Argonaut project on scheduling that has stalled at STU3. The work is in cooperation with the Argonaut project approval. The project is focusing on simple appointments with proposed #FHIR Operations for finding appointment slots, holding an appointment slot, and booking an appointment slot. Current committee draft
  • A whitepaper that focuses on how various Health Information Exchange topologies can be architected. Indicating the various design decisions, with benefits and drawbacks. These topologies that will be described will start with simple single-depth, but will be more focused on the complexity as multiple-depth networks are needed and where various sub-networks have different architectures. Current committee draft
  • XCPD Revoke Transaction - This was a CP, but has become a work item due to the scale of the changes -- The XCPD Health Data Locator and Revoke Option supplement adds a Revoke message to ITI-55. The Revoke message is really an entirely separate message, with its own Message Semantics, Trigger Events, Expected Actions, etc. separate from the main Cross Gateway Patient Discovery message in ITI-55. Therefore, it would make more sense for the supplement to introduce this message as its own transaction rather than add it on to ITI-55.
  • A FHIR centered Patient Privacy Consents Implementation Guide -- The name of this will be determined sometime in the future after the set of use-cases are decided upon. Initial scope is to replicate the BPPC functionality except using FHIR Consent rather than CDA. There may be some of APPC brought in given the functionality of FHIR Consent. Thus the use-cases would tend to be around the same Consent functionality at controlling HIE access to Document scoped data. Future versions might expand to data scope at the FHIR resource level.
I welcome participation in IT-Infrastructure to help with these work items, and propose work items of your own. IHE is a much lower overhead than HL7, yet focuses on producing tightly conformance specifications that are formally tested at IHE-Connectathon.

Future projects

Some potential next projects, based on interest and resources:
  • Profiling of $match for Patient lookup
  • Federating MHDS communities (using XCA or not)
  • Converting more of the existing FHIR Profiles to IG format
    • mXDE
    • QEDm (not formally an ITI project, but we touched it last)
    • RESTful ATNA
    • NPFS
    • mACM
  • Impact of the HL7 Gender Harmony IG on ITI profiles
  • Broader workflows such as 
    • Maternal Health full care flows using HIE
    • EMS full care flows using HIE
    • Social Determinants of Health full care flows using HIE


Wednesday, September 21, 2022

Security Labeling Service

Data may be “Normal” medical data or “Restricted” medical data. The distinction is for this IG focused purely on data classification for sensitive topics.

The various clinical Resources in FHIR are very complex and highly variable. Although Observation is the most often used Resource, sensitive data may exist in ANY other FHIR resource including Allergies, Procedures, CarePlan, Medication, Problems, DiagnosticReport, DocumentReference, ImagingStudy, Genomics, etc… By assessing the sensitivity classification and placing that assessment into a well-known location found in all FHIR Resources - .meta.security, the Access Control does not need to be aware of the kind of FHIR Resource, it can just process the data as a DomainResource and simply look at the .meta.security element.

The classification of data into sensitive topcs is the role of the Security Labeling Service (SLS). The SLS inspects the data, and may use the context of the data to identify the sensitivity classification. It is expected that most data will not be considered sensitive, aka “Normal”.

Data tagging Considerations

Some data are direct and clearly in a sensitive category. But there can be indirect relationships, such as three medications prescribed together are a clear indication of a sensitive category but are not individually.

Some data may also not be sensitive in the coding, but rather sensitive in the narrative, this would be poor data quality but it is a reality that should be considered. Thus an SLS may need to include some Natural Language Processing to find sensitive human words in narrative.

Some approaches use well-defined ValueSets, where others use a list of words. The list of words can be search across the data without regard for the data structure, which has the benefit of not needing to have the SLS data schema aware. The list of words can be codes, such as snomed numeric codes.

Architecture approaches to data tagging

When the SLS is executed is a systems design decision. General alternatives are:

Pre Tagging data

Tagging the data as it is created, updated, or imported.

Pre categorize data within the EHR databaseEHRSLSBatch/New/Updatetagged results


Which has the advantage that the access to the data does not need to assess the data, it just uses the existing sensitivity tag.

Query/Use enforcement based on pre-calculated SLSEHRAppACEQueriestagged resultsenforce rules



This solution is likely to be more performant on use of data, but may not have as accurate sensitivity tags due to the dynamic nature of policies around sensitivity, and dynamic nature of data relationships. This solution also requires that the EHR database support data tags.
Use time tagging data

Alternative is that the data are temporarily tagged prior to use, thus the sensitivity is freshly determined and used only for that access enforcement

Real-Time sensitivty classification at Use/Query/ExportEHRSLSAppACEQueries/Uses/ExportQuery resultstagged resultsenforce rules



This solution does not require that the EHR database be updated to support tagging of data, but may incur a performance impact on data use.

Example ValueSets

One way to understand a very basic SLS is that it looks for clinical codes in the data. It might do this using ValueSets, but likely would need to do this in a more performing way.

There are some valueSets that were authored 9 years ago by SAMSA (requires a free login to see the details). This was during a critical point in the early development of the use of Security Labeling. These valueSets are old, but they are informative. Any standards based managed ValueSet would need to be used as input to a organizational use in an SLS. So the fact these are 9 years old is not as important as that they are a well informed base to start with. I have put the SAMSA valuesets into some ValueSets of my own. 

Tuesday, September 13, 2022

MHD Document Responder: patient.identifier chaining

This is a quick article on a requirement of the MHD Document Responder that may be less obvious to some. The specific requirement is related to chained search parameters, like `patient.identifier`;  `source.given` and `source.family`; and `author.given` and `author.family`. These search parameters have a `.` that indicates that one is to search deeper, aka chaining the search value to a different kind of resource and use the results in the primary search.

The requirement is hinted at being special with a mention of FHIR Chaining Parameters:

This use of patient.identifier follows the FHIR Chaining Parameters search methodology.


But these hints might not be enough, because they do not tell you how to solve the requirement, and this is because there are many ways to solve this, and the implementation details of your system are more important than any factor.

The hints just indicate that the parameter provided is to be matched in a chained way. For example with patient.identifier the parameter is an identifier that should be first looked up with the Patient Identity Manager to find the Patient resource that is then used to find the DocumentReference resources.

That hint tells the Document Responder, that when the Document Source chooses to use `patient.identifier` rather than `patient`; that the Document Source is expecting the Document Responder to do this lookup, rather than the Document Source to do that very same lookup. So, it seems reasonable that queries using chained search parameters might be slower than those that are not.

There are cases where this is inverted, such as when the MHD has an XDS or XCA backend; in these cases the use of patient.identifier that is from the Affinity Domain or Community is better than providing the Patient link. As when a Patient link is the search parameter then a MHD front end to XDS or XCA would need to convert the patient link into the Affinity Domain or Community. This case is likely to be a system such that the Document Responder can quickly do this lookup.

Another place where patient.identifier is going to be preferred are environments that have a national patient identifier. In these cases the national patient identifier is more readily available to both Document Consumer and Document Responder. In these cases it is possible that the DocumentReference.subject element could hold both the Patient id link and the national patient identifier.

The chaining of given name and last name are similar but different in how one must support them on the Document Responder given the system design you have.



Monday, August 22, 2022

eConsent standards

 As with any standard, one more is clearly needed. 



as to the different Consent Standards.. I likely don't know about all of them, but here are some. I am also not indicating that there should be no improvement or even new standards. I just don't want historic lessons-learned to be lost.

for use in Document Sharing exchanges like XDS/XCA/XDR/XDM/MHD/MHDS
This fall I hope to get a FHIR Consent - basic patient privacy project going.

There is an orchestration of various things referred to as Point-of-Care, which is an interaction model using BPPC and XUA - https://healthcaresecprivacy.blogspot.com/2017/01/enabling-point-of-care-consent.html
- this is part of CareQuality, and is built into Epic's CareEverywhere

The FHIR Consent - http://hl7.org/fhir/consent.html FHIR Consent is rich to be profiled. 

There are some projects that claim to be profiling Consent, but they are not yet published.

There is work in FHIR to add a Permission Resource. This would possibly be used by Consent in the future, but that future is likely 5 years out - http://build.fhir.org/permission.html

There is also the OpenID - UMA - HEART - https://openid.net/wg/heart/

There is a broader (beyond healthcare) project in Kantara to support a Consent Receipt

surely I missed something? Please comment or email me.