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

From LIMSWiki
Jump to navigationJump to search
Line 14: Line 14:
A laboratory can integrate cybersecurity thinking into its laboratory informatics product selection in several ways. First, the lab should have a cybersecurity plan in place, or if not, it should be on the radar. This is a good resource to tap into in regards to deciding what cybersecurity considerations should be made for the software. Can the software help your lab meet your cybersecurity goals? What regulatory requirements for your lab are or are not covered by the software? Another tool to consider—which may have been used in any prior cybersecurity planning efforts—is a cybersecurity framework. Many, but not all, cybersecurity frameworks include a catalog of security controls. Each control is "a safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements."<ref name="NISTSecurity19">{{cite web |url=https://csrc.nist.gov/glossary/term/security-control |title=security control |work=Computer Security Resource Center |publisher=National Institute of Standards and Technology |date=2019 |accessdate=10 January 2020}}</ref> These controls give the implementing organization a concrete set of configurable goals to apply to their overall cybersecurity strategy. Other frameworks may be less oriented to security controls and more program-based or risk-based. Choosing the best frameworks will likely depend on multiple factors, including the organization's industry type, the amount of technical expertise within the organization, the budget, the organizational goals, the amount of buy-in from key organizational stakeholders, and those stakeholders' preferred approach.  
A laboratory can integrate cybersecurity thinking into its laboratory informatics product selection in several ways. First, the lab should have a cybersecurity plan in place, or if not, it should be on the radar. This is a good resource to tap into in regards to deciding what cybersecurity considerations should be made for the software. Can the software help your lab meet your cybersecurity goals? What regulatory requirements for your lab are or are not covered by the software? Another tool to consider—which may have been used in any prior cybersecurity planning efforts—is a cybersecurity framework. Many, but not all, cybersecurity frameworks include a catalog of security controls. Each control is "a safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements."<ref name="NISTSecurity19">{{cite web |url=https://csrc.nist.gov/glossary/term/security-control |title=security control |work=Computer Security Resource Center |publisher=National Institute of Standards and Technology |date=2019 |accessdate=10 January 2020}}</ref> These controls give the implementing organization a concrete set of configurable goals to apply to their overall cybersecurity strategy. Other frameworks may be less oriented to security controls and more program-based or risk-based. Choosing the best frameworks will likely depend on multiple factors, including the organization's industry type, the amount of technical expertise within the organization, the budget, the organizational goals, the amount of buy-in from key organizational stakeholders, and those stakeholders' preferred approach.  


Finally, having a cybersecurity plan that incorporates one or more cybersecurity frameworks gives the laboratory ample opportunity to apply stated goals and chosen security controls to the evaluation and selection process. In particular, a user requirements specification (URS) that incorporates cybersecurity considerations will certainly help a laboratory with meeting regulatory requirements while also protecting its data systems. A USR that is pre-built with cybersecurity controls in mind—such as LIMSpec, discussed later—makes the evaluation process even easier.
Finally, having a cybersecurity plan that incorporates one or more cybersecurity frameworks gives the laboratory ample opportunity to apply stated goals and chosen security controls to the evaluation and selection process. In particular, a user requirements specification (URS) that incorporates cybersecurity considerations will certainly help a laboratory with meeting regulatory requirements while also protecting its data systems. A USR that is pre-built with cybersecurity controls in mind—such as [[Book:LIMSpec 2019 R1|LIMSpec]], discussed later—makes the evaluation process even easier.


===2.1.3 Regulatory compliance considerations===
===2.1.3 Regulatory compliance considerations===
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.


Also, 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/corporate/news/document/call-to-action.pdf |format=PDF |title=Data Standardization: A Call to Action |publisher=JPMorgan Chase & Co |date=May 2018 |accessdate=14 December 2019}}</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.  
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/corporate/news/document/call-to-action.pdf |format=PDF |title=Data Standardization: A Call to Action |publisher=JPMorgan Chase & Co |date=May 2018 |accessdate=14 December 2019}}</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.  


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 to 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.
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 to 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.


