Monday, March 20, 2017

Healthcare Blockchain use?

Today starts the "Healthcare Blockchain Summit". I wish I could be there. What makes a good use of Blockchain, while also helping Healthcare? What are the questions Blockchain proposals need to answer? Blockchain is the hot word right now, Gartner indicates that it is still on the Peak of Inflated Expectations.
Gartner estimates 90% of enterprise blockchain projects launched in 2015 will fail within 18 to 24 months. Part of the problem is that the majority of enterprise blockchain projects don’t actually require blockchain technology. In fact, these projects would probably be more successful if they did not utilize blockchain.
Gartner give fantastic reasons, that I very much agree with. I am not going to duplicate them here as they do a great job.

Blockchain is a public ledger that is maintained by an interested network of systems. One can make a private blockchain, with private parties; this is possible, but I would argue takes much of the value out of the blockchain system. The blockchain can be validated by anyone, regardless of if they are just looking, just joined as a participant, or are a long standing validating node.

So what does someone proposing a Healthcare use of blockchain need to answer?

  1. What problem being solved? Why is that problem not best solved with 'classic' database? The excuse that the problem has not been solved today is not an acceptable answer. The problem has likely not been solved yet because it is not valuable to solve, so throwing expensive infrastructure like blockchain at it is unlikely to succeed.
  2. How is Privacy protected? The nature of blockchain is that the information put on the block must be sufficient for all parties to Validate. Putting purely encrypted information, or just pointers to data protected elsewhere is not helpful. This is why I recommend NEVER to put healthcare data on the blockchain. Just because healthcare data can't be put on the blockchain does not mean that there is no use of blockchain in healthcare. It is just not a treatment use-case.
  3. How is Identity managed? The nature of blockchain is that it is a system that does not require Identity to be known. There is an Identity linked cryptographically to information and signatures on the blockchain. One can always expose your own identity. Is this necessary with the proposed system? Exposing Identity might not be a bad thing, but it must be addressed either way. This fact means that blockchain is a ready made Pseudonym, hence why I proposed it be used to advertise availability of de-identified data.
  4. How is value created? Blockchain are expensive. How do participants gain value from their participation in the Blockchain? With Bitcoin, the value is equivalent to money, and is gained through proof-of-work, where part of that proof-of-work grows the chain with blocks offered by other participants, where each of those participants offer some bitcoin to have their block included. With a proposal to use Blockchain for Healthcare, one must have a good answer for how value is created, transferred, and consumed. It does not, and likely won't, be the same system as bitcoin. Hence why it is likely a different use of Blockchain for a healthcare specific purpose. Like my proposal to use it for Research Notebooks

Blockchain is good for?

I don't think that healthcare data should go into the blockchain. But there is good value in using blockchain to ( a ) advertise availability of data, ( b ) publish terms (smart-contract) of use that when met unlock access, ( c ) Merkle tree signatures used to validate authenticity of data managed elsewhere, ( d ) track revisions, and ( e ) record (audit) access and use.

Healthcare Blockchain - Big-Data Pseudonyms on FHIR
Blockchain and Smart-Contracts applied to Evidence Notebook

Friday, March 3, 2017

Multiple formats of the same Document content

I propose that “The most technically advanced” document format be considered the Prime, with all of the other formats considered Transforms (XFRM) from that prime document. Thus if the Document Source can create a C-CDA 2.1; then that becomes the prime. Yet if a Document Source only can create a C32 and PDF, then the C32 would be the prime. In this way, regardless of if the secondary formats were actually derived from that prime document, they would be Registered as if they were. This enables a Document Consumer to follow the XFRM link to the Prime without needing to understand all the formats presented. The Document Consumer can also follow the XFRM links down to all the ‘equivalent’ formats to discover those to choose from.

details.....

Now that C-CDA 2.1 is emerging, the following situation becomes more prominent. The situation is that the same content could be encoded in various document format types.
  1. How do you publish in XDS/XCA a set of documents that cover the same content but are different in their encoding format? 
  2. How do Content Consumers perceive when they find a set of documents that seem to cover the same content but are different encoding format? 
  3. How do we prevent miscommunication, or misinterpretation, or worse duplicate attribution. 
Various document encoding formats:

specification
year
mime-type
format
C-CDA 2.1
2015
text/x-hl7-text+xml
urn:hl7-org:sdwg:ccda-structuredBody:2.1
C-CDA 1.1
2013?
text/x-hl7-text+xml
urn:hl7-org:sdwg:ccda-structuredBody:1.1
CCD
2007
text/xml
urn:ihe:pcc:xphr:2007
C32
2007
text/xml
urn:ihe:pcc:xphr:2007
CDAR2 structured
2005
text/xml

CDAR2 unstructured
2005
text/xml
urn:ihe:iti:xds-sd:pdf:2008
FHIR Document
2017
application/fhir+xml
application/fhir+json

PDF - rendered view of C-CDA using publishers stylesheet
2001
application/pdf

XDS-I
2005
application/dicom

CCR
2005
application/x-ccr

Bluebutton text
2013
text/plain



