PN

Aus Hl7wiki
(Teildokument von V3 Datentypen Release 1)
Wechseln zu: Navigation, Suche
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 .

PN (Personenname – Person Name)

Der Datentyp PN wird verwendet, um den Namen einer Person darzustellen.

Attribute

Lvl RIM Name Desc DT Kard Conf Beschreibung
1 ent @use Benutzertyp(en) SET<CS> 0..1 optional
2 ent validTime Gültigkeitsperiode IVL<TS> 0..1 Optional
2 ent delimiter Trennzeichen PNXP 0..* Optional
2 ent family Nachname PNXP 0..* Optional
2 ent given Vorname PNXP 0..* Optional
2 ent prefix Präfix PNXP 0..* Optional
2 ent suffix Suffix PNXP 0..* Optional


Struktur: Der Daten-Typ PN ist eine Extension des Daten-Typs EN (Entity Name) und besitzt folglich einen sogenannten ‘mixed content’, wobei im Prinzip Freitext mit name parts kombiniert werden kann. Für Deutschland gilt, dass die Verwendung von ‘mixed content’ bei Personennamen begrenzt ist. Zugelassen sind:

  • Der vollständige Personenname als Freitext (es gibt also keine person name parts), wenn es dem Sender nicht möglich ist, Teile des Namen zu benennen.
  • Alle Teileinheiten sind als person name part definiert. In einem solchen Fall darf also kein Text vorkommen, der nicht von einem der nachstehend beschriebenen Tags begleitet wird.
Talk.svg Die Sequenz der person name parts ist relevant! Als Richtlinie gilt, dass diese in der ‘natürlichen’ Sequenz der Benutzung des Namens angegeben werden. Die angegebene Sequenz ist besonders in den folgenden Fällen wichtig:
  • Präfixe (prefix) müssen immer vor dem Namen stehen, zu dem sie gehören.
  • Suffixe (suffix) müssen immer hinter dem Namen stehen, zu dem sie gehören.
  • Vornamen (given) müssen immer in der offiziellen (gesetzlichen) Sequenz stehen.
  • Nachnamen (family) und ein eventuelles Trennzeichen (meistens ‘-‘) müssen in der offiziellen Sequenz stehen, abhängig von der Wahl bei der Eheschließung.
Nähere Erläuterungen finden Sie bei den verschiedenen person name parts.

XML Beispiele

Personennamen als Freitext: 

<name>
	Jan Meier
</name>

Der Name wurde ohne interne Struktur übermittelt.

Personenname mit name parts: 

<name>
	<given>Jan</given>
	<family>Meier</family>
</name>

Die beiden Bestandteile des Namens werden benannt und erhalten einen qualifier: “Jan” ist ein ‘Name, der bei der Geburt gegeben wurde’, bzw. ein Vorname (voll ausgeschrieben). “Meier” ist ein ‘Familienname, der bei der Geburt empfangen wurde’, bzw. der eigene Nachname.

Ungültiger Personenname: 

<name>
	Jan <family>Meier</family>
</name>

Dies ist kein gültiger Personenname, da Freitext mit einem name part kombiniert wurde.

@ Attribut DT Card Conf Beschreibung
use CS 0..1 optional Typ der Namenverwendung


Im Prinzip kann von jedem Person Name angegeben werden, in welcher Situation dieser verwendet werden kann. Für Deutschland wurde beschlossen, dass die folgenden Verwendungstypen für Namen zugelassen sind:

