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.
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.
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.
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.