HdBe-Alert
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 | Een alert beschrijft een klinisch of administratief feit dat onder de aandacht van de gebruikers van de klinische systemen wordt gebracht, om er bij het vormen van diagnostisch en therapeutisch beleid of bij de omgang met de patiënt rekening mee te houden, meestal wegens een veiligheidsrisico. Aandoeningen, die de overgevoeligheid van het lichaam voor een stof beschrijven, zich uitend in een specifieke fysiologische reactie na blootstelling, worden allergieën genoemd. Deze worden in een aparte bouwsteen beschreven Waarschuwingen voor niet allergische aandoeningen kunnen betreffen:
PurposeHet vastleggen en doorgeven van aandoeningen of condities die aandacht behoeven, is een belangrijk onderdeel van de medische registratie. Het raakt de kern van patiëntveiligheid. In de uitvoering van onderzoek en behandeling moet veelal continu rekening worden gehouden met deze, als waarschuwing gemarkeerde, patiëntkenmerken. Ze verschaffen informatie die belangrijk is in relatie met de conditie van de patiënt en de opties die een zorgverlener heeft voor therapie. Aandoeningen die als Alert worden geregistreerd of overgedragen, kunnen ook als Probleem worden beschreven. Het verschil is hierin gelegen, dat de zorgverlener het probleem heeft aangemerkt als Alert = waarschuwing. In veel gevallen zal overdracht onderworpen zijn aan sterke privacy regels, aangezien de waarschuwing niet altijd een adequate reactie van de geïnformeerde omgeving kan uitlokken. InstructionsIndien sprake is van een contra-indicatie die tevens van belang is voor de medicatieveiligheid dient deze ook via de g-standaard (Thesaurus 40) te worden vastgelegd. Zie hiervoor de bouwsteen MedicatieContraIndicatie | 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 |