gms | German Medical Science

The current digital transformation changes business processes by saving and exchanging relevant information in appropriate IT structures and procedures, respectively, instead of on paper or other media. As a result of this transformation, requirements for the storage and communication of medical information are constantly growing at German university hospitals. An increasing number of IT procedures, more data and documentation sources have to be combined into a single electronic patient record. At the same time, the data generated need to be accessible to recipients outside the hospital, including telemedicine procedures, aftercare providers or the patients themselves. Moreover, patients might want to provide information prior to their in-patient treatment. Computer-based decision support, including applications of artificial intelligence algorithms, rely critically on high-quality patient data and can profit from providing comprehensive datasets. Finally, medical data should be prepared and provided for different forms of secondary data use, in particular for clinical and health services research to expand medical knowledge. Therefore, these digitalization processes are also directly related to the on-site, research-driven activities of the consortium SMITH “Smart Medical Information Technology for Healthcare” [1] of the German Medical Informatics Initiative [2].

Interoperability of data, information, and processes is the key to meeting these requirements [3]. Interoperability in healthcare is defined as (I) tested conformance of two or more systems or components to specifications that are compliant to technical standards for global use and, on that basis, (II) the ability of these systems or components to (a) exchange information and to (b) use the information that has been exchanged [4], [5]. While achieving interoperability in healthcare is a difficult task, it ensures that the fruits of digitalization can be effectively used in healthcare by formatting and representing medical data in such a way that it can be processed automatically and system-independently anywhere in the world.

Strategies to create optimal capabilities of information technology to support the processes in healthcare institutions can be categorized in two variants of implementation [6]:

• Holistic/monolithic approaches
  Most components of a hospital information system (HIS) are supplied by the same manufacturer. Here, storage of data and creation of interfaces between sub-systems is of concern to the manufacturer.
  However, the larger the healthcare institution, the more difficult it is to implement all IT processes from a single manufacturer. With the connection of highly specialized IT systems and medical devices, different vendors are inevitable.
• Best-of-breed strategies
  The second variant focusses on the use of different available systems: Best-of-breed strategies emphasize the need for sub-systems that are optimally adapted to their application, regardless of which manufacturer supplies them. Here, interfaces and data storage are fundamental and part of the IT implementation in the healthcare institution.

A different way of approaching the need for interoperability is a platform strategy. Here, monolithic versus best-of-breed becomes a minor matter, since all parts of a medical documentation – patient information, documents, single data etc. – are stored in a vendor-neutral platform independent from all clinical sub-systems (see Figure 1 [Fig. 1]). Usually, a platform strategy is combined with a best-of-breed approach, where hospital information system (HIS), electronic medication management and order entry (eMedication), patient data management system (PDMS), clinical workplace system (CWS), mobile applications, and other clinical sub-systems are chosen from different vendors. However, the combination of a platform strategy and a best-of-breed approach is not required.

The IT systems are connected to the platform via standardized interfaces. Archiving, inter-institutional communication, and secondary data use will be enabled through the services of the platform. To achieve this, the platform and its interfaces rely on interoperability standards, especially in accordance with the specifications of the international standardization initiative IHE (Integrating the Healthcare Enterprise). Here, technical profiles describe how a master patient index (MPI) can be utilized to combine patient identity managements from different clinical sub-systems.. The IHE XDS profile (Cross-Enterprise Document Sharing) adds the registrability and storability of clinical documents to the functionality of a platform.

While IHE-XDS-based platforms are currently becoming increasingly widespread – especially for the use for document-based communication with other healthcare facilities or patient-managed apps – the connection of FHIR-conform data communications in hospitals in Germany is still relatively new. However, the interest in FHIR in this area is very high [7], [8].

As a consequence, vendor-neutral platforms will have to support various types of data management in the future and make discrete individual data available in addition to document-based exchange.

The necessity and implementability of the exchange of individual, patient-related data in an archiving and communication platform of a healthcare facility will be illustrated in a Jena University Hospital project.

At Jena University Hospital, a vendor-neutral archive (VNA) for patient-related data management was introduced in 2016. The core components of this platform are the mapping of medical documents in the standardized format HL7 CDA (Clinical Document Architecture) based on the human-readable data format XML and the communication of individual data in the format HL7 FHIR (Fast Health Interoperability Resources).