Tabelle: Domäne EntityNameUse Attribut Werte
Code Name Definition
L Regulärer Name Der Name, den die Person (Entität) führt. Die Abkürzung ‘L’ stand ursprünglich für Legal (gesetzlich), Tatsache ist aber, dass in dem Namen auch Komponenten vorkommen dürfen (z.B. ein Rufname), die nicht gesetzlich festgelegt sind. Dieser Namenverwendungstyp ist der Default, wenn kein Typ durchgegeben wird.
A Pseudonym Ein Künstlername, ‘Deckname’ oder zeitlicher Name für eine Person (Entität). Dieser weicht also von dem regulär geführten Namen ab und wird z.B. benutzt, um die Identität einer Person zu tarnen (Privacy) oder als temporärer Name, wenn der echte unbekannt ist (‘John Doe’).
OR Gesetzlich registrierter Name Der Name mit den exakten Komponenten, der im Einwohnermeldeamt des betreffenden Landes registriert ist.
Talk.svg Beachten Sie, dass ein Name auch zwei use Attribute haben darf. Das kann z.B. vorkommen, wenn der gesetzlich registrierte Name (‘OR’) auch als regulärer Name geführt wird (siehe nachstehendes Beispiel). Achten Sie aber darauf, dass dann keine einzige Komponente vorkommen darf (wie Rufname oder ein Partnername) die nicht Teil des gesetzlich registrierten Namens ist. EMBox
Logo-hl7.svg Der use code ‘OR’ ist noch nicht im offiziellen HL7 Standard aufgenommen. Er wurde aber, vorauslaufend auf die internationale Harmonisierung, bereits hinzugefügt. HL7deBox

XML-Beispiele

Der reguläre Name als default, also kein use Attribut 

<name>
</name>

Ein Pseudonym eines Patienten 

<name use=”A”>
</name>

Der gesetzlich registrierte Name 

<name use=”OR”>
</name>

Der geführte Name stimmt exakt mit dem gesetzlich registrierten Namen überein 

<name use=”OR L”>
</name>
< Element DT Card Conf Beschreibung
validTime IVL_TS 0..1 O Gültigkeitszeitraum


Dies ist ein optionales XML Element innerhalb Person Name, welches die Periode angibt, in der dieser Name für die betreffende Person ‘in Gebrauch’/gültig war. Die Optionen sind:

  • Es gibt kein validTime Element: Der betreffende Name ist im Prinzip unbegrenzt gültig.
  • Es gibt eine Unter- und Obergrenze: Der Name war in der angegebenen Periode gültig.
  • Es gibt nur eine Untergrenze: Der Name ist seit dem angegebenen Datum gültig.
  • Es gibt nur eine Obergrenze: Der Name war bis einschl. angegebenem Datum gültig.

Dieses Element von Person Name kann verwendet werden, um anzugeben, dass im Leben einer Person einmal oder mehrmals eine Namensänderung stattgefunden hat. Dies geschieht u.a bei:

  • Adoption eines Babys, das den Nachnamen der Adoptiveltern erhält.
  • Eheschließung, wobei der Name des Partners an den eigenen Namen angefügt wird.
  • Ehescheidung, wobei ein vorher angenommener Name wieder abgelegt wird.
  • Personen, die aus anderen Gründen ihren Vor- oder Nachnamen ändern.
Talk.svg In allen Situationen, in denen ein oder mehrere Person Names durchgegeben werden, muss minimal der Name angegeben werden, der zum Zeitpunkts des Versendens gültig/aktuell ist. Nicht mehr gültige Namen können also nur angegeben werden, wenn das betreffende Nachrichtenelement wiederholt benutzt wird (also mit einer Kardinalität > 1). EMBox

Zu beachten ist, dass viele Patientenerfassungssysteme keine wirkliche Historie (mit Anfangsdatum) der Patientennamen führen. Wohl wird häufig ein allgemeines ‘audit trail’ (Änderungshistorie) der Patientendaten geführt. Im Bedarfsfall könnte daraus die Historie des Personennamens abgeleitet werden, obwohl es natürlich auch möglich ist, nur den aktuellen Namen durchzugeben (also kein validTime zu verwenden).

Talk.svg Im Gegensatz zu der Situation bei Organization Name ist es nicht zugelassen, dass die Unter- oder Obergrenze einer validTime Angabe bei Person Name in de Zukunft liegt. Es kann also kein ‘geplanter’ neuer Name oder ein ‘geplantes Verfallsdatum’ des heutigen Namens für Personennamen durchgegeben werden. EMBox

Der aktuelle Name ist gültig seit dem 12. Juli 2005 

<name>
	<validTime>
		<low value="20050712"/>
	</validTime>
</name>

