POCT1-A
The POCT1-A standard describes and simplifies the communication channels between point-of-care testing devices ( POCT ), which are used to carry out laboratory tests close to the patient, and the hospital information system (HIS). This standard also enables seamless quality assurance that meets the legal requirements.
Formation of POCT1-A
The standard was created as a result of three specifications. The specification of the Connectivity Industry Consortium CIC served as the basis. The CIC is an association of 52 organizations made up of medical device manufacturers and providers. Members of this consortium are, for example, Philips Medical Systems, Bayer Diagnostics and Roche Diagnostics / AVL. In the first draft a description of the attributes of an access point, the communication protocol between the device and the access point and the communication between a data manager and the HIS was given.
From these requirements, a specification was developed in cooperation with manufacturers, which represents a merger of the interests and requirements of CIC, NCCLS , HL7 , IEEE , manufacturers and legal regulations. The NCCLS, which recently changed its name to CLSI , is a global, non-profit, ANSI- accredited standardization organization that promotes medical standards and in particular has published POCT1-A and is busy with the further development of the standard. The current version of the standard was adopted in December 2001 and is now an IEEE and NCCLS standard. Efforts are also being made to integrate POCT1-A into HL7.
Overview POCT1-A
The standard consists of two communication interfaces, on the one hand the device interface and on the other hand the observation reporting (EDI) interface. The first of the two interfaces, the device interface, represents the path from the device to the POC data manager. This describes the transmission of measurement data via an existing infrastructure. The second part deals with the transfer of this data to the HIS.
• Devices, Docking Stations: According to the standard, these devices are normally represented by physical POCT devices. As things stand at present, there are no devices on the market that have implemented POCT1-A.
• Access Points / Network: So that the device can communicate with the POC Data Manager, an existing network infrastructure of the hospital must be used. A wireless connection of POCT devices has a number of advantages over a wired or synchronization solution. In addition to mobility, the most important advantage is the immediate availability of the measured values in the HIS.
• POC Data Manager: The POC Data Manager consists of an observation reviewer, which primarily functions as a server. With the help of this server, the POC device can be configured, maintained and queried. In addition, the observation reviewer also offers the possibility of further disseminating the data in the HIS.
Structure of POCT1-A
The POCT1-A standard provides for the use of XML messages for communication between a POCT device and observation reviewer . At the time when the standard was specified, the company wanted to incorporate what was then the current state of development of the XML functionality of HL7 Version 3.0. This is why the POCT1-A-XML data types are also based on the drafts of the HL7 standard in version 3.0 at the time. The POCT1-A messages are made up of individual POCT1-A objects, which in turn consist of individual POCT1-A data types. The structure of these data types should be explained using the CE data type as an example:
<OBS.observation_id V = "2703 - 7" SN = "LN" DN = "OXYGEN">
This data type has five attributes. If a new tag of this type is created, these five attributes can be set or read out individually. In this example, the observation_id field from the observation object is shown. The V value holds a LOINC coded value. The parameter SN refers to the coding type and DN specifies a value which can be used for representation.
Using the example of a POCT1-A message, the Hello message (HEL.R01), the structure of POCT1-A messages will now be explained in detail. This is the first message sent by a device. It can be equated with a connection request.
With this message, the device informs the observation reviewer which individual capabilities it has and which modes it is capable of. As you can see in the figure on the left, the HEL.R01 message consists of three POCT1-A objects, one of which has two sub-objects, i.e., strictly speaking, even five POCT1-A objects. The first object, the header, precedes every message and contains the type of message, a unique control number and the time at which the message was created. The second object holds information about the device itself and defines technical capabilities of the device in its two sub-objects. Here the information is transmitted via the options of receiving operator or patient lists or processing certain directives. This is discussed in more detail in this chapter. In the third and last object you can still see data about the connection. On the left side of the figure you can see the XML file dynamically generated from the objects, which is also sent. In this way, all POCT1-A messages can be put together. A detailed list of the messages and objects can be found in the appendix. In order to implement communication using these messages, the standard defines message profiles.
News profiles
A standard protocol (Basic Message Flow) and two extensions for this are described. These extensions are called Continuous Mode and Asynchronous Mode in the standard. The following text deals with the standard process and the two special cases. However, a successful data exchange between the two devices is preceded by a "registration process" of the device. It is initiated by the device by sending a hello message (HEL.R01) to the observation reviewer. If the latter receives this message without errors, it sends a positive acknowledgment message to the device. The Hello message only contains the request to establish a connection. In a next step, the device informs the observation reviewer of its capabilities and available functions. This is done using the device status message. This message also contains information about any measurements that have not yet been transmitted. If the observation reviewer has accepted the message and acknowledged it with a positive acknowledgment, the connection is established. This message flow is mandatory and may not be changed in the sequence, nor may an error occur. Otherwise, the two devices cannot connect correctly.
Basic message flow
In the Basic Message Flow Profile, the device offers the following communication options with the observation reviewer. A POCT1-A-capable device can answer a query regarding an observation (measurement) with the appropriate message. The observation reviewer sends a request message for this purpose. After the device has responded to this with one (or more) observation messages, it sends an end-of-topic message to indicate the end of the transmission. If the observation reviewer receives this message, it is ensured that no further messages have to be received. Every observation sent must be acknowledged with a positive acknowledgment.
The sequence of a request for one (or more) device events (device-specific event, e.g. “empty battery” or the like) is equivalent to the previous request for an observation.
The observation reviewer can send both operator lists and patient lists to the device. Both lists exist in two different versions. Before such a list is sent, however, it must be ensured that the device supports reception of it. The device notifies the observation reviewer of any support during the registration process explained at the beginning. A precise differentiation between the aforementioned possible types is applicable. Each of the two lists can either be sent incrementally in order to add or delete the new data only to the ones already in the device, or they can also be sent as a new list in order to delete the old data and replace it with new one.
The observation reviewer can send control commands to the device using so-called directives. With the help of this message type, it is also possible to set the device to continuous mode. However, the message can only be processed if the device can do this. Similar to the support of patient / operator lists, this is communicated to the observation reviewer in the registration sequence.
A keep-alive message is sent to detect malfunctions even at times when the device is not sending any data. This can be sent both by the device itself and by the observation reviewer. This is confirmed again with a positive acknowledgment message.
In conclusion, it can be said that there is no fixed order for these messages. The processes only have to be consistent in themselves. The terminate message enables the observation reviewer to terminate the connection. However, the standard still requires confirmation from the device. It is also possible to terminate the connection when the device requests it. However, this also requires confirmation from the observation reviewer.
A type of communication modified to the basic message flow is the continuous mode, which is presented in the following section.
Continuous mode
The continuous mode is always preceded by the basic message profile, or at least a connection establishment as a result of a directive. If the device is switched to continuous mode, the message flow changes. The possible types of communication are briefly presented in this section. The main difference to the Basic Message Profile is that a device no longer has to wait for a request message until it sends the observation, but can send it continuously. An observation message still has to be confirmed by an acknowledgment. If you compare the flow of messages with the Basic Profile, you can see that both the request message and the end-of-topic message are missing. These are no longer necessary with this profile. Thus it is possible to transfer the data immediately after the measurement.
Just like an observation message, a device event message can be sent without prior request. Since the device is connected to the observation reviewer for a long time in this mode, this is an important function. In this way, for example, the observation reviewer can be informed about a weak battery or other device-specific information.
In continuous mode, it must be ensured that the device can receive both operator and patient messages, provided that neither the device nor the observation reviewer send or receive other messages or wait for them and these message types are also supported.
If two devices are connected to each other for a longer period of time, the connection may be unintentionally broken. A keep-alive message is sent in order to detect such a fault even at times when the device is not sending any data. As in the Basic Profile, the device can also receive directive messages and a terminate message. The integration of manufacturer-specific messages and directives should also be provided in both basic mode and continuous mode. In general, it should always be possible to send a Terminate message. This mode is primarily intended for devices that are permanently connected to an observation reviewer over a long period of time. This mode should be used to get the maximum benefit from data transmission via WLAN. This means that the data can be made available immediately in the HIS. In contrast to the Basic Profile, the time that elapses between queries is saved because the data can be sent immediately after the measurement.
Asynchronous mode
The message flow can be optimized by supporting the asynchronous mode. An attempt is made to increase the throughput of the data transmission by not having to send the respective acknowledgment messages immediately after receipt. This eliminates any waiting times when processing the messages.
If the asynchronous mode is supported, the device can send a sequence of observation messages without waiting for the respective positive confirmation of receipt. The end of the transfer is indicated here with an end-of-topic message. It should be noted here, however, that an observation message received on the observation reviewer side was only sent correctly for the device when the appropriate acknowledgment was sent back. If this does not happen, an error can be assumed and the sent but unconfirmed message is to be regarded as not processed. The POCT1-A standard also provides procedures for errors.
Error handling
If an error occurs during communication between a device and an observation reviewer, the standard offers two messages that can handle this error case. In the event that a message was received incompletely or incorrectly, the standard provides for a negative acknowledgment. If such an acknowledgment occurs during the transmission of observation or device events, there are three different options for further processing. • You can try to send the same message again if it is suspected that the problem is only temporary. • The device can proceed to the next message. • An end-of-topic message can be sent.
In the cases of unsupported or received messages which are not possible in the current communication status, an escape message is sent. If the device sends such a message, it must be ensured that it is put back into a communication state in which it can process all messages. However, the observation reviewer must continue with the next point to be processed.
Evaluation of POCT1-A
Benefits of POCT1-A
With the use of POCT1-A in POCT devices, a significant improvement can be achieved in many areas. Enormous savings can be achieved through more efficient use of hardware and software. The devices can be integrated directly into the HIS without any further adjustments, regardless of the manufacturer. The data exchange between the devices and the HIS can be controlled and the messages can be validated. There is also the possibility of recognizing and eliminating any errors in data transmission. Hardware and software can be combined and exchanged as required. Online maintenance of the POCT devices can be carried out using the standard. Newly calibrated and serviced devices can be queried from a central point with regard to their status. In this way, you always have an overview of the maintenance status of the devices and have the option of quality control, which is also required by law according to the MPBetreibV .
Compared to HL7
" HL7 " is a great tool for hospital information systems, with which all tasks in an intranet can be solved. The development and description of POCT1-A was intended for a limited purpose. The entire functionality of POCT can be carried out according to the standards of HL7. HL7 offers a very extensive range of functions and is rather unwieldy for POCT applications. When developing applications for POCT based on the specifications for HL7, appropriate specializations must be made. POCT devices are stand-alone devices that have limited hardware and must provide reliable communication. The integration of POCT devices into a programmable network by means of HL7 requires safety precautions which were not previously provided in the POCT devices.
Evaluation of POCT1-A
The storage space for a complete POCT1-A implementation on the device side is limited to less than one megabyte. The clear definition of the message exchange ensures that a clear interpretation of the standard is given. POCT1-A is therefore not to be seen as a “competitor product” to HL7, but rather as an extension. That is why the second part of the standard also deals with the further processing of the measured values and the conversion of POCT1-A messages into HL7-compliant messages.