To establish FHIR-based storage and transfer of single data from and to clinical sub-systems, several sub-projects have been initiated at the IT business division at Jena University Hospital, in cooperation with several industry and research partners:

• addition of FHIR-based communication and persistence to the VNA platform,
• FHIR-based anamnesis documentation and patient self-assessment,
• electronic medication management,
• hospital food menu ordering and supply,
• FHIR-based secondary data use for research and analysis projects.

In each of the sub-projects, a common method was applied, which is similar to the development and profiling of technical standards [5]. The steps of this method are:

• analysis and documentation of relevant medical information,
• overview and selection of semantic annotations of the medical data applying international terminologies,
• research of relevant components of the technical standard and existing profiles for technical mapping,
• selection and application of suitable IT procedures and tools for the integration of the functionality in cooperation with appropriate manufacturers.

In this case report, we illustrate the advantages of structured, interoperable data handling via the HL7 FHIR standard as well as the scope, methods, and first experiences from Jena’s sub-projects. We discuss open questions and general considerations for achieving interoperability, especially the applicability of the chosen method and the platform strategy to achieve single-data based archiving and communication combined with existing document-based approaches in healthcare facilities in general.

As an example throughout, we use individual data in the form of allergy documentation. Allergic diseases are a significant cause of death worldwide. Allergies or related diseases affect at least 30% of the population and almost 80% of all families [9]. In Germany, almost a third of all citizens are affected by an allergic disease [10], [11]. Allergic reactions appear in different organ systems and can possibly lower the quality of life for affected persons. The medical costs associated with these allergic diseases can be significant.

A record of a clinically determined allergy or intolerance is essential for patient care. Practitioners need to estimate hypersensitivities or potential risks to an individual. Otherwise, the use of certain materials could lead to adverse reactions to the specified substance, or the class of substances. When a sensitivity to a substance or material is identified, the information needs to be recorded. This comprises any reaction event that is characterized by any harmful or undesirable physiological response that is specific to the individual.

Allergies or intolerances recorded in a patient’s medical history or in direct succession of a patient’s hypersensitivity reaction can also improve perioperative care.

Intolerances and allergies should be recorded differently since they cause different physical reactions (immunological for allergies vs. non-immunological for intolerances). Records should generally classify adverse reactions as intolerances when they are either determined or perceived to not be allergic or allergy-like.

Unfortunately, scientific publications on FHIR-based projects related to allergies or intolerances are still rare – an example is [12]. At Jena University Hospital, the aforementioned platform containing a patient’s medical record, with individual information represented using HL7 FHIR, provides allergy or intolerance information based on clinical assessments in order to indicate a higher level of potential risk for a patient. By directly linking these data (FHIR resource AllergyIntolerance) with the patient master data (FHIR resource Patient), it can be easily reused, e.g. for preoperative preparation. For example, known allergies to certain substances can influence the stock lists for operating theaters and thus prevent the use of these substances.

A prominent example here would be latex gloves, which according to the German S1 guideline are still often used for operations [13]. The use of synthetic latex is only recommended in cases of known latex allergies. In the case of latex, the documented prevalence of allergic reactions has risen from less than 1% to 12% in the last 25 years [14], [15], [16], [17]. Digitally documented allergy data from the patient record will automatically create a list of allergy-causing components from the patient’s medical history and thus prevent usage of materials that could cause a harmful response. Also, digitally managed surgery schedules can be automatically created to schedule patients with latex allergies at the beginning of the day, immediately after cleaning, according to general recommendations, to prevent contamination of the room with the allergen.

By a consistent digital documentation of possible cross allergies to known allergies and previous minor allergic reactions, risks can be excluded in advance of the treatment [18]. There are documented cases of undetected minor allergic reactions (e.g. to chlorhexidine) during previous operations which led to anaphylactic shock during a later operation [19]. The digital documentation of allergies as FHIR resources would offer the possibility of documenting such a minor reaction as a suspected unconfirmed allergy during postoperative treatment. Such a reaction could also be observed in a later treatment of the patient and could trigger a precautionary test for the suspected allergen.

The sub-project aims to integrate patients’ pre-existing conditions into the archiving and communication platform using the example of structured allergy and intolerance information.

