EN 17269:2019

SLOVENSKI STANDARD
01-januar-2020
Zdravstvena informatika - Mednarodni povzetek podatkov o pacientu
Health informatics - The International Patient Summary
Medizinische Informatik - Die Patienten-Kurzakte für ungeplante, grenzüberschreitende
medizinische Versorgung
Informatique de santé - Résumé international du dossier médical du patient
Ta slovenski standard je istoveten z: EN 17269:2019
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 17269
EUROPEAN STANDARD
NORME EUROPÉENNE
November 2019
EUROPÄISCHE NORM
ICS 35.240.80
English Version
Health informatics - The International Patient Summary
Informatique de santé - Résumé international du Medizinische Informatik - Die Patienten-Kurzakte für
dossier médical du patient ungeplante, grenzüberschreitende medizinische
Versorgung
This European Standard was approved by CEN on 7 October 2019.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 17269:2019 E
worldwide for CEN national Members.

Contents Page
European foreword . 5
Introduction . 6
1 Scope . 8
2 Normative references . 8
3 Terms and definitions . 8
4 Abbreviations . 11
5 Conformance . 12
5.1 Introduction . 12
5.2 IPS Conformance Detail . 12
6 Definition and Descriptors for the IPS Data Set . 15
6.1 International patient summary data set . 15
6.2 IPS Terms and Descriptors . 15
6.3 Patterns within the IPS Data Set . 17
6.3.1 General . 17
6.3.2 Label Concept . 18
6.3.3 List . 18
6.3.4 Reference . 19
6.3.5 Person Name . 19
6.3.6 Coded Element. 19
6.3.7 Date Time . 19
6.3.8 Identifier . 20
6.3.9 Address . 20
6.3.10 Telecom . 20
6.3.11 Organization Name . 20
6.3.12 Text . 21
6.3.13 Any . 21
6.3.14 Range . 21
6.3.15 Quantity . 21
6.3.16 Period . 22
6.3.17 General Time Specification . 22
6.3.18 Healthcare Provider . 22
6.3.19 String . 23
6.3.20 Ratio . 23
6.4 Model Extensibility . 23
7 Definition of the IPS Document or IPS . 24
7.1 Overview Description: THE IPS DOCUMENT . 24
7.2 Detailed Description: THE IPS DOCUMENT . 25
8 Definition for IPS Attribute Collection: PATIENT ATTRIBUTES . 28
8.1 Overview Description: PATIENT ATTRIBUTES. 28
8.2 Detailed Description: PATIENT ATTRIBUTES . 28
9 Definition for IPS Attribute Collection: PATIENT’S ADDRESS BOOK . 30
9.1 Overview Description for PATIENT’S ADDRESS BOOK . 30
9.2 Detailed Description for PATIENT’S ADDRESS BOOK . 31
10 Definition for IPS Section: ADVANCE DIRECTIVES . 32
10.1 Overview Description for ADVANCE DIRECTIVES . 32
10.2 Detailed Description for ADVANCE DIRECTIVES . 32
11 Definition for IPS Section: ALLERGIES and INTOLERANCES . 34
11.1 Overview Description for ALLERGIES and INTOLERANCES . 34
11.2 Detailed Description for ALLERGIES and INTOLERANCES . 35
12 Definition for IPS Section: FUNCTIONAL STATUS. 38
12.1 Overview Description for FUNCTIONAL STATUS . 38
12.2 Detailed Description for FUNCTIONAL STATUS . 39
13 Definition for IPS Section: HISTORY OF PAST PROBLEMS . 40
13.1 Overview Description for HISTORY OF PAST PROBLEMS . 40
13.2 Detailed Description for HISTORY OF PAST PROBLEMS . 41
14 Definition for IPS Section: HISTORY OF PREGNANCY . 42
14.1 Overview Description for HISTORY OF PREGNANCY . 42
14.2 Detailed Description for HISTORY OF PREGNANCY . 43
15 Definition for IPS Section: HISTORY OF PROCEDURES . 45
15.1 Overview Description for HISTORY OF PROCEDURES . 45
15.2 Detailed Description for HISTORY OF PROCEDURES . 46
16 Definition for IPS Section: IMMUNIZATIONS. 47
16.1 Overview Description for IMMUNIZATIONS . 47
16.2 Detailed Description for IMMUNIZATIONS . 47
17 Definition for IPS Section: MEDICAL DEVICES . 49
17.1 Overview Description for MEDICAL DEVICES . 49
17.2 Detailed Description for MEDICAL DEVICES . 49
18 Definition for IPS Section: MEDICATION SUMMARY . 50
18.1 Overview Description for MEDICATION SUMMARY . 50
18.2 The IPS Medication Summary and IDMP . 51
18.3 Detailed Description for MEDICATION SUMMARY . 52
19 Definition for IPS Section: PLAN OF CARE . 55
19.1 Overview Description for PLAN OF CARE . 55
19.2 Detailed Description for PLAN OF CARE . 55
20 Definition for IPS Section: PROBLEMS . 57
20.1 Overview Description for PROBLEMS . 57
20.2 Detailed Description for PROBLEMS. 57
21 Definition for IPS Section: Results . 59
21.1 Overview Description for RESULTS . 59
21.2 Detailed Description for RESULTS . 59
22 Definition for IPS Section: SOCIAL HISTORY . 61
22.1 Overview Description for SOCIAL HISTORY . 61
22.2 Detailed Description for SOCIAL HISTORY . 61
23 Definition for IPS Section: Vital Signs . 63
23.1 Overview Description for VITAL SIGNS . 63
23.2 Detailed Description for VITAL SIGNS . 63
24 Definition for IPS Attribute Collection: Cross Border . 65
24.1 Overview Description for CROSS BORDER. 65
24.2 Detailed Description for CROSS BORDER . 65
25 Definition for IPS Attribute Collection: Provenance Metadata . 66
25.1 Overview Description for PROVENANCE . 66
25.2 Detailed Description for PROVENANCE . 67
Annex A (informative) The first IPS Scenario focussed on ‘unscheduled, cross-border care’ . 69
Annex B (informative) Explicit Trace between eHN Guideline Version 2. 77
Annex C (informative) The eHN Guideline, the JIC PS Standards Set, and IPS . 81
Bibliography . 82

