PN

Aktuelle Version vom 16. Oktober 2015, 14:44 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 .

PN (Personenname – Person Name)

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

Attribute

Lvl	Name	Desc	DT	Kard	Conf	Beschreibung
1	name	Name	PN	1..1	optional
2	@use	Nutzungsart(en)	CS	0..1	optional	wofür ist diese Namensangabe zu verwenden?
2	validTime	Gültigkeitsperiode	IVL<TS>	0..1	Optional	in welchem Zeitraum ist dieser Name gültig?
2	delimiter	Trennzeichen	PNXP	0..*	Optional	zur Kennzeichnung von Trennsymbolen, um eine mixed-content-Darstellung in XML zu vermeiden; Kann an unterschiedlichen Stellen mehrfach vorkommen, beispielsweise zur Trennung von Vor- und Nachnamen
2	prefix	Präfix	PNXP	0..*	Optional
3	@qualifier	Qualifier		0..*	Optional	zur Kennzeichnung von Anreden, Titel, etc.
2	given	Vorname(n)	PNXP	0..*	Optional
3	@qualifier	Qualifier		0..*	Optional	zur Kennzeichnung Geburtsname, Rufname, Initialen, etc.
2	family	Nachname	PNXP	0..*	Optional
3	@qualifier	Qualifier		0..*	Optional	zur Kennzeichnung Geburtsname, Spouse, etc.
2	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.

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

<name>Jan Meier</name>

Der Name wurde ohne interne Struktur übermittelt.

<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.

<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.

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.

Der use code ‘OR’ ist noch nicht im offiziellen HL7 Standard aufgenommen. Er wurde aber, vorauslaufend auf die internationale Harmonisierung, bereits hinzugefügt.

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.

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).

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).

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.

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>
  <!-- “Nicole de Vries” als Name des Babys vor der Adoption -->
</name>

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

<name>
  <validTime>
    <low value="20050825"/>
  </validTime>
  <!-- “Nicolette Scheick-Jansen” als Name nach der Eheschließung -->
</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:

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).

	<	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.

AD

angenommener Name

prüfen!

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.

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).

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.

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.

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.

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.

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).

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.

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.

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.

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).

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.

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.

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.

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.

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”.

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.

XML-Beispiele

Ronald Cornet, MSc

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

Varianten (Flavors, Templates)

Der Datentyp PN kennt einige Varianten (Flavors), die in verschiedenen Situationen benutzt werden.

Kurzbezeichnung	Beschreibung	Datentype/Flavor
voller Name	alle Elemente sind zugelassen	PN
Standard	voller Name mit Anrede, Titel, Vor- und Nachname sowie Geburtsname Dies entspricht am ehesten dem "legal Name".	PN.DE
förmliche Anrede	Zur Darstellung auf Briefumschlägen etc.	PN.DE.FORM
Anrede in Briefen	Wie soll die Person in Briefen angeredet werden? "Lieber Hans" anstelle von "Herr Dr. Meier"	PN.DE.LETTER
pseudonymisiert	Anstelle des "echten" Namens wird ein Pseudonym übermittelt, das mit Hilfe einer trusted third party ermittelt/festgelegt worden ist.	PN.DE.PSEUDONYM
anonymisiert	ohne verwertbare Namensinformation	PN.DE.ANONYM

PN

Aktuelle Version vom 16. Oktober 2015, 14:44 Uhr

PN (Personenname – Person Name)

Attribute

Varianten (Flavors, Templates)

Navigationsmenü

Meine Werkzeuge

Namensräume

Varianten

Ansichten

Mehr

Suche

Hauptnavigation

Enzyklopädie

Best practice / Tipps

Interoperabilitätsforum

IHE

EBMF

Medizingeräte

Hilfe

Werkzeuge

@@ Zeile 1: / Zeile 1: @@
+{{DocumentPart}}
 == PN (Personenname – Person Name) ==
-Ein Name einer Person.
+Der Datentyp PN wird verwendet, um den Namen einer Person darzustellen.
 ===Attribute===
