DRAFT FOR DEVELOPMENT DD ENV

12018:1998

Identification,
administrative, and
common clinical data
structure for
Intermittently
Connected Devices
used in healthcare
(including machine
readable cards)

ICS 11.020; 35.240.60

DD ENV 12018:1998

National foreword

This publication is not to be regarded as a British Standard.

This Draft for Development is identical with the European prestandard
ENV 12018:1997 Identification, administrative, and common clinical data
structure for Intermittently Connected Devices used in healthcare (including
machine readable cards), prepared by CEN, whose members have committed
themselves to making it available in an appropriate form. In the UK the Draft
for Development is the form now chosen for ENVs in the information
technology area.
This Draft for Development is published under the direction of the Information
Systems Technology Assembly, whose Technical Committee IST/35 has the
responsibility to:
— aid enquirers to understand the text;
— present to the responsible European committee any enquiries on the
interpretation, or proposals for change, and to keep the UK interests
informed;
— monitor related international and European developments and
promulgate them in the UK.
NOTE International and European Standards, as well as overseas standards, are available from
Customer Services, BSI, 389 Chiswick High Road, London W4 4AL.
After two years this ENV will be reviewed by CEN members with a view to its:
— conversion into a European Standard (which would be implemented in
the UK as a British Standard);
— extension once for a further two years;
— replacement by a revised ENV (which would be published in the UK as a
revised Draft for Development);
— withdrawal.
The future of this Draft for Development is therefore bound to that of the ENV
and the Draft for Development will not be reviewed separately.

Summary of pages
This document comprises a front cover, an inside front cover, pages i and ii,
the ENV title page, pages 2 to 91 and a back cover.
This standard has been updated (see copyright date) and may have had
amendments incorporated. This will be indicated in the amendment table on
the inside front cover.

This Draft for Development, Amendments issued since publication

having been prepared under
the direction of the DISC Amd. No. Date Comments
Board, was published under
the authority of the
Standards Board and
comes into effect on
15 March 1998

© BSI 06-1999

ISBN 0 580 28959 1

 DD ENV 12018:1998

Contents

Page
National foreword Inside front cover
Foreword 2
Text of ENV 12018 5

© BSI 06-1999 i
ii blank
EUROPEAN PRESTANDARD ENV 12018
PRÉNORME EUROPÉENNE
October 1997
EUROPÄISCHE VORNORM

ICS 11.020; 35.240.60

Descriptors: Medicine, data processing, information interchange, data transmission, data, organization of data

English version

Identification, administrative, and common clinical data

structure for Intermittently Connected Devices used in
healthcare (including machine readable cards)

Structure des données d’identification, des Struktur der Indentifizierungs-, Verwaltungs-

données administratives et des données und der üblichen Medizindaten für im
médicales communes pour les Dispositifs Gesundheitswesen angewandte
Connectés par Intermittence utilisés dans le intermittierend angeschlossene Geräte
domaine de la santé (y compris les cartes (einschließlich der maschienenlesbaren
lisibles par machine) Karten)

This European Prestandard (ENV) was approved by CEN on 30 October 1995

as a prospective standard for provisional application.
The period of validity of this ENV is limited initially to three years. After two
years the members of CEN will be requested to submit their comments,
particularly on the question whether the ENV can be converted into a
European Standard.
CEN members are required to announce the existence of this ENV in the same
way as for an EN and to make the ENV available promptly at national level in
an appropriate form. It is permissible to keep conflicting national standards in
force (in parallel to the ENV) until the final decision about the possible
conversion of the ENV into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium,
Czech Republic, Denmark, Finland, France, Germany, Greece, Iceland,
Ireland, Italy, Luxembourg, Netherlands, Norway, Portugal, Spain, Sweden,
Switzerland and United Kingdom.

CEN
European Committee for Standardization
Comité Européen de Normalisation
Europäisches Komitee für Normung
Central Secretariat: rue de Stassart 36, B-1050 Brussels

© 1997 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national
Members.
Ref. No. ENV 12018:1997 E
ENV 12018:1997

Foreword Page
[Link] The “Place” data object 13
This European Prestandard has been prepared by
[Link] The “Telecommunication” data object 13
Technical Committee CEN/TC 251 “Medical
informatics”, the secretariat of which is held by SIS. [Link] The “Telephone Numbers” data object 13
This European Prestandard has been prepared [Link] The “X.400” and “Other Network
under a mandate (BC-IT-217) given to CEN by the Addresses” data objects 13
European Commission and the European Free [Link] The “Money” data object 13
Trade Association, and supports essential 6.3 Basic data objects 13
requirements of EU Directive(s).
6.3.1 Record persons 13
According to the CEN/CENELEC Internal
Regulations, the national standards organizations [Link] The “Record Persons” data object 13
of the following countries are bound to announce [Link] The “Record Person” data object 14
this European Prestandard: Austria, Belgium, [Link] The “Major Record Identifier” data
Czech Republic, Denmark, Finland, France, object 14
Germany, Greece, Iceland, Ireland, Italy, [Link] The “Alternative Record Identifiers”
Luxembourg, Netherlands, Norway, Portugal, data object 15
Spain, Sweden, Switzerland and the
United Kingdom. [Link] The “Record Identification
Verification” data object 15
Contents 6.3.2 The “Device Specific Data” object 15
Page [Link] The “Device Type” data object 15
Foreword 2 [Link] The “Device Class” data object 15
Introduction 5 [Link] The “Device Standard” data object 15
1 Scope 6 [Link] The “Device Specifications” data
object 15
2 Normative references 6
[Link] The “Device Applications” data
3 Definitions 7 object 15
4 Abbreviations 10
[Link] The “Device Specific Directory”
5 Basic data object model for an ICD 10 data object 16
5.1 Object structure 10 [Link] The “Device Identification” data
5.2 Linking 11 object 16
6 Basic data objects for referencing 11 6.3.3 Objects linking sites and persons 16
6.1 Overview 11 [Link] The “Healthcare Sites” data object 16
6.2 Generally useful types used for [Link] The “Healthcare Persons” data
implicit definitions 11 object 16
6.2.1 Person name related data objects 12 [Link] Linking of sites and healthcare
[Link] The “Full Name” data object 12 persons: the “Site Mix Table” data
object 16
[Link] The “Title” data object 12
6.3.4 Coded data 17
[Link] The “Surname Prefix” data object 12
[Link] The “CodingSchemesUsed” data
[Link] The “Surnames” data object 12 object 17
[Link] The “Surname” data object 12 [Link] The “CodedData” data object 17
[Link] The “Forenames” data object 12 6.3.5 Attributes 17
[Link] The “Forename” data object 12 [Link] Accessory attributes 17
[Link] The “Name Element” data object 12 [Link] Device and data security attributes 18
6.2.2 Address and telecommunication 6.4 Link associations between objects 19
related data objects 12
6.4.1 The “RecordPersonPointer” data
[Link] The “Postal Address” data object 12 object 19
[Link] The “Post Code” data object 12 6.4.2 The “ReferencePointer” and
[Link] The “Country” data object 12 “ReferenceTag” data objects 19
[Link] The “Date” data objects 13 6.4.3 The “Linkages” data object 19

2 © BSI 06-1999
 ENV 12018:1997

Page Page
6.5 Data from ICDs held by healthcare 9 Specific ICDs security services
persons 20 related data objects 27
7 Basic identification and 9.1 Patient devices security related data 27
administration data 20 9.2 Healthcare persons devices security
7.1 The “Variable Identification Data” related data 27
object 20 9.2.1 Healthcare persons access keys: the
7.1.1 The “Address” data object 20 “PatientICDAccessData” data object 27
7.1.2 The “Record Person Telecom” data 9.2.2 Healthcare persons authentication
object 20 key: the “IdAuthenticateData” data
7.1.3 The “Preferred Languages” data object 27
object 20 9.2.3 Healthcare persons signature
7.1.4 The “Maiden Name” data object 21 key: the “HCPSignFuncData”
data object 28
7.1.5 The “Previous Surnames” data
object 21 9.2.4 Healthcare persons authentication
and signature public keys and
7.1.6 The “Other Names” data object 21
certificate 28
7.2 The “Record Person Post Code” data
9.2.5 Object related security reference
object 21
data 28
7.3 The “Record Person Country” data
9.3 The “SecurityAttributes” data object 28
object 21
Annex A (informative) General points
7.4 The “Contact Persons” data object 21
about ASN.1 data objects representation 29
7.5 The “Record Person Visiting
A.1 ASN.1 definitions 29
Instructions” data object 21
A.2 ASN.1 syntax 30
7.6 The “Payment Provisions” data
object 22 A.3 The Tag-Length-Value format 31
7.7 The “Patient Payments” object 23 A.4 The use of tags 31
7.8 The “Other Coded Administrative A.5 Examples of using the Basic
Data” object 23 Encoding Rules for use with ASN.1
for objects in this standard 31
8 Clinical data 23
Annex B (normative) ASN.1 representation
8.1 The “Clinical Coded Data” object 23
of data objects in this European Prestandard 32
8.2 The “Parameter” data objects 23
B.1 Basic Data Objects for Referencing 32
8.2.1 The “Medication Note” parameter
B.1.1 Person Name related data objects 32
object 23
B.1.2 Address and Telecommunication
8.2.2 The “Medication Prescription”
related data objects 33
parameter object 24
B.1.3 The “Money” data object 33
8.2.3 The “Medication Administered”
parameter object 24 B.2 Basic Data Objects 33
8.2.4 The “Medication Dispensed” B.2.1 The “Record Persons” data object 33
parameter object 25 B.2.2 The “Major Record Identifier” data
8.2.5 The “Drug Sensitivity” parameter object 34
object 25 B.2.3 The “Alternative Record Identifiers”
8.2.6 The “Laboratory Test Results” data object 34
parameter object 25 B.2.4 The “Record Identification
8.2.7 The “Digital Binary Data” Verification” data object 35
parameter object 26 B.3 The “Device Specific Data” object 35
8.2.8 The “Request” parameter object 26 B.3.1 The “Device Data” object 35
8.2.9 The “Diagnosis” parameter object 26 B.3.2 The “Device Type” data object 35
8.2.10 The “Procedures” parameter object 26 B.3.3 The “Device Applications” data object 35
8.3 The limited emergency data set 26 B.3.4 The “Device Specific Directory”
data object 35

© BSI 06-1999 3
ENV 12018:1997

Page Page
B.3.5 The “Device Identification” data B.20.2 The “Medication Prescription”
object 36 parameter object 44
B.4 The “Healthcare Sites” data object 36 B.20.3 The “Medication Administered”
B.5 The “Healthcare Persons” data parameter Object 45
object 36 B.20.4 The “Medication Dispensed”
B.6 Linking of sites and healthcare parameter object 45
persons: the “Site Mix Table” data B.20.5 The “Drug Sensitivity” parameter
object 37 object 46
B.7 Coded data and coding schemes 37 B.20.6 The “Laboratory Test Results”
B.7.1 The “Coding Schemes Used” data parameter object 46
object 37 B.20.7 The “Digital Binary Data”
B.7.2 The “Coded Data” data object 37 parameter object 47
B.8 The “Accessory Attributes” data B.20.8 The “Request” parameter object 47
object 37 B.20.9 The “Diagnosis” parameter object 47
B.9 Link associations between objects 38 B.20.10 The “Procedure” parameter object 47
B.9.1 The “Record Person Pointer” data B.21 The Limited Emergency Data Set 47
object 38 B.22 Specific ICDs security services
B.9.2 The “Reference Pointer” and related data objects 48
“Reference Tag” data objects 39 B.22.1 Patient devices security related data 48
B.9.3 The “Linkages” data object 39 B.22.2 Healthcare persons devices
B.10 Data from ICDs held by security related data 49
healthcare persons 39 Annex C (informative) The hierarchy of
B.11 Basic ID & Administration Data 39 data objects 51
B.11.1 The “Address” data object 39 C.1 Basic data objects for referencing 51
B.11.2 The “Record Person Telecom” C.2 Basic data objects for identification
data object 39 and administrative purposes 54
B.11.3 The “Preferred Languages” data C.3 Clinical data 57
object 40 C.4 Specific ICDs security services
B.11.4 The “Maiden Name” data object 40 related data objects 59
B.11.5 The “Previous Surnames” data Annex D (normative) Application specific
object 40 data object tags and their values 60
B.11.6 The “Other Names” data object 40 Annex E (informative) Devices that may
B.12 The “Record Person Post Code” function as Intermittently Connected Devices 60
data object 40 Annex F (informative) Data Dictionary 61
B.13 The “Record Person Country” data F.1 Data types 62
object 40 F.2 Status of the attributes within
B.14 The “Contact Persons” data object 40 the objects 62
B.15 The “Record Person Visiting Annex G (informative) EDIFACT
Instructions” data object 41 representation of a sample of data objects 82
B.16 The “Payment Provisions” data Table F.1 — Data dictionary 63
object 41 Table G.1 — Data dictionary illustration 86
B.17 The “Patient Payments” data object 43 Table G.2 — EDIFACT message
B.18 The “Other Coded Administrative representation between CAD and host 90
Data” object 43
B.19 The “Clinical Coded Data” object 43
B.20 The “Parameter” data objects 44
B.20.1 The “Medication Note” parameter
object 44

4 © BSI 06-1999
 ENV 12018:1997

Introduction
With a more mobile population, greater healthcare delivery in the community and at patients’ homes,
together with a growing demand for improved quality of ambulatory care, portable information systems
and stores have increasingly been developed and used. Such devices are used for tasks ranging from
identification, through portable medical record files, and on to patient-transportable monitoring systems.
The functions of such devices are to carry and to transmit person-identifiable information between
themselves and other systems; therefore, during their operational lifetime they may share information
with many technologically different systems which differ greatly in their functions and capabilities.
Healthcare administration increasingly relies upon similar automated identification systems too. For
instance prescriptions may be automated and data exchange carried out at a number of sites using patient
transportable computer readable devices. Healthcare insurers and providers are increasingly involved in
cross-region care, where reimbursement may require automated data exchange between dissimilar
healthcare systems.
The advent of remotely accessible data bases and support systems has led to the development and use of
“Healthcare Person” identification devices that are also able to perform security functions and transmit
digital signatures to remote systems via networks.
With the growing use of intermittently connected devices for practical everyday healthcare delivery, the
need has arisen for a standardised data format for interchange.
The data carried by an ICD can be categorised in three broad types: identification, administrative and
clinical.
Identification data may include:
— identification of the device itself;
— unique identification of the device holder or of all other persons to whom the data carried by the device
are related.
Administrative data may include:
— complementary person(s) related data;
— identification of the funding of health care, whether public or private, and their relationships
i.e. insurer(s), contract(s) and policy(ies) or types of benefits;
— other data (distinguishable from clinical data) that are necessary for the purpose of healthcare
delivery.
Common clinical data may include:
— items that provide information about health and health events;
— their appraisal and labelling by a Healthcare Provider (HCP);
— related actions planned requested or performed;
— the outcome of such actions (e.g. in terms of tests results).
Because there exists a need to optimise the use of memory by avoiding redundancies, and also because an
ICD essentially provides specific answers to definite queries, “high level” Object Modelling Technique
(OMT) has been applied with respect to ICDs data structure.
Data in the three categories above share many features. For instance, each may need to include ID
numbers, names and dates. Some information may also have clinical as well as administrative uses.
Therefore it has been considered inadequate to provide a simple list of items carried by ICDs without
applying a generic organisation, based upon the existence of basic data elements. These may be defined by
their characteristics (e.g. their format), and from them compound data objects may be constructed; several
such objects may also share attributes.
This European Prestandard describes the data objects using plain text in normative clauses 6, 7, and 8.
Clause 6 defines basic data objects for referencing.
Clause 7 defines objects for:
— administrative data to allow identification of patient or of healthcare persons (professionals and other
types of personnel) and of records belonging to them;
— demographic and general administrative data.

© BSI 06-1999 5
ENV 12018:1997

Clause 8 defines objects for clinical data interchange requirements, with special emphasis on coded data.
Annex A gives general information about the ASN.1 syntax.
Annex B, Annex C, and Annex D (normative) provide a representation of all objects using ASN.1 notation
with the corresponding tags, whilst Annex F provides a data dictionary, and Annex G (informative) an
EDIFACT representation of a sample of data objects.

1 Scope
This European Prestandard establishes a common framework for the content and the structure of
identification, administrative and common clinical data. It applies exclusively to situations in which such
data are recorded on or transported by Intermittently Connected Devices (ICDs) which are intended for use
in healthcare.
This European Prestandard specifies the basic structure of the data, but does not specify particular
data-sets for storage on devices.
To allow interoperability, whenever an application is built for use in the healthcare domain in compliance
with this European Prestandard, data items required for that application shall be drawn from the list of
objects (some of which are extensible) as provided in clauses 6 to 8. The detailed functions and mechanisms
of the following services are not within the scope of this European Prestandard, (although its structures
can accommodate suitable data objects elsewhere specified):
— security functions and related services which are likely to be recommended for ICDs depending on
their specific application, for example: confidentiality protection, data integrity protection, and
authentication of persons and devices;
— access control services which may depend on active use of some ICD classes such as microprocessor
cards;
— the initialisation and issuing process (which begins the operating lifetime of an individual ICD, and
by which the ICD is prepared for the data to be subsequently communicated to it according to this
European Prestandard).
Data is extracted from an ICD in the form of a “message”. This European Prestandard addresses the
“meaning” of the message within or at the interface between an ICD and an application system, not the
“method” of its origination or transmission.
The following topics are therefore beyond the scope of this European Prestandard:
— physical or logical solutions for the practical functioning of particular types of ICDs;
— how the message is processed further “downstream” of the interface between two systems;
— the form which data takes for use outside the ICD, or the way in which such data is visibly represented
on the ICD or elsewhere.

2 Normative references
This European Prestandard incorporates, by dated or undated reference, provisions from other
publications. These normative references are cited at the appropriate places in the text and the
publications are listed hereafter. For dated references, subsequent amendments to or revisions of any of
these publications apply to this European Prestandard only when incorporated in it by amendment or
revision. For undated references the latest edition of the publication referred to applies.
ENV 1068:1993, Medical informatics — healthcare information interchange — Registration of coding
schemes.
EN 1387, Machine readable cards — Health care applications — Cards: General characteristics1).
EN 23166:1994, Codes for the representation of names of countries.
EN 27816-3:1992, Identification cards — Integrated circuit(s) cards with contacts — Part 3: Electronic
signals and transmission protocols.
EN 28601:1992, Data elements and interchange formats — Information interchange — Representation of
dates and times.
ISO 639:1988, Codes for the representation of names of languages.

1)
At present at the stage of draft.

6 © BSI 06-1999
 ENV 12018:1997

ISO 4217:1990, Codes for the representation of currencies and funds.

ISO 5218:1977, Information interchange — Representation of human sexes.
ISO 6093:1985, Information processing — Representation of numerical values in character strings for
information interchange.
ISO 6523:1984, Data interchange — Structures for the identification of organisations.
ISO 7498-2:1989, Information processing systems — Open Systems Interconnection — Basic Reference
Model — Part 2: Security Architecture.
ISO/IEC 8824:1990, Information technology — Open Systems Interconnection — Specification of Abstract
Syntax Notation One (ASN.1).
ISO/IEC 8825:1990, Information technology — Open Systems Interconnection — Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1).
ISO 8859-1:1987, Information processing — 8-bit single byte coded graphic character sets — Part 1: Latin
alphabet No. 1.
ISO 8908:1993, Banking and related financial services — Vocabulary and data elements.
ISO/IEC 9594-8:1990, Information technology — Open Systems Interconnection: The Directory —
Part 8: Authentication framework.
ISO/IEC 9798-1:1991, Information technology — Security techniques — Entity authentication
mechanisms — Part 1: General model.
ISO/IEC 10181-2, Information technology — Open Systems Interconnection — Security Frameworks for
Open Systems: Authentication Framework2).
CCITT, Numbering plan for the international telephone service.
Recommendation
E.163

3 Definitions
For the purposes of this European Prestandard, the following definitions apply.
3.1
alternative record identifier
an alternative record identifier is an identifier, composed of characters, that is not identical to the major
record identifier and is related to the same record person
3.2
asymmetric authentication method
method for demonstrating knowledge of a secret, in which not all authentication information is shared by
both entities
3.3
confidentiality
the property that information is not made available or disclosed to unauthorised individuals, entities or
processes. [ISO 7498-2:1989]
3.4
country
the code that identifies the country of origin of the device issuer
NOTE This may not necessarily be the same as the nationality of the device holder.
3.5
cryptographic key
parameter used, in conjunction with an algorithm, for the purposes of validation, authentication,
encipherment, or decipherment. [ISO 8908:1993]

2)
At present at the stage of draft.

© BSI 06-1999 7
ENV 12018:1997

3.6
cryptography
the discipline which embodies principles, means, and methods for the transformation of data in order to
hide its information content, prevent its undetected modification and/or prevent its unauthorised use.
[ISO 7498-2:1989]
3.7
data integrity
the property that data has not been altered or destroyed in an unauthorised manner [ISO 7498-2:1989]
3.8
data object
a data object is a collection of data that has a natural grouping and may be identified as a complete entity
3.9
data origin authentication
the corroboration that the source of data received is as claimed [ISO 7498-2:1989]
3.10
data sub-object
a data sub-object is a component of a data object that itself may be identified as a discrete entity
3.11
device holder
a device holder is an individual transporting an ICD which contains a record with themselves identified as
the major record person
3.12
digital signature
data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit
to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient
[ISO 7498-2:1989]
3.13
entity authentication
the corroboration that an entity is the one claimed [ISO/IEC 9798-1:1991]
3.14
erasure
the process whereby access to a data entity after a given point in time is permanently removed or access
denied thereafter to all parties
NOTE This may not involve physical removal from the device, and may merely be the result of altering security such that access is
permanently denied to all parties.
3.15
healthcare person device
an HCP device is designed to provide the function of allowing healthcare persons to have their identity and
qualifications acknowledged by the information systems that they use, including informatics and
telematics, and if necessary, to sign the transactions that they perform via these systems
3.16
ICD application system
an application system that can communicate with an ICD
3.17
ICD connecting unit
a physical device, which may also contain software elements, that enables communication to take place
between an ICD and a host

8 © BSI 06-1999
 ENV 12018:1997

3.18
interface
may be both physical or electrical or logical. A hypothetical junction between an ICD and the external
environment
NOTE This term can be used with a qualifier to describe an attribute to allow data flow to take place over this hypothetical point.
3.19
intermittently connected device (ICD)
an Intermittently Connected Device:
a) stores person related information in computer readable format; and
b) supports data interchange; and
c) when used for data interchange does not require that the originator of the information receives
“confirmation of receipt” of the information”.
NOTE Many different types of hardware may be ICDs but it is important that being an ICD according to this definition is never an
intrinsic aspect of the device itself but is dependant upon a certain usage. An ICD may have several uses and hardware functions
other than the storage and transmission of person related data.
3.20
linkage
the ability to join together two or more entities or parts. It may be physical, electrical or relational
3.21
major industry identifier (MII)
the code that identifies the sector/industry within which the ICD is intended for use
3.22
major record identifier
the major record identifier is an identifier linked to a primary record relating to a record person within an
ICD and a given healthcare delivery system
3.23
personal identification number (PIN)
the PIN is a 4 to 12 character alphanumeric code or password the device holder possesses for the purposes
of authentication
3.24
record
a record is a collection of data
3.25
record person
a record person is an individual about whom there is an identifiable record containing person related data
3.26
security
the combination of confidentiality, integrity and availability
3.27
soft network
a logical form of linkage in which message sender and recipient are not physically linked and in which
message receipt confirmation may not be received by sender
3.28
update
the process whereby information is erased and replaced by new information
3.29
write
the process whereby information is added to the ICD