European foreword
This document (EN 17269:2019) has been prepared by Technical Committee CEN/TC 251 “Health
informatics”, the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by May 2020, and conflicting national standards shall be
withdrawn at the latest by May 2020.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
The goal of this standard is to deliver a single, common International Patient Summary (IPS), comprising
core content.
The scope of this standard is to achieve that goal by defining a minimal yet non-exhaustive data set and
its associated business rules. This document is intended to be implementation independent yet still
supportive of any implementation by providing formal definition and clear description of a small data set.
The primary input to the data set is the second revision of the European eHealth Network’s data set [1],
which, in turn, builds upon significant clinical input from the European Patients-Smart Open Services
(epSOS) pilot project [2].
This document defines the International Patient Summary (IPS), with the initial focus upon unplanned
care across national borders. Starting from this focus, the specification is intended to be used and be
useful in local applications and also to be supportive of planned care. It emphasizes the data required
and the associated business rules to support use and the necessary conformance of the use case for an
international patient summary.
The data set described is intended for global use beginning with a shared vision from a collaboration
between CEN /TC 251 and HL7.  CEN has produced a separate Technical Specification (CEN/TS 17288)
that provides a European-specific guideline for IPS implementation. HL7 have produced CDA and HL7
FHIR templates for realizing implementations of the IPS.
The ‘International’ element of the IPS emphasizes the need to provide generic solutions for global
application moving beyond a particular region or country; consequently, wherever possible, reference is
made to international standards, rather than local ones. However, different international contexts will
offer a variety of requirements that need to be considered to ensure that patient safety is not
compromised. The IPS is underpinned by the ISO standard “System of concepts to support continuity of
care” [3] and uses those concepts in the initial IPS scenario, which is fully described in Annex A.
This standard focuses upon the overall structure of the patient summary as well as the individual data
elements that comprise it. The layout of this document uses a hierarchy of levels (H0 to H7) to facilitate
more detailed description with the purpose of supporting consistent implementation of the data set. The
level ‘H0’ describes the IPS Document as a whole, whilst levels H1-H7 describe the IPS Data Blocks with
attributes. Descriptors are added to each data element to better define the characteristics. The ‘H0’ level
document structure and constraints will be described first, the components start with H1 (e.g. IPS
Sections, IPS Attribute Collections).