===2.1.4 Features and functions===
===2.1.4 Features and functions===

Revision as of 18:15, 10 January 2020

Choosing laboratory informatics software for your lab ... Opening text goes here.

2.1 Evaluation and selection

2.1.1 Technology considerations

2.1.2 Cybersecurity considerations

From law firms[1] to automotive manufacturers[2], the need to address cybersecurity is increasingly apparent. In 2018, the Center for Strategic & International Studies estimated that cybercrime causes close to $600 billion in damages to the global economy every year[3], though due to underreporting of crimes, that number may be much higher. That number also likely doesn't take into account lost business, fines, litigation, and intangible losses[4] In the end, businesses of all sizes average about $200,000 in losses due to a cybersecurity incident[5], and nearly 60 percent of small and midsize businesses go bankrupt within six months because of it.[6]

Medical diagnostic and research laboratories are no exception, regardless of business size. Even tiny labs whose primary digital footprint is a WordPress website advertising their lab are at risk, as hackers could still spread malware, steal user data, add the website to a bot network, hack the site for the learning experience, or even hack it just for fun.[7][8][9] Even more importantly are those labs performing digital data management tasks that handle sensitive patient and proprietary data, requiring additional cybersecurity considerations.

A laboratory can integrate cybersecurity thinking into its laboratory informatics product selection in several ways. First, the lab should have a cybersecurity plan in place, or if not, it should be on the radar. This is a good resource to tap into in regards to deciding what cybersecurity considerations should be made for the software. Can the software help your lab meet your cybersecurity goals? What regulatory requirements for your lab are or are not covered by the software? Another tool to consider—which may have been used in any prior cybersecurity planning efforts—is a cybersecurity framework. Many, but not all, cybersecurity frameworks include a catalog of security controls. Each control is "a safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements."[10] These controls give the implementing organization a concrete set of configurable goals to apply to their overall cybersecurity strategy. Other frameworks may be less oriented to security controls and more program-based or risk-based. Choosing the best frameworks will likely depend on multiple factors, including the organization's industry type, the amount of technical expertise within the organization, the budget, the organizational goals, the amount of buy-in from key organizational stakeholders, and those stakeholders' preferred approach.

Finally, having a cybersecurity plan that incorporates one or more cybersecurity frameworks gives the laboratory ample opportunity to apply stated goals and chosen security controls to the evaluation and selection process. In particular, a user requirements specification (URS) that incorporates cybersecurity considerations will certainly help a laboratory with meeting regulatory requirements while also protecting its data systems. A USR that is pre-built with cybersecurity controls in mind—such as LIMSpec, discussed later—makes the evaluation process even easier.

2.1.3 Regulatory compliance considerations

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.

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[11][12], 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.

One of the downsides of regulations is that they can at times be "imprecise" or "disconnected"[12] from what actually occurs within the organization and its information systems. Rather than focusing heavily to 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.[11] 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.

2.1.4 Features and functions

2.1.5 Contract considerations (maintenance, support, warranty, and enhancements)

2.1.6 Cost considerations

2.2 Implementation

2.2.1 Internal and external integrations

2.3 Maintenance and updates

2.4 How a user requirements specification fits into the entire process

Merriam-Webster defines a "specification" as "a detailed precise presentation of something or of a plan or proposal for something."[13] In other words, an existing or theoretical product, concept, or idea is presented in detail for a particular audience. In a broad sense, detailing the specifics about a project, concept, or idea to others is just common sense. This applies just as well to the world of software development, where a software requirements specification is essential for preventing the second most commonly cited reason for project failure: poor requirements management.[14]

In fact, the ISO/IEC/IEEE 29148:2018 standard (a conglomeration of what was formerly IEEE 830 and other standards) is in place to help specify "the required processes implemented in the engineering activities that result in requirements for systems and software products" and provide guidelines for how to apply those requirements.[15] The standard describes the characteristics that make up quality software requirement development, including aspects such as[16]:

  • correctly describing system behavior;
  • effectively removing ambiguity from the language used;
  • completely covering the system behavior and features;
  • accurately prioritizing and ranking the requirements; and
  • unequivocally ensuring the requirements are testable, modifiable, and traceable.

