Healthcare

Abstract

Healthcare is the most complex area addressed in this book. It is a data-rich environment and data dependent. Often healthcare delivery is time critical; it experiences high demand and under surge conditions is reliant on individual or groups of human healthcare workers. These surge conditions arise from multiple sources, and while coping mechanisms are planned their occurrence is influenced by a wide range of external factors. For example, a major incident may occur during a period of already high demand.

In this section, the reader is encouraged to consider how the Safety Risk Model (SRM) is influenced by large changes in demand. These changes induce secondary effects such as demand for consumables (e.g. Personnel Protective Equipment). They also induce tertiary effects along the supply chain. What ‘best fit’ set of ‘decision models’ would be appropriate and wow would these be modelled.

‘Want is one only of five giants …the others are Disease, Ignorance, Squalor, and Idleness.’ – William Beveridge

This is the third application domain to be addressed. It sits at the highest level of abstraction of the three areas and is an example of a Data-Centric Organisation (DCO) (1.5.3). The objective of this chapter is

Objective 25.0.1 Competing Metamodels —

to provide an example of the application of the DSM (20.0.1) where in whole or in part data metamodels (7.8.2) compete for the available resources, capacities and capabilities.

Definition 25.0.1 Healthcare —

the organised provision of medical care (25.0.2) to individuals or a community [289].

Definition 25.0.2 Care —

the provision of what is necessary for the health, welfare, maintenance and protection of someone or something [93].

Definition 25.0.3 Healthcare System —

organised delivery of healthcare (25.0.1) by people, institutions, enterprises and state resources to meet the health needs of target populations.

A demand-side definition of healthcare (25.0.1) describes the diagnosis, treatment and prevention of disease, illness, injury and other physical and mental impairments in humans. The healthcare system (25.0.3) delivers these services at the local, regional and national levels [39]. A supply-side definition addresses healthcare provision and extends far beyond clinical delivery to setting policies, financing, managing programmes and administrative support [39].

The demand for healthcare is insatiable, and its provision is highly politicised. The healthcare footprint is vast and provides medical services. The organisations (1.5.2) that implement these services can be enterprises (1.5.1) or the state. In the UK the state organisation is the National Health Service (NHS), which consists of many operational sites. Hospitals provide healthcare services from administration to maternity units, through A+E (Accident and Emergency) to specialist clinics. It is in the national interest to promote good health. Health contributes to the national economy through productivity by reducing the number of days lost to sickness. Behaviour change programmes promote health awareness. Heath monitoring provides data for vector-control campaigns. Statutory instruments implement occupational health and safety legislation.

This application area addresses a healthcare system, where multiple data metamodels (7.8.2) compete for resources. The healthcare context (6.0.2) is large, diverse, fragmented and above all complex (3.8.4). This complexity is manifest at the macro, meso and micro levels [620]. In such an environment, the introduction of techniques, measures, procedures, equipment and technology changes the behaviour of the system (1.5.5). In short, the healthcare system is a Complex Adaptive System (CAS) (3.8.2). It presents as a Wicked Problem (3.8.5) whereby any changes to the healthcare provision intended to solve one issue have the potential to cause others.

Healthcare provision consists of multiple interrelated operational contexts (OC) (9.1.1). Each OC contains at least one model describing multi-dimensional islands of services or functions. These models are interdisciplinary, interfacing with multiple internal and external organisations. Maintaining Patient Confidentiality (3.3) is paramount. A robust Security Model (3.3.2) and security management (S.3.3) is required to identify, authenticate (3.3.4) and manage personnel (Clinical, Support and Administration Staff) and their access to data such as Electronic Health Records (EHR) and drugs within this regulated environment.

The concept of a ‘one-size-fits-all’ healthcare system is neither practical nor pragmatic. Healthcare must cater for the individual, group and ethnicity of patients based on equality. It must consider regional variations and the demographics of the population as a whole. Changes in demographics place different demands on the provision of healthcare. It must also address the full range of timescale, from emergency medicine and short-term treatments to long-term conditions. Its abstractions address many societal issues, ranging from epidemiology to health education. Where possible, healthcare promotes the eradication of diseases. Each of these issues has the potential to change the demands placed on healthcare.

A healthcare system typically employs an organisational hierarchy. In the UK NHS, this includes HMG Department for Health, the development, monitoring and provision of operational sites, Healthcare Staff and the logistics associated with the healthcare activities.

25.1. Introduction

Healthcare is a rich application domain for Data Safety (DS). It has an extensive scope; its services are often time-dependent, long-duration and applicable to the individual, groups of individuals and broader society. Data must be provided to the right people at the right time. Data removal and archiving are also important factors in ensuring that data is transformed into good information (1.3.4). Economic factors influence the selection of drugs and their changing effectiveness (such as antibiotic resistance), or the approval and introduction of new Integrated Care Pathways (25.1.2), treatments and procedures. These decisions (2.3.1) are based on the collection of appropriate data, as determined by instantiation of the relevant data metamodels.

Definition 25.1.1 Care Pathway —

is a complex intervention for the mutual decision-making and organisation of care processes for a well-defined group of patients during a well-defined period [655], [556].

Definition 25.1.2 Integrated Care Pathway —

(ICP) is a methodology for mutual decision making and the organisation of care (25.0.2) for a clinical condition for a well-defined period [94].

Healthcare is a data-rich environment. Its data (1.2.1) addresses the full range of information relating to healthcare service provision. As an illustration, consider a ‘Patient’ and their engagement with the healthcare system. An unwell patient makes an appointment and visits their Doctor (a.k.a. General Practitioner (GP)). One outcome is a referral to a Hospital Clinic. One or more Consultants at the Clinic assesses the patient. They request tests (bloodwork, X-rays, etc.) to support diagnosis and to determine a course of treatment (ICP). The ICP may require multiple visits and/or perhaps surgical intervention. Once the patient has returned home, they may require home-delivered services from the District Nurse. Delay in provision or availability may adversely affect the outcome.