As you can see, C-CDA 2.1 is not really special, but it happens to be the thing that has just released and C-CDA 1.1 are laying around. As proof, FHIR Documents will re-open this discussion. Especially with the CDA-on-FHIR efforts. Thus although C-CDA 2.1 isn’t special, it is a nexus today.

Example using a Discharge Summary:

As an example of a document that might need to be published in multiple formats is a Discharge Summary for an Episode of Care. This use-case is the most clear as to why the very same content might be made available in multiple formats. Other document types are also possible.

Why publish multiple formats?

The main reason to publish multiple formats is for the benefit of various Document Consumer systems. Given a Health Information Exchange, or Nationwide Health Information Exchange, there will be a variety of capabilities and use-cases for the hundreds-thousands of various Document Consumers. Some of these Document Consumers might not be updated at each revision of the C-CDA specification, thus they can only consume an older format.

All this for the benefit of the Document Consumer, but it creates a problem for the Document Consumer too. How do they know that the very same content is represented in the different formats, vs that the different formats are actually about different content? Ideally they would have some way of discovering this short of retrieving all documents and comparing them.

A user should not be bothered by making a choice between various encoding formats, all for the same content. It would be best if the Document Consumer could automatically pick the ‘best’ format. This pick, might be:
  • simply because that Document Consumer only supports one format. Example might be an old piece of software that can only consume C32 (aka XPHR). 
  • might be because a Document Consumer is able to render one format better than another format for a given context. For example, a patient view versus a clinical view. A Patient Generated Health Data (PGHD) CDA document vs a CCDA CCD. 
  • might be a good workflow reason to show a PDF rendered view, as that specific rendered view was that of the Document Source (publisher). 

Not rewriting history

It should be noted that I am not talking about going back in history to create more formats of documents previously published. Revising history is against medical-records principle.

Those old formatted documents must forever be supported by Document Consumers. That is to say that a Document Consumer should never remove the functionality it has to consume older formats.

What I am focused on here is the front-edge of standards advancing. What happens as ‘new’ formats become supported by Document Source. And how to best support Document Consumer needs.

Potential Solution

It would seem that the closest representation in XDS is the transform (XFRM) association, because it means two representations of the same information, as opposed to RPLC, APND, etc. However, it may not always be right to say one is a transformation of the other. They could all have been created at the same time, from the same underlying EHR data, simply for the purpose of satisfying the largest range of clients. In this case, which one is prime?

That said, a Transform (XFRM) association in XDS does have a directionality component. It has a source side, and a transformed side. Thus to



use the Transform (XFRM) association we need to determine a directionality. I look to IHE PCC and IHE ITI to see if there is a precedent. There is similar use of Transform (XFRM) in XDS-SD, and also APPC. In both documented cases the directionality component is left to ‘local policy’. So it would seem that the IHE committees have not yet decided.


I propose that “The most technically advanced” document format be considered the Prime, with all of the other formats considered Transforms (XFRM) from that prime document. Thus if the Document Source can create a C-CDA 2.1; then that becomes the prime. Yet if a Document Source only can create a C32 and PDF, then the C32 would be the prime. In this way, regardless of if the secondary formats were actually derived from that prime document, they would be Registered as if they were. This enables a Document Consumer to follow the XFRM link to the Prime without needing to understand all the formats presented. The Document Consumer can also follow the XFRM links down to all the ‘equivalent’ formats to discover those to choose from.

This all said, there could be some policy reason why a different format is considered to be the prime by the Document Source. For example that the Document Source publishes in C-CDA 1.1, and uses a stylesheet transform to produce the C-CDA 2.1. This said, a Document Consumer should be able to rely on the top most (Prime) Transform as the most complete and accurate.

Robust Document Consumer

Given that whatever guidance we advocate would be adopted over time and not uniformly, a Document Consumer needs to handle whatever is available, and be robust to formats that are not understood. Unfortunately, there is probably not a fully deterministic way to go. For example, a given Document Source might adopt this guidance but other Document Source might not, so some but not all equivalent documents would have associations.

Unresolved technical issues:

The various formats are not fully equal. Clearly a PDF format doesn’t carry the fidelity of data that a C-CDA 2.1 can. There might be use case where this difference is not a problem, but any loss of fidelity is potentially problematic. Thus there must be some recognition that the various formats might all be “Transforms” (XFRM), but are not equal. This is why I recommend the prime be the most technically advanced, so that the number of hops away from the prime is an indication of potential loss of fidelity.

There is no obvious metadata place for this ‘completeness’ or ‘accuracy’ or ‘integrity’ evaluation recognition to be placed. There are Vocabulary available in the Value-Set (integrity) recommended for ConfidentialityCode… I am not yet ready to recommend this.

Conclusion

This is just a recommendation. It might kick off a discussion in IHE to write similar recommendations. Not clear if this is a ITI or PCC responsibility.


Attribution: Tone Southerland and Joe Lamy both helped me with the content. Thank you!


Keith covered this in a different way back in 2009. focused more on template inheritance -- Template Identifiers, Business Rules and Degrees of Interoperability -- with a cool graphic