View source for Laboratory Informatics Buyer's Guide for Medical Diagnostics and Research/Choosing laboratory informatics software for your lab/Implementation

===2.2 Implementation===
If you've ever worked through a system implementation process with a vendor, it was hopefully a smooth process. However, there are plenty of horror stories out there, highlighting the need of the laboratory to discuss in detail how a potential vendor will handle installation, validation, and training for the informatics solution. Does the vendor truly understand the industry and your needs? Does the vendor assign a project manager who will work with you, from planning to go-live and beyond? Can they offer you references of other labs who have gone through implementation so you can compare notes with those labs? How much attention does the potential vendor give to related issues such as data integrity of migrated data? Do they have the means to properly handle your legacy data? And are they able to work with your schedule, even if it means implementing software at off-peak work hours?<ref name="Wagner7Soft19">{{cite web |url=https://blog.walkme.com/7-software-implementation-challenges/ |title=7 Software Implementation Challenges and How to Solve Them |author=Wagner, M. |work=WalkMe Blog |publisher=WalkMe Ltd |date=10 October 2019 |accessdate=18 November 2021}}</ref><ref name="MuraBullet18">{{cite web |url=https://blog.userlane.com/software-implementation-plan/ |title=Bullet-Proof Software Implementation Plan: Challenges and Tactics |author=Mura, A. |work=Userlane Digital Adoption Blog |publisher=Userlane GmbH |date=12 July 2018 |accessdate=18 November 2021}}</ref>

As you finally get down to the ultimate decision on which vendor to work with, you may wish to start setting up an implementation checklist as part of your early project planning. Do you receive a help desk account as part of the implementation process, and if so, what information is included? If not, you'll need to keep track of specific details such as business associate agreement (BAA), sales agreement, scope documents, welcome letters, documentation, and approved staff who can utilize the vendor's support. You'll likely need to share other configuration details with the vendor, including time zone requirements, DNS and URL requirements, up-time monitors, and administrative account requirements. Finally, you'll want to ensure you and the vendor are on the same page concerning any additional customization, integration, and system validation requirements, ensuring the roll-out period is pain-free and efficient.

====2.2.1 Internal and external integrations====
[[File:LabMachines.jpg|right|400px]]Laboratories acquire data management software for many reasons, including improving accuracy, saving time, increasing productivity, and adding capabilities. One way of doing all of those activities is to integrate or interface your systems, databases, and instruments so that human error is greatly reduced or eliminated, workflows are automated and sped up, and each component's capabilities are brought into play in the most efficient and effective ways possible. As such, you'll want to inquire with the vendor about its solution's hardware and software integration capabilities. Is it designed to interface with every laboratory instrument or software that can output any readable electronic file? Or are integrations limited to certain instruments and systems? How does it connect, i.e., what protocols does the software depend on to connect with other systems? Does the system allow a user to map their own file imports and exports? Can system processes be set to detect new instances of file outputs at regular intervals? Ask these and other questions to make sure the vendor clearly describes what internal and external integrations are supported with their application.

In many cases, a vendor's solution will have integration capability built into the software, but occasionally such interfaces are separate from the main software. Today's interfaces are generally built on standardized communication tools, including messaging formats like [[Health Level 7]] (HL7).<ref name="Sinard06">{{cite book |url=https://link.springer.com/book/10.1007/0-387-28058-8 |title=Practical pathology informatics: Demystifying informatics for the practicing anatomic pathologist |author=Sinard, J. |publisher=Springer Science+Business Media |year=2006 |isbn=9780387280585}}</ref><ref name="MLOStaffInterfacing12">{{cite web |url=https://www.mlo-online.com/home/article/13004490/interfacing-the-lis |title=Interfacing the LIS |author=MLO Staff |work=Medical Laboratory Observer |publisher=Endeavor Business Media, LLC |date=01 August 2012 |accessdate=18 November 2021}}</ref> The HL7 messaging standards are particularly important to laboratory data management because they define how information is packaged and communicated from one party to another. Such standards set the language, structure, and data types required for seamless integration of various systems and instruments.<ref name="KimCreating05">{{cite web |url=http://www.kathykim.com/sitebuildercontent/sitebuilderfiles/ClinicalDataStandardsInHealthCare.pdf |archiveurl=https://web.archive.org/web/20170114055221/http://www.kathykim.com/sitebuildercontent/sitebuilderfiles/ClinicalDataStandardsInHealthCare.pdf |format=PDF |title=Creating Clinical Data Standards in Health Care: Five Case Studies |author=Kim, Katherine |publisher=California HealthCare Foundation |date=July 2005 |archivedate=14 January 2017 |accessdate=10 January 2020}}</ref> Health Level 7 describes the types of information communicated between such systems in the clinical environment as including "process control and status information for each device or analyzer, [as well as] each specimen, specimen container, and container carrier; information and detailed data related to patients, orders, and results; and information related to specimen flow algorithms and automated decision making."<ref name="HL711">{{cite web |url=http://www.hl7.org/implement/standards/product_brief.cfm?product_id=203 |archiveurl=https://web.archive.org/web/20170711070938/http://www.hl7.org/implement/standards/product_brief.cfm?product_id=203 |title=HL7 version 2.7 standard: Chapter 13 - Clinical laboratory automation |author=Health Level Seven International |date=2011 |archivedate=11 July 2017 |accessdate=18 November 2021}}</ref>

You may also want your laboratory informatics solution to be able to communicate with other software and databases. This is often done using [[application programming interface]]s (APIs) that depend on web services implementation protocols such as REST and SOAP.<ref name="MonusSOAP19">{{cite web |url=https://raygun.com/blog/soap-vs-rest-vs-json/ |title=SOAP vs REST vs JSON comparison [2019] |author=Monus, A. |work=Raygun |date=05 March 2021 |accessdate=18 November 2021}}</ref><ref name="LVAQuick18">{{cite web |url=https://www.labvantage.com/a-quick-guide-to-lims-web-services/ |title=A Quick Guide to LIMS Web Services |author=LabVantage Solutions |publisher=LabVantage Solutions, Inc |date=07 January 2018 |accessdate=18 November 2021}}</ref><ref name="GrandOneTool19">{{cite journal |title=One tool to find them all: A case of data integration and querying in a distributed LIMS platform |journal=Database |author=Grand, A.; Geda, E.; Mignone, A. et al. |volume=2019 |page=baz004 |year=2019 |doi=10.1093/database/baz004}}</ref> These messaging protocols actually allow for the creation of an API that receives communication requests and sends responses between two software systems. A more practical example is wanting your laboratory informatics solution to communicate with an [[enterprise resource planning]] (ERP) application. Perhaps the ERP system needs to create sample batches within the informatics solution, and when testing is done, have the results returned to the ERP. APIs and communication protocols make this happen.<ref name="LVAQuick18" />