Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://www.cplire.ru/rus/telemed/CEN251/TC_251Method.pdf Äàòà èçìåíåíèÿ: Tue Dec 10 19:02:32 2002 Äàòà èíäåêñèðîâàíèÿ: Tue Oct 2 10:13:36 2012 Êîäèðîâêà: Ïîèñêîâûå ñëîâà: http www.badastronomy.com bad tv foxapollo.html

EUROPEAN COMMITTEE FOR STANDARDIZATION COMITè EUROPèEN DE NORMALIS ATIO N EUROPäISCHES KOMITEE FýR NORMUNG

CEN/TC 251/N99-043
1999-05-27

CEN/TC 251

Health Informatics
Secretariat: SIS-HSS

TITLE/ SUBJECT:

prENV 13606-4: Health informatics - Electronic healthcare record communication - Part 4: messages for the exchange of information Revised final draft for formal vote
CEN/TC 251/WG I FOR FORMAL VOTE AT THE TC MEETING 1999-06-29

SOURCE: ACTION REQUIRED:

CEN/TC 251 Secretariat: SIS-HSS (Swedish Healthcare Standards Institution)
Mail address: Fax: Tel: Box 704 87 SE-107 26 Stockholm, Sweden +46(0)8 702 4915 +46(0)8 702 4916 TC Secretary: Karin Kajbjer Visiting and Courier mail: Hornsgatan 20 e-mail: karin.kajbjer@hss.se Web site: www.centc251.org


EUROPEAN PRESTANDARD PRèNORME EUROPèENNE EUROPäISCHE VORNORM
ICS 35.240.80

REVISED FINAL DRAFT prENV 13606-4
1999-05-27

English version

Health informatics - Electronic Healthcare communication Part 4: Messages for the exchange of information

This draft European Prestandard is submitted to CEN members for formal vote. It has been drawn up by the Technical Committee CEN/TC 251. 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. Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and shall not be referred to as a European Standard.

EUROPEAN COMMITTEE FOR STANDARDIZATION COMITè EUROPèEN DE NORMALISATIO N EUROPäISCHES KOMITEE FýR NORMUN G

Central Secretariat: rue de Stassart, 36

B-1050 Brussels

© 1999 CEN

All rights of exploitation in any form and by any means reserved worldwide for CEN national Members.

Ref. No. prENV 13606-4:1999 E


Page 2 prENV 13606-4:1999

CONTENTS
0. INTRODUCTION ............................................................................................................ 6 1. SCOPE........................................................................................................................... 7 2. NORMATIVE REFERENCES ........................................................................................ 9 3. DEFINITIONS............................................................................................................... 10 4. COMMUNICATION ROLES ......................................................................................... 17
4.1. General ................................ ................................ ................................ ................................ ..............................17 4.2. Communication roles for different messages ................................ ................................ ................................ .......17

5. COMMUNICATION REQUIREMENTS AND SCENARIOS ......................................... 19
5.1. Introduction ................................ ................................ ................................ ................................ ........................19 5.2. Transfer initiated by an EHCR source ................................ ................................ ................................ .................20 5.3. Transfer of care initiated by an EHCR destination ................................ ................................ ...............................21 5.4. Provision of a temporary service without a request from the EHCR source ................................ ..........................22 5.5. Provision of a temporary service following a request from the EHCR source ................................ .......................23 5.6. Provision of continuing care by two or more parties ................................ ................................ ............................24 5.7. Scenarios involving a third party ................................ ................................ ................................ .........................26

6. REQUIREMENTS AND GENERAL MESSAGE DESCRIPTIONS............................... 30
6.1. Conformance requirements ................................ ................................ ................................ ................................ 30 . 6.2. General Message Descriptions ................................ ................................ ................................ ............................30 6.3. Requirements common to all EHCR messages ................................ ................................ ................................ 31 .... 6.4. Specification of EHCR message information ................................ ................................ ................................ .......32 6.5. Provide EHCR Message ................................ ................................ ................................ ................................ 34 ..... 6.6. EHCR Extract ................................ ................................ ................................ ................................ ....................35 6.7. Original component complexes ................................ ................................ ................................ ...........................35 6.8. Data items ................................ ................................ ................................ ................................ ..........................44 6.9. Link set items ................................ ................................ ................................ ................................ .....................46 6.10. Selected component complexes ................................ ................................ ................................ .........................46 6.11. Empty record component ................................ ................................ ................................ ................................ 46 .. 6.12. Adding comments to items ................................ ................................ ................................ ...............................47 6.13. Request EHCR Message ................................ ................................ ................................ ................................ 47 ... 6.14. EHCR notification message ................................ ................................ ................................ ..............................48

7. DOMAIN INFORMATION MODEL............................................................................... 49
7.1. 7.2. 7.3. 7.4. Introduction ................................ ................................ ................................ ................................ ................49 Presentation of attributes from generalisations ................................ ................................ .............................49 EHCR communicating parties subsystem ................................ ................................ ................................ 51 .... EHCR message subsystem ................................ ................................ ................................ ..........................55


Page 3 prENV 13606-4:1999 7.5. 7.6. 7.7. 7.8. 7.9. 7.10. 7.11. 7.12. 7.13. EHCR structured record subsystem ................................ ................................ ................................ .............65 EHCR data item subsystem ................................ ................................ ................................ .........................82 EHCR link subsystem ................................ ................................ ................................ ...............................107 EHCR message component subsystem ................................ ................................ ................................ 112 ...... EHCR distribution rule subsystem ................................ ................................ ................................ .............119 Healthcare agent subsystem ................................ ................................ ................................ ...................123 Subclasses................................ ................................ ................................ ................................ .............134 Compound Types ................................ ................................ ................................ ................................ 143 .. Simple Data Types ................................ ................................ ................................ ................................147

ANNEX A. (INFORMATIVE) HOW TO READ THE MODELS ...................................... 148 ANNEX B. (INFORMATIVE) DRAFT XML DTDS FOR EHCR MESSAGES ................ 153 INDEX ............................................................................................................................. 175


Page 4 prENV 13606-4:1999

TABLE OF FIGURES
Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure 1. Illustration of EHCR message communications and communication role ................................ ...................18 2. General sequence of messages ................................ ................................ ................................ ..................19 3. Patient transfer initiated by an EHCR source ................................ ................................ .............................20 4. Transfer of care initiated by an EHCR destination ................................ ................................ .....................21 5. Service provision without a request ................................ ................................ ................................ ........... 22 6. Service provision following a request ................................ ................................ ................................ ....... 23 7. Continuing care by two parties ................................ ................................ ................................ ..................25 8. Indirect communication initiated by the recipient ................................ ................................ ......................26 9. Indirect communication initiated by the sender ................................ ................................ .........................27 10. Indirect communication initiated by the third party ................................ ................................ ..................28 11. GMD for the common structures applicable to all EHCR Messages ................................ .........................32 12. GMD for Specification of EHCR Information applicable to all EHCR messages ................................ 33 ...... 13. GMD Provide EHCR Message ................................ ................................ ................................ ................34 14. GMD EHCR Extract Component Hierarchy ................................ ................................ ............................36 15. GMD Folder - Original Component Complex ................................ ................................ .........................38 16. GMD Composition - Original Component Complex ................................ ................................ ................40 17. GMD Headed Section - Original Component Complex ................................ ................................ ........... 41 18. GMD Cluster - Original Component Complex ................................ ................................ ........................43 19. GMD Data Item ................................ ................................ ................................ ................................ 45 ..... 20. GMD Request EHCR Message ................................ ................................ ................................ ...............47 21. GMD EHCR Notification Message ................................ ................................ ................................ ......... 48 22. DIM - EHCR Message Top Level ................................ ................................ ................................ ........... 50 23. DIM - Communicating Parties Subsystem ................................ ................................ ...............................51 24. DIM - EHCR Message Subsystem ................................ ................................ ................................ .......... 55 25. DIM - EHCR Structured Record Subsystem ................................ ................................ ............................65 26. DIM - EHCR Data Item Subsystem ................................ ................................ ................................ ........ 82 27. DIM - EHCR Link Subsystem ................................ ................................ ................................ .............. 107 28. DIM - EHCR Message Component Subsystem ................................ ................................ ......................112 29. DIM - EHCR Distribution Rules ................................ ................................ ................................ ........... 119 30. DIM - Healthcare Agent Subsystem ................................ ................................ ................................ 126 ...... A.1. Representation of classes in DIM and GMD diagrams ................................ ................................ ......... 148 A.2. Representation of packages in diagrams ................................ ................................ ..............................148 A.3. Illustrations of classes A and B as specialisations of Class C ................................ ...............................149 A.4. Illustrations of classes A and B as specialisations of the abstract Class C ................................ ............. 149 A.5. Illustration of aggregation relationships ................................ ................................ ...............................150 A.6. Illustration of a composition relationship ................................ ................................ .............................151 A.7. Illustration of associations between classes ................................ ................................ ..........................151 A.8. Illustration of associations between packages ................................ ................................ ......................152 A.9. Illustrations of constraints on relationships ................................ ................................ ..........................152


Page 5 prENV 13606-4:1999

FOREWORD
This European Prestandard has been prepared by CEN/ TC 251 Health Informatics under mandate BC/CEN/03/255/97/23 by the European Commission and the European Free Trade Association. This is Part 4 of a multipart standard on Electronic Healthcare Record Communication. The multipart standard consists of the following parts: Part Part Part Part 1: 2: 3: 4: Extended Architecture Domain Term List Distribution Rules Messages for the Exchange of information

This Prestandard was drafted using the conventions of the ISO/IEC directive part 3. All annexes of Part 4 are Informative.


Page 6 prENV 13606-4:1999

0. INTRODUCTION
This European Prestandard provides a set of messages that enable the electronic transfer of healthcare record information between heterogeneous systems. These messages address the needs and capabilities of current healthcare record systems. They also take account of the more sophisticated requirements of future systems. A combination of the following factors provide the motivation for this European Prestandard: -- Many hospitals, clinics and doctors now store the healthcare records of their patients in an electronic form. Current electronic healthcare record systems are heterogeneous in nature. They store information in a variety of structures that differ in their levels of detail and sophistication. Some differences are idiosyncratic but others reflect variations in user requirements determined by organisational structures or clinical specialties. -- Timely availability of healthcare records is essential to the safe delivery of high quality healthcare. Healthcare professionals need access to a patient's healthcare record to inform their decisions. If necessary information is not available, this leads to errors, delays or repetition of procedures. The end results of missing information include health risks, inconvenience for the patient and expense for the service provider. -- During their lifetime patients are cared for by more than one healthcare professional. Patients may see a different healthcare profession when they move home, travel or require care out of the normal working hours of their usual physician. Patients may receive continuing care from a team of professionals or from a combination of specialists relevant. -- Timely availability of healthcare records requires communication between different healthcare professionals who care for the same patient. Since the professionals involved will often have different electronic healthcare record systems, these communications usually involve paper reports or unstructured electronic exchanges. The relative inaccessibility of information received in these forms detracts from the quality, completeness and usability of the electronic healthcare record. Implementation of the messages specified by this European Prestandard will: a) facilitate the transfer of electronic healthcare records or parts of these records; b) enable the communication of requests for transfer of electronic healthcare records; c) reduce the need for human intervention to manually duplicate entries in different healthcare record systems; d) minimise the time and effort required for the introduction of information interchange agreements that support the exchange of electronic healthcare record information; e) reduce the development effort required by suppliers to allow their systems to communicate with a wide range of other electronic healthcare record systems; f) reduce the cost of information interchange between clinical information systems. When implementing information exchange based on this European Prestandard, data security services, including confidentiality provisions, will need to comply with the laws in force in the different CEN member countries. Other European Prestandards currently under development address technical issues relating to meeting this need. This European Prestandard has been developed following the methods recommended in the CEN Report on "Medical Informatics - Methodology for the development of healthcare messages" (CR 12587:1996). However, in accord with the decisions of CEN TC251 WGI, a different modelling technique has been used. This is a subset of the Unified Modelling Language (UML) as documented in Annex A. This European Prestandard specifies messages in a syntax independent form. Its requirements for conformance define the minimum acceptable content and structure for these messages. Compliant messages can be developed in a variety of implementation syntaxes and these syntax specific implementations may be the subject of future Standards. This European Prestandard is directly relevant to suppliers of computer systems for use in hospitals, general practices, clinical departments and specialist clinics. Its provisions are also relevant to those planning, specifying, procuring or implementing information systems for use in departments, hospitals, general practices, clinical departments and specialist clinics.


Page 7 prENV 13606-4:1999

1. Scope
This European Prestandard specifies messages that enable exchange of electronic healthcare record information between healthcare parties responsible for the provision of clinical care to an individual patient. These messages allow information from an electronic healthcare record held by one health professional to be sent to another health professional. The messages specified by this European Prestandard can be used to convey: -- a complete copy of a patient's record as stored in one information system; -- parts of a patient's record that form a logically sound extract or summary of that record; -- parts of a patient's record used for updating a parallel record on another system. The primary purpose of these messages is to support the provision of care to individual patients. The availability of consistent, continuing clinical care, when and where it is needed, requires appropriate and unambiguous communication between clinical professionals. The messages specified by this European Prestandard are designed to meet this requirement by enabling users of different clinical information systems to exchange electronic healthcare record information. Implementation of these messages will therefore assist the maintenance of timely and appropriate patient records. This European Prestandard considers two distinct properties of electronic health record communication. a) Readability - Communication of information in a form that can be rendered human-readable by the receiving system. If the exchange of electronic healthcare record information is to support individual patient care, clinicians using the receiving system need to be able to read and understand the transferred information.

b) Processability - Communication of information that can be incorporated into a record held by the receiving system in a way that enables it to be processed and retrieved as an integral part of that record. The benefits of electronic healthcare records include retrieval and processing for decision support, audit and research. If these benefits are to be fully realised, systems need to be able to process received information in ways that, while recognising the source of that information, are otherwise consistent with the processing of locally recorded information. The European Prestandard specifies messages that permit exchange of electronic health record information with different levels of structure. The least structured level is sufficient to enable any receiving system to render the information in a human-readable form. The more structured levels enable information to be transferred in a manner that facilitates subsequent retrieval and processing. The ability of communicating systems to achieve a particular level of interoperability by using these messages depends on: -- the compatibility of the structures in which the systems store patient records; -- the mappability of different forms of representation used by those systems (e.g. languages, terminologies and coding schemes); -- the level of trust between the communicating parties. These factors will therefore determine how the messages specified by this European Prestandard are used. This European Prestandard takes account of the following issues related to the confidentiality, source and status of the transferred information. -- Distribution ­ The messages include provisions for conveying and referencing distribution rules in the form specified in Part 3 of this European Prestandard. These distribution rules are intended to govern subsequent distribution of information. These rules may be applied to the entire message or to individual components within the message. This European Prestandard does not mandate a particular mechanism for the enforcement of distribution rules. -- Attribution ­ The messages support communication of attribution details regarding the originator and time of origin of information. Attribution information, including digital signatures, may be applied to the entire message or to individual components within the message. This European Prestandard does not mandate a particular mechanism for secure verification of digital attribution information. However, the algorithm specified in ENV12388 may be used for this purpose subject to the agreement of the communicating parties. -- Integration ­ The messages support the communication of information in a way that allows receiving systems to distinguish new information from information that they have already received.


Page 8 prENV 13606-4:1999 Specific security requirements and the mechanisms to be used to meet these requirements are outside the scope of this European Prestandard. Implementers of the messages specified by this European Prestandard should ensure that the security mechanisms used satisfy national and international legislation, user requirements and ethical guidance. The messages specified by this European Prestandard are general in nature. They meet the requirements for transferring electronic healthcare record information in a manner appropriate to a wide-variety of situations covering all clinical professions and specialties. However, to maximise the processability of communicated information for particular purposes, a specific profile of the messages specified in this European Prestandard may be required. A profile may restrict the degrees of freedom inherent in the general message and may specify additional types of data item that can be used within a communicating community. The messages described in this European Prestandard are based on the architectural principles stated in Part 1 of this European Prestandard. This does not preclude the use of this message for communications between systems that do not conform to Part 1. The message applies the architectural principles in a way that facilitates clinically safe communication even between systems with widely different record structures. However, the faithfulness of communication of the structural richness of an electronic record will be greater in the case of systems that comply with or are closely aligned with all parts of this European Prestandard. The messages specified by this European Prestandard are primarily aimed at conveying character-based information between systems. The messages also provide for references to binary objects, which may form part of an EHCR. However, the European Prestandard does not specify the format of such binary objects, nor does it specify the methods by which they shall be communicated or made available to a receiving system. Communication of EHCR information is often associated with specific requests for intervention by or advice from the recipient of this information. The response from the recipient of EHCR information may similarly be accompanied by a specific report that they have undertaken (or have accepted responsibility for undertaking) a requested service. The messages specified in this European Prestandard are not designed for communication of these requests or reports, as these are standardised by previous European Prestandards 1. However, if such communications require the exchange of detailed EHCR information the messages or components defined in this European Prestandard may be used for that purpose. To facilitate this, the "EHCR extract" class specified in this European Prestandard may be used in place of the "Clinical Information" class in messages specified in previous European Prestandards for healthcare messages. The messages specified by this European Prestandard are not designed for communication with intermittently connected devices such as patient data cards. However, due account has been taken of the relevant European Prestandard covering this domain (ENV12018). These messages are not validated for the exchange of EHCR information for other purposes such as administration, resource allocation, research or quality monitoring.

1

ENV1613 "Medical Informatics - Messages for exchange of laboratory information", ENV12538 "Medical Informatics - Messages for patient referral and discharge" and ENV 12539 "Medical Informatics - Request and report messages for diagnostic service departments".


Page 9 prENV 13606-4:1999

2. Normative References
This European Prestandard incorporates by dated or undated references, provisions from other publications. These normative references are cited in the appropriate places in the text and the publications are listed hereafter. For dated references, subsequent amendments and revisions of any of these publications apply to this European Prestandard only when they are incorporated in it by amendment and revision. For undated references the latest edition of the publication referred to, applies. ISO639:1988 ISO6523 ISO2382-4:1987 ISO5281:1977 ISO/IEC 7826-1 ISO/IEC 7826-2 ISO8601: 1988 ENV 1613:1995 ENV 1614:1995 ENV 12018:1997 ENV 12265 ENV 12381:1996 ENV 12388:1996 ENV 12435 ENV 12537-1:1997 ENV 2537-2:1997 Symbols for languag es, geographical areas and authorities Data interchange - Structure for the identification of organizations. Information processing - Vocabulary Part 4: Organisation of data Information interchange - Representation of h uman sexes Information technology ­ General structure for the interchange of code values ­ Part 1: Identification of coding schemes Information technology ­ General structure for the interchange of code values ­ Part 2: Registration of coding schemes Data elements and interchange formats - Information interchange - Representation of dates and times Medical informatics - Messages for exchange of laboratory information Medical informatic s - Structure for nomenclature, classification, and coding of properties in clinical laboratory sciences Medical informatics - Identification, administrative and common clinical data structure for Intermittently Connected Devices used in healthcare (including machine readable cards) Medical informatics - Electronic healthcare record architecture Medical informatics - Time standards for healthcare specific problems Medical informatics - Algorithm for Digital Signature Services in Health Care Medical informatics - Expression of the results of measurements in health sciences Medical informatics - Registration of information objects used for EDI in healthcare - Part 1: The Register Medical informatics - Registration of information objects used for EDI in healthcare - Part 2: Procedures for the registration of information objects used for electronic data interchange (EDI) in healthcare Medical in formatics - Messages for patient referral and discharge Medical informatics - Request and report messages for diagnostic service departments CEN Report: Medical informatics - Methodology for the development of healthcare mes sages Medical informatics - Messages for the exchange of healthcare administrative information Electronic Healthcare Record Communication ­ Extended Architecture Electronic Healthcare Record Communication ­ Term List Electronic Healthcare Record Communication ­ Distribution Rules Health Informatics - Messages for The Exchange of Information on Medicine Prescriptions

ENV 12538:1997 ENV 12539:1997 CR 12587:1996 ENV 12612:1997 prENV 13606-1 prENV 13606-2 prENV 13606-3 prENV 13607


Page 10 prENV 13606-4:1999

3. Definitions
For the purpose of this European Prestandard, the following definitions apply:

3.1.
annotation identifier a means to summarise the key contextual information pertaining to a component complex or a data item. NOTE within Part elementary retrieval of the ann otations are added to the record component as a coded value. The component annotation measure 2 provides a means to summarise in a standardised form the key contextual information pertaining to an or compounded entry, primarily to assist in its safe interpretation. A secondary purpose is to facilitate the relevant entries by computerised searches. See Part 2 for more details.

3.2.
attestation a binding of the healthcare agent (with digital signature) to a unit of information content to confirm the acceptance of the content.

3.3.
clinical information information about a patient, relevant to the health or treatment of that patient, that is recorded by or on behalf of a healthcare professional. NOTE Clinical information about a patient may include information about the patient's environment or about related people where this is relevant.

3.4.
cluster original component complex used to aggregate data items and/or other clusters to represent a compound concept. EXAMPLES A blood pressure measurement consisting of systolic and diastolic pressure, a collection or clo sely related clinical findings, results of a battery of laboratory investigations, a treatment schedule consisting of several individually specified preparations or dosages.

3.5.
code meaning element within a coded set. EXAMPLE "Paris Charles-De-Gaulle" which is mapped on to the three-letter abbreviation "CDG" by the coding scheme for three-letter abbreviations of airport names.

3.6.
code value result of applying a coding scheme to a code meaning. EXAMPLE "CDG" as the representation of "Paris Charles-De-Gaulle" in the coding scheme for three-letter representations of airport names.

3.7.
coding scheme collection of rules that maps the elements of one set on to the elements of a second set.

3.8.
communicating community geographically or organisationally defined grouping of healthcare parties that agree to communicate, subject to an agreed set of constraints or guidelines.

3.9.
component name attribute that is used to provide a title or label to an instance of an EHCR message component.


Page 11 prENV 13606-4:1999

3.10.
component name category attribute that provides a high level indication of the general nature of the content of a record component. NOTE 1 These categories are assigned by or derived from th e EHCR, depending upon the nature of the data or the process being carried out. NOTE 2 See Part 2 for permissible values for different types of record component.

3.11.
composition original component complex that contains a set of record components relating to one time and place of care delivery, a single session of recording or a single document included in the EHCR. EXAMPLES Consultation note, operation note, discharge summary, vital signs chart, laborat ory report.

3.12.

data item single unit of data that in a certain context is considered indivisible. NOTE 1 The content of data is dependent upon the structure and type of the identified data type.

NOTE 2 The context may mean that this component's content may represent for example either a single clinical statement (see Part 2) or a single complex type such as an X-ray report. Its granularity is determined by the context.

3.13.

digital signature data appended to, or a cryptographic transformation of, a data unit that allows a recipient of a data unit to prove the source and integrity of the unit and protect against forgery e.g. by the recipient. [ISO 7498-2]

3.14.
distribution rule logical concept or rule intended to convey and govern distribution . NOTE The form of representation of EHCR distribution rules is the subject of Part 3 of this Pre standard.

3.15.
distribution rule reference attribute referencing a distribution rule.

3.16.
domain information model DIM conceptual model describing common concepts and their relationships for communication parties required to facilitate exchange of information between these parties within a specific domain of healthcare.

3.17.
electronic healthcare record EHCR healthcare record in computer readable form.

3.18.
electronic healthcare record architecture a set of principles governing the logical structure and behaviour of electronic healthcare records that enables communication of the whole or part of a healthcare record.

3.19.
EHCR destination communicating party that is the destination or intended of EHCR information that is requested, transferred or acknowledged in an EHCR message.


Page 12 prENV 13606-4:1999

3.20.
EHCR extract EHCR message component representing the entirety of a patient's electronic healthcare record or that part of the record contained within a particular instance of an EHCR message.

3.21.
EHCR source communicating party that is the source or intended source of EHCR information that is requested, transferred or acknowledged in an EHCR message.

3.22.

EHCR message generalisation applicable to all messages specified by this Prestandard for the purposes of requesting or providing EHCR information or for notifying another communicating party about this process.

3.23.
EHCR message component part of an electronic healthcare record contained within an EHCR message in a form that renders it identifiable for the purposes of referencing and revision. NOTE This European Prestandard specifies two types of EHCR message component. These are the "EHCR extract" and the "record component".

3.24.
EHCR message related agent communicating party other than the source, intended source, destination or intended destination of EHCR information. EXAMPLES Intermediary, forwarding agent, copy destination, trusted third party authenticating a request or provide EHCR message.

3.25.

EHCR notification message message specified by this Prestandard for the purpose of conveying notifications about the sending, receipt, rejection or acceptance of a request EHCR message or provide EHCR messages.

3.26.
EHCR source communicating party that is the source or intended source of EHCR information that is requested, transferred or acknowledged in an EHCR message.

3.27.
EHCR system system for recording, retrieving and manipulating information in electronic healthcare records.

3.28.
folder original component complex used to group record components collected and/or recorded during several contacts with a patient. NOTE A folder may include information collected and recorded at different times and by different people.

3.29.
general message description GMD subset of a domain information model prescribing the information content and semantic structure of a message used to meet one or more identified information interchange requirements. NOTE General message descriptions are independent of the syntax used for constructing an actual message. They provide statement of the information interchange requirements in a form that can be implemented using different syntaxes.


Page 13 prENV 13606-4:1999

3.30.
headed section original component complex representing a sub-division within a composition, the contents of which have a common theme or are derived through the same healthcare process.

3.31.
healthcare agent healthcare person, healthcare organisation, healthcare device or healthcare software component that performs a role in a healthcare activity.

3.32.

healthcare agent function reference to a healthcare agent that identifies them only in terms of their function in relation to another healthcare agent and not by an individual name or identifier. NOTE The healthcare agent function allows a record component or message to refer to healthcare agents who are not individually identified at the time of recording. EXAMPLE To send a message to the "duty doctor" in an emergency department, to indicate the contact details for a specialist's secretary, to distinguish between the parts of a pre-operative assessment applicable to the "anaesthetist".

3.33.
healthcare agent in context one or more healthcare agents related together in a specified manner for the purposes of performing a particular role in a healthcare activity.

3.34.
healthcare agent in context reference reference which uniquely identifies a healthcare agent in context. NOTE: Use of a healthcare agent in context reference depends on the existence of shared information describing the healthcare agent in context to which it refers.

3.35.
healthcare agent role role played by a healthcare agent (or by a healthcare agent in context) in a healthcare activity. EXAMPLES Originator or author of a record entry, reque ster of a service, provider of a service, sender of a message, recipient of a message, person signing a message or record entry.

3.36.
healthcare agent relationship relationship between two healthcare agents. NOTE 1 A healthcare agent relationship may apply for a specified period of time.

EXAMPLE 1 Employee / employer NOTE 2 A healthcare agent relationship may be specific to a particular healthcare agent role.

EXAMPLE 2 On behalf of / re sponsible for.

3.37.
healthcare device device or equipment involved in the direct or indirect provision of healthcare services to an individual or to a population. EXAMPLE ECG machine, auto-analyse r, syringe pump.


Page 14 prENV 13606-4:1999

3.38.
healthcare organisation organisation involved in the direct or indirect provision of healthcare services to an individual or to a population. NOTE Groupings or subdivi sions of an organisation, such as departments or sub-departments, may also be considered as organisations where there is need to identify them.

3.39.
healthcare party organisation or person involved in the direct or indirect provision of healthcare services to an individual or to a population.

3.40.
healthcare person person involved in the direct or indirect provision of healthcare services to an individual or to a population. NOTE A carer or the patient may be a healthcare person. This enables the role of the patient in providing his/her own care to be recorded. EXAMPLE Primary care physician, dentist, nurse, social worker, pharmacist, medical secretary.

3.41.
healthcare record repository of information regarding the health of a subject of care.

3.42.
healthcare service service provided with the intention of directly or indirectly improving the health of the person or populations to whom it is provided.

3.43.
healthcare software software component involved in the direct or indirect provision of healthcare services to an individual or to a population. EXAMPLE: EHCR system, decision support software, viewing tools.

3.44.
implementable message specification IMS specification of a general message description in a particular message syntax.

3.45.
interchange format specification of a message type according to a given message syntax, covering the identification of the message type components, their arrangement, representation and interrelationships.

3.46.
International Coding Scheme Identifier ICSI unique permanent identifier of a coding scheme as specified by ISO 7826-1. [ISO7826]

3.47.
link set item record component that provides a means of associating two or more other instances of EHCR message component, and specifying the relationship between them. NOTE The link set item is used to convey a collection of one or more link items (defined in accordance with Part 1 of this Prestandard) for which both the link source component and relationship are identical.


Page 15 prENV 13606-4:1999

3.48.
message profile specification derived from an implementable message specification by selecting its optional elements, appropriate to the specific business requirements of the communicating parties.

3.49.
message syntax system of rules and definitions specifying the basic component types of messages, their interrelationships and their arrangement.

3.50.

message type identified, named and structured set of functionally related information which fulfils a specific business purpose.

3.51.
multiplicity expression of the number of instances of one class that may be part of or associated with another class. NOTE The term cardinality has been used in earlier related European Prestandards. However, following the decision to use UML as the modelling notation the term multiplicity is more appropriate. In UML "cardinality" refers to the actual number of members of a set of relations. The term "multiplicity" is used to refer to the "allowable cardinalities" and this is the sense in which this concept is represented in this Prestandard.

3.52.
organisation unique framework of authority within which a person or persons act, or are designated to act towards some purpose. NOTE Groupings or subdivisions of an organisation may also be considered as organisations where there is need to identify them for information interchange. [ISO 6523-1984]

3.53.
original component complex OCC record component representing an aggregation of other record components that is determined by the time and situation in which they were originally added to the EHCR.

3.54.
original information context topological placement and position of data in the EHCR as entered by an authoring healthcare agent, be that person, software or device.

3.55.
provide EHCR message message specified by this Prestandard for the purpose of conveying EHCR information between two healthcare agents.

3.56.
record component component part of an electronic healthcare record that is identifiable for the purposes of referencing and revision.

3.57.
request EHCR message message specified by this Prestandard for the purpose of conveying a request for EHCR information between two healthcare agents.


Page 16 prENV 13606-4:1999

3.58.
selected component complex SCC record component representing an aggregation of other record components that is not determined by the time or situation in which they were originally added to the EHCR. NOTE Selected component complexes are used to provide alternative views or groupings of records. They can represent the record as viewed at a particular time or they can represent groupings of clinically or logically associated record components.

3.59. Abbreviations
The following abbreviations are used for the terms defined in this European Prestandard. DIM DTD EHCR GMD GP HGMD ICSI IMS MIG OCC SCC UML XML Domain Information Model Document Type Definition Electronic Healthcare Record General Message Description General Practitioner Hierarchical General Message Description International Coding Scheme Identifier Implementable Message Specification Message Implementation Guide Original Component Complex Selected Component Complex Unified Modelling Language Extensible Markup Language


Page 17 prENV 13606-4:1999

4. Communication roles
4.1. General
This clause defines the communication roles applicable to the exchange of electronic healthcare record in a manner that is compliant with this European Prestandard. It establishes the relationships between the communication roles and the General Message Descriptions (GMDs), as well as the relationships between the messages defined by the GMDs.

4.2. Communication roles for different messages
The following ­ ­ ­ messages are defined in this European Prestandard: request EHCR message; provide EHCR message; EHCR notification message.

For each of these messages there are two primary communication roles: ­ The message originator role (the sender) ­ The message destination role (the intended recipient) During a series of exchanges relating to a single EHCR transfer, the same healthcare party may be both a sender and recipient of messages. For example, the originator of a request will be the recipient of a response to that request. Rather than considering the role in respect of a particular message, this European Prestandard refers to healthcare parties according to the roles played in a sequence of messages related to one EHCR transfer. These roles are: ­ The EHCR source ­ the current holder of EHCR information that is requested, transferred or acknowledged. ­ The EHCR destination ­ the requester or recipient of the EHCR. The same healthcare party may act as an EHCR source and an EHCR destination in respect of different messages. For example, the EHCR destination for one provide EHCR message may be the EHCR source for another provide EHCR message. Other healthcare parties may play secondary roles in the communication of the EHCR. Examples of these roles include: ­ Acting as a clearinghouse or forwarding agent. ­ Validating the source of the EHCR message. ­ Confirming the right of the EHCR destination to receive the EHCR for a patient. Healthcare parties undertaking these roles are referred to in this European Prestandard as EHCR message related agents. The involvement of EHCR message related agents depends on the procedures agreed for exchanging EHCR messages within a communicating community. This European Prestandard enables but does not require the involvement of EHCR message related agents and it does not specify the details of the roles an EHCR message related agent may play. Table 1 notes the communication roles that different parties may play in relation to the messages described in this Prestandard. Figure 1 provides a graphical representation of this information. The following notes apply to Figure 1 and outline the different types of EHCR notification message that each party may send or receive. The decision on which, if any, of these notifications should be used is dependent on the business process in a communicating community and is not subject to any normative provisions in this Prestandard. NOTE 1 NOTE 2 An EHCR source may notify an EHCR destination of acceptance or rejection of a request EHCR message. An EHCR destination may notify an EHCR source of acceptance or rejection of a provide EHCR message.

NOTE 3 Either an EHCR destination or EHCR source may notify a third party (an EHCR message related agent) when they send, receive, accept or reject of a message. NOTE 4 An EHCR message related agent may forward a notification from an EHCR destination or EHCR source to another communicating party.


Page 18 prENV 13606-4:1999 Table 1. Associations between Communicating parties, communicating party roles and messages Communicating party (actor no.) 1. Healthcare party acting as EHCR source 2. Healthcare party acting as EHCR destination 3. Healthcare party acting as EHCR related agent (e.g. clearing house or forwarding agent ) Origi- DestiMessages nating nation role role X provide EHCR message EHCR notification message X request EHCR message EHCR notification message X request EHCR message EHCR notification message X provide EHCR message EHCR notification message X provide EHCR message EHCR notification message X request EHCR message EHCR notification message X provide EHCR message EHCR notification message X request EHCR message EHCR notification message To actor no. 2,3 2,3 1,3 1,3 2 1 1 2 From actor no.

Request EHCR message Provide EHCR message EHCR notification message (note 1) EHCR notification message (note2)

EHCR source
message

EHCR destination

(note

Request EHCR EHCR Provide EHCR notification EHCR message notification message message message
(note (note2) 1)

message message

EHCR

notification EHCR

Provide

EHCR

EHCR message related agent

Figure 1. Illustration of EHCR message communications and communication role

EHCR

notification

message

Request

(note2)

1)


Page 19 prENV 13606-4:1999

5. Communication Requirements and Scenarios
5.1. Introduction
This clause outlines the communication requirements supported by use of the messages specified in this European Prestandard. The requirements are identified as part of several general scenarios outlined in this clause. However, these scenarios do not form an exhaustive list of circumstances in which these messages are applicable. The clause outlines each scenario in a general manner followed by illustrative examples and a summary of the main communication requirements arising from the scenario. Each communication requirement is related to an instance of a specific message. The messages referred to are specified by this European Prestandard or have already been adopted as part of previously published European Prestandards. Each scenario involves the transfer of EHCR related information in one or more directions between two or more healthcare parties. Figure 2 shows the general sequence of use of the messages. However, some scenarios use only one or two of the messages shown in this figure. Also, as noted in Clause 4, the communicating parties may have different roles at different stages in a communication scenario. For this reason many of the illustrations in this clause refer to the communicating parties as Party A and Party B rather than using the role name. The diagrams in this section follow the general notation of Unified Modelling Language sequence diagrams. Time is represented by the vertical axis. The parties are represented by a dotted lifeline. While a party has a role in relations to the patient the lifeline is overlaid by a hollow rectangle. Lines between the parties indicate the flow of messages.

Party A
(EHCR source)

Party B
(EHCR destination)

Request EHCR message

EHCR notification message (e.g. rejection of request) {OR}

Provide EHCR message

EHCR notification message (e.g. acceptance of EHCR)

Figure 2. General sequence of messages


Page 20 prENV 13606-4:1999

5.2. Transfer initiated by an EHCR source
5.2.1. Scenario outline Party A becomes aware that a patient will in future seek the healthcare services previously provided by Party A from Party B. ­ Party A hands over their clinical responsibility for the patient to Party B. ­ Party A does not expect to have continuing clinical responsibility for the care of the patient. ­ Party B assumes a continuing responsibility for the care of the patient. EXAMPLES ­ A patient informs their GP that they are moving to another area. The GP hands over care of a patient to a colleague in the area to which the patient is moving. ­ A specialist is retiring or leaving a clinic and makes arrangements for the future care of his patients. ­ A patient chooses to change the healthcare professional that they consult for a particular service. The patient informs their current provider that they wish care to be transferred. The current provider transfers the EHCR to the new provider. 5.2.2. Communication requirements and use of messages Party A provides Party B with complete or summarised EHCR information about the patient and indicates that they wish Party B to take over responsibility for the patient. ­ Party A (an EHCR source) sends a provide EHCR message to Party B (an EHCR destination). Party B may respond to the by informing Party A that they have received the information provided and have either accepted or rejected responsibility for the care of the patient. ­ Party B (an EHCR destination) sends an EHCR notification message to Party A (an EHCR source).

Party A
(EHCR source)

Party B
(EHCR destination)

Party A knows patient is mo ving or transferring and sends their EHCR to Party B.

Provide EHCR message

EHCR notification message (acceptance of EHCR)

Party B acknowledges receipt of EHCR from Party A

Figure 3. Patient transfer initiated by an EHCR source


Page 21 prENV 13606-4:1999

