AMSUS talk on FHIR CarePlan as the goal app for Patient Engagement

Lighting the Pathway Through FHIR To Optimized Care Plans: A Case Study of MyHealtheVet and Next Steps (By Light)

The HL7 FHIR standard is gaining quick acceptance in the USA and globally. Every major EHR vendor now supports FHIR for Patient access of their own data using SMART-on-FHIR and Argonaut implementation guides. Many applications are being written to access this data, including the much heralded Apple HealthKit.

The result could be an overwhelming nightmare, or you can lead the way on a pathway to better care. In this talk I will inspire on how FHIR CarePlan can enhance Patient outcomes, Patient conformance, and lower overall Clinician impact through intelligent software agents.

The presentation will explore how this might look at a Patient portal, like VHA MyHealtheVet. The benefit is that the patient would be actively encouraged and automatically tracked, tasks prepared, and results viewable. The benefit to the clinician is that software agents can track progress and focus their attention on those patients that need extra help.

FHIR enables, but does not solve, these advancements in the way care is improved.

Learning Objectives:

• Describe FHIR, and how it is a good basis to build upon
• Show how Care Plans in FHIR are a win-win for Clinician, Organization, Payers, and Patient
• Develop a Library of Care Plan Patterns and Orchestrate the patient's treatment plan given a Pattern
• Automate with Intelligent services promoting specific actions and conformance
• Use Care Plan pattern specific apps that leverage Care Plan standards

Presentation details

My reportout on ONC Interop Forum panel discussion

I have not written a blog article on the output of the Panel discussion I lead at the ONC Interop Forum. The discussion I wrote up before the event is a good place to start. The panel, as one would expect, did deviate slightly with a much more focus on:

1. Difficulty implementing Privacy controls with the large number of privacy regulations. This complexity becomes very difficult around the edge cases: Going across state lines, Emancipated Minor, Minor transition, Elderly delegated access, etc. The panel members were NOT looking for less privacy rights, just more clear rights. 
• There is some benefit to federation level overrides such as we now see with Europe GDPR
2. Provenance of the data submitted by the Patient. Where did the Patient get the data? How do we know the Patient hasn't changed the data? Most Patients are good, but some are being nefarious, for example drug seeking behavior. There is a need for clear guidance on minimal Provenance information.
3. The four modes of communication became more clear as well as a model to discuss the interactions with the Patient.
4. Ask to ONC, from Sean during my panel "Please help make the right thing to do, the easiest thing to do." Simplify Privacy complexity without removing privacy rights. 
5. Patient population is not uniform. There are some Patients that want to be very actively involved in the flow of their data, there are many other Patients that want their data to be readily available for Treatment purposes without them needing to get involved.

Luck for me the day 1 and day 3 reports are available on YouTube now, published by ONC. There are two recordings of significant length. Each minute is useful to listen to.

See the video of me reporting out on the third day just prior to hour 2 of the 6 hour recording available. The following video should start right at the beginning of that report out (2:16:00). Additional action items for ONC from my panel at 2:36:15. Response to Adrian Gropper question at 2:43:29 regarding patients activity.

Brand new sport coat... How do I look?

Webinars on MHD and mXDE available from IHE

 I presented these same slides at the FHIR DevDays. The overall goal is 15 Minute presentations that build first explaining general Document Sharing (XDS, XCA, etc), then Mobile access to Health Documents (MHD), and finally the Mobile Cross-Enterprise Document Data Element Extraction (mXDE) which orchestrates Query Element Data for Mobile (QEDm).

The slide deck is also available to View and download.

View Document Sharing Slides

View MHD Slides

View mXDE Slides

Improving Document Exchange Response with Asynchronous FHIR API

In the last article I show how PDQm can be made Asynchronous by using the FHIR Subscription. This is just one step in the overall interaction that one does with a Cross-Community Document Exchange (XCA). It is however the one that typically has the largest delay.

Baseline using Synchronous API

Here is a simplified view of a Consumer requesting through a synchronous API to do a Patient Discovery (PD), Query for Documents (QD), and Retrieve Documents (RD). A more detailed view in previous articles. This high-level view works for MHD as an API to XCA, just as well as using XCA/XDS old-school.

Lets imagine there is 200 partners within the exchange. The Patient Discovery must be sent to each one of them. This fan-out is not shown, it is being done by the Service on the right. The Service must wait for the response to come back from each of them. Only when all partners have responded, or some timeout has happened, can the results be returned back to the Consumer.  As I indicated before some of the 200 partners might take a few minutes to return a result. Thus this Patient Discovery can take minutes before the second step of Query for Documents can happen.

The Query for Documents is a bit more targeted, as you would only query the partners for which you got a positive patient identity match. In the example from 200 partners, only 10 of them know of the patient of interest. Thus the Query for Documents can be limited to just those 10. It is still possible that those 10 are slow.

The Query for Documents to those 10  can be done in parallel if your Consumer technology stack allows that. I show it here as 10 one after another. Thus the overall Query for Documents will be the combination of all the partners including the slowest partner that has data on the patient of interest.

This diagram shows that for every Document Entry found, a Retrieve Document will be done. This is not unusual for some middleware that might be decomposing those documents, such as the mXDE environment I show. I guess I really need to blog that mXDE environment.

Also there are opportunities to detect the same document at multiple locations, thus eliminating the Retrieve Document being done multiple times. See this article.

Better Response using Async API

