gms | German Medical Science

GMS Medizinische Informatik, Biometrie und Epidemiologie

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (GMDS)

ISSN 1860-9171

Integration of allergy documentation into an interoperable archiving and communication platform to improve patient care and clinical research at the Jena University Hospital

Integration der Allergie-Dokumentation in eine interoperable Archivierungs- und Kommunikationsplattform zur Verbesserung der Patientenversorgung und der klinischen Forschung am Universitätsklinikum Jena

Case Report

  • Henner M. Kruse - Data Integration Center and IT Department, Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative
  • Alexander Helhorn - Data Integration Center and IT Department, Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative
  • Lo An Phan-Vogtmann - Data Integration Center and Institute of Medical Statistics, Computer and Data Sciences (IMSID), Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative
  • Julia Palm - Institute of Medical Statistics, Computer and Data Sciences (IMSID), Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative
  • Eric Thomas - Data Integration Center and IT Department, Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative
  • Andreas Iffland - Hospital Pharmacy, Jena University Hospital, Jena, Germany
  • Andrew Heidel - Data Integration Center and IT Department, Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative
  • Susanne Müller - Data Integration Center and Institute of Medical Statistics, Computer and Data Sciences (IMSID), Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative
  • Kutaiba Saleh - Data Integration Center and IT Department, Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative
  • Karsten Krohn - IT Department, Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative
  • Martin Specht - IT Department, Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative
  • Michael Hartmann - Hospital Pharmacy, Jena University Hospital, Jena, Germany
  • Katrin Farker - Hospital Pharmacy, Jena University Hospital, Jena, Germany
  • Cord Spreckelsen - Institute of Medical Statistics, Computer and Data Sciences (IMSID), Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative
  • Andreas Henkel - IT Department, University Hospital rechts der Isar, Munich, Germany
  • André Scherag - Institute of Medical Statistics, Computer and Data Sciences (IMSID), Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative
  • corresponding author Danny Ammon - Data Integration Center and IT Department, Jena University Hospital, Jena, Germany; SMITH consortium of the German Medical Informatics Initiative

GMS Med Inform Biom Epidemiol 2021;17(2):Doc06

doi: 10.3205/mibe000220, urn:nbn:de:0183-mibe0002201

Published: April 26, 2021

© 2021 Kruse et al.
This is an Open Access article distributed under the terms of the Creative Commons Attribution 4.0 License. See license information at http://creativecommons.org/licenses/by/4.0/.


Abstract

As part of the digitalization strategy for medical documentation, we introduced a vendor-neutral archive (VNA) at the Jena University Hospital. The VNA provides data based on interoperable formats for all clinical systems and for communication with other actors as well as for secondary data use. HL7 FHIR is used as a standard for structuring individual data. Using the example of allergy documentation, the paper describes objectives, work status, and experiences from several sub-projects currently being pursued in Jena to establish FHIR. Challenges in information modelling, semantic annotation, connection of clinical sub-systems and integration of FHIR resources in archiving structures and processes are discussed and the necessary cooperation for profiling technical standards is indicated.

Keywords: HL7, FHIR, vendor-neutral archive, interoperability, allergy, anamnesis, electronic medication management

Zusammenfassung

Im Rahmen der Digitalisierungsstrategie für die medizinische Dokumentation haben wir am Universitätsklinikum Jena ein „Vendor-Neutral Archive“ (VNA) eingeführt. Das VNA stellt Daten auf der Basis interoperabler Formate für alle klinischen Systeme und zur Kommunikation mit anderen Akteuren sowie für die Sekundärdatennutzung zur Verfügung. Für strukturierte Einzeldaten kommt hierbei der Standard HL7 FHIR zum Einsatz. Der Artikel beschreibt am Beispiel der Allergiedokumentation Zielsetzungen und Erfahrungen aus mehreren Teilprojekten, die derzeit in Jena zur Etablierung von FHIR verfolgt werden. Herausforderungen bei der Informationsmodellierung, semantischer Annotation, Anbindung klinischer Subsysteme und Einbindung von FHIR-Ressourcen in Archivierungsstrukturen und -prozesse werden diskutiert und notwendige Kooperationen bei der Profilierung technischer Standards aufgezeigt.