5.3. Transfer of care initiated by an EHCR destination
5.3.1. Scenario outline A patient, currently cared for by Party A, requests Party B to provide a continuing healthcare service. ­ Party B takes over clinical responsibility for the patient from Party A. ­ Party A does not have continuing clinical responsibility for the care of the patient. ­ Party B assumes a continuing responsibility for the care of the patient. EXAMPLES ­ A patient consults or registers with a new GP after moving to another area. ­ A patient chooses to change the specialist or clinic that they attend. 5.3.2. Communication requirements and use of messages Party B requests Party A to provide a complete or summarised EHCR for the patient. ­ Party B (an EHCR destination) sends a request EHCR message to Party A (an EHCR source). Party A may accept or reject the request for the EHCR. If the request is accepted, Party A provides Party B with complete or summarised EHCR information about the patient. ­ Party A (an EHCR source) sends a provide EHCR message to Party B (an EHCR destination). If the request is rejected, Party A informs Party B of this decision. ­ Party A (an EHCR source) sends an EHCR notification message to Party B (an EHCR destination).

Party A
(EHCR source)

Party B
(EHCR destination)

Request EHCR message

Party B sees a patient and requests their record from Party A

Party A either sends the requested record or rejects the request

EHCR notification message (e.g. rejection of request) {OR}

Provide EHCR message

Figure 4. Transfer of care initiated by an EHCR destination


Page 22 prENV 13606-4:1999

5.4. Provision of a temporary service without a request from the EHCR source
5.4.1. Scenario outline A patient, usually cared ­ Party B ­ Party A ­ Party B EXAMPLES ­ ­ ­ ­ ­ A A A A A for by Party A, requests Party B to provide a service of limited duration. performs the service for the patient. resumes clinical responsibility for the care of the patient. does not expect to play a further role in the future care of the patient. attends an Accident Emergency department at a hospital. self-refers to a particular specialist. requires healthcare services while out of their home area. requires urgent healthcare services out of the normal office hours of their doctor. consults another GP (in countries where patients may see more than one GP).

patient patient patient patient patient

5.4.2. Communication requirements and use of messages Party B may decide that they need EHCR information from Party A in order to perform the service. In this case, Party B requests Party A to provide a complete or summarised EHCR for the patient. ­ Party B (an EHCR destination) sends a request EHCR message to Party A (an EHCR source). Party A may accept or reject the request for the EHCR. If the request is accepted, Party A provides Party B with complete or summarised EHCR information about the patient. ­ Party A (an EHCR source) sends a provide EHCR message to Party B (an EHCR destination). If the request is rejected, Party A informs Party B of this decision. ­ Party A (an EHCR source) sends an EHCR notification message to Party B (an EHCR destination). When the service has been performed Party B may send the EHCR information recorded while performing the service to Party A. The communication roles of the parties are now reversed. ­ Party B (an EHCR source) sends a provide EHCR message to Party A (an EHCR destination).

Party A

Party B

Request EHCR message

Party B sees a patient and requests their record from Party A

Party A either sends the requested record or rejects the request

EHCR notification message (e.g. rejection of request) {OR} Provide EHCR message

Provide EHCR message

Party B sends EHCR information arising from service back to Party A

Figure 5. Service provision without a request


Page 23 prENV 13606-4:1999

5.5. Provision of a temporary service following a request from the EHCR source
5.5.1. Scenario outline A patient, usually cared ­ Party A ­ Party B ­ Party A ­ Party B for by Party A, receives a service of limited duration from Party B at the request of Party A. requests the service from Party B. performs the service for the patient. resumes or retains clinical responsibility for the care of the patient. does not expect to play a further role in the future care of the patient.

EXAMPLES ­ A GP refers a patient to a specialist. ­ A specialist involves a therapist in a particular aspect of a patient's care. 5.5.2. Communication requirements and use of messages Party A requests Party B to provide a service and may provide a copy or summary of the EHCR as part of this request. This may be done using the specialist service request message specified by ENV 12538 or using the provide EHCR message. ­ Party A (an EHCR source) sends a provide EHCR message to Party B (an EHCR destination). When the service has been performed Party B may send the EHCR information recorded while performing the service to Party A. This may be done using the specialist service report message specified by ENV 12538 or using the provide EHCR message. If the provide EHCR message is used, the communication roles are reversed. ­ Party B (an EHCR source) sends a provide EHCR message to Party A (an EHCR destination).

Party A

Party B

Specialist service request message
Party A sends a referral and/or the patient's EHCR to Party B

{OR}

Provide EHCR message

Specialist service report message

Provide EHCR message

{OR}

Party B provides the requested service and sends EHCR information arising from service back to Party A

Figure 6. Service provision following a request


Page 24 prENV 13606-4:1999

5.6. Provision of continuing care by two or more parties
5.6.1. Scenario outline Party A is providing care to a patient and requests Party B to become involved in providing for a particular aspect of that patient's care. ­ Party A's general responsibility for the care of the patient continues. However, a specific part of that responsibility is shared with Party B while a series of services are provided. ­ Party B usually sees the patient two or more times while providing the requested service. ­ During the period during which Party B is sharing responsibility, Party A may also seen the patient one or more times. ­ EXAMPLES ­ GP and diabetic specialist providing care to a diabetic patient. ­ GP and Midwife and/or Obstetrician providing antenatal care. 5.6.2. Communication requirements and use of messages Party A requests Party B to provide a service and may provide a copy or summary of the EHCR as part of this request. This may be done using the specialist service request message specified by ENV 12538 or using the provide EHCR message. ­ Party A (an EHCR source) sends a provide EHCR message to Party B (an EHCR destination). After the initial contact with the patient, Party B may send the EHCR information recorded during that contact to Party A. ­ Party B (an EHCR source) sends a provide EHCR message to Party A (an EHCR destination). After each subsequent consultation, or other interaction with the EHCR, Party A sends an update of the EHCR information recorded during that contact to Party B. ­ Party A (an EHCR source) sends a provide EHCR message to Party B (an EHCR destination). After each subsequent consultation, or other interaction with the EHCR, Party B sends an update of the EHCR information recorded during that contact to Party A. ­ Party B (an EHCR source) sends a provide EHCR message to Party A (an EHCR destination). An alternative to the unsolicited transfers of updates described here is for the update to be explicitly requested. If an update is required by Party A. ­ Party A (an EHCR destination) sends a request EHCR message to Party B (an EHCR source). ­ Party B (an EHCR source) responds by sending a provide EHCR message to Party A (an EHCR destination). If an update is required by Party B. ­ Party B (an EHCR destination) sends a request EHCR message to Party A (an EHCR source). ­ Party A (an EHCR source) responds by sending a provide EHCR message to Party B (an EHCR destination).


Page 25 prENV 13606-4:1999

Party A

Party B

Specialist service request message
Party A sends a referral and/or the patient's EHCR to Party B

{OR}

Provide EHCR message

Provide EHCR message

Party B sends EHCR information arising from service back to Party A

Request EHCR message
Party A sends updates of EHCR information to Party B. This may occur regularly, after each change to the record or on request.

Provide EHCR message

Sequences may repeat

Request EHCR message
Party B sends updates of EHCR information to Party A. This may occur regularly, after each change to the record or on request.

Provide EHCR message

Figure 7. Continuing care by two parties


Page 26 prENV 13606-4:1999

5.7. Scenarios involving a third party
5.7.1. Description Some scenarios may involve a third party ( Party C). Party C may act as a clearing-house where parties are not sure to whom they should send requests (see 5.7.2) or EHCR information (see 5.7.3). Party C may also act as a Trusted Third Party either confirming that a requester is authorised to receive EHCR information (see 5.7.5) or authenticating the source of the EHCR information (see 5.7.6). 5.7.2. Indirect communication initiated by the recipient Case -- Party B wishes to receive EHCR information but does not know who holds this information Action -- -- -- -- Party B Party C Party C Party A Party B -- If Party Party B. sends the request EHCR message to Party C. establishes the location of a party who holds relevant EHCR information. forwards the request EHCR message to Party A. responds by sending a provide EHCR message or an EHCR notification message either directly to or to Party C as an intermediary. C is used as an intermediary then the message received from Party A is forwarded by Party C to

Party A
(EHCR source)

Party C
(EHCR related agent)

Party B
(EHCR destination)

Request EHCR message
Party C forwards the request to Party A

Party B requests the EHCR using Party C as an intermediary to locate and obtain the record.

Request EHCR message

Provide EHCR message
Party A send the EHCR (or a notification of rejection of the request) to Party B via Party A

{OR} EHCR notification message (e.g. reject request)

Provide EHCR message {OR} EHCR notification message (e.g. reject request)
Party C forwards the EHCR (or notification) to Party B

Figure 8. Indirect communication initiated by the recipient


Page 27 prENV 13606-4:1999 5.7.3. Indirect communication initiated by the sender Case -- Party A is aware that another party will require EHCR information but is not aware of the identity of that party. -- Party C acts as a clearing-house. Action -- -- -- -- Party A sends a provide EHCR message to Party C. Party C retains the record acting as a clearing-house. Party B sends a request EHCR message to Party C. Party C checks whether the relevant provide EHCR message has been received and also checks that Party B is authorised to receive this message. -- Party C either forwards the provide EHCR message to Party B or generates and sends an appropriate EHCR notification message to Party B

The second part of this scenario is superficially similar to the more general request scenario (see 5.3). However, there are two important differences in requirements. The first is that the provide EHCR message must identify its origin (Party A) as well as the intermediary. The second is that the intermediary may need to be aware of the distribution rules applied at the point of origin in order to determine whether Party B is authorised to receive the provide EHCR message. The messages specified allow this information to be conveyed but the security mechanisms for enforcing these provisions are outside the scope of this European Prestandard.

Party A
(EHCR source)

Party C
(EHCR related agent)

Party B
(EHCR destination)

Provide EHCR message
Party A send the EHCR to Party C

Request EHCR message

Party B requests the EHCR from the clearing service provided by Party C

Provide EHCR message {OR} EHCR notification message (e.g. reject request)
Party C sends the EHCR to Party B or notifies Party B that they are not able to provide the requested EHCR

Figure 9. Indirect communication initiated by the sender


Page 28 prENV 13606-4:1999 5.7.4. Indirect communication initiated by the third party Case -- Party C, acting as a medical dispatch centre, wishes to receive information from an identified Party A in order to select and request a service from an appropriate Party B. EXAMPLES A patient at home has a cardiac infarction and needs immediate intensive care. A communication between the family doctor and the emergency medical dispatch centre is established by telephone. The medical dispatch centre informs the intensive care unit of the regional university hospital. The medical dispatch centre requests the relevant patient records and forwards them to the hospital. An injured tourist asks an emergency medical assistance provider for repatriation. The assistance provider obtains the records from the treating clinicians in the country where the patient was injured and forwards this information to an appropriate hospital or clinician in the tourist's home country. Party C sends a request EHCR message to Party A. Party A sends a provide EHCR message to Party C (optionally Party C sends a specialist service request message (referral) to Party B) (optionally Party B sends a request EHCR message to Party C) Party C sends a provide EHCR message to Party B.

-

Action -- -- -- -- --

Party A
(EHCR source)

Party C
(EHCR related agent)

Party B
(EHCR destination)

Party C requests a patient's record to support transfer of care from current carer/provide to new care/provider

Request EHCR message specialist service request or administrative message

Party C requests Party B to provide care to the patient using a message defined in another Prestandard

Party A sends the record to Party C

Provide EHCR message

request EHCR message

Provide EHCR message

Party C forwards the record to the new carer/provider (Party B).

Figure 10. Indirect communication initiated by the third party


Page 29 prENV 13606-4:1999 5.7.5. Confirming the entitlement of a requester to EHCR Information If the request EHCR message is used between two parties with an existing relationship of trust, it may be sufficient for the request message to confirm its source and authenticity (for example using a digital signature). However, in the case of transfers within a wider community, the holder of the EHCR ( Party A) may need to check the status of the requester (Party B) before responding to a request. This check may be done using various mechanisms that are outside the scope of this European Prestandard. However, some of the possible mechanisms impose additional requirements on the message. -- The request EHCR message may need to convey a reference to a third party ( Party C) recognised by Party A as being authorised to vouch for the status of Party B. -- The request EHCR message may need to convey information that allows it to be routed via a third party (Party C) responsible for logging and checking the validity of requests before forwarding valid requests to Party A. -- The request EHCR message may need to convey a password or key provided by the patient to Party B, which is recognised by Party A as indicating authorisation by that patient for the EHCR to be provided. -- The provide EHCR message may need to capable of being sent without recognisable identification information. This "unidentified" EHCR may then be recombined with the appropriate identification information provided by a recognised third party who is able to provide a link between the information in this message and the appropriate patient. 5.7.6. Authenticity of origin of EHCR Information If the provide EHCR message is used between two parties with an existing relationship of trust it may be sufficient for the message to confirm its source and authenticity (for example using a digital signature). However, in the case of transfers within a wider community, the recipient ( Party B) may need to check the status of the sender ( Party A) before accepting the validity of the EHCR information provided. This check may be done using various mechanisms that are outside the scope of this European Prestandard. However, some of the possible mechanisms impose additional requirements on the message. -- The provide EHCR message may need to convey a reference to a third party ( Party C) recognised by Party B as being authorised to vouch for the status of Party A. -- The provide EHCR message may need to convey information that allows it to be routed via a third party (Party C). Party C only forwards the message if it recognises the status of Party A. 5.7.7. Sending EHCR information to multiple destinations If it is appropriate to send a copy of the same information to several destinations, separate instances of the provide EHCR message should be used. Only one EHCR destination may be specified in an instance of the message. However, if appropriate, the same EHCR information can be included in another message sent to another EHCR destination. The other recipients of the same EHCR information can be identified in the message as EHCR message related agents with the role copy destination. NOTE The requirement to use separate messages for each EHCR destination is intended to ensure that ethical and legal responsibility for each communicative act is explicit in the message. Therefore, each EHCR message is specifically identified and is sent by a single identified EHCR source, to a single identified EHCR destination.


Page 30 prENV 13606-4:1999

6. Requirements and General Message Descriptions
6.1. Conformance requirements
6.1.1. This clause specifies the normative minimum acceptable content and structure requirements for messages that comply with this European Prestandard. 6.1.2. Messages that comply with this European Prestandard shall support the structure and relationships illustrated by the GMD diagrams and textual descriptions in this clause. The requirements in this clause incorporate by reference the relevant class descriptions in Clause 7. 6.1.3. In respect of each class referred to in the clause 6, compliant messages shall support the detailed content of the class as described in Clause 7. 6.1.4. A reference to a class description implies a requirement to fully support the listed attributes of that class, including those that are further decomposed by reference to further class and subclass descriptions in Clause 7. 6.1.5. Messages that comply with this European Prestandard need not support relationships shown in the domain information model diagrams in Clause 7, except to the extent that these are either: -- Explicitly specified in this clause; or -- Listed in Clause 7 as a component or attribute of a class explicitly specified in this clause. 6.1.6. Where text description in this clause include phrases such as " the... message shall contain an optional instance of...", practical implementation of messages that comply with this European Prestandard shall include appropriate provision for the specified information. However, this European Prestandard does not require the user of such a message to send an instance of these classes in each instance of the message. NOTE 1 This phrase is used to make clear that in these cases the optionality specified in the model applies to population of instances of the message with data. It is mandatory for the message to be capable of carrying these classes. NOTE 2 In practice, the use of some of these optional attributes may be constrained by rules agreed wi th communicating communities while others may depend on a variety of factors including availability of relevant information, capabilities of communicating applications and the needs or preferences of users. 6.1.7. Where text description in clause 6 include phrases such as " the... message shall contain one mandatory instance of...", practical implementation of messages that comply with this European Prestandard shall include appropriate provision for the specified information. This European Prestandard requires that the message shall oblige the sender of such a message to send an instance of the referred classes in each instance of the message. NOTE This phrase is used to make clear that in these instances it is not only mandatory for the messa ge to be able to carry the specified class; it is also mandatory for the class to be populated with appropriate data in each instance of the message.

6.2. General Message Descriptions
6.2.1. The diagrammatic representation of the GMDs shows the hierarchical decomposition of each message into its main classes. The depth of the hierarchy shown in the diagrams has been limited to highlight the main points. Wherever a branch of the hierarchy is shown in an expanded form all its direct descendants are included. Thus some of the boxes in these diagrams represent attributes rather than classes. 6.2.2.In some of the GMD diagrams, the generalisation of a class is shown by text within the box representing the specialised class, rather than by explicitly listing the generalised content of the class. The Domain Information Model in Clause 7 contains a fully expanded listing of the components of each class, including the attributes inherited from generalised classes.


Page 31 prENV 13606-4:1999

6.3. Requirements common to all EHCR messages
6.3.1. The EHCR message (7.4.1) is an abstract generalisation of the three messages specified in this Prestandard. It is used to refer to those elements of the messages that are common to a wide range of patient related healthcare messages. 6.3.2. Any implementation of the provide EHCR message (7.4.3), request EHCR message (7.4.2) or EHCR notification message (7.4.4) shall comply with all the requirements for the EHCR message as stated in this subclause. These requirements are summarised in the GMD diagram ( Figure 11). A more detailed description of the EHCR message class and its constituent attributes is provided in the Domain Information Model ( 7.4.1) 6.3.3. An -- -- -- -- 6.3.4. An -- -- -- EHCR message shall contain one mandatory instance of each of the following attributes (see 7.4.1): identification of message by originator issue date and time of message urgency of message message receipt acknowledgement request. EHCR message shall contain one mandatory instance of each of the following classes. EHCR source (7.3.2) EHCR destination (7.3.3) patient matching information (7.4.6).

6.3.5. An EHCR message shall contain optional instances of each of the following attributes (see 7.4.1): -- comment on message -- language. 6.3.6. An -- -- -- EHCR message shall contain optional instances of each of the following classes: EHCR message related agent (7.3.4) healthcare agents directory (7.10.19) message reference (7.4.5).

6.3.7. In accordance with the descriptions in Clause 7, the EHCR source, EHCR destination and any EHCR message related agents are identified using a healthcare agent in context reference (7.10.12). These references, and those for other healthcare agents identified in the message, may either refer to entries in a common shared directory or may refer to entries in the healthcare agents directory (7.10.19) class contained in the message. An individual instance of the message shall contain appropriate healthcare agents directory entries for any healthcare agent, or healthcare agent in context, referred to in the message, unless the reference refers to an existing entry for this agent in a directory readily accessible to both communicating parties. 6.3.8. The mandatory instance of patient matching information (7.4.6) shall contain sufficient information to identify the patient who is the subject of the message. The message shall include instances of the following attributes, one or more of which should be mandatory in any instance of the message. -- patient identifiers -- person name -- date of birth. 6.3.9. The requirement to include a patient identifier, person name or date of birth may be met by use of an alias or encrypted identifier where this is required to comply with data protection legislation. In this case, the communicating community shall specify a mechanism that enables an authorised communicating party to match a message to a patient. 6.3.10. The mandatory instance of patient matching information (7.4.6) should also contain optional instances of the following attributes. These may be included in individual instances of the message where this information may assist accurate matching: -- alternative person name -- person administrative sex -- person addresses. 6.3.11. Communicating communities should specify which combinations of the attributes listed in 6.3.8 and 6.3.10 are acceptable to enable safe automated or manually assisted matching of a message to a patient. 6.3.12. If the EHCR message is a response to another message, a message reference (7.4.5) should be included in the message and, if included, this shall uniquely identify the relevant message.


Page 32 prENV 13606-4:1999
EHCR message - see 7.4.1
1 1 1 1 0..* 1 1 1 0..* 0..1 0..1

identification of message by originator - see 7.4.1 issue date and time of message- see 7.4.1 EHCR source - see 7.3.2 EHCR destination - see 7.3.3 EHCR message related agent - see 7.3.4 urgency of message - see 7.4.1 patient matching information - see 7.4.6 message receipt acknowledgement request- see 7.4.1 comment on message - see 7.4.1 language - see 7.4.1 healthcare agents directory - see 7.10.19
0..* 0..*

healthcare agent in context - see 7.10.11 healthcare agent - see 7.10.10 healthcare party - see 7.10.13

May be specialised as one of

healthcare person - see 7.10.14 healthcare organisation - see 7.10.15 healthcare device - see 7.10.16 healthcare software - see 7.10.17

0..1

message reference - see 7.4.5

Figure 11. GMD for the common structures applicable to all EHCR Messages

6.4. Specification of EHCR message information
6.4.1. The specification of EHCR information is used to indicate the nature of the information that an EHCR message requests, contains or refers to. The requirements for including this class vary and are stated in the clauses relevant to each message. However, when specification of EHCR information is included in a message, the requirements for its composition are not dependent on the nature of the message. 6.4.2. Any implementation of the provide EHCR message (7.4.3), request EHCR message (7.4.2) or EHCR notification message (7.4.4) shall conform with all the requirements stated in this subclause. These requirements apply to the class specification of EHCR information, when it is included in any of the three messages specified in this Prestandard. These requirements are summarised in the GMD diagram ( Figure 12). A more detailed description of specification of EHCR information class and its constituent attributes is provided in the Domain Information Model ( 7.4.7). 6.4.3. The specification of EHCR information shall contain one mandatory instance of the attribute EHCR scope. This shall indicate whether the EHCR information represents: -- the complete EHCR for a patient as held by the EHCR source; -- a selected subset from the EHCR; -- an update of changes during a specified period. 6.4.4. The specification of EHCR information shall contain one instance of the attribute EHCR subset description (see 7.4.7). This attribute shall be mandatory in any instance of the message in which the EHCR scope indicates that the information is a selected subset of the record.


