Development of SW Interface between Healthcare Standards—DASTA and HL7

Abstract

The prescription and administration of drugs are the most common process that takes place in hospitals. Although a relatively simple process, it is considered the riskiest process in hospitals because mistakes during drug administration are among the most common ones. The aim is to introduce technological and process changes that will contribute to maximally increase the safety of the medication process and the efficiency of drug management. To support the automation of the medication process, it is desirable to use the international standard Health Level 7 (HL7). However, the Czech healthcare system currently supports the local healthcare standard—DASTA. For that reason, the paper introduces some of the options how to transfer data from DASTA to HL7 and deals with the development of a software (SW) interface that converts data necessary for robotic preparation of patient medication from the Czech DASTA data standard to the HL7 international standard used by selected robotics. Based on the performed analyses, a combination of robotics for the preparation of single-dose packages of drugs with one of the automated warehouses is recommended.

1. Introduction

The prescription and administration of drugs are the most common process that takes place in hospitals. Although a relatively simple process, it is considered the riskiest process in hospitals because mistakes during drug administration are among the most common ones. Normally, a hospital with, for example, 500 beds administers over 1,600,000 drugs per year (with an average of nine drugs administered to a patient per day). However, the number and typology of mistakes they make are often not even monitored. Even with the correct administration of drugs at the level of 99.9%, there would be 1643 medication errors in such a hospital in one year.

Until recently, interest in healthcare errors—and the role of the human factor in them—was very low. Unlike areas with a high degree of potential risk (e.g., air, rail, and maritime transport, nuclear power, chemical industry, etc.), when in case of disaster, the massive loss of life and extensive damage to property and the environment occurs, in fact, accident in health care concerns individuals. Therefore, they do not individually attract such great social and political attention. However, this does not mean that they are not serious and, not at all, that they do not happen.

In general, the medication process in Czech healthcare facilities (unlike other hospital processes) has not been much innovated over the past few decades—the same manual decentralized preparation of drugs by nurses in wards is still applied. Unlike the clinical part of hospitals, institutional pharmacies do not use worlds’ common technologies and techniques; rarely, a clinical pharmacist is involved in the medication process, and patient verification and administration record are not sufficient, so the ability to verify the correctness of administration is limited (there is usually no clear and complete record of drug administration); stock records of medicines are administratively very demanding and, therefore, confusing and unreliable; the time of preparation of medication is time-consuming, etc. An important factor increasing the risk of the process is the lack and overload of nurses.

Despite the obvious success of Czech hospitals in increasing the safety of the medication, it is indisputable that the current decentralized manual preparation of drugs by nurses in wards carries a number of safety risks for patients in inpatient wards and also a number of economic and procedural inefficiencies for the entire hospital.

The safety of the drug delivery process increases with the introduction of new technologies and innovative approaches. The current safest and most effective practice is the automated preparation of drug therapies for individual patients centralized in a hospital pharmacy using robotically prepared single-doses of drugs. Every movement of such a single dose within the hospital is completely transparent and ensures maximum safety for the patient. For efficiency, records, and safety reasons, this approach is combined with the use of automated warehouses to manage drugs that cannot be prepared in individual doses.

Zhou et al. [1] published a study about the safety of the drug delivery system that fully considers the clinical drug safety decision support system in various businesses. They used the object-oriented method, the client-server (C/S) architecture method to design the system, and strict access control and realized the basic data maintenance, information query, drug prevention, a variety of interface design of the business, information query, prescription, prescription management.

Technology to automate aspects of the dispensing process of drugs is described, e.g., in [2,3,4]. These articles present the background to automation, giving details of the main pharmacy-based, original pack dispensing systems that are currently available.

Le Gonidec et al. [5] presented a study focused on the performances of the automated dispensing system in terms of single-dose packaging, single-dose dispensing, dispensing error rate, and security of the medication circuit. The 76 plus or minus 5% of the prescribed medications are automatically dispensed. The packaging working flow rate is 377 units doses per hour, and the dispensing working flow rate is 537 doses per hour. The dispensing error rate is 0.5% due to wrong delivery orders, mainly generated by the Pharma^® computer-order entry software.

Another study dealt with automated drug dispensing systems but from a different point of view. Skyggedal et al. [6] measured dexamethasone residue left on the suction cup after the production of 100 and 400 dexamethasone tablets and after 20 paracetamol tablets used as a negative control. Results: It has been found that 32.9 μg and 49.5 μg of dexamethasone have been transferred to the suction cup in the two experiments. This is approximately 1 per mile of the dexamethasone content in a 40 mg tablet. The reason for their research was that the risk of drug-drug cross-contamination in drug-dispensing robots in hospital pharmacies causes cumbersome restraints to be put on the production of the robot, for example, by scheduling high-risk drugs to be dispensed at the end of the day.

The solutions described below are compliant, for example, with the requirements of the European Association of Hospital Pharmacists [7] and the recommendations of the Expert Group on Safe Medication at the European Council [8]. In the current medication process, the medication process itself is separate from the drug distribution and management process. However, an innovative approach through digitalization, at all levels, integrates these processes and creates a closed cycle (see Figure 1).

The automated and safe medication process, as can be seen in Figure 1, proceeds as follows:

• The doctor prescribes a schedule of medication in the Information System (IS).
• The clinical pharmacist can verify the medication, possibly corrected as needed (e.g., exchange for appropriate drug or adjusts the strength of the dose).
• The original packages of medicines are divided into the institutional pharmacy and repackaged into sachets containing a single dose of a specific medicine. A barcode and other necessary information about the medicine are printed on these bags.
• The pharmacist completes the therapy (robotically-bound single-dose packs and non-single-dose packs) and prepares them for transport to the ward.
• Nurses give this therapy (already prepared in the pharmacy) to patients at the right time.

2. Related Work

2.1. Healthcare Standards

The integration of heterogeneous healthcare data sources is an important and necessary step to enable the use of valuable information in clinical research. As mentioned below, many authors address the issue of standardization in healthcare, ways of transferring data between systems, and finding ways to ensure communication between systems based on different standards.

