Kardinalitäten

Aus Hl7wiki
(Teildokument von V3 Datentypen Release 1)
Wechseln zu: Navigation, Suche
(Kardinalitäten, “mandatory" und “required”)
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1: Zeile 1:
 
{{DocumentPart}}
 
{{DocumentPart}}
== Kardinalitäten, “mandatory" und “required” ==
+
== 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” 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 || 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 R (required, Pflicht), NP (not permitted, nicht zugelassen) und optional.
+
|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 an anderer Stelle in diesem Leitfaden) angegeben werden.
+
*''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).
 
 
 
''Optional (optional)'' bedeutet, dass ein Element nicht oder wohl vorhanden sein darf und dass Unterstützung durch das sendende Anwender-programm auch nicht verpflichtend ist.
 
 
|-
 
|-
|NullFlavor || Für Felder/Assoziationen mit einer Mindest-Kardinalität von 1 muss ein nullFlavor angegeben werden, wenn in einem sendenden Anwender-programm keine Informationen für dieses Element verfügbar sind. Bei-spiele von nullFlavor sind “keine Information” (NI –  no information), “unbekannt” (UKN – unknown) usw. Für nähere Erläuterungen siehe unter nullFlavor in diesem Leitfaden.
+
|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.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

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:

  • 0..1
  • 1..1
  • 1..*
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:
  • 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 nullFlavor) angegeben werden.
    Beispiel: <value nullFlavor="UNK"/>
  • 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).
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.