Page 33 prENV 13606-4:1999 6.4.5. The specification of EHCR information shall contain one instance of the attribute EHCR update period (see 7.4.7). This attribute shall be mandatory in any instance of the message in which the EHCR scope indicates that the information is an update of changes to the record. 6.4.6. The specification of EHCR information shall contain one instance of the attribute EHCR update period (see 7.4.7). This attribute shall be mandatory in any instance of the message in which the EHCR scope indicates that the information is an update of changes to the record. 6.4.7. The 7.4.7): -- -- -- specification of EHCR information shall contain one optional instance of each of the following attributes (see communicating community identifier enterprise identifier EHCR language.

6.4.8. If the attribute communicating community identifier is present in an instance of a message, it shall identify the communicating community which defined the implementation guidelines followed by this message. According to the nature of those guidelines, it may also determine the expected nature of a response to the message and/or the use of community defined data items within the message. 6.4.9. If the attribute enterprise identifier is present in an instance of a message, it shall identify the enterprise environment of the sending system. This may determine the inclusion of, or capability to interpret, enterprise specific community defined data items. 6.4.10. If the attribute EHCR language is present in an instance of a message, it shall identify the predominant language in which EHCR information is represented or, in the case of a request EHCR message, the language in which the EHCR destination would prefer to receive this information.
specification of EHCR information - see 7.4.7
0..1 0..1

communicating community identifier enterprise identifier

0..1

EHCR language
1

EHCR scope
0..1

EHCR subset description
0..1

EHCR update period

Figure 12. GMD for Specification of EHCR Information applicable to all EHCR messages


Page 34 prENV 13606-4:1999

6.5. Provide EHCR Message
6.5.1. The provide EHCR message is used to communicate all or part of a single patient's EHCR: -- In response to: ­ a request EHCR message; ­ a request conveyed by other means (i.e. a verbal or written request). -- Without a specific preceding request: ­ as part of the regular sharing of information between healthcare parties caring for the same patient; ­ when the EHCR source is aware of a likely future requirement for another healthcare party to have access to a particular patient record; ­ as part of the process of transferring a patient to the care of another healthcare party. 6.5.2. The requirements applicable to the provide EHCR message are stated in this subclause and summarised in the GMD diagram ( Figure 13). A more detailed description of the provide EHCR message is included in the Domain Information Model ( 7.4.3). 6.5.3. The provide EHCR message shall comply with the general requirements for EHCR messages stated in 6.3. 6.5.4. The provide EHCR message shall include one mandatory instance of specification of EHCR information which shall comply with the requirements stated in 6.4. This shall indicate the scope of the EHCR information in the message. It may also indicate the predominant language and communicating community or enterprise constraints or extensions applied to that information. 6.5.5. The provide EHCR message should include one optional instance of distribution rule directory (7.9.1) which, if present, shall contain one or more instances of distribution rules (7.9.3). The rules included in the directory shall comply with the detailed requirements specified in Part 3 of this Prestandard. The EHCR extract or any of its constituent record components may refer to one or more of these rules using the distribution rule reference (7.9.2) attribute. Access to record components that refer to distribution rules shall be governed by those rules as specified in Part 3. 6.5.6. The provide EHCR message shall include one mandatory instance of EHCR extract. This shall contain the EHCR information indicated by the specification of EHCR information and shall be structured as specified in 6.6.

provide EHCR message - see 7.4.3 Specialisation of EHCR message - see Figure 11

1

specification of EHCR information - see Figure 12

0..1 distribution rule directory - see 7.9.3

0..*

distribution rule - see 7.9.1

1

EHCR extract - see Figure 14 Specialisation of EHCR message component - see 7.5.1

Figure 13. GMD Provide EHCR Message


Page 35 prENV 13606-4:1999

6.6. EHCR Extract
6.6.1. The EHCR extract represents the entirety of the EHCR information within the message. Thus it acts as the root of a hierarchical structure including all the other record components that convey the structure and content of the EHCR. If the message contains the complete EHCR, the EHCR extract is equivalent to the EHCR Root Architectural Component specified in Part 1 of this Prestandard. However, this is not the case if the message contains a selected subset or an update of EHCR information. 6.6.2. The requirements applicable to the EHCR extract are stated in this subclause and summarised in the GMD diagram ( Figure 14). A more detailed description of the EHCR extract class is included in the Domain Information Model (7.5.1). 6.6.3. The EHCR extract is a specialisation of the abstract class EHCR message component. Therefore, the EHCR extract shall include instances of the attributes of EHCR message component as specified in 7.8.1 and these attributes shall be populated in accordance with the specification of usage included in the full description of the EHCR extract in 7.5.1. 6.6.4. The EHCR extract shall include one or more members and each of these members shall be an instance of one of the following specialisations of the abstract class record component: -- original component complexes (7.5.3) of the following types: ­ folder (7.5.4) ­ composition (7.5.5) -- selected component complex (7.5.8) -- empty record component (7.5.9) -- link set item (7.7.1) -- text data item (7.6.2). 6.6.5. Implementation of the provide EHCR message in an Implementable Message Specification shall not restrict the maximum number of members that an EHCR extract may have.

6.7. Original component complexes
6.7.1. General requirements 6.7.1.1. Original component complexes are used to structure the record in accordance with the time and situation in which information was recorded in the EHCR. 6.7.1.2. Within the message all record components that are not members of the EHCR extract shall be members of one, and only one, original component complex. A record component that is a member of the EHCR extract shall not also be a member of an original component complex. 6.7.1.3. All the record components that are members of the same original component complex shall have arisen in a common original information context based on the time and situation in which they were recorded. Original component complexes shall not be used to represent logical or clinical relationships between record components that arose in different original information contexts. 6.7.1.4. The original component complex is a specialisation of the abstract class record component. Therefore, the original component complex shall include instances of the attributes of record component as specified in 7.5.2. These attributes shall be populated in accordance with the specification of usage included in the full description of the original component complex in 7.5.3. 6.7.1.5. Each instance of original component complex shall include one or more members and each of these members shall be an instance of one of the concrete specialisations of the abstract class record component. 6.7.1.6. Each member of an original component complex may play one of three component roles in the representation of the information content of that part of the EHCR. By default a member provides structured content. However, in each original component complex there may be one optional instance of a record component that provides a parallel narrative text representation of the same part of the record. They may also be one optional instance of a record component that provides a parallel enterprise specific representation of the same part of the record. These roles are indicated by the value of the component role attribute ( 7.5.2).


Page 36 prENV 13606-4:1999

EHCR extract - see 7.5.1 Specialisation of EHCR message component

folder - see Figure 15 Specialisation of original component complex ... and thus of record component ... and thus of EHCR message component
contains record components as its members

composition Specialisation ... and thus of ... and thus of

- see Figure 16 of original component complex record component EHCR message component

{Each instance of a member is a choice of one of these specialisations of record component}

1..*

selected component complex - see 7.5.8 Specialisation of record component ... and thus of EHCR message component

text data item - see 7.6.2 Specialisation of data item - see Figure 19 ... and thus of record component ... and thus of EHCR message component

link set item - see 7.7.1 Specialisation of record component ... and thus of EHCR message component

empty record component - see 7.5.9 Specialisation of record component ... and thus of EHCR message component

Figure 14. GMD EHCR Extract Component Hierarchy


Page 37 prENV 13606-4:1999 6.7.1.7. Implementation of the provide EHCR message in an Implementable Message Specification shall not restrict the maximum number of members that an original component complex may have. 6.7.1.8. Four specialised types of original component complex are described in this Prestandard. These are folder (7.5.4), composition (7.5.5), headed section (7.5.6) and cluster (7.5.7). All original component complexes have the same general structure but differ in respect of: -- coarseness of granularity of their shared original information context; -- permissible values for certain attributes; -- propagation of attribute values to their members; -- specialisations of record components that are permitted to be their contain members. The following subclauses describe and illustrate these points for each specialisation of original component complex. 6.7.2. Folders 6.7.2.1. A folder is used to group record components collected and/or recorded during several contacts with a patient. A folder may include information collected and recorded at different times and by different people. EXAMPLES Nursing notes, Primary care notes, Specialist departmental record. 6.7.2.2. All implementations of the provide EHCR message should be capable of supporting folders. However, users of the message need not include instances of folder in a message. 6.7.2.3. If folders are implemented and used in the message, they shall comply with the requirements which are stated in this subclause and summarised in the GMD diagram ( Figure 15). A more detailed description of the folder class is included in the Domain Information Model ( 7.5.4). 6.7.2.4. A folder is a specialisation of the abstract class original component complex. Therefore, the EHCR extract shall comply with the requirements specified for all types of original component complex in 6.7 and shall fully support the specialised constraints specified for folder type original component complexes in 7.5.4. 6.7.2.5. A folder shall include one or more members and each of these members shall be an instance of one of the following specialisations of the abstract class record component: -- original component complexes (7.5.3) of the types: ­ folder (7.5.4) ­ composition (7.5.5) -- selected component complex (7.5.8) -- empty record component (7.5.9) -- link set item (7.7.1) -- text data item (7.6.2) 6.7.2.6. A folder may include other folders among its members. A communicating community may specify limitations to the level of nesting of folders as part of the implementation guidelines for the provide EHCR message.


Page 38 prENV 13606-4:1999

folder - see 7.5.4 Specialisation of original component complex ... and thus of record component ... and thus of EHCR message component

members may include further instances of

contains record components as its members

composition Specialisation ... and thus of ... and thus of

- see Figure 16 of original component complex record component - see 7.5.2 EHCR message component

{Each instance of a member is a choice of one of these specialisations of record component}

1..*

selected component complex - see 7.5.8 Specialisation of record component ... and thus of EHCR message component

text data item - see 7.6.2 Specialisation of data item - see Figure 19 ... and thus of record component ... and thus of EHCR message component

link set item - see 7.7.1 Specialisation of record component ... and thus of EHCR message component

empty record component - see 7.5.9 Specialisation of record component ... and thus of EHCR message component

Figure 15. GMD Folder - Original Component Complex


Page 39 prENV 13606-4:1999 6.7.3. Compositions 6.7.3.1. A composition is used to group record components collected during a single contact with a patient and/or a single interaction between the originating healthcare agent and the EHCR system. EXAMPLES Notes of a consultation, an investigation report, a referral letter. 6.7.3.2. All implementations of the provide EHCR message shall support compositions. Each instance of the message should include at least one composition. However, an instance of the message that only conveys a narrative text summary of the EHCR need not contain a composition. 6.7.3.3. Compositions shall comply with the requirements which are stated in this subclause and summarised in the GMD diagram ( Figure 16). A more detailed description of the composition class is included in the Domain Information Model (7.5.5). 6.7.3.4. A composition is a specialisation of the abstract class original component complex. Therefore, the EHCR extract shall comply with the requirements specified for all types of original component complex in 6.7 and shall fully support the specialised constraints specified for composition type original component complexes in 7.5.5. 6.7.3.5. Every instance of a composition shall include a value for the component name category attribute. This shall be one of the "Categories for Composition OCC types", listed in Table A.1 of Part 2 of this Prestandard. These values are required to communicate information about the general nature of the composition. An optional additional more detailed title may be provided using the component name structure (7.8.4). 6.7.3.6. Every instance of a composition shall include a value for the attributes originating date and time and originating healthcare agent. 6.7.3.7. A composition shall include one or more members and each of these members shall be an instance of one of the following specialisations of the abstract class record component: -- original component complexes (7.5.3) of the types: ­ headed section (7.5.6) ­ cluster (7.5.7) -- selected component complex (7.5.8) -- empty record component (7.5.9) -- link set item (7.7.1) -- data item (7.6.1) of any of the types specified in ( 6.8) 6.7.3.8. A composition shall not include folders or other compositions as members.


Page 40 prENV 13606-4:1999

composition Specialisation ... and thus of ... and thus of

- see 7.5.5 of original component complex record component EHCR message component

contains record components as its members

headed section - see Figure 17 Specialisation of original component complex ... and thus of record component ... and thus of EHCR message component cluster - see Figure 18 Specialisation of original component complex ... and thus of record component ... and thus of EHCR message component

{Each instance of a member is a choice of one of these specialisations of record component}

1..*

selected component complex - see 7.5.8 Specialisation of record component ... and thus of EHCR message component

A specialisation of data item - see Figure 19 Specialisation of record component ... and thus of EHCR message component

link set item - see 7.7.1 Specialisation of record component ... and thus of EHCR message component

empty record component - see 7.5.9 Specialisation of record component ... and thus of EHCR message component

Figure 16. GMD Composition - Original Component Complex


Page 41 prENV 13606-4:1999

headed section - see 7.5.6 Specialisation of original component complex ... and thus of record component - see ... and thus of EHCR message component

members may include other instances of

contains record components as its members

{Each instance of a member is a choice of one of these specialisations of record component}

cluster - see Figure 18 Specialisation of original component complex ... and thus of record component ... and thus of EHCR message component

1..*

selected component complex - see 7.5.8 Specialisation of record component ... and thus of EHCR message component

A specialisation of data item - see Figure 19 Specialisation of record component ... and thus of EHCR message component

empty record component - see 7.5.9 Specialisation of record component ... and thus of EHCR message component

Figure 17. GMD Headed Section - Original Component Complex


Page 42 prENV 13606-4:1999 6.7.4. Headed sections 6.7.4.1. A headed section is used to group record components that are part of a composition under an appropriate heading. A headed section shall not be used to group record components that arise from more than one contact with a patient. EXAMPLES Clinical history, examination, treatment. 6.7.4.2. All implementations of the provide EHCR message should be capable of supporting headed sections. However, users of the message need not include instances of headed section in a message. 6.7.4.3. If headed sections are implemented and used in the message, they shall comply with the requirements which are stated in this subclause and summarised in the GMD diagram ( Figure 17). A more detailed description of the headed section class is included in the Domain Information Model ( 7.5.6). 6.7.4.4. A headed section is a specialisation of the abstract class original component complex. Therefore, the EHCR extract shall comply with the requirements specified for all types of original component complex in 6.7 and shall fully support the specialised constraints specified for headed section type original component complexes in 7.5.6. 6.7.4.5. Every instance of a headed section shall include a value for the component name category attribute. This shall be one of the "Categories for Headed Section OCC types", listed in Table A.2 of Part 2 of this Prestandard. These values are required to communicate information about the general nature of the headed section. An optional additional more detailed heading may be provided using the component name structure (7.8.4). 6.7.4.6. A headed section shall include one or more members and each of these members shall be an instance of one of the following specialisations of the abstract class record component: -- original component complexes (7.5.3) of the types: ­ headed section (7.5.6) ­ cluster (7.5.7) -- selected component complex (7.5.8) -- empty record component (7.5.9) -- data item (7.6.1) of any of the types specified in ( 6.8) 6.7.4.7. A headed section may include other headed sections among its members. A communicating community may specify limitations to the level of nesting of headed sections as part of the implementation guidelines for the provide EHCR message.

6.7.5. Clusters 6.7.5.1. A cluster is used where it is necessary or desirable to group data item into logically or clinical associated collections within a composition or headed section. A cluster shall not be used to group record components that arise from more than one contact with a patient or that have been recorded under different headed sections. EXAMPLES Blood pressure measurement (including systolic and diastolic as separate data items, the results of a "battery" of investigations. 6.7.5.2. All implementations of the provide EHCR message should be capable of supporting clusters. Instances of a message should include clusters if the EHCR source systems contains an indication of a fundamental relationship between several observations or actions recorded during the same contact with the patient. 6.7.5.3. If clusters are implemented and used in the message, they shall comply with the requirements stated in this subclause and summarised in the GMD diagram ( Figure 18). A more detailed description of the cluster class is included in the Domain Information Model (7.5.7). 6.7.5.4. A cluster is a specialisation of the abstract class original component complex. Therefore, the EHCR extract shall comply with the requirements specified for all types of original component complex in 6.7 and shall fully support the specialised constraints specified for cluster type original component complexes in 7.5.7. 6.7.5.5. The nature of the information within a cluster should be represented by one or more code values applied to the component name structure (7.8.4). The codes used for this purpose shall be taken from a coding scheme or controlled terminology agreed for use within the communicating community and identified in the message.


Page 43 prENV 13606-4:1999 6.7.5.6. Any other coded or structured information that alters the meaning of the entire cluster should be represented by inclusion of one or more instances of the annotation identifier attribute, which shall contain an appropriate value from the list in Table B.1 in Part 2 of this Prestandard. 6.7.5.7. A following -- -- -- cluster shall include one or more members and each of these members shall be an instance of one of the specialisations of the abstract class record component: original component complexes (7.5.3) of the type cluster (7.5.7) empty record component (7.5.9) data item (7.6.1) of any of the types specified in ( 6.8)

6.7.5.8. A cluster may include other clusters among its members and this Prestandard does not specify a limit to the levels of nesting. A communicating community may specify limitations to the level of nesting of clusters as part of the implementation guidelines for the provide EHCR message.

cluster - see 7.5.7 Specialisation of original component complex ... and thus of record component ... and thus of EHCR message component

members may include other instances of

contains record components as its members

{Each instance of a member is a choice of one of these specialisations of record component}

1..*

A specialisation of data item - see Figure 19 Specialisation of record component ... and thus of EHCR message component

empty record component - see 7.5.9 Specialisation of record component ... and thus of EHCR message component

Figure 18. GMD Cluster - Original Component Complex


Page 44 prENV 13606-4:1999

6.8. Data items
6.8.1. Concrete specialisations of the abstract class data item represent individual items of EHCR information that cannot be subdivided without losing all or part of their meaning. 6.8.2. The specialisations of data item are illustrated by Figure 19. A more detailed description of the data item class is included in the Domain Information Model ( 7.6.1). 6.8.3. A data item is a specialisation of the class record component. Therefore, each instance of data item shall include instances of the attributes of record component as specified in 7.5.2. These attributes shall be populated in accordance with the specification of usage included in the full description of each specialisation of data item in 7.6. 6.8.4. All implementations of the messages specified by this European Prestandard shall fully support the structure of the following mandatory specialisations of data item (7.6.1) as specified in the referenced clauses of the Domain Information Model: -- address data item (7.6.13) -- event data item (7.6.6) -- external data reference data item (7.6.7) -- language data item (7.6.15) -- medication data item (7.6.5) -- patient related party data item (7.6.9) -- person identifier data item (7.6.11) -- person name data item (7.6.12) -- physical entity reference data item (7.6.8) -- quantifiable observation data item (7.6.4) -- structured coded data item (7.6.3) -- telecom data item (7.6.14) -- text data item (7.6.2) 6.8.5. The nature of main information within a data item should be represented by one or more code values applied to the component name structure (7.8.4). The codes used for this purpose shall be taken from a coding scheme or controlled terminology agreed for use within the communicating community and identified in the message. More detailed specific requirements regarding the use of the component name are included in the description of the individual specialisation of data item. The component name structure is mandatory for most specialisations of data item but is optional or not applicable for others, such as the text data item. EXAMPLES Coded representations of a diagnosis, a procedure, a drug identification or a property measured or observed. 6.8.6. Demographic and healthcare administrative information contained in the EHCR should be conveyed using the appropriate data items. The attributes for names, identifiers, address, sex, date of birth in patient matching information should only be used for information intended to be used to match a message to a patient. NOTE The rationale for treating patient matching information separately for formal communication of demographic information is as follows. The patient matching information is part of the message but outside the formally defined EHCR. This allows a separation between data required to support the management of the message and information contained within the record. Information within the EHCR is conveyed as record components that are identifiable, attributable, subject to distribution rules and capable of supporting revision. Patient matching information is not subject to these constraints, it should be the minimum information required for a match and it may be effective even if it is out-of-date. For example, if a patient has moved home recently, their previous address may be more useful than their current address for matching a message to an existing record. 6.8.7. Information about characteristics of a patient such as sex, marital status and occupation should be conveyed in instances of structured coded data item. 6.8.8. The date of birth and/or date of death should be conveyed in instances of the event data item. 6.8.9. Any other coded or structured information that alters the meaning of the data item shall be represented by inclusion of one or more instances of the annotation identifier attribute, which shall contain an appropriate value from the list in Table B.1 in Part 2 of this Prestandard. 6.8.10. Those involved in implementing the messages specified by this European Prestandard may specify additional community defined data items (7.6.16) for use within a communicating community. These additional types of data item (7.6.1) should be defined using the sub-classes and data types specified in this European Prestandard. To facilitate future extension of communicating communities the specification of community defined data items should follow a documentary form similar to that used in this European Prestandard.


Page 45 prENV 13606-4:1999

data item - see 7.6.1 Specialisation of record component ... and thus of EHCR message component

text data item - see 7.6.2

structured coded data item - see 7.6.3

quantifiable observation data item - see 7.6.4

medication data item - see 7.6.5
{each instance of data item is represented by one of a single instance of one of these concrete classes}

event data item - see 7.6.6

external data reference data item - see 7.6.7

physical entity reference data item - see 7.6.8

patient related party data item - see 7.6.9

related location data item - see 7.6.10

person identifier data item - see 7.6.11

person name data item - see 7.6.12

address data item - see 7.6.13

telecom data item - see 7.6.14

language data item - see 7.6.15

community defined data item - see 7.6.16

Figure 19. GMD Data Item


Page 46 prENV 13606-4:1999

6.9. Link set items
6.9.1. A link set item is used to indicate relationships between record components other than those relationships that are determined by the original information context. 6.9.2. All implementations of the provide EHCR message shall enable the communication of link set items that comply with the requirements specified in this clause. An individual instance of the message need not include any link set items. However, link set items are the only way to convey explicit associations between record components other than those derived from the original information context. Therefore, link set items should be used wherever necessary for this purpose. Communicating communities may specify additional constraints in respect of the use of link set items. 6.9.3. A link set item is a specialisation of the class record component. Therefore, each instance of link set item (7.7.1) shall include instances of the attributes of record component as specified in 7.5.2. These attributes shall be populated in accordance with the specification of usage included in the full description of the link set item in 7.7.1. 6.9.4. Every instance of a link set item shall include a value for the component name category attribute. This shall be one of the "Categorisation of Link Item Names" listed in Table C.1 of Part 2 of this Prestandard. These values are required to communicate information about the general nature of the relationship between the linked components. An optional additional more detailed indication of the nature of a link may be provided using the component name structure (7.8.4). 6.9.5. The link set item shall also include a single mandatory instance of the source component (7.7.2) and one or more instances of the target component (7.7.3) attribute.

6.10. Selected component complexes
6.10.1. A selected component complex is used to aggregate record components in a manner not determined by the time and situation in which they were originally added to the EHCR. Selected component complexes can be used in the message to communicate various alternate views of the EHCR. EXAMPLES Problem lists, views of information associated a particular topic or problem, summaries of based on reference to information in various parts of the record, representation of the record as it appeared at a particular time in the past, dynamic views generated by applying selection criteria to the record. 6.10.2. All implementations of the provide EHCR message shall enable the communication of selected component complexes. However, the requirements for this are equivalent to those for conveying a data item because, in the message, members of a selected component complex are associated with the complex using link set items. An individual instance of the message need not include any selected component complexes. 6.10.3. A selected component complex is a specialisation of the class record component. Therefore, each instance of selected component complex shall include instances of the attributes of record component as specified in 7.5.2. These attributes shall be populated in accordance with the specification of usage included in the full description of the selected component complex in 7.5.8. 6.10.4. The component name structure (7.8.4) should be used to denote the title of the view of the EHCR provided by the selected component complex. This may be mapped to a high-level component name category. In this case the value of the component name category shall be one of the values specified in Tables A.1 and A.2 of Part 2 of this European Prestandard. 6.10.5. The selected component complex may contain an additional optional attribute, the component selection criteria, for communicating the criteria used to generate a dynamic view. However, the nature of these criteria is not specified by this Prestandard. Therefore if this attribute is implemented, its contents shall be specified and agreed by the communicating community.

6.11. Empty record component
6.11.1. An empty record component is used to communicate the deletion of existing record component. 6.11.2. Any implementations of the provide EHCR message should enable the communication of empty record component. However, this component need not be supported if the message is not being used for updating. 6.11.3. An empty record component is a specialisation of the class record component (7.5.2). However the attributes required for this specialisation form a restricted set, which is specified in the Domain Information Model ( 7.5.9).


Page 47 prENV 13606-4:1999

6.12. Adding comments to items
Comments on the information content of any record component may be included in the record in the form of text data items associated with the component to which they relate in one of the following ways: -- By an explicit link represented by link set item (7.7.1) -- By proximity within the same original component complex. ­ This second method is only applicable if the comment originates at the same time as the component on which the comment is made.

6.13. Request EHCR Message
6.13.1. The request EHCR message is used to request all or part of the EHCR for a single specified patient. 6.13.2. The requirements applicable to the request EHCR message are stated in this subclause and summarised in the GMD diagram ( Figure 20). A more detailed description of the request EHCR message is included in the Domain Information Model ( 7.4.2). 6.13.3. The request EHCR message shall comply with the general requirements for EHCR messages stated in 6.3. 6.13.4. The request EHCR message shall include one mandatory instance of specification of EHCR information, which shall comply with the requirements stated in 6.4. This shall indicate the scope of the EHCR information requested by the EHCR destination (7.3.3). It may also indicate the language in which the EHCR information is requested and any communicating community or enterprise constraints that apply to the requester. 6.13.5. The request EHCR message shall include one mandatory instance of the coded or string attribute reason for request.
request EHCR message - see 7.4.2 Specialisation of EHCR message - see Figure 11

1 specification of EHCR information - see 7.4.7

1 reason for request - see 7.4.2

Figure 20. GMD Request EHCR Message


Page 48 prENV 13606-4:1999

6.14. EHCR notification message
6.14.1. The EHCR notification message is used to enable the communicating parties to notify one another about the progress of EHCR communication. It may also be used to notify third parties about the transfer of EHCR information in a communicating community that requires this. 6.14.2. The requirements applicable to the EHCR notification message are stated in this subclause and summarised in the GMD diagram ( Figure 21). A more detailed description of the EHCR notification message is included in the Domain Information Model ( 7.4.4). 6.14.3. The EHCR notification message shall comply with the general requirements for EHCR messages stated in 6.3. 6.14.4. The EHCR notification message shall include one optional instance of specification of EHCR information, which shall comply with the requirements, stated in 6.4. This may be used to indicate the scope of the EHCR information conveyed or requested by the message that is the subject of this notification. 6.14.5. The EHCR notification message shall include one mandatory instance of the enumerated attribute EHCR message notification type and this shall be used to indicate the type of notification (see 7.4.4). 6.14.6. The EHCR notification message shall include one mandatory instance of the coded or string attribute EHCR notification comment and this shall be used to convey a comment relevant to the notification.

EHCR notification message - see 7.4.4 Specialisation of EHCR message - see Figure 11

0..1 specification of EHCR information - see Figure 12

1 EHCR message notification type - see - see 7.4.4

1 EHCR message notification comment - - see 7.4.4

Figure 21. GMD EHCR Notification Message


Page 49 prENV 13606-4:1999

7. Domain information model
7.1. Introduction
This clause contains the model on which the messages in clause 5 are based. It states requirements for the concrete classes of which the message is composed and also describes the abstract classes that form the common basis for the concrete classes. The clause is divided up into sections that illustrate particular sets of related classes referred to as subsystems. This subdivision is arbitrary and primarily designed to aid clarity and understanding. Inclusion of a class in one subsystem rather would not alter the requirements in any way. Figure 1 represents a top-level overview that illustrates the main dependencies between the classes. The subsystems are as follows: The EHCR communicating parties subsystem contains Information about the healthcare agents who are the source and destination of the EHCR being transferred. The EHCR message subsystem describes the general content of EHCR messages and relates this to the three messages specified in this Prestandard. The EHCR structured record subsystem describes those elements of the EHCR that represent the structure of the record in a way that relates together information according to the time and/or place of origin. The EHCR data item subsystem contains the various specialisations of data item that convey the main content of the EHCR as conveyed by the provide EHCR message . The EHCR link subsystem describes the way in which record components can be related to one another, including the references used to refer to the preceding version of a component. The EHCR message component subsystem specifies the structure of the EHCR message component, which is the most generalised abstract class that provides the foundation for the EHCR extract and for all types of record component. The EHCR distribution rule subsystem illustrates the interface between the message and the distribution rules specified in Part 3 of this Prestandard. The healthcare agent subsystem contains the general purpose information used to provide information about healthcare agents (including healthcare persons (or professionals), organisations, hardware devices and software. The Subclasses, Compound Types and Simple Data Types contain the data elements that are used in the the classes included in this Prestandard. The order of the classes in each subsystem follows a logical (rather than alphabetical) order moving from the general to the specific or otherwise grouping similar classes together. The index at the end of this Prestandard may be used to locate classes and attributes if the extensive cross-references are insufficient for this purpose.

7.2. Presentation of attributes from generalisations
The description of each class in this clause includes all attributes inherited from a generalisation as well as those that are specific to a particular specialisation. A double or heavier line on the left border of the table indicates that an attribute is derived from a generalisation of the class. This substantially increases the size of the textual description of the model but reduces the need to check various layers of the model to establish the full set of attributes applicable to a concrete class. The descriptions of attributes in different specialisations of the same class vary. This enables it to be more directly appropriate to each context in which the attribute is used. For example, the component name is the name of the measurable quantity for a quantifiable observation data item but is used to identifying a drug in the medication data item. A double line to the right of a row indicates that the row contains notes, examples or values specific to the use of a generalised attribute in this specialised class. In some cases the multiplicities associated with a particular attribute differ when used in different specialisations based on the same abstract generalisation. In all these cases, the specialisation constrains rather than extending the range of multiplicities. For example component name category has a "0 or 1" relationship with record component, a mandatory "one" occurrence for the specialisations headed section and composition and is not used in the case of a link set item. A double line to the right of a cell that contains multiplicities indicates that special constraints apply to the use of this attribute in this specialisation.


Page 50 prENV 13606-4:1999

EHCR message subsystem see 7.4

may include distribution rules

may include healthcare agents

communicated between

includes EHCR extract

EHCR communicating parties subsystem see 7.3

specialised roles of healthcare agents

healthcare agent subsystem see 7.10

originated by and/or referring to healthcare agents EHCR extract and record component are specialisations of EHCR message components

EHCR structured record subsystem see 7.5

EHCR message component subsystem see 7.8

original component complexes contain EHCR information in data items

EHCR message components may reference distribution rules

EHCR distribution rule subsystem see 7.9

data items are specialisations of record component

original component complexes may include link set items component references refer to EHCR message components

EHCR message components contain revision information

link set items are specialisations of record components

EHCR data item subsystem see 7.6

EHCR link subsystem see 7.7

Figure 22. DIM - EHCR Message Top Level


Page 51 prENV 13606-4:1999

7.3.

EHCR communicating parties subsystem

EHCR communicating parties subsystem
is the source or intended source of EHCR information referred to by or contained in

EHCR message subsystem (incomplete) see 7.4

EHCR source see 7.3.2

1

is specialised as

EHCR destination see 7.3.3
1

receives or is intended to receive EHCR information referred to or contained in 0..*

0..*

EHCR message see 7.4.1
0..*

communicating party see 7.3.1 EHCR message related agent see 7.3.4

may have a role in the communication of the EHCR information in 0..*

is identified by

originator of referenced message see 7.3.5

may qualify the message identifier in 0..1 0..*

message reference see 7.4.5

healthcare agent subsystem (incomplete) see 7.10 healthcare agent in context reference see 7.10.12
1

Figure 23. DIM - Communicating Parties Subsystem


Page 52 prENV 13606-4:1999 7.3.1. communicating party

Type: Abstract Class Description: A healthcare agent (7.10.10) involved in the communication of EHCR information. Specialisations A communicating party is specialised as an EHCR message related agent (7.3.4), an EHCR destination (7.3.3), an EHCR source (7.3.2) or an originator of referenced message (7.3.5). Attributes healthcare agent in context reference (7.10.12) Type class Occurrence 1

A reference to a healthcare agent in context (7.10.11) using an unique identifier. 7.3.2. EHCR source

Type: class Specialisation of: communicating party Description: A communicating party that sends EHCR information or receives a request for EHCR information. Contained in An EHCR source is the source or intended source of EHCR information referred to by or contained in any number of EHCR messages (7.4.1). Attributes healthcare agent in context reference (7.10.12) Type class Occurrence 1

Attributes from generalisation: communicating party (7.3.1) A reference to a healthcare agent in context (7.10.11) using an unique identifier. 7.3.3. EHCR destination

Type: class Specialisation of: communicating party Description: A communicating party that receives EHCR information or sends a request for EHCR information. Contained in An EHCR destination receives or is intended to receive EHCR information referred to or contained in any number of EHCR messages (7.4.1). Attributes healthcare agent in context reference (7.10.12) Type class Occurrence 1

Attributes from generalisation: communicating party (7.3.1) A reference to a healthcare agent in context (7.10.11) using an unique identifier.


Page 53 prENV 13606-4:1999 7.3.4. EHCR message related agent

Type: class Specialisation of: communicating party Description: A communicating party, other than the EHCR source (7.3.2) or EHCR destination (7.3.3), referred to in a message to indicate their involvement in the process of communication. Usage: An EHCR message related agent may be: -- A party that acts as a forwarding agent for messages that request or provide EHCR information. -- Another recipient of the same EHCR information. In this case, the purpose of including this in the message is to inform the recipient of a message about the other recipients of the same information. -- The EHCR source (7.3.2) or EHCR destination (7.3.3) of another EHCR related message. This enables an EHCR notification message (7.4.4) to inform a third party that an EHCR message has been sent to or received from another party. -- A Trusted Third Party able to confirm that the EHCR destination (7.3.3) is entitled to receive EHCR information regarding a particular patient; -- A Trusted Third Party able to confirm that the EHCR source (7.3.2) is qualified and/or registered to provide EHCR information. Note: Each EHCR message has one EHCR source (7.3.2) and one EHCR destination (7.3.3). If the EHCR is sent to several parties, each instance of the message has a different EHCR destination (7.3.3). Instances of EHCR message related agent, may be used to represent the list of all the parties involved in a particular communication. Example(s): The intended recipient of this notification (if not the EHCR source (7.3.2) or {EHCR destination). Contained in An EHCR message related agent may have a role in the communication of the EHCR information in any number of EHCR messages (7.4.1). Attributes healthcare agent in context reference (7.10.12) Attributes of specialisation EHCR message related agent role E [Enumerated] 1 An indication of the role of the EHCR message related agent in relation to the current message or a related EHCR message. Usage: Some of the potential roles that may be played by EHCR message related agents are outlined in the notes on usage of this class. The roles to be supported depend on the range of communication functions and message routing options required to meet the needs of a particular communicating community. Values: 0. Copy destination. 1. Forwarding agent. 2. Authorising third party. 3. Originator of this message. 4. Intended recipient. The "originator" and "recipient" roles are only applicable to notification messages sent to or from parties other than the EHCR source or EHCR destination. Type class Occurrence 1

Attributes from generalisation: communicating party (7.3.1) A reference to a healthcare agent in context (7.10.11) using an unique identifier.


Page 54 prENV 13606-4:1999 EHCR message related agent role scope E [Enumerated] 1

An indication of whether the role of the EHCR message related agent applies to this message, to a related EHCR message or to this message and any related messages. Example(s): In a request EHCR message (7.4.2) an EHCR message related agent may be the copy destination for a request or an intended copy destination for a reply to that request. In an EHCR notification message (7.4.4) an EHCR message related agent may be the recipient of a copy of the notification or a copy of a provide EHCR message (7.4.3) referred to by the notification. Values: 0. Role applies to this message. 1. Role applies to expected replies to this message. 2. Role applies to this message and expected replies to this message. 3. Role applies to the referenced message. 7.3.5. originator of referenced message

Type: class Specialisation of: communicating party (7.3.1) Description: The communicating party that originated a message referred to by the current message. Note: Unless a scheme of message identifiers ensures unique identification of all messages exchanged within a communicating community, the originator of referenced message is required to enable a referenced message to be uniquely identified. Contained in An originator of referenced message may qualify the message identifier in any number of message references (7.4.5). Attributes healthcare agent in context reference (7.10.12) Type class Occurrence 1

Attributes from generalisation: communicating party (7.3.1) A reference to a healthcare agent in context (7.10.11) using an unique identifier.


Page 55 prENV 13606-4:1999

7.4.

EHCR message subsystem

EHCR communicating parties subsystem (incomplete) see 7.3 EHCR source see 7.3.2
1 includes information about

EHCR destination see 7.3.3
1

EHCR message related agent see 7.3.4

originator of referenced message see 7.3.5
0..1 may be qualified by

0..* includes information about

may include information about

EHCR message subsystem patient matching information see 7.4.6
is linked to the subject of the EHCR by 1 0..* 0..*

EHCR message
1

may refer to a 0..* previous related message using 0..1 1 1 refers to

0..*

see 7.4.1

message reference see 7.4.5 0..*
0..*

request EHCR message see 7.4.2
0..1

EHCR notification message see 7.4.4
0..1 may refer to EHCR information specified by

provides EHCR information specified by

0..1

provide EHCR message see 7.4.3
0..1

requests EHCR information specified by

1

0..1

1

may include contains EHCR information in

specification of EHCR information see 7.4.7

EHCR distribution rule subsystem 0..1 (incomplete) see 7.9 distribution rule directory see 7.9.3

EHCR structured record subsystem (incomplete) 1 see 7.5 EHCR extract see 7.5.1

Figure 24. DIM - EHCR Message Subsystem


Page 56 prENV 13606-4:1999 7.4.1. EHCR message

Type: Abstract Class Description: An abstract class which represents a generalisation on which all the messages specified by this Prestandard are based. It contains general information applicable to all messages. Note: Includes urgency of the message, request for acknowledgement, comments and language. Specialisations An EHCR message is specialised as an EHCR notification message (7.4.4), a request EHCR message (7.4.2) or a provide EHCR message (7.4.3). Attributes identification of message by originator Type S [String] Occurrence 1

Identifier assigned by the originator of a message. Usage: The identification of message by originator shall be unique for each EHCR message originated by a particular communicating party. Ideally the identification of message by originator should be unique for all each EHCR message within the communicating community. Note: A communicating community may specify a particular concatenation of values to generate a unique message identification. For example, a concatenation of originator identifier, year and a serial number generated by the originating system. issue date and time of message TOCD [Time+Date] 1 Date and time at which a message is issued by the sending application. Note: A mail service may store or batch messages and, as a result, the issue date and time of message need not be the same as the dispatch time to the intended recipient. EHCR source (7.3.2) EHCR destination (7.3.3) EHCR message related agent (7.3.4) class class class 1 1 0 to many A communicating party that sends EHCR information or receives a request for EHCR information. A communicating party that receives EHCR information or sends a request for EHCR information. A communicating party, other than the EHCR source (7.3.2) or EHCR destination (7.3.3), referred to in a message to indicate their involvement in the process of communication. urgency of message E [Enumerated] 1 Indication by sender of the urgency with which the receiver should deal with the request. Usage: This Prestandard does not specify any particular response times for the urgency values. The use and interpretation of these values is dependent on operational agreement within a communicating community. As a general principle, the urgency value "Normal" should be applied to the majority of messages with "Low" and "High" used for exceptions. The urgency value "Immediate" is only applicable in communicating communities where real-time responses are supported. Values: 0. Low 1. Normal 2. High 3. Immediate patient matching information (7.4.6) message receipt acknowledgement request class E [Enumerated] 1 1 Information provided for the purpose of matching an EHCR message to a uniquely identified individual patient. Indication of whether or not the originator of a message requests an acknowledgement of receipt by the recipient. Values: 0. Never acknowledge. 1. Always acknowledge. 2. Acknowledge only if an error is detected.


Page 57 prENV 13606-4:1999 comment on message C/S [Code or String] (7.12.2) 0 to many

A comment from the sender of the message. Note: The comment should only be used to convey information that cannot be represented in other attributes of the EHCR message class. language V [Code Value] (7.12.6) 0 or 1 The language of the message represented by the abbreviations specified in ISO 639. Usage: The coding scheme does not require identification by an ICSI as the codes used are derived directly from ISO 639. Note: Other attributes are provided to specify: -- the predominant language of the EHCR information provided or requested ( language attribute of specification of EHCR information (7.4.7)). -- the language of individual parts of the record ( language attribute of record component (7.5.2)). healthcare agents directory (7.10.19) class 0 or 1 A collection of information about any number of healthcare agents (7.10.10) and/or healthcare agent in contexts (7.10.11) that may be included in the message to enable subsequent reference without repetition of the detailed information. Usage: healthcare agents directory information need not be included in a message if it is available in a shared directory stored on, or accessible from, systems used by the systems between which the message is exchanged. Note: The healthcare agents directory represents a directory containing information about healthcare agents (7.10.10) and their inter-relationships in a form that can be referred to by other classes in a message. message reference (7.4.5) class 0 or 1 A reference from an EHCR message to a related message. 7.4.2. request EHCR message

Type: message Specialisation of: EHCR message Description: A message used to send a request for EHCR information from an EHCR destination (7.3.3) to an EHCR source (7.3.2). Attributes Attributes from generalisation: EHCR message (7.4.1) identification of message by originator Identifier assigned by the originator of a message. issue date and time of message EHCR source (7.3.2) EHCR destination (7.3.3) EHCR message related agent (7.3.4) TOCD [Time+Date] class class class 1 1 1 0 to many Date and time at which a message is issued by the sending application. The communicating party to which a request for EHCR information is sent in this message. The communicating party that requested EHCR information by sending this message. A communicating party, other than the EHCR source (7.3.2) or EHCR destination (7.3.3), referred to in a message to indicate their involvement in the process of communication. Example(s): An intermediary involved in the communication of this message or the anticipated response. A Trusted Third Party able to confirm that the EHCR destination (7.3.3) is entitled to receive EHCR information regarding a particular patient. Another destination to whom a copy of the response to this message should be sent. urgency of message E [Enumerated] 1 Indication by sender of the urgency with which the receiver should deal with the request. S [String] 1 Type Occurrence


Page 58 prENV 13606-4:1999 patient matching information (7.4.6) message receipt acknowledgement request class E [Enumerated] 1 1

Information provided for the purpose of matching an EHCR message to a uniquely identified individual patient. Indication of whether or not the originator of a message requests an acknowledgement of receipt by the recipient. comment on message A comment from the sender of the message. language healthcare agents directory (7.10.19) V [Code Value] (7.12.6) class 0 or 1 0 or 1 The language of the message represented by the abbreviations specified in ISO 639. A collection of information about any number of healthcare agents (7.10.10) and/or healthcare agent in contexts (7.10.11) that may be included in the message to enable subsequent reference without repetition of the detailed information. message reference (7.4.5) Attributes of specialisation specification of EHCR information (7.4.7) class 1 A specification of the language and completeness of content of the EHCR information requested by this message. The specification of EHCR information may include an identification of the enterprise environment and/or communicating community of the party requesting EHCR information. reason for request 7.4.3. provide EHCR message C/S [Code or String] (7.12.2) 1 An indication of the reason for requesting EHCR information. class 0 or 1 A reference from an EHCR message to a related message. C/S [Code or String] (7.12.2) 0 to many

Type: message Specialisation of: EHCR message (7.4.1) Description: A message used to send EHCR information from an EHCR source (7.3.2) to an EHCR destination (7.3.3). Attributes Attributes from generalisation: EHCR message (7.4.1) identification of message by originator Identifier assigned by the originator of a message. issue date and time of message EHCR source (7.3.2) EHCR destination (7.3.3) EHCR message related agent (7.3.4) TOCD [Time+Date] class class class 1 1 1 0 to many Date and time at which a message is issued by the sending application. The communicating party that provided the EHCR information in this message. The communicating party to which EHCR information is sent in this message. A communicating party, other than the EHCR source (7.3.2) or EHCR destination (7.3.3), referred to in a message to indicate their involvement in the process of communication. Example(s): An intermediary involved in the communication of the message. A Trusted Third Party, which confirms that the EHCR source (7.3.2) is qualified and/or registered to provide EHCR information. A copy destination that received the same information. S [String] 1 Type Occurrence


Page 59 prENV 13606-4:1999 urgency of message patient matching information (7.4.6) message receipt acknowledgement request E [Enumerated] class E [Enumerated] 1 1 1

Indication by sender of the urgency with which the receiver should deal with the request. Information provided for the purpose of matching an EHCR message to a uniquely identified individual patient. Indication of whether or not the originator of a message requests an acknowledgement of receipt by the recipient. comment on message A comment from the sender of the message. language healthcare agents directory (7.10.19) V [Code Value] (7.12.6) class 0 or 1 0 or 1 The language of the message represented by the abbreviations specified in ISO 639. A collection of information about any number of healthcare agents (7.10.10) and/or healthcare agent in contexts (7.10.11) that may be included in the message to enable subsequent reference without repetition of the detailed information. message reference (7.4.5) class 0 or 1 An optional reference to the request EHCR message (7.4.2) to which this message is a response. Usage: If the provide EHCR message is a response to a request EHCR message it should refer to that message. Attributes of specialisation specification of EHCR information (7.4.7) class 1 A specification of the language and completeness of content of the EHCR information provided in this message. The specification of EHCR information may include an identification of the nature of the enterprise environment and/or communicating community applicable to system from which the EHCR information was derived. distribution rule directory (7.9.3) class 0 or 1 The set of distribution rules (7.9.1) that apply to all or part of the EHCR infor mation conveyed in a provide EHCR message. EHCR extract (7.5.1) class 1 An EHCR message component (7.8.1) that represents the entire EHCR content of the message. If the message contains the entire EHCR for the patient the EHCR extract is equivalent to the EHCR Root Architectural Component specified in Part 1 of this European Prestandard. However, if differs in that it need not contain the entire EHCR but may instead contain a subset of, or update to, the EHCR. C/S [Code or String] (7.12.2) 0 to many


Page 60 prENV 13606-4:1999 7.4.4. EHCR notification message

Type: message Specialisation of: EHCR message (7.4.1) Description: A message sent by a healthcare agent (7.10.10) to another healthcare agent (7.10.10) to notify the recipient of the state or action related to the communication of EHCR information. Note: The EHCR source (7.3.2) may send any of the following notifications to an EHCR destination (7.3.3) or to an EHCR message related agent (7.3.4). -- request EHCR message (7.4.2) received. -- request for EHCR accepted. -- request for EHCR rejected. -- provide EHCR message (7.4.3) sent. The EHCR destination (7.3.3) may send any of the following notifications to an EHCR source (7.3.2) or to an EHCR message related agent (7.3.4). -- request EHCR message (7.4.2) sent. -- provide EHCR message (7.4.3) received. -- EHCR information accepted. -- EHCR information rejected. Attributes Attributes from generalisation: EHCR message (7.4.1) identification of message by originator Identifier assigned by the originator of a message. issue date and time of message EHCR source (7.3.2) TOCD [Time+Date] class 1 1 Date and time at which a message is issued by the sending application. The communicating party that according to the nature of the notification contained in this message: -- sent EHCR information; -- rejected a request for EHCR information; -- received a request for EHCR information; -- was intended to receive a request for EHCR information. EHCR destination (7.3.3) class 1 The communicating party that according to the nature of the notification contained in this message: -- sent a request for EHCR information; -- received EHCR information; -- was intended to receive EHCR information. EHCR message related agent (7.3.4) class 0 to many A communicating party, other than the EHCR source (7.3.2) or EHCR destination (7.3.3), referred to in a message to indicate their involvement in the process of communication. urgency of message patient matching information (7.4.6) message receipt acknowledgement request E [Enumerated] class E [Enumerated] 1 1 1 Indication by sender of the urgency with which the receiver should deal with the request. Information provided for the purpose of matching an EHCR message to a uniquely identified individual patient. Indication of whether or not the originator of a message requests an acknowledgement of receipt by the recipient. S [String] 1 Type Occurrence


Page 61 prENV 13606-4:1999 comment on message A comment from the sender of the message. language healthcare agents directory (7.10.19) V [Code Value] (7.12.6) class 0 or 1 0 or 1 The language of the message represented by the abbreviations specified in ISO 639. A collection of information about any number of healthcare agents (7.10.10) and/or healthcare agent in contexts (7.10.11) that may be included in the message to enable subsequent reference without repetition of the detailed information. message reference (7.4.5) class 0 or 1 An optional reference to the request EHCR message (7.4.2) to which this message is a response. Usage: If the provide EHCR message (7.4.3) is a response to a request EHCR message it should refer to that message. Attributes of specialisation specification of EHCR information (7.4.7) class 0 or 1 A specification of the language and completeness of content of the EHCR information requested or provided in the activity notified by this message. EHCR message notification type E [Enumerated] 1 An indication of the type of notification. Values: 0. Request EHCR message sent. 1. Request EHCR message received. 2. Request for EHCR accepted. 3. Request for EHCR rejected. 4. Provide EHCR message sent. 5. Provide EHCR message received. 6. EHCR information accepted. 7. EHCR information rejected. 8+. Other notifications. The nature of the notification is represented by EHCR message notification comment. EHCR message notification comment C/S [Code or String] (7.12.2) 1 A text or coded comment or qualification of the new. Example(s): The reason for rejection of a request. Coded representation of other types of notification required by the communicating community. 7.4.5. message reference C/S [Code or String] (7.12.2) 0 to many

Type: class Description: A reference from an EHCR message (7.4.1) to a related message. Contained in A message reference may be part of an EHCR message (7.4.1). Attributes identification of message by originator issue date and time of message Type S [String] TOCD [Time+Date] Occurrence 1 0 or 1

The identifier assigned by the originator of the referenced message. Date and time at which the referenced message was issued by the sending application. Note: This may be included to provide verification of the identification of the referenced message. originator of referenced message (7.3.5) class 0 or 1 The communicating party that originated a message referred to by the current message.


Page 62 prENV 13606-4:1999 7.4.6. patient matching information

Type: class Description: Information provided for the purpose of matching an EHCR message (7.4.1) to a uniquely identified individual patient. Note: This class includes patient identifiers, names and other supporting information. All the attributes are optional but at least one element shall be included in any instance of this class. This class is not intended for providing or updating administrative or demographic information about the patient. For this purpose the relevant data items (7.6.1) should be used as part of the EHCR extract (7.5.1). Contained in patient matching information identifies the subject of an EHCR message (7.4.1). Associations patient matching information identifies the subject of an EHCR extract (7.5.1). Attributes One or more of patient identifiers party identifiers (7.11.10) Type Occurrence 0 or 1

A set of one or more party identifiers (7.11.10) used to identify the patient. Note: Each identifier (7.11.5) is qualified to indicate the identification scheme from which it is derived. person name person name details (7.11.12) The structured or unstructured name of a person. Note: This includes the type of name and period of validity as well as an option for use of either structured or unstructured names. date of birth TOCD [Time+Date] Note: In case the exact date and time is unknown, year only or year + month or year + month + day are sufficient. alternative person name person administrative sex person name details (7.11.12) E [Enumerated] 0 to many 0 or 1 An alternative name by which the person is, or has been, known. The gender of the patient as recognised by the organisation responsible for administration of healthcare services. Note: In rare cases this may differ from genetic or anatomical gender which may be recorded as clinical information. Represented by the abbreviations specified in ISO 5281. Values: 0. Unknown 1. Male 2. Female 9. Unspecified person address address (7.11.1) 0 to many An address associated with a person. Each address contains an address type and a period of validity. These attributes can be used to specify former addresses, temporary addresses and to distinguish between home and work addresses.


Page 63 prENV 13606-4:1999 7.4.7. specification of EHCR information

Type: class Description: A specification of the language and completeness of content of the EHCR information requested or provided. The specification of EHCR information may include an identification of the nature of the enterprise environment and/or communicating community of the party sending the message. Contained in specification of EHCR information specifies the EHCR information provided by a request EHCR message (7.4.2). specification of EHCR information may be part of a provide EHCR message (7.4.3). specification of EHCR information may indicate the EHCR referred to by an EHCR notification message (7.4.4). Attributes communicating community identifier Type identifier (7.11.5) Occurrence 0 or 1

An identification of the communicating community within which this message is intended to be used. Usage: Communicating communities may specify community defined data items (7.6.16) and may impose particular implementation guidelines on systems that use these messages. The communicating community identifier is provided to allow the sender of message to inform the recipient about the source of any guidelines applicable to the message or to anticipated responses to the message. enterprise identifier identifier (7.11.5) 0 or 1 An indication of the enterprise environment applicable to an EHCR message or to an enterprise item within a message. Usage: When used in a provide EHCR message (7.4.3) the enterprise identifier indicates the source of reference for any community defined data items (7.6.16) that are not generally used throughout the community specified by the communicating community identifier. When used in a request EHCR message (7.4.2) the enterprise identifier indicates the enterprise characteristics of the EHCR destination (7.3.3). This information may be used by the EHCR source (7.3.2) to determine whether it is appropriate to include any community defined data items (7.6.16) that are specific to a particular enterprise. EHCR language V [Code Value] (7.12.6) 0 or 1 The language in which the EHCR was requested or provided. Usage: The language should be represented by the abbreviations specified in ISO 639. EHCR scope E [Enumerated] 1 An indication of whether the EHCR information contained in (or requested by) the message is complete, a selected subset or an update of changes during a specified EHCR update period. Note: The message does not provide a mechanism for constructing and submitting detailed selection criteria for subset of the EHCR. However, the scope of the EHCR information provided may be a subset of the record selected by a healthcare person (7.10.14) acting as the EHCR source (7.3.2). When the message is used to convey a subset of the message the EHCR subset description may be used to describe the nature of the subset. Values: 0. Complete 1. Subset 2. Update determined by EHCR update period


Page 64 prENV 13606-4:1999 EHCR subset description C/S [Code or String] (7.12.2) 0 or 1

A description the nature of a subset of the EHCR included a provide EHCR message (7.4.3) or requested by a request EHCR message (7.4.2). Note: A subset of the EHCR may be a general-purpose summary or may be created to provide a particular view of the patient. The EHCR subset description provides a free text label or a code from a list of EHCR extract (7.5.1) types determined and agreed within a communicating community. This attribute is not intended to be used for fully automated selection but the coded values may enable the systems to assist the clinician to prepare an appropriate summary. This attribute should only be used if the EHCR scope attribute is set as "subset". Example(s): General summary, nursing care records, summary from diabetic specialist for ophthalmologist. EHCR update period period (7.11.11) 0 or 1 EHCR update period the period of time to which the requested or provided part of the EHCR applies. Note: Unless otherwise agreed between the communicating parties, the period applies to the date and time or origin of the relevant EHCR message components (7.8.1). patient consent status C/S [Code or String] (7.12.2) 0 or 1 An indication of the fact that the patient has (or has not) given consent for the requested transfer of information. It may also indicate any limitations in the consent given. Usage: This Prestandard does not specify how this attribute should be used. It is included to enable use in accordance with local business practice as agreed within a communicating community. Note: This attribute indicates the message originators understanding of the consent status. It is not intended as a means of communicating verifiable patient consent.


Page 65 prENV 13606-4:1999

7.5.

EHCR structured record subsystem
EHCR message subsystem (incomplete) see 7.4 provide EHCR message see 7.4.3
1 conveys the EHCR in 1

EHCR message component subsystem (incomplete) see 7.8 EHCR message component see 7.8.1

EHCR message subsystem (incomplete) see 7.4 patient matching information see 7.4.6
0..1

EHCR structured record subsystem folder
for patient identified by 0..1 is specialised as

EHCR extract
is a type of

see 7.5.1
0..1

see 7.5.4 composition see 7.5.5 headed section see 7.5.6

contains contains {constraint 1}

1

original component complex see 7.5.3

1..*

1..*

record component see 7.5.2

selected component complex see 7.5.8

cluster see 7.5.7

empty record component see 7.5.9

EHCR link subsystem (incomplete) see 7.7
is specialised as

link set item see 7.7.1

EHCR data item subsystem (incomplete) see 7.6
Constraint 1: Each record component is either part of an original record component or part of the EHCR extract.

data item see 7.6.1

Figure 25. DIM - EHCR Structured Record Subsystem


Page 66 prENV 13606-4:1999 7.5.1. EHCR extract

Type: class Specialisation of: EHCR message component (7.8.1) Description: An EHCR message component (7.8.1) that represents the entire EHCR content of the message. If the message contains the entire EHCR for the patient the EHCR extract is equivalent to the EHCR Root Architectural Component specified in Part 1 of this European Prestandard. However, if differs in that it need not contain the entire EHCR but may instead contain a subset of or update to the EHCR. Usage: A provide EHCR message (7.4.3) shall contain one and only one EHCR extract whether it contains the entire EHCR, a summary of the EHCR or an update to a previously communicated EHCR. The simplest instance of a message based on this standard consists of an EHCR extract class containing a single text data item (7.6.2) with the component role "Narrative Text". In this simplistic version of the message the text data item (7.6.2) contains a textual version of all the EHCR information to be communicated. Contained in An EHCR extract conveys the EHCR in a provide EHCR message (7.4.3). Associations An EHCR extract contains EHCR information about a patient identified by patient matching information (7.4.6). Attributes component unique identifier (7.8.5) component identification by originating system Type class S [String] Occurrence 1 0 or 1

Attributes from generalisation: EHCR message component (7.8.1) Identifies an instance of EHCR extract as a unique EHCR message component. An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) class TOCD [Time+Date] E [Enumerated] class 1 1 0 or 1 0 to many A reference to the healthcare agent (7.10.10) responsible for generating this EHCR extract. Date and time on which this EHCR extract was generated. An indication of the validity of the originating date and time. A reference to a healthcare agent (7.10.10) that has a role in relation to the content of an EHCR message component, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. related date (7.8.7) component name category Not applicable to this specialisation. component name structure (7.8.4) An optional coded description of the EHCR extract. component status E [Enumerated] 1 The component status of the EHCR extract in a provide EHCR message (7.4.3) should always be "Current". class 0 or 1 class TL [Term List code] (7.12.5) 0 to many None


Page 67 prENV 13606-4:1999 distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) Information about the attestation of the EHCR extract. component language V [Code Value] (7.12.6) 0 or 1 The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. Attributes of specialisation record component (7.5.2) class 1 to many The EHCR extract consists of one or more members. Each member is an instance of one of the concrete specialisations of the abstract class record component. Usage: An EHCR extract may contain record components of the following types: -- folder (7.5.4) -- composition (7.5.5) -- selected component complex (7.5.8) -- link set item (7.7.1) -- text data item (7.6.2) -- empty record component. A EHCR extract shall not contain record components of the following types: -- headed section (7.5.6) -- cluster (7.5.7) -- data items (7.6.1) of types other than text data item (7.6.2). If the message includes a narrative text account of its contents, this should be contained in a single text data item (7.6.2) with the component role "Narrative". 7.5.2. record component class class class 0 to many 0 or 1 0 to many

Applies a referenced distribution rule (7.9.1) to all the contents of the EHCR extract. A link to a previous version of this EHCR extract which is superseded by this EHCR extract.

Type: Abstract Class Specialisation of: EHCR message component (7.8.1) Description: A record component is a part of an EHCR that is identifiable for the purposes of referencing and revision. Note: A record component is an abstract class that only exists as instantiations on one of its concrete specialisations. Two of the specialisations ( original component complex (7.5.3), and data item (7.6.1)) are themselves abstract classes and only exist as instances of the more specialised types of original component complex (7.5.3) and data item (7.6.1). Part 1 of this Prestandard specifies an additional abstract class component complex. This is a specialisation of record component that is itself further specialised into original component complex (7.5.3) and selected component complex (7.5.8). Although the component complex represents a conceptual relationship it does not have any attributes or relationships other than those of its generalisation record component and its specialisations. Therefore, it plays no part in providing structure or content to the message. Specialisations A record component is specialised as an empty record component, a data item (7.6.1), a link set item (7.7.1), an original component complex (7.5.3) or a selected component complex (7.5.8). Contained in A record component may be part of an original component complex (7.5.3). A record component may be part of an EHCR extract.


Page 68 prENV 13606-4:1999 Attributes component unique identifier (7.8.5) component identification by originating system Type class S [String] Occurrence 1 0 or 1

Attributes from generalisation: EHCR message component (7.8.1)

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) class 0 or 1 A reference to the healthcare agent (7.10.10) responsible for adding the record component to the record. Usage: Other parties associated with the EHCR message component shall be represented as related healthcare agents (7.8.8). originating date and time originating date validity related healthcare agent (7.8.8) TOCD [Time+Date] E [Enumerated] class 0 or 1 0 or 1 0 to many Date and time on which the record component was added to the EHCR system on which it originated.

A reference to a healthcare agent (7.10.10) that has a role in relation to the record component, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. related date (7.8.7) class 0 to many A date, other than the originating date and time, which is related to information recorded in a data item (7.6.1). The relevance of the date is specified by the attribute related date role. component name category TL [Term List code] (7.12.5) 0 or 1 A standard high-level category assigned to an EHCR message component to support communication. Usage: The component name category is mandatory is some specialisation of EHCR message component and not used in others. Refer to the specialisations for further details. Values: The acceptable values of component name category are specified by tables in Part 2 of this Prestandard. The applicable table of values varies according to the specialisation of record component and is specified separately for each specialisation. component name structure (7.8.4) class 0 or 1 A coded descriptor, title, heading or label that represents the nature or focus of the information contained by in the record component. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1 Indication of whether the record component is the current valid version or has been superseded. Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component. Information about the attestation of the record component. The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. Attributes of specialisation component order I [Integer] 0 or 1 A positive integer representing the order of a record component within its original component complex (7.5.3). Note: The component order should be specified if reordering record components within the original component complex (7.5.3) could lead to loss of pertinent information. For example, if the record components within the original component complex (7.5.3) describe a logical sequence of events.


Page 69 prENV 13606-4:1999 7.5.3. original component complex Type: Abstract Class Specialisation of: record component Description: The original component complex is an abstract specialisation of record component (7.5.2). Its concrete specialisations all have the property of grouping other record components (7.5.2) (the members of the original component complex) in a manner determined by the original information context; that is the original time and situation in which they were originally added to the EHCR. The specialisations of original component complex represent different levels or granularity in respect of the scope of the original information context. Usage: The original component complexes in a provide EHCR message (7.4.3) form a hierarchy with a single axis linking each EHCR message component (7.8.1) to the EHCR extract (7.5.1). An original component complex should not be used to aggregate record components (7.5.2) to represent clinical or logical relationships between items of information collected at different times or in different places. Except as explicitly stated elsewhere in this part of the Prestandard, the following rules govern propagation of values from an original component complex to its members and descendants within a message. -- The value of an attribute stated for an original component complex is propagated to descendent members of that original component complex that do not themselves contain a value for an equivalent attribute. -- Propagation of a value is terminated by a value for the same attribute specified at a lower level in the hierarchy. -- In the case of attributes that may have multiple values the propagation rule applies to the entire set of values. Thus if a record component (7.5.2) contains any values for a particular attribute this interrupts propagation of the complete set of values for that attribute. -- Propagation of values applies to selected component complexes (7.5.8) and link set items (7.7.1) as members of an original component complex but does not cross to the members of a selected component complex (7.5.8) or to other record components (7.5.2) linked by a link set item (7.7.1). -- All applicable attribute values must be stated explicitly in an original component complex of the type composition (7.5.5). Values from a folder (7.5.4) type original component complex are not propagated to a composition (7.5.5) type original component complex. Note: The four specialisations of original component complex included in the message are referred to in Part 1 and Part 2 of this Prestandard as types of original component complex. They are identified as specialised classes in the message to enable distinctions to be made regarding: -- constraints on their relationships and attributes. -- the values applicable to attributes. Specialisations An original component complex is specialised as a composition (7.5.5), a headed section (7.5.6), a cluster (7.5.7) or a folder (7.5.4). Attributes Type Occurrence

Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1

An optional additional identifier based on the identification of the EHCR message component in the originating system.


Page 70 prENV 13606-4:1999 originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) class TOCD [Time+Date] E [Enumerated] class 0 or 1 0 or 1 0 or 1 0 to many

