Building Blocks: Newborn Screening Health IT Implementation Guide and Toolkit

Section 3: Implementing Newborn Screening Data Exchange with a Messaging Partner

This resource is part of the Building Blocks: Newborn Screening Health IT Implementation Guide and Toolkit. Explore the full Building Blocks: Newborn Screening Health IT Implementation Guide and Toolkit.

Save

Summary

Section 3 describes the general process that laboratories will follow when implementing NBS data exchange with a hospital or other messaging partner. First, as described in Section 2: Managing Relationships with Hospitals for Newborn Screening Data Exchange, the laboratory must work with the hospital to plan the implementation, sign any partnership documents, and agree on the specific details of the technical solution (transport method, routing, etc.) that the hospital will use. Next, the laboratory will need to support the hospital’s IT team as it establishes and tests connectivity with the laboratory. The messaging partners will then need to develop and validate test messages to ensure that the data each receives meets system and program requirements. Finally, the partners transition the data exchange to production and discontinue the legacy method of sending test orders and results. The steps in this section will likely need to be completed separately with each hospital or hospital system.

While the process to establish a data exchange with a message partner follows the same basic steps, the actual implementation is unique for each messaging partner. Setting up and testing the exchange is an iterative process that will require close coordination between the laboratory and hospital. Not only the network and system SMEs but the program SMEs must review and validate the data flow and the messages. The testing and validation process will continue as the teams identify and resolve issues. It is important to clearly establish the requirements for the messaging so that everyone concurs when the data exchange can move into production.

Establish Connectivity for Data Exchange

Introduction

Much of the effort to establish connectivity will have been accomplished in the preparation and planning stages. The technical effort is most likely the least time-consuming aspect of this implementation. The laboratory should have defined several artifacts prior to establishing connectivity:

  • A messaging policy document
  • A security policy review
  • Technical design document
  • A test plan (See Set Up Newborn Screening Health Data Validation Method)

The technical approach to connectivity and transport will vary from laboratory to laboratory and possibly from hospital to hospital. Transport options include PHINMS, Secure File Transfer Protocol (SFTP), Web Services, Direct, Virtual Private Network (VPN) and Health Information Exchange (if available).

Testing and establishing the connectivity should take days while the preparation may take weeks or months. It will involve technical staff from both the laboratory and the hospital. Preparatory work will include security personnel as well as administration from both the hospital and laboratory.

Develop Messaging Policy Document

The first artifact required for connectivity is the messaging policy document (e.g., an MOU or DURSA). It should document confidentiality, authorization, and non-repudiation constraints of the messaging system. For each electronically ordered newborn screening specimen, the laboratory will receive an electronic data set as well as the data set received on the physical form. The messaging policy document should outline how the laboratory will handle and prioritize these data sets. It should also document requirements for protecting personally identifiable information (PII) per state laws and regulations. The messaging policy document may describe policies, practices, and specific third-party security packages such as firewalls, intrusion detection software, and proxy servers that may impact the system.

It should identify the approach for encryption of payload as well as authentication of sender. The messaging policy should clearly define what data is required in the HL7 message and what data will be required on the order card. Additionally, the document should include a process to handle missing and/or conflicting data, as well as information about the intended retention and archiving strategy. It is recommended that the laboratory retain original HL7 order messages for at least six months.

Finally, the document should include an approach or strategy for uniquely identifying an ordering entity. Object Identifiers (OIDS) are recommended as a best practice. The messaging policy document should also define what constitutes a unique message (the key field or fields) as well as a unique order to avoid duplicates and handle updates correctly.

Review and Sign Off on Security Policy

The NBS messaging team should review existing IT Security Policies at both the laboratory and hospital. It is recommended that any security policy decisions are documented in the messaging policy document and approved by both the laboratory and hospital. Depending on the policies in place at the agency, it may be necessary to have a security officer or the laboratory director involved with this review and sign-off process.

Establish and Test Connection

Note that the initial connection between the hospital and laboratory will be used to execute the test plan as described in Set Up Newborn Screening Health Data Validation Method. The testers must affirm that the data exchange and all test messages have passed validation before the laboratory establishes a connection in production. To test the connection, it is recommended to begin with a simple non-encrypted text message ("Hello, world"). Both parties essentially send a test to ensure that they can send and receive data from each other. Further testing should include validation of the encryption method. Various error test cases (malformed message, incorrupt file, data transmission interruptions) should also be performed to ensure the system handles errors correctly.

"This pilot project showed that the infrastructure for sending electronic results could be set up quickly and at little cost. This process could easily be expanded to send electronic results to multiple hospitals. Currently the data is being sent in PDF format, but the same infrastructure could be used to send HL7 messages."

Ohio Newborn Screening Program; State Case Study #8

Complete Validation of Newborn Screening Data Messages

Introduction

