Integrating the Healthcare Enterprise

5

10

IHE IT Infrastructure
Technical Framework
Volume 4
IHE ITI TF-4
National Extensions

15

20

Revision 14.0 – Final Text
July 21, 201725

Please verify you have the most recent version of this document, which is published here.

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Contents

30

35

40

45

50

55

60

65

70

1 Introduction ................................................................................................................................ 5
1.1 Introduction to IHE ............................................................................................................. 5
1.2 Intended Audience .............................................................................................................. 5
1.3 Overview of Volume 4........................................................................................................ 5
1.4 Comment Process................................................................................................................ 6
1.5 Copyright Licenses ............................................................................................................. 6
1.5.1 Copyright of Base Standards ....................................................................................... 6
1.6 Trademark ........................................................................................................................... 6
1.7 Disclaimer Regarding Patent Rights ................................................................................... 6
1.8 History of Document Changes ............................................................................................ 7
2 Overview of National Extensions to the Technical Framework ................................................ 8
2.1 Scope of National Extensions ............................................................................................. 8
2.2 Process for Developing National Extensions...................................................................... 8
2.3 Process for Proposing Revisions to the Technical Framework .......................................... 9
3 National Extensions for IHE USA ........................................................................................... 10
3.1 Data Segmentation for Privacy (DS4P) ............................................................................. 10
3.1.1 DS4P Document Content ........................................................................................... 12
3.1.2 DS4P DocumentEntry ................................................................................................ 12
3.1.2.1 DS4P DocumentEntry.confidentialityCode ....................................................... 12
3.1.2.1.1 DS4P Confidentiality Security Classification Label .................................. 12
3.1.2.1.2 DS4P Sensitivity Security Classification Label ......................................... 12
3.1.2.1.3 DS4P Handling Caveats Security Category ............................................... 13
3.1.2.2 DS4P DocumentEntry.healthcareFacilityTypeCode .......................................... 13
3.1.2.3 DS4P DocumentEntry.practiceSettingCode ....................................................... 13
3.1.2.4 DS4P DocumentEntry.typeCode ........................................................................ 14
3.1.3 DS4P SubmissionSet .................................................................................................. 14
3.1.3.1 DS4P SubmissionSet.intendedRecipient ............................................................ 14
3.1.3.2 DS4P SubmissionSet.author ............................................................................... 14
4 National Extensions for France ................................................................................................ 15
4.1 French requirements related to Patient and Patient Administration ................................. 15
4.1.1 Requirements on all HL7 V2.x transactions .............................................................. 15
4.1.1.1 HL7 character set ................................................................................................ 15
4.1.1.2 Forbidden fields in France .................................................................................. 16
4.1.1.3 EVN Segment ..................................................................................................... 16
4.1.1.4 MSH Segment rules ............................................................................................ 16
4.1.1.5 PID Segment ....................................................................................................... 16
4.1.2 Segments that apply only to ITI-30 and ITI-31.......................................................... 20
4.1.2.1 PD1 Segment ...................................................................................................... 20
4.1.2.2 ROL Segment ..................................................................................................... 21
4.1.2.3 NK1 Segment ..................................................................................................... 23
4.1.2.4 PV1 Segment ...................................................................................................... 26
4.1.2.5 PV2 Segment ...................................................................................................... 33___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

2

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

75

80

85

90

95

100

105

110

4.1.2.6 ACC segment...................................................................................................... 39
4.1.2.7 ZBE Segment: Action on a movement ............................................................... 40
4.1.2.8 ZFA segment ...................................................................................................... 43
4.1.2.9 ZFV Segment: Additional information regarding the encounter ....................... 45
4.1.2.10 ZFM segment: DRG movement ....................................................................... 48
4.1.2.11 IN1; IN2; IN3: Medical coverage..................................................................... 51
4.1.2.11.1 Compulsory Health Insurance (CHI) coverage related to the patient’s
account ...................................................................................................... 51
4.1.2.11.2 Complementary private health insurance (CPHI) or Complementary
Medical Assistance (CMA), or Universal Complementary Health (UCH)
coverage related to the patient’s account .................................................. 54
4.1.2.11.3 Other payer ............................................................................................... 56
4.1.2.12 OBX segment ................................................................................................... 58
4.1.3 Requirements on PAM Profile ................................................................................... 61
4.1.3.1 Minimal common data model ............................................................................. 61
4.1.3.1.1 The Functional Unit (FU) or Ward ............................................................. 61
4.1.3.1.2 The concept of patient account (informative) ............................................. 62
4.1.3.1.3 The concept of visit/encounter.................................................................... 62
4.1.3.1.4 The concept of movement .......................................................................... 63
4.1.3.2 Actor Requirements for PAM ............................................................................ 63
4.1.3.3 Transaction Specific Requirements .................................................................... 64
4.1.3.3.1 Movement management rules applicable in France ................................... 64
4.1.3.3.1.1 The concept of movement ................................................................... 64
4.1.3.3.1.2 Granularity of messages that describe a movement ............................ 65
4.1.3.3.1.3 Trigger events associated with movement .......................................... 66
4.1.3.3.1.4 Requirements ...................................................................................... 67
4.1.3.3.2 ITI-30 Extensions ....................................................................................... 67
4.1.3.3.3 ITI-31 Extensions ....................................................................................... 68
4.1.3.3.3.1 Trigger Event Extensions.................................................................... 68
4.1.3.3.3.2 ITI-31 French specific segments ......................................................... 69
4.1.3.3.3.3 Historic Movement Management (from intl)...................................... 71
4.1.3.3.3.4 Details regarding the account/visit/movement identifiers .................. 72
5 National Extensions for IHE Germany ...................................................................................... 73
5.1 Referenced Standards........................................................................................................ 73
5.2 HL7 v2 Conventions for Message Profiles ....................................................................... 73
5.2.1 HL7: Support for Character Sets ............................................................................... 73
5.2.2 Naming Conventions for Profiles .............................................................................. 73
5.3 ITI-30 and ITI-31 .............................................................................................................. 73
5.3.1 Extension Requirements: Notation and Location ...................................................... 74
5.3.1.1 German Message Profile Architecture ............................................................... 75
5.3.2 German HL7 Message Profiles for PAM .................................................................. 76
5.3.3 Additional German HL7 Message Profile Components ............................................ 77
5.3.4 Additional German Segment Definitions .................................................................. 78
5.3.5 Additional German Data Type Definitions................................................................ 79___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

3

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
115

5.3.6 Additional German Table Value Definitions ............................................................. 79
Appendices .................................................................................................................................... 81
Glossary ........................................................................................................................................ 82___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

4

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

1 Introduction
120

This document, Volume 4, of the IHE IT Infrastructure (ITI) Technical Framework describes thecountry-specific extensions to ITI transactions and content modules.

1.1 Introduction to IHE
125

130

Integrating the Healthcare Enterprise (IHE) is an international initiative to promote the use ofstandards to achieve interoperability among health information technology (HIT) systems andeffective use of electronic health records (EHRs). IHE provides a forum for care providers, HIT
experts and other stakeholders in several clinical and operational domains to reach consensus on
standards-based solutions to critical interoperability issues.
The primary output of IHE is system implementation guides, called IHE Profiles. IHE publishes
each profile through a well-defined process of public review and trial implementation andgathers profiles that have reached final text status into an IHE Technical Framework, of which
this volume is a part.
For more general information regarding IHE, refer to www.ihe.net. It is strongly recommended
that, prior to reading this volume, readers familiarize themselves with the concepts defined in the
IHE Technical Frameworks General Introduction.

135

1.2 Intended Audience
The intended audience of IHE Technical Frameworks Volume 4 is:140•

Those interested in integrating healthcare information systems and workflows on aninternational or country basis•

IT departments of healthcare institutions•

Technical staff of vendors participating in the IHE initiative•

Experts involved in standards development

1.3 Overview of Volume 4145This volume contains information about the scope of national extensions to the transactions
and/or content modules defined in the IHE IT Infrastructure (ITI) 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 anddocumentation in the IHE Technical Framework. Section 3 and beyond describe the national
extensions, per country, which have been defined. Examples include specific transaction orcontent changes for IHE Canada, IHE Germany, IHE Japan.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

5

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
150

1.4 Comment Process
IHE International welcomes comments on this document and the IHE initiative. They can besubmitted by sending an email to the co-chairs and secretary of the IT Infrastructure domain
committees. See http://ihe.net/ITI_Public_Comments.

1.5 Copyright Licenses
155

160

165

IHE International hereby grants to each Member Organization, and to any other user of these
documents, an irrevocable, worldwide, perpetual, royalty-free, nontransferable, nonexclusive,
non-sublicensable license under its copyrights in any IHE Profiles and Technical Framework
documents, as well as any additional copyrighted materials that will be owned by IHE
International and will be made available for use by Member Organizations, to reproduce anddistribute (in any and all print, electronic or other means of reproduction, storage ortransmission) such IHE Technical Documents.
The licenses covered by this Copyright License are only to those copyrights owned or controlled
by IHE International itself. If parts of the Technical Framework are included in products that also
include materials owned or controlled by other parties, licenses to use those products are beyond
the scope of this IHE document and would have to be obtained from that other party.
1.5.1 Copyright of Base Standards

170

IHE Technical Documents refer to and make use of a number of standards developed andpublished by several standards development organizations. All rights for their respective basestandards are reserved by these organizations. This agreement does not supersede any copyrightprovisions applicable to such base standards.
Health Level Seven, Inc. has granted permission to IHE to reproduce tables from the HL7® 1
standard. The HL7 tables in this document are copyrighted by Health Level Seven, Inc. All rights
reserved. Material drawn from these documents is credited where used.

1.6 Trademark
175

IHE® and the IHE logo are trademarks of the Healthcare Information Management Systems
Society in the United States and trademarks of IHE Europe in the European Community. They
may only be used with the written consent of the IHE International Board Operations
Committee, which may be given to a Member Organization in broad terms for any use that is
consistent with the IHE mission and operating principles.

180

1.7 Disclaimer Regarding Patent Rights
Attention is called to the possibility that implementation of the specifications in this document
may require use of subject matter covered by patent rights. By publication of this document, no1

HL7 is the registered trademark of Health Level Seven International.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

6

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

185

190

position is taken with respect to the existence or validity of any patent rights in connection
therewith. IHE International is not responsible for identifying Necessary Patent Claims for whicha license may be required, for conducting inquiries into the legal validity or scope of Patents
Claims or determining whether any licensing terms or conditions provided in connection withsubmission of a Letter of Assurance, if any, or in any licensing agreements are reasonable ornon-discriminatory. Users of the specifications in this document are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, isentirely their own responsibility. Further information about the IHE International patent
disclosure process including links to forms for making disclosures is available at
http://ihe.net/Patent_Disclosure_Process. Please address questions about the patent disclosure
process to the secretary of the IHE International Board: secretary@ihe.net.

1.8 History of Document Changes
195
Date

Document
Revision

Change Summary

2014-09-23

11.0

Newly created Volume 4 - Create and add US Data Segmentation for Privacy (DS4P)

2015-09-18

12.0

Add German and French Extensions

2016-09-09

13.0

Updated revision and date and removed copyright footer on each page and replaced withfootnotes when applicable.

2017-07-21

14.0

Updated revision and date to coincide with updates to other volumes.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

7

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

2 Overview of National Extensions to the Technical Framework
200

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
205

210

215

220

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.

2.2 Process for Developing National Extensions

225

230

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.
Established IHE national initiatives may draft a document describing potential national
extensions containing the general information outlined above. This draft document is submitted
to the IHE Technical Committee for review and comment. Based on discussion with theTechnical 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 documentsin the relevant domain.
___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

8

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

2.3 Process for Proposing Revisions to the Technical Framework235

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.

240

National extensions 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,called the Change Proposal Process.

245

More substantial revision proposals, such as proposals to add new integration profiles or majorcountry-based extensions, should be submitted directly to the IHE Technical and Planning
Committees via the process for submitting new proposals called the Profile Proposal Process.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

9

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

3 National Extensions for IHE USA
250

The national extensions documented in this section shall be used in conjunction with thedefinitions of integration profiles, actors and transactions provided in Volumes 1 through 3 of theIHE ITI Technical Framework. This section includes extensions and restrictions to effectively
support the regional practice of healthcare in the United States.
This ITI national extension document was authored under the sponsorship and supervision of
IHE USA and the IT Infrastructure Technical Committee. Comments should be directed to:
http://www.ihe.net/ITI_Public_Comments

255

3.1 Data Segmentation for Privacy (DS4P)

260

This National Extension shows how to use and interpret the Document Sharing Metadata Profiles(XDS.b, XCA, XDR, XDM, and MHD) in compliance with the requirements identified for Data
Segmentation for Privacy (DS4P). Data Segmentation is the privacy and security concept fordifferentiating between data that are to be handled differently for privacy or security reasons.
Data Segmentation for Privacy support in this context is the interoperability constraints to enable
documents of various and different privacy and sensitivity to be communicated within a trust
framework in a way that the sender can communicate necessary and specific privacy and security
attributes and obligations in a way that the recipient can clearly understand them and act
properly.

265

270

275

280

285

This national extension is intended to be used within a trust framework between communicating
parties. This trust framework includes policy agreements to use this national extension tocommunicate segmented sensitive information. For each document that is communicated within
this trust framework (PUSH or PULL) the following metadata constraints shall be used tocommunicate the highest sensitivity of the content as evaluated by the sender. The identified
sensitivity level is then enforced by the recipient. Trust enforcement is expected to be definedand managed within that trust framework.
This USA National Extension addresses methods for sharing of segmented documents containing
personally identifiable information (PII) as may be permitted by privacy policies or regulations.
The privacy policies on which this National Extension is based do not explicitly address theclinical implications of giving patients control over the disclosure of their sensitive records.
Standards development organizations are focused on the development of technical infrastructure
specifications and remain agnostic on the appropriateness of a privacy policy.
Privacy policies are defined as limits on disclosure and use. Disclosure and use restrictions may
originate from a patient, a service provider, or from jurisdictions where healthcare is delivered.
Implementations should be prepared to extend functionality based on state, region, and local
policies.
This USA National Extension is the result of a proposal from the US Department of Health andHuman Services, Office of the National Coordinator for Health IT (ONC) to develop guidance
for implementation of Data Segmentation Techniques, including RESTful patterns as defined in
the MHD Profile, using the standards, building blocks and principles documented in the Use___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

10

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

290

295

300

305

310

Cases developed by the S&I DS4P stakeholder community, and the NwHIN SOAP/Exchange
version of the S&I DS4P Implementation Guide. Furthermore, this specification draws upon andcites specific instances of U.S. law such as 42 CFR Part 2, 38 CFR Part 1, etc. These specificreferences are intended to profile a specific set of users operating under realm specific law andgoals. Nothing in this supplement is intended to prevent adoption or customization to meet theneeds of other realms.
This USA National Extension is based on artifacts and the findings of pilot implementations of
the Data Segmentation for Privacy (DS4P) S&I Framework Initiative, specifically on the Use
Cases developed by the stakeholder community, and the NwHIN SOAP/Exchange version of the
S&I DS4P Implementation Guide. Additionally, content from the HL7 DS4P Profiles(HL7_IG_DS4P_R1_CH1_CONTENT_N2_2014JAN,
HL7_IG_DS4P_R1_CH2_DIRECT_N2_2014JAN, and
HL7_IG_DS4P_R1_CH3_EXCHANGE_N2_2014JAN) which in turn reference IHE XDS are
noted as important companion documents. For a detailed description of the project, refer to the
S&I Initiative DS4P Project Executive Summary found at
http://wiki.siframework.org/Data+Segmentation+for+Privacy+Homepage.
This USA National Extension defines constraints according to the requirements captured in the
Use Cases developed by the Data Segmentation for Privacy (DS4P) S&I Framework Initiative
stakeholder community and additional requirements that were identified by pilot projects
engaged in validating the implementation guidance developed by the DS4P S&I Framework
Initiative.
Conformance to the Document Sharing Profiles (XDS.b, XDR, XDM, XCA, and MHD) is
expected with the following additional constraints based on privacy policies related to the type of
document and the context of the exchange (requesting user, patient, consent, document, facility,
purpose, communications mechanism, etc.).
•

Document Entry constraints are given in Section 3.1.2 below. The constraints include:
•

315

320

Security tags (confidentialityCode ) constraints•

indicate the Confidentiality Level specified by using the designated HL7
Confidentiality vocabulary•

indicate the Handling Caveats for Obligation Policy using a designated Obligation
Policy vocabulary•

indicate the Handling Caveats for Purpose of Use using a designated Purpose of
Use vocabulary•

indicate Handling Caveats for Refrain Policy using a designated Refrain Policy
vocabulary•

indicate the Authoring healthcare facility type using a designated restricted healthcare
facility type vocabulary•

indicate the Document practice setting type using a designated restricted practicesetting vocabulary___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

11

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
325

•
•

330

indicate the Low-level classification of the document (typeCode) using a designatedrestricted type code vocabulary

SubmissionSet constraints are given in the Section 3.1.3 below. The constraints include:•

Indicated as necessary the Targeted intended recipient (intendedRecipient)•

Indicate the SubmissionSet creator

