View source for Healthcare Systems Engineering

This article provides an overview of the role of systems engineering in the engineering or re-engineering of {{Term|Healthcare (glossary)|healthcare}} systems to meet a number of modern day challenges.  The role of SE in medical devices, healthcare IT, pharmaceuticals, and public health systems are considered and contrasted to "traditional" SE practices discussed elsewhere in the SEBoK.  See [[Overview of the Healthcare Sector]] for details of the stakeholders and constraints of the these different parts of the sector.

==Topics==
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: 
*[[Overview of the Healthcare Sector]]
*[[Systems Engineering in Healthcare Delivery]]
*[[Systems Biology]]
*[[Lean in Healthcare]]

==Healthcare and Systems Engineering==
{{Term|Healthcare (glossary)|Healthcare}} today faces many challenges related to safety (e.g. Hospital Safety Score 2013, Andel et al. 2012, Institute of Medicine 1999), affordability, access, and the means for reliably producing positive outcomes for all patients of all ages and across all care environments.  Furthermore, the health of individuals is challenged by many threats such as environmental and behavioral norms, emerging natural infectious diseases, and acute and chronic conditions that are becoming more prevalent because of longer lifespans.  Re-engineering today’s healthcare to address these challenges requires a systems approach – an approach that develops solutions to contend with the complexity of healthcare-related policy, economics, social dynamics, and technology.  Systems Engineers are trained to grapple with this kind of complexity by thinking holistically and to work with trans-disciplinary teams to develop solutions making re-engineering healthcare a natural fit for systems engineers and the tools of systems engineering.

The disciplines involved in re-engineering healthcare are far reaching across academia, government, industry, private, and public sectors including the patients and families the healthcare field serves. Systems Engineers involved in this re-engineering draw on several tools when working with these stakeholders to develop solutions. In doing so they follow the general systems principles described in the [[Systems Approach Applied to Engineered Systems]] knowledge area in SEBoK [[Foundations of Systems Engineering|Part 2]].  First, with so many diverse {{Term|Stakeholder (glossary)|stakeholders}} involved in this field, it is vitally important for the Systems Engineer to help clarify the problem or opportunity and to conceive of the objective of the re-engineering.  They need to “envision the solution” without being entirely prescriptive of the solution’s specific implementation, see [[Identifying and Understanding Problems and Opportunities]].  Then, drawing from best practices, the Systems Engineer guides the stakeholders through the [[Synthesizing Possible Solutions|synthesis of possible solutions]] and the [[Analysis and Selection between Alternative Solutions|analysis and selection between alternatives]].  Systems engineers are also involved in the [[Implementing and Proving a Solution|implementation and testing]] and the [[Deploying, Using, and Sustaining Systems to Solve Problems|deployment, use and sustainment]] of healthcare systems to provide stakeholder value.  The systems approach in healthcare must be particularly mindful to not exclusively focused on technical aspects of the effort since the solutions to healthcare’s challenges exist not only in technical areas but the integration of culture, workflow and processes, with technology as a tool to support the delivery of safe, affordable, and accessible care.  

To achieve this system approach healthcare projects follow a version of the SE {{Term|Life Cycle (glossary)|life cycle}} described in SEBoK [[Systems Engineering and Management|Part 3]].  This included the creation of {{Term|Stakeholder Needs and Requirements (glossary)|Stakeholder}} and {{Term|System Requirement (glossary)|System}} Requirements, Systems {{Term|Architecture (glossary)|Architecture}} and {{Term|Design (glossary)|Design}} and System {{Term|Integration (glossary)|Integration}}, {{Term|Verification (glossary)|Verification}} and {{Term|Validation (glossary)|Validation}}. The SE life cycle extends to include [[System Deployment]], Operation, {{Term|Maintenance (glossary)|Maintenance}} and {{Term|Logistics (glossary)|Logistics}}. Healthcare project will also follow some of the [[Systems Engineering Management]] processes described in Part 3.

It is vitally important for the healthcare systems engineer to ensure socio-technical integration and interoperability among system components are part of any project – the last thing healthcare needs is another standalone innovation that perpetuates the silos that exist in the field today.  Remaining focused on the objective and problem to solve, managing scope creep, disciplined design, implementation, and project management are key activities the Systems Engineer is responsible for in {{Term|Healthcare Systems Engineering (glossary)|healthcare systems engineering}}. 