There is asynchronous support in XCPD/XCA; it is just not often used. For example the eHealth Exchange and CareQuality don't have any use of asynchronous while they have required everyone to support it.  I understand that the Epic Care Everywhere internal network that is based on XCPD/XCA does use the Asynchronous SOAP. Using Asynchronous SOAP gets the same improvement shown here.

This improvement can also be done using FHIR Subscription and orchestration of each notification. The diagram shows one full Patient Discovery, Query for Documents, and Retrieve Documents. The last notes shown just indicate the same could be done for each result returned.

Something that is hard to diagram is that all of these events are asynchronous so everything is overlapping in parallel.

The result is that the first full Document returned might be available in fractions of a second, while the last might take a long time. In fact the last one would only take as long as the three steps (PD+QD+RD) for that entry alone. This Asynchronous approach decouples the response of each partner.

Conclusion

Async is great... but it still must be managed, and the failure-modes are messy. If one has infinite resources, for example an infinite number of threads, then one can just let the system go. But often one has just a limited number of threads or memory or cache.. Thus some events might need to be queued to happen when resources come available.

Automating the Document Retrieve is not as important, but showing it can be orchestrated in just hammers home the message. This step would not be done for human view, but would be done for a middleware service that is decomposing the documents, like mXDE describes.

Even more advanced orchestration

The other use-case is the one that David Vazquez and I worked together on as an internal API within the VA. It is David that made this vision come to life. He orchestrated PD->QD->RD completely. He made an internal API so had some design criteria to help him.  Used FHIR Subscription on DocumentReference. There was clear Patient search parameters that can be chained cleanly onto DocumentReference query. There is a need for cache of DocumentReference and Documents. By having this cache could then respond to requests from the app quickly.  He then changed the Web based application the Clinicians use to use this Async MHD like API, and showed the huge improvement in response time. The Clinician would normally sit waiting for many seconds before anything would happen (the slowest community wins), but with the Async API they would get results right away (the fastest community wins). What surprised us both is that overall the complete results were available faster.

Alternative Patient Discovery performance improvement

The biggest advance is gained by the Patient Discovery. The alternative architecture is the one CommonWell has implemented as their Record Localization Service. They get the equivalent of an Asynchronous performance by requiring all Partners to feed them an ADT, for which they do cross-reference correlation at that time, so that when a Patient Discovery is needed the answer is already known fully.  This is what IHE has in the XDS environment. The negative is that all Patient Demographics are stored locally regardless of if that patient will ever utilize the network (some patients never leave home). The performance improvement is significant. Likely also much better quality of the matching is possible.

The websequencediagrams

+-------------------------+
title High-Level Community Exchange

participant Consumer
participant Service

Consumer->+Service: Patient Discovery (PD)
note right of Consumer
time happens (PD)
end note
Service->-Consumer: 10 Patients found

loop for each Patient at 10 Communities
Consumer->+Service: Query for Documents (QD)
note right of Consumer
time happens (QD)
end note
Service->-Consumer: 10 Documents found at that Partner Community
end loop

loop for each Document (10*10)
Consumer->+Service: Retrieve Document (RD)
note right of Consumer
time happens (RD)
end note
Service->-Consumer: returned document 
end loop


+-------------------------+
title High-Level Async Community Exchange

participant Consumer
participant Service

Consumer->+Service: Async Patient Discovery (PD)
Service-->Consumer: first Patient found
activate Consumer
par for each Patient 
Consumer->+Service: Async Query for Documents (QD)
deactivate Consumer

Service-->Consumer: first Document Entry at that Community
activate Consumer

par for each Document Entry
Consumer->+Service: Retrieve Document (RD)
deactivate Consumer
Service->-Consumer: returned document 
end par
Service->-Consumer: ... 10 Documents found at that Partner Community
note right of Consumer
each would kick off a par like above
end note 
end par
Service->-Consumer: ... 10 Patients found in network
note right of Consumer
each would kick off a par like above
end note 

+-----------------------------+
title Automate fully Async Community Exchange

participant App
participant Middleware
participant Service

App->+Middleware: Subscription (DocumentReference?Patient:fname="bob")
Middleware->+Service: Async Patient Discovery (PD)
note right of App
Middleware will notify App for each DocumentEntry found
end note
Service-->Middleware: first Patient found

activate Middleware
par for each Patient 
Middleware->+Service: Async Query for Documents (QD)
deactivate Middleware

Service-->Middleware: first Document Entry at that Community
activate Middleware

par for each Document Entry
Middleware->+Service: Retrieve Document (RD)
deactivate Middleware
Service->-Middleware: returned document 
end par
Service->-Middleware: ... 10 Documents found at that Partner Community
note right of Middleware
each would kick off a par like above
end note 
end par
Service->-Middleware: ... 10 Patients found in network
note right of Middleware
each would kick off a par like above
end note 
Middleware-->App: in realtime - notifiy of each more Document Entry
App->Middleware: GET DocumentReference...
App->Middleware: GET document

App->Middleware: deactivate Subscripiton

PDQm using FHIR Subscription as Async API to XCPD/XCA

In the last article I covered the basic flow of using PDQm and MHD as an API to an XCPD/XCA environment. This is the classic intention of the current IHE Profiles.

But, the reality of XCA communities are that

1. You likely have hundreds of communities to probe
2. Some of those communities will be fast, some will be slow
3. Some communities will be down and never respond

The reality is that the time between a Consumer asking a PDQm discovery request, and getting ALL of the results from ALL of the communities, might be many minutes. Yes, many minutes. That long of a time between a RESTful GET (query) and the response is unusual. A typical http RESTful api toolkit likely doesn't wait that long.

