Glad 2021 is now passed

 I am reminded of "This too shall pass.", and I really hope it is true. The past two years have been monotonous, with very little positive things to get excited about. That said, I expect 2022 will simply be a workhorse of a year with small advancements that are not clear today. Yeah, that is the most blah prediction.

The most positive is that my household family continue to be COVID-19 free. However I lost my father with COVID-19 as a factor. COVID-19 has been the healthcare story in the standards I work on, but is also the thing that is preventing the standards groups from gathering and being more productive. I don't mind the pace slowdown, and initially didn't mind the lack of face-to-face meetings, but lately I have found myself wishing for the face-to-face workgroup meetings. I likely just want some of the positive meeting dynamics, while noting that most of the time the meetings were compulsory and a waste of time.

The last time I did a year-end report was at the end of 2017 - HIE Future is Bright - stepping into 2018. Looking back at that report, it is rather disappointing that none of the expectations have been achieved, yet so much has happened toward the direction of each of these. The activities that have happened are clear now that they were necessary, but of course at the time it felt like everything was ready for progress.

"The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one." - Mark Twain

Over the year, my blog saw mostly the same amount of visitors (90k), and I posted mostly the same number of articles (30). The biggest impact I had this year:

1. IHE whitepaper on Health Information Exchange models (3.7k)
2. From Implementation-Guide to IHE-Connectathon (2.7k)
3. Healthcare use of Identity level of assurance (2k)
4. When is a document not a Document but still a document? (1.6k)
5. Agile improvements toward #FHIR (1.5k)
6. Security of #FHIR implementations concerns (1k)

It is good to see that the Alisa Knight cybersecurity attacks on #FHIR were not a big reason for visitors to my blog. 

2021 Themes

Health Information Exchange using FHIR

• IHE conflicting Patient Identity Feed patterns
• Updates to IHE foundational #FHIR profiles MHD, PDQm, and PIXm
• IHE IT-Infrastructure fall 2021
• #FHIR Basic AuditEvent for generic RESTful actions
• FHIR Document Digital Signatures
• FHIR data in existing Nationwide Health Information Exchange
• Book: IHE Profiles for Health Information Exchange
• User Management on FHIR
• Healthcare use of Identity level of assurance
• IHE is on #FHIR
• Why use current Exchange infrastructure rather than starting over?
• Set of documents that are very focused #FHIR
• When is a document not a Document but still a document?
• Agile improvements toward #FHIR
• IHE ITI February 2021
• IHE whitepaper on Health Information Exchange models
• From Implementation-Guide to IHE-Connectathon
• Actual Consent is more important than more standards for Consent

Healthcare IT Security

• Mantras for Secure FHIR Development
• Please secure your #FHIR API and Apps
• Security of #FHIR implementations concerns
• #FHIR Basic AuditEvent for generic RESTful actions
• FHIR Document Digital Signatures
• InScope podcast: #FHIR security
• Healthcare use of Identity level of assurance

Presenting and giving Tutorials

• Mantras for Secure FHIR Development
• HIMSS presentation on FHIR CarePlan
• InScope podcast: #FHIR security
• Tutorial Links
• FHIR Security & Privacy Tutorial

COVID-19

• note I am big fan of the HL7 Smart Health Cards
• Elitism is Vaccine Credentials Passport
• COVID-19 Immunization Summary Document - use-case analysis

Fun

• A good hot beverage on #FHIR (April 1st)

Mantras for Secure FHIR Development

This morning I presented to the India FHIR-Connectathon on the topic:

Mantras for Secure FHIR Development

The slides are available in google slide desk. Summarized below ---

Alissa Knight -- White Hat Hacker

The New Healthcare Ecosystem will depend on FHIR APIs, but are They Secure?

My reaction

1. EHRs are doing a good job of securing their FHIR implementations
2. FHIR is good and worthy
3. There is room for improvement in some implementations
4. There are included recommended improvements.

Grahame’s reaction

1. The report explicitly notes that no vulnerabilities were found or are documented in the EHR FHIR implementations themselves.
2. Nevertheless, lots of vulnerabilities were found. All of them are very basic house-keeping stuff well covered in the OWASP top ten risks.

Media Hype

1. Many media outlets did not get the facts right at all. Or even the impressions
2. Don’t trust the media, read the report

