By completing the steps outlined in Section 1, the project team prepares the laboratory’s personnel, technical infrastructure, and messaging capabilities to receive and send electronic NBS data exchange. At the end of this process, the project team will have determined the following:
- The scope, timeline, and overall management plan for the implementation project and the outreach approach for engaging hospital partners.
- The implementation profile that the laboratory will use to define the NBS electronic message.
- The changes that laboratory will need to make to the existing laboratory workflows and LIMS.
- The laboratory system(s) involved in receiving and processing the incoming test order message, as well as those generating and sending the outgoing results message and how these systems will integrate.
- The test plan that the laboratory will use to verify that the data exchange process is stable and the messages are valid.
While the laboratory may have to revisit and revise the decisions and artifacts developed in Section 1, the preponderance of this foundational work should remain stable throughout the project lifecycle and while completing the subsequent activities described in this Guide.
It is important to stress that the laboratory should not approach the tasks in each Chapter or even in each Section in a completely linear mode. The laboratory may be able to start certain Section 2 and 3 activities before all Section 1 activities have been completed. In some cases, a specific hospital partner may have been involved from the beginning of the process and have been invested in the planning and development of the electronic message. The hospital may be able to take preparatory steps of its own during this period. The key is that that the laboratory cannot fully implement the data exchange with any hospital until the basic messaging framework has been established. Furthermore, as the laboratory begins to engage and onboard multiple messaging partners, it will be more efficient for the laboratory to already have a solid outreach strategy in place and be ready to begin implementation work. Section 2 describes this outreach.
The Project Management Institute’s authoritative Project Management Body of Knowledge (PMBOK) identifies project initiation as the first phase in a project lifecycle. The team uses this initial phase to draft a tentative plan, articulate the overall objectives of the project, and obtain authorization from key decision makers. The duration and level of effort in this first activity will vary by laboratory. It may be a single meeting or require several months of discussions. In general, it is advised that the laboratory anticipate the initial project planning process to take at least two to three months.
 Project Management Book of Knowledge. 2013. Fifth Edition. Project Management Institute.