One solution is to just make sure all your Consumer implementations wait a very long time before giving up and assuming their Responder/InitiatingGateway infrastructure has failed them. How long to wait? This might be a value populated somewhere, like the CapabilityStatement on the Responder, or in a Service directory.

But that is not friendly to the user. You might be able to get the Consumer software to wait many minutes, but there is likely a human waiting that long too. It is possible to stream each result back as they become available, to the Consumer. I am not sure what that looks like. To stream the results would also require the design of the Consumer software to be expecting streamed results. Meaning it doesn't wait for the whole http response before it starts looking at what it does have... Again, not a friendly solution.

Lastly the Responder/InitiatingGateway must have a blocking thread for this many minutes too, taking up precious resources on the middleware.

Some of these problems are http RESTful, but most of them are general problems that exist even in the classic XCPD/XCA world using SOAP. 

FHIR has a solution ready to be used... Subscription.... With Subscription the Consumer creates a Subscription resource with the subscription criteria equal to the PDQm query it might otherwise do.  The Consumer gets notified as data matching that Subscription becomes available.

The typical use-case for Subscription is to register a subscription for new data that might appear in the future as created by someone else. In the use-case I am describing here it is as an Asynchronous mechanism for a set of transactions (XCPD). In my case the creation of the Subscription is a trigger to start some backend XCPD discovery. Once all of that XCPD discovery is done, then the Subscription is useless. So the end of the Subscription is different than typical use-case for Subscription.

I worked with a developer who implemented this as an internal API to their implementation that interfaces with the eHealth Exchange (Sequoia Network). Where there are well over 100 partners, and some partners take many minutes to respond. The result was a much more responsive application behavior, in that case a web-interface. In fact the whole response-time from start to complete finish was faster as the critical processing could happen during what would normally be wait time, rather than doing critical processing after all the network interactions happened. So double win!

This looks more busy, and it is.. but the waiting is between the gaps. The best part of this approach is that the "new results - ping 1234" will happen once for each Patient match found, and will happen when that match is available. Thus the Consumer software will learn of matches from fast partners really fast. The Consumer can then start doing something right then, like minimally displaying the results. Unlike the classic solution that prevents the Consumer from knowing anything until everything is known.

Note I used web-sockets here, which does require a the Consumer to query after each notification. There are other Subscription types that can pass the data back. I haven't experienced them, and don't see much written about them.

Here is the source for the UML diagram that can be used at https://websequencediagrams.com

+------------------------+
title PDQm Subscription -- XCA

participant Consumer
participant Responder
participant InitiatingGateway
participant RespondingGateway

note right of Consumer
based on some need a patient is of interest
end note over 
Consumer->+Responder: Create Subsubscription
note right of Consumer
Simply move the PDQm search on Patient 
into the Subscription criteria:
Subscription.criteria = Patient? blah
Subscription.channel = websockets
end note
Responder->Responder: check if valid request
Responder->InitiatingGateway: start discovery
activate InitiatingGateway
Responder->Consumer: Subscription Create success = 1234
Consumer->Responder: Open Web-Sockets channel
note right of Consumer
endpoint of Web-Sockets is identified 
in CapabilityStatement on Responder
uses websocket extension
end note
Consumer-->Responder: link this websocket to subscription -- bind 1234
Responder-->Consumer: successful link to subscription -- bound 1234

loop for --ALL-- Partners in Community
note right of InitiatingGateway
Design backend to be most responsive:
Could be thread pool, could be event driven 
Might use XCPD synchronous or asynchronous
end note
activate InitiatingGateway

InitiatingGateway->+RespondingGateway: XCPD Patient Discovery
RespondingGateway->-InitiatingGateway: found patient alpha @ beta community
InitiatingGateway-->Responder: store result in cache
activate Responder
deactivate InitiatingGateway
end loop

Responder-->Consumer: new results - ping 1234
deactivate Responder
activate Consumer
note right of Consumer
normal PDQm query
plus Consumer remembers the time it last queried
Find Patient?blah&_lastupdated=time
end note
Consumer->+Responder: PDQm Patient?blah&_lastupdated=time
Responder->-Consumer: results from Cache
note right of Responder
cached entries returned 
can be maintained or flushed
end note
deactivate Consumer
InitiatingGateway->Responder: notice all Partners have responded, or timeout
deactivate InitiatingGateway
note right of InitiatingGateway
Given no more can happen then done
end note 
Responder->Consumer: Close web-socket

Consumer->Responder: Update Subscription(1234) inactivae
deactivate Responder
note right of Consumer
at any time Consumer can inactivate
end note
note right of Responder
take down web-socket if still up
flush cache 
end note

MHD as an API to XCA

I expected this configuration was well enough explained within the MHD profile with the one paragraph and one diagram in the informative section 33.6.2-1.

I find that I need to explain this a bit more than I expected, and have a follow on article that needs this baseline.

Often I have to address the fact that XCA is a federation protocol that is addressing many communities. Federation is an important architectural capability allowing many communities to each act on-their-own, while cooperating in a Patient centric way.

The concept of simply using MHD as an API for XCA is over simplifying what actually needs to be done. Even the following diagram still oversimplifies in that not just PDQm and MHD are needed, but also ATNA for basic security, and IUA (or SMART-on-FHIR) paired with XUA for app and user security. This pairing of OAuth for FHIR with SAML for SOAP is not trivial, but is also not an unusual configuration for these security protocols. I am sure there is support in these product/stacks for this. Likely somewhere is needed a Consent management that might be based on BPPC or APPC.

