Stakeholder Identification and Use Case Representation for Internet of Things Applications in Healthcare

Abstract

We describe the initial process of eliciting requirements for an Internet of Things (IoT) application involving a hospital emergency room. First, we discuss the process of modeling IoT systems through Rich Pictures and Use Cases. Then, we demonstrate how these can be used to model emergency room systems. Then we create Use Case models for a particular situation – a patient potentially suffering from a myocardial infarction. Finally, we discuss generalization of the specific case to a broader hospital wide system.

We believe that such an approach can lead to increased efficiency, increased safety, and better tracking of people, equipment and supplies.

I. INTRODUCTION

THE Internet of Things (IoT) is a collective noun for an instance of any system that is connected to the Internet for enhanced control, data storage, and analytics. IoT is simply a distributed system with a heavy emphasis on sensing, computing, and communication. Typically, a Network of Things, of which the IoT is one type, includes sensors, actuators, and processors, where each sensor and actuator is defined by a concise set of primitives (proposed by Voas [1]) necessary to determine the trustworthiness of a specific ‘network of things’ in specific contexts and environments:

1. snapshot - an instant in time,

2. environment – an operational profile,

3. cost –an estimation or prediction,

4. geographic location – physical place,

5. owner - person or entity, 6. device_ID – a unique identifier.

While there are more ingredients in Voas’ model that deal with issues such as big data, the software that fires off actuators or transactions, computing equipment and software, scalability and heterogeneity, it is clear that networks of tagged and sensed artifacts in the workflow of a hospital setting can offer substantial cost savings and potential life-saving benefits. Since emergency medicine occurs in a mission critical, real-time environment, the first primitive above, snapshot, is critically important to trustworthiness when deploying IoT technologies in hospitals. After all, people are born and die at specific times, and emergency care seeks to increase this differential.

Healthcare is an important IoT applications domain, which can be characterized in three settings: acute care (hospital), long-term care (e.g. a nursing home) and community-based care (e.g., home care). Additionally there are three application scenarios for healthcare systems: tracking humans, tracking things or tracking both.

The combination of setting type and system classes yields nine general classes of healthcare IoT systems [2]. For all of these systems, general goals (outcomes) include: best health outcomes, safety, privacy, and efficiency. But our main interest in this paper is for Emergency Room (ER) systems -- i.e. acute care systems -- that involve tracking people and things. Such a system can use bar coding, video surveillance, Radio-frequency Identification (RFID), location sensing, etc., to enhance the patient experience and to increase efficiency and safety.

In this work we seek to show how to identify stakeholders and model their activities in the ER using Rich Pictures and Use Cases. We will also explore the application to the larger hospital system, tracking the patient who is admitted. The combination of these two techniques may lead to improved requirements elicitation for certain IoT healthcare applications.

II. PREVIOUS AND RELATED WORK

Surprisingly, very little work exists on even modeling hospital information systems using traditional Unified Modeling Language (UML) or Systems Modeling Language (SySML) approaches for the purposes of requirements elicitation. In one such case, Batarseh et al used activity diagrams to model patient flow in an emergency department to improve workflow. They also noted that conceptual modeling in healthcare settings, particularly to facilitate communication between stakeholders, has received little prior attention [3]. Even less work exists on using UML or SysML for modeling hospital systems in conjunction with the IoT. Several notable exceptions are mentioned below.

Lahboube et al introduced a system of systems based paradigm for requirements elicitation in healthcare information systems and used SysML as a modelling language. They also demonstrated their approach on a medical billing system [4].

Winter, Alfred and Wendt presented a UML-based ontology for describing hospital information systems architectures. Their ontology comprised three modeling layers: the domain, logical tool layer, physical tool, and defined the relevant components for each layer [5].

Shiki et. al. were able to model a hospital-based cancer registration processes using UML for the purposes of identifying workflow. Using their UML model and the derived work functions they were able to identify optimization opportunities [6].