== Systems Engineering for Medical Device Development ==
Systems Engineering for medical device development is essentially an application of [[Product Systems Engineering]] as described in SEBoK [[Applications of Systems Engineering|Part 4]] with a few customizations:
* The life cycle has to comply with specific healthcare regulations, which constrain aspects of the life cycle, as exemplified by FDA regulations in the US (21CFR 820.30)
* The products are market driven, with little customization allowed by the manufacturer at the customer site
* The markets are midsized, with the market for a given technology or product line often being in the $1-10B range
* Medical device development programs are mid-sized…many from 10-100 man-years of development, lasting 1-2 years
* Time to market is critical, with the first mover or first with a complete solution capturing the majority of the profits
* Most products are cyber-physical, with software becoming a larger part of the product.  Many products include significant aspects of physiology or chemistry
* There is a special tension between “efficacy” and “safety”. Efficacy requires the vast majority to be helped. Safety is compromised if only a very small minority is adversely affected. Truly safe systems require a special approach to systems engineering . (Leveson 2011)
* Customer feedback may be constrained by safety issues as well as HIPAA regulations

=== Device Development in a Market Environment ===
One critical difference between many “traditional” systems engineering industries (defense and aerospace) and healthcare device development is that most healthcare device development is market driven, rather than contract driven.  Some key differences between market and contract systems engineering:
* The program size (budget) and dates are not ‘fixed’, they are set by the business leadership designed to maximize return on investment across a portfolio of product programs
* Program scope and requirements are not fixed externally; they can be changed fairly rapidly by negotiation between functions and the executive committee.
* The goal for the product development isn’t necessarily a feature set, it is a market share and price premium relative to the competition…which can be a moving target.  A competitive announcement will often force a change in the program scope
* In a contract based program there is an identified customer, with a set of applications and workflows. In a market driven program the workflow and use cases are defined by the developer, and the buyer needs to ‘own’ the integration of the offering into their specific systems and workflows.
* For specific medical products the FDA can require pre-market trials and post market studies . (FDA 2014)
* The different types of healthcare reimbursement across the world (universal coverage private insurance, national single provider, national single payer, private insurance, and out of pocket) creates dramatically different market dynamics (for individuals, healthcare providers, and product developers) . (Reid 2010)

=== Regulations for Medical Device Development ===
As with all regulated products, there are many regulations governing the development of medical devices.  The medical device industry specific regulations are primarily driven by the US (FDA), Europe (European Commission), and Canada (Health Canada).  Within the US, the FDA governs medical devices primarily through 21 CFR 820.30 (Quality Systems Regulation, Subpart C Design Controls) , which contains requirements similar to ISO 13485. The sections of the Quality Systems Regulation for Design Controls can be mapped fairly directly to ISO/IEC/IEEE 15288 (2015) and the INCOSE ''SE Handbook'' (INCOSE 2015).

Table 1. Comparison of Healthcare Safety Regulations with ISO/IEC/IEEE 15288 and the INCOSE ''SE Handbook''.
{|
 
  |
<nowiki>  </nowiki>'''21CFR820.30'''
  
  |
<nowiki>  </nowiki>'''ISO/IEC/IEEE 15288:2015'''
  
  |
<nowiki>  </nowiki>'''INCOSE ''SE Handbook'''''  
 
 |-
  |
<nowiki>  </nowiki>(b)
<nowiki> </nowiki> Design and development planning
  
  |
<nowiki>  </nowiki>6.3.1
<nowiki> </nowiki> Project Planning Process
  
  |
<nowiki>  </nowiki>5.1
<nowiki> </nowiki> Project Planning Process  
 
 |-
  |
<nowiki>  </nowiki>(c)
<nowiki> </nowiki> Design input.
  
  |
<nowiki>  </nowiki>6.4.2
<nowiki> </nowiki> Stakeholder needs and requirements definition process
<nowiki>  </nowiki>6.4.3 Systems requirements definition process
  
  |
<nowiki>  </nowiki>4.2
<nowiki> </nowiki> Stakeholder needs and requirements definition process
<nowiki>  </nowiki>4.3 Systems requirements definition process  
 
 |-
  |
<nowiki>  </nowiki>(d)
<nowiki> </nowiki> Design output
  
  |
<nowiki>  </nowiki>6.4.5
<nowiki> </nowiki> Design definition process
<nowiki>  </nowiki>6.4.7 Implementation process
  
  |
<nowiki>  </nowiki>4.5
<nowiki> </nowiki> Design definition process
<nowiki>  </nowiki>4.7 Implementation process  
 
 |-
  |
<nowiki>  </nowiki>(e)
<nowiki> </nowiki> Design review
  
  |
<nowiki>  </nowiki>6.3.2
<nowiki> </nowiki> Project Assessment and Control process
  
  |
<nowiki>  </nowiki>5.2
<nowiki> </nowiki> Project Assessment and Control process  
 
 |-
  |
<nowiki>  </nowiki>(f)
<nowiki> </nowiki> Design verification
  
  |
<nowiki>  </nowiki>6.4.9
<nowiki> </nowiki> Verification Process
  
  |
<nowiki>  </nowiki>4.9
<nowiki> </nowiki> Verification Process  
 
 |-
  |
<nowiki>  </nowiki>(g)
<nowiki> </nowiki> Design validation
  
  |
<nowiki>  </nowiki>6.4.11
<nowiki> </nowiki> Validation Process
  
  |
<nowiki>  </nowiki>4.11
<nowiki> </nowiki> Validation Process  
 
 |-
  |
<nowiki>  </nowiki>(h)
<nowiki> </nowiki> Design transfer
  
  |
<nowiki>  </nowiki>6.4.10
<nowiki> </nowiki> Transition Process
  
  |
<nowiki>  </nowiki>4.10
<nowiki> </nowiki> Transition Process  
 
 |-
  |
<nowiki>  </nowiki>(i)
<nowiki> </nowiki> Design changes
  
  |
<nowiki>  </nowiki>6.3.5
<nowiki> </nowiki> Configuration Management Process
<nowiki>  </nowiki>6.4.13 Maintenance Process
  
  |
<nowiki>  </nowiki>5.5
<nowiki> </nowiki> Configuration Management Process
<nowiki>  </nowiki>4.13 Maintenance Process  
 
 |-
  |
<nowiki>  </nowiki>(j)
<nowiki> </nowiki> Design history file
  
  |
<nowiki>  </nowiki>6.2.6
<nowiki> </nowiki> Knowledge Management Process
  
  |
<nowiki>  </nowiki>5.6
<nowiki> </nowiki> Information Management Process  
 
|}

