The Endocrinology Department of the Virgen de la Victoria University Hospital worked with multiple blood glucose meter vendors. Diabetes patients used these meters for their daily glucose controls. This information is very valuable to the endocrine physician because it allows the patient to be monitored and problems and risks detected in the daily management of diabetes.

The glucometers offered the possibility of downloading the measurement data to a PC. Thus, when patients went to the endocrine consultation, they brought their glucometer so that the data could be downloaded. But this entailed a few difficulties:

• Each glucometer used its own type of cable, even different models from the same vendor.
• Each glucometer required a specific driver and specialized software installed on the PC.
• The downloaded data was only stored on the office PC.

The Virgen de la Victoria University Hospital had its own electronic medical record system, which was used by endocrinologists to visualize the clinical information of patients.

The objectives for the Endocrinology Department were:

• To integrate blood glucose measurement information provided by blood glucose meters into the patient’s electronic health record.
• That this integration was automatic, simple and did not interfere with the daily work on the consultation.
• That the patient information was available homogeneously to the physician independently of the glucometer vendor.

These objectives presented important technological and business challenges such as:

• Each vendor had a different set of requirements due to their own technical and business strategy.
• The data format and the means of collection were different for each case, even within the same vendor.
• Each vendor had to be treated as an independent project with a specific development that guaranteed the security, confidentiality, autonomy and business requirements of that vendor.
• All of these independent projects had to be aligned to meet the goals set by the department.
• The projects were not carried out simultaneously, but the strategy of the Endocrinology service was translated into a series of projects separated in the time frame that had to be managed without interfering among them.

Different integration scenarios were found in the implementation of these projects. Some of the most interesting were the following:

Integration of patient demographics data

Each glucometer was bound to a single patient so that it was necessary to identify the patient of each measuring device. The demographic information for this patient could have come from two sources:

• The electronic medical record system of the Virgen de la Victoria University Hospital.
• Diraya, the electronic medical record of the Andalusian Health Service.

Diraya Integration

The integration with Diraya required communications through the corporate ESB using SOAP and HL7 XML web services. The messaging involved included:

• Patient discharge: HL7 ADT_A28
• Patient Modification: HL7 ADT_A31
• Merging Patient Records: HL7 ADT_A40
• Changing the Patient Identifier List: HL7 ADT_A47
• Patient Exitus: HL7 ADT_A03

Destination of demographic data

Demographic data was needed to:

• Maintain the patient/glucometer association database.
• Provide and synchronize patient information to proprietary vendor applications.
• In some cases, provide information to a platform in the cloud.

Integration of glucose measurements

The measurements provided by the glucometers had to be integrated into the electronic health record. To obtain these measurements, each vendor and glucometer offered different possibilities:

• Proprietary application with local database.
• Proprietary application with networked database.
• Cloud platform.
• Low level access to the glucometer device.

Different strategies were followed depending on the peculiarities of each vendor to meet all integration requirements.

Mirth Connect was used as an integration tool and PostgreSQL as a database, in addition to the additional developments required in each situation, to develop the integration engine that met these requirements.

Vendor with proprietary application

In cases where the vendor had its own application (local, network or cloud-based), this application was responsible for communicating with the glucometer. It was the responsibility of the integration engine:

• To insert patient demographic information into the application through an API or database.
• To recover information from glucose measurements by the same means.

Caduceus customized development

In some cases, there was no proprietary application of the vendor or its use was desired to be avoided, then the entire circuit was covered by custom developments. In these cases it was required to implement:

• Specific drivers for communication with glucose measuring devices.
• A desktop application capable of communicating with drivers to extract measurements and with the server to manage the relationship between patients and glucometers.
• A server that deployed an API so the application could easily interact with the integration.

Through a series of independent projects, glucose measurements taken from multiple vendors’ meters were integrated into the electronic medical record of the Virgen de la Victoria University Hospital.

The cumulative activity in December 2016 for the four main suppliers was as follows:

Vendor	Bonded glucometers	Measurements downloaded
Vendor A	650	580,000
Vendor B	116	107,246
Vendor C	36	29,266
Vendor D	25	12,369

The cumulative activity for the leading integrated vendor can be seen in the following graphs showing the cumulative values for bound devices and measurements downloaded in the clinical history:

Users of the electronic health record had the information available to them directly in the medical record. This information was presented in the form of data and blood glucose graphs of different types that provided key information.

Although the data came from different vendors, the integration was responsible for homogenizing them and displaying them with a single interface for all. The result was highly satisfactory for the users of the clinical history and facilitated the realization of their daily practice, achieving the objectives.