Friday, August 17, 2018

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.

Thursday, August 16, 2018

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 

Wednesday, August 15, 2018

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

Thursday, August 9, 2018

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.

Sunday, July 29, 2018

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: FHIRPrivacy/Consent, Health Exchange, Blockchain in Healthcare, De-Identification, Patient Identity, Direct, and even GDPR.

Saturday, July 21, 2018

Timebound XDS queries done right

As the author of the soon to be published IHE "Document Sharing Metadata Handbook", I have been involved in some very deep and disturbing discussions on how to do timebound queries in XDS/XCA. I say very deep because this discussion included almost a dozen of the best minds on the XDS Metadata and Query models. Disturbing because the discussion showed that the simple concept of timebound queries in XDS/XCA is not understood well. Perplexing because we have figured this out many times. If it takes us this long to re-invent this understand, then it must be much harder for others.

Mistakes have been made

I wrote an article on our first attempt. I thought it was good. It was not wrong. But it would have resulted in false-positives, and false-negatives that can be avoided. See Basics of doing Document Sharing Query right

For the version of the Metadata Handbook that we sent to public comment, we flipped the logic, thus making a very bad mistake.

Back to the mostly right logic I had in my article, a couple of optimizations were determined this week in the solution we came up with. 

One adjustment, to add wiggle-room on the query parameters, helps because although we want everyone to have well synchronized clocks, many of these times are based on human statements of start and stop. Thus adding wiggle-room extends the times you are looking for to put your start a bit earlier, and you stop a bit later.

The other adjustment is to use the other two service time query parameters to eliminate document entries that have only one of the service times (start or stop, but not both). Clearly if something stopped before the time you are interested in, then it s not what you are looking or; same is true about something that didn't start until after then timeframe you are looking for.

When we got to the final understanding, it became clear that it is possible our readers don't understand this too. Some form of this might end up in the Technical Framework, as this handbook (and blog) have very limited audiences.  We also felt we had done this before, and had written up changes to the Technical Framework. We had, but had only discussed the CreationTime, which is  point in time. Service Time is a range, which brings more complexity...

serviceStartTime - serviceStopTime 

When there is a timerange of the service event that you are interested, you will query against the serviceStartTime and service StopTime metadata element to find documents that indicate they fit your timerange. . The service times are specific to the time range of the treatment or episode. This is different than the document creation time, which is when the document was created. The query results will return any document whose “service time” falls within that range. It is important to note that these parameters work together to give a period of time.

Given you are interested in a specific time range (Start -> Stop).

The serviceStartTimeFrom and serviceStopTimeTo are clear they should bound that time with a little slop to deal with poor timeclocks:

  • serviceStartTimeFrom parameter in the query should be set to a few minutes before the time you are interested in being the Start of the service time range
  • serviceStopTimeTo parameter in the query should be a set to a few minutes after the time you are interested in being in the Stop of the service time range
When either or both service time is missing on a DocumentEntry, it will be included in the above query results. So we need to look for ways to eliminate these false-positives. 

Some DocumentEntries will have a service start time but not have a service stop time. This is common in chronic care, radiology, and other circumstances where the end of the service has not happened or where the end is unknowable;  therefore you should include a query parameter that would eliminate DocumentEntries that have a declared start time well after the time range you are interested in:

  • serviceStartTimeTo parameter in the query should be set to a few minutes before the time you are interested in being the Stop of the service time range

Some DocumentEntries will have a service stop time but not a service start time. This is not common, but will happen where there is no clear start time to an observation, therefore you should include a query parameter that would eliminate DocumentEntries that have a declared stop time well before the time range you are interested in:

  • serviceStopTimeFrom parameter in the query should be set to a few minutes after the time you are interested in being the Start of the service time range

Some DocumentEntries will have neither service start or stop. These will be returned regardless of any timeframe query parameters. Your Community Metadata Specification should encourage all metadata publications populate the serviceStartTime and serviceStopTime element as much as possible to avoid false-positive query results.

Post processing to eliminate false-positives

Ultimately one will get false-positive results from the query, the solution is to look at ALL of the metadata to find reasons to find and eliminate these false-positives.

Conclusion

The only real way to avoid false-positives is to force all DocumentEntries in the Community to have at least ONE service time. Most of the time Service Start Time can be determined.  It might be only to the accuracy of the day, or month, or year. But even that eliminates many false-positives. When there is not one of these times available, one is sure to have false-positives. For the Metadata Handbook, this is a fantastic observation as it can become a community rule that at-least one, preferably both times must be filled in.

Yes we know that there are MANY other query parameters. Yes we know that one could design better query language support. The point though is that this is the system we have. AND when used properly it will work just fine. Any data publisher that doesn't follow the rules will mess up Any well designed system. This is not a case of a poorly designed query system, this is a fact. Query is at the mercy of the data, bad data gives bad query results.


Monday, June 25, 2018

FHIR patient extensible data portability

Discussions at FHIR DevDays raised this question of a basic way to leverage FHIR API capability to enable the Patient beyond the limited Apps their provider has approved.

If a healthcare provider offers a FHIR API (e.g. argonaut) -- meeting the Meaningful Use "API" requirement. Would it be reasonable to expect that the Meaningful Use "Download" (from View/Download/Transfer) capability would be offered in FHIR format?

Proposed quick-and-dirty solution?

This could be something like a zipped Bundle containing the results of $everything for that Patient, given that patient as the user.  The zipping would help with the potential huge size.

The amount of data would be limited to that which is available on the FHIR API offered, which is often not all possible data.

Concern would come up when this export of $everything includes other data such as documents and images. The theory is that they are all necessary to export, but the problem is the overwhelming size that might result. (Unfortunately compression would be less helpful with documents and images where they are slight variations that are mostly the same, but because of the base64 encoding they all look very different)

Should this be a FHIR Document?

It might be more well-formed to have this be a FHIR Document, but it is not clear to me that adds much benefit over simply an export of all data that is known (aka $everything). 

There would be benefit that the Bundle would then be far more identifiable as coming from a specific Organization on a specific Time for a specific purpose. This could also be simply a Provenance resource on the bundle. This might be very important to a downstream recipient of this blob so that it can be authenticated and proven as complete (Principles of a Document)

Essentially the CCD provides this today, and is often the solution for "download", so this is just a different mime-type (FHIR).

I think just getting an export is more important than making sure it is a FHIR Document.

Why would anyone do this or want this?

The reason why this is useful is for patients that want to use Apps that are not (yet) approved by that provider.  Waiting for each of their providers to approve a useful App can be limiting on the Patient and on the Marketplace.

Counter this with the potential stupid patient that doesn't realize what they are doing with their data... This is going to happen, and when it does there will be an outcry. This outcry will complain that the provider was not acting as a parent to that child, but this kind of an outcry should not be a reason not to do this. Better that the patient be warned, but not forbidden from getting all their data in an download of FHIR format.

Who does this?

If this is reasonable, who does this today? 

GDPR

Note that this would also be helpful in support of GDPR Article 20 - Right to data Portability