-{{AttDesc | att | use | Benutzertyp(en) | SET<CS> }}
-===Elemente===
+{| class="hl7table"
-{{AttDesc | elm | validTime | Gültigkeitsperiode | IVL<TS> }}
+! Lvl
-{{AttDesc | elm | delimiter | Trennzeichen | PNXP }}
+! Name
-{{AttDesc | elm | family | Nachname | PNXP }}
+! Desc
-{{AttDesc | elm | given | Vorname | PNXP }}
+! DT
-{{AttDesc | elm | prefix | Präfix | PNXP }}
+! Kard
-{{AttDesc | elm | suffix | Suffix | PNXP }}
+! Conf
+! Beschreibung
+|-
+|1
+|bgcolor="88ff88"| name
+| Name
+| PN
+|1..1
+| optional
+|
+|-
+|2
+|bgcolor="88ff88"| @use
+| Nutzungsart(en)
+| CS
+| 0..1
+| optional
+| wofür ist diese Namensangabe zu verwenden?
+|-
+|2
+|bgcolor="88ff88"| validTime
+| Gültigkeitsperiode
+| IVL<TS>
+| 0..1
+| Optional
+| in welchem Zeitraum ist dieser Name gültig?
+|-
+|2
+|bgcolor="88ff88"|delimiter
+| Trennzeichen
+| PNXP
+| 0..*
+| Optional
+| zur Kennzeichnung von Trennsymbolen, um eine mixed-content-Darstellung in XML zu vermeiden; Kann an unterschiedlichen Stellen mehrfach vorkommen, beispielsweise zur Trennung von Vor- und Nachnamen
+|-
+|2
+|bgcolor="88ff88"| prefix
+| Präfix
+| PNXP
+| 0..*
+| Optional
+|
+|-
+|3
+|bgcolor="88ff88"| @qualifier
+| Qualifier
+|
+| 0..*
+| Optional
+| zur Kennzeichnung von Anreden, Titel, etc.
+|-
+|2
+|bgcolor="88ff88"| given
+| Vorname(n)
+| PNXP
+| 0..*
+| Optional
+|
+|-
+|3
+|bgcolor="88ff88"| @qualifier
+| Qualifier
+|
+| 0..*
+| Optional
+|zur Kennzeichnung Geburtsname, Rufname, Initialen, etc.
+|-
+|2
+|bgcolor="88ff88"| family
+| Nachname
+| PNXP
+| 0..*
+| Optional
+|
+|-
+|3
+|bgcolor="88ff88"| @qualifier
+| Qualifier
+|
+| 0..*
+| Optional
+| zur Kennzeichnung Geburtsname, Spouse, etc.
+|-
+|2
+|bgcolor="88ff88"| suffix
+| Suffix
+| PNXP
+| 0..*
+| Optional
+|
+|}
 Struktur: Der Daten-Typ PN ist eine Extension des Daten-Typs [[V3dtr1:EN|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.
-{{BeginEMBox}}
+{{EMBox|
 '''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.
@@ Zeile 22: / Zeile 114: @@
 :* 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''.
-{{EndEMBox}}
-'''''XML Beispiel'''''
-Personennamen als Freitext:
-{{HL7XML
-| code =
-<name>
-	Jan Meier
-</name>
 }}
+'''''XML Beispiele'''''
+<syntaxhighlight lang="xml" heading="Personennamen als Freitext">
+<name>Jan Meier</name>
+</syntaxhighlight>
 Der Name wurde ohne interne Struktur übermittelt.
-Personenname mit name parts:
+<syntaxhighlight lang="xml" heading="Personenname mit name parts">
-{{HL7XML
-| code =
 <name>
 	<given>Jan</given>
 	<family>Meier</family>
 </name>
-}}
+</syntaxhighlight>
 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:
+<syntaxhighlight lang="xml" error="true" heading="Ungültiger Personenname">
-{{HL7XML
-| code =
 <name>
 	Jan <family>Meier</family>
 </name>
-| error = true
+</syntaxhighlight>
+Dies ist kein gültiger Personenname, da Freitext mit einem name part kombiniert wurde.
+{{AttDesc
+| ae=att
+| rim=ent
+| name=use
+| desc = Typ der Namenverwendung
+| dt=CS
+| card=0..1
+| conf=optional
 }}
-Dies ist kein gültiger Personenname, da Freitext mit einem name part kombiniert wurde.
-{{AttDesc | att | use | Namenverwendungstyp | en }}
 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:
@@ Zeile 71: / Zeile 160: @@
 |}
-{{BeginEMBox}}
+{{EMBox|
 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.
-{{EndEMBox}}
+}}
-{{BeginHL7Box}}
+{{HL7deBox|
 Der use code ‘OR’ ist noch nicht im offiziellen HL7 Standard aufgenommen. Er wurde aber, vorauslaufend auf die internationale Harmonisierung, bereits hinzugefügt.
-{{EndHL7Box}}
+}}
 '''''XML-Beispiele'''''
 Der reguläre Name als default, also kein ''use'' Attribut
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
 <name>
-	<!-- Name, unterverteilt in Komponenten -->
+	<!-- ... -->
 </name>
-}}
+</syntaxhighlight>
 Ein Pseudonym eines Patienten
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
+<name use="A">
-<name use=”A”>
+	<!-- ... -->
-	<!-- Name, unterverteilt in Komponenten -->
 </name>
-}}
+</syntaxhighlight>
 Der gesetzlich registrierte Name
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
+<name use="OR">
-<name use=”OR”>
+	<!-- ... -->
-	<!-- Name, unterverteilt in Komponenten -->
 </name>
-}}
+</syntaxhighlight>
 Der geführte Name stimmt exakt mit dem gesetzlich registrierten Namen überein
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
+<name use="OR L">
-<name use=”OR L”>
+	<!-- ... -->
-	<!-- Name, unterverteilt in Komponenten -->
 </name>
+</syntaxhighlight>
+{{AttDesc
+| ae=elm
+| rim=ent
+| name=validTime
+| desc=Gültigkeitszeitraum
+| dt=IVL_TS
+| card=0..1
+| conf=O
 }}
-{{AttDesc | elm | validTime | 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.
@@ Zeile 126: / Zeile 220: @@
 :*Personen, die aus anderen Gründen ihren Vor- oder Nachnamen ändern.
-{{BeginEMBox}}
+{{EMBox|
 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).
-{{EndEMBox}}
+}}
 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).
-{{BeginEMBox}}
+{{EMBox|
 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.
-{{EndEMBox}}
+}}
 Der aktuelle Name ist gültig seit dem 12. Juli 2005
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
 <name>
 	<validTime>
 		<low value="20050712"/>
 	</validTime>
-	<!-- Name, unterverteilt in Komponenten -->
+	<!-- ... -->
 </name>
-}}
+</syntaxhighlight>
 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
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
 <name>
-	<validTime>
+  <validTime>
-		<high value="19850412"/>
+    <high value="19850412"/>
-	</validTime>
+  </validTime>
-	<!-- “Nicole de Vries” als Name des Babys vor der Adoption -->
+  <!-- “Nicole de Vries” als Name des Babys vor der Adoption -->
 </name>
+</syntaxhighlight>
+<syntaxhighlight lang="xml">
 <name>
-	<validTime>
+  <validTime>
-		<low value="19850413"/>
+    <low value="19850413"/>
-		<high value="20050824"/>
+    <high value="20050824"/>
-	</validTime>
+  </validTime>
-	<nowiki><!-- “Nicolette Scheick” als Name nach der Adoption, aber vor Eheschließung --></nowiki>
+  <!-- “Nicolette Scheick” als Name nach der Adoption, aber vor Eheschließung -->
 </name>
-}}
+</syntaxhighlight>
-{{HL7XML
-| code =
+<syntaxhighlight lang="xml">
 <name>
-	<validTime>
+  <validTime>
-		<low value="20050825"/>
+    <low value="20050825"/>
-	</validTime>
+  </validTime>
-	<nowiki><!-- “Nicolette Scheick-Jansen” als Name nach der Eheschließung --></nowiki>
+  <!-- “Nicolette Scheick-Jansen” als Name nach der Eheschließung -->
 </name>
+</syntaxhighlight>
+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.
+{{AttDesc
+| ae=elm
+| rim=ent
+| name=delimiter
+| desc = Trennzeichen
+| dt=PNXP
+| card=0..*
+| conf=O
 }}
-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.
-{{AttDesc | elm | delimiter | 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.
@@ Zeile 190: / Zeile 292: @@
 Trennung zwischen Partnername und Geburtsname
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
 <name>
 	<family qualifier=”SP”>Jansen</family>
@@ Zeile 197: / Zeile 298: @@
 	<family qualifier=”BR”>Scheick</family>
 </name>
-}}
+</syntaxhighlight>
 Trennung zwischen Nachnamen und akademischem Titel
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
 <name>
 	<family>Jansen</family>
@@ Zeile 207: / Zeile 307: @@
 	<title qualifier="AC">MSc</family>
 </name>
-}}
+</syntaxhighlight>
 Weitere allgemeine Beispiele finden Sie am Ende dieses Abschnitts.
 Einige auf der Hand liegende Fragen (und Antworten) über ''delimiters'':
-{{BeginFAQBox}}
+{{FAQBox|
 '''Frage:''' Muss ein empfangendes System einen delimiter speichern?
@@ Zeile 221: / Zeile 322: @@
 '''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).
+}}
-{{EndFAQBox}}
+{{AttDesc
+| ae=elm
+| rim=ent
+| name=family
+| desc = Nachname
+| dt=PNXP
+| card=0..*
+| conf=O
+}}
-{{AttDesc | elm | family | Nachname | }}
 Attribut:
-{{AttDesc | att | qualifer | Namensart | CS }}
+{{AttDesc
+| ae=att
+| rim=ent
+| name=qualifier
+| desc = Namensart
+| dt=CS
+| card=0..1
+| conf=optional
+}}
 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).
