Difference between revisions of "User:Shawndouglas/sandbox/sublevel1"

From LIMSWiki
Jump to navigationJump to search
Line 1: Line 1:
Without a doubt, it's vital that medical diagnostic and research laboratories operate within the bounds of a regulatory atmosphere, not only to better ensure the best patient outcomes but also to ensure the quality of test results, the privacy of patient information, and the safety of personnel. Maintaining regulatory compliance requires deliberate approaches to developing and enforcing processes and procedures, quality training, consistent communication, and knowledgeable personnel. It also requires a top-down appreciation and commitment to a culture of quality. From the [[Clinical Laboratory Improvement Amendments]] (CLIA) and [[Health Insurance Portability and Accountability Act]] (HIPAA) to [[21 CFR Part 11]] and the [[General Data Protection Regulation]], laboratories have much to consider in regards to what regulations impact them.
Before selecting a solution, your laboratory should also have internal discussions about how diversified its offered services are, as well as what the future may bring to the lab. If, for example, your lab is currently configured for toxicology testing, does your existing laboratory informatics system—or the ones you may be considering—have the flexibility to add other types of clinical testing, protocols, and workflows? Will you be doing the footwork to add them, or will the vendor of your system support you in that effort? If you're a start-up, will your lab be focusing solely on a specific type of clinical testing and expand into other markets later, or will your test menu need to be much broader right from the start? In most of these cases, you'll desire a LIMS that is flexible enough to allow for not only running the specific tests you need now, but also sufficiently expandable for any future testing services your lab may conduct in the mid- and long-term. Having the ability to create and customize [[Sample (material)|specimen]] registration screens, test protocols, labels, reports, specification limit sets, measurement units, and substrates/matrices while being able to interface with practically most any instrument and software system required will go a long way towards making your expanding test menu and workflows integrates as smoothly as possible.


That said, consider approaching the question of regulatory compliance from the standpoint of adopting standards. Consider first that the risks and consequences of performing a task poorly drives regulation and, more preferably<ref name="CiocoiuTheRole10">{{cite book |chapter=Chapter 1. The Role of Standardization in Improving the Effectiveness of Integrated Risk Management |title=Advances in Risk Management |author=Ciocoui, C.N.; Dobrea, R.C. |editor=Nota, G. |publisher=IntechOpen |year=2010 |isbn=9789535159469 |doi=10.5772/9893}}</ref><ref name="JPMorganData18">{{cite web |url=https://www.jpmorganchase.com/content/dam/jpmc/jpmorgan-chase-and-co/documents/call-to-action.pdf |format=PDF |title=Data Standardization: A Call to Action |publisher=JPMorgan Chase & Co |date=May 2018 |accessdate=18 November 2021}}</ref>, standardization, which in turn moves the "goalposts" of quality and security among organizations. In the case of regulations, those organization that get caught not conforming to the necessary regulations tend to suffer negative consequences, providing some incentive for them to improve organizational processes and procedures.  
Such a system will typically be marketed as being highly user-configurable, giving labs a relatively painless means to adapt to rapid changes in test volume and type over time. However, once you've internally addressed current and anticipated future growth, your lab will want to learn what explicitly makes any given vendor's system user-configurable. How easy is it to configure the system to new tests? Add custom reports? What knowledge or skills will be required of your lab in order to make the necessary changes, i.e., will your staff require programming skills, or are the administrator and advanced user functions robust enough to make changes without hard-coding? These and other such questions should be fully addressed by the vendor in order to set your mind at ease towards a system's stated flexibility. Ultimately, you want the system to be flexible enough to change with the laboratory itself, while minimizing overall costs and reducing the time required to make any necessary modifications.
 
One of the downsides of regulations is that they can at times be "imprecise" or "disconnected"<ref name="JPMorganData18" /> from what actually occurs within the organization and its information systems. Rather than focusing heavily on regulatory conformance, well-designed standards may, when adopted, provide a clearer path of opportunity for organizations to improve their operational culture and outcomes, particularly since standards are usually developed with a broader consensus of interested individuals with expertise in a given field.<ref name="CiocoiuTheRole10" /> In turn, the organizations that adopt well-designed standards likely have a better chance of conforming to the regulations they must, and they'll likely have more interest in maintaining and improving the goalposts of quality and security in the lab.
 
Additionally, reputable software developers of laboratory informatics software will not only adopt their own industry standards for software development but also understand the standards and regulations that affect laboratories and research centers. In turn, the developed software should meet regulations and standards, help the laboratory comply with its regulations and standards, and be of reliably good quality.
 
If you're a potential buyer of a laboratory informatics solution, it may be that you know a bit about your laboratory's workflow and a few of the regulations and standards that influence how that workflow is conducted, but you're not entirely informed about all the regulations and standards that affect your lab. Turning to a URS such as LIMSpec—which was developed around laboratory regulations and standards—and reviewing the various statements contained within may be necessary to help further inform you. Additionally, as you investigate various informatics options, you can then use the requirements in the URS as a base for your laboratory's own requirements list. Using the categories and their subdivisions, you can then add those requirements that are unique to your laboratory and industry that are not sufficiently covered by the base URS. As you review the various options available to you and narrow down your search, your own list of requirements can be used as both as a personal checklist and as a requirements list you hand over to the vendor you query. And since your URS is based off the standards and regulations affecting your lab, you can feel more confident in your acquisition and its integration into your laboratory workflow.
 
==References==
{{Reflist}}

Revision as of 23:50, 21 January 2022

Before selecting a solution, your laboratory should also have internal discussions about how diversified its offered services are, as well as what the future may bring to the lab. If, for example, your lab is currently configured for toxicology testing, does your existing laboratory informatics system—or the ones you may be considering—have the flexibility to add other types of clinical testing, protocols, and workflows? Will you be doing the footwork to add them, or will the vendor of your system support you in that effort? If you're a start-up, will your lab be focusing solely on a specific type of clinical testing and expand into other markets later, or will your test menu need to be much broader right from the start? In most of these cases, you'll desire a LIMS that is flexible enough to allow for not only running the specific tests you need now, but also sufficiently expandable for any future testing services your lab may conduct in the mid- and long-term. Having the ability to create and customize specimen registration screens, test protocols, labels, reports, specification limit sets, measurement units, and substrates/matrices while being able to interface with practically most any instrument and software system required will go a long way towards making your expanding test menu and workflows integrates as smoothly as possible.

Such a system will typically be marketed as being highly user-configurable, giving labs a relatively painless means to adapt to rapid changes in test volume and type over time. However, once you've internally addressed current and anticipated future growth, your lab will want to learn what explicitly makes any given vendor's system user-configurable. How easy is it to configure the system to new tests? Add custom reports? What knowledge or skills will be required of your lab in order to make the necessary changes, i.e., will your staff require programming skills, or are the administrator and advanced user functions robust enough to make changes without hard-coding? These and other such questions should be fully addressed by the vendor in order to set your mind at ease towards a system's stated flexibility. Ultimately, you want the system to be flexible enough to change with the laboratory itself, while minimizing overall costs and reducing the time required to make any necessary modifications.

Retrieved from "https://www.limswiki.org/index.php?title=User:Shawndouglas/sandbox/sublevel1&oldid=45916"