© BSI 06-1999 9
ENV 12018:1997

4 Abbreviations

CAD Card accepting device

HCP Healthcare person
HCD Healthcare coding scheme designator
ICC Integrated circuit card
ICD Intermittently Connected Device
IEC International Electrotechnical Commission
ISO International Organisation for Standardisation
PIN Personal Identification Number
MII Major Industry Identifier
UTC Coordinated Universal Time

5 Basic data object model for an ICD

5.1 Object structure
A set of basic data object tools has been designed to facilitate the storage of identification, administrative,
or common clinical data in a flexible structure, allowing for future and application specific enhancements.
These tools should help implementation of common accessory characteristics of stored data in a way that
allows efficient use of memory, an important feature for many ICDs.
The tools consist of a genetic data structure based on an object-oriented model. The content of this
object-oriented structure is described in Annex B (normative) using ASN.1 notation. The ASN.1 notation
is only used as a tool to describe this structure. Examples of an implementation using EDIFACT syntax are
also provided in Annex G (informative).
NOTE It is possible to take the data objects and recombine them whilst preserving their context specific tags, and to define new
objects, while still preserving interoperability.
In addition to the capability of building complex aggregate data objects from simpler building blocks, the
standard allows for associations between certain objects, so that information can be shared. This feature is
mainly used to allow, for example, a set of accessory attributes to be used as services to several stored
information objects.
The basic data object tools consist of these functional groups:
a) identification, security and linkage objects consisting of:
record persons,
device specific data,
coding schemes used,
healthcare persons and sites,
accessory attributes,
linkages;
b) administrative data objects consisting of:
administrative coded data,
function related non coded administrative data sets;
c) clinical data objects consisting of:
coded clinical data,
non coded clinical data,
function related clinical data.

10 © BSI 06-1999
 ENV 12018:1997

5.2 Linking
A number of objects in the data model of this European Prestandard are used mainly as a reference to other
objects. One example is the RecordPerson that defines the basic identification information of a person to
whom records on the device relate. Since this is a part of an aggregate object containing information on all
record persons in a sequential order, the pointer may be a simple one-dimensional integer number. This
type of pointer has the name RecPersPointer and is used extensively to indicate the record person to whom
a certain information object is related.
In other situations, constructed objects contain a more general pointer called a RefPointer that is a
sequence of tags allowing a reference to any object, including sub-objects that can only be referenced as part
of a constructed object, using an application specific tag and a number of context specific tags to sufficient
depth.
A RefPointer to the name of a healthcare person may contain the following information with the
appropriate tags (here represented by their symbolic names):
HealthCarePersons [7]HealthCarePerson no 7 [1] HcpName
Application tag Context level 1 Context level 2

All administrative and clinical Coded data items have Accessory attributes. These data objects contain
information on when, where and who recorded data. They allow specification of security services and
parameters. If security requirements permit, such data objects may be associated with several objects.
There is also a third possibility that allows the creation of linkages between all objects using the Linkages
object (see further in clause 11.4). This is an ordered list of link associations. All entries in this list are a
sequential list of other objects, each defined with a RefPointer.
EXAMPLE: Link no 2 may link four objects
1:
2: RefPointer1 RefPointer2 RefPointer3 RefPointer4
3:

An example of this process could be the linkage of the following objects as defined in clause B.20.
Diagnosis — RefPointer1
MedicationPrescription — RefPointer2
MedicationNote — RefPointer3
MedicationDispensed — RefPointer4

This linkage table entry may be pointed to by the ClinRefPointer of each ClinDat object.
NOTE Even though the Link object itself is openly available, the linked objects may have restricted access.

6 Basic data objects for referencing

6.1 Overview
A series of generally useful type definitions have been made that have no meaning by themselves, but
which are used to define other objects within this standard. These objects are described in clause 6.2.
A series of basic data objects have also been defined to be used as references in other information objects
for both administrative and clinical data. Contrary to the above, some of these objects are also used directly,
particularly when identification is the primary use of the ICD. Operations that may be performed with
these objects in association with other information objects are described in clause 6.3.
6.2 Generally useful types used for implicit definitions
These objects shall only be used to define other objects and shall never be referenced independently.
The OCTET STRING type used in the following definitions shall be used to represent character strings
coded in the ISO 8859-1:1987 character set unless otherwise specified.

© BSI 06-1999 11
ENV 12018:1997

6.2.1 Person name related data objects

Data objects related to person names shall be constructed as defined textually according to a top-down
approach in the following sub-clauses.
The ASN.1 representation of all these person name related data objects is provided in Annex B,
clause B.1.1.
[Link] The “Full Name” data object
The object “Fullname” shall consist of a sequence of “Title”, “Surname Prefix”, “Surnames”,
“Surname Suffix”, and “Forenames”.
The ASN.1 representation of these data sub-objects is provided in Annex B, clause B.1.1.
[Link] The “Title” data object
The object “Title” shall consist of an octet string of length from 1 to 7 characters.
[Link] The “Surname Prefix” data object
The object “SurnamePrefix” shall consist of an octet string of length from 2 to 15 characters.
[Link] The “Surnames” data object
The object “Surnames” shall be constructed of a sequence of up to two objects “Surname”; one “Surname”
may be designated as the “Preferred Surname”.
[Link] The “Surname” data object
Each object “Surname” shall be constructed according to the definition contained in object “Nameelement”
as defined in clause [Link].
[Link] The “Forenames” data object
The object “Forenames” shall consist of a sequence of up to three objects “Forename”; one “Forename” may
be designated as the “Preferred Forename”.
[Link] The “Forename” data object
Each object “Forename” shall bc constructed according to the definition contained in object “Nameelement”
as defined in clause [Link].
[Link] The “Name Element” data object
The object “Nameelement” shall consist of an octet string of length 2 to 27 characters.
6.2.2 Address and telecommunication related data objects
Data objects related to address locations and data objects related to telecommunications shall be
constructed as defined textually according to a top-down approach in the following sub-clauses. The ASN.1
representation of all these address and telecommunication related data objects is provided in Annex B,
clause B.1.2.
[Link] The “Postal Address” data object
“PostAddr” data object shall not include the post code nor a component identifying the country and shall
consist of an alphanumeric string of variable length between 1 and 35 characters.
The structure of such an address shall follow the format: House name/Number and name of street, Town,
County. The separator * (asterisk) shall be used between each component. In the event of only one
component being present the separator shall precede this component.
The ASN.1 representation of this data object is provided in Annex B, clause B.1.2.
[Link] The “Post Code” data object
“PostCode” data object shall consist of an alphanumeric string of variable length between 1 and 8
characters.
[Link] The “Country” data object
Country shall be represented by coded data in the form of a three character numeric string as defined in
EN 23166:1994.

12 © BSI 06-1999
 ENV 12018:1997

[Link] The “Date” data objects

“Date” data objects shall be constructed according to the UTC time definitions detailed in
ISO/IEC 8824:1990, with a length of between 6 and 12 characters.
The ASN.1 representation of these data objects is provided in Annex B, clause B.1.2.
[Link] The “Place” data object
“Place” data objects shall be constructed as an octet string with a length comprised between 1 and 15
characters.
The ASN.1 representation of these data objects is provided in Annex B, clause B.1.2.
[Link] The “Telecommunication” data object
The data object “Telecom” shall consist of a set of optional data objects “TelnoRecpersonHome” (Telephone
Number of Record Person’s Home), “TelnoRecpersonWork” (Telephone Number of Record Person’s Working
place), “TelnorecpersonOther” (Other Telephone Number of Record Person), “FaxnoRecpersonHome”
(Fax Number of Record Person’s Home), “FaxnoRecpersonWork” (Fax Number of Record Person’s Working
place), “X.400address”, and “OtherNetworkAddress”.
With the exception of “X.400address”, and “OtherNetworkAddress” data objects, each of these objects shall
be constructed according to the definition contained in object “Telno” (see clause [Link]).
“X.400address”, and “OtherNetworkAddress” data objects shall be constructed according to the definition
contained in clause [Link].
The ASN.1 representation of these data objects is provided in Annex B, clause B.1.2.
[Link] The “Telephone Numbers” data object
A “Telno” data object shall be constructed in the format required to dial the number from any location in
the world. It shall not include either the code required to obtain an international line from any specific
location, nor the first redundant character of any internal area code.
The string shall therefore consist of country code consisting of 1-3 digits as described in CCITT
Recommendation E. 163 Annex A, area code and local telephone number. Such telephone numbers shall
consist of a numeric string with no separators of between 1 and 15 characters.
The ASN.1 representation of this data object is provided in Annex B, clause B.1.2.
[Link] The “X.400” and “Other Network Addresses” data objects
“X.400” and “OtherNetworkAddress” shall consist of an octet string of between 1 and 30 characters in
length.
The ASN.1 representation of these data objects is provided in Annex B, clause B.1.2.
[Link] The “Money” data object
The “Money” data object shall be constructed as a sequence of both value (“Amount”) and “Currency”.
“Amount” shall consist of an integer.
“Currency” shall be in the form of a code as described in ISO 4217:1990, i.e. in the form of an octet string
with a length of three characters.
The ASN.1 representation of these data objects is provided in Annex B, clause B.1.3.
6.3 Basic data objects
Basic data objects are objects that contain information in relation to the device itself, or otherwise used for
reference to other objects.
6.3.1 Record persons
This series of data objects provide identification information regarding the various persons that may have
records on the device.
Usually there will only be data relating to one person.
[Link] The “Record Persons” data object
This is identification information regarding the various persons that may have records on the device. When
the device is a card, there will usually be data relating to only one person.

© BSI 06-1999 13
ENV 12018:1997

The “RecordPersons” data object shall consist of a sequence of “RecordPerson” data objects. A “Major
Record Person” shall always be designated. In addition there may be any number of other Record Persons.
Thus the “Major Record Person” shall be followed by a choice of other Record Persons (spouse, child, father,
mother, other person). Each of these “RecordPerson” data objects shall be constructed as defined in
clause [Link].
The ASN.1 representation of these data objects is provided in Annex B, clause B.2.1.
NOTE When the device is a card, the Major Record Identifier of the Major Record Person, is also the Major Identifier for the device;
in such a case it will therefore always be present as visible data on the outside of the card.
[Link] The “Record Person” data object
The purpose of this object is to allow for record linkage to be performed. The object may also be used to
provide identification information. When the device is a card, the major record identifier of the major record
person will always be present as visible data on the outside of the card if following the scheme standardised
within EN 1387.
The “Record Person” data object shall consist of a set of a “Major Record Identifier”, of optional “Alternative
Record Identifiers”, and of a “Record ID Verification” data objects.
The ASN.1 representation of these data objects is provided in Annex B, clauses B.2.1 to B.2.4.
[Link] The “Major Record Identifier” data object
The “Major Record Identifier” data object shall be constructed as a sequence of components. These
components shall consist of the Major Industry Identifier (MII), the issuer country, the issuer identifier, a
check digit, and a record ID number.
The healthcare sector indicator (“Major Industry Identifier”, or MII) shall consist of a 2 characters long
Numeric String. The default value shall be 80 as already allocated to the health sector.
The “Issuer Country” code shall be three characters numeric coded data as defined according to
EN 23166:1994 in clause [Link] (“Country” data object).
The “Issuer Identifier” shall be a five character numeric code as allocated to all card issuers when the ICD
is in the form of a card. This issuer code shall be allocated by a nationally appointed registration authority.
A “Check Digit” shall be calculated on the foregoing three code values according to the Luhn modulus ten
double-add-double check digit formula.
The “Record ID Number” shall be constructed according to the “Evolutionary Record Identifier” data object
defined below. The evolutions of the record identifier are intended to provide for the existence of any format
of identifier whilst preserving the migration of identifiers towards integrated systems.
A “Record ID Number” shall consist of:
— a transitional sequence identifier consisting of a single integer defined as an “Evolutionary Record
Identifier”. This data object indicates the phase of evolution of the numbering system and value. Thus
identifiers can appear in three possible types. But all such record ID numbers when undergoing future
structural change shall transfer to the all numeric format;
— the “Evolutionary Record Identifier” data object shall consist of a choice of three octet strings
(Evolution1, Evolution2, and Evolution3).
“Evolution1” type defines a free format alphanumeric record identifier, with any form of separator,
and a maximum number of characters of 27.
“Evolution2” type defines a record identifier that has only alphanumeric characters and a single
form of separator being a forward slash (/). Its maximum number of characters is 27.
“Evolution3” type defines a RecordIdentifier that is all numeric with no separators and a maximum
number of characters of 27.
NOTE 1 The evolutions of the RecordIdentifier are intended to provide for the existence of any format of Identifier whilst preserving
the migration of identifiers towards integrated systems. These evolutions are “tagged” and thus identified, so that records relating to
an individual may be identified by more than one type of identifier within a given healthcare delivery system. This concept is distinct
from the facility provided within alternative record identifiers (see clause [Link]).
NOTE 2 In the case of an ICD in the form of a card the Evolutionary Record Identifier shall be the card holder identification number
as defined in EN 1387.
The ASN.1 representation of this data object and its components is provided in Annex B, clause B.2.2.

14 © BSI 06-1999
 ENV 12018:1997

[Link] The “Alternative Record Identifiers” data object

Alternative record identifiers provide for the function of record linkage and are intended for use between
different healthcare delivery systems or where more than one record identifier exists.
The “Alternative Record Identifiers” data object shall be constructed as an optional set consisting of a social
security number and a sequence of alternative numeric record identifiers.
The ASN.1 representation of these data objects is provided in Annex B, clause B.2.3.
[Link] The “Record Identification Verification” data object
The “Record Identification Verification” data object represents data that are fixed for the lifetime of the
record person to whom the record relates. It is to be used as an aid to verification when identity is not
obvious.
The “Record Identification Verification” data object shall be constructed as a set consisting of the record
person full name as written at birth registration, his or her date of birth, the sex of the individual as stated
at birth, his or her place of birth described in a concise format, and optionally accessory attributes.
The “Record Person Name” shall be defined as a “FullName” data object (see [Link]).
The “Date of Birth” shall be defined as a “Date” data object (see [Link]).
The “Sex at Birth” shall consist of an size 1 octet string according to ISO 5218:1977.
The “Place of Birth” shall be defined as a “Place” data object (see [Link]).
The “Accessory Attributes” data object is defined in clause 6.3.5.
The ASN.1 representation of these data objects is provided in Annex B, clause B.2.4.
6.3.2 The “Device Specific Data” object
Device specific data gives information related to the capabilities of the device, the types and ranges of
information stored. Additional data shall exist within the object to enable signature functions related to
the device to take place.
The object “DeviceData” shall consist of the set of optional sub-objects “DevType”, “DevDirectory”, and
“DevIdentification” as defined in clauses [Link] to [Link].
The ASN.1 representation of these data objects is provided in Annex B, clause B.3.5.
[Link] The “Device Type” data object
The “DevType” data object shall contain a set of coded data that will convey information regarding the type
of ICD and its capabilities. It shall not contain information regarding either applications on the device or
specific security attributes. The object “DevType” shall consist of a set of three Coded Data objects
(constructed as defined in clause [Link]), namely “Device Class”, “Device Standard”, and “Device
Specifications”.
The ASN.1 representation of this data object is provided in Annex B, clause B.3.2.
[Link] The “Device Class” data object
The “DeviceClass” data object shall be in the form of coded data and shall specify the class of ICD.
[Link] The “Device Standard” data object
The “DeviceStandard” data object shall be in the form of coded data and shall specify a particular published
standard in relation to the class of device.
[Link] The “Device Specifications” data object
The “DeviceSpec” data object shall be in the form of coded data and shall specify the functions that the
device is able to perform and its capabilities.
[Link] The “Device Applications” data object
The applications on the device may be defined by two methods. Broad classes (identification,
administrative, clinical, and other) may be defined in the boolean object “DevApplicationClass”, while a
more specific definition may be added using coded data in the “DevApplicationCodes” object.
Thus the “DevApplications” data object”, listing the applications on the device, shall consist of a set of
sub-objects “DevApplicationClass” and “DevApplicationCodes”.
Sub-objects “DevApplicationClass” are of Boolean type; “True” means “available”; combinations are
allowed.

© BSI 06-1999 15
ENV 12018:1997

The “DevApplicationCodes” object shall consist of a set of coded data objects as defined in clause [Link].
The ASN.1 representation of these data objects is provided in Annex B, clause B.3.3.
[Link] The “Device Specific Directory” data object
The application specific tags of the objects stored on the device shall be contained in a separate object that
will be unprotected by any subsidiary security functions. This data object shall consist of a set of reference
tags (RefTag) related to the addressable objects available on the device. It shall not convey any other
meaning.
The object RefTag is defined in clause 6.4.2.
The ASN.1 representation of this data object is provided in Annex B, clause B.3.4.
[Link] The “Device Identification” data object
The object “Devidentification” shall provide the identification of the individual device and the various
parties involved in its manufacturing and issuing. It shall consist of coded data to represent the device
manufacturer, coded data to represent the device component manufacturer, coded data to represent the
personaliser of the device, a unique device serial number and the issuing date of the device.
The object “DevIdentification” shall be constructed as a set of sub-objects “deviceManufacturer”,
“deviceComponentManuf”, “devicePersonaliser”, deviceIdNo”, and “deviceActivationDate”.
The objects “deviceManufacturer”, “deviceComponentManuf”, and “devicePersonaliser” shall consist of
CodedData objects, as defined in clause [Link].
The object “deviceIdNo” shall consist of an octet string with a length comprised between 1 and 21
characters.
The optional object “deviceActivationDate” shall consist of a Date object, as defined in clause [Link] above.
The ASN.1 representation of these data objects is provided in Annex B, clause B.3.5.
6.3.3 Objects linking sites and persons
[Link] The “Healthcare Sites” data object
The “Health Care Sites” data object shall consist of a reference table of sites which are associated with
healthcare personnel who have recorded data on the device.
The “HealthCareSites” data object shall be constructed as a sequence of the sub-object “HeathCareSite”.
This data object “HealthCareSite” itself shall be constructed as a set of sub-objects “hcsCountry” (of
“Country” type), “hcsId” (a numeric string with a length of between & and 21 characters), “hcsName” (an
octet string of 15 characters), “hcsAddr” (of “Address” type), “hcsType” (CodedData), and “hcsTelecom” (of
“Telecom” type).
The ASN.1 representation of these data objects is provided in Annex B, clause B.4.
[Link] The “Healthcare Persons” data object
The “Healthcare Persons” data object shall contain a list of all healthcare persons (professionals and type
of personnel that have performed healthcare) recorded on the ICD or added data to it.
The “HealthCarePersons” data object shall consist of a sequence of the sub-object “HealthCarePerson”.
The data object “HealthCarePerson” itself shall be constructed as a set of “hcpCountry” (of “Country” type),
“hcpIdNo” (a numeric string with a length between 1 and 21 characters), “hcpName” (of “Fullname” type),
optionally “hcpRelationCode” (of “CodedData” type, a code that would indicate things like primary
responsible general practitioner, specialist, consultant, etc.), “hcpClass” (a sequence of booleans described
hereafter), optionally “hcpProfession” (a sequence of “hcpProfCode”, in order to allow for national codes
linking to exact definitions of various HCP groups), optionally “hcpEmploymentNo” (of BitString type),
optionally “hcpEmploymentData” (a sequence of “CodedData”).
The object “hcpClass” shall consist of a sequence of booleans indicating professions (doctor, dentist,
pharmacist, midwife, nurse, admin., professions allied to medicine, professions allied to dentistry,
professions allied to pharmacy, professions allied to nursing).
The ASN.1 representation of these data objects is provided in Annex B, clause B.5.
[Link] Linking of sites and healthcare persons: the “Site Mix Table” data object
The “SiteMixTable” data object provides the function of allowing multiple HCPs to be present at one site
or one HCP to be present at multiple sites without having the necessity of having duplicated data.

16 © BSI 06-1999
 ENV 12018:1997

The “SiteMixTable” data object shall consist of a sequence of “SiteMix” objects, each consisting of “HCSRef”
and “HCPRef” reference pointers pointing respectively at “HealthCareSites” and “HealthCarePersons”.
The ASN.1 representation of these data objects is provided in Annex B, clause B.6.
6.3.4 Coded data
Coded values are understood by reference to the coding scheme to which they apply. The general principle
in this European Prestandard is that it is not mandatory to use a particular coding scheme, unless
specified within this European Prestandard, when such codes act as parameters. One example is the
use of EN 23166:1994 for country codes.
When a coding scheme is exclusively specified within this European Prestandard no alternative coding
scheme shall be allowed. Any references to coding schemes not so specified may however be modified in the
future independent of the rest of the standard.
[Link] The “CodingSchemesUsed” data object
Coding schemes not specified within this European Prestandard may themselves be the subject of a
registration within the coding schemes procedure as defined in ENV 1068:1993 and shall then be
interpreted, if at all, in accordance with all conditions of that registration.
ENV 1068:1993 specifies a procedure for registration of coding schemes and the allocation of a healthcare
coding scheme designator (HCD). It is possible to reference both internationally registered coding schemes
and unregistered coding schemes as defined in clause 5 of ENV 1068:1993. The use of such private
CodeIdentifiers may however create the potential risk of ambiguity if a device should be used in an open
environment.
Code values from unregistered schemes (or registered schemes outside the scope of a particular
application) cannot be understood, unless the recipient of information is party to an agreement with the
originator to use additional or non registered coding schemes.
The data object “CodingSchemesUsed” shall consist of an ordered sequence of the sub-object
“CodingScheme”, which shall itself consist of a code identifier (an octet string of 6 characters), a code length
(of integer type), and an optional free text comment (an octet string with a length of between 1
and 20 characters).
The ASN.1 representation of this data object is provided in Annex B, clause B.7.1.
[Link] The “CodedData” data object
The data object “CodedData” shall include both a reference to coding schemes used and a code data value
as well as optional free text and shall be constructed as a set of the sub-objects “codingSchemeRef”,
“codeDataValue”, and optionally “codeDataFreeText”.
The object “codingSchemeRef” is a Ref Pointer pointing at a value that identifies a particular coding scheme
within the object coding schemes used. If CodingSchemeRef = 0 then the coding scheme is implicit in this
standard.
The data type “codeDataValue” has been defined to indicate the actual code value in a particular coding
Scheme. The length of “codeDataValue” is one OCTET and the following codeDataValues are
defined: “A” means “Administrative free text entry”, “C” means “Clinical free text entry”.
The ASN.1 representation of this data object is provided in Annex B, clause B.7.2
6.3.5 Attributes
[Link] Accessory attributes
The data object “AccessoryAttributes” shall consist of an ordered set of data that is essential to record an
audit trail regarding both the originator of the information and the means via which it arrives to the
recipient. It shall consist of:
Date1 which shall represent the time/date of data being communicated to the ICD across the interface;
Date2 which shall represent the time/date of data being available to the originator of the message;
Place1 which shall represent the identity/locator of the sender of the message and is linked with
“person1”;
Place2 which shall represent the identity/locator of the original author of the data;
Personid3 shall be either the code or representation of the person/device/system that provided the
information that was added to a system to become the data within the “message”;

© BSI 06-1999 17
ENV 12018:1997

