Requirements Thinking
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.