Basic failure to secure

Resource-Server not enforcing scopes in the OAuth token

• Change the URL by the attacker (change the Patient id parameter)
• Given a read-only token, able to change data (change a medication of another patient)

Client/Server architecture where all data is sent to the Client

• A Patient Engagement App… the client was being used by a Patient on the Patients computer

Resource-Server not validating tokens

• Intercept a legitimate client app request, extract out the OAuth token, put that token into a request from your hacking client - so enforce timeouts and refresh cycles

Clients with hardcoded API keys in the app

• Not hard for a hacker to decompile your app and find keys

Hack yourself before someone else does it for you

• Your API or App will be attacked, better that you prepare
• Look to cybersecurity experts - this is both a skill and an attitude
• There are recommendations like from OWASP - https://www.owasp.org/
• OWASP top 10 API
• OWASP mobile top 10
• Don’t assume tokens are valid, don’t assume token authorizes the request
• Audit Logging of everything, and regularly inspect the logs for deviations
• Provide a way for Vulnerabilities to be reported
• Methods: https://securitytxt.org/, or https://dnssecuritytxt.org/, or https://disclose.io/
• Expect issues to be reported, and be prepared (first response matters!)
• OAuth and TLS have Best Current Practices written by experts

Questions are welcome

Please secure your #FHIR API and Apps

 Just updated the FHIR core spec Security and Privacy Module with a simple message, yellow highlight for the new text:

6.0.3 Security 

FHIR is focused on the data access methods and encoding leveraging existing Security solutions. Security in FHIR needs to focus on the set of considerations required to ensure that data can be discovered, accessed, or altered only in accordance with expectations and policies. Implementation should leverage existing security standards and implementations to ensure that:

• All communications can be encrypted to prevent unauthorized access.
• No information leaks when errors occur
• No active script content can be injected into narrative resources
• Full audit trails can be constructed and used to detect anomalous access patterns

For general security considerations and principles, see Security. Please leverage mature Security Frameworks covering device security, cloud security, big-data security, service-to-service security, etc. See NIST Mobile Device Security  and OWASP . These security frameworks include prioritized lists of most important concerns.

Recent evidence indicates lack of implementer attention to addressing common security vulnerabilities emphasized by OWASP top 10 API . Reviewing the OWASP Top Ten and OWASP mobile top 10  and ensuring those vulnerabilities are mitigated is important for good security.

The Security Checklist also added two new items

12 When using OAuth  - Consider the draft Best-Current-Practice for OAuth 

13. Security / Privacy Event Reporting  - Consider legal obligations and ethical obligations to provide a means for Security and/or Privacy Event Reporting such as security vulnerability, or breach.

---------------------------------  Revised to add these notes ----------------------------- 

Not on the FHIR standard, because it is a bit too prescriptive for HL7. These are the highest takeaways from the past month:

1. Bad API security
1. Take initiative, hack your own API before someone else does.
2. Resource-Server MUST enforce authorization tickets, don't just trust that a valid ticket is authorizing the request being made -- 
1. OWASP -API5:2019 Broken Function Level Authorization
2. OWASP -API1:2019 Broken Object Level Authorization
3. Don't assume any level of trust, always check tokens on EVERY transaction 
4. Don't allow hardcoded API keys
5. And my personal favorite, log events AND audit the logs - OWASP -API10:2019 Insufficient Logging & Monitoring
6. Look to CyberSecurity experts, there are many. There are many tools. 
1. HITRUST.org - they do have a useful cross-reference, and are risk based.
2. Security / Privacy Event Reporting 
1. One method of advertising HOW to contact your security people -- https://securitytxt.org/
2. An alternative using DNS -- https://dnssecuritytxt.org/
3. Great community effort, including policy templates, somewhat more oriented towards researchers:   https://disclose.io/
4. Guidance from CERT on Coordinated Vulnerability Disclosure  
5. Guidance from USA Department of Homeland Security-
6. First.org guidance on MultiParty vulnerability coordination
7. ISO 27000 compliance ISO 29147/2018 and  ISO 30111/2019
8. A commercial product (Luta) maturity model for vulnerabilities  https://www.lutasecurity.com/vcmm
9. a bit on bug bounties, which can be a very useful technique, but one must have a mature baseline in place:   https://bugbountycoi.org/framework/
3. OAuth Best Practice
1. OAuth 2.0 Security Best Current Practice
2. OAuth 2.0 - Security Considerations
3. TLS Best Current Practice

