HL7® Specifications: The Basics

What is an HL7® specification?

HL7 specification standard
HL7® specification standards

 No matter how many interfaces you are integrating, a critical step is the definition of your HL7® interface specifications.

A formal definition from HL7 International in the v2.5 standard definition states:

“An HL7® message profile (or HL7® specification) 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, HL7® specifications or a profile describe the data and messages that an interface sends and/or receives. The description must be clear and precise enough so that it can act as a set of requirements. Each integration project needs a spec for each inbound and outbound interface. Without the spec, you’ll waste lots of time trying to figure out what’s going on through trial and error.

HL7 specification syste Basically, an HL7® specification describes:

  • Trigger events supported
  • Data format (segments, fields and component descriptions)
  • Data semantics
  • Message acknowledgment responsibilities

With the spec, you’ll be able to:

  • Get analyst, developers, internal customers, vendors, and consultant all on the same page.
  • Identify risks before interface development.
  • Eliminate time lost spent determining requirements, testing, and fixing issues during go-live.
  • Develop the interface documentation you can share with your team and your client.
  • Easily generate your gap analysis report and test and validation report.

For more information on HL7® specifications, check out Chapter 6 of our Survival Guide.

HL7® Specification Template

To get you started, we’ve developed the HL7® Specification Template. You’ll find both Excel and Word documents included in the zip file. Download it here.

In the Caristix world, you can generate gap analyses, documentation, test plans and validation reports using Caristix Workgroup and cut interface development time – and cut waste from the entire interface lifecycle.  Learn more via the Caristix Workgroup on-demand demo.

Interface lifecycle management: do more with less

Caristix white paper lifecycle managment
Caristix White Paper: HL7 Integration: From Trial and Error to Predictable Project Outcomes and Margins

If you’re responsible for interfacing within a hospital system, a consulting organization, or an HIE, you know one thing: you need to do more with less. With EHR implementations slowing down, the big HIT implementation budgets are drying up. But so much of the promise and value of those systems is tied to interoperability and data exchange, and you’re still accountable for delivering those capabilities. So what do you do?

In this situation, you want to consider a lifecycle approach to your interoperability programs. Interface lifecycle management removes waste from the work by getting rid of ad hoc processes. You’ll be able to do more with less, and as a result, sustain your operations and meet demands for interoperability more easily.

The major phases and potential pitfalls

We’ve outlined the major phases of the interfacing lifecycle below, along with the some of the pitfalls you might encounter.

 Scoping

In the scoping stage, the first step is to understand what systems are in place, what data is available, when it is available, and in what format. Management may underestimate the amount of effort for this phase, since people who not hands-on assume the HL7 standard helps streamline this process. But the standard is such a loose framework that, used on its own, it leads to a lot of trial and error in the next phases. The lifecycle really starts with strong requirements-gathering practices right here in the scoping phase.

Configuration

The next step is to configure or code the interface, or build a bridge that connects two systems. In most cases, developers use an interface engine to handle the mapping and transformation. Even with the use of an interface engine, your team will need good requirements from the scoping phase in order to eliminate waste during this phase.

Validation

In the validation phase, developers (or quality testers) test the interface before it goes into production. If the underlying requirements from the scoping phase aren’t strong, the configuration and subsequent validation will be subject to multiple trial and error cycles – wasted time and effort. What’s worse, you may not discover gaps until the system is in production, affecting data quality, user adoption, and potentially quality of care. From a project management point of view, you also can’t predict the project end-date because it’s impossible to anticipate the defects testers will uncover.

After Go Live, support and maintenance

Is the data flowing as expected? Are new bugs emerging? Use the work your team did in the scoping, configuration, and validation phases to manage and maintain the interface. If you’ve got multiple interfaces, make sure the work from previous phases is readily available to consult in a shared repository. Those requirements from the scoping phase are especially important.

Upgrade decision

Whenever your leadership decides to proceed with a version upgrade of a source or destination system, you’ll need to evaluate the impact on the interfaces that connect those systems. In most cases, an upgrade will mean you start the interface lifecycle all over again. Without the artifacts – requirements, tests, queries – from the previous cycle, you’ll be starting from scratch.

Download white paper on interface lifecycle management

