Process Interoperability in House and Senate Bills

Yesterday I was poking fun at the two dozen mandates for “cultural and linguistic appropriateness” in the House and Senate bills. Vince Kuraitis’ recent posting on interoperability made me want to delve more into this bit of legislative doublespeak. To better understand the legislators' intent and ability to transfer from policy to private sector initiatives, take a look at Vince’s summary of “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. 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"

Perhaps “cultural and linguistically appropriateness” 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's linguistic appropriateness is that very little verbiage is required when listening to music. Perhaps we can design a healthcare system with similar elegance.

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:

1. It is possible to look at the healthcare system as a series of payment transactions (intellectual debt owed to Hal Luft and Metavante)
2. Payment systems require scale
3. Scale requires technology
4. Therefore we can see the healthcare system as a technology system.

While less scary than cancer (except maybe for politicians), designing the intermediate steps of accessing, organizing, sharing, and distributing payment for healthcare 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.

In line with Vince’s 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.”