SecurityLevels which shall be constructed according to the ASN.1 definition contained in B.8 and shall
represent the rights in relation to reading, writing, updating and erasing the data contained within the
data object to which these accessory attributes are attached.
CompressionMethodData shall be constructed according to the ASN.1 definition contained in B.8 and
shall consist of a ref pointer pointing at a defined compression methodology within a compression
methodology table. This represents the methodology applied to the data contained within the data
object to which the accessory attributes are attached.
Object security attributes.
The “AccessoryAttributes” data object shall be constructed as a set of the following optional data objects:
— “date1” and “date2” (of “Date” type);
— “place/Person1” and “place/Person2” (of “RefPointer” type);
— “personId3” (a set of “PersonCode” of RefPointer type, and free “PersonText” with a length of up
to 30 characters);
— and of “ObjectSecAttributes” (a set of “SecurityServices”).
The data objects “SecurityServices” shall each consist of a sequence of digital signatures, as well as
algorithms and keys for signature and encryption.
None of the above attributes is mandatory, however all are highly desirable. It is recommended that all
(with the possible exception of Personid3) should be delivered every time that the media/system allows. A
list of priorities in groupings follows and in principle should be followed as groups:
{Date1,Date2,Place1,Place2,Personid3,SecurityLevels, CompressionMethodData,ObjSecAttributes}
{Date1,Place1,Place2, SecurityLevels, CompressionMethodData,ObjSecAttributes}
{Date1,Place1,Place2, SecurityLevels, CompressionMethodData,ObjSecAttributes}
{Date1,Place2, SecurityLevels, CompressionMethodData,ObjSecAttributes}
{Date1, SecurityLevels, CompressionMethodData,ObjSecAttributes}
{SecurityLevels, CompressionMethodData,ObjSecAttributes}
{ObjSecAttributes}
NOTE This “AccessoryAttributes” data object can be associated to any other data object.
The ASN.1 representation of this data object is provided in Annex B, clause B.8.
[Link] Device and data security attributes
Data stored in intermittently conected devices in health care may be personally sensitive. For this reason
this European Prestandard provides a series of security attributes in the form of data objects that may be
required for the provision of security functions. The actual data content (value) is not within the scope of
this standard, nor are the mechanisms that make use of these data elements. It is emphasised that the
security attributes cannot satisfy given security requirements without the implementation of the
appropriate security functions and mechanisms within the ICD.
READ — Always
— Never
— Protected
— With ICD holders’agreement
— With external authentication (for instance: card issuer, health care professional, ...)
— In relation to the originator only

WRITE — Protected
— With ICD holders’agreement
— With external authentication
— Never

UPDATE — Protected
— With external authentication
— With ICD holders’agreement
— In relation to the originator only
— Never

18 © BSI 06-1999
 ENV 12018:1997

ERASE — Protected
— With external authentication
— With ICD holders agreement
— In relation to the originator only
— Never
Following these principles a matrix of possibilities represents data access conditions:
PROTECTED

ALWAYS HOLDER EXTERNAL ORIGINATOR NEVER

AGREEMENT AUTHENTICATION ONLY

READ
WRITE
UPDATE
ERASE

Such rights of “access” are attributable to specific individuals with respect to discrete data items. These
rights will be defined by application developers and can be controlled by automated systems such as health
care professional cards. The rights may be defined at the application level thereby providing application
and potential country specificity.
The “SecurityServices” data object provides for the storage of data required to deliver these security
functions and mechanisms. These data can be “attached” to individual data elements thereby preserving
the original author’s security requirements when the data object is transferred between different forms of
ICD. This mechanism may therefore ensure that in the process of transferring data from active to passive
media and then back to active media, the original security requirements are re-generated. This ability also
allows exact replication of an ICD such as on regeneration after failure.
6.4 Link associations between objects
The following reference objects may be associated with other information objects defined. This relation is
a not an aggregation. The reference object is not a part of the information object but stays independent and
may be referenced by several objects.
The concept used within this European Prestandard is to reference (point at) the appropriate record person
as well as a healthcare provider and relevant accessory attributes.
These linkages add value to the data and may be used to provide context specificity.
6.4.1 The “RecordPersonPointer” data object
The data object “RecPersPointer” is used to reference one of the record persons stored in the
“RecordPersons” data object and shall be of integer type.
The ASN.1 representation of this data object is provided in Annex B, clause B.9.1.
6.4.2 The “ReferencePointer” and “ReferenceTag” data objects
A general reference pointer is defined in this European Prestandard as an ordered list of tags pointing to
the object or sub-object that is referenced.
The data object “RefPointer” shall consist of a sequence of “RefTag” (of integer type).
The “RefTag” is the APPLICATION SPECIFIC tag of the object as defined in this European Prestandard.
The following “RefTag”s specify the CONTEXT SPECIFIC tags in increasing depth.
The ASN.1 representation of this data object is provided in Annex B, clause B.9.2.
6.4.3 The “Linkages” data object
The “Linkages” object is used to create linkages between any objects. It shall be constructed as a sequence
of sub-objects “Link”.
The data object “Link” shall consist of a sequence of references to other objects in the form of a sequence of
“RefPointer” objects. This is pointed to by a “LinkagePointer” object.
The ASN.1 representation of this data object is provided in Annex B, clause B.9.3.

© BSI 06-1999 19
ENV 12018:1997

6.5 Data from ICDs held by healthcare persons

Data objects from ICDs held by healthcare persons shall provide for the functions of identification, access
control and signature. These functions are provided by a discrete number of sub-objects.
The identification information related to a healthcare person and his or her responsible agency shall be
provided by the data object “HcpData”. This “HcpData” data object shall be constructed as an implicit
sequence of health care person identification data, of healthcare site location data, and of optional accessory
attributes.
The ASN.1 representation of this data object is provided in Annex B, clause B.10.

7 Basic identification and administration data

This clause defines a number of identification and administrative data objects that are always associated
with a record person as defined in clause 6.
7.1 The “Variable Identification Data” object
The variable identification data object shall consist of a sequence of identification data that relates to the
respective record person in the record persons object.
The “VariableIdData” object shall be constructed as a sequence of “RecPersVariableID” data objects.
The “RecPersVariableID” data object shall consist of a set of the following optional sub-objects:
— “Address” (of “Address” type);
— “PreviousAddresses” (a sequence of “Address”);
— “Telecom” (of “Telecom” type);
— “Preferred Languages” (of “CodedData” type);
— “MaidenName”, “PreviousSurname”, and “OtherNames” (of “Surname” type as defined in [Link]);
— and “AccessoryAttributes” (see clause 6.3.5).
The ASN.1 representation of this data object is provided in Annex B, clause B.11.
7.1.1 The “Address” data object
The “Address” data object shall not include the elements of data used to represent either the post code or
country. It shall consist of two components:
— an object containing data that used in combination with both the post code and country code shall
represent the internationally agreed form of postal address (“PostAddr”, an octet string with a length of
between 1 and 35 characters);
— an optional object containing data that is location specific that is appropriate for the purposes of
healthcare, being an extension of the basic postal address (“ExtHcareAddr”, an octet string with a length
of between 2 and 175 characters).
NOTE Within the data string a standard separator of star (*) shall be utilised which shall be appended to the start of the successive
data element. In some applications this may produce the physical effect of line feed. This separator shall be present before the last
data element even if there is only a single element.
The ASN.1 representation of this data object is provided in Annex B, clause B.11.1.
7.1.2 The “Record Person Telecom” data object
The “RecordpersonTelecom” data object is of “Telecom” type as defined in clause [Link].
The ASN.1 representation of this data object is provided in Annex B, clause B.11.2.
7.1.3 The “Preferred Languages” data object
The record person preferred languages object shall allow for up to four languages spoken and/or understood
in a sequence determining the order of preference. Languages shall be coded according to ISO 639:1988.
The “PreferredLanguages” data object shall be constructed as a sequence of up to four “Language”
sub-objects in order of preference, each language being designated by a proper code (i.e. an octet string with
a length of three characters).
The ASN.1 representation of this data object is provided in Annex B, clause B.11.3.

20 © BSI 06-1999
 ENV 12018:1997

7.1.4 The “Maiden Name” data object

The “Maiden Name” data object shall contain a sub-object “Surnames” that represents the name of the
individual prior to marriage.
It shall be constructed as a set of sub-object “MaidenSurname” (of “Surnames” type), and optional
“AccessoryAttributes” (as defined in clause 6.3.5).
The ASN.1 representation of this data object is provided in Annex B, clause B.11.4.
7.1.5 The “Previous Surnames” data object
The “Previous Surnames” data object shall contain a sub object as defined in “Surnames” that represents
the surname of the individual prior to the one in current usage.
It shall be constructed as a set of sub-object “PreviousSurname” (of “Surnames” type as defined in
clause [Link]), and optional “AccessoryAttributes” (as defined in clause 6.3.5).
The ASN.1 representation of this data object is provided in Annex B, clause B.11.5.
7.1.6 The “Other Names” data object
The “OtherNames” data object shall contain a set of sub objects as defined in “Fullname” that represent the
different names that records identified and linked with this individual may contain.
It shall be constructed as a set of sub-object “OtherSurname” (of “Fullname” type, as defined in
clause [Link] above), and optional “AccessoryAttributes” (as defined in clause 6.3.5).
The ASN.1 representation of this data object is provided in Annex B, clause B.11.6.
7.2 The “Record Person Post Code” data object
The “PostCode” data object shall be a separate object from “Address”. It may thus be software manipulated
to different positions in printed/visually represented data according to local environment rules. It may also
be used for other purposes than mailing to indicate roughly the location of residence, e.g. for
epidemiological purposes.
The object “RecPersPostCode” shall be constructed as a set of “PersPostCode” (of “PostCode” type, as
defined in clause [Link]), and “PostcodePointer” (of “RecPersPointer” type, as defined in clause 6.4.1).
The ASN.1 representation of this data object is provided in Annex B, clause B.12.
7.3 The “Record Person Country” data object
The “RecPersCountry” data object shall be a separate object from “Address”. It may thus be software
manipulated to different positions in printed/visually represented data according to local environment
rules. It may also be used for other purposes than mailing to indicate roughly the location of residency.
The “RecPersCountry” data object shall be constructed as a set of “PersCountry” (of “Country” type, as
defined in clause [Link]), and “PersCountryPointer” (of “RecPersPointer” type, as defined in clause 6.4.1).
The ASN.1 representation of this data object is provided in Annex B, clause B.13.
7.4 The “Contact Persons” data object
The “ContactPersons” data object shall contain data relating a sequence of “persons to contact in
emergency” in relationship to an individual, in order of preference, with a possibility of indicating the
relationship in a free text comment.
The “ContactPersons” data object shall be constructed as a set of sub-objects “ContactPerson” and
“RecPersPointer” (the latter of “RecPersPointer” type, as defined in clause 6.4.1).
The “ContactPerson” object shall itself consist of a set of sub-objects “Name” (of “Fullname” type, as defined
in clause [Link]), “ContactTelno” (of “Telecom” type, as defined in clause [Link]), and optionally
“Comment” (an octet string with a length of up to 20 characters).
The ASN.1 representation of this data object is provided in Annex B, clause B.14.
7.5 The “Record Person Visiting Instructions” data object
The function of this object, which may have separate security attributes from the other objects, is to convey
information that is not contained in either the object PostalAddress or ExtHCAddress to aid a healthcare
worker arrive at a physical location, e.g. “even though its number1 Marston Crescent the entrance is
actually round the back in Windsor Square”.

© BSI 06-1999 21
ENV 12018:1997

The “RecPerVisitInstr” data object shall contain data that adds value to an address. This shall be a
separate object with a pointer to the address to which it relates.
The “RecPerVisitInstr” data object shall be constructed as a set of sub-objects “visitInstr” (an octet string
with a length of up to 80 characters), “visitPointer” (of “RecPersPointer” type as defined in clause 6.4.1),
and optional “AccessoryAttributes” (as defined in clause 6.3.5).
The ASN.1 representation of this data object is provided in Annex B, clause B.15.
7.6 The “Payment Provisions” data object
The “Payment provisions” data object shall cover a generic term that will include both insurance schemes
and national or other public healthcare payment systems.
There may be several instances of “Payment provisions” each of them with one payment body, which is the
term used to include insurance companies and other organisations which pay for healthcare delivery.
There may be a number of policies for each payment body. The policy conditions can cover several persons,
each with a set of conditions.
As an example the information contained in this object allows the storage of the information stated on the
official E 111 document held by any EU citizen travelling outside his/her member state (though within EU)
as enacted within Article 22 1(a) Council Regulation 1408/71.
The “PaymentProvisions” data object shall consist of a sequence of sub-objects “PaymentProvision”.
The “PaymentProvision” data object shall itself consist of a set of sub-objects:
— “PaymentBodyID”;
— optionally “PaymentBodyName” (an octet string with a length of up to 20 characters),
“PaymentBodyAddress” (a sequence of “Address”, “PostCode”, and “Country” as defined in
clauses [Link] to [Link], and “PaymentBodyTelecom” (of “Telecom” type, as defined in clause [Link]).
— “Policies”;
— and optionally “AccessoryAttributes” (as defined in clause 6.3.5).
The “PaymentBodyID” data object shall consist of a sequence of sub-objects “PaymentBodyCountry” (of
“Country” type as defined in clause above), and “PaymentBodyNumber” (an octet string with a length
comprised between 1 and 9 characters). “PaymentBodyCountry” represents the country of the payment
body number; the country of address may be different.
The “Policies” data object shall consist of a set of sub-objects “Policy”.
The “Policy” data object itself shall consist of a set of sub-objects “PolicyIdNo” (an octet string with a length
of up to 21 characters), “Member” (optional, an octet string with a length of up to 15 characters), and
“CoveredPersonConditions” (a set of sub-objects “PersonCondition”); the term “condition” is to be
understood in the sense of “conditions of cover” and not “medical condition”.
The “PersonCondition” data object shall consist of a sequence of sub-objects “RecPersPointer” (as defined
in clause 6.4.1), and “Condition”.
The “Condition” data object shall itself consist of a sequence of the following sub-objects:
— “ObligatoryStatus” (optional, boolean, “true” meaning “obligatory”);
— “CareCoverageCode” (optional, a set of “CoverageCode” of “CodedData” type as defined in
clause [Link]); CoverageCode will include (but is not limited to) surgical care, accident, occupational
disease, occupational accident, pregnancy, long term disease;
— “CareCoverageText” (optional, an octet string with a length of up to 20 characters);
— “CoverageAreas” (optional, a set of “CoveredCountries”, being themselves of “Country” type as defined
in clause [Link]);
— “PaymentLevel” (a sequence defined hereafter);
— “StartDate” (optional, of “Date” type as defined in clause [Link]);
— “EndDate” (optional, of “Date” type as defined in clause [Link]);
— “AccessoryAttributes” (optional, as defined in clause 6.3.5).
The “PaymentLevel” data object shall consist of a sequence of optional sub-objects:
— “LowerLimitCoverage” (of “Money” type), the value above which provisions are valid;
— “UpperLimitCoverage” (of “Money”), the value under which provisions are valid;

22 © BSI 06-1999
 ENV 12018:1997

— “BenefitsRate” (of “real” type), percentage of coverage;

— “SetPrice” (of “boolean” type, “true” means a SetPrice fixed for the service);
— “SetPriceValue” (of “Money” type);
— “ThirdParty” (of “boolean” type, “true” means the payment body pays directly);
— “EmploymentStatus” (a set of optional boolean sub-objects “Employed”, “SelfEmployed”,
“EmployedPensionable”, and “SelfEmployedPensionable”, “true” means status applicable according to
EU E111 form);
— “AuthorisationReq” (of “boolean” type, “true” means authorisation by payer required).
The ASN.1 representation of this data object is provided in Annex B, clause B.16.
7.7 The “Patient Payments” object
The “PatientPayments” data object shall contain data related to the fees actually paid by the patient for
healthcare services recorded on the device.
It shall be constructed as a set of sub-objects “IdPatientPayment” (of “RecPersPointer” type),
“PatientAccPayment” (of “Money” type), “PatientCarePayments” (a sequence of sub-objects
“PatientCarePayment”, each consisting of a set of “ProcedureRef” of “RefPointer” type, a pointer to the
procedure that was paid for, and of “ProcedureAmount” of “Money” type), and optionally
“AccessoryAttributes” (as defined in clause 6.3.5).
The ASN.1 representation of this data object is provided in Annex B, clause B.17.
7.8 The “Other Coded Administrative Data” object
This object shall make possible the use of any particular coding system permitted by the application, as
registered under the registration system described by ENV 1068:1993, as described in clause 6.3.4.
The “OtherCodedAdminData” data object shall consist of a sequence of sub-objects “AdmDat”.
The “AdmDat” data object itself shall consist of a set of sub-objects “IDPatientCodedData” (of
“RecPersPointer” type), “AdmCodedData” (of “CodedData” type), “AdminMoney” (of “Money” type),
“AdmRefPointer” (of “LinkagePointer” type, a pointer to the “Link” element in the “Linkages” reference
table), and optionally “AccessoryAttributes” (as defined in clause 6.3.5).
The ASN.1 representation of this data object is provided in Annex B, clause B.18.

8 Clinical data
This generic model for the storage of clinical data follows the same general structure as the storage of coded
administrative data as described above.
8.1 The “Clinical Coded Data” object
The “ClinicalCodedData” data object shall be constructed as a sequence of sub-objects “ClinDat”.
The “ClinDat” data object shall consist of a set of sub-objects “IDPatientCodedData” (of “RecPersPointer”
type), “ClinCodedData” (of “CodedData” type), “Parameter” (a choice of optional data objects to be defined
and described in clause 8.2), “ClinRefPointer” (of “LinkagePointer” type, a pointer to the “Link” element in
the “Linkages” reference table), and optionally “AccessoryAttributes” (as defined in clause 6.3.5).
The ASN.1 representation of this data object is provided in Annex B, clause B.19.
8.2 The “Parameter” data objects
The “Parameter” data objects are designed to be attached to a “ClinicalCodedData” data object, and by their
content they add value to that coded data. The “Parameter” data objects are distinct and their content vary
dependant upon their function: they define a structure and a set of rules related to this content.
8.2.1 The “Medication Note” parameter object
A “Medication Note” parameter object shall consist of a set of coded data consisting of:
“GenericMedCode”, coded data that shall represent the GENERIC name of the medicine as distinct
from either its proprietary or chemical name (e.g. ATC code);
“ProprietaryMedCode”, coded data that shall represent the proprietary name of the medicine;
“DosageInstructionsCode”, coded data that shall represent the dosage instructions;

© BSI 06-1999 23
ENV 12018:1997

“PatientAdviceCode”, coded data that shall represent general advice regarding the medicine to be
conveyed to the patient.
NOTE The “ClinCodeData” object itself can also specify the literal proprietary name.
The ASN.1 representation of this data object is provided in Annex B, clause B.20.1.
8.2.2 The “Medication Prescription” parameter object
A “Medication Prescription” parameter object shall consist of a set of coded data consisting of:
“GenericMedCode”, coded data that shall represent the GENERIC name of the medicine as distinct
from either its proprietary or chemical name (e.g. ATC code);
“ProprietaryMedCode”, coded data that shall represent the proprietary name of the medicine;
“Strength”, a sequence of “NoStrengthUnits” of Real type, and “StrengthUnits” of coded data, that shall
represent the number of units and the nature of the units used to measure the strength of the medicine;
“Form”, coded data that shall represent the form of a medicine;
“DosageInstructionsCode”, coded data that shall represent the dosage instructions;
“PatientAdviceCode”, coded data that shall represent general advice regarding the medicine to be
conveyed to the patient;
“Iterations”, a numeric string that shall have the default value of 1 and shall represent the number of
times the quantity may be dispensed;
“QuantityToDispense”, a set of “DaysSupply” (of numeric string type), “NoDispenseUnits” (of real type),
and “DispenseUnits”, a choice of several boolean type objects (“TabletCaps” including suppositories,
vagitories and other forms of special “tablets” that may be sold as an arbitrary number of individual
entities, “Packages”, “Grams”, “Milligrams”, “Litres”, “Millilitres”, “IntlUnits”, and “Special”);
“ReimbursementInfo”, coded data that shall represent information about the level of reimbursement of
the considered medicine.
NOTE The “ClinCodeData” object itself can specify the specific proprietary name and also form, strength and package amount. In
this case the specially tagged objects for this information may be omitted.
The ASN.1 representation of this data object is provided in Annex B, clause B.20.2.
8.2.3 The “Medication Administered” parameter object
A “Medication Administered” parameter object shall consist of a set of coded data consisting of:
“GenericMedCode”, a code that represents the GENERIC name of the medicine as distinct from either
its proprietary or chemical names (e.g. ATC code);
“ProprietaryMedCode”, coded data that shall represent the proprietary name of the medicine;
“Strength”, a sequence of “NoStrengthUnits” of Real type, and “StrengthUnits” of coded data, that shall
represent the number of units and the nature of the units used to measure the strength of the medicine;
“Form”, coded data that shall represent the form of a medicine;
“DosageInstructionsCode”, coded data that shall represent the dosage instructions;
“PatientAdviceCode”, coded data that shall represent general advice regarding the medicine to be
conveyed to the patient;
“QuantityAdministered”, a set of “NoDispenseUnits” (of real type), and “DispenseUnits”, a choice of
several boolean type objects (“TabletCaps” including suppositories, vagitories and other forms of special
“tablets” that may be sold as an arbitrary number of individual entities, “Packages”, “Grams”,
“Milligrams”, “Litres”, “Millilitres”, “IntlUnits”, and “Special”).
“Batchidentifier (of Octectstring type), optional, to identify the production batch to which the
medication belongs to.
NOTE The “ClinCodeData” object itself can specify the specific proprietary name and also form, strength and package amount. In
this case the specially tagged objects for this information may be omitted.
The ASN.1 representation of this data object is provided in Annex B, clause B.20.3.

24 © BSI 06-1999
 ENV 12018:1997

8.2.4 The ”Medication Dispensed” parameter object

A “Medication Dispensed” parameter object shall consist of a set of “MedicationDispensedActual” that shall
itself consist of:
a code that represents the actually dispensed medicine. This may be given in two forms, the specific
code similar to the ClinCodeData of a prescription note or by “GenericMedCode”, a code that represents
the GENERIC name of the medicine as distinct from either its proprietary or chemical names (e.g. ATC
code);
“ProprietaryMedCode”, coded data that shall represent the proprietary name of the medicine;
“Strength”, a sequence of “NoStrengthUnits” of Real type, and “StrengthUnits” of coded data, that shall
represent the number of units and the nature of the units used to measure the strength of the medicine;
“Form”, coded data that shall represent the form of a medicine; form and strength need only to be
present if it differs from original prescription;
“DosageInstructionsCode”, coded data that shall represent the dosage instructions: this item shall only
be recorded if dosage is different from the linked prescription;
“PatientAdviceCode”, coded data that shall represent general advice regarding the medicine to be
conveyed to the patient: this item shall only be recorded if advice is different from prescription;
“QuantityDispensed”, a set of “NoDispenseUnits” (of real type), and “DispenseUnits”, a choice of
several boolean type objects (“TabletCaps” including suppositories, vagitories and other forms of special
“tablets” that may be sold as an arbitrary number of individual entities, “Packages”, “Grams”,
“Milligrams”, “Litres”, “Millilitres”, “IntlUnits”, and “Special”).
“DispenseByID” (of “HcpRefPointer” type as defined in clause above), data to enable the identification
of the dispensing agency;
“DispenseDate” (of “Date” type as defined in clause above), to identify the date when the medicine has
been dispensed;
“DispensePrice” (of “Money” type), optional data to identify the cost of the medicine;
“DispensePaid” (of “Money” type), optional data to identify the price the patient actually paid to receive
the dispensed medicine.
“DispensingIdentifier” (of “Octectstring” type), optional: where the application requires additional
checks for certain classes of drugs (e.g. narcotics) this identifier indicates for reconciliation purposes
quantities supplied to, delivered by, the pharmacist.
“Batchidentifier (of Octectstring type), optional, to identify the production batch to which the
medication belongs to.
The ASN.1 representation of this data object is provided in Annex B, clause B.20.4.
8.2.5 The “Drug Sensitivity” parameter object
A “Drug Sensitivity” parameter object shall indicate that the record person is allergic to the product
represented by the coded data. It shall consist of CodedData used to represent the sensitivity type
i.e. “rash” and optional free text.
The ASN.1 representation of this data object is provided in Annex B, clause B.20.5.
8.2.6 The “Laboratory Test Results” parameter object
A “Laboratory Test Results” parameter object shall consist of a set of “Results” sub-objects appropriate to
the information imparted by the code to which it is attached.
The “Results” object shall contain data that presents:
“TimeSample” (UTC time), the time of collection of the sample;
“LabResult” (of “LabValue” type as defined hereafter), the laboratory value of the result;
“NormalRange” (of boolean type, “true” meaning “normal” and “false” meaning “therapeutic interval”),
data to record the reference range of the laboratory;
“RefLowerLimit” (of “LabValue” type as defined hereafter), optional;
“RefUpperLimit” (of “LabValue” type as defined hereafter), optional.
The “LabValue” type shall be defined as a set of “Units”, coded data that represent the units of
measurements, and of “Value” (of real type).

© BSI 06-1999 25
ENV 12018:1997

The ASN.1 representation of this data object is provided in Annex B, clause B.20.6.
8.2.7 The “Digital Binary Data” parameter object
A “BinaryParam” parameter object shall consist of an octet string that can be used to represent any
additional type of digital data.
The ASN.1 representation of this data object is provided in Annex B, clause B.20.7.
8.2.8 The “Request” parameter object
A “Request” parameter object shall consist of a set of preferred date and planned date.
The ASN.1 representation of this data object is provided in Annex B, clause B.20.8.
8.2.9 The “Diagnosis” parameter object
A “Diagnosis” parameter object shall consist of a set of five booleans denoting the status of the diagnostic
label, the true value stating the designation of the diagnosis with respect to:
— unconfirmed or suspected;
— confirmed by tests;
— given on admission of patient to hospital or clinic;
— given at discharge of patient from hospital or clinic;
— and principal diagnosis.
The ASN.1 representation of this data object is provided in Annex B, clause B.20.9.
8.2.10 The “Procedures” parameter object
A “Procedures” parameter object shall consist of a set of coded data. The structure of the “CodedData” type
allows for this “Procedures” parameter object to designate the procedures either by a registered code,
e.g. OPCS-4 (“ProcedureCode”) or by a free text label (“GenericProcedureCode”).
The ASN.1 representation of this data object is provided in Annex B, clause B.20.10.
8.3 The limited emergency data set
An object “LimEmergencyData” shall consist of a set of data consisting of “EmergencyDataBitMap”, a
sequence of booleans, within which the status “true” shall indicate the presence of the condition in the
record person, or in the case of a medication that the record person may be taking this medication, plus the
optional element “AccessoryAttributes”. This object is intended to convey the majority of the fixed clinical
data set defined within the European emergency health record.
The conditions specified are the following:
— asthma;
— heart disease;
— epilepsy fits;
— neurological disorder;
— haemophilia;
— clotting disorder;
— diabetes;
— glaucoma;
— dialysis treatment;
— transplant;
— missing organ;
— pacemaker in situ;
— antipsychotic medication;
— anticonvulsants;
— antiarrythmics;
— blood pressure drugs;
— anticoagulants;
— antidiabetic agents;

26 © BSI 06-1999
 ENV 12018:1997

— antihistamines.
The ASN.1 representation of this data object is provided in Annex B, clause B.21.

9 Specific ICDs security services related data objects

All the security service objects required to deliver security related to patient data held on and transmitted
by ICDs shall be constructed according to the following definitions.
9.1 Patient devices security related data
Patient held ICDs may require the following security services:
— verification of the ICD holder;
— authentication of the ICD holder;
— authentication of the “entity” attempting to access data contained in the ICD.
These services shall be provided by the objects:
— ICD-holder verification
and its associated data ICDHolderVer;
— ICD-Authentication
and its associated DevAuthenticateData;
— ICD-Authenticating HCP-class for access control
and its associated HCPAuthenticateData.
The ASN.1 representation of this data object is provided in Annex B, clause B.22.1.
9.2 Healthcare persons devices security related data
ICDs used by Healthcare Persons may have these security mechanisms and its associated data:
— ICD-holder verification
and its associated data ICDHolderVer;
— HCP-Class Authentication by Patient held ICDs
and its associated PatientICDAccessData;
— HCP-Individual Authentication
and its associated IdAuthenticateData;
— Digital signature Generation
and its associated SignFunctionData
and its associated HCPAuthenticateData.
All these security service objects shall be constructed according to the definitions below.
The ASN.1 representation of this data object is provided in Annex B, clause B.22.2.
9.2.1 Healthcare persons access keys: the “PatientICDAccessData” data object
Each healthcare person (HCP) or individual shall have up to three HcpAccess keys for international use,
and three for national use. These keys shall not correspond to the HcpClass data. Such keys may also have
the function of being access keys to data on other devices or systems than ICDs.
NOTE The corresponding secret keys shall be stored in a keyfile on the device where the position corresponds to the above keyID.
These keys are never transmitted over the interface described in this standard, but their presence is proven in the authentication
process.
The description of this object is included in Annex B, clause B.22.2.
9.2.2 Healthcare persons authentication key: the “IdAuthenticateData” data object
For HCP-individual authentication a public key encryption method shall be used with the private
authenticate key stored in a protected way on the device with a corresponding public key certificate openly
available. The description of a certificate as a data object included in Annex B, clause B.22.2, has been
derived from ISO/IEC 9594-8:1990.

© BSI 06-1999 27
ENV 12018:1997

9.2.3 Healthcare persons signature key: the “HCPSignFuncData” data object

For HCP-individual signature function a public key encryption method shall be used with the private
authenticate key stored in a protected way on the device and a corresponding public key certificate openly
available.
9.2.4 Healthcare persons authentication and signature public keys and certificate
The two keys described above in 9.2.2 and 9.2.3 shall have corresponding public keys with a signed
certificate by the appropriate authority.
These certificates shall be openly accessible. They shall be constructed according to ISO 9594-8:1990
(similar to CCITT X.509).
9.2.5 Object related security reference data
Shared data for the object related security services shall be contained within the objects “signature
algorithm IDs” and “Encryption Algorithm IDs”.
These security service objects shall be constructed according to the definitions contained in Annex B.8.
9.3 The “SecurityAttributes” data object
The “SecurityAttributes” data object shall be constructed according to the ASN.1 definitions contained in
Annex B.8.

28 © BSI 06-1999
 ENV 12018:1997

Annex A (informative)
General points about ASN.1 data objects representation
A representation of the data objects belonging to this European Prestandard is proposed hereafter in
informative annex using Abstract Syntax Notation One (ASN.1), of which normative references are:
ISO 8824:1990, Information technology — Open Systems Interconnection — Specification of Abstract
Syntax Notation One (ASN.1).
ISO 8825:1990, Information technology — Open Systems Interconnection — Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1).
A.1 ASN.1 definitions
A.1.1
asn.1 encoding rules
rules specifying the representation during transfer of the value of any ASN.1 type. [ISO 8824:1990]
A.1.2
bitstring type
a simple type whose distinguished values are an ordered sequence of zero, one or more bits [ISO 8824:1990]
A.1.4
boolean type
a simple type with two distinguished values. Possibilities are true or false [ISO 8824:1990]
A.1.5
co-ordinated universal time (UTC)
the time scale maintained by the Bureau international de l’heure (International Time Bureau) that forms
the basis of a co-ordinated dissemination of standard frequencies and time signals [ISO 8824:1990]
A.1.6
simple type
a type defined by directly specifying the set of its values [ISO 8824:1990]
A.1.7
structured type
a type defined by reference to one or more other types [ISO 8824:1990]
A.1.8
tag
a type denotation which is associated with every ASN.1 type [ISO 8824:1990]
A.1.9
tagging
replacing the existing (possibly default) tag of a type by a specified tag [ISO 8824:1990]
A.1.10
type
a named set of values [ISO 8824:1990]
A.1.11
type or value reference name
a name associated uniquely with a type or value within some context [ISO 8824:1990]
A.1.12
integer type
a simple type with distinguished values which are the positive and negative whole numbers including zero.
[ISO 8824:1990]
A.1.13
real type
a simple type whose distinguished values are members of the set of real numbers [ISO 8824]
A.1.14
octet string type
a simple type whose distinguished values are an ordered sequence of zero, one or more octets, each octet
being an ordered sequence of eight bits [ISO 8824:1990]

