Author: Kevin Roy

We get this question a lot. Over the past few years, we’ve come up with a few answers. Let’s bring this full circle into 3 simple bullet points:

• A profile captures an interface specification. So profile = spec.
• Some people use the terms profile, spec, and specification interchangeably.
• Why build a profile? So that you save time building an interface and getting it into production.

Why build an HL7 profile?

• The profile or spec also gives you interface documentation you can share with your team or your client.
• The profile allows you to create a series of test scenarios – which in turn gives you a validation report.
• Profiles are the core of the interface lifecycle. And the core to getting interfacing work done faster, with fewer moving parts.
• That’s why profiles are a big part of our software.

The official HL7 International definition

We can also look at the formal definition of profile, introduced by HL7 International in the v2.5 specification. Here is an excerpt from section 2.12:

“An HL7 message profile is an unambiguous specification of one or more standard HL7 messages that have been analyzed for a particular use case. It prescribes a set of precise constraints upon one or more standard HL7 messages.”

In other words, a profile is a description of the data and messages that an interface sends and/or receives. The description covers:

• data format
• data semantics
• message acknowledgment responsibilities

The description must be clear and precise enough so that it can act as a set of requirements.

HL7 profiles make it easy to automate interface management

In the Caristix world, your HL7 profile gives you the ability to automate the production of:

• A gap analysis or mapping table between two systems. It’s much quicker to build the mapping table from profiles than by hand. It’s more accurate, too.
• Site-customized interface documentation. Customizing your documentation means support calls go faster, with much less back and forth.
• A test plan containing a series of validation tasks to automate your testing. This means you catch glitches before they go into production.
• A validation report for your testing. This means you can show that the work’s been done.

You can use the profile before the servers, the network connectivity, and the database configuration are set up.

Interface documentation

HL7.org uses the term “Conformance Statement” to cover conformance requirements. At Caristix, we prefer “Interface Documentation” because it doesn’t refer to a specific template or content. Whatever the term, your documentation should be flexible enough to contain whatever information is relevant to the project (and no more) so the documentation can flex with any integration project.

Gap analysis report

Using an HL7 profile, you’ll be able to map the differences between the profiles of the systems you need to connect. A Gap Analysis Report helps you document each difference or gap, providing a list of items the interface will have to address. These might include the data format, location or another requirement. For more on gap analysis, read the Caristix blog on gap types and how you go about performing a gap analysis.

Test plan and validation report

You can also use the HL7 profile to generate valid (and known invalid) HL7 messages so your newly configured interface can be tested automatically. When needed, the profile can help to test the data mapping defined in an interface engine. The profile can also help to validate that data semantics (the meaning of data) is consistent across the board.

HL7 profiles and automation

You can generate profiles and automatically create gap analyses, documentation, test plans, and validation reports using Caristix Workgroup software. Check out Part 1 of our on-demand webinar here:

http://youtu.be/uOBjjEpKLWY

 The full 16-minute webinar

Like what you see in the intro above? The full webinar is available for viewing on-demand right now. Click this link to get to the full video.

For more information about Workgroup, visit the Workgroup product page.

9 Diagnostic Questions: Interfacing Management Maturity Model

Last week, we introduced a maturity model for interfacing management. We explained how organizations progress through 3 distinct stages: Manual, Message, and  System.

This week, we’ll cover key diagnostic questions. These 9 questions will help you determine which stage you’re in and whether you should consider moving to the next stage.

1. How many sample messages are you using when scoping?

This gives you an idea of which stage you’re at. A handful of messages and you’re likely at the Manual stage of the interface management maturity model. The Message stage is characterized by analysts building out interfaces and interfacing capabilities based on message analysis, usually done by slicing and dicing about 50-100 messages to uncover exceptions to a spec or standard. Is it time to bump up to the next level and enable analysts to run through a larger volume in the 100, 000 to 1,000,000 range?

2. How long to bring an interfacing project to fruition?