Schlüsselwörter: HL7, FHIR, Vendor-Neutral Archive, Interoperabilität, Allergie, Anamnese, elektronisches Medikationsmanagement


1 Introduction and motivation

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.


2 Methods

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.


3 Description of projects and first results

3.1 Managing and documenting allergies during medical treatment

3.1.1 Project description

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.

3.1.2 Platform integration

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.

3.1.3 Current status and prospects

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.

3.2 Documentation of anamnestic data

3.2.1 Project description

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.

3.2.2 Platform integration

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.

3.2.3 Current status and prospects

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

3.3 Electronic medication management

3.3.1 Project description

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.

3.3.2 Platform integration

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.

3.3.3 Current status and prospects

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.

3.4 Hospital food menu ordering and supply

3.4.1 Project description

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.

3.4.2 Platform integration

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.

3.4.3 Current status and prospects

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.

3.5 Analysis projects using patient care data

3.5.1 Project description

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

3.5.2 Platform integration

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.

3.5.3 Current status and prospects

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

3.6 Summary overview

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.


4 Discussion

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.


5 Conclusion

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.


Abbreviations

  • 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

Notes

Funding

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

Competing interests

The authors declare that they have no competing interests.


References

1.
Winter A, Stäubert S, Ammon D, Aiche S, Beyan O, Bischoff V, Daumke P, Decker S, Funkat G, Gewehr JE, de Greiff A, Haferkamp S, Hahn U, Henkel A, Kirsten T, Klöss T, Lippert J, Löbe M, Lowitsch V, Maassen O, Maschmann J, Meister S, Mikolajczyk R, Nüchter M, Pletz MW, Rahm E, Riedel M, Saleh K, Schuppert A, Smers S, Stollenwerk A, Uhlig S, Wendt T, Zenker S, Fleig W, Marx G, Scherag A, Löffler M. Smart Medical Information Technology for Healthcare (SMITH). Methods Inf Med. 2018 Jul;57(S 01):e92-e105. DOI: 10.3414/ME18-02-0004 External link
2.
Gehring S, Eulenfeld R. German Medical Informatics Initiative: Unlocking Data for Research and Health Care. Methods Inf Med. 2018 Jul;57(S 01):e46-e49. DOI: 10.3414/ME18-13-0001 External link
3.
Lehne M, Sass J, Essenwanger A, Schepers J, Thun S. Why digital medicine depends on interoperability. NPJ Digit Med. 2019;2:79. DOI: 10.1038/s41746-019-0158-1  External link
4.
IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. IEEE Std 610. 1991. DOI: 10.1109/IEEESTD.1991.106963 External link
5.
Oemig F, Blobel B. Compliance or Conformance: What Should Interoperability Focus on? Stud Health Technol Inform. 2017;237:63-7. DOI: 10.3233/978-1-61499-761-0-63 External link
6.
Forslund DW, Kratz M, George JE, Koenig S, Carter R, Staab T. The Importance of Distributed, Component-based Healthcare Information Systems: the Role of a Service-based Architecture. In: Proceedings 14th IEEE Symposium on Computer-Based Medical Systems; 2001; Bethesda, MD, USA. p. 79-82. DOI: 10.1109/CBMS.2001.941701 External link
7.
Bender D, Sartipi K. HL7 FHIR: An Agile and RESTful Approach to Healthcare Information Exchange. In: Proceedings of the 26th IEEE International Symposium on Computer-Based Medical Systems; 2013 Jun 20-22; Porto. p. 326-31. DOI: 10.1109/CBMS.2013.6627810 External link
8.
Lehne M, Luijten S, Vom Felde Genannt Imbusch P, Thun S. The Use of FHIR in Digital Health - A Review of the Scientific Literature. Stud Health Technol Inform. 2019 Sep 3;267:52-8. DOI: 10.3233/SHTI190805 External link
9.
Hermann-Kunz E. Allergische Krankheiten in Deutschland. Bundesgesundheitsblatt Gesundheitsforschung Gesundheitsschutz. 2000 Jun 7;43(6):400-6. DOI: 10.1007/s001030070045 External link
10.
Sánchez-Borges M, Martin BL, Muraro AM, Wood RA, Agache IO, Ansotegui IJ, Casale TB, Fleisher TA, Hellings PW, Papadopoulos NG, Peden DB, Sublett JL, Tilles SA, Rosenwasser L. The importance of allergic disease in public health: an iCAALL statement. World Allergy Organ J. 2018;11(1):8. DOI: 10.1186/s40413-018-0187-2 External link
11.
Schmitz R, Kuhnert R, Thamm M. 12-Monats-Prävalenz von Allergien in Deutschland. Journal of Health Monitoring. 2017;2(1). DOI: 10.17886/RKI-GBE-2017-011.2 External link
12.
Topaz M, Seger DL, Goss F, Lai K, Slight SP, Lau JJ, Nandigam H, Zhou L. Standard Information Models for Representing Adverse Sensitivity Information in Clinical Documents. Methods Inf Med. 2016;55(2):151-7. DOI: 10.3414/ME15-01-0081  External link
13.
Arbeitskreis Krankenhaus- & Praxishygiene der AWMF. S1-Leitlinie 029-021: Anforderungen an Handschuhe zur Infektionsprophylaxe im Gesundheitswesen. AWMF; 2017. Available from: https://www.awmf.org/leitlinien/detail/ll/029-021.html External link
14.
Reddy S. Latex allergy. Am Fam Physician. 1998 Jan;57(1):93-102.
15.
Sussman GL, Beezhold DH. Allergy to latex rubber. Ann Intern Med. 1995 Jan;122(1):43-6. DOI: 10.7326/0003-4819-122-1-199501010-00007  External link
16.
Lieberman P. Anaphylactic reactions during surgical and medical procedures. J Allergy Clin Immunol. 2002 Aug;110(2 Suppl):S64-9. DOI: 10.1067/mai.2002.124970 External link
17.
Gibilisco PA. Clinical and Financial Risks and Implications of Latex Allergy in Critical Care Settings. ICU Medical Inc.; 2015. Available from: https://www.icumed.com/media/10044/m1-1252-clinical-perils-of-latex-rev04-web.pdf External link
18.
Saleh K, Stucke S, Uciteli A, Faulbrück-Röhr S, Neumann J, Tahar K, Ammon D, Schmidt T, Neumuth T, Besting A, Portheine F, Herre H, Kaeding A, Specht M. Using Fast Healthcare Interoperability Resources (FHIR) for the Integration of Risk Minimization Systems in Hospitals. Stud Health Technol Inform. 2017;245:1378. DOI: 10.3233/978-1-61499-830-3-1378 External link
19.
Opstrup MS, Garvey LH. Chlorhexidine Allergy: Mild Allergic Reactions Can Precede Anaphylaxis in the Healthcare Setting. Turk J Anaesthesiol Reanim. 2019 Aug;47(4):342-4. DOI: 10.5152/TJAR.2019.22058 External link
20.
Phan-Vogtmann LA, Helhorn A, Kruse HM, Thomas E, Heidel AJ, Saleh K, Rissner F, Specht M, Henkel A, Scherag A, Ammon D. Approaching Clinical Data Transformation from Disparate Healthcare IT Systems Through a Modular Framework. Stud Health Technol Inform. 2019;258:85-9. DOI: 10.3233/978-1-61499-959-1-85 External link
21.
Neurath MF, Lohse AW, editors. Checkliste Anamnese und klinische Untersuchung. 4th ed. Stuttgart: Thieme; 2015. DOI: 10.1055/b-003-106499 External link
22.
Hayna S, Schmücker P. Elektronische Anamnese - Konzept und prototypische Realisierung. In: Schreier G, Hayn D, Ammenwerth E, editors. Tagungsband der eHealth2011. Wien: OCG; 2011. p. 59-64.
23.
Scott PJ, Heitmann KU. Team Competencies and Educational Threshold Concepts for Clinical Information Modelling. Stud Health Technol Inform. 2018;255:252-6. DOI: 10.3233/978-1-61499-921-8-252 External link
24.
Hwang Y, Yoon D, Ahn EK, Hwang H, Park RW. Provider risk factors for medication administration error alerts: analyses of a large-scale closed-loop medication administration system using RFID and barcode. Pharmacoepidemiol Drug Saf. 2016 Dec;25(12):1387-96. DOI: 10.1002/pds.4068 External link
25.
Moskow JM, Cook N, Champion-Lippmann C, Amofah SA, Garcia AS. Identifying opportunities in EHR to improve the quality of antibiotic allergy data. J Am Med Inform Assoc. 2016 Apr;23(e1):e108-12. DOI: 10.1093/jamia/ocv139 External link
26.
Gøeg KR, Hummeluhr M. An Empirical Approach to Enhancing Terminology Binding – An HL7 FHIR SNOMED CT Example. Stud Health Technol Inform. 2018;247:206-10. DOI: 10.3233/978-1-61499-852-5-206 External link
27.
Hong N, Wen A, Shen F, Sohn S, Liu S, Liu H, Jiang G. Integrating Structured and Unstructured EHR Data Using an FHIR-based Type System: A Case Study with Medication Data. AMIA Jt Summits Transl Sci Proc. 2018;2017:74-83.
28.
Sinha S, Jensen M, Mullin S, Elkin PL. Safe Opioid Prescription: A SMART on FHIR Approach to Clinical Decision Support. Online J Public Health Inform. 2017;9(2):e193. DOI: 10.5210/ojphi.v9i2.8034  External link
29.
Martinez-Costa C, Schulz S. HL7 FHIR: Ontological Reinterpretation of Medication Resources. Stud Health Technol Inform. 2017;235:451-5.
30.
Neisecke T, Freitag MH, Ammon D, Breitbart J, Freytag A, Bär KJ, Scupin O, Schlattmann P, Specht M, Wensing M, Gensichen J. Einfluss intersektoraler elektronischer Medikationslisten auf die Arzneimitteltherapiesicherheit. ZFA - Zeitschrift Für Allgemeinmedizin. 2016;92(12):508-13. DOI: 10.3238/zfa.2016.0508-0513 External link
31.
Ammon D, Saleh K, Schulze D, Specht M, Henkel A. Rechnergestütztes Medikationsmanagement im deutschen Gesundheitswesen – Anforderungen, Spezifikationen und Aufgaben. In: HEC 2016: Health – Exploring Complexity. Joint Conference of GMDS, DGEpi, IEA-EEF, EFMI. München, 28.08.-02.09.2016. Düsseldorf: German Medical Science GMS Publishing House; 2016. DocAbstr. 659. DOI: 10.3205/16gmds145 External link
32.
Auer D, Bick M, Kabisch B, Kummer TF. RFID-gestützte Medikation im Krankenhaus: Ein Erfahrungsbericht. In: Bick M, Eulgem S, Fleisch E, Hampe JF, König-Ries B, Lehner F, Pousttchi K, Rannenberg K, editors. Mobile und Ubiquitäre Informationssysteme. Technologien, Anwendungen und Dienste zur Unterstützung von mobiler Kollaboration Proceedings zur 5. Konferenz Mobile und Ubiquitäre Informationssysteme (MMS 2010) Göttingen, 23.–25. Februar 2010. Bonn: Gesellschaft für Informatik e.V.; 2010. (Lecture Notes in Informatics). p. 84-96.
33.
Pronova BKK. Männer-/Frauengesundheit 2018. 2018. Available from: https://www.pronovabkk.de/media/downloads/presse_studien/studie_maenner_frauengesundheit_2018/Studienband-Maenner-Frauengesundheit-2018.pdf External link
34.
IMAS International. Die Abwehrreaktion des Körpers – Allergien in Österreich. IMAS Report 11/2019. 2019. Available from: http://imas.at/images/imas-report/2019/11_Allergien.pdf External link
35.
Techniker Krankenkasse. Iss was, Deutschland. TK-Studie zur Ernährung 2017. 2017. Available from: https://www.tk.de/resource/blob/2026618/1ce2ed0f051b152327ae3f132c1bcb3a/tk-ernaehrungsstudie-2017-data.pdf External link
36.
Oemig F, Blobel B. Natural Language Processing Supporting Interoperability in Healthcare. In: Biemann C, Mehler A, editors. Text Mining: From Ontology Learning to Automated Text Processing Applications. Heidelberg/New York: Springer; 2014. p. 137-56. DOI: 10.1007/978-3-319-12655-5_7 External link
37.
Lohr C, Luther S, Matthies F, Modersohn L, Ammon D, Saleh K, Henkel AG, Kiehntopf M, Hahn U. CDA-Compliant Section Annotation of German-Language Discharge Summaries: Guideline Development, Annotation Campaign, Section Classification. AMIA Annu Symp Proc. 2018;2018:770-9.
38.
European Parliament; Council of the European Union. EU Regulation on the Provision of Food Information to Consumers. Regulation No 1169/2011. 2011 Oct 25. Annex II: Substances or Products Causing Allergies or Intolerances; p. L304/43. Available from: https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32011R1169 External link
39.
Castells M, Khan DA, Phillips EJ. Penicillin Allergy. N Engl J Med. 2019 Dec;381(24):2338-51. DOI: 10.1056/NEJMra1807761 External link
40.
Sacco KA, Bates A, Brigham TJ, Imam JS, Burton MC. Clinical outcomes following inpatient penicillin allergy testing: A systematic review and meta-analysis. Allergy. 2017 Sep;72(9):1288-96. DOI: 10.1111/all.13168 External link
41.
Hagel S, Gantner J, Spreckelsen C, Fischer C, Ammon D, Saleh K, Phan-Vogtmann LA, Heidel A, Müller S, Helhorn A, Kruse H, Thomas E, Rißner F, Haferkamp S, Vorwerk J, Deffge S, Juzek-Küpper MF, Lippmann N, Lübbert C, Trawinski H, Wendt S, Wendt T, Dürschmid A, Konik M, Moritz S, Tiller D, Röhrig R, Schulte-Coerne J, Fortmann J, Jonas S, Witzke O, Rath PM, Pletz MW, Scherag A. Hospital-wide Electronic Medical Record-based Computerized Decision Support System to Improve Outcomes of Patients With Staphylococcal Bloodstream Infection (HELP). Study Protocol for a Multicenter Stepped-wedge Cluster Randomized Trial. BMJ Open. 2020 Feb;10(2). DOI: 10.1136/bmjopen-2019-033391 External link
42.
Kruse HM, Helhorn A, Phan-Vogtmann LA, Thomas E, Heidel AJ, Saleh K, Scherag A, Ammon Dl. Modeling a Graph Data Model for FHIR Resources. In: 64. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (GMDS). Dortmund, 08.-11.09.2019. Düsseldorf: German Medical Science GMS Publishing House; 2019. DocAbstr. 262. DOI: 10.3205/19gmds160 External link
43.
HL7 International. HL7 FHIR Specification Release 4. Available from: https://www.hl7.org/fhir/index.html External link
44.
HL7 International. International Patient Summary Implementation Guide. Available from: https://build.fhir.org/ig/HL7/fhir-ips/index.html External link
45.
HL7 Germany; IHE Germany. Wiki-Portal des Interoperabilitätsforums. Available from: https://wiki.hl7.de/index.php?title=Hauptseite External link
46.
HL7 Germany; IHE Germany. FHIR-Marktübersicht. Available from: https://wiki.hl7.de/index.php?title=FHIR-Marktübersicht External link