Thursday, September 9, 2021

#FHIR Basic AuditEvent for generic RESTful actions

I have drafted a prototype Implementation Guide covering the AuditEvent profiling for generic FHIR RESTful actions.

For any FHIR REST operation there is a well-defined AuditEvent specified in this implementation guide. The appropriate AuditEvent shall be recorded by Client and Server applications that claim conformance to this implementation guide. The resulting set of AuditEvents are made available to a client authorized to retrieve them. The AuditEvent in this case is useful for the typical privacy office and security office use, but is also useful to enable a Patient facing app that can inform the patient when and how their data are used.

Basic Auditing where there is a known subject of the data involved. This profile is a formal specification of the guidance given in the FHIR Core AuditEvent under Common Scenarios

This guide does not cover all AuditEvents. It does not cover
  • how accesses to data where their is no subject, such as a Provider Directory. Although this is likely similar, just without the mandated Patient entity.
  • how failures are recorded. Failures are recorded with the .outcome that is not success, and is thus a very large body of possibilities. Failures are logged with best-effort and with verbose content. This makes the AuditEvent of a failure very hard to characterize, vary hard to automatically process, and possibly exposing of privacy or business secrets. These might be access control denials, which the patient would be interested in but for which it is not clear they would be due these kinds of notices. These might be infrastructural failures, which are too hard to characterize.
The AuditEvent profiles here could be used as a prototype for a more specific AuditEvent profile in a use-case specific Implementation Guide. Where a use-case specific Implementation Guide defines an AuditEvent profile, those profiles should be used rather than the Basic AuditEvent profiles found here. Both could be recorded without harm. 

Actors defined in the Implementation Guide



Data using Client

Requesting application in a REST relationship with the Server.

Note that the Client may also record the appropriate AuditEvent into the Audit-Repository. For security use-cases it is very helpful for the client to record the AuditEvent too, as this sets up a pattern of normal operation that can be watched for deviations. Deviations such as the client stopping audit logging should be investigated, a possible cause is that the client credentials have been stolen and are being used by another application than the one authorized.

Data Server

Responding server that holds the data the Client is requesting thru REST. Server records the appropriate AuditEvent into the Audit-Repository.

Audit Repository

FHIR repository holding the AuditEvents created, and provides access to the AuditEvents to Audit-Clients. The Audit-Repository would typically not allow Update or Delete of any AuditEvent previously recorded. Thus only allowing Create, and Read of AuditEvents.

Note that the Audit-Repository may be the same system as the Server.

Audit using Client

A Client that retrieves AuditEvents for some functionality. Where the functionality is not constrained or defined here. The Audit-Client queries AuditEvents for a given Patient.

Purpose

The reason for me to have written this Implementation Guide is for two specific reasons
  1. To provide a structureDefinition Profile set of these basic audit even patterns. Which does test the FHIR core AuditEvent specification.
  2. To provide a pattern for an Audit using Client that uses the AuditEvent(s) for various purposes. Including the purpose of providing a  Patient Engagement - Access Log

References

Monday, August 16, 2021

FHIR Document Digital Signatures

I was asked about Digital Signatures for FHIR documents:

I am working on _____  IG that is FHIR document based and we need a means to prove authenticity. The model is relatively simple in that a document and all of its parts represent a single thing that needs to be “signed”.

I have looked around for examples of this in IGs and in example documents and I have not found anything. I see a lot of references to CDA documents and signatures, but not much in the ay of FHIR documents. Can you point me in the right direction? Are there example FHIR IGs and documents out there. Where should I start?

Documents are good

The right way to do this is to have the signature cover the whole document, you have gotten to that point well. This is important as the signature covers all of the contents, including identity, date/time, context, etc; and also the meat of the content you are needing signed.  The point here is that a Document does not rely on references to outside data that might change, but rather a document should copy within itself everything that needs to be protected with the signature.

A FHIR-Document is not different than a CDA Document or any other kind of document. It is seen by the digital signature as simply a bucket of bits. Thus anything you see showing a digital signature on a CDA document is likely just as applicable to a FHIR-Document. 