25.1.1. Background

The medical profession is undergoing radical change. Along with the legal profession (working in domains such as the Criminal Justice System), it is one of the last professions to be subjected to the Information Age. Once at the pinnacle of professional status, Medical Doctors are challenged and questioned as their collective actions are normalised, subjected to review, revision and measurement. Technology has always been present in healthcare; infrastructural technologies (4.0.2) and data ecosystems (4.0.1) enable the communication, collation and analysis of clinical data that without it was previously not possible. Therefore, clinical practice is transforming to create data that can be consumed by these infrastructural technologies.

In a stable society, the healthcare system has core and surge capabilities. The core capability represents the steady state, incrementally increasing year-on-year as it tracks demand. The surge capability adapts to sudden-onset events. Incidents require an immediate response. This scale of the response is proportional to the incident. The capacity of local healthcare system elements are likely to be exceeded during a civil contingency incident.

In its core operations1 , there is regularity to healthcare provision. A multitude of support services range from the physical environment (Clinic or Hospital), nursing, administrative support (Patient Records, Pharmacy and clerical support) to transportation (Ambulance Services). These are supported by the organisational hierarchy, supply chains, training, estates management and regulatory bodies to name but a few.

This is the background to the healthcare application area, a complex, complicated (3.8.3), multi-dimensional, multi-disciplinary, multi-organisation, interrelated and interconnected context. Healthcare contains many metamodels competing for resources,including data resources.

25.1.2. Health Strategy

By way of an example, this text is confined to health strategy [500], [499] published by Public Health England (PHE). This strategy outlines the priorities for the next five years to both protect people and help people to live longer in good health:

• •keeping people safe;
• •working to prevent poor health;
• •narrowing the health gap;
• •supporting a strong economy.

PHE is a 24/7 organisation that seeks to protect and improve the nation's health and reduce health inequalities. In this limited application area, we explore the PHE's strategic objective to ‘keep the public safe’. Navigation through the strategy [499] leads to consideration of:

Item 6: Effective Responses to Major Incidents

PHE is a 24/7 organisation that seeks to protect and improve the nation's health and reduce health inequalities. In this limited application area, we explore the PHE's strategic objective to ‘keep the public safe’. Pandemic influenza is considered the highest risk in HMG's National Risk Register [456], [455], with estimates suggesting that such an outbreak could lead to up to half of the UK population being infected. Recent events (Covid-19) have brought these issues into sharp focus. For this application area, we extract the following elements:

• •need to provide a system at the local and national level that provides emergency preparedness, resilience and a response system,
• •need to define and agree on a set of high-intensity and high-demand scenarios,
• •need to establish the core and surge capability to address these scenarios and participation in test exercises to assure emergency preparedness.

The PHE strategy [499] infers that demand for healthcare is not stable, and that many factors and sudden onset demands influence it [455]. Thus, data metamodels and associated metadata and data are also not stable. Explicit identification and management of the metamodels, metadata and data allows for effective change management including Change Impact Analysis (CIA) (7.0.3).

25.1.3. Scope and Organisational Change

The scope of healthcare is pan-societal; it affects all humans and human activity. Its provision is an unquestionable right. A healthcare system is in a constant state of change. Healthcare evolves as it responds to its context and new treatments, and to societal pressures such as birth rate, addiction, mental health and an ageing population. In parallel, technology creates change to

• •Core administrative services;
• •Logistics and supply chain services;
• •Clinical solutions;
• •Data, analytics and information services

Healthcare delivery is subject to moral and ethical principles that transcend age, ethical, religious and gender divisions. There is a balance to be struck between the ‘rights of the individual’, ‘life at all costs’ and ‘quality of life’, and the trade-offs and compromises required to address societal issues, such as prevention and the cost of provision. The full scope of healthcare is too broad for this application area. Instead, we focus on ICPs and the resources required for their delivery.

25.1.4. Context

The most challenging aspect of healthcare for Data Safety (DS) is the extensive array of stakeholders and their viewpoints. An individual may have multiple stakeholder roles. For example, the parent of a child is also the responsible adult for that child and may or may not be a patient registered with the child's GP. The same adult may be a point of contact for their parents (or parents-in-law), siblings and other members of an extended family. A clinician (such as a GP), may have these adult roles and also be the practitioner for thousands of patients, have management responsibilities within the GP surgery and offer a medical specialism. Many stakeholder viewpoints are complex, interrelated and interdependent. Table 25.1 provide a broad categorisation of healthcare provision.

Figure 25.1 illustrates Table 25.1.

Figure 25.1.

A Broad Categorisation of Healthcare Provision

25.1.5. Performance

Perhaps the most emotive aspect of healthcare is performance. Performance is a non-functional requirement typically expressed as a combination of throughput, latency and resource usage. Predictions and estimates of performance for deterministic systems depend on good requirements coverage. Typically, a healthcare system is not well defined. There are many elements which are loosely coupled and cooperate and, in some cases, compete for resources,

Table 7.3 is adapted in Table 25.2 as a non-exclusive list of desirable properties of healthcare performance. Consider the potential data requirements associated with these properties.

25.1.6. Initial Description of the Healthcare System DSM

An initial description of the healthcare system considers the enterprise, organisational unit and optimising layers of the A-axis of the DSM. Table 25.3 describes three elements of the metamodels that are used later.

Assumption 25.1 A large-scale Healthcare System can be adequately defined. —