Hours, days, weeks, months? Are those multiple iterations and circular processes eating up the time of your developers and analysts? Is your potential revenue sliding down the drain? You gain productivity by moving up the curve. 

3. How is your documentation?

If you’re in the Manual stage, chances are you have little to no documentation such as a list of requirements, a test plan, etc.  But at the Message stage, chances are you have an abundance of documentation, because it mushrooms at this stage: you’ll have requirements, mapping tables, gap analyses, message lists, a unit testing plan, a validation plan, and much more. Not to mention document versioning on each of these. That’s when you’ll want to consider establishing a single document repository that works across all projects. At the System stage, documentation becomes more unified. You’ll use your system-based analysis to have a single source of source of truth – an HL7 profile for instance – and pull out different elements depending on the audience. Your test plans should flow directly from the scoping and profile work.

4. Do you have templates and are they usable?

Templates are part of your documentation process, which really gets going at the Message stage. At the Message level, they tend to multiply. It becomes a headache to manage them. There are often a variety of (sometimes competing) format: Excel. Word. PDF for read-only sharing. Emailing back and forth can become a versioning nightmare. Oftentimes, a manager will look to a shared drive to manage templates and documentation at the Message stage. But this is when it makes sense to move to the System stage and seek out content repositories with multi-user sync capabilities to retain a single source of truth. 

5. Are there unplanned or unexpected delays?

The earlier the stage, the more likely unplanned delays are. But the root causes of delays will vary depending on the stage. At the Manual stage,  delays can crop up because of a lack of requirements-gathering allows potential show-stoppers to slip through. At the Message stage, delays have to do the volume of work. At the System level, delays are few and far between. The key consideration: understand if your project scoping is adequately identifying your timeline and anticipating potential areas of concern so you can fill in needed information before the concerns become critical.

6. Can you estimate costs?

At the Manual stage, it’s hard to. The lack of process at this stage leads to a lack of predictability. What teams often do is log project hours and FTE costs, and attempt to use retrospective data to predict next project. But if the requirements for the next project are different (and unknown), the ability to predict remains low. At the Message stage, the organizations with strong project management capabilities often can estimate costs. Some can even do it per interface type. But the cost curve keeps rising.  At the System stage, they are not only estimating costs accurately, they are also bending the cost curve.

7. How many projects?

As a rule of thumb, the further along the maturity curve, the more projects a team can handle. You should expect the same headcount to be able to handle a greater volume of interfacing projects as the organization goes up the curve.

8. How long does testing take?

At the Manual stage of the interface management maturity model, testing is often ad-hoc. There might not even be testing plan; the interface is simply unit tested until it works. There is no way to really gauge testing effort, although there may be a heroic effort to get it in by a deadline. At the Message stage, a testing plan is in place — probably a rigorous testing plan. So much so that a 10 minute change to the interface code can take 2 weeks to test before it goes into production. At the System stage, your requirements drive testing. You’re also able to automate the testing, so a 10 minute change to the code takes 2 minutes to test through a series of test scripts.

9. Is go-live ever delayed?

At the Manual stage, it’s entirely possible not to even have a target date, or have a target date that will flex. At the Message stage, the team will often scramble to meet a deadline. And at the System stage, thorough scoping with system-based HL7 profiles and gap analyses lead to more accurate, more confident project planning. These teams hit the go-live dates comfortably because they have a handle on the entire interface lifecycle.

 Your Feedback

We’ll be adding to the model over the coming weeks. We’ll address the process deliverables, metrics, and organizational needs and impact. Are there other topics you’d like to see? Let us know in the comments.

Download the HL7 Survival Guide

It’s clear that the needs around interfacing and integration are exploding. To match that need, Caristix is introducing an interfacing management maturity model. If you’re reading this, you know that there is a lot of implementation expertise available from analysts, developers, and consultants. But at the organization level, capabilities vary. Many organizations are seeking benchmarks to see where and how they can grow and adapt to meet their needs. That’s where our model can help.