The wrong way to do this is to believe that one can include a signature within the document (or within anything that is signed -- for example a FHIR Resource that contains a signature element). As soon as you need to exclude something in the bucket of bits, you open up the opportunity for other things to be excluded from the signature. So, always sign a whole bucket of bits, and a whole bucket of bits that is internally complete (doesn't rely on outside data).

The solution

A signature over a document is a document itself. It is a document of type XML-Signature.

There is already a specification for this from IHE – Document Digital Signature (DSG); and is what the FHIR core specification recommends. https://profiles.ihe.net/ITI/TF/Volume1/ch-37.html

Both documents would have DocumentReference that point at the bits (My preference is using a Binary, but the enclosed base64 data is an alternative).

The two documents would have a relationship. The digital signature (DocumentReference) would have a .relatesTo with the .relatesTo.target of the DocumentReference with the content; and the .relatesTo.code of ‘signs’.

Some more context on this https://healthcaresecprivacy.blogspot.com/2017/04/ihe-document-digital-signature-dsg.html

Note the concept of having everything needed (document) in one blob to be signed is very similar to what the COVID-19 credential does, but they strip things down to the bare minimum in order to fit in a reasonable QR code. They do use a JSON signature and encapsulate the content. So it is logically similar to the above, but practically it looks very different.  (Updated to be more correct)

My other articles on Digital Signatures

Tuesday, August 10, 2021

FHIR data in existing Nationwide Health Information Exchange

In the USA and elsewhere, there are Document Sharing based Health Information Exchanges. These exchanges have been built up over the past ten or so years. They have security models, privacy models, patient identification models, record location models, and data format models.  They also have mature testing tools, events, and have been specialized for many projects.

The solution is to leverage this existing solution, and just add FHIR. 


The exchanges in the USA include a PUSH model as well as a Query / Retrieve model. The PUSH model is used to convey information to a specified recipient. This can be done by way of the IHE-XDR protocol or the Direct Project (which uses IHE-XDM). The point I make below applies here, but I am not going to focus on PUSH models, simply for simplifying the message.

Nationwide Federated Exchanges

The Query / Retrieve models are based on the IHE-XCA, which is a federated query model that is designed to enable query of various types of patient data among a federation of partners. This model is used at the state level, and has three flavors at the national level, with interoperability between them... Thus a Federation of Federations.

Both the PUSH and the Query/Retrieve models today are dominated by the


C-CDA content specification. This is a good specification, and many organizations have gone to great lengths to build up their skills at creating the C-CDA, and also at consuming the C-CDA. Thus many want to continue to use CDA to preserve this investment. My point in this article is that this does not need to be a restriction on those that do want to move on to FHIR.

Ready for anything


The IHE-XCA implementation guide is designed to be content agnostic, focusing on a set of metadata that describes the document. These metadata are well talked about. They are designed to be minimal, yet powerful. Defining who the Patient is, Who the Author is, where was the content created, why was the content created, what are the privacy considerations, what are the relationships to other healthcare workflows and things. 

The metadata is not specific to CDA. Indeed the metadata schema was defined back when CDA was just emerging, when there were other content formats that might have become dominant. So the design of the metadata planned for a future when different formats would exist.

And, where the exact same content might be needed in two or more different formats. There is a specific type of relationship between metadata entries to indicate that the two content objects have the same context, with just a different technical encoding.

Just add FHIR

FHIR is a content format. There are Implementation Guides already published for a "Medical Summary" that is using the FHIR content format encoding. The International Patient Summary (IPS) is a FHIR Document that covers the same need as the C-CDA Medical Summary. Thus for those that want a FHIR content format, the choice would be the IPS rather than the C-CDA.  IHE has provided an Implementation Guide that takes the IPS content and explains how to communicate it within the Document Sharing infrastructures. So IPS over XCA.

Transition with no disruption

The best part is that the transition from everyone using C-CDA to everyone using IPS can be easy. There needs to be no change to Patient Identity, Security, Privacy, Records Discovery, Records Retrieval. By Just adding FHIR, the whole nationwide exchange that is functioning today just works.


Those organizations that can publish an IPS, just indicate in metadata entries that they can also provide an IPS. Those organizations that would prefer to consume an IPS, can detect those that are willing to provide an IPS. This addition of FHIR does not get in the way of those that are stuck in the C-CDA encoding. But it automatically enables those that want to speak FHIR.

The key is that there is an association between the C-CDA and the IPS content to indicate that they are about the same context, just different encodings. This association is shown above as a linkage between the FHIR content (IPS) and the CDA content (CCDA). In this diagram the C-CDA content is the master, but it does not need to be that way. An organization could focus on creating FHIR content and have a derived C-CDA for those partners that need C-CDA. This is all about making the transition smooth.

Conclusion

The existing nationwide networks provide many capabilities that have matured over time and are working, we should leverage this. The design of XCA is such that this transition is possible with no disruption, just add FHIR.

The use of FHIR in the existing networks does not mean that we should give up on designing solutions that use FHIR RESTful API. I encourage this too. This setting will need to solve for all of the capabilities that the existing nationwide networks have already solved for, so it will take some time, but it will eventually work.

My message is that the existing networks can be better, just add FHIR.

See the HIE-Whitepaper - section 2.7 Document Relationships where this is discussed.

Thursday, August 5, 2021

Book: IHE Profiles for Health Information Exchange

 I am late to promoting this book, should have done it back in March when it was released. It is called a book, but is available for free download in multiple formats.

IHE Profiles for Health Information Exchange

By Keith Boone

He is the author, but he gives credit for pulling from many sources including my blog.

It goes a bit deeper than the IHE HIE Whitepaper. 

Tuesday, August 3, 2021

InScope podcast: #FHIR security

I was honored to be on the In Scope podcast, and excited to be paired up with Alissa Knight. We talked about FHIR security and such.  The host Mike Murry, who I worked with at GE for many years. He doesn't get to be in the pretty picture (Not my best picture, well I don't think I have better. Really sorry to Alissa for what I bring to the picture ). 