What I will explain is the interactions between PDQm/MHD and XCPD/XCA.  The following diagram shows on the left the FHIR transactions, and on the right the SOAP transactions. This diagram shows the three steps: Patient discovery (PDQm-->XCPD), Document query (MHD-->XCA), and Document retrieve (MHD-->XCA). The three steps are joined by some processing that happens on the client side.

It is very possible that the processing on the client side is to simply do a Document query against all Patients found, and for each DocumentReference returned a Document retrieve. However I would hope that some kind of processing happens to select only the communities of interest, and only the documents of interest.

I don't show the design needed to convert PDQm (FHIR queries) into XCPD queries. I assert that for a given set of normally used queries this is possible. Note that the normally used queries are still a much smaller capability than PDQm or XCPD support. So, think about what is minimally needed, and work on that first.

I don't show the design needed to convert the MHD (FHIR queries) into the XCA queries. I assert that for a given set of normally used queries that are possible, there is a subset that is not hard to convert from FHIR to XCA. See Timebound XDS queries done right

Note that I have not done any extensions beyond what is documented in the PDQm/MHD or XCPD/XCA profiles. It is possible to do some short-cuts. It is possible to do some optimizations. I however here just wanted to put the facts on the table.

The above diagram is built from https://websequencediagrams.com using the following script. I provide it here for your use and enhancement, but also for my own archive of it:

+------------------------------+
title MHD -- XCA

participant Consumer
participant Responder
participant InitiatingGateway
participant RespondingGateway

note left of Responder
Consumer is used as PDQm-Consumer, and MHD-DocumentConsumer
Responder is used as PDQm-Supplier and MHD-DocumentResponder
end note 
note over Consumer
based on some need a patient is of interest
end note over 
Consumer->+Responder: PDQm Patient? blah
Responder->Responder: check if valid request
loop for all Partners in Community
Responder-->InitiatingGateway: trigger discovery

activate InitiatingGateway

InitiatingGateway->+RespondingGateway: XCPD Patient Discovery
RespondingGateway->-InitiatingGateway: found patient alpha @ beta community
InitiatingGateway-->Responder: store result in cache
deactivate InitiatingGateway
end loop
Responder->Consumer: Found all Patient reesources in cache
deactivate Responder

note over Consumer
based on Consumer processing of 
Patient resources returned
some or all Patients are interesting
end note

loop for all Patient entries found
Consumer->Responder: MHD DocumentReference?Patient=ABC&class=XYZ 
activate Responder
Responder->Responder: check if valid request
Responder-->InitiatingGateway: trigger 
activate InitiatingGateway
InitiatingGateway->+RespondingGateway: XCA Find Documents for given parameters
RespondingGateway->-InitiatingGateway: (n) Document metadata entries found
InitiatingGateway-->Responder: store results in cache

deactivate InitiatingGateway
end loop

Responder->Consumer: Found all document metadata entries in cache
deactivate Responder

note over  Consumer
based on Consumer processing of
DocumentReference resources returned
some or all Document Entries 
describe Documents of interest
end note
Consumer->Responder: Retrieve XYZ document
note right of Responder
URL found in DocumentReference is just retrieved (GET)
That URL might have been encoded by Responder to
have all the information necessary to do the XCA 
or it might rely on information in cache
end note
activate Responder
Responder->Responder: check if valid request (look in cache)
Responder-->InitiatingGateway: trigger Retrieve
activate InitiatingGateway
InitiatingGateway->+RespondingGateway: XCA Retrieve Documents
RespondingGateway->-InitiatingGateway: document returned
InitiatingGateway-->Responder: trigger doc available
deactivate InitiatingGateway
Responder->Consumer: document returned
deactivate Responder

Basics of Healthcare Data access rights in USA

You should (federally required) have access to View, Download, and Transfer your medical data.

View

View just means you should be able to login to some web portal and see the data.

Not very useful, but everyone should be able to do this. It is most helpful when you want to see the data that the doctor just talked to you about, but when the doctor was talking to you the information overload was too much. So you want to look at it later, at home, where you can spend a bit more time with it. The idea is also that you then get a chance to think of questions for the next time you talk to the doctor. These "Views" of the data are often not the best quality, or easy to understand.

Download

Download means that from that same web portal you can download a copy of the data.

This 'should' be a higher quality, and should be in a 'standard' format. This is where my work comes in. Most things are available in a summary report. This might be referred to as "Blue Button", a marketing term that doesn't mean anything, but was something to rally the healthcare community around. This summary report might be a simple and rather useless text file, or PDF file.  Hopefully it is a more complete CDA standard format (often called CCD, C32, CCDA, C-CDA, etc). For images, like MRI, the DICOM standard is used.

The idea of downloading these CDA or DICOM standard formats is that you can take them to some other doctor, second-opinion, or be background helping with future problem. Also you can find applications on the internet that can help you yourself investigate these, and you can find services on the internet that can analyze it for a computer driven second-opinion (dangerous in my view). You can send this data to clinical research projects that would like to use your data to better future care of the issues you have had. 

The point is that your data is YOUR data. You can do anything you want with it. You can even be stupid and leave it somewhere it should not be.

Transfer

Transfer means that the data can be sent elsewhere. This is MORE what I get to define in my job...

