Interoperabilità tra sistemi clinici

Technical Corner

Health IT interoperability has an important role in health service quality and effectiveness at different levels, from the intra-institutional communication between department-based clinical systems (such as Laboratory Information Systems, Radiology Information Systems, etc.) to the inter-institutional interaction and coordination of regional or national components of a healthcare system. Also, in clinical and biomedical research, data integration is essential as a basis for guiding differential outcome analysis. Interoperability implies an exchange and mutual interpretation of information by two or more systems. In fact, the first definition of interoperability in the IEEE Standard Computer Dictionary stated, “the ability of two or more systems or components to exchange information and to use the information that has been exchanged”¹. Notice that the concept is not limited to information exchange, since this action is necessary but not sufficient to achieve interoperability. Focusing on health informatics, HL7 International² gave a more detailed characterization³ identifying three main types of health IT interoperability:

• technical interoperability, focusing on physical communication of data;
• semantic interoperability, relating to the meaning of data exchanged;
• process interoperability, addressing systems integration into a work setting.

This classification goes beyond simple labels, creating a hierarchical model which can guide interoperability implementation in different contexts: the activity of Healthcare Flows Research Program spans all the three types above and the following paragraphs show some of the results obtained in this field.

Technical Interoperability
From the technical interoperability perspective, the group develops and maintains HL7apy, an innovative Python package to manage HL7 v2.x messages for fast prototyping of HL7-compliant software. As shown in Figure 1, the main library components are:

1. inner components: core classes and an API to create and manage HL7 messages; Message Parser, to parse ER7-encoded messages; and Validator, to validate messages;
2. two utility scripts: an XSD Parser, to generate Python modules for every HL7 v2 minor version; and a Message Profiles Parser, to serialize files for message profiles.

The main classes defined in HL7apy to represent HL7 elements are:

• Messages
• Group
• Segment
• Field
• Component
• SubComponent
• Base datatype classes

The core classes allow the developer to create HL7-compliant messages, to navigate their structure and to manipulate HL7 elements in a compact form, as shown in the code examples in Figure 2, Figure 3 and Figure 4.

One of the most important features provided by HL7apy is the validation of messages, since it ensures their compliance with the standard for the specific message type and HL7 version. The library allows two levels of validation: STRICT and TOLERANT.
A detailed description of HL7apy can be found in⁴; the project is still under development and the code is released under an open-source license⁵.

Semantic and Process interoperability
The Healthcare Flows group also actively works on semantic and process interoperability, collaborating intensely with IHE⁶– the reference institution for information sharing and healthcare systems interoperability. In 2010 the group joined the IHE Technical Committee for the Laboratory Domain, now called “Pathology and Laboratory Medicine (PaLM)” Domain. Our first contribution in this context was the proposal of an extension to the IHE Laboratory guidelines to enhance traceability in the pre-analytical phase, going from the prescription of exams to sample preparation for analysis⁷. For each domain, IHE models clinical processes by defining the main workflow steps in detail, the main use cases, the actors involved, the transactions and, for each transaction, the messages to be used and the specific meaning of each message field. Concerning the laboratory pre-analytical process, IHE defines two main steps, identification and sample collection, mapping them to IHE PDQ (Patient Demographics Query) and LBL (Laboratory Specimen Barcode Labeling) profiles. The actors involved are:

1. Patient Demographics Consumer (PDC): to query a set of patient information;
2. Patient Demographic Supplier (PDS): provides patient-specific information;
3. Label information Provider (LIP): the actor that provides information about labels;
4. Label Broker (LB): the actor responsible for the labeling of the containers according to the information provided by the LIP.

The transactions for the two profiles are:

1. ITI-21 and ITI-22 for PDQ;
2. LAB-61 and LAB-62 for LBL

All of them are based on HL7 messages exchange. Concerning LBL, in a phlebotomy process supported by automation, the robotized labeling of specimen containers considers two different scenarios: Request Mode and Query Mode. These are both showed in Figure 5.

The main information needed for the labeling process is carried by the HL7 messages exchanged between the actors. In detail they provide: patient data, drawn specimens with their unique id, tests to be performed on every specimen and type of container to use. This information is very useful for traceability purposes, but no details are provided by the LBL profile regarding the preparation of the sample container and the sample collection. For these reasons, we proposed an extension of this profile, adding two new transactions, LAB-63 (Labeled Containers Production Confirmation) and LAB-64 (Specimen Collection Confirmation), depicted in Figure 6.

The HL7 messages chosen to define these transactions are OML^O33 (Laboratory Order Message) and ORL^O34 for acknowledgment, since they are specimen-centric and their structures contain all the information needed for traceability purposes.

We submitted the profile extension in a Supplement to the Committee for public discussion in July 2011. LAB-63 was reviewed and immediately accepted and – after the trial implementation period – was included in IHE PaLM Domain Technical Framework⁸. LAB-64 was considered above LBL scope, as it also involves other IHE profiles; for these reasons, the proposed profile became the starting point for a completely new profile, called Specimen Event Tracking (SET), which we have been developing since 2016 in strict collaboration with PALM Technical Committee.