Kardinalitäten
(Teildokument von V3 Datentypen Release 1)
(→Kardinalitäten, “mandatory" und “required”) |
|||
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
{{DocumentPart}} | {{DocumentPart}} | ||
− | == Kardinalitäten, “mandatory" | + | == Kardinalitäten, “mandatory", “required”, "optional" == |
− | In den HL7 Version 3 Nachrichten können bei den Klassen-Attributen weitere Eigenschaften genutzt werden, wie z.B. die Kardinalität des Attributs. Die nachstehende Tabelle enthält eine Übersicht dieser zusätzlichen Eigenschaften. | + | In den HL7 Version 3 Nachrichten bzw. CDA-Dokumenten können bei den Klassen-Attributen weitere Eigenschaften genutzt werden, wie z.B. die Kardinalität des Attributs. Die nachstehende Tabelle enthält eine Übersicht dieser zusätzlichen Eigenschaften. |
{| class="hl7table" | {| class="hl7table" | ||
Zeile 9: | Zeile 9: | ||
|- | |- | ||
|Kardinalität || Spezifiziert die minimale und maximale Anzahl des Vorkommens eines Elements (Feld oder Assoziation) in einer XML Instanz. Beispielsweise 1..* bedeutet, dass das Element mindestens 1 Mal vorkommen muss und dass maximal eine unbeschränkte Anzahl Elemente zugelassen ist. | |Kardinalität || Spezifiziert die minimale und maximale Anzahl des Vorkommens eines Elements (Feld oder Assoziation) in einer XML Instanz. Beispielsweise 1..* bedeutet, dass das Element mindestens 1 Mal vorkommen muss und dass maximal eine unbeschränkte Anzahl Elemente zugelassen ist. | ||
+ | |||
+ | Typische Beispiele: | ||
+ | * 0..1 | ||
+ | * 1..1 | ||
+ | * 1..* | ||
|- | |- | ||
− | |Mandatory || Ein | + | |Mandatory || Ein “mandatory" Item (Feld/Assoziation) '''muss''' in einer XML-Instanz vorkommen, ansonsten ist die Nachricht ungültig. Für “mandatory” Elemente ist die Mindestanzahl (Kardinalität) auf 1 (eins) festgelegt. “Mandatory" Elemente sollten nur sparsam und bedacht in Spezifikationen eingesetzt werden, da beim Fehlen von Informationen gar keine Information als Nachricht oder Dokument gesendet werden kann. |
|- | |- | ||
− | |Conformance || Hier wird ein Unterschied gemacht zwischen | + | |Conformance || Hier wird ein Unterschied gemacht zwischen: |
− | + | *''R = Required'' bedeutet, dass das sendende Anwenderprogramm dieses Feld oder diese Assoziation unterstützen muss. Wenn Daten verfügbar sind, muss dieses Feld/diese Assoziation in einer Nachricht vorhanden sein. Wenn die Mindest-Kardinalität 0 ist und wenn keine Daten verfügbar sind, darf das Element in einer XML-Instanz fehlen und ist die Nachricht/das Dokument immer noch gültig. Wenn die Mindest-Kardinalität 1 ist und keine Daten verfügbar sind, muss dies mit einem nullFlavor (siehe [[v3dtr1:NullFlavor|nullFlavor]]) angegeben werden.<br/>Beispiel: <code><value nullFlavor="UNK"/></code> | |
− | ''R = Required'' bedeutet, dass das sendende Anwenderprogramm dieses Feld oder diese Assoziation unterstützen muss. Wenn Daten verfügbar sind, muss dieses Feld/diese Assoziation in einer Nachricht vorhanden sein. Wenn die Mindest-Kardinalität 0 ist und wenn keine Daten verfügbar sind, darf das Element in einer XML Instanz fehlen und ist die Nachricht immer noch gültig. Wenn die Mindest-Kardinalität 1 ist und keine Daten verfügbar sind, muss dies mit einem nullFlavor (siehe | + | *''Optional (optional)'' bedeutet, dass ein Element in einer Instanz nicht oder doch vorhanden sein darf und dass Unterstützung durch das sendende Anwenderprogramm nicht verpflichtend ist. |
− | + | *''NP = not permitted'' (nicht zugelassen) bedeutet, dass das Feld / die Assoziation nicht in einer Nachricht/einem Dokument vorkommen darf (und auch nicht in dem zugrunde liegenden Schema vorhanden ist/sein soll). | |
− | ''NP = not permitted'' (nicht zugelassen) bedeutet, dass das Feld / die Assoziation nicht in einer Nachricht vorkommen darf (und auch nicht in dem zugrunde liegenden Schema vorhanden ist) | ||
− | |||
− | |||
|- | |- | ||
− | |NullFlavor || Für Felder/Assoziationen mit einer Mindest-Kardinalität von 1 muss ein nullFlavor angegeben werden, wenn in einem sendenden | + | |NullFlavor || Für Felder/Assoziationen mit einer Mindest-Kardinalität von 1 muss ein nullFlavor angegeben werden, wenn in einem sendenden Anwenderprogramm keine Informationen für dieses Element verfügbar sind. Beispiele von nullFlavor sind “keine Information” (NI – no information), “unbekannt” (UKN – unknown), “sonstige” (OTH - other) usw. Für nähere Erläuterungen siehe [[v3dtr1:NullFlavor|nullFlavor]]. |
|} | |} |
Aktuelle Version vom 24. August 2015, 08:56 Uhr
Dieses Material ist Teil des Leitfadens V3 Datentypen Release 1.
|
Kardinalitäten, “mandatory", “required”, "optional"
In den HL7 Version 3 Nachrichten bzw. CDA-Dokumenten können bei den Klassen-Attributen weitere Eigenschaften genutzt werden, wie z.B. die Kardinalität des Attributs. Die nachstehende Tabelle enthält eine Übersicht dieser zusätzlichen Eigenschaften.
Begriff | Erklärung/Anmerkungen |
---|---|
Kardinalität | Spezifiziert die minimale und maximale Anzahl des Vorkommens eines Elements (Feld oder Assoziation) in einer XML Instanz. Beispielsweise 1..* bedeutet, dass das Element mindestens 1 Mal vorkommen muss und dass maximal eine unbeschränkte Anzahl Elemente zugelassen ist.
Typische Beispiele:
|
Mandatory | Ein “mandatory" Item (Feld/Assoziation) muss in einer XML-Instanz vorkommen, ansonsten ist die Nachricht ungültig. Für “mandatory” Elemente ist die Mindestanzahl (Kardinalität) auf 1 (eins) festgelegt. “Mandatory" Elemente sollten nur sparsam und bedacht in Spezifikationen eingesetzt werden, da beim Fehlen von Informationen gar keine Information als Nachricht oder Dokument gesendet werden kann. |
Conformance | Hier wird ein Unterschied gemacht zwischen:
|
NullFlavor | Für Felder/Assoziationen mit einer Mindest-Kardinalität von 1 muss ein nullFlavor angegeben werden, wenn in einem sendenden Anwenderprogramm keine Informationen für dieses Element verfügbar sind. Beispiele von nullFlavor sind “keine Information” (NI – no information), “unbekannt” (UKN – unknown), “sonstige” (OTH - other) usw. Für nähere Erläuterungen siehe nullFlavor. |