In the biomedical and healthcare environment, an important differentiator in Risk Management activities compared to other industries (see [[Risk Management]]) is that the users and patients are the center of risk analysis rather than technical or business risks. Risk management is an important element of the design control process, as preliminary hazard analysis drive initial design inputs. Traceability between identified risks, risk mitigations, design inputs, and design outputs is a key factor in product clearance through regulatory agencies. Most regulatory bodies have recognized ISO 14971: Medical devices -- Application of risk management to medical devices as a methodology for assessing and documenting product safety and effectiveness.

Usability Engineering is an important subset of risk management activities.  ISO 62366-1 Medical devices – Part 1: Application of usability engineering to medical devices provides a “process for a manufacturer to analyze, specify, develop and evaluate the usability of a medical device as it relates to safety. This usability engineering  (human factors engineering) process permits the manufacturer to assess and mitigate risks associated with correct use and use errors, i.e., normal use.“ . (IEC 62366-2015)  For example, for a device designed for home care use, there are many complex interfaces that product designers must consider. Patients may be physically or cognitively affected (age, medication, injury, etc.); they may be untrained or cared for people who are untrained; they are not professionals used to technical systems, etc. Even in the hospital setting, untrained patients may have physical access to systems. This puts a critical focus on usability and human factors considerations and the complexity of the use environment.

Further, as medical devices incorporate more software and become cyber-physical devices, the regulators are also focusing on privacy and security (ISO 21827) and software life cycle management (ISO 62304).
[[File:Use Cases ISO 14971 15288.png|centre|'''Figure 1 Overlap of Regulations and Standards for Medical Device Development.''' (Modified from (Malins et al. 2015). Used with Permission. All other rights are reserved by the copyright owner.)|700x700px|thumb]]

Medical Device regulations, guidance, and technical standards are constantly changing, adding a complex dynamic to manage and incorporate throughout the product development life cycle.

== Systems Engineering for Healthcare IT ==
Systems Engineering for Healthcare Information Technology is very similar to other IT developments, with the addition of medical regulations.  Healthcare Information Technology is critical to efficient flow of information and delivery of services . (Presidents Council of Advisors on Science and Technology 2010) The product development is a mix of contract driven development (with a target customer, such as healthcare.gov), and market driven (where there are more standard products, with minimal customization).  Much of the market, especially for hospitals and hospital chains, is a mix of standard products with large amounts of customization to the customer’s specific needs, terminology, and workflows.

== Systems Engineering for Pharmaceuticals ==
The pharmaceutical industry leverages systems that include hardware, software and sometimes single-use components in different part of their value chain, for example complex analytical systems during drug discovery, complex bioreactors and downstream filtration and chromatography systems in manufacturing and drug delivery devices for the use of their drugs. These systems are subject to very different regulations, e.g. GMP or medical devices, depending on the use. One challenging aspect of these systems is that the users have different skill sets and  working under different environments. And in all of the examples below, biological and/or chemical processes run on these systems, requiring deep domain knowledge of the system development teams.

