FHIR Bulk Data (a.k.a. Flat FHIR)

Naming things is hard.  Sometimes technologies are given more than one name.  Such is the case with FHIR Bulk Data.  This article is written to explain FHIR Bulk Data at a high level and why it is sometimes called "Flat FHIR".

The FHIR Bulk Data is a draft specification for accessing (you guessed it) FHIR data in bulk.  Unlike regular FHIR, Bulk Data is an asynchronous exchange built atop HTTP.  Some situations where this paradigm may be useful include:
  • When results are very large such as population-level queries.
  • When results are not immediately available and need to be compiled.  HTTP servers and clients usually time out in a minute or two, so any query taking longer than thirty seconds should consider this asynchronous approach.

FHIR Bulk Data responses can represent a population and can therefore be very large. After the initial request is made, an immediate response is returned to the client including the target URL in the response body. The target URL is where the final results can be obtained after they are ready.

When the results are complete, and the client begins to download the contents from the target URL, the results are returned in "Newline Delimited JSON" format.  Newline Delimited JSON is abbreviated as "NDJSON". See http://ndjson.org/ for more information on this specification.  Each line of the NDJSON response is separated by a newline (i.e. "\n").  Each line is still structured data.  It is not a comma-separated-value (CSV) or a fixed-length file.  Those formats are often referred to as "flat files", but they are very different from the structured JSON described in the FHIR Bulk Data proposal.  The fact there is one JSON object, per line is the source of the "Flat FHIR" nickname.

FHIR Bulk Access clients will include the following HTTP headers:
 
{
 'Accept': 'application/fhir+ndjson',
 'Prefer': 'respond-async',
}

To avoid confusion, we recommend the term FHIR Bulk Data over the term Flat FHIR.  Hopefully this short article will help clear things up too.

Additional Resources:


  • FHIR Bulk Data Transfer Privacy and Security Concerns -
http://wiki.hl7.org/index.php?title=FHIR_Bulk_Data_Transfer_Privacy_and_Security_Concerns

Comments

Post a Comment

Popular posts from this blog

Conveying Identity and Authenticator Assurance Levels in OpenID Connect and Beyond in Healthcare

Conveying Identity and Authenticator Assurance Levels in OpenID Connect and Beyond in Healthcare 1. Standards and the Proposed Rule NIST's Special Publication 800-63-3 Digital Identity Guidelines outlines 3 identity assurance levels, "1", "2", and "3" to codify how well a person is or isn't, with 1 being a low confidence a person is who they say they are.  Similarly, Authentication Assurance Levels (AALs) of "1", "2", and 3" are also defined in NIST guidelines.  IAL details the  "login" or Authentication event. In ONC's proposed rule, " 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program ", OpenID Connect is proposed in the following passage:   To enable and support persistent user authentication and app authorization processes, we propose to adopt a standards and additional implementation specification for the FHIR standard. First, w
Read more

A National Patient Identifier Would Be Totally Awesome!

Fun Fact:  Did you know that congress actually has a gag order preventing Health and Human Services(HHS) from even discussing the idea of a national health identifier?  Well fear no more... word on the street is that this might finally change . America's multi-payer system is already complex enough. We also have to contend with a lack of a national health identifier?  Certainly national health identifiers have issues, but it is still a monumental step in the right direction.  While a national patient identifier will not fully solve the patient linking and matching problem, it will go quite a long way in improving the status quo.  I've spent way too much time thinking about how such an identifier should be constructed and issued.  Here are some main points: It should be numeric so it is easy to enter via a number pad/telephone. It should, in-part, be defined by the end user.  For example the first 10 digits could be someone's phone number It should contain a check d
Read more