The definition, capabilities and capacities of the system (1.5.5) and its boundaries (2.1.12) can be adequately identified if appropriate modelling frameworks such as the DSM (20.0.1) are employed.

Assumption 25.1 may seem strange. Highly adaptive socio-technical systems are notoriously difficult to define as they are often subject to multiple, sometimes contradictory pressures. Changes in demand and the healthcare system environment compound the management challenges. The following descriptions are indicative and greatly simplify a complex system.

Enterprise

This application area uses the context of UK healthcare and a healthcare system based on ‘NHS England’ [639]. NHS England is one entity; it is responsible for the planning and execution of large-scale changes to the infrastructure, responding to changes in legislation and assessing NHS delivery organisations for compliance to care standards, procedures and competency requirements. A separate enterprise ‘Public Health England’ (PHE) is responsible for setting policy and maintaining standards. Monitoring and compliance are undertaken by the Care Quality Commission (CQC).

Figure 25.2 is indicative of the high-level context for UK healthcare provision. This provides the context in which the performance target ‘waiting time’ is satisfied and monitored against metrics produced over appropriate data.

Figure 25.2.

High-level Context for UK Healthcare Provision

A COBRA2 is an emergency response committee, comprising government ministers, civil servants, the police, intelligence officers and other appropriate personnel. COBRA meetings are called whenever major and mass casualty incidents require a national response.

Performance

One expression of performance is ‘waiting time’. Two waiting times are explored: the first is waiting time at the A+E department, the second is waiting time associated with Hospital referral to a patients' GP appointment. Table 25.4 describes the elements of the initial healthcare enterprise data metamodel.

Table 25.4.

Initial Healthcare ‘Enterprise’ Metamodel

Organisational Unit

A hospital as the System of Interest (SoI) is probably the most easily recognisable ‘organisational unit’. However, individual healthcare trusts may consist of many hospitals and a hierarchy of other ‘organisational units’. Under normal operating conditions the arrangement and interrelationships, whilst fluid, are understood. The primary pressures result from increasing demand, economic constraints, the availability of healthcare resources and staff. The hospital administrator has the organisational responsibility for the delivery of the healthcare service. The hospital administration plays little part in real-time operations of the SoI being more concerned with the medium-term maintenance (including actor and organisational (1.5.2) competencies) and development of the infrastructure, and the subsequent future delivery of the healthcare service. The hospital administration will become involved in the short-term operation in response to a serious incident (13.0.1) that causes a substantial impact on the delivery of the core healthcare service. Table 25.5 outlines the initial Healthcare ‘Organisational Unit’ Metamodel.

Optimising

Two candidates for ‘waiting time’ application within a Hospital are resources availability (bloodworm, X-Ray etc.) and the A+E department. For a generalised outline of healthcare provision these examples represent the most sophisticated control layer. At its most developed the optimisation layer maximises the use of resources for healthcare provision. They are required to respect the performance and safety constraints of the underlying system context (6.0.1). The information (1.3.4) demands on the optimisation layer are high, requiring a full understanding of the underlying system, the planned service, contingency plans, current status and the predicted future state of the system.

The optimising layer is above the supervisory layer and represents a more complex level of control. This complexity may be a result of a large-scale operation, integrating dissimilar functions, or interpreting complex (or ambiguous) data (or some combination of these). The distinction between the reflex and supervisory layers is the judgement or knowledge of the clinician that must be applied, particularly in degraded or emergency situations. Supervisory systems are characterised by the need to support the judgement of the actor. The supervisory layer is predominantly downward-looking, viewing the performance of the lower levels.

25.2. System Definition

Let's recap our definition of a system (1.5.5) as a (purposeful [102]) set of things working together as part of a mechanism or an interconnecting network; in other words, it is a complex whole [615]. Systems operate in increasingly open environments. Healthcare systems exchange data which are homogeneous or heterogeneous or a mixture of both. The nature of the system environment influences the formation of the system boundary (2.1.12) (porous or secure, as defined by an appropriate security model (3.3.2)). For modern complex systems (15.8.1) it is common to present several views of the system (possibly in a hierarchy) or to separate physical realisations from abstract (logical) models. Therefore, reviewing any classification system requires an appreciation of the context, including the role of the actors within each viewpoint.

The Systems of Systems (SoS) (3.0.2) concept provides a way to collate a set of ICP elements for an integrated clinical treatment plan that would otherwise be difficult for the individual aspects to accomplish separately. Each ICP is formulated as a metamodel. Each constituent ICP keeps its management, goals, and resources while coordinating within the metamodel and adapting to meet ICP goals [253]. Interconnected ICP metamodels give rise to accidental tasks associated with the mapping and representation of abstract entities and mapping of those entities onto the constraints of the solutions [80]. ICP metamodels may be adaptive and require additional elements (joiners) or the removal of elements (leavers). A joiner introduces additional capabilities, capacities and tasks. A leaver removes them. The ICP metamodel is modified (adapted) to reflect these changes in the element catalogues.

There are several interrelated models at play in the healthcare system.

• •Security – Of primary importance is confidentiality. All entities are allocated an identity so that an actors data access privileges can be assigned (and revoked). How will the relevant authorities of the ICP elements and the actors that use and are served by the healthcare system be managed?
• •Continuity – How should the ICP and the response of their respective services be defined to be resilient and adapt to unavailability? How will the ICP metamodel be reconfigured to manage reduced capability whilst one or more elements are not available?
• •Execution – How big, complex or complicated should an ICP be before the risks associated with its failure demand the creation of an execution model? An operational strategy should be used to direct and inform the creation and maintenance of the execution model. Issues associated with size and complexities require that a decision model (2.3.2) be constructed and maintained over the timeline of the execution model.
• • Safety (2.0.1) – Should each ICP be associated with safety analysis and justification? It is not clear that such requirements are applied to ICPs in current practice.
• • Risk (2.0.2) – In complex ICPs, the form and nature of risks are multi-dimensional, crossing many discipline and healthcare boundaries. Many of these boundaries are indistinct. The risks associated with reliance on individual ICP elements require the reappraisal of existing risk models.
• • Supervision (7.4.2) – The act of supervising someone or something [607]. A supervisory model (7.4.1) is a scheme for specifying and enforcing supervisory policies. There are several possible supervisory models which are determined by the clinical severity and the capability and capacity at a point in time. In a quiescent state, the supervisory model is determined by the core service provision and the requirements of the ICP. During a civil emergency, a surge in demand requires triage of the casualties. A finite set of healthcare resources are prioritised. Such circumstances present clinicians with difficult choices, choices they would not make under core conditions. Selecting a supervisory model leads to the selection of associated metadata and data.

25.2.1. Healthcare as a Complex Adaptive System

A healthcare system is context-aware (6.0.3) as it adapts its core and surge capabilities to the operational conditions. We should not lose sight of the people as they are the primary resource in providing resilience. Healthcare as a Complex Adaptive Systems (CAS) (3.8.2) exhibits many degrees of freedom. It is a multi-dimensional problem consisting of many metamodels, each competing for resources. It is this competition for resources that we explore in this application area.

The Healthcare CAS exhibits emergence and self-organisation [376]. It can be sub optimal in that it does not have to be perfect in order for it to thrive within its environment. The greater the variety within the system the stronger it is [54]. The ways in which people (and increasingly AAs) in a system connect and relate to one another is critical to its survival.

The Shipman case exposed the threats that arise through malicious usage [581], [582], [583], [584], [585], [586]. These threats are amplified and may be undetected and undetectable when combined with a weak security model. It should not be assumed that a Healthcare CAS is safety benign.

25.2.2. Data in Healthcare

An awareness of data-related issues promotes a more comprehensive assessment of safety risk in a healthcare setting. The data metamodels discussed above must take these issues into account so that appropriate metadata and data can be employed for CCPs and appropriate assurance arguments and evidence provided. Table 25.6 describes the typical issues that can arise in the healthcare context.

Table 25.6.

Typical Issues that can arise in the Healthcare Context

25.2.3. Operational Modes

Even in the most challenging circumstances, in a natural disaster, famine, war or epidemic, healthcare is required. The operational environment determines the sophistication of healthcare provision. In modern times casualty survival rates from conflict zones have dramatically improved through increased understanding of trauma injuries, first aid, stabilisation and evacuation to established (remote) medical facilities.

As a CAS, healthcare, the healthcare system and healthcare provision exhibit the characteristics of a wicked problem. It is difficult or impossible to solve because of incomplete, contradictory and changing requirements that are often difficult to recognise and are resistant to resolution. However, individual elements, equipment and even instances of specialist departments will possess a range of operational modes (11.6.1).

25.2.4. Common Cause Failure

Increasing reliance and trust in IT systems creates dependency. Clinicians are placed under immense stress when the infrastructure technologies (4.0.2) or data ecosystems (4.0.1) fail. Many failures in the operational domain may be inconvenient at the time of failure. Some healthcare provision cannot be delayed. A failure in the operating theatre during a critical procedure could be life-threatening. CCF (2.4.8) can be caused by deliberate misuse. A tiny minority of Clinicians and healthcare professionals have abused the trust we place in them. Shipman [581], [582], [583], [584], [585], [586] is an example of a rogue Doctor (GP) who killed an estimated 250 of his patients [278].

Thalidomide is an example of a pharmaceutical CCF. It was used to treat nausea and to alleviate morning sickness in pregnant women. In 1957 between 5,000 and 7,000 infants were born with phocomelia (malformation of the limbs), due to thalidomide [633].

25.2.5. Single Point of Failure

On 28 November 2018, an electrical cable fault led to a power failure at the University Hospital Southampton [415]. This failure affected the emergency generator, which failed to start. Staff handled the situation calmly and with complete professionalism to provide care in difficult circumstances. This SPoF (2.4.9) example illustrates that emergency preparedness and resilience, and a response system are required to address multiple levels of failure [415], [78].

25.2.6. Patient Identity

The acceptance of digital technologies by society creates expectations for the use of these technologies in healthcare. The healthcare system faces pressure to adopt digital technologies whilst retaining an ability to function without them on their failure. A patient clutching their ‘paper’ notes provides a strong association. In contrast, digital technologies rely on associations based on digital identity. These identifiers afford the opportunity to sense-check patient data. For example, blood type should not change; a simple test could be used to confirm that the sample presented for analysis was the same as that in the patient's digital record.

Therefore, identity provides one means of seeking confirmation, and hence adds a level of confidence to the test results. Confirmation procedures also consume resources. They also reduce the risks associated with clinical procedures, for this example, blood transfusion. The digital patient record provides one way to introduce a range of rule-based alerts.

25.2.7. Healthcare as a Data ‘Container System’

Healthcare infrastructure contains administration, utilities, services and housekeeping. Secondary and tertiary healthcare requires pharmacy, pathology, imaging and mortuary services. The Hospital is served and supported by vendors providing pharmaceuticals, consumables and services. The healthcare system element Hospital is defined for this application area as follows:

• 1. Objective: healthcare provision as a container of services and facilities to support the ICP instances drawn from a catalogue of ICPs;
• 2. Functions and elements: these are described in each ICP and confirmed in its instantiations as required by the Clinician and health service workers to support the individual patient and their specific needs (including referrals, technical and operational elements);
• 3. Boundary: several concentric boundaries include the physical Hospital, the consulting rooms, treatment rooms, imaging suites within the context of secondary and tertiary healthcare provision. The entry point for a hospital is assumed to be a referral from the GP (primary healthcare). The point of exit is discharge back to primary healthcare.

  A non-exclusive list of interacting systems include patient records (medical history), pharmacy, pathology, imaging systems.

• 4.
  Interfaces:

  • (a)
    Physical (interacting systems): a non-exclusive list includes patient records (medical history), pharmacy, pathology, imaging systems;
  • (b)
    Functional (input and output) interfaces: identified in each ICP;
  • (c)
    Non-functional: performance criteria dependant on the ICP, the patient and the nature of the condition. Many conditions require timely intervention.
• 5. Environment: part of healthcare provision as defined by Public Health – England;
• 6. Safety measures: the Care Quality Commission monitors patient safety and standards of healthcare provision.
• 7. Assumptions: adequate capacity and capability are available to satisfy the instantiations of the ICP for each patient.

25.2.8. ICP Metamodel

The following presents an idealised form of an ICP metamodel. Clinicians amongst our readership are invited to correspond with the authors on any matters arising.

Assumption 25.2 An ICP can be formalised into a Metamodel. —

An individual ICP (25.1.2) is sufficiently well defined so that its requirements can be satisfied within the definition, capabilities and capacities of the healthcare system (25.0.3), its boundaries (2.1.12) and any safety-related application conditions (SRAC) (7.9.1).

Assumption 25.3 A catalogue of ICPs and their Metamodels are defined. —

Each ICP (25.1.2) is defined within a common framework so that requirements placed on the capabilities and capacities of the healthcare system (25.0.3), its boundaries (2.1.12) and safety-related application conditions (SRAC) (7.9.1) can be adequately assessed.

A narrative outline of the ICP begins with a Patient appointment with a GP. The GP makes an initial diagnosis, perhaps requests blood tests, before referring the Patient for specialist care at a Hospital. The Patient is seen at the outpatient clinic, assessed and placed on one or more ICPs. Treatment may require the Patient to be admitted to the Hospital. For this narrative, the Patient is assumed to require treatment under several ICPs, one of which is a ‘management’ ICP where the best interests of the Patient are coordinated between any possible competing treatments and their overlapping side effects. The instantiation of an ICP is initiated by a Clinician. The management ICP provides a framework and hierarchy, that is populated from the ICP catalogue. A Clinician is appointed as the owner of the ‘management’ ICP to ensure oversight of the subordinate ICPs (to ensure non-interference and execution maintains a proper sequence). On completion, the Clinician discharges the Patient to the GP (Primary Care).

An outline of an ICP metamodel includes the following:

• 1. Objective: an extensive list of healthcare requirements, components, data and treatments required to provide care. The ICP metamodel is the basis of a hierarchy, with the highest level addressing the management of the collected ICPs and the lowest level showing individual ICPs, diagnostic tests, medical imaging, treatments and procedures;
• 2. Functions and elements: each ICP encapsulate relevant diagnostic tests, medical imaging, treatments and procedures, implying multiple transformations of the data;
• 3. Boundary: an interrelated set of ICPs will include physical, temporal, spatial data storage and access as well as economic constraints. These also address other interacting ICPs and management of side effects of treatments and procedures;
• 4.
  Interfaces:

  • (a)
    Physical: the implementation of the ICP requires the physical collocation of the Patient and the healthcare provision. Only limited services can be provided outside the healthcare system;
  • (b)
    Functional: (input and output) addressing sequencing and selection of diagnostic tests, medical imaging and timely provision of treatments and procedures;
  • (c)
    Non-functional: are addressed in performance criteria set out in Section 25.1.5;
• 5. Environment: each clinical condition may result from a wide range of environmental factors, such as nutrition, public health, vaccination, genetic factors as well as exposure to disease. Data needs to be collected for all these elements. Treatments may require outpatient, inpatient or isolation;
• 6. Safety measures: as ICPs evolve, after the necessary relevant iterations, the definition of the safety requirements identified by a suitable and sufficient risk assessment process;
• 7. Assumptions: the primary assumption is the widespread adoption of ICPs as the basis of clinical practice in healthcare provision.

Collections of ICP metamodels represent the basis of forward resource and capacity plan for healthcare provision. The ICP metamodel requires a catalogue Identity. The instance of the use of a catalogue entry is associated with the Patient (and the Patient Identity). These form the foundation of the traceability based on Used-By (7.5.3) and Controlled-By (7.5.4) references. This hierarchy forms the basis of a resource and sequencing plan.

25.2.9. ICP and the DSM

The ICP catalogue contains a wide spectrum of healthcare provision. The required capacity and capability can be calculated from the summation of the instantiations of the ICP assigned at an instance in time. Strategic planning requires an understanding of the utilisation of specific healthcare elements, and their associated staffing resources.

25.3. Metamodel Integration

At one extreme, an ICP metamodel is a form of automation [41] that is confined to actions described by a pre-determined set of clinical practices. At the other are learning systems that adapt their behaviour in response to changes in the operating environment – its context.

It is context (circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood) is not limited to clinical delivery; it also reaches into the community. In contrast, the engineered system (1.5.6) reflects the designer's (2.0.6) expectation of the operational environment. For the clinician, the metamodel is a combination of ICPs based on the needs of the patient. This position is further complicated by what learning systems ‘understand’ as the basis for the formulation of its response.