The in-vitro diagnostic industry also uses many systems, small devices (e.g. self-testing blood glucose or coagulation monitoring systems) all the way to large, fully automated, high throughput systems for the use in centralized laboratories. Very often, these systems operate as a closed system, so that the reagents used for the diagnostics tests, are proprietary and the vendor of the system only guarantees high quality results only when using the proprietary chemistry. This enables the vendors to often ‘place’ the instruments as highly competitive prices when the actual profit is generated through the consumables.

For the chemistry part of pharma, understanding the scientific method, using a systems thinking approach, and using six sigma approaches to managing variation and interdependencies is critical.  Once you create a product which includes software and physical parts (including manufacturing equipment), systems engineering of the functional design, design analysis, and integration and verification of the solution become critical.

== Systems Challenges for Public Health ==
Summits and inquiries into problems or shortcomings in the public health space have consistently uncovered the same issues: systemic failures in the way that public health is approached that make it nearly impossible to adequately respond to major health events. Examples can be seen from the US response to Hurricane Katrina (e.g. The White House 2006), the 2011 Thoku tsunami (e.g. Carafano 2011, The Heritage Foundation 2012), or even the 2014-2015 Ebola outbreak in West Africa (e.g. GHTC 2015).

The White House report provides insights into just a few of potential challenges for the health aspects of disasters or large-scale emergencies (2006, Chapter 6):
* Tens of thousands of people may require medical care.
* Large portions of a population with chronic medical conditions may themselves without access to their usual medications and sources of medical care. 
* Hospitals and other healthcare facilities may be totally destroyed or otherwise rendered inoperable and the area’s health care infrastructure may sustain extraordinary damage.
The types of public health challenges will also change over time: Immediate challenges include the identification, triage and treatment of acutely sick and injured patients; the management of chronic medical conditions in large numbers of evacuees with special health care needs; the assessment, communication and mitigation of public health risk; and the provision of assistance to State and local health officials to quickly reestablish health care delivery systems and public health infrastructures. (The White House 2006) As time passes, longer-term infectious disease outbreaks may occur or environmental impacts may cause health risks (e.g. Fukushima nuclear meltdown after the 2010 tsunami). And over time, the public health and overall healthcare infrastructure must be re-established and repaired.

But the public health “system” in most countries, as currently structured, is not prepared to deal with these types of challenges. In talking about the US, Salinsky and Gursky state, “Despite recent attention to the biodefense role of public health, policymakers have not developed a clear, realistic vision for the structure and functionality of the governmental public health system. Lack of leadership and organizational disconnects across levels of government have prevented strategic alignment of resources and undermined momentum for meaningful change. A transformed public health system is needed to address the demands of emergency preparedness and health protection. … The future public health system cannot afford to be dictated by outmoded tools, unworkable structures, and outdated staffing models.” (2006)

The framing of the challenge as a systems one requires the application of a systems approach, and the use of tools capable of supporting systems views, to enable better understanding of the challenges for public health and for creating ways to address these challenges.  The SEBoK knowledge areas on [[Enterprise Systems Engineering]] and [[Systems of Systems (SoS)]] at least partially consider some of these challenges from a systems engineering perspective.

== Systems Biology for Healthcare ==
As systems science is a foundation for system engineering, systems biology is becoming recognized as a foundational discipline for healthcare systems engineering. Systems biology is an emerging discipline and is recognized as strategically important when tackling complex healthcare problems. The development of systems biology is also an emerging environment for systems engineers.

According to Harvard University, “Systems biology is the study of systems of biological components, which may be molecules, cells, organisms or entire species. Living systems are dynamic and complex and their behavior may be hard to predict from the properties of individual parts. To study them, we use quantitative measurements of the behavior of groups of interacting components, systematic measurement technologies such as genomics, bioinformatics and proteomics, and mathematical and computational models to describe and predict dynamical behavior. Systems problems are emerging as central to all areas of biology and medicine.” (Harvard University 2010)

As systems biology matures, its integration into healthcare approaches is expected to lead to advanced practices such as personalized and connected healthcare and the resolution of complex diseases.

== Conclusion ==
While systems engineering practices apply to the healthcare domain, they face different challenges than other industries and need to be tailored.  In fact, different segments of the healthcare industry can take significantly different approaches to effective systems engineering and systems thinking.

==References==

