Integrating the Healthcare Enterprise

5

10

IHE Radiology (RAD)Technical Framework
Volume 4
IHE RAD TF-4
National Extensions

15

20

Revision 13.0 – Final Text
July 30, 201425

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 .............................................................................. 123.16 Patient Account Number ................................................................................................... 123.17 Translations of PV1-4 (Admission Type) and Selection of Values .................................. 123.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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

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 ................................................................................................... 226.10 Extension and Translations of Physician Types in PV1 ................................................... 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
8.9 Extension and Translations of Physician Types in PV1 ................................................... 27
9 National Extensions for IHE Spain .......................................................................................... 28
9.1 Comments ......................................................................................................................... 28
9.2 IHE-E: Scope of 2007’s 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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

1 Introduction
110

115

120

125

130

Integrating the Healthcare Enterprise (IHE) is an initiative to promote the use of standards toachieve interoperability of health information technology (HIT) systems and effective use ofelectronic health records (EHRs). IHE provides a forum for volunteer committees of careproviders, HIT experts and other stakeholders in several clinical and operational domains toreach consensus on standards-based solutions to critical interoperability issues. IHE publishes theimplementation guides they produce (called IHE profiles), first to gather public comment andthen 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 isincorporated 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 canpublish 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 theactivities 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 anddefines 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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
145

150

1.2 Overview of Volume 4This 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 forapproval 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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

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 thedevelopment of IHE National Deployment Committees to address issues specific to local healthsystems, 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 specificlocal 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 andconfidentiality• 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 toaddress. 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 anational 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 foundin sections 4-6 of the current document. They submit this draft document to the IHE TechnicalCommittee 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 theannual 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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

2.3 Process for Proposing Revisions to the Technical Framework190

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 besubmitted directly to the IHE Technical and Planning Committees. The initial submission of suchproposed 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 necessityof 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 theirdisposition. 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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

215

3 National Extensions for IHE France

220

The national extensions documented in this section shall be used in conjunction with thedefinitions 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 theregional 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: kbourquard@yahoo.fr

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
La table ci-dessous fournit la traduction de champs specific du segment PID.
Table 3.5-1: Translation of PID Segment Fields
Champ (Field)

Interprétation/Traduction

Patient Identifier List (PID – 3)

IPP (Identifiant Permanent du Patient)

Legal Name (PID – 5)

Nom patronymique

Maiden Name (PID – 5)

Nom de jeune filleDisplay Name (PID – 5)

Nom usuel

SSN Number Patient (PID – 19) This is the
personal social security number of the patientwhich may not be the social security number used
for the insurance billing payment.

Numéro de Sécurité 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.

Numéro de compte patient Numéro unique qui permet decollecter et de grouper tous les éléments nécessaires à lafacturation ET / OU à la transmission vers les organismesd'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 purposeof 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 patientcharge 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#

1

4

SI

R

Set ID – IN1

2

60

CE

R

Insurance Plan ID

3

59

CX

R

Insurance Company ID

260

ITEM#

ELEMENT NAME

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

1

60

XON

O

Insured Employee ID

2

60

XON

O

Insured Social Security Number__________________________________________________________________________
9
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
Adapted from the HL7 Standard, version 2.3.1
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 thistable.
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
ValeurDescription

Interprétation/Traduction

A

Separated

Séparé

D

Divorced

DivorcéM

MarriedMarié

SSingleCélibataireW

Widowed

Veuf/Veuve

G

Living together

ConcubinP

Domestic Partner

Pacte Civil de Solidarité (PACS)

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
Ce numéro 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

Interprétation/Traduction

Visit Number (PV1 – 19)

Numéro de séjour / numéro 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 shallextend this table.
Note: The Addition of the W, S and K values will be submitted to the HL7 French Chapter whencreated.

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 Classet ne doit pas être étendue:

305

Table 3.14-1: PV1-2 Values and Translations
ValeurDescription

Interprétation/Traduction

E

Emergency

Urgence

I

Inpatient

HospitaliséO

Outpatient

ExterneP

Preadmit

Peut comprendre les catégories
nationale : Hospitalisation
programmées, Consultants
externes programmés, Psychiatrie
programmées, Résidents
programmésR

Recuring Patient

Résident

B

Obstetrics

ObstétriqueD

Day hospital

Hopital du jourW

Week hospital

Hopital de semaine

S

Psychiatric

