Medical IoT solution for emergency care

Solution

Discovery phase

Having considered the complex nature of the solution, Itransition proposed to start the project with a discovery phase to first create a sound architectural and UX foundation. The main goal was to dive deeper into the envisioned solution features and business flows, design the initial concepts of key interfaces, and discuss technical aspects of hardware integrations and interoperability.

The discovery phase represented a two-month collaboration between the customer’s stakeholders and a part of Itransition’s team allocated for this project. The customer’s side involved a product owner and a technical lead, while Itransition’s team included a delivery manager, two business analysts, a technical architect, a UX/UI designer, and a project manager. Since the customer had just a preliminary vision of the solution from both business and technical perspectives, our goal was to collect more project details to elaborate and assess a high-level project scope. The main point of contact was the customer’s product owner, who had a medical background and with whom we constantly communicated. The customer's technical lead occasionally joined our calls too to elicit requirements.

At first, there was no clear project roadmap with elaborated features. The product owner articulated their overall business needs to our team, often generating ideas during our conversations, and our team helped translate them into software requirements. We then discussed them, transforming these requirements into particular system entities, and thought through connections and dependencies between them. 

Itransition’s team took a flexible approach to accommodate all customer’s requirements while giving advice and proposing possible workarounds if some options weren’t technically feasible. Our business analysts, with the help of the technical architect and UX designer, considered possible implementation options and prepared mockups. During calls, they demonstrated multiple realization options to the product owner for further iterating when needed. Together with the PO, we often tried out various approaches and practiced brainstorms. This was recorded in our project wiki, with each page dedicated to a particular feature approved by the product owner when completed. Our technical architect communicated with the customer’s technical lead in separate meetings. Nevertheless, our business analysts regularly synced with him to make sure we were on the same page and business requirements did not contradict technical ones from business and architectural points of view.

As a result of the discovery phase, Itransition provided a more strategic delivery plan for the development of medication and equipment management software. We prepared an architectural document describing what the solution should approximately look like and highlighting the most important areas. After that, our business analysts had joint meetings with our technical architect to compose a WBS (work breakdown structure) document, decomposing the overall project scope into tasks and estimating them.

Medication and equipment management solution

Itransition delivered a HIPAA- and FDA-compliant medication and equipment management solution. End users of the solution are nurses, pharmacists, and other personnel working in US hospitals and providing patient care in the event of cardiac arrest. The system allows for managing inventory (drugs and supplies) in smart carts and configuring workflows for the Code Blue event, helping the staff document how medical help was provided during such events. It guides nurses on what to do in a given patient condition with particular life characteristics while documenting this process, collecting statistics on the provided care by showing quality levels, and building charts. The system is also capable of interacting with additional on-cart hardware devices.

Given that the customer planned to work with various hospitals, it was critical that the data of one hospital shouldn’t be accessed by users of another. Thus, the delivered solution supports multi-tenancy, where one database is used by all clients, with all tenants isolated from each other, whereas data and infrastructure are different for various clients.

Solution architecture

The delivered solution consists of three key components: Central System, Cart System, and Tablet System. The Central System is an integral part of the solution, functioning in conjunction with the Cart System, the Tablet system, or both subsystems at the same time depending on client needs.

The Central System is a cloud-based web application, which serves as a means of managing the entire system and can be accessed from any computer using the login form. It includes such functionality as:

• Code Blue settings
• User management and authentication
• Cart management
• Medication inventory management
• Quality reports
• Audit logging
• HL7 interfaces

The Cart System is an application supporting 2 types of carts: adult and pediatric resuscitation carts. It is installed on an SBC (single board computer) mounted on a cart and equipped with a Wi-Fi module. The system is responsible for user, patient, and inventory management on a particular cart, as well as performing the Code Blue documentation and Cart Check processes. Each cart is registered in the Central System, and the Cart System gets configuration and user data from the Central System via an implemented sync service.

To synchronize data between the Central System and the Cart System each time a cart connects to the internet, we implemented Central Sync and Cart Sync services.

The Cart System is also capable of interacting with the following on-cart hardware devices:

• Barcode scanner to ensure medication identification for the inventory purposes
• Biometric reader for authentication via fingerprints
• RFID reader for authentication via an RFID card
• Electronic drawer lock 
• Temperature and humidity sensors
• Defibrillator power port
• Cardiac board
• Tablet's docker

