Development of SW Interface between Healthcare Standards—DASTA and HL7

: 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 e ﬃ ciency 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. 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 proﬁles, which refer to HL7 standards, are adopted within hospitals for message exchange and for the deﬁnition of integration scenarios. The broad overview of the standards as well as a brief discussion of the immediate history of healthcare standards. dealt with the following standards: HIPAA (Health Insurance Portability and Accountability Act), (International Revision), and CPT (Current Procedural Terminology) in his paper. Abstract message syntax: The message consists of control and data segments, the frequency of which (cardinality) is deﬁned using mandatory / optional / repeatable values. The frequency of occurrence can be described using the abstract message syntax.


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 The automated and safe medication process, as can be seen in Figure 1, proceeds as follows: 1. The doctor prescribes a schedule of medication in the Information System (IS). 2. The clinical pharmacist can verify the medication, possibly corrected as needed (e.g., exchange for appropriate drug or adjusts the strength of the dose). 3. 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. 4. The pharmacist completes the therapy (robotically-bound single-dose packs and non-singledose packs) and prepares them for transport to the ward. 5. Nurses give this therapy (already prepared in the pharmacy) to patients at the right time.

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

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) The automated and safe medication process, as can be seen in Figure 1, proceeds as follows: 1.
The doctor prescribes a schedule of medication in the Information System (IS).

2.
The clinical pharmacist can verify the medication, possibly corrected as needed (e.g., exchange for appropriate drug or adjusts the strength of the dose). 3.
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. 4.
The pharmacist completes the therapy (robotically-bound single-dose packs and non-single-dose packs) and prepares them for transport to the ward.

5.
Nurses give this therapy (already prepared in the pharmacy) to patients at the right time.

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

Authors Main Contribution (Paper Topic)
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.

Authors Main Contribution (Paper Topic)
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.

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.

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.

Research Area Main Contribution (Paper Topic)
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. 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.

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.

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.

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

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 presents the definition of selected segments as well as an overview of the message field values and their description. 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.

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 presents the definition of selected segments as well as an overview of the message field values and their description.

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.

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

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 (Tables 4-15) describe individual segments of the HL7 message for the 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.

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 (Tables 4-15) describe individual segments of the HL7 message for the prescription of medication.      OBX||ST|1010.1ˆHEIGHT||190|cm<CR> The messages described above (Tables 3-14) send the following information to the PillPick system: 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.

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.

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.

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.

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.

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.

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:

1.
Use of an additional HIS/PIS module, if the HIS/PIS manufacturer provides such a module-see option 1 below.

2.
It is also possible to create an integration bridge communicating with HIS/PIS via the available API (application program interface)-see option 2 below. 3.
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.

4.
For a more comprehensive solution, it is possible to implement an integration bus-see option 4 below.

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

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.

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.

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.

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

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.

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.

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

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: 1. 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, 2.
A statement of the data sentence created in the DASTA standard, 3.
A statement of the data sentence created in the HL7 standard, "translated" through the interface created between protocols, 4.
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: 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.

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

Patient information 2.
New medication entry form 3.
Preview of the patient's medication 4.
Selection of the date to generate a medication report 5.
DASTA report as of the given day 6.
Illustration of the resulting IHD physical output

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.

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.

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.

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.

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. 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. 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 Figure 11. IDH-DASTA message for the specified day.

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. Figure 11. IDH-DASTA message for the specified day.

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.

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.

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. The format of this message directly corresponds to a format that is "readable" for ADMS.

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.

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.  From this input data, IDH will generate messages in the DASTA and HL7 standards and visualize them, as described in Table 16.

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.

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

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

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.