Why healthcare interoperability standards arent perfect

Oct 2, 2013

Referring to HL7 and other SDO’s, Tim Cook writes:

Such consensus groups gather political power from their expertise on healthcare IT standards, but they are seldom aware of all the problems real software companies dealing with real customers are facing. After many months or years, and hundreds or millions of dollars or euros spent, this little group of experts define a data model, a message or a schema, and they want to enforce it on everybody. Your customer gets frustrated, because that seldom matches the way clinical practictioners want their data collected, because the conventional top-down standards are much more concerned about the information needs of central governments or large medical hardware corporations than with the routine clinical documentation, which is the essence of medical decision making that really impacts on patient outcomes.

This is both true and false. I can’t decide which it’s more of. I’ll confine my comments to HL7, which is where I can speak with some knowledge.

Who goes to HL7? A mix of people. You can check Dave Shaver’s run-down, or just use my simplified list:

  • Health software developers
  • Academics
  • Government policy representatives
  • Integration contractors/consultants

HL7 was traditionally vendor driven: a focus on “problems real software companies face”. That slipped, when the people trying to solve the problems got too ambitious - but it’s coming back. FHIR is both an outcome and an input to this - it reflects the fact that HL7 is focusing more on practical problems, and it drives a more practical approach. There is a need to reflect policy, but policy input can only be limited by the fact that policies differ so wildly.

With regard to the fact that this seldom matches the way practitioners want their data collected, my belief is that the fundamental underlying problem is that there’s so little agreement amongst the practitioners about how they want their data collected. This makes the standards process easily fall hostage to some particular small clique of practitioners who think it should be done in one particular way. I call this clinical activism, and I’ve seen it again and again. The government processes are particularly prone to this - they have to work with clinicians who are prepared to work with them, and there’s an inherent self-selection process at work there.

However it is true that the outcomes of the standards will reflect the prejudices of those who bank-roll it. And for bigger enterprises, it’s a smaller fraction of their budget. So they can afford it more easily. And the standards do unduly reflect their goals. But hang on, aren’t their goals to sell more software, to make things better? In as much as the standards don’t solve the problems that Tim wants solved, the standards don’t meet the goals of the “needs of central governments or large medical hardware corporations”.

So, how to fix this? I’d like to see

  • More clinical record keeping standards (not IT ones)
  • More engagement with the standards process by professional associations reflecting people who actually work at the coalface, and can’t easily afford to participate

But, of course, engagement with standards takes years to bear fruit, and actually involves compromise. It’s really hard to find people who are willing to engage for years only to not get what they want.

As a general comment on the the roll-your-own scheme in the reference above: it sounds like Tim is just rerunning the whole RIM design approach again to me. I can’t really tell the difference between his goals and methodology, and that of the RIM or even openEHR. There’ll be some differences, from not falling into some of the RIM pitfalls (i.e. USAM), but openEHR already avoided those. What I’ve learnt, though, is that interoperable meaning is hard - you won’t get it without one of two things: expensive data conversion points everywhere, or community driven consensus.

Community driven consensus is the expensive bit, and always will be.