Currently, most of these data concerning patients’ allergies and intolerances are documented in clinical sub-systems containing individual lists or free text as possibilities for documentation. With the enhancement of the vendor-neutral platform in the next years, these data will be available independently of the sub-systems via HL7 FHIR. In order to achieve this, new interfaces for data transformation to HL7 FHIR are currently being developed in Jena in cooperation with manufacturers, but also as in-house development [20]. A first sub-project in this field concerns the medical and technical harmonization of anamnestic data, including allergy information.

The medical and nursing anamnesis are some of the core procedures required for diagnosis and have a high importance in every medical discipline. The recording of the medical history describes a process step in the context of inpatient or outpatient treatment in which a doctor or nurse questions the patient in order to obtain potentially important medical data and document this data for further therapy [21]. The collected data are documented using schematized history sheets. These sheets contain various subjects like pre-existing conditions, allergies/intolerances, risk factors, medications, immunization status, current complaints, and social aspects [21]. Adequate documentation of any known allergic disease is motivated by the high prevalence, associated risks, and the costs of allergies (see above).

Documentation of any known allergic disease is of high importance. Part of this documentation is the individual patient history including observed complaints and their circumstances.

As part of the increasing digitalization in healthcare, numerous software applications have been developed which can be used by doctors and nurses to document anamnesis in hospitals, medical care centers, doctor’s offices, and other healthcare providing facilities [22]. The process of collecting history data can already be initiated prior to entering any healthcare facility. Patients themselves can access an online patient portal from home with registration in a privacy-compliant way. Following registration, they complete a questionnaire concerning their situation, or alternatively, a patient can complete this step at his bedside terminal during his stay at the hospital.

To integrate anamnestic data into the archiving and communication platform, these have to be structured and semantically annotated. This is the focus of the sub-project, which will then make it possible to properly archive anamnestic information about patients.

University Hospital Jena currently utilizes multiple IT procedures as components of the hospital information system, clinical workplace system or patient data management system, in which the medical history of a patient can be documented.

Based on the ongoing deployment of mobile devices (smartphones, tablets) with mobile applications for accessing and editing medical documentation location-independently, an uninterrupted transmission of structured and standardized medical history data as well as their reusability must be guaranteed. To accomplish this, Jena University Hospital applies the HL7 FHIR standard.

The FHIR standard makes it possible to transmit medical anamnesis data, including allergies, uninterrupted and in a structured and standardized format. The transmission of data is possible between mobile devices and main- or sub-systems and between the main- and a suitable archive-system. In Jena, the medical history data will be queried via multiple FHIR questionnaire resources. The information can be accessed by different applications.

In Jena, necessary basic anamnesis data is currently being harmonized across all clinics. One of the most important experiences from the projects is that the professional agreement on the representation of medical contents in the patient-specific documentation of a healthcare institution is top priority. The cooperation with responsible clinicians and caregivers should lead to a “technology-agnostic information modelling” [23] that will be used afterwards for a technical representation.

In 2021–2022, data modeling and mapping to FHIR resources will follow, so that specific anamnesis data such as known allergies can then be transmitted using FHIR interfaces that are currently established between the clinical workplace system, the mobile patient record, and the newly introduced nursing documentation system. All information will be stored in a FHIR server as part of the archiving and communications platform (VNA).

Drug intolerances, especially allergic reactions, are a frequent phenomenon and pose a serious problem in hospital treatment, where medication often has to be applied quickly and directly. These reactions can be against the active ingredients of a pharmaceutical product (e.g. to certain antibiotics) but also against auxiliary substances (e.g. dyes or preservatives) or application materials (e.g. to certain plastics). If the intolerance or allergy is known to the patient, this information can be documented during anamnesis and is a common question in pre-admission or pre-operative questionnaires (cf. section 3.1).

For this information to be compared with possible allergens in a medication which is to be prescribed, an electronic medication management process has to be established. This process consists of the following steps:

• computerized physician order entry (CPOE),
• pharmacist clinical review,
• unit-dose medication dispense,
• patient identification and assessment,
• medication confirmation,
• documentation of medication.

Through these steps, the following elements are verified [24]:

• correct patient,
• appropriate drug,
• appropriate drug dosage,
• appropriate drug route,
• appropriate time of administration.

