# Modul PROCEDURE
## Core Dataset Module Procedure ##
| Note | Under construction!|
|---|---|
||This Implementation Guide represents the current working version of the module 'Procedure'. 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_Prozeduren/IGMIIKDSModulProzedur.html).|
The present specification describes the FHIR representation of the core data set module ‘Procedure’ 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|09.04.2021|
|Version|1.0.6|
|Status| Active|
|Realm| DE|
**Table of content**
- IG MII CDS module Procedure
- 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
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)
Ant-je 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.
### Disclaimer
* The content of this document is public. Please note 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 greatest care, the authors cannot accept any liability for direct or indirect damage that might arise from the content of this specification.
## Description of the module
### Introduction
The basic PROCEDURE module contains data elements for the documentation of operations, interventions and other medical procedures as well as selected drug therapies.
The module is used to record the details of current and historical interventions. A procedure is an activity that is performed on, with or for a patient as part of the care.
*Examples include surgical procedures, diagnostic procedures, obstetric assistance, endoscopic procedures, biopsies, counseling, physical therapy, personal support services, adult day care services, non-emergency transportation, home modifications, exercises, etc.*
The procedures can be performed by a healthcare professional, a service provider, a friend or relative, or in some cases, the patient himself / herself.
For historical and billing reasons (additional fees), selected expensive drugs are also counted as an independent procedure in Germany.
### Mapping of the PROCEDURE module in ART-DECOR
The module provides the following features of a procedure that are required for the automated processing of the procedure information:
[](https://art-decor.org/art-decor/decor-datasets--mide-?id=&effectiveDate=&conceptId=&conceptEffectiveDate=)
A procedure is "an action that is or has been performed on or for a patient. This can be a physical procedure such as an operation, or less invasive such as long-term services, counseling or hypnotherapy." (See http://hl7.org/fhir/procedure.html)
Information on the procedure can range from the mere recording of a procedure code for a treatment case to detailed, structured OR documentation with the main procedure and secondary procedures including anesthesia and positioning care with individual recording of the operation date, total operation time, anesthesia time, incision-suture time , Surgeons, anesthetists, OR nurses, medications and more.
In this implementation guide for the PROZEDUR module in the initial version of the MII core data set, we focus on the basic requirements for the use cases of the MI initiative. We essentially limit ourselves to the basic features of procedure and date. A free text description and part of the body can be added. We deliberately leave room for the later design of the module.
### 1. Focused basic information on the procedure
As announced in the introduction, the information in the PROCEDURE module focuses on the essential features as required in the MII use cases. A description of these use cases can be found below in the section "Description of scenarios for the application of the PROCEDURE module".
First of all, the procedure itself and an associated execution date should be mentioned here. Operations carried out should be clearly represented by a triple made up of a procedure code, the associated catalog and the catalog text. A free text description and the specification of a page localization can be implicit.
As a rule, DIMDI uses the proprietary German OPS catalogs for coding procedures in the source systems of the university hospitals involved. As a milestone for the further development of the documentation, we have added the detailed nomenclature SNOMED CT as a permitted code system (as in the DIAGNOSIS module).
#### Free text description
If available in the source documentation, the information model of the MII core data set allows these to be saved and presented. The OPS catalog and / or SNOMED CT can be used for the additional coding.
[](https://art-decor.org/art-decor/decor-datasets--mide-?id=&effectiveDate=&conceptId=&conceptEffectiveDate=#)
The leading classification and nomenclature for operations and other procedures (interventions, treatments, examinations) in Germany is the DIMDI Operation and Procedure Code (Operationen- und Prozedurenschlüssel- OPS). The OPS is an interdisciplinary, monohierarchically structured, alphanumeric classification for operations and procedures with up to 6 hierarchical levels. The current version of the OPS system contains six chapters (1, 3, 5, 6, 8 and 9), which cover the area of all encodable medical measures.
For historical reasons (reference to the ICPM) there are gaps in the chapter numbers; Also, not all four-digit key numbers within the chapters are assigned, the free spaces allow extensions.
Chapter 5 Operations is structured topographically and anatomically, so interventions can be found under the respective organ chapter. The remaining chapters are structured according to the procedures.
| Chapter No | Code area | Class title |
| -------- | -------- | -------- |
| 1 | 1-00... 1-99 | Diagnostic measures |
| 3 | 3-03... 3-99 | Imaging diagnostics |
| 5 | 5-01... 5-99 | Operations |
| 6 | 6-00... 6-00 | Medicaments |
| 8 | 8-01... 8-99 | Non-surgical therapeutic measures |
| 9 | 9-20... 9-99 | Complementary measures |
For general coding, the "[Instructions for use](https://www.dimdi.de/static/de/klassifikationen/ops/kode-suche/opshtml2020/zusatz-04-hinweise-zur-benutzung.htm)" must be observed. When coding for billing purposes in the inpatient area, the application of the [German coding guidelines (DKR and DKR-Psych) of the self-administration partner](https://www.g-drg.de/aG-DRG-System_2020/Kodierrichtlinien/Deutsche_Kodierrichtlinien_2020) is required.
#### Complete procedure code
As with other codes, it is not sufficient to specify a code for the unambiguous documentation of a procedure. The complete procedure code is a triple which combines the OPS code, the corresponding code system (= OPS catalog with year of validity) and the catalog text of the procedure code.
#### Side localization
Since the OPS does not contain any pre-coordinated page information, this is usually documented separately with the values [right, left, both sides], which must be taken into account in the data sinks with the information model of the MII core data set.
#### Coded SNOMED procedure
[](https://art-decor.org/art-decor/decor-datasets--mide-?id=&effectiveDate=&conceptId=&conceptEffectiveDate=)
The inclusion of the nomenclature SNOMED CT in the canon of code systems for diagnoses, procedures and other medical entities follows the decision of the National Steering Committee of the MII, the support of the BMBF and the goals of the BMG, which are presented in the [draft bill for the Patient Data Protection Act](https://www.bundesgesundheitsministerium.de/fileadmin/Dateien/3_Downloads/Gesetze_und_Verordnungen/GuV/P/Referentenentwurf_Patientendaten-Schutzgesetz__PDSG.pdf). At the time of the publication of this ImplementationGuide, SNOMED CT is hardly used in Germany. The inclusion in the canon of the code systems is more of a milestone for an internationally interoperable and better multi-usable documentation, which is to be achieved soon.
#### Complete procedure code
As with other code systems, complete composition is also expected with SNOMED CT, although the SNOMED CT code in itself is already unique. The complete procedure code is a triple which combines the SNOMED CT code, the code system SNOMED CT, in which, due to its stability, no time and place information is required, and the preferred name of the code, as the catalog text is called here.
Due to the precoordination of the page number in the multiaxial SNOMED CT code, a separate feature page localization is not required. However, a separate transfer of the information about the body part (left shoulder blade, terminal phalanx of the right index finger, ticus pedal valve) is possible and useful if it is available in documentation.
#### Body part
The body part can be used to indicate in which area of the body a procedure was carried out (topographical information). The part of the body was deliberately coded out of the SNOMED procedure, so that it is also possible to code the part of the body when it is coded using the OPS code. The body location is then specified using SNOMED CT, but does not require a complete SNOMED-CT procedure code.
### 2. Complementary aspects
#### **Temporal allocation**
#### Implementation date
The initial design of the PROCEDURE module limits the time allocation to the point in time at which a procedure was carried out or started.
#### Documentation date
Operations and other procedures are increasingly being documented alongside the procedure. The separate specification of a documentation date allows deviations from this to be recorded.
## Context in the overall project/references to other modules
Diagnostic, therapeutic and other procedures represent a core process of routine care and take place at all locations of the Medical Informatics Initiative.
The most detailed and usually digital documentation of operations and procedures is carried out at all locations in the central OR areas. Documentation is regularly carried out in accordance with local requirements in a large number of separate OR and anesthesia systems.
The information on the DRG-relevant measures in the OPS table of the data set in accordance with § 301 SGB V are nationwide, uniformly available for all inpatient and partially inpatient cases from all German hospitals, including the university clinics involved in the Medical Informatics Initiative
In the future, procedural information is of great importance for a large number of questions, e.g. in effectiveness studies and health economic analyzes. However, since there are no requirements from the use cases of the Medical Informatics Initiative that go beyond OPS recording, the adaptation of the MII-CDS is essentially limited to FHIR profiling and internationalization by adding SNOMED CT as a permitted code system.
### References to other modules
Similar to the DIAGNOSTICS module, the PROCEDURE module in the MII core data set is primarily linked to the PERSON module. Apart from the fact that almost all procedures per se require a service provider, practically all procedure information naturally come from service providers where the persons examined or treated procedurally are patients and cases. This is expressed by a care case-procedure relation, which is not shown in the ART-Decor model, but which is implemented in the FHIR profile.
It should be noted that the [Medication module](https://simplifier.net/guide/MedizininformatikInitiative-ModulMedikation-ImplementationGuide/KontextimGesamtprojektBezgezuanderenModulen) as well as the [Case module](https://simplifier.net/guide/MedizininformatikInitiative-ModulFall-ImplementationGuide/KontextimGesamtprojektBezgezuanderenModulen) have references to this module. Explanations can be found in the respective module.
### Deferred relationships with other modules
* DIAGNOSIS module
As a rule, procedures are only carried out if justified by a diagnosis. In the initial MII core data set, as in the data set according to § 21 KHEntgG, the assignment of procedures to diagnoses is dispensed. 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.
## References
The modeling of the data record for the PROCEDURE module contains references to the following projects:
* § 21 data set according to KHEntgG, for the purpose of backward compatibility
* FHIR profile Procecure-uv-ips of the [IPS](https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Procedure-uv-ips.html) (International Patient Summary), perspective for the purpose of forward compatibility.
The [core specification of HL7 FHIR](http://hl7.org/fhir/), including the corresponding resource [procedure](https://www.hl7.org/fhir/procedure.html), and the previous work on the German basic profiles in FHIR version [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 dated 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-).
On the one hand, for the classifications and terminology, the German "Operations and Procedures Code" from DIMDI is used. On the other hand, the introduction of the procedural part of SNOMED CT is anticipated.
## Use cases/information model
### Description of scenarios for the application of the PROCEDURE module
The modeling and FHIR profiling of the basic modules of the MII core data set, including the PROCEDURE 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](https://www.medizininformatik-initiative.de/en/start) (MII) [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 stored (or to be stored) 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.
Regarding the PROCEDURE module: Procedures do not yet play a central role in the current use cases of the Medical Informatics Initiative. That is why the design of the PROCEDURE module was very cautious and left a lot of leeway for subsequent elaborations.
The individual scenarios of the consortia:
* DIFUTURE: In the current use cases of the DIFUTURE consortium, operations and other procedures do not play a role in modeling.
* HiGHmed: In the current uses cases of the HiGHmed consortium, operations and other procedures do not play a role in modeling.
* MIRACUM: In Use Case 1 "IT support for patient recruitment", procedures are included as an inclusion or exclusion criterion in the automated selection of potential study candidates.
* SMITH: Selected procedures are referenced in the HELP use case. The simple representation without assignment to department case, specialist department and care location is sufficient.
* POLAR-MI: In the comprehensive joint project POLAR-MI, all available information on medications is required. The medications represented by procedure codes are also used, which are noted redundantly to the MEDICATION module in the PROCEDURE module.
* CORD-MI: In the comprehensive joint project CORD-MI, deliveries (especially OPS code 9-260) of women with a rare disease (cystic fibrosis or phenylketonuria) play a role. No special adjustment was necessary.
### Datasets including descriptions
The official and approved version of the information model for the PROCEDURE module can be found on ArtDecor. To standardize the representation, the information model was also mapped as a FHIR Logical Model:
(**INSERT SNIP**)
It should be noted that the logical model aims purely at mapping 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. For each element within the logical model there is a 1: 1 mapping to an element of a specific FHIR resource.
| Logical data set | Description |
| -------- | -------- |
| Procedure | The basic module procedures includes the description of diagnostic or therapeutic measures, which are documented and coded as service complexes for billing, e.g. operations. |
| Procedure.OPSProcedureCoded | Coding of the performed procedure using OPS
| Procedure.OPSProcedureCoded.ProcedureCode | The complete procedure code: triplet of OPS code, code system (including version!) and catalog text | Text |
| Procedure.OPSProcedureCoded.SideLocalization | Side, location and location localization for the procedure carried out |
| Procedure.SNOMEDProcedureCoded | Coding of the procedure carried out using SNOMED CT |
| Procedure.SNOMEDProcedureCoded.CompleteProcedureCode | The complete procedure code: Triple of SNOMED-CT code, code system (version optional) and preferred name |
| Procedure.BodySide | Body side of the procedure using SNOMED CT including laterality (R, L, B) |
| Procedure.ImplementationIntention | Intention with which the procedure is carried out. |
| Procedure.ImplementationDate | The date is the timepoint at which a procedure was performed. |
| Procedure.DocumentationDate | The date is the timepoint at which a procedure was documented. |
| Procedure.FreeTextDescription | Free text description of the procedure carried out |
### 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 association relationships with one another. Characteristics of the person and the case are highlighted in color from the other characteristics of the procedure.
(**INSERT DIAGRAM**)
## Technical implementation
### FHIR-Profile
The work of the core dataset specifications is based, where possible, on international standards and terminology. The [International Patient Summary](https://international-patient-summary.net/?title=Main_Page) should be emphasized here in particular. An adaptation to the general conditions of the German health care system takes place through the use of the [German basic profiles](https://simplifier.net/guide/basisprofil-de-r4/home) 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 text form below the profile.
| Note | Mandatory / must-support elements |
| -------- | -------- |
|  | For elements that are mandatory or marked 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. |
#### Procedure
This profile describes a procedure in the medical informatics initiative.
Name: ProfileProcedureProzedur ([Simplifier Link](https://simplifier.net/MedizininformatikInitiative-ModulProzeduren/Prozedur/~overview))
Canonical: https://www.medizininformatik-initiative.de/fhir/core/modul-prozedur/StructureDefinition/Procedure
Differential
(**INSERT SNAP**)
| FHIR-Element | Explanation |
| -------- | -------- |
| Procedure.id | Must support, but optional |
| Procedure.meta | Must support, but optional |
| Procedure.status | No restrictions on the chosen status |
| Procedure.category | Mandatory SNOMED CT categorization based on the procedure code. See [Terminologies](https://simplifier.net/guide/MedizininformatikInitiative-ModulProzeduren-ImplementationGuide/Terminologien) for Mapping OPS Class Titles to SNOMED CT. Only relevant if the procedure is coded via OPS, see proc-mii-1 |
| Procedure.code | Mandatory coding either via OPS or SNOMED. Further coding allowed. |
| Procedure.code:ops | See [OPS coding - German basic profiles](https://simplifier.net/guide/basisprofil-de-r4/Ressourcen-Procedure-OPS) |
| Procedure.performed[x] | In addition to specifying a dateTime, a period can also be specified (if the start and end times are known) |
| Procedure.bodySide | Detailed coding of the body part(s) of the procedure. Should NOT be used to depict the laterality of the procedure. This is a property of the code. See Procedure.code: ops |
| Procedure.note | Free text information on the procedure |
| FHIR Element | Logical data set |
| -------- | -------- |
| Procedure.code:ops | Procedure.OPSProcedureCoded |
| Procedure.code:ops.coding.code | Procedure.OPSProcedureCoded.CompleteProcedureCode (Code) |
| Procedure.code:ops.coding.system | Procedure.OPSProcedureCoded.CompleteProcedureCode (code system) |
| Procedure.code:ops.coding.version | Procedure.OPSProcedureCoded.CompleteProcedureCode (Version) |
| Procedure.code:ops.extension.seitenlokalisation | Procedure.OPSProcedureCoded.SideLocation |
| Procedure.code:sct | Procedure.SNOMEDProcedureCoded |
| Procedure.code:sct.code | Procedure.SNOMEDProcedureCoded.CompleteProcedureCode (Code) |
| Procedure.code:sct.system | Procedure.SNOMEDProcedureCoded.CompleteProcedureCode (CodeSystem) |
| Procedure.bodySide | Procedure.BodySide |
| Procedure.performed[x] | Procedure.ExecutionDate |
| Procedure.note | Procedure.FreeTextDescription |
| Procedure.extension.recordedDate | Procedure.DocumentationDate |
| Procedure.extension.durchfuehrungsabsicht | Procedure.ImplementationIntention |
The following invariants must be taken into account when implementing the profile:
Constraints:
| proc-mii-1 | error | If the procedure is coded via OPS, a SNOMED-CT coded category must be mapped |code.coding.where(system = 'http://fhir.de/CodeSystem/dimdi/ops').exists() implies category.coding.where(system = 'http://snomed.info/sct').exists()|
| -------- | -------- | -------- |--------|
| **sct-ops-1** | **error** | **The procedure is either coded with OPS or SNOMED-CT.** |**coding.where(system = 'http://snomed.info/sct').exists() or coding.where(system = 'http://fhir.de/CodeSystem/dimdi/ops').exists()**|
(**INSERT SNAP**)
#### Examples
Example (minimal)
```
{
"resourceType": "Procedure",
"id": "ExampleProcedure",
"meta": {
"profile": [
"https://www.medizininformatik-initiative.de/fhir/core/modul-prozedur/StructureDefinition/Procedure"
]
},
"status": "completed",
"category": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "387713003",
"display": "Surgical procedure (procedure)"
}
]
},
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "80146002",
"display": "Excision of appendix (procedure)"
},
{
"system": "http://fhir.de/CodeSystem/dimdi/ops",
"version": "2020",
"code": "5-470",
"display": "Appendektomie"
}
]
},
"performedDateTime": "2020-04-23",
"subject": {
"identifier": {
"system": "http://mii-standort.example.de/fhir/NamingSystem/pid",
"value": "1234567890",
"assigner": {
"identifier": {
"system": "https://www.medizininformatik-initiative.de/fhir/core/NamingSystem/DIZ",
"value": "UKK"
}
}
}
}
}
```
### Terminologies
| Note | |
| -------- | -------- |
|  | In addition to international terminology, the PROCEDURE module defines the following ConceptMaps, ValueSets and CodeSystems. It should be noted that all CodeSystems also contain an implicit ValueSet, which can be found in the respective FHIR CodeSystem resource. |
#### ConceptMaps
The following ConceptMap is a mapping of the OPS class titles on SNOMED CT. It should be noted that SNOMED CT itself does not offer any "residual classes", so that matching SNOMED CT codes can be used instead of "Other" if these are available for "additional measures". Furthermore, the OPS code for class 6 does not refer to the administration of medication but to the medication itself as an independent concept.
Mapping from http://fhir.de/ValueSet/dimdi/ops to SNOMED_CT
| Source | Equivalence Destination |
| -------- | -------- |
| (Diagnostic measures) | equivalent [103693007]() (Diagnostic procedure) |
| Imaging diagnostics | equivalent [363679005]() (Imaging) |
| Operations | equivalent [387713003]() (Surgical procedure) |
| Medicines | relatedto [18629005]() (Administration of medicine) |
| Non-operative therapeutic measures | equivalent [277132007]() (Therapeutic procedure) |
| Complementary measures | relatedto [394841004]() (Other category) |
#### ValueSets
Please note that the following ValueSets do not contain any expansion. For use for validation purposes, this must be created via the FHIR terminology server.
Canonical: https://www.medizininformatik-initiative.de/fhir/core/modul-diagnose/ValueSet/Lebensphase
The ValueSet 'procedures-sct' contains all codes which may be used for Procedure.code: sct.
**ValueSet 'ValueSetSNOMEDProcedureCodes'**
| Version | 1.0 |
| -------- | -------- |
| Published by | https://www.medizininformatik-initiative.de |
| Status | Active (since 2020-04-22) |
| Experimental | False |
Contains all SNOMED procedure codes
This value set includes codes from the following code systems:
* Include codes from SNOMED_CT where concept DescendentOf 71388002
Canonical: https://www.medizininformatik-initiative.de/fhir/core/modul-prozedur/ValueSet/procedures-intend
The ValueSet 'ExecutionIntention' contains all codes which may be used for Procedure.extension:ExecutionIntention.
**ValueSet execution intention**
| Version | 1.0 |
| -------- | -------- |
| Published by | https://www.medizininformatik-initiative.de |
| Status | Active (since 2020-04-22) |
| Experimental | False |
Intent to execute the procedure.
This value set includes codes from the following code systems:
* The following codes from system: [SNOMED_CT](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/80147)
| Code | Display |
| -------- | -------- |
| [262202000](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/80147) | Therapeutic |
| [363676003](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/80147) | Palliative intent |
| [261004008](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/80147) | Diagnostic intent |
| [264931009](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/80147) | Symptomatic |
| [255231005](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/80147) | Revision - value |
| [255302009](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/80147) | Complicated |
| [129428001](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/80147) | Preventive intent |
| [394602003](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/80147) | Rehabilitation - speciality |
| [74964007](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/80147) | Other |
#### CodeSystems
The CodeSystem with the Canonical http://fhir.de/CodeSystem/dimdi/ops is published within the Procedure module according to the DIMDI license conditions.
Sign in with Wallet
Connect another wallet