1) Exchange: You are in California, where there is a strong health exchange. That health exchange is connected to other states via nationwide exchange. You can enable your data to flow through this network, more likely you can tell them you do NOT want the data to flow. The advantage of these kind of health exchanges is that the data is often there where it needs to be without you as a patient getting involved. For example during an emergency when you are away from home. Or during a natural disaster when you are pushed away from home. .This network that I am explaining is being used in CA to help those displaced by the wildfires. The exchange is simply doing what most patients figure is logical. This exchange helped Grandma Gloria when she would go between Wisconsin, and Texas. It requires nothing of you, except you agreement.

2) Direct: There is an agreed protocol for sending healthcare data to a healthcare provider of your choosing. This is a different network, and a different concept. In this case you must enter what looks like an email address (it actually is, but in a secure way). You pick the data you want to send. And you send it at that time. This works really well when you want to get a second-opinion, or are moving to a new home. It however requires you to request the transfer, and it is done once.

3) Apps: The newest hot technology (meaning it isn't available everywhere) is to use a third method that enables Applications. This is what Apple has added to their phones. If you have an Apple phone you have an App from Apple that can get your data. That is, if your healthcare provider has offered the data through this "API", specifically the API following the FHIR standard. This standard is very new, not really ready to be used. Apple is not the only one with a Healthcare App. There are many. The struggle is that this is all so new that there are many issues to work out. For the geeks, this is fun. For everyone else, this will be nothing but frustration for the next 2-3 years. So play with it, but don't rely on it.

Conclusion

I want EVERYONE to know about this. The main reason to know about it is to be happy that Exchange happens, but is controllable by you. And that Download is available for the chance that you need it for a second opinion or to help with clinical research. All the other reason to get your data are not all that well developed, so would just frustrate you. I have my data, and it just sits there on my computer taking up space.

YES I know many people find their data far more useful, and life critical. This is why I do what I do. I am simply realistic about the impact to the general public.
 

IHE Document Sharing (XDS) Metadata management Handbook

The IHE IT Infrastructure Technical Committee has published a new Handbook as of August 20, 2018: Document Sharing Metadata

The above document is available for download at https://www.ihe.net/Technical_Frameworks/ or at User Handbooks.

The full IHE formal announcement


The Document Sharing profiles from IHE including XDS and XCA, enable a Community to share Patient specific medical documents. This is described in the Enabling Document Sharing through IHE Profiles white paper (HIE using IHE). Each document shared is described by metadata. A Community deploying an HIE this way needs to define some metadata constraints and practices, so that the documents are found when they are needed. This handbook helps a Community to come up with appropriate constraints.

Purpose of the Document Sharing Metadata Handbook

This handbook is intended to assist the reader on the steps necessary to define how document metadata would be used, how to enforce and propagate that use, and how to evolve the document metadata use constraints over time. Use of this handbook will produce a set of documentation and plans that we call your “Community Metadata Specification”. A well-managed Community Metadata Specification is an essential component of an efficient and coordinated Document Sharing system. This becomes more important with increase in participation, the number of patients, document types, and shared documents.

This handbook uses the term “Community” as defined in the Enabling Document Sharing through IHE Profiles white paper (HIE using IHE). This definition is inclusive of an XDS Affinity Domain, an XCA Community, or a set of XCA Communities. This definition is also inclusive of the use of MHD (XDS-on-FHIR), although further discussion of MHD is not explicitly included in this handbook.

This handbook constrains document metadata to enable optimal discoverability of the shared documents within your Community. There are other responsibilities of Community management: patient identity and demographics management, organizational identification and credentialing, privacy policy, security policy, partner certification processes, etc. IHE addresses these broader topics in other publications listed in , Section 1.3, including the whitepaper “Template for XDS Affinity Domain Deployment Planning”.

Continued Discussion and sharing

These and other examples can be found at https://wiki.ihe.net/index.php/Metadata_Handbook. A discussion forum has also been setup at https://groups.google.com/forum/#!forum/ihe-metadata

August 24, 2018 -- added
For Fun I put the handbook on GITHub in Markdown format. Comments (issues) welcome.


Other articles of mine on Healthcare Document Sharing (HIE)

Blockchain for Patient to sell their data to Clinical Research

Smart-Contracts are a very important part of blockchain. The openness of blockchain is another. I have presented a possible way to use these features of blockchain to enable a Patient to be able to sell access to their data. I include some features also enabled by blockchain, such as micro-payments and escrow for breach of terms. I think these are critical to Patient selling access to their Data, and the ability to add this is simple given the Bitcoin example of Blockchain.

This all said, Smart-Contracts are hard to write correctly, and easy to get wrong. So I think there needs to be far more maturity to the space of Smart-Contracts before they are actually controlling access to Patient data.

Patient data for sale for Clinical Research

So a patient might offer access to their data, managed on a FHIR Server, to anyone that can satisfy a smart-contract they put into a public chain. I first described over two year ago as a response to Grahame's original ask Healthcare Blockchain - Big-Data Pseudonyms on FHIR

The smart-contract would include:

1. Upfront payment for the access (some micro-payment)
2. Requirement for escrow of coin to be unlocked to the Patient if other terms are violated
3. Terms of protection of the data
4. Kind of clinical trial allowed (heart conditions, but not brain)
5. Agreement to keep all research public
6. Agreement to contact patient if the patient could benefit from new treatment detected
7. Agreement to contact patient if some treatable medical condition not previously known is discovered
8. Agreement to not contact patient if terminal condition is detected

A clinical trail that can meet these, could satisfy the contract and gain access. If they violated any of the terms, the smart-contract would automatically transfer the escrow coin to the patient. Based on some sunset term (like possibly the natural death of the patient), the escrow coin goes back to the research organization. So clearly that legal-will is important to this use-case...

How does this work? 

I have indicated that the data would not exist on the Blockchain, it would exist in some FHIR server somewhere. I use FHIR because it is http RESTful and common to protect it using OAuth using SMART-on-FHIR profile. Thus it is to the general IT world, a RESTful server protected by OAuth.

So, this specific FHIR Server, and the OAuth that is protecting it, is linked to the BlockChain. It is the one taking the results of the Smart-Contract. If the terms of a Smart-Contract are satisfied by an agent, then that agent gets an appropriately scoped OAuth token. That agent can then use that OAuth token to access the data in the FHIR server.

In this way the FHIR Server is just a normal FHIR Server being protected by OAuth using the SMART-on-FHIR profile (aka scopes).   The OAuth service is the bridge between http-RESTful world and the BlockChain Smart-Contract world.

Variants on smart-contract based on de-identification capability

It is possible that the patient publishes multiple flavors of the smart-contract. Each offering different types of pseudonym blinding: Some flavors would expose MORE information, and have higher contract requirements (like shown above). Some would expose very well de-identified data, and have less strict contract requirements.

Highly de-identified data, where ALL direct and in-direct (Quasi identifiers) are removed. Including fuzzing completely dates, patient characteristics, location, etc. If the data is highly de-identified it is less valuable for clinical trials, but it also wold not need to be as strongly protected. So it is possible for this offering the smart-contract does not require an escrow of coin.

These variants would require that the authorized access to the data enforce these variations. Thus one would need some access method to the data where the de-identification can be accomplished. This might be done by different servers hosting the various flavors, confirmed by a human statistical analysis. This might be done by some automated de-identification service as I describe in
#FHIR and Bulk De-Identification

Am I wrong?

I am very willing to hear that I am wrong. I am very willing to hear adjustments. I am very willing to hear that someone has implemented this.

More reading:

• This article originally published November 10, 2017 Healthcare use of Blockchain thru creative use of Smart-Contracts
• Healthcare use of Blockchain on FHIR
• Blockchain as a platform for Supply Chain
• Healthcare Blockchain use?
• Blockchain and Smart-Contracts applied to Evidence Notebook
• Healthcare Blockchain - Big-Data Pseudonyms on FHIR
• #FHIR and Bulk De-Identification

Healthcare use of Blockchain on FHIR

I went to the ONC Interop Forum in DC. The security track focused on blockchain all morning. There was nothing new mentioned. This not to say that the audience didn't get any value, just that I didn't hear anything new. This lack of new insight is itself an important point. It indicates that much of the interest in Blockchain is very niche, that any efforts have not yet found the 'killer app'. This is also not an indication that no killer app is going to appear, just that it has not yet been found.

The panelists were surprised by this question. All the experts were clear that this early days. Caution, but excitement. They were all full of encouragement to try stuff out. All recognized that there is much misinformation and hype. All recognized anyone using blockchain is taking a big risk. None would state any prediction of the future. They also all recognized that those that have succeeded have reaped great rewards. They are all fully committed and excited...

There was not much questions from the audience so I asked

Given that the use of Blockchain will be use-case specific, has there been Healthcare use-cases brought before the Blockchain community that were determined to be a poor use of Blockchain?

Their answer: Do not put healthcare data onto the blockchain, no matter how it is protected (e.g. permissioned chains, or encrypted, etc) . It is better to put pointers (to FHIR Servers) onto the chain. So pointers are good, data are bad. 

To emphasize a Good use-case is where the data are already public, thus the blockchain is there to support it, validate it, confirm it, or trigger off of it.

 keeps fidgeters occupied while not bothering others around them

No surprise, I have said this too:

What should Healthcare do with blockchain?

This does not mean there is no room for blockchain and healthcare. just that we need to be careful about how we approach the topic. I have covered a set of Blockchain considerations for healthcare

Don't put medical data into the blockchain.

I am more convinced that putting healthcare data into a blockchain is a really bad idea.  Seems this is also a consensus that is coming together. Thus there will be many FHIR Servers that hold your data (might be others than FHIR, but why bother mentioning them).  For any specific use of data related to the blockchain, there might be one server or there might be many. That is to say that it is fully possible that the FHIR server associated with a blockchain project might have centralized the data prior to exposure through blockchain, or might proxy and make it appear as if there is only one. However probably best to presume many FHIR servers. In initial experimentation, experiment with one, but keep open as a gap expansion to many.

Don't use blockchain for direct Treatment.

I am equally convinced that using blockchain for direct Treatment use-cases is a very bad idea. Treatment has many expectations. The data must clearly be identified with a specific human, can't use pseudonyms. There must be no delay in getting to the data (urgency). There must be clear provenance of the data (where did this data come from, etc...). Treatment use-cases require that new events, observation, interactions are recorded; that any mistake detected is corrected. And there is also medical-emergency break-glass. etc.

Treatment related workflows

There are some Treatment like things that don't have these expectations. Such as participating in a clinical trial, where they can treat you as a pseudonym (strongly identity proofed). There are other Treatment scenarios where one also don't need actual identity, like a laboratory or pharmacy supply. Some of these are already given only the MRN, thus they don't have much more than a form of pseudonym. A new one that I really like is using blockchain to track the supply-chain of medication and medication components.

Provider Directory proofing

The beyond the medication supply-chain use-case, this Provider Directory use-case seems very interesting to me. The general need is that each provider organization must do background checks on all of their practicing clinicians. This background checking is expensive. The idea of using blockchain is to have a permissioned chain that is managed by all the provider organizations. Each time they proof a clinician, they put that evidence onto that permissioned chain and indicate they have verified it. Thus it is a consensus driven identity proofing for clinician licensing and background.

Smart-Contract to control clinical research

Patient data for sale for Clinical Research might be an opportunity. A patient might offer access to their data (which is elsewhere) to anyone that can satisfy a smart-contract they put into a public chain. Unfortunately this best opportunity is what I described over a year ago given Grahame's original ask  Healthcare Blockchain - Big-Data Pseudonyms on FHIR

The smart-contract would include:

• Upfront payment for the access (some micro-payment)
• Requirement for escrow of coin to be unlocked to the Patient if other terms are violated
• Terms of protection of the data
• Kind of clinical trial allowed (heart conditions, but not brain)
• Agreement to keep all research public
• Agreement to contact patient if the patient could benefit from new treatment detected
• Agreement to contact patient if some treatable medical condition not previously known is discovered
• Agreement to not contact patient if terminal condition is detected

A clinical trail that can meet these, could satisfy the contract and gain access. If they violated any of the terms, the smart-contract would automatically transfer the escrow coin to the patient.  Based on some sunset term (like possibly the natural death of the patient), the escrow coin goes back to the research organization. So clearly that legal-will is important to this use-case...

Variants on smart-contract based on de-identification capability

It is possible that the patient publishes multiple flavors of the smart-contract. Each offering different types of pseudonym blinding: Some flavors would expose MORE information, and have higher contract requirements (like shown above). Some would expose very well de-identified data, and have less strict contract requirements.  

Highly de-identified data, where ALL direct and in-direct (Quasi identifiers) are removed. Including fuzzing completely dates, patient characteristics, location, etc. If the data is highly de-identified it is less valuable for clinical trials, but it also wold not need to be as strongly protected. So it is possible for this offering the smart-contract does not require an escrow of coin.

These variants would require that the authorized access to the data enforce these variations. Thus one would need some access method to the data where the de-identification can be accomplished. This might be done by different servers hosting the various flavors, confirmed by a human statistical analysis. This might be done by some automated de-identification service as I describe in
#FHIR and Bulk De-Identification

Healthcare Financial transactions

I any financial related transactions might certainly be good blockchain, even if it is healthcare related. Still privacy and safety concerns, but these are a step away. For example 

More reading:

• Blockchain as a platform for Supply Chain
• Healthcare Blockchain use?
• Blockchain and Smart-Contracts applied to Evidence Notebook
• Healthcare Blockchain - Big-Data Pseudonyms on FHIR
• #FHIR and Bulk De-Identification

Open Call for IHE Work Item Proposals 2019

As the IHE ITI Planning Co-Chair... I want to bring attention to the opportunity to bring an Interoperability Problem to IHE to be solved and formulated into an IHE Profile (Implementation Guide). The planning cycle has begun! The IT Infrastructure (ITI) and Patient Care Coordination (PCC) Domains are soliciting work item proposals for the 2018 Publication Cycle. The Call for Proposals concludes September 21, 2018.

For detailed information visit the IHE Call for Proposals Wiki site.

If you are new to the IHE International Call for Proposal Process?

• Watch the online webinar to learn more about submitting a proposal and the evaluation process.

Ready to participate in the Call for Proposals?
Interested parties are invited to submit a brief proposal (template form) for new IHE Profiles and/or White Papers to be considered for development in the new Publication Cycle.

Proposals should be entered using the attached Brief Profile Proposal template. They should address the following:

• What is the problem and how does it look in practice? (Describe the use case)
• How should things look in practice if it were fixed?
• What specific standards could be used to solve the problem, if known?
• If possible, give some indication of the business case for solving the problem (e.g., quantify the cost).
• It is strongly recommended that the proposal include the name of an editor for the proposal should it be selected for development.

Email your completed brief IHE Proposal template to the corresponding email address listed below before September 21, 2018 at 11:59pm CDT. Proposal templates can also be found online at:

• ITI Domain Proposals: John Moehrke at: johnmoehrke@gmail.com, ITI Planning Chair
• PCC Domain Proposals: Emma Jones at: Emma.Jones@allscripts.com, PCC Planning Chair

What happens if my proposal is selected?
The IHE ITI and PCC Planning Committee will review each Brief Proposal and select a "short list" of proposals for further consideration. Detailed Profile Proposals are sent to the IHE ITI or PCC Technical Committee for evaluation and returned to the Planning Committee for a final vote. Please visit the Wiki for detailed information about the IHE Call for Proposals.

Questions or Comments? I am glad to guide, assist, or otherwise encourage.

Modes of patient centric communication

When it comes to Patient Data exchange, I want us to be inclusive of "Mediated" exchange, "Directed" exchange, "Controlled" exchange, and "Negotiated" exchange. I have not seen these formally defined, so here is my informal definition. Let me know if you know of another mode of communication.

• Mediated Exchange -- where the Patient themselves is an active part of the communication pathway. Such as carrying the data within their possession, using a personal device and application, --- Such as using a phone resident App using FHIR to download their data, then upload that data to some recipient. 
• Directed Exchange -- where the Patient actively requests that the information flow to a selected destination. --- Such as a patient using Direct Secure Messaging, or where a patient requests that the data be pushed.
• Controlled Exchange -- where the Patient does not get directly involved in the communication, but should be understanding of the communication and possibly have control. over that communication ---- Like using Health Exchange between Provider organizations
• Negotiated Exchange -- where the Patient themselves connects two parties and authorizes the flow between those two parties. This might use the HEART standard for authorization, and FHIR bulk data access.

Are we there yet? I think we need multiple modes. None of these solve all needs. Each has specific strength.

Privacy and Security Considerations for the use of Open APIs for Patient Directed Exchange.

I have the great honor to be hosting a panel discussion in Washington DC as part of the Office of the National Coordinator's 2nd Interoperability Forum. This event is, next week, August 6-8. My panel is scheduled for the afternoon of August 7th, from 1:30 to 3:00 pm. My panel title is "Privacy and Security Considerations for the use of Open APIs for Patient Directed Exchange."

Here is the main vision for this panel:

Assuming that we agree that patient advocates’ and privacy advocates’ vision is our goal; what lack of standards is getting in the way.  This is not a discussion about what the goal is, but rather it is meant to focus on what is still preventing the big stakeholders from embracing this vision.

General flow

Before my panel is a "Blockchain" topic and "Identity and Trust"; after my panel is a Lighting round where some new tech will be showcased.

Where Blockchain and the Lighting round will be clearly looking to new and shiny tech; I am hopeful that Identity/Trust, and my segment will be more grounded in reality. 

I have invited to my panel individuals representing very large organizations, very well established organizations. The reason I did this is because we don't get to hear publically from this perspective. Mostly the reason is because when this size of an organization makes a change, it affects MANY. However this size of an organization can't make quick changes. This size of an organization can't make risky changes. This size of an organization NEEDS some standard to guide them. This standard must be mature and have partner acceptance. 

Yes, sometimes a large organization can lead. This does happen. But it happens toward a standard. Example is Apple adopting FHIR.

What's a Standard?

Where in this panel standards is the broadest view. Inclusive of :

• Interoperability Standards -- from the likes of HL7, FHIR, and IHE;
• Vocabulary Standards -- from the likes of HL7, SNOMED, LOINC, IEEE, ISO, etc;
• Implementation Guides -- specific use-case analysis with specific solutions -- From Argonaut, IHE, or ONC;
• Standards of Practice -- professional society guidance from HIMSS, AMA, and other medical professional societies;
• Standard policy framework -- Legal framework that encompases many reglations and defines appropriate use and responsibilities;
• Trust Framework -- Multi-party trust agreement that binds the parties to a set of rules and mitigations, backed by technology (like Certificate Authority). For example Sequoia DURSA or DirectTrust;
• Reference Implementation -- software provided in open-source by a consensus body as an implementation of a standard. Such as the many FHIR open source projects;
• Standard Interpretation of Regulation -- like HHS/ONC has done with for example the use of email with patients; and
• Laws and Regulations -- we all hope for as few regulations as possible, but sometimes they are needed.

Ideal Patient Centered Privacy

Here are my notes extracted from my blog on Privacy Principles. I hope not to cover these in this detail, but am ready to if need be. I think it is important to recognize ALL of these Principles, not just "Consent".

1. Collection Limitation Principle -- There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.
2. Data Quality Principle -- Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.
3. Purpose Specification Principle -- The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfilment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.
4. Use Limitation Principle -- Personal data should not be disclosed, made available or otherwise used for purposes other than those specified in accordance with Paragraph 9 except: a) with the consent of the data subject; or b) by the authority of law.
5. Security Safeguards Principle -- Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorised access, destruction, use, modification or disclosure of data.
6. Openness Principle -- There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.
7. Individual Participation Principle -- An individual should have the right:a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to him; b) to have communicated to him, data relating to him within a reasonable time; at a charge, if any, that is not excessive; in a reasonable manner; and in a form that is readily intelligible to him; c) to be given reasons if a request made under subparagraphs(a) and (b) is denied, and to be able to challenge such denial; and d) to challenge data relating to him and, if the challenge is successful to have the data erased, rectified, completed or amended.
8. Accountability Principle -- A data controller should be accountable for complying with measures which give effect to the principles stated above.