The following table (

Table 1. List of authors who deal with the issue of healthcare standards.

Authors	Main Contribution (Paper Topic)
Vcelak et al. [9]	Tool for data and metadata extraction primarily from heterogeneous medical data. It is a non-interactive command-line open-source application for processing a large amount of data. The MetaMed tool extracts data and metadata from incoming files. It solves an issue with later use of all these data in a user interface or experiments. An indexing process is done immediately when new raw heterogeneous medical data incomes from the clinical center. All of the metadata are available for any subsequent usage.
Bezerra et al. [10]	A cloud middleware based on the HL7 (Health Level 7) standard capable of encoding, storing, interoperating, and integrating electronic health record (EHR) data between different applications. Based on HL7 clinical document architecture, the software architecture of the proposed middleware is specified, a set of rules, which maps relational data schemas to HL7 messages, is described, and a tool that supports interoperability and integration of EHR data among health institutions is described.
Margheri et al. [11]	A solution that can manage the provenance of patients’ records via transparent integration within the routine operations on healthcare data.
Alahmar et al. [12]	A framework for clinical pathways (CP) knowledge representation and sharing using ontologies, CP standardization based on SNOMED CT (Systematized Nomenclature of Medicine – Clinical Terms) and HL7, and CP digitization based on a novel coding system to encode CP data. To show the feasibility of the proposed framework, they developed a prototype of a clinical pathway management system based on CPs, currently in use at hospitals.
Ji et al. [13]	Conversion of referral documents in a Health Level 7 clinical document architecture to the common data model to facilitate health information exchange data available for longitudinal data analysis and to identify data quality levels for application in future clinical studies.
Fischer et al. [14]	Data extraction as HL7 FHIR (Fast Healthcare Interoperability Resources) bundle to be transformed to Observational Medical Outcomes Partnership Common Data Model (OMOP CDM) by using XSLT (eXtensible Stylesheet Language Transformations).
Ulrich et al. [15]	Examination of various script languages to find the most suitable candidate for the definition of transformation rules and implement a smart editor, which supports the data stewards in selecting rules reusing them.
Olivero et al. [16]	Their work aimed to allow modeling the HL7 standard by using Unified Modeling Language (UML).
Nagy et al. [17]	The evaluation of two standardized approaches to the implementation of messages for data exchange between the preventive cardiology outpatient departments located at the Institute of Computer Science AS CR, v.v.i. in Prague and the Outpatients Department of Cardiology of Municipal Hospital in Caslav. They evaluated the suitability of the Integrating the Healthcare Enterprise (IHE) patient administration management profile (including HL7 v.2.5) and Czech national standard DASTA using standard evaluation framework.
Maule et al. [18]	Description of features and background of the scientific medical system. The ambitious goal of the system is to provide relevant medical data for various medical methods and experimental implementations testing. Their article presented needs for such a system and administrative background, which it requires. The main standards that are used in medical applications are also mentioned, like the Digital Imaging and Communications in Medicine (DICOM), DASTA, or HL7 format, with the relation to their experimental medical system.
Muslim et al. [19]	Web services of transformation data based on OpenEHR (electronic health records) into health level seven standards. This web service is expected to standardize the health data based on HL7 so that the process of data exchange or health information becomes more structured.
Sutanto et al. [20]	A translation for healthcare institutions, which use HL7, to effectively communicate with personal health record (PHR) systems, which use the CCR (Continuity of Care Record). The translation package is coded in Java version 1.6.x. Java is also used by the Mirth message gateway and by Google Health, among others. The development environment is Eclipse.
Barbarito et al. [21]	Implementation of standards for the interoperability among healthcare providers in the public regionalized healthcare information system of the Lombardy Region. Integrating the healthcare enterprise, integration profiles, which refer to HL7 standards, are adopted within hospitals for message exchange and for the definition of integration scenarios.
St. Cyr [22]	The broad overview of the standards as well as a brief discussion of the immediate history of healthcare standards. He dealt with the following standards: HIPAA (Health Insurance Portability and Accountability Act), EDI (Electronic Data Interchange), HL7, DICOM, IEEE 11073, ICD-9 (International Classification of Diseases, Ninth Revision), and CPT (Current Procedural Terminology) in his paper.

) summarizes the main contributions regarding healthcare standards. As can be seen, it is a very serious problem, and it has been the objective of many research papers.

2.2. Emerging Technologies Not Only for Healthcare Applications

Technological development in the last decades opens new possibilities for the implementation of these devices, systems, and applications in areas of our daily use. Neural networks, machine learning, wearable sensors have been the focus of attention in recent decades. It is evident that Artificial Neural Networks (ANNs) have been successfully applied to many infrastructure engineering areas like prediction, risk analysis, decision-making, resource optimization, classification, and selection.

A deep learning model can assist healthcare professionals in making decisions regarding medications, hospitalizations quickly, and thus save time and also serve the healthcare industry better, as was discussed by Bhavya and Pillai [23].

eHealth is a long-discussed topic and priority of the European Union. eHealth is denoting a modern concept, which uses information and communication technologies to support prevention, diagnosis, treatment, and to promote public health and a healthy lifestyle. This includes the collection of data on patients and healthcare providers, i.e., electronic health records (EHR—electronic healthcare records) [24], as well as the construction of a secure and reliable health communication infrastructure, leading to the possibility of exchanging important documentation between health service providers.

It is possible to control the use and reimbursement for medical care in the following: wearable devices, which measure energy expenditure and sleep activity; a weight that not only determines weight and measures body fat but also directly designs a suitable diet; mobile applications of health insurance companies. These are just a few of the simplest examples of the use of new technologies in areas called smart health or mHealth. But much more sophisticated solutions are also emerging, such as big data analysis systems and appropriate treatments based on big data analysis and artificial intelligence technology; see Rhee et al., who proposed, for example, a blood glucose prediction model [25]. Additionally, an effective heart disease prediction model for a clinical decision support system [26] and the development of a disease prediction model based on the ensemble learning approach for diabetes and hypertension [27] have also been proposed.

Many researchers and experts consider it important to mention technologies that deal with real-world problems of patient’s health observations and are monitored in various fields, such as signal/image processing, e-commerce, smart homes, surveillance systems, and many others. Such applications and technologies that contribute to the improvement of daily life are mentioned in

Table 2. Related work regarding key enabling technologies in healthcare.

Authors	Research Area	Main Contribution (Paper Topic)
Yadav et al. [28]	Internet of Things	The role of the Internet of Things (IoT), with the help of new technologies involved and big data, has been shown towards the field of healthcare.
Sarangi et al. [29] Surati et al. [30]	IoT and cloud computing	Explanation of the role of IoT, fog computing, and cloud computing has been described along with applications of machine learning and big data that runs on these paradigms.
Susan et al. [31]	Object recognition	Feature representation of object contours by quantifying the continuity of edge pixels along the four principal directions, and evolve a set of eight ‘edge continuity’ features that describe effectively an object shape or pattern. Eight features are formulated based on the edge-edge orientation over three consecutive pixels, subsequently averaged over all the edge pixels. A grey-to-RGB template matching using city-block distance is proposed for our scheme. The new feature set is applied for object recognition from color images, with successful results.
Tingting et al. [32]	Neural networks	An application for age estimation. The proposed model consists of three stages—preliminary abstraction stage for extracting deeper features, local feature encoding stage to model the relationship between local features, and recall stage for the combination of temporary local impressions.
Zhu et al. [33]	Neural networks	A new radial basis function network (RBFN), which is based on a new kernel-clustering method. From the obtained results, they found that with kernel clustering, the classification performance becomes better than the original algorithm. Different parameters and ways bring different classification results. The most important matters derived from their experiments are (i) bubble sort (BS) always costs more time than escape nearest outlier (ENO), but BS has feasible kernels, (ii) dynamic criterion always costs more time than a static one, but dynamic one brings fewer kernels.
Wiens [34]	Simulation studies	An analysis of the potential for engine speed reduction in hydraulic equipment, taking into account not only the minimum engine speed required to meet the current flow demand but also the minimum speed capable of accelerating the engine to meet increased flow demand in the near future. His work was focused on engine speed reduction for hydraulic machinery using predictive algorithms. The presented results show the potential for reducing engine speed while not significantly reducing the useful work output of an excavator. Besides, two controllers that can automatically adapt to changes in operator style are presented—one predicts the future flow demand based on the current flow, and another predicts that it is based on current flow and pressure.
Osterland and Weber [35]	Modeling and simulation	A straightforward formulation of the stationary and dynamic behavior of a pressure relief valve (PRV). This includes an analytical solution for the static p-Q-characteristic, the step and harmonic response, and a stability criterion using elementary operations only. It also mathematically proves the intrinsic connection between the gradient of the static p-Q-characteristic and stability.
Shokri and Tavakoli [36]	Neural networks	A review of the artificial neural network approach to the analysis and prediction of seismic damage in infrastructure. The survey demonstrates that artificial neural networks (ANNs) are the essential tools for predicting damage detection of seismic performances of RC bridges. It has also been shown that the efficiency stresses of the reinforcements are one of the important sources of uncertainty in the fragility analysis of RC bridges.
Mahmood et al. [37]	Neural networks	A WHITE STAG model to wisely track human interactions using space-time methods, as well as shape-based angular-geometric sequential approaches over full-body silhouettes and skeleton joints, respectively. After feature extraction, feature space has been reduced by employing codebook generation and linear discriminant analysis (LDA). Finally, a kernel sliding perceptron has been used to recognize multiple classes of human interactions.
Kim et al. [38]	Neural networks and artificial intelligence	A study focused on in-depth video-based human activity recognition (HAR) system to utilize skeleton joints features, which recognize the daily activities of elderly people in indoor environments. Initially, depth maps are processed to track human silhouettes and produce body joints information in the form of a skeleton, resulting in a set of 23 joints per each silhouette. Then, from the joints information, skeleton joints features are computed as a centroid point with magnitude and joints distance features. Finally, using these features, the hidden Markov model is trained to recognize various human activities. Experimental results show a superior recognition rate, resulting in up to the mean recognition rate of 84.33% for nine daily routine activities of the elderly.
Ahmed et al. [39]	Neural networks and artificial intelligence	An efficient multiclass objects categorization method for the indoor-outdoor scene classification of scenery images using benchmark datasets. We illustrate two improved methods—fuzzy c-mean and mean shift algorithms—which infer multiple object segmentation in complex images. Multiple object categorization is achieved through multiple kernel learning (MKL), which considers local descriptors and signatures of regions. Their system should be applied in various domains, such as drone targeting, autonomous driving, Global positioning systems, robotics, and tourist guide applications.
Nadeem et al. [40]	Neural networks and artificial intelligence	A study that combines linear discriminant analysis with an artificial neural network for precise human action detection and recognition. The proposed mechanism detects complicated human actions in two state-of-the-art datasets, i.e., KTH-dataset and Weizmann Human Action. The obtained results show that the proposed technique is reliable and applicable in health exercise systems, smart surveillance, e-learning, abnormal behavioral detection, protection for child abuse, care of the elderly people, virtual reality, intelligent image retrieval, and human-computer interaction.
Jalal et al. [41]	Neural networks and artificial intelligence	A novel human activity recognition (HAR) methodology, utilizing the recognized body parts of human depth silhouettes and Hidden Markov Models (HMMs). They have performed HAR with the trained HMMs for six typical home activities and obtained the mean recognition rate of 97.16%. The presented HAR methodology should be useful for residents monitoring services at smart homes.
Quaid and Jalal [42]	Neural networks and artificial intelligence	A new effective framework, having statistical features and a reweighted genetic algorithm, to recognize human behaviors using the triaxle signals acquired from accelerometer sensors. They proposed a reweighted genetic algorithm that provides a variation of chromosomes adjustment and a combination of windowed signal patterns to recognize random human behaviors.
Badar et al. [43]	Wearable sensors	A wearable inertial sensor for daily activity analysis based on Adam optimization and the maximum entropy Markov model, i.e., a human activity recognition model that acquires signal data from motion node sensors, including inertial sensors, i.e., gyroscopes and accelerometers. The proposed system should be applicable to man-machine interface domains, such as health exercises, robot learning, interactive games, and pattern-based surveillance.
Jalal et al. [44]	Neural networks and artificial intelligence	A depth-based life-logging HAR system is designed to recognize the daily activities of elderly people and turn these environments into an intelligent living space. The Hidden Markov model is used. The proposed system is directly applicable to any elderly monitoring system, such as monitoring healthcare problems for elderly people or examining the indoor activities of people at home, office, or hospital.
Desai Karanam et al. [45]	Neural networks and artificial intelligence	A complete design process of a multi-mode biometric-based security layer to provide secure authentication to access healthcare data at the edge devices deployed in hospitals and patient’s smart homes. The authors have discussed the prototype design for the authentication of the end-users of healthcare data and carried out a face recognition experiment for authentication.