@@ Zeile 245: / Zeile 362: @@
 |-
 |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.
+|-
+|AD|| '''angenommener Name'''
+{{FAQBox|
+prüfen!
+}}
 |}
-{{BeginEMBox}}
+{{EMBox|
 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.
-{{EndEMBox}}
+}}
-{{BeginOIBox}}
+{{OIBox|
 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).
-{{EndOIBox}}
+}}
-{{BeginHL7Box}}
+{{HL7deBox|
 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.
-{{EndHL7Box}}
+}}
 '''''XML-Beispiele'''''
 Jan Meier
+<syntaxhighlight lang="xml">
-{{HL7XML
-| code =
 <name>
 	<given>Jan</given>
 	<family qualifier=”BR”>Meier</family>
 </name>
-}}
+</syntaxhighlight>
 Nicolette Jansen-Scheick
+<syntaxhighlight lang="xml">
-{{HL7XML
-| code =
 <name>
 	<given>Nicolette</given>
@@ Zeile 281: / Zeile 399: @@
 	<family qualifier=”BR”>Scheick</family>
 </name>
+</syntaxhighlight>
+{{AttDesc
+| ae=elm
+| rim=ent
+| name=given
+| desc = Vorname
+| dt=PNXP
+| card=0..*
+| conf=O
 }}
-{{AttDesc | elm | given | Vorname | }}
 Attribut:
-{{AttDesc | att | qualifer | Namensart | CS }}
+{{AttDesc
+| ae=att
+| rim=ent
+| name=qualifier
+| desc = Namensart
+| dt=CS
+| card=0..1
+| conf=optional
+}}
 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''.
@@ Zeile 306: / Zeile 441: @@
 |}
-{{BeginEMBox}}
+{{EMBox|
 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.
-{{EndEMBox}}
+}}
-{{BeginEMBox}}
+{{EMBox|
 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.
-{{EndEMBox}}
+}}
-{{BeginEMBox}}
+{{EMBox|
 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).
-{{EndEMBox}}
+}}
-{{BeginOIBox}}
+{{OIBox|
 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.
-{{EndOIBox}}
+}}
 '''''XML-Beispiele'''''
 Hans Jansen, ohne qualifier