A reference to the healthcare agent (7.10.10) responsible for adding the record component to the record. Date and time on which the record component was added to the EHCR system on which it originated.

A reference to a healthcare agent (7.10.10) that has a role in relation to the record component, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. related date (7.8.7) class 0 to many A date, other than the originating date and time, which is related to an original component complex. The relevance of the date is specified by the attribute related date role. component name category TL [Term List code] (7.12.5) 0 or 1 A standard high-level category assigned to a record component to support communication. Refer to concrete specialisations of original component complex for details. component name structure (7.8.4) class 0 or 1 A coded descriptor, title, heading or label that represents the nature or focus of the information contained by in the record component. component status distribution rule reference (7.9.2) revision information (7.7.4) E [Enumerated] class class 1 0 to many 0 or 1

A reference to the immediately preceding version of this record component. Usage: An original component complex shall only be used to supersede a previous version that is another instance of the same concrete specialisation of original component complex. attestation (7.8.2) component language class V [Code Value] (7.12.6) 0 to many 0 or 1 Information about the attestation of the record component. The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order Attributes of specialisation enterprise specific indicator B [Boolean] 0 or 1 An indication that the original component complex is an enterprise specific structure representing an alternative version of the standard structured content of the original component complex or EHCR extract (7.5.1) of which it is a member. record component (7.5.2) class 1 to many Each original component complex contains of one or more members. Each member is an instance of one of the concrete specialisations of the abstract class record component. Usage: The members of an original component complex may themselves be original component complexes. However, certain restrictions apply to the types of original component complexes that may be nested within one another. These restrictions are specified in the descriptions of the individual specialisations. I [Integer] 0 or 1


Page 71 prENV 13606-4:1999 7.5.4. folder

Description: An original component complex (7.5.3) used to group record components (7.5.2) collected and/or recorded during several contacts with a patient. A folder may include information collected and recorded at different times and by different people. Type: class Specialisation of: original component complex Usage: A folder shall be a member of one and only one of the following: -- EHCR extract (7.5.1) -- another folder. Attributes Type Occurrence

Attributes from generalisation: original component complex (7.5.3) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) class TOCD [Time+Date] E [Enumerated] class 0 or 1 0 or 1 0 or 1 0 to many A reference to the healthcare agent (7.10.10) responsible for adding the record component to the record. Date and time on which the record component was added to the EHCR system on which it originated.

A reference to a healthcare agent (7.10.10) that has a role in relation to the record component, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. related date (7.8.7) class 0 to many A date, other than the originating date and time, which is related to an original component complex. The relevance of the date is specified by the attribute related date role. component name category component name structure (7.8.4) TL [Term List code] (7.12.5) class None 0 or 1 Not applicable to original component complexes of type folder. A coded descriptor or title for the folder. Example(s): Primary care medical notes, orthopedic specialist notes, nursing notes, records extracted from legacy system. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1

A reference to the immediately preceding version of this record component. Information about the attestation of the record component. The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639.


Page 72 prENV 13606-4:1999 component order enterprise specific indicator I [Integer] B [Boolean] 0 or 1 0 or 1

An indication that the original component complex is an enterprise specific structure representing an alternative version of the standard structured content of the original component complex or EHCR extract (7.5.1) of which it is a member. record component (7.5.2) class 1 to many Usage: A folder may contain record components of the following types: -- folder -- composition (7.5.5) -- selected component complex (7.5.8) -- link set item (7.7.1) -- text data item (7.6.2) -- empty record component. A folder shall not contain record components of the following types: -- headed section (7.5.6) -- cluster (7.5.7) -- data items (7.6.1) of types other than text data item (7.6.2). If the folder includes a narrative text account of its contents, this should be contained in a single text data item (7.6.2) with the component role "Narrative". Attributes of specialisation folder content indicator E [Enumerated] 0 to 1 An indication of whether the contents of the folder in this message are a complete snapshot of the status of a folder at the time or sending or represent an extension to or modification of the content of that folder. Usage: Unlike other types of original component complex, a folder may be extended by addition of record components collected at various times and places. It is also possible that a message may contain only those record components from the folder that are required to support a view represented by a selected component complex (7.5.8). In either of these circumstances the appropriate value for the folder content indicator shall be used to inform the receiving system that the folder as contained in the message does not contain the complete content of the folder as held by the sender. Values: 0. Complete representation of the folder at the date of sending (default). 1. Extension to the folder representing additions during the EHCR update period indicated in the specification of EHCR information (7.4.7) 2. Selected content from a folder provided to support a view.


Page 73 prENV 13606-4:1999 7.5.5. composition

Type: class Specialisation of: original component complex Description: An original component complex (7.5.3) that contains a set of record components (7.5.2) relating to one time and place of care delivery, a single session of recording or a single document included in the EHCR. Usage: A composition shall be a member of one and only one of the following: -- EHCR extract (7.5.1) -- folder (7.5.4). Example(s): Consultation note, operation note, discharge summary, vital signs chart, laboratory report. Attributes Type Occurrence

Attributes from generalisation: original component complex (7.5.3) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) class TOCD [Time+Date] E [Enumerated] class 1 1 0 or 1 0 to many A reference to the healthcare agent (7.10.10) responsible for adding the record component to the record. Date and time on which the record component was added to the EHCR system on which it originated.

A reference to a healthcare agent (7.10.10) that has a role in relation to the record component, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. related date (7.8.7) class 0 to many A date, other than the originating date and time, which is related to an original component complex. The relevance of the date is specified by the attribute related date role. component name category TL [Term List code] (7.12.5) 1 This attribute shall specify a high-level category indicating the general nature of the composition. An additional more detailed title may be provided using the component name structure. Values: The value shall be one the categories for Composition OCC types, listed in Table A.1 of Part 2 of this Prestandard. component name structure (7.8.4) class 0 or 1 In a composition this attribute may be used to include a coded title for the notes, report or document. An appropriate high level category for this heading shall also be included (see component name category). Example(s): The component name structure might be a represent the title "Outpatient consultation". In this case the component name category value would be "DTC01" meaning "Consultations". The component name structure might represent the title "Discharge summary". In this case the component name category value would be "DTC06" meaning "Episode summary reports". component status E [Enumerated] 1


Page 74 prENV 13606-4:1999 distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language class class class V [Code Value] (7.12.6) 0 to many 0 or 1 0 to many 0 or 1

A reference to the immediately preceding version of this record component. Information about the attestation of the record component. The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order enterprise specific indicator I [Integer] B [Boolean] 0 or 1 0 or 1

An indication that the original component complex is an enterprise specific structure representing an alternative version of the standard structured content of the original component complex or EHCR extract (7.5.1) of which it is a member. record component (7.5.2) class 1 to many Usage: A composition may contain record components of the following types: -- headed section (7.5.6) -- cluster (7.5.7) -- selected component complex (7.5.8) -- link set item (7.7.1) -- data item (7.6.1) -- empty record component. A composition shall not contain record components of the following types: -- folder (7.5.4) -- composition. If the composition includes a narrative text account of its entire structured contents, this should be contained in a single text data item (7.6.2) with the component role "Narrative".


Page 75 prENV 13606-4:1999 7.5.6. headed section

Type: class Specialisation of: original component complex Description: An original component complex (7.5.3) representing a sub-division within a composition (7.5.5) the contents of which have a common theme or are derived through the same healthcare process. Usage: A headed section shall be a member of one and only one of the following: -- composition (7.5.5) -- another headed section. Attributes Type Occurrence

Attributes from generalisation: original component complex (7.5.3) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) class 0 or 1 Usage: May be omitted if the value is the same as the value applied to a composition (7.5.5) or headed section which contains this headed section. originating date and time TOCD [Time+Date] 0 or 1 Date and time on which the record component was added to the EHCR system on which it originated. Usage: May be omitted if the value is the same as the value applied to a composition (7.5.5) or headed section which contains this headed section. originating date validity related healthcare agent (7.8.8) E [Enumerated] class 0 or 1 0 to many

A reference to a healthcare agent (7.10.10) that has a role in relation to the record component, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. related date (7.8.7) class 0 to many A date, other than the originating date and time, which is related to an original component complex. The relevance of the date is specified by the attribute related date role. component name category TL [Term List code] (7.12.5) 1 This attribute shall specify a high-level category indicating the general nature of the headed section. An additional more detailed title may be provided using the component name structure. Values: A value from the "Set of Categories for Headed Section OCC Types" as listed in Table A.2 of Part 2 of this Prestandard. component name structure (7.8.4) class 0 or 1 In a headed section this attribute may be used to include a coded title for the section of a report or document. An appropriate high level category for this heading shall also be included (see component name category). Example(s): The component name structure might be a coded section heading "Prescribed medication". In this case the component name category value would be "DTH07" meaning "Delivered Interventions". component status E [Enumerated] 1


Page 76 prENV 13606-4:1999 distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language class class class V [Code Value] (7.12.6) 0 to many 0 or 1 0 to many 0 or 1

A reference to the immediately preceding version of this record component. Information about the attestation of the record component. The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order enterprise specific indicator I [Integer] B [Boolean] 0 or 1 0 or 1

An indication that the original component complex is an enterprise specific structure representing an alternative version of the standard structured content of the original component complex or EHCR extract (7.5.1) of which it is a member. record component (7.5.2) class 1 to many Usage: A headed section may contain record components of the following types: -- headed section -- cluster (7.5.7) -- selected component complex (7.5.8) -- data item (7.6.1) -- empty record component. A headed section shall not contain record components of the following types: -- folder (7.5.4) -- composition (7.5.5) -- link set item (7.7.1). If the headed section includes a narrative text account of its entire structured contents , this should be contained in a single text data item (7.6.2) with the component role "Narrative".

7.5.7.

cluster

Type: class Specialisation of: original component complex Description: A type of original component complex (7.5.3) used to aggregate data items and/or other clusters to represent a compound concept. Usage: A cluster shall be a member of an instance of one and only one of the following: -- composition (7.5.5) -- headed section (7.5.6) -- another cluster. Example(s): A blood pressure measurement consisting of two data items (7.6.1) (one for systolic and the other diastolic pressure), a collection or closely related clinical findings, results of a battery of laboratory investigations, a treatment schedule consisting of several individually specified preparations or dosages.


Page 77 prENV 13606-4:1999 Attributes Type Occurrence

Attributes from generalisation: original component complex (7.5.3) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) class 0 or 1 Usage: May be omitted if the value is the same as the value applied to a composition (7.5.5), headed section (7.5.6) or cluster which contains this cluster. originating date and time TOCD [Time+Date] 0 or 1 Date and time on which the record component was added to the EHCR system on which it originated. Usage: May be omitted if the value is the same as the value applied to a composition (7.5.5), headed section (7.5.6) or cluster which contains this cluster. originating date validity related healthcare agent (7.8.8) E [Enumerated] class 0 or 1 0 to many

A reference to a healthcare agent (7.10.10) that has a role in relation to the record component, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. related date (7.8.7) class 0 to many A date, other than the originating date and time, which is related to an original component complex. The relevance of the date is specified by the attribute related date role. component name category component name structure (7.8.4) TL [Term List code] (7.12.5) class None 0 or 1 Not applicable to original component complexes of type cluster. A coded title or label indicating the nature of the contents of the cluster. Example(s): A code representing concepts such as: Blood pressure, serum electrolytes, examination of peripheral pulses. Usage: If any part of the component name structure modifies the information contained in the cluster in ways that affect the annotation types listed in Table B.1 of Part 2 of this Prestandard, this shall also be indicated by including the appropriate annotation identifier. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1

Information about the attestation of the record component. The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order enterprise specific indicator I [Integer] B [Boolean] 0 or 1 0 or 1

An indication that the original component complex is an enterprise specific structure representing an alternative version of the standard structured content of the original component complex or EHCR extract (7.5.1) of which it is a member.


Page 78 prENV 13606-4:1999 record component (7.5.2) class 1 to many

Usage: A cluster may contain record components of the following types: -- cluster -- data item (7.6.1) -- empty record component. A cluster shall not contain record components of the following types: -- folder (7.5.4) -- composition (7.5.5) -- headed section (7.5.6) -- selected component complex (7.5.8) -- link set item (7.7.1). If the cluster includes a narrative text account of its entire structured contents, this should be contained in a single text data item (7.6.2) with the component role "Narrative". Attributes of specialisation annotation identifier TL [Term List code] (7.12.5) 0 to many An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item (7.6.1) or cluster. Usage: The annotation identifier should not be used as the primary means of communicating modification information. Its is intended to provide a high-level indication of any safety critical modifiers within the information communicated. This may include modifiers that form part of the component name structure or modification implied by the structure of the information in the sending system. Table B.1 of Part 2 of this European Prestandard lists the terms and coded representations to be used as the annotation identifier values. The types of annotation supported are summarised here: -- reliability of annotation -- negation -- subject of information -- certainty -- life cycle (applicable to activities) -- focus -- potentiality (applicable to states) -- knowing mode (observation or action by author, opinion or conclusion by author, etc). -- process status A sending system should only apply an annotation identifier where it can be derived reliably from the data held by that system. If any annotations are derived by automated parsing of text the annotation shall also include the "annotation unreliable" annotation identifier. Implementation guidelines within a communicating community may apply additional constraints to the process of annotation as deemed appropriate to ensure clinical safety. The rules in table B.1 of Part 2 of this Prestandard indicate which annotation types can have more than one value in the same cluster. In all other cases, no more than one value for each annotation type shall be specified for any one cluster. If a cluster does not contain a value for a particular annotation type, the only safe assumption is that nothing is known about that aspect of the information. This Prestandard does not define a default meaning. However, in some communicating communities it may be considered to be clinically safe to apply operational rules in respect of some annotation types. For instance, in the absence of a "subject of information" annotation, the information may be deemed to apply to the patient who is the subject of the record. The risk of misinterpretation of such an approach should be carefully considered. Any assumptions of this type should be stated explicitly in implementation guidelines and only apply to communication within that communicating community. Example(s): The component name structure may include a modifier indicating that an entry refers to "Family history specific to the patient's father". In this case the annotation identifier should be "DS01" meaning "Subject of information = Relative". The component name structure may include a modifier indicating that an entry represents a "Differential diagnosis". In this case the annotation identifier would be "DC01" meaning "Uncertain".


Page 79 prENV 13606-4:1999 7.5.8. selected component complex

Type: class Specialisation of: record component (7.5.2) Description: A record component (7.5.2) representing an aggregation of other record components (7.5.2) arranged in a manner not determined by the time and situation in which they were originally added to the EHCR. Usage: Within the message the members of a selected component complex are communicated using link set items (7.7.1) that associate the member of a view or grouping to the selected component complex. Therefore the selected component complex acts only as a node to which members are attached and has no specialised attributes of its own. This mechanism allows components to be added to a view without changing the components themselves or the selected component complex. Each link set item (7.7.1) is a record component (7.5.2) in its own right. Therefore, attribution of origin and modification of changes to views is taken care of by the general provisions for record components (7.5.2). Note: selected component complexes are used to provide an alternative view or grouping of record components (7.5.2). They can represent the record as viewed at a particular time or they can represent groupings of clinically or logically associated record components. Attributes Type Occurrence

Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) class TOCD [Time+Date] E [Enumerated] class 0 or 1 0 or 1 0 or 1 0 to many A reference to the healthcare agent (7.10.10) responsible for adding the record component to the record. Date and time on which the record component was added to the EHCR system on which it originated.

A reference to a healthcare agent (7.10.10) that has a role in relation to the record component, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. related date (7.8.7) class 0 to many A date, other than the originating date and time, which is related to information recorded in a data item (7.6.1). The relevance of the date is specified by the attribute related date role. component name category TL [Term List code] (7.12.5) 0 or 1 An optional values from Table A.1 or A.2 in Part 2 of this Prestandard may be used where appropriate to the content of a selected component complex. Otherwise this attribute should be omitted. component name structure (7.8.4) class 1 A coded title or heading that describes the nature of the content in the selected component complex. Example(s): -- Problem list -- Diabetes (or another named problem) -- Current medication -- Record as viewed on (date).


Page 80 prENV 13606-4:1999 component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1

Indication of whether the record component is the current valid version or has been superseded. Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component. Information about the attestation of the record component. The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order Attributes of specialisation selected component complex type V [Code Value] (7.12.6) 0 or 1 Distinguishes between different types of selected component complexes. Example(s): -- Fixed views created with explicit links to other record components (7.5.2) (e.g. a "snapshot" of the record at a particular time). -- Views created with explicit links but capable of being updated by addition of new links (e.g. Problem list, problem oriented views). -- Views generated dynamically based on specified selection criteria or a protocol (e.g. current medication, investigation results, chronic disease review profile). splitting restriction E [Enumerated] 0 or 1 An explicit statement that the components selected by the selected component complex should be viewed as a whole, and a warning that the originating healthcare agent (7.8.6) considers that it would be unsafe to separate the selected components. Note: This is intended for binding an ad-hoc set of components found in an EHCR but which are not organised together in the same part of the original component complex (7.5.3) hierarchy. Values: 0. Unsafe to split content. 1. Safe to split content. component selection criteria [defined within a community] 0 to many A specification of criteria designed to support a dynamic view of the record. Example(s): Criteria to select all current medication. I [Integer] 0 or 1 A positive integer representing the order of a record component within its original component complex (7.5.3).


Page 81 prENV 13606-4:1999 7.5.9. empty record component

Type: class Specialisation of: record component (7.5.2) Description: A specialisation of record component (7.5.2) that is used to mark an earlier record component (7.5.2) as deleted. Usage: An empty record component indicates that the component indicated by the revision information (7.7.4) is no longer valid. Attributes Type Occurrence

Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) class 1 A reference to the healthcare agent (7.10.10) responsible for indicating that the previous version of this record component should be marked as superseded or rendered void. originating date and time TOCD [Time+Date] 1 Date and time on which the previous version of this record component was deleted or rendered void on the originating EHCR system. originating date validity related healthcare agent (7.8.8) Not applicable to an empty record component. related date (7.8.7) Not applicable to empty record components. component name category Not applicable to empty record components. component name structure (7.8.4) Not applicable to empty record components. component status distribution rule reference (7.9.2) revision information (7.7.4) E [Enumerated] class class 1 0 to many 1 Indication of whether the record component is the current valid version or has been superseded. Applies a distribution rule (7.9.1) to a record component. A reference to the record component to be deleted or rendered void by this empty record component. Usage: An empty record component may supersede a previous version of any record component. attestation (7.8.2) component language class V [Code Value] (7.12.6) 0 to many 0 or 1 Information about the attestation of the record component. The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order Not applicable to empty record component. I [Integer] None class None TL [Term List code] (7.12.5) None class None E [Enumerated] class 0 or 1 None


Page 82 prENV 13606-4:1999

7.6.

EHCR data item subsystem

EHCR data item subsystem text data item see 7.6.2 structured coded data item see 7.6.3 quantifiable observation data item see 7.6.4 medication data item see 7.6.5 physical entity reference data item see 7.6.8 record component see 7.5.2
is a type of

EHCR structured record subsystem (incomplete) see 7.5

data item see 7.6.1

external data reference data item see 7.6.7 event data item see 7.6.6 person identifier data item see 7.6.11 person name data item see 7.6.12 language data item see 7.6.15 address data item see 7.6.13 telecom data item see 7.6.14 patient related party data item see 7.6.9 related location data item see 7.6.10

community defined data item see 7.6.16

Figure 26. DIM - EHCR Data Item Subsystem


Page 83 prENV 13606-4:1999 7.6.1. data item

Type: Abstract Class Specialisation of: record component (7.5.2) Description: A data item is the EHCR message component (7.8.1) that represents the smallest structural unit into which the content of the EHCR can be broken down without losing its meaning. A data item may aggregate information that cannot be safely disaggregated. Usage: A data item shall be a member of an instance of one and only one of the following: -- composition (7.5.5) -- headed section (7.5.6) -- cluster (7.5.7). An exception to this rule applies in the case of the concrete specialisation text data item (7.6.2) one instance of which may be a member of the EHCR extract (7.5.1) or of any type of original component complex (7.5.3). In these cases, the text data item (7.6.2) provides a narrative account of the structured information within that component. Specialisations A data item is specialised as a related location data item (7.6.10), a language data item (7.6.15), a person identifier data item (7.6.11), a person name data item (7.6.12), an address data item (7.6.13), a telecom data item (7.6.14), a community defined data item (7.6.16), a text data item (7.6.2), a physical entity reference data item (7.6.8), a quantifiable observation data item (7.6.4), an event data item (7.6.6), an external data reference data item (7.6.7), a patient related party data item (7.6.9), a structured coded data item (7.6.3) or a medication data item (7.6.5). Attributes Type Occurrence

Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) class 0 or 1 Usage: May be omitted if the value is the same as the value applied to a composition (7.5.5), headed section (7.5.6) or cluster (7.5.7) which contains this data item. originating date and time TOCD [Time+Date] 0 or 1 Usage: May be omitted if the value is the same as the value applied to a composition (7.5.5), headed section (7.5.6) or cluster (7.5.7) which contains this data item. originating date validity related healthcare agent (7.8.8) related date (7.8.7) component name category E [Enumerated] class class TL [Term List code] (7.12.5) 0 or 1 0 to many 0 to many 0 or 1

A standard high-level category assigned to an EHCR message component to support communication. Usage: Applicability to data items varies according to the concrete specialisations. component name structure (7.8.4) class 0 or 1 A coded descriptor specifying the main focus of the information contained in the data item. Refer to concrete specialisations of data item for further details. Usage: If any part of the component name structure modifies the information contained in the data item in ways that affect the annotation types listed in Table B.1 of Part 2 of this Prestandard, this shall also be indicated by including the appropriate annotation identifier.


Page 84 prENV 13606-4:1999 component status distribution rule reference (7.9.2) revision information (7.7.4) E [Enumerated] class class 1 0 to many 0 or 1

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component. Usage: An original component complex (7.5.3) shall only be used to supersede a previous version that is another instance of the same concrete specialisation of original component complex (7.5.3). A data item shall only be used to supersede a previous version that is another instance of the same concrete specialisation of data item. attestation (7.8.2) component language class V [Code Value] (7.12.6) 0 to many 0 or 1

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order Attributes of specialisation annotation identifier TL [Term List code] (7.12.5) 1 to many An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Usage: The annotation identifier should not be used as the primary means of communicating modification information. Its is intended to provide a high-level indication of any safety critical modifiers within the information communicated. This may include modifiers that form part of the component name structure or modification implied by the structure of the information in the sending system. Table B.1 of Part 2 of this European Prestandard lists the terms and coded representations to be used as the annotation identifier values. The annotation types supported are summarised here: -- reliability of annotation -- negation -- subject of information -- certainty -- life cycle (applicable to activities) -- focus -- potentiality (applicable to states) -- knowing mode (observation or action by author, opinion or conclusion by author, etc). -- process status A sending system should only apply an annotation identifier where it can be derived reliably from the data held by that system. If any annotations are derived by automated parsing of text the annotation shall also include the "annotation unreliable" annotation identifier. Implementation guidelines within a communicating community may apply additional constraints to the process of annotation as deemed appropriate to ensure clinical safety. The rules in table B.1 of Part 2 of this Prestandard indicate which annotation types can have more than one value in the same data item. In all other cases, no more than one value for each annotation type shall be specified for any one data item. If a data item does not contain a value for a particular annotation type, the only safe assumption is that nothing is known about that aspect of the information. This Prestandard does not define a default meaning. See additional notes on annotation identifier within the description of original component complexes of the type cluster (7.5.7). Example(s): The component name structure may include a modifier indicating that an entry refers to "Family history specific to the patient's father". In this case the annotation identifier should be "DS01" meaning "Subject of information = Relative". The component name structure may include a modifier indicating that an entry represents a "Differential diagnosis". In this case the annotation identifier would be "DC01" meaning "Uncertain". I [Integer] 0 or 1 A positive integer representing the order of a record component within its original component complex (7.5.3).


Page 85 prENV 13606-4:1999 7.6.2. text data item

Type: class Specialisation of: data item (7.6.1) Description: A data item content that consists of plain text or presentationally enhanced text. Usage: This element is only suitable for human-readable information and should not be machine processed for analysis or decision support. The structured coded data item (7.6.3) should be used to represent text that is directly associated with structured coded information intended for searches and retrieval of data. A plain text element may be used to provide narrative text describing the content of an original component complex (7.5.3), which is also represented in structured form. This plain text information can then be used as a fallback to ensure communication of human-readable information, even if the receiving system cannot fully interpret the structured content of that complex. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1 Type Occurrence

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) related date (7.8.7) class TOCD [Time+Date] E [Enumerated] class class 0 or 1 0 or 1 0 or 1 0 to many 0 to many

A date, other than the originating date and time, which is related to a text data. The relevance of the date is specified by the attribute related date role. component name category component name structure (7.8.4) Not applicable to text data items. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1 TL [Term List code] (7.12.5) class 0 or 1 None Category values from Part 2 Annex E may be used if appropriate.

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order I [Integer] 0 or 1 A positive integer representing the order of a record component within its original component complex (7.5.3).


Page 86 prENV 13606-4:1999 annotation identifier TL [Term List code] (7.12.5) 1 to many

An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation text markup indicator S [String] 0 or 1 An indication of where mark-up has been used in the associated text block. Usage: Omit if plain text with no mark-up. Otherwise specify the markup applied by repeating the content of the "DOCTYPE" element. Additional attributes can be added to confirm that statement as used in the mark-up Example(s): HTML PUBLIC "-//IETF//DTD HTML//EN" text block S [String] 1 A block of printable human readable text. The text may contain mark-up for presentational enhancement subject to the following four conditions: -- the text markup indicator shall be set to indicate the presence and nature of mark-up. -- presentation enhanced text in this text data item shall not be subjected to automated processing except for the purpose of rendering displaying the appropriately rendered text. -- the mark-up shall be limited to either an ASCII printable 8 bit character set or the Unicode character set. -- the communicating community shall have explicitly agreed and specified a subset of HTML markup to be permitted within that community. While reaching this agreement they should take note of the possible risks to structured communication posed by extensive use of mark-up. Note: There is a strong practical case for using HTML to enhance the presentation and readability of textual information. However, concerns have been raised that full implementation of HTML within the text data item may compromise clinical and/or system safety. The extent of these risk is unproven but any communicating community should consider the following possible risks: -- List and table structures in HTML may embed and hide semantics from the receiving system. Thus a laboratory report rendered as a table may be easy to read. However, a receiving system will not be able to safely manipulate this presentation for analysis or decision support. Thus a possibility arises of inconsistencies and gaps in information that is sent only in a presentational form. -- If communicating parties decide to use the presentational information for processing. The informal structures of text mark-up may circumvent validation applied to the EHCR message structure. -- Full HTML complete with scripts and web links will provide a possible route for attacks on the security and integrity of the EHCR system. One way to minimise these risks while providing an effective mechanism for presentational enhancement would be to specify a subset of HTML. However, this issue remains unclear and the while area is evolving so a normative subset specification is inappropriate at this stage. A very narrow definition of permitted enhancement would be too restrictive to meet the needs of users and developers. On the other hand, mandating an unlimited HTML enabled text data item seems unwise at this stage. Presentational enhancement could also be achieved by using XML with XSL style sheets. However, this will increase the risk that features intended for presentational enhancement may be used for adding arbitrary data structures nested within the standard message structure. A clear distinction should be drawn between use of XML for arbitrary structures within the text data item and the use of XML as a possible implementation of this Prestandard (see Annex C). narrative account indicator B [Boolean] 0 or 1 An indication that the text data item contains a narrative account of the structured content of the original component complex (7.5.3) or EHCR extract (7.5.1) of which it is a member.