.

3. Communication Protocols in Healthcare

Data standards serve to facilitate communication between healthcare systems during the transfer of medical data.

“In view of the ever-expanding and growing healthcare agenda and the effort to integrate individual global healthcare systems, there is a need for a single standard that defines all systems. The Czech Republic, however, has gone in the opposite direction. While the global trend is unification, it bet on the development of its own medical data standard. It is quite different from the most frequently used world standard, HL7” [46].

The main structural problem is that the HIS (hospital information system) and outpatient software in the Czech Republic are not able to communicate in HL7 (validly). There is a lack of structured medical records and problematic translation of DASTA into HL7 [47].

In order for information systems to exchange data, we must specify a communication language—a protocol. It must be implemented on both sides and, if possible, with the greatest possible generality. At the same time, however, we must include all possible states that systems could transmit. Such standards for the exchange of medical data have existed for some time, but the problem is their inconsistency and the absence of a major data standard for healthcare.

3.1. The DASTA Communication Protocol

DASTA is an acronym for the Czech national data standard for the exchange of information in healthcare. This standard is published by the Ministry of Health of the Czech Republic.

DASTA is a regularly updated, open standard for communication between the information systems of healthcare facilities, covering clinical, laboratory, statistical, and administrative areas, which includes code lists (for example, the National Code List of Laboratory Items, Clinical Events code list, current code lists of the Institute of Health Information and Statistics, etc.), documents, and tools (for example, the Laboratory Items Code List (ČLP) program) [48].

“The conceptual basis of the standard is created by the Working Group of Data Standards of the Czech Society of Health Informatics and Scientific Data (ČSZIVI) ČLS JEP in cooperation with other entities involved in the development of the standard and according to the needs of the National Health Information system” [48].

In 1997, the first version of the Czech national standard for the exchange of information in the healthcare sector, DASTA, was created; since 2002, DASTA has been routinely used by all main information systems in Czech healthcare.

Data blocks form the basis of DASTA; they are described by a unique name within the entire standard, as well as a unique name of the XML element in the file. The block specifies what mandatory and optional information it will contain. The definition of these blocks can be found in text form and in the form of tables on the DASTA website [49]. As of DS 04.01, it is also possible to define an Extensible Markup Language (XML) schema or an earlier Document Type Definition (DTD). Officially, however, the tabular form is superior to all others.

Description of main data blocks:

• source_js—here, we find codes: company_code, program_code, program_version, clearly specifying the source of the data.
• pm—receiving place—the place where we send the data file—it is possible to select from the following codes: ico, icl, icp, icz, pcz, oddel.
• is—one of the most important blocks, containing directly the data on patients (in block ip). Another important item is the definition of the sender of the data file.
• ip—block, uniquely defining the patient—there are items like id_pac, rodcis (birth number), name, surname, sex (gender—M for men and F for women), and others.

3.2. The HL7 Communication Protocol

3.2.1. Overview of HL7

In contrast to the DASTA standard, which is strictly national, HL7 represents a set of international standards. HL7 standards are set by the international organization Health Level Seven International, and from there, they are adopted by other standard organizations, such as the International Organization for Standardization and the American National Standards Institute.

“The HL7 (Health Level Seven) communication standard was developed for the healthcare system. HL7 enables electronic communication between virtually all participating institutions and fields. Currently, it offers the support of extensive experience, with respect to its use in hospitals” [50].

As Noumier [51] presented, HL7 is a standard for exchanging information between medical information systems. It is widely deployed and covers the exchange of information in several functional domains. It is very important and crucial to achieving interoperability in healthcare. HL7 competencies are needed by all professionals, touching information technology in healthcare.

“HL7 and its members provide a framework (and related standards) for the exchange, integration, sharing, and retrieval of electronic health information. These standards define how information is packaged and communicated from one party to another, setting the language, structure, and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services and are recognized as the most commonly used in the world” [52].

The name refers to the upper (seventh) level of the international organization for standardization (ISO) communication model for the open system interconnection (OSI). This level is also called the application layer. In the application layer, the data to be exchanged must be defined, as well as sequential message processing and error protection management.

The message is the smallest transferable unit and consists of segments. It starts with a message header segment (MSH). It is identified by message type and initialization event (trigger event).

“Example: A message transmitting patient admission data is identified by the ADT (Admission, Discharge, Transfer) message type and the trigger event A01 (ADT ^ A01)” [50].

Segments are arranged sequences of boxes. Segments can be declared as mandatory, optional, or with possible repetition. They are clearly identified by three characters placed at the beginning (segment identifier). They are separated by segment delimiters. For example, the ADT message may consist of segments on the simple scheme, Figure 2, where the ADT message is displayed with segments MSH (i.e., message header), EVN (trigger event description), PID (patient identification), and PV1 (patient visit information).

Fields: The semantic content of messages is transmitted in the so-called segment fields. Fields can be of variable length and are separated by field separators, Figure 3. A data type is defined for each field, e.g., string, value, time (duration), timestamp.

Abstract message syntax: The message consists of control and data segments, the frequency of which (cardinality) is defined using mandatory/optional/repeatable values. The frequency of occurrence can be described using the abstract message syntax.

