Tuesday, June 18, 2019

ACME is not appropriate for Heathcare use

There is a new standard from IETF -  ACME -- https://datatracker.ietf.org/doc/rfc8555/

Abstract

   Public Key Infrastructure using X.509 (PKIX) certificates are used
   for a number of purposes, the most significant of which is the
   authentication of domain names.  Thus, certification authorities
   (CAs) in the Web PKI are trusted to verify that an applicant for a
   certificate legitimately represents the domain name(s) in the
   certificate.  As of this writing, this verification is done through a
   collection of ad hoc mechanisms.  This document describes a protocol
   that a CA and an applicant can use to automate the process of
   verification and certificate issuance.  The protocol also provides
   facilities for other certificate management functions, such as
   certificate revocation.
The ACME protocol is the standardized variant of "Lets Encrypt" certificate issuance. This is NOT appropriate for healthcare use, as this model of certificate management is primarily intended to make the process of server identity proofing as fast as possible. The intended result is that more web servers would support TLS encryption, with the restriction that there is no authentication of the identity proofing. 

This is very counter to the use of certificates and TLS in healthcare as recommended by IHE-ATNA profile. The ATNA profile specifically focuses on mutual-authentication using TLS to a locally known trusted authority. In this profile we explicitly explain that this model should NOT use the certificate store that is managed by web-browsers. This ACME model weakens even the web-browser certificate management.

I would recommend against any use of ACME for ATNA based secure node or secure application; and would recommend against use of ACME managed certificate for ANY healthcare traffic, even simple HTTP based traffic.

Thursday, June 13, 2019

XDS sha-1 is still okay

I get the following question about every other month. Here is the version I just responded to:

In this project I encountered a requirement to use SHA-256. Apparently this was in reaction to the SHA-1 collision vulnerability (https://shattered.io/) from late 2017. IHE XDS requires the hash to be SHA-1. Have you heard of any requests to change that?

There is no requirement in IHE that a Document Consumer must check the size+hash against the document they have received. This would be a policy choice. This is a policy choice that IHE does enable. That is to say that IHE includes a requirement to set the size/hash value to enable this downstream check.  The main reason to not mandate it is that there are few cases where the normal transport, especially TLS, doesn't already confirm integrity. If we added mandatory check of the hash/size, then we would need to express what must then be done if a failure is detected.

Intended failure detection

The hash element is intended to be used with the size element to detect storage, encoding, or transport errors. Where a Document Consumer receives the metadata (DocumentEntry) from a Query from the Registry; and the Document Consumer receives the document via Retrieve transaction from the Document Repository; the check of size+hash is a mechanism available to the Document Consumer to assure that the document they got is very likely the document described by the DocumentEntry.

In the most distributed configuration of XDS there is one Registry managed centrally, and many Repository servers maintained at each of the custodians of the documents. The kind of errors this can detect are errors such as bit loss while in storage, encoding loss due to errors in encoding algorithms, or transport failures due to multiple hops or intermediary.

Note in the diagram above, that the Green line is the pathway the DocumentEntry follows, where as the Orange line is the pathway the Document follows. The loops represent persistence for hours or decades.

The other transport options in the Document Sharing (XD*) family are less distributed, but the metadata is always separated from the Document itself.

The failures of sha-1 are all specifically failures to detect attack by a malicious and well-funded attacker. The failures of sha-1 are not the kind of failures that would randomly happen due to technical failures.  It is important that one recognize that XDS mechanism is both a sha-1 hash and a size. So an attacker must get a sha-1 collision without changing the size of the document. A determined attacker will just replace the hash/size elements in the Registry, for which this kind of successful attack would not matter if the hash was sha-1 or sha-256.

I emphasize that the size+hash is a mechanism that leverages the fact that the metadata (DocumentEntry) traverses a different pathway than the Document. They both are managed in different systems. So the intention of the size+hash is to detect technical (accidental) failures in these various systems and interconnections.

High Security

The metadata size+hash is not a high-security mechanism. If one is concerned about malicious acts of deception, then one must use Document Digital Signatures.

Document Digital Signatures would use SHA-256 (or better), and also have timestamp, purpose of the signature, and are counter signed by a verifiable identity backed by a certificate chained to a certificate authority that manages trust and revocation status. Without the signature across the hash, and a timestamp, one does not know that the digital signature is valid. 

So if an organization is really serious about digital signatures, then they should be mandating Document Digital Signature. Further, they must then make a clear policy on what Document Consumers must do, Such as when is it mandatory to check the signature, what is to be done if there is no signature, what is to be done if certificate revocation checking can't be done, what requirements of timestamp are necessary.

Once all this analysis of overhead involved in Digital Signatures discussion happens, they realize that this overhead is likely too expensive for the benefit. Backing back from that, they realize that sha-1 plus size checks are sufficient most of the time.

There is an alternative mechanism built into Document Digital Signature Profile that many people may not be aware of. This mechanism has been promoted by the Italian domain. The mechanism is to upon Provide and Register, they sign the SubmissionSet as a Document Digital Signature, and thus at any time downstream a Document Consumer can confirm that the documents they are using are those in the original SubmissionSet as published by the original Document Source. This Document Digital Signature is a end-to-end, but is not a declaration of the author.

Good for Intended use

I would never advocate for use of SHA-1 within a Digital Signature today... but the XDS mechanism is not a Digital Signature, it is an integrity protection. There is a high security mechanism in Document Digital Signatures or SubmissionSet signature.


Tuesday, June 11, 2019

Patient Engagement - Access Log

The HIPAA Accounting of Disclosures is obsolete and dangerous.

Patients are expected to become more engaged with their healthcare and do this using applications. Applications are sometimes software that runs on the Patient's phone, but sometimes software running at a third party cloud. Patients should not be expected to have done a software code review of these applications, and a legal review of the applications Privacy Policy. This would be ideal, but is simply not realistic.

I am using the word "applications" mostly generically, but clearly "FHIR Applications" are a proper subset of applications. As FHIR matures, this subset may become the only set of applications. This would be a good thing.

The Patient's choice of applications should be rather open ended, today. This eventually will become more constrained, but during this wild-wild-west time for healthcare applications we simply don't know enough about the potential good or bad that these applications might cause. I am sure there will be a set of these applications that are out-right-dangerous. I encourage us being open at this point because any rules we might put in place might inappropriately restrict good applications. With a few years into the future we will have a much better idea of how a community evaluation can help keep patients safe. 

But just because I think we should be open with allowing the applications, does not mean I trust them...

One small step that I would like to promote is that the healthcare provider that holds data on a patient MUST record all accesses to that data, and provide the patient visibility into that audit log. This is specifically recording of the API access requests made, and if they were successful or rejected. It is important to record the rejections and the successful transactions. It is also very important to record what was requested and what security token identity was used.

For the most part this audit log would be just the FHIR API "REST" activities.

REST operation logged on server (example)rest RESTful Operation[code] defined for operation CRUDAgent for logged in user, if available.
Search operation logged on server (example)rest RESTful Operation[code] defined for operationE ExecuteAgent for logged in user, if available, and one object with a query element.

This Access Log should include ALL access, not just those types of access that qualify as "Accounting of Disclosures". The Accounting of Disclosures has too many exceptions, and thus the report given to the patient is not valuable. It would especially not valuable for the Applications space.

This Access Log would include clinician accesses of the data, researcher accesses of the data, etc. But would also include logs of accesses that applications are claiming are on-behalf of the patient themselves.

The Access Log as I am speaking about it here is just the log that is maintained by a Healthcare data custodian, about the API accesses to the data on that patient in the control of that custodian. Where a Patient has many data holders, the patient would need to get a comprehensive audit log by gathering the audit logs from each of the custodians that they have data at.

Log analysis is not something that I expect that a Patient would know how to do, but once we have agreement that each Custodian would maintain a FHIR AuditEvent log of API access; then we can mandate that the custodian also provide a FHIR AuditEvent API access to that audit log. Once we have an API to the AuditEvent log of API calls; then someone can write Application that gathers the audit logs together and does analysis. This analysis would do typical audit log analysis looking for patterns, getting approval of a well understood pattern. Once well understood patterns are identified, then the application would alert the Patient when an unusual pattern is seen.

The IHE ATNA profile has been updated with full support for FHIR AuditEvent; so this is a really good specification to support this model.


Wednesday, June 5, 2019

IHE Audit Log Specifications

For those that struggle with the way that IHE documents the specific requirements of audit logging per type of security event or per ITI transaction; there is an easier tool. The IHE Gazelle "Security Suite" Tool has each audit log message broken down and explained.

My hope is that soon this tool is the way that IHE documents the transaction patterns, so that the supplements and technical-framework documents no longer have the ugly tables.

Here is what shows for the IHE ITI-2 User Authenticate Login message: 

The Gazelle tool is also used for Testing...

Here is the generic Security relevant events. These are expected of any application/service that participates in these security relevant events. DICOM -- PS3.15 - A.5.3


ITI-TF-2a 3.2.6 IHE - ITI-2 User Authentication Login
ITI-TF-2a 3.2.6 IHE - ITI-2 User Authentication Logout
ITI-TF-2a 3.10.5.1.2 IHE - ITI-10 Patient Identifier Cross-reference Consumer audit message
ITI-TF-2a 3.10.5.1.1 IHE - ITI-10 Patient Identifier Cross-reference Manager audit message
ITI-TF-2a 3.18.5.1.1 IHE - ITI-18 Document Consumer audit message
ITI-TF-2a 3.18.5.1.2 IHE - ITI-18 Document Registry audit message
ITI-TF-2a 3.21.5.1.1 IHE - ITI-21 Patient Demographics Consumer audit message
ITI-TF-2a 3.21.5.1.2 IHE - ITI-21 Patient Demographics Source audit message
ITI-TF-2a 3.22.5.1.1 IHE - ITI-22 Patient Demographics Consumer audit message
ITI-TF-2a 3.22.5.1.2 IHE - ITI-22 Patient Demographics Source audit message
ITI-TF-2b 3.32.5.1.1 IHE - ITI-32 Portable Media Creator Audit Message
ITI-TF-2b 3.32.5.1.2 IHE - ITI-32 Portable Media Importer Audit Message
ITI-TF-2b 3.38.4.1.4 IHE - ITI-38 Initiating Gateway audit message
ITI-TF-2b 3.38.4.1.4 IHE - ITI-38 Responding Gateway audit message
ITI-TF-2b 3.39.4.1.4 IHE - ITI-39 Initiating Gateway audit message
ITI-TF-2b 3.39.4.1.4 IHE - ITI-39 Responding Gateway audit message
ITI-TF-2b 3.41.5.1.2 IHE - ITI-41 Document Repository or Document Recipient audit message
ITI-TF-2b 3.41.5.1.1 IHE - ITI-41 Document Source audit message
ITI-TF-2b 3.42.7.1.2 IHE - ITI-42 Document Registry audit message
ITI-TF-2b 3.42.7.1.1 IHE - ITI-42 Document Repository or Integrated Document Source/Repository audit message


Saturday, May 18, 2019

Record Location on FHIR - aka Patient Identity Correlation

IHE has created
a FHIR based Patient identity management system for health information exchanges. This builds on PDQm and PIXm, by adding a Feed mechanism, and a subscription to the Feed. Added to this is a set of requirements and expectations around how Merging (Link and UnLink) are to be implemented.

The result of a Merge is that the two identities of a Patient are linked, one become master, and all the data recorded against both are considered one Patient. This means that a system implementing the Profile will treat a query request for one of the identities as if it was a query against all the linked identities. Putting the burden of link management and comprehensiveness of the query results upon the server, so that applications don't need do multiple queries to get a comprehensive patient record.

There is expected further refinement of this after Public Comment, and in coordination with HL7 Patient Administration workgroup efforts on the same topic. It is possible that a formal Merge will be supported, but in FHIR a Merge comes with some downsides. When FHIR is a front-end to a non-FHIR system (e.g. an EHR), the result will likely look like a Merge, in that only the surviving identity will ever be seen from again. Where as a native FHIR Server is used, a link is more friendly to the integrity of the data persisted in FHIR Resource form. Especially if those FHIR Resources have digital signatures on them.

What we also don't quite know is how to scale a Patient Identity Management system to a very large federation. How to keep track of communities that are behind communities (nested communities). What additional functionality that FHIR can bring to the table, what issues will appear once we start using FHIR Resources to discover the locations where Patient Data exists. It feels like this will be easy, it feels like we have learned from v2 and v3; but there is always dragons hiding.

So, does FHIR Patient Identity Management replace XCPD which is based on HL7 v3, or PIX/PDQ which is based on HL7 v3? The answer is, "Yes, eventually". But that timeframe is likely 5-15 years. That is to say that the backbone that exists today using HL7 v2 ADT, and the XCPD infrastructure is functioning and will continue to function. There is no need to rip-and-replace. However there is a STRONG need to provide more simple API into those environments for NEW partners and applications. This is where PDQm, and PIXm have been for a while. Now there is the Feed and Subscription to the Feed that this new profile brings.

So, yes HL7 v2, v3, and FHIR (four) will be used together for different endpoints. The common factor is the Patient Identity, Patient Demographics, Patient Address, Patient Phone Numbers, and other non-patient identifiers like SSN, Drivers License, Insurance ID, etc...

Thursday, May 9, 2019

FHIR Security & Privacy activities

This is an update of what is going on in Security and Privacy in, and around, the FHIR specification. 

---------------tl;dr-----------------------

  • FHIR R4 includes Security Considerations classification
  • SMART-on-FHIR first flavor is Normative
  • Addition of X-Provenance and X-Consent http headers
  • GDPR assessment against FHIR indicates good coverage of needs in FHIR already
  • Maturing AuditEvent and Provenance to Normative by FHIR R5
    • HL7 Implementation Guide on Basic Provenance (CDA and FHIR)
    • IHE updated ATNA to include FHIR AuditEvent feed and query
  • Signature datatype not likely to be R5 normative candidate

-----------------Details -----------------------

Overall Security Considerations:

The FHIR R4 specification now has an overall Security Consideration Classification. This spans the whole of the FHIR specification such that each Resource is assessed into one of four buckets of Security Considerations: Patient specific, Other Identified Individual specific, Business sensitive, and Anonymous Readable. These are not mutually exclusive classifications, but rather a "tendency". That is to say that each resource could cover many of these classifications, but tends to fall into the specified classification. The main goal of the classification is to raise awareness that the FHIR specification covers use-cases other than just sensitive patient data. The Security WG set the initial assessment, but the owner of the Resource can re-classify.  Also, actual use will be context specific. There is nothing wrong with using the 'Patient" classified resources in a way that is fully anonymous because they are holding synthetic data.

GDPR driven activities:

The Security WG has done an assessment of FHIR in the context of GDPR. This has produced a white paper that is available informally today. The GDPR assessment has driven some of changes that are already in the specification, and is also driving some future changes or implementation guides. These things have not really started formally yet, but include :
  • consent decision service -- to enable a FHIR Server to ask a service for Permit/Deny on an otherwise authorized request
  • basic Privacy Authorization Consent IG to support freely given and informed privacy authorizing consent
  • erasure operation to support GDPR and Right-to-Forget

SMART-on-FHIR:

The SMART-on-FHIR specification is now published in the basic form that is compatible with the original Argonaut version. This base-lines the standard at this starting point. There is interest in opening up for the next more advanced form of OAuth token support. One method uses a JSON Scope encoding, thus enabling far more comprehensive and complex scopes.

Maturity toward FHIR Release 5:

The Security Workgroup is going to work toward getting Provenance and AuditEvent to Normative by Release 5 (R5) of FHIR (Approximately end of 2020). This will be enabled by two different projects.  The HL7 Basic Provenance Implementation Guide, and IHE Audit Trail and Node Authentication updates to support FHIR. Signature datatype is not likely to go Normative in R5, but likely will have some advancements.

Plan to Mature Provenance:

The HL7 Basic Provenance Implementation Guide is getting started, so there is no specific conclusions yet. That said, the goal of this project is to define realistic and effective guidance on implementation of Provenance in a cross-organizational health information exchange (HIE) for the purpose of Treatment (may be Payment). This project is not addressing the Provenance requirements for within an organization. This project is not addressing ALL possible use-cases for Provenance, such as supporting Clinical Research. The most important part of the scope of this project is to set requirements that are as minimal as possible, yet effective for supporting Treatment. Counter this against a comprehensive Provenance implementation that would likely have well over a dozen Provenance records for any one clinical object record. Meaning that in a fully advanced Provenance it is very likely that Provenance is 10x the clinical data.  This Implementation Guide will drive public comment ballot, comment resolution, improvement of the core Provenance resource, and testing at Connectathon.  This is the maturity steps that the core Provenance resource needs to approach Normative in R5.

Note there are some Implementation Guides that have included Provenance guidance and constraints.

Plan to Mature AuditEvent

The IHE Audit Trail and Node Authentication (ATNA) project will help mature the core AuditEvent resource in support of Normative in R5. The ATNA profile is one of the oldest profiles in IHE, but has seen a major change to add FHIR based interactions. Last year there was an update of ATNA to add a query one could make of an Audit Repository to support reporting and alerting such as a report for Accounting of Disclosures, Access Log, and to support investigation of security and privacy incidents. This year IHE has added a AuditEvent feed support to support FHIR based applications recording AuditEvents using http RESTful FHIR create. Thus now the ATNA profile has support for recording an AuditLog, and queries.  This is going through a Public Comment ballot in the coming months, and will be setup for testing at IHE Connectathon in the future.

Advancements since R4

Provenance has not changed much yet, although there is a related abstract Provenance service ballot going through the HL7 ballot process. This abstract Provenance service work may impact the FHIR Provenance resource, but no changes have yet been proposed.

Provenance X-Header:

In FHIR R4 there is a new capability that may not be as well known. When an app is creating a FHIR Resource (for example an Observation), that application likely has a very rich understanding of the context of the creation event, so could provide a Provenance. The historic way it could do this was to either create the Observation, then create the Provenance; or it could use a Transaction to send a Bundle with both the Observation and Provenance. These do work, but there is a question of making this more easy. So there is now a http "X" header that one can use in a simple RESTful create/update to also carry the Provenance. Thus a normal http RESTful create of a new Observation can carry the app's definition of the Provenance in the http header, while the Observation is in the body. 

Consent X-Header:

A joint effort with CBCP has moved to add an X-Header to support an app asserting that a FHIR Consent authorizes the request being made. This is a http "X" header that holds the URL to the FHIR Consent. The Server is not obliged to consider the Consent, but it may consider it. That is to say that the use of this "X" header will only enable actions that the access control protecting the data also agrees with. The prime use-case for this feature is to enable a real-time point-of-care capturing of a Consent from the patient that authorizes the interaction. Where prior to having this Consent, the request would be rejected, but with appropriate proof that an informed and freely given Consent would now enable access. A similar "point of care consent" interaction is supported in some Nationwide Health Exchanges such as CareQuality.

Signature:

The Signature datatype is receiving some interest. Given that the primary function of a digital signature leverages external Digital-Signature standards such as XML-Signature and JSON Signature. Thus we are not developing the technology of Digital-Signature. In the FHIR Signature Datatype, we are just exposing in a more friendly FHIR way some of the useful attributes about the signature. The Digital-Signature validation is done using the Digital-Signature standard. A new use-case that is driving some interesting new views is one that has a context of a Provenance "Service" that is managed independently from the Clinical repository. In this case a end-user may be using a clinical Resource and use a Provenance Service to discover the Provenance of that clinical Resource. In that case the Provenance is being managed independently from the clinical Resource and the pathway the clinical Resource was communicated; then the Provenance.signature does not need to be a non-repudiation, but can be a simple integrity check (e.g. sha256). See other issues on Signature


Monday, May 6, 2019

IHE ITI Spring 2019

Updated with Public Comment details available here

The IHE ITI, PCC, and QRPH workgroups met in OakBrook, IL this week at the RSNA Headquarters. We still are not meeting in Treviso Italy., but we have heard that the July meeting will be in Sardinia Italy. Right before the big tourism time. Specifically we will be at the Facilities of Sardegna Ricerche at Polaris, Parco Scientifico e Tecnologico della Sardegna, in Pula (CA), Italy. Great time to join IHE and have your company send you to the meeting.

The ITI committee this week finished up one small supplement on adding Facility support to the Mobile Care Services Discovery (Provider/Services Directory). This updates the version from last meeting. 

We approved for Public Comment three brand new Supplements

  1. Adding a FHIR AuditEvent feed capability to the ATNA profile. Thus the ATNA profile would now include a Query on AuditEvent to support reporting and alerting applications, and now a Feed (RESTful Create) of AuditEvent to support applications recording audit events.  This work item also updated the Query to FHIR R4, so this supplement is focused on FHIR R4. There is now good bi-directional support for the original DICOM Audit Message schema, and the FHIR AuditEvent. This gives applications flexibility on how they record auditable events. They can use:
    • UDP Syslog - DICOM XML schema
    • TLS/TCP Syslog - DICOM XML schema
    • http/REST - FHIR JSON AuditEvent
    • http/REST - FHIR XML AuditEvent
  2. Adding support to XCA for a deferred response mode to support responding organizations that need significant time to complete a request. For example where a responding organization holds large quantities of historic paper records, which they will make available, but want specific patient request to trigger them scanning and indexing that data. In this way they can receive a request for a specific patient, they can respond that they do have data, but need a day or week to complete the request, then as they scan the data they can feed the data back in bunches.  This work is similar to a deferred mode in XCPD, and much of the technical work was done many years ago in a white paper by Karen.
  3. Creation of a FHIR based Patient identity management system for health information exchanges. This builds on PDQm and PIXm, by adding a Feed mechanism, and a subscription to the Feed. Added to this is a set of requirements and expectations around how Merging (Link and UnLink) are to be implemented. The result is that when two identities of a Patient are linked, one become master, and all the data recorded against both are considered one Patient. This means that a system implementing the Profile will treat a query request for one of the identities as if it was a query against all the linked identities. Putting the burden of link management and comprehensiveness of the query results upon the server, so that applications don't need do multiple queries to get a comprehensive patient record.
I am confident of the text we are sending to Public Comment, but I also expect that there is a significant amount of experience we need to gain before these become final specifications. That there will be more clarifications needed based on Trial Implementation, and the use-case that drives constraints will become more clear.

There are three very short webinars by the three editors of these Public Comment versions of their supplements. In these webinars they explain the use-cases that are being addressed, how they are addressed, and specific open issues we would like the Public Comment to help us with.