IHE conflicting Patient Identity Feed patterns

Now that IHE has added a PIXm Feed transaction, there is now confusion between PIXm and PMIR. Let me explain.

Overall

The PIXm and PMIR implementation guides are intending on solving two very different models of managing Patient Identity. There is no expectation that a community would deploy both models.

• PMIR model is about one master Patient instance;
• PIXm model is about cross-references to identifiers;

This is further explained in the "HIE Whitepaper - Patient Identity Management"

PMIR

PMIR model is one where a community wants to cooperate on a master Patient identity for each patient, a "golden" patient. This model has each authoritative party in the community cooperatively keeping the single Patient identity for a patient up-to-date. When a patient is seen one of the locations in the community, the master Patient identity is pulled from the PMIR Registry. If there is anything that needs to be updated, then that system will send the update back to the PMIR Registry. Thus there is only one Patient identity (demographics, addresses, phone numbers, national numbers, etc). This cooperation is what PMIR is all about.

There are additional features in PMIR that enable those that rely on this master Patient instance to be notified of changes. This is another use of the feed. This feed does enable the data custodians to be notified of important changes like when two master identifiers were determined to actually be about the same patient and thus have been merged. In this case the data custodian is expected properly update their data to represent the merge.

PIXm 

PIXm model is one where a community wants to cooperate on Cross-References between each community members instance of the Patient identity as they know it. Where a cross-reference is simply a list of  Patient.id and Patient.identifier (that is a patient identity such as MRN). The cross-reference is derived at using the other elements in the Patient resource, but a cross-reference does not expose on a query interface these other elements in the Patient resource. The PIXm query is just a set of identifiers (id and identifier) that are cross-referenced. 

Each time a community participant updates their local instance of the Patient identity, they do feed those updates to the PIXm Manager. The Manager looks at the details with the ONLY output that the PIXm Manager updates the cross-references that it would return in the future when a PIXm client asks for the cross-references. It is very likely that the PIXm Manager does remember the demographics, addresses, phone numbers, national numbers, etc... but there is no effort to harmonize these at the element level. 

PMIR uses PIXm

PMIR does include the PIXm Query transaction. This is useful when a client in the PMIR environment for a very few cases:

1. When the client does not want the whole Patient, just the .id so that it can record that value. There are plenty of client use-cases where it is not important to have access to the full, and sometimes sensitive, elements in the Patient resource. For example a weight scale wanting to record a new body-weight observation, where the scale knows the PMIR Registry and knows that the weight scale GUID is recorded as a Patient.identifier. Thus this device can do a PIXm Query given the scale GUID and get the Patient .id value. It can put that value into the Observation.subject element. 

2. When the client does not want the whole Patient, just knows the Patient .id and wants a local MRN value. Not as clear why this client does not want to be exposed to the Patient Demographics, but it is possible.

PIXm and PMIR feed are not compatible

So the above should make it clear that PIXm and PMIR are solving different community models, and that those models would not exist in the same community. It is possible that a PMIR community would want to be a community participating in a broader PIXm community. Thus the PMIR Registry would participate as a PIXm Patient Identity Source.

The elephant in the room is... WHY did PIXm and PMIR feed choose totally different technical approaches at the FHIR interaction? If you didn't notice this, let me explain.

• PMIR uses a "history" Bundle for the Feed. 
• PIXm uses more basic RESTful Create/Update/Delete (mostly)

Neither model is great. It is very possible that in the spring we update PMIR to more closely align with PIXm. I say "more closely" because the "expected actions" of the PMIR Registry are very different than the those of the PIXm cross-reference Manager. But the communication on the wire might be possible to be 'closer'...

Trial-Implementation

All this said... these implementation guides are both in "Trial-Implementation" state. This is the state used when IHE wants implementers to try it out, and give feedback to improve the future. So, please try them out, and give us feedback. Would prefer you join the ITI-Technical committee, but would also take input on the Public-Comment forum or GitHub for PIXm. I would also welcome comments on this blog article.

My Father

