Introduction

Summary: FHIR server django app built on top of FHIRbase

Key objectives:

• Provide a working, documented, FHIR API interface
• Meet the HL7 FHIR Implementer's Safety Checklist
• Support server side django application development by providing the relevant FHIR objects as python/django classes
• Keep technology stack to the minimal technologies identified in Diakonia (python/postgres) to aide maintenance, development, and system administration
• Be as pythonic as possible. Zen is good

Notes

Background research for alternative solutions:

• FHIRbase Github Repository
• List of open source FHIR implementations contains 4 examples: One in Delphi/MSSQL; One in Grails (Java/Groovy/Postgres); One in .net/MongoDB; One in Java/java-db. None of these fit the technology stack requirements
• GNU Health offers a FHIR server in python/tryton/postgres stack, so may offer some help, but isn't close enough to the mark to start from
  • The Tryton based server code is at http://hg.savannah.gnu.org/hgweb/health/file/9e52df027d5d/tryton/backend/fhir/server. Not clear at first glance as to its operation and how/why the fhir classes are hardcoded
  • The basic python client from them is also not maintained... (last uploaded 17/4/2014)
• SMART on FHIR offers a maintained python FHIR client with good documentation. This may be able to be incorportated to provide the FHIR objects as python classes, however this is written as a flask app, so can't be fully run without expanding the tech base with another python framework
  • Perhaps of more use is the SMART on FHIR, fhir-parser which goes through the specification and generates python classes
  • They also have a package of sample patients for testing with
• Django-FHIR (nice optimistic title) is an alpha level project that hasn't seen development in 5+ months which aims to do python/django/mongodb implementation of a FHIR server. Alpha level is a bit of a stretch from browsing through the current master branch, looks like there isn't much to work from here

Requirements

1. Provide a RESTful, FHIR-compliant, API to the data layer
   1. API should be available via https
   2. API should support REST methodology
   3. API should support the following FHIR calls: Create (http POST), Read (http GET), Update (http PUT), Delete (http DELETE)
   4. API should additionally support FHIR calls: vread, history (instance), search (instance), history (type), conformance, history (system), search (system). See FHIR RESTful API pages, in particular the summary table.
2. Create (a resource) should:
   1. Accept http POST request
   2. Map the contents to an url which indicates the resource type (E.g. http://server.org/fhir/patient)
   3. Accept the body’s format in Content-Type header (a: application/json+fhir;charset=utf-8 and b: application/xml+fhir;charset=utf-8)
   4. Return http status 201 (Created).
   5. Return only the newly assigned version id URL in the Location header
3. Update (a resource) should:
   1. Accept http PUT request
   2. Map the contents to an url which indicates the resource type (E.g. http://server.org/fhir/patient/id/_history/version_id)
   3. Accept the body’s format in Content-Type header (a: application/json+fhir;charset=utf-8 and b: application/xml+fhir;charset=utf-8)
   4. Return http status 200 (OK), and the full version URI
   5. If resource does not exist, return http status 405 (Method Not Allowed). This is update, not update-or-create!
   6. If the resource URI does not match the latest version, return http status 409 (Conflict) and do not apply the update

Design

This is the nitty gritty bit... what is a FHIR Server? How much functionality can we hand off to FHIRbase? Are there packages (like Django REST Framework) we can hand off large chunks of functionality to?

FHIRbase have taken the view that json is the standard for web apis, and so don't export xml natively. They do offer an xslt transformation for FHIR xml to json, which is handy, but nothing vice-versa. Whilst it recommends using Saxon as the XSLT engine, lxml is a more common python approach. There is a JS implementation that does json to xml to look at. Consider: Leaving XML implementation to a later version of FHIRstation.

System layer diagram (modelled on the Hospital Systems one). Work in Progress, clearly.

We're using FHIR as a semantic structure for the data layer, with FHIR-like communication happening between data and application layers. FHIR (exact) communication should then be happening between the client and application layers.

Standard ORM techniques from most frameworks are of limited use with FHIRbase directly, though given other system elements will reside in a Postgres DB, they will still have their uses, and the FHIRbase DB can also be queried by SQL SELECT statements via ORM.

Question: Do we handle the Binary endpoint? https://www.hl7.org/fhir/binary.html There's no hint in the FHIRbase docs about what it does or does not support regarding binary types.