+<syntaxhighlight lang="xml">
-{{HL7XML
-| code =
 <name>
 	<given>Hans</given>
 	<family>Jansen</family>
 </name>
-}}
+</syntaxhighlight>
 Johannes Theodorus Cornelis Jansen, offizielle Vornamen
+<syntaxhighlight lang="xml">
-{{HL7XML
-| code =
 <name>
 	<given qualifier=”BR”>Johannes Theodorus Cornelis</given>
 	<family>Jansen</family>
 </name>
-}}
+</syntaxhighlight>
 Johannes Theodorus Cornelis Jansen, mit Rufname Hans
+<syntaxhighlight lang="xml">
-{{HL7XML
-| code =
 <name>
 	<given qualifier=”BR”>Johannes Theodorus Cornelis</given>
@@ Zeile 353: / Zeile 482: @@
 	<family>Jansen</family>
 </name>
-}}
+</syntaxhighlight>
 Johannes Th. C. Jansen, ohne Duplizierung des Anfangsbuchstabens ‘J’
+<syntaxhighlight lang="xml">
-{{HL7XML
-| code =
 <name>
 	<given qualifier=”BR”>Johannes</given>
@@ Zeile 364: / Zeile 491: @@
 	<family>Jansen</family>
 </name>
-}}
+</syntaxhighlight>
 Kai Uwe Heitmann, Kai ist sowohl offizieller Name als auch Rufname
