Übersetung Implementation Guides

# Module PERSON

## Coredata Set Module Person ##

| Note | Under construction!|
|---|---|
||This Implementation Guide represents the current working version of the module 'Person'. 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_Person/IGMIIKDSModulPerson.html).|

This specification describes the FHIR representation of the module Person in the core data set of the Medical Informatics Initiative (MII).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|07.04.2021|
|Version|1.0.13|
|Status| Active|
|Realm| DE|

**Table of content**
- IG MII CDS module Person
- Description of the module
- 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
- FHIRE 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 Böhnisch (HiGHmed)
- Christian Kamann (MIRACUM)
- agmar 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
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.

#### Disclaimer
The content of this document is public. It should be noted that parts of this document are based on FHIR Version R4, which is copyrighted by HL7 International.

Although this publication has been prepared with the utmost care, the authors cannot accept any liability for direct or indirect damage that may arise from the contents of this specification.

## Description module person ##
The PERSON module plays a central role in the information model of each hospital and each large study, as well as in cross-site or cross-project information models.

In the present specification, the PERSON module is explicitly modeled for PATIENTS and PROBANDS, the previous DEMOGRAPHY module is integrated, and the possibility of a cross-site Master Patient Index based on identifying data (IDAT) is provided.

The addition of demographic features such as date of birth, gender, and place of residence improves the identification capability. (The insurance number can be mentioned as a further, in a certain context well identifying characteristic for patients with statutory insurance (90% of the population in Germany)).

The individual data on persons in the PERSON module are not used for identification purposes only. An attribute such as place of residence is also needed for spatial analyses; and age and gender, for example, are also needed for risk adjustment. The fact that this information is contained in the PERSON module of the core data set does not mean that it is intended for general release. Their use is subject to the rules of the respective data integration center and the Medical Informatics Initiative (MII). The required special security must be ensured by technical and organizational measures and as part of the implementation.

Within hospitals or other health care institution, the term *patient* is used for persons admitted for care on one or more occasions. In most cases, a person receives a *patient identifier* and a *case number/admission number* the first time they are hospitalized. Each time a person is admitted again, administratively delineated, they receive new case numbers; the patient number should be retained for life, if possible. Each person can be a patient in several different hospitals and other health care institutions and is assigned a institution-specific patient identification number for each. For more information on the *patient* entity, look at module CASE.

In studies, the term *subject* is used for test persons. Each person can be a subject in different studies and receives a new *subject identification number* in each case.

From the perspective of the MII, a distinction must be made between external and internal test persons. External subjects are enrolled in cohort studies, registry studies, or randomized clinical trials where data are collected independently of the MII. On the other hand, Internal subjects are enrolled in the MII based on health care data, and individuals may be test persons more than once, for example, in the HiGHmed use cases Infection Control and Cardiology or the SMITH use cases HELP and ASIC, and additionally in one or both of the consortia-wide use cases CORD and POLAR. Each person can be a test person more than once.

For each subject, the study in which participation is taking place is noted. In addition, the featuressubject identification code, legal basis of participation, start, end and status of participation are documented.

## Context in overall project/ References to other modules ##
The module PERSON plays a central role in all use cases of the MII in the form of the entity patient and in the form of the entity test person:
- Patient: Secondary use of health care data is the focus of MII. Data of a patient exists only if the entity patient exists. The local Data Intergration Center (DIC) hold the local patient data for use.
- Subjects: Each inclusion in an MII use case generates one test person.