Mandatory segments are identified by segment identifiers, and optional segments are enclosed in [], repeatable in {}.

Each message begins with information about the message itself (MSH message header, ENV event description, etc.). Usually, it is followed by patient data (patient identification PID, etc.)

Exchanging HL7 messages requires that error-free and complete transmission within networks (e.g., via TCP/IP (Transmission Control Protocol/Internet Protocol)) be ensured and that an unlimited message length be possible.

3.2.2. The Usage of HL7 in the Case of Automated Drug Management System Swisslog (PillPick and BoxPicker)

Incoming and outgoing messages are transmitted over TCP/IP or stored in a file. The automated drug management system (ADMS) interface receives and responds to ports that are specified during configuration.

The interface reads the message from a file in the shared storage and saves the response to another file. Message segments and fields that are not directly supported by the ADMS are ignored. Incoming messages are acknowledged with an ACK (acknowledge) message. Outgoing messages require a response in the form of an ACK message. Messaging is asynchronous.

Table 3. Definition of selected segments and an overview of message field values and their description.

Value	Description
Definition of selected segments
MSH	Message header
MSA	Message acknowledgment segment
EVN	Event
PID	Patient ID
PV1	Patient visit
MFI	Master file identification
MFE	Master file entry
ZDP	Package information
ZDR	General drug information
ZIG	Purchase info
ZSQ	Stock location
Overview of message field values and their description
AD	Address
CE	Coded element
CF	Coded element with formatted values
CK	Composite ID with check digit
CM	Composite
CN	Composite ID and name
CP	Composite price
CX	Extended composite ID with check digit
DT	Date
ED	Encapsulated data
EI	Entity identifier
FT	Formatted text—display
PN	Person name
PT	Processing type
RP	Reference pointer
SI	Sequence
SN	Structured numeric
ST	String
TM	Time
TN	Telephone number
TQ	Timing/quantity
TS	Time stamp
TX	Text data—display
XAD	Extended address
XCN	Extended composite name and number for persons
XON	Extended composite name and number for organizations
XPN	Extended person name
XTN	Extended telecommunications

presents the definition of selected segments as well as an overview of the message field values and their description.

Default HL7 separators are supported:

• | Field separator
• ~ Field repeat separator
• ^ Component separator
• & Subcomponent separator
• \ Meaning change character

3.3. Data Exchange in HL7

HL7 enables data exchange between systems. An example is the “admission of a patient to the hospital” event. In HL7, such an event is called a “trigger event”, see Figure 4, where the graphical interpretation of that kind of algorithm is shown.

In general, two categories of messages are distinguished:

• Unsolicited change of data,
• A query, such as a specific laboratory system query, as to whether demographic information is available about the patient in question.

The so-called “unsolicited data change” is created by an event (e.g., patient admission). This event leads to an internal transaction in the sending system (e.g., insertion into the database). Then, the data is sent via HL7. The recipient receives the message and can respond to the transaction himself.

The ‘hospitalized patient admission’ event leads to the exchange of data in HL7 via message A01. The sending system (the inpatient care subsystem in Figure 5) must transmit message A01 to the other subsystems. Typically, interface tools are used for the data distribution task. The sending system transmits the data to the interface tool, which then sends a message to all systems for which the receipt information is relevant.

Acknowledgment messages (ACK, see Figure 6) are sent back to the sender to indicate receipt as “message received” (receiving ACK) or “message understood and processed” (application ACK). The acronym ADT in the next figure is one of the multi-purpose messages defined in HL7, namely “patient administration: admission, discharge, and transfer”.

If data is missing during the transaction, a query is generated in the system. The recipient should respond. Apart from this response, no other transaction is performed. The answer allows the querying system to complete the transaction.

3.4. Prescription Medication Requirement for the Patient (Standard)

This message is sent from the department (from Hospital Information System HIS) or pharmacy information system (from PIS) to the PillPick Manager (robotics SW) and ensures the preparation of personalized medication (drug circle for a specific patient) for the next 24 h. The system will start handling this type of request based on a “command” from the operator, respectively, according to a given schedule of activities in a robotic pharmacy.

The following tables (

Table 4. Message Header (MSH) Segment.

SEQ	LEN	DT	OPT	Element	PPS Usage
1	1	ST	R	Field separator	|
2	4	ST	R	Character encoding	^~&\
3	180	HD	O	Sending application	HOSPITAL
4	180	HD	O	Sending location	SURGERY
5	180	HD	O	Receiving application	SWISSLOG
6	180	HD	O	Receiving location	HL7GATE
7	26	TS	O	Date/Time	Time stamp
9	7	CM	R	Message type	RDE^O01
10	20	ST	R	ID message check	Unique number
11	3	PT	R	ID processing	P or T
12	8	ID	R	ID version	2.2

,

Table 5. Example of MSH segment.

Message—MSH Segment
1:	MSH|^~\&|HOSPITAL|SURGERY|SWISSLOG|HL7GATE|20031001091225||RDE^O01|20031001 12345852|P|2.2|||||

,

Table 6. PID segment.

SEQ	LEN	DT	OPT	Element	PPS Usage
2	20	CX	R	Patient ID	Patient code
5	48	XPN	R	Patient’s name	Surname and name of patient
7	26	TS	O	Date of birth	RRRRMMDD
8	1	ID	O	Sex	M or F

,

Table 7. Example of PID segment.

Message—PID Segment
1:	PID|||00001094879||SVOBODA^PETR||19650505|M||||||||||||||||

,

Table 8. PV1 segment.

SEQ	LEN	DT	OPT	Element	PPS Usage
3	80	PL	O	Location of patient	Department, room, bed, description of department

,

Table 9. Example of the PV1 segment.

Message—PV1 Segment
1:	PV1|||SUR1^012^12B^^PTS STATION CODE^^^^SURGERY|||||||||||||||||||||||||||||

,

Table 10. ORC segment.

SEQ	LEN	DT	OPT	Element	PPS Usage
1	2	ID	R	Order check	NW
2	22	EI	C	Order number	Number of decursus/medication description
9	6	TS	O	Date and time of transaction	Date and time of order

,

Table 11. Example of ORC segment.

Message—ORC Segment
1:	ORC|NW|001299|||||||20181003091225|||||||||||

,

Table 12. RXE segment.

SEQ	LEN	DT	OPT	Element	PPS Usage
1	200	TQ	R	Amount/Time of medication	Date and time of medication
2	100	CE	R	Code	Code of medicine
7	250	CE	O	Instructions	Instructions described by doctor
10	6	NM	R	Amount of issue	Requested amount
30	2	ID	O	Form of issue	UD (unit dose) or PK (package request) (default UD)

,

Table 13. Example of the PV1 segment.

Message—PV1 Segment
1:	RXE|^^^201810041000^201810050959^3^^^^1000&1600&2200|38783695|||^example|||6|||UD

,

Table 14. OBX segment.

SEQ	LEN	DT	OPT	RP#	TBL#	ITEM#	Element
1	10	SI	O			00569	Set ID—OBX
2	2	ID	C		0125	00570	Type of value
3	590	CE	R			00571	Observation identifier
4	20	ST	O			00572	Observation sub-ID
5	65,536	*	C			00573	Observed value
6	60	CE	O			00574	Units

and

Table 15. Example of the OBX segment.

Message—OBX Segment
1:	OBX||ST|1010.1^BODY WEIGHT||62|kg<CR>
2:	OBX||ST|1010.1^HEIGHT||190|cm<CR>

) describe individual segments of the HL7 message for the prescription of medication.

• Patient code: 00001094879
• Name and surname: Petr Svoboda
• Date of birth: 5. 5. 1965
• Sex: Male

• Department: SUR1
• Room: 12
• Bed: 12B
• Department description: SURGERY
• Pipeline post station: Pipeline station code (optional)

• Type of claim: NW
• Number of decursus/medication description: 001299
• Date and time of order: 3. 10. 2018 09:12:25