Psychiatrie__________________________________________________________________________
11
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
ValeurK

310

Description

Interprétation/Traduction

NewbornNouveau 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 l’admission d’un patient dans cette catégorie, letype d’admission sera précisé 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 séjour.
If Field PV1-2 is « D or W » then PV1-19 is interpreted as n° de séjour.
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 séance.

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:
ValeurDescription

Interprétation/Traduction

A

Accident

Accident de travail

CElective

Confort (chirurgie esthétique…)

E

Emergency

Urgence

L

Labor and Delivery

Accouchement

N

Newborn (Birth in Healthcare
facility)

Nouveau NéR

RoutineRoutineU

UrgentUrgent__________________________________________________________________________
12
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

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

Interprétation/Traduction

PV1-7Attending doctor:

The person primarily responsible
for the care of the patient during aparticular health care visit(generally used for inpatient
events, but could be extended to an
outpatient visit as well.)

Médecin responsable pendant ladurée de l’admission.

PV1-8Referring doctor

Is any physician who referred thepatient to the care of anotherphysician (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.

Médecin (en général extérieur àl'établissement) qui a adressé lepatient.

PV1-9Consulting doctor

Is generally a specialist who sees apatient as the result of a referral ora consultation order. She/he is not
the attending physician for thecase, although that status could betransferred to a consulting
physician at some point.

Le médecin qui est consulté pourun deuxième avis.

PV1-17 Admitting doctor

Is the physician who decides that apatient meets the criteria for an
inpatient admission to a hospitalduring a specific visit. The
admitting physician is responsible
for evaluating the patient so that
their acuity satisfies admission
criteria.

Médecin de l'établissement qui
décide d’hospitaliser un patient.
(ex. En cas d’urgence)

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
ValeurV

Description
Visit

Interprétation/Traduction
Venue__________________________________________________________________________
13
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

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 definedtable). No IHE-F implementation shall extend this table.

3.21 Translation of PV2-3 (Admit Reason) and Selection of ValueIn 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 d’une hospitalisation d’un patient en psychiatrie alors on devra utiliser le champ
PV2-3 Admit Reason afin de préciser le mode de placement.
Table 3.21-1: PV2-3 Interpretation of Values
CodeMode de placement

HL

Hospitalisation Libre

HO

Placement d’office

HDT

Hospitalisation à la demande d’un tiers

LV

Levée d’hospitalisation

SE

Sortie à l’essai

3.22 Management of Functional Units
350

355

A major difference between the management of responsibilities between the USA and France isthat 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 différence entre la manière dont les responsabilités sont gérées aux USA et en France.
Alors qu’aux USA la responsabilité du patient est très souvent liée au médecin (Attending
Doctor), en France, celle-ci est rattachée à l’unité fonctionnelle. C’est pourquoi le champ privé
ZFU a été crée.
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.
C’est l’unité fonctionnelle responsable des soins donnés au patient.
Field ZFU-2 Housing Functional Unit is responsible for housing the patient.
C’est l’unité fonctionnelle d’hébergement.

365

Field ZFU-3 Medical Functional Unit is the unit for which the attending doctor is operating.
C’est l’unité fonctionnelle qui a la responsabilité Médicale du patient.

__________________________________________________________________________
14
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
Table 3.22-1: IHE profile - ZFU Segment

370

SEQ

LEN

DT

OPT

TBL#

ITEM#

ELEMENT NAME

1

60

XO
N

C

Nursing Functional Unit: UF
soin

2

60

TS

C

Nursing Functional Unit Start
date/time

3

60

XO
N

C

Housing Functional Unit: UF
hébergement

4

60

TS

C

Housing Functional Unit Start
date/time

5

60

XO
N

C

Medical Functional Unit: UF
médicale

6

60

TS

C

Medical Functional Unit Start
date/time

Conditions: At least one of these three functional units is required (name and date/time that thepatient has “entered” the functional unit). Two or three of them can have the same value.
Conditions : Au moins une des ces unités fonctionelles est obligatoire (nom et la date/heure lepatient est « entré » sous l’unité fonctionnelle). Deux ou trois d’entre eux peuvent avoir la mêmevaleur.

375__________________________________________________________________________
15
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

4 National Extensions for IHE Germany

380

The national extensions documented in this section shall be used in conjunction with thedefinitions 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 theregional 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 <ihe-d@rad.rwth-aachen.de> or to
Marco Eichelberg <eichelberg@offis.de>, IHE-D Technical Project Manager.

4.2 Scope390

The extensions, restrictions and translations specified apply to the following IHE Integration
Profiles:• Scheduled Workflow• Patient Reconciliation• Consistent Presentation of Images

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-27HL7 USA Semantics
Veteran Military Status

HL7 Germany Semantics
Beruf/Tätigkeit des Patienten(Patient’s Profession/Occupation)__________________________________________________________________________
16
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

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. Clinicalsituations have been identified in which an ORM message is sent for an outpatient, but theReferring Doctor is unknown and, therefore, field PV1-8 cannot be valued. In particular thisaffects 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 thatfield 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 OrderManagement, 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#

0010

00138

ELEMENT NAME

. . .
8

60

XCN

R2

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 afield called “Movement ID” which allows, upon the reception of a change message (e. g.
ADT^A08), to exactly determine the original message (ADT^A01, ADT^A02) to which thechange 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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
Table 4.8-1: Translation of IHE-Germany ZBE Table
DT

OPT

RP/#

1

EI

R

Y

2

TS

3
4

SEQ

LE
N

TBL
#

ITEM#

ELEMENT NAME

49071

Movement ID

O

49072

Start of Movement Date/Time

TS

O

49073

End of Movement Date/Time

ST

O

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

5 National Extensions for IHE United States

450

The national extensions documented in this section shall be used in conjunction with thedefinitions 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 theregional 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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

455

6 National Extensions for IHE Italy

460

The national extensions documented in this section shall be used in conjunction with thedefinitions 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 theregional 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: csaccavini@rad.unipd.it

6.2 IHE-I 2003 Scope
The extensions, restrictions and translations specified apply to the following IHE Integration
470

475

profiles:• Scheduled Workflow• Patient Reconciliation• Consistent Presentation of Images• Key Image Notes• Simple Image and Numerical Report• Access to Radiology Information• Basic Security

6.3 Extended DICOM Character Sets
480

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.

6.4 Extended HL7 Character Set

485

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.

__________________________________________________________________________
20
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

6.5 Translation of specific Fields of the PID Segment
The table below provides the 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
495This 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 theProtected Dismission.
Sono stati introdotte tre nuove classi di paziente: il Day Hospital, il Post-Ricovero e laDimissione Protetta.
Table 6.8-1: Translation of PV1-2 Segment Fields Patient Class
Value

Description

Translation/Traduzione

E

Emergency

Paziente proveniente dal Pronto Soccorso

I

Inpatient

Paziente in Ricovero OrdinarioO

Outpatient

Paziente Esterno o Ambulatoriale

P

Preadmit

Paziente in Ricovero Programmato

R

Recurring Patient

Paziente con ricovero che prevede cicli di cura__________________________________________________________________________
21
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
Value

505

Description

Translation/Traduzione

B

Obstetrics

Valore non utilizzato in Italia

D

Day Hospital

Paziente in regime di ricovero giornalieroC

After Dismission

Paziente in regime di prestazioni di post-ricovero

X

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

6.10 Extension and Translations of Physician Types in PV1
510

The table below includes the translations of the PV1 Physician Types:
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
doctorMedico responsabile della cura del paziente durante il ricovero, il medico di medicina
generale nel caso di un paziente esterno o ambulatoriale

PV1-8Referring
doctorIl medico che richiede la consulenza e che è indicato come il destinatario della rispostadello specialista.

PV1-9Consulting
doctorIl medico che esegue la consulenza richiesta dal Referring Doctor

PV1-17 Admitting
doctorIl medico che decide il ricovero del paziente__________________________________________________________________________
22
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

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

The extensions, restrictions and translations specified apply to the following IHE Integration
Profiles:• Scheduled Workflow• Patient Reconciliation• Consistent Presentation of Images

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^A04 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-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 sothat she/he receives a copy of any test results or documentation of care.

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.

__________________________________________________________________________
23
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
Field
PV1-17AdmittingdoctorDescription
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 thepatient 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

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).
Note: this character set supports the Welsh language__________________________________________________________________________
24
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

8 National Extensions for IHE Canada

550

The national extensions documented in this section shall be used in conjunction with thedefinitions 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 theregional 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
555This 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: Alain.Gauvin@muhc.mcgill.ca , David.Heaney@mckesson.com ,David.Koff@sw.ca or rnoumeir@ele.etsmtl.ca

560

The extensions, restrictions and translations specified apply to the radiology technical frameworkof IHE.

8.2 Extended DICOM Character Sets
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.
565

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

8.4 Translation of Specific Fields of the PID Segment
570

The table below provides the translation of specific fields of the PID Segment:
La table ci-dessous fournit la traduction de champs spécifiques du segment PID.
Table 8.4-1: Translation of PID Segment Fields or component values
Champ (Field)

Interprétation/Traduction

Patient Identifier List (PID – 3)

Numéro 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 filleDisplay Name (in table 0200 for name type in PID – 5)

Nom usuel

SSN Number Patient (PID – 19) This is the personal

Numéro de Sécurité Social du patient.

__________________________________________________________________________
25
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
Champ (Field)
social security number of the patient which may not be
the social security number used for the insurance billing
payment.

Interprétation/Traduction

Patient Account Number (PID – 18) Unique identifier
for collecting and grouping all elements necessary forcharging AND / OR the transmission to the insurancecompany for charging.