Modes of Communication

I am not constraining the mode of healthcare data communication. I want us to be inclusive of "Mediated" exchange, "Directed" exchange, "Controlled" exchange, and "Negotiated" exchange. I have not seen these formally defined, so here is my informal definition. Let me know if you know of another mode of communication.

• Mediated Exchange -- where the Patient themselves is an active part of the communication pathway. Such as carrying the data within their possession, using a personal device and application, --- Such as using a phone resident App using FHIR to download their data, then upload that data to some recipient. 
• Directed Exchange -- where the Patient actively requests that the information flow to a selected destination. --- Such as a patient using Direct Secure Messaging, or where a patient requests that the data be pushed.
• Controlled Exchange -- where the Patient does not get directly involved in the communication, but should be understanding of the communication and possibly have control. over that communication ---- Like using Health Exchange between Provider organizations
• Negotiated Exchange -- where the Patient themselves connects two parties and authorizes the flow between those two parties. This might use the HEART standard for authorization, and FHIR bulk data access.

Are we there yet?

So, standards in the broadest definition are important to the large organization. So I want to hear from them, what standard is still need. What lack of a standard is preventing them from achieving the vision of the Privacy and Patient advocates?

I would love to hear: "Nothing is needed, we are already there." I think we are closer than many think. I know that my efforts within the VA on their Patient Portal -- My HealtheVet -- shows that they are really close.

I do expect there is still some standards needed. Identity? Authentication? Consent? Care-Team? Provenance? Data-Tagging? Obligations? App-Validation? App-Store?

I certainly have blog articles on many of theses topics: FHIR,  Privacy/Consent, Health Exchange, Blockchain in Healthcare, De-Identification, Patient Identity, Direct, and even GDPR.