© BSI 06-1999 29
ENV 12018:1997

A.1.15
null type
a simple type consisting of a single value called null [ISO 8824:1990]
A.1.16
set type
a structured type, defined by referencing a fixed, unordered, list of distinct types (some of which may be
declared to be optional); each value in the new type is an unordered list of values, one from each of the
component types [ISO 8824:1990]
A.1.17
set of type
a structured type, defined by referencing a single existing type; each value in the new type is an unordered
list of zero, one or more values in the existing type [ISO 8824:1990]
A.1.18
sequence-of-type
a structured type defined by referencing a single existing type, each value of the new type being in an
ordered list of zero, one or more values of the existing type [ISO 8824:1990]
A.1.19
sequence type
a structured type, defined by referencing a fixed, ordered, list of types (some of which may be declared to
be optional); each value of the new type is an ordered list of values, one from each component type
[ISO 8824:1990]
A.1.20
value
a distinguished member of a set of values [ISO 8824:1990]
A.2 ASN.1 syntax
The ASN.1 syntax is used to build complex data objects that all are derived from a set of elementary types
that are defined in ASN.1. The elementary types used in this standard are:

— Integer Used for integer numerical values

— Boolean Used for logical variables that can have a value of TRUE or FALSE (yes-no)
— Octet String Used to represent a series (string) of octets (bytes) that may have any value.
It is mainly to represent character strings where the ISO 8859-1 (Latin-l) Character
set is used. In part two of this standard for clinical data additional types are used
such as REAL and BINARY STRING.
From these elementary types of UNIVERSAL CLASS, a set of derived generally useful types are defined
in this standard. These are only used as components to build specific constructed query objects and can not
be accessed separately.
Examples of this are:
— Date;
— Nameelement;
— Telephonenumber;
— CountryCode.
These elementary types are used to build constructed objects by aggregating several elementary objects in
various ways and be specialisation. The latter means that by assigning a specific tag to an object, this will
have a certain meaning e.g.

Birthdate 4 Date

Meaning a birthdate has the format of the general Date-type but in addition a specific connotation.

30 © BSI 06-1999
 ENV 12018:1997

A.3 The Tag-Length-Value format

An ASN.1 object generally has three components:

Tag Length Value

Tag is a label that is used to identify the object. It may be of several forms.
The Length component defines the length of the Value field. Generally ASN.1 objects have variable length
allowing for flexibility and application specific priorities. In this standard, however, a maximum length
allowed is defined for certain objects, to facilitate the interchange with application systems that could be
designed to be able to handle any ICD issued according to this standard.
Value is a field that may be of elementary type, e.g. an OCTET STRING. However, in case of constructed
aggregate objects frequently used in this standard, the value field may also contain an object. In this way
objects may be nested in many layers.
Constructed Object

Tag Length Value

TLV
T L V, T L V, T L V, T L V
TLV

A value field may contain a number of other objects as a SET or a SEQUENCE.

In order to analyse such an object to find a specific component, the system only needs to be able to interpret
the Tag-type and the Length of the nested objects.
A.4 The use of tags
The ASN.1 provides for four classes of tags, UNIVERSAL, APPLICATION, PRIVATE and CONTEXT
specific.
Universal tags are assigned by ISO to the elementary types used to construct derived types.
Application specific means tags as they are defined in a European Prestandard such as this and as used to
define the objects of ICDs in healthcare on the highest level.
Context specific tags are used within constructed objects to define the relative position. A sub-object that
is identified only by a context specific tag cannot be identified without reading the object in which it is a
part from the start until it appears.
Private tags may be assigned by a particular issuer or user group to identify objects that are not
standardised but may coexist on the same ICD as standardised Objects. However it is then up to the user
to make sure that no conflict of tag assignment occurs. Such objects cannot be used for wide inter system
or international interchange.
ASN.1 does allow for a series of tags assigned to the same object to show explicitly how it was constructed.
This principle is not utilised in this standard where only one level of context-specific tag is used for each
sub-object. The tags thus constitute a hierarchical structure, from the APPLICATION specific top level.
Tag level:

0 1 2 3 4 5
Application Context level 1 Context level 2 Context level 3 Context level 4 Context level 5 etc.
A.5 Examples of using the Basic Encoding Rules for use with ASN.1 for objects in this standard
Example: Firstnames value assignment:
{Firstname “ANNA”, preferred firstname “GERTRUD”, Firstname “MARIA”}
Encoded format
Firstnames tag class context specific e.g. 129
Preferred firstname tag class context specific e.g. 130

© BSI 06-1999 31
ENV 12018:1997

[Application] length contents

[octet string] length contents

129 4 “ANNA”
130 7 “GERTRUD”
129 5 “MARIA”
Address Example

{Postaddr “Wyntroyd*Howbrook*[Link]”,
ExtHealthCareAddr“Wyntroyd Farm*Hollinberry Lane*Howbrook*High Green*Nr
Sheffield*[Link]”
}
Encoded Format
Address tag class application specific e.g. xxx
Postaddr tag class application specific e.g. yyy
ExtHealthCareAddr tag class application specific e.g. zzz

[Application tag]Length Contents

[octet string] length Contents
yyy 33 “Wyntroyd*Howbrook*[Link]”
zzz 73 “Wyntroyd Farm*Hollinberry Lane*Howbrook*High
Green*Nr Sheffield*S. Yorks”

Annex B (normative)
ASN.1 representation of data objects in this European Prestandard
Annex B takes precedence over any other clause of this European prestandard which may state or imply
contradictory descriptions of data objects.
This normative annex defines using ASN.1 notation the contents of the data objects and their structure.
The storage and transmission methodology to be used is outside the scope of this European Prestandard.
B.1 Basic Data Objects for Referencing
B.1.1 Person Name related data objects
The plain text definition of these objects is provided in normative clause 6.2.1.

Fullname 4 SEQUENCE
{ Title OPTIONAL,
Surnameprefix OPTIONAL,
Surnames,
Surnamesufix OPTIONAL
Forenames
}

{
Title [0] 4 OCTET STRING OPTIONAL (SIZE(1..7)),
Surnameprefix [1] 4 OCTET STRING OPTIONAL (SIZE(2..15)),
Surnames [2] 4 SEQUENCE OF SIZE(1..2),
CHOICE {Surname,PreferredSurname}
-- maximum two surnames
{
Surname [0] 4 Nameelement,

32 © BSI 06-1999
 ENV 12018:1997

PreferredSurname [1] 4 Nameelement,

}
Surnamesufix [3] 4 OCTET STRING OPTIONAL (SIZE(2..15)),
Forenames [4] 4 SEQUENCE OF SIZE(1..3),
CHOICE {Firstname,PreferredFirstname)
-- maximum three firstnames
{
Firstname [0] 4 Nameelement,
PreferredFirstname [1] 4 Nameelement,
}
}
Nameelement 4 OCTET STRING (SIZE(2..27)),
B.1.2 Address and Telecommunication related data objects
The plain text definition of these objects is provided in normative clause 6.2.2

PostCode 4 OCTET STRING (SIZE(1..8))

PostAddr 4 OCTET STRING (SIZE(1..35))

Country 4 NumericString (SIZE(3))

-- EN 23166

Date 4 UTC Time (Size (6..12))

Place 4 OCTET STRING(SIZE(0..15))

Telecom 4 SET
{
TelnoRecpersonHome [0] Telno OPTIONAL,
TelnoRecpersonwork [1] Telno OPTIONAL,
TelnoRecpersonother [2] Telno OPTIONAL,
FaxnoRecpersonhome [3] Telno OPTIONAL,
FaxnoRecpersonwork [4] Telno OPTIONAL,
X.400address [5] OCTET STRING OPTIONAL,
OtherNetworkAddress [6] OCTET STRING OPTIONAL
}

Telno 4 NUMERIC STRING (SIZE(1..15))

-- Countrycode, area code, local phone no
-- Countrycodes for tele, 1-3 digits CCITT E.163
-- Annex A
B.1.3 The “Money” data object
The plain text definition of this object is provided in normative clause [Link].

Money 4 SEQUENCE
{
Amount [0] INTEGER,
Currency [1] OCTET STRING (SIZE(3)) OPTIONAL
-- ISO 4217
}
B.2 Basic Data Objects
B.2.1 The “Record Persons” data object
The plain text definition of this object is provided in normative clause 6.3.1.

© BSI 06-1999 33
ENV 12018:1997

RecordPersons 4 [APPLICATION 8] SEQUENCE

{
MajorRecordPerson 4 [0] RecordPerson,
SEQUENCE OF CHOICE
{
spouse [1] RecordPerson,
child [2] RecordPerson,
father [3] RecordPerson,
mother [4] RecordPerson,
otherPerson [5] RecordPerson
}
}

RecordPerson 4 SET
{
MajorRecordldentifier,
AlternativeRecordIdentifiers OPTIONAL,
RecordIdVerification
}
B.2.2 The “Major Record Identifier” data object
The plain text definition of this object is provided in normative clause [Link].

MajorRecordIdentifier 4 [0] SEQUENCE

{ mII [0] NUMERIC STRING DEFAULT 80 (SIZE(2)),
issuerCountry [1] Country,
issuerIdentifier [2] NUMERIC STRING (SIZE(5)),
checkdigit [3] NUMERIC STRING (SIZE(1)),
-- Calculated according to Luhn
recordIdNumber [4] EvolRecordIdentifier
}

EvolRecordIdentifier 4 CHOICE
{
evolution1 [0] OCTET STRING (SIZE (1..21)),
evolution2 [1] OCTET STRING (SIZE (1..21)),
evolution3 [2] OCTET STRING (SIZE (1..21))
}
-- The Evolution1 type defines a RecordIdentifier that
-- has free format
-- The Evolution2 type defines a RecordIdentifier that
-- has only alphanumeric characters and the
-- separator “/”
-- The Evolution3 type defines a RecordIdentifier that
-- is all numeric with no separators
B.2.3 The “Alternative Record Identifiers” data object
The plain text definition of this object is provided in normative clause [Link].

AlternativeRecordIdentifiers 4 [1] SET OPTIONAL

{ SocialSecurityNo [0] RecordIdentifier OPTIONAL,
AlternativeNumbers [1] SEQUENCE OF RecordIdentifier
}

34 © BSI 06-1999
 ENV 12018:1997

B.2.4 The “Record Identification Verification” data object

The plain text definition of this object is provided in normative clause [Link].

RecordIdVerification 4 [2] SET

{ RecordPersonName [0] Fullname,
DateOfBirth [1] Date,
SexAtBirth [2] OCTET STRING (SIZE(1))
-- ISO 5218
PlaceOfBirth [3] Place
[4] AccessoryAttributes OPTIONAL
}
B.3 The “Device Specific Data” object
B.3.1 The “Device Data” object
The plain text definition of this object is provided in normative clause 6.3.2.

DeviceData 4 [APPLICATION 9] SET

{
Devtype OPTIONAL [0],
DevApplications OPTIONAL [1],
DevDirectory OPTIONAL [2],
DevIdentification OPTIONAL [3],
PatientDevSecurity OPTIONAL [4],
HCPDevSecurity OPTIONAL [5]
}
B.3.2 The “Device Type” data object
The plain text definition of this object is provided in normative clauses [Link] to [Link].

DevType 4 [0] SET

{ DeviceClass [0] CodedData,
DeviceStandard [1] CodedData,
DeviceSpec [2] CodedData
}
B.3.3 The “Device Applications” data object
The plain text definition of this object is provided in normative clause [Link].
DevApplications 4 [1] SET
{
DevApplicationClass [0] SEQUENCE
{
Identification [0] BOOLEAN,
Administrative [1] BOOLEAN,
Clinical [2] BOOLEAN,
Other [3] BOOLEAN
-- For these four objects, True means available
-- Combinations allowed.
}
DevApplicationCodes [1] SET OF CodedData
}
B.3.4 The “Device Specific Directory” data object
The plain text definition of this object is provided in normative clause [Link].
DevDirectory 4 [2] SET OF RefTag

© BSI 06-1999 35
ENV 12018:1997

B.3.5 The “Device Identification” data object

The plain text definition of this object is provided in normative clause [Link].
DevIdentification 4 [3] SET
{
deviceManufacturer [0] CodedData,
deviceComponentManuf [1] CodedData,
devicePersonaliser [2] CodedData,
deviceIdNo [3] OCTET STRING (SIZE(0..21),
deviceActivationDate [4] Date OPTIONAL
}
B.4 The “Healthcare Sites” data object
The plain text definition of this object is provided in normative clause [Link].
HealthCareSites 4 [APPLICATION 10] SEQUENCE OF HealthCareSite

HealthCareSite 4 SET
{ hcsCountry [0] Country,
hcsId [1] Numeric String (SIZE(1..21)) OPTIONAL,
hcsName [2] OCTET STRING (SIZE(15)),
hcsAddr [3] Address
hcsType [4] CodedData OPTIONAL,
-- This is a code that determines the type of
-- establishment i.e. Doctors Surgery, Clinic,
-- Hospital, Laboratory etc.
hcsTelecom [5] Telecom
}
B.5 The “Healthcare Persons” data object
The plain text definition of this object is provided in normative clause [Link].
HealthCarePersons 4 [APPLICATION 11] SEQUENCE OF HealthCarePerson

HealthCarePerson 4 SET
{
HCPCountry [0] Country
HCPIdNo [1] NumericString (SIZE(1..21)),
HCPName [2] Fullname,
HCPRelationCode [3] CodedData OPTIONAL,
-- This is a code that would indicate things like
-- Primary responsible General Practitioner
-- Specialist, consultant, etc.
HCPClass [4] Sequence of BOOLEAN
{
Doctor [0] BOOLEAN
Dentist [1] BOOLEAN
Pharmacist [2] BOOLEAN
Midwife [3] BOOLEAN
Nurse [4] BOOLEAN
Admin. [5] BOOLEAN
Professions allied to medicine [6] BOOLEAN
Professions allied to dentistry [7] BOOLEAN
Professions allied to pharmacy [8] BOOLEAN
Professions allied to nursing [9] BOOLEAN
},
hcpProfession [5] SEQUENCE OF HcpProfCode OPTIONAL,

36 © BSI 06-1999
 ENV 12018:1997

-- This will allow national codes for exact definitions

-- of various HCP groups.
hcpEmploymentNo [6] BitString OPTIONAL,
hcpEmploymentData [7] SEQUENCE OF CodedData OPTIONAL
}
B.6 Linking of sites and healthcare persons: the “Site Mix Table” data object
The plain text definition of this object is provided in normative clause [Link].
SiteMixTable 4 [APPLICATION 12] SEQUENCE OF SiteMix

SiteMix 4 SET
{
HCSRef 4 [0]RefPointer,
-- Pointer to HealthCareSite object
HCPRef 4 [1]RefPointer,
-- Pointer to HealthCarePerson object
}
B.7 Coded data and coding schemes
B.7.1 The “Coding Schemes Used” data object
The plain text definition of this object is provided in normative clause [Link].
CodingSchemesUsed 4 [APPLICATION 13] SEQUENCE OF CodingScheme

CodingScheme 4 SEQUENCE
{
codeIdentifier [0] OCTET STRING(SIZE 6)),
codeLength [1] INTEGER,
Comment [2] OCTET STRING(SIZE(1..20)) OPTIONAL }
}
B.7.2 The “Coded Data” data object
The plain text definition of this object is provided in normative clause [Link].
CodedData 4 SET
{
codingSchemeRef [0] RefPointer.
codeDataValue [1] OCTET STRING,
codeDataFreeText [2] OCTET STRING OPTIONAL
}
-- codingSchemeRef is a Ref Pointer pointing at a
-- value that identifies a particular coding scheme
-- within the object coding schemes used.
-- If CodingSchemeRef = 0 then the coding scheme
-- is implicit in this standard. The length of the
-- CodeDataValue is one OCTET and the following
-- CodeDataValues are defined: “A” = Administrative
-- free text entry, and “C” = Clinical free text entry
B.8 The “Accessory Attributes” data object
The plain text definition of this object together with its functions are provided in normative clause 6.3.5.
AccessoryAttributes 4 SET
{
date1 [0] UTC TIME (SIZE (6..12)) OPTIONAL,
date2 [1] UTC TIME (SIZE (6..12)) OPTIONAL
place/Person 1 [2] RefPointer OPTIONAL,
place/Person2 [3] RefPointer OPTIONAL,

© BSI 06-1999 37
ENV 12018:1997

personid3 [4] SET OPTIONAL

{
PersonCode [0]RefPointer,
PersonText [1] OCTETSTRING (SIZE(0..30))
},
SecurityLevelPointer [5] SecurityLevels OPTIONAL,
-- points to SecurityLevels table
CompressionMethod [6] CompressMethodData OPTIONAL,
-- points to CompressMethodData
ObjectSecAttributes [7] SET OF SecurityServices OPTIONAL
{
SecurityServices 4 SEQUENCE
{
signatureAlgorithmID [0] RefPointer
-- This points to the Algorithm Table
signatureKeyId [1] RefPointer,
-- This points to the Signature Key
DigitalSignature [2] BIT STRING,
EncryptionAlgorithmID [3] RefPointer,
-- This points to the Algorithm table
EncryptionKeyId [4] RefPointer
-- This points to the Encryption Key
}
}
}

