The overall aim of DEMIS is to enhance reporting efficiency and support the standardized, secure, and reliable transmission of health data through partially automated data processing.

The primary objective of DEMIS implementation was to establish the technical infrastructure required for electronic transmission of laboratory and disease notifications. This included the development and provision of HL7 FHIR profiles for diagnostic and clinical information related to infectious diseases, implementation of FHIR-based interfaces to ensure stable data processing, and access for notifiers. The secondary objective was to ensure the interoperable exchange and processing of electronic notifications across the different software systems used by notifiers and recipients.

Key performance indicators for the implementation included (1) system performance, measured by DEMIS availability and notification processing capacity; (2) system adoption, measured by the number of laboratories and hospitals connected to DEMIS; (3) system utilization, measured by the number of notifications transmitted through DEMIS; and (4) data quality of pathogen notifications, measured by the proportion of notifications that conform to specified terminology standards.

DEMIS was initiated in 2012 as a collaboration between the RKI and Fraunhofer FOKUS (Fraunhofer-Gesellschaft; specialized in open communication systems) [5,6]. Following a conceptual phase (2012‐2014), implementation was funded by the Federal Ministry of Health (FMH) from 2016 to 2020. During the COVID-19 pandemic, implementation accelerated through collaboration with gematik (National Digital Health Agency), which developed the infrastructure architecture with FHIR interfaces. A managed service provider is used for hosting and an external service provider for first-level support. RKI is the responsible party for DEMIS. The further development of DEMIS is partly mandated by law, and its road map is aligned and coordinated between the RKI, gematik, and the FMH.

DEMIS is funded by the FMH and the European Commission through annual budget allocations to the RKI, with operation and further development split into:

The majority of DEMIS funding is invested into the development and hosting of the technical infrastructure.

To ensure interoperability of DEMIS with other health care applications in Germany, we use the FHIR standard [7] and international standardized terminologies such as LOINC (Logical Observation Identifiers Names and Codes) [8] and SNOMED CT (Systematized Nomenclature of Medicine - Clinical Terms) [9]. The overall implementation process is described in the following steps:

The entire implementation should be accompanied by security and data protection besides stakeholder communication. A depiction of the implementation process along with detailed information is shown in Figure 2.

DEMIS uses dedicated FHIR profile packages for different surveillance purposes. Pathogen notifications are represented by rki.demis.laboratory package [10] and disease notifications by rki.demis.disease [11]. Profiles of basic notifiable information (eg, patients and notifier facility) and general FHIR document information were outsourced to rki.demis.common [12], on which all DEMIS-FHIR packages (including rki.demis.statistic [hospital capacity surveillance] [13] and rki.demis.igs [upload of sequence data towards integrative genomic surveillance] [14]) have dependencies. Due to data protection requirements, DEMIS-FHIR resources are strictly specified, using cardinalities and constraints, compared with the basic HL7 standard and contrary to the established good practice guidelines [15].

The DEMIS-FHIR profiles are based on FHIR Release 4 and exchange structured data (“resources”) as FHIR document bundles in XML or JSON format. The outer framework is a Bundle, which contains a Composition that defines the structure and narrative content [16,17]. The resources PractitionerRole, Practitioner, or Organization are used to transmit information on the notifier or sample submitter, and Patient for details on the notified person. These general resources are then extended by notifiable category-specific resources. The structure of rki.demis.laboratory is shown as an example in Figure 3. It corresponds to a standardized written description and interpretation of the laboratory medical test. The resources thus represent the individual laboratory test results within Observation, the sample material in Specimen, and the summary of different test results within DiagnosticReport (Figure 3). Technical information should be communicated using the appropriate LOINC and SNOMED CT terminologies.

The structure of the FHIR profile for notifiable diseases (rki.demis.disease) is equivalent to the pathogen notifications. It uses resources from the basic profile (rki.demis.common) in addition to the FHIR resources Questionnaires including QuestionnaireResponse, Immunization, and Condition. Here, standardized information is provided for clinical symptoms, disease forms, and vaccination for preventable diseases, in the form of questions and answers.

Different status information within various FHIR resources (eg, Composition, QuestionnaireResponse, or DiagnosticReport) is managed using unique identifiers to support the life cycle of a notification. This life cycle management allows different types of notifications (initial or follow-up) and facilitates sending related notification bundles over time and place, with notifications not centrally stored and updated.

Both profiles use ValueSets, which are lists of pre- or postcoordinated codes primarily drawn from the terminologies LOINC and SNOMED CT. These ValueSets enable standardized transmission of information, such as symptoms, infection risk, pathogens, specimens, test methods, and test results. In DEMIS, ValueSets are pathogen- and disease-specific. Detailed information on technical specifications is published as an individual implementation guide [10,11,13,14]. To support automated processing by public health authorities, the RKI provides mapping (made available to other software developers) of the ValueSet codes, especially for pathogen notifications, to the proprietary coding system used in SurvNet. The proprietary coding system is precoordinated; each code generally contains information about the specimens and testing methods and implicitly indicates pathogen detection. Therefore, the mapping from the notification to the software must consider and anticipate several possible combinations of codes (eg, LOINC+ code for result+ SNOMED material or SNOMED organism) at different positions in the notification.

DEMIS is implemented as a microservices architecture based on Kubernetes, enabling independent development of new features or surveillance systems and zero-downtime deployments. Kubernetes is provided by a German hosting provider as a managed private cloud platform. Since DEMIS notifications contain highly sensitive personal health data, data protection is ensured through continuous offline and online vulnerability scans, strong encryption, a secure development life cycle, enforcement of cluster policies, and supply chain security measures.

