Difference between revisions of "Transport Pattern Mapping"
WalcoVanLoon (talk | contribs) |
WalcoVanLoon (talk | contribs) |
||
| (12 intermediate revisions by the same user not shown) | |||
| Line 14: | Line 14: | ||
There are some exceptions to this scheme: the "transaction" operation utilizes POST to create or update a set of resources (resource bundle) atomically. | There are some exceptions to this scheme: the "transaction" operation utilizes POST to create or update a set of resources (resource bundle) atomically. | ||
| − | == Mapping of FHIR operations to existing | + | == HTTP headers == |
| + | As with most REST based APIs, Content-Type and Accept headers are used to process or request a specific representation of a resource. Location can either identify a resource or be a symbolic endpoint in FHIR with specific semantics (Mailbox, Binary). | ||
| + | |||
| + | == Mapping of FHIR operations to existing IHE transactions == | ||
=== Transaction === | === Transaction === | ||
This operation can facilitate Provide & Register Document Set-b (ITI-41, ITI-42), "Update Document Set" (ITI-57) and "Delete Document Set" (ITI-62) transactions. It can create and update a set of resources (authors, documents) in one transaction: | This operation can facilitate Provide & Register Document Set-b (ITI-41, ITI-42), "Update Document Set" (ITI-57) and "Delete Document Set" (ITI-62) transactions. It can create and update a set of resources (authors, documents) in one transaction: | ||
| − | * If entry.content is omitted, the resulting operation | + | * If entry.content is omitted, the resulting operation maps to Register Document Set-b (ITI-42). |
| − | * If entry.id refers to an existing resource, it mimicks "Update Document Set" | + | * If entry.id refers to an existing resource, it mimicks "Update Document Set" (ITI-57) |
| − | * If entry.deleted specifies a date before now, the entry will be deleted. | + | * If entry.deleted specifies a date before now, the entry will be deleted, mimicking "Delete Document Set" (ITI-62). Note that entry.content will also be deleted. |
| + | |||
| + | The MHD "Put Document Dossier" (ITI-65) transaction could be mapped in a similar fashion. This would enrich the semantics of this transaction and add support for the creation of multiple resources. | ||
=== Read === | === Read === | ||
| − | This operation can be used for the current Retrieve Document Set transaction, although it can only be used for | + | This operation can be used for the current Retrieve Document Set (ITI-43) transaction, although it can only be used for a single resource. The "search" operation might be an alternative. |
=== Delete === | === Delete === | ||
| − | This operation can be mapped to Delete Document Set, but only works for | + | This operation can be mapped to Delete Document Set (ITI-62), but only works for a single resource. |
| + | |||
| + | === Update === | ||
| + | This operation can be mapped to Update Document Set (ITI-57), but only works for a single resource. | ||
| + | |||
| + | === Search === | ||
| + | This operation can be mapped to various query transactions. | ||
| + | |||
| + | Open issue: can it be used for Retrieve Document Set - the "Patient" compartment could be used to retrieve all document resources for a given patient (?) | ||
== Resources == | == Resources == | ||
| − | Resources in FHIR can be represented in JSON, XML and as Binary. | + | Resources in FHIR can be represented in JSON, XML (application/xml+fhir) and as Binary. Binary content can be specified in JSON using the "data" attribute on "content" objects, containing Base64 encoded data. XHTML content can be conveyed through a "div" attribute on "text" objects. For the XML representation, these are both XML elements. In JSON, the "resourceType" attribute specifies the type of resource (Bundle, Patient,...). |
| − | + | Open issue: it is unclear whether data can be submitted as a separate multipart entry with a (cid) reference in the JSON representation to allow submission of large files and prevent the base64 encoding for inline data. | |
| − | |||
=== Bundles === | === Bundles === | ||
| − | Operations on sets of resources are performed on resource bundles. In XML these are represented as Atom Feeds. The JSON representation is a custom format that honors order | + | Operations on sets of resources are performed on resource bundles. In XML these bundles are represented as Atom Feeds (RFC 6721) (mime type: application/atom+xml). The JSON representation (mime type: application/json+fhir; "resourceType": "Bundle") is a custom format that honors logical order in entries, and tries to follow the XML representation where possible. |
| + | |||
| + | == Symbolic endpoints == | ||
| + | === Mailbox === | ||
| + | Models one way messaging in FHIR. Messages or bundles can be sent to this endpoint. Might be mapped to "Asynchronous Web Services Exchange". | ||
| + | |||
| + | === Binary === | ||
| + | Binary representations can be created, and fetched using a specific location on the resource. Search is not supported for such a resource. The mime type matches the binary content. | ||
Latest revision as of 16:12, 21 July 2014
FHIR-MHD Transport Pattern Mapping Notes
- FHIR REST API (in least in theory) is based on OMG Health RESTful specification
- http://www.omg.org/spec/HData/1.0/PDF/
- on first inspection, it does not seem to cause incompatibility issues with existing use of REST in MHD.
- the recommendation of using CORS has impact on HTTP level: http://enable-cors.org/. Discussed in http://www.hl7.org/implement/standards/fhir/security.html
HTTP verbs used for basic operations on a (single) resource in FHIR
- POST - create
- PUT - update
- DELETE - delete
- GET - read
There are some exceptions to this scheme: the "transaction" operation utilizes POST to create or update a set of resources (resource bundle) atomically.
HTTP headers
As with most REST based APIs, Content-Type and Accept headers are used to process or request a specific representation of a resource. Location can either identify a resource or be a symbolic endpoint in FHIR with specific semantics (Mailbox, Binary).
Mapping of FHIR operations to existing IHE transactions
Transaction
This operation can facilitate Provide & Register Document Set-b (ITI-41, ITI-42), "Update Document Set" (ITI-57) and "Delete Document Set" (ITI-62) transactions. It can create and update a set of resources (authors, documents) in one transaction:
- If entry.content is omitted, the resulting operation maps to Register Document Set-b (ITI-42).
- If entry.id refers to an existing resource, it mimicks "Update Document Set" (ITI-57)
- If entry.deleted specifies a date before now, the entry will be deleted, mimicking "Delete Document Set" (ITI-62). Note that entry.content will also be deleted.
The MHD "Put Document Dossier" (ITI-65) transaction could be mapped in a similar fashion. This would enrich the semantics of this transaction and add support for the creation of multiple resources.
Read
This operation can be used for the current Retrieve Document Set (ITI-43) transaction, although it can only be used for a single resource. The "search" operation might be an alternative.
Delete
This operation can be mapped to Delete Document Set (ITI-62), but only works for a single resource.
Update
This operation can be mapped to Update Document Set (ITI-57), but only works for a single resource.
Search
This operation can be mapped to various query transactions.
Open issue: can it be used for Retrieve Document Set - the "Patient" compartment could be used to retrieve all document resources for a given patient (?)
Resources
Resources in FHIR can be represented in JSON, XML (application/xml+fhir) and as Binary. Binary content can be specified in JSON using the "data" attribute on "content" objects, containing Base64 encoded data. XHTML content can be conveyed through a "div" attribute on "text" objects. For the XML representation, these are both XML elements. In JSON, the "resourceType" attribute specifies the type of resource (Bundle, Patient,...).
Open issue: it is unclear whether data can be submitted as a separate multipart entry with a (cid) reference in the JSON representation to allow submission of large files and prevent the base64 encoding for inline data.
Bundles
Operations on sets of resources are performed on resource bundles. In XML these bundles are represented as Atom Feeds (RFC 6721) (mime type: application/atom+xml). The JSON representation (mime type: application/json+fhir; "resourceType": "Bundle") is a custom format that honors logical order in entries, and tries to follow the XML representation where possible.
Symbolic endpoints
Mailbox
Models one way messaging in FHIR. Messages or bundles can be sent to this endpoint. Might be mapped to "Asynchronous Web Services Exchange".
Binary
Binary representations can be created, and fetched using a specific location on the resource. Search is not supported for such a resource. The mime type matches the binary content.