SecurityLevels 4 SEQUENCE
{
ReadSecAttribute [0] SecAttData OPTIONAL
WriteSecAttribute [1] SecAttData OPTIONAL

UpdateSecAttribute [2] SecAttData OPTIONAL

EraseSecAttribute [3] SecAttData OPTIONAL
}

SecAttData 4 Sequence of Boolean

{
Always [0] True = Always available
Never [1] True = Never available
ExtAuth [2] True = Requires external authentication
HoldAg [3] True = Requires ICD Holder agreement
OrigAg [4] True = Can only be done by originator of data element
}

CompressMethodData 4 Set of CodedData

B.9 Link associations between objects
B.9.1 The “Record Person Pointer” data object
The plain text definition of this object is provided in normative clause 6.4.1.
RecPersPointer 4 INTEGER

38 © BSI 06-1999
 ENV 12018:1997

B.9.2 The “Reference Pointer” and “Reference Tag” data objects

The plain text definition of this object is provided in normative clause 6.4.2.
RefPointer 4 SEQUENCE OF RefTag

RefTag 4 INTEGER
-- This object can hold the ASN.1-tag of another object
B.9.3 The “Linkages” data object
The plain text definition of this object is provided in normative clause 6.4.3.
Linkages 4 [APPLICATION 22] SEQUENCE OF Link
-- This is a sequence of references to other objects

Link 4 SEQUENCE OF LinkagePointer

LinkagePointer 4 INTEGER
B.10 Data from ICDs held by healthcare persons
The plain text definition of this object is provided in normative clause 6.5.
HcpData 4 [APPLICATION 25] IMPLICIT SEQUENCE
{
HealthCarePerson [0],
HealthCareSite [1],
[2] AccessoryAttributes OPTIONAL
}
B.11 Basic ID & Administration Data
The plain text definition of these objects is provided in normative clause 7.1.
VariableIdData 4 [APPLICATION 14] SEQUENCE OF RecPersVariableID

RecPersVariableID 4 SET
{
Address [0]Address OPTIONAL,
PreviousAddresses [1] SEQUENCE OF Address OPTIONAL,
Telecom [2] Telecom OPTIONAL,
Preferred Languages [3] CodedData OPTIONAL,
MaidenName [4] OPTIONAL,
PreviousSurname [5]OPTIONAL,
OtherNames [6]OPTIONAL,
[7]AccessoryAttributesOPTIONAL
}
B.11.1 The “Address” data object
The plain text definition of this object is provided in normative clause 7.1.1.
Address 4 SEQUENCE

{
PostAddr [0] OCTET STRING (SIZE (1..35)),
ExtHcareAddr [1] OCTET STRING (size(2..175)) OPTIONAL
}
B.11.2 The “Record Person Telecom” data object
The plain text definition of this object is provided in normative clause 7.1.2.
RecordPersonTelecom 4 Telecom

© BSI 06-1999 39
ENV 12018:1997

B.11.3 The “Preferred Languages” data object

The plain text definition of this object is provided in normative clause 7.1.3.
PreferredLanguages 4 SEQUENCE SIZE(0..4) OF Language
-- up to four language codes in order of preference

Language 4 OCTET STRING(SIZE(3))

B.11.4 The “Maiden Name” data object
The plain text definition of this object is provided in normative clause 7.1.4.
Maiden name 4 SET
{
MaidenSurname [0]Surnames,
[1]AccessoryAttributes OPTIONAL
}
B.11.5 The “Previous Surnames” data object
The plain text definition of this object is provided in normative clause 7.1.5.
Previous surnames 4 [4]SET
{
PreviousSurame [0] Surnames,
[1]AccessoryAttributes OPTIONAL
}
B.11.6 The “Other Names” data object
The plain text definition of this object is provided in normative clause 7.1.6.
OtherNames 4 [5]SET
{
OtherName [0]Fullname,
[1]AccessoryAttributes OPTIONAL
}
B.12 The “Record Person Post Code” data object
The plain text definition of this object is provided in normative clause 7.2.
RecPersPostCode 4 [APPLICATION 15] SET
{
PersPostCode [0]PostCode,
Postcode Pointer [1]RecPersPointer
}
B.13 The “Record Person Country” data object
The plain text definition of this object is provided in normative clause 7.3.
RecPersCountry 4 [APPLICATION 16] SET
{
PersCountry [0]Country,
PersCountryPointer [1] RecPersPointer
}
B.14 The “Contact Persons” data object
The plain text definition of this object is provided in normative clause 7.4.
ContactPersons 4 [APPLICATION 17] SET
{
ContactPerson [0] 4 SET
{
Name [0] Fullname,
ContactTelno [1] Telecom,

40 © BSI 06-1999
 ENV 12018:1997

Comment [2] OCTET STRING(SIZE(0..20)) OPTIONAL

}
RecPersPointer [1] RecPersPointer,
[2]AccessoryAttributes OPTIONAL
}
B.15 The “Record Person Visiting Instructions” data object
The plain text definition of this object is provided in normative clause 7.5.
RecPersVisitInstr : 4 [APPLICATION 18] SET
{
visitInstr [0] OCTET STRING (SIZE(0..80)),
Visit Pointer [1] RecPersPointer,
[2]AccessoryAttributes OPTIONAL
}
B.16 The “Payment Provisions” data object
The plain text definition of this object is provided in normative clause 7.6.
PaymentProvisions 4 [APPLICATION 19] SEQUENCE OF PaymentProvision

PaymentProvision 4 SET
{
PaymentBodyID [0],
PaymentBodyName OPTIONAL [1],
PaymentBodyAddress OPTIONAL [2],
PaymentBodyTelecom OPTIONAL [3],
Policies [4],
AccessoryAttributes OPTIONAL [5]
}

PaymentBodyID 4 [1] SEQUENCE

{
PaymentBodyCountry [0] Country,
-- This represents the country of the Payment Body
-- Number; the country of PaymentBodyAddress may be
different
PaymentBodyNumber [1] OCTET STRING(SIZE(1..9))
}

PaymentBodyName 4 [2] OCTET STRING(SIZE(0..20)),

PaymentBodyAddress 4 [3] SEQUENCE

{ [0]Address,
[1]PostCode,
[2]Country
}
PaymentBodyTelecom 4 [4] Telecom

Policies 4 [5] SET OF Policy

Policy 4 SET
{
PolicyIdNo [0] OCTET STRING(SIZE(0..21)),
MemberNo [1] OCTET STRING(SIZE(0..15)) OPTIONAL,
CoveredPersonConditions [2] SET OF PersonCondition
}

© BSI 06-1999 41
ENV 12018:1997

PersonCondition 4 SEQUENCE
{
RecPersPointer [0] RecPersPointer,
Conditions [1] SET OF Condition
}

Condition 4 SEQUENCE
{
ObligatoryStatus OPTIONAL [0],
CareCoverageCode OPTIONAL [1],
CareCoverageText OPTIONAL [2],
CoverageAreas OPTIONAL [3],
PaymentLevel [4],
StartDate OPTIONAL [5],
EndDate OPTIONAL [6],
AccessoryAttributes OPTIONAL [7]
}

ObligatoryStatus 4 [0] BOOLEAN

OPTIONAL,
-- True means obligatory
CareCoverageCode 4 [1]SET OF CoverageCode OPTIONAL,
CareCoverageText 4 [2] OCTET STRING (SIZE(0..20) OPTIONAL,
CoverageAreas 4 [3] SET OPTIONAL
{
CoveredCountries [0] SET OF Country
}

PaymentLevel 4 [4] SEQUENCE

{
LowerLimitCoverage [0] Money OPTIONAL,
-- The Value above which provisions are valid
UpperLimitCoverage [1] Money OPTIONAL,
-- The value under which provisions are valid
BenefitsRate [2] REAL OPTIONAL,
-- Percentage of coverage
SetPrice [3] BOOLEAN OPTIONAL,
-- True means a SetPrice (fixed for the service
-- exists)
SetPriceValue [4] MONEY OPTIONAL,
ThirdParty [5] BOOLEAN OPTIONAL,
-- True means the payment body pays direct

EmploymentStatus [6] SET OPTIONAL,

{
Employed [0] BOOLEAN,
SelfEmployed [1] BOOLEAN,
EmployedPensionable [2] BOOLEAN,
SelfEmployedPensionable [3] BOOLEAN
}
-- True means status applicable according to EU
-- E111 form
AuthorisationReq [7] BOOLEAN OPTIONAL,

42 © BSI 06-1999
 ENV 12018:1997

-- True means authorisation by payer required.

}

StartDate 4 [5] Date OPTIONAL,

EndDate 4 [6] Date OPTIONAL
}

CoverageCode 4 CodedData,
-- CoverageCode shall include (but is not limited
-- to) Surgical Care, Accident, Occupational
-- Disease, Occupational accident, Pregnancy,
-- Long term disease
B.17 The “Patient Payments” data object
The plain text definition of this object is provided in normative clause 7.7.
PatientPayments 4[APPLICATION 20] SET
{
IdPatientPayment [0] RecPersPointer,
PatientAccPayment [1] Money,
PatientCarePayments [2] SEQUENCE OF PatientCarePayment,
[3] AccessoryAttributes OPTIONAL
}

PatientCarePayment 4 SET
{
ProcedureRef [0] RefPointer,
-- A pointer to the procedure that was
-- paid for
ProcedureAmount [1] Money
}
B.18 The “Other Coded Administrative Data” object
The plain text definition of this object is provided in normative clause 7.8.
OtherCodedAdminData 4 [APPLICATION 21] SEQUENCE OF AdmDat

AdmDat 4 SET
{
IDPatientCodedData [0] RecPersPointer,
AdmCodedData [1] Coded Data,
AdminMoney [2] Money,
AdmRefPointer [3] LinkagePointer
-- This is a pointer to the Link element in the
-- Linkages reference table,
[4] AccessoryAttributes OPTIONAL
}
B.19 The “Clinical Coded Data” object
The plain text definition of this object is provided in normative clause 8.1.
ClinicalCodedData 4 [APPLICATION 23] SEQUENCE OF ClinDat