Identifying a Lead
As soon as the laboratory has determined that NBS messaging is a priority, the laboratory director or division chief should identify a project manager to take the lead on the planning. The effort will move forward more quickly with a dedicated individual to coordinate stakeholders and advocate on the project’s behalf. This individual, whether a member of laboratory leadership, a laboratorian, an IT resource, or other SME, should have strong communication and organizational skills and possess a basic understanding of both laboratory and IT processes. This individual should have the authority to pull the necessary internal resources together and should be prepared to see the project through the initiation and planning stages.
In the initiation phase, the project manager will facilitate meetings of various stakeholders and help the laboratory navigate the early decision-making process. As part of this process, the project manager will develop artifacts that describe the project at a high level. This preliminary documentation may include a business case, a project charter, a message flow diagram or other artifacts. These artifacts should be well documented and easily accessible to current and future laboratory staff. As project teams change, strong documentation will ease transitions between staff.
A business case summarizes the justification for starting a new project. It defines the problem that the project is attempting to address and explains the proposed solution. It often provides both quantitative (e.g., decreased cost) and qualitative (e.g., improved customer experience) benefits of the project. For example, in the case of NBS electronic messaging, the problem being addressed may be a delay in testing NBS specimens due to manual demographic data entry. The business case in this instance should include information about the percentage of births each hospital represents within the state and basic information about the electronic health records (EHRs) that they use.
The business case should also include a cost benefit analysis. This analysis may describe the potential benefits to hospitals implementing the NBS data exchange, in addition to the benefits to the NBS program, both in terms of money saved long-term, the number of potential newborns saved, improvements to work processes, and time saved in testing NBS specimens. The value received for all involved parties by completing the project should be readily understood by the decision makers and backed up with documentation, if possible. While this analysis may not be comprehensive, it is important to document the estimated monetary and non-monetary costs of implementing NBS electronic messaging, as well as the cost of doing nothing, such as risks associated with delayed testing and/or reporting. Laboratorians and technical SMEs can provide input on the costs associated with assessing and changing laboratory workflows, purchasing and implementing new software, modifying the laboratory’s system architecture, and long-term maintenance and operation costs.
In many ways, the project charter builds on the business case. It itemizes the objectives of the project and the general roles and responsibilities of each party. It begins to hone in on the project scope and timeline. If the laboratory has any target milestone dates, these should be documented. For example, does the laboratory intend to have one hospital in production by the end of the fiscal year, or some percentage of all NBS orders submitted electronically within two years? Keep in mind that outside factors may affect this timeline (e.g., system upgrades, funding deadlines).
For NBS messaging, it is also important that the project charter identifies the specific data-messaging standard (e.g., HL7), the specific implementation guide for that messaging data standard, and the terminology data standard to be implemented (e.g., Local Observation Identifiers Names and Codes [LOINC]). The charter should also identify the approach that the laboratory will use to constrain the implementation guide for use by that laboratory in that specific use case (see Define the Newborn Screening Electronic Data Exchange for more details on this process). The project manager can use the project charter to present the details of this initiative to laboratory leadership and to other stakeholders.
Data Flow Diagram
It is highly recommended that the laboratory also draft a tentative data flow diagram as part of this exercise. The project manager should draw on technical SMEs to help develop this diagram and explain the laboratory’s current data exchange capabilities. It may be that the NBS program can leverage existing solutions to facilitate NBS messaging. The data flow diagram will begin to flesh out the details of the transport mechanism and the specific laboratory information systems that will be used to send and receive the NBS messages. See Identify a Health Data Exchange Technical Solution for an example diagram and more information on how to identify and design a technical solution for NBS messaging. In addition, the laboratory will need to confirm whether messaging partners will exchange data directly or if they will use a health information exchange (HIE) to route the message. The laboratory can review this message flow diagram with IT leadership to identify potential system modifications or integrations, security concerns, and other issues.
Before beginning the implementation in earnest, it is advised that laboratories take time to assess the readiness of their systems and the availability of resources. This task should be completed in parallel with the project charter since it will reveal key tasks needed for a successful project. From a technical perspective, the laboratory’s infrastructure (i.e., the hardware, software, network resources, and related systems) should have the minimum requirements to generate, validate, transport, and receive HL7 messages. The laboratory should also have a test environment that mimics the workflows of the production environment and allows the LIMS administrator to evaluate intended changes before deploying them to the live system. The relationship of the systems in the test environment should mirror those of the production environment. The laboratory must also be able to support whatever mechanism is chosen to transport the data between the laboratory and the hospitals.
"Programs serve different public health needs, but we learned from talking with other programs about pitfalls and successes in informatics. Most tools and lessons learned can be adapted to all public health electronic reporting projects. This is a lesson we can learn over and over again"
Newborn Screening (NBS) Program at the Minnesota Department of Health (MDH); State Case Study #1
In addition to these technical considerations, the project manager will need to review the IT team’s calendar to coordinate the implementation of NBS messaging with any planned system upgrade or other major IT projects. The project manager should also engage the laboratory’s legal and IT security SMEs during this assessment to inventory any significant considerations that will need to be resolved before the project can be authorized or that will need to be addressed at a later stage.
In many ways, the Guide serves as a checklist that laboratories can use to assess their readiness to move forward with the implementation of NBS messaging. Laboratories can use it to evaluate steps already taken as well as those yet to be completed. While not every task will need to be completed in sequential order, most steps will need to be accounted for at some point during the implementation process. Therefore, the laboratory should be prepared to meet the technical requirements and message specifications necessary to establish the data exchange.
In addition to the technical development, the laboratory can expect substantial changes to accessioning, processing orders, and verifying and sending results. See Prepare to Send and Receive Newborn Screening Health Data Messages for a summary of the questions that the laboratory should consider when assessing current workflows. The laboratory staff will need to plan and prepare for these changes.
The project team should carefully review this entire Guide to determine the laboratory’s readiness to implement the test order and result messages. The laboratory is also encouraged to review and complete the APHL Informatics Self-Assessment Toolkit to evaluate the laboratory’s overall informatics capabilities. The technical team may need to enhance certain areas of the laboratory’s technical infrastructure before the implementation begins.
A serious concern for laboratories is how to produce a realistic budget estimate for a large-scale messaging project. Unfortunately, given the unique circumstances of each laboratory, it is impractical to estimate average costs. Not all costs will apply to all laboratories. Moreover, the level of effort required to complete the various tasks will depend on the laboratory’s systems, contracts, staff expertise, and other considerations.
Rather than presenting overall project estimates, therefore, this Guide provides a list of factors that the laboratory should review in budgeting for this project. In addition, Virginia DCLS has provided an Example Budget that laboratories can use as a reference and model.
Internal Staff Resources
The SME Matrix summarizes the types of internal personnel resources that each step of the project will require. The laboratory can use this matrix to estimate staff assignments based on the scope of each task.
Centralized Versus In-House IT Resources
Some states have set up a shared services model to deliver IT support to all areas within the department of health, or even across multiple agencies. The laboratory may need to develop a plan for funding this IT support. Similarly, if the laboratory uses the State Health Information Exchange (HIE) as its point of connection for NBS messaging, it may be necessary to include HIE setup and maintenance costs in the project estimate.
While some laboratories will be able to rely predominantly on in-house resources, others will need to bring in vendors to update their systems. Most laboratories use a LIMS to record and track their NBS testing activities. This project will likely require updates to the LIMS in the form of modifications or additions of certain data elements. Many laboratories use specialized software to translate and transform the data coming out of the LIMS into an HL7 message that can be sent to a recipient. This message broker or integration engine also performs the same function to allow the LIMS to consume an incoming message. The laboratory may have a contractual arrangement with the LIMS or integration engine vendor and may need to engage the vendor’s services to make the required updates. The laboratory will need to factor the costs and schedule for these services into the overall project plan and budget.
Some vendors offer an application to hospitals that assists in collecting and configuring the EHR data needed to submit electronic orders to the laboratory. These applications interface with the EHR to collect auxiliary NBS data and, in many cases, create and send the electronic NBS message to the laboratory. Many laboratories and hospitals have found this service beneficial for several reasons. First, it takes the burden off the hospital IT team and may speed up implementation. Second, the vendor has the primary responsibility for engaging the messaging partners and providing technical assistance and training for both sides. Third, this approach leverages work that has already been done to interface with other laboratory and hospital systems. Nevertheless, relying on third-party software limits how much the laboratory can tailor the process or message to match existing workflows. Both the hospital and the laboratory are also then dependent on the vendor not only for the implementation but also for continued maintenance and operations. The laboratory should also be cautious about assuming that all hospital systems will agree to use third-party vendors for NBS messaging. The laboratory risks having to implement and maintain data exchanges through the vendor as well as with hospitals that opt out of using the software solution. Finally, this software will likely require licensing, a cost which will have to be negotiated between the laboratory, the vendor and hospital partners.
Keep in mind that data exchanges require continued operations and maintenance once they are in production. NBS messages may arrive at the hospital at any time, and the laboratory may need to arrange for a help desk or other on-call services. In addition, the laboratory staff should monitor and review and verify both the data feed and the contents of the message as well as plan and roll out updates. The laboratory will need to assess and account for the continuing expenses associated with NBS messaging to make the data exchange sustainable.
Maintaining project documentation is an important as laboratory staff turnover. By keeping project documentation up-to-date and readily accessible the project manager will streamline the onboarding and transition of staff when it is needed. The project team should consider using a document storage and sharing software to manage these documents (ex. SharePoint)
Some laboratories are committed to replacing legacy systems with electronic NBS messaging and begin work on the project without a clear cost estimate. Others insist on obtaining a definitive source of funding for the project in advance.
Many laboratories use the business case to develop a grant application. Laboratories can strengthen an application by identifying and partnering with a particular pilot hospital partner to demonstrate that they have laid the groundwork for a successful project. Keep in mind that identifying and procuring a funding stream, such as a grant, may take considerable time. The project may be put on hold for several months or longer while the laboratory waits for funding to come through.
The laboratory may determine that the cost of NBS messaging can be rolled into testing fees. The funding approach will depend on the laboratory’s administration and business processes. Regardless, it is advisable that laboratory leadership review the costs associated with NBS messaging and agree on a strategy, both for the implementation and long-term maintenance.
Authorizing the Project
By the end of this first set of tasks, laboratory leadership should have formally authorized the project as it is described in the business case or project charter and identified a funding stream. Each laboratory will have its own policies and protocol around the exact mechanism for project authorization. Once the project is authorized, leadership should assign a project manager who will guide the implementation through to completion.
For a large-scale data exchange implementation project to be successful, it is essential that the NBS laboratory invest time at the beginning to create a set of project management documents that define the scope of the project and all parties involved, lay out the anticipated timeline, and identify milestones and factors to measure progress and success. A project management plan will establish a solid foundation for the project, present the consensus strategies for managing all aspects of the project and help the team guide the project through its entire lifecycle.
A well-defined project management plan (PMP) is a set of documents that addresses a host of considerations for effectively managing a project. It lays out objectives and milestones as well as resources and cost, so everyone knows what to expect. It documents the approach for tracking and managing all aspects of the project, including schedules, changes, resources, risks, communications, etc. In many instances, the PMP will formally document many of the decisions that the laboratory has already made and summarized in the project charter, the stakeholder matrix, and other artifacts. The PMP should be considered a living document (or set of documents), as the project team will continually reference and update the plan throughout the life of the project. The PMP will serve as a strategic guide to help the team respond to changing circumstances over the course of the project.
The Tools Reference Guide provides examples of project management plans. Note, however, that many states and agencies require staffs to use specific templates to document project planning and management activities. Moreover, to secure funding and authorization, the project manager must ensure that the project documentation includes all the information and details as mandated by the jurisdiction. The project manager should carefully review the requirements within the jurisdiction as the team begins to prepare the project management plan and associated documentation.
A complex data exchange implementation project will involve many diverse stakeholders, including internal laboratory staff and external partners. Therefore, it is highly recommended that the project manager develops a stakeholder matrix early on to list out the stakeholders, their impact and influence over the project and their specific needs or interests. The project team will repeatedly refer to this matrix during the planning stages as well as throughout the project lifecycle.
The project manager should define the roles and personnel resources needed at different stages of the project, such as IT leadership (Chief Information Officer), a data standards SME, a LIMS administrator, other relevant technology system administrators, the NBS program manager, a network engineer and a technical architect. The project manager will likely need to engage stakeholders beyond the laboratory as well, such as government officials, legal representatives, IT leaders and other leadership within the agency or the state HIE.
The SME Matrix provides a detailed list of the types of resources that may be required to complete the various activities associated with an implementation project. The project manager can use this matrix to identify individuals who will perform each required role on the project. In general, NBS program SMEs are primarily involved early in the process to reconcile HL7 fields with LIMS data while the laboratory’s IT implementer is involved later to create and validate the HL7 message. The level of participation for each stakeholder will vary depending on the division of work within the laboratory and the subject matter expertise required for the activities. While certain stakeholders may serve in supplemental capacities, joining the project as their expertise is needed, the project would benefit from having a small, dedicated team made up of laboratorians and IT personnel who are assigned to the project for its entire lifecycle.
Engaging with these internal stakeholders early will provide the project manager with a vision of the feasibility of the project. This task may be accomplished most effectively through one-on-one conversations with laboratory and IT staff. The project manager should indicate the proposed project timeline and encourage individuals to discuss competing priorities.
"The NBS HL7 project took a long time to gain momentum. At the beginning of the HL7 NBS project, we underestimated the amount of work needed to complete such an endeavor. We later realized that we needed a person knowledgeable in NBS disorders who also had a working knowledge of the laboratory information management system (LIMS) to perform the data mapping."
Michigan Newborn Screening Program; State Case Study #7
Depending on the contractual arrangements that the laboratory holds with vendors, the project manager may need to engage external stakeholders, in other words, partners outside of the laboratory or health department system, such as LIMS vendors, third-party software vendors or others.
The project manager should meet early on with any vendors to discuss the project and estimate costs and the timeline for modifications. The vendor may have insight into similar projects at other client sites and may be able to provide valuable reusable components for the project. Note that some stakeholders may require a formal contract to secure their support.
While in the planning stages, laboratories should carefully read Section 2: Managing Relationships with Hospitals for Newborn Screening Data Exchange of this Guide which describes strategies for "Managing Relationships with Hospitals." The project manager will need to engage hospitals early and often during the planning stages. In addition, the project team will likely need to produce some of the artifacts described in Section 2 to help explain the project to hospitals and obtain buy-in from them. Many laboratories have cited lack of hospital engagement as an obstacle to project success. It is strongly encouraged that hospitals be fully engaged and committed to the project before the work begins in earnest. The team should be aware that as they engage with multiple hospitals, each may have different requirements for the exchange process – it will not be a “one size fits all” solution.
The project manager should be able to leverage the project charter to explain to stakeholders the project’s objectives and the types of resources that may be needed and to secure their commitment to the project. Keep in mind, though, that it will likely be necessary to communicate the objectives of the implementation project in non-technical language to stakeholders who lack a general knowledge of laboratory informatics. It is often difficult to explain informatics design and requirements to administrators, financial and legal experts, or even to laboratorians. The Public Health Informatics Institute (PHII) recently released the PHII Communications Toolkit, which provides recommendations for how to present and discuss informatics concepts to non-technical audiences. The project manager may consider incorporating some of these communication strategies in the discussions with stakeholders.
Standards like HL7 make it possible for the laboratory to build to a common specification, ensuring that we are consistent with how data is reported for a specific use case like newborn screening. It provides a framework or blueprint from which to work. However, base standards lack the specificity to be used as-is. A successful implementation requires that these standards be constrained to meet the requirements of the implementer or newborn screening program. This specification, or implementation profile, is utilized by both sender and receiver and should be created with both partners in mind.
Creating an implementation profile requires a familiarity with the base HL7 standard, the mechanisms for its constraint, and an understanding of program requirements. This section will cover some of the key tasks and questions pertinent to developing a messaging guide. Further information on fundamental HL7 concepts may be found on the HL7 website. Vendors may be able to assist with these tasks or complete them in their entirety, and the laboratory may want to consider contracting with a vendor if needed.
Understand the Standard
Clearly communicating expectations for how senders and receivers will process NBS orders and results is essential to successful data exchange. Working toward an agreement on a singular way of doing things reduces the time and resources needed to maintain unique interfaces with each messaging partner. An understanding of how these standards work is necessary to both leverage the existing framework and to meet the laboratory’s needs. However, the laboratory may have to be flexible with their partners and weigh the risks of accommodating one-off solutions versus the benefit of on-boarding partners.
While HL7 publishes multiple standards for data exchange, the public health community has most commonly adopted the HL7 2.5.1 version. Because HL7 is designed to be broadly applicable to many use cases, the HL7 2.5.1 standard is not defined at a granular enough level to support a specific use case like newborn screening. Further definition or constraint of the base is necessary to remove ambiguity and define exactly what data should be included in an HL7 message.
Constrain the Standard
To have a viable data exchange process, the data contained in the message must be appropriate to meet the needs of the laboratory and its partner. This means that the all data elements must be clearly defined as far as optionality and the type of data transmitted. Openness in HL7 may be described by the inclusion of optional data elements or those that are not entirely defined, which can be difficult to implement for a specific use case. The process of constraining or reducing the openness of a standard is called “profiling,” and it is necessary to tailor the HL7 framework for a specific use.
Several initiatives have carried out work on a NBS profile. Recent efforts have incorporated the newborn dried bloodspot screening (NDBS) use case into the HL7 Laboratory Results Interface (LRI) and Laboratory Orders Interface (LOI) Implementation Guides developed by the Standards and Interoperability (S&I) Framework. This work built on the Public Health Informatics Institute (PHII) implementation guide for NBDS laboratory results, most recently updated in 2011. LRI and LOI are based off the HL7 2.5.1 standard and define requirements for electronic ordering and resulting of laboratory tests — specifically the implementation of laboratory orders and results interfaces in healthcare facilities. The creation of the NDBS profile component further constrains the standard for sending electronic laboratory orders and results for NDBS testing.
LOI and LRI are structured into groups of requirements called “profile components.” Implementers may define their profile to a certain extent by their selection of these components. This first step will set programs up to further define or tailor the standard to their state’s NBS program requirements. For more information on selecting these components see Baby Steps Toward Defining the Message , a companion resource that is included in the Tool Reference Guide in Section 5.
Perform the Gap Analysis
Selection of the appropriate laboratory profile components results in a constrained profile. However, the requirements of this profile probably will not yet meet the specific needs of the NBS program. For orders, the laboratory may collect only a subset of the data elements supported by the HL7 Orders Profile. Similarly, it may report only some of the data elements associated with the results. Further definition or constraint of this profile is needed to create an implementation profile that is specific to the laboratory’s NBS program. To identify which data elements will need to be defined further, the team must determine which segments and fields the laboratory will use to send and receive NBS orders and results. This will require a gap analysis.
At a minimum:
- For laboratory orders, the gap analysis will likely include a comparison between the collection card and the LOI profile.
- For laboratory results, the gap analysis will compare results reports (usually paper) and the LRI profile.
The gap analysis should result in documentation that clearly captures which data elements will be collected for both orders and results and where there are discrepancies with the LOI or LRI profiles to which your messages will adhere. For more information on performing a gap analysis see Baby Steps Toward Defining the Message.
The laboratory may share this documentation with partner hospitals at this point to assess whether 1) the hospital can realistically provide the requested data for the order; and 2) the hospital has the capability of receiving and consuming elements conveyed in the result message. Feedback from the hospitals may indicate that the laboratory will need to modify the guide. The laboratory should consider the hospitals partners in this process and work together to determine a fully implementable profile.
Create the Implementation Profile
With a completed gap analysis, the team is ready to create a program-specific implementation guide—a fully constrained profile that leaves no ambiguity as to which data elements should be sent and how they should be conveyed to meet the specific data requirements for the newborn screening program.
While there is no formal specification for how implementation guides should be formatted, most often, they mirror the look of the profile from which it is based. The document is edited where needed to reflect specific changes for the program. The implementation profile may include additional guidance or clarification on various parts of the document as needed. When we think of creating a constrained profile, however, many times we are referring to changes made to the static definition, which defines requirements for how the message should look in terms of segments and fields. For a more detailed description of how to create an Implementation Profile specific to the laboratory, see Section 5C, Baby Steps Toward Defining the Message.
As shown in the last several sections, a great deal of effort can go into not only understanding the standard but also applying it to a specific use case and then, finally, a specific implementation. The driving force behind this work is the idea that creating a granular, unambiguous definition allows both senders and receivers to build to a common goal, thereby reducing the need to maintain unique interfaces.
With so much effort put into defining the "rules," it is understandable that "conformance," or the adherence to agreed-upon rules, is paramount. At a basic level, the statement of conformance profiles in the message header says, "These are the rules I play by" and, by extension, "If you play by the same rules, we can play together."
However, what happens when the program is not able to follow the rules? For example, due to program business processes or application differences, the laboratory may be unable to support a data element that is identified by the NDBS component as required. Or alternatively, the laboratory may need to use a data element that has been marked as not supported (X). Using a strict interpretation of the rules, the laboratory will have been deemed non-conformant to the NDBS component. What does this really mean, and should you be worried?
The uniqueness of NBS programs in the United States makes the creation of a one-size-fits-all option almost impossible. The NDBS component should accommodate most programs with additional constraint of any "open" fields presumably making up the difference. Nevertheless, in reality, not everyone will be fully conformant and deviations from the standard may be negotiated between sender and receiver and thoroughly documented in the implementation guide. A certain amount of nonconformance is acceptable, as long as you have documented your deviations and all partners are in agreement.
The implications for those who must demonstrate conformance may be more significant. For example, vendors building to your specification would need to modify their specifications to promote a product as "conformant."
"The NBS program learned that the hospitals were not capturing all fields in the Electronic Medical Record, and our staff needed to make some decisions about how critical those missing fields were to laboratory results. It stretched the staff to think outside the box regarding what they needed to have versus what was nice to have."
Newborn Screening (NBS) Program at the Minnesota Department of Health (MDH); State Case Study #3
In the previous sections, we have looked at the profile or definition—specifically the segments and fields that structure the message. How these data elements are populated, however, is equally important and is determined by the field’s format i.e. the datatype. Datatypes provide a standardized way of sending information such as names, dates, addresses, text, and more. Information conveyed using standardized identifiers are ‘coded’.
Coded values, often referred to as "vocabulary," are essential to achieving interoperability. Just as HL7 provides a common structure, coded information allows sender and receiver to agree upon a common representation of data within that structure. For example, standardized codes for sex remove ambiguity. Senders and receivers can be confident that transmission of an "M" will always stand for Male, "F" for Female, etc. The values that may be used for each coded field are determined by the value set, a collection of codes that dictates the allowable content. The following resources provide more information on the existing standardized vocabulary that the NBS message will use:
- Value Set Companion Guide – This document defines detailed value sets for each field of the LOI and LRI guides. These values are expected to apply to the profile unless it has been specifically documented otherwise.
- Newborn Screening Coding and Terminology Guide – The National Library of Medicine (NLM) has defined codes specifically for Newborn screening test Panels. Of particular value is the panel of Laboratory Observation Identifiers Names and Codes (LOINC), which the laboratory will need to describe many of the concepts contained in the result message.
The availability of the Value Set Companion guide and the NBS Coding and Terminology Guide is a great help, as standard codes have already been identified for the clear majority of concepts relevant for newborn screening orders and results. With the variability of data collected across newborn screening programs, however, it is unlikely that the existing value sets will adequately cover every value collected by every state.
When this occurs and an existing code is not available, local additions to a value set are permitted. Additions must be clearly communicated between senders and receivers and should be well documented. The Lab Value Set Companion Guide offers implementation guidelines which may be helpful for programs going this route.
As you map standard codes, it may be helpful to keep in mind the following:
- Where will my vocabulary be maintained? Within my laboratory information management system (LIMS) or within my integration engine?
- Who will be responsible for maintaining (updating, adding, retiring) values?
- Will you have a change management process for vocabulary?
The work of mapping your local values to standardized codes is important—it will determine if you are accurately conveying the intended information. A vocabulary mapping document has been created to aid with this task. It includes NDBS associated value sets for fields relating to patient demographics, treatment history, order details, and results, among others.
"Electronic orders are reviewed by the Wisconsin NBS lab the day they are placed, allowing for any errors to be resolved by the time the specimens are received. We require that ETOR partners include the newborn screen card number (barcoded) with the electronic order. The card number is copied to order segment PID.18 (visit number) where it functions as an alternative requisition identifier (providing receiving staff with a 'link' to the electronic order)."
Wisconsin Newborn Screening Program; State Case Study #5
It may be necessary to revise the scope of the project based on the level of effort involved in modifying and integrating the laboratory’s technical architecture. Therefore, the project manager should meet with IT subject matter experts who are familiar with the lab environment early in the project planning phase. The IT personnel should be familiar enough with the data entry process in a hospital or lab setting to identify the technical solution that the implementation project will use to process and parse an incoming message.
The level of effort needed for implementing these changes will vary greatly depending on whether or not the laboratory has an existing messaging infrastructure. The team may be able to re-use an existing infrastructure with little or no modification. However, if this is the laboratory’s first messaging project, the technical development can take months to complete. Additionally, the contractual or staffing resources within the laboratory may require that a vendor or other third party complete the changes to the LIMS or other software applications; the schedule of these entities may also impact the timing of the development.
Gather Technical Documentation
The project team should assemble the available internal documentation that will allow them to fully understand the current technical architecture within the organization, initiate a gap analysis, and design an appropriate technical solution. The technical architecture is the set of systems and associated people and processes that will enable the current workflow to process NBS orders and generate and send results. Typically, this is a combination of automated and manual processes that span multiple systems or applications, including order entry applications, the LIMS, and systems involved in message transport, among others.
Artifacts that may be useful as the project team designs a technical solution include:
- The NBS collection device(s) or cards that the hospital uses to collect patient information and submit blood samples for testing.
- Current test result report format (may be PDF or digital).
- The Laboratory Orders Interface (LOI) message specification that the hospital will use to send the NBS order to the laboratory.
- The Laboratory Results Interface (LRI) message specification that the laboratory will use to send results to providers.
- An example data extract from the LIMS that the laboratory uses to generate the current test result report.
- Any diagrams, workflows, or other information that the laboratory has outlining or describing the systems which comprise the laboratory’s technical infrastructure and how these systems are integrated.
Design Technical Solution
Once the team has gathered the appropriate documentation, it is time to design the technical solution that the laboratory will use to receive orders and send results. This design will translate the message flow diagram developed earlier in the project initiation and planning phase (Initiate and Plan the Newborn Screening Electronic Health Data Exchange Project) into a model technical architecture. The technical team will also rely on the results of both the gap analysis performed in Section 1B and the Workflow Analysis performed in Section 1D. In addition, the team should plan to review the proposed solution with at least one partner hospital. The success of the design hinges on the ability and willingness of hospital partners to modify their own systems to support the data flow.
The key artifact developed by IT during this task is a holistic architectural diagram of the laboratory systems that will be involved in each step of the message generation and transport (for results) and the message receipt and import (for orders). The design should specify the use of such components as integration engines or data warehouses and explain the intended transport mechanism along with other enterprise services.
The architectural approach taken will vary based on multiple factors. It may be that the laboratory’s technical architecture includes more than one system (e.g., the LIMS and a data broker such as Rhapsody or Mirth, or even custom code) that can perform the necessary functions. There is no one right answer. Some LIMS have native functionality to support terminology mapping and/or HL7 message processing. The availability and type of technical expertise will also impact the architectural decision.
If the LIMS is not maintained by in-house staff, changes can be complex, costly, time-consuming, and subject to the scheduling of external resources. In this case, it may be more efficient for functions such as terminology translation and HL7 segment generation to be accomplished outside of the LIMS with either a broker or custom coding. Similarly, if centralized IT or outside vendors support data brokering, it is important to build a solution architecture that is configurable wherever possible. The appropriate solution will accommodate software and security constraints and will ideally build on the strengths of the laboratory’s technical team. Note that message formats, standard codes, and validation rules change over time and must be maintained. A table-driven approach that minimizes hard-coding in the data broker will allow for easier and less expensive changes to the message.
In general, it is recommended that the laboratory adopt an architectural approach that is modular and loosely coupled. A system that is loosely coupled uses components that do not rely heavily on the design or definition of components in other systems. This allows for a single component to be changed without requiring changes to other components. The goal of such an architectural approach is to insulate the LIMS or other source systems from changes to the message and terminology. See the Sample Architectural Diagram below for a very simple model of an architecture. The diagram should clearly identify the following functions, along with the system performing those functions.
Existing Components of the Technical Architecture
The first factor to consider when designing a technical solution is the existence or absence of a current messaging solution at the laboratory. Most laboratories have developed an infrastructure to support standardized messaging of reportable conditions such as Electronic Laboratory Report (ELR) or Laboratory Response Network (LRN) standardized messaging. To the extent possible, the existing messaging infrastructure should be leveraged for NBS messaging.
Laboratories may encounter challenges in several areas when trying to repurpose the existing infrastructure:
- Many laboratories can send result messages from the LIMS, but NBS orders require that the LIMS can receive order messages.
- Incoming messages present additional security challenges for the technical staff as most IT departments are reluctant to create a hole in their firewall and open themselves up to cyber attacks.
- Many laboratories use a different LIMS for NBS than they do for other testing. Thus, the NBS team may not be able to leverage the model for data extraction and HL7 mapping from existing messaging projects.
- While the laboratory’s existing technical architecture and messaging capabilities will inform the technical solution that is designed, keep in mind that it may be necessary for the technical team to develop new components as part of the overall solution.
Standard Terminology Mapping, Translation and Maintenance
Local codes and terms that are stored in the LIMS will need to be translated to standard codes as identified in the HL7 Implementation Guide. The technical design should account for where and how within the laboratory’s architecture this translation will be accomplished.
Data Import / Extract from Source System(s)
The technical solution should indicate how the data contained in the order message will be imported into the LIMS (or other systems) and how the data needed to create the result message will be exported out of the LIMS (or other systems). The approach will depend on native LIMS functionality and the technical expertise available.
Transformation of Source System Data Elements
The data extract must be transformed into a structured HL7 message. Similarly, the incoming message must be transformed into a format that the LIMS can consume. In most cases, this transformation is accomplished with some type of data broker or integration engine, such as Rhapsody or Mirth.
Secure Transport / Receipt of Messages
The effective exchange of HL7 messages necessitates a bi-directional and secure messaging platform that can provide a common approach to security requirements (such as encryption and authentication), as well as a standard method for addressing and routing content. Such exchanges also require auditing capability and a consistent way to send and receive data exchange confirmations.
The transport mechanism that the laboratory chooses to send the order and result messages between the laboratory and the hospital will depend on the internal security requirements of both messaging partners. The NBS messaging team should work with the laboratory’s internal technical team and clinical partners to determine the best method. Many hospitals prefer to set up a virtual private network (VPN). Other options for transport include CDC’s Public Health Information Network Messaging System (PHINMS), Secure File Transfer Protocol (FTP), Direct, or the use of a messaging hub such as a state HIE or APHL’s Informatics Messaging Services (AIMS) platform. It would be easier for the laboratory to maintain a single transport mechanism for all NBS messaging, but the capabilities of messaging partners may necessitate the implementation of more than one type of data exchange.
Data that will be included in the NBS messages will include patient identifiable information. Because this information is protected, data security is a high priority. The Health Insurance Portability and Accountability Act of 1996 (HIPAA) and other legislative rules have exemptions for disclosures for public health activities and purposes when that disclosure is to a public health authority, foreign government acting with a public health authority, or a person exposed or at risk of contracting or spreading a disease. The project team will need to consider HIPAA regulations as well as state privacy laws and regulations when designing the technical solution. Care should be taken specifically during the validation phases to ensure that no personally identifiable information is shared with unauthorized personnel or through a non-secure manner such as e-mail.
 2Standards for Privacy of Individually Identifiable Health Information: Implications for Public Health Practice, March 2000, http://www.cdc.gov/cic/documents/publichealthprivacy.ppt, April 15, 2004
