For a long time, the well-trodden path within healthcare IT has been to look to large-scale, one-size-fits-all systems, costing many millions of pounds/euros/dollars and taking years to implement – in the UK, the National Programme for IT (NPfIT) was a prime example, becoming both the largest civilian IT project of all time – and one of the biggest failures. Nearly 15 years after the launch of the scheme, one of whose prime objectives was to provide a care record which would be truly portable, we aren’t much closer to achieving that goal (although some aspects of the programme have had rather more success). When the coalition government was elected in the UK in 2010, the Department of Health held a review into NPfIT and concluded that, “a centralised, national approach is no longer required… A new approach to implementation will take a modular approach… NHS services will be the customers of a more plural system of IT embodying the core assumption of ‘connect all’, rather than ‘replace all’” ⁽¹⁾.

The ability to ‘connect all’ has a major flaw, however. There have been relatively few material advances in the world of health interoperability during the last 20 years. The dominant standard, HL7, has only had 2 major releases – version 2 and version 3. While version 2 is almost ubiquitous, it is far from perfect (“if you’ve seen one HL7 interface, you’ve seen one HL7 interface” is almost a cliché now). Version 3, the standard which the majority of effort has been spent on, arguably has only one useful implementation in the form of CDA (Clinical Document Architecture). Amongst other criticisms, version 3 is costly to implement, doesn’t respond well to change requests and creates semantic interoperability at the expense of clinical interoperability. Amongst other potential standards, FHIR was looking like a more reasonable proposal, but has a long way to go before it is usable, primarily because it still relies on the implementation of a standard data model within the interface. In fact, this has been the crux of many problems with the writing of standards for healthcare interoperability – how to create a standard which allows plug-and-play interconnection while remaining flexible enough that all software which needs to can use it, all without making the cost of implementation astronomical.

Meanwhile, interoperability outside healthcare has advanced dramatically through the sharing of data through web services. The number of companies publishing open APIs has grown exponentially and has led to the web becoming a vastly more joined-up place. Having a Facebook account has become a way of signing in to a vast diversity of websites. Any product can be linked to its independent reviews. Need to provide an address to a customer? Show them instead, using a Google Map embedded in your site.

Traditionally, healthcare data has consisted of silos of information which the software’s rights holder jealously guarded for two main reasons; protection of data integrity and protection of potential income from charging for an interface. The vendors wrote and sold interfaces – some standard, some custom – usually at great cost. This resulted in the growth of integration engines to allow an interface, bought once, to be replicated and shared between many downstream applications in a variety of formats (amongst other uses). The idea of a hub and spoke approach to the sharing of data appealed to people drawing diagrams of data flow because it made everything seem simple, but it also creates a single point of failure. The fact is, though, that the majority of applications within an ecosystem will only require data to be exchanged with a minimal subset of the other applications available, meaning that while the potential number of connections between nodes is n(n-1)/2, the actual number of connections will be much lower. In any case, within a web services environment, the number of connections is largely irrelevant.

The two objections to vendors opening their data up are easily overcome with an open API:

• With an API, you still control data access. A web function still obeys your business rules.
• There are almost as many business models around open APIs as there are open APIs, such as totally free (where the benefits revolve around increased market share gained through ease of use and other, less quantifiable benefits), pay-as-you-go, freemium, revenue share, subscription and many more.

Some of the larger and/or more forward-thinking vendors are starting to approach integration in this manner, - but few SMEs have had the courage to try to publish an API – or at least create one which is distributed to its customers. It’s easy to see why. Web APIs are widely understood. They are easy (read low cost) to implement because they build on the existing business and data layers within a product. They are easy to maintain and they don’t require a vendor to conform to any set data model within their software. Until such time as semantic interoperability may be achieved at a cost which would provide a return on investment within a lifetime, open APIs seem to be where healthcare should be headed towards.

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

 

⁽¹⁾ webarchive.nationalarchives.gov.uk/20130107105354/http:/www.dh.gov.uk/en/MediaCentre/Pressreleases/DH_119293