Obenstehende Situation kann z.B. bei einem System vorkommen, das nur den aktuellen Namen übermittelt, aber auch die Historie führt. Die oben genannte Person kann z.B. am 12. Juli geheiratet haben und dabei den Namen des Partners angenommen haben.

Alte Namen plus aktueller Name 

<name>
	<validTime>
		<high value="19850412"/>
	</validTime>
</name>

<name>
	<validTime>
		<low value="19850413"/>
		<high value="20050824"/>
	</validTime>
	&lt;!-- “Nicolette Scheick” als Name nach der Adoption, aber vor Eheschließung --&gt;
</name>



<name>
	<validTime>
		<low value="20050825"/>
	</validTime>
	&lt;!-- “Nicolette Scheick-Jansen” als Name nach der Eheschließung --&gt;
</name>

In vorstehendem Beispiel wird das Baby Nicole de Vries von der Familie Scheick adoptiert, wobei sich also ihr Nachname ändert. Weil den Adoptiveltern dieser Name besser gefällt, wird auch ihr Vorname (oder auf jeden Fall ihr Rufname) geändert in Nicolette. Nach ihrer Eheschließung nimmt sie den Nachnamen ihres Partners (Jansen) an. Das sendende System sendet in diesem Fall die gesamte Namenshistorie mit.

< Element DT Card Conf Beschreibung
delimiter PNXP 0..* O Trennzeichen


Ein delimiter hat keine spezielle Bedeutung als Bestandteil eines Person Name, im Gegensatz zur Übermittlung eines (Stückchens) wörtlichem Text, der in dem geschriebenen Namen vorkommt.

Ein delimiter muss immer an der Stelle in Person Name stehen, an der man auch den Text schreiben würde. Es gibt keine impliziten Leerstellen. Wenn man also normalerweise eine Leerstelle davor oder dahinter schreibt, muss diese explizit angegeben werden.

Beispiele von delimiters in Person Names sind:

  • Der Bindestrich ‘-‘ zwischen dem eigenen Nachnamen und dem Partnernamen (oder umgekehrt).
  • Das Komma plus Leerstelle ‘, ‘ zwischen dem Namen und bestimmten Nachsilben.
  • Der Text ‘, geb. ’ oder ‘, E.v. ‘ (Ehefrau von), der manchmal benutzt wird bei dem eigenen, bzw. Partnernamen.

Diese könnten folgendermaßen in einem Person Name XML Nachrichtenelement benutzt werden:

Trennung zwischen Partnername und Geburtsname 

<name>
	<family qualifier=”SP”>Jansen</family>
	<delimiter>-</delimiter>
	<family qualifier=”BR”>Scheick</family>
</name>

Trennung zwischen Nachnamen und akademischem Titel 

<name>
	<family>Jansen</family>
	<delimiter>, </delimiter>
	<title qualifier="AC">MSc</family>
</name>

Weitere allgemeine Beispiele finden Sie am Ende dieses Abschnitts.


Einige auf der Hand liegende Fragen (und Antworten) über delimiters:

Faq.svg Frage: Muss ein empfangendes System einen delimiter speichern?

Antwort: Ein empfangendes System, dass die einzelnen person name parts verarbeitet, wird delimiters praktisch nie in der eigenen Datenbank speichern.


Frage: Warum sollte ein sendendes System dann überhaupt delimiters mitsenden?

Antwort: Es kann vorkommen, dass empfangende Systeme keine oder nicht alle person name parts separat verarbeiten können (z.B. weil sie nur ein Feld für den Nachnamen haben). Sie können über delimiters einen voll ausgeschriebenen Namen übernehmen. (Ein Beispiel eines solch einfachen Empfängers ist ein Webinterface, das eingehende HL7 v3 Nachrichten in ein HTML Format umsetzt, zur direkten Wiedergabe auf dem Bildschirm).

FAQBox
< Element DT Card Conf Beschreibung
family PNXP 0..* O Nachname


Attribut:

@ Attribut DT Card Conf Beschreibung
qualifier CS 0..1 optional Namensart


Ein person name part des Typen family bezieht sich auf einen Teil des Namens, den eine Person durch Familienbande bekommen hat und der meistens als Nachname bezeichnet wird. Normalerweise bezieht sich dies also auf den eigenen Nachnamen (erhalten von den Eltern) und eventuell auf einen nach einer Heirat angenommenen Nachnamen. (‘übernommen’ vom Partner).