Page 87 prENV 13606-4:1999 7.6.3. structured coded data item

Type: class Specialisation of: data item (7.6.1) Description: An item of clinical or other healthcare related information represented by a code value or composite code with optional additional text. Note: The main difference between this and the text data item (7.6.2) is that the information in a structured coded data item is suitable for structured searches and retrieval of data as well as human-readability. In contrast, the text data item (7.6.2) is only suitable for human interpretation and should not be subject to automated processing. Example(s): Family history (e.g. father diabetic), symptoms (e.g. headache), signs (e.g. hepatomegaly), problems (e.g. weight loss or loss of body mass), diagnoses (e.g. thyrotoxicosis, both known and tentative), operative procedures (e.g. pancreatectomy), information given to the patient or relative. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1 Type Occurrence

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) class TOCD [Time+Date] E [Enumerated] class 0 or 1 0 or 1 0 or 1 0 to many

A reference to a healthcare agent (7.10.10) that has a role in relation to the structured coded data, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. Example(s): Person making a diagnosis, person undertaking a procedure, organisation responsible for a procedure, device used during a procedure, software module used to support protocol. related date (7.8.7) class 0 to many A date, other than the originating date and time, which is related to a structured coded data. The relevance of the date is specified by the attribute related date role. Example(s): Date of examination and time of examination, date or diagnosis, date of registration, date of birth, date of death. component name category component name structure (7.8.4) TL [Term List code] (7.12.5) class 0 or 1 1 Category values from Part 2 Annex E may be used if appropriate. A coded representation of the primary focus of a statement about the clinical situation of the patient. Usage: The broad scope of concept "clinical situation" is illustrated in Table D.2 of Part 2 of this Prestandard. Instances of the component name structure of the structured coded data item shall be used for communication of most structured and/or coded information about the clinical situation of the patient. However, quantifiable observations and medication are conveyed in other specialisations of data item. Values: This information can be encoded in a range of different coding schemes and/or controlled terminologies. The composite code structure includes provision for identifying the coding schemes used and for including both the original code recorded on the source systems and a mapping to a coding scheme adopted for the purpose of communication within a defined communicating community.


Page 88 prENV 13606-4:1999 component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation additional related text S [String] 0 to many Text that adds to the content expressed by the code values in this structured coded data item. 7.6.4. quantifiable observation data item

Type: class Specialisation of: data item (7.6.1) Description: Result of a single clinical measurement or laboratory investigation. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1 Type Occurrence

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) class TOCD [Time+Date] E [Enumerated] class 0 or 1 0 or 1 0 or 1 0 to many

A reference to a healthcare agent (7.10.10) that has a role in relation to the quantifiable observation, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. Example(s): Person making or reporting an observation, department responsible for a measurement, device used to carry out a measurement.


Page 89 prENV 13606-4:1999 related date (7.8.7) class 0 to many

A date, other than the originating date and time, which is related to the quantifiable observation. The relevance of the date is specified by the attribute related date role. Example(s): Date and time of measurement, date of reporting results. component name category component name structure (7.8.4) TL [Term List code] (7.12.5) class 0 or 1 1 No category values are specified for quantifiable observation data item. A coded representation of the measurable quantity (i.e. the property that was measured). Usage: The measurable quantity may be represented by a single code value that represents the entire concept of the measurement. Alternatively the composite code can be used to hold code values from a multi-axial coding scheme. Note: The composite code can be used to capture the individual "component", "system" and "kind of quantity" axes specified in by IFCC/IUPAC, was included explicitly in ENV1613 and ENV1614. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation Choice of numerical range result of observation numerical value result of observation measurement range (7.11.8) measurement with comparator (7.11.9) 1

A measurement expressed a range between two numeric values qualified by a unit of quantity. A measurement expressed as a numeric value and unit of quantity with an optional mathematical comparator text value result of observation date value result of observation C/S [Code or String] (7.12.2) TOCD [Time+Date] An observation or investigation result expressed using text or codes. An observation or investigation result expressed as a date. Example(s): Estimated date of obstetric delivery. reference limit (7.11.13) subclass 0 to many A reference limit or normal range expressed as a numeric measurement range (7.11.8) or in a textual form. The limits may be applicable to a particular population and may be of a specified type.


Page 90 prENV 13606-4:1999 7.6.5. medication data item

Type: class Specialisation of: data item (7.6.1) Description: Information about a patient's previous, planned or current treatment with a substance or chemical compound for the prevention, alleviation or treatment of a medical condition. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1 Type Occurrence

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) class TOCD [Time+Date] E [Enumerated] class 0 or 1 0 or 1 0 or 1 0 to many

A reference to a healthcare agent (7.10.10) that has a role in relation to the medication, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. Example(s): Prescriber, dispenser, person administering a drug, person authorising repeat medication, person recommending change of treatment, pharmacy from which dispensed. related date (7.8.7) class 0 to many A date, other than the originating date and time, which is related to a medication data item. The relevance of the date is specified by the attribute related date role. Example(s): Date of prescribing, date of dispensing, date and time of administration. component name category TL [Term List code] (7.12.5) 1 Information that describes the status of the medication data item information. Values: The following values for medication status will appear in a table in Annex E of a future revision of Part 2. 0. Record of current medication (at the time of origin of this item). 1. Past medication. 2. Record of an issued prescription. 3. Record of a decision to prescribe or change dosage. 4. Record of medication administered to the patient. 5. Record of a recommendation. 6. Dispensed for later administration or self-administration. 7. Discontinued. 8. Record of an authorisation of a set of one or more prescriptions. 9. Record of non-compliance or uncompleted regime for any reason 10. Other.


Page 91 prENV 13606-4:1999 component name structure (7.8.4) class 1

A code or composite code identifying the drug, preparation or other prescribable product that is the focus of this medication data item. Usage: The general purpose component name structure shall be used either to represent a drug using a single code or a composite code. The construction of any composite code for identification of a drug may separately represent various properties such as active ingredient(s), pharmaceutical form, strength, manufacturer, pack size. Note: This Prestandard does not mandate a particular structure of drug identification. However, the component name structure can be used with coding schemes and structures that are fully compatible with the unstructured drug identification and structured drug identification classes defined in the Prescription message Prestandard (prENV 13607). component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation Choice of unstructured dosage administration structured dosage administration (7.11.16) days supply quantity of drug supplied C/S [Code or String] (7.12.2) subclass I [Integer] value of quantity (7.11.22) 0 or 1 0 or 1 1

Note: This consists of the attributes numerical value and unit of quantity representing the amount of the drug prescribed, dispensed or administered. medication provision category V [Code Value] (7.12.6) 0 or 1 Whether the medication was provided as an over the counter sale or as a health service, health insurance or private prescription. Usage: Values for this need to be specified in the communicating community in a manner that allows recording of the various methods of supply of medication to patients in that country. Example(s): In the UK their are at several relevant values such as: NHS-GP, NHS-Hospital as outpatient, NHSInpatient, Private and OTC (over the counter sales). Other values may apply elsewhere. medication commercial category E [Enumerated] 0 or 1 Whether the medication prescribed, dispensed or administered was a proprietary or generic form. Values: 0. Generic. 1. Proprietary name with generic substitution permitted. 2. Proprietary.


Page 92 prENV 13606-4:1999 comment to drug treatment S [String] 0 or 1

Usage: This attribute may be used to add an integral free text comment to a medication data item. However, a more flexible approach to commenting on this or any other record component (7.5.2) is to add a separate text data item (7.6.2). This may then be linked to the record component (7.5.2) to which the comment applies using a link set item (7.7.1). repeat medication information (7.11.14) subclass 0 or 1 Information about the authorisation for repeat prescribing. This sub-class is an optional part of the medication data item. It should be included in instances of the medication data item that have the drug information status authorisation. reason for stopping treatment C/S [Code or String] (7.12.2) 0 or 1 The reason why treatment with this medication was stopped. Usage: Only applicable if the drug information status is "discontinued". Note: The person making the decision to stop treatment is recorded as a related healthcare agent (7.8.8) and the date of stopping is as a related date (7.8.7). 7.6.6. event data item

Type: class Specialisation of: data item (7.6.1) Description: Information about a planned or actual event that relates to the care process for an individual. Note: EHCR -- -- -- related events include: individual contacts between health professionals and patients (e.g. consultations, phone calls) admission, transfers and discharges identifiable periods of care (e.g. episodes) Type Occurrence

Attributes Attributes from generalisation: data item (7.6.1)

Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) class TOCD [Time+Date] E [Enumerated] class 0 or 1 0 or 1 0 or 1 0 to many

A reference to a healthcare agent (7.10.10) that has a role in relation to the event, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. Example(s): Person registering a patient, person involved in contact or consultation, department admitting a patient, person planning an admission, organisation responsible for arranging an appointment. related date (7.8.7) class 0 to many A date, other than the originating date and time, which is related to an event. The relevance of the date is specified by the attribute related date role. Example(s): Date of birth, date of death, date of registration, date of admission, date and time of consultation, scheduled date of a planned appointment, date of planning an appointment.


Page 93 prENV 13606-4:1999 component name category TL [Term List code] (7.12.5) 0 or 1

A standard high-level category assigned to an event to support communication. Values: One of the values specified in Table E.1 of Part 2 of this Prestandard. component name structure (7.8.4) class 0 or 1 A coded descriptor specifying the detailed nature of the event. Usage: For the purposes of communication a high-level category for the event should also be specified in the component name category. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation urgency status of event Classification of event in terms of urgency. Example(s): Emergency, elective. administrative outcome C/S [Code or String] (7.12.2) 0 or 1 Information relevant to further action. Note: If a request that is rejected or a planned investigation is postponed there may be further plans (e.g. a new appointment may be issued automatically or only on further request). The reason for postponement may impact future plans (e.g. non-attendance for the appointment, admission or death of the patient). Example(s): patient did not attend appointment, patient died, another appointment given, open appointment, appointment to be given at a later date, no further arrangements will be made. Values: A candidate list of codes and associated terms is provided in Table E.3 of Part 2 this Prestandard. V [Code Value] (7.12.6) 0 or 1


Page 94 prENV 13606-4:1999 duration of event time interval (7.11.20) 0 or 1

An interval of time expressed a number and a unit of time. Usage: If the event is planned this attribute expresses an expected duration. If the event is complete, it expresses an actual duration and if the event is in process the duration so far. If the duration of multiple sub events needs to be communicated (e.g. travel, waiting time and consultation) each should be represented as a separate event. The separate events can then be linked explicitly (using a link set item (7.7.1)) or implicitly (by proximity within an original component complex (7.5.3)). planning stage C [Coded] (7.12.1) 0 or 1 The stage that has been reached in planning the delivery of this event. Usage: Scheduled dates and dates of planning are represented as related dates (7.8.7) in the containing EHCR message component (7.8.1). Example(s): Accepted, proposed, scheduled, completed, rejected, postponed, cancelled. Values: A candidate list of codes and associated terms is provided in Table E.2 of Part 2 this Prestandard. expected delay before event expected delay (7.11.4) 0 or 1 The time interval (7.11.20) of, and reason for, a delay. Usage: Only applicable to events which are planned or being planned. comment 7.6.7. external data reference data item S [String] 0 or 1

Type: class Specialisation of: data item (7.6.1) Description: External reference to information stored in a digital form. Note: A digital representation of an image such as an X-ray or a signal such as an electrocardiograph may be stored on or transferred between computer systems in a manner that makes it accessible to the sender and recipient of a message. The reference pointer attribute group allows a message to refer to information of this type. The message has no internal knowledge of the format of the digital information and use of the reference pointers requires that the sender and recipient of the message have a shared understanding of the information types referred to. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1 Type Occurrence

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) related date (7.8.7) class TOCD [Time+Date] E [Enumerated] class class 0 or 1 0 or 1 0 or 1 0 to many 0 to many

A date, other than the originating date and time, which is related to the external data. The relevance of the date is specified by the attribute related date role. Example(s): Date of a procedure from which the external data reference data item/referenced data item! was derived.


Page 95 prENV 13606-4:1999 component name category component name structure (7.8.4) TL [Term List code] (7.12.5) class 0 or 1 0 or 1

Category values from Part 2 Annex A or Annex E may be used if appropriate. A coded descriptor specifying the nature of the external data. Usage: The component name structure should indicate the healthcare relevant nature of the external data, rather than the file format. Example(s): Chest X-ray, Discharge report, Electrocardiograph. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation EHCR external information identifier external data locator identifier (7.11.5) S [String] 1 1 A unique identifier applied to an item or collection externally referenced digital information. Unique identifier for the referenced information as assigned by the system/application that stores the data. Note: The precise form of expression is determined by the external data application identifier attribute. Example(s): A directory path-name and file-name, a database and a uniquely identified record within that database, a uniquely identified instance of an object. external data application identifier S [String] 0 or 1 Unique identifier of a system and/or application in or through which the externally referenced information is accessible to the recipient of a message. Note: The identifier (7.11.5) must be understood unambiguously by the communicating parties. external data bookmark S [String] 0 to many A reference to an internal pointer or marker within an external referenced source of information. Note: This attribute can only be used if the information type referenced contains an internal referencing system for annotations. The form of expression depends on the information type referenced. Example(s): A reference to an annotation or marked area of an X-ray film.


Page 96 prENV 13606-4:1999 7.6.8. physical entity reference data item

Type: class Specialisation of: data item (7.6.1) Description: A reference to a physical entity such as a paper file, a sample, a film or tracing. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1 Type Occurrence

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) class TOCD [Time+Date] E [Enumerated] class 0 or 1 0 or 1 0 or 1 0 to many

A reference to a healthcare agent (7.10.10) that has a role in relation to the physical entity, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. Example(s): Person responsible for collecting a sample, department responsible for storage of an image. related date (7.8.7) class 0 to many A date, other than the originating date and time, which is related to the physical entity. The relevance of the date is specified by the attribute related date role. Example(s): Scheduled date and time of collection, date and time of sample collection, start and end dates and times of a sample collection. component name category component name structure (7.8.4) TL [Term List code] (7.12.5) class 0 or 1 0 or 1 Category values from Part 2 Annex A or Annex E may be used if appropriate. A coded descriptor specifying the nature of the physical entity. Usage: The component name structure should indicate the healthcare relevant nature of the physical entity. Example(s): Chest X-ray film, throat swab, sample of venous blood. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639.


Page 97 prENV 13606-4:1999 component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many

A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation physical entity identifier identifier (7.11.5) 0 or 1 A general purpose identifier that can be qualified by the identification scheme from which the identifier is derived. physical entity location The current location of the referenced physical entity. 7.6.9. patient related party data item location details (7.11.7) 0 or 1

Type: class Specialisation of: data item (7.6.1) Description: Information about a person or organisation who has a role in relation to the care of a patient other than as a healthcare agent (7.10.10). Note: Additional information about a patient related party data item may be provided by linking an instance of patient related party data item with other data items (7.6.1). For example, an address data item (7.6.13) or telecom data item (7.6.14). Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1 Type Occurrence

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) related date (7.8.7) class TOCD [Time+Date] E [Enumerated] class class 0 or 1 0 or 1 0 or 1 0 to many 0 to many

Usage: In the case of time limited relationships between patient related party and the patient instances of related date should be used to indicate the start and/or end of the period of the relationship. component name category TL [Term List code] (7.12.5) 0 or 1 Usage: This attribute should be used to specify a high-level category indicating the general nature of the relationship between the patient related party and the patient who is the subject of the record. An additional more detailed indication of the relationship may be provided using the component name structure. Values: A value from the Table E.4 of Part 2 of this Prestandard. Example(s): Next of kin, wife, carer, father, guardian, prison officer, friend. component name structure (7.8.4) class 0 or 1 This attribute may be used to specify details of the relationship with the patient related party, if the component name category provides insufficient detail. component status E [Enumerated] 1


Page 98 prENV 13606-4:1999 distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language class class class V [Code Value] (7.12.6) 0 to many 0 or 1 0 to many 0 or 1

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation One or more of name of patient related person organisation name identification of patient related party person name details (7.11.12) S [String] party identifiers (7.11.10) 0 or 1

Identification of a patient related party data item assigned by a national healthcare authority. 7.6.10. related location data item

Type: class Specialisation of: data item (7.6.1) Description: Information about a location including associated information. Note: Associated information may include period (7.11.11) of time at a location, the address (7.11.1), telecommunication (7.11.19) and healthcare organisation (7.10.15) responsible for a location. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1 Type Occurrence

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) related date (7.8.7) class TOCD [Time+Date] E [Enumerated] class class 0 or 1 0 or 1 0 or 1 0 to many 0 to many

Example(s): Organisation responsible for provision of services at a specified location. Usage: If the role of the location is date limited, instances of related date should be used to indicate the start and/or end of that role.


Page 99 prENV 13606-4:1999 component name category TL [Term List code] (7.12.5) 0 or 1 Usage: This attribute should be used to specify a high-level category indicating the general nature of the role of the related location in relation to the patient who is the subject of the record. An additional more detailed indication of the role may be provided using the component name structure. Values: A value from the Table E.5 of Part 2 of this Prestandard. Example(s): Location at which a service was performed, intended location of a service, location prior to a service, location after completion of a service. component name structure (7.8.4) class 0 or 1 This attribute may be used to specify details of the role of the related location in relation to the patient, if the component name category provides insufficient detail. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation One or more of location address of location bed location (7.11.2) telecommunication of location location details (7.11.7) address (7.11.1) subclass telecommunication (7.11.19) 0 to many 0 or 1

Information about a geographical location or type of location, expressed without a formal postal address. An address expressed in a structured or unstructured form. A location expressed as a combination of a bed, a room and ward. Telephone, facsimile and other telecommunication (7.11.19) numbers in a structured or unstructured form.


Page 100 prENV 13606-4:1999 7.6.11. person identifier data item

Type: class Specialisation of: data item (7.6.1) Description: Demographic Information about a person. Includes name, date of birth, sex, address, telecommunication. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1 Type Occurrence

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) related date (7.8.7) component name category Not required for person identifier data item. component name structure (7.8.4) Not required for person identifier data items. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1 class None class TOCD [Time+Date] E [Enumerated] class class TL [Term List code] (7.12.5) 0 or 1 0 or 1 0 or 1 0 to many 0 to many None

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation party identifier identifier (7.11.5) 1


Page 101 prENV 13606-4:1999 7.6.12. person name data item

Type: class Specialisation of: data item Description: The name of the patient. Note: May also be used for alternative names specified using the person name type attribute. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1 Type Occurrence

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) related date (7.8.7) component name category Not required for person name data item. component name structure (7.8.4) Not required for person name data item. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1 class None class TOCD [Time+Date] E [Enumerated] class class TL [Term List code] (7.12.5) 0 or 1 0 or 1 0 or 1 0 to many 0 to many None

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation person name person name details (7.11.12) 1 The structured or unstructured name of a person. Note: This includes the type of name and period of validity as well as an option for use of either structured or unstructured names.


Page 102 prENV 13606-4:1999 7.6.13. address data item

Type: class Specialisation of: data item Description: The address of the patient or of a patient related party. Usage: May also be used for alternative addresses specified using the address type attribute. When used for the address of a patient related party this item should be associated with the appropriate patient related party data item (7.6.9) using a link set item (7.7.1) and an annotation identifier for the subject of information should be included in the address data item. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) related date (7.8.7) component name category Not required for address data item. component name structure (7.8.4) Not required for address data item. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1 class None class S [String] class TOCD [Time+Date] E [Enumerated] class class TL [Term List code] (7.12.5) 1 0 or 1 0 or 1 0 or 1 0 or 1 0 to many 0 to many None Type Occurrence

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation person address address (7.11.1) 1 An address associated with a person. Each address contains an address type and a period of validity. These attributes can be used to specify former addresses, temporary addresses and to distinguish between home and work addresses.


Page 103 prENV 13606-4:1999 7.6.14. telecom data item

Type: class Specialisation of: data item (7.6.1) Description: A telecommunication number associated with the patient or a patient related party. Usage: When used for the telecommunication number of a patient related party this item should be associated with the appropriate patient related party data item (7.6.9) using a link set item (7.7.1) and an annotation identifier for the subject of information should be included in the telecom data item. A telecommunication number can be associated with an address either by including the appropriate address type of telecommunication or by linking the address data item (7.6.13) to the telecom data item using a link set item (7.7.1). Note: Various telecommunication numbers can be specified using the telecommunication type attribute. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) related date (7.8.7) component name category Not required for telecom data item. component name structure (7.8.4) Not required for telecom data items. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language component order annotation identifier E [Enumerated] class class class V [Code Value] (7.12.6) I [Integer] TL [Term List code] (7.12.5) 1 0 to many 0 or 1 0 to many 0 or 1 0 or 1 1 to many class None class S [String] class TOCD [Time+Date] E [Enumerated] class class TL [Term List code] (7.12.5) 1 0 or 1 0 or 1 0 or 1 0 or 1 0 to many 0 to many None Type Occurrence

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation person telecommunication telecommunication (7.11.19) 1


Page 104 prENV 13606-4:1999 7.6.15. language data item

Type: class Specialisation of: data item (7.6.1) Description: A language spoken by the patient or a patient related party. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1 Type Occurrence

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) related date (7.8.7) component name category Not required for language data item. component name structure (7.8.4) Not required for language data item. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1 class None class TOCD [Time+Date] E [Enumerated] class class TL [Term List code] (7.12.5) 0 or 1 0 or 1 0 or 1 0 to many 0 to many None

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7). Attributes of specialisation language details of party language details (7.11.6) 1 Information about the ability of a person or organisation to communicate using a particular language.


Page 105 prENV 13606-4:1999 7.6.16. community defined data item

Type: class Specialisation of: data item (7.6.1) Description: This abstract class provides an optional extension of the EHCR message using a specialised data items (7.6.1) with contents defined for use between members of a particular communicating community. The definition of the content of a community defined data item is specified by the data item type reference. Attributes Attributes from generalisation: data item (7.6.1) Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1 Type Occurrence

An optional additional identifier based on the identification of the EHCR message component in the originating system. originating healthcare agent (7.8.6) originating date and time originating date validity related healthcare agent (7.8.8) related date (7.8.7) component name category class TOCD [Time+Date] E [Enumerated] class class TL [Term List code] (7.12.5) 0 or 1 0 or 1 0 or 1 0 to many 0 to many 0 or 1

Category values should be enumerated as part of the definition of a particular type of community defined data item. component name structure (7.8.4) class 0 or 1 Usage: Use of the component name structure in a community defined data item should be determined as part of the definition of a particular community defined data item. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) component language E [Enumerated] class class class V [Code Value] (7.12.6) 1 0 to many 0 or 1 0 to many 0 or 1

Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component.

The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order annotation identifier I [Integer] TL [Term List code] (7.12.5) 0 or 1 1 to many A positive integer representing the order of a record component within its original component complex (7.5.3). An annotation identifier is used to indicate the presence of modifiers that significantly alter the meaning of information in a data item or cluster (7.5.7).


Page 106 prENV 13606-4:1999 Attributes of specialisation data item type reference V [Code Value] (7.12.6) 1 A reference to one of an agreed set of element types defined within a community. Applicable only if the data item content is a community defined data item. Note: The data item type reference may be used with the data item type "community defined elements" to refer to either an element type defined in Informative Annex B or to an element type defined at a National, Regional or enterprise level. New data item content types should be defined using combinations of data types and sub-classes defined in the Normative parts of this European Prestandard. The data item type reference may also be used with one of the defined data item types to specify an extension to one of the data item type types defined in this European Prestandard. data item content class 1 The data item content class contains information in a structure that conforms with a specification referred to by the data item type reference. The structures to be used within a communicating community should be agreed by that community. An enterprise within a communicating community may also specify and use alternative structures in accordance with the limitations imposed of record components (7.5.2) with the component role "enterprise". enterprise specific indicator B [Boolean] 0 or 1 An indication that the community defined data item contains enterprise specific data or structures representing an alternative version of any structured content of the composition (7.5.5), headed section (7.5.6) or cluster (7.5.7) of which it is a member.


Page 107 prENV 13606-4:1999

7.7.

EHCR link subsystem

EHCR structured record subsystem (incomplete) see 7.5 record component see 7.5.2

EHCR link subsystem link set item see 7.7.1

is a type of

contains

contains

1

1..*

source component see 7.7.2

target component see 7.7.3

revision information see 7.7.4
0..1

component reference see 7.7.5
0..* is part of

may be qualified by

refers to another component using a

EHCR message component subsystem (incomplete) see 7.8 0..1 originating healthcare agent see 7.8.6

1

component unique 1 identifier see 7.8.5

EHCR message component see 7.8.1

Figure 27. DIM - EHCR Link Subsystem


Page 108 prENV 13606-4:1999 7.7.1. link set item

Type: class Specialisation of: record component (7.5.2) Description: A record component (7.5.2) that provides a labelled link between one EHCR message components (7.8.1) (nominated as the source component (7.7.2)), with one or more EHCR message components (7.8.1) (nominated as the target components (7.7.3)). Usage: The nature of the relationship between the linked record components (7.5.2) is indicated by the component name category attribute of the link set item. Note: Part 1 of this Prestandard defines a link item as having only one target component (7.7.3). The link set item represents a set of one or more link items with a common source component (7.7.2) and label. A link set item with a single target component (7.7.3) can be used to represent a link item. However, a single link set item can also represent a set of link items used to communicate the relationship between a group of clinically related record components (7.5.2) (e.g. a problem title and notes from various consultations relating to the progress of that problem). Attributes Type Occurrence

Attributes from generalisation: record component (7.5.2) Attributes from generalisation: EHCR message component (7.8.1) component unique identifier (7.8.5) component identification by originating system class S [String] 1 0 or 1

An optional additional identifier based on the identification of the EHCR message component in the originating system. Not required, as this is implicit by the named record component specialisation. originating healthcare agent (7.8.6) class 0 or 1 A reference to the healthcare agent (7.10.10) responsible for adding the link set item to the record. Usage: May be omitted if the value is the same as the value applied to the composition (7.5.5) which contains this link set item. originating date and time TOCD [Time+Date] 0 or 1 Date and time on which the link(s) represented by the link set item were first created on an EHCR system. Usage: May be omitted if the value is the same as the value applied to the composition (7.5.5) which contains this link set item. originating date validity related healthcare agent (7.8.8) Not applicable to link set item related date (7.8.7) Not applicable to link set items. component name category TL [Term List code] (7.12.5) 0 or 1 A standard high-level category assigned to an EHCR message component to support communication. Usage: This attribute shall be used to specify the nature of the relationship between the linked record components. Values: A value from the "Set of Categorisation of Link Item Names" listed in Table C.1 of Part 2 of this Prestandard. class None E [Enumerated] class 0 or 1 None


Page 109 prENV 13606-4:1999 component name structure (7.8.4) class 0 or 1

An optional coded descriptor acting as a more detailed indication of the nature of the relationship between the source component (7.7.2) and the target component (7.7.3). Usage: Even if the component name structure is used the component name category shall be included to provide a high-level categorisation of the nature of the link. component status distribution rule reference (7.9.2) revision information (7.7.4) attestation (7.8.2) E [Enumerated] class class class 1 0 to many 0 or 1 0 to many Indication of whether the record component is the current valid version or has been superseded. Applies a distribution rule (7.9.1) to a record component. A reference to the immediately preceding version of this record component. Note: If attestation is applied to a link set item it attests the link(s), not the content of the linked record components. component language V [Code Value] (7.12.6) 0 or 1 The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. component order Attributes of specialisation source component (7.7.2) target component (7.7.3) class class 1 1 to many A reference to the EHCR message component (7.8.1) from which the link is to be made. A reference to the EHCR message component (7.8.1)(s) to which are to be linked to the source component (7.7.2). 7.7.2. source component I [Integer] 0 or 1 A positive integer representing the order of a record component within its original component complex (7.5.3).

Type: class Specialisation of: component reference (7.7.5) Description: A reference to the EHCR message component (7.8.1) from which the link is to be made. Usage: The source component shall not be a link set item (7.7.1). Contained in A source component is part of a link set item (7.7.1). Attributes component identifier value Type S [String] Occurrence 1

Attributes from generalisation: component reference (7.7.5) This attribute uniquely identifies an instance of an EHCR message component (7.8.1) within the scope specified by the scope of component identifier. originating date and time TOCD [Time+Date] 0 or 1 Date and time on which the EHCR message component (7.8.1) was added to the EHCR system on which it originated. originating healthcare agent (7.8.6) class 0 or 1 A reference to the healthcare agent (7.10.10) responsible for adding the EHCR message component (7.8.1) to the record.


Page 110 prENV 13606-4:1999 7.7.3. target component

Type: class Specialisation of: component reference Description: A reference to the EHCR message component (7.8.1)(s) to which are to be linked to the source component (7.7.2). Usage: The target component shall not be a link set item (7.7.1). Contained in A target component is part of a link set item (7.7.1). Attributes component identifier value Type S [String] Occurrence 1

Attributes from generalisation: component reference (7.7.5) This attribute uniquely identifies an instance of an EHCR message component (7.8.1) within the scope specified by the scope of component identifier. originating date and time TOCD [Time+Date] 0 or 1 Date and time on which the EHCR message component (7.8.1) was added to the EHCR system on which it originated. originating healthcare agent (7.8.6) class 0 or 1 A reference to the healthcare agent (7.10.10) responsible for adding the EHCR message component (7.8.1) to the record. Attributes of specialisation referenced component order I [Integer] 0 or 1 A number indicating the position of a referenced EHCR message component (7.8.1) where several references of the same type exist. Note: Two or more referenced components may share the same referenced component order. In this case the order of these referenced components in relation to one another is arbitrary. 7.7.4. revision information

Type: class Specialisation of: component reference (7.7.5) Description: A reference to the EHCR message component (7.8.1) that contains the immediately preceding version of the information in this EHCR message component (7.8.1). Contained in revision information is part of an EHCR message component (7.8.1). Attributes component identifier value originating date and time Type S [String] TOCD [Time+Date] Occurrence 1 0 or 1

Attributes from generalisation: component reference (7.7.5) This attribute uniquely identifies an instance of an EHCR message component (7.8.1). Date and time on which the EHCR message component (7.8.1) was added to the EHCR system on which it originated. originating healthcare agent (7.8.6) class 0 or 1 A reference to the healthcare agent (7.10.10) responsible for adding the EHCR message component (7.8.1) to the record.


Page 111 prENV 13606-4:1999 Attributes of specialisation reason for revision Reason for revision as a coded value. Example(s): Error of recording reason for revision comments Textual comment on reason for revision 7.7.5. component reference S [String] 0 or 1 V [Code Value] (7.12.6) 0 or 1

Type: Abstract Class Description: An abstract class containing a reference to an EHCR message component (7.8.1). Specialisations A component reference is specialised as revision information (7.7.4). A component reference is specialised as a target component (7.7.3). A component reference is specialised as a source component (7.7.2). Associations A component reference refers to another component using a component unique identifier (7.8.5). Attributes component identifier value Type S [String] Occurrence 1

This attribute uniquely identifies an instance of an EHCR message component (7.8.1) within the scope specified by the scope of component identifier. originating date and time TOCD [Time+Date] 0 or 1 Date and time on which the EHCR message component (7.8.1) was added to the EHCR system on which it originated. Usage: Part 1 of this Prestandard requires the originating date and time to be included in every Architectural Component. However, in the message the originating date and time need not be repeated unless it differs for the originating date and time of the containing composition (7.5.5), headed section (7.5.6) or cluster (7.5.7). Other dates and time associated with the EHCR message component (7.8.1) shall be represented as related dates (7.8.7). In the case of a revision that supersedes an existing component, the originating date and time is the date and time of the revision. Information about the date of origin of the superseded version is available in that version of the EHCR message component (7.8.1). originating healthcare agent (7.8.6) class 0 or 1 A reference to the healthcare agent (7.10.10) responsible for adding the EHCR message component (7.8.1) to the record.


Page 112 prENV 13606-4:1999

7.8.

EHCR message component subsystem
EHCR message component subsystem

EHCR structured record subsystem (incomplete) see 7.5 EHCR extract see 7.5.1

specialised as

EHCR message component see 7.8.1

described by 0..1

component name structure see 7.8.4

record component see 7.5.2

identified by may include

related date EHCR link subsystem (incomplete) see 7.7 component reference see 7.7.5
0..* 1 1 may be referred to by 0..*

see 7.8.7

component unique identifier see 7.8.5
may include may refer to preceding and subsequent revisions 0..* 0..*

related healthcare agent see 7.8.8

revision information see 7.7.4

0..1

attestation see 7.8.2

EHCR distribution rule subsystem (incomplete) see 7.9 distribution rule 0..* reference see 7.9.2

includes the author as may be attested by 0..1

includes 1

originating healthcare agent see 7.8.6

attesting agent see 7.8.3

{constraint - an instance healthcare agent link reference is part of one instance of one of the agent role classes}

healthcare agent subsystem (incomplete) see 7.10

1

1

1

healthcare agent in context reference see 7.10.12

Figure 28. DIM - EHCR Message Component Subsystem


Page 113 prENV 13606-4:1999 7.8.1. EHCR message component

Type: Abstract Class Description: The EHCR message component is an abstract class representing the attributes and relationships common to the all parts of an electronic healthcare record contained within an EHCR message. Each EHCR message component contains sufficient information to render it identifiable for the purposes of referencing and revision. Note: The EHCR message component is an abstract class. Therefore it only exists as an instance of one of its two specialisations. These are the EHCR extract (7.5.1), which represents the top-level of the EHCR hierarchy within the message, and the record component (7.5.2), which represents the subdivision of the EHCR within the message. The EHCR message component is based on the Architectural Component, specified in Part 1 of this European Prestandard. It differs in two ways: -- The specialisation the EHCR extract (7.5.1), differs from the EHCR Root Architecture Component as it can contain a subset of the EHCR, an update the EHCR or the entire EHCR. -- Some attributes are defined in ways that are particular to the needs of message communication. Specialisations An EHCR message component is specialised as a record component (7.5.2) or an EHCR extract (7.5.1). Attributes component unique identifier (7.8.5) Type class Occurrence 1

This identification shall uniquely identify an instance of EHCR message component from all other instances belonging to the same EHCR. The scope within which this identification is unique may be limited as indicated by the attribute scope of component identifier. component identification by originating system S [String] 0 or 1 An optional additional identifier based on the identification of the EHCR message component in the originating system. Usage: This additional identifier may be included if the component identifier value used in the message differs from the identification in the originating system. Support for this attribute is optional and its use depends on implementation guidelines agreed within the communicating community. originating healthcare agent (7.8.6) class 0 or 1 A reference to the healthcare agent (7.10.10) responsible for adding the EHCR message component to the record. originating date and time TOCD [Time+Date] 0 or 1 Date and time on which the EHCR message component was added to the EHCR system on which it originated. Usage: Part 1 of this Prestandard requires the originating date and time to be included in every Architectural Component. However, in the message the originating date and time need not be repeated unless it differs for the originating date and time of the containing composition (7.5.5), headed section (7.5.6) or cluster (7.5.7). Other dates and time associated with the EHCR message component shall be represented as related dates (7.8.7). In the case of a revision that supersedes an existing component, the originating date and time is the date and time of the revision. Information about the date of origin of the superseded version is available in that version of the EHCR message component.


Page 114 prENV 13606-4:1999 originating date validity E [Enumerated] 0 or 1

An indication of the validity of the originating date and time. Usage: If there is any uncertainty about the originating date and time, this attribute shall be used to indicate the basis from which the originating date and time have been derived. Values: 0. Confirmed originating date derived from a system that fully conforms with this Prestandard. This is the default value. 1. Probable originating date derived from a partially-conformant system. 2. Date assigned on receiving information from another system. 3. Date assigned when processing information from a legacy system with no previous reliable indication of date of origin. 4. Date of compiling the information into a summary or update. related healthcare agent (7.8.8) class 0 to many A reference to a healthcare agent (7.10.10) that has a role in relation to the content of an EHCR message component, other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. related date (7.8.7) class 0 to many A date and time, other than the originating date and time, which is related to an EHCR message component. The relevance of the date is specified by the attribute related date role. component name category TL [Term List code] (7.12.5) 0 or 1 A standard high-level category assigned to an EHCR message component to support communication. Usage: The component name category is mandatory in some specialisation of EHCR message component and not used in others. Refer to the specialisations for further details. Values: The acceptable values of component name category are specified by tables in Part 2 of this Prestandard. The applicable table of values varies according to the specialisation of component name category and is specified separately for each specialisation. component name structure (7.8.4) class 0 or 1 A coded descriptor, title, heading or label that represents the primary focus or nature of the information conveyed by an EHCR message component. The information conveyed by an instance of this class varies according to the specialisation of EHCR message component to which it applies. Specific usage details are provided in the description of each specialisation. component status E [Enumerated] 1 Indication of whether the EHCR message component is the current valid version or has been superseded. Usage: A "current" EHCR message component may later be superseded by another component that refers to it using the revision information (7.7.4). A "superseded" EHCR message component may be conveyed in a message to provide a record of previous versions of component. A "deleted" EHCR message component may be conveyed in a message to provide a record of the predeleted version of component. An EHCR message component may be superseded by another component status of the same type or by an empty record component. In the latter case, the component status is of the superseded component becomes "deleted" and the component is effectively hidden from normal viewing. Note: This is an abbreviated version of the class component status information specified by Part 1 of this Prestandard. The other information in that class relates to the date and responsibility for revision. This information is conveyed in the message as the originating healthcare agent (7.8.6) and originating date and time of the revising EHCR message component. Values: 0. Current 1. Superseded 2. Deleted


