Buying vs. building an HL7 system
Whether you build or buy, the process is still essentially the same.
If you are considering adding an HL7 subsystem to your healthcare application—provider or vendor, the process you need to undertake is essentially the same. The questions below encompass what we believe are the key questions to answer prior to building or buying and then implementing your HL7 subsystem.
Answering these questions will help make your HL7 implementation easier to understand, and less time-consuming, and less costly in the long term.
What is HL7?
HL7 is a Standards Developing Organization accredited by ANSI (American National Standards Institute) to write standards representing a consensus of various entities in the healthcare arena. HL7 is also the term given to a collection of standardization protocols published for the industry. HL7 specifications define an ideal presentation of information, or encoding rules. The broad objective is to provide comprehensive standards for the electronic exchange of data among healthcare applications.
To clear up a common misconception, HL7 is not a software application. The title HL7 conjures images of a packet of compact disks, manuals and clever icons. This could not be further from the truth. In reality, every HL7 version is a four inch thick, three-ring notebook, with thousands of pages of detailed interfacing information. The HL7 standard is a ‘book of rules’ that sets forth a framework for negotiation in interfacing, giving programmers and analysts a starting point from which to begin their technical discussions.
The prime objective of HL7 is to simplify the implementation of interfaces between healthcare software applications and various vendors, so as to reduce the need for custom interface programming. What was originally created as an intra-hospital communications standard has matured and arguably become the undisputed, de facto model for the entire healthcare industry’s data exchange challenges.
Why is an HL7 subsystem so challenging to implement?
The strengths and limitations of HL7 are easily identifiable. Prior to the first HL7 standard being published, there was absolutely no framework for negotiation when it came to healthcare IT interfaces. Vendors and providers sat down across the table from each other with blank sheets of paper and simply said, “Where do we start?” This not only created massive nonconformity in the healthcare interfacing, but also made healthcare interfaces painful to implement and costly to develop.
Over the years, versions of the HL7 standard have continued to develop slowly, methodically and thoroughly. The 2.X versions of the HL7 standard have become a comprehensive framework for negotiation for use in the developing of interfaces. The standard is not, however, a rigid unbending set of rules. Version 2.X is simply an immensely detailed list of interfacing items set forth to discuss and to negotiate, leaving room for optionality and flexibility.
“Intentional optionality” was built into the original versions of the HL7 standard. The standard was built from the bottom up; beginning with very general concepts, allowing for additions to the standard when situations arose that dictated the need. To ease adoption efforts, it was decided that early versions (such as version 2.1) would be frozen in time and that when making additions to the standard, all the new parts and pieces would become optional.
Backward compatibility was a goal in all 2.X versions of the standard, again, to make adoption of each new version of the standard easier to achieve. Therefore, the vast majority of what is now found in the most current balloted version of HL7 is optional or “open to negotiation.” Hence, implementing a standard that is inherently optional by nature can be a complex and time-consuming task.
What tasks does my HL7 subsystem need to perform?
You will want to perform a needs analysis to determine the specific requirements of your HL7 subsystem. Although an HL7 subsystem can contain an infinite set of features and functionality, the following ten attributes are absolutely imperative:
- Ability to establish HL7 TCP/IP MLP connectivity layer to facilitate communication
- Ability to parse and/or serialize any standard version of HL7 to XML, XML to HL7, or any combination thereof (e.g., HL7 to XML to HL7)
- Ability to parse and/or serialize any non-standard, vendor specific “flavor” of HL7
- Ability to persist messages in storage until they need to be acted upon
- Ability to send HL7 and XML messages
- Ability to receive HL7 and XML messages
- Ability to handle messages timeouts and resends
- Ability to automatically generate message acknowledgments
- Ability to “non-programmatically” configure your HL7 subsystem
- Ability to easily monitor message flows and troubleshoot interface problems
Should I buy or build my HL7 subsystem?
To build your own solution would require at least one of your programmers (and more likely two) to become HL7 experts. Every organization is understaffed these days, and yours is probably no exception. To be honest, it really comes down to this: Why build and maintain an HL7 subsystem, that’s outside of your core set of skills, which an off-the-shelf application can handle instantly.
From a quantitative perspective, the development and maintenance costs need to be calculated and considered seriously before proceeding. From a strategic perspective, the product management and development focus needs to be evaluated— what is the core strength and requirements of your application in the market?
How do I learn enough about HL7 to design my subsystem?
Build or buy, you still need to have a solid understanding of the HL7 standard. Without solid HL7 knowledge, it is nearly impossible to make wise choices during your implementation of the standard. You’ll need to understand the basics (e.g., HL7 message structure and common message flows). You’ll also need to understand more complex issues such as determining proper HL7 business logic, how to write and interpret HL7 specifications, and how to document the overall HL7 system you put in place.
How will I implement my HL7 subsystem?
Once you have defined your HL7 subsystem requirements, you will want to document the steps and overall process needed to make your HL7 subsystem a reality. Questions you will need to answer are:
- How are you going to map HL7 into your database?
- What tools will you use to handle message parsing, encoding, send/receive logic, reject queues, acknowledgements, log files, etc?
- Who will be your early adopters to verify the implementation?
- Does the implementation satisfy all of my functional requirements? etc.
- Whether you build or buy your HL7 subsystem, it is important to have an HL7 implementation strategy planned out.
What is the business logic for my HL7 subsystem?
Assuming your HL7 subsystem has been designed to provide robust HL7 services, the demanding part of implementing HL7 is adopting your business logic into an HL7 message.
- If you are receiving HL7 messages, you need to define what data will be pulled from the HL7 message and how this information will be used to update your patient database.
- If you are sending HL7 messages, you need to determine the specific data to send within the message and what fields will be used to identify this data.
- Whether you are sending or receiving HL7 messages, the processing sequence of your HL7 messages is critical if your patient database is to remain accurate.
How your business logic is defined has a direct impact on how easy your HL7 subsystem is to maintain so make sure you give yourself adequate time and resources for this step.
How do I write the HL7 specification for my subsystem?
The key to successful HL7 communication is to completely, and in detail, document your interface’s functionality. Your HL7 specification will either be your lifesaver or your boat anchor as this specification is the contract between you and your customer healthcare applications.
Having an HL7 specification that accurately documents the HL7 information your system will be using and the format of this information enables successful communication with other systems.
What is the process for obtaining funding for an HL7 subsystem?
The funding process for your HL7 subsystem depends on the business issues surrounding your decision to implement an HL7 subsystem. Therefore, before you apply for funding you will need to write a business case for your HL7 subsystem.
Without the business case, all of the technical details you determined as you answered the previous questions don’t matter. You need to understand the costs of adopting and deploying HL7 as you will need to justify these costs to your boss, CEO, CFO, etc.
As part of your business case, make sure you answer the following questions:
- What is the contract/payment schedule process if I am buying an HL7 subsystem?
- What is the funding process if I am building an HL7 subsystem?
- What is the ROI of the HL7 subsystem and how will this ROI be obtained?
How will the HL7 subsystem be shipped?
If you are a vendor implementing an HL7 subsystem for your product, you must also decide how the HL7 subsystem will be shipped with your product. This includes determining the platform your HL7 subsystem will run on (i.e., a stand-alone PC or a shared PC with your application server). You will also need to specify the installation process for your HL7 subsystem.
When determining how the subsystem will be shipped, it is important to think about your end users and the level of technical support they will have available to them, as this will impact the complexity of the HL7 interface installation and configuration process.
How will the HL7 subsystem be supported?
Once you know how your HL7 subsystem will be implemented, how it will communicate with other HL7 interfaces, and how it will be installed, you need to decide how you will support your HL7 subsystem.
Supporting an HL7 interface can be expensive. HL7 interfaces often need to be adjusted for each site where the interface is installed. As you document subsystem support, make sure you also specify what is included in the support fee and what work will entail additional costs. Define a policy for handling interfacing issues that occur when the systems you are interfacing to change.
How will users be trained on my HL7 subsystem?
HL7 interfaces can be complicated, but they don’t have to be. If the interface specification has been well written, and the installation and configuration processes have been well thought out with good end user instructions, using the HL7 subsystem will also be straightforward.
At this point, you need to determine if written instructions for using your HL7 subsystem will be enough or if additional end-user training will be required. If additional end-user training is required, will this training be the same for each installation or will training need to be customized on a site-by-site basis?
How will upgrades to the HL7 subsystem be handled to take advantage of future features in the product or interfaces?
HL7 is not a static specification. New features and messages types are continually being added to existing HL7 versions. In addition, new versions of the specification are being added. Are you planning to upgrade your HL7 subsystem to take advantage of changes in the HL7 standard? If you are building your HL7 subsystem, how hard will it be to modify your software to handle HL7 changes? If you are buying an HL7 subsystem, what is the vendor’s policy on upgrading their HL7 subsystem?
There is ample information to think about before you begin the process of HL7 enabling your product(s). However, answering these questions prior to beginning the implementation process will help guarantee your HL7 implementation is a success.