Einige Regeln in Bezug auf person name parts des Typen family:

  • Diese müssen untereinander immer konform mit der offiziellen Schreibweise angeordnet sein (z.B. zuerst der eigene Nachname und dann der Nachname des Partners oder genau umgekehrt).
  • Es gibt immer eine implizite Leerstelle als Zwischenraum mit dem darauf folgenden name part, außer bei einem delimiter oder einem suffix (siehe dort).
  • Die Art des Nachnamens kann weiterhin durch die Verwendung des optionalen Attributs qualifier angegeben werden. Siehe Tabelle für die dabei zugelassenen Werte.
  • Es darf nur ein Familienname pro Qualifier-Typ im Namen vorkommen!
Tabelle: qualifiers bei person name part family
Qualifer Anwendung
BR (birth) Geburtsname. Ein Nachname, den man bei der Geburt erhalten hat. Normalerweise ist dies der Geburtsname eines (natürlichen) Elternteils, aber in einigen Kulturen kann es sich dabei auch um eine Kombination der Geburtsnamen beider Eltern handeln, oder um eine Ableitung des Vornamens eines Elternteils.
CL Rufname. Ein Nachname, mit dem eine Person informell angesprochen wird und der meistens von einem der offiziellen Nachnamen abgeleitet ist.
SP (spouse) Partnername. Ein Nachname, der von einem Partner bei einer Ehe ‘übernommen’ wurde (meistens der Geburtsname eines Partners). Dies sagt nichts aus über das Geschlecht des Namensträgers, da die Annahme von Namen zwischen beiden Partnern in den Deutschland gleichgestellt ist. Auch wenn ein Partnername fehlt, kann daraus keine Schlussfolgerung über den Ehestand gezogen werden, da jemand verheiratet sein kann, ohne den Namen des Partners zu führen. Es ist zu beachten, dass es bei der Verwendung eines Partnernamens nicht nur relevant ist, dass jemand verheiratet ist, sondern vor allem, ob die betreffende Person mit dem Namen des Partners angesprochen werden möchte oder nicht. Die Anwendung des Partnernamens im Personennamen ist unabhängig von einer eventuellen Benennung des Partners als Kontaktperson. In der heutigen deutschen Namensrecht ist nach einer Eheschließung jede Kombination von Eigenname und/oder Partnername von beiden Partnern möglich. Natürlich ist das Geschlecht der beiden Partner dabei nicht relevant.
Talk.svg Wenn ein person name part vom Typ family ohne einen qualifier benutzt wird, wird dies einfach als Nachname interpretiert. Wenn der Empfänger zwischen einer Speicherung als Geburtsname oder als Partnername wählen kann, muss in einem solchen Fall der Geburtsname gewählt werden. EMBox
Issue.svg Es muss noch entschieden werden, was mit einem Geburtsnamen geschehen soll, den jemand nach einer Eheschließung nicht mehr führt (weil ausschließlich der Partnername geführt wird). Der Geburtsname muss in einem solchen Fall trotzdem gespeichert (und übermittelt) werden, aber es könnte dabei angegeben werden, dass der Name ‘unsichtbar’ sein muss. Eine Lösung könnte die Implementierung eines Attributs invisible sein. Es ist auf jeden Fall möglich, den Namen zweimal zu übermitteln: einmal mit dem use Attribut ‘OR’ (mit dem Geburtsnamen) und einmal mit einem ‘L’ (ohne). OIBox
Logo-hl7.svg Es muss im internationalen Rahmen noch untersucht werden, wie mit dem Nachnamen zu verfahren ist, der von den Adoptiveltern übernommen wurde. Nach der heutigen Definition ist der qualifier “BR” hierfür nicht geeignet, aber es ist klar, dass die qualifiers “SP” und “CL” ebenfalls nicht ausreichend sind. Vorläufig lautet die Empfehlung in solchen Fällen (falls überhaupt bekannt ist, dass es sich um einen Adoptivnamen handelt) keinen qualifier mitzusenden. In der Praxis wird ein derartiger Name allerdings meistens als ‘eigener Nachname’ (und daher mit qualifier “BR”) benutzt werden. HL7deBox