Page 115 prENV 13606-4:1999 distribution rule reference (7.9.2) revision information (7.7.4) class class 0 to many 0 or 1

A distribution rule reference applies a referenced distribution rule (7.9.1) to an EHCR message component. A reference to the EHCR message component that contains the immediately preceding version of the information in this EHCR message component. attestation (7.8.2) component language class V [Code Value] (7.12.6) 0 to many 0 or 1 Information about the attestation of the EHCR message component. The language in which the content of the EHCR message component is expressed, represented by the abbreviations specified in ISO 639. 7.8.2. attestation

Type: class Description: Information about the attestation of the EHCR message component (7.8.1). Note: The mechanism of attestation by digital signature is not specified in this Prestandard but is subject to agreement within a communicating community in conformance with other Standards. Contained in An attestation attests an EHCR message component (7.8.1). Attributes date and time of attestation attesting agent (7.8.3) reason for attestation Type TOCD [Time+Date] class C/S [Code or String] (7.12.2) Occurrence 1 1 0 or 1

The healthcare agent (7.10.10) attesting the EHCR message component (7.8.1). The reason why the EHCR message component (7.8.1) was attested. Example(s): To confirm the accuracy of the information contained, to authorise an instruction or request, to take responsibility for a recorded action. digital signature 7.8.3. attesting agent Signature (7.13.7) 1

Type: class Description: The healthcare agent (7.10.10) attesting the EHCR message component (7.8.1). Contained in An attesting agent is part of an attestation (7.8.2). Attributes healthcare agent in context reference (7.10.12) Type class Occurrence 1

A reference to a healthcare agent in context (7.10.11) using an unique identifier.


Page 116 prENV 13606-4:1999 7.8.4. component name structure

Type: class Description: A coded descriptor, title, heading or label that represents the primary focus or nature of the information conveyed by an EHCR message component (7.8.1). The information conveyed by an instance of this class varies according to the specialisation of EHCR message component (7.8.1) to which it applies. Specific usage details are provided in the description of each specialisation. Usage: The code values used may be composite (e.g. multi-axial or compositional) and in some situations a communicating community may require the inclusion of the original code (as recorded in the originating system) and a code derived by mapping into an agreed common coding scheme. Example(s): A code representing the title or heading for a component complex, a diagnosis, a procedure, a medicinal product or the nature of a measurable quantity. Contained in A component name structure may be part of an EHCR message component (7.8.1). Attributes Choice of component name original code CC [composite code] (7.12.3) Type Occurrence 1

A coded descriptor, title, heading or label as applied to the EHCR message component (7.8.1) in the originating system. component name text S [String] An plain text title, heading or label as applied to a folder (7.5.4). Usage: The component name text shall not be used for naming EHCR message components other than folders. component name mapped code CC [composite code] (7.12.3) 0 or 1 A coded descriptor, title, heading or label, which was derived by mapping the original code to a coding scheme that is specified for use within a communicating community. 7.8.5. component unique identifier

Type: class Description: This identification shall uniquely identify an instance of EHCR message component (7.8.1) from all other instances belonging to the same EHCR. The scope within which this identification is unique may be limited as indicated by the attribute scope of component identifier. Usage: Part 1 of this Prestandard requires that the component unique identifier shall be unique for all components applicable to the patient who is the subject of this EHCR message component (7.8.1), throughout a communicating community. However, the message may be used by systems that are unable to comply with this requirement. In these cases, the limitation to the scope of uniqueness shall be indicated by the scope of component identifier. Any EHCR message component (7.8.1) that it is subject to a limitation of the scope of uniqueness shall not be the subject of a subsequent update or revision. However, this need not preclude the replacement of a uniquely identified EHCR message component (7.8.1) that contains constituent elements that are not themselves uniquely identified. Use of any message to enable revision requires prior agreement within a communicating community on the detailed requirements, responsibilities and supporting business processes. As a general rule any provision for updating using the provide EHCR message (7.4.3) will be dependent on receiving systems retaining the component identifier value for any record component (7.5.2) that may subsequently require revision. In this context, the term "revision" includes subsequent communication of new links to an existing record component (7.5.2).


Page 117 prENV 13606-4:1999 Contained in A component unique identifier identifies an EHCR message component (7.8.1). Associations A component unique identifier may be referred to by any number of component references (7.7.5). Attributes component identifier value Type S [String] Occurrence 1

This attribute uniquely identifies an instance of an EHCR message component (7.8.1) within the scope specified by the scope of component identifier. scope of component identifier E [Enumerated] 1 An indication of whether the identifier is only unique within this message or is unique within the wider scope. The wider scopes supported are the EHCR for this patient as held by the EHCR source, the entirety of the system held by the EHCR source or the EHCR for this patient within a communicating community. Usage: Systems that do not support unique internal identification of record components should use this attribute to indicate that the identifier is unique within a more limited scope. A system may uniquely identify some record components (7.5.2) (e.g. a part of the record represented by an original component complex (7.5.3)) while not internally identifying all the constituent component items. In this case the sending system may generate unique identifiers for these elements when creating the message. Therefore, different values may apply to the scope of component identifier of different components within the message. Values: 0. Unique within message 1. Unique within originator's EHCR for this patient 2. Unique within originator's system 3. Unique within a communicating community 7.8.6. originating healthcare agent

Type: class Description: A reference to the healthcare agent (7.10.10) responsible for adding the EHCR message component (7.8.1) to the record. Usage: Part 1 of this Prestandard requires the originating healthcare agent to be included in every Architectural Component. However, in the message the originating healthcare agent need not be repeated unless it differs for the originating healthcare agent of the containing composition (7.5.5), headed section (7.5.6) or cluster (7.5.7). Other parties associated with the EHCR message component (7.8.1) shall be represented as related healthcare agents (7.8.8). In the case of a revision that supersedes an existing component, the originating healthcare agent is the healthcare agent (7.10.10) responsible for the revision. Information about those responsible for a superseded version is available in that version of the EHCR message component (7.8.1). Contained in An originating healthcare agent originator of an EHCR message component (7.8.1). An originating healthcare agent may be part of a component reference (7.7.5). Attributes healthcare agent in context reference (7.10.12) Type class Occurrence 1

A reference to a healthcare agent in context (7.10.11) using an unique identifier.


Page 118 prENV 13606-4:1999 7.8.7. related date

Type: class Description: A date and time, other than the originating date and time, which is related to an EHCR message component (7.8.1). The relevance of the date is specified by the attribute related date role. Usage: The system timestamp representing the creation or modification of a component shall not be expressed as a related date. The originating date and time attribute of the EHCR message component (7.8.1) shall be used for this purpose. Example(s): The date of a past event, the start and end dates (or dates and times) of a procedure, a planned or scheduled future date, etc. Contained in A related date specifies a date applicable to an EHCR message component (7.8.1). Attributes date Type TOCD [Time+Date] Occurrence 1

A date associated with an EHCR message component (7.8.1). Note: The date may be expressed at any valid level of precision. ( e.g. Year only, year + month, year + month + day, year + month + day + hour, year + month + day + hour + minutes, year + month + day + hour + minutes + seconds). related date role TL [Term List code] (7.12.5) 1 The role or relationship of a date to an EHCR message component (7.8.1) Values: One of the values specified in Table E.6 in Part 2 of this Prestandard. related date accuracy E [Enumerated] 0 or 1 The accuracy of a date. Note: It is possible to express a date using different levels of precision. This attribute is used to indicate whether the date is accurate or approximate to the level of detail stated. Example(s): If the date of a historical event is stated as 1975 this may mean it occurred sometime in 1975 or it may mean that the patient indicated that it occurred at sometime in the mid 1970's. In the latter case, this can be indicated with the value "Approximate". Similarly even when an apparently complete time is given it may mean that an event occurred at that time (accurate) or around about that time (approximate). Values: 0. Accurate 1. Approximate 7.8.8. related healthcare agent

Type: class Description: A reference to a healthcare agent (7.10.10) that has a role in relation to the content of an EHCR message component (7.8.1), other than as the originating healthcare agent (7.8.6). The role of the healthcare agent (7.10.10) is specified by the attribute role of related healthcare agent. Contained in A related healthcare agent may be referred to by an EHCR message component (7.8.1). Attributes role of related healthcare agent Type TL [Term List code] (7.12.5) Occurrence 1

Indication of the relationship between an EHCR message component (7.8.1) and the related healthcare agent. Example(s): Carried out procedure, assisted with the procedure, reported the recorded information, authorised a report, responsible for a period of care, provided a service, source of a request or referral, destination of a request or referral, originator of the information (i.e. if information from another source is entered from a paper form). Values: One of the values specified in Table E.7 in Part 2 of this Prestandard. healthcare agent in context reference (7.10.12) class 1 A reference to a healthcare agent in context (7.10.11) using an unique identifier.


Page 119 prENV 13606-4:1999

7.9.

EHCR distribution rule subsystem
EHCR distribution rule subsystem

distribution rule
1 0..*

see 7.9.1
referred to by

0..*

0..1

distribution rule reference see 7.9.2
0..*

distribution rule directory see 7.9.3
0..1

applies a distribution rule to

may be conveyed in

EHCR message component subsystem (incomplete) EHCR message see 7.8 component see 7.8.1

EHCR message subsystem (incomplete) 0..1 see 7.4 provide EHCR message see 7.4.3

Figure 29. DIM - EHCR Distribution Rules


Page 120 prENV 13606-4:1999 7.9.1. distribution rule

Type: class Description: All the necessary data to ascribe the intent of the author of the distribution rule with respect to data provision and access rules and rights to the data object to which the distribution rule is attached. Note: This class is represented in the manner specified in clause 5.4 of Part 3 of this European Prestandard. Contained in A distribution rule may be conveyed by a provide EHCR message (7.4.3). A distribution rule referred to by any number of distribution rule references (7.9.2). A distribution rule may be part of a distribution rule directory. Attributes distribution rule unique identifier Type identifier (7.11.5) Occurrence 1

If this distribution rule is applied to the architectural component as a healthcare persons demonstration of consent according to an existing, applied distribution rule, this attribute shall contain a reference to that distribution rule. DR access type E [Enumerated] 0 or 1 The intent of the author of that distribution rule as to the data processing permissions related to the information within an EHCR message component (7.8.1).. Note: See clause 5.4 of Part 3 of this European Prestandard. Values: R. Read only M. Modify B. Block E. Erase. apply DR access E [Enumerated] 0 or 1 A coded representation of the intent of the author of that distribution rule as to the permission concerning applying new distribution rules or invalidating already attached distribution rules to any EHCR message component (7.8.1) to which this distribution rule is attached. DR who DR when DR where DR why DR how DR rule author [class defined in Part 3] [class defined in Part 3] [class defined in Part 3] [class defined in Part 3] [class defined in Part 3] class 0 to many 0 or 1 0 to many 1 to many 0 to many 1 Note: See clause 5.5 of Part 3 of this European Prestandard. Note: See clause 5.6 of Part 3 of this European Prestandard. Note: See clause 5.7 of Part 3 of this European Prestandard. Note: See clause 5.8 of Part 3 of this European Prestandard. Note: See clause 5.9 of Part 3 of this European Prestandard. All the necessary data to be able to identify the author of the distribution rule. The author of a distribution rule shall be an identifiable individual or organization specified as a healthcare agent in context reference (7.10.12).


Page 121 prENV 13606-4:1999 7.9.2. distribution rule reference

Type: class Description: A distribution rule reference applies a referenced distribution rule (7.9.1) to an EHCR message component (7.8.1). Usage: A distribution rule reference may refer to a distribution rule (7.9.1) conveyed in the message or to a distribution rule (7.9.1) held in a shared directory of commonly applied rules. The restrictions imposed by a distribution rule (7.9.1) apply to any hierarchical descendants of the EHCR message component (7.8.1) from which that rule is referenced. Therefore, if a distribution rule (7.9.1) is referenced by the EHCR extract (7.5.1), the restrictions apply to all EHCR information in that message. Note: The distribution rule reference is specified by clause 5.3 of Part 3 of this European Prestandard. Contained in A distribution rule reference applies a distribution rule to an EHCR message component (7.8.1). Attributes distribution rule unique identifier Type identifier (7.11.5) Occurrence 1

If this distribution rule is applied to the architectural component as a healthcare persons demonstration of consent according to an existing, applied distribution rule, this attribute shall contain a reference to that distribution rule. DR applied date and time DR applied by TOCD [Time+Date] class 1 1 The date and time the distribution rule (7.9.1) was applied to the architectural component. A reference to the healthcare agent (7.10.10), and the context of that agent, that applied the distribution rule (7.9.1) to the EHCR message component (7.8.1). DR valid from TOCD [Time+Date] 0 or 1 The date and time the distribution rule first may be used for accessing the architectural component. If not present, it may be used from the time of application. DR valid to TOCD [Time+Date] 0 or 1 The date and time the distribution rule will cease be used in connection with the architectural component. If not present, there are no time limitations for its use. DR invalidated by class 0 or 1 If the distribution rule (7.9.1) is invalidated within the period of time originally applied, this attribute shall contain a unique reference to the healthcare agent (7.10.10), and the context of that agent, that invalidated it. DR negation statement B [Boolean] 1 A functional flag that informs the information system that the contents of the rule of which this is a part shall both be interpreted as a disabling mechanism and take precedence over all enabling rules containing any of the same distribution rule (7.9.1) components applied to this EHCR message component (7.8.1). DR basic distribution rule B [Boolean] 1 A functional flag that represents that the distribution rule (7.9.1) is applied as a basic distribution rule (7.9.1) to the EHCR message component (7.8.1). If one or more basic distribution rules (7.9.1) are applied to an EHCR message component (7.8.1), it shall not be possible to apply any non-basic distribution rule (7.9.1) if its contents do not comply with one or more of the basic distribution rules (7.9.1). DR country of application C [Coded] (7.12.1) 0 or 1 Coded data representation of the country in which the distribution rule (7.9.1) was applied to the EHCR message component (7.8.1). DR consent demonstration reference identifier (7.11.5) 0 or 1 If this distribution rule (7.9.1) is applied to the EHCR message component (7.8.1) as a healthcare person (7.10.14)'s demonstration of consent according to an existing, applied distribution rule, this attribute shall contain a reference to that distribution rule (7.9.1).


Page 122 prENV 13606-4:1999 7.9.3. distribution rule directory

Type: class Description: The set of distribution rules (7.9.1) that apply to all or part of the EHCR infor mation conveyed in a provide EHCR message (7.4.3). Usage: If access limitations are to be applied to the EHCR extract (7.5.1) or to any of the record components (7.5.2) within it these are conveyed as a table or distribution rules (7.9.1). The individual rules are references from the appropriate components in the message by including an instance of the distribution rule reference (7.9.2) class within the component. Contained in A distribution rule directory may be part of a provide EHCR message (7.4.3). Attributes distribution rule (7.9.1) Type class Occurrence 0 to many

All the necessary data to ascribe the intent of the author of the distribution rule with respect to data provision and access rules and rights to the data object to which the distribution rule is attached.


Page 123 prENV 13606-4:1999

7.10. Healthcare agent subsystem
7.10.1. Introduction 7.10.1.1. The healthcare agent subsystem supports different ways of referring to healthcare persons, healthcare organisations, healthcare devices and healthcare software from within a message. The method used may be constrained by the GMD of a particular message. If the GMD permits more than one of these methods, the approach to be taken may be subject to agreement between communicating parties. 7.10.1.2. As a general rule only three of the classes in this subsystem may be directly related to classes in other subsystems of a message. These are the healthcare agent in context, healthcare agent in context reference and the healthcare agents directory. A simple message need only refer to the healthcare agent in context. 7.10.2. Healthcare agent roles 7.10.2.1. Wherever a message needs to refer to a particular healthcare agent it includes a role specific specialisation of either healthcare agent in context or healthcare agent in context reference. These specialisations are referred to here as healthcare agent roles. 7.10.2.2. Healthcare agent roles are equivalent to healthcare party roles in earlier messages of CEN TC251. Thus any healthcare party role in such a message can be represented as either a healthcare agent in context or healthcare agent in context reference. However, the healthcare agent roles includes several features missing from healthcare party role: -- An explicit distinction between a reference and complete representation; -- Allows the same healthcare person or organisation to be referred to in different contexts within the same message; -- Allows a device or software module to be referred to as a source of information or a participant in a procedure. NOTE: The healthcare agent subsystem is illustrated in a generic form applicable to any healthcare message. Therefore, since healthcare agent roles vary from message to message they do not appear in the model. 7.10.3. Healthcare agent in context 7.10.3.1. A healthcare agent in context is an explicit representation of a healthcare agent acting within a particular context. This context is described as a relationship with other healthcare agents. For example, a secretary acting on behalf of a clinician, a person working in a particular organisation or a department within a hospital. The same healthcare agent can be the subject of several healthcare agents in context and thus distinctions can be drawn between activities of the healthcare person while serving in two different capacities. EXAMPLES: The same nurse, working in different departments. The same doctor, acting in his own right or as a locum on behalf of a colleague. 7.10.4. Healthcare agent in context references 7.10.4.1. A healthcare agent in context reference is a reference to a healthcare agent in context. It healthcare agent in context to be included several times in a message without repeating the details. agent in context to which the healthcare agent in context reference refers may either be in a shared the communicating parties have access or may be communicated in a message within an instance of directory. allows the same The healthcare directory to which healthcare agents

7.10.4.2. The simplest instance of healthcare agent in context includes only one healthcare agent with no specified healthcare agent relationships. Therefore the healthcare agent in context or healthcare agent in context reference can be used for a simple case where it is deemed unnecessary to set the healthcare agent in the context of any relationships. However, the reverse does not apply. Therefore, unless there is an instance in a message in which an unqualified reference to a healthcare agent is always sufficient, specialisations of the healthcare agent in context or healthcare agent in context reference should be specified in the message rather than instances of healthcare agent.


Page 124 prENV 13606-4:1999 7.10.5. Messages with a fixed number of instances of healthcare agent roles 7.10.5.1. In a message that only refers a fixed number of references to people, organisations, devices or software the full healthcare agent in context may be included for each such instance. In this case there is no need to exchange or share a healthcare agents directory. 7.10.6. Messages with an indeterminate number of instances of healthcare agent roles 7.10.6.1. In a message that includes an indeterminate number of references to people, organisations, devices or software the healthcare agent in context reference should be used. The sender then need only include the full details of any healthcare agent in context once. 7.10.6.2. The information about each healthcare agent in context can be conveyed in the healthcare agents directory class as part of such a message. Alternatively, the healthcare agents directory information may be communicated in a separate message used for maintaining and aligning this information. A third option is to provide real-time access to a shared or distributed directory containing the relevant information. 7.10.7. Representation of interrelationships between multiple healthcare agents 7.10.7.1. The classes healthcare agent in context or healthcare agent in context reference are not intended to represent all the relationships between a group of healthcare agents. They are intended to represent the context in which an agent is acting in respect of a particular action or event. Therefore, the fact that a healthcare person may work in various departments, which are parts of different organisations, should not be captured in a single instance of healthcare agent in context. Separate instances of healthcare agent in context should be used to refer to each context in which a healthcare person acts. 7.10.7.2. The context in which a healthcare agent acts may consist of relationships with several other persons or organisations. These relationships may be viewed as being a hierarchical chain of relationships. However, as noted above (7.10.7.1), the purpose of the healthcare agent in context is to convey the context in which an individual healthcare agent is acting while fulfilling a particular role. Even if these relationships are part of a hierarchy, they can also be stated a simple set of direct relationships with that healthcare agent. EXAMPLE: If Dr A undertakes a procedure or makes a record while working for Dr B and "Dr B is part of department C" and "Department C is in hospital D" the context in which Dr A acts is represented as three relationships: -- Dr A working for Dr B -- Dr A working in department C -- Dr A working in hospital D Some of these known to be a Dr A may also relationships a applicable to a relationships may be known to be fixed and need not be represented. Thus if department C is specific department within hospital D then the third relationship can be omitted. work for Dr E in department F of hospital G. Therefore to state the full set of Dr A's hierarchical approach is necessary. However, this is not needed to represent a single context particular role.

7.10.7.3. The approach described in 7.10.7.2 significantly simplifies implementation when compared with a richer recursive structure for representation of healthcare agent interrelationships. A communicating community may use directories that represent a fuller picture of these relationships. If such a directory provides a unique way to refer to a healthcare agent and a discrete set of relationships, it may be used in place of the healthcare agents' directory specified in this Prestandard. In this case, the healthcare agent in context reference refers to entries in this alternative directory. 7.10.7.4. If more than one healthcare agent is directly involved in, or responsible for, an activity, the roles of should be represented by separate references to each of these healthcare agents. The involvement of several agents in an activity should not be represented by combining these healthcare agents as a single healthcare context. EXAMPLE: If two surgeons are involved in carrying out an operation, each of these is represented by a separate healthcare agent in context. each agent healthcare agent in

instance of


Page 125 prENV 13606-4:1999 7.10.8. Using the healthcare agents directory in a message 7.10.8.1. A message may contain a single instance of the healthcare agents' directory. This may contain any number of healthcare agents in context and healthcare agents. 7.10.8.2. The same healthcare agent may be part of many healthcare agents in context. To avoid repetition of the details about a healthcare agent can be carried once in the healthcare agents directory. Then each healthcare agent in context that refers to that agent need only include an unspecialised instance of the class healthcare agent containing the appropriate identifier. EXAMPLES: The several doctors may work in one department. The department details can be carried once as a healthcare agent specialised as a healthcare organisation. The healthcare agent in context representing each doctor within the department includes healthcare agent relationship with an unspecialised instance of the healthcare agent. This refers to the relevant details by sharing the same identifier. 7.10.9. Restricted healthcare agent roles 7.10.9.1. Some specific healthcare party roles that can only be played by particular types of healthcare agents. Where such restriction apply these are stated as a constraint in the role specific class and this is also made explicit in the GMD by including only those specialisations that are permitted. EXAMPLE: Prescriber is a specialisation of healthcare agents in context that is always a healthcare person.


Page 126 prENV 13606-4:1999

healthcare agent subsystem healthcare agent in context reference see 7.10.12
0..* identifies a 1

may contain directory entries representing

0..*

healthcare agent in context see 7.10.11
0..*

may include contextual information in the form of 0..*

0..1

healthcare agents directory see 7.10.19
0..1

may be the subject of

healthcare agent relationship see 7.10.18
0..*

1 may contain directory entries representing

healthcare agent
0..*

specifies a relationship with 1

see 7.10.10

may be specialised as

healthcare party see 7.10.13

is specialised as

healthcare person see 7.10.14

healthcare organisation see 7.10.15

healthcare device see 7.10.16

healthcare software see 7.10.17

Figure 30. DIM - Healthcare Agent Subsystem


Page 127 prENV 13606-4:1999 7.10.10. healthcare agent Type: class Description: Information about a healthcare person (7.10.14), healthcare organisation (7.10.15), healthcare device (7.10.16) or healthcare software (7.10.17) that performs a role in a healthcare activity. Usage: This is not an abstract class because it may exist without a specialisation. In this case, the identifier shall refer to a healthcare agent about which the communicating parties already share a common set of information. This shared information may be provided or maintained using messages that contain an instance of the class healthcare agents directory (7.10.19). Alternatively the shared information about healthcare agents may be derived from a commonly accessible directory service maintained in a manner separate from the messaging process. Note: The class healthcare agent contains only an identifier. However, its specialisations contain other attributes, which enable details about different types of healthcare agents to be conveyed. Specialisations A healthcare agent may be specialised as healthcare software (7.10.17), a healthcare device (7.10.16) or a healthcare party (7.10.13). Contained in A healthcare agent may be contained in a healthcare agents directory (7.10.19). A healthcare agent may be the subject of any number of healthcare agent relationships (7.10.18). A healthcare agent may be the subject of any number of healthcare agent in contexts (7.10.11). Attributes healthcare agent identifier Type identifier (7.11.5) Occurrence 1 to many

A unique identifier of a healthcare agent. Note: Alternative identifiers may be used if required. Each identifier includes a coded attribute to identify the identification scheme from which it is derived. 7.10.11. healthcare agent in context Type: class Description: Information about a healthcare agent (7.10.10) in the context of a specified set of relationships to other healthcare agents (7.10.10). The healthcare agent in context enables a distinction to be made between references to the same healthcare agent (7.10.10) operating in different practical or organisational contexts. Usage: The simplest instantiation of healthcare agent in context is equivalent to a healthcare agent (7.10.10) as the inclusion of healthcare agent relationships (7.10.18) is optional. Therefore, for consistency, this class should be used even when it is unnecessary or impossible to specify any relationships to other healthcare agents (7.10.10). Note: Any class that represents a healthcare agent (7.10.10) in a particular role is a specialisation of this class. However, this is a generic model, which is used in different messages and the available specialisations depend on the nature of the message. Therefore these specialisations are neither listed here nor shown in the diagrammatic representation of the healthcare agent subsystem. Example(s): A doctor while working in a particular hospital or department. A secretary acting for a clinical specialist. A specified department within a hospital. A radiologist using a specified piece of X-ray equipment. A specified piece of software running on a particular device. Contained in A healthcare agent in context may be contained in a healthcare agents directory (7.10.19). Associations A healthcare agent in context may be referenced by any number of healthcare agent in context references (7.10.12).


Page 128 prENV 13606-4:1999 Attributes healthcare agent in context identifier Type identifier (7.11.5) Occurrence 1

A unique identifier of a healthcare agent in context. Note: The identifier includes attributes for indicating the identification scheme. healthcare agent (7.10.10) class 1 The subject of this healthcare agent in context. The healthcare person (7.10.14), healthcare organisation (7.10.15), healthcare device (7.10.16) or healthcare software (7.10.17) to which this healthcare agent in context provides context. healthcare agent function C/S [Code or String] (7.12.2) 0 or 1 Information about the function being carried out by the Healthcare Agent. Note: Enables a healthcare agent in context to refer to an otherwise unidentified healthcare agent (7.10.10) fulfilling a particular function in respect of or on behalf of an identified healthcare agent (7.10.10). Example(s): Duty doctor in a department (when the identity of the duty doctor is unknown). Locum for a specified general practitioner (when the identity of the locum is unknown). healthcare agent relationship (7.10.18) class 0 to many A relationship between the subject of this healthcare agent in context and another healthcare agent (7.10.10). Each healthcare agent relationship specifies part of the context surrounding the subject healthcare agent (7.10.10). 7.10.12. healthcare agent in context reference Type: class Description: A reference to a healthcare agent in context (7.10.11) using an unique identifier. Note: A healthcare agent in context (7.10.11) is a healthcare agent (7.10.10) qualified by an optional set of relationships to other healthcare agents (7.10.10). For example, rather than simply identifying a person, the healthcare agent in context reference may identify a person acting in accordance with a specific responsibility to a specified organisation. Contained in A healthcare agent in context reference is part of a related healthcare agent (7.8.8). A healthcare agent in context reference is part of an originating healthcare agent (7.8.6). A healthcare agent in context reference is part of an attesting agent (7.8.3). A healthcare agent in context reference is part of a communicating party. Associations A healthcare agent in context reference identifies a healthcare agent in context (7.10.11). Attributes healthcare agent in context identifier Type identifier (7.11.5) Occurrence 1

A unique identifier of a healthcare agent in context (7.10.11). Note: The identifier includes attributes for indicating the identification scheme. 7.10.13. healthcare party Type: Abstract Class Specialisation of: healthcare agent (7.10.10) Description: Information about an organisation or person responsible for the direct or indirect provision of healthcare services to an individual or to a population. Note: This is an abstract class. It exists only as instances of one of its specialisations healthcare organisation (7.10.15) or healthcare person (7.10.14). Specialisations A healthcare party is specialised as a healthcare person (7.10.14) or a healthcare organisation (7.10.15).


Page 129 prENV 13606-4:1999 Attributes healthcare agent identifier A unique identifier of a healthcare agent. Attributes of specialisation address of healthcare party telecommunication of healthcare party address (7.11.1) telecommunication (7.11.19) 0 to many 0 to many An address expressed in a structured or unstructured form. Telephone, facsimile and other telecommunication numbers or electronic addresses in a structured or unstructured form. Usage: Email and web site addresses may be specified using the unstructured telecommunication number, associated with the appropriate telecommunication type. language details of party medical specialty of healthcare party language details (7.11.6) C/S [Code or String] (7.12.2) 0 to many 0 to many Information about the ability of a person or organisation to communicate using a particular language. A healthcare discipline or speciality in which a healthcare party provides a service. 7.10.14. healthcare person Type: class Specialisation of: healthcare party Description: Person involved in the direct or indirect provision of healthcare services to an individual or to a population. Note: A carer or the patient may be a healthcare person. This enables the role of the patient in providing his/her own care to be recorded. Example(s): GP, consultant endocrinologist, dentist, nurse, radiographer, laboratory scientist, social worker, pharmacist, medical secretary. Attributes Type Occurrence Type identifier (7.11.5) Occurrence 1

Attributes from generalisation: healthcare agent (7.10.10)

Attributes from generalisation: healthcare party (7.10.13) Attributes from generalisation: healthcare agent (7.10.10) healthcare agent identifier identifier (7.11.5) 1 to many A unique identifier of a healthcare agent. Note: Alternative identifiers may be used if required. Each identifier includes a coded attribute to identify the identification scheme from which it is derived. address of healthcare party telecommunication of healthcare party address (7.11.1) telecommunication (7.11.19) 0 to many 0 to many An address expressed in a structured or unstructured form. Telephone, facsimile and other telecommunication numbers or electronic addresses in a structured or unstructured form. language details of party medical specialty of healthcare party language details (7.11.6) C/S [Code or String] (7.12.2) 0 to many 0 to many Information about the ability of a healthcare person to communicate using a particular language. A healthcare discipline or speciality in which a healthcare person provides a service.


