IHE Radiology (RAD) Technical Framework: Integrating The Healthcare Enterprise

Integrating the Healthcare Enterprise
10
IHE Radiology (RAD)

Technical Framework
Volume 4
IHE RAD TF-4
National Extensions
15
20
Revision 13.0 Final Text

July 30, 2014
25
Please verify you have the most recent version of this document, which is published here.
Copyright 2014: IHE International, Inc.
IHE Radiology Technical Framework, Volume 4: National Extensions

______________________________________________________________________________
CONTENTS
30
35
40
45
50
55
60
65
70
1 Introduction ................................................................................................................................ 4
1.1 Overview of Technical Framework .................................................................................... 4
1.2 Overview of Volume 4 ........................................................................................................ 5
2 Overview of National Extensions to the Technical Framework ................................................ 6
2.1 Scope of National Extensions ............................................................................................. 6
2.2 Process for Developing National Extensions...................................................................... 6
2.3 Process for Proposing Revisions to the Technical Framework .......................................... 7
3 National Extensions for IHE France .......................................................................................... 8
3.1 Comments ........................................................................................................................... 8
3.2 IHE-F 2002 Scope............................................................................................................... 8
3.3 Extended DICOM Character Sets ....................................................................................... 8
3.4 Extended HL7 Character set ............................................................................................... 8
3.5 Translation of Specific Fields of the PID Segment ............................................................ 8
3.6 Insurance Information ......................................................................................................... 9
3.7 Forbidden PID Fields ........................................................................................................ 10
3.8 Syntax Rules for PID-5 (Patient Name)............................................................................ 10
3.9 Syntax Rules for PID-11 (Patient Address) ...................................................................... 10
3.10 Extensions of PID-16 (Marital Status).............................................................................. 10
3.11 Translations of PID-16 (Marital Status) and Selection of Values .................................... 10
3.12 Translations of PV1-19, Visit Number ............................................................................. 10
3.13 Extensions of PV1-2 (Patient Class) ................................................................................. 11
3.14 Translations of PV1-2 (Patient Class) and Selection of Values ....................................... 11
3.15 Visit number usage and interpretation .............................................................................. 12
3.16 Patient Account Number ................................................................................................... 12
3.17 Translations of PV1-4 (Admission Type) and Selection of Values .................................. 12
3.18 Extension and Translations of Physician Types in PV1 ................................................... 13
3.19 Translation of PV1-51 Visit Indicator and Selection of Value ......................................... 13
3.20 Extension of PV2-3 (Admit Reason) ................................................................................ 14
3.21 Translation of PV2-3 (Admit Reason) and Selection of Value ........................................ 14
3.22 Management of Functional Units...................................................................................... 14
4 National Extensions for IHE Germany .................................................................................... 16
4.1 Comments ......................................................................................................................... 16
4.2 Scope ................................................................................................................................. 16
4.3 DICOM: Support for ISO Latin 1 ..................................................................................... 16
4.4 HL7: Support for ISO Latin 1 ........................................................................................... 16
4.5 HL7: German Semantics ................................................................................................... 16
4.6 HL7: PID-18 Patient Account Number and PV1-19 Visit Number .......................... 17
4.7 Change PV1-8 Referring Doctor to Type R2 in all PV1 Segments .............................. 17
4.8 HL7: ZBE Segment in ADT ............................................................................................. 17
5 National Extensions for IHE United States .............................................................................. 19
5.1 PID Segment ..................................................................................................................... 19
__________________________________________________________________________
2
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
75
80
85
90
95
100
105
6 National Extensions for IHE Italy ............................................................................................ 20