What happens if changes in clinical practice require a new generation of ICPs to provide fit-form-function replacements? Healthcare workers are humans that have a wealth of experience, training and competence to execute ICPs. In this sense, each healthcare worker comes with availability, capability and capacity connected via formal and informal human networks. Therefore, an ICP metamodel contains unused capability and capacity. Taking a SoS (3.0.2) perspective, this residual and (possibly) unsecured functionality represents one or more emergent properties, perhaps with unintended consequences.

Metamodels are multi-dimensional. There are strong parallels with autonomy [43] and its use in Industry 4.0: [291], [389]

• •The vertical integration of flexible and reconfigurable ICP metamodels within the healthcare system;
• •The horizontal integration of inter-model chains and networks;
• •The care life cycle integration of digital end-to-end ICP activities across the entire chain of both the product and the associated ICP elements.

25.4. Vertical Integration

Vertical integration can be used to describe how a metamodel grows through the acquisition of upstream and downstream elements. This ability requires vertical integration of flexible and reconfigurable metamodels.

These requirements also apply to ICP metamodels. Consider a basic ICP that consists of GP health screening, referral to secondary care and treatment, leading to discharge to primary care. In past implementations, the input would be wholly dependent on awareness of the patient to seek treatment. Two examples of healthcare vertical integration are explored here. Firstly, a vaccination programme is used to inoculate children against a range of treatable and childhood diseases. This has the effect of reducing future demand by reducing or eradicating the incidence of those diseases. Secondly, a programme of health screening on at-risk groups is used to identify conditions in their early stages, where they are more treatable.

Figure 25.3 illustrates vertical integration using a simplified supplier, secondary and tertiary delivery, and primary provision model to facilitate the integration discussion.

Figure 25.3.

A Simplified Supplier, Secondary and Tertiary Delivery, and Primary Provision Model

25.4.1. Backward (Upstream)

A healthcare provider implements upstream expansion by purchasing the pharmaceutical supplier. Upstream integration provides more data, command and control of the upstream systems. Upstream integration is consumption-led and may lag behind demand.

25.4.2. Forward (Downstream)

A healthcare provider implements downstream expansion by purchasing respite and recovery care facilities. Downstream integration allows the healthcare provider to admit more patients into hospital as they can be moved on more quickly to respite and recovery care. Downstream integration is demand-led. Sudden (step) changes in demand may create instability and lead to over and under admission.

25.4.3. Balanced (both Upstream and Downstream)

A healthcare provider implements balanced expansion by purchasing the suppliers and respite and recovery care facilities. Balanced integration contains a balance of consumption, demand and ‘damping’ (stabilising) elements. Balanced integration may implement complex functions analogous to the Proportional-Integral-Derivative (PID) pattern in control theory. Other patterns also apply. In a control system example, balanced integration is where the controller adapts to the operational requirement adjusting the input sensor rate to the best fit to the PID set-point and deviations from it. At the same time, the controller calculates a predictive output anticipating the effort required to deliver the capacity and capability of healthcare provision.

25.5. Horizontal Integration

A healthcare provider implements horizontal integration through changes in capacity and capability. Horizontal integration combines an array of identical balanced healthcare resources. These may be used to create load-balancing across the multiple healthcare regions. This implies the use of supervision [607] over the array of healthcare regions. This also implies that horizontal data transformation and vertical abstraction transformations need to be considered when identifying Critical Control Points (CCP) (8.5.1) [459] to ensure that operational processes do not introduce accidental autonomy [231].

Paths (physical product or data) may involve multiple sources and multiple sinks. These issues are compounded when these paths are dynamic. This dynamism is not limited to changing numbers of sources or sinks or processes, but also to changes in demand (capacity), availability and capability (such as data fusion). Paths may be transient synthesised on demand for single-use and then discarded.

For example, one implementation of dynamic data paths (8.8.1) would be to use a standardised library of elements across a node (15.6.1) and link (15.6.2) network. Redundancy can be provided through reconfiguration where nodes are unavailable. In network theory (S.15.6), links can be assigned a weight; path management is used to identify a route with the least weight. Implementation requires the definition of an Identity Model and Security Model.

25.6. ‘Product Line’ Integration

A ‘product line’ can be defined as a set of systems sharing a common, managed set of features that satisfy specific needs and are developed from a common set of core assets in a prescribed way [113], [463]. Here, we reuse metamodel elements. One approach to the development of ICP metamodels is to adopt a product-line approach. A product-line [468] development employs a life cycle model and the process it contains to develop the system definition into the system. The defined set of features can be reused within defined fit-form-function contexts.

ICP metamodels introduced via a product line approach present two potential threats. Firstly, that the product line replacement adds residual and unsecured functionality, and secondly that the system has grown organically and cannot support digital end-to-end engineering activities with a reasonable certainty of outcome. This may lead to the Clinician being presented with a range, sequence and timings of data in an ‘unfamiliar’ environment that cannot be managed safely. When things go wrong with the ICP metamodel or its implementation, the Clinician is relied on to retrieve the situation.

25.7. Cyber Physical System Threats

When deciding what steps to take to prevent and respond to threats, we might immediately focus on the threat of hacking. However, the range of threats systems face is much broader than this, encompassing anything that can adversely affect their operation, including theft, destruction, disclosure, modification or unauthorised access.

We modify the definition of threat [642] to be ‘an actor (1.0.1) likely to cause (2.1.13) one or more hazards (2.1.10).’ This definition includes autonomy within the actor. Changes in system context (6.0.1) require resilience and robustness from the autonomy to withstand threats arising from identity, security and sneak attributes.

25.7.1. Identity

