Bills-FHIR-page

These are my notes on FHIR. As they become mature they will probably migrate to John's page.

FHIR class

March 11, 12 2014 I took FHIR class given by HL7 (Floyd taught). The slides from that class are available for download from here

As a summary of the class, I believe that the full semantics of XDS.b can be translated to FHIR with the exception of Folders. I have not looked into Folders yet. This would mean replacing the ebXML Registry binding with the FHIR binding and replacing the SOAP binding with the combination of FHIR REST and ATOM. I describe it this way because FHIR has its own flavor of REST and ATOM. (a comment, not a criticism).

The class was quite overwhelming in the same way that drinking from a fire hose is overwhelming.

What follows below are my notes from the class. I will continue to add to this page as I discover more things that I learned (see fire hose).

Terminology

We are going to have a hard time with terminology. FHIR and DS use a lot of the same terms. They just don't have the same meaning. The following sections offer some important terminology, how it is used by FHIR and how it related to DS and ebRIM.

Global and local ids

In ebRIM a global ID is a UUID and a local ID is any other value. In FHIR a global ID is a URI which can be dereferenced to obtain the content referenced and a local ID is a UUID.

Resource

In FHIR a resource is a predefined object (XML or JSON or RDF) that describes something interesting about heath care. There are currently about 50 resource types defined. Eventually there will be about 100. The DocumentReference resource maps approximately to a DocumentEntry. The the Manifest resource maps approximately to a SubmissionSet. Most of the detail coded in a resource is optional so you can use what you need. Resources can be extended using, wait for it, Extensions. We will be writing a bunch of extensions.

In the most basic form of FHIR, a resource is created/retrieved one at a time using REST GET/PUT/POST. They can also be created/retrieved in collections (more than one resource at a time). The most basic collection is called a Bundle. This will be discussed more later since additional background is necessary to understand.

Metadata

In ebRIM metadata is the collection of attributes describing a document. In FHIR metadata is a collection of details about a resource. Metadata is not part of the resource, it stands alone. Metadata can be sent/received in a request or response to pass information about the resource but it is not part of the resource. It's scope may be limited to the request/response. Request/response usually means a REST request or response. An example of metadata is the URI of a resource returned from a GET. The metadata contains the URI including version information. Confidentially information is coded as metadata since it may change over the lifetime of the resource. If the resource is signed then a simple change to confidentially information would trigger a new version of the resource and a new signature. So metadata contains information about the resource that can reasonably change over the lifetime of the resource without really impacting the content of the resource.

In some contexts metadata is also called Tags. Metadata is handled differently depending on the context of the transfer. The two major examples are transfer of a single resource via REST and transfer of a resource as part of a transaction.

Message vs request/response vs transaction

These are 3 totally separate concepts in FHIR.

A simple REST request/response transfers a single resource. Each resource is individually addressable (is assigned a permanent URI). Using PUT/POST/GET a resource can be created, updated and retrieved. In this environment, metadata about the resource can be transferred as Tags. Tags are coded as HTTP headers. So a GET of a resource will return the resource in the body of the GET response and will also return relevant metadata as HTTP headers in the response.

A transaction is the submission/retrieval of a collection of resources. The transactions carries the expected semantics: all or none (in the context of a submission). A later section will describe how to map IHE Document Sharing transactions into FHIR transactions. FHIR transactions are much more general than we need but our semantics can be defined using FHIR transactions.

Messages are request/response pairs that occur in response to an external event. This is a much more advanced topic and we can safely ignore it for now.

REST vs Transaction URIs

FHIR has transactions and it has REST. Here I mean REST in the form of direct addressing of individual objects like DocumentEntry and SubmissionSet (XDS terms).

On the direct addressing side, one can submit a single object, say DocumentReference, assigning it a permanent ID or allowing the server to assign the ID. To submit allowing the server to assign the ID you would POST the single DocumentReference object to

    http://server.com/xds/DocumentReference

where

http://server.com/xds

defines the server and service supporting FHIR (yes, I made them up). The FHIR server would reply giving status (HTTP status) and giving you the permanent address of the object in a HTTP header:

    Location: http://server.com/xds/DocumentReference/1002/_history/1

where 1002 is the assigned ID (server controlled) and the _history/1 indicates that this is the first version of this object. The object can be retrieved with a GET to

    http://server.com/xds/DocumentReference/1002

which will return the most recent version.

This shows the most simple submit/retrieve operation on what we would call metadata. Beware, FHIR has another definition of metadata and it has nothing in common with what DS calls metadata. More on that later.

The simple submit/retrieve has been done via REST. No transaction was involved. Transactions, like in the traditional database use of the term, implies that multiple object are involved and the operation is performed all or none. I have to layout a lot more detail before I can comment on transactions. This was just a teaser.

Bundles

Bundles are used everywhere in FHIR. In some ways bundles in FHIR are like multi-part in SOAP. They allow a collection of things to be included. Bundles, like everything else, are coded in XML or JSON or RDF (RDF is a format on the near horizon - not in the current documentation).

Bundles are used differently in submission and retrieve. Raw bundles are use in retrieve response since there is no obvious connection between the individual objects returned. In submit, there is structure that must be coded in the same way that in our Provide and Register transaction there is a DocumentEntry that is linked to an attached Document through the rules of MTOM.