My father passed away this week, joining my mother. His health has been fading since his love of 70 years passed. He passed peacefully with his favorite nurse at his side, in the middle of the night.  

During my life he was a Wisconsin State Trooper. He joined on a dare from his older brother who had joined in 1956, the next year my father joined the 6th recruit Class, badge #287.  He retired after 28 years. There were plenty of stories of my father as a Trooper. Most of what I remember is that he had friends in every little city, truck-stop, gas-station, etc. I never caught the skill of making friends that he had. 

I learned from my father (and mother) respect for others. I know that police do not have a good reputation today, and I suspect there were bad apples back then too. But I am confident of the stories I was taught regarding "perspective". I was taught to not judge someone by the first impression, to try very hard to look at their situation from their perspective. It is when you see their perspective you realize they are fighting trying times. This perspective exercise is what enables me to be comfortable with people that are "not like me", people who make life choices that I myself can't understand, people who are down on their luck and likely would benefit greatly from the smallest of help. Perspective is key, try to walk a mile in their shoes before you judge. 

I learned from my father work-ethic. He would work hard when doing a job, with appropriate breaks. But he would also reserve recreation time. And of course sleep.  He enjoyed odd-jobs, such as gathering up used tires to take them to the "re-tread" factory. We would fill the back of the pickup truck, nicely organized tires, three rows high. Learning how to get the rain water out of the tire without getting wet. I am sure this odd-job was never worth the income.

When I heard of his passing, I was relieved for him. I will miss the bi-weekly visits I had with him. I went for a walk, turned on classical music (my mothers favorite) and listened for sour-notes and clinkers (my father always would). Ended up sitting in a local church prayer garden, alone with the sunset.

Updates to IHE foundational #FHIR profiles MHD, PDQm, and PIXm

Updated MHD, PDQm, and PIXm

Patient Identifier Cross-reference for Mobile (PIXm) -

Rev. 3.0.0. This revision was created using the Implementation Guide publisher. This is an update of PIXm that was previously published in PDF form. This new publication is published in HTML form with a full set of conformance resources and examples. New functionality has been added to support a patient identity feed to inform the Patient Identity Manager of changes to patient identities.

https://profiles.ihe.net/ITI/PIXm/index.html

Patient Demographics Query for Mobile (PDQm) - Rev. 2.3.0. This revision was created using the Implementation Guide publisher. This is an update of PDQm that was previously published in PDF form. This new publication is published in HTML form with a full set of conformance resources and examples. No new features were added.

https://profiles.ihe.net/ITI/PDQm/index.html

Mobile Access to Health Documents (MHD) - Rev. 4.0.2. This revision updated the publication to use the new Implementation Guide template. No new functionality was added.

https://profiles.ihe.net/ITI/MHD/index.html

Mobile Care Services Discovery (mCSD) Use Cases White Paper - Rev. 1.1 . This white paper presents multiple use cases that mCDS supports.

https://profiles.ihe.net/ITI/papers/mCSD/index.html

IHE Publications

These new publications are a part of the IHE family of Implementation Guide Profiles, and can be found at https://profiles.ihe.net

IHE is dedicated to the task of use-case driven Implementation Guide authoring, publication, maintenance, and testing. There is a long list of IHE Profiles (a form of Implementation Guide) supporting Healthcare IT workflows within and across the Healthcare space.

IHE Connectathon

These updated Implementation Guides will be available for formal product Interoperability testing at the upcoming IHE Connectathons https://www.ihe.net/participate/connectathon. 

IHE IT-Infrastructure fall 2021

