Healthcare Integration: What Got You Here Won’t Get You There

Healthcare-integration-what-got-you-here-won't-get-you-thereThe 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.


2 thoughts on “Healthcare Integration: What Got You Here Won’t Get You There

  1. Profiles developed by who? Shared by who? Unless profile use is adopted in the industry I don’t see how this will work

  2. Virginia, thanks for responding to our blog post.

    Profiles or specifications as they are commonly named, are the basis on any integration project. A profile (or spec) is specific to a project and is used by the project team. Any communication of the profile would then be handled within the team and with their primary client(s) as needed in scoping, validation and testing. Commonly, profiles (or specs) are built manually in Word and Excel by painstakingly analyzing multiple messages; some also use Messaging Workbench, and of course, our customers automate this process using Caristix Conformance and Workgroup.

    Your question concerning whether profile use will be adopted by the industry is an interesting challenge. We’re seeing increasing adoption, since automated profile building, through technology developed by Caristix and other vendors in the market, represents a more integrative approach than simply analyzing messages. We’re hearing that profiles help with globally managing project data needs and matching the trends toward increased standardization. In addition, they match the business needs of streamlined time and resource management.

Leave a Reply

Your email address will not be published. Required fields are marked *