+<syntaxhighlight lang="xml">
-{{HL7XML
-| code =
 <name>
 	<given qualifier=”BR CL”>Kai</given>
@@ Zeile 375: / Zeile 500: @@
 	<family>Heitmann</family>
 </name>
-}}
+</syntaxhighlight>
 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.
-{{AttDesc | elm | prefix | Präfix | }}
+{{AttDesc
+| ae=elm
+| rim=ent
+| name=prefix
+| desc = Präfix
+| dt=PNXP
+| card=0..*
+| conf=O
+}}
 Attribute:
-{{AttDesc | att | code | Titelcode | CE, nicht bei qualifier ”VV” }}
+{{AttDesc
-{{AttDesc | att | qualifer | Namensart | CS }}
+| ae=att
+| rim=ent
+| name=code
+| desc = Titelcode
+| CE, nicht bei qualifier ”VV”
+| dt=SC
+| card=0..1
+| conf=optional
+}}
+{{AttDesc
+| ae=att
+| rim=ent
+| name=qualifier
+| desc = Namensart
+| dt=CS
+| card=0..1
+| conf=optional
+}}
 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).
@@ Zeile 390: / Zeile 542: @@
 :* 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.
-{{BeginHL7Box}}
+{{HL7deBox|
 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.
-{{EndHL7Box}}
+}}
 {| class="wikitable"
@@ Zeile 409: / Zeile 561: @@
 |}
-{{BeginEMBox}}
+{{EMBox|
 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.
-{{EndEMBox}}
+}}
-{{BeginEMBox}}
+{{EMBox|
 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.
-{{EndEMBox}}
+}}
 '''''XML Beispiele'''''
 Monique van Wijk
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
 <name>
 	<given>Monique</given>
@@ Zeile 427: / Zeile 578: @@
 	<family>Wijk</family>
 </name>
-}}
+</syntaxhighlight>
 Dr. Kai Heitmann
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
 <name>
 	<prefix qualifier=”AC”>Dr. </prefix>
