eHealth Week came to Dublin in 2013 and was once again a focal point for knowledge transfer, sharing and discovery of how technology can transform healthcare, set against the backdrop of the hugely impressive Dublin Convention Centre. Expected numbers were >2,500 attendees and >100 exhibitors and there certainly didn’t seem to be a shortage of either of these groups. Common to many shows I’ve attended recently, there was more of an air of cautious optimism than in the years immediately following the global financial crisis. Buyers are still wary, but at least there are buyers.
My particular interest in healthcare surrounds integration and as such I was privileged to be asked to be a part of the panel for the HL7 discussion. Inhabitants of the integration world tend to fall into one of two groups (although there is a lot of crossover). The first group spend a lot of their time contributing to the development of standards such as HL7 v3, the RIM and FHIR. The second group’s working lives revolve around getting disparate systems, often using ageing technology and data models, to interact under tight budgetary and time constraints. This leads them to almost invariably use v2, as it is nearly ubiquitous and getting another vendor to implement an additional standard is futile without a solid business case. The HL7 meeting, as with the majority of HL7 events, was comprised of almost exclusively the first group, which led to a lot of discussion of reasonably obscure concepts. The opening address was from Charles Jaffe, CEO of HL7 International. His talk gave an overview of the major developments within HL7, including the removal of licensing restrictions on HL7 IP and the groundswell which is building behind FHIR.
FHIR (Fast Healthcare Interoperability Resources) uses RESTful web services (amongst other methods) to insert, delete, update and request resources to/from a compliant server. The resources are designed to be atomic, removing one of the bugbears with v2, which is that a full message is required to change just one detail, increasing processing at all stages. They are encoded in either XML or JSON.
By way of an example use case, if a user creates a patient within a PAS which is connected via FHIR to a compliant radiology system maintaining a shadow PMI, the PAS uses an HTTP PUT statement to send a JSON representation of just the patient demographics to the radiology system, which updates its database accordingly. HTTP GET are used to read resources, DELETE to remove them and so on.
We at Slainte have been following FHIR for some time, as we long ago recognised that HL7 v2 was limited, v3 was over-engineered and there were no real alternatives. Our solution was to create a web service API which we expose to our integration engine. The concept of publishing an API to your product is one which is almost unheard of in healthcare IT, but is one which deserves exploration. The idea of plug and play interoperability has long been the panacea of healthcare IT, but there are three (interlinked) issues with this. The first is that at some point, the data from each system has to be mapped onto a common data model. Whether this happens as part of the interfacing, or as part of the structure of the application, it is both difficult and expensive. This leads to the second issue: finance. Few vendors are willing to take on the expense of mapping to a data model in this way when the ROI is unclear. It will only work when the industry as a whole takes on the same data model. The final issue is that almost every system has custom data items which don’t map to a common data model, meaning all interoperability standards need a way of transmitting custom data.
HL7 v2 has been so popular because it addresses all three of these points. It is a cheap-to-implement standard, used across the industry which gives an easy way to include any data. But this strength of v2 has also been one of its biggest downfalls. Because the model can be changed and customised at will, no two vendors implement it in exactly the same way. This has led to custom interfaces for every project, which are difficult to implement and maintain, in part because each message tries to pass far too much data, most of which is irrelevant to the event in question.
A web API fixes a lot of these problems. Vendors of modern software find it relatively easy to present an API – indeed, if they are dealing with legacy v2 interfaces, they may find it extremely beneficial financially to create an API even for internal use to parse incoming HL7 onto. Custom data items are easily exposed and transported, ignored if they are irrelevant. The only data transferred is the data which is relevant and required. 2-way interfaces become as simple to expose as 1-way.
Increasingly, however, what we are seeing is that FHIR is not going to be the answer to the problems that we face in interoperability because it maintains the reliance on a standard data model. This is not the same as exposing an API. It adds a layer of translation and the same issues which have been ensuring that interoperability remains complex and costly remain.
Perhaps understandably, the HL7 forum at WOHIT focused still on adoption and development of v3 and aspects of CDA. There were presentations from industry representatives who showed ecosystems of interoperating systems with hundreds of interfaces (this was very positive and should be applauded). But perhaps the questions we are trying to answer in interoperability need to be revisited and reframed.
On a more general note, this conference, like many others, was missing one of the key ingredients to adoption of technology in healthcare – clinicians. In 2011, Hungary’s show saw 5% of the attendees classing themselves as clinicians. In Copenhagen last year, this figure dropped to a mere 1%. My estimation from the people I met this year was that the corresponding percentage in Ireland was still worryingly low.
This isn’t to say that the event was anything other than positive. From an exhibitor perspective, there was a lot of footfall which will lead to some very interesting and innovative solutions being implemented across Europe and the rest of the world. It is always useful to discover what those outside your immediate markets and experience are doing to solve problems which pay no regard to international boundaries. We will certainly be revisiting the conference next year.