A new starter recently asked this question during the first day of being with the company and I realised that the answer I had been used to giving may not really be relevant any more. In the past, I’ve drawn a diagram showing multiple hospital IT systems that need to share data, with the explanation that, creating system to system interfaces between all the different elements leads to complications, support difficulties and, inevitably, high cost. Then I draw the integration engine in the centre and explain that a single inbound interface or incoming data feed may be replicated multiple times, with different “flavours” sent to each recipient, saving time and money. Business case sorted. In the patient care paradigm, little more is expected of the engine.
But this now undersells what an integration engine does, or is capable of. While the bulk of the integration work may still follow this diagram, the engine that Sláinte uses, Interfaceware’s Iguana, took a new approach to solving the healthcare interoperability problem and the solution that they came up with has the potential to change the role of the integration engineer within a healthcare setting.
As I stated in the last Insight article, the historic trend within integration engine development, has been to provide ever-increasingly complex user interfaces. This is in an attempt to reduce the need for (and amount of time spent on) coding and therefore provide rapid development of interfaces. Like anything which isn’t used frequently, coding skills diminish over time and then when called upon, a script which would otherwise be simple becomes complex and error-prone.
The solution Interfaceware came up with was to immerse the engineer in a coding environment which allowed them to rapidly develop scripts, build libraries of commonly used functions and bring the testing into the coding environment. Their Translator components utilise the Lua scripting language, whose runtime operates within the browser process and executes the written code in real time on a set of test data – showing the results of your coding efforts as you type each line. Code completion, versioning, loop step-through and click-to-follow function calls are, amongst other features, built into the same interface.
But while this solution makes creating interfaces a rapid, accurate and efficient way of integrating, it has also re-drawn the boundaries of what constitutes an integration engine. The scripts which run within Iguana aren’t limited to processing integration traffic, and APIs, which specify how components interact with each other, are provided to allow communication with a huge range of systems, including Iguana itself. With this kind of unshackling, what a hospital is left with is a system which may access both patient data and a myriad of hospital systems – back-end, middleware and front-end. The possibilities opened up by this paradigm are only limited by the creativity of the Iguana user.
As an example, a channel (defined as a conduit for a data move or transformation, having a source, filter/transform and endpoint), can be written in a few lines of code, to monitor a high priority database table, checking for inconsistencies or entries which the support team need to know about. When an error is encountered, a web API (
www.twilio.com) is called, with a script which the web service reads to the support team over the phone, with telephone keypad button presses, triggering different actions, thus allowing rapid resolution of the issue. Multiple systems may be monitored, with unlimited actions for issue resolution.
Another example: after simply anonymising HL7 messages, another web API or built application can be used to predict trends in the population, such as the incidence of MRSA infection. The data coming back from this web service can be served up directly by Iguana, running as an HTTP server, in standard coding formats, such as HTML, CSS and Javascript.
These are simply 2 examples of the type of applications which a modern integration engine could and should be used for. The solution which one forward-thinking company designed, to solve the issue of how healthcare data interfaces were being developed, is now innovating in that field, helping to push the boundaries of what is possible, using the data which flows through hospital systems every day worldwide. This makes the answer to the question posed above far more complex.
In answer to the question, an integration engine enables the advancement of healthcare interoperability and ultimately gives the user the powerful tool of 'data', using this, clinicians can make improved decisions and provide better patient care.
Dominic Green - Global Technical Sales Manager UK, Sláinte Healthcare
Dominic has responsibility for overseeing all aspects of interface work between Slaínte products, client sites and 3rd party systems, including scoping, designing and specifying interfaces, designing innovative methods of extracting and utilising data and managing the team which implements and supports the interfaces. Prior to joining Sláinte Healthcare, Dominic graduated from Liverpool University with a 1st class honours in Computer Science and began a career in the NHS, initially within senior programming roles and later moving into integration, interface development and project management. His primary responsibilities involved acquiring, administering and developing the hospital’s interface engine (Iguana), incubating and piloting innovative projects designed to drive efficiency and patient care, organising multi-disciplinary effort and managing the software development lifecycle for in-house developments.
LinkedIn: http://uk.linkedin.com/pub/dominic-green/10/222/aa0