XML-Beispiele

Jan Meier 

<name>
	<given>Jan</given>
	<family qualifier=”BR”>Meier</family>
</name>

Nicolette Jansen-Scheick 

<name>
	<given>Nicolette</given>
	<family qualifier=”SP”>Jansen</family>
	<delimiter>-</delimiter>
	<family qualifier=”BR”>Scheick</family>
</name>
< Element DT Card Conf Beschreibung
given PNXP 0..* O Vorname


Attribut:

@ Attribut DT Card Conf Beschreibung
qualifier CS 0..1 optional Namensart


Ein person name part des Typen given bezieht sich auf den Teil des Namens, den eine Person meistens von den Eltern und meistens bei der Geburt erhält. In Deutschland wird dies meistens als Vorname bezeichnet, obwohl dieser nicht in allen Kulturen vor dem Familiennamen steht. Auch Namensbestandteile, die von dem Vornamen abgeleitet sind, z.B. die Initialen (Anfangsbuchstaben) und der Rufname (informeller Vorname) haben den Typ given.

Einige Regeln für person name parts des Typen given:

  • Eine Person kann ohne weiteres mehrere Vornamen oder Initialen haben.
  • Offizielle Vornamen und Initialen müssen immer in der richtigen Sequenz stehen.
  • Es muss immer eine implizite Leerstelle als Zwischenraum zu dem darauf folgenden name part stehen, außer wenn es sich um ein delimiter oder ein suffix handelt (siehe dort).
  • Die Datenart des gegebenen Namens kann zudem angedeutet werden, indem das optionale Attribut qualifier benutzt wird. Siehe Tabelle für die dabei zugelassenen Werte.
Tabelle: qualifiers bei person name part given
Qualifer Anwendung
BR Offizieller Vorname. Ein Vorname, der meistens bei der Geburt gegeben ist (meistens von den Eltern) und der offiziell registriert ist. Vornamen müssen voll ausgeschrieben werden und in der richtigen Sequenz stehen. Wenn eine Person mehrere Vornamen hat, muss auf jeden Fall der erste Name übermittelt werden (Die ausschließliche Benutzung des ersten Vornamens ist also zugelassen, die ausschließliche Benutzung des zweiten Vornamens dagegen nicht). Wenn es mehrere Vornamen gibt, können diese sowohl als separate given Elemente, als auch in einem Element (getrennt durch Leerstellen) übermittelt werden. Es kommt auch vor, dass der erste Vorname voll ausgeschrieben in Kombination mit den Initialen benutzt wird.
CL Rufname. Ein Vorname, mit dem eine Person informell angesprochen wird und der meistens von einem der offiziellen Vornamen abgeleitet ist. Im Gegensatz zu den offiziellen Vornamen kann ein Rufname im Leben einer Person ohne weiteres variieren. Eine Person kann sogar mehrere Rufnamen gleichzeitig haben, je nachdem wie Menschen die Person kennen. In diesem Fall muss der am meisten zutreffende Rufname gesendet werden.
SP Initialen. Meistens eine Abkürzung des Vornamens. Dabei kann es sich um einen einzigen oder um mehrere Buchstaben handeln (z.B. ‘Th.’ für Thomas). Ein abschließender Punkt muss explizit angegeben werden. Initialen müssen in der korrekten Sequenz angegeben werden. Wenn es mehrere Initialen gibt, können diese sowohl als separate given Elemente, als auch in einem Element (getrennt durch Punkte) übermittelt werden. Der Vorteil dieser Methode ist, dass keine Leerstellen zwischen den einzelnen Initialen im Namen impliziert werden.
Talk.svg Wenn ein person name part des Typen given ohne einen qualifier verwendet wird, wird dieses einfach als Vorname interpretiert. Wenn der Empfänger wählen muss, ob dies als offizieller Vorname oder als Rufname gespeichert werden soll, muss in einem solchen Fall der offizielle Vorname gewählt werden. EMBox
Talk.svg Die qualifiers “BR” und “CL” können auch gemeinsam vorkommen, um an-zugeben, dass ein offizieller Vorname auch als Rufname fungiert. So kann vermieden werden, dass der gleiche Name zwei Mal mit gesendet werden muss. Wenn der Rufname allerdings von den offiziellen Vornamen abweicht, können beide übermittelt werden: zuerst die offiziellen Vornamen und danach der Rufname. EMBox
Talk.svg Wenn eine Kombination von offiziellem Vornamen und Initialen mit gesendet wird, dürfen diese sich in Deutschland nicht ‘überlappen’ dürfen, d.h. dass der erste Anfangsbuchstabe (falls erforderlich) von dem empfangenden System von dem/den ersten Buchstaben des offiziellen Vornamens ab-geleitet werden muss (siehe nachstehendes Beispiel). EMBox
Issue.svg In Deutschland muss noch untersucht werden, wie man mit dem Vornamen, den die Adoptiveltern gegeben haben, zu verfahren hat. Nach der heutigen Definition ist der qualifier “BR” hierfür nicht geeignet, aber es ist nicht klar, ob der qualifier “CL” (Rufname) wohl ausreichend ist. Die Frage ist nämlich, ob ein derartiger Name einen offiziellen Charakter bekommt oder nur als Rufname fungiert. OIBox