A requirement typically comes in the form of a statement that begins with "the system/user/vendor shall/should ..." and focuses on a provided service, reaction to input, or expected behavior in a given situation. The statement may be abstract (high-level) or specific and detailed to a precise function. The statement may also be of a functional nature, describing functionality or services in detail, or of a non-functional nature, describing the constraints of a given functionality or service and how it's rendered. An example of a functional software requirement could be "the user shall be able to query either all of the initial set of databases or select a subset from it." This statement describes specific functionality the system should have. On the other hand, a non-functional requirement, for example, may state "the system's query tool shall conform to the ABC 123-2014 standard." The statement describes a constraint placed upon the system's query functionality.

This is where a requirements specification shines, not only for the software developer but also for those acquiring the software. A set of development requirements, compiled in the form of a software requirements specification, can serve to strengthen the software development process. For those acquiring the software, a set of user requirements, compiled in the form of a user requirements specification (URS), can be used for the selection and acquisition of software or a service.[17][18] In the case of the URS, the acquiring business can approach this several ways. The simple way would be to essentially take the vendor at the word in regards to what they say their system can and can't do, agreeing formally to their description and taking responsibility that it will cover all the applicable regulations required by your business. However, this method isn't comprehensive and leaves the business open to not being able to fully meet its goals.[18]

The other method has the URS be specific to your business' needs. The process is more work but leaves less to chance.[18] Developing your own URS isn't always straightforward. Often times, the developed document turns into a mix of "wishlist" requirements from potential and active clients, as well as regulation-mandated requirements. The wishlist items aren't necessarily ignored by developers, but the URS should in fact clearly prioritize requirements as "nice to have" or "essential to system operation," or something in between.[19][20][21] Whatever the URS looks like in the end, it's ultimately up to the vendor to be able to demonstrate how the software does and does not meet its requirements.

In the latter half of this guide, you'll be given an opportunity to see an example of a URS for the medical diagnostic and research industries in the form of LIMSpec, an evolving set of software requirements specifications for laboratory informatics systems. Built from requirements found in ASTM E1578-18 Standard Guide for Laboratory Informatics, as well as dozens of other standards and regulations, the LIMSpec examples we provide will demonstrate how a URS is put to use, while also showing you how an informatics system can help you laboratory better meet regulatory requirements.

