I had a wry smile on my face when I read this article today: Data Integration Continues to Bedevil Healthcare Industry. I felt I knew where the article was coming from and I only had to get to the third paragraph to see words that made me smile: “We still have so much work to do as an ecosystem to have data that is interoperable, not just systems that are interoperable,” said Karen DeSalvo, MD, National Coordinator for Health IT. This perfectly captures a gnarly topic that so many folks relate to technical issues and technology, since it relates to ‘data integration’ or ‘application integration’. This is a technology issue, right? Wrong!
The fact are these – and this condition spans industries and are not unique to healthcare: you can integrate applications and systems so that they appear to work together but unless the semantics of the data being shared are consistent or aligned/reconciled to a degree, the business process that needs the shared data won’t work as planned. Or, in the parlance of the pure, physical system integrity has little to do with process integrity. I had an inquiry from a client in consumer goods asking talk about the exact same issue today. And this issue is going to be spotted soon in all those lovely IoT pilots and POCs being launched: so many vendors are focused on network integrity they are not even thinking, yet, about data and semantic integrity in or across or between those networks. Oh boy.
The Information Management article continues with more from Karen DeSalvo: “We want to move to a place where we’re working off of the same language so that there’s not the added work and expense and sometimes frustration of not having federally recognized national standards, but also creating opportunities to really advance new kinds of standards that can advance the field.” This is just so classic. So many organizations only budget for the “integration” since that is what the vendors sold them. Then when it comes to fixing the stuff later, there is no money or energy left. So we end up baking in and even budgeting for mediocrity.
So this looks like a question of standards, specifically data and semantic standards, and has little to do with the integration protocols of connecting two systems. But standards? Ouch. Not exactly exciting stuff, is it. Standard does not quite turn the head. And so this is another misunderstanding: data (or semantic) standards do not have to universally adopted wall to wall for every piece of data shared by everyone. To get the most value from the shared data you only have to enforce data standards (same data) or process standards for how that the most important data is governed (related data and use). In other words, you first need to understand process interoperability and outcome before you determine the extent of data interoperability- and in both cases, the link to technology interoperability is negligible at best. You don’t even need data integration people in the room to get to agreement.
I am not a healthcare analyst nor do I focus on any one industry, but I can easily recommend a general course of action:
- Identify the primary (or worse case, range of) set of business outcomes or analytics the healthcare community seeks to improve. Don’t ask the IT folks – ask the business folks
- Develop a pace layered information governance framework:
- Determine the least amount, and most important, data that is needed to be consistent between stakeholders to share in a common view of the outcome, or the application or workflow needed to support that/those outcome(s)
- Determine additional data needed to support the outcome(s) but that warrants regional governance.
- Determine additional data needed to support the outcome(s) that only needs local governance
- Establish information governance (e.g. policy setting) and information stewardship (i.e. policy enforcement) in the healthcare industry, specifically in the stakeholder organizations, starting only with the most important data. Leave the other data until a later phase.
- To give 3) above a chance, establish shared performance and reward indicators for these collaborating stakeholders.
- Ask IT to change the data integration tooling to support the needed data flows – spanning source and recipient systems and also any centrally governed data (phase 1). Additional roll out will be needed for regional (phase 2), and local information governance and stewardship (phase 3+)
- Report status of performance metrics of shared data, and its impact/use on the outcomes targeted in 1). Tune process as needed and expand to subsequent phases.
Note how little of this plan relates to technology. There is though, to be true, a need for some technology that does not yet exist widely in the market. IT cannot govern data; IT cannot steward data. Only business users can do this – and they need tools that normal people can use. That’s a tall order if you look at the range of tools out there today in support of “information governance”. So there is a need for some innovation – and thankfully some vendors are on the ball here too.
Anyway, I loved the article and I loved the conclusion. I just wish enough folks knew how to get the technology conversation off the table and start talking business.
Here are some previous blogs I posted on this specific topic:
- July 2015: Electronic Health Record Interoperability – Why is it so hard?
- February 15 2015: Health IT Roadmap for Industry Interoperability – Where is the data quality?
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.