Bills-FHIR-page: Difference between revisions
| Line 32: | Line 32: | ||
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. | 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. | ||
== Terminology == | |||
I use submit and retrieve as simple verbs. In REST they would be POST vs GET. In XDS they would be PnR or Register and Query or Retrieve. FHIR does not distinguish between what we think of as metadata vs documents. It is all content to them. FHIR is considered a future replacement for V2 and V3 and CDA so what is message and what is document is a question that has a new style of answer. | |||
== 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 vs retrieve | |||
Revision as of 11:27, 12 March 2014
These are my notes on FHIR. As they become mature they will probably migrate to John's page.
FHIR class
March 11, 12 2014 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. 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).
REST vs Transactions
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.
Terminology
I use submit and retrieve as simple verbs. In REST they would be POST vs GET. In XDS they would be PnR or Register and Query or Retrieve. FHIR does not distinguish between what we think of as metadata vs documents. It is all content to them. FHIR is considered a future replacement for V2 and V3 and CDA so what is message and what is document is a question that has a new style of answer.
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 vs retrieve