ClinDat 4 SET
{
IDPatientCodedData [0] RecPersPointer,
ClinCodedData [1] CodedData,
Parameter [2] CHOICE OPTIONAL,

© BSI 06-1999 43
ENV 12018:1997

{
MedicationNoteParam [0],
MedicationPrescriptionParam [1],
MedicationAdministeredParam [2],
MedicationDispenseParam [3],
Drug SensitivityParam [4],
LabTestResultsParam [5],
BinaryParam [6],
RequestedParam [7],
DiagnosisParam [8],
ProceedureParam [9]
}
-- The structure of the parameter object will be
-- dependent upon the ClinCodeData and the
-- modifier
ClinRefPointer [3] LinkagePointer,
-- This is a pointer to the Link element in the
-- Linkages reference table,
[4] AccessoryAttributes
}
B.20 The “Parameter” data objects
The plain text definition of these data object are provided in normative clause 8.2.
B.20.1 The “Medication Note” parameter object
The plain text definition of this object is provided in normative clause 8.2.1.
MedicationNoteParameter 4[0] SET
{
GenericMedCode [0]Coded Data,
-- E.g. ATC-code
ProprietaryMedCode [1] CodedData,
DosagelnstructionsCode [2]CodedData,
PatientAdviceCode [3]CodedData
}
B.20.2 The “Medication Prescription” parameter object
The plain text definition of this object is provided in normative clause 8.2.2.
MedicationPrescriptionParam 4 [1] SET
{
GenericMedCode [0] CodedData,
. -- E.g. ATC-code
ProprietaryMedCode [1] CodedData,
Strength [2] SEQUENCE,
{ NoStrengthUnits [0] Real,
StrengthUnits [1] CodedData
}
Form [3] CodedData,
DosageInstructionsCode [4] CodedData,
PatientAdviceCode [5] CodedData,
Iterations [6] NUMERIC STRING DEFAULT 1,
-- The number of times the quantity may be
-- dispensed
QuantityToDispense [7] SET,
{
DaysSupply [0] NUMERIC STRING,
NoDispenseUnits [1] REAL,

44 © BSI 06-1999
 ENV 12018:1997

DispenseUnits [2] CHOICE

{
TabletCaps [0] BOOLEAN,
-- This includes suppositories, vagitories and other
-- forms of special “tablets” that may be sold as an
-- arbitrary no of individual entities
Packages [1] BOOLEAN,
Grams [2] BOOLEAN,
Milligrams [3] BOOLEAN,
Litres [4] BOOLEAN,
Millilitres [5] BOOLEAN,
IntlUnits [6] BOOLEAN,
Special [7] BOOLEAN
}
ReimbursmentInfo [8] CodedData
}
B.20.3 The “Medication Administered” parameter Object
The plain text definition of this object is provided in normative clause 8.2.3.
MedicationAdministeredParam 4 [2] SET
{
GenericMedCode [0] CodedData,
-- E.g. ATC-code
ProprietaryMedCode [1] CodedData
Strength [2] SEQUENCE
{ NoStrengthUnits [0] Real,
StrengthUnits [1] CodedData
}
Form [3] CodedData
DosageInstructionsCode [4] CodedData,
PatientAdviceCode [5] CodedData,
QuantityAdministered [6] SET of
{
NoDispenseUnits [0] REAL,
DispenseUnits [1] CHOICE
{
TabletCaps [0] BOOLEAN,
- This includes suppositories, vagitories and other forms of special
“tablets” that may be sold as an arbitrary no of individual entities
Packages [1] BOOLEAN,
Grams [2] BOOLEAN,
Milligrams [3] BOOLEAN,
Litres [4] BOOLEAN,
Millilitres [5] BOOLEAN,
IntlUnits [6] BOOLEAN,
Special [7] BOOLEAN
}
BatchIdentifier [7] OCTETSTRING OPTIONAL
}
B.20.4 The “Medication Dispensed” parameter object
The plain text definition of this object is provided in normative clause 8.2.4.
MedicationDispenseParam 4 [3] SET
{
MedicationDispensedActual [0] CHOICE

© BSI 06-1999 45
ENV 12018:1997

{
ProprietaryMedCode [0] CodedData,
GenericMedCode [1] Coded Data
-- E.g. ATC-code
}
Strength [1] SEQUENCE
{ NoStrengthUnits [0] Real,
StrengthUnitsCode [1] CodedData
}
Form [2] CodedData
DosageInstructionsCode [3] CodedData,
PatientAdviceCode [4] CodedData,
IterationNo [5] NUMERIC STRING DEFAULT 1,
-- The sequence number of the quantity being dispensed
QuantityDispensed [6] SET,
{
DaysSupply [0] NUMERIC STRING,
NoDispenseUnits [1] REAL,
DispenseUnits [2] CHOICE OF
{
TabletCaps [0] BOOLEAN,
-- This includes suppositories, vagitories and other
forms of special “tablets” that may be sold as an
arbitrary no of individual entities
Packages [1] BOOLEAN,
Grams [2] BOOLEAN,
Milligrams [3] BOOLEAN,
Litres [4] BOOLEAN,
Millilitres [5] BOOLEAN,
IntlUnits [6] BOOLEAN,
Special [7] BOOLEAN
}
DispensedByID [7] HcpRefPointer
DispensedDate [8] Date,
DispensedPrice [9] Money OPTIONAL,
DispensedPaid [10] Money OPTIONAL
BatchIdentifier [11] OCTETSTRING OPTIONAL
DispensingIdentifier [12] OCTETSTRING OPTIONAL
-- Represents identifier allocated to the
dispensed item allocated by the
dispensing pharmacist
B.20.5 The “Drug Sensitivity” parameter object
The plain text definition of this object is provided in normative clause 8.2.5.
DrugSesitivityParam 4 [4] CodedData
B.20.6 The “Laboratory Test Results” parameter object
The plain text definition of this object is provided in normative clause 8.2.6.
LabTestResultsParam 4 [5] SET OF Results

Results 4 SET
{
TimeSample [0] UTC Time,
LabResult [1] LabValue,
NormalRange [2] BOOLEAN DEFAULT TRUE,

46 © BSI 06-1999
 ENV 12018:1997

-- True means normal, False means Therapeutic

-- range
RefLowerLimit [3] LabValue OPTIONAL,
RefUpperLimit [4] LabValue OPTIONAL
}

LabValue 4 SET
{ Units [0] CodedData,
Value [1] REAL
}
B.20.7 The “Digital Binary Data” parameter object
The plain text definition of this object is provided in normative clause 8.2.7.
BinaryParam 4 [7] OCTET STRING
B.20.8 The “Request” parameter object
The plain text definition of this object is provided in normative clause 8.2.8.
RequestParam 4 [8] SET
{
PreferredDate [0] Date,
PlannedDate [1] Date
}
B.20.9 The “Diagnosis” parameter object
The plain text definition of this object is provided in normative clause 8.2.9.
DiagnosisParam 4 [9] SET OF BOOLEAN
{
UnconfirmedDiagnosis [0] Boolean,
-- True means unconfirmed or suspected
ConfirmedDiagnosis [1] Boolean,
-- True means diagnosis confirmed by tests
DiagnosisAtAdmision [2] Boolean,
— True means diagnosis given on admission to
-- hospital or clinic
DiagnosisAtDischarge [3] Boolean,
-- True means diagnosis given at discharge of
-- patient from clinic or hospital
PrincipalDiagnosis [4] Boolean
-- True means diagnosis is principal diagnosis
}
B.20.10 The “Procedure” parameter object
The plain text definition of this object is provided in normative clause 8.2.10.
ProcedureParam 4 [10] SET
{
ProcedureCode [0] CodedData,
GenericProcedureCode [1] CodedData
-- e.g. OPCS4
}
B.21 The Limited Emergency Data Set
The plain text definition of this object is provided in normative clause 8.3.
LimEmergencyData 4 [APPLICATION 24]SET
{
EmergencyDataBitMap 4 [0] SEQUENCE OF BOOLEANS
{

© BSI 06-1999 47
ENV 12018:1997

Asthma [0],
HeartDisease [1],
EpilepsyFits [2],
NeurologicalDisorder [3],
Haemophilia [4],
ClottingDisorder [5],
Diabetes [6],
Glaucoma [7],
DialysisTreatment [8],
Transplant [9],
MissingOrgan [10],
PacemakerInSitu [11],
AntipsychoticMedication [12],
Anticonvulsants [13],
Antiarrythmics [14],
BloodPressureDrugs [15],
Anticoagulants [16],
AntidiabeticAgents [17],
Antihistamines [18]
}
[1] AccessoryAttributes OPTIONAL
}
B.22 Specific ICDs security services related data objects
B.22.1 Patient devices security related data
The plain text definition of this data object is provided in normative clause 9.1.
PatientDevSecurity 4 [4] SET
{
IcdHolderVer [0],
DevClassAuthenticateData [1],
PatEncryptionData [2],
PatsSignatureFunctData [3],
HcpAuthenticateData [4]
}

IcdHolderVer 4 [0] SEQUENCE

{
VerificationMethod [0] CodedData,
VerificationData [1] OCTET STRING
}

DevClassAuthenticateData 4 [1] SEQUENCE

{
AuthenticationMethod [0] CodedData,
DevAuthenticationKey [1] OCTET STRING
}

PatEncryptionData 4 [2] SEQUENCE

{
PatEncAlgorithmID [0] RefPointer,
-- This points to the algorithm table
PatEncKeyID [1] RefPointer
-- This points to the Key table
}

48 © BSI 06-1999
 ENV 12018:1997

PatSignatureFunctData 4 [3] SEQUENCE

{
PatSignAlgorithmID [0] RefPointer,
-- This points to the algorithm table
PatSignKeyID [1] RefPointer
-- This points to the Key table
}

HCPAuthenticateData 4 [4] SEQUENCE

{
HcpAuthentMethod [0] CodedData,
HcpIntlKeys [1] SEQUENCE OF (SIZE(1..8)) HCPKeyID,
HcpNatKeys [2] SEQUENCE OF (SIZE(1..8)) HCPKeyID
}

HCPKeyID 4 OCTET
B.22.2 Healthcare persons devices security related data
The plain text definition of this data object is provided in normative clause 9.2.
HCPDevSecurity 4 [5] SET
{
IcdHolderVer [0],
IdAuthenticateData [1],
DevClassAuthenticateData [2],
PatientICDAccessData [3],
HcpEncryptionData [4],
HcpSignFuncData [5]
}

IcdHolderVer 4 [0] SEQUENCE

{
VerificationMethod [0] CodedData,
VerificationData [1] OCTET STRING
}

IdAuthenticateData 4 [1] SEQUENCE

{
IdAuthenticMethod [0] CodedData OPTIONAL,
IdAuthenticateKey [1] BIT STRING(512) OPTIONAL,
AuthenticateCert [2] Certificate OPTIONAL
}

Certificate 4 SEQUENCE
{
Version [0] Version DEFAULT 1988,
SerialNumber [1] SerialNumber OPTIONAL,
CertAlgorithm [2] AlgorithmIdentifier OPTIONAL,
CertIssuer [3] CertificateAuthority OPTIONAL,
Validity [4] Validity OPTIONAL,
HcpIdNo [5] Name OPTIONAL,
HcpPublicKeyInfo [6] SubjectPublicKeyInfo OPTIONAL,
CertSign [7] CertSignature OPTIONAL
-- This object description of a certificate is derived
-- from ISO/IEC 9594-8
}

© BSI 06-1999 49
ENV 12018:1997

Version 4 INTEGER { 1988(=)}

SerialNumber 4 INTEGER

Validity 4 SEQUENCE
{
NotBefore [0]UTCTime,
NotAfter [1]UTCTime}

AlgorithmIdentifier 4 SEQUENCE
{
Algorithm [0] OBJECT IDENTIFIER,
Parameters [1] ANY DEFINED BY algorithm
OPTIONAL}

CertificateAuthority 4 Name

SubjectPublicKeyInfo 4 SEQUENCE
{
Algorithm [0] algorithmIdentifier,
SubjectPublicKey [1] BIT STRING}

CertSignature 4 BIT STRING

DevClassAuthenticateData 4 [2] SEQUENCE

{
AuthenticationMethod [0] CodedData,
DevAuthenticationKey [1] OCTET STRING
}

PatientIcdAccessData 4 [3] SEQUENCE

{
HcplntlAccessIDs [0] SEQUENCE OF SIZE(1..3)
IntlAccessID NUMERIC STRING(SIZE(1)),
HcpNatAccessIDs [1] SEQUENCE OF SIZE(1..3)
NatAccessID NUMERIC STRING(SIZE(1)),
AccessKeys [2] SEQUENCE OF SIZE(1..8)
Access key BIT STRING(SIZE(1..2000))
}

HcpEncryptionData 4 [4] SEQUENCE

{
HcpEncAlgorithmID [0] RefPointer,
-- This points to the algorithm table
HcpEncKeyID [1] RefPointer
-- This points to the Key table
}

HcpSignFuncData 4 [5] SEQUENCE

{
SignMethod [0] CodedData, OPTIONAL,
SignKey [1] BIT STRING(SIZE(1..2000)),
SignatureCertificate [2]Certificate OPTIONAL
}

50 © BSI 06-1999
 ENV 12018:1997

Annex C (informative)
The hierarchy of data objects
This annex shows the hierarchy of most data objects. The tags attached to the objects subsequently follows
the same hierachy.
C.1 Basic data objects for referencing

RecordPersons
MajorRecordPerson
Spouse
Child
Father
Mother
OtherPerson

RecordPerson
MajorRecordIdentifier
RecordIdentifier
MII
IssuerCountry
IssuerIdentifier
Checkdigit
RecordIDNumber
AlternativeRecordIdentifiers
SocialSecurityNo
AlternativeNumbers
RecordIdentifier
MII
IssuerCountry
IssuerIdentifier
Checkdigit
RecordIDNumber
RecordIdVerification
RecordpersonName
Fullname
Title
Surnameprefix
Surnames
Surname
Surnamesufix
Forenames
Forename
DateofBirth
Sex
PlaceofBirth
AccessoryAttributes

DeviceData
Devtype
DeviceClass
Device Standard
DevicSpec
DevApplications
DevApplicationClass
Identification

© BSI 06-1999 51
ENV 12018:1997

Administrative
Clinical
Other
DevApplicationCodes
DevDirectory
DevIdentification
DeviceManufacturer
DeviceComponentManuf
DevicePersonaliser
DeviceIdNo
DeviceIssueDate
PatientDev Security
ICDHolderVer
VerificationMethod
VerificationData
DevClassAuthenticateData
AuthenticationMethod
DevAuthenticationKey
PatEncryptionData
PatEncAlgorithmID
PatEncKeyID
PatSignatureFunctData
PatSignAlgorithmID
PatSignKeyID
HCPAuthenticateData
HCPAuthentMethod
HCPIntKeys
HCPNatKeys
HCPDevSecurity
ICDHolderVer
VerificationMethod
VerificationData
DevClassAuthenticateData
AuthenticationMethod
DevAuthenticationKey
PatientICDAccessData
HCPIntAccessIDs
IntlAccessID
HCPNatAccessIDs
NatAccessID
IDAuthenticateData
IDAuthenticateMethod
IDAuthenticateKey
AuthenticateCert
Certificate
Version
SerialNumber
CertAlgorithm
CertIssuer
Validity
CertStartDate
CertEndDate
HCPIdNo
HCPPublicKeyInfo
CertSign

52 © BSI 06-1999
 ENV 12018:1997

HCPSignFuncData
SignMethod
SignKey
SignatureCertificate
Certificate

HealthCareSites
HealthcareSite
HcsCountry
HcsIdNo
HcsName
HcsAddr
PostalAddress
ExtHcAddress
HcsPostCode
HcsAddrCountry
HcsTelecom

HealthCarePersons
HealthCarePerson
HcpCountry
HcpIdNo
HcpName
Fullname
HcpRelationCode
HcpClass
HcpProfession
HcpEmploymentNo
HcpEmploymentData

SiteMixTable
SiteMix
HcsRef
HCPRef

CodingSchemes Used
Coding Scheme
CodeIdentifier
CodeLength
Comment

CodedData
CodingSchemeRefno
CodeDataValue
CodeDataFreeText

© BSI 06-1999 53
ENV 12018:1997

C.2 Basic data objects for identification and administrative purposes

Address
PostalAddress
ExtHealthCareAddress

HcpData
HealthcarePerson
HealthcareSite
AccessoryAttributes

AccessoryAttributes
Date1
Date2
Place/Person1
Place/Person2
Place/Person3
PersonCode
PersonText
SecurityLevels
ReadSecAttribute
WriteSecAttribute
UpdateSecAttribute
EraseSecAttribute
CompressionMethod
ObjectSecurityAttributes
SecurityServices
SignatureAlgorithmId
SignatureKeyId
DigitalSignature
EncryptionAlgorithmId
EncryptionKeyId

SecurityLevels
ReadSecAttribute
WriteSecAttribute
UpdateSecAttribute
EraseSecAttribute
CompressMethodData

SecAttData
Always
Never
ProtExtAg
ProtHoldAg
ProtAuthAg

VariableIdData
RecPersVariableId
Address
Telecom
PreferredLanguages
Language
MaidenName
MaidenSurname

54 © BSI 06-1999
 ENV 12018:1997

AccessoryAttributes
Previous Surname
Surnames
AccessoryAttributes
OtherNames
Fullname
AccessoryAttributes

RecPersPostCode
Post Code
RecPersPointer

RecPersCountry
Country
RecPersPointer

ContactPersons
ContactPerson
Name
Fullname
ContactTelNo
Telecom
Comment
RecPersPointer
AccessoryAttributes

RecPersVisitInstr
VisitInstr
RecPersPointer
AccessoryAttributes

PaymentProvisions
Payment Provision
PaymentBodyID
PaymentBodyCountry
PaymentBodyNumber
PaymentBodyName
PaymentBodyAddress
Address
PostCode
Country
PaymentBodyTelecom
Policies
PolicyIDno
MemberNo
CoveredPersonConditions
PersonCondition
RecordPersPointer
Conditions
Condition

© BSI 06-1999 55
ENV 12018:1997

ObligatoryStatus
CareCoverageCode
CareCoverageText
CoverageAreas
CoveredCountries
Country
PaymentLevel
LowerLimitCoverage
Money
Amount
Currency
UpperLimitCoverage
Money
Amount
Currency
BenefitsRate
SetPrice
SetPriceValue
Amount
Currency
ThirdParty
EmploymentStatus
Employed
SelfEmployed
EmployedPensionable
SelfEmployedPensionable
AuthorisationReq
StartDate
EndDate
AccessoryAttributes

PatientPayments
IdPatientPayment
RecPersPointer
PatientAccPayment
Money
PatientCarePayments
PatientCarePayment
ProcedureRef
ProcedureAmount
AccessoryAttributes

OtherCodedAdminData
AdmData
AdmCodedData
AdminMoney
AdmRefPointer
AccessoryAttributes
Linkages
Link
RefPointer

56 © BSI 06-1999
 ENV 12018:1997

C.3 Clinical data

ClinicalCodedData
ClinDat
IDPatientCodedData
ClinCodedData

Parameter
MedicationNoteParam
GenereicMedCode
ProprietaryMedCode
DosageInstructionsCode
PatientAdviceCode

MedicationPrescriptionParam
GenericMedCode
ProprietaryMedCode
Strength
NoStrengthUnits
StrengthUnit
Form
Dosage InstructionsCode
PatientAdviceCode
Iterations
QuantityToDispense
DaysSupply
NoDispenseUnits
DispenseUnits
Tablets
Caps
Packages
Grams
Milligrams
Litres
Millilitres
InternationalUnits
Special
ReimbursementInfo

MedicationAdministeredParam
GenericMedCode
ProprietaryMedCode
Strength
NoStrengthUnits
StrengthUnitCode
Form
DosageInstructionsCode
PatientAdviceCode
QuantityAdministered
NoDispenseUnits
DispenseUnits

© BSI 06-1999 57
ENV 12018:1997

MedicationDispenseParam
MedicationDispensedActual
GenericMedCode
ProprietaryMedCode
Strength
NoStrengthUnits
StrengthUnitCode
Form
DosageInstructionsCode
PatientAdviceCode
IterationNo
QuantityDispense
DaysSupply
NoDispenseUnits
DispenseUnits
DispensedById
DispensedDate
DispensedPrice
DispensedPaid

DrugSensitivityParam
CodedData

LabTestResultsParam
Results
TimeSample
Labresult
LabValue
Units
Value
NormalRange
RefLowerLimit
LabValue
RefUpperLimit
LabValue

BinaryParam

DiagnosisParam
UnconfirmedDiagnosis
ConfirmedDiagnosis
DiagnosisAtAdmission
DiagnosisAtDischarge
PrincipleDiagnosis

RequestParam
PreferredDate
PlannedDate

ProcedureParam
ProcedureCode
CodedData

58 © BSI 06-1999
 ENV 12018:1997

GenericProcedureCode
CodedData
ClinRefPointer
AccessoryAttributes

LimitedEmergencyData
EmergencyDataBitMap
BitMap
AccessoryAttributes
C.4 Specific ICDs security services related data objects

PatientDevSecurity
ICDHolderVer
VerificationMethod
VerificationData
DevClassAuthenticateData
AuthenticationMethod
DevAuthenticationKey
PatEncryptionData
PatEncAlgorithmID
PatEncKeyID
PatSignatureFunctData
PatSignAlgorithmID
PatSignKeyID
HCPAuthenticateData
HcpAuthentMethod
HcpIntlKeys
HcpNatKeys

HCPDevSecurity
ICDHolderVer
VerificationMethod
VerificationData
IdAuthenticateData
IdAuthenticMethod
IdAuthenticateKey
AuthenticateCert
Certificate
Version
SerialNumber
CertAlgorithm
CertIssuer
Validity
HcpIdNo
HcpPublicKeyInfo
CertSign
DevClassAuthenticate Data
AuthenticationMethod
DevAuthenticationKey
PatientICDAccessData
HcpIntlAccessIDs

© BSI 06-1999 59
ENV 12018:1997

HcpNatAccessIDs
AccessKeys
HcpEncryptionData
HcpEncAlgorithmID
HcpEncKeyID
HcpSignFuncData
SignMethod
SignKey
SignatureCertificate

Annex D (normative)
Application specific data object tags and their values
This standard defines certain referencable tags each of which has a specific associated value shown below.
Any application may define its own private tags for additional data, but the range 32-63 inclusive shall be
reserved for constructed objects.
RecordPersons 45
DeviceData 46
HealthCareSites 47
HealthCarePersons 48
SiteMixTable 49
CodingSchemesUsed 50
VariableIdData 51
RecPersPostCode 52
RecPersCountry 53
ContactPersons 54
RecPersVisitlnstr 55
PaymentProvisions 56
PatientPayments 57
OtherCodedAdminData 58
Linkages 59
ClinicaICodedData 60
LimEmergencyData 61
HcpData 62

Annex E (informative)
Devices that may function as Intermittently Connected Devices
Passive memory media
Magnetic
Standard Magstripe Cards
Nonstandard Magnetic techniques, low and high density
Optical
Printed barcode
Laser recorded reflex alteration
Transparent microsphere technology
Integrated Circuit Chip (Synchronous non-microprocessor type)
EPROM (non erasable)
EEPROM (erasable)

IC-Cards with some hardwired security functions

60 © BSI 06-1999
 ENV 12018:1997

Active microprocessor cards (Asynchronous communication)

With and without advanced security features
EPROM (non erasable)
EEPROM (erasable)

Contactless microprocessor cards

Low range inductive type
Long range radiofrequency type

Microprocessor cards with user interface

With keyboard and display (visual or supersmart)

All Other IC cards in nonstandard, non ISO format

PCMCI — Memory cards
ROM-Cards
SRAM with battery
FLASH-PROM

Discs
Flexible diskettes
Hard diskettes
Smart diskettes
Removable winchesters
Removable optical disks
Removable magneto-optical

Tapes
Magnetic tape cassettes
Other digital tape cassettes
Optical tape cassettes
Magnetic tape on wheels
Optical tape on wheels

Portable computers
Handhold computers of all types
Notebook computers
Other portable computers

Other devices
Portable ECG and blood pressure monitors and similar devices
Portable imagers
Portable scanners
Etc.

Annex F (informative)
Data Dictionary
This Data Dictionary lists the data objects, of various data types, in a format different from the normative
ASN.1 objects previously described.
The data objects taken from within this data dictionary are combined in different combinations to produce
data objects that are identifiable by their tags and have defined structures intended for specific uses
e.g. providing for the function of identifying an individual or passing an electronic prescription. Some data
elements can be combined in many different structures whilst retaining the same format and content and
may be repeated with different tags in order to perform different functions i.e. identify different
individuals.

© BSI 06-1999 61
ENV 12018:1997

It should be noted that the Data Dictionary description does not completely define the richness and
complexity of the ASN.1 syntax descriptions.
This table should not be regarded as being identical to the attribute layer specification as
described within EDIFACT syntax, in that it contains data types inadmissible within EDIFACT.
The reader is referred to the normative ASN.1 definitions in Annex A for full textual clarity.
F.1 Data types
The following data types are used in the data dictionary table:
a) string (S): a string of characters from the ISO 8859-1:1987 character sets; (This corresponds to the use
of the ASN.1 OCTET STRING in the normative part of the standard);
b) time of calendar date (D): string limited to the representation of the year, month, day, hour, minutes,
seconds. This time of calendar date is represented as UTC time (ISO 8824:1990);
c) boolean (B): a simple type with two distinguished values. Possibilities are true or false
(ISO 8824:1990);
d) integer (I): a simple type with distinguished values which are the positive and negative whole
numbers including zero (ISO 8824:1990);
e) real (R): a simple type whose distinguished values are members of the set of real numbers
(ISO 8824:1990);
f) coded data (C): this data type consists of 3 components:
1) a coding scheme indicator pointing to a device specific table of coding schemes used. This table will
contain a reference to the HCD (Healthcare Coding Scheme Designator) or ICD (International Coding
Scheme Designator): data type integer, mandatory component,
2) code value: data type string, mandatory component,
3) free text: data type string, optional component;
NOTE When there is an explicit definition of a particular coding scheme to be used within the normative standard, data values
may actually be codes but of data type string and with no reference to the coding scheme used, which is implicitly defined by the
standard.
g) set of coded values (SC): value which may be represented by a repetition of coded values;
h) bit string (BS): Data type represented as a bit string (ISO 8824:1990);
i) attribute group (AG): compound data type used to group together a set of logically coherent attributes
and/or attribute groups;
j) common attribute group (CAG): compound data type used to group together a set of logically coherent
attributes, described separately;
k) [Link].(RT) a reference tag of the integer type being a number. A pointer to a look up table containing
the reference tags of other objects.
l) Reference pointer (SRT) a sequence of [Link].
F.2 Status of the attributes within the objects
The abbreviations used in the table indicate the status of an attribute or attribute group when the related
object is present in a message. Instances are:
— M: mandatory;
— O: optional;
— NA: not applicable.
The status of an entry in the table for an attribute or attribute group for a given object is only applicable
when the higher level component (the object for attribute groups and attributes, the attribute group for
attributes and attribute groups belonging to such a group) is present in any stored data object or data
exchange.
Table F.1 does not include the “data objects” used for commands and responses relating to initiation and
closure of sessions with ICDs, nor read and write requests and responses.

62 © BSI 06-1999
 ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
RECORD PERSONS CAG M
MAJOR RECORD PERSON AG M
MAJOR RECORD IDENTIFIER AG M
MAJOR RECORD PERSON MII 2 R M
MAJOR RECORD PERSON COUNTRY 3 C M
MAJOR RECORD PERSON ISSUER ID 5 R M
MAJOR RECORD PERSON CHECK DIGIT 1 R M
MAJOR RECORD PERSON RECORD ID NUMBER 21 S M
MAJOR RECORD PERSON SOCIAL SECURITY NUMBER AG O
MAJOR RECORD PERSON SOCIAL SECURITY NUMBER MII 2 R M
MAJOR RECORD PERSON SOCIAL SECURITY NUMBER 3 C M
COUNTRY
MAJOR RECORD PERSON SOCIAL SECURITY NUMBER 5 R M
ISSUER ID
MAJOR RECORD PERSON SOCIAL SECURITY NUMBER 1 R M
CHECK DIGIT
MAJOR RECORD PERSON SOCIAL SECURITY NUMBER 21 S M
RECORD ID NUMBER
MAJOR RECORD PERSON ALTERNATIVE RECORD AG O
NUMBER
MAJOR RECORD PERSON ALTERNATIVE RECORD 2 R M
NUMBER MII
MAJOR RECORD PERSON ALTERNATIVE RECORD 3 C M
NUMBER COUNTRY
MAJOR RECORD PERSON ALTERNATIVE RECORD 5 R M
NUMBER ISSUER ID
MAJOR RECORD PERSON ALTERNATIVE RECORD 1 R M
NUMBER CHECK DIGIT
MAJOR RECORD PERSON ALTERNATIVE RECORD 21 S M
NUMBER RECORD ID NUMBER
MAJOR RECORD PERSON RECORD ID VERIFICATION AG M
MAJOR RECORD PERSON FULLNAME AG M
MAJOR RECORD PERSON TITLE 7 S M
MAJOR RECORD PERSON SURNAME PREFIX 15 S M
MAJOR RECORD PERSON PREFERRED SURNAME 27 S M
MAJOR RECORD PERSON SURNAME 27 S O
MAJOR RECORD PERSON SURNAME SUFFIX 15 S M
MAJOR RECORD PERSON PREFERRED FORENAME 27 S M
MAJOR RECORD PERSON FORENAME 27 S O
MAJOR RECORD PERSON DATE OF BIRTH 12 D M

© BSI 06-1999 63
ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O

MAJOR RECORD PERSON SEX AT BIRTH 1 C M

MAJOR RECORD PERSON PLACE OF BIRTH 15 S M
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
READSECATTRIBUTE B O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID RT O

SPOUSE RECORD PERSON AG O

SPOUSE RECORD PERSON MAJOR RECORD AG M
IDENTIFIER
SPOUSE RECORD PERSON MII 2 R M
SPOUSE RECORD PERSON COUNTRY 3 C M
SPOUSE RECORD PERSON ISSUER ID 5 R M
SPOUSE RECORD PERSON CHECK DIGIT 1 R M
SPOUSE RECORD PERSON RECORD ID NUMBER 21 S M
SPOUSE RECORD PERSON SOCIAL SECURITY NUMBER AG O
SPOUSE RECORD PERSON SOCIAL SECURITY NUMBER 2 R M
MII
SPOUSE RECORD PERSON SOCIAL SECURITY NUMBER 3 C M
COUNTRY
SPOUSE RECORD PERSON SOCIAL SECURITY NUMBER 5 R M
ISSUER ID
SPOUSE RECORD PERSON SOCIAL SECURITY NUMBER 1 R M
CHECK DIGIT
SPOUSE RECORD PERSON SOCIAL SECURITY NUMBER 21 S M
RECORD ID NUMBER
SPOUSE RECORD PERSON ALTERNATIVE RECORD AG O
NUMBER

64 © BSI 06-1999
 ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O

SPOUSE RECORD PERSON ALTERNATIVE RECORD 2 R M

NUMBER MII
SPOUSE RECORD PERSON ALTERNATIVE RECORD 3 C M
NUMBER COUNTRY
SPOUSE RECORD PERSON ALTERNATIVE RECORD 5 S M
NUMBER ISSUER ID
SPOUSE RECORD PERSON ALTERNATIVE RECORD 1 N M
NUMBER CHECK DIGIT
SPOUSE RECORD PERSON ALTERNATIVE RECORD 21 S M
NUMBER RECORD ID NUMBER
SPOUSE RECORD PERSON RECORD ID VERIFICATION AG O
SPOUSE RECORD PERSON FULLNAME AG O
SPOUSE RECORD PERSON TITLE 7 S M
SPOUSE RECORD PERSON SURNAME PREFIX 15 S M
SPOUSE RECORD PERSON SURNAME SUFFIX 15 S M
SPOUSE RECORD PERSON PREFERRED SURNAME 27 S M
SPOUSE RECORD PERSON SURNAME 27 S O
SPOUSE RECORD PERSON PREFERRED FORENAME 27 S M
SPOUSE RECORD PERSON FORENAME 27 S O
SPOUSE RECORD PERSON FORENAME 27 S O
SPOUSE RECORD PERSON DATE OF BIRTH 12 D M
SPOUSE RECORD PERSON SEX AT BIRTH 1 C M
SPOUSE RECORD PERSON PLACE OF BIRTH 15 S M
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID RT O

CHILD RECORD PERSON AG O

© BSI 06-1999 65
ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O

CHILD RECORD PERSON MAJOR RECORD IDENTIFIER AG M

CHILD RECORD PERSON MII 2 R M
CHILD RECORD PERSON COUNTRY 3 C M
CHILD RECORD PERSON ISSUER ID 5 R M
CHILD RECORD PERSON CHECK DIGIT 1 R M
CHILD RECORD PERSON RECORD ID NUMBER 21 S M
CHILD RECORD PERSON SOCIAL SECURITY NUMBER AG O
CHILD RECORD PERSON SOCIAL SECURITY NUMBER MII 2 R M
CHILD RECORD PERSON SOCIAL SECURITY NUMBER 3 C M
COUNTRY
CHILD RECORD PERSON SOCIAL SECURITY NUMBER 5 R M
ISSUER ID
CHILD RECORD PERSON SOCIAL SECURITY NUMBER 1 R M
CHECK DIGIT
CHILD RECORD PERSON SOCIAL SECURITY NUMBER 21 S M
RECORD ID NUMBER
CHILD RECORD PERSON ALTERNATIVE RECORD AG O
NUMBER
CHILD RECORD PERSON ALTERNATIVE RECORD NUMBER 2 R M
MII
CHILD RECORD PERSON ALTERNATIVE RECORD NUMBER 3 C M
COUNTRY
CHILD RECORD PERSON ALTERNATIVE RECORD NUMBER 5 R M
ISSUER ID
CHILD RECORD PERSON ALTERNATIVE RECORD NUMBER 1 R M
CHECK DIGIT
CHILD RECORD PERSON ALTERNATIVE RECORD NUMBER 21 S M
RECORD ID NUMBER
CHILD RECORD PERSON RECORD ID VERIFICATION AG O
CHILD RECORD PERSON FULLNAME AG M
CHILD RECORD PERSON TITLE 7 S M
CHILD RECORD PERSON SURNAME PREFIX 15 S M
CHILD RECORD PERSON SURNAME SUFFIX 15 S M
CHILD RECORD PERSON PREFERRED SURNAME 27 S M
CHILD RECORD PERSON SURNAME 27 S O
CHILD RECORD PERSON PREFERRED FORENAME 27 S M
CHILD RECORD PERSON FORENAME 27 S O
CHILD RECORD PERSON FORENAME 27 S O
CHILD RECORD PERSON DATE OF BIRTH 12 D M
CHILD RECORD PERSON SEX AT BIRTH 1 C M
CHILD RECORD PERSON PLACE OF BIRTH 15 S M
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O

66 © BSI 06-1999
 ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O

DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID RT O
FATHER RECORD PERSON AG O
FATHER RECORD PERSON MAJOR RECORD AG M
IDENTIFIER
FATHER RECORD PERSON MII 2 R M
FATHER RECORD PERSON COUNTRY 3 C M
FATHER RECORD PERSON ISSUER ID 5 R M
FATHER RECORD PERSON CHECK DIGIT 1 R M
FATHER RECORD PERSON RECORD ID NUMBER 21 S M
FATHER RECORD PERSON SOCIAL SECURITY AG O
NUMBER
FATHER RECORD PERSON SOCIAL SECURITY NUMBER 2 R M
MII
FATHER RECORD PERSON SOCIAL SECURITY NUMBER 3 C M
COUNTRY
FATHER RECORD PERSON SOCIAL SECURITY NUMBER 5 R M
ISSUER ID
FATHER RECORD PERSON SOCIAL SECURITY NUMBER 1 R M
CHECK DIGIT
FATHER RECORD PERSON SOCIAL SECURITY NUMBER 21 S M
RECORD ID NUMBER
FATHER RECORD PERSON ALTERNATIVE RECORD AG O
NUMBER
FATHER RECORD PERSON ALTERNATIVE RECORD 2 R M
NUMBER MII
FATHER RECORD PERSON ALTERNATIVE RECORD 3 C M
NUMBER COUNTRY
FATHER RECORD PERSON ALTERNATIVE RECORD 5 R M
NUMBER ISSUER ID

© BSI 06-1999 67
ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
FATHER RECORD PERSON ALTERNATIVE RECORD 1 R M
NUMBER CHECK DIGIT
FATHER RECORD PERSON ALTERNATIVE RECORD 21 S M
NUMBER RECORD ID NUMBER
FATHER RECORD PERSON RECORD ID VERIFICATION AG M
FATHER RECORD PERSON FULLNAME AG M
FATHER RECORD PERSON TITLE 7 S M
FATHER RECORD PERSON SURNAME PREFIX 15 S M
FATHER RECORD PERSON SURNAME SUFFIX 15 S M
FATHER RECORD PERSON PREFERRED SURNAME 27 S M
FATHER RECORD PERSON SURNAME 27 S O
FATHER RECORD PERSON PREFERRED FORENAME 27 S M
FATHER RECORD PERSON FORENAME 27 S O
FATHER RECORD PERSON FORENAME 27 S O
FATHER RECORD PERSON DATE OF BIRTH 12 D M
FATHER RECORD PERSON SEX AT BIRTH 1 C M
FATHER RECORD PERSON PLACE OF BIRTH 15 S M
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID I O

MOTHER RECORD PERSON AG O

MOTHER RECORD PERSON MAJOR RECORD AG M
IDENTIFIER
MOTHER RECORD PERSON MII 2 R M
MOTHER RECORD PERSON COUNTRY 3 C M
MOTHER RECORD PERSON ISSUER ID 5 R M
MOTHER RECORD PERSON CHECK DIGIT 1 R M
MOTHER RECORD PERSON RECORD ID NUMBER 21 S M

68 © BSI 06-1999
 ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O

MOTHER RECORD PERSON SOCIAL SECURITY AG O

NUMBER
MOTHER RECORD PERSON SOCIAL SECURITY NUMBER 2 R M
MII
MOTHER RECORD PERSON SOCIAL SECURITY NUMBER 3 C M
COUNTRY
MOTHER RECORD PERSON SOCIAL SECURITY NUMBER 5 R M
ISSUER ID
MOTHER RECORD PERSON SOCIAL SECURITY NUMBER 1 R M
CHECK DIGIT
MOTHER RECORD PERSON SOCIAL SECURITY NUMBER 21 S M
RECORD ID NUMBER
MOTHER RECORD PERSON ALTERNATIVE RECORD AG O
NUMBER
MOTHER RECORD PERSON ALTERNATIVE RECORD 2 R M
NUMBER MII
MOTHER RECORD PERSON ALTERNATIVE RECORD 3 C M
NUMBER COUNTRY
MOTHER RECORD PERSON ALTERNATIVE RECORD 5 R M
NUMBER ISSUER ID
MOTHER RECORD PERSON ALTERNATIVE RECORD 1 R M
NUMBER CHECK DIGIT
MOTHER RECORD PERSON ALTERNATIVE RECORD 21 S M
NUMBER RECORD ID NUMBER
MOTHER RECORD PERSON RECORD ID VERIFICATION AG O
MOTHER RECORD PERSON FULLNAME AG M
MOTHER RECORD PERSON TITLE 7 S M
MOTHER RECORD PERSON SURNAME PREFIX 15 S M
MOTHER RECORD PERSON SURNAME SUFFIX 15 S M
MOTHER RECORD PERSON PREFERRED SURNAME 27 S M
MOTHER RECORD PERSON SURNAME 27 S O
MOTHER RECORD PERSON PREFERRED FORENAME 27 S M
MOTHER RECORD PERSON FORENAME 27 S O
MOTHER RECORD PERSON FORENAME 27 S O
MOTHER RECORD PERSON DATE OF BIRTH 12 D M
MOTHER RECORD PERSON SEX AT BIRTH 1 C M
MOTHER RECORD PERSON PLACE OF BIRTH 15 S M
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O

© BSI 06-1999 69
ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O

SECURITY LEVELS 1 CAG O

READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID RT O
OTHER RECORD PERSON AG O
OTHER RECORD PERSON MAJOR RECORD AG M
IDENTIFIER
OTHER RECORD PERSON MII 2 R M
OTHER RECORD PERSON COUNTRY 3 C M
OTHER RECORD PERSON ISSUER ID 5 R M
OTHER RECORD PERSON CHECK DIGIT 1 R M
OTHER RECORD PERSON RECORD ID NUMBER 21 S M
OTHER RECORD PERSON SOCIAL SECURITY NUMBER AG O
OTHER RECORD PERSON SOCIAL SECURITY NUMBER MII 2 R M
OTHER RECORD PERSON SOCIAL SECURITY NUMBER 3 C M
COUNTRY
OTHER RECORD PERSON SOCIAL SECURITY NUMBER 5 R M
ISSUER ID
OTHER RECORD PERSON SOCIAL SECURITY NUMBER 1 R M
CHECK DIGIT
OTHER RECORD PERSON SOCIAL SECURITY NUMBER 21 S M
RECORD ID NUMBER
OTHER RECORD PERSON ALTERNATIVE RECORD AG O
NUMBER
OTHER RECORD PERSON ALTERNATIVE RECORD 2 R M
NUMBER MII
OTHER RECORD PERSON ALTERNATIVE RECORD 3 C M
NUMBER COUNTRY
OTHER RECORD PERSON ALTERNATIVE RECORD 5 R M
NUMBER ISSUER ID
OTHER RECORD PERSON ALTERNATIVE RECORD 1 R M
NUMBER CHECK DIGIT
OTHER RECORD PERSON ALTERNATIVE RECORD 21 S M
NUMBER RECORD ID NUMBER
OTHER RECORD PERSON RECORD ID VERIFICATION AG O

70 © BSI 06-1999
 ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
OTHER RECORD PERSON FULLNAME AG M
OTHER RECORD PERSON TITLE 7 S M
OTHER RECORD PERSON SURNAME PREFIX 15 S M
OTHER RECORD PERSON SURNAME SUFFIX 15 S M
OTHER RECORD PERSON PREFERRED SURNAME 27 S M
OTHER RECORD PERSON SURNAME 27 S O
OTHER RECORD PERSON PREFERRED FORENAME 27 S M
OTHER RECORD PERSON FORENAME 27 S O
OTHER RECORD PERSON FORENAME 27 S O
OTHER RECORD PERSON DATE OF BIRTH 12 D M
OTHER RECORD PERSON SEX AT BIRTH 1 C M
OTHER RECORD PERSON PLACE OF BIRTH 15 S M
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID RT O
DEVICE DATA AG M
DEVICE TYPE CAG O
DEVICE CLASS C M
DEVICE STANDARD C M
DEVICE SPECIFICATION C M
DEVICE APPLICATIONS AG O
DEVICE APPLICATION CLASS 4 B M
DEVICE APPLICATIONS CODES SC M
DEVICE DIRECTORY SRT O
DEVICE IDENTIFICATION AG O
DEVICE MANUFACTURER C M
DEVICE COMPONENT MANUFACTURER C M
DEVICE PERSONALISER C M
DEVICE ID NUMBER 21 R M

© BSI 06-1999 71
ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
DEVICE ISSUE DATE 12 D M

PATIENT DEVICE SECURITY AG O

ICD HOLDER VERIFICATION METHOD C M
ICD HOLDER VERIFICATION DATA S M
DEVICE CLASS AUTHENTICATION METHOD C M
DEVICE AUTHENTICATION KEY S M
PAT ENCRYPTION ALGORITHM ID RT M
PAT ENC KEY ID RT M
PAT SIGNATURE FUNCT DATA RT M
PAT SIGN KEY ID RT M
HCP AUTHENTICATION METHOD C M
HCP INTL KEYS CAG M
HCP KEY ID S M
HCP NATIONAL KEYS CAG M
HCP KEY ID S M
HCP DEV SECURITY CAG O
ICD HOLDER VERIFICATION METHOD C M
ICD HOLDER VERIFICATION DATA S M
DEVICE CLASS AUTHENTICATION METHOD C M
DEVICE AUTHENTICATION KEY BS M
PATIENT ICD ACCESS DATA CAG O
HCP INT ACCESS Ids CAG M
INTERNATIONAL ACCESS ID l I M
HCP NATIONAL ACCESS Ids CAG M
HCP NATIONAL ACCESS Ids l I M

CAG O
ID AUTHENTICATE DATA
ID AUTHENTICATE METHOD C M
ID AUTHENTICATE KEY 512 BS M
CERTIFICATE CAG M
AUTHENTICATION CERTIFICATE VERSION SERIAL S M
NUMBER
CERTIFICATION ALGORITHM IDENTIFIER BS M
CERTIFICATION ALGORITHM PARAMETERS BS O
CERTIFICATION AUTHORITY S M
AUTHENTICATION CERTIFICATE VERSION VALIDITY NOT 12 D M
BEFORE
AUTHENTICATION CERTIFICATE VERSION VALIDITY NOT 12 D M
AFTER
HCP ID NUMBER S M
ALGORITHM IDENTIFIER BS M
PUBLIC KEY BS M

72 © BSI 06-1999
 ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
CERTSIGNATURE BS M

HCP SIGNATURE DATA AG O

SIGNATURE METHOD C M
SIGNATURE KEY BS M
SIGNATURE CERTIFICATE AG M
OBJECT SIGNATURE DATA AG O
SIGNATURE ALGORITHM Ids CAG M
SIGN ALG BS M
SIGN KEY ID C
OBJECT ENCRYPTION ALGORITHM Ids CAG O
ENC ALG C M
ENC KEY ID BSC M

HEALTH CARE SITES CAG

HEALTH CARE SITE AG M
HEALTH CARE SITE COUNTRY 3 C M
HEALTH CARE SITE ID 21 S O
HEALTH CARE SITE NAME 15 S M
HEALTH CARE SITE ADDRESS 70 S M
HEALTH CARE SITE EXTENDED HEALTH CARE ADDRESS 175 S O
HEALTH CARE SITE POSTCODE 8 S M
HEALTH CARE SITE TYPE C O
HEALTH CARE SITE TELECOM AG M
TELECOMMUNICATION — TELNO WORK 15 R O
TELECOMMUNICATION — TELNO OTHER 15 R O
TELECOMMUNICATION — FAXNO WORK 15 R O
X.400 ADDRESS 30 S O
OTHER NETWORK ADDRESS 30 S O

HEALTH CARE PERSONS CAG

HEALTH CARE PERSON AG M
HEALTH CARE PERSON COUNTRY 3 C M
HEALTH CARE PERSON ID NUMBER 21 R M
HEALTH CARE PERSON NAME TITLE 7 S O
HEALTH CARE PERSON NAME SURNAME PREFIX 15 S O
HEALTH CARE PERSON PREFERRED SURNAME 27 S M
HEALTH CARE PERSON SURNAME 27 S M
HEALTH CARE PERSON SUFFIX 15 S O
HEALTH CARE PERSON PREFERRED FORENAME 27 S M
HEALTH CARE PERSON FORENAME 27 S M
HEALTH CARE PERSON RELATION CODE C O
HEALTH CARE PERSON CLASS 10 B M
HEALTH CARE PERSON PROFESSION SC O

© BSI 06-1999 73
ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
HEALTH CARE PERSON EMPLOYMENT NO BS O
HEALTH CARE PERSON EMPLOYMENT DATA SC O

SITE MIX TABLE SRT

CODING SCHEMES USED CAG

CODING SCHEME AG
CODE IDENTIFIER 6 S M
CODE LENGTH I M
CODE COMMENT 20 S O

CODED DATA AG O
CODING SCHEME REF. RT M
CODE DATA VALUE S M
CODE DATA FREE TEXT S O

ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O
OBJECT SECURITY ATTRIBUTES AG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID RT O

COMPRESS METHOD DATA CAG O

COMPRESS METHOD C O

LINKAGES CAG
LINK SRT M

HCP DATA AG
HEALTH CARE PERSON AG M
HEALTH CARE PERSON COUNTRY 3 C M
HEALTH CARE PERSON ID NUMBER 21 R M
HEALTH CARE PERSON NAME TITLE 7 S O
HEALTH CARE PERSON NAME SURNAME PREFIX 15 S O
HEALTH CARE PERSON PREFERRED SURNAME 27 S M
HEALTH CARE PERSON SURNAME 27 S M
HEALTH CARE PERSON SUFFIX 15 S O

74 © BSI 06-1999
 ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
HEALTH CARE PERSON PREFERRED FORENAME 27 S M
HEALTH CARE PERSON FORENAME 27 S M
HEALTH CARE PERSON RELATION CODE C O
HEALTH CARE PERSON CLASS 10 B M
HEALTH CARE PERSON PROFESSION SC O
HEALTH CARE PERSON EMPLOYMENT NO BS O
HEALTH CARE PERSON EMPLOYMENT DATA SC O
HEALTH CARE SITE AG M
HEALTH CARE SITE COUNTRY 3 C M
HEALTH CARE SITE ID 21 S O
HEALTH CARE SITE NAME 15 S M
HEALTH CARE SITE ADDRESS 70 S M
HEALTH CARE SITE EXTENDED HEALTH CARE ADDRESS 175 S O
HEALTH CARE SITE POSTCODE 8 S M
HEALTH CARE SITE TYPE C O
HEALTH CARE SITE TELECOM AG M
TELECOMMUNICATION — TELNO WORK 15 R O
TELECOMMUNICATION — TELNO OTHER 15 R O
TELECOMMUNICATION — FAXNO WORK 15 R O
X.400 ADDRESS 30 S O
OTHER NETWORK ADDRESS 30 S O
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID RT O

RECORD PERSONS POST CODE AG

PERSON POST CODE 8 S M
POST CODE POINTER RT M

© BSI 06-1999 75
ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
RECORD PERSONS COUNTRY
PERSON COUNTRY 3 C M
PERSON COUNTRY POINTER RT M

CONTACT PERSONS CAG O

CONTACT PERSON AG M
CONTACT PERSON NAME TITLE 7 S O
CONTACT PERSON NAME SURNAME PREFIX 15 S O
CONTACT PERSON PREFERRED SURNAME 27 S M
CONTACT PERSON SURNAME 27 S M
CONTACT PERSON SUFFIX 15 S O
CONTACT PERSON PREFERRED FORENAME 27 S M
CONTACT PERSON FORENAME 27 S M
CONTACT PERSON TELNO HOME 15 R O
CONTACT PERSON TELNO WORK 15 R O
CONTACT PERSON TELNO OTHER 15 R O
CONTACT PERSON FAXNO HOME 15 R O
CONTACT PERSON FAXNO WORK 15 R O
CONTACT PERSON X.400 ADDRESS 30 S O
CONTACT PERSON OTHER NETWORK ADDRESS 30 S O
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID RT O

RECORD PERSONS VISIT INSTRUCTIONS CAG NA

RECORD PERSON VISIT INSTRUCTIONS AG
VISIT INSTRUCTIONS 80 S M
VISIT POINTER RT M
VARIABLE ID DATA AG O

76 © BSI 06-1999
 ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID RT O
PAYMENT PROVISIONS CAG NA
PAYMENT PROVISION AG M
PAYMENT BODY ID AG M
PAYMENT BODY COUNTRY 3 C M
PAYMENT BODY NUMBER 9 S M
PAYMENT BODY NAME 20 S O
PAYMENT BODY ADDRESS AG O
PAYMENT BODY POSTAL ADDRESS 70 S M
PAYMENT BODY EXT HEALTH CARE ADDRESS 175 S M
PAYMENT BODY POST CODE 8 S M
PAYMENT BODY COUNTRY 3 C M
PAYMENT BODY TELECOM AG O
PAYMENT BODY TELNO 15 R O
PAYMENT BODY TELNO OTHER 15 R O
PAYMENT BODY FAXNO 15 R O
PAYMENT BODY X.400 ADDRESS 30 S O
PAYMENT BODY OTHER NETWORK ADDRESS 30 S O
POLICIES CAG M
POLICY AG M
POLICY ID NO 21 S M
MEMBER NUMBER 15 S O
COVERED PERSON CONDITIONS AG M
RECORD PERSON POINTER RT M
CONDITIONS AG M
OBLIGATORY STATUS 1 B O
CARE COVERAGE CODE SC O
CARE COVERAGE TEXT 20 S O

© BSI 06-1999 77
ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
COVERAGE AREAS SC O
PAYMENT LEVEL AG M
LOWER LIMIT COVERAGE CURRENCY 3 C O
LOWER LIMIT COVERAGE AMOUNT R O
LOWER LIMIT COVERAGE CURRENCY 3 C O
LOWER LIMIT COVERAGE AMOUNT R O
BENEFITS RATE R O
SET PRICE 1 B O
SET PRICE VALUE CURRENCY 3 C O
SET PRICE VALUE AMOUNT S O
THIRD PARTY 1 B O
EMPLOYMENT STATUS 4 B O
AUTHORISATION REQUIRED 1 B O
START DATE 12 D O
END DATE 12 D O
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 I O
PLACE/PERSON 2 I O
PLACE/PERSON 3 I O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD B O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID I O
SIGNATURE KEY ID I O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID I O
ENCRYPTION KEY ID I O
PATIENT PAYMENTS AG O
ID PATIENT PAYMENT I M
PATIENT ACC PAYMENT CURRENCY 3 C M
PATIENT PAYMENT AMOUNT S M
PATIENT CARE PAYMENTS CAG M
PATIENT CARE PAYMENT AG M
PROCEDURE REF I M
PROCEDURE AMOUNT AG M
PROCEDURE AMOUNT CURRENCY 3 C M
PROCEDURE AMOUNT VALUE S M
ACCESSORY ATTRIBUTES AG O

78 © BSI 06-1999
 ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 2 I O
PLACE/PERSON 3 I O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID I O
SIGNATURE KEY ID I O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID I O
ENCRYPTION KEY ID I O

OTHER CODED ADMIN DATA CAG O

ADMIN DATA AG M
ID PATIENT CODED DATA I M
ADMIN CODED DATA C M
ADMIN MONEY CURRENCY 3 C M
ADMIN MONEY AMOUNT S M
ADMIN REF POINTER I M
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID RT O

CLINICAL CODED DATA CAG O

© BSI 06-1999 79
ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
CLIN DAT AG M
ID PATIENT CODED DATA RT M
CLIN CODED DATA C M
MEDICATION NOTE PARAM CAG O
GENERIC MED CODE C M
PROPRIETARY MED CODE C M
DOSAGE INSTRUCTIONS CODE C M
PATIENT ADVICE CODE C M
MEDICATION PRESCRIPTION PARAM AG O
GENERIC MED CODE C M
PROPRIETARY MED CODE C M
STRENGTH AG M
NO STRENGTH UNITS R M
STRENGTH UNITS C M
FORM C M
DOSAGE INSTRUCTIONS CODE C M
PATIENT ADVICE CODE C M
ITERATIONS R M
QUANTITY TO DISPENSE AG M
DAYS SUPPLY R M
NO DISPENSE UNITS R M
DISPENSE UNITS 8 B M
REIMBURSEMENT INFO C M
MEDICATION ADMINISTERED PARAM AG O
GENERIC MED CODE C M
PROPRIETARY MED CODE C M
STRENGTH AG M
NO STRENGTH UNITS R M
STRENGTH UNITS C M
FORM C M
DOSAGE INSTRUCTIONS CODE C M
PATIENT ADVICE CODE C M
QUANTITY ADMINISTERED AG M
DAYS SUPPLY R M
NO DISPENSE UNITS R M
DISPENSE UNITS 8 B M
MEDICATION DISPENSED PARAM AG O
GENERIC MED CODE C M
PROPRIETARY MED CODE C M
STRENGTH AG M
NO STRENGTH UNITS R M
STRENGTH UNITS C M
FORM C M
DOSAGE INSTRUCTIONS CODE C M
PATIENT ADVICE CODE C M

80 © BSI 06-1999
 ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O
ITERATION NO R M
QUANTITY TO DISPENSED AG M
DAYS SUPPLY R M
NO DISPENSE UNITS R M
DISPENSE UNITS 8 B M
DISPENSED BY ID RT M
DISPENSED DATE 12 D M
DISPENSED PRICE AG O
DISPENSED PRICE CURRENCY 3 C M
DISPENSED PRICE AMOUNT R M
DISPENSED PAID CURRENCY 3 C M
DISPENSED PRICE AMOUNT R M
DRUG SENSITIVITY PARAM C O
LAB TEST RESULTS PARAM CAG O
RESULTS AG M
TIME SAMPLE 12 D M
LAB RESULT AG M
LAB RESULT UNITS C M
LAB RESULTS VALUE R M
NORMAL RANGE 1 B M
REF LOWER LIMIT R O
REF LOWER LIMIT UNITS C M
REF LOWER LIMIT VALUE R M
REF UPPER LIMIT R O
REF UPPER UNITS C M
REF UPPER VALUE R M
IMAGE PARAM AG O
COMPRESSION TYPE C M
IMAGE VALUE BS M
BINARY DATA PARAM BS M
REQUEST PARAM CAG O
PREFERRED DATE 12 D M
PLANNED DATE 12 D M
DIAGNOSIS PARAM 5 B O
PROCEDURE PARAM CAG O
PROCEDURE CODE C M
GENERIC PROCEDURE CODE C M
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O

© BSI 06-1999 81
ENV 12018:1997

Table F.1 — Data dictionary

TITLE FIELD FIELD TYPE M
LENGTH O

WRITE SEC ATTRIBUTE B O

UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID RT O

LIMITED EMERGENCY DATA SET AG O

EMERGENCY DATA BIT MAP 20 B M
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 RT O
PLACE/PERSON 2 RT O
PLACE/PERSON 3 RT O
PERSON 3 TEXT 30 S O
SECURITY LEVELS 1 CAG O
READSECATTRIBUTE B O
WRITE SEC ATTRIBUTE B O
UPDATE SEC ATTRIBUTE B O
ERASE SEC ATTRIBUTE B O
COMPRESSION METHOD RT O
OBJECT SECURITY ATTRIBUTES AG O
SIGNATURE ALGORITHM ID RT O
SIGNATURE KEY ID RT O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID RT O
ENCRYPTION KEY ID RT O

Annex G (informative)
EDIFACT representation of a sample of data objects
This European Prestandard defines the data structure of objects communicated to/from intermittently
connected devices. ASN.1 syntax is proposed in Annex B, Annex C, and Annex D for several reasons,
amongst them the fact that the object-oriented syntax allows a comprehensive and compact description of
a large number of possible data structures in a specific device whilst maintaining maximum flexibility,
according to various needs of the users of the standard. Another feature of the ASN.1 is that it allows for a
very compact coding according to ISO 8825:1990, very important for many machine readable cards where
memory space is a serious limiting factor.

