After the last article I wrote was published, I was asked a very insightful question, which was, “If you were writing a new piece of software, how would you go about integrating it?” This led me to reflect on the changes within both our company’s attitude to integration and the changes within the industry in general since I became involved in integration around 8 years ago.
When I joined Sláinte in 2008 to lead the integration function, we set about creating an HL7 specification which customers could use to send data to Claimsure. We very quickly realised two things, however:
- The length of projects was greatly increased if we insisted on our customers providing an interface which matched our exact specification.
- The standard interfaces (ADT, Radiology, Lab, etc.) which are already implemented at most hospitals had everything we needed in some format.
As we incorporated Iguana within all of our product rollouts anyway, we didn’t actually care which format, protocol or order the data arrived in, so long as it built the story of the episode and gave us all the data we needed to build a health insurance claim. So, we stopped developing our own specification and went to customers asking for their standard ADT (and any other) feed. The document we gave out simply stated the data items which were essential, important and desirable.
What we saw as a result of this was a very great drop in the implementation timeline for a Claimsure integration, as we no longer needed to factor in the development and testing of a custom HL7 interface by the PAS/EPR vendor or by the integration team at the hospital. We didn’t need an HL7 specification, but do you?
If your software, like so many other packages, simply requires standard data which every hospital already supplies to other vendors, then the answer is almost certainly no, but this must be qualified by the assumption that you are able to bundle in an integration engine to ease the burden of developing different inbound interfaces for every project.
As an example, we have long worked with a software vendor who recognised that our method of integrating was something they would like to emulate, but they didn’t have the software to do it. What they did have was the foresight to recognise their strengths and weaknesses, which led them to employ Sláinte to manage their integration function. While they concentrated on what they did best and we delivered their data to them, with installation and configuration achieved with minimum involvement from the client, their major competitor fell behind, in market share terms, due to lengthy implementations and an in-built inflexibility.
The decision to not produce a specification had one other unforeseen benefit. By not tying ourselves to an HL7 specification, we didn’t tie ourselves to HL7. While the majority of healthcare interfaces do, and will continue to, use HL7, there are other methods of integrating which may be required or may provide more benefits. By simply treating integration as a separate product or module, there follows a separation of concerns which is beneficial for the project as a whole.
In summary, for many software vendors, an HL7 specification is a document which, while it may provide exactly the feed they require, has a number of downsides. Some vendors, where possible, are avoiding this tactic and separating integration from their core product by leveraging an integration engine, leading to smoother and more rapid implementations.
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