Mindful that not all potential clients would want to buy the unified hardware-software platform, preferring to use just the software part in order to document the Code Blue process, the customer asked Itransition to realize an idea of an alternative to the Cart System – the Tablet System. The implemented solution can be launched on tablets without coupling them with the customer's smart carts and can also be used together with end clients’ own hardware, i.e. custom non-smart carts. The Tablet System represents a stripped-down mobile version of the Central System with added Code Blue management. From the UI perspective, the solution is identical to the Cart System – the app connects to the shared database via the internet and receives Code Blue settings defined through the Central System.

Code Blue

Carts with the accompanying software are used to document the Code Blue event and track medications and supplies given to a patient. The main goal of the Code Blue process is to document all the steps that were applied during the emergency event for a patient and get final event documentation at the end. As a rule, most hospitals record this process manually on paper. The delivered software for carts automates this process and allows for further editing and leaving comments. To ensure uninterrupted operation of carts during Code Blue if there’s no access to the internet or loss of Wi-Fi connection between the cart and the tablet, we implemented the offline mode.

The solution allows for performing the following stages of the Code Blue process:

Initial information 
Indicating the current patient condition (pulse, responsiveness, respirations), age group, weight, and the time when Code Blue was started.

Event documentation
Selecting and documenting all events that were applied during Code Blue for a patient, such as listing rhythm, interventions, etc., with the system constantly logging all activities in the event log. During Code Blue, the system automatically adapts timers to align with Advanced Cardiac Life Support (ACLS) algorithms. The system also presents cues on what to do in a particular situation by displaying a set of necessary actions when a particular patient condition is chosen.

Additional information
After the Code Blue process has been stopped, nurses can enter general patient information and post-event data with the reason for ending Code Blue, while indicating team members and their roles. Based on the input data, the system generates a final report saved in patient records.

The Central System also allows for choosing the date range to visualize statistics for all Code Blue events based on certain criteria to get a global picture of patients in a hospital and collect metrics in the form of quality reports that can be exported.

Quality reports represent a set of parameters and indicators that allow hospital staff to collect statistics and estimate the efficiency of Code Blue. The data is represented in different types of interactive charts that illustrate the calculated quality parameters. The system populates quality reports based on the events recorded in the event log during the code.

Inventory management

Each cart contains inventory – drugs and supplies that might be used during Code Blue. Inventory items can be placed into the cart’s tray, a portable container with different configurations, such as the number of pockets, pocket size, and their arrangement, or directly into the cart’s drawer. Everything is configured to define what exactly and in what amount should be placed in a particular drawer. Based on the created rules, the system allows for managing and tracing the contents of a particular cart at a certain time and expiration dates of medications and, if needed, generates alerts.

As carts can remain in idle mode for up to several weeks until a Code Blue occurs, they must be checked regularly to ensure their readiness for the Code Blue process. To facilitate this process, we implemented a Cart Check feature. Nurses complete a questionnaire on a daily basis at regular intervals (e.g. every 8 hours/12 hours/24 hours) using a tablet to verify the cart’s state against defined criteria that can be configured. These criteria might include checking medications’ expiration date, temperature and humidity levels, whether a defibrillator is in place, and so on. Based on the data entered into the questionnaire, the system defines whether any additional actions with the cart are required and if so, generates alerts, notifying users about what should be done.

For each key process, the system generates alerts and notifies users of certain actions that must be performed through sending SMS and email. For example, when a drug or supply is expired, a cart should be restocked, unauthorized access to a cart’s drawer, cart inspection or certain drawers after Code Blue is needed, etc. Alerts are highlighted both in the Cart System and the Central System as long as there is at least one unresolved alert.

EHR integration

The solution can be integrated with internal EHR systems of healthcare facilities to transfer Code Blue-related patient records and billing requirements while obtaining general patient data and receiving confirmation messages about the successful delivery of the order charge. The communication between EHR systems and the solution’s Central System occurs through a third-party interface engine as a layer between both systems, taking advantage of the HL7 protocol. At the same time, patient data can be created and managed in the system manually.

IoT hub

Azure IoT Hub enables secure and reliable communication between the solution and carts. It is used for registering a cart in the system and sending configuration parameters to it. When a cart is registered in IoT Hub using the Device Provisioning service (DPS) as a helper service, this event is detected by Azure Function, which generates a unique key for the cart, saves it in Azure KeyVault, and sends it to the cart via device twins – JSON documents that store device state information including metadata, configurations, and conditions. Azure IoT Hub maintains a device twin for each device that is connected to IoT Hub. Using this key, the cart is authenticated during synchronization. After the cart is successfully registered, the first synchronization process takes place and then the cart is added to the database and is fully operational.Security and HIPAA/FDA compliance

