WorkingMouse tack­les the eHealth pro­to­col at Australia’s Health Startup Weekend

A startup week­end is dif­fer­ent to a hackathon. At a hackathon the prob­lems are usu­ally set by prob­lem own­ers and over the week­end a pro­to­type is de­vel­oped. A startup week­end is more about val­i­dat­ing an idea for a mar­ket and find­ing out if any­one is in­ter­ested. For the Health Startup Weekend each of the groups brought their own ideas. Finding out the tar­get mar­ket as early as pos­si­ble can mit­i­gate the risk of build­ing the wrong prod­uct or sim­ply build­ing a prod­uct that no one wants. It was a great col­lab­o­ra­tive week­end with 140 at­ten­dees, 80 full week­end par­tic­i­pants and 13 pitches!


The idea WorkingMouse wanted to ex­plore over the week­end was re­lated to eHealth in Australia. The National eHealth Transition Authority (NEHTA) is lead­ing the na­tional vi­sion for Australia’s eHealth fu­ture. One of their re­spon­si­bil­i­ties is to cre­ate the pro­to­col used by soft­ware sys­tems to ex­change in­for­ma­tion. Having a com­mon pro­to­col is fun­da­men­tal for the fu­ture of eHealth. So, what is a pro­to­col?

An ex­am­ple of a pro­to­col that you would use of­ten is the Simple Mail Transfer Protocol (SMTP) used for send­ing emails. For sim­plic­ity, this pro­to­col says you will have a to’ ad­dress, CC ad­dress, BCC ad­dress, from’ ad­dress, sub­ject, con­tent, at­tach­ments, etc. Since it is a pro­to­col - and every­one ad­heres to it - we can send emails around the world. So, in the same spirit, NEHTA has spec­i­fied a pro­to­col for eHealth. Their pro­to­col says what will be in a pa­tient record, al­low­ing us to ex­change pa­tient record in­for­ma­tion. This is re­ally im­por­tant to en­able eHealth to open up all sorts of pos­si­bil­i­ties that were not pre­vi­ously con­ceiv­able.

One of the biggest chal­lenges is the tech­ni­cal one; how do we get soft­ware sys­tems to sup­port the pro­to­col? For ex­am­ple, the Shared Health Summary (SHS) and its re­lated doc­u­men­ta­tion can be down­loaded in 7 dif­fer­ent groups of files. Some of these are un­zipped to re­veal more. The main spec­i­fi­ca­tion it­self is a 140 page PDF doc­u­ment with 14 Chapters and 7 sub-sec­tions per chap­ter - a mind bog­gling amount of in­for­ma­tion. And to fur­ther com­pound the prob­lem, the SHS is one of around thirty clin­i­cal doc­u­ments to deal with.

First, our job was to val­i­date this as a prob­lem in the mar­ket. So we went and spoke with the other groups that were at­tend­ing the week­end and asked them - how would you share the in­for­ma­tion they were gath­er­ing with other soft­ware sys­tems for eHealth? They all ex­pressed that they could­n’t as the bar­ri­ers for en­try were too high and they there­fore placed the prob­lem in the too hard’ bas­ket. We at­tempted to con­tact some ex­ist­ing soft­ware providers to find out how they were ad­dress­ing the chal­lenge, but re­cieved no re­sponse as it was a week­end (we are still fol­low­ing this up).

There are 3 gen­eral ap­proaches that can be taken when at­tempt­ing to sup­port the eHealth pro­to­col in your soft­ware sys­tem. First is the tra­di­tional ap­proach, read and un­der­stand the doc­u­men­ta­tion and then hand-code a so­lu­tion. Besides be­ing a lengthy ex­er­cise, the on­go­ing main­te­nance on this ap­proach means that every new ver­sion of the pro­to­col re­quires more ef­fort. The sec­ond ap­proach is to use the NEHTA toolset. They do pro­vide ex­am­ples in .NET (and I be­lieve Java soon or this maybe avail­able now) but these are ex­am­ples only and is there­fore lim­ited to just these tech­nolo­gies. The third op­tion - and our favourite - is to use code gen­er­a­tors and ro­bots to do all the heavy lift­ing for you. A good ex­am­ple of this in the wider tech­nol­ogy com­mu­nity is Swagger, the open API ini­tia­tive.

The so­lu­tion we wanted to ex­plore was to cre­ate a toolset for soft­ware sys­tems that al­lowed them to use the eHealth pro­to­col. Here at WorkingMouse we ad­vo­cate the use of code gen­er­a­tors and ro­bots to cre­ate as much of the code and files as we can. A pro­to­col is a per­fect can­di­date for this type of work. The so­lu­tion - shown in the di­a­gram be­low - was to cre­ate an im­porter that re­verse en­gi­neered a model from the pro­to­col. From the model we then gen­er­ated an ap­pli­ca­tion and a toolset. The toolset pro­vided a de­vel­oper API and some client li­braries for com­mu­ni­cat­ing us­ing the eHealth pro­to­col. The ap­pli­ca­tion pro­vided a user in­ter­face to al­low some op­er­a­tions on a SHS like read­ing, up­dat­ing, etc.


The re­sult was a model as seen in the first screen­shot be­low. By us­ing a code gen­er­a­tor we had mapped the process from the pro­to­col as well as an ex­act rep­re­sen­ta­tion. We also had an API ready to com­mu­ni­cate us­ing the pro­to­col seen in the sec­ond screen­shot be­low. The API here is RESTful/JSON and we would need to change it over to also sup­port SOAP for the PCEHR, but for the week­end demon­stra­tion, what we achieved was enough to demon­strate the process.



The prob­lem of sup­port­ing eHealth in Australia will con­tinue. At the mo­ment, the pro­to­col is based on HL7′s Clinical Document Architecture (CDA) pro­to­col. Soon there will be more pro­to­cols to sup­port like Fast Healthcare Interoperability Resources (FHIR). We also have not touched on the con­for­mance lev­els or se­cu­rity re­lated is­sues ei­ther. This means more work needs to be done by soft­ware ven­dors. We be­lieve what we achieved demon­strated an ap­proach us­ing code gen­er­a­tors and ro­bots that helps lower the cost and main­tain an ac­tive ecosys­tem of soft­ware ven­dors.

In sum­mary, the startup week­end brought a lot of lessons. It was in­ter­est­ing to see a num­ber of groups find out that the idea they thought had a lot of po­ten­tial would un­likely gain mar­ket trac­tion or a vi­able busi­ness model. For ex­am­ple, one group liked the idea of vi­t­a­min-wa­ter and thought it could be ex­tended to in­clude vi­t­a­min-cidar. Why could­n’t drink­ing also be healthy? So, they did some mar­ket re­search but by the end of the week­end they de­cided that the mar­ket did not ex­ist be­cause most drinkers are not that health con­scious. So though they failed, they are now mov­ing onto the next idea. By the end of the week how­ever, we con­tinue to be sat­is­fied that the prob­lem of sup­port­ing eHealth pro­to­cols will con­tinue on and be even more per­ti­nent once it be­comes manda­tory.

Thanks to Bernie, all the men­tors, or­gan­is­ers and other at­ten­dees for a great week­end and we look for­ward to next year! And all the crew at NEHTA please keep up the good work in mov­ing us all - which is a mam­moth job - to­wards an eHealth fu­ture.

To learn more about APIs check out WorkingMouse’s blog.



Matt Francis

Brewer of beers, smoker of meats

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call