Each of these steps can be supported by IT processes tailored to the requirements of the task. Especially relevant to the prevention of adverse events due to intolerance or allergic reactions are order entry, pharmacist review, and documentation of medication.

The information that a patient has an allergy to a substance is only one part of the necessary documentation. Other important data about the allergy include codes for the substance (drug, auxiliary substance, application material, as mentioned above) causing the allergy, codes for the allergy itself, the type of allergic reaction caused, and the verification status of the allergy. The verification status is especially useful to record as it is often unknown and inaccurate allergy information reduces the effectiveness of the documentation [25].

Semantic annotation of allergens and medications with codes from internationally consented terminologies – an important part of FHIR-based communication and persistence [26] – is the next challenge. Here, substance and allergies need to be coded and must be brought into context. Common, billing-related code systems are not sufficient for this task. Codes for the allergy and a substance causing the allergy, for example, must be selected from LOINC or SNOMED CT codes. Several projects have been identified where a representation of medication data in FHIR was in the focus [27], [28], [29] and findings from these works are to be included in further specifications.

Medication data are a critical component of patient-related information in the context of treatment. The sub-project focuses on the storage of such information in the archiving and communication platform in a structured manner and relating it to anamnestic and disease information.

The influence of digitally available medication statements on drug safety has been investigated at Jena University Hospital [30], [31]. Likewise, Jena has a long-term experience with unit dose medication processes using barcode and RFID tracking methods [32].

During 2020 and 2021, an electronic medication management system is in the process of installation at Jena University Hospital, which supports CPOE, pharmacist review and documentation of medication. The new IT system is connected to clinical workplace systems, mobile patient record and pharmacy materials management. Medical information relevant to drug safety checks, such as anamnesis data including premedication, diagnoses, or laboratory results, can be imported into the system. During medication order and pharmacist review, this information is included to generate drug safety alerts, reminding the user about dosages, allergies, drug-drug interactions, or other possible adverse events.

To achieve this functionality, FHIR-based interfaces to relevant IT procedures will be enabled. Thus, medical information will be sent as FHIR AllergyIntolerance, Condition, DiagnosticReport, and MedicationStatement resources. Orders, checks, and given medication will be available respectively as MedicationRequest, MedicationAdministration, and Medication for the drug itself.

In addition to pharmaceutical databases containing coded products and coded ingredients (possible code systems are ATC – Anatomical Therapeutic Chemical Classification System, UNII – Unique Ingredient Identifier, or ASK – “Arzneimittel-Stoffkatalog”), relations between terminologies must be provided. To achieve this, at Jena University Hospital we are using a terminology server as a component of the documentation, mapping, and alerting process. It is part of the electronic medication management system and provides the named functionality. Code systems, relations, and mappings can be stored and will be available via FHIR terminology functions.

The electronic medication management system has been implemented at Jena University Hospital, and a pilot project is currently running at one clinic. FHIR-based interfaces will be expanded in 2020.

During an inpatient stay in hospital, correct medical care and the right diet are essential factors for a patient’s recovery. A hospital kitchen is responsible for the correct preparation of thousands of meals every day. Several statistics show that up to 15% of citizens in German-speaking countries suffer from food allergies (immunological defense reaction detectable) or food intolerances (no immunological defense reaction detectable) ([33] p. 23, [34] p. 4, [35] p. 23). In the worst case, a food allergy can lead to anaphylactic shock, therefore a correct and patient-oriented preparation of meals is essential.

Before an inpatient stay, an anamnesis is usually taken (cf. section 3.1). From an organizational point of view, this provides a good basis for subsequent consideration of the allergies and intolerances during meal preparation. Since the process of catering for dozens of patients has to be planned, performed, and documented in a hospital or clinic, a supporting software system for food menu ordering and supply is often used. If both the anamnesis and the planning and execution of the meal preparation are digitally supported, data exchange between the systems used represents a possible way of adapting the production plan in the kitchen. This allows the allergies and intolerances of a patient to be taken into account during meal preparation.

