Test-Driven Development With FHIR

Peter JordanWhile preparing for, and participating in, the recent FHIR Connectathon 11 held in Orlando, Florida, yet another benefit of FHIR’s implementer-friendly philosophy became apparent to me – the ability to facilitate Test-Driven Development (TDD).

TDD has been defined as “a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.” Dating back to 2003, TDD is now considered by many developers to represent the state of their art – shining some much-needed light on the darkness might be another way of looking at it!

Having decided to register for the Terminology Services Track to put a nascent Terminology Server, built for my client Patients First Ltd, through its paces, I was able to locate a series of Test ValueSets and load them onto my Server before jetting to Orlando with test client in hand. The FHIR community had saved me the trouble of creating these resources myself and, for a bonus point, given me the benefit of refinements made in previous Connectathons, plus a list of the Operations to be executed against these artefacts – all clearly described, with examples galore, in the Terminology Service Section of the FHIR Specification.

Although many developers’ adoption of TDD is restricted to Unit Testing, it is actually applicable to any form of testing that can be injected into an agile-based project with iterative development cycles – including interoperability and conformance testing. Furthermore, it still allows the professional tester to be a developer’s best friend so, with this thought in mind, my first Connectathon task was to locate the representatives of Healthcare Information Exchange (HIE) compliance testing specialists, AEGIS.net.

FHIR Connectaton 11-Image credit Peter Jordan

Our relatively tall ships had collided on previous nights although, on this occasion, my smartphone overrode my body clock informing me that it was morning! Anyway, re-introductions over, I immediately posed the question…”I’d like to test my Terminology Server – what have you got for me” and received an instant response…the Touchstone Test Platform (Touchstone).

To precise the description that followed, this cloud-based tool provides highly-granular, professional-level, automated on-line testing with detailed reporting on both warnings and errors – using a set of pre-supplied test scripts and resources (covering, of course, all the Connectathon scenarios). “Sounds perfect, quick driving lesson please!” was my next request.

To their great credit, AEGIS was able to set up my account, provide a quick user tutorial and respond to issues (including one tiny glitch with a test script) throughout the day. In a room packed with over 120 participants, this was no mean feat! In the course the day, the Touchstone application threw both good and bad data at my server, highlighting a number of issues and weaknesses that necessitated three server upgrades. Post-Connectathon, from faraway New Zealand, I’ve continued to use Touchstone to re-run the full suite of tests after every published QA release of my Server and passed on suggestions and resources for additional tests. Like FHIR itself, this process is inclusive, engaging, productive and fun!

The tool itself is pretty easy to use with a pleasing user interface; the screenshot below gives a small flavour of “Touchstone Nirvana” – the tests all pass…

Now…most developers do not like to broadcast failures, and I’m no exception…but suffice to say there were more than a few on the day! However, I am happy to share a warning that details my various sins against the text element of a ValueSet.

Realistically, developers need to park their egos before logging into Touchstone: this Tool exposes your bugs and omissions – and that’s a good thing, right? It throws various combinations of good and bad data at a server, and demands that it be treated appropriately – strictly according to the specification. Generally speaking, developers write tests to prove that their software works – so-called “happy path” testing, whereas Touchstone places an equal, and compensating, importance on negative testing and – in all instances – supplies highly granular evidence to support its assertions, including full details of each request and response.

While any explanation of the inner workings of this wonderful tool is best left to its developers, one key aspect worth mentioning is the internal use of a FHIR Resource designed to aid its very purpose – the Testscript Resource. This Resource specifies a suite of tests against a FHIR server implementation to determine compliance against the FHIR specification. In other words, FHIR supplies a resource to test implementations – in a standardised way.

My parting thought is that FHIR’s almost native facilitation of the modern development methodology of TDD may well become one of its key value propositions. It also has the potential to close the HIE standards implementation “loop” by providing both standardisation and transparency to conformance testing processes. Adapting a fashionable FHIR slogan…“Build-Test-FHIR-Repeat”.