Threats may arise from identity error, duplication and missing identities. A malicious, deliberate identity-based (spoofing) act could be used as a way to gain control of the system, entity or the healthcare intended for another. The misidentified individual is at risk from the treatment intended for the original patient. It cannot be assumed that identity theft applies only to users as it applies equally to actors, systems, assets, data and data paths (def). One way to counter identity-based threats is the use of a formalised and managed identity model (3.4.2). An identity model is a scheme for specifying and enforcing identity policies.

Error, omission or duplicate identities in dynamically reconfigurable systems present significant system safety management challenges. These issues are compounded where an ICP metamodel relies on people as resources. Joiners and leavers are one way of satisfying operational demand, including capability and capacity. Joiners and leavers create issues associated with changing, and hence with dynamic identity sets.

25.7.2. Security

A security model is a scheme for specifying and enforcing security policies. It uses a formal model of access rights. Authorisation (3.3.3) is implemented using identity and is enforced through authentication (3.3.4). Potentially, failures of cyber-security provide the intruder with unbridled access to a system. Identity and its management is a critical feature of both Data Safety (DS) and information security.

Should each instance of an ICP metamodel be assigned its own unique identity? Healthcare delivery typically uses identities (authentication and authorisation) for access to controlled drugs, but not. Clinical emergencies require ‘super-user’ rights as delays in the provision of treatment may prove fatal. Beyond emergency medicine, more extensive systems require security models, and therefore each actor or ICP metamodel requires one or more identities.

25.7.3. Sneak Attributes

Systems may contain sneak attributes (15.8.2) that cause (2.1.13) unwanted actions or inhibit desired functions [440]. Sneak attributes arise where the physical realisation contains many more characteristics than the logical representation. Examination of simple network switches reveals capabilities to separate network traffic using configuration data. Errors in the configuration may permit ‘mixed network’ traffic, compromising the intended separation and creating additional paths between entities.

Sneak attributes may include the following:

• •Paths: unintended paths within a system, the ICP metamodel and its external interfaces.
• •Timing: unexpected interruption or enabling of a function (or service) due to timing problems which may cause or prevent the activation or inhibition of a function (or service) at an unexpected time.
• •Indications: undesired activation or deactivation of a (status) indication which may cause an ambiguous or false display of the system operating conditions.
• • Identity: incorrect or ambiguous identity of a function (or service) which may cause actor error through inappropriate control activation.

As complex networks of Autonomous Agents (AA) (1.0.2) are embedded within ICP metamodels, one possible emergent property is the ability to create accidental autonomy [231] via sneak attributes.

25.8. Healthcare Incident

Under normal conditions, thankfully, major incidents are rare. Insight into major incident response is provided in the ‘Emergency Preparedness, Resilience and Response Framework’ [211] and ‘Clinical Guidelines for Major Incidents and Mass Casualty Events’ [115]. The reader is cautioned that [211] and [115], although modest in size, are intended to be used during a major incident. A word of caution, some readers may find the choices, to be made during emergency response, difficult to read in [211], [115].

Section 1 of the Civil Contingencies Act (CCA) 2004 [261] provides a definition of an ‘emergency’ as

• (a)an event or situation which threatens serious damage to human welfare;
• (b)an event or situation which threatens serious damage to the environment;
• (c)war, or terrorism, which threatens serious damage to the security (of the nation).

The scale of the incident drives the demand for emergency responders and healthcare provision. The Incident Classification used by the NHS is shown in Table 25.8 [211].

As an incident evolves, it may be described in terms of its level, as in Table 25.9 [211]. These levels are used to determine the coordinated response taking the overall NHS as a viewpoint. For example, a Level 1, Critical Incident can be managed by a local health provider organisation. As the incident level increases, so does the demand for healthcare resources, and therefore requirements for higher-level coordination and management. Data infrastructure must be able to support surges at all levels. CCPs may be different at different levels. CCP trade-offs and strands of data provision for some actions may occur as incidents progress through the level.

Table 25.9.

NHS Incident Level

A combination of Incident Class and Incident Level provides an indicator of the competition between core and incident demand and therefore is the determinant in the competition for healthcare resources. The immediacy of the emergency response requires pre-planning and rehearsal.

25.8.1. Multiple Safety Risk Models

This book has presented a consistent world view of prevention and operational management. In this world view the context is documented and the system is defined, and safety analysis identifies hazards which are either removed or mitigated and managed. This is only one side of the coin; on the other side the incident has happened or is still happening. In this context of the incident and post-incident recovery, several interrelated safety risk models (SRM) (2.6.2) are active concurrently.

25.8.2. Major Incident

Road Traffic Incidents (RTI) occur frequently and range from minor damage to the vehicles to major incidents involving multiple vehicles (and possibly hazardous loads). Major incident response (S.13) invokes the provisions of the Civil Contingencies act [261], [262] in the execution of a rehearsed pre-planned response (S.13.1.2).

Risk-based response planning considers how the SRM is changed by the incident and the response to it. The incident response creates concentric zones around the geographic location(s) of the incident. In traversing each zone towards the epicentre the risk profile increases, additional hazards need to be managed and therefore require different SRMs. Based on the Common Recognised Information Picture (CRIP), the Incident Manager creates and maintains the Incident Record (S.13.1.3). The Civil Contingencies Guidance [262] describes the required organisation of the emergency services (Police, Fire Brigade and Ambulance). Table 25.9 describes the NHS Incident Level as the basis for the mobilisation of healthcare emergency response.

Once a Major Incident is declared, the organisation and responses described in the Civil Contingencies act [261], [262] are instantiated. One aspect is the Incident Control Team which focuses on four main functions:

• •Operations – ensure that all operational staff, including the clinicians, have been given direction and to monitor their progress in achieving these objectives.
• •
  Planning – ensure that accurate and up-to-date information is available

  • –
    Casualties awaiting treatment
  • –
    Resources available
  • –
    Any anticipated resource deficits