• Medication preparation from: 4. 10. 2018 10:00
• Medication preparation till: 5. 10. 2018 09:59
• Priority: 3
• Schedule of administration: 10:00, 16:00, 22:00
• Code of medicine: 38783695
• Number of serving (doses): 6 (respectively, 2 doses at 10:00, 2 doses at 16:00, 2 doses at 22:00)

In this message, the priority has a numeric value of 1–89, with 89 being the highest.

The schedule of submissions is recorded, for example, as follows: …… ^ 1000 = once a day; …… ^ 1000 & 1800 = 2x daily; …… ^ 0600 & 1200 & 1800 & 2400 = 4 times a day.

The messages described above (Table 3, Table 4, Table 5, Table 6, Table 7, Table 8, Table 9, Table 10, Table 11, Table 12, Table 13 and Table 14) send the following information to the PillPick system:

● Patient code:	00001094879
● Name:	Petr Svoboda
● Born:	5 May 1965
● Sex/Gender:	Male
● Department:	SUR1
● Room:	12
● Bed:	12B
● Department description:	SURGERY
● Requirements type:	NW
● Medication course/schedule number:	001299
● Date and time of order:	3. 10. 2018 09:12:25
● Preparation of medication for the period from:	4 October 2018 10:00
● Preparation of medication for the period until:	5 October 2018 09:59
● Priority:	3
● Submission schedule:	10:00, 16:00, 22:00
● Medicinal product code:	38783695
● Number of servings:	6

This report represents the requirement to prepare one medicinal product per day for one patient. One message must be sent for each Medicinal product (MP). The complete “order” of medication is, therefore, formed from these individual reports.

3.5. Summary of Healthcare Communication Standards

Seidl compared [53] the data standard DASTA and HL7 from the technical point of view, and they seem to be very similar. In both cases, we may have a problem with the non-standard character set; the original writing format has no support in modern programming languages, but both standards offer a variant of writing in XML. Looking at the transport layer, the current practice between DASTA systems is to create files on shared storage; HL7 version 2 defines the requirements for the transport layer (so-called LLP—lower layer protocol), which is usually implemented in a TCP connection. However, HL7 messages as disk files are also common (*.hl7 files). From a technical point of view, there is a significant difference in the data types used, where DASTA uses the basic types provided by programming languages (number, text, enumeration), while HL7 version 2 uses 89 compound data types [53].

In terms of content, however, the standards are practically incomparable. Each trigger event has its own unique code (e.g., A01, S04), and if it occurs, it will cause the transmission of a specific type of message with a defined segment structure. New segments are also defined that contain the necessary fields for transferring domain-specific data. In contrast, DASTA is always limited to the description of the data structure, while the obligation, multiplicity, the non-use of a specific data, or block, respectively, follows from the logic of the case. Likewise, the triggering event (and thus also the meaning of the processed message) must be inferred by the receiving party, or the meaning must be explicitly agreed in advance (e.g., by choosing a separate directory) [53].

The book written by Oemig et al. [54] focuses on the development and use of interoperability standards related to healthcare information technology (HIT) and provides an in-depth discussion of the associated essential aspects. The book explains the principles of conformance, examining how to improve the content of healthcare data exchange standards (including HL7 v2.x, V3/CDA (Clinical Document Architecture), FHIR (Fast Healthcare Interoperability Resources), CTS2 (Common Terminology Services, Release 2), DICOM (Digital Imaging and Communication in Medicine), EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport), and ebXML (Electronic business XML)), the rigor of conformance testing, and the interoperability capabilities of healthcare applications for the benefit of healthcare professionals who use Health(care) Information Technology (HIT), developers of HIT applications, and healthcare consumers who aspire to be recipients of safe and effective health services facilitated through meaningful use of well-designed HIT.

4. Transfer of Patient Medication Messages

4.1. Medication Message, Its Contents, and Significance

The medication message, which is a key element in HIS (hospital information system) and SW ADMS (automated drug management system) communication, contains all the information needed to deliver the correct medication for a specific day and patient.

It contains the patient’s identification data, the ward where the patient is located, and a list of all the medicines to be taken by the patient that day. Together with the schedule of administration of these medications, they form a comprehensive overview that will enable passing all information on to the ADMS for its activities and, consequently, to issue an automatically prepared package of personalized medication in the hospital pharmacy.

4.1.1. How a Message is Generated in the DASTA Standard and What It Tells Us

All information that can be requested from the HIS in the Czech Republic is available in the DASTA standard. It is a standard used across healthcare facilities throughout the country. It allows individual devices to easily exchange the information they need for their cooperation.

In our case, we are interested in the patient medication message for the given date. In chapter 6, the example of DASTA and HL7 messages are illustrated. The message report provides the patient’s basic data, together with a list of all his or her medications, including dosage. This is the information that is necessary and, at the same time, sufficient to assemble the correct task for robotic drug preparation.

4.1.2. Why Convert Messages to the HL7 Standard?

HL7 is an international standard for communication in healthcare facilities and their applications. In some areas, its coverage overlaps with the Czech DASTA standard; however, both provide the possibility to create a patient medication report, as described above. The final form of the report and partly the contents’ event may differ, though.

The large overlap of information contained in both reports makes it possible to convert between them at a sufficient level of quality, thereby correctly informing the ADMS, which communicates in the international HL7 standard.

The main reason why to convert data from Czech DASTA to international HL7 standard is the fact that systems for automated and safe medication processes communicate at HL7 standard instead of DASTA, which is used in Czech hospitals’ information systems.

4.1.3. What Information is Transferred between Reports and What Information is Drawn from the Internal Database?

Most of the information used to compile a report informing the ADMS of medication is known from the report generated by the HIS. It is the identification of the patient through his or her birth number, name, last name, and gender, while at the same time, information regarding the ward in which the patient is hospitalized is also transmitted. For the medication itself, it is necessary to enter the date to which it relates and a list of all medicines with details, including the breakdown, SUKL (state institute for drug control) identification code, the total quantity to be issued, and the package type.

The only information outlined above that is not included in the DASTA report is the type of drug pack. This is essential for robotic drug therapy, with respect to how automation will physically prepare the dose. However, this information is easily located in the drug database, which the prepared interface keeps and in which the drug identification number matches the number sent in the DASTA report.

5. Implementation Options

If the HIS/PIS (Hospital Information System/Pharmacy Information System) does not usually allow integrated communication in the HL7 format, which is the case in commonly-used HIS and PIS in the Czech environment, this can be achieved by various means:

• Use of an additional HIS/PIS module, if the HIS/PIS manufacturer provides such a module—see option 1 below.
• It is also possible to create an integration bridge communicating with HIS/PIS via the available API (application program interface)—see option 2 below.
• In case the HIS/PIS does not have an integration API available, it is then possible to create an integration bridge accessing the HIS/PIS database directly—see option 3 below. In option 3, communication with the HIS/PIS system database assumes read/write permission to this database for two-way communication.
• For a more comprehensive solution, it is possible to implement an integration bus—see option 4 below.

5.1. Option 1—HL7 Module for HIS/PIS

For proper communication with Swisslog systems, it is possible to create a module that ensures the necessary conversion of HIS/PIS data and the creation of communication messages according to the HL7 specification. These messages can be sent via the TCP/IP network protocol on ports according to individual configuration or stored in a file from where the robot will read them, see Figure 7. This option would allow tighter integration into the HIS/PIS system and its functionality, including the possibility of better integration for use in system processes, for example. The disadvantage of this option is the dependence on cooperation with HIS/PIS vendor as not all such systems allow for 3rd party custom modules to be used. Development of the module would need to be done by the vendor itself and then restricted for that particular HIS/PIS solution, and such module would not be usable in other installments where different vendor/system is used. Besides, this does not support distributed architectures.

5.2. Option 2—Communication through Integration Bridge

For communication with Swisslog systems, it is possible to create an integration bridge that retrieves data from HIS/PIS via the API and ensures the necessary conversion and generation of communication messages according to the HL7 standard. The integration bridge can send these messages via the TCP/IP network protocol on ports according to individual configuration or save them to a file from where the robot will read them, see Figure 8. This option supports distributed architectures and multiplatform solutions. It is less dependent on HIS/PIS vendor, but it assumes that the given system does support API integration through the provided API interface. Besides, each change in API through the system upgrade will result in stopping the working of the bridge and would need to be updated.