@@ Zeile 437: / Zeile 587: @@
 	<family>Heitmann</family>
 </name>
-}}
+</syntaxhighlight>
 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
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
 <name>
 	<given>Berend-Jan</given>
@@ Zeile 449: / Zeile 598: @@
 	<family>Fürst zu Fürst</family>
 </name>
-}}
+</syntaxhighlight>
 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
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
 <name>
 	<prefix qualifier=”TITLE”>Sehr geehrter Herr </prefix>
@@ Zeile 461: / Zeile 609: @@
 	<family>Düren</family>
 </name>
-}}
+</syntaxhighlight>
 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
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
 <name>
 	<prefix qualifier=”TITLE”>Frau </prefix>
@@ Zeile 472: / Zeile 619: @@
 	<family>Jansen</family>
 </name>
+</syntaxhighlight>
+{{AttDesc
+| ae=elm
+| rim=ent
+| name = suffix
+| desc = Suffix
+| dt =PNXP
+| card=0..*
+| conf=O
 }}
-{{AttDesc | elm | suffix | Suffix | }}
 Attribut:
-{{AttDesc | att | code | Titelscode | CE }}
+{{AttDesc
+| ae=att
+| rim=ent
+| name=code=
+| desc = Titelscode
+| dt =SC
+| card=0..1
+| conf=optional
+}}
-{{AttDesc | att | qualifer | Namensart | CS }}
+{{AttDesc | ae=att | rim=ent| name= qualifier | desc=Namensart | dt=CS | card=0..1 | conf=optional }}
-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 den Niederlanden sind Nachsilben ausschließlich bei '''akademischen Graden''' zugelassen.
+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).
@@ Zeile 488: / Zeile 651: @@
 Die Art der Nachsilbe kann ferner angegeben werden durch die Anwendung des optionalen Attributs ''qualifier''. Siehe die Tabelle für die dabei zugelassenen Werte.
-{{BeginHL7Box}}
+{{HL7deBox|
 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.
-{{EndHL7Box}}
+}}
 {| class="wikitable"
 |+ Tabelle: ''qualifiers'' bei person name part ''suffix''
-! Qualifer !! Anwendung
+! 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”.
 |}
-{{BeginEMBox}}
+{{EMBox|
 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.
-{{EndEMBox}}
+}}
 '''''XML-Beispiele'''''
 Ronald Cornet, MSc
-{{HL7XML
+<syntaxhighlight lang="xml">
-| code =
 <name>
 	<given>Ronald</given>
 	<family>Cornet</family>
-	<suffix qualifier=”AC”>, MSc</suffix>
+	<delimiter>,</delimiter>
+	<suffix qualifier=”AC”>MSc</suffix>
 </name>
-}}
+</syntaxhighlight>
+===Varianten (Flavors, Templates)===
+Der Datentyp PN kennt einige Varianten (Flavors), die in verschiedenen Situationen benutzt werden.
+{|class="hl7table"
+|-
+! Kurzbezeichnung
+! Beschreibung
+! Datentype/Flavor
+|-
+|voller Name
+|alle Elemente sind zugelassen
+|PN
+|-
+|Standard
+|voller Name mit Anrede, Titel, Vor- und Nachname sowie Geburtsname<br>
+Dies entspricht am ehesten dem "legal Name".
+|PN.DE
+|-
+|förmliche Anrede
+|Zur Darstellung auf Briefumschlägen etc.
+|PN.DE.FORM
+|-
+|Anrede in Briefen
+|Wie soll die Person in Briefen angeredet werden?<br/>
+"Lieber Hans" anstelle von "Herr Dr. Meier"
+|PN.DE.LETTER
+|-
+|pseudonymisiert
+|Anstelle des "echten" Namens wird ein Pseudonym übermittelt, das mit Hilfe einer trusted third party ermittelt/festgelegt worden ist.
+|PN.DE.PSEUDONYM
+|-
+|anonymisiert
+|ohne verwertbare Namensinformation
+|PN.DE.ANONYM
+|}