In a medical facility, several highly specialized devices and systems may not have the knowledge of the existence of all other systems, or at least cannot exchange data with these systems. This lack of communication between systems illustrates a current medical informatics challenge. Medical software solutions are often individual solutions, adapted to the specific use case. For this reason, highly specialized systems such as HIS, LIS, PACS or even catering systems were developed and engineered to the functional requirements of the corresponding application. Naturally this also has an influence on the internal data format used to store information. Each system currently has its own proprietary format. Previously implemented interfaces between the systems also represent individual solutions, since an interface must be created for each system or a system must adapt to the interface of another system.

The sub-project focuses on a further use of the patient-related data stored in the archiving and communication platform so that they are available for menu ordering.

Jena University Hospital Jena is striving to create process-related, syntactic, and semantic interoperability with standardized interfaces and access options as an integral part of a vendor-neutral architecture in the form of a platform strategy. For this reason, in the future all information shall be stored in a central FHIR repository both during anamnesis and during the planning and provision of patient catering. As soon as a primary system stores a food allergy or intolerance as an AllergyIntolerance FHIR resource linked to a patient in the central repository, this can be considered by other systems. Due to the interoperable data exchange format FHIR, the primary system itself only plays a subordinate role – the patient-related data and thus the actual patient comes to the fore. Only free text documentation from existing sub-systems currently stands in the way of a sustainable and robust solution. However, Jena University Hospital is also meeting this challenge with the first proof of concepts with natural language processing services [36], [37].

The manufacturer independence that has been gained allows the application case to be extended by further improvements for the patient. In Jena, an extension of a newly introduced menu ordering system is currently being planned which, for example, will be made available to patients in the form of a bedside terminal or a mobile device such as a smartphone or tablet and integrates food allergies and intolerances into the generation of a menu. These data are compared to stored information about the planned meals and their ingredients when these are belonging to one of the 14 groups of allergens requiring labelling in the EU [38]. When there is a match, e.g. a patient with severe peanut allergy and a meal containing peanuts, then the meal in question will not be offered to this patient for selection. To achieve this, first approaches to map the EU allergen categories to LOINC and SNOMED CT have been carried out in Jena in 2019 and shall be extended in 2021 and 2022 and used for mapping between special allergies and these categories using FHIR. Ontologies containing relations between domain concepts like SNOMED CT allow this type of mapping, but SNOMED CT must be licensed for this use, as Germany currently is not yet a member country of SNOMED International.

Documenting clinical data such as an allergy information in an interoperable format such as FHIR may be directly beneficial for patient care as described above, but also distally by allowing for analysis projects on this data. In the context of allergies, information about medication allergies stored in the AllergyIntolerance resource could for example be evaluated regarding their reliability and compared to the actually administered medication that was documented in the MedicationAdministration resource. This way it is possible to do quality checks both on allergy information and medication administration.

The basic procedure for such an analysis on FHIR data will be illustrated with an example of penicillin allergy. Castells et al. [39] describe how the label of “penicillin allergy” has two different sides in clinical practice. On one hand, it is important that true penicillin allergies are recorded and carefully considered in the treatment of a patient, as “Penicillins have been the most common cause of drug-induced fatal and non-fatal anaphylaxis in the United States and the United Kingdom” [39]. On the other hand, more than 90% of the patients with recorded penicillin allergy are actually falsely labelled and could receive the drug without risk of adverse events [40]. This is an important finding, as these patients often receive alternative medications such as vancomycin which may in turn lead to less favorable outcomes and a higher risk of developing antibiotic resistance. The main reason for this suboptimal treatment is the poor data quality of the allergy information. In many cases, the allergy information is acquired in childhood, when allergic symptoms can be confused with symptoms of viral or bacterial illness and passed on from there without any further validation [39]. However, If an allergy information is coded in an AllergyIntolerance resource in FHIR, this resource will not only hold information about the allergy status, but also about the source of this information (i.e. the recorder/asserter element of the resource) as well as information about the date of this information (i.e. the onset/lastOccurence element of the resource). With this information, it is possible to evaluate the allergy label in regard of its validity. In a data use project dealing with allergies, one could get all AllgeryIntolerance resources from a certain time span that code an allergy to penicillin. Since this resource is linked to a Patient resource and the Patient resource in turn is linked to all MedicationAdministration resources for this patient, it would easily be possible to collect the information about any medication given to patients with a recorded penicillin allergy in any given time frame and hospital. In addition, the level of validity of the allergy labels would be available too. The schematic representation of this extraction is shown in Figure 2 [Fig. 2] with an example of two AllergyIntolerance resource instances, each belonging to one specific patient with certain medication administrations recorded for this patient. Links between resources are indicated as dotted lines from attributes which are references to another resource, e.g. AllergyIntolerance.patient from AllergyIntolerance 1 references to Patient 1.