Numéro de compte patient Numéro unique qui permetde collecter et de grouper tous les éléments
nécessaires à la facturation ET / OU à la transmission
vers les organismes d'assurances et mutuelles, pourprise 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
ValeurDescription

Interprétation/Traduction

A

Separated

Séparé

D

Divorced

DivorcéM

MarriedMarié

SSingleCélibataireW

Widowed

Veuf/Veuve

G

Living together

Concubin

8.7 Translations of PV1-2 (Patient Class) and Selection of Values
The value ‘D’, for ‘Day hospital’ or ‘Hospitalisation d’un 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 séjour.
If Field PV1-2 is « D » Day Patient then PV1-19 is interpreted as visit number, or n° de séjour.

590

If Field PV1-2 is « O » Outpatient then PV1-19 is interpreted as consult number, or n° deconsultation.

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
If Field PV1-2 is « R » Recurring Inpatient then PV1-19 is interpreted as session number, or n°de séance.

8.9 Extension and Translations of Physician Types in PV1
The optionality status of PV1-8 is R for the Canadian implementation.
595

The table below includes the translations of the PV1 Physician Types:
La table ci-dessous fournit la traduction de champs relatif aux types de médecins dans PV1:
Table 8.9-1: Translation of PV1 Physician Types
Field

Description

Interprétation/Traduction

PV1-7 Attending doctor:

The person primarily responsible
for the care of the patient during aparticular health care visit(generally used for inpatient
events, but could be extended to an
outpatient visit as well.)

Médecin traitant.

PV1-8 Referring doctor