3.1.1 DS4P Document Content
Any CDA® 2 document SHOULD comply with the CDA constraints defined in the HL7 CDA
Privacy Segmented Document template (templateId: 2.16.840.1.113883.3.3251.1.1)
Other content types MAY be carried.
3.1.2 DS4P DocumentEntry

335

The following constraints apply to all documents in the SubmissionSet.
All the designated vocabulary and value sets are defined by HL7.
3.1.2.1 DS4P DocumentEntry.confidentialityCode
The confidentialityCode metadata SHALL use the “HL7 Healthcare Privacy and Security
Classification System (HCS)” as defined in ITI TF-3:4.2.3.2.5

340

3.1.2.1.1 DS4P Confidentiality Security Classification LabelThe confidentialityCode element SHALL contain exactly one value from the codesystem
2.16.840.1.113883.5.25 (i.e., U, L, M, N, R, or V) (aka,
http://hl7.org/implement/standards/fhir/v3/Confidentiality/index.html), to indicate theConfidentiality coding of the content.

345

The confidentialityCode may also contain other values from other codesystems for which
Sections 3.1.2.1.2 and 3.1.2.1.3 below are two examples.
The value represents the most restrictive content in the identified document (aka, High watermark).
3.1.2.1.2 DS4P Sensitivity Security Classification Label

350

The confidentialityCode SHOULD NOT contain a sensitivity indicator unless the trust
framework policies indicate otherwise.

2

CDA is the registered trademark of Health Level Seven International.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

12

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
3.1.2.1.3 DS4P Handling Caveats Security Category
The confidentialityCode element SHALL contain any Obligation Handling Caveats deemednecessary.
355

If present, the Obligation values SHALL be selected from the ValueSet
HL7 ObligationPolicyCode 2.16.840.1.113883.1.11.20445
Also found at http://hl7.org/implement/standards/fhir/v3/vs/ObligationPolicy/index.html
If present, the Purpose Of Use values SHALL be selected from the ValueSet
HL7 PurposeOfUse 2.16.840.1.113883.1.11.20448

360

Also found at http://hl7.org/implement/standards/fhir/v3/vs/PurposeOfUse/index.html
If present, the Refrain Policy values SHALL be selected from the ValueSet
HL7 RefrainPolicy 2.16.840.1.113883.1.11.20446
Also found at http://hl7.org/implement/standards/fhir/v3/vs/RefrainPolicy/index.html
3.1.2.2 DS4P DocumentEntry.healthcareFacilityTypeCode

365

370

The healthcareFacilityTypeCode element contains an indicator of the type of facility that
authored the document. The ValueSet designated is restricted to the subset of practice setting
codes that will not disclose details about the healthcare facility that may be protected in a
specific affinity domain, directed exchange, Health Information Exchange, etc. The HL7
RestrictedHealthcareFacilityTypeCode ValueSet meets this definition and is designated for thispurpose.
The healthcareFacilityTypeCode element’s value SHALL be selected from the ValueSet
HL7 RestrictedHealthcareFacilityTypeCode 2.16.840.1.113883.3.3251.3.2.1
This HL7 ValueSet is a dynamic ValueSet. An HL7 ‘dynamic’ ValueSet is one that can changeover time to adjust to changing policy landscapes, but is a managed ValueSet.

375

380

3.1.2.3 DS4P DocumentEntry.practiceSettingCode
The practiceSettingCode element contains an indicator of the type of practice setting. The
ValueSet designated is restricted to the subset of practice setting codes that will not disclosedetails about the practice that may be protected in a specific affinity domain, directed exchange,
Health Information Exchange, etc. The HL7 RestrictedPracticeSettingCode ValueSet meets thisdefinition and is designated for this purpose. The ValueSet is derived from SNOMED-CT codes
in a way consistent with prevailing privacy policies.
The practiceSettingCode element’s value SHALL be selected from the ValueSet
RestrictedPracticeSettingCode 2.16.840.1.113883.3.3251.3.2.2

385This HL7 ValueSet is a dynamic ValueSet. An HL7 ‘dynamic’ ValueSet is one that can changeover time to adjust to changing policy landscapes, but is a managed ValueSet.
___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

13

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
3.1.2.4 DS4P DocumentEntry.typeCode
The typeCode element identifies the type of document. The ValueSet designated avoids
disclosing protected information. The HL7 RestrictedTypeCode ValueSet meets this definition
and is designated for this purpose.
390

The typeCode element’s value SHALL be selected from the ValueSet
RestrictedTypeCode 2.16.840.1.113883.3.3251.3.2.3
This HL7 ValueSet is a dynamic ValueSet. An HL7 ‘dynamic’ ValueSet is one that can changeover time to adjust to changing policy landscapes, but is a managed ValueSet.
3.1.3 DS4P SubmissionSet

395

The following constraints apply to the submissionSet containing the document entries
3.1.3.1 DS4P SubmissionSet.intendedRecipient

400

The intended recipient element’s value MAY contain the intended recipient. When the exchange
requires an intended recipient constraint, this element SHALL be populated. This element
SHALL contain the e-mail address of that intended recipient unless the trust framework
identifies an alternative encoding that is acceptable.
3.1.3.2 DS4P SubmissionSet.author
The SubmissionSet Author element’s value SHALL contain at least the author of the submission
set.

405

This element SHALL contain the e-mail address of the author of the submission set unless thetrust framework identifies an alternative encoding that is acceptable.
The recipient utilizes the SubmissionSet author as the indicator of the sender for PUSH
transactions, and as the provenance identifier of the submission. This information may be usedby the recipient in policy decisions and enforcement.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

14

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

4 National Extensions for France
410

4.1 French requirements related to Patient and Patient Administration
HL7 v2.5 events and segments used by the PAM Profile are detailed in the IHE ITI Technical
Framework which will be referred to as ITI TF-2 in the remainder of this section.

415

This section describes constraints on HL7 v2.5 events and segments used in the French
environment. Some of these constraints apply to all HL7 transactions. Others only affect the ITI30 and ITI-31 transactions.
The document narrows or specifies the use of events and segments mentioned in ITI TF-2. It also
specifies the use of HL7 v2.5 events and segments that are still not detailed in ITI TF-2.
Each segment is displayed as a table which rows are the items and which “Usage” and “Card.”
Columns respectively specify the use of the item and its cardinalities in the French environment.

420

425

The “Usage” column follows the common codification to HL7 and IHE:
R

Required. The item must be provided in the French environmentRE

Must be provided if the sending application owns the information. The sending
application must be able to supply that item.

O

Optional: IHE France doesn’t impose any restriction on that item which may or
may not be managed by sending and receiving applications.

C

Conditional. The condition for using in the French environment is specified below
the table.

X

Forbidden in France.

The “Card.” column includes the bracketed highest and lowest cardinalities.
430

435

An “IHE Fr” column was added to the tables. Such a column is marked with an asterisk when theconstraint on the use established by IHE France is different from the one set up by IHE
International or by HL7 v2.5 standard for the particular item. In other words, no asterisk meansthat the French use is exactly the same than the international one.
Some of the items are detailed below the data type table. Especially, IHE France can provide
values lists for some of those items. These lists (restricted, extended or even edited as comparedwith the original ones established by HL7) include values that are strictly permitted in France.
None of these lists can be edited without having to update the present document.
4.1.1 Requirements on all HL7 V2.x transactions
4.1.1.1 HL7 character set

440

The ISO 8859/1 and ISO 8859/15 character sets shall be supported.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

15

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
4.1.1.2 Forbidden fields in France
The following fields are forbidden in all HL7 messages.

445•

Patient race: PID-10; NK1-35•

Patient religion: PID-17; NK1-25•

Patient ethnic group: PID-22; NK1-28

4.1.1.3 EVN Segment

450•

Pending events shall use EVN with empty EVN-3 and EVN-6,•

Planned events shall use EVN with planned date time in EVN-3 and empty EVN-6,•

Past events shall use EVN with date time in EVN-6 and EVN-3 empty.

4.1.1.4 MSH Segment rules
The MSH-12 field shall be fully populated. When part of ITI-30 and ITI-31 transactions, it shallbe populated as follows:

455•

MSH-12.1: HL7 version number•

MSH-12.2: Internationalization code (Table #399) shall be FRA•

MSH-12.3: HL7 Profile version number shall be 2.5

4.1.1.5 PID Segment
All transactions that contain a PID segment shall support the changes made to PID-3, PID-5,
PID-6, PID-8, PID-10, PID-16, PID-17, PID-32.
HL7
TBL#

SEQ

LEN

DT

Usage

Card.

ELEMENT NAME

PID-1

4

SI

O

[0..1]

Set ID - PID

PID-2

20

CX

X

[0..0]

Patient ID

PID-3

250

CX

R

[1..*]

Patient Identifier List

PID-4

20

CX

X

[0..0]

Alternate Patient ID - PID

PID-5

250

XPN

R

[1..*]

PID-6

250

XPN

O

[0..*]

PID-7

26

TS

O

[0..1]

PID-8

1

IS

O

[0..1]

PID-9

250

XPN

X

[0..0]

PID-10

250

CEX[0..0]

PID-11

250

XAD

C

[0..*]

PID-12

4

IS

X[0..0]

PID-13

250

XTN

O

[0..*]IHE FR*

National identifier

Patient Name*

French legal policy

Mother’s Maiden Name*

Date/Time of Birth1

Administrative Sex*

Restricted User table*forbidden

Patient Alias
5

Race
Patient Address

289

County CodePhone Number - Home___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

16

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
HL7
TBL#

SEQ

LEN

DT

Usage

Card.

ELEMENT NAMEIHE FR

PID-14

250

XTN

O

[0..*]

PID-15250

CEO[0..1]

296

Primary Language

PID-16250

CEO[0..1]

2

Marital Status*

User table

PID-17250

CE

X[0..0]

6

Religion*

forbidden

PID-18250

CX

C[0..1]

Patient Account Number

PID-1916

ST

X[0..0]SSN Number - Patient

PID-2025

DLN

X[0..0]

Driver's License Number Patient

PID-21250

CX

O[0..*]

Mother's Identifier

PID-22250

CE

X[0..0]

PID-23

250

STO[0..1]

PID-241

IDO[0..1]

PID-25

2

NMC[0..1]

PID-26250

CEO[0..*]

171

CitizenshipPID-27250

CEO[0..1]

172

Veterans Military Status

PID-28

250

CE

X

212

Nationality

PID-2926

TSO[0..1]

PID-301

IDO[0..1]

PID-31

1

ID

CE

PID-3220

IS

RE[0..*]*

French user table

PID-3326

TSC[0..1]

Last Update Date/Time

PID-34241

HDO[0..1]

Last Update Facility

PID-35250

CEC[0..1]

446

PID-36250

CEC[0..1]

447

PID-3780

STO[0..1]

PID-38

250

CE

O

2

429

Production Class CodePID-39

250

CWE

O

[0..*]

171

Tribal CitizenshipPhone Number - Business

189

Ethnic Group
Birth Place

136

Multiple Birth Indicator
Birth Order

Patient Death Date and Time136

Patient Death Indicator

136

Identity Unknown Indicator

445

Identity Reliability CodeSpecies Code
Breed Code
Strain460
PID-3: Patient Identifier List
This field is used to carry the patient’s identifiers, IPP (Permanent Patient identifier), INS-A,
INS-C (Patient’s National Health Identifiers) among others.
Each identifier is carried with its type (CX-5) and its assigning authority (CX-4).
465

470

The INS-C number is calculated. If any INS-C changes; this list shall contain all the known INSC with their calculation dates in CX-7. The most recently calculated INS-C shall be used as thecurrent INS-C.
For each patient’s identifier, the CX type allows specifying the legal entity, the establishment,
the ward or the department that produced or had it. This list shall include all of the patient’s
known INS.
___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

17

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
PID-5: Patient Name
Three types of name can be conveyed in the PID-5 field, which is repeatable. They comply with
the HL-7 name structure, and differ in their use of family name.
475

480

485

•

The family name which is the legal name according to the Art.311-21 of the Code Civil isalso defined as the “name of birth” in the DGOS N°DGOS/MSIOS/2013/281 instruction
from 7 June 2013. Last name and name of birth are then regarded as similar. The
patronymic name is obsolete. The legal name should be present if known. This shall be aname type “L”.

•

The use name, defined by the circular of 26 June 1986: this name is variable through aperson’s life. It also may have been defined and may not be defined any longer a moment
later (a married person who had a marital name may get divorced without conserving it.)A use name is optional. This shall have a name type “D”.

•

A nickname: this name is an assumed name a patient is entitled to ask for if he fulfills
certain conditions, related to his notoriety. Such a name has no legal standing. A
nickname is optional. This shall have a name type “S”.

Reference on the name definition is available on the French administration website:
http://vosdroits.service-public.fr/N151.xhtml
In France, allowed HL7 types (L, D, S and U).
490

The last name (L type) is automatically conveyed in HL7 messages. The use name (D type) will
only be transmitted if it was defined (spouse’s marital name).
The surname prefix shall be in XPN-1 and not separated out as a sub-component. Other prefixes,
e.g., “Dr.” shall be in XPN-5
Examples (the ~ character separates two occurrences):

495

NOZIERE^Violette^^^^^L
Violette NOZIERE (last name, frequently known as birth name)
DE GUERMANTES^Orianne^^^^^D~DES LAUMES^Orianne^^^^^L
Orianne DE GUERMANTES (use name), born DES LAUMES (last
name)

500

Caesar^Julius^^^^^S
VIP registered under the pseudonym Julius Caesar
PID-6: Mother’s Maiden Name
“Mother’s Maiden Name” PID-6 is used to convey the mother’s birth name not the patient’s
birth name.

505___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

18

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
PID-8: Patient Sex
The following values shall be used:
HL7 table 0001 – Administrative Sex

510

Value
IHE FR

Description

Display
FranceF

FemaleFémininM

Male

Masculin

O

Other

Autre

U

Unknown

Inconnu

IHE fr Comments

PID-16: Marital Status
The following values shall be used:
PID-16: Marital Status
Value
IHE FR

Description

Display
FranceA

Separated

Séparé

D

Divorced

DivorcéG

Living together

Concubin

M

Married

Marié

P

Domestic
partner

PACS

SSingleCélibataireU

Unknown

InconnuW

Widowed

Veuf/Veuve

IHE fr Comments

PID-18 Patient Account Number
515

See below in ITI-31 for extra requirements.
Patient account number shall be present if PV1 segment is present.
The “Patient Account Number” PID-18 field is required in the context of the “Patient Encounter
Management” ITI-31 Transaction in France. This field is the account number that will be used by
the facility to issue invoices matching the services performed for the patient.

520

Its duration may exceed the limits of the patient’s visit to the hospital, either the beginning or theend of the stay.
Each visit in the establishment shall be associated to a patient account number.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

19

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
PID-32: Identity Reliability Code525

This field is used to encode the different identity status values set out by the GMSIH 3.
In France, the following 0445 table shall be used:
Value IHE
FR

Description

Recommended display

Translation

VIDE

Identité non encore qualifiée

Identity not qualified

PROV

Provisoire

Provisional identity

VALI

Validé

Validated Identity

DOUB

Doublon ou esclave

Duplicated identity

DESA

Désactivé

Disabled identity

DPOT

Doublon potentiel

Potential duplicatedidentity

DOUA

Doublon avéréReal duplicatedidentity

COLP

Collision potentielle

Potential collision

COLV

Collision validée

Validated collision

FILI

Filiation

filiation

CACH

CachéeHidden identity

ANOM

AnonymeAnonymIDVER

Identité vérifiée par le patient

Identity checked by
the patient

RECD

Reçue d’un autre domaine

Identity received
from anotheridentification domain

IDRA

Identité rapprochée dans un autredomaineIdentity crossreferenced in anotherdomainUSUR

Usurpation

Identity theft

HOMD

Homonyme détecté

Detected homonym

HOMA

Homonyme avéréReal homonym

IHE France
comments

4.1.2 Segments that apply only to ITI-30 and ITI-31
4.1.2.1 PD1 Segment
PD1-2: Living Arrangement

3

Value
IHE FR

Description

A

Alone

Recommended
display

IHE France comments

Seul

GMSIH : Groupement de Modernisation des Systèmes d’Information Hospitaliers___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

20

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________Value
IHE FR

Description

F

FamilyI

Institution

R

Relative

S

Spouse OnlyU

Unknown

H

Homeless

Recommended
display

Sans domicile fixe

IHE France comments

Added by IHE France forhomeless people

530
4.1.2.2 ROL Segment
The role that a physician takes when interacting with the patient is represented by a ROL
segment. This segment shall not be used to identify next of kin or responsible persons. The NK1
segment is used for that.
535
SEQ

LEN

1

60

2

DT

HL7
TBL#

Usage

Card.

ELEMENT NAMEIHE FR

EI

C[0..1]

2

ID

R[1..1]

287

Action Code*User table defined

3

250

CE

R

[1..1]

443

Role-ROL*

User table completedwith French values

4

250

XCN

R

[1..*]

Role Person

5

26

TS

O

[0..1]

Role Begin Date/Time

6

26

TS

O

[0..1]

Role End Date/Time

7

250

CE

O

[0..1]

Role Duration

8

250

CE

O

[0..1]

Role Action Reason

9

250

CE

O

[0..1]

10

250

CE

O

[0..1]

11

250

XAD

O

[0..1]

Office/Home
Address/Birthplace

12

250

XTN

O

[0..1]

Phone

Role Instance ID

Provider Type
406

Organization Unit Type

ROL-2: Action CodeHL7 Table 0287 - Problem/goal action code
Value IHE
FR

Description

Display France

IHE fr Comments

AD

ADD

New physician role

DE

DELETE

Cancellation of the physicianrole___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

21

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Value IHE
FR

Description

Display France

IHE fr Comments

UC

UNCHANGED

Notification of the physician
to be taken into account forthe defined role in the current
context

UP

UPDATE

Updating of the physician’srole

ROL-3 Role Nature (CE)540This element defines the role played by the physician.
Here follow values that are allowed by this national extension:
HL7 Table 0443 – Provider role

545

Value IHE
FR

Description

Display
France

IHE fr Comments

AD

AdmittingPV1-17 Admitting doctor
Physician from the institution that decides
to admit

AT

AttendingPV1-7 Attending doctor
Physician responsible for the patient during
the visit

CP (note3)

Consulting
ProviderConsulted physician for a second opinion,in the scope of the visit

FHCP

Family Health
Care
Professional

Family physician. Used in the few cases heis different from the officially declaredreferring doctor

RP

Referring
ProviderPV1-8 Referring doctor

RT

Referred toProviderCorrespondence physician (National Health
Insurance definition)

ODRP(note1)

Officially
Declared
Referring
PhysicianValue added by
IHE-France

Declared Referring Physician (National
Health Insurance definition)

SUBS (note2)

Substitute

Value added by
IHE-France

Declared Referring physician replacement

1st note: ODRP: « Declared Referring Physician ». Value added to the HL7 0443 table. Indeed, none of the existing values inthe table was likely to represent the Declared referring Physician. “FHCP” is a family physician that might go into a
ROL segment but that is not necessarily the declared referring physician. “RP” is the patient’s referring physician andmay be different from the declared referring physician (for instance a medical specialist).
2nd note: SUBS: “Substitute”. Value added to the HL7 0443 table (user defined). Corresponds to the physician who substitutes
the declared referring physician, currently absent.

550

3rd note: CP: “Consulting Provider”. The consulting physician is entirely detailed in a ROL segment, under the PV1/PV2
combination. The PV1-9 (Consulting doctor) field, which usage is X in the PAM Profile and downgraded by HL7 v2.5,
must not be used.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

22

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
4.1.2.3 NK1 Segment

555

ITI-30 (A28 and A31 messages) and ITI-31 (A05, A01, A04 and Z99 messages) transactions
convey the NK1 segment except if the NK1 segment corresponds to the trustworthy person(NK1-3=K). The latter shall be transmitted only using the ITI-31 transaction.
Each next of kin is described by a NK1 segment.
An NK1 segment transmits identities of next of kin or trustworthy persons.
SEQ

LEN

DT

OPT

1

4

SI

R

2

250

XPN

O

3

250

CE

O

4

250

XAD

O

5

250

XTN

6

250

XTN

7

250

CE

O

8

8

DT

9

8

10

R
P/#

TBL#

ITEM#

ELEMENT
NAME

00190

Set ID - NK1

00191

Name

00192

Relationship

Y

00193

Address

O

Y

00194

Phone Number

O

Y

00195

Business
Number

00196

Contact Role

O

00197

Start Date

DT

O

00198

End Date

60

ST

O

00199

Next of Kin /Associated Parties
Job Title

11

20

JCC

O

00200

Next of Kin /Associated Parties
Job Code/Class

12

250

CX

O

00201

Next of Kin /Associated Parties
Employee Number

13

250

XON

O

00202

Organization Name
- NK1

14

250

CE

O

0002

00119

Marital Status

15

1

IS

O

0001

00111

Administrative Sex

16

26

TS

O

00110

Date/Time of Birth

17

2

IS

O

00755

Living Dependency

Y
0063

0131

0327/0328

Y

Y

0223

IHE FR*

User
translated
completed

table
and

*

User
translated
completed

table
and

Phone

18

2

IS

O

Y

0009

00145

Ambulatory Status

19

250

CE

O

Y

0171

00129

Citizenship

20

250

CE

O

0296

00118

Primary Language

21

2

IS

O

0220

00742

LivingArrangement___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

23

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
SEQ

LEN

DT

OPT

R
P/#

TBL#

22

250

CE

O

0215

00743

Publicity Code

23

1

ID

O

0136

00744

Protection Indicator

24

2

IS

O

0231

00745

Student Indicator

25

25080

CE

X

0006

00120

Religion

26

250

XPN

O

00109

Mother’s
Name

27

250

CE

O

0212

00739

Nationality

28

250

CE

X

Y

0189

00125

Ethnic Group

29

250

CE

O

Y

0222

00747

Contact Reason

30

250

XPN

O

Y

00748

Contact
Name

31

250

XTN

O

Y

00749

Contact
Person’s
Telephone Number

32

250

XAD

O

Y

00750

Contact
Address

33

250

CX

R

Y

00751

Next
of
Kin/AssociatedParty’s Identifiers

34

2

IS

O

0311

00752

Job Status

35

250

CE

X

0005

00113

Race

36

2

IS

O

0295

00753

Handicap

37

16

ST

O

00754

Contact
SocialNumber

38

250

ST

O

01905

Next of Kin Birth
Place

39

2

IS

O

00146

VIP Indicator

Y

Y

0099

ITEM#

ELEMENTNAMEIHE FR

Forbidden
MaidenForbidden

Person’s

Person’s*

Required
IdentifiersFrance*Forbidden

PersonSecurity560
NK1-3: RelationshipThis field indicates the nature of the relationship of the person to the patient. This may be afamilial, professional or friendly relationship.
565

Note: According to the French regulatory requirements, the trustworthy person is bonded to the patient‘s visit (article L.11116 of the Public Health code).

HL7 User Defined Table 0063 - RelationshipValue

Description

Display France

ASC

Associate

Collègue

BRO

Brother

Frère

CGV

Care giver

Professionel de santé

CHD

Child

EnfantDEP

Handicapped dependent

Dépendant handicapé___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

24

Copyright © 2017: IHE International, Inc.

in

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Value

Description

Display France

DOM

Life partner

Compagnon

EMC

Emergency contact

Contact d'urgence

EME

Employee

Employé

EMR

Employer

Employeur

EXF

Extended family

Proche

FCH

Foster child

Enfant adoptif

FND

FriendAmi

FTH

Father

Père

GCH

Grandchild

Petits-enfants

GRD

Guardian

Tuteur

GRP

Grandparent

Grand-parent

MGR

Manager

Directeur

MTH

MotherMère

NCH

Natural child

Enfant naturel

NON

None

Aucun

OAD

Other adult

Autre adulte

OTH

Other

Autre

OWN

Owner

PropriétairePAR

ParentParent proche

SCH

Stepchild

Beau-fils

SEL

Self

Elle-même

SIB

SiblingFrère et soeur

SIS

SisterSoeur

SPO

SpouseEpoux

TRA

Trainer

Entraineur

UNK

Unknown

Inconnu

WRD

Ward of court

Tutelle judiciaire

Note: To transmit a relationship not in the table, set the NK1-3-1 field with the value “OTH” and the NK1-3-2 field with text
describing the relationship.

570

NK1-7: Contact RoleIHE France identified the values list, enclosed below.
HL7 User Defined Table 0131 - Contact Role
ValuesDescription

Display FranceE

Employer

Employeur

C

Emergency Contact

Personne à contacter en cas d'urgence

F

Federal Agency

Agence fédérale

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

25

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
ValuesDescription

Display France

I

Insurance Company

Compagnie d'assurancesN

Next-of-Kin

Parent proche

S

State Agency

Agence d'État

O

Other

Autre

U

Unknown

InconnuK

Confidence contact

Personne de confianceNK1-33: Next of Kin/Associated Party’s Identifiers
575This field is used to transmit the next of kin or trustworthy person’s identifiers.
All identifiers shall have both type (CX-5) and assignment authority (CX-4).
To identify next of kin or trustworthy persons, using the identifier type PN (Person Number) is
recommended.
This field NK1-33 is required.

580

4.1.2.4 PV1 Segment
HL7
TBL#

SEQ

LEN

DT

Usage

Card.

ELEMENT NAME

PV1-1

4

SI

O

[0..1]

PV1-2

1

IS

R

[1..1]

PV1-3

80

PL

C

[0..1]

PV1-4

2

IS

O

[0..1]

PV1-5

250

CX

C

[0..1]

PV1-6

80

PL

C

[0..1]

Prior Patient Location

PV1-7

250

XC
N

O

[0..*]

10

Attending Doctor

PV1-8

250

XC
N

O

[0..*]

10

Referring Doctor

PV1-9

250

XC
N

X

[0..0]

PV1-103

ISO[0..1]

PV1-11

80

PLC[0..1]

PV1-122

ISO[0..1]

87

Preadmit Test Indicator

PV1-132

ISO[0..1]

92

Re-admission Indicator

PV1-146

ISO[0..1]

23

Admit Source

PV1-152ISO[0..*]

9Ambulatory Status

PV1-162

ISO[0..1]

99

PV1-17

250

XC
N

O

[0..*]

PV1-182

ISO[0..1]IHE FR

Set ID - PV1
4

Patient Class*

restricted user table

Assigned Patient Location*

explanation

Admission Type*

User table completed

Preadmit Number*

explanation*

French user table*

French user table

VIP Indicator*

User table defined

10

Admitting Doctor*

18

Patient Type7

Consulting Doctor
69

Hospital Service
Temporary Location___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

26

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
HL7
TBL#

SEQ

LEN

DT

Usage

Card.

ELEMENT NAME

PV1-19250

CX

C[0..1]

PV1-2050

FCO[0..*]

64

Financial Class

PV1-212

ISO[0..1]

32

PV1-222

ISO[0..1]

PV1-232

ISO[0..1]

PV1-242ISO[0..*]

44

Contract CodePV1-258

DTO[0..*]

Contract Effective Date

PV1-2612

NMO[0..*]

Contract AmountPV1-27

3

NMO[0..*]

Contract Period

PV1-282

ISO[0..1]

73

Interest CodePV1-294

ISO[0..1]

110

Transfer to Bad Debt CodePV1-308

DTO[0..1]

PV1-31

10ISO[0..1]

PV1-32

12

NMO[0..1]

Bad Debt Transfer AmountPV1-33

12

NMO[0..1]

Bad Debt Recovery AmountPV1-341

ISO[0..1]

PV1-358

DTO[0..1]

PV1-363

ISO[0..1]

112

Discharge Disposition*

PV1-37

47

DL
D

O

[0..1]

113

Discharged to Location*

PV1-38250

CEO[0..1]

114

Diet Type

PV1-392

ISO[0..1]

115

Servicing Facility

PV1-40

1

IS

X[0..0]

PV1-412

ISO[0..1]

PV1-42

80

PLC[0..1]

Pending Location

PV1-4380

PLO[0..1]

Prior Temporary Location

PV1-4426

TSO[0..1]

Admit Date/Time

PV1-4526

TSO[0..1]

Discharge Date/Time

PV1-46

12

NMO[0..1]

Current Patient BalancePV1-47

12

NMO[0..1]

Total Charges

Visit Number*

Conditional value

Charge Price Indicator*

User table completed

45

Courtesy Code*46

Credit Rating

Transfer to Bad Debt Date
21

111

Bad Debt Agency Code

Delete Account Indicator
Delete Account Date
User table completed

Bed Status
117

Account Status

PV1-4812

NMO[0..1]

Total Adjustments

PV1-4912

NMO[0..1]

Total Payments

PV1-50250

CXO[0..1]

203

Alternate Visit ID

PV1-51

1

ISO[0..1]

326

Visit Indicator

250

XC
N

X

[0..0]

PV1-52IHE FR*

User table defined

Other Healthcare Provider

PV1-2: Patient Class
PV1-2 Shall have a value from the following table:___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

27

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Value IHE
FR

Description

Recommended
display

IHE France comments

E

Emergency

Visit to the emergency
department

Arrival to the emergency department

I

Inpatient

Inpatient admit

Full or partial inpatient admit, all types combined,
including long-term and home care retirement
facilities, post-acute care and rehabilitation...

N

Not ApplicableNot applicableNot applicable: Value used in the « Patient Identity
Feed » ITI-30 transactionO

Outpatient

Outpatient admit

Outpatient admit, including delivering medicines.

R

Recurring
patient

Recurring admit

Recurring admit

585
PV1-3: Assigned Patient Location (PL)This field contains the geographical location of the patient and the housing ward that takes
responsibility for their housing. The following elements shall be provided when known:
590•

PV1-3.1: Housing ward code (housing FU)•

PV1-3.2: room•

PV1-3.3: bed•

PV1-3.4: healthcare facility (HD)•PV1-3.5: bed status (unoccupied/occupied).
HL7 Table 0116 – Bed Status
Value
IHE FR

Description

LibelléconseilléO

Occupied

occupé

U

Unoccupied

libre

Commentaires d’IHE France

595
PV1-4: Admission Type (IS)HL7 Table 0007 – Admission Type
Value IHE
FR

Description

Recommended display

C

Elective

Comfort (plastic surgery)

L

Labor and
DeliveryChildbirth

N

Newborn (Birthin healthcare
facility)

Newborn

IHE France comments___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

28

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Value IHE
FR

Description

R

RoutineRoutineDefault value

U

UrgentAcute emergency problem
whatever is the admission ward

Example: Admission toophthalmology department, aglass shard in the eye

RM

Delivery

Delivery of medicines

Value added by IHE France
to define visits with deliveryof medicines purposes

Inter-facility services

Value added by IHE France
to define visits with services
billed to another facility
purposes.

IE

Recommended display

IHE France comments

PV1-5: Preadmit Number (CX)600

IHE recommends using the exact same pre-admission and admission numbers.
If the account number is different between the pre-admit message and the admission message,
the pre-admit account number shall be recorded in the admission message PV1-5 field.
Therefore, this field becomes conditional.

605

PV1-10: Medical price discipline/Hospital Service (IS)Values recorded in the 0069 table correspond to the B nomenclature (services disciplines)
excerpt from the 2005 healthcare facilities annual statistic published by the French Ministry of
Health available at:610

http://www.parhtage.sante.fr/re7/doc.nsf/VDoc/E7A685B20FF9E7A4C12576A3005BD49F/$FI
LE/NOM2009.pdf
PV1-14: Personalized admit mode (IS)Values shall be taken from table 0023 below when applicable. Additional items can be added
when this list lacks an item that meets the facility’s needs.

615

HL7 User Defined Table 0023 – Admit Source
Value IHE
FR

Description

Recommended display

1

Physician referral

Referred by an external
physician3

HMO referral

Convening to the hospital

4

Transfer from a
hospital

Transfer from another
healthcare facility

6

Transfer from another
health care facility

Admit by internal transfer

IHE France comments___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

29

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Value IHE
FR

Description

Recommended display

IHE France comments
The visit seems to be an
emergency, which is notdeductible from the fact thatthe patient comes from anemergency ward. This value
can be used when the patient isadmitted in emergency after an
accident.
Example: Admission toophthalmology department, aglass shard in the eye

7Emergency room

Emergency admit

8

Court/law enforcement

Admit under forces of law

90

Planned stayPlanned stay91

Personal decision

Personal decision

PV1-16: VIP Indicator
The PV1-16 field allows identifying a patient as a Very Important Person (VIP).
Values from user defined table 0099 shall be used in PV1-16.
620

User-defined table 0099 – VIP Indicator
Value IHE
FR

Description

Y

Yes

N

No

Recommended display

IHE France comments

PV1-17: Admitting Doctor

625

The physician working at the facility who decided to admit the patient. A ROL segment can
provide further details regarding this physician, following the segment group {PV1, PV2, … }(See above).
PV1-19: Visit NumberThis number corresponds to the patient’s physical stay in the healthcare facility: the visit. The
account number (PID-18) applies to one or more visits (PV1-19).

630

The PV1-19 field shall be present in ITI-31 Transactions and may be present in other uses of thePV1 segment. The PV1-2 field (patient class) determines how the PV1-19 field (visit identifier)shall be filled out and interpreted.
•

635

If PV1-2 equals I, then PV1-19 is required and identifies the visit for hospital or homecare.

If PV1-2 equals O, then PV1-19 is required and identifies the visit for medical acts andoutpatient registration, including visits for medicine delivery.
___________________________________________________________________________•

Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.030

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

640•

If PV1-2 equals R, then PV1-19 is required and identifies a recurring visit (a visit
identifier for each recurring visit is necessary).

•

If PV1-2 equals E, then PV1-19 is required and identifies the number of the visit to theemergency department.

•

If PV1-2 equals N (ITI-30 Transaction), then there are no visits and the rest of the PV1
segment shall be empty.

PV1-20: Financial Class

645

This is the rate code of the visit within the medical ward. The terminology will generally
correspond to the facility’s general terminology that unequivocally defines the rate of the staywithin the medical ward.
PV1-21: Charge Price Indicator

650

The national nomenclature, recorded in table 0032 below, corresponds to an excerpt of thenomenclature (Activity type) from the 2005 healthcare facilities annual statistics published by
the French Ministry of Health. Values sent in PV1-21 shall come from this table:
HL7 User defined Table 0032 – Charge Price Indicator
Value IHEFR

Recommended display

IHE France
comments

03

Inpatient care (excluding week hospitalisation)

04

Hospital day care05

Hospital night care

06

Home care

07

Consultations, outpatient care08

Operating unit (including obstetrical and gynaecological)

09

Other medico-technical wards (anaesthesiology, functional explorations,
physiotherapy and rehabilitation, pharmaceuticals)

10

Emergency department reception

11

Complete housing/residency (excluding during the week))

12

Night housing in partnered structures

13

Semi-residency

14

Day services

15

Host family care placement (strictly social)

16

Services in the living area (excluding host family care)17

Week residency

18

Night housing in fragmented structure

19

Ambulatory treatments

20

Week hospitalisation

21

Day-care reception

23

Ambulatory anaesthesia or surgeries___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

31

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Value IHEFR

Recommended display

IHE France
comments

24

Reception and management in therapeutical/psychiatric host family care
departments

25

Temporary holidays or week-ends housing

26

Biological medical tests

28

Dental consultations and care

32

Radiology (radio diagnostic and radiotherapy), medical imaging

33

Research

37

Reception and management in psychiatric therapeutical apartment

38

Reception and management in a psychiatric facility

39

Reception and management in a psychiatric crisis facility

97

Non-stated activity

PV1-22: Request for a private room
This field indicates to what extent the patient requested a private room.
655

The values in user-defined table 0045 shall be used in this field.
User-defined table 0045 – Courtesy Code
Value IHE
FR

Description

Recommended display

Y

Yes

Request for a private roomN

No

No request for a private room

IHE France comments

PV1-36: Discharge Disposition
The values in table 0112 shall be used in this field.
660

HL7 Table User-defined 0112 – Discharge Disposition
Value IHE
FR

Descripti
on

Recommended display

2

Disciplinary measures

3

Medical decision (default value)

4

Against medical advice

5

Awaiting medical tests

6

Personal reasonsR

Trial (Psychiatric context)

E

EscapeF

Fugue

IHE France comments___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

32

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Value IHE
FR

Descripti
on

Recommended display

A

Absence (<12h)PPermission (<72h)

S

Discharge with care program

B

Transfer to a MCO (Medical,
Surgery, Obstetric) facility

IHE France comments

PV1-37: Discharged to location

665

This shall be the destination establishment’s FINESS code. This field is used with the A03(discharge), A16 (pending discharge), A21 (in the scope of a transfer movement to anotherdepartment for a medical act (<48h)) events as well as with the Z99 event, which corresponds tothe update for each one of those events.
PV1-40: Bed Status

670

This field shall not be used. The value shall be sent in the “Patient Housing” PV1-3 field’s 5thcomponent. (See above).
PV1-41: Account Status
This field shall only be filled with the A03 (discharge) and Z99 (if the last discharge is updated)
trigger events. The field allows detailing whether the ending visit closes the account or not.

675

The values in table 0117 shall be used in this field.
HL7 User-defined Table 0117 – Account Status
Value IHE FR

Description

Recommended display

D

It was the last visit for this accountN

It was not the last visit for theaccount

IHE France
comments

4.1.2.5 PV2 Segment
SEQ

LEN

DT

Usage

Card.

PV2-1

80

PL

C

[0..1]

PV2-2

250

CE

O

[0..1]

PV2-3

250

CE

O

[0..1]HL7
TBL#

ELEMENT NAMEIHE FR

Prior Pending Location
129

Accommodation Code
Admit Reason*

User table createdfor psychiatry
assignment___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

33

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
SEQ

LEN

DT

Usage

Card.

HL7
TBL#

ELEMENT NAME

PV2-4

250

CE

O

[0..1]

Transfer Reason

PV2-5

25

ST

O

[0..*]

Patient Valuables

PV2-6

25

ST

O

[0..1]

Patient Valuables Location

PV2-7

2

IS

O

[0..*]

PV2-8

26

TS

O

[0..1]

Expected Admit Date/Time

PV2-9

26

TS

O

[0..1]

Expected Discharge
Date/Time

PV2-103

NMO[0..1]

Estimated Length of
Inpatient Stay

PV2-11

3

NMO[0..1]

Actual Length of Inpatient
Stay

PV2-1250

STO[0..1]

Visit Description

PV2-13

250

XCN

O

[0..*]

Referral Source CodePV2-14

8

DT

O[0..1]

Previous Service Date

PV2-151

IDO[0..1]

136

Employment Illness Related
Indicator

PV2-161

ISO[0..1]

213

Purge Status CodePV2-17

8

DTO[0..1]

PV2-182

ISO[0..1]

214

Special Program CodePV2-191

IDO[0..1]

136

Retention Indicator

PV2-201

NMO[0..1]

PV2-21

1

ISO[0..1]

215

Visit Publicity CodePV2-22

1

IDO[0..1]

136

Visit Protection Indicator

PV2-23

250

XON

O

[0..*]

PV2-242

ISO[0..1]

216

Patient Status CodePV2-251

ISO[0..1]

217

Visit Priority CodePV2-26

8

DT

O[0..1]

PV2-272

ISO[0..1]

PV2-288

DTO[0..1]

Signature on File Date

PV2-298

DTO[0..1]First Similar Illness Date

PV2-30250

CEO[0..1]

218

Patient Charge Adjustment
Code

PV2-312

ISO[0..1]

219

Recurring Service CodePV2-32

1

IDO[0..1]

136

Billing Media CodePV2-3326

TSO[0..1]

PV2-341

IDO[0..1]

136

Military Partnership CodePV2-351

IDO[0..1]

136

Military Non-Availability
Code

130

Visit User CodeIHE FR*

User tablecompleted

Purge Status Date

Expected Number of
Insurance Plans

Clinic Organization Name

Previous Treatment Date
112

Expected Discharge
Disposition*

User table defined

Expected Surgery Date andTime___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

34

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
SEQ

680

LEN

DT

Usage

Card.

HL7
TBL#

ELEMENT NAME

PV2-361

ID

O[0..1]

136

Newborn Baby Indicator

PV2-371

IDO[0..1]

136

Baby Detained Indicator

PV2-38250

CEO[0..1]

430

Mode of Arrival CodePV2-39250

CEO[0..*]

431

Recreational Drug Use CodePV2-40250

CEO[0..1]

432

Admission Level of Care
Code

PV2-41250

CEO[0..*]

433

Precaution CodePV2-42

250

CEO[0..1]

434

Patient Condition CodePV2-432

ISO[0..1]

315

Living Will CodePV2-442

ISO[0..1]

316

Organ Donor CodePV2-45250

CEO[0..*]

435

Advance Directive CodePV2-46

8

DT

O[0..1]

Patient Status Effective Date

PV2-4726

TSC[0..1]

Expected LOA Return
Date/Time

PV2-4826

TSO[0..1]

Expected Pre-admission
Testing Date/Time

PV2-4920

ISO[0..*]534

IHE FR*

French user table

Notify Clergy CodePV2-3: Admit Reason
This field indicates the type of assignment to psychiatry for the following events:

685•

A01 (Admit)•

A05 (Pre-admit)•

A06 (Change of status, outpatient or emergency to inpatient)•

A14 (Pending admit)•

Z99, if it updates one of the events above

Values allowed by this national extension are based on the “Legal care type” nomenclature,
available at: http://www.atih.sante.fr/index.php?id=0002F0006EFF. This is a non-exhaustive listthat may be updated according to the facility’s needs.
690___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

35

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________IHE Table PV2-3 – Admit Reason (Psychiatry)
Value
IHE FR

695

Description

Recommended display

IHE France comments

HL

Free Hospitalisation

Obsolete since 1 January
2012

HO

Involuntary Placement

Obsolete since 1 January
2012

HDT

Hospitalisation requested by a third party

Obsolete since 1 January
2012

JPI

Placement of a person regarded as criminally irresponsible(Penal Code 122.1 article and Public Health Code L32137 article)

Obsolete since 1 January
2012

OPP

Temporary placement order

DET

Prisoner (Code of Criminal Procedure D398 article)

SPP

Psychiatric care for imminent danger

SPL

Free Psychiatric care

SPAP

Psychiatric care with parental permission

SDREP

Psychiatric care following a request by the representativeof the State, by order of the prefect (L3213-1 article)

SDREM

Psychiatric care following the request by the
representative of the State, by order of the mayor (L.32132 article)

SDREIP

Psychiatric care following the request by the
representative of the State after having regarded theperson as criminally irresponsible (L.3213-7 article)

SPD

Psychiatric care of prisoners(Code of Criminal Procedure D.398 article)

SDT

Psychiatric care requested by a third party (2 certificates)(L.3212-1-II-1 article)

SDTU

Psychiatric care requested as an emergency by a third
party (1 certificate) (L3213-3 article)

SPI

Psychiatric care for imminent danger (1 certificate)(L.3212-1-II-2 article)

Obsolete since 1 January
2012

PV2-7: Visit User CodeThe PV2-7 field contains the care pathway indicator. The values in table 0130 shall be used inthis field.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

36

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
HL7 Table 0130 – Visit User CodeValue
IHE FR

Recommended
display

Description

IHE France
commentsTN

New officially declared referring physician(the patient changed his doctor or declared this
doctor for the 1st time)TD

Specific direct admit

TU

Emergency: (The patient gets to theemergency, with no recommendation from theofficially declared referring doctor)

TH

Outside usual homeTR

The patient is referred by the officiallydeclared referring doctor’s substituteMR

Consulted doctor = officially declaredreferring doctor’s substituteTO

patient referred by the officially declaredreferring doctor (The patient sees anotherphysician on the advice of their officiallydeclared referring doctor: (care sequence))ME

consultation of the officially declared referring
doctor = consulted doctor

1C1ère officially declared referring doctor
consultation for opinion

IT

Recurring care in accordance with theofficially declared referring doctor (D162-1-6
par. 1 or 2)

AG

The patient is less than 16 at the time of theconsultation

No B2 codeMT

The patient is referred by the hospital company
works doctor

No B2 codeCS

Out coordination admit (admit on the patient’s
own initiative, without consulting the officiallydeclared referring doctor)

SM

The patient has not declared any officiallydeclared referring doctor

ML

A military person, under army medicalprescription (D162-1-6 SS Article) (patient notreferred by the officially declared referring
doctor)EM

Medical exclusion (smoking, alcoholism, ...)
(D162-1-6 SS Article) (patient not referred by
the officially declared referring doctor)

NT

The patient is referred by a physician who is
not their officially declared physician

PI

The performer is a general practitioner who
has recently been installed.

ZD

The performer is a general practitioner who
has recently moved in a medical deficit area___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

37

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________Value
IHE FR

Recommended
display

Description

IHE France
comments

AL

Acts & consultations planned in the scope of
ALD D162-1-6, 3rd paragraph care protocol

PS

Acts & consultations in the scope of ALD
D162-1-6, 5th paragraph care protocol

AM

State Medical Support (SMS)No B2 code

CI

Foreigner taken care of in the scope ofinternational conventions.

No B2 codeET

Foreigner taken care of – other circumstances(regular status)

MI

Passage migrant (L254-1)

DT

Non active care pathway (Care pathway thatbegan before the implementation date of theregulation)

MA

Special case of Mayotte’s fundAS

Any other circumstances

700
The current legal context requires the coordinated care pathway indicator for the A04(outpatient) and A07 (change of status; inpatient to outpatient) events. In other words, theindicator is required for outpatient registrations.
A Z99 event may update the indicator, updating all the events above, if needed.
705

710

•

The officially declared physician: ROL segment (“ODRP”) following the PID/PDI
combination•

The corresponding doctor: ROL segment (“RT”) following the {PV1, V2, ZBE, … }segments combination•

The officially declared physician’s substitute: ROL segment (“SUBS”) following the{PV1, V2, ZBE, … } segments combination

PV2-30: Patient Charge Adjustment CodeThis field specifies whether a movement is billable or not. If present, values shall come fromtable 0218:
HL7 Table 0218 – Charge adjustment
Value IHE FR

715

Description

Recommended
displayF

BillableN

Not billable

IHE France
comments
Default value

PV2-38: Mode of Arrival CodeThis field is required, if known, for the following events:• A01 (Admit)___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

38

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

720•

A05 (Pre-admit)•

A06 (Change of status, outpatient or emergency to inpatient)•

A14 (Pending admit)•

Z99, if it updates one of the events above

The values in table 0430 shall be used in this field.
HL7 User-defined Table 0430 – Mode of Arrival Code
Value IHE FR

725

Description

Recommended
display0

Police1

Emergency medical
assistance service,land-based2

Public Ambulanceservice3

Private Ambulanceservice

4

Taxi

5

Personal means

6

Emergency medical
assistance service byhelicopter

7

Firefighters

8Lightweight healthvehicle9

OthersIHE France
comments

4.1.2.6 ACC segment
The ACC segment shall be present when a patient is admitted to a facility following an accident.
SEQ

LEN

ACC-1

26

ACC-2

DT

HL7
TBL#

Usage

Card.

ELEMENT NAME

TS

RE

[0..1]

250

CER[1..1]

ACC-3

25

ST

O

[0..1]

Accident Location

ACC-4

250

CE

X

[0..0]

Auto Accident State

ACC-5

1

ID

O

[0..1]

136

Accident Job Related
Indicator

ACC-6

12

ID

O

[0..1]

136

Accident Death Indicator

ACC-7

250

XCN

O

[0..1]IHE FR

Accident Date/Time
50

Accident Code*User tabledefinedEntered By___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

39

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
SEQ

LEN

ACC-8

25

ACC-9

DT

HL7
TBL#

Usage

Card.

ST

O

[0..1]

Accident Description

80

ST

O

[0..1]

Brought In By

ACC10

1

ID

O

[0..1]

ACC11

250

XAD

O

[0..1]

136

ELEMENT NAMEIHE FR

Police Notified Indicator
Accident Address

ACC-2: Accident Code730

This field details the nature of the accident according to the standard nomenclature. The values intable 0050 shall be used in this field.
HL7 Table User-defined 0050 – Accident CodeValue
IHE FR

735

Description

Recommended display

P

Accident on public roadT

Occupational accident

D

Accident in the home

S

Sport accidentJ

Commuting accident

C

Assault and battery

L

School accident

B

Plan Blanc

U

Unknown accident nature

IHE France
comments

Example: Accident on public road, 25 December, 1:20 A.M.
ACC|200512250120|P^Accident on public road

4.1.2.7 ZBE Segment: Action on a movement
HL7
TBL#

SEQ

LEN

DT

Usage

Card.

ELEMENT NAME

1

427

EI

R

[0..*]

Movement ID

2

26

TS

R

[1..1]Start of Movement Date/Time

3

26

TS

X

[0..0]End of Movement Date/Time

4

6

ID

R

[1..1]

Action on the Movement

5

1

ID

R

[1..1]

Indicator “Historicalmovement”

6

3

ID

C

[0..1]

Original trigger event code

IHE FR*

Forbidden in
France___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

40

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

740

HL7
TBL#

SEQ

LEN

DT

Usage

Card.

7

6

XON

O

[0..1]

Ward of medical responsibility
in the period starting with thismovement

*

8

6

XON

O

[0..1]

Ward of care responsibility inthe period starting with thismovement

*

9

3

CWE

R

[1..1]Nature of this movement

*

IHE
ZBE-9

ELEMENT NAMEIHE FR
explanation

French field

French field

This segment identifies a movement excerpt from the sequence of the movements corresponding
to a patient’s visit (see the definition of these terms at ITI TF-2b: 3.31.4. The segment details theaction that will be implemented on this movement: Insert, Cancel, Update.
Insertion can add a new movement only at the end of a sequence. Cancellation shall only be
carried out on the current movement, the last known in the sequence. Updating can be done on
every movement of the sequence.

745

The following paragraphs reuse the ZBE-1 to ZBE-6 definitions, excerpt from IHE ITI TF-2b:
3.31.6.1.
As specified in ITI TF-2b: 3.31.5.6 (Historic Movement Management), the ZBE segment isrequired for the following events:

750

A01, A02, A03, A04, A05, A06, A07, A11, A12, A13, A14, A15, A16, A21, A22, A25, A26,
A27, A38, A52, A53, A54, A55, Z99.
The ZBE segment is also required for the following French extension events:

755

760

•

Z80: Change of medical ward•

Z81: Cancellation of a change of medical ward•

Z82: Change of pending medical ward•

Z83: Cancellation of a change of pending medical ward•

Z84: Change of nursing ward•

Z85: Cancellation of a change of nursing ward•

Z86: Change of pending nursing ward•

Z87: Cancellation of change of pending nursing ward•

Z88: Change of the conditions of the medico-administrative management•

Z89: Cancellation of change of the conditions of the medico-administrative management___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

41

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
ZBE-3: End Movement Date/Time
Forbidden.
765
ZBE-7: Medical Responsible Ward
This field provides the code of the ward that is medically responsible for the patient.
The required elements (when known) are:
770

775

•

ZBE-7.1: The ward’s display name•

ZBE-7.6: Identifier of the assignment authority that granted the responsible ward an
identifier.

•ZBE-7.7: The value of this field shall be “Ward”•

ZBE-7.10: Identifier of the medically responsible ward.

ZBE-8: Nursing care Responsible Ward
This IHE France-added field provides the code of the ward that is responsible for the nursing
care.
The required elements (when known) are:

780

785

•

ZBE-8.1: Display name of the ward•

ZBE-8.6: Identifier of the assignment authority that granted the responsible ward an
identifier.

•ZBE-8.7: The value of this field shall be “Ward”•

ZBE-8.10: Identifier of the nursing care responsible ward.

ZBE-9: Nature of the movement (CWE)
This field details the nature of the element(s) that was (were) submitted to a change of situation
since the ZBE-2 movement date.
Allowed values are:
IHE Table ZBE-9 – Nature of movement
Value IHE
FR

Description

Recommended display

S

Change of nursing care responsibility only

H

Change of housing responsibility only

M

Change of medical responsibility only

L

Change of bed only

IHE France
comments___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

42

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Value IHE
FR

Description

Recommended display

IHE France
comments

D

Change of medico-administrative management
leaving responsibilities and location for the patient
unchanged.

(ex : change of the ward’s
visit fee )SM

Change both of nursing and medical responsibilities

SH

Change both of nursing and housing responsibilities

MH

Change both of housing and medical responsibilities

LD

Change of bed and medico-administrative
management, leaving responsibilities unchanged

HMS

Simultaneous change of the three responsibilities

C

Updating or change of patient’s administrative status
without generating any movement790
4.1.2.8 ZFA segment
SEQ

LEN

DT

Usage

Card.

HL7 TBL#ELEMENT NAMEIHE FR

1

20

ID

RE

[0..1]

Patient’s PHR status

*

2

26

TS

RE

[0..1]

Patient’s PHR status collection date

*

3

26

TS

RE

[0..1]

Patient’s PHR closing date

*

4

1

ID

RE

[0..1]

Valid access authorization to thepatient’s PHR, granted to the facility

*

5

26

TS

RE

[0..1]

Collection date of the status of the
facility’s access authorization to thepatient’s PHR

*

6

1

ID

RE

[0..1]

Opposition of the patient to the “bris deglace” mode access (see 1st note)

*

7

1

ID

RE

[0..1]

Opposition of the patient to the “centre
15” mode access (see 2nd note)

*

8

26

TS

RE

[0..1]

Collection date of the status of
oppositions issued by the patient*This segment is required for the following events: A01, A04, A05 and Z99. It gives some
information regarding the existence of the patient’s PHR.
795

1st note:
The “bris_de_glace” value allows access to information without the patient’s consent, under certain conditions
defined by the target system. This value must not be used except for exceptional emergency situations.
2nd note:

The value “centre_15” is uniquely reserved for emergency services call and dispatch centers.

ZFA-1 Patient PHR’s status (ID)800

This field is required if known (RE). It gives details about the existence and the usability of thepatient’s PHR. If valued, one of these three values shall be used:___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

43

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

805•

ACTIVE: The patient’s PHR exists and is not closed.

•

CLOSED: The patient’s PHR exists and is closed.

•

NONEXISTENT: The patient’s PHR doesn’t exist.

The information is not historically recorded; the Patient Encounter Supplier Actor conveys thelast known status for the patient.
ZFA-2 Patient’s PHR status collection (TS)This field is required if known (RE). It provides the patient’s PHR status collection date.

810
ZFA-3 Patient’s PHR closing date (TS)This field is required if known (RE). It provides the patient’s PHR closing date.
ZFA-4 Valid access authorization to the patient’s PHR, granted to the organization (ID)815This field is required if known (RE). If valued, one of these two values shall be used:
Y: The organization has a valid access authorization
N: The organization does not have any valid access authorization for this PHR

820

ZFA-5 Collection date of the status of the organization’s access authorization to the patient’s
PHR (TS)This field is required if known (RE).
ZFA-6 Opposition of the patient to the « bris de glace » mode access (ID)This field is required if known (RE). If valued, one of these two values shall be used:

825

Y: The patient is opposed to the “bris de glace” use of their PHR
N: The patient is not opposed to the ‘bris de glace” use of their PHR
The “bris_de_glace” mode allows access to information without the patient’s consent, undercertain conditions defined by the target system. This value must not be used except for
exceptional emergency situations.

830
ZFA-7 Opposition of the patient to the « centre 15 » mode access (ID)This field is required if known (RE). If valued, one of these two values shall be used:
Y: The patient is opposed to the “centre 15” use of their PHR___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

44

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
N: The patient is not opposed to the “centre 15” use of their PHR
835

The “centre_15”mode access is uniquely reserved for emergency services call and dispatch
centers.
ZFA-8 Collection date of the status of oppositions issued by the patient (TS)This field is required if known (RE).

840

4.1.2.9 ZFV Segment: Additional information regarding the encounter
The French ZFV segment is required in a hospital or clinical context in the “Patient Encounter
Management” ITI-31 Transaction for the following events:

845

850

•

A01 (Admit)•

A02 (Transfer)•

A03 (Discharge)•

A04 (Outpatient)•

A05 (Pre-admit)•

A14 (Pending admit)•

A21 (Temporary discharge, absence, transfer movement to another department•

Z99, when the updated movement corresponds to one of the events above
SEQ

LEN

1

47

DT
DLD

Usage

Card.

O

HL7
TBL#

ELEMENT NAMEIHE FR[0..1]

Establishment oforigin and date of thelast visit to this facility*

Discharge transportmode (nomenclature
displayed in the 0430
table, see above, under
the PV2-28 field
description)

*

2

250

CE

O

[0..1]

3

2

IS

X

[0..0]

Pre-admit type

*
*

4

26

TS

O

[0..1]

Placement starting
date (psy)

5

26

TS

O

[0..1]

Placement ending date
(psy)

*

6

250

XAD

O

[0..2]

Establishment oforigin or destination
establishment address

*

7

250

CX

O

[0..1]

Establishment oforigin account number*___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

45

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
SEQ

LEN

8

250

9
10

DT

Usage

Card.

CX

O

6

IS

2

IS

HL7
TBL#

ELEMENT NAMEIHE FR[0..N]

Archive number*O[0..1]

Personalizeddischarge mode*C

[0..1]

legal care mode RIMP code transmitted in
the PV2-3*

ZFV-1: Establishment of origin (DLD)855

ZFV-1.1: (IS) FINESS code identifying the establishment of origin before the beginning of thevisit: FINESS codes nomenclature: 0113 table
ZFV-1.2: (TS) Last inpatient admit date (if known)
ZFV-2: Discharge transport mode (CE)860

Admit (PV2-38) and discharge (ZFV-2) transport modes can be used for both normal (A03) andtemporary discharges like “permission”(fr) or transfer to another facility (another legal entity).
ZFV-3: Pre-Admission type (IS)Forbidden. The pre-admit type is supplied by the PV1-2, PV1-4 and PV1-21 elements when theevent’s type is “pre-admit” (A05: “Pre-admit a patient”)

865
ZFV-4: Placement starting date/time (psy) (IS)To be provided for the placement period concerned by the message-referenced visit.
ZFV-5: Placement ending date/time (psy) (IS)870

To be provided for the placement period concerned by the message-referenced visit.
ZFV-6: Establishment of origin or destination address (XAD)875This field of cardinality [0..2] may contain either the facility of origin/destination address orboth addresses. Each address is identified by ZFV-6.7 component (Address Type) and shall beeither “ORI” for origin or “DST” for destination.
See the complete XAD data type description in the “IHE France constraints on common HL7
data types for ITI Profiles” document.
___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

46

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
ZFV-7: Establishment of origin’s account number (CX)
880

This field may contain the establishment of origin’s account number. In can be used within thescope of inter facilities services.
ZFV-9: Personalized discharge mode

885

This field may contain the code that corresponds to the personalized discharge mode. The “userdefined” value table shall be defined according to the facility’s needs.
ZFV-10: Legal care mode code RIMP (CE)This conditional field shall be filled when the legal care mode is transmitted (PV2-3 field).

890

The values in the following table shall be used, according to the official RIM-P codes
documentation:
IHE Table 3302 – RIMP Code
RIM-P CodeRecommended Display

1

Free psychiatric care

3

Psychiatric care following a request by the representative of the State

4

Code of Criminal Procedure 706-135 article and Code of Public Health L. 3213-7 article for
persons regarded as criminally irresponsible

5

Temporary Placement Order6

Prisoners: Code of Criminal Procedure D.398 article

7

Psychiatric care following a request by a third party (2 certificates)
Or
Psychiatric care following an emergency request by a third party (1 certificate)

8

Psychiatric care for Imminent danger (1 certificate, no third party)

Since the PV2-3 field’s type is “user defined”, the editor shall make sure to check thecorrespondence between the PV2-3 field and the RIM-P code.
895

Example:For the legal SDREP & SDREM care modes, defined as follows in the PV2-3 field:

PV2|||SDREP^ Psychiatric care following a request by the representative of the State, by order ofthe prefect |

900

or

PV2|||SDREM^ Psychiatric care following the request by the representative of the State, by orderof the mayor | ,___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

47

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
ZFV-10 field would take the following value:

ZFV||||||||3^Psychiatric care following a request by the representative of the State |905
4.1.2.10 ZFM segment: DRG movement
This segment allows conveying the information about the DRG.

910

DRGs : Diagnosis-related group (DRG) is a system to classify hospital cases into one oforiginally 467 groups,[1] with the 467th group being "Ungroupable". This system ofclassification was developed as a collaborative project by Robert B Fetter, PhD, of the Yale
School of Management, and John D. Thompson, MPH, of the Yale School of Public Health.[2]The system is also referred to as "the DRGs", and its intent was to identify the "products" that ahospital provides.
The ZFM segment shall be present.

915

Note: The ZFM segment may be replaced by future HL7 developments supporting DRGs, Invoicing, etc. Until that time, theZFM segment is used. Software should be prepared to manage a future transition from ZFM to HL7 standard segments.

SEQ

LEN

DT

Usage

Card.

HL7 TBL#ELEMENT NAMEIHE FR

1

1

IS

O

[0..1]IHE ZFM-1

PMSI admission mode

*

2

1

IS

O

[0..1]IHE ZFM-2

PMSI discharge mode

*

3

1

IS

O

[0..1]IHE ZFM-34

PMSI establishment oforigin mode

*

4

1

IS

O

[0..1]IHE ZFM-34

PMSI destination mode*

The French ZFM segment is required for the following events:
920

925

930

•

A01 (Admit)•

A02 (Transfer)•

A03 (Discharge)•

A04 (Outpatient)•

A05 (Pre-admit)•

A14 (Pending admit)•

A21 (Temporary discharge, absence, transfer movement to another department•

A22 (Return following the transfer to another department for a medical act (<48H))•

Z80: Change of medical ward•

Z81: Cancellation of a change of medical ward•

Z82: Change of pending medical ward___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

48

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

935•

Z83: Cancellation of a change of pending medical ward•

Z84: Change of nursing ward•

Z85: Cancellation of a change of nursing ward•

Z86: Change of pending nursing ward•

Z87: Cancellation of change of pending nursing ward•

Z99 (when the updated movement corresponds to one of the events above)

ZFM-1: DRG admit mode (IS)Values allowed by this national extension are:940

IHE Table 3303– DRG admit mode
Value IHE FR

Description

Recommended
display

IHE France comments

0Transfer for medical
act

Temporary visit of the patient to thehospital

6

Move (Same facility)

Arrival of the patient in the ward

7

Arrival from anotherfacility

Arrival of the patient to the hospital8

Any other cases ofarrivals

Visit from home, retirement house,public place, with or without
reception to the emergency
department.

ZFM-2: DRG discharge mode (IS)The values in the following table shall be used in this field.
IHE Table 3304– DRG discharge mode
Value IHE FR

Description

Recommended display

IHE France comments

0Transfer for medical act

4

Fugue or discharge against
medical opinion

Temporary discharge

5

Discharge test

Temporary discharge from thepsychiatric facility. (1)6Transfer (same facility)

The patient leaves the ward

7

Transfer

8

Leaving to home or similar

Permanent discharge

9

Death

Permanent discharge___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

49

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
945

(1)

This is an obsolete value since March 2012, date on which the methodological “collecting medical psychiatricinformation” production guide was released. It is available at:
http://www.sante.gouv.fr/IMG/pdf/sts_20120004_0001_p000.pdf

ZFM-3: DRG origin mode (IS)950

The values the following table shall be used in this field.
IHE Table 3305– DRG origin and destination modes
Value
IHE FR

Description

Origin or
Destination

IHE France comments

1

Acute care nursing ward
(MCO) except
resuscitation ward

2

Long-term care or
rehabilitation care ward

3

Long-term care ward

4

Psychiatric care ward

5

Reception to thefacility’s emergency
department

6Home-based
hospitalisation

7

Medico-social housing
structure

D

Home

Empty value

From a resuscitation carewardThis code is used in case of the admission was made bypermanent or temporary transfer (Admit mode « 0 » or « 7 »code) from a neonatal, pediatric or adult resuscitation careward. Used in the scope of the PMSI MCO.

Only used for the origin mode
(ZFM-3)

R

Allowed values are those displayed in the methodological guide “Production of summaries of
DRG encounters” available at: http://www.atih.sante.fr
955

For example, a value of “1” in ZFM-3 would mean that the patient is transferring from an acutecare nursing ward.
ZFM-4: DRG destination mode (IS)See the IHE ZFM-3-4 Table – DRG origin and destination mode

960

Allowed values are those displayed in the methodological guide “Production of summaries of
DRG encounters” available at: http://www.atih.sante.fr___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

50

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________For example, a value of “1” in ZFM-4 would mean that the patient is transferring to an acute carenursing ward.
4.1.2.11 IN1; IN2; IN3: Medical coverage965

HL7 v2.5 chapters 3 and 6 specify the order and structure of IN1, IN2, and IN3 segments withina message. The field definitions within France are as follows.
4.1.2.11.1 Compulsory Health Insurance (CHI) coverage related to the patient’s
account

970

A [IN1, IN2, IN3] sequence from the “segment group INSURANCE” represents a Compulsory
Healthcare Insurance (CHI) coverage period. Management information (medical management
rate, third-party payer…) shall be repeated for each sequence.
The displayed data are:Coverage information
CHI
Organisation

InsuredType[lg]
HL7

Field

Usage

Card.

Comments

Source/values

Type of payer

CE[250]IN1-2

R[1..1]A CHI
organization or
the State Medical
Assistance(SMA) or the
Universal Health
Cover (UHC)« CHI», « SMA »,« UHC »
See 0068 tableredefined by IHE
France, Section
4.1.2.11.3.

Insurance scheme +fund + paying
centerCX[250]IN1-3

R[1..1]

Schemesuccession (2),management fund(3), management
center (4)Vitale smart card orlegal attestation.
List is available atwww.sesamvitale.fr(Beneficiaryorganisations
codification table)

IRN (Insurance
Register Number)

CX[250]IN1-49RE[0..1]

NIR

Vitale smart card orlegal attestation.

Management code
read on the legal
attestation orprovided by Vitalecard API.

IS[20]

IN1-35

RE[0..1]

2 alphanumericalcharacters

Vitale card
List available atwww.sesamvitale.fr (CDC 1.40Workstation data
dictionary)

Identity

XPN[250]IN1-16

RE[0..1]

Last name, first
name

Address

XAD[250]IN1-19RE[0..1]

Telephones

XTN[250]IN2-63

RE[0..1]

Beneficiary___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

51

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Coverage information

CoverageperiodVisitcoverage

Type[lg]
HL7

Field

Usage

Card.

Comments

Source/values

Birth order

NM

PID-25

RE[0..1]« Birth order », apositive integer
for a multiple
birth.
Otherwise it
remains empty

Vitale card or legal
attestation

Beneficiary’s status

CE[250]IN1-17

R[1..1]

2 alphanumericalcharacters

Vitale card or legal
attestation.
List available atwww.sesamvitale.fr (CDC 1.40Workstation data
dictionary)IN1-12

RE[0..1]

As many [IN1,IN2, IN3]
sequences as
there are CHI
coverage periods

Beginning
DT[8]

End

DT[8]

IN1-13

RE[0..1]

Exemption from copayment

IS[3]IN1-15

RE[0..1]

1 alphanumericalcharacterB2 standard,
Appendix 9

CHI supporting
documentation’s
natureST[2]IN1-45

RE[0..1]

1 alphanumericalcharacterB2 standard,
Appendix 8

Patient
Management
requestAUI[239]

IN1-14

O[0..1]

Authorisation
date of delivery(YYYYMMDD)

Insurance’s natureIS[2]IN1-31

RE[0..1]

10 (disease), 13(Alsace-Moselledisease), 30(Maternity), 41(Work accident),
90 (prevention)

B2 standard (type 2position 77-78)___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

52

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Coverage information
Work accident
number or common
right accident dateor pregnancy
starting date or
childbirth date or
adoption dateType[lg]
HL7

Field

Usage

Card.

Comments

ST[15]

IN1-36

C[0..1]

If accident :Work accident(Insurance nature= 41), display then°AT
Common right
accident (withinsurance nature= 10 or 13),
display date
(YYYYMMDD)
If pregnancy,
childbirth or
adoption(insurance nature= 30), display
corresponding
date(YYYYMMDD)
Date will be
displayed using
one character:
D: Beginning of
the pregnancy
R: Last menses
date
A: Childbirthdate
O: adoption

PV2-7

RE

[0..1]

See PV2 segment
in Frenchextension

B2 standard,
Appendix 25
These values are
similar for eachsegment recurrenceIN1-20RE[0..1]

Y / N (= refund
the insured)

B2 standard,
Appendix 25
These values are
similar for eachsegment recurrence

Care pathway
situation

Third-party payer
(Y/N)

IS[2]

Source/values___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

53

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

975

980

Coverage information

Type[lg]
HL7

Field

Usage

Card.

Patient Medical
Management rate

MOP[23]IN3-5

RE[0..1]

Comments

Source/values
B2 standard,
Appendix 25
The information canbe disaggregatedinto three subfields.
Here, IN3-5.1 must
equal 'PB' whichmeans « percentageof the base ofreimbursement (seethe 0146 table in
Section 4.1.2.11.3).
IN3-5.2 contains thepercentage(example 60).

4.1.2.11.2 Complementary private health insurance (CPHI) or Complementary
Medical Assistance (CMA), or Universal Complementary Health (UCH) coveragerelated to the patient’s account
A [IN1, IN2, IN3] sequence following the CHI coverage represents either a Complementary
Private Health Insurance (CPHI), or a Universal Complementary Health Coverage (UCHC), or aComplementary Medical Assistance coverage (CMAC). There might be several complementaryorganizations that share the patient’s management. For each one of them, only one Entitlement
period is transmitted: the one that is likely to be applied to the visit. Hence, a complementaryorganization is represented by only one [IN1, IN2, IN3] sequence.
Coverage information

Type[lg]
HL7

Field

Usage

Card.

Comments

Source/values

CPHI
OrganizationType of payer

CE[250]IN1-2

R[1..1]CPHI or UCHC
complementaryorganization or
CMA coverage« CPHI »,« UCHC »,« CMA »
See 0068 tabledefined by IHE
France, in Section
4.1.2.11.3

Complementar
y organization
numberCX[250]IN1-3

R[1..1]« CPHI »,« UCHC » or
« CMA »
numberEntitlement support(card or entitlement
attestation)

Memberidentifier

CX[250]IN1-49RE[0..1]CPHI member

Entitlement support(card or entitlement
attestation)

Identity

XPN[250]IN1-16

RE[0..1]

Last name, first
name

Address

XAD[250]IN1-19RE[0..1]

Insured___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

54

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Coverage information

Beneficiary

Type[lg]
HL7

Field

Usage

Card.

Telephones

XTN[250]IN2-63

RE[0..1]

Beneficiary’s
statusCE[250]IN1-17

R[1..1]

CPHI
entitlement
periodVisitcoverage

Comments

Source/values

2 alphanumericalcharacters

Vitale card orentitlement
attestation.
List available atwww.sesamvitale.fr (CDC 1.40Workstation data
dictionary)

A single period
percomplementaryorganization:
The one thatapplies to thisvisit.
BeginningDT[8]IN1-12

RE[0..1]End

DT[8]IN1-13

RE[0..1]Nature of the
CPHI
supporting
documentation

ST[2]IN1-45

RE[0..1]

1 numericalcharacterB2 standard,
Appendix 8

Type ofcontract

IS[2]IN1-31

RE[0..1]

85 (UCHC
outgoing
members
managed by
CHI)
87(UCHCoutgoing
members
managed by
CPHI)
88 (support formutualizing
funds outgoingmembers), 89(current UCHC
beneficiary)
01 (CMA)
02(Complementary
CMA)

Provided by thefund (entitlement
document)___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

55

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Coverage information

Type[lg]
HL7

Field

Usage

Card.

Comments

Patient
MedicalManagement
rate

MOP[23]IN3-5

RE[0..1]

Managedservices

RMC[82]IN2-28

O[0..*]

IN2-28.1 :« DR» = Daily
rate« PRI » = Privateroom
IN2-28.2 :« Y » = Covered« N » = no
« L » = limited

Third-party
payer(Yes/No)IS[2]IN1-20RE[0..1]

Y / N (= refund
the insured)

Source/values
This information
can bedisaggregated into
three subfields.
Here, IN3-5.1
displays the natureof the rate, using avalue allowed by
the 0146 table (see0146 Table in
Section 4.1.2.11.3).
IN3-5.2 contains thepercentage(example 100)985
4.1.2.11.3 Other payer
The ITI-31 Transaction messages can transmit information regarding several other payers: thepatient, the insured, the employer, an external facility, a county…
A [IN1, IN2] sequence represents such a payer
990
Coverage information

Type[lg]
HL7

Field

Usage

Card.

Comments

Source/values

payer/drawee

Type ofpayer

CE[250]IN1-2

R[1..1]

Patient
InsuredExternal
Facility
Employer
County

PAT, INS, EMP,
EXTF, COU:
0068 tabledefined by IHE
France, see below
in this section.

Name or
corporate
name

XPN[250]IN1-16

RE[0..1]First name

XPN[250]IN1-16

RE[0..1]___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

56

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Coverage information

Type[lg]
HL7

Field

Usage

Card.

Addresses

XAD[250]IN1-19RE[0..1]

Telephones

XTN[250]IN2-63

RE[0..1]

BeginningDT[8]IN1-12

RE[0..1]End

DT[8]IN1-13

RE[0..1]Nature ofthesupporting
document

ST[2]IN1-45

RE[0..1]

Entitlement
periodVisitcoverage

Comments

Source/values

1 numericalcharacter

Values that shall be used for the IN1-2 field are displayed in the 0068 “user defined” table (HL7)
and defined by IHE France:
Table User-defined 0068: Guarantor TypeIHE FR
value

Englishvalue

French display

Comments

AMO

CHI

Compulsory Health Insurance

Introduces a [IN1, IN2, IN3] sequencethat represents a coverage period by
the compulsory health insuranceorganisation that covers the visit.

CMU

UCHC

CMU caisse

Introduces a [IN1, IN2, IN3] sequencethat represents a coverage period of thevisit by a Couverture Maladie
Universelle caisse

AME

SMA

State Medical AssistanceIntroduces a [IN1, IN2, IN3] sequencethat represents a coverage period by aState medical assistance

AMC

CPHI

Complementary Private Health
Insurance

Introduces a [IN1, IN2, IN3] sequencethat represents a complementary
private health insurance that covers
the visit.

CMUC

UCHC

Universal Complementary Health
CoverIntroduces a [IN1, IN2, IN3] sequencethat represents a universal
complementary health cover thatmanages the visit

AMEC

CSMA

Complementary State Medical
AssistanceIntroduces a [IN1, IN2, IN3] sequencethat represents a complementary state
medical assistance that covers
the visit

PAT

PAT

Patient

Introduces a [IN1, IN2] sequence thatprovidesdetailed information about the patient
as a payer___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

57

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________IHE FR
value

Englishvalue

French display

Comments

ASS

INS

InsuredIn a [IN1, IN2] sequence providing
details about
the insured as a payer

EMP

EMP

Employer

In a [IN1, IN2] sequence providing
details about
the employer as a payer

ETB

EXTF

External facility

In a [IN1, IN2] sequence providing
details about external facility as a
payer

DEP

COU

CountyIn a [IN1, IN2] sequence providing
details about
the county as a payer

995
Values that shall be used for the IN3-5.1 component are displayed in HL7 standard’s 0146 table:
Table User defined 0146: User amount typeIN3-5.1 IHE
FR values

Implicit meaning

Comments

AT

Absolute amountAmount, in absolute terms. The currency used is notified in theIN3-5.3 subfield (For instance « EUR » for a euro amount). The
amount is provided in the IN3-5.2 subfield

PB

Percentage of the baseof reimbursement

A usable value for both a compulsory and a complementary
coverage.
The IN3-5.2 subfield contains a percentage of the base ofreimbursement. (ex: 60 means « 60 % of the base ofreimbursement »)PT

Exemption from copayment percentage

Usable value for a complementary coverage: The IN3-5.2 subfieldcontains an exemption from co-payment percentage (ex: 100 means« 100% of the ticket modérateur »)PFReal costs percentage

Usable value for a complementary coverage: The IN3-5.2 subfieldcontains a real costs percentage (ex: 90 means « 90% of real costs»)

PC

Non specified
percentage

The IN3-5.2 subfield contains a percentage of which the reference
amount is not specified.

4.1.2.12 OBX segment
1000

The OBX segment is used to transmit medical observations related to the patient. The following
requirements apply when used in ITI-30 or ITI-31 transactions.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

58

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
SEQ

LEN

DT

Usage

Card.

HL7
TBL#

ELEMENT
NAME

OBX1

4

SI

R

[1..1]

OBX2

2

ID

R

[1..1]

OBX3

250

CE

R

[1..1]

Observation
identifier

OBX5

unlimitedvariesC[1..1]

Observation value

OBX6

250

CE

C

[0..1]

Unit

OBX11

1

ID

R

[1..1]

OBX14

26

TS

RE

[0..1]

Observation
date/time

OBX16

250

XCN

R

[1..1]

Data enterer

IHE FR

Set ID - OBX
00125

Observation type

00085

*

Observation status

User tablecompleted*1005
OBX-3: Observation Identifier, Required
The OBX-3 identifier shall be chosen from ASIP’s Interoperability Framework when a suitable
identifier is available. When a suitable identifier is not defined it shall be chosen from the
LOINC nomenclature. The following table shows a few values:
1010
Value

French display

Unit(UCUM)

Terminology

3142-7

Body weight [Mass] Patient ; Numeric ; Declared

kg or g

LOINC

8335-2

Body weight [Mass] Patient ; Numeric ; Estimated result

kg or g

LOINC

3141-9Body weight [Mass] Patient ; Numeric ; Measured result

kg or g

LOINC

3137-7

Patient’s height [length]; Numeric ; Measured result

cm

LOINC

8301-4

Patient’s height [length]; Numeric ; Estimated result

cm

LOINC

OBX-6: Unit, Conditional

1015

This field shall be filled if the observation type is “NM” (Numeric) or “SN” (Structured
Numeric) and if the observation is measured. The units’ list shall be based on UCUM (The
Unified Code for Units of Measure, http://www.unitsofmeasure.org/).
Example UCUM units
Value

English display

French display

Terminology

g

Gram

GrammeUnitsOfMeasureCaseSensitivekg

Kilogram

Kilogramme

UnitsOfMeasureCaseSensitive___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

59

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Value

English display

French display

Terminology

m

Meter

Mètre

UnitsOfMeasureCaseSensitivecm

Centimeter

Centimètre

UnitsOfMeasureCaseSensitive

OBX-11: Observation status
1020

This field shall contain the observation status. The table below lists values that are usable in thescope of French extensions.
Value

Description

Comments

R

Filled but unvalidated observation

This status shall be used as long as theconveyed observation has been unsafe andhas not been validated by the medical staff.

F

Filled and validated observation.

This status shall be used as long as theconveyed observation has been validated by
the medical staff.

D

Deletes the observation conveyed in the OBX
segment.

This status shall be used when theobservation conveyed by the Patient
Demographics Supplier and Patient
Encounter Source Actors is wrong and must
be deleted. This observation shall never be
displayed or used by the receiving systems.

OBX-11: Observation date/time
1025This field is required if available among the “Patient Demographics Supplier” and “Patient
Encounter Supplier” Actors, which initiate the observation transmission. Observation date &time must be as close as possible to the corresponding measured results. For instance, if thepatient’s weight is entered when admitting, the observation date/time will be the one asked thepatient, not the entered one.

1030

OBX-16: Observation manager

1035

This field is required. It contains the identity of the person that entered or changed theobservation status. For instance, if the patient’s weight is entered at the admission desk, it isconveyed with an “R” status and the observation manager is the enterer. If the patient is weighed
within the department, their weight will be conveyed with an “F” status and the observation
manager is the medical staff conducting the weighting.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

60

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
4.1.3 Requirements on PAM Profile
4.1.3.1 Minimal common data model

1040

The figure below shows an assumption of the minimal data model established by the PAM
Profile in its French extension. The HL7 v2.5 segments or parts of segments that carry this item
are highlighted in blue.

Figure 4.1.3.1-1: PAM French Extension Data Model

1045

1050

1st note: many systems have a 1-by-1 correspondence between visit and patient account. Other systems may need to bring
together several visits in a single patient account. That doesn’t affect the charging process that can bundle or not visits
on a single invoice, or by contrast divides a visit into several intermediary invoices. A system that merely manages anidentifier, common to the visit and the patient account, will provide this identifier both in the PV1-19 and in the PID18.
2nd note – reminder: a movement is a time and date stamped event that sets a change in the patient’s situation: a change in thefunctional unit’s responsibility, of bed, of medico-price discipline and so on. The sequence of movements that make up
a visit defines a sequence of take-over situations periods (see Section 5.1.4 below).

4.1.3.1.1 The Functional Unit (FU) or Ward1055

ITI-31 “Encounter Management” transaction’s French extension is based on using features fromthe functional unit (FU) that is responsible for the patient’s care into the healthcare facility. In
the United States however, responsibility for the patient is very often related to the attending
doctor, in France responsibility is related to the functional unit (ward).
___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

61

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

1060

1065

According to the Technical Agency for Hospital computerization (ATIH), which refers to theissue 83/8 bis of “Le Bulletin Officiel”, the functional unit is the smallest one that fitsmanagement constraints, that has a simultaneous homogeneous medical activity on the following
axes:•

Geographical,•

Responsibility (medical/care)•

And for a certain kind of activity (ex: inpatient hospitalization/hospitalization day-care).

Thus, the functional unit allows deducing the various natures of patient management as well as
the different kinds of hospitalization the patient may require in the healthcare facility.
A patient may be under the responsibility of several functional units (up to three), which are
medical ward, nursing ward and housing ward responsibilities: for instance the patient may belocated in a housing ward different from the medical ward responsible of his treatment.

1070

Fee conditions for the patient’s hospital stay or visit, which are generally tightly related to the
medical ward in charge of the patient, may be subject to a specific scale taking into accountparticular medical treatments or accommodation policies. These specific features lead us todistinguish between general fee conditions of the care unit medically in charge of the patientfrom fee conditions that are actually applicable to the patient’s stay within this unit.
4.1.3.1.2 The concept of patient account (informative)

1075

The patient account records each and every medical act, product or attention dispensed to thepatient in a specific visit in order to allow charging process.
A patient account can span more than one enterprise visit.
In the ITI-31 Transaction messages, the PID-18 field represents the account number.
4.1.3.1.3 The concept of visit/encounter

1080

The word of “venue” in French transposes, for the French healthcare facilities, the notions of“visit” and “encounter” managed by the HL7 standards.
In the ITI-31 Transaction messages, the PV1-19 field represents the “visit number”.

1085

1090

A visit is defined as an inpatient or outpatient encounter in the healthcare enterprise. The visit
number identifies the time period during which the patient is taken care of by the enterprise andphysically present in the enterprise (outpatient encounter, inpatient encounter, or its extensions
such as home care, placement in a hosting family…). However, short absences of the patient may
happen during this time period. These temporary absences, dealt with by trigger events such as“Leave of absence” (A21, A22, A51, A52…), do not terminate the visit.
The visit is related to a patient account assigned to any acts, products and services delivered tothe patient in the context of this visit.
For inpatients, a visit can span more than one movement.
___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

62

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
4.1.3.1.4 The concept of movement
This extension uses the IHE international definition of the “movement” as it appears in ITI TF2b:3.31.4.
1095

A movement is an event describing a change of the situation of the patient in the context of theencounter. This concept encompasses changes such as transfers of patient location, change ofpatient class, new attending doctor, new consulting doctor, new encounter starting, encounterclosing, etc. The concept of Movement is a superset of the HL7 concept of “Transfer”.
4.1.3.2 Actor Requirements for PAM

1100

Table 4.1.3.2-1: PAM Profile - Actors and Options
ActorsPatient
Demographics
Supplier

Patient
Demographics
Consumer
Patient Encounter
Supplier

Patient Encounter
Consumer

OptionOptionality

ReferenceIntl

French

Merge

O

R

ITI TF-2b:3.30.4.1

Link/Unlink

OO

ITI TF-2b:3.30.4.2

Acknowledgement SupportOO

ITI TF-2b: 3.30.4.4

Ambulatory Patient DataOOITI TF-2b: 3.30.4.5

Merge

O

R

ITI TF-2b:3.30.4.1

Link/Unlink

OO

ITI TF-2b:3.30.4.2

Acknowledgement SupportOO

ITI TF-2b: 3.30.4.4

Inpatient / Outpatient Encounter
Management

O

R

ITI TF-2b: 3.31.5.2

Pending Event ManagementOO

ITI TF-2b:3.31.5.3

Advanced Encounter
Management

O

R

ITI TF-2b:3.31.5.4

Temporary Patient Transfer
TrackingOO

ITI TF-2b:3.31.5.5

Historic Movement

O

R

ITI TF-2b:3.31.5.6
ITI TF-4: somethingin national extension
for ZBE segment

Acknowledgement SupportOO

ITI TF-2b: 3.31.5.7

Maintain DemographicsOO

ITI TF-1:14.3.9
ITI TF-2b:3.31.5.8

Ambulatory Patient DanaOOITI TF-2b: 3.31.5.8

Inpatient / Outpatient Encounter
Management

O

R

ITI TF-2b: 3.31.5.2

Pending Event ManagementOO

ITI TF-2b:3.31.5.3

Advanced Encounter
Management

O

R

ITI TF-2b:3.31.5.4

Temporary Patient Transfer
TrackingOO

ITI TF-2b:3.31.5.5___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

63

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Actors

OptionOptionality

ReferenceIntl

FrenchHistoric Movement

O

R

ITI TF-2b:3.31.5.6
ITI TF-4: somethingin national extension
for ZBE segment

Acknowledgement SupportOO

ITI TF-2b: 3.31.5.7

Maintain DemographicsOO

ITI TF-1:14.3.9
ITI TF-2b:3.31.5.8

In France, the 3 required options are:•“Inpatient / Outpatient Encounter Management”: this option extends the management
basis function subset adding the concepts of pre-admission, patient transfer, and changeof status (outpatient vs. inpatient)•“Advanced Encounter Management”: this option adds the management of patient’s leaveof absence, of the doctor medically in charge of the patient and changes in their account
file.

•

“Historic Movement”: this option introduces a specific ZBE segment that enables to
identify any kind of movement and thereafter to update it using the Z99 event. Such an
option allows both the current movement (the last one known regarding the admission)and an historic movement (a previous one) to be updated. However, it doesn’t permit theinsertion or the cancellation of an historic movement.

1105

1110

4.1.3.3 Transaction Specific Requirements
1115

4.1.3.3.1 Movement management rules applicable in France
4.1.3.3.1.1 The concept of movement1120

The international definition of “movement” appears in ITI TF-2b:3.31.4. A movement is an
event describing a change of the situation of the patient in the context of the encounter. This
concept encompasses changes such as transfers of patient location, change of patient class, newattending doctor, new consulting doctor, new encounter starting, encounter closing, etc. The
concept of Movement is a superset of the HL7 concept of “Transfer”.
In France, the following real world movements shall be trigger events for ITI-31 transactions. (tobe taken into account for every system that implements the “Patient Encounter Supplier” Actor):

1125

•

The pre-admission•

The admission to the hospital (the beginning of a visit),•

The change of assigned ward’s responsibility:•

Change of the functional unit housing responsibility,___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

64

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

1130

1135

•

Change of the functional unit medical responsibility,•

Change of the functional unit nursing responsibility,•

The temporary absence (that interrupts certain responsibilities),•

The return from an absence,•

The permanent discharge from the hospital (end of the visit that, besides, puts an end to
all responsibilities),•

A change of status: from outpatient or emergency to inpatient,•A change of status: from inpatient to emergency or outpatient.

The following events, for their part, may trigger a movement (i.e., it remains the choice of thesystem that implements the “Patient Encounter Supplier” Actor):•

The change of bed or a bed assignment to a patient (A02). Reminder: the Z99 event
carries out the updating. Using an A02 can notify the assignment of a bed to a patient,
especially when a delay is observed between the patient’s admission and the firstassignment of the bed. However, the Z99 message shall be used in case the end-user•

Wants to add or update this information. In other words, if the assignment of the bed iscarried out at admission time, use the Z99 message to add or update the information.

•

The change of the patient management healthcare administration conditions (healthcare
specialty cost, involuntary hospitalization, and hospitalization requested by a third
party…)•

The patient temporarily leaves the facility (>48h) to be transferred to another department(A21) in another facility to carry out a surgical act or a medical examination.

•

The return following a transfer to another department (A22).

1140

1145

1150

1155

Each movement is the beginning of a period of time during which the patient’s situation is stablein terms of responsibilities and of patient management. The very next movement marks the endof this period, and starts a new one.
The first movement of a visit is the admission; the last one is the discharge. The sequence of thedifferent movements that have arisen over the visit divides this visit into a sequence ofcontiguous stable periods to which acts performed on the patient will be reported.
4.1.3.3.1.2 Granularity of messages that describe a movement

1160

The Patient Encounter Supplier Actor generates messages with granularity that fits its
application’s transactional logic. When several events occur at the same time (e.g., simultaneouschange in the 3 FU responsibilities), they constitute a unique movement, starting point of a new
period of responsibilities allocation. The Patient Encounter Supplier Actor can notify of thismovement (identified in the ZBE segment) either with a unique message that changes the three
responsibilities or with several messages where each one of them states one responsibilitychange. In any case, the movement identifier remains unique.
___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

65

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
4.1.3.3.1.3 Trigger events associated with movement
1165

The following events that are optional in IHE Intl shall be supported, because historic movement
management is required. The update event shall be supported by using the Z99 defined in ITI
TF-2b: 3.31.7.30.
Category

1170

insertcancelupdatePre-admit patient (Patient Class = I)

A05

A38

Z99

Admit inpatient (Patient Class = I)

A01

A11

Z99

Pending admission (Patient Class = I)

A14

A27

Z99

Register outpatient (Patient Class = O or E)

A04

A11

Z99

Change patient class (outpatient or emergency) to inpatient(Patient Class : O to I or E to I)

A06

A07

Z99

Change patient class to outpatient(Patient Class : I to O or E to O)

A07

A06

Z99

Change of responsible doctor (Attending Doctor)

A54

A55

Z99

Transfer: Change of housing ward (location FU)

A02

A12

Z99

Pending transfer

A15

A26

Z99

Permanent discharge (end of inpatient encounter, outpatient encounter,
emergency encounter, etc.)

A03

A13

Z99

Pending discharge

A16

A25

Z99

Leave of absence (permission) and transfer to another department for a
medical act (<48H)

A21

A52

Z99

Return from leave of absence (permission) and return following thetransfer to another department for a medical act (<48H)

A22

A53

Z99

Z80 to Z89 events are specific to this French extension.
Category

insertcancelupdateChange of the medical FU (medical ward)

Z80

Z81

Z99

Change of nursing FU (nursing ward)

Z84

Z85

Z99

Change of medico-administrative conditions

Z88

Z89

Z99

When the Pending Event Management Option is supported, the historical movement events inthe following table shall be supported:
1175
Category

insertcancelupdatePending change of the medical FU

Z82

Z83

Z99

Pending change of nursing FU

Z86

Z87

Z99

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

66

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
4.1.3.3.1.4 Requirements

1180

•

For IHE France, the unit responsible for the housing of the inpatient (or his/her hosting if
he/she is an outpatient) is represented by the first component of the PV1-3 field.

•

The ZBE-7 field represents the unit medically in charge of the patient.

•

The ZBE-8 field represents the unit responsible for the patient’s nursing care (if such aunit is different from the one medically in charge of the patient).

The functional units are required for the following ITI-31 Transaction triggering events:
Trigger events

1185

1190

1195

Required FU

A01, A04, A11, A03, A13, A05, A38, A02,
A12, A14, A27, A15, A26, A16, A25, , A21,
A22, A06, A07

Housing ward (in PV1-3)

Z80, Z81, Z82, Z83

Medical ward (in ZBE-7)

Z84, Z85, Z86, Z87

Nursing ward (in ZBE-8)

Z99

Housing &/or Medical &/or Nursing,depending on ZBE-9 value

ITI-31 Transaction messages merely carry the functional unit’s code. Applications that
implement ITI-31 Transaction are assumed to be aware of the main features of the functional
unit, which are:•Its display name,•

The kind of activity (inpatient, partial, emergency, outpatient or recurring
hospitalization),•

The kind of functional unit (medical: [dedicated to the outpatient stays/inpatient stays,
combined] or not medical),•A simplified classification into FU categories (obstetric, short stay, follow-up care, longstay, psychiatrics…),•

A further-detailed FU classification into medical price disciplines,•

Dates of effect, as functional units will be opened and closed.

4.1.3.3.2 ITI-30 Extensions
The French National Extensions does not modify ITI-30 for identity
creation/update/cancellation/merge messages.
1200

In hospital information systems where several systems can create and assign an identifier for thepatient, IHE-FRANCE recommends using separate ranges of identifier values for the patients(PID-3) within the same identification domain (identified by the assigning authority).
___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

67

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
This recommendation allows avoiding using temporary identifiers. Indeed, the patient’s
identifiers must remain unchanged due to their public nature.
1205

1210

Use case: An EHR application directly admits the patient and creates the patient account number,which will be provided to the administrative application (Administrative Management ofPatients).
File number and sequences must be established and assigned by the healthcare facility to thevarious identity producers and consumers systems. The receiver, in that case the administrative
application, integrates these identifiers in its system without modification and conveys them tothe HIS applications that subscribed to the administrative application.
In any case, IIHE-FRANCE recommends that there should be a one and only identities andmovements source that feeds the rest of the hospital information system applications, according
to the P1.1 pre-established rules from the French governmental Digital Hospital Program.

1215

•

A40 “Merge Patient Identifier List”: the merge of two patients is achieved by the A40
event, but in the scope of the ITI-30 transaction, not in the scope of the ITI-31
transaction. This merge is merely about patient account, and doesn’t address the merge oftwo visits.

4.1.3.3.3 ITI-31 Extensions1220

4.1.3.3.3.1 Trigger Event Extensions
The French extension excludes the following events from the IT-31 transaction:•

A08 “Update patient information”: the updating of demographic information is only
carried out by A31 event of the ITI-30 transaction. The updating of information related tothe patient account, the visit or the movement shall exclusively be implemented thanks to
the Z99 event of the ITI-31 transaction.

•

A40 “Merge Patient Identifier List”: the merge of two patients is achieved by the A40
event, but in the scope of the ITI-30 transaction, not in the scope of the ITI-31
transaction. This merge is merely about patient account, and doesn’t address the merge oftwo visits.

1225

1230

1235

The French extension adds Z80 and Z89 specific events (which use ADT_A01 structure) in orderto manage functional unit’s responsibilities (ward’s responsibilities) changes related to a patient.
The ITI-31 transaction is extended in the French National Extensions. A new class of event,“rectified” is defined and two new real world events “Change medical ward” and “Change
nursing ward” are added. The rectified column is added because this information is mandatory
according to French regulation.
Here follows the exhaustive list of French required events to be fulfilled by the two actors of the
ITI-31 transaction:
This is summarized in Table 4.1.3.3.3.1-1.
___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

68

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
1240

Table 4.1.3.3.3.1-1: List of French required events in France
Real world Event

notified

cancelled

rectified

A11

Z99

A03

A13

Z99

Pre-admit patient : pré-admission

A05

A38

Z99

Change patient class to inpatient : externe devient hospitalisé

A06

A07

Z99

Change patient class to outpatient : hospitalisé devient externe

A07

A06

Z99

Admit inpatient

A01

Register outpatient

A04

Discharge patient : sortie

Transfer patient : mutation

A02

A12

Z99

Change attending doctor : changement médecin responsable

A54

A55

Z99

Leave of absence : absence provisoire (permission) et mouvement de transfert
vers plateau technique pour acte (<48H)

A21

A52

Z99

Return from leave of absence : retour d’absence provisoire (permission) etmouvement de retour suite à transfert vers plateau technique pour acte (<48H)

A22

A53

Z99

Move account information (réattribution de dossier administratif

A44

Fr : Change medical ward

Z80

Z81

Z99

Fr : Change nursing ward

Z84

Z85

Z99

1st note: Z82 and Z83 events, which respectively notify and cancel a pending medical functional unit change are required only
for an actor that supports the “Pending Event Management” Option. Ditto for the Z86 and Z87 events that respectively
notify and cancel a pending functional care unit change. This “Pending Event Management” Option remains optional inFrance, that’s why those 4 events are not displayed in the table above.

1245

2nd note: Z88 and Z89 events, which respectively notify and cancel a change in the conditions for the medico-administrative
take-over, remain optional. (cf. Section 5.1.4).

4.1.3.3.3.2 ITI-31 French specific segments
1250

1255

In addition to the ZBE segment (Movement) defined by the international Patient Administration
Management Profile, the French extension adds five other segments:•

ZFA: Patient’s PHR status•

ZFP: Professional occupation/Work situation•

ZFV: Additional information about the visit•

ZFM: DRGP (Diagnosis Related Group Program) movement

The location of the local segments in the message structure is in bold text in Table 4.1.3.3.3.2-1:
Table 4.1.3.3.3.2-1: French Specific Segments
Segment

Meaning

Usage

Card.

MSH

Message Header

R[1..1]

EVN

Event TypeR

[1..1]

PID

Patient IdentificationR[1..1]

PD1

Additional Demographics

O[0..1]IHE France remarks___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

69

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Usage

Card.

ROL

Segment
Role

MeaningO[0..*]

NK1

Next of Kin / Associated Parties

O[0..*]

PV1

Patient VisitR[1..1]

PV2

Patient Visit – Additional InfoO

[0..1]ZBE

Movement segment

C[1..1]

Highlights FU’s movement & responsibilities

ZFA

PHR status

RE[0..1]

Patient’s PHR status

ZFP

Professional occupation

RE[0..1]

Occupation & socio-professional category

ZFV

Additional information about
the visitRE[0..1]

Origine Institution, period of admission,transport of discharge

ZFM

DRPG 4 Movement

RE[0..1]DRPG modes: admission, discharge, origin,destination

ROL

Role

O

[0..*]

Used to define other physicians that interact
with the patient, especially the substitute andthe referred to provider doctors

DB1

Disability Information

O[0..*]

OBX

Observation/Result

O[0..*]

AL1

Allergy Information

O[0..*]

DG1

Diagnosis Information

O[0..*]DRG

Diagnosis Related GroupO[0..1]------ PROCEDURE begin

O[0..*]

PR1

ProceduresR[1..1]

O[0..*]

ROL

Role

---

--- PROCEDURE end

GT1

Guarantor

O[0..*]------ INSURANCE begin

O[0..*]

IN1

InsuranceR[1..1]

IN2

Insurance Additional Info.

O[0..1]

IN3

Insurance Additional Info - Cert.

O[0..1]

O[0..*]

ROL

Role

---

--- INSURANCE end

ACC

Accident InformationO[0..1]

UB1

Universal Bill InformationO[0..1]

UB2

Universal Bill 92 InformationO[0..1]PDA

Patient Death and AutopsyO[0..1]IHE France remarks
Used to define the officially declared referring
physician

DRGs: Diagnosis-related group (DRG) is a system to classify hospital cases into one of originally 467 groups,[1]with the 467th group being "Ungroupable". This system of classification was developed as a collaborative project byRobert B Fetter, PhD, of the Yale School of Management, and John D. Thompson, MPH, of the Yale School of
Public Health.[2] The system is also referred to as "the DRGs", and its intent was to identify the "products" that ahospital provides.

4___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

70

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
4.1.3.3.3.3 Historic Movement Management (from intl)
This option adds the capability to cancel or update safely any Movement.
1260

The Movement updated can be the current Movement (currently active or pending) or a
Movement in the past (i.e., historic Movement).
The Movement canceled can only be the current Movement (currently active or pending).

1265

This capability is supported by the addition of segment ZBE below PV1/PV2. With this option,
this ZBE segment is required at this position in the messages associated with the following
trigger events: A01, A02, A03, A04, A05, A06, A07, A11, A12, A13, A14, A15, A16, A21,
A22, A25, A26, A27, A38, A52, A53, A54, A55, Z99. In the following sections the ZBE
segment is only shown in the message associated with trigger Z99 which is dedicated to theHistoric Movement Management Option. In the other messages, this segment will appear
whenever this option is active.
This segment ZBE brings the following features:

1270

•

It enables unique identification of the Movement (including admission and discharge).

•

It carries an action code that describes the action to be performed on this Movement: The
three possible actions are:

1275

1280

1285

•

INSERT: The receiver must interpret the content of this message as a new
Movement.

•

CANCEL: This action code is always associated with a “cancel” trigger event. The
receiver shall delete the corresponding Movement (matched with its unique
identifier). Only the current Movement can be cancelled.

•

UPDATE: This action code is associated with the dedicated trigger event Z99
described in ITI TF-2b: 3.31.7.30. The receiver shall update the corresponding
Movement (matched with its unique identifier), which can be the current Movement
or a historic Movement.

•

In the case of UPDATE or CANCEL, the ZBE segment carries the code of the original
trigger event that was associated with the action INSERT of the related Movement.

•

It carries an indicator “Historic Movement” informing whether the action to perform isabout the current Movement or a Historic one.

•

It provides the starting date/time of the “sub-encounter” that this Movement initiates.

•

It carries the ward to which this patient is assigned during this sub-encounter.

This option may apply to any combination of the previous subsets, except Temporary Patient
Transfers Tracking (Temporary Patient Transfers do not need to be uniquely identified).
1290

Implementation note: The Patient Encounter Consumer must support transaction log update tomaintain integrity of the Movement records.
___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

71

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
4.1.3.3.3.4 Details regarding the account/visit/movement identifiers
4.1.3.3.3.4.1 Re-use of the account/visit/movement identifiers
1295

Identifiers (account, visit, movement) are expected to be unique. If an IHE Actor creates anidentifier, is shall be unique.
Upon visit cancellation (A01/A11), the visit and account number (respectively PV1-19 and PID18) shall not be re-used.
4.1.3.3.3.4.2 Account/Visit/Movement id management in a complex environment

1300

An account identifier shall be transmitted in the PID-18 field (CX-type field). The fourthcomponent shall specify the identification domain.
The visit identifier shall be transmitted in the PV1-19 field (CX-type field). The fourthcomponent shall specify the identification domain.

1305

1310

The movement identifier shall be transmitted in the ZBE-1 field with an EI-type field (repeatable
field). The identification domain shall be transmitted in components 2, or components 3 and 4, orcomponents 2, 3, and 4.
IHE-FRANCE recommends that there should be one and only one determined identification
domain for all the identifiers linked to accounts to feed the whole set of HIS applications,according to the P1.1 prerequisite from the governmental French Digital Hospital Programme.
The identification domain allows defining separate ranges of identifiers that may be used by thedifferent HIS applications that are likely to create the identifiers linked to the account. The whole
set of identifiers created under the supervision of the identification domain constitute the uniquevisit and movement identifiers referential stated in the Digital Hospital Programme.
In a complex environment in which several systems cooperate, there are several ways to manage
visit and movement identifiers:

1315

1320

1325

•

Either using separate identifiers ranges, assigned by the identification domain common to
the whole facility. Each system likely to create those identifiers uses an identification
range.

•Or using the combination identification domain/identifier. In this case, each system likely
to create those identifiers owns its identification domain.

The composition of the identifiers and the identification domains shall be determined andassigned by the facility to all the producer and consumer systems of visits and movements.
Transmitting the movement and visit identifiers list is not necessary. The visit or movement
originator software can assign any identifier in its identification domain. Then the combination
identification domain/identifier becomes the visit (PV1-19) or movement (ZBE-1) identificationreference. This reference identifier is then sent to every information exchange; it’s up to thedifferent systems to manage identifiers correspondence tables.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

72

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

5 National Extensions for IHE Germany
1330

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.
This national extension was authored under the sponsorship and supervision of IHE Germany
and the IT Infrastructure Technical Committee. Comments should be directed to:1335

http://www.ihe.net/ITI_Public_Comments and ihe-d-pam-abgleich@googlegroups.com

5.1

Referenced Standards

German HL7 Edition 2.5, German HL7 Chapter (HL7-Benutzergruppe in Deutschland e. V.),
http://www.hl7.de/1340

German National Message Profiles 2003 (Rel.1) to 2004 (Rel.2.1),
http://www.hl7.de/download/documents/Profile_2.1.zip

5.2

HL7 v2 Conventions for Message Profiles

Implementations of ITI-30 and ITI-31 Profiles that also claim support of the German National
Extension shall conform to the requirements in this section and the information provided by thelinks.
1345

5.2.1 HL7: Support for Character Sets
All actors with HL7 transactions shall support the value “8859/1” and “8859/15” for the field
H/18 in the MSH segment.
5.2.2 Naming Conventions for Profiles

1350

The term “profile” is used as defined by IHE and references “integration profiles” as specified by
the different IHE Technical Frameworks.
In case where IHE integration profiles leverage HL7 v2 messages, they consist of one or more
“HL7 message profiles” that are a specialization of the officially published HL7 v2 standard.
When necessary extensions are defined. This is for example the case with the ZBE segment.

1355

The “HL7 Message Profile Component” concept is used to specify fragments of messages, which
can be used with different base messages. Such fragments are tables, data types, segments andsegment groups. This way, a tedious repetition of specification details is prevented and helps tosimplify and reduce development efforts.

5.3
1360

ITI-30 and ITI-31

Implementations of PAM and other profiles that use ITI-30 and ITI-31 that also claim support of
the German National Extension shall conform to the requirements in this section.
___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

73

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________The names of the HL7 fields shall be as defined in the German HL7 Edition 2.5.
IHE Germany has undertaken a three year project to align the National Message Profiles
published in 2003 (Rel.1) to 2004 (Rel.2.1) with the Patient Administration Management Profile.
The overall project details can be found here:1365

http://wiki.hl7.de/index.php/PAM-Profil_Abgleich_(Projekt)
The additional constraints can be roughly divided into the following categories:

1370

•

data type enhancements (XPN, XAD)•

profile support with MSH-21•

software release verification•

provision of specific table values•

diagnosis and procedure related information

Some additional requirements have been crafted in the form of HL7 message profile components
which can be combined with the HL7 base message profiles.
1375•

insurance information (payor data with smartcards)•

DRG-related data•contact persons

5.3.1 Extension Requirements: Notation and Location
Most of the requirements are not documented directly in this document, but are instead included
by reference in these tables below:
1380

1385

•

Table 5.3.2-1 Introductory Documents for German Message Profiles•

Table 5.3.2-2 Detailed German Message Profiles for PAM•

Table 5.3.3-1 Additional German Profile Components PAM•

Table 5.3.4-1 Additional German Segment Definitions•

Table 5.3.5-1 Additional German Data Type Definitions•

Table 5.3.6-1 Additional German Table Definitions•

Table 5.3.7-1 Additional German Profiles

Implementers are responsible for monitoring any changes to the linked tables hosted on the
IHE/HL7 Germany wiki.
1390

In the linked tables, the light blue highlights mark rows containing differences between therequirements in ITI TF-2b for ITI-30 and ITI-31 and German requirements.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

74

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________The Verwendung (optionality) column shows the German requirements, and the requirementsfrom ITI TF-2b have been preserved in parentheses, the Kard. (cardinality) column shows theGerman requirements, but the requirements form ITI TF-2b are not preserved.
1395

All changes are SHALL-level implementation constraints for actors that want to comply with theGerman National Extensions.
For example:

5.3.1.1 German Message Profile Architecture
1400

Figure 5.3.1.1.-1 demonstrates the overall structure and relationship of the German Message
Profiles as a specialization of ITI PAM:
Standard

IHE PAM

German Profiles

Figure 5.3.1.1-1: German Message Profiles as a National IHE Extension

1405

The detailed architecture is depicted in Figure 5.3.1.1-2:___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

75

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Message Profile of Vendor

infor
mati
ve

Implementable Profile(Message, deviating Segment-Constraints, no Optionality)
Message Profile
Aufnahme-Profil
Admission
Profile forDRG
DRG(Subprofil)(Subprofile)

Verlegungs-Profil
DRG
Transfer
Profile for DRG(Subprofil)(Subprofile)…

Admission Profile Standard

norm
ative
(HL7D)

Transfer Profile Standard

addi
ng
const
raint
s

Common Elements

Basis

Common Segments
Common Data Types

IHE ITI PAM
PAM-Profile

Implementation Guidelines
Communication Framework
HL7 v2.5 German Edition

Infor
mati
ve
(HL7D)

Normative
HL7 v2.5(HL7
Figure 5.3.1.1-2: German Message Profile Architecture

5.3.2 German HL7 Message Profiles for PAM
1410

The German HL7 Message Profiles were originally created in German but all relevant details
have been translated into English and interleaved in the pages linked in this section.
Table 5.3.2-1 provides an overview of the details.
Table 5.3.2-1: Introductory Documents for German HL7 Message Profiles
Description

Link

Document Overview

http://wiki.hl7.de/index.php/HL7v2-Profile_Dokumente

Communication Framework

http://wiki.hl7.de/index.php/HL7v2-Profile_Rahmen

Common Elements

http://wiki.hl7.de/index.php/HL7v2-Profile_gemeinsame_Elemente

Correction of Identifiers

http://wiki.hl7.de/index.php/Korrekturen_von_Identifikatoren___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

76

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

1415

To support German National Extensions, the PAM Patient Demographics Supplier, Patient
Demographics Consumer, Patient Encounter Supplier, and Patient Encounter Consumer Actors
shall support the messages listed in Table 5.3.2-2 and shall support the fields and associatedbehaviors described in the links in the Message Profile column. Note that some Events in thetable are associated with options in the PAM Profile.
Table 5.3.2-2: Detailed German HL7 Message Profiles for PAM
Event

German HL7 Message Profile

A01

Admission: http://wiki.hl7.de/index.php/HL7v2-Profile_Aufnahme

A02

Transfer: http://wiki.hl7.de/index.php/HL7v2-Profile_Verlegung

A03

Discharge: http://wiki.hl7.de/index.php/HL7v2-Profile_Entlassung

A04

Patient registration: http://wiki.hl7.de/index.php/HL7v2-Profile_Besuchsmeldung

A05

Preadmit patient: http://wiki.hl7.de/index.php/HL7v2-Profile_Voraufnahme

A06,
A07

Switch in-/outpatient: http://wiki.hl7.de/index.php/HL7v2-Profile_Fallartwechsel

A08

Update: http://wiki.hl7.de/index.php/HL7v2-Profile_Aenderung_Patient

A09,
A10

Patient tracking: http://wiki.hl7.de/index.php/HL7v2-Profile_Abwesenheiten_Einrichtung

A11

Cancel Admission: http://wiki.hl7.de/index.php/HL7v2-Profile_Aufnahme_Storno

A12

Cancel Transfer: http://wiki.hl7.de/index.php/HL7v2-Profile_Verlegung_Storno

A13

Cancel Discharge: http://wiki.hl7.de/index.php/HL7v2-Profile_Entlassung_Storno

A21,
A22

Leave of absence: http://wiki.hl7.de/index.php/HL7v2-Profile_Abwesenheiten_Urlaub

A31

Update Person: http://wiki.hl7.de/index.php/HL7v2-Profile_Aenderung_Person

A24,
A37

Link: http://wiki.hl7.de/index.php/HL7v2-Profile_Verknüpfung

A40,
A47

Update Patient ID: http://wiki.hl7.de/index.php/HL7v2-Profile_Aenderung_Patienten-ID

Z99

Historic Movement: http://wiki.hl7.de/index.php/HL7v2-Profile_historische_Bewegung

1420
5.3.3 Additional German HL7 Message Profile Components
Implementations may choose to support any of the message components listed in Table 5.3.3-1
but if supported shall support the fields and associated behaviors described in the links in the
HL7 Message Profile Component column.
1425

Table 5.3.3-1: Additional German HL7 Message Profile Components PAM
Description

German HL7 Message Profile Component

Insurance
smartcard data

http://wiki.hl7.de/index.php?title=HL7v2-Profilkomponente_Kartendaten

Contact Persons

http://wiki.hl7.de/index.php?title=HL7v2-Profilkomponente_Kontaktpersonen

Insurance

http://wiki.hl7.de/index.php?title=HL7v2-Profilkomponente_Kostenträger___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

77

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Description

German HL7 Message Profile Component

Transmission of
DRG related
data

http://wiki.hl7.de/index.php?title=HL7v2-Profilkomponente_DRG-Rohdaten

Patient Photo(informative)

http://wiki.hl7.de/index.php?title=HL7v2-Profilkomponente_Patient_Photo

5.3.4 Additional German Segment Definitions
Implementations shall support all the segments listed in Table 5.3.4-1 and shall support the fields
and associated behaviors described in the links in the HL7 Message Profile Component column.
1430

Table 5.3.4-1: Additional German Segment Definitions
Segment

Description

HL7 Message Profile Component

DG1

Diagnosis

http://wiki.hl7.de/index.php/Segment_DG1

ERR

Error

http://wiki.hl7.de/index.php/Segment_ERR

EVN

Event

http://wiki.hl7.de/index.php/Segment_EVN

FT1

Financial Transaction

http://wiki.hl7.de/index.php/Segment_FT1

MRG

Merge

http://wiki.hl7.de/index.php/Segment_MRG

MSA

Message Acknowledgement

http://wiki.hl7.de/index.php/Segment_MSA

MSH

Message Header

http://wiki.hl7.de/index.php/Segment_MSH

IN1

Insurance

http://wiki.hl7.de/index.php/Segment_IN1

IN2

Insurance (Part 2)

http://wiki.hl7.de/index.php/Segment_IN2

IN3

Insurance (Part 3)

http://wiki.hl7.de/index.php/Segment_IN3

NK1

Next of Kin

http://wiki.hl7.de/index.php/Segment_NK1

OBR

Observation Request

http://wiki.hl7.de/index.php/Segment_OBR

OBX

Observations

http://wiki.hl7.de/index.php/Segment_OBX
http://wiki.hl7.de/index.php/Segment_OBX_(Codes)

PID

Patient Identification

http://wiki.hl7.de/index.php/Segment_PID

PR1

Procedures

http://wiki.hl7.de/index.php/Segment_PR1

PV1

Patient Visit

http://wiki.hl7.de/index.php/Segment_PV1

PV2

Patient Visit(Addt. Inform.)

http://wiki.hl7.de/index.php/Segment_PV2

ROL

Role

http://wiki.hl7.de/index.php/Segment_ROL

SFTSoftwarehttp://wiki.hl7.de/index.php/Segment_SFT

TXA

Transcription Document Header

http://wiki.hl7.de/index.php/Segment_TXA

ZBE

Movement

http://wiki.hl7.de/index.php/Segment_ZBE

ZGK

Card Data

http://wiki.hl7.de/index.php/Segment_ZGK___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

78

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
5.3.5 Additional German Data Type Definitions
Implementations which send any of the data types listed in Table 5.3.5-1 shall support the fields
and associated behaviors described in the links in the HL7 Message Profile Component column.
1435

Table 5.3.5-1: Additional German Data Type Definitions
Data Type

Description

HL7 Message Profile Component

CE

Coded Elements

http://wiki.hl7.de/index.php/V25dt:CE

CNE

Coded No Exceptions

http://wiki.hl7.de/index.php/V25dt:CNE

CWE

Coded With Exceptions

http://wiki.hl7.de/index.php/V25dt:CWE

CX

Extended Composite ID Numbers

http://wiki.hl7.de/index.php/V25dt:CX

DT

Date/Timehttp://wiki.hl7.de/index.php/V25dt:DTED

Encapsulated Data

http://wiki.hl7.de/index.php/V25dt:ED

EI

Entity Identifier

http://wiki.hl7.de/index.php/V25dt:EI

FN

Family Name (as part of XPN)

http://wiki.hl7.de/index.php/V25dt:XPNHD

Hierarchic Designator

http://wiki.hl7.de/index.php/V25dt:HD

PPN

Performing Person Time Stamp

http://wiki.hl7.de/index.php/V25dt:PPN

SAD

Street or Address (as part of XAD)

http://wiki.hl7.de/index.php/V25dt:XAD

SI

Sequence ID

http://wiki.hl7.de/index.php/V25dt:SI

ST

Stringhttp://wiki.hl7.de/index.php/V25dt:STTS

Timestamp

http://wiki.hl7.de/index.php/V25dt:TS

XAD

Extended Address

http://wiki.hl7.de/index.php/V25dt:XAD

XCN

Extended Composite ID Number and Namefor Persons

http://wiki.hl7.de/index.php/V25dt:XCN

XON

Extended Composite Name and
Identification Number for Organization

http://wiki.hl7.de/index.php/V25dt:XON

XPN

Person Name

http://wiki.hl7.de/index.php/V25dt:XPN

XTN

Contact

http://wiki.hl7.de/index.php/V25dt:XTN

Actors may choose to support any of the messages listed in Table 5.3.2-2 but if supported shallsupport the fields and associated behaviors described in the links in the HL7 Message Profile
Component column.
1440

5.3.6 Additional German Table Value Definitions
Table 5.3.6-1 provides an overview about nationally defined tables. Associated table values will
be found at the end of the provided link.
Table 5.3.6-1: Additional German Table Definitions
Table

Description

German Descr.

HL7 Message Profile Component

4902

Card Type

Kartentyp

http://wiki.hl7.de/index.php/Tabelle_4902 (Kartentyp)4903

WOP Indicator

WOP-Kennzeichen

http://wiki.hl7.de/index.php/Tabelle_4903 (WOPKennzeichen)___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

79

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________
Table

Description

German Descr.

HL7 Message Profile Component

4904

Sample Identification

Stichprobenzuordnung

http://wiki.hl7.de/index.php/Tabelle_4904(Stichprobenzuordnung)

4905

Location classification

Rechtskreis

http://wiki.hl7.de/index.php/Tabelle_4905(Rechtskreis)

4906

Inpatient Services

Stationäre
Leistungen

http://wiki.hl7.de/index.php/Tabelle_4906(stationäre_Leistungen)4907

Indication for specificperson groups

Kennzeichnung
besondere Personengruppen

http://wiki.hl7.de/index.php/Tabelle_4907(Kennzeichnung besondere Personengruppen)

4908

Disease management
program indicator(eGK)

DMP-Kennzeichen(eGK)

http://wiki.hl7.de/index.php/Tabelle_4908 (DMPKennzeichnung_eGK)

4909

Disease management
program indicator(KVK)

DMP-Kennzeichen(KVK)

http://wiki.hl7.de/index.php/Tabelle_4909 (DMPKennzeichnung_KVK)

1445___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

80

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

Appendices
Intentionally left blank.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

81

Copyright © 2017: IHE International, Inc.

IHE IT Infrastructure Technical Framework, Vol. 4 (ITI TF-4): National Extensions______________________________________________________________________________

1450

Glossary
The IHE Glossary can be found as an appendix to the IHE Technical Frameworks General
Introduction at http://ihe.net/TF_Intro_Appendices.

___________________________________________________________________________
Rev. 14.0 – Final Text 2017-07-21
Template Rev. 1.0

82

Copyright © 2017: IHE International, Inc.