NHS hack days are weekends in which clinicians and software developers come together to try to develop information technology solutions for healthcare.

There is a really good piece about them in the BCS magazine by Dr Marcus Baw.

I think they are a great idea and have attended two in Cardiff, most recently as one of the judges.

However, I perceive the benefits to be principally about networking and fun, rather than successfully creating early working versions of products that are then rolled out into the NHS. How many great ideas have been rolled out?

One of the problems is that projects essentially start from nothing.

An open platform

What would happen if, instead of starting with nothing, we provided teams with an open application programming interface (API) containing data, services and logic on which their solutions can run?

This is the year in which this can truly become a reality, with standards such as FHIR and openEHR becoming adopted, we as a community need to start work on building “mocked services”.

Hackday Schematic

Most of these services should be provided via FHIR endpoints and provide mock data. When it comes to running in a live environment, as long as there is a FHIR service that provides those same endpoints, an application will need less work in order to make it a production-ready application.

What needs to be done?

The diagram above is deliberately simple. There are lots of complexities and lots of work to do, but it is achievable.

The very nice feature of FHIR is that services can provide one or many different resources. One might write a single service that only provides patient demographic service. As such, one can implement functionality piecemeal and incrementally.

I think we need to prioritise a list of resources and services in order:

  • Patient demographic service (PDS). We could start with fake data and then switch to using https://github.com/nhs-ciao/ciao-pds-fhir for production - the Ciao PDS is a FHIR facade around the real NHS Spine PDS - or a local organisational patient administration system.
  • Terminology services, including SNOMED-CT. I have already built an open-source SNOMED-CT REST service, but it isn’t currently FHIR compatible. However, the last time I looked the FHIR terminology standard didn’t support free-text search. I’d like to add support for other terminologies, such as LOINC, and provide FHIR-compatible end-points.
  • Laboratory information management system. See FHIR diagnostic report resource
  • A UK NHS reference data service. This should be straightforward so that we take the NHS ODS data from TRUD and provide as FHIR end-points (e.g. see organisations). In Wales, mapping practitioners is much easier as there is a central active directory, but I gather this might not be the case in England.
  • Document storage and retrieval. While the FHIR standard explains how to aggregate resources into a document, initially I’d suggest focusing on a simple document reference store to serve documents created by legacy systems.
  • Patient eFlow / e-observations service. See observation FHIR resource.

With these few core components and lots of fake data, NHS hack days could start adding value quickly making it much more likely that any solutions can evolve to become truly useful within the NHS.