Learn more about interface lifecycle management in this whitepaper from Caristix: HL7 Integration: From Trial and Error to Predictable Project Outcomes and Margins. You’ll get a deep dive on the phases we touched on above, and you’ll come away with a better understanding of the collaboration and operational benefits of adopting interface lifecycle management.

What are HL7 requirements?

Requirements Thinkinginterfacing-project-assets

What are HL7 requirements? First, in the world of software engineering, requirements refer to documented needs that an application or system must perform. Requirements are critical for both designing the software and verifying that it works.
 
In the world of HL7 interfacing, requirements thinking is the right way to build an interface. The problem is, traditional HL7 requirements-gathering leaves serious gaps.

Traditional HL7 Requirements Approach

  • Key technique: manual analysis and pipe counting in message samples
  • Small data samples
  • Incomplete and/or outdated documentation

The result is a series of low-fidelity, low-trust requirements that raise more questions than they can answer easily:

“What exactly is connected here?  Which messages, and which data structures?”

“What is optional in which workflow?”

“Which data sets are applicable?”

“Is the meaning the same in both systems?”

And this means analysts and developers end up with a best-guess interface and fix issues as they pop up. They enter a trial and error cycle.

Traditional Trial and Error Pain

The pain around trial and error extends beyond analysts and developers. Slowdowns impact everyone who is dependent on smooth information exchange within the healthcare organization. Without good requirements, it becomes impossible to accurately forecast integration project effort, timelines, and (worst of all), costs. Similarly, you can’t assess risk accurately. Go-lives become a nightmare, since that interface will continue to be tweaked once the new systems are in production.

Recommendation: Better HL7 Requirements

When we work with our clients and their integration teams, we recommend they generate 3 key requirements documents at the start of a project:

System specifications

Create a system specification (for each system in the interface), or what we call a profile. This will give you a run-down of the data and messages that an interface sends and/or receives. One way to create a profile or spec from your system data is reverse-engineering. Read about reverse-engineering and why you might want to consider this technology for your next integration project.

Gap analysis

Also create a gap analysis – a list of all the differences between the two systems you’ll be interfacing. In essence, a good gap analysis will give a series of mapping tables – which data elements need to be mapped, transformed, or somehow communicated or manipulated from one system to the other. Read more about gap analysis.

Workflows

Finally, you’ll want to document your clinical workflows. Your interface will need to support your clinical and administrative processes, which are mirrored by how the messages flow. Does an ED admit work differently than a med-surg admit? Make sure you capture that; the interface must handle both workflows. If a patient is transferred, does the LIS need to know? If so, capture that. Workflows impact your interface configuration – and they affect your test plan. Read more about workflows and why you need to map them.

How Caristix Software Handles HL7 Requirements

When you create requirements documents, you need a way to track them and update them. Check out the Caristix Workgroup on-demand demo to see how Caristix technology solves this problem.

What is Gap Analysis in HL7 Interfacing?

what-is-gap-analysis-HL7-interfacingFirst, what’s the problem?

One of the problems we hear about from HL7 team leads and their management is that interfaces take a long time to configure. The reasons why boil down to missing information. Here’s what they typically hear back from the team members:

“The fields need fine-tuning.”

“We don’t know up-front which message types will need the most work.”

“That field mapping was a bear because we couldn’t get a complete code set from the source and destination systems.”

“These code sets have been customized. Each code set changes with the message type.”

Impact: money and time

Integration team leads worry when they hear these statements because these bottlenecks signal delays and project slippage. Problems with configuration prolong testing cycles. They push out go-live – or push burnt-out team members to work even longer hours. It’s demoralizing for the analyst and developer, and frustrating for clinical testers. And the bottom line is: it’s a huge business concern for leadership, who see money and time going down the drain with delays.

There is a way out. It’s called gap analysis.

Just what is gap analysis? Gap analysis is about getting the mapping information upfront. In other words, you compare specs for both the source and destination systems upfront, before a single line of interface code is written and or dragged-and-dropped in the engine.

Your gap analysis must answer the following basic questions:

  1. Do the source and destination systems handle the same message types? If not, what are the differences?
  2. Are there mandatory elements in one system that are optional in the other? Note them down.
  3. Do both systems use the same code sets? With the same values? If not, which values need to be mapped? Do this for every field that needs to be mapped.
  4. Do both systems require the same maximum length for all fields? Note the exceptions.
  5. Does either system use z-segments? How will you handle mapping?

 

Document your gap analysis

When you consider the number of message types, segments, and fields that are typically needed in an interface, you won’t want to leave gathering this knowledge to a simple scratch pad. You need a template or system to get everything right and hand off this knowledge to a developer.

Some analysts develop Excel templates to manage all this information. We’ve seen templates with 12 to 15 tabs to track. Excel templates also need to be filled out manually. An analyst spends days comparing two product specs side by side and checking sample messages. Then recording their findings across the Excel tabs.

The other option is to look for interface lifecycle management software that will automate the gap analysis process for you. You want software that will compare two system specs side by and side and flag only the differences that will impact the interface.

And the real reason to automate gap analysis: you’ll save even more time. And time = money.

Further resources

Check out Caristix Workgroup for a full interface lifecycle management suite (16-minute on-demand demo available).

Image credit: https://flic.kr/p/9BsXFM

 

HIEs, Business Models, and Interfacing

Healthcare Information Exchange Types

There are three basic types of healthcare information exchanges (HIEs): some cover a geographic region (for instance, NCHIE in North Carolina), others a community; and yet others that cover a single hospital system (which in turn may be spread out geographically – for instance, Catholic Health Initiatives).

HIE Business Models: Grants vs. Revenue Generation

While some regional and community HIEs got their start via government grants, many of those grants are coming to their end. Even though they might remain as non-profits, HIEs are increasingly moving to revenue-generating business models in order to sustain their operations.

That means HIEs need to be focused on driving down costs for the services they are mandated to provide. Given that many have already invested in infrastructure, their on-going capital budgets have likely stabilized or decreased. Instead they must focus on containing operating expenses. So the key drivers for them are going to be cost-effective delivery, lean production, and efficient maintenance. On the revenue side, they’ve got to ensure their benefits provide sufficient ROI to partner organizations such as hospital systems and physician practices.

The Heart of the Matter at HIEs: Interfacing

A big part of what HIEs do is interfacing – HL7 pure and simple. They need to manage information flow with these systems and more:

  • Commercial labs, hospital labs
  • Immunization registries
  • Cancer registries
  • Other public health reporting and disease registries at both state and federal levels

HIEs also support continuity of care between acute care providers (hospitals) and physicians. With Meaningful Use, CCD is the method of choice. Again, with CCD, many of the issues we run into with conventional HL7 v2 interfacing apply.

In a nutshell, a big part of HIE operations is interfacing. Move the needle with interfacing, and you move the needle on the expense/cost side of their business models and on-going fiscal viability.

The best way to move the needle is to reduce cycle time on the most time consuming part of the interface lifecycle: testing tasks.

HIEs Can Move the Needle

Just how do you get started? Three ways.

1. Get the right requirements up front.

Ensure you have vendor specs, and specs for each site/practice/system. If these stakeholders don’t have specs (or what we call profiles), get sample messages and get analysts to create the specs themselves. Then do the gap analysis between systems, so capture requirements up front. This lets interface developers create a more accurate interface upfront. With high-quality requirements, come high-quality interfaces – and fewer fixes during testing.

2. Automate your testing.

Once you have the interface configured in the test instance of your engine, start testing.  And automate the testing so changes can be implemented faster. With one organization we worked with, before they automated their testing, they spent 2 weeks to test a 15-minute change in the engine. After automation, they spent less than 1 hour. Clear the testing bottleneck.

3. Keep your artifacts for the next go round.

Document it all. You’ll need it as you maintain the interface, and when the source or destination systems are upgraded.

Further Resources

Check out this presentation we gave at the Interconnected Health conference in 2012. It’ll explain why getting the requirements right up front cascades through and drives more cost-effective interfacing.

HL7 Interface Lifecycle Management at Interconnected Health 2012 from Caristix
 

Check out Caristix Workgroup for a full interface lifecycle management suite (16-minute on-demand demo available).

What is an HL7 Profile?

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.

HL7 profiles automate the production of 4 key interfacing artifacts

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.

HL7 Test Automation: Where’s the Low-Hanging Fruit?

HL7 Test Automation: Low Hanging FruitTesting and validation are important tasks, as we explained in the Interoperability Tip Series and the HL7 Survival Guide.

Shouldn’t interfacing be easy by now?

Testing is what takes the longest when you’re building an interface. So when you hear about interface engines that allow you to get an interface into production in a couple of hours, that’s absolutely true. Coding is quick with modern interface engines. But bear in mind that coding time seldom includes testing. We’ve worked with organizations that can code a change in 15 minutes, but need 2 weeks to actually implement — due to testing.

Given the need to test, test automation can save you a lot of time.

Why Automate Testing?

Simple: the benefits are clear. Organizations that adopt test automation spend less time on project lifecycles. They meet tighter deadlines with less project effort. They uncover more bugs, before end-users are impacted. The code is easier to maintain. In a nutshell, when it comes to software testing, it’s all about “find early, fix cheaply.”. Interfaces are no different; after all, they are simply forms of code.

Why Automate HL7 Testing? 6 Key Reasons

1. Save time – the most obvious benefit.

2. Repeatability. Set a series of tests. Run them as often as needed, without manual intervention. Validate that you didn’t break anything simply by pushing a button. Apart from saving time, you get consistency. If you’re a vendor, you ensure that the most critical tests are run across all sites, regardless of client availability. So you deliver consistent quality. The result is less downtime and increased client satisfaction at lower cost.

3. Avoid frozen interface syndrome, maintain interfaces more easily.

4. Implement changes much faster, so clinicians gain access to newer functionality and information in source and destination systems. Ultimately, this puts you on the path to easier, more agile interoperability.

5. Ensure traceability. Test reports allow you to document that tests succeeded and/or failed over time.

6. Increase test coverage. More testing works out to better quality. Manual testing takes so much effort that you can’t test and retest everything. You end up focusing on just the highest risk items.

What If You’re Busy?

These are great reasons to embark on test automation. The organizations that embark on automation get it. But there are other teams that are so crazy-busy, with their heads practically underwater, that they can’t add any more to their plates.

We get that. New methodologies and new ways to get things done put you on a learning curve. Even if the payoff is worth it, it can be hard to get started.

What if there was low-hanging fruit? There is now. We’ve put together some basic tests/validations that are tedious to run manually but easy to automate. If you’re looking for the low-hanging fruit of HL7 test automation, start with segment and field validation here:

Validate Field1 = value
Validate Field1 = Field2 within the same message
Validate Field is X characters long
Validate Field contains a limited set of characters
Validate Field does not contain a set of characters
Validate Field is a valid date

These tests will get you going. They’re easily set up and run easily. Adapt them to your own test automation software. Or if you want to get HL7-specific, ask for an intro to Caristix software to check them out. They’re quick to set up and run repeatedly.

Interfacing Management Maturity Model: Part 2

9 Diagnostic Questions: Interfacing Management Maturity Model

9 diagnostic questions interface managment curveLast 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

Download the HL7 Survival Guide

Interface Gap Analysis: 3 Reasons Why You Can’t Skip It

Tip 11 in the Interoperability Tip Series

3 Reasons Why You Can't Skip Interface Gap Analysis

Last week, you learned about doing a gap analysis – mapping differences  between the systems you’re interfacing. Today, we’ll cover why you need this artifact.

1. Interface Requirements

No interface matters unless those coding the engine can accurately scope the interfaces they need to build. You need a way to communicate who does what on an interface. Is the vendor changing a field? Is the interface engine handling the field transformation? It’s critical that you pin all this down in an interface gap analysis before interface development begins, or you will be wasting time iterating through multiple changes later in the interface lifecycle.

2. The Timeline

Without a gap analysis that details your requirements, you’ll end up implementing a generic interface that doesn’t address your organization’s unique needs. Your end users will be frustrated that they can’t easily access all the information they need. And you’ll end up wasting time, money, and effort troubleshooting after going live. With a gap analysis, you can avoid extended go-live periods, significant maintenance at increased cost, and unhappy clinician end-users who are unable to access the data they need to deliver appropriate patient care.

3. Predictable Effort

Gap analysis work upfront, before the interface is built, lets you stay on track, reduce defects during the build, and get into production faster.

Downloadable Interface Gap Analysis Template

Looking for more guidelines? Use this sample interface gap analysis template to get started.

[caristixbtn style=”green” text=”Download Template Now” url=”https://hl7-offers.caristix.com/hl7-interface-gap-analysis/” blank=”1″]

Introducing an Interfacing Management Maturity Model

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

Download the HL7 Survival Guide