Finally, Jun et al investigated the roles of different diagram types in process modeling for various healthcare systems. Their purpose was to identify those diagrams that were simplest to understand by the healthcare personnel. They concluded that UML was desirable in modeling complex hospital centered tasks and functions. [7]

There are several published works and patents on tracking patients, devices and supplies. For example, Jara et al [8] presented an architectural model for IoT systems in healthcare applications with particular emphasis on tracking patient movement and on security of the system [9]. Their emphasis was on applications in assisted living situations, where the complications of employing tracking technologies in the presence of high radiation medical devices (such as MRI machines) is not present.

Luo et al [10] conceived an architectural framework for remote tracking of patients using an IoT. Their focus was on solving the problem of long range communications of data – a problem that we do not address. In our scheme it is presumed the control structure only requires local, onsite data communications.

Catarinucci et al [11] provide a comprehensive architectural design for a general system using RFID technology. They also implemented two specific cases, one dealing with monitoring of patient biometrics signs and the other with identifying when a patient has fallen using accelerometer data.

Gao et al introduced a real-time patient monitoring that “integrates vital signs sensors, location sensors, ad-hoc networking, electronic patient records, and Web portal technology to allow remote monitoring of patient status” including at disaster scenes [12].

Lorincz et al describe another system called CodeBlue that dynamically integrates sensors and other wireless devices in a disaster response setting. They also developed an RF-based technology called MoteTrack that is used to locate responders and patients within buildings during a disaster [13].

Chew et al proposed a hybrid system using the global positioning system (GPS) and cellular mobile network infrastructure to track patients. They also demonstrated a prototype of their system under a variety of operating conditions and scenarios [14].

Finally, Sato el al [15] reported on a deployed, real-time location system at Kyoto University Hospital. The system employed hand-held barcode scanners, Bluetooth transmitters, a beacon relay system, and barcode tags on patients, nurses and supplies to track workflow. The researchers did not report any real-time positional tracking (e.g. to locate individuals), focusing instead on time to visit the patient and frequency of visits to patients.

In addition several US patents (and, presumably, non-US patents) have been filed involving various kinds of location tracking technologies for people and things in hospitals and other environments, including disaster scenes using wireless and other technologies (e.g. U.S. Patent Nos. 5,458,123, 5,153,584 and 6,083,248).

III. MODELLING SYSTEMS

A first step in requirements engineering for any system is the creation of a high level systems model. This model will help identify the set of people involved in the system (stakeholders) and define the system boundary – the direct and indirect interactions with other entities. The high level systems model is enriched when domain terminology is accurately defined, which requires deep interaction between the requirements engineers and the subject matter experts (e.g., in the case of a healthcare system, doctors and nurses among others).

The requirements engineer, in concert with these stakeholders, then develops a set of scenarios that tell “stories” of how a system will be used from the differing points of view of each of those involved in the system. These so-called Use Cases provide the basis for later requirements elicitation, elaboration, representation and analysis. Use Case definition, along with other forms of requirements discovery, forms the basis of effective requirements elicitation and validation.

A. System Boundary

A useful approach for system boundary and stakeholder identification in an IoT involves the use of Rich Pictures [16]; that is, cartoon-like drawings based on informal rules [16]. For a particular IoT, a Rich Picture depicts all of the people (and systems and things) that have a direct interaction within and without the system. The people and systems are represented by stick figures (whether they are people or other systems, they are referred to as “actors”), and things are represented by icons. For example, consider a simplified Rich Picture for a hospital ER (Fig. 1).

Fig. 1.

Simplified Rich Picture for a hospital ER.

Here, only the actors of patient, nurse and ER doctor are shown. Although there are more than one of these actors in a typical ER, conventionally, only one actor in a role is depicted. The simple interactions between these actors are shown by directed arrows, where an arrow represents affectation. In this case, the interactions are two way – it is also possible to have one way interactions. In the figure, interactions with an IoT are not yet shown. It is also conventional to show a cloud along with each actor depicting one principle concern (goal) for that role. Elaborating on the Rich Picture insures that all stakeholders in the system and their interactions and principal concerns are identified, and can be useful for later acceptance test development. The Rich Picture for the ER will be revisited later in this paper.

B. Use Cases

Once a fully elaborated Rich Picture is developed a set of Use Cases can be elicited from the stakeholders for the system. Stakeholders include a representative (or representatives) of each of the human actors shown in the Rich Picture and other stakeholders that may not be specifically identified in the Rich Picture (e.g., maintenance engineers, government regulators).

A Use Case is an example of how a system is used under different scenarios of operation and there are different forms of representation. While narrative descriptions of Use Cases are common (often represented as User Stories) a diagrammatic representation can be made more precise. A Use Case diagram represents a Use Case using stick figure actors and a bubbles describing the particular use. Directed arrows indicate the participants in a particular use. For example, consider a Use Case for the simplified ER system (Fig. 2).

Fig. 2.

A simplified Use Case diagram for a hospital ER.

A Use Case Diagram is usually accompanied by a textual description. For example, for Fig. 2 the following narrative applies:

This Use Case involves a particular nurse whose role is to triage incoming patients. Patients can be walk-ins or arrive by ambulance. The walk-in patient comes to the ER via a private car or vehicle other than an ambulance. The patient registers with the ER staff and informs the staff of his problem. If an urgent case walks in, such as a patient complaining of chest pain who demonstrates symptoms of a myocardial infraction (MI), this patient is immediately taken from the triage area to a place in the ER where he can be immediately evaluated and begin treatment. The non-urgent patient will be assessed by the nurse in the triage area. Vital signs, brief history and description of patient complaint are taken by the nurse, who then determines where the patient should be placed in the ER and how urgently this patient needs to be evaluated by the ER physician. This is a simplified triage description – there are many more nuances that could be explored.

Triage can occur for patients brought to the ER by ambulance, with a nurse determining if this patient is an urgent case who needs immediate attention, or one that can be admitted to the ER but can wait to be seen by the ER physician. There may be internal rules as to how the nurse can receive a patient brought in by ambulance, for example some hospitals may require a patient brought in on a stretcher can only be moved to another stretcher, but in other hospitals the patient could be taken off a stretcher to wait in a chair until it is his turn to be examined. The transfer from stretcher to chair would only occur if the patient is stable enough, and considered non-urgent.

Use Cases are important because they aid the requirements engineer in discovering essential behavior in the stakeholders’ own words. This interaction helps elicit hidden assumptions, validates system behavior and identifies additional aspects of the operational environment, thus helping to precisely define the system boundary. In an iterative development lifecycle these Use Cases will become increasingly refined and detailed as the analysis and design workflows progress. Other diagrams are then created to describe the behaviors defined by each Use Case.

IV. REQUIREMENTS FOR AN EMERGENCY ROOM

It is important to model any system by including relevant actors, defining Use Cases from the perspective of each actor, and then converting these Use Cases into system requirements. In the foregoing example, we generate a semi-complete Rich Picture model for an ER then create sample Use Cases to show how the activities are elaborated.

A. Domain Model

To begin our system modeling for the ER, we enrich the partial Rich Picture shown in Fig. 1 for a larger urban teaching hospital (Fig. 3).

Fig. 3.

Enhanced Rich Picture for an ER.

Here there is an interprofessional team of health care providers who work tirelessly to save lives. The interprofessional team includes first responders, nurses (including advanced practice nurses) with various roles, ER physicians, physician assistants, respiratory therapists, mental health professionals, and social workers. These actors interact with various equipment, trackable (and non-trackable) supplies and medical records in the ER.

First responders care for the patient pre-hospital admission, stabilizing and transporting the patient to the ER. The first professional a patient usually meets in the ER is the triage nurse if the patient walks in or the triage or other ER nurse if brought in by ambulance.

The interprofessional team can also include numerous students, including nursing students, and medical and surgical residents of different years and specialties. Given that any specialty could be needed at any time, medical physicians and surgeons are never far away, and always have someone on call to respond in a timely manner. Many hospitals also have partnered with larger health systems to share resources, and make referrals a smoother transition. For example, a smaller rural hospital may partner with a larger specialty cancer center.

Equipment in the ER, which is represented by a single icon in Fig. 3, covers a wide spectrum including transportation, treatment, and monitoring equipment. There are stretchers, wheel chairs, and patient chairs; depending on the patient need, patients will be found in any and all of these. Monitoring equipment for the heart is mounted to the walls in the cubicles of the ER and extra portable units are usually nearby for overflow of patients on any given day. All ERs have an organization structure, with critically ill patients (e.g., MI) in one section and ambulatory, non-urgent patients (e.g., ankle sprain) in a different section. The monitoring is very different for each patient, as some need direct observation by a nurse at all times. The MI patient, for example, will be in direct observation by the nurse, attached to monitors that will alert the nurse to any changes in heart rate and/or rhythm, blood pressure, and breathing pattern and/or rate. In addition, oxygen delivery systems are found throughout the ER, with these too having extra portable supplies for overflow and transport of patients out of the ER.

Supplies in the ER, represented by a single icon in Fig. 3, also cover urgent needs for all body systems. For example, there is casting material for a fractured ankle, respiratory treatment equipment (i.e., medications, tubing, masks) for the asthmatic who needs a treatment to be able to breathe, and numerous dressings for a multitude of lacerations and injuries sustained from accidents (e.g. accidental knife wounds, motor vehicle accidents, falls). For just about any emergency situation that can be thought of, there is a supply in the ER to address the urgent treatment to stabilize patients, and move them to the next needed step (e.g., surgery, X-ray, hospital admission). The ER is not meant to hold patients for a long time; however, in today’s health care system this often happens. Therefore, in addition to all mentioned, an ER needs to be able to provide meals for patients awaiting a hospital bed on an inpatient unit, or keep someone comfortable who is waiting several hours for a non-urgent x-ray of his hand. It also needs to handle the flow of visitors who remain with loved ones in the immediate admission area or who return to visit a loved one being held in the ER until an inpatient bed is available. There are patients who also can be stabilized in a critical care section of the ER, for example the suspected MI turns out to be a muscle strain, who can then be moved to a less critical area. All of this activity and change can happen rapidly in the ER making tracking of patients a challenge.

Patients admitted to the hospital present similar challenges for tracking as the ER patient, such as movement on and off the inpatient unit. Patients will continue to be transported for testing in other departments of the hospital. This includes the already mentioned x-ray or surgical areas, but also supportive or rehabilitative care such as the physical therapy department.

B. General Use Case Models

Enhancing the Rich Picture for the ER enables the requirements engineer to identify stakeholders to be consulted for creating a set of Use Cases. Typically, for each actor, a comprehensive set of Use Cases is generated. The collection of all Use Cases is then reconciled (as there are always conflicts due to a variety of sources). In the foregoing, a small subset of Use Cases is created from the perspective of an ER nurse only.

Returning to the simplified Use Case Diagram of Fig. 2 in consultation with an experienced ER nurse, we note that there are additional considerations. Within the walls of the ER there are numerous nurses to care for these patients: administering medications, inserting intravenous (IV) lines, continuously assessing their condition, stabilizing patients, and working with the interprofessional team to treat and move the patient to the next needed space (e.g., admitted to the main floors of the hospital, transferred to another facility, or discharged).

An ER nurse will interview patients who walk in on their own or who are brought in by ambulance, assessing the patient’s complaint and determining the urgency of care needed. This is a complex process as the nurse has little information to begin with and must make critical decisions in a short period of time. Once triaged, the patient undergoes an ongoing assessment and evaluation from entry into the ER through diagnosis of condition, treatment of that condition, and admission or discharge. Various actors are involved in these activities (Fig. 4).

Fig. 4.

An abstract (generic) Use Case Diagram for a hospital ER.

This generic Use Case can be further specialized, depending on the patient condition. For example, a patient who enters the ER with a complaint of a chest pain could be in pain due to a muscle strain and is, therefore, non-urgent, or could be a patient who is experiencing a myocardial infarction (MI), colloquially known as a heart attack.

The nurse relies on the patients to give a complete and accurate account of the symptoms and concerns, but nurses also must rely on their critical thinking and assessment skills to make a decision as to how to triage the patient, determining the level of acuity and concern. If the nurse makes an incorrect assessment, the patient’s treatment could be delayed, and at the extreme, the patient could suffer further injury or die due to a lack of prompt and appropriate treatment. This is why a triage nurse is experienced with sound assessment skills and the ability to think and act quickly.

There are also non-human systems (actors) involved in the ER, namely, monitoring and treatment equipment and supplies (Fig. 5).

Fig. 5.

An abstract (generic) Use Case Diagram for a hospital ER (version 2).

In the case of an MI patient, all of these procedures may not be completed within the walls of the ER. The ER staff, however, must continually assure that the MI patient is monitored and the staff are involved in the transfer to and from these other departments. Once a diagnosis is confirmed, additional medication may be given and testing continues to determine the extent of the MI. Bloodwork is ongoing, and specialists will be brought in as needed (i.e., cardiologists, cardiac surgeons). The goal is to stabilize the patient and move him to an inpatient unit, that is, intensive care unit (ICU) as quickly as possible unless surgery is indicated. The ER team will stabilize and transport the patient, nurses are part of this transport since the patient will need continuous monitoring here as well.

The general Use Case Model in Fig. 5 then provides an abstract template for Use Case diagrams that can be created for specific major activities that will be used as the basis for IoT system requirements.

V. INTERNET OF THINGS IN AN EMERGENCY ROOM

In the ER on any given day, there will be a great diversity of patients and needs for the interprofessional team to deal with. One of the challenges in this rapidly changing environment has been organization and communication amongst the team members as ER patients are often moved within and outside of the ER. For example, a patient initially admitted as a possible MI will be placed in a critical care section of the ER; but once the MI is ruled out, the patient may be moved to a less critical area. The patient will continue to be monitored for acute changes, but he may be considered stable enough to be moved.

Patients are also moved outside of the ER, as they are transported for tests in different hospital departments, such as x-ray, ultrasound, cardiac catheterization labs, or magnetic resonance imaging (MRI). The tests are completed and the patient will be transported back to the ER to await confirmation of diagnosis, treatment, discharge, or admission. It would be beneficial to track where the patient is, and perhaps the equipment that has been brought with the patient (i.e., portable oxygen tanks or cardiac monitors). These situations will be discussed next.

A. Tracking People

Tracking the MI patient through the ER begins with the triage nurse and placement of the patient in a critical care area in the ER. The patient is attached to a heart monitor, given supplemental oxygen, emergency medications, and IVs are inserted. Additional x-rays and noninvasive and evasive procedures may be scheduled within the hospital during the patient’s ER stay.

Consider two cases previously identified: the critically ill MI patient and the non-urgent ankle injury. The MI patient in the ER is in a section that allows constant monitoring, with the ER nurse close to the bedside. This patient is attached to various monitors for the heart and lungs, and the nurse also uses assessment skills to assess the patient’s breathing patterns, skin color, and comfort/pain levels. There are numerous tests that can be completed in the ER, however there can be the need to transport the patient to other departments for specialized testing. If there were a central tracking system that the ER staff had access to, it would be easier to track the patient’s location. Specialists (e.g., cardiologists for the MI patient) outside the ER may be trying to locate the patient for consultation purposes; if the ER staff knew the patient was in the cardiac catheterization lab, this information could be communicated to the specialist, who could then visit the patient in that lab or wait to come to the ER until he knew the patient was back.

Family members are often anxious awaiting news and a chance to visit a loved one. Once a family member arrives, it would help alieviate anxieties if the staff could tell the family member exactly where the patient is. For the MI patient, transport at any time will require personnel to assist in moving the stretcher and needed equipment, but also requires a nurse who can continually assess the patient, observing and reading the monitors, to assure the patient remains safe and as stable as possible.

For the non-urgent ankle injury, x-rays will be completed outside of the ER in the x-ray department. Numerous x-rays of the ankle will be taken, and there is always the possibility that additional films will be needed as the patient is evaluated. This non-urgent patient will not require a nurse to accompany him to x-ray; therefore tracking this patient may be even more challenging. Consider a patient who had an initial set of x-ray films, returned to the ER, and is awaiting a specialist consult of an orthopedic surgeon. The surgeon has been called and is on route to the ER to see the patient, but in the meantime the radiologist in x-ray calls the ER to request the patient back for more films. A charge nurse (not the nurse who has been caring for this patient) or ER secretary may take this call, and arrange for the patient to return to x-ray. The surgeon arrives and cannot find the patient. If IoT tracking were available, the patient’s location could be immediately determined, allowing the surgeon to visit the patient in x-ray or await his return to the ER.

Hospital tracking needs remain, if the patient is admitted to the hospital. A patient will be moved around, transported for testing in other departments, or may be ambulatory and therefore walking around the unit or immediate area. Patients may also be moved from one inpatient unit to another during their stay. The healthcare environment moves quickly, so giving the interprofessional team the ability to better track a patient can assist in making workflows more efficient and enhance safety and security.

Because of electromagnetic compatibility concerns of passive and active electronic technologies (e.g., if the patient must be placed in an MRI machine), we chose a safe, nonactive, non-electronic tracking technology, namely bar code scanning. Bar code scanning is already a part of the patient identification band in many hospitals, therefore we propose to expand on this with the use of IoT tracking of patients.

All patients that are admitted to the ER are given a patient identification wristband that is placed on the patient by the nurse or ER secretary. This band contains at a minimum the patient’s name and identification number, and in many hospitals this band contains a bar code that is an identifier specific to the patient. The Joint Commission (TJC) requires the use of two identifiers to reliably identify the patient before administering medication or performing testing, such as x-rays and blood draws [17]. The patient name and identification number on the wristband and medical order will be compared to assure there is a match. TJC already accepts electronic identification technologies such as bar coding or RFID as long as two acceptable patient identifiers can be accessed with this technology.

In the future bar code scanning would be detected as the patient left the ER, with scanning capabilities embedded in the doorway leading from the ER to other departments. This would require a very sensitive scanner, and one that was silent. There are already numerous alarms within a hospital, so adding a sound when the scanning occurred could be disruptive or cause alarm fatigue, which is a form of sensory overload. Research has shown that 72 % to 99 % of clinical alarms are false [9]. The result is that nurses may become desensitized to the alarms, and possibly actually ignore or miss one that is significant. IoT tracking therefore should not add to this safety concern.

A safe and efficient way to track a patient is to have a device scan the patient’s wristband identification tag when leaving and entering different units within the hospital. The ER staff could have a portable scanning device, or scanning equipment may be at doorways where the patient enters and leaves. This portable technology already exists but is not being used as a method for tracking patient movement. It would not be practical to add another scanning device to the patient, such as a clip on tag, as this could interfere with other monitors and easily become detached as the patient moves around. TJC requires that patient identification bands be secured to the patient, not attached in a way that can get lost or easily removed. The scanning device also must not pose a risk to the patient (e.g., metal clip on a tag that is not removed before an MRI).

A prototype screen shot for such an IoT system that tracks a patient within the ER area only is shown in Fig. 6.

Fig. 6.

Prototype user interface for ER patient tracking system (ER view).

The same system could track patients as they move outside of the ER into other areas of the hospital as previously discussed. A prototype screenshot for such a system is shown in Fig. 7.

Fig. 7.

Prototype user interface for ER patient tracking system (hospital view).

In Fig. 7 each room contains a link to a “patient list.” Clicking on the link would reveal the numbers of patients in those rooms. Clicking on the room would then show the location of the patient within the room as in screen shot of Fig. 6.

The floor plans in these figures are greatly simplified and not necessarily to scale. In a large city hospital these floor plans would be greatly more complex, further highlighting the advantages of such a patient tracking system.

Utilizing a standard template developed for realizing IoT healthcare applications, a component description for the barcode system is as given in Table I.

TABLE I:

Model realization for ER tracking system

Model	Realization
Primitive
1. Sensor	Bar code scanner
2. Snapshot (time)	Asynchronous data capture
3. Cluster	Reader at egress to each room
4. Aggregator	Determine patient location function
5. Weight	Room layout dependent
6. Communication channel	Bluetooth network of sensors/clusters/aggregator, barcode beacon to eUtility.
7. eUtility	Remote monitoring software (onsite – e.g. triage nurse desk).
8. Decision	Optimize workflow

To fully realize the system described, and architectural description and design would be conducted after completing requirements elicitation and analysis. But the overview given here provide a start in creating such a system.

B. Tracking Things

Tracking the patient within and outside the ER poses great challenges but also great opportunities. As previously discussed, ER patients move around often and a central tracking station could allow for better communication and workflow. Tracking of supplies needed in the care and treatment of ER patients is already in place. In the ER there is often a central supply closet with bar coded items that can be scanned and immediately applied to the patient record for charges. This tracking can be enhanced with IoT. If supplies were not only charged to the patient but tracked in a list this could be used for quality improvement purposes. Where are the supplies being taken from, on which day(s) are they being used, and who is accessing them? Beyond the individual patient, are certain supplies being used more on particular days or at particular times? Supplies can be tracked to the patient but also to the person who is using the supplies.

What is not routinely tracked, however, is larger, multi-use equipment such as portable oxygen tanks and heart monitors. Consider the MI patient transported to the cardiac catheterization lab; this patient will have portable oxygen and heart monitors attached along with various IV pumps. Once in the lab, the patient will be connected to the lab’s monitors and oxygen supplies. If this patient has an acute cardiac episode in the lab, he may be immediately sent to the Operating Room (OR). In the rush to care for and transport this patient, equipment is a secondary concern and could get left behind in the lab or set aside in the OR once the patient is connected within the OR suite. Other than labeling the equipment with “ER” on it, if a tracking device were embedded the ER staff could more easily track where the equipment was left or moved to. Within the ER itself, a central monitoring system could better manage availability of supplies and document the need for additional equipment. For example, IoT tracking could assist the respiratory therapist in monitoring availability of oxygen tanks in the ER and perhaps detect the amount in the tank remotely, alerting the therapist of a need to refill or replace thanks without having to manually check each tank in person.

For a realizable IoT system it would be easy to augment the screen shots of Figs. 6 and 7 to include icons representing the locations of relevant supplies and equipment.

VI. GENERALIZING THE ER USE CASE

The ER patient who suffered an MI is always admitted to the hospital for further treatment and care. Tracking this patient throughout his stay can serve several purposes. The interprofessional team will gain another record of the patient experience, as they uniquely view the patient movement within the hospital. One complaint patient’s often have of hospital stays is a lack of rest as they are constantly being assessed and tested/treated. IoT tracking could allow a retrospective view of this patient experience to improve patient care in the future. Whether this tracking would take place through a passive tracking technology such as bar code tags (scanning the patient as he moves from department to department and room to room) or an active one, such as Bluetooth, is matter for the designers. As before, the first step in approaching such a system is to define the boundaries and identify the stakeholders and then proceed to requirements elicitation.

While it might be possible to generalize the Rich Picture of Fig. 3, the result would be rather complex. To simplify matters, we generalize the Rich Picture in Fig. 3, but from the perspective of a specific patient – the MI patient already admitted to the ER. Fig. 8 shows the corresponding generalized rich picture. In Fig. 8 in some cases the actor is labelled as “prof.” for “professional.” Depending on the department this professional can represent multiple persons. For example in cardiac rehab the actor can be an exercise physiologist, cardiac rehab nurse, or other professional.

