# Module CASE
## Core Dataset Module Case ##
| Note | Under construction!|
|---|---|
||This Implementation Guide represents the current working version of the module 'CASE'. The respective version published for productive use can be found on [this page of the Medical Informatics Initiative](https://www.medizininformatik-initiative.de/Kerndatensatz/Modul_Fall/IGMIIKDSModulFall.html).|
The present specification describes the FHIR representation of the core data set module 'CASE' of the Medical Informatics Initiative.
The use cases of the module, as well as the associated FHIR profiles and terminology resources, are described below in their binding form.
|Publication|-|
|---|---|
|Date|15.03.2021|
|Version|1.0.0|
|Status| Active|
|Realm| DE|
### Table of Contents
* IG MII CDS module Case
* Description of the module
- Simple assembly model
- Complex expansion model
* Context in overall project/ References to other modules
* References
* Use cases/ information model
- Descriptions of scenarios for the application of the modules
- Data sets incl. descriptions
- UML
* Technical implementation
- FHIR profiles
- Terminologies
### Impressum
This guideline was created within the framework of the Medical Informatics Initiative (MII) and is subject to the voting process of the Interoperability Forum and the technical committees of HL7 Germany registered association per governance process.
### Contact
* Josef Schepers, Berlin Institute of Health (BIH)
* Andrea Essenwanger, Berlin Institute of Health (BIH)
* Karoline Buckow, TMF – Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V.
Questions about this publication can be asked at any time at [chat.fhir.org](https://chat.fhir.org/login/) in the stream 'german / mi-initiative'.
Comments and criticism are always welcome in the form of ‘Issues’ in the Simplifier project.
**Authors (alphabetical order)**
* Alexander Zautke (HL7 Deutschland)
* Andrea Essenwanger (HiGHmed)
* Antje Wulff (HiGHmed)
* Caroline Thoms-Böhnisch (HiGHmed)
* Christian Kamann (MIRACUM)
* Dagmar Büschges (SMITH)
* Danny Ammon (SMITH)
* Detlef Kraska (MIRACUM)
* Eugenia Rinaldi (HiGHmed)
* Fabian Prasser (DIFUTURE)
* Florian Rißner (SMITH)
* Hauke Hund (HiGHmed)
* Heinrich Lautenbacher (DIFUTURE)
* Holger Stenzhorn (DIFUTURE)
* Josef Schepers (HiGHmed)
* Julia Schaefer (Universität Berlin)
* Julian Saß (HiGHmed)
* Kai Heitmann (HL7 Deutschland)
* Kutaiba Saleh (SMITH)
* Laurence Strasser (Medizinische Universität Wien)
* Martin Boeker (MIRACUM)
* Matthias Löbe (SMITH)
* Miriam Hübner (Universität zu Lübeck)
* Moritz Lehne (HiGHmed)
* Quynh Trang Nguyen Thi (Technische Universität Ilmenau)
* Raffael Bild (DIFUTURE)
* Sylvia Thun (HL7 Deutschland)
* Thomas Ganslandt (MIRACUM)
* Toralf Kirsten (SMITH)
* Ulrich Sax (HiGHmed)
### Copyright notice, use information
Copyright © 2019: TMF e. V., Charlottenstraße 42, 10117 Berlin
The content of this specification is public. There are no restrictions on subsequent use or publication rights.
For usage rights of the underlying FHIR technology, see the FHIR Base Specification.
Some code systems used are published and maintained by other organizations. The copyright of the respective publisher is valid.
## Introduction
In the CASE module of the MII Core Data Set (CDS), we only use the term case as an imprecise generic term and follow the [German Basic Profiles (R4)](https://simplifier.net/guide/basisprofil-de-r4/home) guide, the ImplementationGuide of the German FHIR basic profiles of HL7 Germany registered association. There, the differentiated use of the FHIR terms [EpisodeOfCare](http://hl7.org/fhir/episodeofcare.html), [Encounter](http://hl7.org/fhir/encounter.html) and [Account](http://hl7.org/fhir/account.html) is suggested :
The term "case" groups together different concepts that are represented in FHIR by different resources:
1. Stay / visit: The inpatient stay or outpatient visit of a patient in an institution is mapped in FHIR by the resource Encounter.
2. Billing case: The case in the sense of a grouping of medical services that are billed in a common context are represented in FHIR by the account resource. A billing case can include several encounters (e.g. pre-inpatient visit, inpatient stay and post-inpatient visit).
3. Medical case: The medical case groups information that is in the context of a common (permanent) diagnosis and is represented in FHIR by the [EpisodeOfCare](http://hl7.org/fhir/episodeofcare.html).
The focus of this IG (implementation guideline) is on the stays and visits of patients at health institutions. Stays and visits are summarized below under the term contact and differentiated by various epithets.
Contrary to what the lean allocation of the FHIR resource [Encounter](http://hl7.org/fhir/encounter.html) to inpatient stays and outpatient visits suggests, the presentation of care in healthcare institutions in a module CASE can be designed in almost any complexity.
On the one hand, it must be taken into account that patients encounter is a complex hierarchical organization during an “inpatient stay” in a hospital. The treatment contract is concluded with the institution (upper hierarchy level). Numerous duties and rights are delegated to the medical departments (middle hierarchical level) - partly by the institutions, partly by law (e.g. structural and procedural quality requirements, partly in-house research privileges).
The actual care, however, takes place through the persons acting in the care centers (lower hierarchical level). In the outpatient sector, which is essentially represented by medical practices and the “outpatient visits” of the patients, the structures and processes are generally less complex. However, this does not help much in the modeling, since the inpatient and outpatient sectors are to be mapped together in the model of the medical informatics initiative.
On the other hand, the modeling and FHIR profiling of the CASE module is intended to support a number of different application scenarios in care and research, which deal with the assignment of rights and obligations (e.g. access to patient data and in-house research privileges) and contacts with staff (e.g. hygiene measures and infection tracking), current whereabouts (e.g. delivery of medication and material), historical whereabouts (e.g. analysis of infection chains) or internal cost and performance accounting.
It should be noted that there is no CASE module for the reference projects [International Patient Summary (IPS)](http://hl7.org/fhir/uv/ips/) and [Medical information objects of the National Association of Statutory Health Insurance Physicians (MIO, KBV)](https://mio.kbv.de/site/mio#), because the application goals are different. Therefore, in the case of the CASE module, comparison models and comparison profiles cannot be used.
Conversely, the medical informatics initiative does not require the full range of contact details in every application. There are also constellations in the MII in which only a simple CASE model is required (e.g. to determine the responsibility for quality assurance or in-house research privileges) or the data situation only allows a simple CASE module (e.g. generation from the data set in accordance with [§ 21 KHEntgG](https://www.g-drg.de/Datenlieferung_gem._21_KHEntgG)). This IG (implementation guideline) differentiates between two model development phases:
* [Simple assembly model](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell) with focus on the primary department contacts
* [Complex expansion model](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/KomplexesAusbaumodell) with a more detailed representation of patient-practitioner contacts.
In the first chapter of this IG (implementation guideline), only the simple assembly model and its relationship with the tables CASE and FAB of the data set according to [§ 21 KHEntgG](https://www.g-drg.de/Datenlieferung_gem._21_KHEntgG) is described. The complex expansion model of the CASE module requires that a structural model for the facilities is developed first. Therefore, it is only sketched out in this IG (implementation guideline) for the time being.
What the described Simple assembly model and the sketched Complex expansion model have in common is the preliminary three-level hierarchy with the distinction between the organizational units institution, department and care point in the representation of the organizational structures and the complementary contact types [Institution contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#Einrichtungskontakt), [Department contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#Abteilungskontakt) and [Care point contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#Versorgungsstellenkontakt) in the representation of the backbone of the care processes.
Even the rudimentary structure model allows the addition of information on care locations to some extent. However, it only makes sense to localize the care in the complex expansion model, in which the organizational units such as the OR service, polyclinic service, ambulance service, X-ray unit, etc. are included in the model with the corresponding locations. Therefore, the supplement to the information on the care location can only be found in the final chapter of this IG (implementation guideline).
The MII-CDS module CASE is completed by the relationships to other basic modules such as [diagnosis](https://simplifier.net/medizininformatikinitiative-moduldiagnosen) and [procedure](https://simplifier.net/medizininformatikinitiative-modulprozeduren), and to expansion modules such as the structural data module, which models the organizational unit and the patient's care location. Further information on this can be found in the section [Context in the overall project / references to other modules](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/KontextimGesamtprojektBezgezuanderenModulen).
Another central entity of the MII-CDS case module is the [Account](http://hl7.org/fhir/account.html), the "account" of the billing case. However, this is only taken into account in the [complex assembly model](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/KomplexesAusbaumodell).
## Setting the goals
The task of the case module is the use-case-oriented mapping of the contacts (stays and visits) between patients and facilities with the main questions “who”, “when”, “with whom”.
In the reference projects [International Patient Summary (IPS)](http://hl7.org/fhir/uv/ips/) and [Medical Information Objects (MIO)](https://mio.kbv.de/site/mio#), those involved did not ask these questions for their application scenarios and therefore dispensed with a case module. In the medical informatics initiative, the tracking of contacts often does not play a role. Occasionally it is necessary to know the responsible specialist department with its rights and obligations, and only in one use case, the Infection Control use case of the HiGHmed consortium, is it necessary to understand the complete contact history of the person treated.
If the [Simple assembly model](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell) and the [Complex expansion model](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/KomplexesAusbaumodell) are separated, the simple model can concentrate on the contacts to the specialist departments. Examples of the need in some Federal states are the assignment of in-house research privileges and, in general, the interest in department-related diagnostic statistics and similar.
When designing the simple structure variant of the Case module, orientation is based on the CASE and FAB tables of the data record in accordance with Section [21 KHEntgG](https://www.g-drg.de/Datenlieferung_gem._21_KHEntgG), so that a temporary solution can be generated from these data records.
## The Simple assembly model
Illustration in Art-Decor
The contact model of the MII CDS is based on the specifications for the FHIR Resource [Encounter](http://hl7.org/fhir/encounter.html) of the international standardization bodies and their observance in the [German Basic Profiles (R4)](https://simplifier.net/basisprofil-de-r4).
Stay / visit: The inpatient stay or outpatient visit of a patient in a institution is mapped in FHIR by the resource [Encounter](http://hl7.org/fhir/encounter.html). (Source: [German Basic Profiles (R4)](https://simplifier.net/basisprofil-de-r4))
As a generic term for stay and visit, we use the term contact.
When designing the simple assembly model of the case module, the requirements of the majority of the application scenarios (use cases of the MII, without use case infection control), as well as the rudimentary organizational structure (*Structure*) and process organization (*Process*) of the patient data-keeping facilities involved, had to be taken into account . The expandability was a relevant secondary condition (see the [Complex expansion model](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/KomplexesAusbaumodell)).
The fulfillment of the requirements of the use cases and the consideration of the organizational structure, which is initially reduced to a three-level hierarchy of institution, department and care point, is used to distinguish between:
1. [Institution contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#einrichtungskontakt): Contacts with the institution; Treatment contract etc.
2. [Department contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#abteilungskontakt): contacts to the department; Delegated care responsibility, in-house research privileges, etc.
3. [Care point contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#versorgungsstellenkontakt): Contacts to care points and those actually treating
Initially, only the [Institution contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#einrichtungskontakt) defined by the admissions and discharges of "hospital cases" and a defined selection of [Care point contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#versorgungsstellenkontakt) - as required for the majority of the use cases - are proactively implemented in the simple assembly model. The [Department contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#abteilungskontakt) can be derived from the care point contacts, which contain information about the responsible department.
### Common data elements of the contact levels
#### Contact level
To differentiate between the hierarchical levels of a contact, the characteristic of the contact level is used in the case of the MII core data record module. A distinction is made between the following expressions:
1. [Institution contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#einrichtungskontakt)
2. [Department contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#abteilungskontakt)
3. [Care point contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#versorgungsstellenkontakt)
In the simple assembly model, this structure initially **applies to stationary contacts**. The transfer to outpatient and partial inpatient contacts has yet to be coordinated.
#### Contact class
At the institution level, i.e. at the [Institution contact](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#einrichtungskontakt) level, the contact class can be inpatient, outpatient or partial inpatient. The class distinction continues with the inpatient contacts at the department level. There, a distinction is made between pre-inpatient, fully inpatient, intensive inpatient and post-inpatient classes in the simple structure
In the simple assembly model, there is no differentiation on the second level for outpatient and semi-inpatient contacts. In the **Complex expansion model** of the Case module, additional classes are added on the second and third levels, which is explained in more detail in the section [Complex expansion model](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/KomplexesAusbaumodell).
#### Patient identifier
For internal use, the so-called patient number serves as an identifier. This number is assigned, at the first admission to the institution, in parallel to the first case number (admission number). With each re-admission (or corrective afterwards), an assignment to this constant patient number and a new, changing case/admission number are assigned.
#### Admission number
When planning an admission or when admitting, each patient receives an admission number (also known as a case number or internal hospital identifier). In principle, this admission number applies from admission to discharge - and also for the associated pre-inpatient and post-inpatient contacts. In all digitally supported processes, it is used to allocate to the patient's stay in the institution. In the MII CDS it serves as an identifier or reference to the institution contact.
There is a special feature with planned admissions and pre-inpatient contacts where the admission number is assigned before the admission, which must be taken into account in the admission process. The same applies to the use of the admission number for post-inpatient contacts after discharge. However, this is only specified in the context of the [Complex expansion model](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/KomplexesAusbaumodell).
#### Start date
The formal start date of a institution contact is the time of admission. Previous inpatient contacts are not taken into account when defining the start date.
There is also a new start date for the department and care point contact. In each case, this involves "admission" to or access to the specialist department or care point within the framework of a relocation chain or also in the case of intercurrent contacts / visits without formal relocation.
#### End date
The formal end date of an institution contact is the associated discharge time. Subsequent post-inpatient contacts are not taken into account when defining the end date.
The same applies to the end date for the department and care point contact as for the start date.
### The temporary construct of the "organizational unit"
For the complete mapping of the data structures in the case module, references to data elements from a future module to organizational units are required. Since this module is not yet available, but the case module should still be used, the temporary organizational unit model was created.
Only those data elements, that are needed to complete the Case module, are to be defined here and should not be viewed as a complete module. The required data elements include:
### Institution identifier
To prepare for cooperation with other institutions, the institution identifier should be composed of the name of the institution and the institution identifier of the institution.
### Department identifier
The department identifier consists of the department name, the department abbreviation, the indication of the main department versus the external physician department, the subject description and the subject key.
**Until further notice, the proprietary German department key of § 301 SGB V and the data set according to § 21 KHentgG will be used as the specialty key, because this is used as a department key in every hospital. The use of the IHE department key is considered as soon as relevant requirements are formulated.**
### Care provider identifier
In the simple assembly model, the care point is limited to the medical ward service of the specialist departments that is not spatially assigned. The abbreviation is made up of an abbreviation for medical ward service (ärztlichen Stationsdienst- ÄSD), an intensive care discriminator and the specialty abbreviation. (For example ÄSD_N_0100 or ÄSD_I_3600 or ÄSD_N_2800 or ÄSD_I_2800).
In the further expansion, the care point identifier will in principle consist of the care point name and the in-house abbreviation. It should be the name of the organizational unit. It must be checked how a mix-up with the designation of the location of the care can be avoided.
### Institution contact
An institution contact begins with admission for inpatient treatment (the confirmation of a planned admission is the same) in the hospital with the conclusion of a treatment contract and initially ends with discharge from inpatient treatment. The cohesive characteristic of a institution contact is the admission number (also called case number), which is assigned when admissioned or when planning an admission.
**Pre-inpatient contacts** - that is, previous contacts to the institution's care points, like other out-patient and semi-inpatient contacts, are not taken into account in the simple assembly model.
**Post-inpatient contacts** - that is, contacts to care centers of the institution that follow on in time are not taken into account in the simple structure model, like other outpatient and semi-inpatient contacts.
Pre- and post-inpatient contacts are omitted in the **Simple assembly model** because these have the character of secondary care visits such as surgery visits, X-ray visits and others, which are only presented in more detail in the [Complex extension model](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/KomplexesAusbaumodell). These contacts can be neglected for most questions, as they do not play a special role either in the case count (number of institution contacts) or in the assignment of diagnoses or procedures. They are managed under the same admission number (case number) as the inpatient core case. These are usually not taken into account when calculating the length of stay.
Of course, there are also questions where pre- and post-inpatient contacts have to be taken into account, such as infection control. However, this use case requires the implementation of the Complex expansion model anyway.
| Nr. | The term | Example or meaning |
| -------- | -------- | -------- |
| 1 | Contact level | Institution contact |
| 2 | Type of contact | Inpatient care |
| 3 | Patient identifier | Patient number, lifelong number of the person in the institution |
| 4 | Admission number | Case number assigned to the patient upon admission |
| 5 | Cause of the admission | Referral over physician |
| 6 | Reason for the admission | Hospital treatment, fully inpatient |
| 7 | Start date | Admission date, e.g. 2020.08.15 07:45:00 |
| 8 | End date | Discharge date, e.g. 2020.08.17 17:45:00 |
| 9 | Reason for dimissal | 07: deceased |
As mentioned above, institution contacts are to be differentiated according to the characteristics (contact classes) inpatient, outpatient and partial inpatient. In the simple assembly model, only stationary contacts are taken into account.
In addition to the [common data elements](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/EinfachesAufbaumodell#GemeinsameDatenelemente), a number of features are relevant in the German health care system, the characteristics of which are based on the values in the CASE table of the data set in accordance with [S§ 21 KHEntgG](https://www.g-drg.de/Datenlieferung_gem._21_KHEntgG) and can in part be assigned to the institution contact. This includes the **cause of the admission**, the **reason for admission** and the **reason for dismissal**.
The Art-Decor model is presented below.
### Art-Decor model - Institution contact
### Department contact
In the simple assembly model, the chain of department contacts (minimum and most frequent value: n = 1) corresponds to the generally uninterrupted relocation chain in the FAB table of the data set in accordance with [S§ 21 KHEntgG](https://www.g-drg.de/Datenlieferung_gem._21_KHEntgG). The relationship between the patient and the primary, bed-managing specialist departments that assume responsibility, rights and duties is reproduced. The start date of the first inpatient **department contact** (without contacts in the pre-inpatient class) is identical to the date on which the **institution contact** was made. The end date of the last full inpatient department contact (without contacts of the post-inpatient class) is identical to the discharge date of the **institution contact**. In the department contact, the reference to the specialist department can be established using the **specialist department key**.
For the [complex expansion model](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/KomplexesAusbaumodell), there is the consideration of taking into account not only the contacts to the primary specialist departments (as in the FAB table) but also the contacts to the secondary specialist departments (anesthesia, radiology, adjuvant operating departments) and nursing departments. However, this is only dealt with in more detail in the context of the [complex expansion model](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/KomplexesAusbaumodell) or the **structural data of expansion module**.
### Art-Decor model - department contact
### Care point contact
Care point contacts represent the patient's contacts with **organizational units** (OU) serving as care points such as wards, operating areas, examination and work station areas. It should be ensured that it is the OU to which the care location is assigned. In individual cases, an OU can have a fixed care location, which means that they can have the same name.
In the simple assembly model, the representation of the care point contact is optional. Due to the 1: 1 relationship to the specialist department, the abstract OU “Medical Ward Service” of the bed-managing departments can be integrated into the department contact. The implementation in the complex expansion model will be decided at the appropriate time.
### Art-Decor model - care point contact
### The Billing case (postponed)
For the inpatient sector, the rules for defining billing cases are defined by the flat-rate case law and the hospital fees law. The data format for the calculation of charges and the transmission of data to the Institute for Hospital Charges (Entgelte im Krankenhaus- InEK) is specified in [§ 21 KHEntgG](https://www.g-drg.de/Datenlieferung_gem._21_KHEntgG). This also contains the description of the CASE table. (There is a large overlap with the formats of § 301 SGB V, which are used for communication with the health insurance companies.)
Since we closely followed the key points of the case definition, including the case consolidation provisions in the Hospital Remuneration Act, when determining the key points of the contact of the type **institution contact**, there is a clear basis for the modeling of the account or billing case. The characteristics for the billing cases are taken directly from the CASE table of the § 21 data record.
It is planned to keep the remaining tables of the § 21 data record in a separate extension module of the MII CDS in order to enable internal compatibility with operational control working groups.
Each billing case has a start date and an end date. These dates are often identical to the start date and end date of an associated institution contact. Occasionally, successive cases have to be merged into one billing case because of the same diagnosis or complications.
These administrative case consolidations are occasionally only carried out after a long period of time (for example after a request by the medical service of the health insurance companies) and must be taken into account when maintaining the data repositories in data integration centers.
## Complex expansion model
As continuously communicated in this discussion paper, we distinguish between a s**imple assembly model** (SAM) and a **complex expansion model** (CEM) in the approach to resolving the balloting comments on the proposed CASE module of the MII CDS.
The simple assembly model with contact information Contact modules of the medical ward service should be part of the first round of balloting with a management solution. This should also be the simple construction model, the comments of the HL7 balloting will be resolved as possible. Where this is not possible, the commentators are referred to the further developments of the complex expansion model.
The **complex expansion model** of the CASE module is to be coordinated following the acceptance of the **simple assembly model** in a cooperation between representatives of the MI initiative, industry (BVITG) and the standardization associations (SITIG). The following explanations establish the reference to the simple assembly model and may serve as a basis for further discussion. The more complex expansion model is to be consolidated in a new ballot.
### Differences between the simple assembly model and the complex extension model
Currently, the simple assembly model is sufficient for almost all MII use cases. As far as the authors of this discussion paper are aware, the more complex expansion model could currently only be useful for the Infection Control use case, provided that its independent modeling group should use it. In the future, it will have to be checked whether the more complex model - as assumed by the authors - can not also be used for more differentiated analyzes of the care process by ergonomists or quality managers.
The implementation of the simple model has essentially been described above. In the following, the need for adjustments in the implementation and parameterization of the more complex expansion model is described. There are six relevant differences:
1. In the complex expansion model, on the level of the institution organizational units and institution contacts, in addition to the hospitals' inpatient area, which has been focused up to now, their outpatient services as well as medical practices, emergency services, therapists and other facilities are to be taken into account.
2. In the complex expansion model, not only the care contributions of the primary medical departments should be taken into account at the level of the departmental organizational units and departmental contacts. Rather, there are contacts to care departments and department contacts for secondary services.
3. In the complex expansion model, at the level of the care point organizational unitss and the care point contacts, not only the medical ward service of the bed-managing departments as a care point should be taken into account, but also the care contributions from nursing organizational units and non-bed-managing departments. Consequently, the primary departments also include their use in the operating theater, in the examination areas, in the outpatient departments and in the consultation service.
4. Pre- and post-inpatient contacts are also included in the complex expansion model as contact segments.
5. A consistent solution is developed for the partial discrepancies between "non-case-merged" institution contacts and case-merged billing cases.
6. In the complex expansion model, the care locations can be included in the representation. The difference between the partially abstract organizational units of the care points (e.g. medical service without spatial allocation or nursing station (organizational units) with spatial connection) and the care locations as location (e.g. station (place)) must be taken into account.
Institution contact and billing cases as well as the existing department contacts and modules of the inpatient area remain essentially unaffected when changing from the simple assembly model to the complex extension model.
The combinatorial extension resulting from the expansions is indicated by the following figure; While in the simple assembly model only one variant of facilities (hospitals), departments (bed-managing medical departments) and care centers (medical ward service) were provided, complex extension models result in a noticeable spectrum of variants and their combination.
### Matrix of contact levels and contact classes in the complex expansion model
The expansions and the resulting old and new combinations of contact levels and contact classes are considered in the following from the perspective of the department and care point contacts.
In the case of departmental contacts in the primary specialist departments (for example, for care by a gastroenterology clinic or a visceral surgery clinic), in addition to bed-side care by the medical ward service in the ward area, examinations and treatments in decentralized care centers (organizational areas) such as endoscopy Laboratory and the operating theater are taken into account. In any case, a distinction must still be made between normal wards, intermediate wards and intensive care wards.
However, patients are not only cared for by their primarily responsible specialist departments. For example, gastroenterological patients can be operated on by visceral surgeons, pneumological patients by thoracic surgeons and cardiological patients by cardiac surgeons. In these examples, the use of a care center is linked to the use of another specialist department providing secondary services, which may be the primary clinics for other patients. Similarly, contacts to anesthesiologists, radiologists and so on, in addition to using the relevant care center, also involve using another specialist department.
The organization of care in most hospitals is organized independently with their own care departments. This allows the interpretation that contact with nursing departments is seen parallel to contact with specialist departments and that the use of nursing services can be seen as contact with nursing departments and contact with nursing care centers (often in the form of wards with beds).
The breakdown into contact levels is followed by a differentiation of the contact classes.
In the continuation of the simple assembly model at the contact level institution contact, we distinguish between the in-patient, out-patient and semi in-patient classes as well as the special out-patient form- only *pre-in-patient*.
At the contact level of the department contacts, we can still find the pre-inpatient, fully inpatient and post-inpatient classes in the assembly model. In addition, however, the secondary care class is added to take account of internal foreign contacts and the secondary and nursing classes to take into account the contacts to nursing departments, as well as outpatient and day care. In the case of operations by "external specialist departments", for example, the talk should be of secondary services and not of "outpatient visits".
The expansion of the third encounter level care point requires new encounter classes. As a preliminary approach, the ValueSet Normal Medicine, Intensive Care Medicine, Normal Care, Intensive Care, OR, examination and working unit and Consultation is suggested for inpatient encounters; for day-patient encounters, the shortened ValueSet for normal medicine, normal care, OR, examination and working unit and consultation; for outpatient encounters initially only examination and working unit, consultation and surgery.
**Encounter classes by sector (The proposals are not final !!)**
| Encounter level/type | outpatient including "pre-inpatient only" | semi in-patient |outpatient including "pre-inpatient only" |
| -------- | -------- | -------- |--------|
| Level 1: Institution | in-patient | semi in-patient |outpatient including "pre-inpatient only" |
| | pre-in-patient, fully in-patient | semi in-patient |outpatient including "pre-inpatient only" |
| Level 2: Department | Secondary care, nursing care, post-hospital | | |
| Level 3: Care point | Normal Medicine, Intensive Care Medicine, Normal Care, Intensive Care, OR, U&B, Consiliar | Normal medicine, normal care, OP, U&B, Consiliar |U&B, Consiliar |
### Start and end dates in the complex expansion model
In the complex expansion model, there are institution contacts and primary department contacts, for which the rules for start and end dates are taken over from the simple assembly model. (The handling of "merged cases" must be worked out separately.) Synchronously, the start and end dates for inpatient care are adopted according to the values entered in the hospital information system. Temporary absences - for examinations, treatments and operations, for example - are not taken into account. This means that, as with the primary specialist department contacts in the full inpatient phase, the start date of the first care department contact corresponds to the start date of the institution contact, the date of admission to the house. Similarly, it also applies that the end date of the last care department contact coincides with the end of the institution contact, i.e. the date of discharge from the house, and that the care department contacts usually form a seamless chain.
The situation is different with the specialist department contacts for internal foreign services (secondary services). If possible, exact attendance times are noted here, which look like parallel attendance, but only reflect parallel responsibilities. This picture of sequential and parallel contacts at the department level will be reflected at the care point level. As with the “medical ward service”, which has already been taken into account in the simple assembly model, 1:1 relationships can often be assumed for further contacts as well.
The further procedure for modeling the secondary mapping of the care process in the core data set will depend on the one hand on the questions and on the other hand on the available data and, thirdly, on the balance between transactional and analysis-oriented storage and use of the data. It can be assumed that sequential dates are chosen with regard to the start and end dates of the contacts to care services, while the chronological assignment to secondary care centers (operating theater, x-ray, endoscopy) is often presented as parallel events.
### Consideration of the care locations in the complex expansion model
It was already pointed out in the simple structure model that a distinction must be made between care locations as locations and care points as organizational units. This will be an important aspect of the structural data module in the MII core data set. Care locations in the narrower sense are the structural units of a hospital such as buildings, floors, corridors, room groups and rooms. Depending on the question, elements within rooms such as beds, operating tables, examination chambers and examination chairs will also be regarded as care locations.
At this point, it can be considered that in the care process, as in the relationship between department and care point, 1:1 relationships will often arise in the relationship between care point and care location. Prominent examples are Station organizational units and Station location as well as OR organizational units and OR location. This 1:1 ratio is put into perspective if, in different application scenarios, different details such as resting space and bed, or bed for preparation, operating table and recovery room bed have to be taken into account. The modeling of the complex expansion model also offers a wide range of options at this point and should therefore be implemented in accordance with the requirements at the given time.
## Context in the overall project / references to other modules
As already mentioned in the introduction, the contact entities structure the documentation in the most important sources of the medical informatics initiative, the hospital information systems of the university hospitals involved. This source documentation also provides information on diagnoses, examinations (e.g. laboratory findings) and treatments (procedures and medications). In the sources, the information primarily relates to the current stays (contacts /cases). In the MII core data set as in the International Patient Summary (IPS) and the EPA of the National Association of Statutory Health Insurance Physicians (Kassenärztlichen bundesvereinigung- KBV), however, the information is assigned to the patients in the Person module.
The reference to the institution contacts and, in some cases, to the department contacts is not completely lost, but is included in the relationships of the modules Diagnosis, Procedure; Medication, Laboratory findings and other information on these contact entities are taken into account. However, it is not primarily about tracking the "provenance", but about the context-specific meaning of the information.
### Relation to international projects
In the most important reference of the MII core data set, the [International Patient Summary](https://international-patient-summary.net/?title=Main_Page), there is no equivalent for the elements of the Case module. There diagnoses and procedures are simply assigned directly to the person.
In the MII core data set, however, the Case module is required in order to establish the links to the care process and, in particular, to the specialist departments. The relationship is essentially based on the fact that the most important data sources of the medical informatics initiative are the hospital information systems and clinical workplace systems of the participating locations.
In the case of international comparisons, as described in this specification, it should be noted that not only the billing case, but in a certain sense also the various contact levels are constructs of the German health care system.
Nevertheless, the CASE module in the Medical Informatics Initiative (MII), including the subdivision into the various contact levels, is required for various purposes:
1. In the first place, data protection must be mentioned for some federal states (especially Berlin).
2. Furthermore, department assignments and care locations play a role in the HiGHmed use case Infection Control and in the SMITH use cases HELP and ASIC. (more on this in the complex expansion model).
Outside of the MII, the CASE module can play a major role in benchmarking, quality assurance and controlling projects.
### Relation to the Diagnosis module
The following aspects are taken into account for the inpatient and partial inpatient context. In the course of the admission process to the hospital (including digital communication with the health insurance companies), diagnoses are initially recorded as a prerequisite for the costs to be covered by the health insurance companies. The referring diagnosis category describes the illness reported by the referring doctor. The admission diagnosis category reflects the (preliminary) assessment of the receiving house.
Diagnostic information is also regularly noted in the course of the care process - for example as main and secondary diagnoses, or to justify performance requirements and therapeutic measures, including medications.
The almost final diagnosis documentation takes place in the course of discharge from the hospital. The diagnoses recorded in the process are checked by senior doctors and controllers, and (colored by billing rules) a distinction is made between main hospital and secondary hospital diagnoses. The German Coding Guidelines prohibit the inclusion of information on diagnoses in communication with the insurance providers if they did not generate any expenses during the inpatient stay. In relation to the billing case, these diagnoses do not occur.
If the recorded but non-billing-compatible diagnoses are not deleted (which is in principle forbidden), they should be taken into account in the relationships to the institution contacts and, if possible, to the department contacts. If possible, a distinction may be made between the diagnosis relation types with the characteristics main diagnosis, secondary diagnosis and not billing compatible.
From the conditional terms instruction and admission diagnosis, for which only individual diagnoses are set a flag, the feature "Present on admission, POA" will in future (at the latest when the ICD-11 is introduced) have to be differentiated for all diagnoses. It should be mandatory to carry this yes-no indicator with every diagnosis that is assigned to a institution contact. Accordingly, a "present-on-discharge" (POD) indicator for occasional use should also be provided for each care case- diagnosis.
In the FHIR profiles it looks like this; the relation to the diagnosis profile can be made from the case profile as well as from the diagnosis profile. However, these two alternatives are not equally important. An encounter cannot refer to up to several diagnoses; each of these diagnosis references can be assigned a so-called diagnosis role. This role should primarily express whether the referenced diagnosis for the contact instance is a main or a secondary diagnosis. The main diagnosis is coded here as Chief Complaint (CC), while the secondary diagnosis can be coded as Comorbidity (CM) (for more information see [DiagnosisRole](http://hl7.org/fhir/valueset-diagnosis-role.html)).
For the reference from the diagnosis to the case, it must be noted that although a diagnosis may refer to a case, this must be the case / contact within the framework of which the diagnosis was also established. In other words, a diagnosis must not refer to a institution contact, but to the applicable department / care point contact.
### Relation to the Procedure module
For this purpose, procedures always have a reference to a care point location. For example, some procedures are carried out in the "basic care point locations" of the "ward" type. For many procedures, namely "operations", there are political handling conditions, spatial infrastructures, namely "operating theaters", where they will be. In the initial MII core data set, procedures are not assigned to care point locations. The design of this assignment will be postponed until the next version of the MII CDS, in which this assignment plays a role for specific use cases (see also [complex expansion model](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/KomplexesAusbaumodell))
In addition to the "care point case" class, the MII CDS also knows the "billing case" class. Although procedures in the inpatient sector of the German health system are noticeably relevant to billing, the assignment of procedures to billing cases is dispensed with in the initial basic module of the MII core data set. The design of this assignment will be postponed until the next version of the MII KDS, in which this assignment plays a role for specific use cases. A complementary assignment of procedures to (billing) cases is provided for an extension module with § 21 data.
## References
The modeling of the data set for the CASE module contains references to the following projects:
1. In order to achieve cross-compatibility with §21 KHEntgG, the [data elements](https://www.g-drg.de/Datenlieferung_gem._21_KHEntgG/Dokumente_zur_Datenlieferung/Datensatzbeschreibung) defined there were used to a large extent. Further information can be found [here](https://www.gesetze-im-internet.de/khentgg/__21.html).
2. For inpatient billing, reference is made to [§301 SGB V](https://www.gesetze-im-internet.de/sgb_5/__301.html).
3. The outpatient billing is regulated by [§295 SGB V](https://www.gesetze-im-internet.de/sgb_5/__295.html).
4. The [§ 301-SGB-V](https://www.dkgev.de/themen/digitalisierung-daten/elektronische-datenuebermittlung/datenuebermittlung-zu-abrechnungszwecken/datenuebermittlung-nach-301-abs-3-sgb-v/) department keys come from the Federal Care Rate Ordinance from 2003, Appendix 2, Key.
5. There are no further references with regard to the care point case.
The core specification of [HL7 FHIR](http://hl7.org/fhir/) and the previous work on the German basic profiles in [STU3](https://simplifier.net/basisprofilde) and [R4](https://simplifier.net/basisprofil-de-r4) were also taken into account.
The present specification was designed on the basis of the description of the MII core data set in the version of March 10, 2017 ([PDF](https://www.medizininformatik-initiative.de/sites/default/files/inline-files/MII_04_Kerndatensatz_1-0.pdf)), as well as the data set description in [Art-Decor](https://art-decor.org/art-decor/decor-project--mide-).
## Use cases / information model
### Description of scenarios for the application of the CASE module
The modeling and FHIR profiling of the basic modules of the MII core data set, including the CASE module, aim to generate the most generic information models possible for a wide range of application scenarios. The consortial use cases of the four consortia of the [Medical Informatics Initiative (MII)](https://www.medizininformatik-initiative.de/en/start) [DIFUTURE](https://difuture.de/), [HiGHmed](https://www.highmed.org/), [MIRACUM](https://www.miracum.org/) and [SMITH](https://www.smith.care/konsortium/) and the two transconsortial joint projects [CORD-MI](https://www.medizininformatik-initiative.de/CORD) and [POLAR-MI](https://www.medizininformatik-initiative.de/POLAR) have received priority consideration. The fact that the digitally saved (or to be saved) patient data from the care processes in the 34 university hospitals involved form the essential basis of the Medical Informatics Initiative also had a major influence on the design.
To the CASE module:
The care data recorded in the hospital information systems as the most important data source of the MII are always person and case -related. Every cross-sectional view considers cases (with different lengths). And almost every longitudinal view is based on a series of cases.
Cases are counted in MII use cases with feasibility studies. The discovery of knowledge in data is based on case data and the application of knowledge to patients (decision support) aims at specific cases. Cases are presented in tumor boards and nosocomial infections are combated in the case of infection control.
### Examples of the simple assembly model
As the simplest and at the same time one of the most frequent variants of the stay in the hospital, care can be provided by a bed department such as the “Clinic for Internal Medicine”, in which the majority of the examination and treatment is carried out by the ward service of the clinic.
The use of the medical ward service of the Clinic for Internal Medicine with a start date and an end date defines the "inpatient stay of the patient in the institution, which is mapped in FHIR by the resource [Encounter](http://hl7.org/fhir/encounter.html)."
The length of stay or the length of time the care point contact (in the care point as an organizational unit), the department contact in the specialist department and the institution contact can easily be determined as the difference between the end date and the start date. When calculating the “official” length of stay or the “official” occupancy days, different rules may have to be observed; However, this can be shifted to the **billing case** not described here for the same admission number (case number).
The mainstay of the simple assembly model is the **care point contact**, which describes the patient's contact with selected department-related care point units with information on the beginning and the end. This also implicitly shows the contacts to specialist departments (department contacts) and to the institution (institution contacts). The institution contact should nevertheless be taken into account in parallel.
This hierarchy is shown in the following figure for this simple but frequent constellation with only one care point contact:
The institution contact describes the contact to the institution- the Berolina hospital. This is determined by the treatment contract. The institution contact contains the department contact. The department contact describes the contact to the surgery department.This is determined by the transfer of responsibility from the institution- Berolina hospital, to the surgery department. The department contact contains the care point contact for inpatient surgery. The actual care takes place in the care points (ward service, operating service, examination laboratory, ambulance).
The next example also shows a common form of stay in a hospital, which consists of three (main) care point contacts.
The institution contact begins with a normal medical stay in a normal ward (= care point) of a cutting subject (= department, e.g. clinic for surgery, specializing in general surgery, 1500). This is followed by an intensive care stay in an intensive care unit (= care point) of an intensive care unit (e.g. Clinic for Intensive Care Medicine and Anesthesiology, Specialization Intensive Care Medicine, 3600). The institution contact is rounded off by a normal medical stay in a normal ward (= care point) in the same specialist department as at the beginning (= department, e.g. clinic for surgery, specializing in general surgery, 1500). This results in a institution contact with three department contacts and three care point contacts.
#### The individual scenarios of the consortia:
* DIFUTURE: The DIFUTURE approach is determined by application scenarios (use cases) that are linked to specific clinical pictures. The focus is on the neurological disease entities multiple sclerosis and Parkinson's disease, but also on oncological and cardiological indications. Multiple sclerosis and Parkinson's disease are characterized by years of, unfortunately mostly progressive, courses. Cross-sectoral aspects also play a role. As a result, the focus is on the patient reference, but also on the data that can be assigned to the treatment episodes with reference to the case. The case reference is an important allocation variable for the disease progression, which usually lasts for years, and the associated therapeutic efforts. All parameters specified in the case module are relevant for DIFUTURE.
* HiGHmed: As part of HiGHmed, patient-related data are generally integrated into the MeDICs. However, there is a lot of data that is related to a billing case in the documentation. This includes, among others, diagnoses, procedures, but also movements.
* MIRACUM: Basically, most medical questions are related to treatment cases or their duration or sequence. In the MIRACUM consortium, the treatment case is therefore a central reference value in all three use cases processed. Results are also related to treatment cases in the published analyses on the therapy of strokes or in COVID-19 patients.
* SMITH: SMITH aims to demonstrate the added value of this data use with one methodical and two clinical use cases. In the methodical use case "Phenotype pipeline (PheP)", SMITH develops innovative data analysis methods and tools that automatically extract medical information from electronic patient files. In the clinical use case “Algorithmic Surveillance (ASIC)”, the goal is pursued in intensive care units to continuously evaluate patient management systems in order to automatically monitor the patient's condition in order to enable faster therapeutic intervention. The clinical use case "**H**ospital-wide **EL**ectronic medical record evaluated computerized decision support system to improve outcomes of **P**atients with staphylococcal bloodstream infection (**HELP**)" focuses on electronic support for the guideline-compliant use of antibiotics for the early, targeted control of bacterial infections. All parameters specified in the case module are relevant for SMITH.
* CORD-MI: In the cross-consortium joint project CORD-MI, the visualization of rare diseases by differentiating the diagnoses plays a central role. Since the diagnoses are collected in the care context on a case-by-case basis, the care cases represent an important allocation parameter.
* POLAR-MI: In the cross-consortium joint project POLAR-MI "**POL**ypharmazie, **A**rzneimittelwechselwirkungen und **R**isiken- Polypharmacy, drug interactions and risks", a contribution is made to the detection of health risks in patients with polymedication. Since diagnoses, prescriptions of medications and laboratory parameters are collected on a case-by-case basis in the care context, the cases of care are an important allocation parameter.
### Datasets including descriptions
The official and approved version of the information model for the CASE module can be found on ArtDecor. To standardize the representation, the information model was also mapped as a FHIR Logical Model:
(**insert link??**)
It should be noted that the logical model focuses purely on the mapping of the data elements and their description. The data types and cardinalities used are not to be regarded as mandatory. This is finally determined by the FHIR profiles. In addition, this is not about the FHIR modeling, this representation is only intended to show the content modeling of the model carried out with the Art-Decor.
| Logical record | Description |
| -------- | -------- |
| Case | The basic case module combines features of a stay in a health institution such as admission number, reason for admission, reason for discharge, etc. |
| Case.InstitutionContact | Outpatient, inpatient, pre-inpatient or post-inpatient stay of a patient in a health institution |
| Case.InstitutionContact.ContactLevel | Type of case (**institution contact**, department contact, care point contact) |
| Case.InstitutionContact.ContactClass | At the institution level, i.e. at the institution contact level, the contact class can be inpatient, outpatient or partial inpatient. |
| Case.InstitutionContact.PatientID | For internal use, the so-called patient number serves as an identifier. This is assigned parallel to the first case number (admission number) when admitted to the institution. With each re-admission (or corrective afterwards), an assignment to this constant patient number and a new, changing case number are assigned. |
| Case.InstitutionContact.AdmissionNumber | When planning an admission or when admitting, each patient receives an admission number (also known as a case number or internal hospital identifier). In principle, this admission number applies from admission to discharge - and also for the associated pre-inpatient and post-inpatient contacts. In all digitally supported processes, it is used to allocate to the patient's stay in the institution. |
| Case.InstitutionContact.CauseOfAdmission | According to §21 KHEntgG |
| Case.InstitutionContact.ReasonForAdmission | The reason for admission must be specified in accordance with key 1 of Appendix 2 to the § 301 agreement. The 3rd and 4th digits (xx) are the possible values according to code 1 (01 to 07, for day-related fees also 21 to 27). Cases with the values “41” to “47” in the 3rd and 4th digits (treatment within the framework of contracts for integrated care) can be transmitted. The reason for admission can be omitted for accompanying persons and caregivers who are admitted (reason for admission "B"). In all other cases, the reason for admission is a must. |
Case.InstitutionContact.StartDate| Beginning of a medical institution contact |
| Case.InstitutionContact.EndDate | End of a medical institution contact |
| Case.InstitutionContact.ReasonForDischarge | According to §21 KHEntgG |
| Case.DepartmentContact | |
| Case.DepartmentContact.ContactLevel | Type of case (institution contact, **department contact**, care point contact) |
| Case.DepartmentContact.ContactClass | |
| Case.DepartmentContact.PatientID | Analogous to Case.InstitutionContact.PatientID |
| Case.DepartmentContact.AdmissionNumber | Corresponds to the case or admission number described under the institution contact |
| Case.DepartmentContact.StartDate | Beginning of a medical department contact |
| Case.DepartmentContact.EndDate | End of a medical department contact |
| Case.DepartmentContact.DeaprtmentKey | Unique identifier of a specialist department in inpatient healthcare institutions. The FAB key must be used for cross-institutional research projects in the health system in Germany. |
| Case.CarePointContact | |
| Case.CarePointContact.ContactLevel | Type of case (institution contact, department contact, care point contact) |
| Case.CarePointContact.ContactClass | |
| Case.CarePointContact.PatientID | Analogous to Case.InstitutionContact.PatientID |
| Case.CarePointContact.AdmissionNumber | Corresponds to the case or admission number described under the institution contact |
| Case.CarePointContact.StartDate | Beginning of a medical care point contact |
| Case.CarePointContact.EndDate | End of a medical care point contact |
### UML
A UML class diagram was created as a more abstract version of an information model and to better illustrate the relationships between the technical concepts. Concepts depicted as groups in ART-DECOR are modeled as separate classes, which here have associations with one another. References to the core data record basic modules person and diagnosis, and to the expansion module structural data are highlighted in color.
(**INSERT DIAGRAM**)
## Technical implementation
### FHIR Profile
| **Note** | **Mandatory / must-support elements** |
| -------- | -------- |
|  | For elements marked as mandatory or as must-support, reference is made at this point to the corresponding [rules of the IPS](https://build.fhir.org/ig/HL7/fhir-ips/design.html#must-support), which also apply to this ImplementationGuide |
### Encounter (contact health institution)
This profile describes a case / contact in the medical informatics initiative.
Canonical:https://simplifier.net/packages/de.medizininformatikinitiative.kerndatensatz.fall/1.0.0/files/343013
**INSERT LINK**
| FHIR-Element | Explanation |
| -------- | -------- |
| Encounter.id | Must-support, but optional |
| Encounter.meta | Must-support, but optional |
| FHIR-Element | Logical record |
| -------- | -------- |
| Encounter.type | Case.InstitutionContact.ContactLevel |
| Encounter.class | Case.InstitutionContact.ContactClass |
| Encounter.subject | Case.InstitutionContact.PatientID |
| Encounter.identifier | Case.InstitutionContact.AdmissionNumber |
| Encounter.hospitalization.admitSource | Case.InstitutionContact.CauseOfAdmission |
| Encounter.reasonCode | Case.InstitutionContact.ReasonForAdmission |
| Encounter.period.start | Case.InstitutionContact.StartDate |
| Encounter.period.end | Case.InstitutionContact.EndDate |
| Encounter.hospitalization.dischargeDisposition | Case.InstitutionContact.ReasonForDischarge |
| FHIR-Element | Logical record |
| -------- | -------- |
| Encounter.type | Case.DepartmentContact.ContactLevel |
| Encounter.class | Case.DepartmentContact.ContactClass |
| Encounter.subject | Case.DepartmentContact.PatientID |
| Encounter.identifier | Case.DepartmentContact.AdmissionNumber |
| Encounter.period.start | Case.DepartmentContact.StartDate |
| Encounter.period.end | Case.DepartmentContact.EndDate |
| FHIR-Element | Logical record |
| -------- | -------- |
| Encounter.type | Case.CarePointContact.ContactLevel |
| Encounter.class | Case.CarePointContact.ContactClass |
| Encounter.subject | Case.CarePointContact.PatientID |
| Encounter.identifier | Case.CarePointContact.AdmissionNumber |
| Encounter.period.start | Case.CarePointContact.StartDate |
| Encounter.period.end | Case.CarePointContact.EndDate |
**ADD SNAPSHOT**
### Examples:
**Example institution contact**
```
{
"resourceType": "Encounter",
"id": "5844e89b-c8f3-4e26-bc0f-502e00293874",
"meta": {
"profile": [
"https://www.medizininformatik-initiative.de/fhir/core/modul-fall/StructureDefinition/KontaktGesundheitseinrichtung"
]
},
"status": "finished",
"identifier": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "VN"
}
]
},
"system": "http://medizininformatik-initiative.de/fhir/NamingSystem/Aufnahmenummer/MusterKrankenhaus",
"value": "F_0000002"
}
],
"class": {
"code": "IMP",
"display": "Inpatient",
"system": "http://hl7.org/fhir/v3/ActCode/cs.html"
},
"subject": {
"reference": "Patient/2b9d3335-70df-4055-b33d-27a55fe00855"
},
"serviceProvider": {
"identifier": {
"system": "http://medizininformatik-initiative.de/fhir/NamingSystem/Einrichtungsidentifikator/MusterKrankenhaus",
"value": "260123451_MusterKrankenhaus"
}
},
"diagnosis": [
{
"condition": {
"reference": "Condition/e6b6895c-549b-47c5-a842-41100761385d"
}
}
],
"hospitalization": {
"admitSource": {
"coding": [
{
"system": "https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Aufnahmeanlass",
"code": "N"
}
]
},
"dischargeDisposition": {
"coding": [
{
"system": "https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Entlassungsgrund",
"code": "12.0"
}
]
}
},
"reasonCode": [
{
"coding": [
{
"system": "https://www.medizininformatik-initiative.de/fhir/modul-fall/core/CodeSystem/Aufnahmegrund",
"code": "107"
}
]
}
],
"period": {
"start": "2020-01-08T07:00:00+01:00",
"end": "2020-01-11T05:00:00+01:00"
}
}
```
**Example department contact**
```
{
"resourceType": "Encounter",
"id": "28436186-b5b3-4881-b000-8a89abf659b7",
"meta": {
"profile": [
"https://www.medizininformatik-initiative.de/fhir/core/modul-fall/StructureDefinition/KontaktGesundheitseinrichtung"
]
},
"identifier": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "VN"
}
]
},
"system": "http://medizininformatik-initiative.de/fhir/NamingSystem/Aufnahmenummer/MusterKrankenhaus",
"value": "F_0000001"
}
],
"status": "finished",
"class": {
"system": "https://www.medizininformatik-initiative.de/fhir/core/CodeSystem/EncounterClassAdditionsDE",
"code": "operation",
"display": "Operation"
},
"type": [
{
"coding": [
{
"system": "https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Kontaktebene",
"code": "abteilungskontakt",
"display": "Abteilungskontakt"
}
]
}
],
"subject": {
"reference": "Patient/P_0000000"
},
"period": {
"start": "2020-11-02T03:00:00+00:00",
"end": "2020-11-02T03:59:59+00:00"
},
"reasonCode": [
{
"coding": [
{
"system": "https://www.medizininformatik-initiative.de/fhir/modul-fall/core/CodeSystem/Aufnahmegrund",
"code": "01",
"display": "Krankenhausbehandlung, vollstationär"
}
]
}
],
"hospitalization": {
"admitSource": {
"coding": [
{
"system": "https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Aufnahmeanlass",
"code": "E",
"display": "Einweisung durch einen Arzt"
}
]
},
"dischargeDisposition": {
"coding": [
{
"system": "https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Entlassungsgrund",
"code": "011",
"display": "Behandlung regulär beendet, arbeitsfähig entlassen"
}
]
}
},
"serviceProvider": {
"identifier": {
"system": "http://medizininformatik-initiative.de/fhir/NamingSystem/Abteilungsidentifikator/MusterKrankenhaus",
"value": "1500_ACHI"
}
}
}
```
## Terminologies
| Note | |
| -------- | -------- |
|  | In addition to international terminology, the CASE module defines the following code systems. It should be noted that all CodeSystems also contain an implicit ValueSet, which can be found in the respective FHIR CodeSystem resource. |
### CodeSystems
| Contact level | |
| -------- | -------- |
| Canonical CodeSystem | https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Kontaktebene |
| Canonical ValueSet | https://www.medizininformatik-initiative.de/fhir/core/modul-fall/ValueSet/Kontaktebene |
| Binding | ([required](http://hl7.org/fhir/terminologies.html#required)) Encounter.type |
This code system https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Kontaktebene defines the following codes:
| Code | Display | Definition |
| -------- | -------- | -------- |
| institution contact | Institution contact | Decribes contact with Institution |
| department contact | Department contact | Decribes contact with Department |
| care point contact | Care point contact | Decribes contact with Care point |
| Department key | |
| -------- | -------- |
| Canonical CodeSystem | https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Fachabteilungsschluessel |
| Canonical ValueSet | https://www.medizininformatik-initiative.de/fhir/core/modul-fall/ValueSet/Fachabteilungsschluessel |
| Binding | ([extensible](http://hl7.org/fhir/terminologies.html#extensible)) Encounter.serviceType |
This code system https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Fachabteilungsschluessel defines many codes, of which the following are a subset:
Code Display
0100 Internal Medicine
0200 Geriatrics
0300 Cardiology
0400 Nephrology
0500 Hamatology und Internistic Onkology
0600 Endokrinology
0700 Gastroenterology
0800 Pneumology
0900 Rheumatology
1000 Padiatrics
1100 Child cardiology
1200 Neonatology
1300 Child surgery
1400 Pulmonary and bronchial medicine
1500 General surgery
1600 Trauma Surgery
1700 Neurosurgery
1800 Surgery of blood wessels
1900 Plastic Surgery
2000 Thorax Surgery
2100 Heart Surgery
2200 Urology
2300 Orthopedics
2400 Gynecology and Obstetrics
2500 Obstetrics
2600 Otorhinolaryngology
2700 Ophthalmology
2800 Neurology
2900 General Psychiatry
3000 Child and Adolescent Psychiatry
3100 Psychosomatics / psychotherapy
3200 Nuklear Medicine
3300 Radiation Medicine
3400 Dermatology
3500 Dentistry, oral and maxillofacial surgery
3600 Intensive Medicine
2316 Orthopedics and trauma surgery
2425 Gynecology
3700 Other specialist department
| Source of admission | |
| -------- | -------- |
| Canonical CodeSystem | https://simplifier.net/packages/de.medizininformatikinitiative.kerndatensatz.fall/1.0.0/files/343008 |
| Canonical ValueSet | https://www.medizininformatik-initiative.de/fhir/core/modul-fall/ValueSet/Aufnahmeanlass |
| Binding | ([required](http://hl7.org/fhir/terminologies.html#required)) Encounter.hospitalization.admitSource |
This code system https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Aufnahmeanlass defines the following codes:
Code Display
**E** Admission by a doctor
**Z** Admission by a dentist
**N** Emergency
**R** Admission after previous treatment in a rehabilitation institution
**V** Transfer with treatment in the transferring hospital longer than 24 hours
**A** Transfer with treatment duration in the transferring hospital up to 24 hours
**G** Birth
**B** Accompanying person or caregiver who is accommodated
| Reason for admission | |
| -------- | -------- |
| Canonical CodeSystem | https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Aufnahmegrund |
| Canonical ValueSet | https://www.medizininformatik-initiative.de/fhir/core/modul-fall/ValueSet/Aufnahmegrund |
| Binding | ([required](http://hl7.org/fhir/terminologies.html#required)) Encounter.reasonCode |
This code system https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Aufnahmegrund defines the following codes:
Code Display
**01** Hospital treatment, fully inpatient
**02** Hospital treatment, full inpatient with previous pre-inpatient treatment
**03** Hospital treatment, partilly inpatient
**04** Pre-inpatient treatment without subsequent full inpatient treatment
**05** Inpatient delivery
**06** Birth
**07** Readmission due to complications (flat rate per case) according to KFPV 2003
**08** Inpatient admission for organ removal
**10** Ward equivalent treatment
| Reason for discharge | |
| -------- | -------- |
| Canonical CodeSystem | https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Entlassungsgrund |
| Canonical ValueSet | https://www.medizininformatik-initiative.de/fhir/core/modul-fall/ValueSet/Entlassungsgrund |
| Binding | ([required](http://hl7.org/fhir/terminologies.html#required)) Encounter.hospitalization.dischargeDisposition |
This code system https://www.medizininformatik-initiative.de/fhir/core/modul-fall/CodeSystem/Entlassungsgrund defines the following codes:
Code Display
**011** Treatment ended regularly, dismissed able to work
**012** Treatment ended regularly, dismissed unable to work
**019** Treatment ended normally, no information
**021** Treatment ended regularly, post-inpatient treatment planned, discharged able to work
**022** Treatment ended regularly, post-inpatient treatment planned, discharged unable to work
**029** Treatment ended regularly, post-inpatient treatment planned, no information
**031** Treatment ended for other reasons, dismissed able to work
**032** treatment ended for other reasons, dismissedunable to work
**039** treatment ended for other reasons, no information
**041** Treatment ended against medical advice, dismissed able to work
**042** Treatment ended against medical advice, dismissed unable to work
**049** Treatment ended against medical advice, no information
**059** Change of responsibility of the cost bearer
**069** Transfer to another hospital
**079** Decease
**089** Transfer to another hospital as part of a collaboration (§ 14 (5) sentence 2 BPflV in the version valid on December 31, 2003)
**099** Discharge to a rehabilitation institution
**109** Discharge to a care institution
**119** Discharge to a hospice
**121** internal transfer, dismissed able to work
**13** external transfer for psychiatric treatment
**14** Treatment terminated for other reasons, post-inpatient treatment planned
**15** Treatment ended against medical advice, post-inpatient treatment planned
**16** External relocation with relocation or a change between the fee ranges of the DRG flat rates, in accordance with the BPflV or for special facilities in accordance with § 17b (1) sentence 15 KHG
**17** Internal relocation with a change between the remuneration areas of the DRG flat-rate per case, according to the BPflV or for special facilities according to § 17b (1) sentence 15 KHG
**18** Relocation
**19** Dismissal before resumption with reclassification
**20** Dismissed before resumption with reclassification due to complication
**21** Dismissal or transfer with subsequent readmission
**22** Case closure (internal transfer) when changing between full, part-inpatient and ward-equivalent treatment
**23** Beginning of an external stay with an absence beyond midnight (BPflV area - for the relocating specialist department)
**24** End of an external stay with absence beyond midnight (BPflV area - for pseudo-specialist department 0003)
**25** Discharge at the end of the year if admitted in the previous year (for billing purposes - § 4 PEPPV)
**26** Beginning of a period without direct patient contact (ward equivalent treatment)
**27** End of a period without direct patient contact (ward equivalent treatment - for pseudo-specialist department 0004)
**28** Treatment ended regularly, ventilated on discharge
**29** Treatment ended regularly, relocated on ventilation
Sign in with Wallet
Connect another wallet