In the podcast, the combination of Alissa, Mike, and I is powerful as we all focus on different parts of security applied to FHIR: Design, Protection, Vulnerability.

The link to the episode on apple or general feed on inscope site, but you can find it on your favorite podcast app searching for "In Scope Security". They even have transcripts.

I hope this is just the first podcast on this topic. I would love to discuss more intersections between design, protection, and vulnerability. I would like to get into Mike and my passion for audit logging and analysis (hoping to catch Alissa). 


Friday, July 16, 2021

HIMSS presentation on FHIR CarePlan

 My next speaking engagement is at HIMSS. This will be from the perspective of my employer By Light, as we have been the developer of the current Patient Portal at the VHA - My HealtheVet, and are the implementers of the original Blue Button. I work with the team on the transition to FHIR.

I am not physically going, as I am still very concerned about COVID-19, specifically Delta and whatever comes next. I trust that HIMSS is doing everything they can to provide a good experience, but the Virus does not care about the good works of HIMSS. Further the COVID-19 Vaccine Certificate they are recommending is thru CLEAR : CLEAR Health Pass Validation, and I don't trust CLEAR with my personal data. There are two other alternatives, but they are equally unclear. I am not disappointed, this is likely the only solution that is ready at scale today.  There are standards really close, although I am worried about all solutions.  It is also the likely solution you would have needed to use to fly to Vegas -- In AUGUST!!!

The details on my speaking engagement at virtual HIMSS are that it is about the opportunity that is coming (not yet here) enabled by FHIR and the CarePlan resource in FHIR. I am very excited about the opportunities of Care Plans. They will initially be used as workflow processes within a hospital encounter, but they have so much more to offer.


I think that Care Plans will really be valuable when

  1. The CarePlan actively engages the Patient. Giving the Patient tasks to accomplish. Enabling the Patient to have apps that know what the Patient should be doing, and recording what they do.
  2. The CarePlan enables care participants from outside the hospital system. Where the Patient can choose which physical therapy to use. When the Patient can choose which laboratory to use. All coordinated by a CarePlan
  3. The library CarePlan patterns (Plan Definitions) becomes a formally managed knowledge. The "best" pattern is picked using Clinical Decision Support and customized for the specifics of that Patient. With feedback loops that make the library better based on experiences of the Patients.
  4. Where the system gets mature enough that a Patient can declare their own Goals and intelligent systems aid them picking out a good Plan Definition from the Library, customizing it for their needs, helping them find a Care Team, and leading them to meeting that Goal.

The state of art is... unfortunately far from this. But I can feel it is just over the horizon. The main thing that will prevent this is "the businesses that are healthcare today". The patient will want and strive for this. The Clinicians (doctors, nurses, etc) will strive for this. I would even think that Payers may strive for this. Those that care about improving health will strive for this.

Thursday, July 15, 2021

Tutorial Links

 Having completed the HL7 FHIR Security and Privacy tutorial, I have found that there are links in my presentation that might be useful to itemize in a more web friendly way. Some people can't go to google presentation, some struggled with quickly typing them in. So here are the links from my presentation.

The presentation slides are at http://bit.ly/FHIR-SecPriv

I always edit them there, so any improvements made over time will appear. So using that link you will always get the current slides.

HL7 does have recordings of this weeks presentation. Those that signed up, have access to these recordings. Those that did not sign up can pay to get access. 

The FHIR core specification has the following main security pages

IETF Best Current Practice for 

SMART-on-FHIR presentation at November 2020 DevDays - https://youtu.be/2QENYKqF78U?t=2157

IHE profile on OAuth for business to business http REST
Current real-world security failure
Here is a security hole found in the Spanish COVID Vaccine Credential system that exposes personal demographics (might be more). Likely because there is no access control check if you are providing an id. Creative use of an API must always be considered in a system design.

My personal project to develop a Basic AuditEvent Implementation Guide



Draft efforts to create a Permission resource in FHIR (future)

FHIR Data Segmentation for Privacy Implementation Guide

FHIR Validated Healthcare Directory Implementation Guide

Multiple-Servers with one proxy - Presentation given by Grahame Greve at November 2020 DevDays - Presentation available at https://youtu.be/stFGtk-YKPQ

Ongoing Discussion: 
  • FHIR Security call on Mondays 12 noon eastern