Once this data is collected, one could analyze the frequency of alternative antibiotics (e.g. vancomycin) administered depending on the level of validity of the allergy information. If the treating physician takes the reliability of the allergy information into account, one should see fewer alternative antibiotics for patients with possibly unreliable allergy information. Ideally, this information would instead be updated by the physician (e.g. by doing a skin test). But if the data would show that all patients with an allergy label are treated uniformly, this would indicate that an education program regarding antibiotic stewardship might be necessary. This program could advise physicians to do skin testing for patients with potentially unreliable allergy information, thereby reducing the administration of unnecessary alternative antibiosis. Even an interventional study investigating the effects of such a program could profit from the use of interoperability standards as it would be easy to collect and merge the interoperable routine data that constitute relevant endpoints (e.g. medication administration, quality of allergy information, adverse events in case of wrongly administered antibiotics).

The sub-project focuses on a further use of the patient-related data stored in the archiving and communication platform for study purposes, thus extending the use of the platform to such purposes.

There already is a study analyzing the effect of a clinical decision support system aimed at antibiotic stewardship in the context of bloodstream infections which uses FHIR resources both for a clinical decision support system and collection of endpoints [41]. If interoperability standards are implemented over a wide range of hospitals, as is the aim of the German Medical Informatics Initiative [2], these kinds of studies can be done at large scales. Ultimately, such studies will require less investment given that the costly process of collecting and consolidating data from different hospitals is reduced greatly when clinical routine data in a standardized format is available at all of the participating hospitals.

Overall, FHIR lends itself to many kinds of data use projects that can improve patient care: Clinical routine data can be used in both observational and interventional studies – though the latter may often require the need for an additional data collection – but will benefit from interoperability and data quality indicators that are provided by FHIR. Since the transition to FHIR would also make bigger amounts of clinical routine data available than ever before, the field of statistical learning and machine learning would also greatly benefit from this transition [3].

For the sub-projects related to the introduction and piloting of a FHIR-based component of the vendor-neutral archive at Jena University Hospital, Table 1 [Tab. 1] provides an overview of the respective domain or scenario concerning allergy documentation, the used FHIR resources, the terminologies relevant to each scenario, the IT sub-systems or modules involved, and the respective goal of each scenario/sub-project related to allergy documentation. To achieve each of the indicated goals, the extent of clinical sub-systems generating data and communicating these to or consuming them from the vendor-neutral archive become clear, as well as the use of specific FHIR resources for syntactic interoperability and the necessity of certain terminologies for semantic interoperability of these data. For a complete expansion of these projects, the named FHIR resources as well as a full use of LOINC and SNOMED CT in all IT procedures involved will be required.

As a result of the digital transformation, the IT landscape associated with medical documentation is also changing at Jena University Hospital. Existing IT procedures are enhanced with new interfaces, while new components like an electronic medication management system (cf. section 3.3) are introduced. Since Jena is a founding partner of the SMITH consortium of the German Medical Informatics Initiative [1], medical documentation needs to be digitally available for research and data analysis (cf. section 3.5).

The overall strategy of establishing an interoperable platform as the major source of medical information, to which all IT procedures, healthcare or research, are connected, has not yet been fully implemented at Jena University Hospital. However, as a first step towards this goal, several sub-projects have been initiated. HL7-FHIR-based interoperability, the goals, methods, and the status of these projects have been described in section 3. The challenges and experiences with allergy information as concrete medical information in the focus have been described in the respective sub-sections:

• the need for professional information modeling for certain use cases,
• semantic annotation and licensing of necessary ontologies like SNOMED CT,
• connection and transformation of data, up to processing of free-text entries and documents from existing sub-systems.

Reviewing the scientific literature, it has been found that in many cases, FHIR-based projects are described either without reference to integration of new approaches into existing IT architectures [8], [12], [28] or refer to extensions of and additions to the FHIR standard itself [29]. Since we have not found it described elsewhere, we describe here several general limitations and open issues regarding the integration of FHIR into IT procedures and into a platform strategy at a healthcare facility:

• Integration of an HL7 FHIR server as clinical data repository in an IHE XDS Affinity Domain
  IT platforms in the form of vendor-neutral archives usually offer IHE-XDS-related services suitable for medical document storage and exchange. While HL7 FHIR is a technical standard comparable to HL7 CDA and thus does not conflict with the services of an IHE Affinity Domain, there is currently no well-defined relation between medical content in IHE XDS repositories and clinical data repositories, apart from the option to query patient identification data via PIXm (Patient Identifier Cross-reference for mobile) and PDQm (Patient Demographics Query for Mobile) profiles. For example, how can single allergy information stored in an AllergyIntolerance FHIR resource be linked to structured allergy information contained in an HL7 CDA L3 discharge letter?
• Harmonization of identification, authentication and authorization processes for FHIR servers and other platform components
  While the HL7 FHIR standard does not dictate any specific access control, modern web protocols e.g. OAuth are recommended. IHE profiles such as HPD (Health Provider Directory) for identification, EUA (Enterprise User Authentication) for authentication, XUA (Cross-Enterprise User Assertion) for authorization transport, and BPPC/APPC (Basic/Advanced Patient Privacy Consent) for authorization based on access policies rely on web standards including Kerberos, XACML, and SAML tokens. Propagation of SAML tokens to OAuth authorization is possible, for example, so concepts of such a harmonization need to be made and should ideally be included in the publication as additional IHE profiles.
• Persistence of FHIR resources
  In FHIR it is not explicitly defined how to persist resources. Most implementations utilize a relational database management system. Since these require queries to be conducted on tables or views, partly with expensive “join” functions, they can become slow on larger databases and may require caching of large amounts of stored FHIR data during a query. Other database systems, e.g. graph-based versions, may prove to be a better match for a persistence layer of FHIR resources. Research on this topic is conducted in Jena [42].
• Archiving of FHIR resources
  In the context of a vendor-neutral communication and archiving platform, how can FHIR resources storing individual data be archived and fulfill auditing rules? It would be conceivable to introduce hashing procedures for the communication paths of FHIR resources. In Jena, we plan to address this topic together with industry partners involved in implementing our archiving and communication platform.
• Maintaining actuality of IT infrastructure using the FHIR standard
  As a novel, still rapidly developing standard, new versions of FHIR resources are expected at least every two years. While for resources like Patient or Observation with a current maturity level of N (normative), backwards compatibility is now guaranteed, other resources – like AllergyIntolerance. currently on maturity level 3 –, structural changes are likely to occur [43]. Timely implementation of any current release of FHIR (currently R4) and migration or mapping of existing communication channels and data will cause regular expenditure both for manufacturers and users, which in return will enable a long-term handling e.g. of data in lifelong patient records, constantly based on current technical developments. This might become an important factor for the sustainability of vendor-neutral archives containing FHIR components.

Most of the questions posed here are related to a deeper integration of a FHIR server or the FHIR standard into an existing landscape of IT procedures and standards. Finding answers to these questions requires conceptual work, research, as well as cooperation with industrial partners and standards developing organizations (SDOs). Medical informatics professionals at Jena University Hospital are actively involved in these facets of implementing the practical use of FHIR.

Digital transformation in healthcare includes a change in the storing and communication of medical data, since in most institutions and especially between different institutions, paper-based processes are still used. For a vendor-neutral persistence and transport of relevant parts of medical documentation, the content of these parts has to be “self-explanatory”, not only to a healthcare practitioner, but also to IT procedures in which these data are to be processed, otherwise the processing might be faulty. Modern methods of applied data science from machine learning algorithms to decision support often require large datasets for training and validation. Single site datasets with proprietary formats cannot fulfil this requirement. Moreover, it is not enough to just train an algorithm at one site (with a large dataset). Useful medical applications have to be generalizable to other sites (with a similar patient case mix). Thus, there is a necessity for healthcare facilities to store and communicate their data in interoperable formats, for institution-wide and cross-institutional information exchange and for analysis projects in clinical studies, evaluations of new algorithms etc. Syntax, semantics, and technical processes have to be transformed according to technical standards.

