Anecdote-Driven Systems Engineering and Complaint-Based Interoperability Design Won’t Solve Health IT Woes
As I’ve been preparing to chair the HealthIMPACT conference in Houston next Thursday I’ve been having some terrific conversations with big companies like Cisco, some of our publishing partners, and smaller vendors entering the health IT space for the first time.
As I’ve been preparing to chair the HealthIMPACT conference in Houston next Thursday I’ve been having some terrific conversations with big companies like Cisco, some of our publishing partners, and smaller vendors entering the health IT space for the first time. One great question I was asked during a discussion yesterday by a tech publisher was, “So what’s it going to take to achieve real interoperability in healthcare and how long will it take?” To that my answer was:
- We need to move from anecdote-driven systems engineering to evidence-driven systems engineering and
- We need to move from complaint-based interoperability design to evidence- and workflow-driven interoperability design
Although the discussion was over an audio telecon I could almost see the eyebrows being raised by the editors on the other side of the phone and could tell they were thinking I might be a little weird. I proceeded to explain that systems engineering and interoperability design in healthcare IT suffer from three major flaws:
- The myth that there is a lack of interoperability
- The myth that we don’t have enough standards
- The assumption that health IT leadership has provided staff with the tools they need to do proper systems engineering and interoperbility design
The first myth is perpetuated usually through anecdote after anecdote by anyone who has ever had to fill out their name on two separate paper forms in a waiting room. The fact that you have to fill out forms (the anecdote) doesn’t mean that there isn’t interoperability — it just means that the cost of filling out a form is probably lower than the cost of integrating two systems. Healthcare systems are already interoperable in areas where they have to be — namely, where required by statue, regulation, or law. And, systems are interoperable where there’s a reimbursement (payment) reason to have it or in many cases if there’s a patient safety reason to have it (e.g. for Pharmacy or Lab Orders). Unfortunately, convenience and preference (e.g. for patients to not have to fill out forms twice) doesn’t factor into designs much right now because we have bigger fish to fry. If a non-integrated multi-system workflow isn’t demonstrably unsafe for patients, isn’t costing a lot of money that can be easily counted, or isn’t required by a law that will force leadership’s hands then complaining about lack of interoperability won’t make it so. We need to come up with crisp and clear evidence-driven workflow reasons, patient safety reasons, cost savings reasons, or revenue generating reasons for interoperability if we want improvement.
The second myth of lack of standards is perpetuated by folks who are new to the industry, looking for excuses (vendors do this), or are otherwise clueless (some of our health IT leaders are guilty of this). There are more than enough standards available to solve most of our interoperability woes. If we do workflow-based evidence-driven analysis of systems we come to see that most interoperability can be achieved quickly and without fanfare using existing MU-compliant standards. We have HL7, we have CCDA, ICD, CPT, LOINC, and many other format, transport, and related standards available. I’m not talking about flawless, pain free, error-free, interoperability across systems — I’m talking about “good enough” interoperability across systems where workflow reasons, patient safety reasons, cost savings reasons, or revenue generating reasons are clearly identifiable.
The third problem, lack of proper leadership, is probably the most difficult to tackle but perhaps the most important one. I’ve been as guilty of this as anyone else — we have many environments where we’re demanding interoperability and not giving the time, resources, budget, or tools to our staff that will allow them to prioritize and execute on our interoperability requirements. Leadership means understanding the real problem (workflow-driven, not anecdotal), making decisions, and then providing your staff with everything they need to do their jobs.
If we want to make progress in healthcare interoperability we need to train the next generation of leaders that proper systems engineering approaches are required, better interoperability is possible because some of it already exists now, and that you shouldnt wait for standards to get started on anything that will benefit patients and caregivers. Health IT integration woes can be overcome if we get beyond anecdotes and complaining and start doing something about it.
(interoperability in healthcare / shutterstock)
