|
|
| (32 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| Chapter 2 also looked at deployment approaches in detail, so this section won't get too in-depth. However, the topic of choosing the right deployment approach for your laboratory is still an important one. As Agilent Technologies noted in its 2019 white paper ''Cloud Adoption for Lab Informatics'', a laboratory's "deployment approach is a key factor for laboratory leadership since the choice of private, public, or hybrid deployment will impact the viability of solutions in the other layers of informatics" applied by the lab.<ref name="AgilentCloud19" /> In some cases, like most software, the deployment choice will be relatively straightforward, but other aspects of laboratory requirements may complicate that decision further.
| | {{Saved book |
| | |title=Introduction to Quality and Quality Management Systems |
| | |subtitle= |
| | |cover-image=Time-Quality-Money.png |
| | |cover-color=#fffccc |
| | | setting-papersize = A4 |
| | | setting-showtoc = 1 |
| | | setting-columns = 1 |
| | }} |
|
| |
|
| Broadly speaking, any attempt to move you LIS, LIMS, or [[electronic laboratory notebook]] (ELN) to the cloud will almost certainly involve a [[software as a service]] (SaaS) approach.<ref name="AgilentCloud19" /> If the deployment is relatively simple, with well-structured data, this is relatively painless. However, in cases where your LIS, LIMS, or ELN need to interface with additional business systems like an [[enterprise resource planning]] (ERP) system or other informatics software such as a [[picture archiving and communication system]] (PACS), an argument could be made that a [[platform as a service]] (PaaS) approach may be warranted, due to its greater flexibility.<ref name="AgilentCloud19" />
| | ==''Introduction to Quality and Quality Management Systems''== |
| | {{ombox |
| | | type = content |
| | | style = width: 500px; |
| | | text = This book should not be considered complete until this message box has been removed. This is a work in progress. |
| | }} |
| | The goal of this short volume is to act as an introduction to the quality management system. It collects several articles related to quality, quality management, and associated systems. |
|
| |
|
| But laboratories don't run on software alone; analytical instruments are also involved. Those instruments are usually interfaced to the lab's software systems to better capture raw and modified instrument data directly. However, addressing how your cloud-based informatics systems handle instrument data can be challenging, requiring careful attention to cloud service and deployment models. [[Infrastructure as a service]] (IaaS) may be a useful service model to look into due to its versatility in being deployed in private, hybrid, and public cloud models.<ref name="AgilentCloud19" /> As Agilent notes: "This model enables laboratories to minimize the IT footprint in the lab to only the resources needed for instrument control and acquisition. The rest of the data system components can be virtualized in the cloud and thus take advantage of the dynamic scaling and accessibility aspects of the cloud."<ref name="AgilentCloud19" /> It also has easy scalability, enables remote access, and simplifies disaster recovery.<ref name="AgilentCloud19" />
| | ;1. What is quality? |
| | :''Key terms'' |
| | :[[Quality (business)|Quality]] |
| | :[[Quality assurance]] |
| | :[[Quality control]] |
| | :''The rest'' |
| | :[[Data quality]] |
| | :[[Information quality]] |
| | :[[Nonconformity (quality)|Nonconformity]] |
| | :[[Service quality]] |
| | ;2. Processes and improvement |
| | :[[Business process]] |
| | :[[Process capability]] |
| | :[[Risk management]] |
| | :[[Workflow]] |
| | ;3. Mechanisms for quality |
| | :[[Acceptance testing]] |
| | :[[Conformance testing]] |
| | :[[Clinical quality management system]] |
| | :[[Continual improvement process]] |
| | :[[Corrective and preventive action]] |
| | :[[Good manufacturing practice]] |
| | :[[Malcolm Baldrige National Quality Improvement Act of 1987]] |
| | :[[Quality management]] |
| | :[[Quality management system]] |
| | :[[Total quality management]] |
| | ;4. Quality standards |
| | :[[ISO 9000]] |
| | :[[ISO 13485]] |
| | :[[ISO 14000|ISO 14001]] |
| | :[[ISO 15189]] |
| | :[[ISO/IEC 17025]] |
| | :[[ISO/TS 16949]] |
| | ;5. Quality in software |
| | :[[Software quality]] |
| | :[[Software quality assurance]] |
| | :[[Software quality management]] |
|
| |
|
| Notice that Agilent still allows for the in-house IT resources necessary to handle the control of instruments and the acquisition of their data. This brings up an important point about instruments. When it comes to instruments, realistic decisions must be made concerning whether or not to take instrument data collection and management into the cloud, keep it local, or enact a hybrid workflow where instrument data is created locally but uploaded to the cloud later.<ref name="VyasCloud20">{{cite web |url=https://planetinnovation.com/perspectives/cloud-vs-on-premises-solutions/ |title=Cloud vs. on-premises solutions – 5 factors to consider when planning the connectivity strategy for your healthcare instrument |author=Vyas, K. |work=Planet Innovation: Perspectives |date=September 2020 |accessdate=21 August 2021}}</ref> In 2017, the Association of Public Health Laboratories (APHL) emphasized latency issues as a real concern when it comes to instrument control computing systems, finding that most shouldn't be in the cloud. The APHL went on to add that those systems can, however, "be designed to share data in network storage systems and/or be integrated with cloud-based LIMS through various communication paths."<ref name="APHLBreaking17" />
| | <!--Place all category tags here--> |
| | |
| So what should a laboratory do with instrument systems? PI Digital's general manager, Kaushal Vyas, recognized the difficulties in deciding what to do with instrument systems in September 2020, breaking the decision down into five key considerations. First, consider the potential futures for your laboratory instruments and how any developing industry trends may affect those instruments. Do you envision your instruments becoming less wired? Will mobile devices be able to interface with them? Are they integrated via a hub? And does a cloud-based solution that manages those integrations across multiple locations make sense at some future point? Second, talk to the people who actually use the instruments and understand the workflows those instruments participate in. Are analysts loading samples directly into the machine and largely getting results from the same location? Or will results need to be accessed from different locations? In the case of the latter, cloud management of instrument data may make more sense. Third, are there additional ways to digitize your workflows in the lab? Perhaps later down the road? Does enabling from-anywhere access to instruments with the help of the cloud make sense for the lab? This leads to the fourth consideration, which actually touches upon the prior three: location, location, location. Where are the instruments located and from where will results, maintenance logs, and error logs be read? If these tasks don't need to be completed in real time, it's possible some hybrid cloud solution would work for you. And finally—as has been emphasized throughout the guide—ask what regulations and security requirements drive instrument deployment and use. In highly regulated environments like pharmaceutical research and production, moving instrument data off-premises may not be an option.<ref name="VyasCloud20" />
| |
| | |
| One additional consideration that hasn't been fully discussed yet is whether or not to go beyond a hybrid cloud—depending on one single cloud vender to integrate with on-premises systems—to a cloud approach that involves more than one cloud vendor. We examine this consideration, as well as how it related to vendor lock-in, in the following subsection.
| |
| | |
| ==References==
| |
| {{Reflist|colwidth=30em}}
| |
