HdBe-Alerte
WARNING This page contains a draft CBB, as raw output from the zib export and automatic conversion to CBB. It requires thorough review and adaption to the Belgian realm. This CBB is merely added for informative use.
CBB | Concept | Status |
---|---|---|
HdBe-Alert | Une alerte décrit un fait clinique ou administratif porté à l'attention des utilisateurs des systèmes cliniques, à prendre en compte lors de l'élaboration de la politique diagnostique et thérapeutique ou lors de la prise en charge du patient, généralement en raison d'un risque de sécurité. Les affections décrivant la sensibilité du corps à une substance qui entraîne une réaction physiologique spécifique après exposition à cette substance sont appelées allergies. Elles sont décrites dans un modèle d'information distinct. Les avertissements concernant des affections non allergiques peuvent porter sur :
PurposeDocumenter et saisir les affections ou les états qui nécessitent de l'attention est une part importante de l'enregistrement médical. Cela concerne l'essence de la sécurité des patients. Dans l'exécution de l'examen et du traitement, ces caractéristiques du patient - qui sont notées comme un avertissement - doivent constamment être prises en compte. Elles fournissent des informations importantes pour l'état du patient et les options dont un professionnel de la santé dispose pour la thérapie. Les affections enregistrées ou transférées comme une Alerte peuvent également être décrites comme un Problème. La différence réside dans le fait que le professionnel de la santé considère le problème comme une Alerte = avertissement. Dans de nombreux cas, le transfert sera soumis à des règles strictes en matière de confidentialité, car l'avertissement ne suscitera pas toujours une réaction adéquate dans l'environnement informé. InstructionsS'il existe une contre-indication qui est également importante pour l'innocuité des médicaments, elle doit également être enregistrée via ContreIndicationMédicament. | active |
Alert | I | Alert | |
EndDateTime | 0..1 | dateTime | |
Condition | I | 0..1 | Reference(HdBe-Problem) |
AlertName | I | 0..1 | CodeableConceptBinding |
StartDateTime | 0..1 | dateTime | |
AlertType | 0..1 | CodeableConceptBinding | |
Comment | 0..1 | string |
Alert | 0..* | |
Alert.EndDateTime | dateTime | 0..1 |
Alert.Condition | Reference(HdBe-Problem) | 0..1 |
Alert.AlertName | CodeableConcept | 0..1 |
Alert.StartDateTime | dateTime | 0..1 |
Alert.AlertType | CodeableConcept | 0..1 |
Alert.Comment | string | 0..1 |
Alert | |
Definition | Root concept of the Alert information model. This root concept contains all data elements of the Alert information model. |
Cardinality | 0...* |
Invariants |
|
Mappings |
|
Alert.id | |
Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. |
Cardinality | 0...1 |
Type | System.String |
Mappings |
|
Alert.extension | |
Definition | May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. |
Cardinality | 0...* |
Type | Extension |
Alias | extensions, user content |
Comments | There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone. |
Slicing | Unordered, Open, by url(Value) |
Invariants |
|
Mappings |
|
Alert.EndDateTime | |
Definition | The date and time at which the described condition was retracted as a warning. This can be an exact date and time, or a rough indication of the date (such as only the year, or the month and the year). |
Cardinality | 0...1 |
Type | dateTime |
Invariants |
|
Mappings |
|
Alert.Condition | |
Definition | The patient’s health problem or condition that is the subject of the alert. This could involve a patient’s problem, condition or diagnosis that is seen as a contraindication in prescribing medication or which has to be taken into account when shaping diagnostic and therapeutic policy. This can be in the patient’s own interest, or it can involve a problem or disorder that can make the patient a risk to their surroundings, such as an infection hazard. These are references to conditions included on the patient’s problem list. |
Cardinality | 0...1 |
Type | Reference(HdBe-Problem) |
Comments | References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. |
Invariants |
|
Mappings |
|
Alert.AlertName | |
Definition | A warning, other than a condition or problem. For example, a patient can be given an ‘Aggressive patient' alert. |
Cardinality | 0...1 |
Type | CodeableConcept |
Binding | AlertName codes AlertName (extensible) |
Comments | Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. |
Invariants |
|
Mappings |
|
Alert.StartDateTime | |
Definition | The date and time at which the described condition was entered as a warning. This can be an exact date and time, or a rough indication of the date (such as only the year, or the month and the year). |
Cardinality | 0...1 |
Type | dateTime |
Invariants |
|
Mappings |
|
Alert.AlertType | |
Definition | Indicates the type of alert, meaning a rough description of the cause or origin of the warning. |
Cardinality | 0...1 |
Type | CodeableConcept |
Binding | AlertType codes AlertType (required) |
Comments | Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. |
Invariants |
|
Mappings |
|
Alert.Comment | |
Definition | Explanatory comments to the alert that cannot be expressed in any of the other elements. |
Cardinality | 0...1 |
Type | string |
Comments | Note that FHIR strings SHALL NOT exceed 1MB in size |
Invariants |
|
Mappings |
|
Example instances
alert | |
---|---|
EndDateTime | 2012-12-30 |
condition.Problem | Listeriosis |
AlertName | |
StartDateTime | 2012-09-15 |
AlertType | 75323-6 - Condition (code by LOINC) |
Comment |
zib Alert-v4.1 difference
Concept | Category | Description |
---|---|---|
AlertName |
textual | Removed the notion of allowing free text in the definition because this is confusing and we want to stimulate the use of codes. The ValueSet binding is extensible, meaning that other codes or a text as fall back can be used. |
AlertName |
terminology | Replaced NullFlavor Other and Unkown with SNOMED equivelant codes. |
Terminology Bindings
Path | Name | Strength | URL |
---|---|---|---|
AlertName | AlertName | extensible | https://fhir.healthdata.be/ValueSet/AlertName |
AlertType | AlertType | required | https://fhir.healthdata.be/ValueSet/AlertType |