5.3. Option 3—Communication via Data Bridge

For communication with Swisslog systems, it is possible to create a data bridge that retrieves data directly from the HIS/PIS database and ensures the necessary conversion and generation of communication messages according to the HL7 standard. The data bridge, as can be seen in Figure 9, can send these messages via the TCP/IP network protocol on ports according to individual configuration, or save them to a file from where the robot will read them. This option assumes that the database of the HIS/PIS system can be accessed. Through the access directly to the data layer, the solution is the least dependent on the platform and architecture, as well as on the functionality of the HIS/PIS system; also, it is the least prone to stop working due to the system upgrades by HIS/PIS vendor. The disadvantage of such a level of independence is the lack of integration into the HIS/PIS processes.

5.4. Option 4—Integration Bus

The schematic below shows an example of a possible IT solution for a safe medication process using an integration bus, see Figure 10.

The integration bus interconnects and communicates with various existing and future application solutions (HIS, PIS, structured medication platform, single-robot robot platform, etc.) by individual connectors. Other applications connected to the bus could be systems checking drug interaction (InfoPharm, LexiComp Online, etc.) if they are not already included as part of the HIS/PIS.

6. The Interface between DASTA and HL7 (IDH)

6.1. Basic Description of IDH

Data communication is realized via Ethernet with cabling according to the IEEE 802.3u standard (Institute of Electrical and Electronics Engineers) and higher with a throughput of 100 Mbps and more. TCP/IP—IPv4 is used as a communication protocol. Data for communication with ADMS systems are stored in a database. It is necessary to create a communication interface to the robot software between the hospital information system (or more systems used in the hospital).

For this project, we have named the software interface, which converts the data necessary for robotic preparation of patient medication from the Czech DASTA data standard to the international standard HL7 “readable” for Swisslog robotics, IDH (interface between DASTA and HL7).

Since we have not been able to work with the real HIS so far, we have chosen a solution that, of the options described in the previous chapter, is closest to option 3—data bridge communication. IDH converts the data needed for the robotic preparation of patient medication (written in DASTA standard) into the structure. However, it simulates both the Swisslog robot and the HIS, therefore accessing a database created specifically for this purpose.

The SW allows:

• Selection of medication in the form of a simple simulation of the patient’s medical record and treatment prescribed, as executed by the doctor in HIS,
• A statement of the data sentence created in the DASTA standard,
• A statement of the data sentence created in the HL7 standard, “translated” through the interface created between protocols,
• Display of the prepared medication for the patient according to the treatment plan, in a simple graphical output simulating the robotic preparation of medication in the hospital pharmacy.

The output is presentable via a web interface.

We suppose that upon the completion of this project, the final version of this SW will work with data provided by the real HIS, or will acquire data via the API (a variant preferred by HIS vendors/administrators). In the final phase, we should, therefore, create an integration bridge that retrieves HIS data through the API and provides the necessary conversion and communication of messages to make them usable for Swisslog robotics. In the final phase, this should most likely be option 2, described above.

The information listed below must be available in the HIS/PIS database in order to order drug therapy for a specific patient. Data can originate in different systems/databases/code lists:

• Unique identification of the patient
  • patient’s name
  • the patient’s surname
  • date of birth of the patient
• Department
  • department identifier
  • name of the department
• Unique identification of the drug (or active substance)
  • drug identifier
    • European Article Number (EAN)
    • code SUKL
  • active substance
    • identifier
    • amount
    • unit of measure
  • dosage form
  • method of administration
  • other optional information (e.g., conditional prescription, remarks to submit before/after, etc.)
• Date and time of drug administration
• Nurse identifier (when verifying drug administration)

No information about the patient is required for the need to store single doses in the department. For communication, the data must be transformed into a format corresponding to the specification of the international standard HL7.

6.2. Description of Interface Functionality

The web interface for testing and demonstrating HIS and IHD (Interface DASTA-HL7) communication is designed to be as intuitive as possible and to focus on the essence, which is the communication of the two systems themselves. Therefore, we do not find here all the functions and possibilities that the real HIS provides, because, for the given purpose, these would be distracting and clutter the space unnecessarily. Instead of detailed emulation, we prefer to offer an intuitive and clear presentation that should be quickly understandable, even to those who do not work with similar systems. For those who are accustomed to such systems, however, the arrangement should be familiar and not disrupt their ingrained habits.

The biggest advantage of the simplified preview is clearly the possibility of seeing at first glance the connections between individual phases and the data used in them.

The entire interface consists of the following basic building blocks:

• Patient information
• New medication entry form
• Preview of the patient’s medication
• Selection of the date to generate a medication report
• DASTA report as of the given day
• HL7 report generated from DASTA report
• Illustration of the resulting IHD physical output

6.2.1. Patient Information

In this section, it is possible to read basic patient information. All data is randomly generated and is by no means real data on real persons. For a greater variety of test data, it is possible to switch between 100 fictitious patients using the arrows.

6.2.2. Form for Entering New Medication

The form for entering new medication is based on data obtained from the publicly accessible database of covered or not-covered drugs as of 1 September 2019. The user enters the name of the medication, which is auto-filled from the options provided in the database as it is typed. If there are multiple possibilities of drug strength or form, the desired option can be selected in the fields called “Strength” or “Path”. Based on this, the corresponding drug code is then displayed in the “SUKL” (state institute for drug control) field.

To complete the assignment, it is also necessary to fill in the “Schedule” and “Quantity” of drug administration. For better clarity, the “Schedule” in our presentation is limited to whether the drug will be administered in the morning, at noon, and/or in the evening. This information is provided in the form of “x-x-x“, where x is either 0 or 1, but this does not mean the number/quantity of MP doses, but only whether or not the MP is administered at a given time. All options provided by IDH for the “Schedule” field can be selected from the automatic menu that appears after the first digit is entered. The necessary information regarding drug administration also includes its amount/quantity, as stated in the “Quantity” field. In the case of 1-0-1 and an amount of 2, the patient receives 2 medications in the morning, none at noon, and 2 medications in the evening.

The final information needed to input a new medication on a patient’s card is the date from and to when the drug should be administered. Here, it is possible to ignore the end date for long-term medication. In the case of an urgent order, the start date can be ignored. The current date will be automatically filled in along with the increased priority.

Data cannot be input retroactively into the past and must progress in a logical order, where the start of medication use and the start date come before or on the same day as its termination.

Sending the prescription by one of the two buttons offers the incorporation of the drug into the patient’s list of medications. This effect is immediately visible. The new drug is shown in the first position in the medication report.

6.2.3. Preview of the Patient’s Current Medications

Each sample patient has a pre-filled current medication list generated by IDH, which is a random selection from the drug database and no diagnosis. Again, this is primarily about the widest possible range of test cases. By filling in the prescription, new drugs can be added, and you can remove any of the existing ones from the database by pressing the “Delete” button.

The information displayed in the individual drug view is minimal, but sufficient set of data that is reflected in the DASTA report and that comes from the new medication form. It is again an effort to make the data flow as clear as possible. Even though the real system would show some additional information, this might unnecessarily attract attention, even though it does not play any role in the process demonstrated.

6.2.4. Selection of Day for the Generation of Medication Message

Here, a single click is enough to display a calendar for selecting the date to which you want to issue medication. A good helper for choosing a suitable date is a direct look into the patient’s medication history, where drug names are accompanied by dates of use. After selecting the date, another field is displayed with generated messages and a preview of the IDH physical output.

If a patient’s medication as of the selected date grows to unrealistic dimensions, for clarity of outputs, it will be reduced to a maximum of 10 various medications.

6.2.5. Visualization of the Message Generated from the Input Data in the DASTA Standard

After a date for medication administration is selected, fields that have been hidden up to now are revealed. The first of these is a DASTA message in XML format.

Here, we use the sample DASTA standard message, which is part of its documentation. Individual fields are filled with information from the patient’s card and medication on that day. Highlighted is the information we will need to convert to an HL7 message. In real operation, this message will be provided by the HIS itself.

