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. 

IHE ITI Document Sharing Metadata Handbook Published for Public Comment

Those implementing or improving their XDS or XCA community are the intended audience of this Handbook. As a Handbook, it strives to inform on critical aspects of Metadata management. Please review and comment. Please forward to those with experience.




IHE IT Infrastructure Handbook Published for Public Comment

The IHE IT Infrastructure Technical Committee has published the following new handbook for public comment in the period from June 13 through July 13, 2018:

• Document Sharing Metadata - Rev. 1.0 

The document is available for download at http://ihe.net/Public_Comment. Comments submitted by July 13, 2018 will be considered by the IHE IT Infrastructure Technical Committee in developing the subsequent version of the handbook. Comments can be submitted at ITI Public Comments.

Presenting IHE on FHIR at FHIR-DevDays

I am getting excited to give two IHE on FHIR tutorials at FHIR DevDays in Boston. The FHIR DevDays event is focused on educating IT professionals in the newest standard in healthcare, FHIR – Fast Healthcare Interoperability Resources. The FHIR specification may be the newest standard in healthcare, but it is backed by all those that have developed the previous standards (e.g. HL7, CDA, IHE, XDS,  DICOM), taking the best from experience and using the latest in RESTful API technology. For more on FHIR Dev Days https://www.fhirdevdays.com/ 

IHE on FHIR

Both tutorials will focus on IHE use of FHIR. The first tutorial will focus on a high-level view of how IHE and FHIR interact, and a broad view of the current 22 IHE Profiles that leverage FHIR. This tutorial will be most interesting to a general audience interested in Standards organizations and evolution of IHE Profiles. This tutorial is a shortened version of the IHE-on-FHIR tutorial I gave at the HL7 Workgroup meeting in Cologne.

XDS on FHIR

The Second tutorial will go deeper into the IHE use of FHIR to enable API access to Document Sharing infrastructures based on XDS and/or XCA. These Document Sharing environments exist within USA, Canada, Europe, and elsewhere. The Document Sharing environment provides a way for Clinical Practitioners to publish documents (e.g. CDA, C-CDA, DICOM, PDF, etc) such as medical summary, episode of care, discharge summary, laboratory results, x-ray, CT, MRI, and other. The IHE MHD Profile defines how FHIR enabled apps can discover these documents, retrieve them, and publish new documents.

Advanced IHE Profiles that will be discussed show how these documents could be decomposed into FHIR Resources that are more naturally made available, with Provenance linkage back to the source document from which the FHIR Resource information comes.

Conclusion

The emergence of HL7 FHIR is very exciting, and the collaboration with IHE shows a strong endorsement. I am always excited to work with this new platform to accelerate the advancement of Healthcare.

My blog articles on the topic of FHIR, Document Sharing, and Privacy