Target groups for DEMIS are notifiers or notifying facilities for mandatory notification systems, the recipients’ LPHA, and RKI (see Introduction). As DEMIS remains under development and integration of other surveillance systems is planned, a broader range of notifiers (eg, schools and child care facilities) is expected.

The DEMIS FHIR profiles have been balloted according to HL7 rules and have been adapted in line with comments; entry into the interoperability directory in Germany is planned, according to the national digitalization strategy for public health. Measures to enhance interoperability with other digitalization initiatives include adjustments during the rollout of laboratory reports for electronic health records (German: elektronische Patientenakte; Laborbefund 1.0.0) [18,19] and the European Health Report [20]. Especially, a harmonized semantic for microbiology reports is necessary. To this end, we participate in a German collaboration between RKI, mio42, HL7 Germany, and the Medical Informatics Initiative. Furthermore, within the X-eHealth exchanging electronic health records joint action, a European-wide laboratory working group was started for the semantics of microbiological findings [21].

DEMIS is accessed via FHIR interfaces. Personal data from notifiers is processed in alignment with European data protection regulations [22] and communicated via a privacy policy. Data sending primary systems, such as laboratory information systems or practice management systems, can access DEMIS directly via the DEMIS API. Additionally, individual users can use the DEMIS notification portal free of charge, either through the internet or the telematics infrastructure, a secure network for German health providers. Each LPHA is authorized to retrieve notifications through local software that uses the DEMIS API. All abovementioned access possibilities are explained in Figure 4.

FHIR profiles were published in advance on simplifier.net and could be accessed directly by developers [23]. The go-live date was set by law. By this date, all LPHA systems were technically capable of receiving reports. Notifiers then gradually connected to DEMIS, accompanied by specific communication (see below). Sanctions for a delayed connection could be imposed by the responsible LPHAs.

Communication is particularly crucial in the areas of onboarding of DEMIS users including both notifiers and recipients, further developments in DEMIS (DEMIS road map), and feedback on compliance and usability. Thus, we have established the DEMIS Executive Secretariat, which serves as a central point for coordinating and overseeing communications. Multiple communication channels were set up: (1) user exchange platforms, including monthly Q&A sessions for each user group (LPHAs, laboratories, and hospitals, respectively) plus a central mailbox and help desk ticketing system with first- and second-level support; (2) DEMIS expert groups for laboratories and LPHAs, created at the outset to gather information on real-time notification processes; (3) regular stakeholder meetings; and (4) monthly laboratory quality reports. Information on the DEMIS system and frequently asked questions are published on a public DEMIS knowledge base [24]. Software providers are supported by a DEMIS test stage to facilitate integration of their software.

Ethical approval was not necessary for this study as it was performed to fulfill legal duties based on the Infectious Diseases Prevention Act (Infektionsschutzgesetz). Within this manuscript only anonymized aggregated data are shown.

DEMIS could be established through strong collaborations between stakeholders. Its accessibility spans nationwide mandated notifiers. Standardized FHIR interfaces and terminologies have ensured interoperable data exchange for DEMIS users and other digitalization initiatives. The experience in implementing and harmonizing FHIR-based surveillance systems has underscored the critical importance of strengthening IT infrastructure in Germany’s mandatory notification surveillance system.

We successfully onboarded users through either the API or the notification portal. However, some notifications are still sent on paper to the LPHAs. Regarding pathogen notifications, anecdotal evidence suggests that initial pathogen detection results are sent electronically. However, results from specialist laboratories, such as species identification and genome sequence results, are still submitted on paper. These findings highlight the challenges that small laboratories face when integrating with DEMIS due to their limited IT infrastructure and inadequate support for the DEMIS API, and a complicated authorization process within the notification portal. Currently, the latter requires personal or organizational identifiers, as usernames/passwords for authentication have been disabled due to concerns about misuse. Future development of DEMIS must therefore consider how access can be made easier for smaller laboratories.

We successfully implemented LOINC and SNOMED CT terminologies in DEMIS. Through the monthly report on pathogen notifications, we were able to improve data quality, although not to the required extent. Depending on the laboratory and pathogen reported, the use of LOINC as observation.code ranged between 92% and 97% across all laboratory notifications. Despite the high adoption, all notifications need to contain a LOINC code from the pathogen-specific ValueSets to allow fully automatic import into the LPHA software. In our recent publication, we studied the proportion of cases transmitted via DEMIS and the extent of possible multiple entries of cases in the first year of DEMIS implementation, in which, depending on the pathogen, between 28% to 43% of cases were notified via DEMIS [29]. These results underscored the importance of profile updates. Consequently, stricter FHIR profiles for notifiable pathogens that require the mandatory use of DEMIS ValueSet codes were developed. For notifiable diseases, we could not conduct a similar assessment of data quality. The profile includes required binding for SNOMED CT codes; thus, data quality will be differently assessed (eg, with suggested evaluation methods on completeness and acceptance) [30].

In summary, DEMIS has successfully enabled electronic reporting for mandatory notifications and ensures interoperability with other surveillance systems. The successful implementation of a national electronic surveillance system such as DEMIS relies on comprehensive support from practice management system providers, laboratory information system providers, and software developers for interface implementation; adequate interdisciplinary staffing to support development and operation, ensuring compliant use; and funding to build enduring relationships with stakeholders and service providers.

Routine data quality assessments will enhance data completeness, accuracy, and life cycle management for automatic processing by health authorities. Evaluating the introduction of an electronic surveillance system for infectious diseases and pathogen detection remains important, with metrics on data quality and quantity over time (eg, completeness and acceptance). Future discussions should also aim to improve semantic and conceptual clarity of terminology to improve interoperability of health data across national and international FHIR-based systems.