The system’s security meets the regulatory compliance requirements of HIPAA and FDA. The requirements include such technical safeguards as user authentication and authorization, data audit control, data encryption/decryption, and the absence of vulnerabilities in business logic.

Data audit

Some system entities, such as Code Blue-related information, drawer access data, or miscellaneous configuration settings undergo auditing. The audit process is enabled on a database level. Audit records contain information about the author of the change and its date and time.

Authentication and authorization

The system’s functionality does not allow for unauthenticated access. To increase the security level, logout is performed automatically after a configured timeout. Also, to avoid brute-force attacks, the system gives a limited amount of login attempts. After the limit is reached, the user account is disabled. To identify tries of a security breach, records of unsuccessful login attempts are stored and available for analysis. To protect user identity, the system requires password changes at established intervals and validates password complexity.

Data encryption

Any data leaving the boundaries of the system is encrypted. Therefore HTTPs (TLS) encryption is enabled for data transition. Any ePHI data is stored in the database in an encrypted form. Backups of whole databases are also encrypted.

Process

Communication

Itransition’s team consisted of the delivery manager, project manager, business analysts, solution architect, UX/UI designer, developers, and QA engineers. The customer was represented by the product owner to clarify general requirements; the technical lead to discuss technical questions and architecture matters; and SVP participating in management meetings to clarify our progress and whether there are any risks or impediments. Later, the director of engineering from the customer’s side joined, making final decisions on whether a certain feature should be developed.

Requirements gathering was performed through verbal and written communication between our business analysts and the customer’s product owner. The product owner, possessing the corresponding knowledge, shared the customer’s product vision with our team, and we converted them into low-level requirements. The discussed requirements were analyzed and added to the software requirements specification stored in Confluence. The specification was checked by our team (business analysts, developers, and QA engineers) and the customer for inconsistencies, contradictions, and ambiguities. Once the requirements were clarified, they were recorded in Confluence. If there was a change approved by the customer, we updated the necessary pages accordingly.

Our business analysts had verbal communication with the product owner usually twice a week, if there was nothing urgent, while calls between managers from both sides occurred once a week. Once every 2 weeks, upon completion of each sprint, we held a demo session where our entire team was present, with the engineering manager and sometimes SVP participating from the customer’s side. Tech leads from our and the customer’s sides usually communicated once a week.

The customer was open to our ideas and appreciated our input, granting our team a certain level of freedom in decision-making. We organized joint brainstorms working with the customer in close correlation, thought through possible implementation options, and proposed the most viable path, bearing in mind both the delivery terms and the financial side of the project. We managed to find ways to compromise, and the customer listened to the views of our team.

Agile

Working in accordance with the Scrum framework, the development team used daily meetings to inspect progress toward the sprint goal. A sprint review was held at the end of each sprint to inspect the increment and adapt the product backlog if needed. During the sprint review, our team and the customer’s stakeholders collaborated about what was done in the sprint. The practiced sprint retrospectives provided an opportunity for the team to inspect itself and create a plan for improvements to be enacted during the next sprint. In order to plan the total scope of work for releases more efficiently and predict release dates more accurately, our team evaluated the overall effort required to fully implement a product backlog item in story points. Story points were assigned relative to work complexity, the amount of work, and risk or uncertainty, giving more accurate estimates, reducing planning time, and improving team performance.

Initially, we proceeded from the WBS scope agreed upon after the discovery phase, splitting tasks into milestones. While discussing the project’s scope with the PO, many new details, changes, and features showed up along the way as compared to the discovery stage. That could happen, for example, when receiving product feedback from doctors and nurses or in case of legislative change, resulting in the need to add an extra event to the Code Blue process, for instance. When receiving additional requirements, our team adapted to emerging requirements, estimated the approximate implementation time, and discussed how it could affect the whole process with the customer. The release was split into several milestones – we set up regular software delivery for subsequent testing by the customer in order to be able to receive early feedback from them.

To have an outside perspective on our work, the customer hired a third-party audit organization that organized a series of calls with our team, involving business analysts, project managers, and tech leads. We were interviewed about our processes, how we make decisions and what are we guided by, what kind of documentation we maintain, and how we solve problems in different situations. The auditors also examined the overall code quality and CI/CD setup. As a result, we received positive feedback from both the audit company and the customer itself, confirming that they are very satisfied with our collaboration.