Person, patient and subject are at the beginning of all paths. This already happens when the data of the local care are prepared and made available in a "findable", "accessible", "interoperable" and "reusable" manner ([FAIR principles](https://www.go-fair.org/fair-principles/)) only locally at the site of care and when an initial study is planned.

The central role is played by the PERSON module with the entities patient and subject. Since each institution maintains its own instance of the MII core data set for all patients of the institution, there is initially usually a 1:1 relationship between person and patient per site. Since no individual is required to participate in a study but may participate in many studies, a 0:n relationship exists between individual and test person. Regular participation in the studies and notations as a patient are based on the patient's consents. The participation can also occur on a legal basis without agreement with the individuals, such as in the HiGHmed Use Case Infection Control, in which all patients of the participating hospitals (infected persons as the study group and non-infected persons as the reference group) receive a subject identification code on the basis of the Infection Control Act (IfSG) and are thus included.

## References ##
The modeling of the dataset to the PERSON module contains references to the following projects:
- *Collaborative Project Improvement of Care in Acute Care in Germany through the Establishment of a National Emergency Admission Registry ([AKTIN](https://art-decor.org/art-decor/decor-project--aktin-))*
- [Prescription management](https://art-decor.org/art-decor/decor-project--vomgt-) for the electronic prescription of therapeutics and medications as well as home health care. The header data was taken into account.
- International Patient Summary ([IPS](https://international-patient-summary.net)). The individual references to the [IPS-ART-DECOR project](https://art-decor.org/art-decor/decor-project--hl7ips-) can be found in the corresponding data elements of the Person module.

The [core specification of HL7 FHIR](http://hl7.org/fhir/), including the corresponding resource [patient](http://hl7.org/fhir/patient.html), and the previous work on the German Base Profiles in [STU3](https://simplifier.net/basisprofilde) and [R4](https://simplifier.net/basisprofil-de-r4) were also considered.

This specification was designed based on the description of the MII core data set in the version of 10.3.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 modules ###
With regard to the PERSON module, three use cases can be highlighted as examples:
1. External record linkage for person-related cross-institution evaluations
2. Descriptive basic evaluations by region, gender, and age
3. Risk adjustment by age and gender

Regarding on 1: In Germany, there is no unique national, cross-purpose personal identifier. Tax numbers and insurance numbers are not widely enough used or mature enough, or may not be used secondarily. Therefore, for cross-institutional person-based evaluations, a sufficiently secure linkage characteristic must be regularly implemented on an individual study basis. Both false-positive linkages and false-negative linkages must be minimized. The base for this is identity data (IDAT) such as name, date of birth, sex and place of residence, occasionally supplemented, sometimes substituted where possible, by the insurance number. The identity data (IDAT) are collected and stored separately in each institution and, in projects, are usually communicated only to a trusted agency.

Regarding on 2: In studies, basic evaluations of origin (place of residence), age, and sex, as well as the distribution of characteristics (e.g., a disease) according to these three variables, are often of a fundamental interest.

Regarding on 3: Many symptoms, diseases and events are dependent on age and gender. Therefore, direct or indirect age standardization is regularly necessary for comparisons, for which the corresponding individual data per person are required.

Due to the central relevance of the Person module, the description of the application within the individual consortia is omitted.

### Data sets including descriptions
The official and approved version of the information model for the PERSON module can be found on [ART-DECOR](https://art-decor.org/art-decor/decor-datasets--mide-). To standardise the representation, the information model was additionally mapped as an FHIR Logical Model:

It should be noted that the logical model aims purely at mapping the data elements and describing them. Data types and cardinalities used are not to be considered mandatory. This is finally determined by the FHIR profiles. For each element within the logical model, there is a 1:1 mapping to an element of a concrete FHIR resource.

| Logical dataset | Description|
|---|---|
|Person.Name.Firstname|Complete first name of a person|
|Person.Name.Surname|Surname of a person without prefixes and suffixes. E.g. to order the name alphabetically|
|Person.Name.Familyname|the complete family name, including all prefixes and suffixes, separated by spaces|
|Person.Name.Prefixword|Prefix word such as: "von", "van", "zu", cf. also VSDM specification of Gematik |
|Person.Name.Nameaffix|Name suffix as part of the surname, as defined in VSDM . Examples: Countess, Prince or Prince|
|Person.Name.Prefix|Parts of the name before the first name, e.g. academic degree|
|Person.Name.Kindofprefix| Kind of prefix, e.g. "AD" for academic degree|
|Person.Name.Birthname|Person's family name at the time of birth. Can change afterwards, e.g. through marriage and adoption of another surname.|
|Person.Demography.AdministrativeGender| Administrative gender of a person|
|Person.Demography.Dateofbirth| Patient's date of birth |
|Person.Demography.Address.Country| Country code according to ISO 3166|
| Person.Demography.Address.Postcode| Postcode according to the conventions valid in the respective country|
|Person.Demography.Address.Residence| For persons from city states including the city district|
|Person.Demography.Address.Street| Street name with house number or P.O. Box and other delivery details|
|Person.Demography.VitalStatus.PatientDeceased|Indicates whether the patient is alive or deceased.|
|Person.Demography.Vitalstatus.Timeofdeath|Indicates the time of death, if the patient died in hospital. Otherwise "zero flavour".|
|Person.Demography.VitalStatus.InformationSource|Source of vital status|
|Person.Demography.VitalStatus.LastLivingDate|Last known time when the person was still alive|
|Person.Patient.Patient-Identifier.Patient-Identifier|Health care institution unique identification number for a patient|
|Person.Patient.Patient-Identifier.Patient-IdentifierContext|The context of the patient identifier to describe the patient identifier, as the patient within a health care institution may be assigned a number per system (in the hospital: "laboratory", "radiology", "internal medicine ward" etc.).|
|Person.Patient.Insurance.Insurancenumber|Information on the identification of the insured person|
|Person.Patient.Versicherung.Versicherungsnummer.VersichertenID-GKV |**Angaben speziell für das Deutsche Gesundheitssystem** Data specific for the German health system|
|Person.Patient.Versicherung.Versicherungsnummer.Versichertennummer-PKV| **Angaben speziell für das Deutsche Gesundheitssystem** Data specific for the German health system|
|Person.Patient.Versicherung.InstitutionskennzeichenDerKrankenkasse|**Angaben speziell für das Deutsche Gesundheitssystem** Data specific for the German health system|
|Person.Patient.Insurance.InsuranceType|Type of a person's insurance|
|Person.StudyParticipant.SubjectIdentificationCode|Unique identifier of a patient in the context of a research project (clinical trial, use case).|
|Person.StudyParticipant.LegalBasis|Legal basis (e.g. consent) on the basis of which the patient may be included in the study.|
|Person.Study.Participant.StartParticipation|Start of the person's participation in the study|
|Person.StudyParticipant.EndParticipation|End of the person's participation in the study |
|Person.StudyParticipant.StatusOfParticipation|Status of a person's participation in the study, e.g. "included", "revoked", "completed", etc.|

### UML
An UML class diagram was created as a more abstract version of an information model and to better clarify relationships between the technical concepts. Concepts mapped as groups in ART-DECOR are modelled as separate classes, which here have association relationships to each other. The roles of persons in the module were assigned to the person via a class "Role", which is inherited from. Demographic properties of the person are colour-coded from the other properties.

---
## FHIR-Profile ##
The work of the core data set specifications is based on international standards and terminologies, wherever possible. In particular, the International Patient Summary should be highlighted. Adaptation to the general conditions of the German healthcare system is achieved by using the German Basic Profiles of HL7 Germany.

All elements of the core data set, adapted to the details and requirements for the use cases of the Medical Informatics Initiative, are described below in the form of FHIR StructureDefinitions. The need to adapt the FHIR profiles is explained in textual form below each profile.

### Patient ###
This profile describes a patient in the MII.

It should be noted that no specifications are made for mapping a pseudonymized patient. In the future, specifications may arise in this regard through other core data set modules.

| FHIR element | Description |
| ---| ---| --- |
| Patient.id| must-support, but optional| | Patient.meta| must-support, but optional| | Patient.identifier:versichertenId_GKV| **Speziell für Deutschland**|
| Patient.identifier:versicherungsnummer_pkv | **Speziell für Deutschland**|
| Patient.identifier:pid | See [base profile organization internal patient identifier (PID).](https://simplifier.net/guide/basisprofil-de-r4/organisationsinternerPatienten-IdentifierPID) - **Fehlermeldung** -|
| Patient.identifier| Any other identifiers| | Patient.name| See [base profile for HumanName data type](https://simplifier.net/guide/basisprofil-de-r4/Name) - **Fehlermeldung** -|
| Patient.gender | See [base profile gender](https://simplifier.net/guide/basisprofil-de-r4/Geschlecht) - **Fehlermeldung** -|
| Patient.BirthDate | See [base profile birth date](https://simplifier.net/guide/basisprofil-de-r4/Geschlecht) - **Fehlermeldung** -|
| Patient.deceased[x] | deceasedBoolean is to be replaced by deceasedDateTime where possible if patient is deceased.|
| Patient.address | See [base profile address](https://simplifier.net/guide/basisprofil-de-r4/Adresse) - **Fehlermeldung** - Multiple addresses are allowed. Systems are required to mark former addresses as such, so that the current address of the patient is recognizable.|
|Patient.link|Necessary for linking multiple patient resources, e.g. in the context of patient matching. The present specification does not contain any requirements in this regard; further design is necessary. |

|FHIR element|Logical dataset|
|---|---|
|Patient.identifier:insuredId_GKV (statutory health insurance)|Person.Patient.Insurance.InsuranceNumber.InsuredID-statutory health insurance|
|Patient.identifier:insurance_number_pkv|Person.Patient.Insurance.InsuranceNumber.InsuredID-private insurance|
|Patient.identifier:default|Person.Patient.Insurance, in case there is no insurance (pkv/ gkv)|
|Patient.identifier:pid| Person.Patient.Patient-Identifier|
|Patient.name|Person.Name|
|Patient.name.given|Person.Name.FirstName|
|Patient.name.family|Person.Name.FamilyName|
|Patient.name.family.extension.surname|Person.Name.Surname
|Patient.name.family.extension.prefix|Person.Name.Prefix|
|Patient.name.family.extension.namesuffix|Person.Name.NameSuffix|
|Patient.name.prefix|Person.Name.Prefix|
|Patient.name.prefix.extension-prefix-qualifier|Person.Name.KindOfPrefix|
|Patient.name.use|Person.Name.BirthName|
|Patient.gender|Person.Demography.AdministrativeGender|Patient.birthDate|Person.Demography.BirthDate|
|Patient.deceased[x]|Person.Demography.VitalStatus.PatientDeceased/TimeOfDeath|
|Patient.address|Person.Demography.Address|
|Patient.address.country|Person.Demography.Address.Country|
|Patient.address.postalCode|Person.Demography.Address.Postalcode|
|Patient.address.City + Patient.address.extension.City district (for city states) | Person.Demography.Address.PlaceOfResidence. Note: The district is not part of the [VSDM](https://fachportal.gematik.de/downloadcenter/) Gematik's data set. Other sources conforming to §21 KHEntgG may have to be consulted.|
|Patient.address.line|Person.Demography.Address.Street|

The following invariants must be considered when implementing the profile:

**Constraints**:

|pat-de-1|error|The official differentiation of the gender 'other' may only be filled if the gender 'other' is specified|gender='other' or gender.extension('http://fhir.de/StructureDefinition/gender-amtlich-de').empty()|
|-|-|-|-|
|mii-pat-1|error|Either IKNR or MII Core Location Identifier is to be used|$this = 'http://fhir.de/NamingSystem/arge-ik/iknr' or $this = 'https://www.medizininformatik-initiative.de/fhir/core/CodeSystem/core-location-identifier'|
|pat-cnt-2or3-char|warning|The content of the country element (if present) SHALL be selected EITHER from ValueSet ISO Country Alpha-2 http://hl7.org/fhir/ValueSet/iso3166-1-2 OR MAY be selected from ISO Country Alpha-3 Value Set http://hl7.org/fhir/ValueSet/iso3166-1-3, IF the country is not specified in value Set ISO Country Alpha-2 http://hl7.org/fhir/ValueSet/iso3166-1-2.|country.empty() or (country.memberOf('http://hl7.org/fhir/ValueSet/iso3166-1-2') or country.memberOf('http://hl7.org/fhir/ValueSet/iso3166-1-3'))|
|pat-cnt-2or3-char|warning|The content of the country element (if present) SHALL be selected EITHER from ValueSet ISO Country Alpha-2 http://hl7.org/fhir/ValueSet/iso3166-1-2 OR MAY be selected from ISO Country Alpha-3 Value Set http://hl7.org/fhir/ValueSet/iso3166-1-3, IF the country is not specified in value Set ISO Country Alpha-2 http://hl7.org/fhir/ValueSet/iso3166-1-2.|country.empty() or (country.memberOf('http://hl7.org/fhir/ValueSet/iso3166-1-2') or country.memberOf('http://hl7.org/fhir/ValueSet/iso3166-1-3'))|

Further specifications are made by the profiles for the data types HumanName and Address by the German base profiles.

### ResearchSubject ###
This profile describes a subject in the Medical Informatics Initiative.

When including a test person in a study (including in an MII Use Case), a ResearchSubject resource must be created for that subject. The following variants are to be distinguished:
- Inclusion is by specific informed consent for a study.
- Inclusion is based on broad informed consent ("Broad Consent").
- Inclusion is based on a special legal basis (special law such as state hospital law, infection protection law or cancer registry law). This applies equally to the persons in the study group, the control group and any type of reference population for which personal (or person-related) individual data are included in calculations.

The creation of the resource must occur at the time the data is retrieved for the study. Further obligations and adjustments must be checked for each use case.

|FHIR element|Description|
|---|---|
|Patient.id|must-support, but optional|
|Patient.meta|must-support, but optional|
|Patient.identifier:subjectIdentificationCode|Fixed naming system for uniform, cross-site query of the identifier (for evaluations)|
|Patient.period.start|Date of beginning (inclusion of the patient in the study)|
|Patient.period.end|Date of ending (completion of the study or exclusion of the patient)|
|Patient.study|Reference to the metadata of the study in which the patient is participating. For further specifications, see the STUDY DATA extension module.|
|Patient.individual|Each subject must be assigned to a patient.|
|Patient.consent|Consent to the study or regulatory basis must be available. Further specifications for the modeling of consent may arise from other extension modules.|

|FHIR element|Logical dataset|
|---|---|
|ResearchSubject.identifier:subjectIdentificationCode|Person.StudyParticipant.SubjectIdentificationCode|
|ResearchSubject.status|Person.StudyParticipant.StatusOfParticipation|
|ResearchSubject.period.start|Person.StudyParticipant.StartOfParticipation|
|ResearchSubject.period.end|Person.StudyParticipant.EndOfParticipation|
|ResearchSubject.consent|Person.StudyParticipant.LegalBasis|

### Observation ###
Vital status of the patient. It should be noted that a new observation must be created for each observation. All observations are to be classified as final.

A vital status ("Last known time of life") must be created as an observation at least for each admission/discharge of the patient. It should be noted that the administrative discharge of the patient was also documented due to death.

|FHIR element|Description|
|---|---|
|Patient.id|must-support, but optional|
|Patient.meta|must-support, but optional|
|Observation.category|Fixed value, further codings allowed|
|Observation.code|Fixed LOINC code, further codings allowed|
|Observation.subject|Patient reference must always be given.|
|Observation.effectiveDateTime|effectiveDateTime allows exact coding of the last living time, but partial dates are also allowed. Does **not** contain the time of death (see Patient.deceased[x])!|

|FHIR element|Logical dataset|
|---|---|
|ResearchSubject.effectiveDateTime|Person.Demography.VitalStatus.LastLivingDate|
|MII metadata concept (provenance) is unresolved at the time of publication|Person.Demography.VitalStatus.informationSource|

## Terminologies ##
Codesystems
**VitalStatus:**
The VitalStatus code system was developed independently by the Medical Informatics Initiative, as no corresponding LOINC Answer Sets were found. It is based in part on the basic documentation for tumor patients published by the Association of German Tumor Centers.

This code system https://www.medizininformatik-initiative.de/fhir/core/modul-person/CodeSystem/Vitalstatus defines the following codes:

**CodeDisplay**
L: patient is alive
T: patient is dead
A: unknown, lost to follow-up
N: unknown, care/ aftercare no longer necessary
B: unknown, patient is in care elsewhere
V: unknown, patient refuses further care
X: unknown