6.1 Comments ......................................................................................................................... 20
6.2 IHE-I 2003 Scope ............................................................................................................. 20
6.3 Extended DICOM Character Sets ..................................................................................... 20
6.4 Extended HL7 Character Set ............................................................................................ 20
6.5 Translation of specific Fields of the PID Segment ........................................................... 21
6.6 Syntax Rules for PID-11 (Patient Address) ...................................................................... 21
6.7 Translations of PV1-19, Visit Number ............................................................................. 21
6.8 Extensions of PV1-2 (Patient Class) ................................................................................. 21
6.9 Patient Account Number ................................................................................................... 22
7 National Extensions for IHE United Kingdom ........................................................................ 23
7.1 Introduction ....................................................................................................................... 23
7.2 Scope ................................................................................................................................. 23
7.3 HL7: PID-18 Patient Account Number ......................................................................... 23
7.4 HL7: PV1-19 Visit Number .......................................................................................... 23
7.5 HL7: PV1-8 Referring Doctor ....................................................................................... 23
7.6 DICOM: Support for ISO Latin 1 ..................................................................................... 24
7.7 HL7: Support for ISO Latin 1 ........................................................................................... 24
8 National Extensions for IHE Canada ....................................................................................... 25
8.1 Comments ......................................................................................................................... 25
8.2 Extended DICOM Character Sets ..................................................................................... 25
8.3 Extended HL7 Character set ............................................................................................. 25
8.4 Translation of Specific Fields of the PID Segment .......................................................... 25
8.5 Syntax Rules for PID-5 (Patient Name)............................................................................ 26
8.6 Extensions of PID-16 (Marital Status).............................................................................. 26
8.7 Translations of PV1-2 (Patient Class) and Selection of Values ....................................... 26
8.8 Visit number usage and interpretation .............................................................................. 26
9 National Extensions for IHE Spain .......................................................................................... 28
9.1 Comments ......................................................................................................................... 28
9.2 IHE-E: Scope of 2007s National Extension .................................................................... 28
9.3 1.3 IHE-E: Translation of IHE terms into Spanish ........................................................... 28
9.4 Support for ISO Latin 1 .................................................................................................... 28
9.5 Patient Identification Data ................................................................................................ 29
9.6 Insurance Data .................................................................................................................. 36
9.7 Examples ........................................................................................................................... 37
9.8 References ......................................................................................................................... 41
__________________________________________________________________________
3
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
1 Introduction
110
115
120
125
130
Integrating the Healthcare Enterprise (IHE) is an initiative to promote the use of standards to
achieve interoperability of health information technology (HIT) systems and effective use of
electronic health records (EHRs). IHE provides a forum for volunteer committees of care
providers, HIT experts and other stakeholders in several clinical and operational domains to
reach consensus on standards-based solutions to critical interoperability issues. IHE publishes the
implementation guides they produce (called IHE profiles), first to gather public comment and
then for trial implementation by HIT vendors and other system developers.
IHE provides a process for developers to test their implementations of IHE profiles, including
regular testing events called Connectathons. After a committee determines that a profile has
undergone sufficient successful testing and deployment in real-world care settings, it is
incorporated in the appropriate IHE Technical Framework, of which the present document is a
volume. The Technical Frameworks provide a unique resource for developers and users of HIT
systems: a set of proven, standards-based solutions to address common interoperability issues
and support the convenient and secure use of EHRs.
Purchasers can specify conformance with appropriate IHE profiles as a requirement in requests
for proposal. Vendors who have successfully implemented IHE profiles in their products can
publish conformance statements (called IHE Integration Statements) in the IHE Product Registry
(http://ihe.net/IHE_Product_Registry).
The current versions of this and all IHE Technical Framework documents are available at
http://ihe.net/Technical_Frameworks. Comments may be submitted at
http://www.ihe.net/Radiology_Public_Comments.
IHE domain committees are responsible for developing and publishing Technical Framework
documents. This document is published by the IHE Radiology committees. Information on the
activities of this domain, including its committee rosters and how to participate, is available at
http://wiki.ihe.net/index.php?title=Domains.
135
General information about IHE, including its governance structure, sponsorship, member
organizations and work process, is available at www.ihe.net.
1.1 Overview of Technical Framework
140
An IHE Technical Framework describes use cases requiring interoperability of HIT systems and
defines functional components (called IHE actors) of these systems. Using established standards,
they specify the actions and interactions of these actors, including the content objects they
produce and exchange. Volume 1 of the Radiology Technical Framework provides high-level
overviews of each profile, the use case it addresses and the actors involved. Volumes 2 and 3
provide detailed specifications of each transaction and other technical requirements. The current
document, Volume 4, describes national extensions to the IHE Radiology Technical Framework.
__________________________________________________________________________
4
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
145
150
1.2 Overview of Volume 4

This volume contains information about the scope of national extensions to the transactions
defined in the IHE Technical Framework. Section 2 describes the permitted scope of national
extensions and the process by which national IHE initiatives can propose such extensions for
approval by the IHE Technical Committee and documentation in the IHE Technical Framework.
Sections 3 through 9 provide the sets of national extensions that have thus far been approved by
IHE: those from France, Germany, United States, Italy, United Kingdom, Canada, and Spain.
__________________________________________________________________________
5
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
2 Overview of National Extensions to the Technical Framework
155
The goal of IHE is to promote implementation of standards-based solutions to improve workflow

and access to information in support of optimal patient care. To that end, IHE encourages the
development of IHE National Deployment Committees to address issues specific to local health
systems, policies and traditions of care. The role of these organizations and information about
how they are formed is available at http://ihe.net/Governance/#National_Deployment.
2.1 Scope of National Extensions

160
165
170
National extensions to the IHE Technical Framework are allowed in order to address specific
local healthcare needs and promote the implementation of the IHE Technical Frameworks. They
may add (though not relax) requirements that apply to the Technical Framework generally or to
specific transactions, Actors and Integration Profiles. Some examples of appropriate national
extensions are:
Require support of character sets and national languages
Provide translation of IHE concepts or data fields from English into other national
languages
Extensions of patient or provider information to reflect policies regarding privacy and
confidentiality
Changes to institutional information and financial transactions to conform to national
health system payment structures and support specific local care practices
All national extensions shall include concise descriptions of the local need they are intended to
address. They shall identify the precise transactions, actors, integration profiles and sections of
the Technical Framework to which they apply. And they must provide technical detail equivalent
to that contained in the Technical Framework in describing the nature of the extension.
175
2.2 Process for Developing National Extensions
180
National extension documents are to be developed, approved and incorporated in the Technical
Framework in coordination with the IHE Technical Committee and its annual cycle of activities
in publishing and maintaining the Technical Framework. The first prerequisite for developing a
national extension document is to establish a national IHE initiative and make information
regarding its composition and activities available to other IHE initiatives.
185
Established IHE national initiatives may draft a document describing potential national
extensions containing the general information outlined above and similar in form to those found
in sections 4-6 of the current document. They submit this draft document to the IHE Technical
Committee for review and comment. Based on discussion with the Technical Committee, they
prepare and submit finalized version of the document in appropriate format for incorporation into
the Technical Framework. The publication of National Extensions is to be coordinated with the
annual publication cycle of other Technical Framework documents in the relevant domain. The
annual cycle for Radiology is available at http://wiki.ihe.net/index.php?title=Radiology.
__________________________________________________________________________
6
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
2.3 Process for Proposing Revisions to the Technical Framework

190
In addition to developing national extension documents to be incorporated in the Technical

Framework, national IHE initiatives may also propose revisions to the global Technical
Framework. These may take the form of changes to existing transactions, actors or integration
profiles or the addition of new ones. Such general changes would be subject to approval by the
IHE Technical and Planning Committees.
195
Changes that are minor in scope, such as suggestions for clarifications or corrections to
documentation, may be submitted throughout the year via the ongoing errata tracking process.
Comments on this document may be submitted at
http://www.ihe.net/Radiology_Public_Comments.
200
205
210
More substantial revision proposals, such as proposals to add new integration profiles, should be
submitted directly to the IHE Technical and Planning Committees. The initial submission of such
proposed revisions to the global Technical Framework should be a 1-2 page white paper
containing:
A description of the clinical need addressed by the proposed revision with appropriately
detailed use cases
An overview of the proposed technical approach for meeting this clinical need, including
the established standards to be used
Any known constraints to the proposed solution (e.g., maturity of standards or necessity
of regulatory compliance)
An estimate of the level of effort for developing and implementing the proposed solution
The IHE Planning and Technical Committees will give due consideration to all such revision
proposals received from national IHE initiatives and will notify their originators of their
disposition. Revisions or additions that are accepted as work items for the Technical Committee
will be completed in its annual revision cycle of the Technical Framework.
__________________________________________________________________________
7
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
215
3 National Extensions for IHE France
220
The national extensions documented in this section shall be used in conjunction with the
definitions of integration profiles, actors and transactions provided in volumes 1-3 of the IHE
Technical Framework. This section includes extensions and restrictions to effectively support the
regional practice of healthcare in France. It also translates a number of English terms to ensure
correct interpretation of requirements of the Technical Framework.
3.1 Comments
This national extension document was authored under the sponsorship and supervision of
GMSIH and JFR, who welcome comments on this document and the IHE France initiative.
Comments should be directed to:
225
Karima Bourquard
IHE-France project manager
Email: [email protected]
3.2 IHE-F 2002 Scope

230
235
The extensions, restrictions and translations specified apply to the following IHE Integration
profiles:
Scheduled Workflow
Patient Reconciliation
Consistent Presentation of Images
Key Image Notes
Simple Image and Numerical Report
Access to Radiology Information
3.3 Extended DICOM Character Sets
240
The support of accented characters is required for all actors with DICOM-based transactions.
The Specific Character Set (0008,0005) Attribute shall contain the value ISO_IR 100 in order
to select ISO 8859/1 Latin-1 characters.
3.4 Extended HL7 Character set

The support of accented characters is required for all actors with HL7 based transactions. The
Field MSH 18 shall contain the value 8859/1 in order to select the ISO 8859 Latin-1
characters.
245
3.5 Translation of Specific Fields of the PID Segment

The table below provides the translation of specific fields of the PID Segment:
__________________________________________________________________________
8
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
La table ci-dessous fournit la traduction de champs specific du segment PID.
Table 3.5-1: Translation of PID Segment Fields
Champ (Field)
Interprtation/Traduction
Patient Identifier List (PID 3)
IPP (Identifiant Permanent du Patient)
Legal Name (PID 5)
Nom patronymique
Maiden Name (PID 5)
Nom de jeune fille
Display Name (PID 5)
Nom usuel
SSN Number Patient (PID 19) This is the

personal social security number of the patient
which may not be the social security number used
for the insurance billing payment.
Numro de Scurit Social du patient.
Patient Account Number (PID 18) Unique

identifier for collecting and grouping all elements
necessary for charging AND / OR the transmission
to the insurance company for charging.
Numro de compte patient Numro unique qui permet de

collecter et de grouper tous les lments ncessaires la
facturation ET / OU la transmission vers les organismes
d'assurances et mutuelles, pour prise en charge
250
3.6 Insurance Information

The IHE Technical Framework includes the IN1 and IN2 segments as an option for the purpose
of communicating the insurance information of the patient.
255
IHE-France supports the optional use of the segments IN1 and IN2 in order to convey the social
security number when used as an insurance number for the patient care. It is used when patient
charge posting is made by the clinical / radiology department. It is conveyed through A01, A04
or A08.
Table 3.6-1: IHE profile IN1 Segment
SEQ
LEN
DT
OPT
TBL#
ITEM#
ELEMENT NAME
SI
Set ID IN1
60
CE
Insurance Plan ID
59
CX
Insurance Company ID
260
Adapted from the HL7 Standard, version 2.3.1
Table 3.6-2: IHE profile IN2 Segment

SEQ
LEN
DT
OPT
TBL#
ITEM#
ELEMENT NAME
60
XON
Insured Employee ID
60
XON
Insured Social Security Number
__________________________________________________________________________
9
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
265
3.7 Forbidden PID Fields

In France, it is illegal to transmit the Fields PID-10 (Race) and PID-22 (Ethnic Group).
En France, il est interdit de transmettre les champs PID-10 (Race) et PID-22 (Groupe thnique).
3.8 Syntax Rules for PID-5 (Patient Name)

270
Last name prefix (<family name (ST) & <last_name_prefix (ST)>) will be used for names with
particule . Prefix sera utilis pour la particule des noms particules.
3.9 Syntax Rules for PID-11 (Patient Address)

The ZIP or Postal Code will contain the code postal.
Le ZIP or Postal Code devra contenir le Code Postal.
3.10 Extensions of PID-16 (Marital Status)

275
Two values, G for Living Together and P for Domestic Partner shall be added to the The Marital
Status table 002 of HL7 2.3.1 (User defined table). No IHE-F implementation shall extend this
table.
Note: These G and P values have been obtained from HL7 2.4.
3.11 Translations of PID-16 (Marital Status) and Selection of Values

280
The table below includes the translations of the PID-16, Marital Status:
La table ci-dessous fournit la traduction de champs specific du segment PID-16, Marital Status:
Table 3.11-1: Translation of PID-16, Marital Status
Valeur
Description
Separated
Spar
Divorced
Divorc
Married
Mari
Single
Clibataire
Widowed
Veuf/Veuve
Living together
Concubin
Domestic Partner
Pacte Civil de Solidarit (PACS)
3.12 Translations of PV1-19, Visit Number

285
This number corresponds to physical visit of the patient into the hospital. The patient account
number may group one or more visit number (PV1-19)
__________________________________________________________________________
10
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
Ce numro correspond un passage physique dans l'tablissement. Le patient account number
(PID-18) regroupe un ou plusieurs Visit number (PV1-19).
The table below provides the translation of specific fields of the PV1 Segment:
290
La Table ci-dessous donne la traduction de champs specifiques du segment PV1:

Table 3.12-1: Translation of Specific Fields of PV-1 Segment
Champ
Visit Number (PV1 19)
Numro de sjour / numro de passage ou mouvement
3.13 Extensions of PV1-2 (Patient Class)

295
Two values, W for Week in Hospital, S for Psychiatric, K for Newborn, shall be added to the
The Patient Class Table 004 of HL72.3.1 (User defined table). No IHE-F implementation shall
extend this table.
Note: The Addition of the W, S and K values will be submitted to the HL7 French Chapter when
created.
300
3.14 Translations of PV1-2 (Patient Class) and Selection of Values

The table below includes the translations of the PV1-2, Patient Class and shall not be extended:
La table ci-dessous fournit la traduction de champs specifiques du segment PV1-2, Patient Class
et ne doit pas tre tendue:
305
Table 3.14-1: PV1-2 Values and Translations

Valeur
Description
Emergency
Urgence
Inpatient
Hospitalis
Outpatient
Externe
Preadmit
Peut comprendre les catgories

nationale : Hospitalisation
programmes, Consultants
externes programms, Psychiatrie
programmes, Rsidents
programms
Recuring Patient
Rsident
Obstetrics
Obsttrique
Day hospital
Hopital du jour
Week hospital
Hopital de semaine
Psychiatric
Psychiatrie
__________________________________________________________________________
11
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
Valeur
K
310
Description
Newborn
Nouveau n
Note: For S=Psychiatry, in the context of patient admission in this class, the type of admission
will be refined in the field PV2-3 Admit Reason (See Section A.4.15).
Note : Pour S= Psychiatrie, dans le cadre de ladmission dun patient dans cette catgorie, le
type dadmission sera prcis dans le champ PV2-3 Admit Reason (voir section A.4.15).
3.15 Visit number usage and interpretation

Field PV1-2 Visit Number is a required field in IHE France.
If Field PV1-2 is I then PV1-19 is interpreted as n de sjour.
If Field PV1-2 is D or W then PV1-19 is interpreted as n de sjour.
315
If Field PV1-2 is O Outpatient then PV1-19 is interpreted as n de consultation.

If Field PV1-2 is R Inpatient then PV1-19 is interpreted as n de sance.
3.16 Patient Account Number

Field PID-18 Patient Account Number is an optional field in IHE France.
320
The field PID-18 may be used in cases when a patient may have multiple visits (each visit having
independent transfer and discharge), but where all the visits need to be linked under one
Case/Episode number (either for billing or clinical tracking reasons).
3.17 Translations of PV1-4 (Admission Type) and Selection of Values

The table below includes the translations of the PV1-4, Admission Type and shall not be
extended:
325
La table ci-dessous fournit la traduction de champs specifiques du segment PV1-4, Admission

Type et ne doit pas tre tendu:
Valeur
Description
Accident
Accident de travail
Elective
Confort (chirurgie esthtique)
Emergency
Urgence
Labor and Delivery
Accouchement
Newborn (Birth in Healthcare

facility)
Nouveau N
Routine
Routine
Urgent
Urgent
__________________________________________________________________________
12
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
3.18 Extension and Translations of Physician Types in PV1

The optionality status of PV1-7, PV1-8, PV1-9 and PV1-17 is R2 for French implementation.
330
The table below includes the translations of the PV1 Physician Types:
La table ci-dessous fournit la traduction de champs relatif aux types de doctuers dans PV1:
Table 3.18-1: Translation of PV1 Physician Types
Field
Description
PV1-7Attending doctor:
The person primarily responsible

for the care of the patient during a
particular health care visit
(generally used for inpatient
events, but could be extended to an
outpatient visit as well.)
Mdecin responsable pendant la

dure de ladmission.
PV1-8Referring doctor
Is any physician who referred the

patient to the care of another
physician (generally a specialist)
for a particular visit. The referring
physician might be noted in an
HL7 event so that she/he receives
a copy of any test results or
documentation of care.
Mdecin (en gnral extrieur

l'tablissement) qui a adress le
patient.
PV1-9Consulting doctor
Is generally a specialist who sees a

patient as the result of a referral or
a consultation order. She/he is not
the attending physician for the
case, although that status could be
transferred to a consulting
physician at some point.
Le mdecin qui est consult pour

un deuxime avis.
PV1-17 Admitting doctor
Is the physician who decides that a

patient meets the criteria for an
inpatient admission to a hospital
during a specific visit. The
admitting physician is responsible
for evaluating the patient so that
their acuity satisfies admission
criteria.
Mdecin de l'tablissement qui

dcide dhospitaliser un patient.
(ex. En cas durgence)
3.19 Translation of PV1-51 Visit Indicator and Selection of Value

335
IHE France will only use the visit indicator at the visit level, there is no accounting information
issued.
Table 3.19-1: Translation of PV1-51 Visit Indicator
Valeur
V
Description
Visit
Venue
__________________________________________________________________________
13
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
3.20 Extension of PV2-3 (Admit Reason)

340
Two values listed in Table A.4-1 shall be added to the Table 004 of HL72.3.1 (User defined
table). No IHE-F implementation shall extend this table.
3.21 Translation of PV2-3 (Admit Reason) and Selection of Value

In the case of the hospitalization of a patient in psychiatry, one shall use the field PV2-3 Admit
Reason as defined below:
345
Dans le cadre dune hospitalisation dun patient en psychiatrie alors on devra utiliser le champ
PV2-3 Admit Reason afin de prciser le mode de placement.
Table 3.21-1: PV2-3 Interpretation of Values
Code
Mode de placement
HL
Hospitalisation Libre
HO
Placement doffice
HDT
Hospitalisation la demande dun tiers
LV
Leve dhospitalisation
SE
Sortie lessai
3.22 Management of Functional Units

350
355
A major difference between the management of responsibilities between the USA and France is
that the responsibility for a patient is often managed at the level of a functional unit rather than at
the level of an attending doctor. For this purpose the Z Segment ZFU has been created.
Il y une diffrence entre la manire dont les responsabilits sont gres aux USA et en France.
Alors quaux USA la responsabilit du patient est trs souvent lie au mdecin (Attending
Doctor), en France, celle-ci est rattache lunit fonctionnelle. Cest pourquoi le champ priv
ZFU a t cre.
For IHE-F, the ZFU segment is required for messages A01, A02, A04, A05, A06, A07, and A08.
Pour IHE-F ce segment est obligatoire pour les messages: A01, A02, A04, A05, A06, A07, and
A08.
360
Field ZFU-1 Nursing Functional Unit is responsible for the care of the patient.
Cest lunit fonctionnelle responsable des soins donns au patient.
Field ZFU-2 Housing Functional Unit is responsible for housing the patient.
Cest lunit fonctionnelle dhbergement.
365
Field ZFU-3 Medical Functional Unit is the unit for which the attending doctor is operating.
Cest lunit fonctionnelle qui a la responsabilit Mdicale du patient.
__________________________________________________________________________
14
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
Table 3.22-1: IHE profile - ZFU Segment
SEQ
370
LEN
DT
OPT
TBL#
ITEM#
ELEMENT NAME
60
XO
N
Nursing Functional Unit: UF

soin
60
TS
Nursing Functional Unit Start

date/time
60
XO
N
Housing Functional Unit: UF

hbergement
60
TS
Housing Functional Unit Start

date/time
60
XO
N
Medical Functional Unit: UF

mdicale
60
TS
Medical Functional Unit Start

date/time
Conditions: At least one of these three functional units is required (name and date/time that the
patient has entered the functional unit). Two or three of them can have the same value.
Conditions : Au moins une des ces units fonctionelles est obligatoire (nom et la date/heure le
patient est entr sous lunit fonctionnelle). Deux ou trois dentre eux peuvent avoir la mme
valeur.
375
__________________________________________________________________________
15
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
4 National Extensions for IHE Germany
380
regional practice of healthcare in Germany.
4.1 Comments
385
The IHE-D Initiative welcomes comments on this document and the IHE Germany initiative.
Comments should be directed to the IHE-D Working Group <[email protected]> or to
Marco Eichelberg <[email protected]>, IHE-D Technical Project Manager.
4.2 Scope
390
Profiles:
Scheduled Workflow
4.3 DICOM: Support for ISO Latin 1
395
All actors with DICOM based transactions shall support the value ISO_IR 100 for the attribute
(0008,0005) Specific Character Set if this attribute is defined in the DICOM SOP class used by
the IHE transaction. This attribute value specifies the ISO 8859-1 (Latin 1) character set.
4.4 HL7: Support for ISO Latin 1

All actors with HL7 based transactions shall support the value 8859/1 for the field MSH-18
Character Set in the MSH segment. This value specifies the printable characters from the ISO
8859-1 (Latin 1) character set (see Table 0211 in HL7 Appendix A).
400
4.5 HL7: German Semantics

The semantics (i.e., names) of the HL7 fields shall be used as defined in the German HL7 edition
2.3.1d published by the German HL7 Chapter (HL7-Benutzergruppe in Deutschland e. V.,
http://www.hl7.de/). In particular, the use of the following field deviates from the U.S. HL7
specification:
405
Table 4.5-1:
Field
PID-27
HL7 USA Semantics

Veteran Military Status
HL7 Germany Semantics

Beruf/Ttigkeit des Patienten
(Patients Profession/Occupation)
__________________________________________________________________________
16
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
4.6 HL7: PID-18 Patient Account Number and PV1-19 Visit

Number
410
Field PV1-19 Visit Number is required and shall be used to transmit the patient admission
identifier (Fallnummer). Field PID-18 Patient Account Number is used to consolidate
information relative to several visits and is generally not used in Germany.
4.7 Change PV1-8 Referring Doctor to Type R2 in all PV1 Segments

Volume 2, Sections 4.1.4.1.2.4, 4.2.4.1.2.3, 4.4.4.1.2.3 and 4.12.4.2.2.4
415
In Volume 2, sections 4.1.4.1.2.4, 4.2.4.1.2.3, 4.4.4.1.2.3 and 4.12.4.2.2.4 of the Technical

Framework, the optionality of field PV1-8, Referring Doctor, is C: Conditional. Clinical
situations have been identified in which an ORM message is sent for an outpatient, but the
Referring Doctor is unknown and, therefore, field PV1-8 cannot be valued. In particular this
affects the treatment of emergency outpatients in the German healthcare system.
420
Therefore, the optionality of field PV1-8, Referring Doctor shall be changed to R2, meaning that
field PV1-8 Referring Doctor shall always be sent when a message contains the PV1 segment
and the sending application has data for the field. It may be present otherwise. This change
affects the following IHE transactions: Patient Registration, Placer and Filler Order
Management, Procedure Scheduled and Patient Update.
Tables 4.1-3, 4.2-2, 4.4-2 and 4.12-4 and explanations following shall be modified as shown:
425
Table 4.7-1: Modifications to PV1-8

SEQ
LEN
DT
OPT
TBL#
ITEM#
ELEMENT NAME
. . .
8
60
XCN
R2
0010
00138
Referring Doctor
. . .
...
Field PV1-8 Referring Doctor shall be valued when a procedure is scheduled for an outpatient,
and the sending application has data for the field. It may be present otherwise.
4.8 HL7: ZBE Segment in ADT

430
435
The ZBE segment is an HL7 extension defined by the German Chapter of HL7. It introduces a
field called Movement ID which allows, upon the reception of a change message (e. g.
ADTÂ08), to exactly determine the original message (ADTÂ01, ADTÂ02) to which the
change is related. The following table contains an English translation of the original ZBE
definition table which is part of the German HL7, edition 2.3.1d and available online at
http://www.hl7.de/zregister/zbeweg.html.
__________________________________________________________________________
17
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
Table 4.8-1: Translation of IHE-Germany ZBE Table
DT
OPT
RP/#
EI
TS
3
4
SEQ
LE
N
TBL
#
ITEM#
ELEMENT NAME
49071
Movement ID
49072
Start of Movement Date/Time
TS
49073
End of Movement Date/Time
ST
49074
Reason for Triggering the Movement /

Processing Identifier (INSERT,
UPDATE, DELETE)
440
The use of this Z-segment is optional, but allowed and recommended in IHE-D for all ADT
messages.
445
Note: It is the intention of the IHE-D working group to declare support of the ZBE segment
mandatory for all ADT messages sent by an ADT actor in a future version of the German
Technical Framework Addendum. Implementations of an ADT actor according to this Technical
Framework Addendum are strongly recommended to support the ZBE segment.
__________________________________________________________________________
18
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
5 National Extensions for IHE United States
450
regional practice of healthcare in the U.S.A.
5.1 PID Segment

In the US, PID-18 Patient Account Number must be valued and PV1-19 Visit Number is required
when PID-18 identifies an account that spans more than one encounter or visit.
__________________________________________________________________________
19
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
455
6 National Extensions for IHE Italy
460
Technical framework. This section includes extensions and restrictions to effectively support the
regional practice of healthcare in Italy. It also translates a number of English terms to ensure
correct interpretation of requirements of the Technical Framework..
6.1 Comments
This national extension document was authored under the sponsorship and supervision of SIRM,
welcome comments on this document and the IHE Italy initiative. They should be directed to the
National Project Manager:
465
Claudio Saccavini
IHE-Italy project manager
Email: [email protected]
6.2 IHE-I 2003 Scope

470
475
profiles:
Scheduled Workflow
Key Image Notes
Simple Image and Numerical Report
Access to Radiology Information
Basic Security

480
The Specific Character Set (0008,0005) Attribute shall contain the value "ISO_IR 100" in order
6.4 Extended HL7 Character Set
485
Field MSH 18 shall contain the value "8859/1" in order to select the ISO 8859 Latin-1
characters.
__________________________________________________________________________
20
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
6.5 Translation of specific Fields of the PID Segment

La tabella sotto riporta la traduzione di alcunicampi specfici del segmento PID:
490
Table 6.5-1: Translation of PID Segment Fields

Campo (Field)
Traduzione/Traduction
Patient Identifier List

(PID 3)
Identificativivo univoco del paziente all'interno della singola struttura sanitaria.

Normalmente pu essere il codice sanitario
Legal Name (PID 5)
Cognome e Nome del paziente. Nel caso delle donne sposate non si utilizza ma il
cognome del marito.
Maiden Name (PID 5)
Campo non utilizzato in Italia
SSN Number Patient

(PID 19)
Numero della tessera sanitaria del Servizio Sanitario Nazionale della Regione di
Residenza del paziente.
Patient Account Number

(PID 18)
Codice Fiscale del Paziente
Campo (Field)
Traduzione/Traduction
6.6 Syntax Rules for PID-11 (Patient Address)

The ZIP or Postal Code will contain the "code postal".
Il "ZIP or Postal Code" dovr contenere il Codice di Avviamento Postale.
6.7 Translations of PV1-19, Visit Number

495
This number corresponds to physical visit of the patient into the hospital.
Questo numero corrisponde al numero di ricovero per i pazienti interni, o al numero di richiesta
nel caso di pazienti esterni.
6.8 Extensions of PV1-2 (Patient Class)

500
We introduce three new types of Patient Class, the Day Hospital, the After Dismission and the
Protected Dismission.
Sono stati introdotte tre nuove classi di paziente: il Day Hospital, il Post-Ricovero e la
Dimissione Protetta.
Table 6.8-1: Translation of PV1-2 Segment Fields Patient Class
Value
Description
Translation/Traduzione
Emergency
Paziente proveniente dal Pronto Soccorso
Inpatient
Paziente in Ricovero Ordinario
Outpatient
Paziente Esterno o Ambulatoriale
Preadmit
Paziente in Ricovero Programmato
Recurring Patient
Paziente con ricovero che prevede cicli di cura
__________________________________________________________________________
21
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
Value
505
Description
Translation/Traduzione
Obstetrics
Valore non utilizzato in Italia
Day Hospital
Paziente in regime di ricovero giornaliero
After Dismission
Paziente in regime di prestazioni di post-ricovero
Protected Dismission
Paziente in regime di Dimissione Protetta
6.9 Patient Account Number

Field PID-18 Patient Account Number is a required field in IHE Italy.
Il Campo PID-18 Patient Account Number obbligatorio per IHE-Italy

510
La tabella sotto riportata fornisce l'interpretazione dei Tipi Medici:
Table 6.10-1: Translation of Physician Types in PV1
Campo (Field)
Traduzione/Translaction
PV1-7Attending
doctor
Medico responsabile della cura del paziente durante il ricovero, il medico di medicina
generale nel caso di un paziente esterno o ambulatoriale
PV1-8Referring
doctor
Il medico che richiede la consulenza e che indicato come il destinatario della risposta
dello specialista.
PV1-9Consulting
doctor
Il medico che esegue la consulenza richiesta dal Referring Doctor
PV1-17 Admitting
doctor
Il medico che decide il ricovero del paziente
__________________________________________________________________________
22
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
7 National Extensions for IHE United Kingdom

7.1 Introduction
515
This Appendix to the IHE Technical Framework document shall be used in conjunction with the
Integration profiles defined in the body of the IHE Technical Framework, Revision 5.5. This
document includes provisions that must be implemented by UK participants in the European
Connectathon to be held in 2003.
7.2 Scope
520
Profiles:
Scheduled Workflow
525
7.3 HL7: PID-18 Patient Account Number

Field PID-18 Patient Account Number is not supported in the UK (i.e. ignored).
7.4 HL7: PV1-19 Visit Number

Field PV1-19 Visit Number shall contain a locally unique patient admission identifier
(Enterprise Visit Identifier).
530
7.5 HL7: PV1-8 Referring Doctor

Field PV1-8 Referring Doctor shall always be sent when a message contains the PV1 segment.
Note: In the Technical Framework, rev. 5.5, PV1-8 is only required for ADTÂ04 messages.
Note: In HL7 UK standard this field is optional
The table below shows PV1 Field Physician Types as given in IHE France specifics:
535
Field
Description
PV1-7
Attending
doctor:
The person primarily responsible for the care of the patient during a particular healthcare visit
(generally used for inpatient events, but could be extended to an outpatient visit as well.)
PV1-8
Referring
doctor:
Is any physician who referred the patient to the care of another physician (generally a
specialist) for a particular visit. The referring physician might be noted in an HL7 event so
that she/he receives a copy of any test results or documentation of care.
PV1-9
Consulting
doctor:
Is generally a specialist who sees a patient as the result of a referral or a consultation order.
She/he is not the attending physician for the case, although that status could be transferred to a
consulting physician at some point.
__________________________________________________________________________
23
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
Field
PV1-17
Admitting
doctor
Description
Is the physician who decides that a patient meets the criteria for an inpatient admission to a
hospital during a specific visit. The admitting physician is responsible for evaluating the
patient so that their acuity satisfies admission criteria.
7.6 DICOM: Support for ISO Latin 1
540
All actors with DICOM based transactions shall support the value ISO_IR 100 for the attribute
(0008,0005) Specific Character Set if this attribute is defined in the DICOM SOP class used by
the IHE transaction. This attribute value specifies the ISO 8859-1 (Latin 1) character set.
Note: this character set supports the Welsh language
7.7 HL7: Support for ISO Latin 1
545
8859-1 (Latin 1) character set (see Table 0211 in HL7 Appendix A).
Note: this character set supports the Welsh language
__________________________________________________________________________
24
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
8 National Extensions for IHE Canada
550
regional practice of healthcare in Canada. It also translates to French a number of English terms
to ensure correct interpretation of requirements of the Technical Framework.
8.1 Comments
555
This national extension document was authored by the Radiology committee of IHE Canada.
Comments and suggestions should be sent to:
Alain Gauvin, David Heaney, David Koff (co-chair) or Rita Noumeir (co-chair)
Email: [email protected] , [email protected] ,
[email protected] or [email protected]
560
The extensions, restrictions and translations specified apply to the radiology technical framework
of IHE.

The Specific Character Set (0008,0005) Attribute shall contain the value ISO_IR 100 in order
565
8.3 Extended HL7 Character set

Field MSH 18 shall contain the value 8859/1 in order to select the ISO 8859 Latin-1
characters.
8.4 Translation of Specific Fields of the PID Segment

570
La table ci-dessous fournit la traduction de champs spcifiques du segment PID.
Table 8.4-1: Translation of PID Segment Fields or component values
Champ (Field)
Patient Identifier List (PID 3)
Numro de dossier
Legal Name (in table 0200 for name type in PID 5)
Nom de famille
Maiden Name (in table 0200 for name type in PID 5)
Nom de fille
Display Name (in table 0200 for name type in PID 5)
Nom usuel
SSN Number Patient (PID 19) This is the personal
Numro de Scurit Social du patient.
__________________________________________________________________________
25
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
Champ (Field)
social security number of the patient which may not be
the social security number used for the insurance billing
payment.
Patient Account Number (PID 18) Unique identifier
for collecting and grouping all elements necessary for
charging AND / OR the transmission to the insurance
company for charging.
Numro de compte patient Numro unique qui permet

de collecter et de grouper tous les lments
ncessaires la facturation ET / OU la transmission
vers les organismes d'assurances et mutuelles, pour
prise en charge
8.5 Syntax Rules for PID-5 (Patient Name)

575
Last name prefix (<family name (ST) & <last_name_prefix (ST)>) will be used for names with
particule . Prefix sera utilis pour la particule des noms particules.
8.6 Extensions of PID-16 (Marital Status)

One value, G for Living Together shall be added to the The Marital Status table 002 of HL7
2.3.1 (User defined table).
580
Note: The value G has been obtained from HL7 2.4.

Table 8.6-1: Translation of PID-16, Marital Status
Valeur
Description
Separated
Spar
Divorced
Divorc
Married
Mari
Single
Clibataire
Widowed
Veuf/Veuve
Living together
Concubin
8.7 Translations of PV1-2 (Patient Class) and Selection of Values

The value D, for Day hospital or Hospitalisation dun jour shall be added to the table 0004.
585
8.8 Visit number usage and interpretation

PV1-19 (Visit Number) is an identifier for the visit or consult episode.
If Field PV1-2 is I Inpatient then PV1-19 is interpreted as visit number, or n de sjour.
If Field PV1-2 is D Day Patient then PV1-19 is interpreted as visit number, or n de sjour.
590
If Field PV1-2 is O Outpatient then PV1-19 is interpreted as consult number, or n de

consultation.
__________________________________________________________________________
26
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
If Field PV1-2 is R Recurring Inpatient then PV1-19 is interpreted as session number, or n
de sance.

The optionality status of PV1-8 is R for the Canadian implementation.
595
La table ci-dessous fournit la traduction de champs relatif aux types de mdecins dans PV1:
Table 8.9-1: Translation of PV1 Physician Types
Field
Description
PV1-7 Attending doctor:
The person primarily responsible

for the care of the patient during a
particular health care visit
(generally used for inpatient
events, but could be extended to an
outpatient visit as well.)
Mdecin traitant.
PV1-8 Referring doctor
Is any physician who referred the

patient to the care of another
physician (generally a specialist)
for a particular visit. The referring
physician might be noted in an
HL7 event so that she/he receives
a copy of any test results or
documentation of care.
Mdecin rfrant.
PV1-9Consulting doctor
Is generally a specialist who sees a

patient as the result of a referral or
a consultation order. She/he is not
the attending physician for the
case, although that status could be
transferred to a consulting
physician at some point.
Le mdecin qui est consult pour

un deuxime avis.
PV1-17 Admitting doctor
Is the physician who decides that a

patient meets the criteria for an
inpatient admission to a hospital
during a specific visit. The
admitting physician is responsible
for evaluating the patient so that
their acuity satisfies admission
criteria.
Mdecin responsable de
ladmission.
__________________________________________________________________________
27
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
9 National Extensions for IHE Spain

600
regional practice of healthcare in Spain. IHE Spain provides a translation tool to ensure correct
interpretation of requirements of the Technical Framework (see www.ihe-e.org).
605
9.1 Comments
IHE-Spain (from now on IHE-E) welcomes comments on this document and the IHE Spain
initiative. Comments can be directed to the IHE-E technical manager, following the links of the
IHE-E web site: www.ihe-e.org.
9.2 IHE-E: Scope of 2007s National Extension

610
The extensions, restrictions and translations specified apply to HL7 and DICOM requirements as
used in IHE integration profiles: such as Scheduled Workflow.
9.3 1.3 IHE-E: Translation of IHE terms into Spanish
615
A JAVA tool has been developed to support the translation of the main IHE terms into Spanish.
This tool provides a dictionary that contains integration profiles, actors and transactions, and for
each one, the domain/TF document where they are referenced (if applicable), acronym, the
translation of the term into Spanish, and a short description.
The last version of this JAVA tool can be downloaded from the web site of the Spanish IHE
initiative (www.ihe-e.org).
9.4 Support for ISO Latin 1

620
9.4.1 HL7
8859 (Latin 1) character set.
Note: this character set supports all languages which are official in Spain.
625
9.4.2 DICOM
All actors with DICOM based transactions shall support the value ISO_IR_100 for the
attribute (0008, 0005) Specific Character Set if this attribute is defined in the DICOM SOP
class used by the IHE transaction. This attribute specifies the ISO 8859-1 (Latin 1) character set.
Note: this character set supports all languages which are official in Spain.
__________________________________________________________________________
28
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
630
9.5 Patient Identification Data

This section is intended to give an orientation in the use of the main attributes related to the
patient entity and which can be subject to an ambiguous interpretation. Likewise, we will focus
in the use or adoption or codifications that allow a higher interoperability between systems.
9.5.1 Spanish naming convention: the second family name
635
In Spain, people use two family names. In this document they will be referred to as the first
family name and the second family name. The first family name is the fathers first family name
and the second family name is the mothers first family name.
For instance, Picasso is known for his second family name. His real name was Pablo Ruiz
Picasso, son of Jos Ruiz Blasco, and Maria Picasso Lopez.
640
Another example useful for non-Spanish readers: The daughter of the actors Antonio Banderas
and Melanie Griffith is named Estela Banderas Griffith.
Note that, as women in Spain dont change names when they get married, a persons second
family name is as well his/her mothers maiden name.
645
The patients second family name is an essential attribute for a persons identification in Spain.
However, if a person is not of Spanish descent, it is possible that he or she does not have a
second family name
Handling particles
650
It is quite common in Spain that names have particles. Some examples of this are Felipe de
Borbon y Grecia or Teresa Garcia de la Vega. These particles are not handled consistently across
hospitals (or other information systems) and its codification is beyond the scope of this national
extension. Common solutions are either adding de particle at the end of the name (|BORBON>Y
GRECIA^FELIPE DE|) or before the surname (|DE BORBON>Y GRECIA^FELIPE)|
9.5.2 HL7
655
Most of the identification data of a patient are specified in the PID segment as described in the
table below (Table 1. PID attributes, HL7 version 2.3.1. Chapter 3, section 3.4.2)
Table 9.5.2-1: IHE profile PID Segment
SEQ
LEN
DT
OPT
RP/#
TBL#
ITEM
#
ELEMENT NAME
SI
00104
Set ID PID
20
CX
00105
Patient ID
20
CX
00106
Patient Identifier List
20
CX
00107
Alternate Patient ID PID
48
XPN
00108
Patient Name
48
XPN
00109
Mothers Maiden Name
__________________________________________________________________________
29
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
SEQ
LEN
DT
OPT
RP/#
26
TS
IS
48
XPN
10
80
CE
11
106
XAD
12
IS
13
40
XTN
14
40
XTN
15
60
CE
16
80
CE
17
80
18
TBL#
ITEM
#
ELEMENT NAME
00110
Date/Time of Birth
00111
Sex
00112
Patient Alias
00113
Race
00114
Patient Address
00115
County Code
00116
Phone Number Home
00117
Phone Number Business
0296
00118
Primary Language
0002
00119
Marital Status
CE
0006
00120
Religion
20
CX
00121
Patient Account Number
19
16
ST
00122
SSN Number Patient
20
25
DLN
00123
Drivers License Number - Patient
21
20
CX
00124
Mothers Identifier
22
80
CE
00125
Ethnic Group
23
60
ST
00126
Birth Place
24
ID
00127
Multiple Birth Indicator
25
NM
00128
Birth Order
26
80
CE
0171
00129
Citizenship
27
60
CE
0172
00130
Veterans Military Status
28
80
CE
0212
00739
Nationality
29
26
TS
00740
Patient Death Date and Time
30
ID
00741
Patient Death Indicator
0001
0005
0289
0189
0136
0136
660
9.5.2.1 Second family name

Patients second family name
665
Amongst the fields defined for the PID segment, there is no specific location for the second
family name. In most current implementations, the field selected to convey this information is
PID-6 Mothers Maiden Name (XPN). This is a composed data type, whose description
according to HL7 v2.3.1 is the following:
XPN Components: <family name (ST)> & <last_name_prefix (ST)> ^ <given name (ST)> ^ <middle initial or
name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <name type
code (ID) > ^ <name representation code (ID)>
__________________________________________________________________________
30
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
The second name shall be positioned in the following XPN route:
670
PID-6 Mothers maiden name Family Name

However, this solution cant be extended to reporting other second family names, i.e. attending
doctor. To achieve a rule that is consistent for reporting second family names of all persons
involved, it is suggested that the second family name is coded as a subcomponent of the patients
family name as well.
675
Therefore the component <family name (ST)> can have two parts the first family name and the
second family name, separated by a >, as shown in the following example:
|BANDERAS>GRIFFITHÊSTELA|
As people who are not Spanish descendants may not have second family name this field PID-6 is
not required to be filled.
680
Professionals second family name
The second family name is used for any persons, including patients. An example can be the name
of the physician visiting a patient (i.e. PV1 9, Consulting Doctor XCN).
685
In HL7 v2.3.1 a subcomponent of the family name component can be used in the same way is
done for the patient name.
In v2.5 the definition for XCN data type is changed, and it is recommended to place both patient
and professional names of XCN fields such as Consulting Doctor, in the following XCN route:
Field x Second and Further Given Names or Initials Thereof
9.5.2.2 Patient Identifiers
690
The identifier associated to a patient shall be located in the PID-3 Patient Identifier List field.
According to HL7 v2.3.1 the patient identifier list is defined as follows.
PID-3 Patient identifier list (CX)
695
00106
Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check
digit scheme employed (ID)> ^ <assigning authority (HD)> ^
<identifier type code (IS)> ^ <assigning facility (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID
(ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID
(ST)> & <universal ID type (ID)>
700
This is a mixed type that allows great flexibility of use due to its subcomponents. With the goal
of simplifying the patient identifiers management, the use of the components shown in Table 2
is required.
__________________________________________________________________________
31
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
Table 9.5.2-2: HL7 v2.3.1 PID-3
705
PID-3 Patient identifier list (CX)
Identifier code (i.e.
43678234V or
DAAS223446778999)
id number (ST)
check digit (ST)
check digit Scheme (ID)
Assigning authority (i.e. ministerio interior,

servicio de salud de la comunidad xx,
Clinica privada yy
assigning authority (HD)

namespace ID (IS)
universal ID (ST)
universal ID type (ID)
Type of identifier (i.e identificador interno

del paciente, documento nacional
identidad, numero seguridad social)
identifier type code (IS)

assigning facility (HD)
namespace ID (IS>
universal ID (ST)
universal ID type (ID)>
710
There are many approaches for the management of these identifiers (for more details in other
possible strategies see [1]). The technical subcommittee has decided to use specific values for
assigning authorities and identifier type codes. These are summarized in Table 3. The last
column, assigning jurisdiction is a field added in v2.5, and is shown here only as a
recommendation for future v2.5 implementations.
Table 9.5.2-3: Spains local codes for HL7 v2.3.1 PID-3, assigning authority fields
Description
Codes to be used
Identifier
(Spanish
name)
Identifier
(English description)
Assigning Authority
Identifier
Type
Code
DNI
National identify card
NamespaceID: MI
NNESP
Pasaporte
Passport
NamespaceID: MI
PPN
Assigning Jurisdiction
(recommendation for
V2.5)
2
Identifier ESP Name of

Coding System: ISO3166 (3
char)
2
Identifier ESP Name of
The last 3 characters correspond to the ISO3166 code (3 characters) of the country that issues the document. See
reference [6].
This applies only for Spain. For other countries, their ISO codification should be taken into.
__________________________________________________________________________
32
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
Description
Identifier
(Spanish
name)
Identifier
(English description)
Codes to be used
Assigning Authority
Identifier
Type
Code
Assigning Jurisdiction
(recommendation for
V2.5)
char)
715
Trajeta
residencia
Spanish identity card for

foreigners resident in
Spain
NamespaceID: MI
PRC
Nmero
afiliacin
Seguridad
Social
Social Security id
NamespaceID: SS
SS
CIP
autonmico
Regional authority
unique patient identifier
NamespaceID:CAXX
CIP del SNS
National health authority

unique patient identifier
CIP europeo
ID interno
Identifier: ESP Name of

char)
Coding System: ISO3166
(3 char)
JHN
Identifier: AN, AR, ..

Name of Coding System:
4
ISO3166-2
Namespace ID: MS
HC

char)
European patient
identifier
NamespaceID: TSE
HC
Identifier: EU Name of
Coding System: ISO3166
Internal patient identifier
Definition pending
PI
Definition pending
9.5.2.3 Contact Data

For the contact data (mail, telephone, etc.) the use of PID-13 Phone Number Home shall be
used. This field is of the type XTN (extended telecommunication number data type)
The following fields shall be used:
720
725
phone number (NM): this field contains the telephone number (without country code)
telecommunication use code: in this field the values suggested in the HL7 0201 table
shall be used.
telecommunication equipment type: in this field, the values suggested in the HL7 0202
shall be used.
country code: the international code for Spain, +34, is optional. Foreign international
codes shall be filled in.
9.5.2.4 Address Data

The field used in the PID segment to store the possible addresses of the patient is PID-11 Patient
Address.
3
The ISO code should be replaced with the regional authority (Comunidad autonoma - CA) ISO (see following note). See
reference [5] for autonomous regions codification.
ISO regional authority (CCAA) Codification. See reference [5].
__________________________________________________________________________
33
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
Components: <street address (ST)> ^ <other
(ST)> ^ <state or province (ST)> ^ <zip
<country (ID)> ^ < address type (ID)> ^
designation (ST)> ^ <county/parish code
^ <address representation code (ID)>
730
735
designation (ST)> ^ <city

or postal code(ST)> ^
<other geographic
(IS)> ^ <census tract (IS)>
To identify the type of address, it is recommended that the values from the HL7 table 0190 be
used in the following way:
Table 9.5.2-4: Spains recommended local codes for address type
Type of address
740
Address Type Field
Fiscal (tax)
Empadronamiento (city register)
Contacto (contact)
Empresa (company)
Desplazado (temporal)
In the event that the address type is not filled in, the address is considered to be the city
registers postal address (H).
The components of the address field are recommended to be used as follows:
Table 9.5.2-5: Spains recommended interpretation for HL7 v.2.3.1 PID-11 components.
PID-11 component
745
Recommended
interpretation
Recommended coding
scheme
Street Address
Tipo de va, nombre de la va

y nmero de la va
n/a
City:
Municipio
INE code
State or Province:
Provincia
INE code
Zip or postal code
Cdigo Postal
Country
Pas
Other geographic designation
Poblacin
ISO3166 (3 characters)
6
n/a
In version 2.5 the street address component is modified to include a set of subfields. The
recommendation for future v2.5 implementations is:
Spains recommended interpretation for HL7 v.2.3.1 PID-11 components.
Only used in case that the name of the city does not match the name of the INE codified district.
__________________________________________________________________________
34
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
Table 9.5.2-6: Spains recommended interpretation for HL7 v.2.5 PID-11 Street address
subfields.
Subfields of Street Address
component
Recommended interpretation
Street or mailing address
Tipo de va
Street name
Nombre de la va
Dwelling number
Nmero de la va
750
9.5.3 DICOM: Patient Identification Module
755
The DICOM Standard provides definitions for the information objects [9]. Most of the
identification data of a patient are specified in the Patient Modules. (DICOM 2007 PS 3.3.
Patient Identification Module). Patient Identification Attributes are summarized in DICOM 2007
PS 3.3. Table C.2-2.
9.5.3.1 Second family name
Attribute Patients Name (0010, 0010) has a value representation ([10] 6.2. Value
Representation, VR) of person name (PN), which does not allow to distinguish [11] between the
first and the second family name.
760
Amongst the patients personal data fields available in the Patient Identification Modules, there
is as well no specific location for the second family name.
Therefore, it is recommended that the first and second family names are placed in the first
component of PN, family name, in the above mentioned order, using the character > (ANSI
003E hex) as delimiter.
765
Other Patient Name (0010,1001) attribute was not chosen to specify second family name because
there are other Names in the system such as the Referring Physician which can be encoded in the
same way.
770
775
Other examples besides the Referring Physicians Name (0008, 0090), are Performing
Physicians Name (0008, 1050), Name of Physicians Reading Study (0008, 1060), Operators
Name (0008, 1070), Names of Intended Recipients of Results (0040,1010), Order Entered By
(0040,2008), Human Performers Name (0040,4037), Verifying Observer Name (0040,A075),
Content Creators Name (0070,0084), Reviewer Name (300E,0008), Interpretation Recorder
(4008,0102), and Interpretation Transcriber (4008,010A).
9.5.3.2 Patient Identifiers
The main patient identifier shall be reported in:
(0010, 0020)
Patient ID
__________________________________________________________________________
35
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
(0010, 0021)
780
785
Issuer of Patient ID (Corresponds to HL7 Assigning authority,

see Table 3 for recommended codes)
In some cases the Assigning authority alone is not enough to ensure a unique interpretation of the
patient id (see Table 3), and additional information regarding the Identifier Type Code is
needed. This is supported in HL7 v2.3, but not in the current DICOM specification. Please note
that this issue may lead to errors if an assigning authority uses only the identifier type code to
distinguish between the patient identifiers.
To code more than one patient identifier, the attribute (0010,1002) "Other Patient IDs Sequence
(PS 3.3 - 2007 Page 242) can be used.
9.6 Insurance Data

790
This section recommends a representation for insurance data. It focuses on the identification of
the Insurance Company and does not cover the specific conditions of the insurance. This last
aspect depends mainly on implementation and it goes beyond the aim of this national extension.
The proposal for the identification of the patients main insurance data can be found in document
[8].
795
9.6.1 HL7: Insurance Data Mapping

The following table (Table 8) describes the elements of the HL7 v2.3.1 IN1 segment (chapter 6,
section 6.4.6) that shall be used and their recommended interpretation. Fields 1,2 and 3 are
required according to HL7v2.3.1 definition.
800
IN1 segment should not be sent if the information in IN1-3 (Insurance company ID) is not
relevant.
Table 9.6.1-1: Spains recommended interpretation for HL7 v.2.3.1 IN1
IN1 Field
Optionality
In1-1 Set id IN1
Number that identifies the transaction. If the patient

has more than one insurance company, the
message shall be repeated for each company, using
a different transaction ID.
Required
In1-2 Insurance
Plan ID
Coverage Plan identifier.
Required
In1-3 Insurance
Company ID
Unique company identifier.
Required
In1-4 Insurance
Company Name
Name of the company. We suggest repeated use of

this field to identify the name of the companys
delegation.
Optional
In1-12 Plan
effective date
The date the Coverage Plan comes into force.
Optional
__________________________________________________________________________
36
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
IN1 Field
Optionality
In1-13 Plan
expiration date
The date the Coverage Plan finishes.
Optional
In1-36 Policy
Number
Policy number.
Optional
9.7 Examples
805
9.7.1 HL7 Example 1

The first example provided is the PID information of a patient living in the Extremadura region.
Only information addressed within this document is shown.
Datos del paciente
Nombre
Primer Apellido
Segundo Apellido
Identificadores
DNI
CIP autonmico
Nmero afiliacin Seguridad Social
Identificador interno del HIS
Datos de contacto
Telfono de casa
Mvil
Correo electrnico
Direcciones
Direccin de empadronamiento
Tipo de va
Nombre de la va
Nmero
Piso
Escalera
Cdigo Postal
Municipio
Poblacin
Provincia
Pas
Direccin de contacto
Tipo de va
Nombre de la va
Nmero
Piso
Escalera
Cdigo Postal
Municipio
Poblacin
Patient data
Name
First family name
Second family name
Identifiers
National identity card
Regional authority unique patient
identifier
Social Security id
Internal patient id at the HIS
Contact information
Home phone
Cell phone
e-mail
Adresses
Address for the city register
Street type (avenue, square,..)
Street name
Street number
Floor
Stair
Zip code
City
City
Province
Country
Contact address
Street type
Street name
Street number
Floor
Stair
Zip code
City
City
Manuel
Fernndez
Ferrer
37456765V
CAEX123456789088
(extremadura =EX)
061081880847
9987765
924678564
659877877
[email protected]
Avenida
Alange
8
4-3
B
06800
Mrida
Mrida
Badajoz
Espaa
Calle
Constitucin
34
1-C
06800
Mrida
Mrida
__________________________________________________________________________
37
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
Provincia
Pas
810
Province
Country
Badajoz
Espaa
The location of these data in an HL7 message would be the following:

PID-3 Patient
identifier List
ID Number
Assigning Authoriy
37456765V
Namespace ID
MI
NNESP
CAEX123456789088
Namespace ID
CAEX
JHN
61081880847
Namespace ID
SS
SS
9987765
Namespace ID
HC
PI
Surname
Fernndez
Manuel
Surname
Ferrer
Identifier Type Code

ID Number
Assigning Authoriy
ID Number
Assigning Authoriy
ID Number
Assigning Authoriy
PID-5 Patient Name
PID-6 Mother's Maiden

Name
PID-11 Patient Address
PID-13 Phone Number Home

Family Name
Given Name
Family Name
Given Name
Street Address
Other Designation
City
State or Province
Zip or Postal Code
Country
Address Type
Other Geographic Designation
Street Address
Other Designation
City
State or Province
Zip or Postal Code
Country
Address Type
Other Geographic Designation
Telecommunication Use Code
Telecomm. Equipment Type
Country code
Phone Number
Country code
Phone Number
Email Address
Avenida Alange 8 4-3 Escalera B

06083
06
06800
ESP
H
Calle Constitucin 34 1 - C
06083
06
06800
ESP
M
PRN
PH
+34
924678564
WPN
CP
+34
659877877
NET
Internet
[email protected]
And the corresponding PID segment in a message would be:
815
PID|
1|
__________________________________________________________________________
38
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
820
825
37456765V^^^MI&&^NNESP^~
CAEX123456789088^^^CAEX&&^JHN^~
61081880847^^^SS&&^SS^~
9987765^^^HC&&^PI^~||
FERNANDEZ>FERRER^MANUEL|
FERRER||
F|||
Avenida Alange 8 4-3 Escalera B^^06083^06^06800ÊSP^H^^^^~
Calle Constitucin 34 1 - C^^06083^06^06800ÊSP^M^^^^||
^PRN^PH^^^924678564~
^WPN^CP^^^659877877~
^NET Internet^^^[email protected]
9.7.2 HL7 Example 2
830
This example shows the data of a patient admitted in the Emergency Room of the Hospital
Virgen de la Salud at Toledo (Castilla La Mancha Region).
Datos del paciente
Nombre
Primer Apellido
Segundo Apellido
Fecha de nacimiento
Identificadores
DNI
CIP autonmico
Identificador interno del HIS
Datos de contacto
Telfono de casa
Otro telfono de contacto
Mvil
Correo electrnico
Direcciones
Direccin de contacto
Nombre de la va
Cdigo Postal
Municipio
Poblacin
Provincia
Pas
Patient data
Name
First family name
Second family name
Date of birth
Identifiers
National identity card
Regional authority unique patient identifier
Social Security id
Internal patient id at the HIS
Contact information
Home phone
Secondary contact telephone
Cell phone
e-mail
Adresses
Contact address
Street name
Zip code
City
City
Province
Country
Estela
Banderas
Griffith
June 1st, 1970
00000001R
HOPN700641916019
2803800541502
40004
925 123 456
925 654 321
660 445 566
Plaza de Alfares 2 , Apt. 2 A

45002
Toledo
Toledo
The patient identifiers are coded as follows:

CIP autonomico
HOPN700641916019^^^CACM&&^JHN^
DNI
00000001R^^^MI&&^NNESP^
Identificador interno del HIS (Nmero de historia

clnica)
40004^^^PI&&^
__________________________________________________________________________
39
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
835
2803800541502^^^SS&&^SS^
The address is coded taking into account that the code for the city of TOLEDO is (45 1685) and
the province of is TOLEDO(45) 45002 ESP M
Plaza de Alfares 2, Apt. 2 A^451685^45^45002^ ESP^M
The resulting patient identification segment (PID) is as follows:
840
845
850
PID|1|HOPN700641916019^^CACM&&^JHN^~
00000001R^^MI&&^NNESP^~
40004^^^PI&&^^^~
2803800541502^^SS&&^SS^^^~||
BANDERAS>GRIFFITHÊSTELA|
GRIFFITH|
19700601|
F|||
Plaza de Alfares 2 , Apt. 2 A^451685^45^45002^ ESP^M||
^PRN^PH^^^925123456~
ÔRN^PH^^^925654321~
ÔRN^CP^^^660445566
9.7.3 DICOM Example 1
855
The patient information described in section 9.7.1 HL7 example 1 would be codified as follows
in DICOM.
TAG
Value
(0010,0010)
FERNANDEZ>FERRER^MANUEL
(0010,0020)
9987765
(0010,0021)
PEND
(0010,1002)
(0010,0020)
CAEX123456789088
(0010,0021)
CAEX
(0010,0022)
TEXT
(0010,0020)
61081880847
(0010,0021)
SS
(0010,0022)
TEXT
(0010,0020)
37456765V
(0010,0021)
MI
(0010,0022)
TEXT
__________________________________________________________________________
40
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
(0010,1040)
Avenida Alange 8 4-3 Escalera B
(0010,1060)
FERRER>
(0010,2150)
ESP
(0010,2152)
06083
(0010,2154)
+34924678564 / +34659877877
9.7.4 DICOM Example 2

860
The patient information described in section 1.7.2 HL7 example 2 would be codified as follows
in DICOM.
TAG
Value -according to option 1
(0010,0010)
BANDERAS>GRIFFITHÊSTELA
(0010,0020)
40004
(0010,0021)
PEND
(0010,0022)
TEXT
>(0010,1002)
>(0010,0020)
2803800541502
>(0010,0021)
SS
>(0010,0022)
TEXT
>(0010,0020)
00000001R
>(0010,0021)
MI
(0010,0022)
TEXT
(0010,1040)
Plaza de Alfares 2, Apt. 2 A
(0010,1060)
GRIFFITH
(0010,2150)
ESP
(0010,2152)
451685
(0010,2154)
+34925123456 / +34925654321 / +34660445566
9.8 References
865
[1] Proposal for Identifiers Management

(Technical Subcommittee HL7 Spain, http://www.hl7spain.org/)
[2] Minutes of Meeting Technical Subcommittee ADT 03-02-2005
[3] Minutes of Conference Call Technical Subcommittee ADT 14-02-2005
870

__________________________________________________________________________
41
Rev. 13.0 Final Text 2014-07-30

______________________________________________________________________________
[4] Minutes of Meeting Technical Subcommittee ADT 10-03-2005
[5] ISO Codification for Regions (autonomous regions) in Spain
(ISO, http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/nli-4.pdf)
875
[6] ISO Codification for Countries

(ISO, http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_31661_decoding_table.html#EU)
[7] INE Codification for Districts and Provinces
(http://www.ine.es/inebase/cgi/um?M=%2Ft20%2Fe245%2Fcodmun&O=inebase&N=&L=0)
880
[8] Proposal for Insurance data associated with the patient

[9] DICOM 2007 Part 3: IOD, information Object Definitions
[10] DICOM 2007 Part 5, Data Structures and Encoding
885
[11] ANSI HISPP MSDS: COMMON DATA TYPES for Harmonization of Communications
Standards in Medical Informatics
__________________________________________________________________________
42
Rev. 13.0 Final Text 2014-07-30

IHE Radiology (RAD) Technical Framework: Integrating The Healthcare Enterprise

Uploaded by

Copyright:

Available Formats

IHE Radiology (RAD) Technical Framework: Integrating The Healthcare Enterprise

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IHE Radiology (RAD) Technical Framework: Integrating The Healthcare Enterprise

Uploaded by

Copyright:

Available Formats

Integrating the Healthcare Enterprise

IHE Radiology (RAD)

Revision 13.0 Final Text

Copyright 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions

Copyright 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions

6 National Extensions for IHE Italy ............................................................................................ 20

Copyright 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions

1.1 Overview of Technical Framework

Copyright 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions

1.2 Overview of Volume 4

Copyright 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions

2 Overview of National Extensions to the Technical Framework

The goal of IHE is to promote implementation of standards-based solutions to improve workflow

2.1 Scope of National Extensions

2.2 Process for Developing National Extensions

Copyright 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions

2.3 Process for Proposing Revisions to the Technical Framework

In addition to developing national extension documents to be incorporated in the Technical

Copyright 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions

3 National Extensions for IHE France

3.2 IHE-F 2002 Scope

3.3 Extended DICOM Character Sets

3.4 Extended HL7 Character set

3.5 Translation of Specific Fields of the PID Segment

Copyright 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions

Patient Identifier List (PID 3)

IPP (Identifiant Permanent du Patient)

Legal Name (PID 5)

Maiden Name (PID 5)

Nom de jeune fille

Display Name (PID 5)

SSN Number Patient (PID 19) This is the

Numro de Scurit Social du patient.

Patient Account Number (PID 18) Unique

Numro de compte patient Numro unique qui permet de

3.6 Insurance Information

Adapted from the HL7 Standard, version 2.3.1

Table 3.6-2: IHE profile IN2 Segment

Insured Social Security Number

Copyright 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions

3.7 Forbidden PID Fields

3.8 Syntax Rules for PID-5 (Patient Name)

3.9 Syntax Rules for PID-11 (Patient Address)

3.10 Extensions of PID-16 (Marital Status)

3.11 Translations of PID-16 (Marital Status) and Selection of Values

Pacte Civil de Solidarit (PACS)

3.12 Translations of PV1-19, Visit Number

Copyright 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions

La Table ci-dessous donne la traduction de champs specifiques du segment PV1: