Vendor-Driven Standards for Interoperability
David Hancock, the healthcare executive advisor at InterSystems, was recently elected vendor co-chair of INTEROPen, a UK collaboration that promotes open standards for interoperability in the health and care sector. HealthManagement.org spoke to David about why he wants INTEROPen to be vendor-led and how this approach will help both suppliers and the health and care ecosystem.
What is INTEROPen, and why has it grown so quickly?
INTEROPen is a collaborative that was set up three years ago to promote the development and adoption of open standards for interoperability in health and social care. There were seven founder members, of which InterSystems was one, but there are 350 organisations involved today.
I think INTEROPen has grown so quickly for two reasons. Firstly, because the focus of National Health Service (NHS) policy has been to create integrated health and care organisations to shift care closer to the patient. Secondly, because we have known for a long time that the greatest risk of a gap in care opening up, or of poor-quality care being delivered, is when a patient is passed from one provider or professional to another and they can’t share information because they use different systems. Both require the IT systems that organisations use to “talk to each other” as health and social care secretary Matt Hancock puts it. And the way to get systems talking to each other is to make sure they use standards to code and structure and exchange data in the same way.
How is the leadership of INTEROPen changing?
This summer, there was an election for a new vendor co-chair, which is the position I now hold. I will co-chair the monthly INTEROPen board meetings with my colleague, Luke Readman, who works in the NHS as the senior responsible officer for the One London local health and care record exemplar.
I will also work with three other vendor representatives who sit on the board of INTEROPen, who come from Cerner, Orion Health and System C. The aim is to make INTEROPen more vendor-led, while still being in dialogue with the NHS and standards organisations, so we can all achieve win-wins together.
Why do you want INTEROPen to become vendor driven?
Until now, INTEROPen has tended to focus on working with NHS Digital and with NHS organisations to define standards. It still needs to do that, because it needs to make sure that the work it is doing is the work that health and care needs to be done.
But it also needs to shift its focus to adoption. It’s not enough to define standards; we need to be able to plan for their success, so we can reduce the time it takes to get to a critical mass of adoption. The most important way to do that is to get standards built into vendor products.
Health and care organisations purchase a lot of commercial, off-the-shelf solutions, and they purchase a lot of integration engines to help them exchange information with each other. If they all support standards, that will drive adoption across the service.
What are the benefits for suppliers of this approach?
On the one hand, this is about supporting start-ups and small and medium sized companies. NHSX, the new unit set up to lead NHS IT, wants to move towards creating technology platforms on which smaller companies can ‘plug and play;' but they will only be able to do that if their own products use standards.
We want to give small companies a voice, help them adopt standards and mature them over time, so that we support innovation but also make sure it is replicable. At the same time, we want to make sure large companies have new standards on their development roadmaps.
As a supplier, I know roadmaps are normally defined six to 12 months out, so if there are new standards coming along, we need to know what they are going to be, and when they are going to be released. We also need to make sure that if vendors invest in the development and support of standards those standards are going to be used. If they aren’t, as a supplier, you think: “All the resources that I put into meeting this standard could have been used for something else; something that would have made a return for me and delivered a benefit for my customers.” There is an opportunity cost in the work we do, and we have to recognise that.
Why is it important for the healthcare ecosystem to adopt this approach?
The standards that we are working with these days are much more complex than the standards we used in the past. For example, the NHS and its vendors are working with standards for health data exchange called Fast Healthcare Interoperability Resources (FHIR) which are published by the HL7 organisation.
FHIR is sophisticated and it defines how healthcare data should be specified, coded, how it should be secured and implemented when used in different ways (for example as messages, or as documents or as APIs).
This complexity means we do not always know how new standards will work in the wild. So, we need to get them tested, for example in events that we call hackathons. INTEROPen sets these up so developers can spot issues that haven’t been thought through in enough detail, or work things out that don’t work in the way we expected them to work.
Then, we need to work with organisations like NHSX and NHS Digital to take the learning from the hackathons and test it again with a small number of selected customers, in what we call first of type testing. Once that has been done, we need to work with the whole NHS so we know where the second and third wave deployments are going to be, and everybody can be ready to go.
What health tech areas are in most urgent need of standardisation in the UK?
We could talk about so many things here. but I would focus on interoperability. As I mentioned above, poor interoperability leads to poor productivity and poor patient experience.
If a patient is being moved from one part of a hospital to another, and data does not move with them electronically, perhaps because different departments are using different systems that don’t "talk to each other," then that data will have to travel another way. It may be written down on a form and re-entered or it may just get scribbled down on a sticky note. Even if it is captured formally, re-entering it takes time that could be put to better use and it runs the risk that information could be mistyped or misunderstood. Having interoperable IT systems go a long-way towards stopping that happening.
Similarly, when one provider hands over the care of a patient to another provider there is a risk of a gap in care if the receiving provider doesn’t have all the information they need. Same when a patient is being cared for by a multi-disciplinary team, and that team can’t share information.
That can happen if a patient is being looked after in the community, perhaps by a GP, community nurse, occupational therapist and social care. There will be many people involved and if they are all using different systems and can’t share data, then nobody will have a complete view of the patient; which has huge implications for safety.
While setting standards for healthcare IT might sound like quite an abstract thing to be doing, it is absolutely vital. It is standards that support the secure and seamless flow of information across the health and social care system and the care that patients receive.
What are the blocks on defining and implementing standards?
Standards are not a new idea in healthcare IT, but there have been some big, technical barriers to implementing them. For example, there is huge endpoint variability across health and social care; by which I mean there are big differences in the capability of systems that need to be “talking” to each other.
Some systems have application programming interfaces or APIs, that allow another system to access their features or data quite easily; but some don’t and then you have to write SQL against their database to get any information out of them.
That’s why making sure that systems and technology platforms come with open APIs is a big focus for NHS IT policy just now. At the same time, if I am honest, the term ‘standards’ has probably been applied too loosely in the past. A lot of the ‘standards’ that have been set have just been guides and vendors and organisations have followed them in slightly different ways. In the days before FHIR, for example, there was a standard for sending messages between IT systems called HL7 v2, but there was a lot of variability in the messages that were sent.
A further challenge is that different localities have different health and care authorities, which means their priorities for interoperability are going to be very different. If you’ve got one health locality that is focussing on frail elderly patients and another that’s focussing on Type 2 Diabetes in the under 50s, they are going to want to exchange different types of information between different health and care staff.
If you have a standard, what is it a standard for? What clinical area? If it’s not relevant it’s not going to be used. That is why INTEROPen has focused on producing standards for the exchange of information in specific clinical settings; and making sure that all the stakeholders are involved in doing that.
How will you drive this forward as vendor co-chair at INTEROPen?
We know that NHSX is on board with the standards-based approach. It has said from the outset that interoperability is one of the biggest issues that it wants to tackle, and its chief executive, Matthew Gould, has said the future of health tech is platforms with open APIs that release data to new services, including apps for patients.
This is right in the wheelhouse of what INTEROPen is about, so, over the next 12 months, I want to make sure we are supporting this agenda. I want to move towards a partnership model for INTEROPen, in which vendors would pay to be members. That would give us an income and enable us to run more independently from the NHS. If that happens, INTEROPen would become more like an organisation called Argonaut in the US, which is a private sector initiative that works on information sharing in line with national policy.
I want to do some technical work so the UK can start working with the latest edition of the HL7 FHIR standards. That matters, because the latest edition, FHIR 4, is normative, which means that any future changes that are made to them will be backwards compatible - or that anything that is built using FHIR now will work even if something alters in the future.
I want to speed up the rate at which we define standards and I want fewer standards to be set top-down and more to be defined by the service. If a local health and care record exemplar sets a standard in one of its clinical priorities, for example, I want it to make sure that it does it in a way that means the whole NHS can benefit.
Really, though, I want to speed up adoption. We are getting better at setting standards and we are seeing more standards come through; so for me, this role is all about adoption.
interoperability, NHS, Hackathon, NHS Digital, Vendor-Driven Standards for Interoperability, vendor, INTEROPen, David Hancock, InterSystems, NHSX, Matt Hancock, Luke Readman, One London, Local health and care record exemplar, LHCRE, Cerner, Orion Health, System C, NHS IT, Fast Healthcare Interoperability Resources, FHIR, APIs David Hancock, the healthcare executive advisor at InterSystems, was recently elected vendor co-chair of INTEROPen, a UK collaboration that promotes open standards for interoperability in the health and care sector.