Completing the message validation will rely heavily on the implementation guide and test plans completed in Section 1. At the end of this phase of implementation, the laboratory will be ready to exchange messages with its hospital partner. The laboratory will need to complete these tasks with each hospital. The process may change slightly, depending on the specific needs of each partner. As the laboratory repeats this process with multiple partners, it should document frequently encountered issues and the methods used to resolve them as well as any other lessons learned. This documentation will increase efficiencies and reduce the time and effort needed to complete the validation and onboarding process with other partners. If working with a third-party software vendor or through a state HIE, additional testing will be required to test the interface between hospital EHR and the third- party software, as well as the message transport between hospital and state laboratory.

Perform Test Cases

Refer to the test plan (Section 1E) to determine the test cases that need to be run during this phase. The laboratory should prepare and discuss a list of scenarios with the hospital partner. Due to the unique requirements of the partner hospital, some modifications to the plan may need to be made before beginning this process. These test cases will need to be run in a test system to avoid any confusion with real patient samples.

The laboratory may already have entered test samples into the LIMS test environment if they have on-boarded hospitals previously. The hospital can enter test cases into its EHR test environment even while the IT team is working on setting up the technical infrastructure to transmit the message. During this process, the project manager must ensure that the laboratory and hospital testers are clear about how to report issues identified during testing. To resolve these issues, the laboratory tester will need to coordinate with the tester on the hospital team as well with the developers and integration specialist on the laboratory team. The team will need to test both incoming orders and outgoing results messages. Scenarios for orders and results should have been determined in the test plan.

Consume Test Orders

The first step in validation will be the ability to consume test orders that the hospital generates. The hospital partner should mock up orders in their test EHR that correspond to the test case scenarios defined in the test plan.

Once the order arrives at the laboratory, testers must verify that every field arrives as expected in the LIMS. Note some fields are kept "behind the scenes" and are not visible through the LIMS user interface, but by working closely with the integration SME, the tester can identify these scenarios. The tester must also make sure any defined triggers are working correctly. For example, if the test case requires the order be linked to a previous submission, the tester should assess this linkage, as well as any differences in test orders that may be required because of the linking.
During this phase of testing, the laboratory tester will have to work closely with the partner hospital to address any issues identified. Additionally, the tester must keep documentation on the results of the testing as well as any issues that arise and how they were addressed. Working closely with the quality assurance staff at the laboratory, the tester is responsible for producing the documentation needed to meet accreditation requirements.

Send Test Results from LIMS

The second phase of message validation is to run the tests through the LIMS and release results. The tester should have a mechanism to view the HL7 results messages and ensure the messages meet the specifications of the implementation guide and the test cases. The laboratory should have completed much of this testing before engaging the partner hospital, but the tester should still check every field for compliance with implementation guide and reporting requirements for the laboratory. Once verified, these messages should be sent to the test system of the partner hospital for verification. The laboratory should be in constant communication with the hospital to ensure that the messages were received and are being consumed correctly in the EHR.

Again, the laboratory tester should be responsible for documenting the results of the validation efforts. The laboratory may ask the hospital partner to send screen shots of the data as it appears in the EHR to record as part of the validation packet.

Incorporate Changes

All issues identified during the validation phases should be recorded. The laboratory tester should work closely with development staff to assist in addressing any issues. The laboratory development staff should also be prepared to work closely with their counterparts at the hospital to assist in resolving issues, if needed.

In some cases, the issues identified may reveal limitations in the hospital or laboratory systems that cannot be resolved by coding and development. The laboratory and hospital should work together to find business solutions to these issues, if needed. The resolution to each issue, whether it is a development effort or a business decision, should also be recorded to make sure any deviation from the test plan is understood. Some issues identified will be classified as enhancements to be addressed after the go-live event. The team should be careful to prioritize the issues that are required for go-live, versus those that can be addressed after, and work to maintain the project schedule by holding a hard line on not spending time on "nice-to-have" enhancements to system function.

It is important to note the changes made during the on-boarding of each hospital and to take care in assessing whether any of these changes will affect hospitals that are already in production.

Re-perform Test Messages

The laboratory and hospital partners should repeat test cases until all issues have been resolved and recorded as complete. In many situations, test cases might have to be adjusted during this process to meet the granularity needed to identify and correct issues, so the team may expect the total number of test cases performed to grow during this process. The team must continue with this iterative process until all test messages pass validation as defined in the test plan. The results of all these tests, as well as any issues and resolutions, should be documented and maintained according to the quality assurance requirements of the laboratory and hospital.

Preparation and Go-Live for Electronic Health Data Exchange

Introduction

Before scheduling the go-live event, all partner agreement documentation should be in place, the validation of the messages should be complete, and all documentation submitted and signed off. By the end of this chapter, the laboratory will have moved the required code into production. The laboratory should have developed a cutover plan during the project planning phase, but this plan may need to be adjusted for each hospital, depending on its particular needs.

Train Laboratory Staff in New LIMS Functions