This interfacing management maturity model is not about the engine or the standards. This model zeroes in on organizational capabilities. We look at an organization’s ability to use interfacing to meet their needs around data exchange, interfacing, and interoperability. The key question: how does a team scalably support their organization’s needs to share or exchange data while controlling costs? As organizations mature, they aim to act quickly to meet strategically driven integration needs, support ongoing operations, and support initiatives such as Meaningful Use.

Below are descriptions of what teams do at each stage. Over the following weeks, we’ll be filling out this model with further points.

Getting Started with Interfacing and Integration

Before you hop on the interfacing management maturity curve, there is a learning curve to get through.

The learning curve with integration is deep and steep. Many smaller vendor organizations who haven’t yet had to deal with interfacing or data exchange start here. CIOs, integration architects, and VPs of R&D have to make calls that are going to decide the future of their organizations or businesses here. They make critical architecture decisions at this stage. The key activity at this stage is learning and training. And the key deliverable is fundamental: integration architecture.

So it pays to get educated. It pays to get training and bring on a consultant with healthcare integration expertise to help with the decision-making.
 

Manual Stage

Once you’re past the Learning Stage, you start to get your feet wet with building interfaces.

Building and coding the first few will seem intuitive. If the team is working with a modern interface engine, it should be.

At this stage, you might see little or need to gather requirements or do any scoping. Some analysts reach out for sample messages from either a system vendor or the hospital team. They will make do with just a dozen or so — one or two of each message type you’ll be needing for the project.

Once the interface is built, the developer connects the systems. And surprise: the interface doesn’t work. Messages aren’t transmitted, they populate unexpected fields. So the analyst and the developer spend time validating and fixing defects. It’s nearly impossible to predict end dates and timelines, and the team (or client) doesn’t have a firm grasp on the effort required to get to a production-grade interface.

Message Stage

Once you’re past the Manual Stage, you’ve learned about the power of scoping and requirements gathering.

At this stage, you’re building out interfaces and interfacing capabilities based on message analysis. To gather interface requirements, the team works at the message level to slice and dice to uncover exceptions to a spec or standard. Sample questions: are there z-segments? Are there exceptionally long field lengths?

Requirements-gathering is based on getting to good-enough – say about 80% of the way.

Unfortunately, 80% isn’t good enough. Requirements gathering during the Message Stage follows an unexpected (and unwelcome) twist on the 80-20 rule, turning it into the 80-20-80 rule.

80-20-80 goes like this:
•    Analysts uncover 80% of interfacing requirements by slicing and dicing at the Message level.
•    Developers get the remaining 20%  during interface coding.
•    But that hidden 20% will account for 80% of actual coding work. 

The project slows down because of rework and a need for extensive validation. Validating the interface is  characterized by an unpredictable number of versions and iterations –because the team can’t realistically predict effort or project duration. If time isn’t a factor and low-volume interfacing is acceptable, the team can stay in the Message Stage indefinitely. Likewise, if you’re maintaining stable interfaces and not building new ones or updating source and destination systems, remaining at the Message Stage may work for the organization.

The System Stage

After the Message Stage comes the System Stage. This is a conceptual leap.

For most teams, it’s a mental-model leap to go from messages and message validation to system analysis and working directly with specs or profiles.  Many analysts and their managers are used to thinking in terms of message analysis.

But the ones who are leaping forward to profiles are seeing gains in productivity.

For instance, some profile builders (such as the one we build in Workgroup) enable analysts to run through a large volume of messages  — in the 100,000 to 1,000,000 range. This enables analysts to capture requirements more completely and cover more use cases contained in the data. As the interface is developed, it needs much less rework what you find in the Message Stage. As a result, testing and validation is smoother. The bottlenecks encountered in message-based validation disappear in the Profile Stage. Projects are more predictable, with fewer iterations and less project effort. Project managers can confidently hit target dates with allocated resources.

 

Your Feedback

We’ll be adding to the model over the coming weeks. We’ll address the process deliverables, metrics, and organizational needs and impact. Are there other topics you’d like to see? Let us know in the comments.

Download the HL7 Survival Guide