• •Logistics – to acquire and allocate resources (identified by the planning function) so that the actions tasked by operations functions can be carried out.
• •Safety – to ensure patient and healthcare provider safety throughout the incident.

Typically, the Incident Control Team comprises:

• •A manager (Incident Commander)
• •A nurse
• •A doctor
• •A ‘loggist’ and administrative support (to maintain the incident log)
• •Communications Officer

The Incident Control Team maintains the situation awareness of the following:

• •number of functional operating theatres available
• •number of staffed ITU beds available
• •number of other acute admissions
• •overall bed availability
• •number of staffed functional imaging suites (e.g. X-ray rooms)
• •Blood Bank status

The planning for a major incident consists of paper plans and logs (although electronic copies may be available). The overriding assumption is that during the major incident, there will be no guarantee of information system support. Therefore, paper forms and logs have been prepared. In these circumstances, data content is managed manually through pre-defined process, roles and responsibilities.

25.8.3. Mass Casualty Incident

The time and location of the Mass Casualty Incidents (MCI) is unplanned. The response to it is both planned and rehearsed. Hazardous Materials (HAZMAT) and Chemical, Biological, Radiological and Nuclear (CBRN) events present significant risk to the responders, to the healthcare providers, and to the wider society. Consider a HAZMAT event as the result of a Road Traffic Incident involving a chemical tanker and other road users. The Police manage the traffic excluding other road users from the scene. The Fire Service establishes a chemical decontamination station. Fire officers in protective suits extinguish the fire, and prepare to evacuate casualties. Paramedics (also in protective suits) assess the casualties. Figure 25.4 [211] illustrate three zones each with different risk models.

Figure 25.4.

Mass Casualty Event

Hot Zone: contains the Point of Emergency (PoE), the Triage Point (T) and forward First Aid (F) point. P1 (severe) casualties are the most seriously injured and are typically unconscious. P2 (moderate) casualties are immobile and require assistance during their evacuation. P3 (mild) casualties can walk from the PoE.

Warm Zone: contains the forward Casualty Clearing Point (CCP), a triage point (T) and Life-saving interventions (L). Casualties are re-assessed and progress across the warm zone through the casualty decontamination area. Once decontaminated, casualties are transported to Hospital.

Cold / Clean Zone: provides Advanced Medical Care (A). On arrival, triage (T) is used to re-assess the casualties. On admission, each casualty is assigned a clinical team and a management ICP.

MCIs require deployment of paramedics and clinicians. A medical team is established in the warm zone. The type and nature of the emergency create the demand and requirements placed on the healthcare system requiring management and coordination. Significant incidents require regional and possibly national coordination.

Once the incident has occurred and a MCI declared, the time and location are known. At this point little data is available. Almost nothing is known about the casualties. How then is sufficient data generated to facilitate the effective management of the incident aftermath? How is sufficient data collected to undertake lessons learnt analysis? In this application area we ask the Reader to consider how the incident data (information) flows across the zones (T-axis) and through the organisations (A-axis). How is capacity and capability measured? Which data, metadata and metamodels are used for dynamic resource allocation?

25.8.4. Flu Pandemic

Influenza (flu) is an infectious disease caused by an influenza virus [336]. The severity of a pandemic varies; for example, the Spanish influenza (virus H1N1) [484], [637], [1] in 1918 (with 40-50 million deaths attributed) had a pandemic severity index [485] of 5, inducing a 30% sickness rate (with a 2% case fatality rate) and a three-week length of illness. The Spanish influenza was unusual in that 99% of deaths occurred in people under 65, with more than half in young adults of 20 to 40 years old [578].

Flu will affect healthcare workers and therefore reduce the capacity and capability of the healthcare system. Flu is a foreseeable event; it is seasonal and has the potential to be a pandemic. Flu will also affect the wider population. At-risk groups, those with existing conditions and older age groups are the most vulnerable.

Typically, flu is more prevalent in the winter. What cannot be predicted is the severity of this season's outbreak, and therefore its impact on the healthcare system. Once established, the flu outbreak reduces capacity across all human activities. Under these conditions, the healthcare system experiences increased demand with reduced human resources (due to illness). The occurrence of a major incident under these conditions is likely to ‘break’ the healthcare system. Under such circumstances, additional winter environmental factors, such as cold, snow, rain and ice have an amplified effect.

25.9. Summary

Healthcare is the most complex area addressed in this book. It is a data-rich environment and data dependent. Often healthcare delivery is time critical; it experiences high demand and under surge conditions is reliant on individual or groups of human healthcare workers. These surge conditions arise from multiple sources, and while coping mechanisms are planned their occurrence is influenced by a wide range of external factors. For example, a major incident may occur during a period of already high demand.

Resilience is provided through the excellence of individuals or groups of human healthcare workers, typically when the supporting technologies have failed or are not available. The healthcare domain contains multiple stakeholders, multiple disciplines often grouped in silos. The domain contains multiple DSMs, RMMs and Safety Risk Models (SRM) (2.6.2). Technology can offer support, but solutions are not to be found solely in the application of technology. The role of technology will evolve with time. EHR are a good start to support decision models and activity planning (such as ICPs). We see a role for data, metadata and metamodels, but caution that healthcare is vast in scale, rich and complex. There are no easy solutions.

In this final paragraph, the reader is encouraged to consider how the SRM is changed by large changes in demand. These changes induce secondary effects such as demand for consumables (e.g. Personnel Protective Equipment). They also induce tertiary effects along the supply chain. What ‘best fit’ set of decision models would be appropriate. How would these be modelled in the DSM?