All laboratory staff who are involved in the new process will have to be trained in the new method. By using the tools found in Section 1 on change management, the laboratory staff should be prepared for these changes. These changes will be most acute as the first hospital is on-boarded to electronic messaging, but as additional hospitals are added, the corresponding changes should be reduced.

"The Wisconsin NBS program worked with their contracted courier to provide differently colored specimen envelopes for the birthing hospitals participating in ETOR. In addition, we placed brightly colored stickers on the NBS cards themselves before shipping them... These two visual cues ensured specimens expected to be associated with an electronic order were identified upon receipt in the NBS lab."

Wisconsin Newborn Screening Program; State Case Study #4

The first step in training the laboratory in the new functions is to prepare training materials. These materials should be gauged toward their audience to be most effective. For the personnel most closely involved in the receiving of electronic orders and sending of electronic results, one-on-one training may be best, while other laboratory staff may simply require a group presentation to be informed about the relevant changes that affect them. The project team should assist in the development or editing of formal standard operating procedures to reflect the new process. Laboratory staff may also require quick reference guides, especially for referencing questions that come from hospital submitters. The project team may be able to develop some training materials through the validation process, but in order to make sure the most up-to-date information is included in the training material, these should be finalized after the validation process is complete.

The project manager should ensure that all laboratory staff, including those who work outside the newborn screening laboratory, are aware of the updates in the NBS lab. If any unintended consequences are realized after the go-live event, such as dips in bandwidth or delays in other electronic messaging, the laboratory should know whom to contact with questions or issues.

As with the performance of the test cases, the laboratory trainers should document staff training to make sure the quality assurance requirements of the laboratory are being met. Staff with new job functions should be assessed for competency, and the results should be documented in their training records.

Cut Over to Production

Schedule Go-Live Event

The team should schedule the go-live event carefully, ensuring all essential personnel are available to assist. As with many of the tasks in this section, the on-boarding of the first hospital will require more attention during the go-live than subsequent hospitals. After identifying the essential personnel needed during the go-live the team can identify a time for the deployment. Management should be aware of the need for overtime and should secure preapproval for the staff, if needed. The laboratory team should know with whom to communicate at the partner site, both the IT and the administrative contacts, and how to reach them to resolve issues.

Frequently, moving new code into production will need to be scheduled after hours so not to affect the laboratory’s daily processes negatively. If possible, the team should plan on testing basic function of the system after the deployment to ensure there are no negative consequences of the production move.

Develop Transition Plan

Well in advance of the go-live event, the project manager should have developed a transition plan. This will need to be reviewed with all affected personnel who will be responsible for the operation and maintenance of the system. The plan should also include any knowledge transfer activities and may need to be tweaked to accommodate the needs of each individual hospital. For example, depending on the needs and preference of the partner hospital, the team may adjust the length of time and scope of parallel reporting (both paper and electronic). During parallel testing, the team should rely on a clear communication plan between the laboratory and the hospital to complete and report the comparison between the paper and electronic reports. As with the test cases, the team should document any issues and their resolutions during the parallel testing phase.

Close Out

Turn Off Paper Reporting

Once parallel testing is complete, the laboratory team will need to cease the production of paper reports from their LIMS for that site. This may require significant LIMS changes or minor configuration, depending on the LIMS and its capabilities. The laboratory testers should validate this change to ensure all reports that should be printed are continuing to print, and those that are not, do not. The project manager should make sure the changes are clearly communicated to the staff responsible for reporting so that they are prepared for the change of job function.

Retire Legacy System

If, during the close out, legacy systems are retired, the team should make sure all data retention policies are met. The team must decide if the legacy data will be migrated to the new system or archived for retrieval using a different method. The team must clearly communicate to staff how the data must be retrieved from legacy systems.

Celebrate

A project of this scope should be celebrated once the goal has been met. The team can use this opportunity to present or publish the work of the team at a conference or in a journal. The project team and laboratory administration should recognize staff who have gone above and beyond for their service to the team and to the laboratory. If possible, include the partner hospital in a celebration recognizing their hard work. Boosting team morale by recognizing the hard work and achievement of the team will be useful to maintain energy for subsequent implementations.

Schedule Post Go-Live

During the test cases and parallel testing, the team will likely have identified enhancements to the data exchange function that will need to be addressed. The team should prioritize and schedule these post-implementation enhancements to make sure the system functions as smoothly as possible. The team may need to have several minor production releases after the go-live event to fix issues and provide enhancement to the function rolled out during go-live.

Post Go-Live Communication

The project manager will need to communicate clearly with all laboratory staff to make sure everyone is aware that the implementation phase of the project has ended and is moving into the maintenance and operations phase. Depending on the structure of the development team, these same personnel may transition their roles to maintenance and support, or new staff may take over these roles. The team should communicate clearly to the laboratory and partner sites about whom they must contact regarding issues in the maintenance and operations phase so that all staff can be focused on their roles identified after the go-live event.