Thursday, August 22, 2019

FHIR Scaling to a Nation

Most discussions about FHIR are simple interaction diagrams like this:


Many Sources (n != 1)


The Real story needs to consider that the "Source" above is a single box representing 10,000 potential source systems that hold data about the patient: (map is a static view of CareQuality network)

More important is that the above map only represents Clinical sources. There are also Payer sources, and many more...

So there is a real scale problem with the above.

If we look at the use-case of Treatment needing to get a current view of data. We could imagine that EACH of these Sources will publish a FHIR endpoint and publish US-Core based Common Clinical Data Set (CCDS). Thus your Source system will need to query them all.

The diagram is not all that more complex as in a sequence diagram we just add a loop. But we all need to understand that loop is multiplied by all sites that indicate the patent has data

Combining Many Sources


You will note that EACH Consumer system needs to do some detailed combination of the results.

  1.  Hope all provide well constrained (e.g. US-Core)
    • need to be robust to variations
  2.  Combine current data from many sources, 
    • leverage any List indicating reconciled at that site
    • hope republished data preserved original id
    • resolving duplicates 
    • leverage any Provenance indicating duplicate resolution
  3.  resolving invalidated deactivate
    •  watching age and Provenance
  4.  harmonize vocabulary differences
  5.  Provide Provenance back to source REST resources

Not everyone will publish US-Core level resources

Reality is that many of the sites won't provide US-Core level access, but will only provide Documents. Best-case is that it is a On-Demand Medical Summary, which does cover the same data and does provide only current data. But may be a set of discharge summary, or episode documents.

So one might need to combine REST access with Document content.  One could optimize to NOT pull documents from sites that provided REST access to current data.

I show this being implemented by an Intermediary. I am not proposing a common Intermediary, although that is possible. I suspect that these Intermediary will have organizational customization. That is that the Consumer organization will want to control the algorithm and output. Thus the Intermediary is likely as many as there are Consuming organizations. This might be able to be generalized for a region. But the more one moves it to a central position, the more one creates potential Privacy concerns.




NOT fully discussed here 


I did not address how the sub-set of sites that have data on this patient are discoverd. There likely needs to be some level of Federated search, or centralized Record Locator, or a combination of both.

I did not address how security is addressed. There could be a national managed security infrastructure, but that is another kind of scale problem. It is possible, but not addressed in this article.

I did not address how Privacy is addressed. I expect that this will continue to be a Source side management. That is that each Source manages their responsibility to protect the data and to release it as appropriate according to the Consent they have on file. There likely is a need for "Point-of-Care Consent".

Likely many more too

----------------------------------- websequence diagram source ---------------------------

title Interop tendency

participant Source
participant Intermediary
participant Consumer

note left of Source: Broad tendency

loop Current Details
note right of Source: Many sources for each site patient Visited
Source->Consumer: FHIR REST
note right of Source
 Note that results can include 
 DocumentReference to documents flow
end note
end

loop Discharge or Episode or Problem or CarePlan or Notes
note right of Source
 Targeted to one document sources or all
 Clinical Documents cover 5 Principles 
 * Persistence
 * Wholeness 
 * Stewardship  
 * Context 
 * Potential for authentication
 Documents could be CDA or FHIR documents
 Not optimial but may be TEXT or PDF 
 Transport can be XD* or MHD (FHIR DocumentReference)
end note
Source->Consumer: FHIR/CDA Document

end


loop Population on a cohort
note right of Source: Many sources

Source->Consumer: FHIR Bulk access
end

note left of Source
 Comprehensive view 
 using Intermediary
end note
opt Reconcilled
Consumer->+Intermediary: Request for data
loop over all sites with current
Source->Intermediary: REST
note left of Intermediary
 Hope all provide well constrained (e.g. US-Core)
 Combine current from many sources, 
 * leverage any List indicating harmonized
 * resolving duplicates, 
 ** leverage any Provenance indicating duplicate resolution
 * resolving invalidated deactivate
 ** watching age and Provenance
 * harmonize vocabulary differences
 Provide Provenance back to source REST resources
end note
end
loop over all sites with Documents 
note left of Intermediary: e.g. IHE mXDE Profile
Source->Intermediary: Document
note left of Intermediary
 Decompose Documents
 Combine document data with current
 Provide Provenance back to source Document
end note 
end
Intermediary->-Consumer: FHIR REST
end

Wednesday, August 21, 2019

Treatment based interop is best using Documents

I want to drive discussion on this, so will take a position that many may disagree with. This position is that for Treatment and Payment the best format for clinical data is Document based. The consumption side is a different topic, and today a big frustrating point. Although publication should be Document based, these documents must be decomposed and analyzed relative to the current Treatment situation.

Why?

Because the output of a prior Treatment needs to be tied off with conclusions supported by the evidence known at that time. The document must be Authentic and Authenticatible. The document must be complete story of the whole story around that treatment.  The Clinical Document meets a set of Principles that all are critical.

How?

The document must be both narrative and coded. This CDA is a good solution, but a FHIR Document is better. FHIR document is based on the fundamentals of FHIR, but in a Document format. A FHIR document is 100% FHIR. This it is well formed and easily understood.

Better, publish both.

Where?

The document exchanges we have today can carry a FHIR document just as easily as CDA or PDF.

Documents can be anything, not just a highly coded discharge summary. They can be informal clinical notes. They can be fragments of data that do not meet the full principles of a Clinical Document. These do however fit the broader definition of a document. These documents are also well handled by the document exchanges.

When NOT?

Documents have narrative but this narrative should only be a last resort on the consumption side. Please don't expect the clinician or patient to directly view these Documents, no stylesheet will make this worthy.

Discuss...

Friday, July 26, 2019

IHE Profiles on FHIR R4 now have conformance resources available

This week the ITI and PCC face-to-face meeting approved new/updated FHIR conformance resources (ImplementationGuide, StructureDefintion, CapabilityStatement, ValueSet, CodeSystem, and OperationDefinition) for publication. These have been aligned with FHIR R4.


* PIXm -- supplement soon to be released to Public Comment
* NPFS -- supplement soon to be released to Public Comment
* (mACM) -- supplement soon to be released to Public Comment
* MHD
* NPFS
* mCSD
* ATNA
* QEDm
* DCP
* DCTM
* PCS


More details on these at http://wiki.ihe.net/index.php/Category:FHIR


There was also agreement to make public knowledge that we are managing these formal conformance resources on an IHE managed GitHUB repository dedicated to FHIR conformance resources related to Normative IHE Profiles. As before the supplement text is the normative specification, and the conformance resources are informative.

https://github.com/IHE/fhir


These have also been reflected on the IHE FTP site in the previously published location. The FTP site will be maintained for a period of time while we continue to mature our publication mechanisms.
ftp://ftp.ihe.net/TF_Implementation_Material/fhir/


Please report any errors or improvement opportunities. These conformance resources are not normative, so many methods of reporting should work. The CP system can be used, but is not required to be used at this time.

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