Person module

Medical documentation typically distinguishes between the person, the patient and the case. The person-related basic module of the core data set is intended to allow reference to be made to other modules. This module can contain site-specific identifiers from local identity management systems or existing unique keys from other modules of the core data set. Where required, the module may include personal attributes for cross-institutional or cross-sector integration. The goal is not just to monitor basic data for a single hospitalisation for a specific person, but to make it possible to track the course of treatment across multiple hospitalisations. The current specification explicitly models the person module for patients and clinical study participants.

Click here for the most recent release

Case module

The content of the case module is the documentation of contacts (stays and visits) of patients in healthcare facilities, with the main questions "who", "when" and "with whom". The medical informatics initiative aims to provide information on patient visits throughout the treatment process. This information includes details on whether inpatient or outpatient contacts were involved, when admission and discharge took place and in which specialist department the treatment was carried out. The clinical data from other core data set modules is placed in the context of the treatment case by linking it to this module.

Click here for the most recent release

Consent module

The foundation for providing patient data within the MII for secondary data usage is the MII Broad Consent—a standardized declaration allowing for the subsequent scientific utilization of patient data gathered during medical care. Developed by the MII's Consent Working Group and endorsed by the relevant data protection officers, the Broad Consent ensures a standardized approach to data usage permissions.
The current technical execution of the MII Broad Consent has been tailored and fine-tuned to meet the specific requirements of the MII. This adaptation and profiling were conducted by the Consent Implementation Task Force, leveraging the generic HL7 specification as a basis for implementation.

Click here for the most recent release

Diagnosis module

A diagnosis is the reason for treatment in a given health care system. With in-patient care, the primary and any secondary diagnoses are entered into hospital information systems (HIS) for a variety of purposes. With out-patient care, the attending physician generally only records a diagnosis for each case on a quarterly basis within the scope of invoicing/cost settlement. In many research projects, the diagnosis is the most important (generally) independent variable.

Click here for the most recent release

Procedure module

A further central element of medical documentation is the standardised description of any treatment. The procedure module contains data elements related to the documentation of operations, interventions, other medical procedures and selected therapies with medication. A procedure is any activity within the scope of health care performed with or for a patient. This includes diagnostics and treatment/therapy. The procedure module records the details of current and historical interventions.

Click here for the most recent release

Laboratory test results module

Laboratory tests are performed for almost all hospital in-patients. The test results are usually stored centrally. The following items of information for each patient and case should be transferred to the corresponding data integration centre (DIC) each time a laboratory test is conducted:

  • The test/analysis designation, with unique test identifier (using the LOINC standard coding system)
  • The date the test was conducted
  • The result (measured value) with standardised unit of measurement
  • Interpretation: indication whether result represents a pathological value (recommended)
  • Type of scale (optional)
  • Reference range (recommended)
  • Source laboratory (optional)

It is also possible to model other clinical tests, microbiological tests and vital signs that go beyond the scope of conventional clinical/chemical and haematological laboratory data.

Click here for the most recent release

Medication module

The medication module contains data elements that document the prescription and administration of medication. The prescription of medication is a core aspect of routine health care and takes place at all MII hospitals. However, the proportion of prescriptions documented in digital form varies greatly from site to site with regard to the degree to which it is structured, and the populations and medications included. Data on medication is central to a wide range of questions, e.g. on pharmacovigilance (drug safety), and as inclusion/exclusion criteria for specific studies.

It is possible to distinguish between the following types of administered medication to be documented:

  • Medication in hospital (primarily/partially in-patient care)
  • Medication upon discharge from hospital
  • Medication for out-patients
  • Self-medication (OTC)
  • Medication administered within the scope of clinical studies

Data can range from the basic documentation of the administration of a particular pharmaceutical product in a case of treatment, to the detailed, structured capture of individual doses with encoding of the active ingredient, dosage form, route of administration, and dosage in line with international standards.

At a minimum, accessible data should include the active ingredient. As a next step, it is proposed to make the following data elements available:

  • Commercial names of administered pharmaceuticals
  • The dose with unit of measurement
  • Dosage form
  • Location and route of administration

Where the data are available, a third step could extend the scope of documentation to include the following elements:

  • Dosage regimen
  • Composition of infusions / flow rate of infusion pumps
  • Indication (i.e. reference to the related diagnosis)

Click here for the most recent release


Do you have any questions or suggestions regarding the further development of the core data set or individual core data set modules? Would you like to get involved in the work on the core data set?

Please contact us by email at (keyword: core data set).