Geek Wisdom: “Interoperability” Must Include Process Collaboration

GeekI know — you’re thinking that using “geek” and “wisdom” in the same sentence is an oxymoron. Bear with me — I’m trying to make a really important point in today’s posting.

Interoperability has multiple dimensions — and I’d bet that most of us have never thought of interoperabilty as involving “process” — people working together and collaborating; I know I hadn’t.

The Interoperability Work Group of HL7’s Electronic Health Record (EHR) Technical Committee was formed in April 2005 to attempt to define the concept of interoperability. The group examined 100+ definitions of interoperabilty. Their work is summarized in their report: Coming to Terms: Scoping Interoperability for Health Care, February 2007.

3 Types of Interoperability: Technical, Semantic, Process

Through work group consensus, three principal types of interoperability were identified: technical interoperability, semantic interoperability, and process interoperability. Here’s an overview:

Type 1: Technical Interoperability

The most basic, hardware-based form of interoperability. IEEE-90 defines interoperability as, “The ability of two different systems to exchange data so that it is useful”

The focus of technical interoperability is on the conveyance of data, not on its meaning. Were it not for the fact that computers tend to use written language, this would be similar to the level of interoperability provided by voice communications, e.g., via a telephone.

Type 2: Semantic Interoperability

the ability of information shared by systems to be understood… so that non-numeric data can be processed by the receiving system.

HL7 also defined a quality that is necessary for optimal semantic interoperability to exist. The quality-based rationale of the HL7 semantic interoperability messaging standard asserts that health information systems will communicate information in a form that will be understood in exactly the same way by both sender and recipient.

Type 3: Process Interoperability

Process interoperability is an emerging concept that has been identified as a requirement for successful system implementation into actual work settings. It was identified during the project by its inclusion in academic papers, mainly from Europe, and by its being highlighted by an Institute of Medicine (IOM) report issued in July 2005 which identified this social or workflow engineering as key to improving safety and quality in health care settings, and for improving benefits realization.8 It deals primarily with methods for the optimal integration of computer systems into actual work settings and includes the following:

  • Explicit user role specification
  • Useful, friendly, and efficient human-machine interface
  • Data presentation/flow supports work setting
  • Engineered work design
  • Explicit user role specification
  • Proven effectiveness in actual use

Here’s another helpful angle on the three types of interoperabilty:

Technical interoperability neutralizes the effects of distance.

Semantic interoperability communicates meaning.

Process interoperability coordinates work processes.

Together, these three types of interoperability are all required to the consistent and timely achievement of what has come to be called “Best Practice.”

More About Process Interoperability

The authors provide more detailed explanations that are useful in better understanding process interoperability:

The third type of interoperability which emerged from the analysis is “process/social” interoperability. Although it was cited infrequently, it was remarkable that it was cited by a number of cutting-edge organizations, including caBIG and the Federal CIO Council, Canada’s CanCore and the CEN (Committee European Normalization) community.

In the United States, this type of interoperability has emerged from the management engineering field where it beenreferred to as “workflow management” or “systems engineering,” both established terms having to do with the design of and implementation of human work processes, which increasingly include interaction with computer systems.

There is certainly no question that process interoperability places requirements and constraints on how information is provided for use in real-life settings, as a commonly cited example will show. The continuous improvement movement, popular in health care in the early 1990s, based on the work of W. Edwards Deming, Joseph M. Juran, and others is primarily concerned with process interoperability as the term is used in this paper.

Implications

This report changed my thinking about interoperability.  Prior to reading it, I thought of “interoperability” as encompassing only technical and semantic components.

For me the description of the third element of process interoperabilty was a BFO (blinding flash of the obvious). Once you see it, it’s evident and clear.

Technical and semantic interoperabilty are necessary to advance health care reform, but not sufficient.

Over time, the definition of “meaningful use” must encompass concepts of process, workflow and collaboration among members of the patient’s care team.

In many real life patient care contexts, process interoperabilty should optimize (not maximize) data.  The authors provide an example of an emergency room physician treating a patient; the physician needs actionable data presented in a highly usable way — the data must be put into context, e.g., time (past vs. now vs. future) and presentation (filtering, summarization, alerts). Access and quantity of data are only parts of the equation. 

Optimizing care collaboration will be advanced by achieving technical and semantic interoperabilty…but getting started on improving process interoperabilty should not be dependent on achieving technical and semantic interoperability.

After the geeks’ work is done and technical and semantic interoperabilty is achieved, there is still much to do in achieving process interoperability.  We have to collaborate.

 

 

15 thoughts on “Geek Wisdom: “Interoperability” Must Include Process Collaboration

  1. Pingback: Zen Benefiel
  2. Pingback: Leon Moniot
  3. Pingback: Dennis E. Hamilton
  4. Pingback: Medicity
  5. Pingback: Chad Osgood
  6. Bravo Vince on “Process Interoperability.” You hit the Jack Pot. We have been researched & developed EHR Platform for coordinated care in Phoenix, Arizona in the last three years. You hit hard on our last part, Implementation with “Process Interoperability.” Please note that “Process Interoperability” requires specific customization from the start (R&D x 3 years) to fit into a particular business model, not the other way around. For example, coordinated care between hospitals, skill nursing facilities and telemedicine physicians using an integrated EHR. Stop by Arizona by the end of 2009 and we will show you Vince :-). Can’t wait until we finish our pilot. Linh

  7. Pingback: Amy Berman
  8. Pingback: Amy Berman
  9. Vince, I applaud your bumping this material to the surface. Yesterday I was poking fun at the two dozen mandates for “cultural and linguistic appropriateness” in the House and Senate bills. Perhaps that was our legislators’ best attempt at mandating “process interoperability”. If they minded their own mandate (i.e., wanted people to understand and act upon it) they might just say: we need to make the healthcare system like an iPod.

    The iPod metaphor is a cliché, but clichés exist for a reason. This one regresses laterally towards absurdity when we think that Steve Jobs was looking at Porsches during his BFO, so let me get into the analysis to bridge the gap to healthcare.

    If we look at the healthcare system as a series of transactions (intellectual debt owed to Metavante), I am reminded of the adage in the payments business that the payments business requires scale, and therefore it is a technology business. While less scary than cancer (except maybe for politicians), designing the intermediate steps of accessing, organizing, sharing, and distributing payment is not trivial. Successfully piloting innovative payment strategies for physicians and care providers that foster disease prevention and care coordination will require active participation from many players in the private sector. The threat, and the call to action, is that they won’t use it if they don’t like it. That is the “process interoperability” requirement in a nutshell.

    Just to reinforce your comment: processing power and cheap telecommunications make it easy for technology implementers to provide lots of data and lots of configurability; winners focus on culling the most useful information from data and making configuration choices on the consumer’s behalf. Likewise, important tradeoffs are to be made between interoperability and security.

    Given that the private sector runs much of the healthcare payments infrastructure regardless of who foots the bill, I wish that legislation was more “process interoperable” with the mindset of those who run the back office pipes. It does give me hope when I see process interoperability as the mission statement of the micro-data crunchers at firms like Acumen LLC. They philosophize with a sledgehammer: “To us, the most important aspect of such systems is not the database, but rather the interfaces we design that make data meaningful to our clients.” http://www.acumen-llc.com/info_resources.html.

  10. Pingback: Vince Kuraitis
  11. Pingback: Leonard Kish
  12. Pingback: Vince Kuraitis
  13. Pingback: CLOUDHealth
  14. Pingback: Zu?r?i?s??a??

Comments are closed.