References

  1. ↑ Sobowale, J. (1 March 2017). "Law firms must manage cybersecurity risks". ABA Journal. American Bar Association. http://www.abajournal.com/magazine/article/managing_cybersecurity_risk/. Retrieved 09 January 2020. 
  2. ↑ Watney, C.; Draffin, C. (November 2017). "Addressing new challenges in automotive cybersecurity" (PDF). R Street Policy Study No. 118. R Street Institute. https://www.rstreet.org/wp-content/uploads/2018/04/118-1.pdf. Retrieved 09 January 2020. 
  3. ↑ Lewis, J.A. (21 February 2018). "Economic Impact of Cybercrime". Center for Strategic & International Studies. https://www.csis.org/analysis/economic-impact-cybercrime. Retrieved 09 January 2020. 
  4. ↑ "BLOG: Cost of Cyber Crime to Small Businesses". Virginia SBDC Blog. Virginia SBDC. 30 May 2017. https://www.virginiasbdc.org/blog-cost-of-cyber-crime-to-small-businesses/. Retrieved 09 January 2020. 
  5. ↑ "Hiscox Cyber Readiness Report 2019" (PDF). Hiscox Ltd. April 2019. https://www.hiscox.com/documents/2019-Hiscox-Cyber-Readiness-Report.pdf. Retrieved 09 January 2020. 
  6. ↑ Galvin, J. (7 May 2018). "60 Percent of Small Businesses Fold Within 6 Months of a Cyber Attack. Here's How to Protect Yourself". Inc.com. https://www.inc.com/joe-galvin/60-percent-of-small-businesses-fold-within-6-months-of-a-cyber-attack-heres-how-to-protect-yourself.html. Retrieved 09 January 2020. 
  7. ↑ Grima, M. (14 November 2019). "Top reasons why WordPress websites get hacked (and how you can stop it)". WP White Security. https://www.wpwhitesecurity.com/why-malicious-hacker-target-wordpress/. Retrieved 09 January 2020. 
  8. ↑ Moen, D. (19 April 2016). "What Hackers Do With Compromised WordPress Sites". Wordfence Blog. Defiant, Inc. https://www.wordfence.com/blog/2016/04/hackers-compromised-wordpress-sites/. Retrieved 09 January 2020. 
  9. ↑ Talaleve, A. (May 2019). "Website Hacking Statistics (Updated 2019)". WebARX. https://www.webarxsecurity.com/website-hacking-statistics-2018-february/. Retrieved 09 January 2020. 
  10. ↑ "security control". Computer Security Resource Center. National Institute of Standards and Technology. 2019. https://csrc.nist.gov/glossary/term/security-control. Retrieved 10 January 2020. 
  11. ↑ 11.0 11.1 Ciocoui, C.N.; Dobrea, R.C. (2010). "Chapter 1. The Role of Standardization in Improving the Effectiveness of Integrated Risk Management". In Nota, G.. Advances in Risk Management. IntechOpen. doi:10.5772/9893. ISBN 9789535159469. 
  12. ↑ 12.0 12.1 "Data Standardization: A Call to Action" (PDF). JPMorgan Chase & Co. May 2018. https://www.jpmorganchase.com/corporate/news/document/call-to-action.pdf. Retrieved 14 December 2019. 
  13. ↑ "specification". Merriam-Webster. Merriam-Webster, Inc. https://www.merriam-webster.com/dictionary/specification. Retrieved 09 January 2020. 
  14. ↑ Bieg, D.P. (August 2014). "Introduction" (PDF). Requirements Management: A Core Competency for Project and Program Success. Project Management Institute. p. 3. https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/requirements-management.pdf. Retrieved 09 January 2020. 
  15. ↑ "ISO/IEC/IEEE 29148:2018". International Organization for Standardization. November 2018. https://www.iso.org/standard/72089.html. Retrieved 09 January 2020. 
  16. ↑ Seibert, P. (28 July 2011). "How do you write software requirements? What are software requirements? What is a software requirement?". HubTechInsider. https://hubtechinsider.wordpress.com/2011/07/28/how-do-you-write-software-requirements-what-are-software-requirements-what-is-a-software-requirement/. Retrieved 09 January 2020. 
  17. ↑ Memon, A. (Spring 2010). "Software Requirements: Descriptions and specifications of a system" (PDF). University of Maryland. https://www.cs.umd.edu/~atif/Teaching/Spring2010/Slides/3.pdf. Retrieved 09 January 2020. 
  18. ↑ 18.0 18.1 18.2 Schmitt, S. (2018). "User Requirements Specifications–How Difficult Can It Be?". Pharmaceutical Technology 42 (11): 58. http://www.pharmtech.com/user-requirements-specifications-how-difficult-can-it-be-0. Retrieved 09 January 2020. 
  19. ↑ Aasem, M.; Ramzan, M.; Jaffar, A. (2010). "Analysis and optimization of software requirements prioritization techniques". Proceedings from the 2010 International Conference on Information and Emerging Technologies: 1–6. doi:10.1109/ICIET.2010.5625687. 
  20. ↑ Hirsch, J. (22 November 2013). "10 Steps To Successful Requirements Gathering". Phase2 Technology, LLC. https://www.phase2technology.com/blog/successful-requirements-gathering. Retrieved 09 January 2020. 
  21. ↑ Burris, E. (2007). "Requirements Specification". CS451R, University of Missouri–Kansas City. University of Missouri–Kansas City. http://sce2.umkc.edu/BIT/burrise/pl/requirements/. Retrieved 09 January 2020. 
Retrieved from "https://www.limswiki.org/index.php?title=User:Shawndouglas/sandbox/sublevel3&oldid=37380"