82 © BSI 06-1999
 ENV 12018:1997

On the other hand EDIFACT syntax has been used widely to define messages between a variety of health
informatics systems for both clinical and administrative purposes due to its relative simplicity in
implementation and to the relatively wide spread knowledge of its use. It is very likely that data from ICDs
transferred according to this pre-standard will in many cases also be utilised in various applications that
will communicate with other health information systems using EDIFACT messages.
In order to facilitate the understanding of how such messages may be developed and the relation between
the ASN.1 format and the EDIFACT syntax description, the following text has been prepared.
The EDIFACT message outlined herein is not to be regarded as a standard; only as an example
to illustrate certain points of such implementations.
The actual future standardisation of EDIFACT messages for health care follows other routes and priorities
and it is specifically not recommended that particular ICD EDIFACT messages are created at this point.
The ICD data will however be available for use by several applications that need to create EDIFACT
messages according to current and future standards in various fields.
Most of the data objects of this European Prestandard may be transferred to EDIFACT syntax with few
problems, particularly when the possible variability of the standard has been reduced to a real life
implementation profile, making selections among the many options. There are however a few structures
that can not be correctly described in EDIFACT and some of these are pointed out below.
For the purpose of this exercise the scenario of data from a card designed to be used in an emergency
situation will be used. Data considered will primarily be used in identifying the individual, his carer,
payment provisions in terms of the E111 document and the very limited clinical emergency data set from
the European Emergency Health Care Card. For the sake of simplification this data and the other data
contained within the device have no access restrictions.
To conform to this European Prestandard the whole ICD-application should be considered to conform when
transferring the relevant data objects to the ICD-application. Assume that this application requires to
transfer data to another system for further consideration. It may for instance be the case that the
ICD-system is located in an ambulance and that the data from the emergency card is subsequently going
to be transferred to the nearby hospital using radio link and EDIFACT message syntax.
The relevant objects using the ASN.1 format are considered first. A hypothetical Emergency Card Data Set
is created from the relevant objects of the standard to encompass the totality of the data needed for this
application. The EmergencyCardDataSet used in this illustration is not itself part of the prestandard but
its component objects are taken directly from the Prestandard and reproduced here to provide a complete
illustration.
EmergencyCardDataSet 4 SET
{
RecordPerson [0]
RecPersVariableID [1]
ContactPerson [2]
Responsible Physician [3]
PaymentProvisions [4]
LimEmergDataSer [5]
}

{
RecordPerson [0]
MajorRecordIdentifier [0]
mII [0] NUMERIC STRING DEFAULT 80
(SIZE(2)),
issuerCountry [1] Country,
issuerIdentifier [2] NUMERIC STRING (SIZE(5)),
checkdigit [3] NUMERIC STRING (SIZE(1)),
-- Calculated according to Luhn
recordIdNumber [4] EvolRecordIdentifier
AlternativeRecordIdentifiers[1]
SocialSecurityNo [0]
mII [0] NUMERIC STRING DEFAULT 80

© BSI 06-1999 83
ENV 12018:1997

(SIZE(2)),
issuerCountry [1] Country,
issuerIdentifier [2] NUMERIC STRING (SIZE(5)),
checkdigit [3] NUMERIC STRING (SIZE(1)),
-- Calculated according to Luhn
recordIdNumber [4] EvolRecordIdentifier

RecordIdVerification [2]
RecordPersonName [0] Fullname,
DateOfBirth [1] Date,
SexAtBirth [2] OCTET STRING (SIZE(1),
-- ISO 5218
PlaceOfBirth [3] Place
[4] AccessoryAttributes OPTIONAL

RecPersVariableID [1]
Address [0] Address OPTIONAL,
PreviousAddresses [1] SEQUENCE OF Address OPTIONAL,

Telecom [2] Telecom OPTIONAL,

Preferred Languages [3] CodedData OPTIONAL,
MaidenName [4] OPTIONAL,
PreviousSurname [5] OPTIONAL,
OtherNames [6] OPTIONAL,
[7] AccessoryAttributes OPTIONAL

ContactPerson [2]
name [0] Fullname,
ContactTelno [1] Telecom,
comment [2] OCTET STRING(SIZE(0..20))
OPTIONAL
[3]AccessoryAttributes OPTIONAL

HealthCarePerson [3]
HCPCountry [0] Country
HCPIdNo [1] NumericString (SIZE(1..21)),
HCPName [2] Fullname,
HCPRelationCode [3] CodedData OPTIONAL,
-- This is a code that would indicate things like
-- Primary responsible General Practitioner Specialist,
-- consultant, etc.
HCPClass [4] Sequence of BOOLEAN,hcpProfession
[5] SEQUENCE OF HcpProfCode OPTIONAL,
-- This will allow national codes for exact definitions of
-- various HCP groups.
HCPEmploymentNo [6] BitString OPTIONAL,
HCPEmploymentData [7] SEQUENCE OF CodedData OPTIONAL

PaymentProvision[4]
PaymentBodyID [1] SEQUENCE
PaymentBodyCountry [0] Country,
-- This represents the country of the Payment
-- BodyNumber
-- The country of address may be different

84 © BSI 06-1999
 ENV 12018:1997

PaymentBodyNumber [1] OCTET STRING(SIZE(1..9))

PaymentBodyName [2] OCTET STRING(SIZE(0..20)),
PaymentBodyAddress [3] SEQUENCE
[0]Address
[1]PostCode
[2]Country
PaymentBodyTelecom [4] Telecom,
Policies [5] SET OF Policy,

Policy 4 SET
PolicyIdNo [0] OCTET STRING(SIZE(0..21))
MemberNo [1] OCTET STRING(SIZE(0..15))
OPTIONAL
CoveredPersonConditions [2] SET OF PersonCondition,

PersonCondition 4 SEQUENCE
RecPersPointer [0]RecPersPointer,
Conditions [1] SET OF Condition

Condition 4 SEQUENCE
ObligatoryStatus [0] BOOLEAN OPTIONAL,
-- True means obligatory
CareCoverageCode [1] SET OF CoverageCode
OPTIONAL,
CareCoverageText [2] OCTET STRING (SIZE(0..20)
OPTIONAL
CoverageAreas [3] SET OF Country OPTIONAL
PaymentLevel [4] SEQUENCE
LowerLimitCoverage [0] Money OPTIONAL,
-- The value above which provisions are valid
UpperLimitCoverage [1] Money OPTIONAL,
-- The value under which provisions are valid
BenefitsRate [2] INTEGER OPTIONAL,
-- Percentage of coverage
SetPrice [3] BOOLEAN OPTIONAL,
-- True means a SetPrice (fixed for the service exists)
SetPricevalue [4] MONEY OPTIONAL
ThirdParty [5] BOOLEAN OPTIONAL,
-- True means the payment body pays direct
EmploymentStatus [6] SET OPTIONAL,
Employed [0] BOOLEAN,
SelfEmployed [1] BOOLEAN,
EmployedPensionabl [2] BOOLEAN,
SelfEmployedPensionable [3] BOOLEAN
-- True means status applicable according to ECU
-- E 111 form
AuthorisationReq [7] BOOLEAN OPTIONAL,
-- True means authorisation by payer required.

StartDate [5] Date OPTIONAL,

EndDate [6] Date OPTIONAL,

© BSI 06-1999 85
ENV 12018:1997

EmergencyData [5]
EmergencyDataBitMap [0] SEQUENCE OF BOOLEANS
Asthma [0]
HeartDisease [1]
EpilepsyFits [2]
NeurologicalDisorder [3]
Haemophilia [4]
ClottingDisorder [5]
Diabetes [6]
Glaucoma [7]
DialysisTreatment [8]
Transplant [9]
MissingOrgan [10]
PacemakerInSitu [12]
AntipsychoticMedication [13]
Anticonvulsants [14]
Antiarrythmics [15]
BloodPressureDrugs [16]
Anticoagulants [17]
AntidiabeticAgents [18]
Antihistamines [19]
[1] AccessoryAttributes OPTIONAL
The data dictionary for such an implementation is illustrated in Table G.1.
Table G.1 — Data dictionary illustration
TITLE FIELD FIELD TYPE M
LENGTH O
RECORD PERSONS CAG M
MAJOR RECORD PERSON AG M
MAJOR RECORD IDENTIFIER AG M
MAJOR RECORD PERSON MII 2 R M
MAJOR RECORD PERSON COUNTRY 3 C M
MAJOR RECORD PERSON ISSUER ID 5 R M
MAJOR RECORD PERSON CHECK DIGIT 1 R M
MAJOR RECORD PERSON RECORD ID NUMBER 21 S M
MAJOR RECORD PERSON SOCIAL SECURITY NUMBER AG O
MAJOR RECORD PERSON SOCIAL SECURITY NUMBER MII 2 R M
MAJOR RECORD PERSON SOCIAL SECURITY NUMBER 3 C M
COUNTRY
MAJOR RECORD PERSON SOCIAL SECURITY NUMBER 5 R M
ISSUER ID
MAJOR RECORD PERSON SOCIAL SECURITY NUMBER 1 R M
CHECK DIGIT
MAJOR RECORD PERSON SOCIAL SECURITY NUMBER 21 S M
RECORD ID NUMBER
MAJOR RECORD PERSON RECORD ID VERIFICATION AG M
MAJOR RECORD PERSON FULLNAME AG M
MAJOR RECORD PERSON TITLE 7 S M
MAJOR RECORD PERSON SURNAME PREFIX 15 S M
MAJOR RECORD PERSON PREFERRED SURNAME 27 S M
MAJOR RECORD PERSON SURNAME 27 S O

86 © BSI 06-1999
 ENV 12018:1997

Table G.1 — Data dictionary illustration

TITLE FIELD FIELD TYPE M
LENGTH O

MAJOR RECORD PERSON SURNAME SUFFIX 15 S M

MAJOR RECORD PERSON PREFERRED FORENAME 27 S M
MAJOR RECORD PERSON FORENAME 27 S O
MAJOR RECORD PERSON DATE OF BIRTH 12 D M
MAJOR RECORD PERSON SEX AT BIRTH 1 C M
MAJOR RECORD PERSON PLACE OF BIRTH 15 S M
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 I O
PLACE/PERSON 2 I O
PLACE/PERSON 3 I O
PERSON 3 TEXT 30 S O
OBJECT SECURITY ATTRIBUTES AG O
SIGNATURE ALGORITHM ID I O
SIGNATURE KEY ID I O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID I O
ENCRYPTION KEY ID I O
CONTACT PERSONS AG
CONTACT PERSON NAME TITLE 7 S O
CONTACT PERSON NAME SURNAME PREFIX 15 S O
CONTACT PERSON PREFERRED SURNAME 27 S M
CONTACT PERSON SURNAME 27 S M
CONTACT PERSON SUFFIX 15 S O
CONTACT PERSON PREFERRED FORENAME 27 S M
CONTACT PERSON FORENAME 27 S M
CONTACT PERSON TELNO HOME 15 R O
CONTACT PERSON TELNO WORK 15 R O
CONTACT PERSON TELNO OTHER 15 R O
CONTACT PERSON FAXNO HOME 15 R O
CONTACT PERSON FAXNO WORK 15 R O
CONTACT PERSON X.400 ADDRESS 30 S O
CONTACT PERSON OTHER NETWORK ADDRESS 30 S O
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 I O
PLACE/PERSON 2 I O
PLACE/PERSON 3 I O
PERSON 3 TEXT 30 S O
OBJECT SECURITY ATTRIBUTES AG O

© BSI 06-1999 87
ENV 12018:1997

Table G.1 — Data dictionary illustration

TITLE FIELD FIELD TYPE M
LENGTH O

SIGNATURE ALGORITHM ID I O
SIGNATURE KEY ID I O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID I O
ENCRYPTION KEY ID I O
HEALTH CARE PERSON AG M
HEALTH CARE PERSON COUNTRY 3 C M
HEALTH CARE PERSON ID NUMBER 21 R M
HEALTH CARE PERSON NAME TITLE 7 S O
HEALTH CARE PERSON NAME SURNAME PREFIX 15 S O
HEALTH CARE PERSON PREFERRED SURNAME 27 S M
HEALTH CARE PERSON SURNAME 27 S M
HEALTH CARE PERSON SUFFIX 15 S O
HEALTH CARE PERSON PREFERRED FORENAME 27 S M
HEALTH CARE PERSON FORENAME 27 S M
HEALTH CARE PERSON RELATION CODE C O
HEALTH CARE PERSON CLASS 10 B M
HEALTH CARE PERSON PROFESSION SC O
HEALTH CARE PERSON EMPLOYMENT NO BS O
HEALTH CARE PERSON EMPLOYMENT DATA SC O
PAYMENT PROVISION AG M
PAYMENT BODY ID AG M
PAYMENT BODY COUNTRY C M
PAYMENT BODY NUMBER 9 S M
PAYMENT BODY NAME 20 S O
PAYMENT BODY ADDRESS AG O
PAYMENT BODY POSTAL ADDRESS S M
PAYMENT BODY EXT HEALTH CARE ADDRESS S M
PAYMENT BODY POST CODE 8 S M
PAYMENT BODY COUNTRY 3 C M
PAYMENT BODY TELECOM AG O
PAYMENT BODY TELNO 15 R O
PAYMENT BODY TELNO OTHER 15 R O
PAYMENT BODY FAXNO 15 R O
PAYMENT BODY X.400 ADDRESS 30 S O
POLICIES CAG M
POLICY AG M
POLICY ID NO 21 S M
MEMBER NUMBER 15 S O
COVERED PERSON CONDITIONS AG M
OBLIGATORY STATUS 1 B O
CARE COVERAGE CODE SC O
CARE COVERAGE TEXT 20 S O

88 © BSI 06-1999
 ENV 12018:1997

Table G.1 — Data dictionary illustration

TITLE FIELD FIELD TYPE M
LENGTH O
COVERAGE AREAS AG O
COVERED COUNTRIES SC O
PAYMENT LEVEL AG M
LOWER LIMIT COVERAGE CURRENCY 3 C O
LOWER LIMIT COVERAGE AMOUNT R O
LOWER LIMIT COVERAGE CURRENCY 3 C O
LOWER LIMIT COVERAGE AMOUNT R O
BENEFITS RATE I O
SET PRICE 1 B O
THIRD PARTY 1 B O
EMPLOYMENT STATUS 4 B O
AUTHORISATION REQUIRED 1 B O
START DATE 12 D O
END DATE 12 D O
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 I O
PLACE/PERSON 2 I O
PLACE/PERSON 3 I O
PERSON 3 TEXT 30 S O
OBJECT SECURITY ATTRIBUTES AG O
SIGNATURE ALGORITHM ID I O
SIGNATURE KEY ID I O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID I O
ENCRYPTION KEY ID I O
LIMITED EMERGENCY DATA SET AG O
EMERGENCY DATA BIT MAP 20 B M
ACCESSORY ATTRIBUTES AG O
DATE 1 12 D O
DATE 2 12 D O
PLACE/PERSON 1 I O
PLACE/PERSON 2 I O
PLACE/PERSON 3 I O
PERSON 3 TEXT 30 S O
OBJECT SECURITY ATTRIBUTES CAG O
SIGNATURE ALGORITHM ID I O
SIGNATURE KEY ID I O
DIGITAL SIGNATURE BS O
ENCRYPTION ALGORITHM ID I O
ENCRYPTION KEY ID I O
NR = Segment Number
LN = Length in bytes
TY = Data Type
END POS. = End Position
O/M = Optional or Mandatory

© BSI 06-1999 89
ENV 12018:1997

In the application illustrated by Table G.1 it is assumed that the implementors wish to conform to this
pre-standard and require the eventual ability to share data with other systems, thus designing their data
models as per the standard.
To be conformant with the original user requirement, the implementors will strip the data set of all
accessory attributes and security functions thereby providing the simplest system (with unprotected access
to data as already assumed). However they appreciate that the use of EDIFACT as the medium of
communication between the CAD and host renders certain data types inadmissible, so they will lose the
functionality of differential access to data. (Also if the system were to be implemented via a microprocessor
card with security functions then their application would not be able to access the bulk of the data on such
a card.) Furthermore, all data which is coded using coding systems not mandated by this standard will not
be interpreted by their application, and all fields with no upper limit defined within the standard will also
be inadmissible.
On these assumptions, the designed EDIFACT message between CAD and host is shown in Table G.2.
NOTE There exists the possibility for eight Boolean values per byte.
Table G.2 — EDIFACT message representation between CAD and host
NR DATA ELEMENT NAME LN TY END O/M
POS.

101 MAJOR RECORD PERSON MII 2 R 2 M

102 MAJOR RECORD PERSON COUNTRY 3 C 5 M
103 MAJOR RECORD PERSON ISSUER ID 5 R 10 M
104 MAJOR RECORD PERSON CHECK DIGIT 1 R 11 M
105 MAJOR RECORD PERSON RECORD ID NUMBER 21 S 31 M
106 MAJOR RECORD PERSON SOCIAL SECURITY 2 R 33 M
NUMBER MII
107 MAJOR RECORD PERSON SOCIAL SECURITY 3 C 36 M
NUMBER COUNTRY
108 MAJOR RECORD PERSON SOCIAL SECURITY 5 R 41 M
NUMBER ISSUER ID
109 MAJOR RECORD PERSON SOCIAL SECURITY 1 R 42 M
NUMBER CHECK DIGIT
110 MAJOR RECORD PERSON SOCIAL SECURITY 21 S 63 M
NUMBER RECORD ID NUMBER
111 MAJOR RECORD PERSON TITLE 7 S 70 M
112 MAJOR RECORD PERSON SURNAME PREFIX 15 S 85 M
113 MAJOR RECORD PERSON PREFERRED SURNAME 27 S 112 M
114 MAJOR RECORD PERSON SURNAME 27 S 139 0
115 MAJOR RECORD PERSON SURNAME SUFFIX 15 S 154 M
116 MAJOR RECORD PERSON PREFERRED 27 S 181 M
FORENAME
117 MAJOR RECORD PERSON FORENAME 27 S 208 O
118 MAJOR RECORD PERSON DATE OF BIRTH 12 D 220 M
119 MAJOR RECORD PERSON SEX AT BIRTH 1 C 221 M
120 MAJOR RECORD PERSON PLACE OF BIRTH 15 S 236 M
121 CONTACT PERSON NAME TITLE 7 S 243 O
123 CONTACT PERSON NAME SURNAME PREFIX 15 S 258 O
124 CONTACT PERSON PREFERRED SURNAME 27 S 285 M

90 © BSI 06-1999
 ENV 12018:1997

Table G.2 — EDIFACT message representation between CAD and host

NR DATA ELEMENT NAME LN TY END O/M
POS.
125 CONTACT PERSON SURNAME 27 S 312 M
126 CONTACT PERSON SUFFIX 15 S 327 O
127 CONTACT PERSON PREFERRED FORENAME 27 S 354 M
128 CONTACT PERSON FORENAME 27 S 381 M
129 CONTACT PERSON TELNO HOME 15 R 396 O
130 CONTACT PERSON TELNO WORK 15 R 411 O
131 CONTACT PERSON TELNO OTHER 15 R 426 O
132 CONTACT PERSON FAXNO HOME 15 R 441 O
133 CONTACT PERSON FAXNO WORK 15 R 456 O
134 CONTACT PERSON X.400 ADDRESS 30 S 486 O
135 CONTACT PERSON OTHER NETWORK ADDRESS 30 S 516 O
136 HEALTH CARE PERSON COUNTRY 3 C 519 M
137 HEALTH CARE PERSON ID NUMBER 21 R 540 M
138 HEALTH CARE PERSON NAME TITLE 7 S 547 O
139 HEALTH CARE PERSON NAME SURNAME PREFIX 15 S 562 O
140 HEALTH CARE PERSON PREFERRED SURNAME 27 S 589 M
141 HEALTH CARE PERSON SURNAME 27 S 616 M
142 HEALTH CARE PERSON SUFFIX 15 S 631 O
143 HEALTH CARE PERSON PREFERRED FORENAME 27 S 658 M
144 HEALTH CARE PERSON FORENAME 27 S 683 M
145 HEALTH CARE PERSON CLASS 10 B 694 M
146 PAYMENT BODY COUNTRY 3 C 697 M
147 PAYMENT BODY NUMBER 9 S 706 M
148 PAYMENT BODY NAME 20 S 726 O
149 PAYMENT BODY POSTAL ADDRESS 70 S 796 M
150 PAYMENT BODY EXT HEALTH CARE ADDRESS 175 S 941 M
151 PAYMENT BODY POST CODE 8 S 949 M
152 PAYMENT BODY COUNTRY 3 C 952 M
153 PAYMENT BODY TELNO 15 R 967 O
154 PAYMENT BODY TELNO OTHER 15 R 982 O
155 PAYMENT BODY FAXNO 15 R 997 O
156 PAYMENT BODY X.400 ADDRESS 30 S 1027 O
157 POLICY ID NO 21 S 1048 M
158 MEMBER NUMBER 15 S 1063 O
159 OBLIGATORY STATUS 1 B 1064 O
160 CARE COVERAGE TEXT 20 S 1084 O
161 SET PRICE 1 B 1085 O
162 THIRD PARTY 1 B 1086 O
163 EMPLOYMENT STATUS 1 B 1087 O
164 AUTHORISATION REQUIRED 1 B 1088 O
165 START DATE 12 D 1100 O
166 END DATE 12 D 1112 O
167 EMERGENCY DATA BIT MAP 3 B 1115 M

© BSI 06-1999 91
DD ENV
12018:1998
BSI — British Standards Institution
BSI is the independent national body responsible for preparing
British Standards. It presents the UK view on standards in Europe and at the
international level. It is incorporated by Royal Charter.

Revisions

British Standards are updated by amendment or revision. Users of

British Standards should make sure that they possess the latest amendments or
editions.

It is the constant aim of BSI to improve the quality of our products and services.
We would be grateful if anyone finding an inaccuracy or ambiguity while using
this British Standard would inform the Secretary of the technical committee
responsible, the identity of which can be found on the inside front cover.
Tel: 020 8996 9000. Fax: 020 8996 7400.

BSI offers members an individual updating service called PLUS which ensures
that subscribers automatically receive the latest editions of standards.

Buying standards

Orders for all BSI, international and foreign standards publications should be
addressed to Customer Services. Tel: 020 8996 9001. Fax: 020 8996 7001.

In response to orders for international standards, it is BSI policy to supply the

BSI implementation of those that have been published as British Standards,
unless otherwise requested.

Information on standards

BSI provides a wide range of information on national, European and

international standards through its Library and its Technical Help to Exporters
Service. Various BSI electronic information services are also available which give
details on all its products and services. Contact the Information Centre.
Tel: 020 8996 7111. Fax: 020 8996 7048.

Subscribing members of BSI are kept up to date with standards developments

and receive substantial discounts on the purchase price of standards. For details
of these and other benefits contact Membership Administration.
Tel: 020 8996 7002. Fax: 020 8996 7001.

Copyright

Copyright subsists in all BSI publications. BSI also holds the copyright, in the
UK, of the publications of the internationalstandardization bodies. Except as
permitted under the Copyright, Designs and Patents Act 1988 no extract may be
reproduced, stored in a retrieval system or transmitted in any form or by any
means – electronic, photocopying, recording or otherwise – without prior written
permission from BSI.

This does not preclude the free use, in the course of implementing the standard,
of necessary details such as symbols, and size, type or grade designations. If these
details are to be used for any other purpose than implementation then the prior
written permission of BSI must be obtained.

If permission is granted, the terms may include royalty payments or a licensing

agreement. Details and advice can be obtained from the Copyright Manager.
BSI Tel: 020 8996 7070.
389 Chiswick High Road
London
W4 4AL