CEN/TC 251 and HL7 have a shared vision for the patient summary, “to further the care for citizens across the
globe by providing a single, common International patient summary (IPS) that is usable by all clinicians for the
cross-border, unscheduled care of a person”.
HL7, Health Level Seven, CDA and FHIR are registered trademarks of Health Level Seven International. Reg. U.S.
Pat & TM Off.
Table 1 — Description of IPS Data Set concepts and their hierarchical relationships
Descriptive H0 H1 H2 – H7
hierarchy
IPS Data IPS All possible IPS and the Non-IPS Further detail is provided within
Transfer Object Document components are identified the IPS Data Blocks’ clauses
IPS Data Blocks - Individual IPS Sections, Hierarchical description of data
elements
IPS Attribute collections, and
IPS Metadata
The ordering of the IPS Data Blocks in this standard is alphabetic within three broad categories of Non-
Clinical Data, Clinical Data and Metadata. This follows the eHDSI patient summary deployment project
[4] and here is used purely to help presentation. However, in practice it is recognised that individual
attributes might appear in different categories depending on dynamic use rather than static classification.
As the amount of information for each data element is variable, and can be extensive, this standard
presents the information using a table with descriptors for each IPS Data Block; the table provides an
overview of the hierarchical structure and its requirement with explicit links to more details using a
consistent set of descriptors. Those attributes in the table that do not have a link to further detail are
either self-explanatory or explained by the hierarchical context. Note, the order of sibling attributes is
arbitrary and has no implication for any implementation. The name of the element is given in full, if the
hierarchical arrangement in the description with the term is still open to ambiguous interpretation.  This
has been done to avoid any misunderstanding. For example, the term ‘Device Type’ will be used rather
than just “Type” albeit that it refers to a data element positioned within the Medical Device IPS Data Block.
1 Scope
This document defines the core data set for a patient summary document that supports continuity of care
for a person and coordination of healthcare. It is specifically aimed at supporting the use case scenario
for ‘unplanned, cross border care’ and is intended to be an international patient summary (IPS). The data
set is minimal and non-exhaustive, providing a robust, well-defined core set of data items. This tight focus
on the use case enables the IPS to also be used in planned care, and for both unplanned and planned care
to be supported by this data set within local and national contexts, thereby increasing its utility and value.
It uses the European Guideline from the eHN as the initial source for the patient summary requirements
but takes into consideration other international efforts so as to provide an interoperable data set
specification for global application.
This IPS standard provides an abstract definition of a Patient Summary from which derived models are
implementable. Due to its nature therefore, readers should be aware that the compliance with this
standard doesn’t imply automatic technical interoperability; this result, enabled by this standard, can be
reached with the conformity to standards indicated in the associated technical specification and
implementation guides.
This international standard does not cover workflow processes of data entry, data collection, the
summarization act itself, nor subsequent data presentation, nor assimilation, nor aggregation.
It is not an implementation guide that is concerned with the various technical layers beneath the
application layer. Implementation guidance for specifically jurisdictional concerns, e.g. Directives,
terminologies, formats etc., is specified in the associated Technical Specification (CEN/TS 17288).
In particular, representation by various coding schemes, additional structures and terminologies are not
part of this standard. Terminology and its binding are addressed in the associated Technical Specification
(CEN/TS 17288). The Identification of Medicinal Products standards (abbreviated to IDMP) are the
recommended target for the Medication Summary related to this standard but, prior to IDMP’s full
implementation in practice, this IPS standard cannot insist in its use at this point in time and recognizes
that interim schemes may be necessary until IDMP becomes established as a norm.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 80000 (all parts), Quantities and units
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:

• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
compliance
adherence to requirements for the necessary consistency of one member of the family of specifications
or standards with another which are established during the standardization process
[SOURCE: ISO/IEC 10746-2 (ISO, 2010)]
Note 1 to entry: In this context, compliance “refers to logical consistency and correspondence between a source
artefact and a target artefact, with the target having undergone a transformation (usually a restriction). That is,
given an existing source artefact such as a specification or standard, and a target artefact that resulted from applying
a known transformation to the source, the target is in compliance with the source if the transformation is considered
“legal” by the source artefact’s originator [5].
Note 2 to entry: The target artefact is therefore compliant with the source artefact if and only if
all conformant implementations of the target are also conformant with the source.
3.2
conformance
any proposition that is true of the specification must be true in its implementation
[SOURCE: ISO/IEC 10746-2 (ISO, 2010)]
Note 1 to entry: “A given implementation instance is said to be conformant to a given specification if the
implementation instance satisfies the various requirements defined in the specification.” [5].
3.3
continuity of care
efficient, effective, ethical care delivered through interaction, integration, co-ordination and sharing of
information between different healthcare actors over time
[SOURCE: EN ISO 13940:2016]
3.4
core care plan
reusable content and structure for a potential care plan for a specified set of circumstances
[SOURCE: EN ISO 13940:2016]
3.5
derived model
any conceptual, logical or implementable information model that is obtained from applying a known
transformation from a source information model
Note 1 to entry: example of derived models could be an EN 13606 archetype obtained from a conceptual model; or
an HL7 FHIR profile derived from a HL7 FHIR Logical model; or a CDA template that specializes, or is adapted from,
a parent CDA template. In this sense a CDA implementable specification can be considered a kind of derived model.
Note 2 to entry: An IPS derived model is any logical or implementable model or specification that complies with this
standard.
3.6
demand for care
demand for healthcare
demand for healthcare provider activities expressed by a healthcare actor
Note 1 to entry: A demand for care may be expressed either by the subject of care or on their behalf.
[SOURCE: EN ISO 13940:2016]
3.7
demand for initial contact
first demand for care concerning one or more specific health issues to be assessed by a healthcare
provider
[SOURCE: EN ISO 13940:2016]
3.8
electronic patient summary
electronic health record extract containing essential healthcare information intended for specific uses
[SOURCE: EN ISO 13940:2016]
3.9
health condition
observed or potential observable aspects of the health state at a given time
[SOURCE: EN ISO 13940:2016]
3.10
health record component
part of a health record that is identifiable for the purposes of referencing and revision
Note 1 to entry: The content of a health record is not limited to information in electronic format, the content of
health record components may be in formats other than electronic.
[SOURCE: EN ISO 13940:2016]
3.11
health record extract
EHR extract
health record extract consisting solely of electronic record components
[SOURCE: EN ISO 13940:2016]
3.12
healthcare information request
request sent out by a healthcare actor to another healthcare actor for specific healthcare information
needed for the provision of healthcare to a subject of care
[SOURCE: EN ISO 13940:2016]
3.13
patient summary
Health record extract comprising a standardized collection of clinical and contextual information
(retrospective, concurrent, prospective) that provides a snapshot in time of a subject of care’s health
information and healthcare
[SOURCE: ISO/TR 12773-1:2009]
Note 1 to entry: The eHN Guideline definition is: A Patient Summary is an identifiable “dataset of essential and
understandable health information” [that is made available] “at the point of care to deliver safe patient care during
unscheduled care [and planned care] with its maximal impact in the unscheduled care”; [defined at a high level as:]
“the minimum set of information needed to assure Health Care Coordination and the continuity of care”.
3.14
point of care
location where direct healthcare activities are performed
Note 1 to entry: Location refers to the geographical location of the subject of care; not the body area of the subject
of care that the treatment is applied to.
[SOURCE: EN ISO 13940:2016]
3.15
provenance
record that describes entities and processes involved in producing and delivering or otherwise
influencing that resource
Note 1 to entry: Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing
reproducibility. Provenance assertions are a form of contextual metadata and can themselves become important
records with their own provenance. [6]
[SOURCE: W3C Provenance XG Final Report]
3.16
subject of care
Synonym: patient, client, citizen
healthcare actor with a person role; who seeks to receive, is receiving, or has received healthcare
[SOURCE: EN ISO 13940:2016]
4 Abbreviations
For the purposes of this document, the following abbreviations apply.
CEN Comité Européen de Normalization (European Committee for Standardization, a
federation of 34 national standards bodies that are also ISO member bodies)
CEN IPS CEN International Patient Summary
CEN/TC 251 CEN Technical Committee 251 Health Informatics
eHDSI eHealth Digital Services Infrastructure
EHR Electronic Health Record
eHN eHealth Network
EN European Standard
epSOS European Patients-Smart Open Services pilot project
EU European Union
GP General Practitioner
HL7 Health Level Seven
HL7 CDA HL7 Clinical Document Architecture
HL7 FHIR HL7 Fast Healthcare Interoperability Resources
HL7 IPS HL7 International Patient Summary
IDMP Identification of Medicinal Products standards
IHE Integrating the Healthcare Enterprise
IPS International Patient Summary
ISO International Organization for Standardization
JIC Joint Initiative Council
JIC PSSS JIC Patient Summary Standards Set
PS Patient Summary
TS Technical Specification
UCUM Unified Code for Units of Measure
5 Conformance
5.1 Introduction
To conform to the IPS standard, a patient summary shall be an IPS Document, comprising five mandatory
IPS Data Blocks. One additional, required IPS Data Block, is conditional on the need for any cross-border
application for the IPS. The six mandatory IPS Data Blocks within the IPS Document are:
1. Patient Attributes (‘Patient’s name’ from the Collection)
2. Allergies and Intolerances
3. Medication Summary
4. Problems
5. Provenance (‘Date of IPS Document Creation’ from the Collection)
6. Cross Border (conditional)
An Attribute Collection Data Block is mandatory if an attribute within it is mandatory. The exception is
the cross-border attribute collection; for cross-border applications only, a conformant IPS Document
shall contain the IPS Cross Border data as the sixth required data element.
A conformant IPS Document may contain optional IPS Data Blocks, which are also defined in this
standard.
A conformant IPS Document may also include non-IPS components if required. However, the non-IPS
components are outside of the scope of this standard and are undefined in this standard and therefore no
conformance for them from this document is possible.
Individual IPS Data Blocks can be used in non-IPS patient summaries providing a limited conformance to
the IPS Data Set but for full conformance to this IPS standard, the IPS Document shall comprise at least
the required IPS data elements specified in this clause and have the same purpose as a summary extracted
from the patient’s recorded history.
The IPS Document structure is essentially hierarchical. Whereas the hierarchical relationships between
data elements are significant in terms of requirement, the order of sibling elements is arbitrary and has
no requirement for any implementation.
5.2 IPS Conformance Detail
Table 2 shows the shorthand abbreviations for these ‘requirement descriptors’ and describes what they
mean with respect to the different types of IPS data element.  That having been said, the data element
conformance information has been derived from HL7 and IHE semantics, which illustrate ways of
representing data for transmission and receipt to ensure consistency.
A compliant model or a conformant implementation shall also:
1. Share the same scope of the IPS. Note, a Discharge Summary, although a type of continuity care
document, does not have the same purpose as a patient summary and is not an IPS, although it can
use the IPS Data Blocks as required.
2. Declare, if not self-evident, how the data patterns defined in section 6.3 are realized.
3. Fulfil the conformance rules, as described by the following table, for the IPS Data Blocks and elements
specified in clause 7 Definition of the IPS Document or IPS.
Table 2 — Requirement Descriptors for IPS Document, Section types and IPS data
Value Description Comment
M Mandatory A mandatory element shall always be present and - where applicable
- shall be valorised with valid values. No exceptions or empty/null
(exceptions not
values are allowed in this case.
allowed)
If it refers to a composite element (e.g. a section, a list; a label concept)
the presence of the included elements is determined by the
conformance rules of these sub-elements.
Recipient shall understand mandatory elements.
If a ‘mandatory’ element is missing then the document is no longer a
conformant IPS.
A derived model (that includes also implementable specifications)
shall maintain an equivalent conformance strength.
R Required A required element shall always be present and - where applicable -
should be valorised with valid values. Exceptions or empty/null
(exceptions
values are allowed in this case.
allowed)
If it refers to a composite element (e.g. a section, a list; a label concept
a complex data type) the presence of the included elements is
determined by the conformance rules of these sub-elements.
Recipient shall understand required elements.
If a ‘required’ element is missing then the document is no longer a
conformant IPS.
A derived model (that includes also implementable specifications)
shall maintain an equivalent conformance strength; or may further
constrain it (e.g. from ‘R’ to ‘M’).
Value Description Comment
RK Required, if A “Required if known” element is one that should be provided.
known
If there is information available, the element must be present and -
where applicable - valorised with valid values.
If there is no information available, the element may be omitted, may
be left empty, or may be valorised with exceptional or null values
depending on the implementation.
If it refers to a composite element (e.g. a section, a list, a label concept,
a complex data type) the presence of the included elements is
determined by the conformance rules of these sub-elements.
Recipient shall understand required elements.
A derived model (that includes also implementable specifications)
shall maintain an equivalent conformance strength; or may further
constrain it (e.g. from ‘RK’ to ‘R’).
C Conditional Depending on predicate conditions the element may assume different
conformance strengths (e.g. O, R, RK) or not being present.
(has associated
condition A predicate can be simple (for example: «element A exists»; «attribute
predicates) b = value1») or complex (for example: «element C exists» AND «the
attribute x of element D = value2).
A conditional element may be evaluated on a single condition (if
predicate A then ‘Required’ else ‘Optional’) or on multiple conditions
(e.g. if predicate A then ‘Required’; if predicate B then ‘Optional’; else
‘Not Present’).
The resulting conformance strength (M, R, RK, O, .) is determined by
the conditions.
If it refers to a composite element (e.g. a section, a list, a label concept,
a complex data type) the presence of the included elements is
determined by the combination of the predicate conditions of this
element and the conformance rules of its sub-elements. For example:
1. no exception is raised if a required sub-element is missing,
when the parent is correctly omitted.
2. an exception is raised if a required sub-element is missing,
when the parent is present.
Derived models or implementable specifications shall maintain an
equivalent conformance strength; but it is allowed to modify the
conformance strength if the predicate condition permits.
Recipient shall understand conditional elements, when required. For
example, a conditional element that could be optional or not present
could be omitted by a derived model and ignored by a recipient. Or, a
condition for which a conditional element become required doesn’t
apply to a jurisdiction, in that case a jurisdictional specification could
omit that element and recipient could ignore it.
Depending on the conditions, exception is or is not raised if the data
are missing.
Value Description Comment
O Optional This data element can be omitted from a derived model, including
from implementations.
Recipient may ignore optional elements.
If it refers to a composite element (e.g. a section, a list, a label concept,
a complex data type) the presence of the included elements is
determined by the presence of this element and the conformance
rules of its sub-elements. For example, no exception is raised if a
required sub-element is missing, when the parent is omitted.
The reason for specifying the optional data elements is to ensure that
both sender and recipient use the appropriate semantic
interpretation of these elements.
No exception is raised if the data are missing.
6 Definition and Descriptors for the IPS Data Set
6.1 International patient summary data set
Term: international patient summary data set
Abbreviation: IPS Data Set
Definition: minimal, non-exhaustive set of data elements required for the international patient summary
NOTE 1 ‘Minimal’ and ‘Non-exhaustive’ criteria are derived from the eHN Guideline for the patient summary.
NOTE 2 ‘Minimal’ reflects the ideas of ‘summary’ and the need to be concise, but also alludes to the existence of
a core set of data elements that all health care professionals can use; it is intended to be a speciality agnostic and
condition independent set. It does not imply that all the items in the data set will be used in every summary. It is
also possible to refine the extract from a record such that the content of the summary is more relevant to a particular
condition (e.g. asthma) but no asthma-specific elements will be specified in this standard. The IPS Document or IPS
can be extended by non-IPS standard condition-specific data.
NOTE 3 ‘Non-exhaustive’ recognizes that the ideal data set is not closed, and is likely to be extended, not just in
terms of requirement evolution, but also pragmatically in instances of use. However, such data are outside the scope
of this current standard until review.
NOTE 4 The initial focus of use for IPS is unscheduled care but the IPS can also be used within scheduled care
scenarios; scheduled care or planned care, would probably have access to the full EHR and provide a more extensive
set of data but would also include the IPS Data Set elements.
6.2 IPS Terms and Descriptors
The informative description of the IPS Data Set provides the general layout of what follows. The purpose
of this clause is to describe in detail the normative content, to identify and give meaning to the descriptors
that are used to specify each component and sub component of the IPS data standard.
Each part of the IPS Data Set is described in the same way to provide a consistent and comprehensive
expression of the requirement. The first part is a hierarchy represented within a tabular form naming
and describing the data element and any constituent items.  The table provides the naming and high-
level conformance detail of the data elements. The second part comprises further details and includes a
set of descriptors for the data element and further detailed information concerning the data elements.
The Descriptors used are introduced in Table 3. Certain Descriptors may not be applicable for every part
of the IPS. Nether the less, they will be explicitly included for each data element and their applicability
status will be explicitly stated.so as to avoid any possible confusion by their absence.
Table 3 — Listing and meaning of IPS Data Element Descriptors
Descriptor Comment
Purpose The meaning and value of the data element
Definition A formal description (this may not be necessary if common use is well known)
Business Rules A predicate which defines or constrains some aspect of the IPS and always resolves
to either true or false. More generally, this descriptor is used to describe business
logic.
Missing The meaning of absent data and how it should be addressed
Format How the data are to be represented if more information is required to clarify data
type use.
Inclusion The rationale for including the data element within this standard (cons
...