XML-Beispiele

Hans Jansen, ohne qualifier 

<name>
	<given>Hans</given>
	<family>Jansen</family>
</name>

Johannes Theodorus Cornelis Jansen, offizielle Vornamen 

<name>
	<given qualifier=”BR”>Johannes Theodorus Cornelis</given>
	<family>Jansen</family>
</name>

Johannes Theodorus Cornelis Jansen, mit Rufname Hans 

<name>
	<given qualifier=”BR”>Johannes Theodorus Cornelis</given>
	<given qualifier=”CL”>Hans</given>
	<family>Jansen</family>
</name>

Johannes Th. C. Jansen, ohne Duplizierung des Anfangsbuchstabens ‘J’ 

<name>
	<given qualifier=”BR”>Johannes</given>
	<given qualifier=”IN”>Th.C.</given>
	<family>Jansen</family>
</name>

Kai Uwe Heitmann, Kai ist sowohl offizieller Name als auch Rufname 

<name>
	<given qualifier=”BR CL”>Kai</given>
	<given qualifier=”BR”>Uwe</given>
	<family>Heitmann</family>
</name>

Das Fazit dieser Beispiele ist, dass diverse Kombinationen von offiziellen Vornamen, Rufnamen und Initialen möglich sind, abhängig von den Speicher- und Kommunikations-kapazitäten des sendenden Systems. Die Bedeutung der einzelnen Bestandteile muss allerdings deutlich sein.

< Element DT Card Conf Beschreibung
prefix PNXP 0..* O Präfix


Attribute:

@ Attribut DT Card Conf Beschreibung
code SC 0..1 optional Titelcode


@ Attribut DT Card Conf Beschreibung
qualifier CS 0..1 optional Namensart


Ein person name part des Typen prefix bezieht sich auf einen Teil des Namens, der zu einem oder mehreren anderen Namensbestandteilen gehört und vorne angehängt wird. Im Prinzip gibt es zwei Arten von Vorsilben, nämlich Vorsilben zu Nachnamen und zu Titeln/akademischen Graden (die als Zufügung zum geschriebenen Namen aufgenommen werden).

Einige Regeln für person name parts des Typen prefix:

  • Ein prefix muss immer direkt vor die Namensbestandteile platziert werden, auf die es sich bezieht (d.h. wo es normalerweise geschrieben wird).
  • Es gibt keine implizite Leerstelle als Zwischenraum zu dem darauf folgenden name part, d.h. eine Leerstelle nach der Vorsilbe muss explizit im Text angegeben werden!

Die Art der Vorsilbe kann zudem angedeutet werden, indem man das optionale Attribut qualifier benutzt. Siehe Tabelle für die dabei zugelassenen Werte.