In the message, information shared between DASTA and HL7 standard messages is shown in a different color, as can be seen in Figure 11.

6.2.6. An HL7 Message Generated from a DASTA Message

The HL7 message appears along with the DASTA message, although it is generated slightly later. The DASTA message is the source of all the information contained here. Therefore, we do not take the displayed data from the patient card or medication but take it directly from the message, which we will also work with in real operation. Again, there is color-shaded data that is shared between messages, see Figure 12.

The format of this message directly corresponds to a format that is “readable” for ADMS.

7. Tests Performed and Results

For illustrative purposes, we present only one example of a randomly generated patient. These are data contained only in IDH and do not correspond to any real patients (all patient’s information and medication are fictional). The aim is to make the output of the application as clear as possible to the reader of this message, who would not have enough time to try the application itself.

7.1. Patient 1

The patient (Martin Veselý), see Figure 13, lying in the Ear-Nose-Throat Clinique (abbr. ORL), was prescribed Tobrex eye drops (2 drops 3x daily) and Apo-Ibuprofen tablets (1 tablet in the morning and in the evening). Another previously entered medication is no longer in the current use of the patient.

From this input data, IDH will generate messages in the DASTA and HL7 standards and visualize them, as described in

Table 16. The message generated from the IDH-DASTA standard.

Message Generated from IDH-DASTA Standard
1:	<?xml version=“1.0” encoding=“UTF-8”?>
2:	<ds:dasta xmlns:ds=“urn:cz-mzcr:ns:dasta:ds4:ds_dasta” xmlns:dsip=“urn:cz-mzcr:ns:dasta:ds4:ds_ip” id_soubor=“MEDICALC_KK11115_2005-12-12T14:46:25” verze_ds=“04.19.01” verze_nclp=“02.66.01” bin_priloha=“T” ur=“T” typ_odesm=“KK” ozn_soub=“11115” dat_vb=“2008-06-13T14:46:25” potvrzeni=“P”>
3:	<ds:zdroj_is kod_firmy=“MEDICALC” kod_prog=“WMEXP” verze_prog=“2.2.3.8”/>
4:	<ds:pm>
5:	<ds:as typ=“I” poradi=“1”>
6:	<ds:vnitrni>999</ds:vnitrni>
7:	</ds:as>
8:	</ds:pm>
9:	<ds:garant_dat id_garant=“450124145” odbornost=“801”>MUDr. Jan Konečný</ds:garant_dat>
10:	<ds:is ico=“12345678” icz=“44101000” icp=“44101882” oddel=“ORL”>
11:	<ds:as typ=“I”>
12:	<ds:vnitrni>801</ds:vnitrni>
13:	</ds:as>
14:	<dsip:ip id_pac=“1801020908”>
15:	<dsip:rodcis>1801020908</dsip:rodcis>
16:	<dsip:jmeno>Martin</dsip:jmeno>
17:	<dsip:prijmeni>Veselý</dsip:prijmeni>
18:	<dsip:dat_dn format=“D”>2018-01-02</dsip:dat_dn>
19:	<dsip:sex>M</dsip:sex>
20:	<dsip:h vyska=“185” hmotnost=“83.5” dat_ab=“2005-12-30T09:46:25”/>
21:	<dsip:pv_pac typ_pv=“ZP” dat_ab=“2005-12-01T12:53:12”>
22:	<dsip:pv_zp>
23:	<dsip:cispoj>7052024826</dsip:cispoj>
24:	<dsip:kodpoj>111</dsip:kodpoj>
25:	</dsip:pv_zp>
26:	</dsip:pv_pac>
27:	<dsip:lek dat_ab=“2005-09-26T18:40:09”>
28:	<dsip:garant_dat id_garant=“5511111111” odbornost=“606”>Mgr. Jmeno Prijmeni</dsip:garant_dat>
29:	<dsip:lek_v nazev_lek=“TOBREX” ind_oprav_sd=“N” poc_bal=“2” kod_lek=“93207”>
30:	<dsip:dat_du typ=“A”>2019-12-17T00:00:00</dsip:dat_du>
31:	<dsip:rozpis_v>2 - 2 - 2</dsip:rozpis_v>
32:	<dsip:vydal>MUDr. Jmeno Prijmeni</dsip:vydal>
33:	<dsip:pozn>používat pouze po doporučení lékaře</dsip:pozn>
34:	</dsip:lek_v>
35:	<dsip:lek_v nazev_lek=“APO-IBUPROFEN RAPID 400 MG SOFT CAPSULES” ind_oprav_sd=“N” poc_bal=“2” kod_lek=“170267”>
36:	<dsip:dat_du typ=“A”>2019-12-17T00:00:00</dsip:dat_du>
37:	<dsip:rozpis_v>1 - 0 - 1</dsip:rozpis_v>
38:	<dsip:vydal>MUDr. Jmeno Prijmeni</dsip:vydal>
39:	<dsip:pozn>používat pouze po doporučení lékaře</dsip:pozn>
40:	</dsip:lek_v>
41:	</dsip:lek>
42:	</dsip:ip>
43:	</ds:is>
44:	</ds:dasta>

.

Table 17. The message generated from the IDH-DASTA standard.

Message Generated from IDH-HL7 Standard
1:	MSH|^~\&|HOSPITAL|PHARMA|SWISSLOG|HL7GATE|20050926184009|RDE^O01|MSG_ID|P|2.2|||||
2:	PID|||1801020908||Veselý^Martin||20180102|M||||||||||||||||
3:	PV1|||ORL|||||||||||||||||||||||||||||||||||||||||||||||
4:	ORC|NW|DASTA_ORDER_ID|||||||20120403091225|||||||||||
5:	RXE|^^^201912170001^201912172359^1^^^^1000&1600&2200|93207||||||||6|||||||||||||||||||PK
6:	RXE|^^^201912170001^201912172359^1^^^^1000&2200|170267||||||||2|||||||||||||||||||UD

describes an algorithm of messages generated from IDH in the HL7 standard.

IDH will further create a simple visualization of the prepared “circuit” with the patient’s 24-h drug therapy, see Figure 14. The circuit contains a “dispatch note” for the patient Martin Veselý (the dispatch note provides information about the patient and all his/her medication, whether or not it can be physically single-dose) and “bags” with single-doses of the prescribed medicine. Because drops cannot be single-dosed, the robot would only dispense ibuprofen in single doses, and the next part of the medication would be handled by an automated warehouse instead of robotics for single-dose preparation.

The image representing the tablet, as shown in Figure 9, will reappear when you click to an arrow on the right. The arrows in the visualization field of the “drug bag” show the “flipping” between the images of the individual single doses that the ring would contain. The tablet image is shown twice because the patient is prescribed an ibuprofen tablet twice a day, and the “ring” contains a single-dose, 24-h medication.

7.2. Patient 2

A patient (Petr Procházka), shown in Figure 15, lying in the Orthopedics Department, was prescribed two medicines: Muscoril in the morning and Una tablet in the evening.

From this input data, IDH will generate messages in the DASTA and HL7 standards and visualize them, see

Table 18. The message generated from the IDH-DASTA standard.