Page 130 prENV 13606-4:1999 Attributes of specialisation type of healthcare person V [Code Value] (7.12.6) 0 or 1 Example(s): Doctor, dentist, nurse, radiographer, laboratory scientist, social worker, pharmacist, secretary, a carer or the patient (to record the patient's role in the delivery of their own care). Values: A candidate list of codes and associated terms is provided in Table E.12 of Part 2 this Prestandard. name of healthcare person position of healthcare person person name details (7.11.12) C/S [Code or String] (7.12.2) 0 or 1 0 or 1

Example(s): Head of department, hospital consultant, trainee. Values: A candidate list of codes and associated terms is provided in Table E.8 of Part 2 this Prestandard. qualification of healthcare person C/S [Code or String] (7.12.2) 0 to many Note: This information is as supplied by the healthcare person or the organisation within which they work. It is not proof of qualification to undertake healthcare services. Example(s): MD, M.Sc. military rank of healthcare person Example(s): Captain, Major. 7.10.15. healthcare organisation Type: class Specialisation of: healthcare party (7.10.13) Description: Information about an organisation involved in the direct or indirect provision of healthcare services to an individual or to a population. Usage: If it is necessary to identify groupings or subdivisions of an organisation, such as departments or subdepartments, these should also be represented as organisations. Relationships between grouping and subdivisions of organisations may be expressed using healthcare agent relationships (7.10.18) as part of a healthcare agent in context (7.10.11). Attributes Type Occurrence C/S [Code or String] (7.12.2) 0 or 1

Attributes from generalisation: healthcare party (7.10.13) Attributes from generalisation: healthcare agent (7.10.10) healthcare agent identifier identifier (7.11.5) 1 to many A unique identifier of a healthcare agent. Usage: If organisation identifiers issued in accord with ISO6523 are available, these should be used. Note: Alternative identifiers may be used if required. Each identifier includes a coded attribute to identify the identification scheme from which it is derived. address of healthcare party telecommunication of healthcare party address (7.11.1) telecommunication (7.11.19) 0 to many 0 to many An address expressed in a structured or unstructured form. Telephone, facsimile and other telecommunication numbers or electronic addresses in a structured or unstructured form. language details of party medical specialty of healthcare party Attributes of specialisation name of healthcare organisation type of organisation S [String] V [Code Value] (7.12.6) 0 or 1 0 or 1 language details (7.11.6) C/S [Code or String] (7.12.2) 0 to many 0 to many Information about a language in which the healthcare organisation is able or willing to communicate. A discipline or speciality provided by the healthcare organisation.

Example(s): University hospital, private clinic, laboratory service provider. Values: A candidate list of codes and associated terms is provided in Table E.9 of Part 2 this Prestandard.


Page 131 prENV 13606-4:1999 7.10.16. healthcare device Type: class Specialisation of: healthcare agent (7.10.10) Description: Device or equipment involved in the direct or indirect provision of healthcare services to an individual or to a population. Example(s): Computer, ECG machine, auto-analyser, syringe pump. Attributes healthcare agent identifier Type identifier (7.11.5) Occurrence 1 to many

Attributes from generalisation: healthcare agent (7.10.10) A unique identifier of a healthcare agent. Usage: This should be used for a user organisation assigned identifier. A separate device serial number attribute is provided for a manufacturer assigned serial number. However, if there is no user organisation assigned identifier for a device the device serial number may be used. Attributes of specialisation device type The nature or function of a device. Example(s): ECG machine, Computer, Cardiac monitor. device manufacturer The name or organisation code for of the manufacturer. manufacturer's model name The model name assigned by the manufacturer. device version device serial number S [String] S [String] 0 or 1 0 or 1 Version number assigned to a device or to its constituent firmware. Serial number allocated by the manufacturer. Usage: This should not be used for a user assigned identifier of the device. device location location details (7.11.7) 0 or 1 The physical location of the device. Usage: This is only relevant for devices that have a fixed physical location. If it is necessary to specify the location at the time of use for a particular procedure, the record component (7.5.2) that records that activity should be linked to a related location data item (7.6.10). 7.10.17. healthcare software Type: class Specialisation of: healthcare agent (7.10.10) Description: Software component involved in the direct or indirect provision of healthcare services to an individual or to a population. Example(s): EHCR system, decision support software, viewing tools. Attributes healthcare agent identifier Type identifier (7.11.5) Occurrence 1 to many S [String] 0 or 1 C/S [Code or String] (7.12.2) 0 or 1 C [Coded] (7.12.1) 1

Attributes from generalisation: healthcare agent (7.10.10) A unique identifier of the healthcare software. Usage: If there is no unique identification scheme for software modules, an identifier may be generated by concatenation of relevant other relevant attributes including software product name and software version.


Page 132 prENV 13606-4:1999 Attributes of specialisation software product name software manufacturer software internal name S [String] C/S [Code or String] (7.12.2) S [String] 1 1 0 or 1 The name of the software product as assigned by the manufacturer. The name or organisation code for of the manufacturer or developer of the software. The name or identifier by which the software is referred to by other software. This may also be a programming object name. software filename S [String] 0 or 1 The filename of the file that contains the software (or the main or initial part of the software). Example(s): Winzip.exe software version software date The date of creation or last modification of the software. 7.10.18. healthcare agent relationship Type: class Description: A relationship between two healthcare agents (7.10.10). Note: A healthcare agent relationship is stated as relationship from a healthcare agent (7.10.10) (source) to another healthcare agent (7.10.10) (target). The source healthcare agent (7.10.10) is the subject of the healthcare agent in context (7.10.11) of which includes the healthcare agent relationship. Each healthcare agent relationship that is part of a healthcare agent in context (7.10.11) specifies part of the context to the "source" healthcare agent (7.10.10). Example(s): Employee / employer. On behalf of / responsible for. Contained in A healthcare agent relationship provides context for a healthcare agent in context (7.10.11). Attributes healthcare agent relationship type Type V [Code Value] (7.12.6) Occurrence 1 S [String] TOCD [Time+Date] 1 0 or 1 The version number of the software as assigned by the manufacturer.

The nature of the relationship between the source and target healthcare agents (7.10.10). Example(s): Employer of, responsible for, employee of, responsible to, sub-division of, parent organisation of, etc. Values: A candidate list of codes and associated terms is provided in Table E.10 of Part 2 this Prestandard. healthcare agent (7.10.10) class 1 The subject of this healthcare agent in context (7.10.11). The healthcare person (7.10.14), healthcare organisation (7.10.15), healthcare device (7.10.16) or healthcare software (7.10.17) to which this healthcare agent in context (7.10.11) provides context.


Page 133 prENV 13606-4:1999 7.10.19. healthcare agents directory Type: class Description: A collection of information about any number of healthcare agents (7.10.10) and/or healthcare agent in contexts (7.10.11). Usage: The healthcare agents directory may contain information about one or more healthcare agent in contexts (7.10.11) (i.e. a healthcare agent (7.10.10) in the context of their relationships with other healthcare agents (7.10.10)). The healthcare agents directory may also contain information about individual healthcare agents (7.10.10) (i.e. healthcare persons (7.10.14), healthcare organisations (7.10.15), healthcare devices (7.10.16) or healthcare software (7.10.17)) in a form that can be referred to in a healthcare agent in context (7.10.11) without repeating the details. Note: The healthcare agents directory represents a directory containing information about healthcare agents (7.10.10) and their inter-relationships in a form that can be referred to by other classes in a message. Example(s): Detailed information about a hospital may be conveyed as a healthcare agent (7.10.10) in the healthcare agents directory. Information about a doctor working in that hospital may be conveyed in a healthcare agent in context (7.10.11) related to the healthcare agent (7.10.10) that represents the hospital. Attributes healthcare agent in context (7.10.11) Type class Occurrence 0 to many

Information about a healthcare agent (7.10.10) in the context of a specified set of relationships to other healthcare agents (7.10.10). The healthcare agent in context enables a distinction to be made between references to the same healthcare agent (7.10.10) operating in different practical or organisational contexts. healthcare agent (7.10.10) class 0 to many Information about a healthcare person (7.10.14), healthcare organisation (7.10.15), healthcare device (7.10.16) or healthcare software (7.10.17) that performs a role in a healthcare activity.


Page 134 prENV 13606-4:1999

7.11.
7.11.1.

Subclasses
address

Type: subclass Description: An address expressed in a structured or unstructured form. Attributes address type Values: 0. Home 1. Work 2. Vacation 3. Temporary 4. Former 5. Other 6. Unspecified period of address validity postal code area of country / county Choice of structured address (7.11.15) unstructured address (7.11.21) 7.11.2. bed location subclass subclass period (7.11.11) S [String] C/S [Code or String] (7.12.2) 0 or 1 0 or 1 0 or 1 1 The period during which the associated address is applicable to the associated person or organisation. Type E [Enumerated] Occurrence 1

Type: subclass Description: A location expressed as a combination of a bed, a room and ward. Attributes One or more of ward Separate division in a hospital. room bed S [String] S [String] Identification or name of a room within a ward, as part of a bed location. An identification or description of a particular bed within a ward. C/S [Code or String] (7.12.2) Type Occurrence 0 or 1


Page 135 prENV 13606-4:1999 7.11.3. duration

Type: subclass Description: A period of time expressed as a time interval, date range or textual description. Attributes Choice of duration as time interval time interval (7.11.20) An interval of time expressed a number and a unit of time. Note: This sub-class consists of a numerical value and unit of duration. duration as date range duration as text description 7.11.4. expected delay period (7.11.11) S [String] Type Occurrence 1

Type: subclass Description: The time interval (7.11.20) of, and reason for, a delay. Attributes duration of expected delay comments to expected delay 7.11.5. identifier Type time interval (7.11.20) S [String] Occurrence 1 0 or 1

Type: subclass Description: A general-purpose identifier that can be qualified by the identification scheme from which the identifier is derived. Attributes identifier type Type V [Code Value] (7.12.6) Occurrence 0 or 1

An indication of the type of entity that is identified by the identifier. Examples: Person, organisation. identification scheme V [Code Value] (7.12.6) 0 or 1 The identification scheme from which an associated identifier is derived. Note: This may be omitted where there is appropriate agreement between communicating parties which include partner agreed identifiers for the party or object identified by the associated identifier value. identifier value S [String] 1 A number or string specified in an identification scheme to uniquely identify a single instance of an entity.


Page 136 prENV 13606-4:1999 7.11.6. language details

Type: subclass Description: language(s) in which a person is willing and able to converse for the purposes of providing or receiving healthcare services. Attributes language Type V [Code Value] (7.12.6) Occurrence 1

Language represented by the abbreviations specified in ISO 639. Usage: The coding scheme does not require identification by an ICSI as the codes used are derived directly from ISO 639. ability in language Values: 1. First language 2. Preferred language 3. Fluent 4. Fair 5. Limited 6. None 7.11.7. location details E [Enumerated] 0 or 1

Type: subclass Description: Information about a geographical location or type of location, expressed without a postal address (7.11.1). Example(s): In the patient's home, in hospital, in a ward, in a diagnostic department, in a particular ward, in a particular room within a department. Attributes One or more of location type C [Coded] (7.12.1) Type Occurrence 1

A code indicating the nature of the location. Example(s): Hospital ward, patient's residence, outpatient clinic, accident & emergency department, prison, nursing home, diagnostic department. Values: A candidate list of codes and associated terms is provided in Table E.11 of Part 2 this Prestandard. location description A textual description of the location. location identification S [String] A partner agreed identification of the location. Usage: If the location is identified using a scheme that is internal to a particular organisation, the location organisation should be specified to identify this organisation. location organisation healthcare agent (7.10.10) 0 or 1 A reference to a healthcare organisation (7.10.15) used to qualify a location identification or description. Example(s): If the location is a clinic or other place within a hospital, the location organisation identifies the hospital. S [String]


Page 137 prENV 13606-4:1999 7.11.8. measurement range

Type: subclass Description: A measurement range expressed as two numeric values and unit of quantity. Attributes One or more of upper limit value lower limit value unit of quantity R [Real] R [Real] V [Code Value] (7.12.6) 1 Type Occurrence 0 or 1

Usage: SI units should be used wherever possible. If standard SI unit abbreviations are used, the coding scheme need not be specified explicitly. In this case the ICSI associated with the code value may be omitted. Example(s): mmol/L, mg, days, kg, mmHg. 7.11.9. measurement with comparator

Type: subclass Description: A measurement or value of quantity (7.11.22) expressed as a numeric value and unit of quantity with an optional mathematical comparator Note: Used where it is rational for a value of quantity (7.11.22) to be expressed as greater than or less than a specified value. Attributes numerical value Example(s): "140" when a result is 140 mmol/l. unit of quantity V [Code Value] (7.12.6) 1 Usage: SI units should be used wherever possible. If standard SI unit abbreviations are used, the coding scheme need not be specified explicitly. In this case the ICSI associated with the code value may be omitted. Example(s): mmol/L, mg, days, kg, mmHg. arithmetic comparator V [Code Value] (7.12.6) 0 or 1 A mathematical sign indicating where a measurement is equal to, less than or greater than the specified numerical value. Example(s): >,>=,=,=<, <. 7.11.10. party identifiers Type: subclass Description: A set of one or more party identifiers used to identify a person or organisation. Note: Each identifier (7.11.5) is qualified to indicate the identification scheme from which it is derived. Attributes party identifier Type identifier (7.11.5) Occurrence 1 to many Type R [Real] Occurrence 1


Page 138 prENV 13606-4:1999 7.11.11. period Type: subclass Description: A period expressed as a start and end date. Attributes One or more of start date and time Date and time of the start of the specified period. end date and time Date and time of the end of the specified period. 7.11.12. person name details Type: subclass Description: The structured or unstructured name of a person. Attributes person name type Type V [Code Value] (7.12.6) Occurrence 0 or 1 TOCD [Time+Date] TOCD [Time+Date] Type Occurrence 0 or 1

Example(s): -- Alias name (artificial or assumed name by which a patient has been or is known; any code may serve as an alias, sometimes temporarily because proper identity is unknown or to preserve anonymity; a given person may have more than one alias). -- Maiden name (when female patients change their family name - e.g. upon marriage - this item carries their previous family name), -- Former name, -- Mother's maiden name (may be required to distinguish between patients with the same birth date and family name when registry files are very large and when no other means of unique patient identifiers by name is available), -- Preferred name. period of name validity period (7.11.11) 0 or 1 The period during which this name is or was valid. Note: This may be used to refer to previous names for the same person. Choice of structured person name (7.11.17) unstructured name subclass S [String] A person name composed of separately identifiable elements. A person name represented as a plain string of text without decomposition into separate name elements. Note: Used instead of structured names when communication parties do not support structured names. In some cases it may be impossible to distinguish which parts or a name should be placed in which name elements. Example(s): "Adelin Albert", "Alexandre le Grand", "Lord George Christopher" 1


Page 139 prENV 13606-4:1999 7.11.13. reference limit Type: subclass Description: A reference limit or normal range expressed as a numeric measurement range (7.11.8) or in a textual form. The limits may be applicable to a particular population and may be of a specified type. Example(s): Normal range for patients of a specified age and sex. Attributes Choice of numerical reference limit measurement range (7.11.8) Type Occurrence 1

Note: This attribute group consists of the attributes numerical value of lower reference limit of quantity, numerical value of upper reference limit of quantity and unit of numerical reference limit values. textual reference limit reference population definition C/S [Code or String] (7.12.2) C/S [Code or String] (7.12.2) 0 or 1 Note: A reference limit may be expressed as a string (e.g. "Between 10 and 20%"). Note: To indicate the meaning of the reference limit. Example(s): Sex, age, race, smoker/non-smoker, clinical status. type of reference interval V [Code Value] (7.12.6) 0 or 1 Example(s): Therapeutic (in the case of drug-monitoring). 7.11.14. repeat medication information Type: subclass Description: Information about the authorisation for repeat prescribing. This sub-class is an optional part of the medication data item (7.6.5). It should be included in instances of the medication data item (7.6.5) that have the drug information status authorisation. Usage: The provision of this information is a message is not intended to trigger an authorisation in the EHCR destination (7.3.3) system. Its purpose is to convey a record of any authorisation existing in the EHCR source (7.3.2) system. Note: Instances of the related date (7.8.7) attribute of the medication data item (7.6.5) should be used to convey information about dates or authorisation and date of expiry of authorisation. Instances of the related healthcare agent (7.8.8) attribute of the medication data item (7.6.5) should be used to indicate the person making the authorisation, the person responsible for the initial prescription of this medication and the person of people entitled to issue further repeats. Attributes number of issues authorised number of prescriptions issued interval between repeat issues Type I [Integer] I [Integer] time interval (7.11.20) Occurrence 0 or 1 0 or 1 0 or 1

The total number of issues authorised for this repeat medication. The number of prescriptions issued up the time on which this record was created. The expected interval between issues of an authorised repeat medication prescription.


Page 140 prENV 13606-4:1999 7.11.15. structured address Type: subclass Attributes number or name of house PO box number Note: PO is post office. apartment number street name district city or town country 7.11.16. structured dosage administration Type: subclass Attributes route of administration Example(s): oral, topical, intravenous injection single dose value of quantity (7.11.22) 0 or 1 The quantity of medicinal product administered to the patient at one event of administration of medicine. Example(s): 2 tablets, 2.5 ml, 3 puffs dosage pattern C/S [Code or String] (7.12.2) 0 or 1 Semi-structured way of describing dosage administration. Example(s): one tablet three times a day, two puffs two to four times daily. maximum daily dose infusion rate trigger for administration value of quantity (7.11.22) value of quantity (7.11.22) C/S [Code or String] (7.12.2) 0 or 1 0 or 1 0 to many Type V [Code Value] (7.12.6) Occurrence 0 or 1 S [String] S [String] S [String] S [String] C/S [Code or String] 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1 Type S [String] S [String] Occurrence 0 or 1 0 or 1

Part of a city, town or rural area used as part of a postal address. The name of the city, town or rural area used as part of the postal address.

The event or condition that should initiate or terminate the treatment or elicit the administration of a single dose. Example(s): by heartburn, when blood glucose lower than 2 mmol/l, by meals, when needed duration of drug treatment associated equipment/devices time of administration duration (7.11.3) C/S [Code or String] (7.12.2) TOCD [Time+Date] 0 or 1 0 or 1 0 to many Information on the length of time that the party recommending or prescribing the drug intends it to be taken.


Page 141 prENV 13606-4:1999 7.11.17. structured person name Type: subclass Description: A person name composed of separately identifiable elements. Attributes family name first given name Type S [String] S [String] Occurrence 1 0 or 1

Note: "last name" is ambiguous, especially in the case of persons of Far Eastern extraction. Note: "first name" is ambiguous, especially in the case of persons of Far Eastern extraction; "Christian name" may cause offence. middle name S [String] 0 or 1 Note: If the complete name consists of more than one name besides family name and given name, initials of the other names may be substituted for the middle name. title Example(s): Mr, Mrs, Sir, Lord, Dr, Ms, Miss, Rev. generation qualifier S [String] 0 or 1 Note: Usage of this name component is common in the United States of America. Example(s): Jnr, Snr, II, III, IV. 7.11.18. structured telecommunication number Type: subclass Attributes telecommunication country code telecommunication area code telecommunication number telecommunication extension number 7.11.19. telecommunication Type: subclass Description: Telephone, facsimile and other telecommunication numbers in a structured or unstructured form. Attributes telecommunication type Values: 0. Voice 1. Mobile 2. Pager 3. Facsimile 4. E-mail 5. Web-site 6. Other Type E [Enumerated] Occurrence 1 Type S [String] S [String] S [String] S [String] Occurrence 0 or 1 0 or 1 1 0 or 1 S [String] 0 or 1


Page 142 prENV 13606-4:1999 address type of telecommunication E [Enumerated] 0 or 1

Relates a telecommunication number to a particular address or location specified using an associated instance of the address class. Values: 0. Home 1. Work 2. Vacation 3. Temporary 4. Former 5. Other 6. Unspecified period of telecommunication number validity Choice of structured telecommunication number (7.11.18) unstructured telecommunication number subclass S [String] period (7.11.11) 0 or 1 1

Note: Used instead of structured number when communication parties do not support structured telecommunication numbers or when the structure of the number does not match the components available in the telecommunication common attribute group. Example(s): X.400 address. 7.11.20. time interval Type: subclass Description: An interval of time expressed a number and a unit of time. Attributes numerical value of time interval Number of the value for the time interval. unit of time interval V [Code Value] (7.12.6) 1 The unit of time in which the value of the time interval is expressed. 7.11.21. unstructured address Type: subclass Attributes unstructured address line Type S [String] Occurrence 1 to many Type R [Real] Occurrence 1

Note: Used instead of structured address (7.11.15) when communication parties do not support structured addresses or do not need to communicate the address in a structured form. 7.11.22. value of quantity Type: subclass Description: A quantity expressed as a numeric value and a unit of quantity. Attributes numerical value Example(s): "140" when a result is 140 mmol/l. unit of quantity V [Code Value] (7.12.6) 1 Usage: SI units should be used wherever possible. If standard SI unit abbreviations are used, the coding scheme need not be specified explicitly. In this case the ICSI associated with the code value may be omitted. Example(s): mmol/L, mg, days, kg, mmHg. Type R [Real] Occurrence 1


Page 143 prENV 13606-4:1999

7.12.
7.12.1.

Compound Types
C [Coded]

Type: subclass Description: Code with text description. Attributes ICSI Type S [String] Occurrence 0 or 1

International Coding Scheme Identifier identifying the coding scheme from which the associated code value is derived. Usage: The ICSI shall be present unless there is an explicit agreement on the coding scheme to be used for a particular attribute within a communicating community. Note: ICSIs are issued in accordance with ISO7826 to registered coding schemes. ISO7826 provides ranges of values for unregistered local schemes. code value S [String] 1 A string that contains a coded value taken from a specified coding scheme. Usage: The coding scheme shall be specified by one of the following: -- the accompanying ICSI -- an explicit specification for the attribute to which this type applies within the Prestandard -- an explicit specification for the attribute to which this type applies in implementation guidelines agreed within a communicating community. code meaning S [String] 0 or 1 A text string representing the meaning or term associated with the code value. Usage: Implementation guidelines agreed within a communicating community may make the code meaning mandatory for specified attributes of this type. 7.12.2. C/S [Code or String]

Type: subclass Description: Code (with text description) or uncoded text string. Attributes Choice of coded element text description C [Coded] (7.12.1) S [String] Type Occurrence 1


Page 144 prENV 13606-4:1999 7.12.3. CC [composite code]

Type: subclass Description: A sub-class used to convey information represented by one or more composite code elements. Each element within a composite code may contain a code value from a specified axis of a multi-axial coding scheme. Alternatively, the individual elements may be combinations of a coded feature and a code value representing a value applicable to that property. Attributes ICSI Type S [String] Occurrence 1

International Coding Scheme Identifier identifying the coding scheme from which the code values in the associated composite code elements are derived. Usage: The ICSI shall be present for all composite codes and applies by default to all its composite code elements. However, a composite code element may be derived from a coding scheme other than the one specified for the composite code. In this case, the coding scheme is identified by a separate ICSI within the composite code element. Note: ICSIs are issued in accordance with ISO7826 to registered coding schemes. ISO7826 provides ranges of values for unregistered local schemes. composite code element CE [coded element in composite] (7.12.4) S [String] 1 to many

A combination of a code value with optional instances of ICSI, coded feature and code meaning. composite code meaning 0 or 1 A textual description associated with a composite of one or more codes. Note: Individual codes within a composite may have there own textual descriptions. The composite code meaning should only be used where there is a human-readable representation of the composite. Example(s): If the composite includes a code for "neck of the femur", a code for "fracture" and another code for "left". A composite including these codes might be represented by the composite code meaning "fracture of the neck of the left femur".


Page 145 prENV 13606-4:1999 7.12.4. CE [coded element in composite]

Type: subclass Description: This construct is used, within the data type CC [composite code] (7.12.3), to hold a single code value within a composite. Each instance of CE [coded element in composite] contains a code value with optional instances of ICSI, coded feature and code meaning. Attributes ICSI Type S [String] Occurrence 0 or 1

International Coding Scheme Identifier identifying the coding scheme from which the associated code value is derived. Usage: The ICSI shall be present unless the coding scheme applicable to this element is the same as the scheme identified by the ICSI applied to the composite code of which this coded element forms a part. Note: ICSIs are issued in accordance with ISO7826 to registered coding schemes. ISO7826 provides ranges of values for unregistered local schemes. coded feature S [String] 0 or 1 A coded representation of the property to which the associated code value applies. In the case of a multi-axial coding scheme the coded feature is used to represent the axis of the scheme from which the code value Usage: The coded feature is used if it is necessary to convey pairs of codes representing a named property and the coded value of that property. This attribute need not be included if the nature of the property is implicit in the code value. Example(s): Code for "anatomical site" in the case of "anatomical site = heart" Code for "severity" in the case of "severity = mild" Code for "morphology" in the case of a code from the morphology axis of a coding scheme. code value S [String] 1 A string that contains a coded value taken from a specified coding scheme. Usage: The coding scheme is specified by one of the following: -- the accompanying ICSI -- the ICSI of the composite code of which this coded element forms a part. If the coded feature attribute is present, the code value specified a value applicable to the coded feature. Example(s): Code for "heart" in the case of "anatomical site = heart" Code for "mild" in the case of "severity = mild" A code from the morphology axis of a coding scheme. code meaning S [String] 0 or 1 A text string representing the meaning or term associated with the code value. Usage: If present, the code meaning should represent the meaning of the coded information in this coded element in a human-readable form. If the coded feature attribute is present the code meaning should accurately reflect the meaning of the code value in the context of its association with this coded feature. However, this Prestandard does not specify the rules for generating such a combined meaning as these are dependent upon the coding schemes used. Communicating communities should consider whether such rules are appropriate to any or all of the coding schemes used and may specify such rules in implementation guidelines.


Page 146 prENV 13606-4:1999 7.12.5. TL [Term List code]

Type: subclass Description: A code value and optional code meaning derived from a table in Part 2 of this Prestandard. Usage: The applicable table in Part 2 of this Prestandard is specified in the description of each attribute of this type. Attributes code value Type S [String] Occurrence 1

A string that contains a coded value representing an identifier from one of the tables in Part 2 of this Prestandard. code meaning S [String] 0 or 1 A text string representing the meaning or term associated with the code value. 7.12.6. V [Code Value]

Type: subclass Description: Code without description Attributes ICSI Type S [String] Occurrence 0 or 1

International Coding Scheme Identifier identifying the coding scheme from which the associated code value is derived. Usage: The ICSI shall be present unless either: -- this Prestandard specifies a specific coding scheme to be used to represent a particular attribute or -- there is an explicit agreement on the coding scheme to be used for a particular attribute within a communicating community. Note: ICSIs are issued in accordance with ISO7826 to registered coding schemes. ISO7826 provides ranges of values for unregistered local schemes. code value S [String] 1 A string that contains a coded value taken from a specified coding scheme. Usage: The coding scheme shall be specified by one of the following: -- the accompanying ICSI -- an explicit specification for the attribute to which this type applies within the Prestandard -- an explicit specification for the attribute to which this type applies in implementation guidelines agreed within a communicating community.


Page 147 prENV 13606-4:1999

7.13.
7.13.1.

Simple Data Types
B [Boolean]

Description: Boolean. Values: True or False 7.13.2. Blob [Binary large object]

Description: A data type consisting of a collection of binary data the structure of which is not specified explicitly by this Prestandard. Note: This data type is included for use where necessary in community defined data items (7.6.16). It is not currently used for any of the defined classes within this Prestandard. 7.13.3. E [Enumerated]

Description: Enumerated list Usage: The enumerated data type is used where a closed set of concepts is to be supported. The members of the closed set of concepts for each enumerated attribute are specified under the subheading "values" in this Prestandard. The manner in which these concepts are represented may depend on the implementation syntax. 7.13.4. I [Integer]

Description: Integer Note: The value may be any whole positive or negative number including zero. 7.13.5. R [Real]

Description: Real number. Note: The value may be any positive or negative number or zero with any number of decimal places. 7.13.6. S [String]

Description: String of characters. Note: The value may be a string of zero or more characters. The permitted character set shall be determined by agreement within a communicating community subject to the constraints of the implementation syntax. However, the character set chosen shall be either a character set defined in ISO8859 or the Unicode character set. 7.13.7. Signature

Description: Representation of a digital signature. The detailed structure of this will depend on security related Standards and community agreements on implementation. Note: Includes any hash key derived from the signature. Full structure may be dependent on the digital signature algorithm used by agreement between communicating parties. 7.13.8. TOCD [Time+Date]

Description: Time and date Note: The precise representation of the TOCD data type is not specified by this Prestandard and is dependent on the implementation syntax. However, the following points should be taken into account when mapping the attributes of data type TOCD into an implementable message. -- It shall be possible to include the date, time and optionally the time zone. -- It shall be possible to omit the time unless otherwise specified for a specific attribute. -- If the time is specified, it shall be possible to include the time in hours, minutes and seconds. However, it should also be possible to omit the seconds element. -- For certain attributes of the type TOCD the message permits the date to be expressed imprecisely as year only or as year and month. The message shall be capable of representing these imprecise dates.


Page 148 prENV 13606-4:1999

Annex A. (informative) How to read the models
A.1 Introduction
The modelling technique and the definition of terms in the models follow the conventions described within the Unified Modelling Language (UML). This annex contains a brief overview in this European Prestandard only to European Prestandard, or this Annex modelling healthcare information for of the modelling conventions used in this document. However, modelling is used demonstrate consistency and to illustrate the domain. It is not the intention of this to present this modelling method, or its implementation, as a general method for other purposes.

A.2 Classes and Packages
A.2.1 Classes A class is the descriptor for a set of objects with similar structure, behaviour, and relationships. This document provides a graphical notation for the relationships between instances of the classes where this adds to the clarity of the description of the domain. All classes are described textually. Note: an instance of a class may be called `an object'. Within UML, a Class is shown as a solid-outline rectangle with 3 compartments separated by horizontal lines. The upper name compartment holds the class name; the middle compartment holds a list of attributes; the bottom list compartment holds a list of operations. In the DIM diagrams in Clause 7, the representation of a class includes only two compartments, the name compartment and the attribute compartment, the latter indicating the sub-clause within the document where the attributes are described. In the GMD diagrams in Clause 6, where a class is included in a diagrammatic representation of the structure within a subsystem, only the name compartment is shown and reference to the sub-clause follows the class name.
Class Name in DIM see 7.x.x

Class Name in GMD - see 7.x.x

Figure A.1. Representation of classes in DIM and GMD diagrams A.2.2 Packages A package is a grouping of model elements. Packages themselves may be nested within other packages. All kinds of UML model elements and diagrams can be organised into package. A package is shown as a large rectangle with a small rectangle (a "tab") attached on one corner. If the contents of the package are not shown, then the name is placed within the large rectangle.

Package name see 7.x

Figure A.2. Representation of packages in diagrams


Page 149 prENV 13606-4:1999

A.3 Relationships
A.3.1 Generalisation/Specialisation A generalisation/specialisation relationship between classes implies that the specialisation is a kind or subtype of the generalised class. For example a dog is a specialisation of animal. A solid line between classes with a hollow triangle at the generalisation end indicates as generalisation/specification relationship. The lines from several classes may converge on and connect to the generalisation through a single hollow triangle. This indicates that a single instance can only be one of the specialisations shown. Other specialisations may be able to coexist in the same instance. For example "cat" and "female animal" are both specialisations of "animal" and a female cat is a single instance that has the characteristics of both these specialisations.
Class C see 7.x.x
is specialised as is specialised as

Class C see 7.x.x

Class A see 7.x.x

Class B see 7.x.x

Class A see 7.x.x

Class B see 7.x.x

Figure A.3. Illustrations of classes A and B as specialisations of Class C Specialisation classes inherit all attributes, relationships and services from their generalisation class(es). A generalisation may be an abstract class. In this case, no instances of the generalised class exist except as instances of one of the specialisations. The names of abstract classes are italicised in the diagrammatic representations of the model. Class C
see 7.x.x

is specialised as

Class A see 7.x.x

Class B see 7.x.x

Figure A.4. Illustrations of classes A and B as specialisations of the abstract Class C In messages specified by this European Prestandard the generalisation/specialisation relationship may be encountered in either or the following ways: -- A generalised class may be explicitly included in the structure of a message. This usually implies the inclusion of an instance of one of the specialisations of that generalisation (if the generalisation is an abstract class then this is always the case). EXAMPLE 1 If a message includes the generalised class "animal" then it may include an instance of an available specialisation such as "cat" or "dog". -- A specialisation may be explicitly included in the structure of a message. In this case, the specialisation includes an instance of the generalisation and all its attributes. However, it does not follow that a further specialisation instance is included. EXAMPLE 2 If a message includes "dog" then attributes of the general class "animal" are included. However, this instance of animal does not lead to a further instance of "dog" (or "cat").


Page 150 prENV 13606-4:1999 A.3.2 Aggregation Aggregation refers to relationship in which one class is a "a part of" another class. Unlike a composition relationship the parts of an aggregate have an existence even if the aggregate is deleted. For instance a healthcare professional may be part of a healthcare organisation but the same healthcare professional may be referred to outside the context of that organisation. A solid line between two classes with a hollow diamond at one end represents an aggregation. The diamond is attached to the aggregate class. The line is labelled with an indication of the nature of the association and with a triangular arrowhead indicating the direction of association The ends of the line may be labelled with the multiplicities of the association (that is the numbers of instances of one class that may be part of the same instance of the aggregate or the number of aggregation of which the other class may be a part).

Class A
0..1 may contain one may be part of one

Class A see 7.x.x
0..* May be part of any number of

see 7.x.x

0..1

Class B see 7.x.x
0..1 may be part of one

Contains one

1 may contain any number of

Class C
0..*

Class D see 7.x.x

see 7.x.x

Figure A.5. Illustration of aggregation relationships


Page 151 prENV 13606-4:1999 A.3.3 Composition Composition is a type of aggregation relationship in which the aggregate owns the parts. Deletion of the aggregate also deletes all its constituent parts. A solid line between two classes with a solid diamond at one end represents a composition. The diamond is attached to the composite class. The line may be labelled with an indication of the nature of the association and with a triangular arrowhead indicating the direction of association The part end of the line may be labelled with the multiplicities of the association (that is the numbers of instances of one class that may be part of the same instance of the composite). The multiplicity at the end represented by the solid diamond is implicitly "1" since a part only exists within the composite.
Class A see 7.x.x
may include is part of 0..*

Class B see 7.x.x

Figure A.6. Illustration of a composition relationship

A.3.4 Associations between classes An association is any relationship between classes other than the Generalisation/Specialisation and Aggregation and Composition relationships described earlier in this annex. A solid line between two class symbols illustrates an association between those classes. The line is labelled with an indication of the nature of the association and with a triangular arrowhead indicating the direction of association The ends of the line are labelled with the multiplicities of the association (that is the numbers of instances of one class that may be associated with a single instance of the associated class). Associations between classes in this European Prestandard are usually supported in the messages by one or more reference attributes within one or both of the classes which point to or identify one or more instances of the other class.
Class A see 7.x.x
0..* refers to 1

Class B see 7.x.x

Figure A.7. Illustration of associations between classes


Page 152 prENV 13606-4:1999 A.3.5 Associations between packages The only types of association shown between packages in this European Prestandard are association. There is an association between two packages if any of the classes within one package are related to classes within the other package. A dashed line between the package symbols illustrates an association between those packages. The line is labelled with an indication of the nature of the association and with a triangular arrowhead indicating the direction of association. Associations between packages are provided for illustrative purposes only and have no impact on the content of the messages specified in this European Prestandard.
Associated with

Package A see 7.x

Package B see 7.x

Figure A.8. Illustration of associations between packages A.3.6 Constraints on relationships A constraint may be attached to any type of relationship including association, aggregation, composition or specialisation. A dashed line crossing the affected relationships indicates the constraint. A note or reference enclosed in brace characters "{}" indicates the nature of the constraint.
Class A see 7.x.x
0..1

Class C see 7.x.x Class B see 7.x.x
0..1 {constraint rules}

Class A see 7.x.x

0..1

Class C
{OR}

see 7.x.x Class B see 7.x.x
0..1

NOTE The predefined constraint {OR} implies that each instance of Class C may contain an instance of either Class A or Class B.

Figure A.9. Illustrations of constraints on relationships


Page 153 prENV 13606-4:1999

Annex B. (informative) Draft XML DTDs for EHCR Messages
B.1 Introduction
This Annex contains examples of the messages specified in this European Prestandard represented using the Document Type Definition (DTD) of the Extensible Markup Language (XML). These specifications are illustrative only. Further development, refinement and documentation is required to enable successful implementation. Full documented versions of these DTDs are available as separated files on the World Wide Web. To avoid unnecessary repetition, these examples do not contain any comments other than reference to the relevant section of this Prestandard.

B.2 Document Type Definition of the Provide EHCR Message
<-- provide EHCR message (7.4.3) --> <-- This entity represents the choice of any specialisation of data item --> <-- This entity represents the common elements of all those data items in which the Component Name Structure is Optional -->

Page 154 prENV 13606-4:1999 RelDate*, RcNameCateg?, RcNameStruct?, DistRuleRef*, RevisionInfo?, Attestation*, Annotation+,"> <-- This entity represents the common elements of all those data items in which the Component Name Structure is Mandatory --> <-- EHCR destination (7.3.3) --> <-- EHCR source (7.3.2) --> <-- EHCR message related agent (7.3.4) --> <-- originator of referenced message (7.3.5) --> <-- specification of EHCR information (7.4.7) --> <-- message reference (7.4.5) --> <-- patient matching information (7.4.6) -->

Page 155 prENV 13606-4:1999 BirthDate?)| BirthDate), AlternativePersonName*, PersonAdministrativeSex?, Address*)> <-- attestation (7.8.2) --> <-- attesting agent (7.8.3) --> <-- component unique identifier (7.8.5) --> <-- originating healthcare agent (7.8.6) --> <-- component name structure (7.8.4) --> <-- related healthcare agent (7.8.8) --> <-- related date (7.8.7) --> <-- cluster (7.5.7) --> <-- composition (7.5.5) -->


Page 156 prENV 13606-4:1999 <-- EHCR extract (7.5.1) --> <-- empty record component (7.5.9) -->

Page 157 prENV 13606-4:1999 DateValidity (CONFIRMED|PROBABLE|RECEIVED|LEGACY|COMPILED) #IMPLIED> <-- folder (7.5.4) --> <-- headed section (7.5.6) --> <-- selected component complex (7.5.8) -->

Page 158 prENV 13606-4:1999 RelDate*, RcNameCateg?, RcNameStruct, DistRuleRef*, RevisionInfo?, Attestation*, SelectedRcComplexType?, RcSelectionCriteria*)> <-- address data item (7.6.13) --> <-- community defined data item (7.6.16) --> <-- event data item (7.6.6) --> <-- external data reference data item (7.6.7) -->

Page 159 prENV 13606-4:1999 ExtDataApplicationId?, ExtDataBookmark*)> <-- language data item (7.6.15) --> <-- medication data item (7.6.5) --> <-- patient related party data item (7.6.9) --> <-- person identifier data item (7.6.11) -->

Page 160 prENV 13606-4:1999 Id)> <-- person name data item (7.6.12) --> <-- physical entity reference data item (7.6.8) --> <-- quantifiable observation data item (7.6.4) --> <-- related location data item (7.6.10) --> <-- structured coded data item (7.6.3) -->


Page 161 prENV 13606-4:1999 <-- telecom data item (7.6.14) --> <-- text data item (7.6.2) --> <-- link set item (7.7.1) --> <-- source component (7.7.2) --> <-- target component (7.7.3) -->


Page 162 prENV 13606-4:1999 <-- revision information (7.7.4) --> <-- distribution rule directory (7.9.3) --> <-- distribution rule reference (7.9.2) --> <-- healthcare agent in context (7.10.11) --> <-- healthcare agent relationship (7.10.18) --> <-- healthcare agents directory (7.10.19) --> <-- healthcare device (7.10.16) -->

Page 163 prENV 13606-4:1999 Location?)> <-- healthcare organisation (7.10.15) --> <-- healthcare person (7.10.14) --> <-- healthcare software (7.10.17) --> <--The items below here represent subclasses used in the message --> <-- address (7.11.1) --> <-- bed location (7.11.2) --> <-- CE [coded element in composite] (7.12.4) --> <-- expected delay (7.11.4) -->


Page 164 prENV 13606-4:1999 <-- identifier (7.11.5) --> <-- language details (7.11.6) --> <-- location details (7.11.7) --> <-- party identifiers (7.11.10) --> <-- person name details (7.11.12) --> <-- reference limit (7.11.13) --> <-- repeat medication information (7.11.14) --> <-- structured address (7.11.15) --> <-- structured dosage administration (7.11.16) --> <-- structured person name (7.11.17) -->

Page 165 prENV 13606-4:1999 GenerationQualifier?)> <-- structured telecommunication number (7.11.18) --> <-- telecommunication (7.11.19) --> <-- unstructured address (7.11.21) --> <--The items below here represent attributes of the classes used in the message --> <-- additional related text --> <-- route of administration --> <-- time of administration --> <-- trigger for administration --> <-- administrative outcome --> <-- healthcare agent in context identifier --> <-- healthcare agent function --> <-- healthcare agent relationship type --> <-- alternative person name --> <-- annotation identifier --> <-- apartment number -->


Page 166 prENV 13606-4:1999 <-- DR country of application --> <-- associated equipment/devices --> <-- date and time of attestation --> <-- reason for attestation --> <-- bed --> <-- date of birth --> <-- city or town --> <-- code value --> <-- coded element --> <-- code meaning --> <-- coded feature --> <-- comment --> <-- comment on message --> <-- comments to expected delay --> <-- comment to drug treatment --> <-- communicating community identifier --> <-- arithmetic comparator -->


Page 167 prENV 13606-4:1999 <-- composite code meaning --> <-- country --> <-- area of country / county --> <-- date --> <-- duration as date range --> <-- days supply --> <-- device manufacturer --> <-- device serial number --> <-- device type --> <-- device version --> <-- district --> <-- DR applied date and time --> <-- DR basic distribution rule --> <-- DR consent demonstration reference --> <-- DR negation statement --> <-- distribution rule unique identifier --> <-- DR valid from -->


Page 168 prENV 13606-4:1999 <-- DR valid to --> <-- dosage pattern --> <-- quantity of drug supplied --> <-- end date and time --> <-- enterprise identifier --> <-- duration of event --> <-- urgency status of event --> <-- duration of expected delay --> <-- external data application identifier --> <-- external data bookmark --> <-- external data locator --> <-- family name --> <-- folder content indicator --> <-- generation qualifier --> <-- first given name --> <-- number or name of house --> <-- identification scheme --> <-- identifier type --> <-- identifier value -->


Page 169 prENV 13606-4:1999 <-- infusion rate --> <-- data item type reference --> <-- language --> <-- location description --> <-- location identification --> <-- location organisation --> <-- location type --> <-- lower limit value --> <-- manufacturer's model name --> <-- maximum daily dose --> <-- medication provision category --> <-- middle name --> <-- issue date and time of message --> <-- number of issues authorised --> <-- number of prescriptions issued --> <-- numerical reference limit --> <-- date value result of observation -->


Page 170 prENV 13606-4:1999 <-- numerical range result of observation --> <-- numerical value result of observation --> <-- text value result of observation --> <-- type of organisation --> <-- name of healthcare organisation --> <-- organisation name --> <-- originating date and time --> <-- identification of message by originator --> <-- component identification by originating system --> <-- medical specialty of healthcare party --> <-- patient consent status --> <-- patient identifiers --> <-- period of address validity --> <-- person administrative sex --> <-- military rank of healthcare person --> <-- person name type --> <-- position of healthcare person -->


Page 171 prENV 13606-4:1999 <-- qualification of healthcare person --> <-- type of healthcare person --> <-- planning stage --> <-- PO box number --> <-- postal code --> <-- unit of quantity --> <-- component name category --> <-- component name mapped code --> <-- component name original code --> <-- component selection criteria --> <-- type of reference interval --> <-- reference population definition --> <-- role of related healthcare agent --> <-- related date role --> <-- interval between repeat issues --> <-- reason for revision comments --> <-- reason for revision --> <-- room -->


Page 172 prENV 13606-4:1999 <-- selected component complex type --> <-- single dose --> <-- software date --> <-- software filename --> <-- software internal name --> <-- software manufacturer --> <-- software product name --> <-- software version --> <-- start date and time --> <-- reason for stopping treatment --> <-- street name --> <-- text description --> <-- duration as text description --> <-- EHCR subset description --> <-- telecommunication area code --> <-- telecommunication country code --> <-- telecommunication extension number --> <-- telecommunication number --> <-- text block -->


Page 173 prENV 13606-4:1999 <-- text markup indicator --> <-- textual reference limit --> <-- duration as time interval --> <-- unit of time interval --> <-- title --> <-- duration of drug treatment --> <-- unstructured address line --> <-- unstructured dosage administration --> <-- unstructured telecommunication number --> <-- upper limit value --> <-- ward --> <--The items below here represent data types used in the message --> <--Most data types are not explicitly included as XML elements as they are applied directly as templates for individual attributes listed above. Those listed here are referenced indirectly in some cases to avoid introducing mixed element types --> <-- The Signature data type is only a placeholder for specific implementations -->


Page 174 prENV 13606-4:1999

B.3 An XML Document Type Definition of the Request EHCR Message
Only the elements that differ from those in the Provide EHCR message are shown here. <-- request EHCR message (7.4.2) --> 5

10

15

20

B.4 An XML Document Type Definition of the EHCR Notification Message
Only the elements that differ from those in the Provide EHCR message are shown here.

30

35

40


Page 175 prENV 13606-4:1999

Index
A
ability in language associated equipment/devices

in structured dosage administration .....................140 in language details ................................ ..............136
attestation

additional related text

in structured coded data item ................................ 88
address

class description ................................ .................134
address data item

class description ................................ .................102
address of healthcare party

in healthcare organisation ................................ 130 ... in healthcare party ................................ ..............129 in healthcare person ................................ ............129
address of location

in related location data item ................................ 99 ..
address type

in address ................................ ...........................134
address type of telecommunication

in telecommunication ................................ .........142
administrative outcome

in event data item ................................ .................93
alternative person name

in patient matching information ............................62
annotation identifier

definition ................................ .............................10 in address data item ................................ ............102 in cluster ................................ .............................. 78 in community defined data item ..........................105 in data item ................................ ..........................84 in event data item ................................ .................93 in external data reference data item .......................95 in language data item ................................ ..........104 in medication data item ................................ ........91 in patient related party data item ...........................98 in person identifier data item ..............................100 in person name data item ................................ 101 .... in physical entity reference data item ....................97 in quantifiable observation data item ....................89 in related location data item ................................ 99 .. in structured coded data item ................................ 88 in telecom data item ................................ ...........103 in text data item ................................ ...................86
apartment number

class description ................................ .................115 definition ................................ .............................10 in address data item ................................ ............102 in cluster ................................ ..............................77 in community defined data item ..........................105 in composition ................................ .....................74 in data item ................................ ..........................84 in EHCR extract ................................ ...................67 in EHCR message component ............................115 in empty record component ................................ 81 .. in event data item ................................ .................93 in external data reference data item .......................95 in folder ................................ ...............................71 in headed section ................................ ..................76 in language data item ................................ .........104 in link set item ................................ ...................109 in medication data item ................................ ........91 in original component complex .............................70 in patient related party data item ...........................98 in person identifier data item ..............................100 in person name data item ................................ 101 .... in physical entity reference data item ....................96 in quantifiable observation data item ....................89 in record component ................................ .............68 in related location data item ................................ 99 .. in selected component complex ............................80 in structured coded data item ................................88 in telecom data item ................................ ...........103 in text data item ................................ ...................85
attesting agent

class description ................................ .................115 in attestation ................................ ......................115 B
B [Boolean]

class description ................................ .................147
bed

in bed location ................................ ...................134
bed location

class description ................................ .................134 in related location data item ................................ 99 ..
Blob [Binary large object]

class description ................................ .................147 C
C [Coded]

in structured address ................................ ...........140
apply DR access

in distribution rule ................................ ..............120
area of country / county

class description ................................ .................143
C/S [Code or String]

in address ................................ ...........................134
arithmetic comparator

class description ................................ .................143
CC [composite code]

in measurement with comparator ........................137

class description ................................ .................144


Page 176 prENV 13606-4:1999
CE [coded element in composite] city or town

class description ................................ .................145 in structured address ................................ ...........140 definition ................................ .............................10

clinical information cluster

class description ................................ ...................76 definition ................................ .............................10
code meaning

definition ................................ .............................10 in C [Coded] ................................ ......................143 in CE [coded element in composite] ....................145 in TL [Term List code] ................................ .......146

code value

definition ................................ .............................10 in C [Coded] ................................ ......................143 in CE [coded element in composite] ....................145 in TL [Term List code] ................................ .......146 in V [Code Value] ................................ ..............146
coded element

in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in

EHCR message component ............................113 empty record component ................................ 81 .. event data item ................................ .................92 external data reference data item .......................94 folder ................................ ...............................71 headed section ................................ ..................75 language data item ................................ .........104 link set item ................................ ...................108 medication data item ................................ ........90 original component complex .............................69 patient related party data item ...........................97 person identifier data item ..............................100 person name data item ................................ 101 .... physical entity reference data item ....................96 quantifiable observation data item ....................88 record component ................................ .............68 related location data item ................................ 98 .. selected component complex ............................79 structured coded data item ................................87 telecom data item ................................ ...........103 text data item ................................ ...................85 component reference ................................ 111 ...... component unique identifier ...........................117 revision information ................................ .......110 source component ................................ ..........109 target component ................................ ............110 address data item ................................ ............102 cluster ................................ ..............................77 community defined data item ..........................105 composition ................................ .....................74 data item ................................ ..........................84 EHCR extract ................................ ...................67 EHCR message component ............................115 empty record component ................................ 81 .. event data item ................................ .................93 external data reference data item .......................95 folder ................................ ...............................71 headed section ................................ ..................76 language data item ................................ .........104 link set item ................................ ...................109 medication data item ................................ ........91 original component complex .............................70 patient related party data item ...........................98 person identifier data item ..............................100 person name data item ................................ 101 .... physical entity reference data item ....................96 quantifiable observation data item ....................89 record component ................................ .............68 related location data item ................................ 99 .. selected component complex ............................80 structured coded data item ................................88 telecom data item ................................ ...........103 text data item ................................ ...................85

component identifier value

in C/S [Code or String] ................................ .......143
coded feature

in CE [coded element in composite] ....................145
coding scheme

definition ................................ .............................10
comment

component language

in event data item ................................ .................94
comment on message

in in in in

EHCR message ................................ ................57 EHCR notification message .............................. 61 provide EHCR message ................................ 59 .... request EHCR message ................................ 58 ....

comment to drug treatment

in medication data item ................................ ........91
comments to expected delay

in expected delay ................................ ................135
communicating community ................................ ...............10 communicating community identifier

in specification of EHCR information ...................63
communicating party

class description ................................ ...................52 in EHCR destination ................................ ............52 in EHCR message related agent ............................53 in EHCR source ................................ ...................52 in originator of referenced message ......................54
community defined data item

class description ................................ .................105
component identification by originating system

in in in in in in

address data item ................................ ............102 cluster ................................ .............................. 77 community defined data item ..........................105 composition ................................ .....................73 data item ................................ ..........................83 EHCR extract ................................ ...................66

component name

definition ................................ .............................10
component name category

in address data item ................................ ............102 in cluster ................................ ..............................77


Page 177 prENV 13606-4:1999 in in in in in in in in in in in in in in in in in in in in in in in in community defined data item ..........................105 composition ................................ .....................73 data item ................................ ..........................83 EHCR extract ................................ ...................66 EHCR message component ............................114 empty record component ................................ 81 .. event data item ................................ .................93 external data reference data item .......................95 folder ................................ ............................... 71 headed section ................................ ..................75 language data item ................................ ..........104 link set item ................................ ...................108 medication data item ................................ ........90 original component complex .............................70 patient related party data item .....................97, 99 person identifier data item ..............................100 person name data item ................................ 101 .... physical entity reference data item ....................96 quantifiable observation data item ....................89 record component ................................ .............68 selected component complex ............................79 structured coded data item ................................ 87 telecom data item ................................ ...........103 text data item ................................ ...................85 in in in in in in in in in in in in in in in in in in in in in in in in cluster ................................ ..............................77 community defined data item ..........................105 composition ................................ .....................74 data item ................................ ..........................84 empty record component ................................ 81 .. event data item ................................ .................93 external data reference data item .......................95 folder ................................ ...............................72 headed section ................................ ..................76 language data item ................................ .........104 link set item ................................ ...................109 medication data item ................................ ........91 original component complex .............................70 patient related party data item ...........................98 person identifier data item ..............................100 person name data item ................................ 101 .... physical entity reference data item ....................97 quantifiable observation data item ....................89 record component ................................ .............68 related location data item ................................ 99 .. selected component complex ............................80 structured coded data item ................................88 telecom data item ................................ ...........103 text data item ................................ ...................85

component name category

component reference

definition ................................ .............................11
component name mapped code

in component name structure ..............................116
component name original code component name structure

class description ................................ .................111 in revision information ................................ .......110 in source component ................................ ..........109 in target component ................................ ............110
component selection criteria

in component name structure ..............................116 class description ................................ .................116 in address data item ................................ ............102 in cluster ................................ .............................. 77 in community defined data item ..........................105 in composition ................................ .....................73 in data item ................................ ..........................83 in EHCR extract ................................ ...................66 in EHCR message component ............................114 in empty record component ................................ 81 .. in event data item ................................ .................93 in external data reference data item .......................95 in folder ................................ ............................... 71 in headed section ................................ ..................75 in language data item ................................ ..........104 in link set item ................................ ...................109 in medication data item ................................ ........90 in original component complex .............................70 in patient related party data item .....................97, 99 in person identifier data item ..............................100 in person name data item ................................ 101 .... in physical entity reference data item ....................96 in quantifiable observation data item ....................89 in record component ................................ .............68 in selected component complex ............................79 in structured coded data item ................................ 87 in telecom data item ................................ ...........103 in text data item ................................ ...................85 in address data item ................................ ............102

in selected component complex ............................80
component status

component order

in in in in in in in in in in in in in in in in in in in in in in in in in in in

address data item ................................ ............102 cluster ................................ ..............................77 community defined data item ..........................105 composition ................................ .....................73 data item ................................ ..........................84 EHCR extract ................................ ...................66 EHCR message component ............................114 empty record component ................................ 81 .. event data item ................................ .................93 external data reference data item .......................95 folder ................................ ...............................71 headed section ................................ ..................75 language data item ................................ .........104 link set item ................................ ...................109 medication data item ................................ ........90 original component complex .............................70 patient related party data item ...........................97 person identifier data item ..............................100 person name data item ................................ 101 .... physical entity reference data item ....................96 quantifiable observation data item ....................89 record component ................................ .............68 related location data item ................................ 99 .. selected component complex ............................80 structured coded data item ................................88 telecom data item ................................ ...........103 text data item ................................ ...................85


Page 178 prENV 13606-4:1999
component unique identifier

class description ................................ .................116 in address data item ................................ ............102 in cluster ................................ .............................. 77 in community defined data item ..........................105 in composition ................................ .....................73 in data item ................................ ..........................83 in EHCR extract ................................ ...................66 in EHCR message component ............................113 in empty record component ................................ 81 .. in event data item ................................ .................92 in external data reference data item .......................94 in folder ................................ ............................... 71 in headed section ................................ ..................75 in language data item ................................ ..........104 in link set item ................................ ...................108 in medication data item ................................ ........90 in original component complex .............................69 in patient related party data item ...........................97 in person identifier data item ..............................100 in person name data item ................................ 101 .... in physical entity reference data item ....................96 in quantifiable observation data item ....................88 in record component ................................ .............68 in related location data item ................................ 98 .. in selected component complex ............................79 in structured coded data item ................................ 87 in telecom data item ................................ ...........103 in text data item ................................ ...................85 in CC [composite code] ................................ 144 ......

data item type reference date

in community defined data item ..........................106

in related date ................................ .....................118 in attestation ................................ ......................115

date and time of attestation date of birth

in patient matching information ............................62
date value result of observation

in quantifiable observation data item ....................89
days supply

in medication data item ................................ ........91
device location

in healthcare device ................................ ............131
device manufacturer

in healthcare device ................................ ............131
device serial number

in healthcare device ................................ ............131
device type

in healthcare device ................................ ............131
device version

in healthcare device ................................ ............131
digital signature

composite code element composite code meaning

definition ................................ .............................11 in attestation ................................ ......................115
DIM

definition ................................ .............................11
distribution rule

in CC [composite code] ................................ 144 ......
composition

class description ................................ ...................73 definition ................................ .............................11 D
data item

class description ................................ .................120 definition ................................ .............................11 in distribution rule directory ...............................122
distribution rule directory

class description ................................ .................122 in provide EHCR message ................................ 59 ....
distribution rule reference

class description ................................ ...................83 definition ................................ .............................11 in address data item ................................ ............102 in community defined data item ..........................105 in event data item ................................ .................92 in external data reference data item .......................94 in language data item ................................ ..........104 in medication data item ................................ ........90 in patient related party data item ...........................97 in person identifier data item ..............................100 in person name data item ................................ 101 .... in physical entity reference data item ....................96 in quantifiable observation data item ....................88 in related location data item ................................ 98 .. in structured coded data item ................................ 87 in telecom data item ................................ ...........103 in text data item ................................ ...................85
data item content

in community defined data item ..........................106

class description ................................ .................121 definition ................................ .............................11 in address data item ................................ ............102 in cluster ................................ ..............................77 in community defined data item ..........................105 in composition ................................ .....................74 in data item ................................ ..........................84 in EHCR extract ................................ ...................67 in EHCR message component ............................115 in empty record component ................................ 81 .. in event data item ................................ .................93 in external data reference data item .......................95 in folder ................................ ...............................71 in headed section ................................ ..................76 in language data item ................................ .........104 in link set item ................................ ...................109 in medication data item ................................ ........90 in original component complex .............................70 in patient related party data item ...........................98 in person identifier data item ..............................100 in person name data item ................................ 101 ....


Page 179 prENV 13606-4:1999 in in in in in in in in physical entity reference data item ....................96 quantifiable observation data item ....................89 record component ................................ .............68 related location data item ................................ 99 .. selected component complex ............................80 structured coded data item ................................ 88 telecom data item ................................ ...........103 text data item ................................ ...................85
duration as date range

in duration ................................ .........................135

duration as text description duration as time interval

in duration ................................ .........................135 in duration ................................ .........................135

duration of drug treatment

distribution rule unique identifier

in structured dosage administration .....................140
duration of event

in distribution rule ................................ ..............120 in distribution rule reference ...............................121
district

in event data item ................................ .................94
duration of expected delay

in structured address ................................ ...........140
domain information model

in expected delay ................................ ................135 E
E [Enumerated]

definition ................................ .............................11
dosage pattern

in structured dosage administration .....................140
DR access type

class description ................................ .................147
EHCR

in distribution rule ................................ ..............120
DR applied by

definition ................................ .............................11
EHCR communicating parties subsystem .......................... 51 EHCR component ................................ .......................12, 15 EHCR destination

in distribution rule reference ...............................121
DR applied date and time

in distribution rule reference ...............................121
DR basic distribution rule

in distribution rule reference ...............................121
DR consent demonstration reference

in distribution rule reference ...............................121
DR country of application

class description ................................ ...................52 definition ................................ .............................11 in EHCR message ................................ ................56 in EHCR notification message ..............................60 in provide EHCR message ................................ 58 .... in request EHCR message ................................ 57 ....
EHCR distribution rule subsystem ................................ 119 ... EHCR external information identifier

in distribution rule reference ...............................121
DR how

in distribution rule ................................ ..............120
DR invalidated by

in external data reference data item .......................95
EHCR extract

in distribution rule reference ...............................121
DR negation statement

class description ................................ ...................66 definition ................................ .............................12 in provide EHCR message ................................ 59 ....
EHCR language EHCR message

in distribution rule reference ...............................121
DR rule author

in specification of EHCR information ...................63

in distribution rule ................................ ..............120
DR valid from

in distribution rule reference ...............................121
DR valid to

in distribution rule reference ...............................121
DR when

class description ................................ ...................56 definition ................................ .............................12 in EHCR notification message ..............................60 in provide EHCR message ................................ 58 .... in request EHCR message ................................ 57 ....
EHCR message component

in distribution rule ................................ ..............120
DR where

in distribution rule ................................ ..............120
DR who

in distribution rule ................................ ..............120
DR why

in distribution rule ................................ ..............120
drug information status

in medication data item ................................ ........91
duration

class description ................................ .................135

class description ................................ .................113 in address data item ................................ ............102 in cluster ................................ ..............................77 in community defined data item ..........................105 in composition ................................ .....................73 in data item ................................ ..........................83 in EHCR extract ................................ ...................66 in empty record component ................................ 81 .. in event data item ................................ .................92 in external data reference data item .......................94 in folder ................................ ...............................71 in headed section ................................ ..................75


Page 180 prENV 13606-4:1999 in in in in in in in in in in in in in in in language data item ................................ ..........104 link set item ................................ ...................108 medication data item ................................ ........90 original component complex .............................69 patient related party data item ...........................97 person identifier data item ..............................100 person name data item ................................ 101 .... physical entity reference data item ....................96 quantifiable observation data item ....................88 record component ................................ .............68 related location data item ................................ 98 .. selected component complex ............................79 structured coded data item ................................ 87 telecom data item ................................ ...........103 text data item ................................ ...................85
end date and time

in period ................................ ............................138 in specification of EHCR information ...................63 cluster ................................ ..............................77 community defined data item ..........................106 composition ................................ .....................74 folder ................................ ...............................72 headed section ................................ ..................76 original component complex .............................70

enterprise identifier

enterprise specific indicator

in in in in in in

event data item

class description ................................ ...................92
expected delay

EHCR message component subsystem .............................112 EHCR message notification comment

class description ................................ .................135
expected delay before event

in EHCR notification message .............................. 61
EHCR message notification type

in event data item ................................ .................94
external data application identifier

in EHCR notification message .............................. 61
EHCR message related agent ................................ .............12

in external data reference data item .......................95
external data bookmark

class description ................................ ...................53 in EHCR message ................................ ................56 in EHCR notification message .............................. 60 in provide EHCR message ................................ 58 .... in request EHCR message ................................ 57 ....
EHCR message related agent role

in external data reference data item .......................95
external data locator

in external data reference data item .......................95
external data reference data item

class description ................................ ...................94 F
family name

in EHCR message related agent ............................53
EHCR message related agent role scope

in EHCR message related agent ............................54
EHCR message subsystem ................................ ................55 EHCR notification message

in structured person name ................................ 141 ...
first given name

class description ................................ ...................60 definition ................................ .............................12
EHCR scope

in structured person name ................................ 141 ...
folder

in specification of EHCR information ...................63
EHCR source

class description ................................ ...................71 definition ................................ .............................12
folder content indicator

class description ................................ ...................52 definition ................................ .............................12 in EHCR message ................................ ................56 in EHCR notification message .............................. 60 in provide EHCR message ................................ 58 .... in request EHCR message ................................ 57 ....
EHCR structured record subsystem ................................ 65 ... EHCR subset description

in folder ................................ ...............................72 G
general message description

definition ................................ .............................12
generation qualifier

in structured person name ................................ 141 ...
GMD

in specification of EHCR information ...................64
EHCR system

definition ................................ .............................12 H
headed section

definition ................................ .............................12
EHCR update period

in specification of EHCR information ...................64
electronic healthcare record

class description ................................ ...................75 definition ................................ .............................13
healthcare agent

definition ................................ .............................11
empty record component

class description ................................ ...................81

class description ................................ .................127 definition ................................ .............................13 in healthcare agent in context .............................128 in healthcare agent relationship ..........................132


Page 181 prENV 13606-4:1999 in in in in in in healthcare healthcare healthcare healthcare healthcare healthcare agents directory .............................133 device ................................ ............131 organisation ................................ 130 ... party ................................ ..............129 person ................................ ............129 software ................................ .........131
healthcare party

class description ................................ .................128 definition ................................ .............................14 in healthcare organisation ................................ 130 ... in healthcare person ................................ ...........129 class description ................................ .................129 definition ................................ .............................14

healthcare person

healthcare agent function

definition ................................ .............................13 in healthcare agent in context .............................128
healthcare agent identifier

healthcare record

definition ................................ .............................14
healthcare record architecture

in in in in in in

healthcare healthcare healthcare healthcare healthcare healthcare

agent ................................ .............127 device ................................ ............131 organisation ................................ 130 ... party ................................ ..............129 person ................................ ............129 software ................................ .........131

definition ................................ .............................11
healthcare service

definition ................................ .............................14
healthcare software

healthcare agent in context

class description ................................ .................127 definition ................................ .............................13 in healthcare agents directory .............................133 in healthcare agent in context .............................128 in healthcare agent in context reference ..............128

class description ................................ .................131 definition ................................ .............................14 I
I [Integer]

healthcare agent in context identifier

class description ................................ .................147
ICSI

healthcare agent in context reference

class description ................................ .................128 definition ................................ .............................13 in attesting agent ................................ ................115 in communicating party ................................ ........52 in EHCR destination ................................ ............52 in EHCR message related agent ............................53 in EHCR source ................................ ...................52 in originating healthcare agent ............................117 in originator of referenced message ......................54 in related healthcare agent ................................ 118 ..
healthcare agent relationship

definition ................................ .............................14 in C [Coded] ................................ ......................143 in CC [composite code] ................................ 144 ...... in CE [coded element in composite] ...................145 in V [Code Value] ................................ ..............146
identification of message by originator

in in in in in

EHCR message ................................ ................56 EHCR notification message ..............................60 message reference ................................ ............61 provide EHCR message ................................ 58 .... request EHCR message ................................ 57 ....

class description ................................ .................132 definition ................................ .............................13 in healthcare agent in context .............................128
healthcare agent relationship type

identification of patient related party

in patient related party data item ...........................98
identification scheme

in identifier ................................ ........................135
identifier

in healthcare agent relationship ...........................132
healthcare agent role

class description ................................ .................135
identifier type

definition ................................ .............................13

healthcare agent subsystem ................................ .............126 healthcare agents directory

in identifier ................................ ........................135
identifier value

class description ................................ .................133 in EHCR message ................................ ................57 in EHCR notification message .............................. 61 in provide EHCR message ................................ 59 .... in request EHCR message ................................ 58 ....
healthcare device

in identifier ................................ ........................135
implementable message specification

definition ................................ .............................14
infusion rate

in structured dosage administration .....................140
interchange format

class description ................................ .................131 definition ................................ .............................13
healthcare organisation

definition ................................ .............................14
International Coding Scheme Identifier

class description ................................ .................130 definition ................................ .............................14

definition ................................ .............................14
interval between repeat issues

in repeat medication information ........................139


Page 182 prENV 13606-4:1999
issue date and time of message

in in in in in

EHCR message ................................ ................56 EHCR notification message .............................. 60 message reference ................................ ............61 provide EHCR message ................................ 58 .... request EHCR message ................................ 57 ....

in healthcare person ................................ ...........129
medication commercial category

in medication data item ................................ ........91
medication data item

class description ................................ ...................90
medication provision category message profile

L
language

in medication data item ................................ ........91 definition ................................ .............................15 EHCR message ................................ ................56 EHCR notification message ..............................60 provide EHCR message ................................ 59 .... request EHCR message ................................ 58 ....

in in in in in

EHCR message ................................ ................57 EHCR notification message .............................. 61 language details ................................ ..............136 provide EHCR message ................................ 59 .... request EHCR message ................................ 58 ....

message receipt acknowledgement request

language data item

class description ................................ .................104
language details

in in in in

message reference

class description ................................ .................136
language details of party

in in in in

healthcare organisation ................................ 130 ... healthcare party ................................ ..............129 healthcare person ................................ ............129 language data item ................................ ..........104

class description ................................ ...................61 in EHCR message ................................ ................57 in EHCR notification message ..............................61 in provide EHCR message ................................ 59 .... in request EHCR message ................................ 58 ....
message syntax

definition ................................ .............................15
message type

link set item

class description ................................ .................108
link set item

definition ................................ .............................15
middle name

definition ................................ .............................14
location

in structured person name ................................ 141 ...
military rank of healthcare person

in related location data item ................................ 99 ..
location description

in healthcare person ................................ ...........130
multiplicity

in location details ................................ ...............136
location details

definition ................................ .............................15 N
name of healthcare organisation

class description ................................ .................136
location identification

in location details ................................ ...............136
location organisation

in healthcare organisation ................................ 130 ...
name of healthcare person

in location details ................................ ...............136
location type

in healthcare person ................................ ...........130
name of patient related person

in location details ................................ ...............136
lower limit value

in patient related party data item ...........................98
narrative account indicator

in measurement range ................................ .........137 M
manufacturer's model name

in text data item ................................ ...................86
number of issues authorised

in repeat medication information ........................139 in healthcare device ................................ ............131
number of prescriptions issued

in repeat medication information ........................139
number or name of house

maximum daily dose

in structured dosage administration .....................140
measurement range

in structured address ................................ ...........140
numerical range result of observation

class description ................................ .................137
measurement with comparator

in quantifiable observation data item ....................89
numerical reference limit

class description ................................ .................137
medical specialty of healthcare party

in reference limit ................................ ................139
numerical value

in healthcare organisation ................................ 130 ... in healthcare party ................................ ..............129

in measurement with comparator ........................137 in value of quantity ................................ .............142


Page 183 prENV 13606-4:1999
numerical value of time interval

in time interval ................................ ...................142 in quantifiable observation data item ....................89

numerical value result of observation

O
OCC

definition ................................ .............................15 definition ................................ .............................15 in patient related party data item ...........................98

organisation

organisation name

original component complex

class description ................................ ...................69 in cluster ................................ .............................. 77 in composition ................................ .....................73 in folder ................................ ............................... 71 in headed section ................................ ..................75
original component complex

definition ................................ .............................15
original information context

definition ................................ .............................15
originating date and time

in in in in in in in in in in in in in in in in in in in in in in in in

composition ................................ .....................73 data item ................................ ..........................83 EHCR extract ................................ ...................66 EHCR message component ............................114 empty record component ................................ 81 .. event data item ................................ .................92 external data reference data item .......................94 folder ................................ ...............................71 headed section ................................ ..................75 language data item ................................ .........104 link set item ................................ ...................108 medication data item ................................ ........90 original component complex .............................70 patient related party data item ...........................97 person identifier data item ..............................100 person name data item ................................ 101 .... physical entity reference data item ....................96 quantifiable observation data item ....................88 record component ................................ .............68 related location data item ................................ 98 .. selected component complex ............................79 structured coded data item ................................87 telecom data item ................................ ...........103 text data item ................................ ...................85

originating healthcare agent

in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in

address data item ................................ ............102 cluster ................................ .............................. 77 community defined data item ..........................105 component reference ................................ 111 ...... composition ................................ .....................73 data item ................................ ..........................83 EHCR extract ................................ ...................66 EHCR message component ............................113 empty record component ................................ 81 .. event data item ................................ .................92 external data reference data item .......................94 folder ................................ ............................... 71 headed section ................................ ..................75 language data item ................................ ..........104 link set item ................................ ...................108 medication data item ................................ ........90 original component complex .............................70 patient related party data item ...........................97 person identifier data item ..............................100 person name data item ................................ 101 .... physical entity reference data item ....................96 quantifiable observation data item ....................88 record component ................................ .............68 related location data item ................................ 98 .. revision information ................................ .......110 selected component complex ............................79 source component ................................ ..........109 structured coded data item ................................ 87 target component ................................ ............110 telecom data item ................................ ...........103 text data item ................................ ...................85

class description ................................ .................117 in address data item ................................ ............102 in cluster ................................ ..............................77 in community defined data item ..........................105 in component reference ................................ 111 ...... in composition ................................ .....................73 in data item ................................ ..........................83 in EHCR extract ................................ ...................66 in EHCR message component ............................113 in empty record component ................................ 81 .. in event data item ................................ .................92 in external data reference data item .......................94 in folder ................................ ...............................71 in headed section ................................ ..................75 in language data item ................................ .........104 in link set item ................................ ...................108 in medication data item ................................ ........90 in original component complex .............................70 in patient related party data item ...........................97 in person identifier data item ..............................100 in person name data item ................................ 101 .... in physical entity reference data item ....................96 in quantifiable observation data item ....................88 in record component ................................ .............68 in related location data item ................................ 98 .. in revision information ................................ .......110 in selected component complex ............................79 in source component ................................ ..........109 in structured coded data item ................................87 in target component ................................ ............110 in telecom data item ................................ ...........103 in text data item ................................ ...................85
originator of referenced message

originating date validity

in address data item ................................ ............102 in cluster ................................ .............................. 77 in community defined data item ..........................105

class description ................................ ...................54 in message reference ................................ ............61


Page 184 prENV 13606-4:1999 P
party identifier PO box number

in structured address ................................ ...........140 in healthcare person ................................ ...........130 in address ................................ ...........................134

in party identifiers ................................ ..............137 in person identifier data item ..............................100
party identifiers

position of healthcare person postal code provide EHCR message

class description ................................ .................137
patient consent status

in specification of EHCR information ...................64
patient identifiers

class description ................................ ...................58 definition ................................ .............................15 Q
qualification of healthcare person

in patient matching information ............................62
patient matching information

class description ................................ ...................62 in EHCR message ................................ ................56 in EHCR notification message .............................. 60 in provide EHCR message ................................ 59 .... in request EHCR message ................................ 58 ....
patient related party data item

in healthcare person ................................ ...........130
quantifiable observation data item quantity of drug supplied

class description ................................ ...................88 in medication data item ................................ ........91

class description ................................ ...................97
period

R
R [Real]

class description ................................ .................138
period of address validity

class description ................................ .................147 in attestation ................................ ......................115 in request EHCR message ................................ 58 .... in revision information ................................ .......111

in address ................................ ...........................134
period of name validity

reason for attestation reason for request

in person name details ................................ ........138
period of telecommunication number validity

in telecommunication ................................ .........142
person address

reason for revision reason for revision comments

in address data item ................................ ............102 in patient matching information ............................62
person administrative sex

in revision information ................................ .......111
reason for stopping treatment

in patient matching information ............................62
person identifier data item

in medication data item ................................ ........92
record component

class description ................................ .................100
person name

in patient matching information ............................62 in person name data item ................................ 101 ....
person name data item

class description ................................ .................101
person name details

class description ................................ .................138
person name type

in person name details ................................ ........138
person telecommunication

in telecom data item ................................ ...........103
physical entity identifier

in physical entity reference data item ....................97
physical entity location

in physical entity reference data item ....................97
physical entity reference data item planning stage

class description ................................ ...................96 in event data item ................................ .................94

class description ................................ ...................67 definition ................................ .............................15 in address data item ................................ ............102 in cluster ................................ ........................77, 78 in community defined data item ..........................105 in composition ................................ ...............73, 74 in data item ................................ ..........................83 in EHCR extract ................................ ...................67 in empty record component ................................ 81 .. in event data item ................................ .................92 in external data reference data item .......................94 in folder ................................ .........................71, 72 in headed section ................................ ............ 75, 76 in language data item ................................ .........104 in link set item ................................ ...................108 in medication data item ................................ ........90 in original component complex .......................69, 70 in patient related party data item ...........................97 in person identifier data item ..............................100 in person name data item ................................ 101 .... in physical entity reference data item ....................96 in quantifiable observation data item ....................88 in related location data item ................................ 98 .. in selected component complex ............................79


Page 185 prENV 13606-4:1999 in structured coded data item ................................ 87 in telecom data item ................................ ...........103 in text data item ................................ ...................85
reference limit

class description ................................ .................139 in quantifiable observation data item ....................89
reference population definition

in reference limit ................................ ................139
referenced component order

in target component ................................ ............110
related date

in in in in in in in in in in in in

original component complex .............................70 patient related party data item ...........................97 person identifier data item ..............................100 person name data item ................................ 101 .... physical entity reference data item ....................96 quantifiable observation data item ....................88 record component ................................ .............68 related location data item ................................ 98 .. selected component complex ............................79 structured coded data item ................................87 telecom data item ................................ ...........103 text data item ................................ ...................85

class description ................................ .................118 in address data item ................................ ............102 in cluster ................................ .............................. 77 in community defined data item ..........................105 in composition ................................ .....................73 in data item ................................ ..........................83 in EHCR extract ................................ ...................66 in EHCR message component ............................114 in empty record component ................................ 81 .. in event data item ................................ .................92 in external data reference data item .......................94 in folder ................................ ............................... 71 in headed section ................................ ..................75 in language data item ................................ ..........104 in link set item ................................ ...................108 in medication data item ................................ ........90 in original component complex .............................70 in patient related party data item .....................97, 98 in person identifier data item ..............................100 in person name data item ................................ 101 .... in physical entity reference data item ....................96 in quantifiable observation data item ....................89 in record component ................................ .............68 in selected component complex ............................79 in structured coded data item ................................ 87 in telecom data item ................................ ...........103 in text data item ................................ ...................85
related date accuracy

related location data item

class description ................................ ...................98
repeat medication information

class description ................................ .................139 in medication data item ................................ ........92 definition ................................ .............................15

request EHCR message request EHCR message revision information

class description ................................ ...................57

in related date ................................ .....................118
related date role

in related date ................................ .....................118
related healthcare agent

class description ................................ .................118 in address data item ................................ ............102 in cluster ................................ .............................. 77 in community defined data item ..........................105 in composition ................................ .....................73 in data item ................................ ..........................83 in EHCR extract ................................ ...................66 in EHCR message component ............................114 in empty record component ................................ 81 .. in event data item ................................ .................92 in external data reference data item .......................94 in folder ................................ ............................... 71 in headed section ................................ ..................75 in language data item ................................ ..........104 in link set item ................................ ...................108 in medication data item ................................ ........90

class description ................................ .................110 in address data item ................................ ............102 in cluster ................................ ..............................77 in community defined data item ..........................105 in composition ................................ .....................74 in data item ................................ ..........................84 in EHCR extract ................................ ...................67 in EHCR message component ............................115 in empty record component ................................ 81 .. in event data item ................................ .................93 in external data reference data item .......................95 in folder ................................ ...............................71 in headed section ................................ ..................76 in language data item ................................ .........104 in link set item ................................ ...................109 in medication data item ................................ ........90 in original component complex .............................70 in patient related party data item ...........................98 in person identifier data item ..............................100 in person name data item ................................ 101 .... in physical entity reference data item ....................96 in quantifiable observation data item ....................89 in record component ................................ .............68 in related location data item ................................ 99 .. in selected component complex ............................80 in structured coded data item ................................88 in telecom data item ................................ ...........103 in text data item ................................ ...................85 in related healthcare agent ................................ 118 ..

role of related healthcare agent room

in bed location ................................ ...................134
route of administration

in structured dosage administration .....................140


Page 186 prENV 13606-4:1999 S
S [String] structured telecommunication number

class description ................................ .................141 in telecommunication ................................ .........142

class description ................................ .................147
SCC

T
target component

definition ................................ .............................16
scope of component identifier selected component complex

in component unique identifier ...........................117

class description ................................ .................110 in link set item ................................ ...................109
telecom data item

class description ................................ ...................79

class description ................................ .................103
telecommunication

selected component complex type Signature

in selected component complex ............................80

class description ................................ .................141
telecommunication area code

class description ................................ .................147
single dose

in structured telecommunication number ............141
telecommunication country code

in structured dosage administration .....................140
software date

in structured telecommunication number ............141
telecommunication extension number

in healthcare software ................................ .........132
software filename

in structured telecommunication number ............141
telecommunication number

in healthcare software ................................ .........132
software internal name

in structured telecommunication number ............141 in healthcare organisation ................................ 130 ... in healthcare party ................................ ..............129 in healthcare person ................................ ...........129 in related location data item ................................ 99 ..

telecommunication of healthcare party

in healthcare software ................................ .........132
software manufacturer

in healthcare software ................................ .........132
software product name

telecommunication of location telecommunication type

in healthcare software ................................ .........132
software version

in healthcare software ................................ .........132
source component

in telecommunication ................................ .........141
text block

class description ................................ .................109 in link set item ................................ ...................109
specification of EHCR information

in text data item ................................ ...................86
text data item

class description ................................ ...................85 in C/S [Code or String] ................................ .......143 in text data item ................................ ...................86 in quantifiable observation data item ....................89

class description ................................ ...................63 in EHCR notification message .............................. 61 in provide EHCR message ................................ 59 .... in request EHCR message ................................ 58 ....
splitting restriction

text description

text markup indicator

text value result of observation textual reference limit

in selected component complex ............................80
start date and time

in period ................................ ............................138
street name

in reference limit ................................ ................139
time interval

in structured address ................................ ...........140
structured address

class description ................................ .................142
time of administration

class description ................................ .................140 in address ................................ ...........................134
structured coded data item

in structured dosage administration .....................140
title

in structured person name ................................ 141 ...
TL [Term List code]

class description ................................ ...................87
structured dosage administration

class description ................................ .................146
TOCD [Time+Date]

class description ................................ .................140 in medication data item ................................ ........91
structured person name

class description ................................ .................147
trigger for administration

class description ................................ .................141 in person name details ................................ ........138

in structured dosage administration .....................140


Page 187 prENV 13606-4:1999
type of healthcare person type of organisation

in healthcare person ................................ ............130 in healthcare organisation ................................ 130 ... in reference limit ................................ ................139

unstructured telecommunication number upper limit value

in telecommunication ................................ .........142 in measurement range ................................ .........137 EHCR message ................................ ................56 EHCR notification message ..............................60 provide EHCR message ................................ 59 .... request EHCR message ................................ 57 ....

type of reference interval

urgency of message

U
unit of quantity

in in in in

in measurement range ................................ .........137 in measurement with comparator ........................137 in value of quantity ................................ .............142 in time interval ................................ ...................142

urgency status of event

in event data item ................................ .................93 V
V [Code Value]

unit of time interval unstructured address

class description ................................ .................146
value of quantity

class description ................................ .................142 in address ................................ ...........................134
unstructured address line

class description ................................ .................142
view record item complex

in unstructured address ................................ .......142
unstructured dosage administration

definition ................................ .............................16 W
ward

in medication data item ................................ ........91
unstructured name

in person name details ................................ ........138

in bed location ................................ ...................134