Is any physician who referred thepatient to the care of anotherphysician (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.

Médecin référant.

PV1-9Consulting doctor

Is generally a specialist who sees apatient as the result of a referral ora consultation order. She/he is not
the attending physician for thecase, although that status could betransferred to a consulting
physician at some point.

Le médecin qui est consulté pourun deuxième avis.

PV1-17 Admitting doctor

Is the physician who decides that apatient meets the criteria for an
inpatient admission to a hospitalduring a specific visit. The
admitting physician is responsible
for evaluating the patient so that
their acuity satisfies admission
criteria.

Médecin responsable del’admission.

__________________________________________________________________________
27
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

9 National Extensions for IHE Spain
600

The national extensions documented in this section shall be used in conjunction with thedefinitions 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 theregional practice of healthcare in Spain. IHE Spain provides a translation tool to ensure correctinterpretation 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 2007’s 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 foreach one, the domain/TF document where they are referenced (if applicable), acronym, thetranslation 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
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 (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 theattribute (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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
630

9.5 Patient Identification Data
This section is intended to give an orientation in the use of the main attributes related to thepatient 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 name635

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 father’s first family nameand the second family name is the mother’s 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 don’t change names when they get married, a person’s second
family name is as well his/her mother’s maiden name.

645

The patient’s second family name is an essential attribute for a person’s identification in Spain.
However, if a person is not of Spanish descent, it is possible that he or she does not have asecond family nameHandling particles

650

It is quite common in Spain that names have particles. Some examples of this are Felipe deBorbon y Grecia or Teresa Garcia de la Vega. These particles are not handled consistently acrosshospitals (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>YGRECIA^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 thetable 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

1

4

SI

O

00104

Set ID – PID

2

20

CX

B

00105

Patient ID

3

20

CX

R

Y

00106

Patient Identifier List

4

20

CX

B

Y

00107

Alternate Patient ID – PID

5

48

XPN

R

Y

00108

Patient Name

6

48

XPN

O

Y

00109

Mother’s Maiden Name__________________________________________________________________________
29
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
SEQ

LEN

DT

OPT

RP/#

7

26

TS

O

8

1

IS

O

9

48

XPN

O

Y

10

80

CE

O

Y

11

106

XAD

O

Y

12

4

IS

B

13

40

XTN

O

14

40

XTN

O

15

60

CE

O

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

Y

00116

Phone Number – Home

Y

00117

Phone Number – Business

0296

00118

Primary Language

O

0002

00119

Marital Status

CE

O

0006

00120

Religion

20

CX

O

00121

Patient Account Number

19

16

ST

B

00122

SSN Number – Patient

20

25

DLN

O

00123

Driver’s License Number - Patient

21

20

CX

O

Y

00124

Mother’s Identifier

22

80

CE

O

Y

00125

Ethnic Group

23

60

ST

O

00126

Birth Place

24

1

ID

O

00127

Multiple Birth Indicator

25

2

NM

O

00128

Birth Order

26

80

CE

O

0171

00129

Citizenship

27

60

CE

O

0172

00130

Veterans Military Status

28

80

CE

O

0212

00739

Nationality

29

26

TS

O

00740

Patient Death Date and Time

30

1

ID

O

00741

Patient Death Indicator

0001
0005
0289

0189
0136

Y

0136

Adapted from the HL7 Standard, version 2.3.1

660

9.5.2.1 Second family name
Patient’s second family name665

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 Mother’s 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 orname (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <name typecode (ID) > ^ <name representation code (ID)>__________________________________________________________________________
30
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________The second name shall be positioned in the following XPN route:
670

PID-6 Mother’s maiden name  Family Name
However, this solution can’t 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 person’s
involved, it is suggested that the second family name is coded as a subcomponent of the patient’s
family name as well.

675

Therefore the component <family name (ST)> can have two parts the first family name and thesecond family name, separated by a >, as shown in the following example:|BANDERAS>GRIFFITH^ESTELA|As people who are not Spanish descendants may not have second family name this field PID-6 is
not required to be filled.

680
Professional’s second family name
The second family name is used for any persons, including patients. An example can be the nameof 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 isdone for the patient name.
In v2.5 the definition for XCN data type is changed, and it is recommended to place both patientand 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 Identifiers690

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 checkdigit 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 goalof simplifying the patient identifier’s management, the use of the components shown in Table 2
is required.

__________________________________________________________________________
31
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

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 internodel 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 otherpossible 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 lastcolumn, assigning jurisdiction is a field added in v2.5, and is shown here only as arecommendation for future v2.5 implementations.
Table 9.5.2-3: Spain’s 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

1Assigning Jurisdiction(recommendation for
V2.5)
2

Identifier ESP Name of
Coding System: ISO3166 (3char)
2Identifier ESP Name of1

The last 3 characters correspond to the ISO3166 code (3 characters) of the country that issues the document. Seereference [6].

2This applies only for Spain. For other countries, their ISO codification should be taken into.

__________________________________________________________________________
32
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
Description
Identifier(Spanish
name)Identifier(English description)

Codes to be used
Assigning Authority

Identifier
Type
Code

Assigning Jurisdiction(recommendation for
V2.5)
Coding System: ISO3166 (3
char)

715

2

Trajetaresidencia

Spanish identity card forforeigners resident in
Spain

NamespaceID: MI

PRC

Identifier: ESP Name of
Coding System: ISO3166 (3char)

Númeroafiliación
Seguridad
SocialSocial Security id

NamespaceID: SS

SS

Identifier: ESP Name of
Coding System: ISO3166(3 char)

CIP
autonómico

Regional authority
unique patient identifierNamespaceID:CAXX

JHN

Identifier: AN, AR, ..
Name of Coding System:
4
ISO3166-2

CIP del SNS

National health authority
unique patient identifierNamespace ID: MS

HC

Identifier: ESP Name of
Coding System: ISO3166 (3char)

CIP europeo

European patient
identifierNamespaceID: TSE

HC

Identifier: EU Name of
Coding System: ISO3166

ID interno

Internal patient identifier

Definition pending

PI

Definition pending3

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 tableshall 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). Seereference [5] for autonomous regions codification.

4

ISO regional authority (CCAA) Codification. See reference [5].

__________________________________________________________________________
33
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
Components: <street address (ST)> ^ <other designation (ST)> ^ <city(ST)> ^ <state or province (ST)> ^ <zip or postal code(ST)> ^<country (ID)> ^ < address type (ID)> ^ <other geographic
designation (ST)> ^ <county/parish code (IS)> ^ <census tract (IS)>^ <address representation code (ID)>

730

735

To identify the type of address, it is recommended that the values from the HL7 table 0190 beused in the following way:
Table 9.5.2-4: Spain’s recommended local codes for address typeType of address

740“Address Type” Field

Fiscal (tax)L

Empadronamiento (city register)H

Contacto (contact)

M

Empresa (company)

B

Desplazado (temporal)C

In the event that the “address type” is not filled in, the address is considered to be the city
register’s postal address (H).
The components of the address field are recommended to be used as follows:
Table 9.5.2-5: Spain’s recommended interpretation for HL7 v.2.3.1 PID-11 components.
PID-11 component

745

Recommended
interpretation

Recommended coding
scheme“Street Address”

Tipo de vía, nombre de la vía
y número de la vía

n/a“City”:

Municipio

INE code“State or Province”:

Provincia

INE code“Zip or postal code”

Código Postal“Country”

País“Other geographic designation”

Población

55ISO3166 (3 characters)
6n/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:

5

Spain’s recommended interpretation for HL7 v.2.3.1 PID-11 components.

6

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
Table 9.5.2-6: Spain’s 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 vía“Street name”

Nombre de la vía“Dwelling number”

Número de la vía

750
9.5.3 DICOM: Patient Identification Module

755

The DICOM Standard provides definitions for the information objects [9]. Most of theidentification 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 Patient’s 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 thefirst and the second family name.

760

Amongst the patient’s personal data fields available in the Patient Identification Modules, thereis 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 firstcomponent 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 thesame way.
770

775

Other examples besides the Referring Physician’s Name (0008, 0090), are Performing
Physician’s Name (0008, 1050), Name of Physician’s Reading Study (0008, 1060), Operator’sName (0008, 1070), Names of Intended Recipients of Results (0040,1010), Order Entered By(0040,2008), Human Performer’s Name (0040,4037), Verifying Observer Name (0040,A075),
Content Creator’s 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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________(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 thepatient id (see Table 3), and additional information regarding the “Identifier Type Code” isneeded. This is supported in HL7 v2.3, but not in the current DICOM specification. Please notethat 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 patient’s 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 arerequired 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: Spain’s recommended interpretation for HL7 v.2.3.1 IN1
IN1 Field

Recommended interpretation

Optionality

In1-1 Set id IN1

Number that identifies the transaction. If the patient
has more than one insurance company, themessage shall be repeated for each company, using
a different transaction ID.

RequiredIn1-2 Insurance
Plan ID

Coverage Plan identifier.

RequiredIn1-3 Insurance
Company ID

Unique company identifier.

RequiredIn1-4 Insurance
Company Name

Name of the company. We suggest repeated use ofthis field to identify the name of the company’s
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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
IN1 Field

Recommended interpretation

Optionality

In1-13 Plan
expiration date

The date the Coverage Plan finishes.

Optional

In1-36 Policy
NumberPolicy 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
NombrePrimer Apellido
Segundo Apellido
Identificadores
DNI
CIP autonómico
Número afiliación Seguridad Social
Identificador interno del HIS
Datos de contacto
Teléfono de casa
Móvil
Correo electrónico
Direcciones
Dirección de empadronamiento
Tipo de vía
Nombre de la vía
NúmeroPiso
Escalera
Código Postal
Municipio
Población
Provincia
País
Dirección de contacto
Tipo de vía
Nombre de la vía
NúmeroPiso
Escalera
Código Postal
Municipio
Población

Patient data
NameFirst family name
Second family nameIdentifiers
National identity card
Regional authority unique patient
identifierSocial Security id
Internal patient id at the HIS
Contact information
Home phone
Cell phonee-mailAdresses
Address for the city register
Street type (avenue, square,..)Street nameStreet number
Floor
Stair
Zip code
City
City
Province
Country
Contact address
Street typeStreet nameStreet number
Floor
Stair
Zip code
City
City

ManuelFernández
Ferrer37456765V
CAEX123456789088(extremadura =EX)
061081880847
9987765924678564
659877877
mfernandez@hl7spain.org

AvenidaAlange
8
4ª-3ª
B
06800
MéridaMéridaBadajoz
EspañaCalle
Constitución
34
1º-C
06800
MéridaMérida__________________________________________________________________________
37
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
Provincia
País

810

Province
Country

Badajoz
EspañaThe location of these data in an HL7 message would be the following:
PID-3 Patient
identifier List

ID Number
Assigning Authoriy37456765V
Namespace ID

MI
NNESP
CAEX123456789088

Namespace ID

CAEX
JHN
61081880847

Namespace ID

SSSS
9987765

Namespace ID

HC
PI

SurnameFernández
ManuelSurnameFerrerIdentifier Type CodeID Number
Assigning Authoriy
Identifier Type CodeID Number
Assigning Authoriy
Identifier Type CodeID Number
Assigning Authoriy

PID-5 Patient Name

PID-6 Mother's Maiden
Name
PID-11 Patient Address

PID-13 Phone Number Home

Identifier Type CodeFamily Name
Given Name
Family Name
Given Name
Street Address
Other Designation
City
State or Province
Zip or Postal CodeCountry
Address Type
Other Geographic Designation
Street Address
Other Designation
City
State or Province
Zip or Postal CodeCountry
Address Type
Other Geographic Designation
Telecommunication Use CodeTelecomm. Equipment TypeCountry code
Phone Number
Telecommunication Use CodeTelecomm. Equipment TypeCountry code
Phone Number
Telecommunication Use CodeTelecomm. Equipment Type
Email Address

Avenida Alange 8 4º-3ª Escalera B
06083
06
06800
ESP
H
Calle Constitución 34 1ª - C
06083
06
06800
ESP
M
PRN
PH
+34
924678564
WPN
CP
+34
659877877
NETInternetmfernandez_f@ihe-e.org

And the corresponding PID segment in a message would be:

815

PID|
1|
__________________________________________________________________________
38
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________

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^ESP^H^^^^~
Calle Constitución 34 1ª - C^^06083^06^06800^ESP^M^^^^||^PRN^PH^^^924678564~^WPN^CP^^^659877877~^NET Internet^^^mfernandez_f@ihe-e.org
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
NombrePrimer Apellido
Segundo Apellido
Fecha de nacimiento
Identificadores
DNI
CIP autonómico
Número afiliación Seguridad Social
Identificador interno del HIS
Datos de contacto
Teléfono de casa
Otro teléfono de contacto
Móvil
Correo electrónico
Direcciones
Dirección de contacto
Nombre de la vía
Código Postal
Municipio
Población
Provincia
País

Patient data
NameFirst family name
Second family nameDate of birth
Identifiers
National identity card
Regional authority unique patient identifierSocial Security id
Internal patient id at the HIS
Contact information
Home phone
Secondary contact telephone
Cell phonee-mailAdresses
Contact address
Street name
Zip code
City
City
Province
Country

EstelaBanderas
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
ToledoToledoThe patient identifiers are coded as follows:
CIP autonomico

HOPN700641916019^^^CACM&&^JHN^

DNI

00000001R^^^MI&&^NNESP^

Identificador interno del HIS (Número de historia
clínica)

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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________
Número afiliación Seguridad Social

835

2803800541502^^^SS&&^SS^

The address is coded taking into account that the code for the city of TOLEDO is (45 1685) andthe 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^ESTELA|GRIFFITH|
19700601|
F|||
Plaza de Alfares 2 , Apt. 2º A^451685^45^45002^ ESP^M||^PRN^PH^^^925123456~^ORN^PH^^^925654321~^ORN^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

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________(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^ESTELA(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(Technical Subcommittee HL7 Spain, http://www.hl7spain.org/)[3] Minutes of Conference Call Technical Subcommittee ADT 14-02-2005

870(Technical Subcommittee HL7 Spain, http://www.hl7spain.org/)__________________________________________________________________________
41
Rev. 13.0 Final Text – 2014-07-30

Copyright © 2014: IHE International, Inc.

IHE Radiology Technical Framework, Volume 4: National Extensions______________________________________________________________________________[4] Minutes of Meeting Technical Subcommittee ADT 10-03-2005(Technical Subcommittee HL7 Spain, http://www.hl7spain.org/)[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(Technical Subcommittee HL7 Spain, http://www.hl7spain.org/)[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

Copyright © 2014: IHE International, Inc.