Logo-hl7.svg Im nächsten Release der Datentypen von HL7 v3 wird es möglich sein, diverse Elemente die jetzt ein ‘string’ sind, auch optional als Code anzugeben.

Dies kann u.a. zur kodierten Versendung von Titeln/akademischen Graden benutzt werden, wenn das sendende System diese als Code speichert. Darüber hinaus muss der Text aber immer gesendet werden, damit der Empfänger entscheiden kann, was benutzt wird.

HL7deBox
Tabelle: qualifiers bei person name part prefix
Qualifer Anwendung
VV Vorsilbe zu Nachnamen. Dabei handelt es sich um Namensbestandteile wie “von“, “den“, und “zu“, aber auch um Kombinationen wie “von der“ usw. Eine Vorsilbe gehört immer zum person name part des Typen family , der immer direkt dahinter steht (siehe die XML Beispiele). Eine Vorsilbe kann als Bestandteil des Nachnamen aufgenommen werden, aber es ist gebräuchlich, sie einzeln zu speichern (und zu versenden), da Sortierungen (und daher auch das Zurücksuchen) immer auf Nachnamen ohne Vorsilbe stattfinden.
AC Akademischer Grad. Ein Grad (meistens in abgekürzter Form) den jemand aufgrund der Vollendung eines wissenschaftlichen Studiums oder eines anderen Studiums erworben hat, z.B.: “Dr.“, “Dipl.-Ing.“, “Ing.“, “Hr.“, “Dr.“, “Prof.“, aber auch “Prof. Dr.“, „Prof. Dr. med.“.
NB Adelstitel. Ein Titel (meistens voll ausgeschrieben) der auf dem aristokratischen Status einer Person gründet. Beispiele sind “Baron“, “Graf“, usw.
TITLE Allgemeine Anrede (nicht Titel). Diese wird im Prinzip als Anrede zu einem vollständigen Namen (als Briefanrede) verwendet, z.B. “Sehr geehrte Herr” , “Sehr geehrte Frau“, aber auch einfach “Frau“. Die Art einer solchen Anrede hängt also mit dem Geschlecht der Person und dem eventuellen akademischen Grad und/oder Adelstitel ab (mit Hilfe von Ableitungsregeln).
Talk.svg Wenn ein person name part des Typen prefix ohne einen qualifier benutzt wird, wird dies immer interpretiert als Titel. Dies geschieht, weil viele ver-sendende Systeme zwar Titel unterstützen, aber keinen Unterschied machen zwischen akademischen Graden und Adelstiteln. Vorsilben bei Nachnamen und die allgemeine Anrede (“VV” bzw. “TITLE”) müssen also immer explizit übermittelt werden. EMBox
Talk.svg Wenn nicht bekannt ist, ob ein Titel vor oder hinter dem Namen anzuhängen ist, muss dieser als prefix gesendet werden. Dies wird häufig der Fall sein bei Systemen, die keine Rangfolge im Textfeld bei einem Titel speichern. In solchen Fällen werden Titel also immer vor dem Namen im Datentyp Person Name positioniert. EMBox

XML Beispiele

Monique van Wijk 

<name>
	<given>Monique</given>
	<prefix qualifier=”VV”>van </prefix>
	<family>Wijk</family>
</name>

Dr. Kai Heitmann 

<name>
	<prefix qualifier=”AC”>Dr. </prefix>
	<given>Kai</given>
	<family>Heitmann</family>
</name>

In diesem Fall lautet die Regel also, dass der Grad (‘Dr.‘) vor dem kompletten Namen positioniert wird, weil dies die normale Schreibweise ist.

Berend-Jan Baron von Fürst zu Fürst 

<name>
	<given>Berend-Jan</given>
	<prefix qualifier=”NB”>Baron </prefix>
	<prefix qualifier=”VV”>von </prefix>
	<family>Fürst zu Fürst</family>
</name>

In diesem (realen) Beispiel steht der Titel (‘Baron‘) zwischen dem Vornamen und dem Nachnamen, da dies die gebräuchliche Schreibweise ist. Zudem steht eine ‘normale’ Vorsilbe vor dem Nachnamen (‘von‘). Übrigens wird die Software häufig nicht in der Lage sein, einen (einzeln gespeicherten) Titel an die richtige Stelle zu setzen, wodurch ‘Baron‘ auch vornan landen kann.

Sehr geehrter Herr Dr. Frank Düren 

<name>
	<prefix qualifier=”TITLE”>Sehr geehrter Herr </prefix>
	<prefix qualifier=”AC”>Dr. </prefix>
	<given>Frank</given>
	<family>Düren</family>
</name>

In diesem Beispiel hat das versendende System offensichtlich den vollständigen Titel festgelegt (oder vom Titel ableitet) und als Teil des ‘Korrespondenznamen’ übermittelt. Aber auch ohne Titel kann das versendende System eine allgemeine Anrede mitsenden (siehe nachstehend).

Frau A. Jansen 

<name>
	<prefix qualifier=”TITLE”>Frau </prefix>
	<given>A.</given>
	<family>Jansen</family>
</name>
< Element DT Card Conf Beschreibung
suffix PNXP 0..* O Suffix


Attribut:

@ Attribut DT Card Conf Beschreibung
code= SC 0..1 optional Titelscode


@ Attribut DT Card Conf Beschreibung
qualifier CS 0..1 optional Namensart


Ein person name part des Typen suffix bezieht sich auf einen Teil des Namens, der zu einem oder mehreren anderen Namensbestandteilen gehört und hinten angehängt wird. In Deutschland sind Nachsilben ausschließlich bei akademischen Graden zugelassen. Einige Regeln für person name parts des Typen suffix:

  • Ein suffix muss immer direkt hinter die Namensbestandteile positioniert werden, auf die es sich bezieht (d.h. wo es normalerweise steht).
  • Es gibt keine implizite Leerstelle als Zwischenraum zu dem davor stehenden name part, d.h. eine Leerstelle vor der Nachsilbe muss explizit angegeben werden!

Die Art der Nachsilbe kann ferner angegeben werden durch die Anwendung des optionalen Attributs qualifier. Siehe die Tabelle für die dabei zugelassenen Werte.

Logo-hl7.svg Im nächsten Release der Datentypen von HL7 v3 wird es möglich sein, diverse Elemente die jetzt ‘string’ sind, optional auch als Code anzudeuten.

Dies kann u.a. zur kodierten Versendung von Titeln benutzt werden, wenn das sendende System diese als Code speichert. Darüber hinaus muss aber immer der Text gesendet werden, damit der Empfänger entscheiden kann, was benutzt wird.

HL7deBox
Tabelle: qualifiers bei person name part suffix
Qualifier Anwendung
AC Akademische Grade. Ein Grad (meistens in abgekürzter Form) den jemand aufgrund der Vollendung eines wissenschaftlichen Studiums oder eines anderen Studiums erworben hat. Bei Nachsilben handelt es sich dabei meistens um internationale Termen wie “MSc”, “PhD” oder “MD”.
Talk.svg Ein person name part des Typen suffix, der ohne qualifier benutzt wird, muss interpretiert werden als nicht näher bestimmtes Suffix. Auch die Verwendung von (vielfach amerikanischen) Termen wie ‘, Jr.’, ‘, Sr.’ of ‘ III’ fällt unter diese Kategorie. EMBox

XML-Beispiele

Ronald Cornet, MSc 

<name>
	<given>Ronald</given>
	<family>Cornet</family>
	<delimiter>,</delimiter>
	<suffix qualifier=”AC”>MSc</suffix>
</name>


Templates

Aus den o.g. Grundlagen lassen sich verschiedene Templates definieren, die quasi als Grundlage - u.a. zum Testen - genutzt werden können.

Kurzbezeichnung Beschreibung OID
Standard voller Name mit Anrede, Titel, Vor- und Nachname sowie Geburtsname

Dies entspricht am ehesten dem "legal Name".

n.a.
förmliche Anrede Zur Darstellung auf Briefumschlägen etc. n.a.
Anrede in Briefen n.a.
pseudonymisiert n.a.
anonymisiert ohne verwertbare Namensinformation n.a.
Abgerufen von „https://wiki.hl7.de/index.php?title=v3dtr1:PN&oldid=6505“