Message Generated from IDH-DASTA Standard
1:	<?xml version=“1.0” encoding=“UTF-8”?>
2:	<ds:dasta xmlns:ds=“urn:cz-mzcr:ns:dasta:ds4:ds_dasta” xmlns:dsip=“urn:cz-mzcr:ns:dasta:ds4:ds_ip” id_soubor=“MEDICALC_KK11115_2005-12-12T14:46:25” verze_ds=“04.19.01” verze_nclp=“02.66.01” bin_priloha=“T” ur=“T” typ_odesm=“KK” ozn_soub=“11115” dat_vb=“2008-06-13T14:46:25” potvrzeni=“P”>
3:	<ds:zdroj_is kod_firmy=“MEDICALC” kod_prog=“WMEXP” verze_prog=“2.2.3.8”/>
4:	<ds:pm>
5:	<ds:as typ=“I” poradi=“1”>
6:	<ds:vnitrni>999</ds:vnitrni>
7:	</ds:as>
8:	</ds:pm>
9:	<ds:garant_dat id_garant=“450124145” odbornost=“801”>MUDr. Jan Konečný</ds:garant_dat>
10:	<ds:is ico=“12345678” icz=“44101000” icp=“44101882” oddel=“ORTOPEDIE”>
11:	<ds:as typ=“I”>
12:	<ds:vnitrni>801</ds:vnitrni>
13:	</ds:as>
14:	<dsip:ip id_pac=“5704220314”>
15:	<dsip:rodcis>5704220314</dsip:rodcis>
16:	<dsip:jmeno>Petr</dsip:jmeno>
17:	<dsip:prijmeni>Procházka</dsip:prijmeni>
18:	<dsip:dat_dn format=“D”>1957-04-22</dsip:dat_dn>
19:	<dsip:sex>M</dsip:sex>
20:	<dsip:h vyska=“185” hmotnost=“83.5” dat_ab=“2005-12-30T09:46:25”/>
21:	<dsip:pv_pac typ_pv=“ZP” dat_ab=“2005-12-01T12:53:12”>
22:	<dsip:pv_zp>
23:	<dsip:cispoj>7052024826</dsip:cispoj>
24:	<dsip:kodpoj>111</dsip:kodpoj>
25:	</dsip:pv_zp>
26:	</dsip:pv_pac>
27:	<dsip:lek dat_ab=“2005-09-26T18:40:09”>
28:	<dsip:garant_dat id_garant=“5511111111” odbornost=“606”>Mgr. Jmeno Prijmeni</dsip:garant_dat>
29:	<dsip:lek_v nazev_lek=“MUSCORIL INJ” ind_oprav_sd=“N” poc_bal=“2” kod_lek=“107944”>
30:	<dsip:dat_du typ=“A”>2019-12-17T00:00:00</dsip:dat_du>
31:	<dsip:rozpis_v>1 - 0 - 0</dsip:rozpis_v>
32:	<dsip:vydal>MUDr. Jmeno Prijmeni</dsip:vydal>
33:	<dsip:pozn>používat pouze po doporučení lékaře</dsip:pozn>
34:	</dsip:lek_v>
35:	<dsip:lek_v nazev_lek=“UNO” ind_oprav_sd=“N” poc_bal=“2” kod_lek=“46620”>
36:	<dsip:dat_du typ=“A”>2019-12-17T00:00:00</dsip:dat_du>
37:	<dsip:rozpis_v>0 - 0 - 1</dsip:rozpis_v>
38:	<dsip:vydal>MUDr. Jmeno Prijmeni</dsip:vydal>
39:	<dsip:pozn>používat pouze po doporučení lékaře</dsip:pozn>
40:	</dsip:lek_v>
41:	</dsip:lek>
42:	</dsip:ip>
43:	</ds:is>
44:	</ds:dasta>

and

Table 19. The message generated from the IDH-HL7 standard.

Message Generated from IDH-HL7 Standard
1:	MSH|^~\&|HOSPITAL|PHARMA|SWISSLOG|HL7GATE|20050926184009|RDE^O01|MSG_ID|P|2.2|||||
2:	PID|||5704220314||Prcházka^Petr||19570422|M||||||||||||||||
3:	PV1|||ORTOPEDIE|||||||||||||||||||||||||||||||||||||||||||||||
4:	ORC|NW|DASTA_ORDER_ID|||||||20120403091225|||||||||||
5:	RXE|^^^201912170001^201912172359^1^^^^1000|107944||||||||1|||||||||||||||||||PK
6:	RXE|^^^201912170001^201912172359^1^^^^2200|46620||||||||1|||||||||||||||||||UD

.

IDH will again create a “circle” at the same time as visualizing the writing of data standards, shown in Figure 16. In the case of Petr Procházka, this is a patient’s guide, followed by two different single doses (ampoule with a solution for injection and pill).

In our testing environment, the Swisslog Interface Suite for HL7 was installed, which provided the communication with C.P.O.E. (computerized physician order entry or computerized provider order entry) via its TCP components. Our developed solution received the DASTA message via Web Form, as described above, which simulates receiving input data according to Czech DASTA message format requirements. The DASTA message was then translated into the HL7 format using our module and sent via a TCP connection to the HL7 interface. The response was received via the same connection, acknowledging the acceptance of the message by the C.P.O.E. with very low latency that ensured instant execution.

7.3. Benefits of the Innovated Process

Thanks to the developed SW interface, which enables the conversion of data from Czech DASTA to international HL7 standard, and the Swisslog Pillpick system for automated and safe medication processes can be used. It is a system for the preparation of single doses of drugs, which is the most technologically advanced, the safest in terms of errors in medication, the most comprehensive in terms of drug inventory management, and the most effective from the drug consumption point of view.

In addition to eliminating or minimizing errors in the medication process and economic-operational inefficiencies in existing practices, such an innovated (automated) medication process brings a number of benefits:

• Saving time of nurses—according to measurements within the performed process analyses, 15–30% of nurses’ time is used for the management of the drug supply of temporary warehouses and the preparation of medicines according to the surgery. With the introduction of the proposed process-technological change, this time would be re-allocated, in favor of more intensive and thus better nursing care. (Due to the fact that nurses are generally in short supply in Czech hospitals, it cannot be assumed that hospitals will dismiss nurses.)
• Effective use of expertise and know-how of hospital pharmacists and clinical pharmacists, who in the current process play the role of storekeepers in the pharmacy, rather than professional participation in the process of healing the patient by the hospital.
• Easier accreditation or certification of the quality of care, for which the hospital must demonstrate a continuous increase in the quality of care in measurable indicators and data on the results of clinical care. Renewing accreditation forces you to change your routine and demonstrate improved security and process optimization.
• Reduction of the administrative burden of individual departments, thanks to the digitalization of all drug transactions (up to the level of single-dose packages), including patient verification before drug administration.
• Reduction of hospital pharmacy requirements for statim orders, which will be truly exceptional in the new system. The pharmacy will be operated (and thus the individual departments “serviced”) according to a precise schedule of work activities.
• Effective reporting of the actual cost of medicines to individual patients.
• Possibility of generating comprehensive analyses and reports in the field of medication and drug management in order to optimize the drug supply, clinical studies, documents for discussion with insurance companies, etc.
• Increasing the image of the hospital.
• Reduction of risks in the form of future costs of possible legal disputes arising from potential lawsuits of injured patients; in connection with this, the better position of the hospital in relation to commercial insurance companies that insure liability for damage to third parties. (The importance of both of these aspects can be expected to grow in the future.)

8. Conclusions

The paper described the interface created between DASTA and HL7 standards using a visual simulation presentable via a web interface that very simply simulates the process of a doctor’s prescribing a drug in the ward and its automated preparation in a hospital pharmacy. The newly-created interface between DASTA and HL7 (which has a working name abbreviated as IDH) allows the selection of medication in a very simple simulation of the registration of a patient’s medical record and treatment plan in HIS, a statement of the data sentence generated in the DASTA standard, a statement of the data sentence in the HL7 standard from the DASTA message, and showing the patient’s prepared medication in a simple graphical output, simulating a robotically prepared “circuit” of the patient’s personalized drug therapy with accompanying information about the patient and his or her medications for the next 24 h.

To ensure interoperability between healthcare information systems, a solution is presented. The web application for the translation of medical data from the DASTA standard to HL7 can help medical staff and hospital administrators because they can configure the local system easily and prepare it for communication with other systems. The resulted information will have a higher quality and will provide knowledge that will support safe drug dispensing.

For the purpose of this paper, we decided to use option 3 as an illustrative way how to easily transfer data from one standard to another. For future work, the final version of this SW will work with data provided by the real HIS or will acquire data via the API (a variant preferred by HIS vendors/administrators). In the final phase, we should, therefore, create an integration bridge that retrieves HIS data through the API and provides the necessary conversion and communication of messages to make them usable for Swisslog robotics. In the final phase, this should most likely be option 2 described above.