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.