IHE ITI Tech met last week and had a very productive meeting. It seems we are getting the hang of virtual meetings. I will say that they are still about 50% as productive as a face-to-face. There are times at which we are more productive, but there are times when the virtualness gets in the way. This can be due to the lack of non-verbal queues (oh, you really didn't understand what I said), or inability to stand up and draw a picture on a whiteboard, or because everyone is multi-tasking.

Finished this meeting: (will take a week or two to be actually published on https://profiles.ihe.net )

• mCSD Whitepaper 
• PIXm in IG format with Feed transaction - for Trial Implementation
• PDQm in IG format - for Trial Implementation

Continuing Work Items:

• Quality improvements to the HTML publication of the Technical Framework publications
• Maintenance (CP)
• MHD to a Federation task-142

New Work Items:

• Convert mCSD to IG Publisher task-151
• Create Implementation Guide Profile ATNA auditEvent patterns for generic FHIR RESTful transactions with pattern informing IHE profile further specializing task-144
• Convert Metadata Handbook to html publication without technical changes task-169
• Convert MHDS to html publication without technical changes (not an IG yet) task-166 

Ill cover these in other articles.

Security of #FHIR implementations concerns

Security Report: "The New Healthcare Ecosystem will depend on FHIR APis, but Are They Secure?"

Alissa Knight did some invited and funded cyberSecurity research and found some good and some bad. No-one should be surprised by that conclusion. The point we should take from this research is that 

1. EHRs are doing a good job of securing their FHIR implementations
2. FHIR is good and worthy
3. There is room for improvement in some implementations 
4. There are included recommended improvements. 

Some have take a very negative view of the research, most of this negativity is unfounded and driven by the fact that Alissa is excellent at marketing and drama. She has excellent presentation skills, excellent writing skills, excellent hacking skills, and excellent artwork. 

This research was funded by a vendor that provides security frontend for APIs, so certainly there should be some consideration here. I, however, have good reason to believe that this funding did not influence the research. Alissa has a couple of decades of proving she knows what she is doing. This is not just fake research complaining about products that didn't use the vendors solution. Yes there is one mention that a product that did use that vendor solution was not found vulnerable, yes the vendor got mention at the bottom of the report for funding it.

This was not an attempt to bring down FHIR, but rather to challenge us all to be better.  This report says nothing negative about the FHIR standard, it was focused on implementations. 

There is some bad news, some implementations were specifically disgustingly bad at securing the data, and they had lots of data (aggregators). These services had signed up to be part of this research. They were informed of the problems. The report was expressing the trend, not the specific details. Alissa addressed this during the YouTube below, and also on twitter later.

Alissa hosted a Ask Me Anything on live YouTube, the recording here

Deeper dive

The report stands alone, and I have tried to come up with better ways to say what it says, but I just can't. The things that Alissa found were very remedial cyber security issues. Editing URLs in the browser to try to get at obvious other information. Using legitimate security tokens for things it was not intended to do. ...  Alissa has so much deeper skills that she simply never needed to rely on. She goes into all of these details about as detailed as is reasonable without naming products. 

Page 16 was critical for me. I literally was stunned. Not an exaggeration. I knew that there would likely be mistakes, hence why above I said we all should not be surprised she found issues. It was clear there would be issues found. But the class of issues found are just unexplainable.  All of the issues failed to implement even the FIRST section on the FHIR Security page.

Data Aggregators were the worst offenders in my view. I know they provide a useful service, but they do it in ways that are not transparent, and they clearly don't take their responsibility seriously. They have been around for decades, so likely these same bad security implementations were just as bad on their previous proprietary "secret" APIs. The use of FHIR just makes them more obviously bad.

The last bullet on page 16 was the worse, quote:

With one patient engagement app, the API endpoint sent me all the patient and clinician records in its database, indicating it was using the mobile app to filter out just my record.

NO WAY!!??? yup, that happened

mic drop

Conclusion:

I need to bring this back to positives... FHIR is good, the EHRs are good, many apps and services are good... but some are really NOT.  

FHIR is a building block. It has so much to give to us humans (and animals). It will enable many things while it transitions from a "Standard for Trial Use" to something that is used to build CarePlans, Patient Engagement, Emergency Medicine, Disaster Management, Public Health, Artificial Intelligent clinical decision support aids, world wide COVID-19 tracking, and COVID-19 vaccine credentials...  helping patients stay healthy rather than get unhealthy in the first place ...

FHIR is built upon http RESTful concepts, Document concepts, and messaging. These platforms have security and privacy layers available to be used. Healthcare does not need to invent security, we just need to implement it properly. Mostly apply the security layer to the interactions following good policies. Have bad policy, is bad. Have bad implementations, is bad. Have no security, is bad.

All systems that have access to health data need to be designed from the beginning with Privacy Principles which include Security and Security which is about (protecting risks to Confidentiality, Integrity, and Availability).  Failing at "Access Control" makes me wonder about all the other opportunities to have forgotten Privacy and Security in the design.

Now is a good time to be reminded. We are not too far gone, we can do the right thing.

FHIR is the right standard to work with. 

Others comments

• Youtube post release discussion including Grahame and John
• SC Media article
• Grahame article
• Keith article
• Keith tweet storm
• Sean article
• Alissa twitter responses 

#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

• Basic Audit Implementation Guide
• IHE- Mobile Access to Health Documents (MHD) - has AuditEvent profiles 
• IHE Patient Demographics Query for Mobile (PDQm) - has AuditEvent profiles
• IHE Patient Identifier Cross-reference for Mobile (PIXm) - has AuditEvent profiles
• IHE Internet User Authorization (IUA) - has profiled AuditEvent but does not have profiles

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

* Foundation of IHE - DSG profile

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.

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. 

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). 

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.

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

• Security and Privacy Module
• Security Principles
• Security Labels
• Signatures Discussion
• Signature Datatype
• Consent Resource
• Provenance Resource
• Audit Event Resource

IETF Best Current Practice for 

• TLS -- BCP 195
• HTTP -- BCP 56
• OAuth -- not yet assigned a number, but draft available

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

• Presentation at http://bit.ly/smart-fhir-tech
• https://docs.smarthealthit.org/ 
• New version of SMART-on-FHIR draft http://build.fhir.org/ig/HL7/smart-app-launch/

IHE profile on OAuth for business to business http REST

• Internet User Authorization (IUA)

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

My mapping between IHE-BPPC and FHIR Consent

HEART - alternative Consent as a Service using OAuth/UMA

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: 

• https://chat.fhir.org Security & Privacy Stream 
• HL7 Security Workgroup

• FHIR Security call on Mondays 12 noon eastern

User Management on FHIR

 The FHIR standard is a data-model and interface (API) specification for access to health-care data. As such this is a domain of data that is specific to the health of subjects. This is a very big domain, but not all encompassing. When interacting with domains outside of health-care, links between the data is done via Identifiers. FHIR has a data type structure for an Identifier that is designed to hold any kind of globally unique identifier. This identifier data structure thus would hold identifiers such as

• Social Security Number
• Drivers License Number
• Medical Credential Number
• Employee Number
• Organization Identifier (Employer Tax Identifier, domain name, etc)
• National Provider Identifier (NPI)
• bank account number

and

• User Identity (username, userId, etc)

Note that Identifier is also used for things besides human identifiers. Such as legal-case-number, global-shipment-identification-number, vehicle-identification-number (VIN),  device-serial-number, animal-identification-number.

All of these are information managed in another domain outside of FHIR. 

User Management is driven by Organization needs

The user management within an organization will be driven by the needs of the organization. Often this will be driven by early applications (aka the oldest application). Many organizations use Microsoft Active Directory, which does support Authentication and Authorization standards of SAML and OAuth. 

Other platforms for User Management would be Apache Directory, Open LDAP, or an external OAuth provider like Google/Facebook etc.

RESTful standard for User Management

There is a RESTful standard API defined in IETF -- System for Cross-domain Identity Management: Protocol (SCIM) -- RFC-7644

This has not received enough interest to be put into the FHIR security pages as a recommendation. I understand that Grahame has leveraged this in his reference server. There is an old, and unmanaged, page that Grahame created comparing SCIM to FHIR models., and his blog. The Health Samurai also indicates it supports SCIM.

I note that Microsoft Azure Active Directory seems to use SCIM as their API for user management. I am not an expert on Microsoft Active Directory, so I might be wrong. Would love to get comments confirming or redirecting my understanding.

FHIR Security & Privacy Tutorial

HL7 FHIR Security & Privacy

The HL7 FHIR Security & Privacy online class 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).

Update: Here is a later article with links to the recording ($$) and with the links we spoke of and were embedded in the presentation.

This will be a refreshed version of the Tutorial I have given within HL7 before.

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

In the past, I have had to compress these into two parts, but will be able to give them in the natural three parts

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
• IUA
• Mutual-Authenticated TLS
• Access Denied Responses

Part 2 - FHIR capability

• Provenance
• Basic
• Digital Signature
• Audit Logging
• Audit Reporting
• Audit Purging
• Consent - for Privacy
• HEART
• 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
• Extra-Sensitive Treatment
• Share with Protections
• 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.