Fig. 8.

Rich picture depicting the hospital experience for an MI patient.

In Fig. 8 the patient who suffered an MI may be initially admitted to an intensive care unit (ICU), to assure close observation and quick action should the patient have further complications. While in the ICU most treatments and tests will be performed at the bedside, therefore tracking the patient could be very simple here. Once the patient is stable, transfer to non-critical medical unit will occur, where the patient is still continually monitored but not in need of the one on one observation the ICU typically provides. The patient will now be transported to x-ray, Computerized Tomography (CT) scan, physical therapy, or another department as indicated for testing and treatment. It is also possible that the patient is transferred to another medical unit within the hospital during his stay. The reasons for this could be patient or physician choice of unit, or that his health care needs change again and a different inpatient unit can better meet his needs. There are transitional care units (TCU) that provide a bridge from hospital to home for a patient who is not quite ready to be fully discharged. In all of these units, IoT will enable the staff to track the patient closely.

Most of the interactions will occur between the patient, nurses, doctors and the respective specialty departments. Interactions between the specialty departments are unlikely. For example, the dietary and X-ray professionals are not likely to need to interact.

After completing Fig. 8, the next steps in systems engineering involve the development of use cases, potentially, creating screen mockups, then proceeding to requirements analysis, representation, reconciliation and then to systems design.

VII. CONCLUSIONS AND FUTURE WORK

In this paper we described a systematic approach to begin the process of eliciting requirements for an IoT system to support emergency room activities. Screen shots (which are a form of prototype) for the systems were then introduced, and a component description was offered to assist in the process of architectural design once the requirements specification is complete. We then showed how this approach could be generalized to identify stakeholders and boundaries for a broader IoT application covering the entire hospital. A review of related work was also given.

Our approach involved Rich Pictures and Use Cases. Rich Pictures are an excellent way to identify stakeholders and Use Case diagrams are an effective way to define activities in an IoT healthcare system. For example, consider the implications of not consulting with all of the actors shown in Fig. 5 during requirements elicitation.

Rich Pictures and Use Cases can also be used for requirements validation and verification. For example, consider safety and privacy concerns, which are identifiable on many levels. The tracking of the patient who moves within and outside the ER must be carefully applied. Although RFID technologies are popular, there are tests that are not compatible with these, such as MRIs. Metallic objects of any kind (including jewelry, and implanted devices) are contraindicated in MRI scanning due to the strong magnet in this equipment. It would not be advisable to include a removable tracking device because of the risk of it being forgotten at a crucial time. If the patient was brought for an MRI and the staff there was not familiar with the tracking or did not see the tag the patient’s life is now at risk. Workflow must be improved, not add another layer of risk for the patient.

Patient privacy must be maintained in design and implementation of the system. The system needs to be user friendly for the interprofessional team so they can easily track the patient within and outside the ER, but identification of the patient in the system needs to meet privacy standards so that those outside the interprofessional team cannot have access to patient information. Consider the placement of the system in the ER so that it is visible to the interprofessional team but not able to be viewed by visitors and those not involved in patient care.

Simulation laboratories (simlabs) are becoming increasingly popular in healthcare in practice and educational settings. The system presented here should be prototyped and trialed in a simlab as a means to test the usability, safety and practicality of the application. In nursing schools undergraduate and graduate students engage in simulations to enhance their clinical experience and practice situations that may not be exposed to in their clinical education. The ER tracking case we present could be trialed in nursing simlabs with students taking the roles of patient, triage nurse, ER nurse, physician and X-ray technician. From triage through inpatient admission the patient can be tracked along with equipment. Issues of safety and privacy can be explored as well as other potential applications for tracking people and things.

Finally, we showed how the system described herein could be expanded to include tracking of other hospital staff and visitors for security purposes. Significantly more work is required to complete the expansion to such a system and to continue the requirements elicitation process.