The Patient Innovator Track at DevDays - Privacy

I assume anyone reading my blog has already seen this announcement on FireLy, Grahame, HL7, Hay on FHIR, etc. Go read those for the specific details, no good reason for me to duplicate them.

What I will do is focus on the opportunity for Patient to drive for Innovations in Privacy. Most of the other blogs are focusing on the Patient being the Innovator at "using" their data. This is the most powerful thing that Patient access using FHIR enables, by giving high quality and fully coded data into the hands of the Patient... so that the Patient can call upon a vast future set of applications that can enhance their Patient health (and safety).

Patient Privacy enhancements can also happen. When I reference Patient Privacy I am not just speaking of "Confidentiality" or "Consent". I am speaking to all of the Privacy Principles.  Here is the list summarized:

The OECD Privacy Principles are as good as any to review

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.

It isn't even as simple as these 8 Privacy Principles. There are regional nuances, personal decisions, concerns for safety/health, etc. Often times there is complaints that these Privacy Principles get in the way of Medical Ethics the actual cases of conflict are few and usually well understood by those affected.

I included all the Privacy Principles, although most will think that they-as-a-patient have very little control over these. This might be true, but "Innovation" comes from creative thinking. So I challenge the Patient Innovators with the full set of Privacy Principles. 

One that I am working on, with the help from my fresh college graduate son (please hire him), is an app that helps keep the Patient informed of how, and when their data are used. 

Finding Gaps in the specification and implementations:

As with all of the innovations in FHIR, the road is not always smooth. We are uncovering issues in the FHIR specification, issues in common implementations of FHIR Servers, and misunderstandings all around. These gaps are the important thing to uncover at this point in the FHIR Maturity. So please speak up when you uncover a gap. Now is not the time to be held back by a gap, or to 'hack' around the gap. Hit the gap head-on.

Tipping point in Health Interoperability Maturity

In the past two weeks I have been in large audience discussions where there is a very different kind of topic being discussed around Health Information Technology. The topic is about a vision of how things could/should be at the point of care because of successful interoperability. It is not explicitly said that way. These discussions are around better safety, better treatment, better efficiency, better outcomes, etc.

Historically discussions in Health IT have been around very basic interoperability fundamentals. Things like basic security, basic medical data (Allergies, Problems, Medications, etc), basic medical summary, basic episode/discharge summary. These things have been the focus of the past 10 years. These things have been greatly supported by current Health Information Exchange (IHE Document Sharing using XDS/XCPD/XCA). These things are accelerated by FHIR and US-Core.

These existing Health IT Interoperability are supported by basic security and privacy models. Things like IHE ATNA, XUA, BPPC; as well as the FHIR solutions of SMART-on-FHIR. Everyone is so very comfortable with using Mutually-Authenticated-TLS, and Digital Certificates. There is an understanding of how to handle patient consent in the context of Treatment workflows (mostly a custodian side problem that is handled in-house of that custodian).

Maturity

These basic interop solutions are not without issues, but they are mature enough that there is a totally new discussion that is starting with "So, now that we have basic interop, what more can be done?"

These more discussions are happening around new PurposeOfUse beyond just Treatment. There are discussions around Payment centered Interop. There are discussions around Clinical Trials and Clinical Research (something that was done in the past but very expensively and very privately). There are discussions around the PATIENT themselves getting engaged through applications and services.

There are other domains outside core treatment that are getting engaged. Some of them are envisioning being actively engaged in the Health IT, like through a Care Plan. Some of them are looking to get away from purely paper, like EMS and Transport.

There is interest in extending Health IT out to various Directories for discovering specialty treatment organizations, focused practitioners, clinics with specific equipment, etc.

There is also an interest in a large number of measurement devices to contribute to information about the patient. These might be weight scales, pedometers, heart-rate, SPO2, blood-sugar, sleep-tracking, blood-pressure, etc. (This group is scaring many as it has the capacity to overwhelm the Clinician very quickly. I assert this is more of an opportunity than a threat).

There is now discussions around Patient Consent and Authorization for various uses beyond Treatment, or even to more privacy realistic rules within Treatment use-case. There are discussions around patient delegations. There are discussion around patient using portals and applications. There are discussions around making it possible for a patient to REMOVE authorization when they want. There is discussions around empowering the patient to know how their data is being used, so that they can alert authorities when it is being used inappropriately and against their wishes.

Core Interop

Core interop is NOT done. There are plenty of further enhancements.... My blog will always be focused down at the core, and I see no end in sight. But I do see great things that the core Interop have enabled, and that excites me.

Definition

The definition of Interoperability includes this tipping point. The definitions of Interoperability do not stop at getting bits communicated, they are all very careful that the definition of Interoperability always includes that the recipient use the data to improve outcomes.

Here is a HIMSS published definition

Interoperability is the ability of different information systems, devices or applications to connect, in a coordinated manner, within and across organizational boundaries to access, exchange and cooperatively use data amongst stakeholders, with the goal of optimizing the health of individuals and populations.

It has never been acceptable to just communicate bits. The whole purpose of Interoperability MUST be for some end goal. Interoperability is not the goal, it is a tool to get to various goals. 

Note that previous definitions of Interoperability from HIMSS were even more focused on achieving outcomes and improving patient health and safety. 

It is very disappointing that ONC has a much more limited view on what Interoperability is. To them it is just getting bits to flow. This view is constrained by regulation text from 21st Century Cures Act. 

Here is ONC definition

According to section 4003 of the 21st Century Cures Act, the term 'interoperability,' with respect to health information technology, means such health information technology that— "(A) enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user; "(B) allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable State or Federal law; and "(C) does not constitute information blocking as defined in section 3022(a)."

I certainly hope that ONC updates their expectations. I think they have given the agenda at the ONC 3rd Interoperability Forum was very focused on thee higher level outcomes vs the low level means of Interoperability

Success

Success at building "core" Interoperability means that people can now dream about this second part of the definition of Interoperability, that is they can dream of "... optimizing health of individuals and populations".

FHIR Scaling to a Nation

Most discussions about FHIR are simple interaction diagrams like this:

Many Sources (n != 1)

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

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

So there is a real scale problem with the above.

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

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

Combining Many Sources

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

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

Not everyone will publish US-Core level resources

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

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

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

NOT fully discussed here 

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

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

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

Likely many more too

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

title Interop tendency

participant Source
participant Intermediary
participant Consumer

note left of Source: Broad tendency

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

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

end


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

Source->Consumer: FHIR Bulk access
end

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

Treatment based interop is best using Documents

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

Why?

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

How?

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

Better, publish both.

Where?

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

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

When NOT?

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

Discuss...