The premise of Marshall Goldsmith’s leadership book, What Got You Here Won’t Get You There, is simple: the habits and work methods that get you in the game won’t get you to up your game.
The same shift is happening in healthcare integration.
Where We Came From
- 5 years ago, a vendor analyst could fire up an HL7 message viewer tool or even Notepad++ and start reading through sample messages one by one to pick out unexpected PID.2 values over the course of an afternoon. Today, the integration team manager isn’t going meet target go-live dates unless all unexpected field values –not just PID.2— are handled inside a week.
- 5 years ago, an analyst could start working with an Excel file to slowly pull together a mapping table over numerous conversations about code sets with clinical staff. Today, the interface team lead needs that mapping table — along with 120 others– yesterday.
- 5 years ago, a developer could afford to spend 20 hours per interface on recoding when converting from a legacy interface engine to a brand-new interface engine. Today, the director of application integration would never meet Meaningful Use deadlines on that timeline.
- 5 years ago, a consultant could sit through 4-hour crosswalk meetings to check for transformations. Today, there is no way an integration practice leader can bid competitively if their analysts spend upwards of 30 hours on interface scoping.
Where Are We Now with Healthcare Integration?
Things have changed because we’re moving to an era of interconnected systems. CIOs are converting from legacy interface engines to newer technology. HIEs are maturing. Physician practice acquisitions and hospital system mergers are requiring CIOs to rethink integration. And the cherry on the sundae is Meaningful Use.
Integration work is increasing: there are more connected systems, more interfaces, more data types to exchange, and more data to exchange than ever. But the resources we have available are not growing at the same pace. Insert a stat about lack of availability of resources.
The bottom line is that the pace has picked up in interfacing, and there’s no going back.
Plotting the Course Forward
To be successful, leaders and CIOs must find a way to match the rapid change with the way data exchange needs are growing. Leaders must change the way their teams approach interfacing.
There is fundamentally only one way to do this:
- Stop building interfaces from messages
- Start building them from profiles.
Here’s the difference between the interface-coding information embedded in a single sample message versus a profile built from thousands of messages:
| One message | One profile |
| Single message | Thousands of messages |
| 1 message type | Unlimited message types |
| 10-20 segments | All segments organized by message type |
| Under 100 fields | All fields |
| Unknown repeatability | Full repeatability |
| Unknown optionality | Full optionallity |
| Data values present but no data types | All data values, data types, tables |
| Partial information, enough to start trial-and-error work | Full specification for developing interface |
Profiles Speed Up Integration Work
Years ago, it was perfectly normal to work with basic vendor specs and a handful of sample messages. It was easy to download any number of tools — both paid and open-source– to slice and dice messages, then transfer your findings into a Word or Excel template.
But working at the message level no longer works.
The only way to cope with today’s needs is to move up – move up to profiles.
Profiles Reflect Systems
Profiles give analysts and developers a complete list of messages, segments, and fields needed to build an interface. They also include attributes such as optionality and repeatability. Profiles give you system-based information, not message-based information. So having a profile can drive speed and quality throughout the entire interfacing lifecycle:
- Profiles drive gap analysis (capturing differences between two systems), which in turn drive mapping tables and transformations.
- Profiles also drive automated testing. Once you have a profile in machine-readable form, you can use to validate the interface.
- Profiles drive maintenance and troubleshooting. Once you’ve got a profile, it’s easy to consult when the the interface needs maintenance or troubleshooting.
Getting There With Profiles
We got here with messages. We’ll get there – greater interfacing volume at a dramatically lower cost – with profiles.
Your Feedback
What do you think of the profile approach? Does your organization work with profiles? Let us know in the comments.