Difference between revisions of "User:Shawndouglas/sandbox/sublevel4"
Shawndouglas (talk | contribs) |
Shawndouglas (talk | contribs) |
||
| Line 1: | Line 1: | ||
[[File:Loading a centrifuge with samples to separate components of the extraction process. (48788935101).jpg|right| | [[File:Loading a centrifuge with samples to separate components of the extraction process. (48788935101).jpg|right|350px]]Effective implementation and use of a LIMS in the laboratory is partially a function of understanding both the processes of the lab and the capabilities and functions of a LIMS. When neither is fully understood, LIMS implementations tend to falter. This means that accurate feedback of end users of a current or potential clinical informatics solution is incredibly useful. | ||
This process usually begins with end users describing their workflows and how they imagine a LIMS would benefit it. They may not initially understand how the LIMS can assist them with what they need done — for example, sending an automated message to whoever is in charge of results approval post-analysis — but they should be able to at least articulate their needs. Feedback solicited, the lab’s PM can then attempt to match up the requirements feedback with a formal requirements document. They may turn to an existing medical diagnostics and research specification like [[LII:Laboratory Informatics Buyer's Guide for Medical Diagnostics and Research/Blank LIMSpec template for medical diagnostics and research labs|LIMSpec]], which includes a comprehensive set of requirements most clinical labs may have. Requirements that the LIMS support standardized clinical terminology, application programming interfaces (APIs) for instruments, alerts for out-of-specification test results and much more can be found in LIMSpec. Once requirements have been compiled into a “wish list” and compared to a formal specification document like LIMSpec, the PM also has the chance to discover other requirements in the specification that end users may have missed. | This process usually begins with end users describing their workflows and how they imagine a LIMS would benefit it. They may not initially understand how the LIMS can assist them with what they need done — for example, sending an automated message to whoever is in charge of results approval post-analysis — but they should be able to at least articulate their needs. Feedback solicited, the lab’s PM can then attempt to match up the requirements feedback with a formal requirements document. They may turn to an existing medical diagnostics and research specification like [[LII:Laboratory Informatics Buyer's Guide for Medical Diagnostics and Research/Blank LIMSpec template for medical diagnostics and research labs|LIMSpec]], which includes a comprehensive set of requirements most clinical labs may have. Requirements that the LIMS support standardized clinical terminology, application programming interfaces (APIs) for instruments, alerts for out-of-specification test results and much more can be found in LIMSpec. Once requirements have been compiled into a “wish list” and compared to a formal specification document like LIMSpec, the PM also has the chance to discover other requirements in the specification that end users may have missed. | ||
Revision as of 17:18, 10 March 2022
.jpg)
Effective implementation and use of a LIMS in the laboratory is partially a function of understanding both the processes of the lab and the capabilities and functions of a LIMS. When neither is fully understood, LIMS implementations tend to falter. This means that accurate feedback of end users of a current or potential clinical informatics solution is incredibly useful.
This process usually begins with end users describing their workflows and how they imagine a LIMS would benefit it. They may not initially understand how the LIMS can assist them with what they need done — for example, sending an automated message to whoever is in charge of results approval post-analysis — but they should be able to at least articulate their needs. Feedback solicited, the lab’s PM can then attempt to match up the requirements feedback with a formal requirements document. They may turn to an existing medical diagnostics and research specification like LIMSpec, which includes a comprehensive set of requirements most clinical labs may have. Requirements that the LIMS support standardized clinical terminology, application programming interfaces (APIs) for instruments, alerts for out-of-specification test results and much more can be found in LIMSpec. Once requirements have been compiled into a “wish list” and compared to a formal specification document like LIMSpec, the PM also has the chance to discover other requirements in the specification that end users may have missed.
The lab should, however, be careful about overwhelming vendors with their specification-driven wish list early on. Before approaching vendors, it’s advisable to narrow down the full specification to the most critical requirements for you lab. You can then initiate dialog with one or more vendors based on those must-have requirements. Once the vendor pool is narrowed down to one or two vendors, you can then go through several demos of the software with the vendor. This gives your lab a clearer idea of what their LIMS can do, and you can match their functionality to your full specification document. From there, you can then send the full specification document to the vendor and ask them how they address all your lab’s needs.
In the end, this careful internal research on requirements paired with feedback from LIMS vendors experienced in implementing clinical diagnostics solutions for clients provides greater clarity of what is required of a LIMS and how it will actually benefit the lab.