=== Works Cited ===
21 CFR 820.30. “Part 820 – Quality System Regulation: Subpart C – Design Controls.” ''Title 21 – Food and Drugs: Chapter I – Food and Drug Administration, Department of Health and Human Services: Subchapter H – Medical Devices''. Available at: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfCFR/CFRSearch.cfm?fr=820.30

Andel, C., S.L. Davidow, M. Hollander, D.A. Moreno. 2012. “The economics of health care quality and medical errors.” ''Journal of Health Care Finance''. 39(1):39:50. Abstract available at: http://www.ncbi.nlm.nih.gov/pubmed/23155743 200,000 Americans die from preventable medical errors including facility-acquired conditions and millions may experience errors. In 2008, medical errors cost the United States $19.5 billion.

Carafono, J.J. 2011. ''The Great Eastern Japan Earthquake: Assessing Disaster Response and Lessons for the U.S.'' Washington, DC: The Heritage Foundation. Special Report #94 for Japan. May 25, 2011.

FDA. 2014. “Premarket Approval (PMA)”. Washington, DC: U.S. Food and Drug Administration (FDA). Accessed February 17, 2016. Available at: http://www.fda.gov/Medicaldevices/Deviceregulationandguidance/Howtomarketyourdevice/Premarketsubmissions/Premarketapprovalpma/Default.Htm

GHTC. 2015. “Will We Learn from the Lessons of the Ebola Outbreak?” 2015 Policy Report. Washington, DC: Global Health Technologies Coalition (GHTC).

Gursky, E. 2005. ''Epidemic Proportions: Building National Public Health Capabilities to Meeting National Security Threats''. Arlington, VA: Analytic Services Inc. (ANSER).

Harvard University. 2010. “Department of Systems Biology.” Cambridge, MA: Harvard University. Accessed February 17, 2016. Available at: https://sysbio.med.harvard.edu/ 

Hospital Safety Score. 2013. “Hospital Errors are the Third Leading Cause of Death in U.S., and New Hospital Safety Scores Show Improvements are Too Slow.” Washington, DC: The LeapFrog Group. Accessed February 17, 2016. Available at: http://www.hospitalsafetyscore.org/newsroom/display/hospitalerrors-thirdleading-causeofdeathinus-improvementstooslow

IEC. 2015. ''Medical devices – Part 1: Application of usability engineering to medical devices''. Geneva, Switzerland: International Electrotechnical Commissions. IEC 62366-1:2015. Available at: http://www.iso.org/iso/catalogue_detail.htm?csnumber=63179

INCOSE. 2015. “Section 8.2.2.” ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities'', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0

Institute of Medicine. 1999. ''To Err is Human: Building a Safe Health System''. Washington, DC: The National Academy Press, The National Academy of Sciences. Novermber 1999. Available at: https://iom.nationalacademies.org/~/media/Files/Report%20Files/1999/To-Err-is-Human/To%20Err%20is%20Human%201999%20%20report%20brief.pdf  

ISO/IEC/IEEE. 2015. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

Leveson, N.G. 2011. ''Engineering a Safer World: Systems Thinking Applied to Safety''. Cambridge, MA: Massachusetts Institute of Technology (MIT).

Presidential Council of Advisors on Science and Technology. 2010. ''Report to the President: Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward''. Washington, DC: Presidential Council of Advisors on Science and Technology, The White House. December 2010. Available at: https://www.whitehouse.gov/sites/default/files/microsites/ostp/pcast-health-it-report.pdf.

Reid, T.R. 2010. ''The Healing of America: A Global Quest for Better, Cheaper, and Fairer Health Care''. New York, NY: Penguin Books.

Salinsky, E. and E. Gursky. 2006. “The Case for Transforming Governmental Public Health.” ''Health Affairs''. 25(4). 1017-2018. Available at: http://content.healthaffairs.org/content/25/4/1017.full

The Heritage Foundation. 2012. ''One Year Later: Lessons from Recover After the Great Eastern Japan Earthquake''. Washington, DC: The Heritage Foundation. Special Report #108 on Asia and the Pacific. April 26, 2012.

The White House. 2006. ''The Federal Response to Hurricane Katrina Lessons Learned''. Washington, DC: The White House. February 2006. Available at http://library.stmarytx.edu/acadlib/edocs/katrinawh.pdf

=== Primary References ===
None.

=== Additional References ===
None.

----
<center>[[Mission Engineering|< Previous Article]] | [[ Applications of Systems Engineering|Parent Article]] | [[Overview of the Healthcare Sector|Next Article >]]</center>

<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>

[[Category:Part 4]]
[[Category:Topic]]
[[Category:Healthcare Systems Engineering]]