By: Thomas Brizzi, Project Manager
If your pharmacy uses automation to fill prescriptions, you most likely have two separate software systems running in your pharmacy. All pharmacies have their primary software system (commonly called a pharmacy information system, or host system) that stores prescription information, files insurance claims and retains historical data of the prescriptions filled. Then, because your pharmacy has automation equipment that processes the actual prescriptions, there is most likely an additional software system, typically from another vendor. In order for these two systems to “talk,” you must have at least a “one-way” interface where the host system sends the prescription information to the automation system. More commonly, your pharmacy has a “two-way” interface, where the automation system can also send information captured during prescription filling, to the host system. This article is not meant to provide information on the technical details and protocols of how two systems can talk or communicate via HL7, XML, or some other interface format, but rather to help pharmacies, who are typically not experts in managing software development projects, manage the development of such a software interface in a way that both vendors work towards a common goal defined by, and meeting the needs and expectations of the pharmacy.
Too often I have been told by a pharmacy customer, “We manage a pharmacy, we don’t know anything about software interface specifications and managing software projects. That is why we have you two vendors! Why don’t you two software vendors just work out the specification?” The problem with this is both vendors will try to use an interface structure they have used in the past and push the other vendor to do all the work, adapting to meet the specifications of their own interface. Too often these discussions are being made long after cost estimates on the interface development have been made by both vendors, and sometimes after capital expenditures are approved and purchase orders are cut. Even if a prior interface structure/template from one of the vendors is chosen, that template may not meet all the needs of the pharmacy, who after all, is the customer paying for these vendors to develop a communication interface.
Prior to requesting estimates from either vendor, representatives from both vendors should meet to determine what type of interface protocols (again HL7, XML, etc.) both vendors can support. Once you find a common protocol, then the pharmacy should ask both vendors for a typical interface template showing the data fields that each of their systems transmit. The pharmacy should review both of these interface templates and make sure the data fields being sent back and forth include all the fields they truly want communicated between the two systems. Careful thought should be put into any additional, missing fields that may benefit the pharmacy in data tracking, making sure to add these additional fields. Quite often during the template review, the pharmacy will recognize that both vendors’ templates include unnecessary fields, which should be removed. Determining exactly which fields are necessary is important and will streamline and improve transaction speeds between the systems.
After the review, the pharmacy and vendors should meet again to finalize the list of required data fields, and to confirm that the custom fields requested can be accommodated. When all are in agreement on which data fields will be sent the pharmacy should create (or request that one of the two vendors create) a custom interface specification documenting the agreed upon items. Once this custom software interface specification has been drafted, a final review and signoff should be made by all three parties. This software specification now becomes the property of the pharmacy and is a living document throughout the project. Certainly there is a good chance that during the project an additional field or a change to the length or type of field will happen, and this document will be revised. As long as each time a change is needed, the pharmacy revises this document and both vendors sign-off on the revision, there should be no question for either vendor on how the interface should function. Another advantage of an accurate specification document is that the interface costs won’t change unless there is a major change in the project scope. Using the specification, each of the vendors can make a very accurate estimate of the cost to develop an interface for the pharmacy. In this way, the pharmacy can request approval of the capital expenditure, knowing that the prices won’t change unless there is a major change in scope.
The value of keeping the living document up to date is immeasurable. Often, during the length of the project, issues will arise in which the interface does not work as expected. One vendor will invariably blame the other, claiming the error was due to the structure of the other vendor’s message. Each vendor will encourage the other to “fix” their software. Without a signed specification document, it may be impossible to determine which of the parties is at fault, or which vendor would modify code. When the error in the interface is understood, it should be clear, based on the interface document, which vendor was in error.
When pharmacies understand the importance of careful planning and the need for an accurate interface specification document that clearly meets their needs, the interface vendors will be able to work together to build a communication system that works.