Please note that this blog is archived and outdated. For the most current information click here!

WorkingMouse Tackles eHealth at Australia’s Startup Weekend

A startup weekend is different to a hackathon. At a hackathon the problems are usually set by problem owners and over the weekend a prototype is developed. A startup weekend is more about validating an idea for a market and finding out if anyone is interested. For the Health Startup Weekend each of the groups brought their own ideas. Finding out the target market as early as possible can mitigate the risk of building the wrong product or simply building a product that no one wants. It was a great collaborative weekend with 140 attendees, 80 full weekend participants and 13 pitches!

The idea WorkingMouse wanted to explore over the weekend was related to eHealth in Australia. The National eHealth Transition Authority (NEHTA) is leading the national vision for Australia's eHealth future. One of their responsibilities is to create the protocol used by software systems to exchange information. Having a common protocol is fundamental for the future of eHealth. So, what is a protocol?

An example of a protocol that you would use often is the Simple Mail Transfer Protocol (SMTP) used for sending emails. For simplicity, this protocol says you will have a 'to' address, CC address, BCC address, 'from' address, subject, content, attachments, etc. Since it is a protocol - and everyone adheres to it - we can send emails around the world. So, in the same spirit, NEHTA has specified a protocol for eHealth. Their protocol says what will be in a patient record, allowing us to exchange patient record information. This is really important to enable eHealth to open up all sorts of possibilities that were not previously conceivable.

One of the biggest challenges is the technical one; how do we get software systems to support the protocol? For example, the Shared Health Summary (SHS) and its related documentation can be downloaded in 7 different groups of files. Some of these are unzipped to reveal more. The main specification itself is a 140 page PDF document with 14 Chapters and 7 sub-sections per chapter - a mind boggling amount of information. And to further compound the problem, the SHS is one of around thirty clinical documents to deal with.

First, our job was to validate this as a problem in the market. So we went and spoke with the other groups that were attending the weekend and asked them - how would you share the information they were gathering with other software systems for eHealth? They all expressed that they couldn't as the barriers for entry were too high and they therefore placed the problem in the 'too hard' basket. We attempted to contact some existing software providers to find out how they were addressing the challenge, but recieved no response as it was a weekend (we are still following this up).

There are 3 general approaches that can be taken when attempting to support the eHealth protocol in your software system. First is the traditional approach, read and understand the documentation and then hand-code a solution. Besides being a lengthy exercise, the ongoing maintenance on this approach means that every new version of the protocol requires more effort. The second approach is to use the NEHTA toolset. They do provide examples in .NET (and I believe Java soon or this maybe available now) but these are examples only and is therefore limited to just these technologies. The third option - and our favourite - is to use code generators and robots to do all the heavy lifting for you. A good example of this in the wider technology community is Swagger, the open API initiative.

The solution we wanted to explore was to create a toolset for software systems that allowed them to use the eHealth protocol. Here at WorkingMouse we advocate the use of code generators and robots to create as much of the code and files as we can. A protocol is a perfect candidate for this type of work. The solution - shown in the diagram below - was to create an importer that reverse engineered a model from the protocol. From the model we then generated an application and a toolset. The toolset provided a developer API and some client libraries for communicating using the eHealth protocol. The application provided a user interface to allow some operations on a SHS like reading, updating, etc.

The result was a model as seen in the first screenshot below. By using a code generator we had mapped the process from the protocol as well as an exact representation. We also had an API ready to communicate using the protocol seen in the second screenshot below. The API here is RESTful/JSON and we would need to change it over to also support SOAP for the PCEHR, but for the weekend demonstration, what we achieved was enough to demonstrate the process.

The problem of supporting eHealth in Australia will continue. At the moment, the protocol is based on HL7's Clinical Document Architecture (CDA) protocol. Soon there will be more protocols to support like Fast Healthcare Interoperability Resources (FHIR). We also have not touched on the conformance levels or security related issues either. This means more work needs to be done by software vendors. We believe what we achieved demonstrated an approach using code generators and robots that helps lower the cost and maintain an active ecosystem of software vendors.

In summary, the startup weekend brought a lot of lessons. It was interesting to see a number of groups find out that the idea they thought had a lot of potential would unlikely gain market traction or a viable business model. For example, one group liked the idea of vitamin-water and thought it could be extended to include vitamin-cidar. Why couldn't drinking also be healthy? So, they did some market research but by the end of the weekend they decided that the market did not exist because most drinkers are not that health conscious. So though they failed, they are now moving onto the next idea. By the end of the week however, we continue to be satisfied that the problem of supporting eHealth protocols will continue on and be even more pertinent once it becomes mandatory.

Thanks to Bernie, all the mentors, organisers and other attendees for a great weekend and we look forward to next year! And all the crew at NEHTA please keep up the good work in moving us all - which is a mammoth job - towards an eHealth future.