HL7 FHIR is an interoperability standard which due to its advantages – usage of widespread web and mobile technologies, RESTful architecture, accessible specification, etc. – is increasingly used for access to and exchange of structured healthcare data. However, achieving interoperability does not start with the use of a technical standard or representation for medical data. As shown by the projects described in this paper, methodical approach to achieving this goal should start with the description of a specific use case and the necessary data that are generated, received, processed, stored or communicated. For example: Which data elements are necessary to compare a documented allergy to a certain medication that could be prescribed?

Progressing from the establishment of a use case, associated data, the decision on the usage of a technical standard, and the “tailoring” of certain aspects of this standard to the use case are the next steps. This is called profiling and results in a use case-specific description of technical standard elements [5]. These interoperability standard profiles should be discussed in and published for a community which is working with the underlying standards – members of SDOs, healthcare IT industry representatives, clinical users, and further medical informatics specialists. Besides receiving feedback on one’s own profiling work, analogous use cases could be profiled together with other interested parties. More specific profiles can be derived from more general profiles that already exist. Basic forms of allergy documentation in HL7 FHIR, for example, are already profiled in the International Patient Summary Implementation Guide [44]. A good starting point for investigations on FHIR-based systems and projects in Germany is the Wiki of HL7 and IHE Germany [45], especially the list of FHIR-based products and projects in Germany [46].

From the projects carried out in Jena, experience has been gained that the general approach of profiling and further use of standards is applicable to concrete use cases in healthcare facilities and that standardized interfaces can be implemented in cooperation with industrial partners. In order to further develop the chosen platform architecture, the open questions mentioned in the previous section must be brought into focus and solutions must be developed by the community and in practical use by the healthcare institutions. In the future, scientific publications should increasingly deal with integration aspects, where new approaches and applications have to be embedded in existing IT landscapes and platforms and in corresponding healthcare processes.

The introduction of new IT procedures, new interfaces, and new ways of documentation of healthcare data causes processual changes in healthcare institutions as those involved in healthcare are confronted with new procedures for documenting and communicating treatment-relevant information. Specifically, the implementation of the projects concerning an interoperability platform and HL7-FHIR-based communication at Jena University Hospital also contains complex organizational work: harmonization of existing documentation, training and piloting of new IT procedures, repeated interactions between medical IT specialists and active healthcare professionals. For this reason, the digital transformation of healthcare institutions, based on the introduction of interoperability standards like HL7 FHIR, can clearly be described as a multi-professional undertaking. However, the center of any project remains the patient’s well-being, facilitated by the accuracy and availability of her or his detailed medical information.

• APPC = Advanced Patient Privacy Consent
• ASK = Arzneimittel-Stoffkatalog
• ATC = Anatomical Therapeutic Chemical Classification System
• BPPC = Basic Patient Privacy Consent
• CDA = Clinical Document Architecture
• CPOE = Computerized Physician Order Entry
• CWS = Clinical Workplace System
• EUA = Enterprise User Authentication
• FHIR = Fast Healthcare Interoperability Resources
• HIS = Hospital Information System
• HL7 = Health Level Seven
• HPD = Health Provider Directory
• IHE = Integrating the Healthcare Enterprise
• LOINC = Logical Observation Identifiers Names and Codes
• LIS = Laboratory Information System
• OAuth = Open Authorization
• MPI = Master Patient Index
• PACS = Picture Archiving and Communication System
• PDMS = Patient Data Management System
• PDQm = Patient Demographics Query for Mobile
• PIXm = Patient Identifier Cross-reference for mobile
• REST = Representational State Transfer
• SAML = Security Assertion Markup Language
• SDO = Standards Developing Organization
• SMITH = Smart Medical Information Technology for Healthcare
• SNOMED CT = Systematized Nomenclature of Medicine – Clinical Terms
• XDS = Cross Enterprise Document Exchange
• UNII = Unique Ingredient Identifier
• VNA = Vendor-Neutral Archive
• XACML = eXtensible Access Control Markup Language
• XDS = Cross-Enterprise Document Exchange
• XUA = Cross-Enterprise User Assertion

Part of this work has been supported by the German Federal Ministry of Education and Research, Grant-No. 01ZZ1609.

The authors declare that they have no competing interests.