Implementation of electronic laboratory orders and results will lead to significant workflow changes for the laboratory. Laboratory staff should expect changes to their job functions, responsibilities and knowledgebase to accommodate the modifications needed to support electronic messaging. Workload may decrease for a member of the data entry staff but increase for a LIMS administrator. The project team should be aware of the stress caused by these changes and engage with staff early and frequently to address concerns and provide solutions. The Tools Reference Guide in Section 5 provides information about Change Management Tools that the laboratory can use to ease this transition.
Document Existing Workflow
The first stage in workflow modification is to document the existing workflow and the changes that will need to take place to accommodate the electronic messages. In the long run, electronic messaging will replace manual processes for the majority of samples received, but laboratories should expect to continue to support both workflows to process any samples not submitted electronically (as well as a COntinuity of OPerations [COOP] process). Workflow analyses can be very complex, but at the heart of it is the mapping of a sample’s journey through the laboratory. All areas will need to be considered when planning for the new process, including the laboratory workflow itself, the LIMS process, and the physical requirements. The current process is the “as-is” workflow and should demonstrate the physical process of receiving and testing a sample, as well as the staff who interact with a sample and the points at which there are interactions with the LIMS. The project team should take particular note of the processes of receiving specimens, performing demographic entry and reporting result since these will be the areas most impacted by a move to electronic messaging. The project team may want to shadow a member of the receiving, data entry, or reporting teams to be sure the entire scope of jobs duties performed is understood. See the Tools Reference Guide for Workflow Assessment Tools.
Note: Workflow analyses may highlight other areas of the laboratory that may gain efficiencies with changes to workflow, even if these areas are not directly affected by a move to electronic messaging.
"In the typical workflow, the lab creates shell requisitions in the LIMS, and the specimens are accessioned simultaneously in bulk. Conversely, in the ETOR workflow, the electronic orders create requisitions, and the specimens are subsequently accessioned individually once they are received."
Wisconsin Newborn Screening Program; State Case Study #4
Once the "as-is" process is well understood and documented, the project team should then produce the "to-be" workflow diagrams, imagining what changes will come from implementation of electronic messaging. It is important to note that receiving an electronic message essentially moves the data entry process from the laboratory to the submitter. But, new processes for marrying the physical specimen and the electronic order will be required. The project team should plan how that transition will affect accessioning the sample.
Questions the team might want to investigate at this point include:
- How will the laboratory identify the sample when it arrives? What identifiers will the laboratory use to link the sample with the electronic order?
- What pieces of data must the card include for the laboratory to accept it for testing?
- At what stage in the process will remote data import into the LIMS occur?
- What are the requirements for validating the electronic order imported matches the physical card?
- What are the requirements for acceptance of labels?
- How will discrepancies between the physical form data and electronic data be handled and by whom?
- Who will receive the cards? Will the same staff continue to perform this task after the transition to electronic messaging?
- Where will the receiving process take place? Is hardware available in the physical location needed to support the electronic message? For example, if a sample arrives with a barcode to identify it, are barcode readers available to the accessioning staff?
The project team should ask similar questions about the electronic reporting steps:
- What process changes (if any) are needed to generate electronic results from the LIMS?
- Does laboratory staff use a paper report for review purposes? If so, the workflow will need to provide another option for them to complete their review.
- How will the laboratory handle additional copies of a report?
- Will the laboratory send the report electronically to all recipients, or will the laboratory still need to generate a paper report in some instances?
During this analysis, the project team can document any business decisions that have been or need to be made regarding the sending and receiving of electronic orders. As the questions listed above are answered, these should be documented for future project needs. The Workflow Assessment Tools in Section 5 provide examples of the type of business decision documentation that the laboratory should assemble.
Like the “as-is” workflow, the “to-be” workflow should document who will be responsible for the workflow steps, as well as any interactions with the LIMS. These modifications to the sample processing workflow should drive the changes to the LIMS. Both receiving electronic test orders and sending electronic results messages require the use of the LIMS, and it is vital that the LIMS can support the sending and receiving of messages, both from a technical and usability standpoint. The base ability of a LIMS can vary widely, so LIMS modifications needed to support electronic messaging can also vary. To determine the changes needed (if any), a thorough analysis of the current state of the LIMS should be completed. Note that APHL has developed an APHL Informatics Self-Assessment Toolkit that the laboratory can use to assist in this analysis.
First, the project team should evaluate whether the current state of the LIMS can support the “to-be” workflow as documented. The team should document any clear development that will need to be done to support the new workflow. Examples of these types of enhancements can include additional LIMS modules for displaying electronic orders received or the ability to scan the samples received to log them into the LIMS. If multiple programs within the laboratory use the same LIMS, the project team may be able to reuse components and workflows from a program that has already implemented electronic test orders and results. Consolidating workflows will improve cross training, supportability, and data structure within the LIMS.During the evaluation of the “to-be” workflow and the LIMS, it may be helpful to evaluate whether the laboratory has the hardware needed to support this new LIMS use case. The team should document additional reliance on printers, barcode scanners, and workstations. It may be necessary to purchase or rearrange hardware to accommodate the new physical workflow.
Next, the project team should look at the components of the message itself to ensure all aspects are captured by the LIMS. Importantly, while workflow analysis can begin before the tasks described in Define the Newborn Screening Electronic Data Exchange Message are complete, the team will need to compare the message developed in Define the Newborn Screening Electronic Data Exchange Message to fully assess the LIMS changes required. Therefore, the tasks in Define the Newborn Screening Electronic Data Exchange Message and Identify a Health Data Exchange Technical Solution must be completed in concert. The NBS program may require the message and the LIMS to capture additional data fields. The LIMS may also need the tables needed to maintain the standard code sets identified in Define the Newborn Screening Electronic Data Exchange Message. To send a results message that will report the results of multiple testing conditions, the LIMS will need capture results of different conditions in a similar manner and have all the necessary flags and triggers built in to alert the report recipient of a critical or abnormal value.
During this LIMS evaluation, it is important to document any interactions the LIMS may have with other laboratory systems. Billing, inventory, and other systems may all be affected by LIMS changes. The project team will need to identify any changes needed in these other systems and add these updates to the project plan.
The considerations identified in this chapter do not represent a comprehensive list of the changes that will need to be addressed during a laboratory process or LIMS workflow change. Rather, the project team should use this list as a starting point for documenting the changes that will be needed in a specific laboratory scenario. As noted in the summary table above and described in the Tools Reference Guide, several tools exist for assisting laboratories with assessing workflow.
Once the LIMS changes have been identified, the project team must plan and prioritize these changes. If a LIMS vendor needs to make these changes, the team should engage with them early to assist with requirements gathering and scheduling changes. In some cases, a LIMS vendor will require specific documentation on the required change – often referred to as a Software Specification document (SSD). The team should ask for examples of these documents from the vendor so that they can be sure all the necessary information is included. The project manager will need to work out the details of cost, schedule, and contract with the vendor. The same considerations should be taken into account if the changes will be completed by internal staff. Whether a vendor is contracted, or an internal staff is responsible for the changes, these partners will have competing priorities that will need to be considered in the overall project timeline.
Scheduling the LIMS changes is a vital part of the overall project and should consider the overall project timeline. For example, if implementation of results messaging occurs before receiving orders, prioritize these changes first. The schedule must accommodate the testing and the training of the system users. Before the system is production ready, the LIMS standard operating procedures must be updated and distributed according to the internal laboratory requirements. All of these tasks need to be taken into account in the overall project timeline and budget.
Integration engines or data brokers such as Rhapsody or Mirth provide the capability to automate many steps in the messaging process. Integration engines can be used to map elements from an extract file to the appropriate HL7 segments and fields. Additionally, they can provide automated mapping of local codes to the standard terminology codes required by the implementation guide. Finally, an integration engine can also automate the message workflow by adding the message to the transport queue.
During this task, the technical team will develop the integration engine functionality as defined in the technical solution to ensure that the laboratory systems are prepared to send and receive NBS messages. In addition, the team will populate the tables and develop the mapper filters to generate a valid electronic message as defined by the chosen implementation guide and applicable business rules.
Message Lifecycle Example
In what follows, we describe a message lifecycle for a data exchange that uses Rhapsody as its integration engine. This example is intended as illustrative. The laboratory can accomplish the same objectives using any available integration engine. A typical Message Lifecycle generally includes the following:
- The LIMS outputs an object (row in database or extract file) with fields ready to be mapped to a HL7 message.
- Rhapsody consumes the data as either an XML message defined by an xsd or a delimited file defined by a Symphonia EDI Parser control file (s3d).
- A mapper consumes the XML or delimited file and generates a HL7 message, in accordance with the implementation guide and based on the mapping lookup tables.
- Rhapsody translates local codes to standard codes as defined in the implementation guides.
- The Rhapsody route adds certain properties to the message, including:
- Message type (for mapping to condition)
- Message identifier
- PHINMS information
- Message status (errored or valid)
- The transformed HL7 message is queued to a sending application:
- TransportQ_out table via database filter or communication point to be sent by the PHINMS client
- Output directory via directory communication point that is polled by a sending application
- A transport service sends the message securely to the receiver.
The successful processing of order and result messages is dependent on conformance to the implementation profile. The laboratory will need to conduct extensive testing with data exchange partners to ensure that the message reliably transmits the correct information, and that internal validation tools identify and respond to message errors as expected. Upon completion of this chapter, the project team will have:
- Defined the testing needed to ensure the electronic data exchange supports the laboratory’s needs.
- Developed a testing plan for the laboratory and its messaging partners to follow.
- Completed unit and functional testing of message validation.
- Planned to engage with hospitals for integration testing.
Test Planning and Performance
A test plan is a comprehensive document or set of documents that lays out how system updates will be tested. Each phase of testing should have an individual or team responsible for its satisfactory completion. Test plans are designed to make sure the production system will be useful and accommodate testing scenarios. See the Tools Reference Guide for sample Test Plan components.
The test plan should include several categories of testing:
Unit and Functional Testing
Project staff should complete unit and functional testing internally before any other partners are engaged in the testing. This stage of testing will assess the major functional changes and developments made to meet the requirements of the implementation guide. Comparison to the paper report or submission card provides a baseline for expectations of what data should appear in the results message and order message.
Even before partners are fully engaged in the project, the laboratory should simulate and test its ability to receive an order message. The LIMS should be capable of loading an order message that meets the specifications in the implementation guide. The HL7 SME will need to assess each field to make sure it is populating in the correct place in the LIMS. This review can be a difficult task and requires a significant amount of patience and attention to detail, but it is an essential part of validating the incoming message.
In planning for this testing, the project team should consider the test cases they will need to perform. Examples of test cases may include a repeat test card, a collection card that is unsatisfactory, and cards that are linked to previous cards. Identification and testing of these scenarios is important for creating a workable electronic messaging system.
Once the team has completed updates to the LIMS and message broker, they should evaluate the HL7 messages produced for its adherence to the guide specifications. In this testing phase, the team should identify scenarios that represent certain testing outcomes, such as critical, abnormal and normal values, rejections and unsatisfactory results. The test cases should assess each scenario to ensure that the correct report values, alert flags, and triggers appear in the message. Like the testing performed for the consumption of the order message, this testing will be time-consuming and highly detailed. The testers should expect to have to revisit the development stages as issues are noted and retest the messages multiple times to identify all issues. The Tools Reference Guide provides evaluation and issues tracking tools (i.e., the Message Validation Template and the Message Validation Feedback Template) that may help the laboratory accomplish these tasks.
System and Integration Testing
System testing ensures data is properly sent and received between systems. The laboratory will need to develop a plan that tests the integration between its systems and those of its relevant messaging partners, including hospitals and health departments. If the LIMS interacts with any other laboratory systems, such as a billing system, inventory system, or others, the laboratory should also plan to test these integrations during system testing. Internal system testing can and should be performed before the partners are engaged so that when partner agencies are ready to test, the laboratory is confident that the internal process will be stable.
During system and integration tests, all the portions of the system(s) are tested together. Common and unusual scenarios should be identified and tested; some testers may think of this as a time to try to "break" the system. The team should review areas of concern or previous corrective action from paper reporting process during this time to make sure the electronic system will support these scenarios. Again, the project team should be prepared to revisit development efforts as issues are identified and retest once corrected.
Once system testing is complete and acceptable, the project team should engage with partners to perform parallel testing. Parallel testing involves running both paper and electronic data processes. The team should compare these data and note and correct any discrepancies as needed. The lab should request screen shots of the hospital systems at order entry and at results receipt to ensure the data in the message is accurate in comparison to the hospital system. Generally, the team should not have to revisit any development efforts at this stage, since system testing should have identified most development issues. The laboratory usually performs parallel testing for a certain period of time until all parties are comfortable that the electronic system can fully replace the manual process.
Performance and Stress Testing
The laboratory should perform stress testing to verify that the system integration has the capacity to support the volume of testing required. This testing should simulate the peak volume of users and samples in the system at one time. Any degradation of system function or response should be noted and reported to the infrastructure team members to evaluate and correct.
Resource and Expertise
The test plan should identify responsible testers for each testing phase, as well as who will be responsible for approving the system for production. The development team should also be engaged at this phase since they will need to address any issues found during testing. The plan should also document how issues will be reported and the process for revisiting development so testers have a clear path for resolving issues.
While planning for testing, the project team should engage closely with the laboratory quality assurance (QA) staff. Close consideration should be given to making sure that the testing and associated documentation meet the laboratory’s QA and accreditation requirements.