This paper explores the need for interoperability for point of care devices in healthcare ecosystem and possible approach for implementation. POCT1-A2 is the approved standard for interoperability of Point of Care Testing devices. This paper suggests a systematic approach for implementing POCT1-A2 and discusses a framework-based solution for standardizing the implementation across devices for ease of maintenance and higher ROI.

Introduction

Point of Care Testing (POCT) enables rapid diagnostic tests to be performed while the patient is at the point of care facility. It enables test results to be obtained immediately, rather than waiting hours or even days for outside lab results to arrive. There are a variety of tests available on point of care platforms like HbA1c, Glucose, Cardiac (BNP, troponin, D dimer), Coagulation, MIRSA, rapid test for infectious disease, electrolytes analysis, drug of abuse, cholesterol screening, urine analysis, pregnancy and more. POCT devices can play pivotal role in patient care and outcomes as it allows for faster decision making at the site of care.

However, there are still many challenges.

Today POCT devices are used at various locations like primary care centers, pharmacies, hospitals (emergency room, OT, ICU), mobile units, ambulance, physician office, polyclinics etc. Since Point of Care Testing is done in a non-clinical lab setting, it is important for medical device manufactures to ensure the repeatability of tests in different environments, longer shelf life of reagents and kits, and usability aspect of the device.

Complex and critical tests are still performed in a clinical setting by point of care coordinators in non-lab environments, e.g., cardiac test in emergency room and coagulation test in OT. For a service provider, it is important that such POCT devices are managed for Quality Assurance (QA), timely calibrations and interpretation of results, and training needs of point of care coordinators.

The problem of managing these devices gets compounded with multiple vendor devices with proprietary interfaces. It is challenging for service providers to manage these POCT devices using proprietary solutions. With regulatory pressure for digitalization of all medical records and patient outcomes, there is a growing need for connectivity of the entire POCT device to a central system to efficiently manage the workflow for Point of Care Testing.

POCT1-A2 is the approved standard for point of care device interoperability. POCT1-A2 addresses the problems of Point of Care Testing device connectivity and message formats for information exchange between POC data manager and the device for patient results, operator list, patient list, calibration and QC results, and other scenarios.

Approach for Implementing POCT1-A2

Figure 1 shows a typical workflow for Point of Care Testing

1.  Patient list and operator list are downloaded on POCT devices to enable real-time verification of patient identity and allow only authorized point of care coordinators to use designated devices

2.  The device initiates the connection request and sends its status to POC Data Manager. As a part of the status message, the device describes its capability to the Data Manager. Based on device capability, data manager initiates discussion on various topics supported by the device

3.  Patient observations are verified and approved at the data manager. Approved results are moved to LIS system using HL7 interface

 4. LIS coordinates with CIS for generating an order for POCT results for hospital workflow and billing

A successful implementation of POCT1-A2 in a POCT device needs careful considerations for interfaces to be supported, low-level buffering, data integrity, bandwidth considerations, error handing, keep alive messages, application time outs and minimum message set compliance.

Interface Definition

Before embarking on the implementation journey, it is important to agree on the set of interfaces to be supported. POCT1-A2 mandates a minimum set of interfaces to be supported for compliance purpose, apart from standard topics; vendor-specific directives should be documented unambiguously. Poor interface leads to misinterpretation of data and integration issues.

Mapping Data for Messages

Interface requirements drive the POCT1-A2 data model to device data model mapping. This mapping establishes how the data for POCT1-A2 messages will be populated. Most of the time there will be a need for data conversion i.e., changing from device internal representation to POCT1-A2 representation. The team has to be for watchful of temporary variables or values.

Establishing Hooks for Implementation

For Implementing the POCT1-A2 messages, it is critical to identify locations in the code where hooks for triggering the POCT1-A2 messages are needed. This needs a deep understanding of the POCT1-A2 protocol. Many times, these hooks have to be spread across different parts of the code as it is important to capture values, especially observations and error codes, before being overwritten.

Integration

As hooks can be spread across the code, it is important to identify efficient approaches for implementing POCT1-A2 communication model without affecting its existing functionality. This will ensure proper working of the existing device functionality with POCT1-A2 interface. This requires deep understanding of typical IVD devices architecture and of POCT1-A2 protocol.

Testing

For testing POCTI-A2 interface,it is important to generate various scenarios like normal message exchange,Abnormal message sequence,connectivity outage,data integrity,data validations.Apart from having the knowledge for POCTI-A2 this requires the ability to create different scenarios for testing.

Frameworks to Speed Up POCTI-A2 Implementation

Going forward, POCT1-A2 will be a standard requirement for all POCT devices; instead of having a device-specific implementation, device companies can gain by adopting a framework approach. This approach completely decouples POCT1-A2 implementation and provides developers the flexibility for integration, ease of maintenance and verification.

The framework in Figure 2 is a set of portable libraries and communication engine, which can accelerate integration of POCT1-A2 functionality to POCT Devices. POCT1-A2 framework completely decouples the implementation of POCT1-A2 from the device code. Only a minimal device adapter code is required to interface with internal sub-systems or modules to POCT1-A2 framework.

A very minimal code gets impacted by this approach. The team can implement the framework adapter and test POC data manager interface by using a device simulator code. This will allow the team to refine requirements for the device adapter code and touch device code only at required locations (minimal invasion).

POCT1-A2 Test Framework

This testing framework is built on the top of POCT1-A2 framework which can orchestrate various message sequences from XML-based files thus helping the testing team to perform various tests and capturing results in the log file.

Benefits of Using Framework-Based Approach

•  Standardized implementation across devices
•  Ease of maintenance
•  Minimum invasive code for integration
•  Ability to create normal and abnormal testing scenarios
•  Better ROI

Conclusion

POCT devices will transform patient care by bringing better decision-making capabilities at the site of care, thus resulting in better outcomes. To ensure reliability of these devices at the point of care, it is important to manage these devices for quality of results. It is also important to manage data generated from these devices for upstream processes and analytics. POCT1-A2 standard enables interoperability for POCT devices with the healthcare ecosystem. There are many challenges in implementing POCT1-A2 protocol in a POCT device. A framework-based approach helps address these challenges by standardizing implementation across devices, leading to ease of maintenance and better ROI for medical device vendors.