IHE Germany - Value Sets for XDS
0.3.30 - draft
IHE Germany - Value Sets for XDS
0.3.30 - draft
IHE Germany - Value Sets for XDS, published by IHE Deutschland e.V., Berlin, Deutschland. This guide is not an authorized publication; it is the continuous build for version 0.3.30 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE-Germany/ITI.XDS.VS/ and changes regularly. See the Directory of published versions
| Official URL: http://ihe-d.de/ValueSets/IHEXDSeventCodeList | Version: 4.0.0-alpha1 | |||
| Draft as of 2025-10-17 | Maturity Level: 2 | Computable Name: IHEXDSeventCodeList | ||
| Other Identifiers: urn:ietf:rfc:3986#Uniform Resource Identifier (URI)#http://ihe-d.de/ValueSets/IHEXDSeventCodeList (use: official, ), OID:1.2.276.0.76.11.34 (use: secondary, ), urn:ietf:rfc:3986#Uniform Resource Identifier (URI)#http://www.ihe-d.de/fhir/ValueSet/IHEXDSeventCodeList (use: old, ) | ||||
Copyright/Legal: CC-BY-4.0 |
||||
IHE XDS event Code List
References
Die eventCode Liste wurde konzipiert, um den medizinischen Kontext von Dokumenten abzubilden. Jedem Dokument können beliebig viele eventCodes zugeordnet werden. Zum Beispiel kann ein OP-Bericht über die eventCodeList mit je einem kodierten Wert für die durchgeführte Prozedur (z.B. Blinddarmentfernung) und die vorliegende Erkrankung (z.B. Appendizitis) versehen werden. Dies ermöglicht die Suche nach Dokumenten, die mit einer bestimmten Prozedur oder Diagnose zusammenhängen. Über den medizinischen Kontext hinaus kann das Attribut auch allgemein zur Kontextualisierung und zur Inhaltszusammenfassung verwendet werden. Zum Beispiel sieht das IHE BPPC Profil die Nutzung des eventCodes vor, um die Policy ID eines Patienteneinwilligungsdokuments abzubilden. IHE XDW wiederum nutzt den eventCode, um offene von abgeschlossenen Workflow-Aufgaben zu unterscheiden.
Das von der Arbeitsgruppe definierte ValueSet umfasst sowohl von IHE International vergebene eventCodes (u.a. aus XDS-I, DSG) als auch neue von der AG definierte Code Systeme, sowie Empfehlungen zur Einbindung von größeren Katalogen.
Der medizinische Kontext lässt sich gemäß obiger einführender Beschreibung zum Beispiel über einen oder mehrere OPS Codes und/oder ICD-10 Codes ausdrücken. Wenn andere Kataloge für ein bestimmtes Anwendungsgebiet sinnvoller sind (z.B. ORPHA-Nummern bei seltenen Erkrankungen oder ICD-O-3 bei Tumorerkrankungen), kann die Affinity Domain natürlich auch diese in der eventCodeList verwenden. Ob allerdings der medizinische Kontext überhaupt in dieser Granularität in den Metadaten abgebildet werden soll, ist abhängig von den Anwendungsfällen und muss projektspezifisch entschieden werden.
Sowohl der OPS Katalog als auch der ICD-10-GM Katalog werden jedes Jahr mit einer neuen Code System ID veröffentlicht. Um in dieser Spezifikation nicht eine jahresspezifische Version zu referenzieren, wird das Value Set diesbezüglich intensional definiert. Somit empfiehlt die Arbeitsgruppe neben den weiter unten ausdrücklich benannten Codes auch die jeweils aktuelle ICD-10-GM und OPS Versionen als Bestandteil des Value Sets zu implementieren.
Wie oben bereits erwähnt, hat die Arbeitsgruppe zwei neue Codesysteme erstellt, die auch Bestandteile dieses Value Sets sind:
Das erste Codesystem (1.3.6.1.4.1.19376.3.276.1.5.15 - Dokumenten-Warnhinweise) umfasst Warnhinweise, die einem Dokument hinzugefügt werden können. D azu gehört beispielsweise der Hinweis, dass dies ein vorläufiges Dokument ist (z.B. vorläufiger Arztbrief). Der Begriff vorläufig ist dabei unabhängig vom Dokumenten-Status/Lebenszyklus, der in XDS im availabilityStatus abgebildet wird. Ein weiterer Warnhinweis ist, dass das Dokument noch nicht mit dem Patienten besprochen wurde. Letzteres ist vor allem bei Akten sinnvoll, auf die auch der Patient Zugriff hat.
Das zweite Codesystem (1.3.6.1.4.1.19376.3.276.1.5.16 - Fallkontext bei Dokumentenerstellung) umfasst den Fallkontext, in dem das Dokument erstellt wurde. Dazu gehört beispielsweise, ob das Dokument in einem ambulanten, stationären oder telemedizinischen Kontext erstellt wurde. Das Codesystem ist hierarchisch gegliedert, so dass die Abbildung auf einen entsprechenden eventCode je nach vorliegender Information bzw. je nach auslösendem Ereignis der Dokumenterstellung in verschiedenen Detaillierungsgraden erfolgen kann (z.B. "stationärer Aufenthalt" vs. "Verlegung in ein anderes Krankenhaus"). Die Arbeitsgruppe hat sich zur Bildung des Codesystems für den Fallkontext an den bestehenden Schlüsseltabellen zur Abbildung von - im weitesten Sinne - "ADT-Ereignissen" orientiert, die in Anlage 2 zur Vereinbarung nach 301 Abs. 3 SGB V ("GKV-Datenaustausch") definiert sind (Schlüssel 1 Aufnahmegrund, Schlüssel 5 Entlassungs-/Verlegungsgrund). Hierbei wurden vorhandene Differenzierungen, die allein für spezifische Belange des Entgeltsystems von Bedeutung sind, nicht in das Value Set übertragen; es ist jedoch für jeden relevanten 301 Abs. 3 SGB V ("GKV-Datenaustausch") definiert sind (Schlüssel 1 Aufnahmegrund, Schlüssel 5 Entlassungs-/Verlegungsgrund). Hierbei wurden vorhandene Differenzierungen, die allein für spezifische Belange des Entgeltsystems von Bedeutung sind, nicht in das Value Set übertragen; es ist jedoch für jeden relevanten
| Code System Name | Code System ID | Kommentar |
|---|---|---|
| Internationale statistische Klassifikation der Krankheiten und verwandter Gesundheitsprobleme (ICD-10) | versionsabhängig | z.B. ICD-10 GM 2018 mit Code System ID 1.2.276.0.76.5.471 |
| Operationen- und Prozedurenschlüssel (OPS) | Versionsabhängig | z.B. OPS Version 2018 mit Code System ID 1.2.276.0.76.5.472 |
| Digital Signature Purposes from ASTM E1762-95(2013) | 1.2.840.10065.1.12 | aus IHE DSG |
| IHE Format Codes | 1.3.6.1.4.1.19376.1.2.3 | IHE XDW eventCodes werden von IHE International ausnahmsweise mit der OID für das IHE formatCode Code System geführt; siehe unten für die Liste der Codes die Teil des Value Sets sind |
| DICOM Acquisition Modality | 1.2.840.10008.6.1.19 | aus IHE XDS-I |
| DICOM Anatomic Region | 1.2.840.10008.6.1.2 | aus IHE XDS-I |
| IHE Deutschland Dokumenten-Warnhinweise | 1.3.6.1.4.1.19376.3.276.1.5.15 | Das vollständige Code System findet sich weiter unten |
| IHE Deutschland Fallkontext bei Dokumentenerstellung | 1.3.6.1.4.1.19376.3.276.1.5.16 | Das vollständige Code System findet sich weiter unten |
| KDL | versionsabhängig | Alle Codes des Valuesets 1.2.276.0.76.11.469 |
| KBV DMP | versionsabhängig | Alle Codes des Codesystems 1.2.276.0.76.5.223 |
This value set includes codes based on the following rules:
http://ihe-d.de/CodeSystems/DokumentenWarnhinweise version 📦4.0.0-alpha1http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung version 📦4.0.0-alpha1urn:iso-astm:E1762-95:2013 version 📦4.0.1http://ihe-d.de/CodeSystems/DeutscheDokumentenformate version 📦4.0.0-alpha1
| Code | Display |
| urn:ihe:iti:xdw:2011:eventCode:open | Workflow offen |
| urn:ihe:iti:xdw:2011:eventCode:closed | Workflow geschlossen |
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP version 📦1.06
Expansion performed internally based on:
This value set contains 91 concepts
| System | Code | Display (de) | Definition | JSON | XML |
http://ihe-d.de/CodeSystems/DokumentenWarnhinweise | H1 | Dokumente, die der Patient zu seinem Arzt oder in die Klinik mitgebracht hat und die dort vom Leistungserbringer eingescannt (bei Papierdokumenten) bzw. importiert und in die Akte eingestellt wurden. Bei vom Patienten direkt in die Akte eingestellten Dokumenten wird stattdessen das Konzept H5 verwendet. Die Dokumente können von Medizinern und anderen Leistungserbringern, von anderen Autoren wie z.B. Behörden/Krankenkassen/Schulen oder vom Patienten selbst erstellt worden sein. | |||
http://ihe-d.de/CodeSystems/DokumentenWarnhinweise | H2 | Der Hinweis gibt Auskunft darüber, ob das Dokument zum Zeitpunkt des Einstellens bereits mit dem Patienten besprochen wurde. Dies kann genutzt werden um zu verhindern, dass der Patient sensible Informationen, wie die Diagnose einer unheilbaren Krankheit, aus einem Dokument anstatt von seinem Arzt erfährt. Dabei liegt der Fokus auf der Frage, ob das Dokument noch mit dem Patienten besprochen werden muss und nicht wer es noch mit dem Patienten besprechen muss. Somit können auch einrichtungsübergreifende Szenarien unterstützt werden, z.B. wenn die Besprechung des Befundes nicht in der Hand des Erzeugers liegt. | |||
http://ihe-d.de/CodeSystems/DokumentenWarnhinweise | H3 | Der Hinweis zeigt an, dass es sich eventuell um veraltete Daten handelt. Dieses Kennzeichen wird üblicherweise nachträglich zu schon registrierten Dokumenten hinzugefügt. Im Gegensatz zum availabilityStatus "Deprecated" ist es unklar ob das Dokument wirklich veraltet ist oder nicht. Daher handelt es sich hier nur um einen Hinweis für den Empfänger, der üblicherweise keine automatischen Auswirkungen auf Berechtigungen, Speicherfristen, etc. hat. | |||
http://ihe-d.de/CodeSystems/DokumentenWarnhinweise | H4 | Der Hinweis zeigt an, dass es sich um ein vorläufiges Dokument handelt. IHE XDS sieht hierfür keinen eigenen Wert im availabilityStatus Attribut vor, daher wird dieses Konzept ausschließlich über diesen eventCode kommuniziert. | |||
http://ihe-d.de/CodeSystems/DokumentenWarnhinweise | H5 | Dokumente, die der Patient (oder ein Stellvertreter) direkt eingestellt hat, z.B. über ein Patientenportal. Dokumente die physisch vor Ort an den Leistungserbringer übergeben wurden, werden stattdessen mit dem Konzept H1 gekennzeichnet. Die Dokumente können von Medizinern und anderen Leistungserbringern, von anderen Autoren wie z.B. Behörden/Krankenkassen/Schulen oder vom Patienten selbst erstellt worden sein. | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E100 | Ambulanter Kontakt in beliebiger Einrichtung mit Teilnahme an der ambulanten Versorgung | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E110 | Ambulant durchgeführte OP in beliebiger Einrichtung mit ambulant operativer Versorgung | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E200 | Voll-, teil- oder nachstationäre Behandlung in einer Einrichtung mit Teilnahme an der stationären Versorgung | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E210 | Aufnahme zur voll-, teil- oder nachstationären Behandlung in eine Einrichtung mit Teilnahme an der stationären Versorgung | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E211 | Aufnahme in vollstationäre Krankenhausbehandlung; einschließlich vollstationäre Behandlung mit vorausgegangener vorstationärer Behandlung | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E212 | Aufnahme/Wiederaufnahme in teilstationäre Krankenhausbehandlung: Kontakt im Rahmen einer teilstationären Behandlung; einschließlich Tagesklinik | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E213 | Aufnahme zur stationären Entbindung | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E214 | Aufnahme eines Neugeborenen bei stationärer Entbindung | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E215 | Stationäre Aufnahme zur Organentnahme | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E216 | ||||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E230 | Entlassung nach voll-, teil- oder nachstationärer Behandlung aus einer Einrichtung mit Teilnahme an der stationären Versorgung | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E231 | Entlassung aus stationärem Aufenthalt nach Hause: Routineentlassung (Behandlung regulär beendet); Behandlung gegen ärztlichen Rat beendet; Behandlung aus sonstigen Gründen beendet. Einschließlich Entlassung mit geplanter ambulanter Weiterbehandlung. Einschließlich Entlassung in organisierte häusliche Pflege | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E232 | Entlassung aus stationärem Aufenthalt in eine Rehabilitationseinrichtung | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E233 | Entlassung aus stationärem Aufenthalt in eine Pflegeeinrichtung oder ein Hospiz | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E234 | Entlassung aus stationärem Aufenthalt, nachstationäre Behandlung vorgesehen: Behandlung regulär oder gegen ärztlichen Rat beendet mit geplanter nachstationärer Behandlung | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E235 | Patient während stationärem Aufenthalt verstorben | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E250 | Verlegung im Verlauf oder bei Abschluss eines stationären Aufenthaltes | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E251 | Verlegung innerhalb einer stationären Einrichtung ("interne stationäre Verlegung") | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E252 | Verlegung in ein anderes Krankenhaus ("externe stationäre Verlegung") | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E253 | Verlegung zur psychiatrischen Behandlung in eine andere Einrichtung | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E270 | Entlassung mit geplanter nachfolgender stationärer Wiederaufnahme in derselben Einrichtung, z.B. Unterbrechung gegen ärztlichen Rat | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E280 | Konsiliarische Mitbehandlung im Verlauf eines stationären Aufenthaltes oder im ambulanten Kontext, ohne Verlegung | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E300 | Behandlung/ Monitoring im häuslichen Umfeld | |||
http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung | E400 | Behandlung/ Monitoring über virtuellen Patientenkontakt z.B. telemedizinischer Patientenkontakt | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.1 | the signature of the primary or sole author of a health information document. There can be only one primary author of a health information document. | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.2 | the signature of a health information document coauthor. There can be multiple coauthors of a health information document. | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.3 | the signature of an individual who is a participant in the health information document but is not an author or coauthor. (Example a surgeon who is required by institutional, regulatory, or legal rules to sign an operative report, but who was not involved in the authorship of that report.) | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.4 | the signature of an individual who has transcribed a dictated document or recorded written text into a digital machine readable format. | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.5 | a signature verifying the information contained in a document. (Example a physician is required to countersign a verbal order that has previously been recorded in the medical record by a registered nurse who has carried out the verbal order.) | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.6 | a signature validating a health information document for inclusion in the patient record. (Example a medical student or resident is credentialed to perform history or physical examinations and to write progress notes. The attending physician signs the history and physical examination to validate the entry for inclusion in the patient's medical record.) | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.7 | the signature of an individual consenting to what is described in a health information document. | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.8 | the signature of a witness to any other signature. | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.9 | the signature of a witness to an event. (Example the witness has observed a procedure and is attesting to this fact.) | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.10 | the signature of an individual who has witnessed another individual who is known to them signing a document. (Example the identity witness is a notary public.) | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.11 | the signature of an individual who has witnessed the health care provider counselling a patient. | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.12 | the signature of an individual who has translated health care information during an event or the obtaining of consent to a treatment. | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.13 | the signature of a person, device, or algorithm that has reviewed or filtered data for inclusion into the patient record. ( Examples: (1) a medical records clerk who scans a document for inclusion in the medical record, enters header information, or catalogues and classifies the data, or a combination thereof; (2) a gateway that receives data from another computer system and interprets that data or changes its format, or both, before entering it into the patient record.) | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.14 | the signature of an automated data source. (Examples: (1) the signature for an image that is generated by a device for inclusion in the patient record; (2) the signature for an ECG derived by an ECG system for inclusion in the patient record; (3) the data from a biomedical monitoring device or system that is for inclusion in the patient record.) | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.15 | the signature on a new amended document of an individual who has corrected, edited, or amended an original health information document. An addendum signature can either be a signature type or a signature sub-type (see 8.1). Any document with an addendum signature shall have a companion document that is the original document with its original, unaltered content, and original signatures. The original document shall be referenced via an attribute in the new document, which contains, for example, the digest of the old document. Whether the original, unaltered, document is always displayed with the addended document is a local matter, but the original, unaltered, document must remain as part of the patient record and be retrievable on demand. | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.16 | the signature on an original document of an individual who has generated a new amended document. This (original) document shall reference the new document via an additional signature purpose. This is the inverse of an addendum signature and provides a pointer from the original to the amended document. | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.17 | the signature of an individual who is certifying that the document is invalidated by an error(s), or is placed in the wrong chart. An administrative (error/edit) signature must include an addendum to the document and therefore shall have an addendum signature sub-type (see 8.1). This signature is reserved for the highest health information system administrative classification, since it is a statement that the entire document is invalidated by the error and that the document should no longer be used for patient care, although for legal reasons the document must remain part of the permanent patient record. | |||
urn:iso-astm:E1762-95:2013 | 1.2.840.10065.1.12.1.18 | the signature by an entity or device trusted to provide accurate timestamps. This timestamp might be provided, for example, in the signature time attribute. | |||
http://ihe-d.de/CodeSystems/DeutscheDokumentenformate | urn:ihe:iti:xdw:2011:eventCode:open | ||||
http://ihe-d.de/CodeSystems/DeutscheDokumentenformate | urn:ihe:iti:xdw:2011:eventCode:closed | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 00 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 01 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 02 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 03 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 04 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 05 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 06 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 07 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 08 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 09 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 10 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 11 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 12 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 30 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 31 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 32 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 33 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 34 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 35 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 36 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 37 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 38 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 39 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 40 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 41 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 42 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 43 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 44 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 45 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 46 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 47 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 48 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 49 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 50 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 51 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 52 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 53 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 54 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 55 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 56 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 57 | ||||
https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_DMP | 58 |
Explanation of the columns that may appear on this page:
| Level | A few code lists that FHIR defines are hierarchical - each code is assigned a level. In this scheme, some codes are under other codes, and imply that the code they are under also applies |
| System | The source of the definition of the code (when the value set draws in codes defined elsewhere) |
| Code | The code (used as the code in the resource instance) |
| Display | The display (used in the display element of a Coding). If there is no display, implementers should not simply display the code, but map the concept into their application |
| Definition | An explanation of the meaning of the concept |
| Comments | Additional notes about how to use the code |