In Version	Author	Date	Amendment Details
1.0	Core Technical Team	10/05/2004	First release
1.1	Core Technical Team	03/09/2004	Amendments to hyperlinks only
1.2	Core Technical Team	07/01/2005	Removal of paragraph in section 2.3.1 indicating a requirement to provide a mapping to SNOMED Clinical Terms concept identifiers where other coding schemes have been used to code data. Updates to hyperlinks due to new version of EhrExtract message.

1 Introduction

The guide provides a logical walk through of issues encountered when populating the EHR Extract message with real data from clinical systems. The guide provides a more detailed explanation of specific issues but is neither complete nor definitive in its coverage of the all the message elements. Therefore, the guide should be read in conjunction with the message specification documents and not a substitute for these more detailed materials.

In addition to the content of this document, further separate documents describe specific parts of the message in more detail. These can be accessed from here. Documents are available for:

Observations:

Medication:

Other statements:

Other:

2 General advice

2.1 Identifiers

2.1.1 Types of identifier

Within the message there are several types of identifier which are represented using the HL7 “Instance identifier” data type.

Identifiers of people, organisations of things that have validity beyond the scope of the message or a particular record system:

These are referred to in this document as “external instance identifiers”.
They have a recognised assigning authority that can be referenced to relate an identifier to a real world entity.
Examples include a patient’s NHS number, a practitioner identifier (such as the GP number) and identifiers of organisations.

Identifiers used only within the message and/or record system to uniquely identify a specific instance of a class in the information model:

These are referred to in this document as “internal instance identifiers”.
Their primary purpose is to support unambiguous reference from other classes in the message or record system.
Examples include the identifier of a folder, composition or statement.

2.1.2 Representation of external instance identifiers

External instance identifiers are represented by using two attributes of the HL7 instance identifier (II) data type.

Root – contains an OID specifying the identifier scheme:

For example this might specify the UK NHS number;
Details are given in the tabular view.

Extension – contains the identifier of the specific entity:

For example this might be the actual NHS number of a patient.

2.1.3 Representation of internal instance identifiers

Internal instance identifiers are represented using a single attribute from the HL7 instance identifier (II) data type.

Root – contains a DCE Universally Unique Identifier:

For example: 09AF2470-BAE0-11CD-B579-08002B30BFEB.

An instance different DCE UUID must be generated for every element which contains an identifier of this type.

To support subsequent updates and references the identifiers need to be stored by the sending and receiving systems. In P1R2, updating is not a requirement. Therefore, storage of DCE UUIDs for all components is a future rather than immediate requirement.

2.1.4 References to internal instance identifiers

References to internal instance identifiers are represented in the same way as the identifiers themselves. However, where DCE UUIDs exist as references, they are by definition not unique since they refer to an identical existing internal instance identifier.

2.2 Clinical statements

2.2.1 Introduction

The accurate representation of the meaning of clinical statements is a safety critical issue for structured exchange of patient records. There are two cases to be considered.

· Meaning as understood by a person reading the information in the record.

· Meaning as interpreted by computer retrieval and processing.

In each of these cases the meaning of an individual statement is influenced to a greater or lesser extent by surrounding contextual information.

2.2.2 Human reading and interpretation

From a human perspective, a clinical statement is typically a phrase, sentence or the value of a single named investigation result. An informed reader interprets each statement in the context of surrounding statements which explicitly or implicitly qualify its meaning. The reader also takes account of the nature of the record or document that contains the information, the time and date and author of the statement and the times and dates of events to which it refers.

It is essential that communication of all or part of a record between two systems does not distort the likely human interpretation of the record. The receiving system must be able to present the received information to a reader in a form that is equivalent to the representation perceived by its author on the sending system.

It is a requirement that systems shall allow users to review received record entries in a form that ensures that clinical statements are presented in their original context and in the order entered or displayed in the originating system. It is also a requirement that the default view of received patient record information shall show the original phrases as typed, selected or displayed in the sending system.

This is not a rigid requirement for precisely identical screen formats on sending and receiving systems. Such a literal interpretation could be contrary to the objectives of effective communication. It would hinder evolution of more effective user interfaces to patient records and would restrict the ability of the receiving systems to present information in ways familiar to users. The user of the receiving system should be able to use alternative views of the record. However, from any such view it should be possible to select a view that displays the received information in a form that reflects the way it was originally recorded.

2.2.3 Computer retrieval and processing

2.2.3.1 Requirements and assumptions

Computer-based retrieval and interpretation is increasingly important in the provision of effective patient care and in the overall planning and evaluation of the care of the population.

Decision support advice may be used initiate appropriate recalls, aid safe and effective prescribing, guide clinicians through consistent protocols and offer links to relevant up-to-date research and reviews. Non-intrusive decision support depends on the ability of a system to check for particular combination of conditions, events or risk factors in the patient record.
Analysis for research, epidemiology, planning and audit also requires effective mechanisms for retrieval of information about patients that meet specified criteria.

There is an important connection between human interpretation and computer retrieval and processing. If the human readable version of the record asserts a particular condition then the user may assume that a decision support algorithm will also detect this. This assumption will only be correct if the relevant information has been conveyed in a form that is computer processable as well as human readable.

For example, if the screen show the patient has renal failure then the user may expect that an attempt to prescribe a drug contraindicated in renal failure would result in an alert message. The lack of such an alert may lead a user to wrongly suppose that a preparation is not contraindicated. To avoid this it is essential that the condition “renal failure” is communicated in computer retrievable form.

In an electronic record a clinical statement may be composed of data that falls into one of the following categories ¹ which are ordered according to their relative ease of computerised semantic interpretation:

Fields with formally defined meanings;
Coded values interpreted through use of a coding scheme;
“Free” text;
Digital images or signals.

The juxtaposition of statements and/or explicit references between statements may also have an effect on interpretation. The ability of a computer to interpret these elements and relationships is dependent on a variety of factors.

In the context of this message, some assumptions have been made about the computer retrieval and analysis of each of the types of data within clinical statements. These assumptions, stated below, are based on functionality of systems in use in UK General Practices and known issues derived from previous projects that have sought to process this data ².

2.2.3.2 Fields with formally defined meanings

A formally defined field is one that has a specified use and a specified set of unambiguous values. Formally defined fields with can be accurately used in computer retrieval and processing subject to adherence to the specified uses of these fields. These include:

dates and times;
numeric values (subject to use of agreed units);
references to identified people, organisations or devices;
postcodes (within the UK).

2.2.3.3 Coded data

A coded value is one that depends on a specified code list (defined within the message) or a coding scheme (specified externally). Coded values can be used in computer retrieval and processing but the potential uses depend on:

Access to the code list or coding scheme:

This is clearly the minimum requirement to allow the stated meaning of a code to be expressed and used when determining retrieval requirements.

Use of a terminology model:

Simply knowing that a particular code means “fractured femur” may not allow all patients with a record of a fracture of their femur to be retrieved.

The terminology may also have codes for “open fracture of femur”, “fracture of neck of femur” etc. Clinical terminology models such as the Read Codes or SNOMED CT define ways to relate subtype concepts to a supertype concept. Effective use of this aspect of a terminology model is essential for effective retrieval and processing.
The terminology may also allow post-coordinated expressions to be used. For example it might be possible to express “open fracture of femur” as a code phrase including five codes: “Fracture of bone” + “Site” = “Femur” + “Morphology” + “Open fracture”. This combined concept is a subtype of “fracture of femur” but none of the individual code values represent subtypes of that concept. Thus recognition of this aspect of a terminology model is also important.
A terminology may allow ways of expressing “family history of myocardial infarction” using the code values for “family history” and “myocardial infarction”. In this case the mere presence of the code for “myocardial infarction” in a record does not signify that the patient has had a myocardial infarction. If the terminology model includes a specific way of combining concepts like this then this must be recognisable.

Knowledge of the interplay between the terminology model in which the codes are used and the record structure:

A record structure may include several coded fields that relate to one another. For example, a system might have a specific field to indicate certainty or negation of a statement. Knowledge of these specific fields and their influence of interpretation of coded elements is essential for safe interpretation.
A record structure may have distinct record types for particular types of information and these may change the meaning of a code. For example, a system may have a record type for allergies and another record type for medication and drug codes might be used in both these record types with completely different meanings.
A record structure may include headed section that modify the meaning of coded information in otherwise identical records. For example, in such a system a record containing the code for “asthma” might appear either under the heading “Active Problems” or “Family History” with distinctly different interpretations.

In a single system the design of the coding schemes used, the terminology model and interplay between coding schemes and other aspects of record structure are likely to be constrained in known ways. Therefore, effective retrieval and processing of coded data is usually possible within certain known limits. However, the data structures, constraints and usage patterns in different systems may differ markedly. As a result communication between systems may lose some semantic specificity. An objective of GP to GP communications is to minimise this effect by specifying explicit common representation of key semantic information.

2.2.3.4 Text

Any “free” text ³ included a message in assumed to be for human readers only. This text shall not be parsed or processed by the receiving system in an attempt to derived structured or coded data ⁴.

Some sending systems may use text fields in their internal data structure in a fixed way to store information which is capable of being unambiguously encoded in accordance with the provisions of the message specification. In these cases, the sending system is permitted to encode the data in this way before sending. However, any such encoding shall be limited to the sending system and to cases where there is a clear unambiguous way to map a fixed text string. Use of more complex text parsing rules is not permitted.

2.2.3.5 Images and other digital objects

Any digital objects (including images, scanned documents, signals) shall be regarded as providing additional information for human reading, viewing or listening. Therefore, this data should be processed by the receiving system to the extent necessary to render the digitally recorded item in its appropriate form. However, no attempt should be made by a receiving system to parse the semantics within such an object except to the extent permitted or required by other standards formally adopted by the NHS⁴.

For example

A receiving system shall not attempt to generate coded records from a scanned attachment by applying optical character recognition and natural language processing ⁵.
A GP system that receives an NHS laboratory report message as an attachment may process that message.

2.2.3.6 Complete statements

A complete clinical statement may contain a mixture of the types of data discussed. This presents a difficulty for meeting the objective of semantic interoperability.

On the one hand, there is a requirement to retain the ability to retrieve and process information that is present in fields with fixed and unambiguous shared definitions and information encoded in a generally recognised way.
On the other hand, the computer processable of the commonly understood coded part of statement may be incomplete.

The intended meaning and the meaning of the human readable text may include additional semantics that are not accessible to computer.
Some of this additional meaning may be represented in the originating system in ways that are unambiguous. In this case, the issue is to map this to a common agreed representation to avoid incorrect interpretation. Known issues of this type are dealt with by specific advice on common representation in the message plus agreed mappings from specific system structures.
Some of additional meaning may only be represented in free text. In this case, the question is to determine whether the change is (or may be) sufficient to render processing of the coded part of the statement unsafe. One view is that any information conveyed in free text renders associated encoded data unsafe. However, such a view carries its own risks if taken to its ultimate conclusion at it would reduce most records entirely to textual rendering without any opportunity for decision support or analysis.

2.2.3.7 Qualification and modification

Proprietary structured data or free text additions made by a user may have one of two distinct effects on common coded information. For the purpose of these guidelines we refer to these effects as “qualification” and “modification”. Deciding which of these effects applies determines the safety of retaining and processing the coded information.

A “qualification” refines or extends the meaning of a coded statement while a “modification” fundamentally affects the meaning of statement. The following test can be applied to distinguish between a qualification and a modification:

Envisage three clinical statements

Statement A: The common structured coded element of the statement.
Statement B: The additional proprietary structured data or user added text.
Statement C: The combined statement A+B.

Consider a patient record that contains statement C.

1. 1) Does the inclusion of this statement C imply that statement A is true for this patient?

If yes – statement B is a “qualifier” of statement “A”.

Statement C can be safely represented as statement A with the additional information in statement B as text.

If no – statement B is a “modifier” of statement A. Consider question 2.

2. 2) Is statement B a valid coded clinical statement in its own right (even if incomplete)?

If yes – consider question 3.
If no – consider question 4.

3. 3) Does the inclusion of this statement C imply that statement A is true for this patient?

If yes – statement A can be represented as a “qualifier” of statement B.

Statement C can be safely represented as statement B with the additional information in statement A as text.

If no – then consider question 4.

4. 4) Can the modifying information in statement B be unambiguously encoded following rules in the message specification?

If yes – coded representation may be possible in one of two ways

Statement C should be represented using the structures and codes in the message that clearly disambiguate the coded information.

If no – statement C cannot be safely represented in a coded form.

Statement C should be represented as text.

These test can be applied reliably where the potential range of additions can be fully enumerated. For example, where a known code list is used (even if this is proprietary) or where text is added in a predictable way during use of a template or protocol.

Where the user is free to add arbitrary text to a coded entry, determination of whether this text represents a qualification or modification is strictly speaking impossible. However, the view that any text addition should render the coded entry unusable is incompatible with the need to combine the power of coded terminologies with the richer expression possible in narrative text. Therefore, it is suggested that consideration be given to actual current usage of free text and the manner in which the opportunity to enter free text is given to the user.

The problems raised by textual modifications of this type are in principle no different in the local system than after communication. If it is considered “safe” to use coded data with some textual modification in the original system then there is little additional risk in transferring this information in coded form. If the local practice in relation to coded data differs markedly in sending and receiving systems, it can be argued that the recipient system will suffer a degradation in their data quality as a result of accepting this data. However, this argument also applies to coded data without textual additions. Mechanisms for recognising the provenance of different entries within the record are clearly required to allow users with the highest quality data to recognise, quarantine or “clean-up” incoming information. Recognition of provenance of record entries is supported by the message at two distinct levels – the originating practice and system (see EhrFolder) and the original author (see EhrComposition).

System suppliers are advised to review the design and use of their systems to discourage use of text in ways that would fundamentally modify a coded entry. Two significant steps in this direction are to provide appropriate codes or structured constructs for such modifications and to issue simple good practice guidelines.

If there are specific places in current or legacy records where the use of text to fundamentally modify coded data is known to be common practice, then these cases should be identified and handled by rendering data as uncoded narrative. However, this need not be applied where the occasional misuse of text may occur.

Table 1. Examples of qualification and modification

Coded statement A	Additional info B	1	2	3	4	Representation
Fracture of femur	Open fracture (any representation)	Y	-	-	-	Code “Fracture of femur” Qualifier “Open fracture” (code/text as in original) Note that “Open fracture of femur” does mean patient has had a “Fracture of femur”.
Fracture of femur	Possible (coded or derived from record structure)	N	N	N	Y	Code “Fracture of femur” Modifier “Uncertain” Note that “Open fracture of femur” does mean patient has had a “Fracture of femur”.
Asthma	First episode (code)	Y	-	-	-	Code “Asthma” Qualifier “First episode” (code) Note that “First episode of asthma” does mean patient has had “asthma”.
Asthma	Family History (coded or derived from record structure)	N	Y	Y	-	Code “Family history of disease” Qualifier “Asthma” (code) Note that “Family history of asthma” does not mean patient has had “asthma” BUT “Family history of asthma” does mean the patient has a “Family history of disease”.
Penicillin V 250mg tabs	Prescribed	Y	-	-	-	Prescriptions are represented in specific structure in the message are distinguished from authorisation etc using specific structure in the message. Note that generally the inclusion of a drug code in a record implies treatment with that drug. Following this interpretation “Penicillin V 250mg tabs prescribed” does imply treatment with this drug.
Penicillin V	Allergy	N	Y	Y		Code “H/O Drug allergy” Qualifier “Penicillin V” (code) Note that “Allergy to Penicillin V” is not a record of treatment with “Penicillin V” BUT “Allergy to Penicillin V” does mean the patient has a “History of drug allergy”.
Penicillin V	Possible Allergy	N	Y	Y		Code “H/O Drug allergy” Qualifier “Penicillin V” (code) Modifier “Uncertain” Note that “Possible allergy to Penicillin V” is not a record of treatment with “Penicillin V” BUT “Possible allergy to Penicillin V” does mean the patient has a “Possible history of drug allergy”.
Allergy to Penicillin	Possible	N	Y	Y		Code “Allergy to Penicillin” Modifier “Uncertain” Note that “Possible allergy to Penicillin” is not a record of “Allergy to Penicillin” BUT “Possible allergy to Penicillin” does mean the patient has a “Possible history of drug allergy”.

2.3 Coded data and vocabularies

2.3.1 Vocabulary sources and coding schemes

Within these messages a variety of coding schemes are used and these are referenced in relation to individual attributes within the messages. For most coded attributes the "value set" of potential coded values is specified explicitly. In these cases, although a particular coding scheme is used, the value set is a subset of codes from that scheme. No other codes from the scheme may be used if the attribute is marked as CNE ("coded no exceptions"). If the attribute is marked CWE ("coded with exceptions") additional code values from the same coding scheme are permitted.

The primary sources for these are:

HL7 Vocabularies

These are used for structural codes (e.g. classCode, moodCode, typeCode, determinerCode).

NHS Data Standards

Codes specified in extant NHS Data Standards are specified where these are already required for use in GP computer systems (e.g. clinical specialties, departments and location types).

NHS Clinical Terminologies

Version 2 of the Read Codes are to be used for the primary representation of all coded clinical statements in the first instances of these messages.
Where 4 byte Read Codes exist in a record, these should be represented in the form in which they are included in NHS Clinical Terms Version 3. This is the 4-byte code prefixed with a full-stop. (e.g. 4-byte code "6521" is represented as ".6521").
The above codes represent a subset of the NHS Clinical Terms Version 3 superset. Other codes from NHS Clinical Terms Version 3 should not be used in these messages.

Extensions to NHS Clinical Terminologies

SNOMED Clinical Terms have been allocated to cover or complete the coverage of necessary value sets. The value sets to which this applies are fully specified in the Vocabulary section of the NPfIT Message Implementation Manual.

Some coded attributes are irrevocably bound to a particular HL7 specified coding scheme. In these cases no provision is made for identifying the coding scheme source within message instances. Other coded attributes require the coding scheme to be identified using the codeSystem element of one of the coded data type flavours (see Data Type Guide). The OIDs used to identify coding schemes are identified either in the tabular view or in the Vocabulary file.

2.3.2 Representation of codes and concept identifiers

2.3.2.1 General considerations

Most codes have a single literal form of representation which fixes in the "code" element of one of the coded data types. However, in the case of clinical terminologies such as the Read Codes and SNOMED Clinical Terms there may be two or more options for the literal representation. The following guidance is concerned with ensuring that in these case the representation is unambiguous.

2.3.2.2 Read Code

All Read Codes should be represented using a full five characters.

Where 4-byte codes are used these must be preceded by a full-stop as in the NHS Clinical Terms superset (e.g. 4-byte code "6521" is represented as ".6521").
Trailing full-stops are significant and must be included (e.g. "H43" is not a valid Read Code and must be represented in full as "H43..").

Care should be taken in any environment where a Read Code may have be subjected to auto-correction because:

Upper/lower case is significant
Conversion of a sequence of three full-stops "..." to a single "…" (ASCII Hex "85" Unicode Hex "2026") special character occurs in some environments and creates invalid Read Codes.

2.3.2.3 Read Code Version 2 - Term Code

Read Codes Version 2 uses a "Term Code" to distinguish between some alternative terms associated with the same Read Code. A Term Code is represented as a two digit string and is only unique within the context of a single Read Code.

It is now widely recognised that many of the terms associated with a Read Code are not true synonyms. This issue was partially resolved in NHS Clinical Terms Version 3 and further disambiguation has occurred in development of SNOMED Clinical Terms. However, in the meantime where Term Codes are stored these should be communicated with the Read Code.

A Read Code + Term Code combination is communicated as a single seven character code. Thus the code "7001200" represents represents the Term Code "00" associated with the Read Code "70012".

Note that this specification requires the term to be conveyed in the message in addition to any coded representation. Therefore, safe communication is not dependent on use of the Term Code in all systems. Therefore a sending system that does not support Term Codes for a particular item of information should not send a Term Code. Similarly a receiving system that does not support Term Code storage may ignore the Term Code when constructing a record entry. However, where a sending system stores the Term Code this should be included in the message and where a receiving system stores the Term Code this should be retrieved from the message.

2.3.2.4 NHS Clinical Terms Version 3 - Term Id

In NHS Clinical Terms Version 3 the TermId is a five character string that uniquely identifies an associated term (or set of two or three terms of alternative lengths). Although it is globally unique it says nothing about the associated concept and thus must be combined with the Read Code. There are no plans to use NHS Clinical Terms Version 3 and thus inclusion of TermId is not permitted. However, it could be accommodated as a ten-character string using the same approach as for the Term Codes.

2.3.2.5 SNOMED Clinical Terms - Concept Id

In translations from Read Version 2 codes, SNOMED Clinical Term concept identifiers shall be used. This is equivalent to the Read Code in that it identifies a concept. The lengths of ConceptIds are variable but all characters are digits.

2.3.3 Representation of associated text

Coded information may be associated with several distinct kinds of text. The way in which this information should be represented varies according to the nature of the association between the text and the code. A single statement may include more than one kind of text.

A term specified in the coding scheme as an appropriate meaning, term or description of a code.

This is represented in the displayName element of the coded data type.
A coded concept may have multiple possible associated terms and this case the choice of terms is made using the following options presented in order of priority:

The term associated with a specific additional identifier included in the code element (i.e. the term indicated by Term Code, Term Id or Description Id),
Failing that - the term stored with the statement if this precisely matches a term in the coding scheme,
Failing that - a term stated in the coding scheme as the preferred term,
Failing that - any term stated in the coding scheme.

Text present in the statement that was entered by an author or displayed to the author which formed the basis for coding.

This is represented in the originalText element of the coded data type.
There is a presumption that this originalText conveys the same meaning as the code or a meaning that refines a more generalised code. However, it is not possible to verify this automatically and for this reason the originalText should always be displayed to a recipient in preference to (or as well as) the displayName where both exist.

Text that fully describes the meaning of a post-coordinated coded representation

This may occur where a combination of a code and a set of associated qualifier elements are used to represent a complex concept which is also described in text.
This is represented as originalText element of the coded data type.
This is regarded as a minor variant of the other use of originalText outlined above. Although in some cases this kind of text may be automatically derived from the coded representation, the principle is the same since there may be alternative algorithms for generation. Furthermore,

Text present in the statement that is known to be a refinement or qualification of the code meaning represented by the displayName.

Unlike the originalText this is text that is not complete in itself but typically either prefixes or follow the displayName.
Discussions on appropriate representation of this type of text are continuing. The intention is that:

a system that does not support prefixing and/or suffixing text should be able to resolve the combined text as though it were simply included as originalText.
a system that does support prefixing and/or suffixing text should be able to distinguish these elements where they were separately identified in the sending system.

As with the originalText there is a presumption that these additions refine or qualify rather than fundamentally modify the coded meaning.

Textual annotations to a coded statement

Text included in a statement that is distinct from the coded meaning.
For example:

The text of a referral letter where the code represents a type of referral.
A narrative explanation of a particular diagnostic assessment.
A textual comment associated with a set of investigation results.

This type of text should be represented as a separate observation or attachment.

The message specification allows the association of attachments to any type of statement.
Although general attachments can be used this logically requires the text to exist as a distinct entity. Therefore a new textual annotation class with a similar associations to those of the attachment but supporting the direct inclusion of narrative is proposed for the next specification revision.

Textual representation of values from an investigation represented by the code attribute.

Text that represents values or results associated with an observation should be represented using the value attribute of the ObservationStatement statement.
Where this text requires specific layout this should be presented using the subset of HTML presented.

Textual rendering of a complete statement

A sentence or a other textual presentation that fully renders the information in the statement. This type of text includes the meaning of any codes, including modifiers and textual representation of values in the statement.
The type of text belongs in the text attribute of any type of statement.
This is the approach used for statements that exist only in text (or hypertext) forms. In this case the text attribute of the NarrativeStatement is used as the only representation of the meaning of the statement.

2.3.4 Representation of coded equivalents

Some attributes may be coded in the source system using a coding scheme that differs from the scheme required by the message specification. In these cases the coded data type provides for the original coded representation to be accompanied by one or more translations.

This applies to clinical statements which may be encoded using a coding scheme other than the Read Codes. To meet the message specification requirements either the original coded form or a translated representation must be from one of the coding schemes approved for the attribute. The original code (as entered or stored in the source record system) is sent at the top level with the closest equivalent in the approved scheme represented as a translation.

Translation between coding schemes almost invariably leads to some loss of data. This is the reason for sending the original code as well as a code in the approved common coding scheme. It is also one of the reasons for insisting the the text meaning of the code (displayName) is incorporated in the message. If a precise translation is not possible then the translation should always be to a more generalised code. Translation to a more specific code may add spurious precision and should be avoided.

The HL7 Version 3 data type specification permits multiple translations and allows these to be nested indicating a sequence of translation. However, for the purposes of the GP to GP communications no more than one translation should be included for any single coded attribute.

2.3.5 Representation of qualifiers for coded data

The HL7 data type specification provides a structure for representing qualifiers that refine the meaning of a code as part of the coded concept data type. The "modifier" element consists of a coded name and value pair. In the approved common coding schemes only those qualifiers with names and values that are specifically supported by that coding scheme should be used.

Proprietary coded representation that use their own qualifier may incorporate these along with the original code. In these cases, the required translation into the approved common coding should be the closest possible (more generalised) translation of the complete coded expression. There is no provision for individual elements of from a qualified representation to be separately translated as this is not considered to be a safe or useful approach.

This "modifier" element must not be used for major modification of meaning (see G.2.2.3.7.).

3 Message header

The payload of the EHR Extract message begins with the extract element (EhrExtract). This element will be conveyed inside standard HL7 message wrappers.

4 Message payload (EhrExtract)

4.1 Originator and Destination

The message wrapper will typically contain routing information about the sender and recipient.

The top level of the message (EhrExtract) contains information about the author (EhrExtract/author) and intended destination (EhrExtract/destination) of the message. These elements may appear to duplicate the information in the header but there are some important differences.

The information in the header is concerned with ensuring delivery to and indicating a destination for acknowledgement.
The EhrExtract/author element represents the provenance of the information. It allows the generating application and the sending organisation to be specified and dated. It is expected that this element will have a digital signature.
The EhrExtract/destination element represents the intended destination using a construct used for representing the roles of organisations.

Note

At the extract level the details of roles must be expressed in full rather than by use of a role reference. This is an essential variation since the role directories are within the folders. Presentation of information about the intended recipient should not require the contents of one or more folders to be examined.

4.2 The patient (EhrExtract/recordTarget)

The patient whose record is contained in the extract is identified at the extract level. Unless otherwise stated explicitly all information within the structures contained by an extract apply to that patient.

In the current model there are only three ways in which information within a message can be associated to a person other than the patient.

Information about a person within an instance of agent role (EhrFolder/responsibleParty);
Information about a family member, carer, contact or other related person represented as an observation (ObservationStatement) explicitly linked to specified subject of information (ObservationStatement/subject).
Information about a person providing information about the patient, e.g. a family member, carer, contact or other related person, represented as a clinical statement (EhrStatement) explicitly linked to an informant (EhrStatement/informant).

4.3 Specification of message contents (EhrExtract/limitation)

A specification (EhrExtractSpecification) is associated with the extract (via EhrExtract/limitation). This indicates the content of the message.

For initial use in GP to GP communications, most of the values in this element are fixed as the only permitted option is “Entire record available to originator” with a specified date/time of on which this applies.

Future extension of the message to cover temporary residents and shared-care will extend the range of options here. Therefore to avoid future ambiguity, this is a required element.

5 Subdivision of the message payload (EhrFolder)

5.1 Introduction

Folders (EhrFolder) are used as containers to subdivide information derived from and retained in the format of different record holders. The intention of the folder is to support onward transfer of records that include information received in a previous record transfer.

If Practice-A has never received an EHR Extract message about a patient, any EHR Extract message it sends regarding that patient contains only one folder.
If Practice-B has received an EHR Extract message about a patient from Practice-A, any EHR Extract message it sends regarding that patient contains two folders. The folder received from Practice-A and another folder containing information added locally.
If Practice-C has received an EHR Extract message from Practice-B containing two folders, any EHR Extract message it sends regarding that patient contains three folders. The two folders received from Practice-B and another folder containing information added locally.

Specific attention must be paid to the testing of these scenarios to confirm that the message design ensures that information can be passed through into subsequent transfers.

Notes

Entries in one folder may refer to entries in another folder. Thus it is possible to indicate errors or to revise information originating from a previous record holder.

Folders are not used to separate content from reports or other individual communications irrespective of their origin. If messages from other sources are to be retained and passed on in their native format, the attachment data element (ExternalDocument) is used.

5.2 Folder Originator (EhrFolder/author)

The message extract (EhrExtract) includes the author of the entire message. The folder contains another instance of the author element (EhrFolder/author) representing the provenance of the information in that folder. This specifies the source record holder to be specified, dated and digitally signed.

5.3 Role Directory entries (EhrFolder/responsibleParty)

5.3.1 Introduction

A role directory entry specifies a role played by an entity and this role may optionally be defined in more detail by the context of the roles they play in relation to other entities.

An example of a role is: “GP Registrar – Dr Smith – Responsible to – Dr Brown”

A folder must contain role directory entries (EhrFolder/responsibleParty) for each distinct role referenced in that folder. However, there should only be one role directory entry in a folder for each distinct role. The role reference mechanism is provided not just to reduce the size of the message but also to reduce the need for receiving systems to process multiple instances of identical role information.

Each entry in the role directory is an instance of the agent element (AgentRole). The id attribute in the agent element is a DCE UUID that may be entirely internal to the folder. It is used elsewhere in the message in role references (AgentRef) wherever that role participates in any element within the same folder.

5.3.2 Agents, people, organisations and devices

Each agent role is played by a person (Person), an organisation (Organization) or a device (Device).

The identification schemes to be used are specified in the message documentation and include:

SDS Role Profile and SDS User identifiers are used for healthcare professionals where these SDS identifiers are available;
The GP number used in GP-HA link is used to identify GPs where SDS identifiers are not available;
The OCS issued numbers for other health professionals and NHS organisations where SDS identifiers are not available.

5.3.3 Agent context

The entities that play the agent role may optionally have an agent context (AgentRole) in which they play that role whilst representing another entity. For example:

Agent role (GP registrar): Played by Dr Smith

Plays: AgentRole (Responsible to): Scoped by Dr Brown

The intention of constructs of this type is not to identify the individual but rather to distinguish between the same person acting in different roles and contexts. For example, “Dr Smith” may also have been employed as a locum in the same practice or may have been a GP Registrar in another practice. It is possible that the same person has contributed to the record in different contexts and these may be significant to interpretation of the record.

Originating systems may not have be able to distinguish the precise context in which a person acts and in these cases a more limited representation is permitted. The intention is that information about roles that is known should not be lost.

5.3.4 Agent addresses

The AgentRole (AgentRole) element includes an address (addr) attribute. The organisation (Organization) element also includes an address (addr) attribute. This presents two possible ways of recording an address.

6 Compositions (EhrComposition)

6.1 Introduction

A composition represents a discrete transaction between an author and the patient record.

Each composition contains a collection of one or more entries deemed to have been added during a discrete time-limited interaction between an agent (EhrComposition/author) and a patient record.

This definition may seem rather arcane. More familiar expressions like “an encounter record” or “the record of a single contact” may assist understanding. However, the scope of the composition is broader and yet more precise than the usual meanings of these familiar phrases.

The composition is the most significant architectural element in the record above and below it in the structure are somewhat arbitrary collection of information units. The composition on the other hand is a singular point at which authorship is asserted and potentially attested.

A composition may represent one of the following:

A single consultation
A series of indistinguishable consultations
Actions recorded outside a consultation
A contributions to the record made entirely by the computer
A collection of organising information not limited to a single event
Transformed legacy data

The following sections provide advice for representing each of these types of information.

6.2 Representing a single consultation

A consultation that is distinguishable in the source system should be represented by composition. This applies to face-to-face consultation, telephone conversations and to consultations with a third party representing the patient.

The following examples illustrate questions about the boundaries of a single composition.

A patient is seen by the GP who decides a procedure is necessary that requires use of the treatment room. The patient returns to the waiting room until this room is available. An hour later the GP is finally able to complete the required treatment.
A patient is seen by a nurse practitioner who requests a GP opinion. The GP comes to the consulting room and gives an opinion. The nurse practitioner initiates the treatment.
A GP is seeing a patient and is called out to an emergency. The patient is seen by another GP in the practice who in effect undertakes a complete consultation.

The factor that determines whether these are represented in one composition or several is how, when and by whom these events were recorded. If recorded by one person as a set of entries with no explicit demarcation between the steps in the sequence then this is represented as a single composition. If there are identifiably separate authors for different entries then each contribution is a separate composition. If there is a single author but an explicitly recorded temporal separation between two sets of entries then these should also be considered as separate consultations.

Where several people are involved in a consultation or in parts of a consultation these people can be identified as related agents (EhrStatement/participant). Related agents may participate in the entire consultation (in which case they can be associated with the composition) or in selected activities represented by compounds (CompoundStatement) or individual statements.

6.3 Representing series of indistinguishable consultations

There are some situations in which individual consultations may not be distinguishable. In these cases a single composition may represent a series of two or more consultations.

Consultation may be indistinguishable because the source system does not represent the consultation as a demarcated collection of record entries. In these cases, it is permissible to treat all entries recorded on the same day by the same author as part of a single composition.

o For example, a system may record individual entries with a date and time but where two consultations occur on the same day no firm dividing line may exist.

Consultations may be indistinguishable because the clinician record several of these in a single retrospective record. In these cases, permissible and logically entirely correct to represent this multi-consultation note as a single composition.

o For example, a retrospective record of several out of hours visits or phone calls.

6.4 Representing actions outside a consultation

6.4.1 Introduction

Some events that are recorded in a patient record take place without any contact with the patient or as a result of an indirect contact to request a specific routine action. Events that occur outside a consultation are represented in compositions that represent the nature of the interaction with the record.

For example, a report of an outpatient clinic attendance or hospital stay may be reviewed and filed by a practitioner. This activity may involve no direct contact with the patient but the report may be attached to the record and/or information extracted from the report may be added to the local record. This information is represented as a composition.

Some events may take place within a consultation or outside the consultation. If they occur within a consultation, the relevant content is included in the composition that represents the consultation. If they occur without patient contact then the relevant content is included in a separate composition.

For example, a repeat prescription may be issued

During a consultation

The statement(s) relating to the issued prescription should be in the same composition as the remainder of that consultation.

Without any direct contact, as a result of a routine request for an authorised repeat.

The statement(s) relating to the issued prescription should be in a “Repeat Issue Note” composition created for that interaction.

An individual instance of a particular type of event is only recorded in one composition. The name of a composition is concerned with nature of the interaction in which information is recorded and not with the semantics of the information contained.

For example

Repeat prescription issues may occur in compositions other than a repeat prescribing composition.

This repeat prescribing issue information must not be present in any other composition. Therefore, there will be no “Repeat Issue Note” composition.

A “Repeat Issue Note” composition may contain other types of information in addition to repeat prescription issues, such as:

re-authorisations or cancellations of authorisations.
observations about the rationale for reauthorisation, or cancellation.

6.4.2 Representing a request or referral letter

A referral request made or recorded outside a consultation is represented by a separate composition.

This composition contains a record of one or more requests (RequestStatement) made at the same time. It may optionally include other related clinical statements and the request form, letter or message as an attachment (EhrStatement/reference).

Requests made and recorded during a consultation have a similar structure but are included within the consultation composition and do not require a separate composition.

6.4.3 Representing review and filing or a report

A report from another health care providers that is reviewed and/or filed outside a consultation is represented by a separate composition.

This composition contains information derived from the report. It and may optionally include other related statements and the report, letter or message as an attachment (EhrStatement/reference).

Reports reviewed and filed during a consultation have a similar structure but are included within the consultation composition and do not require a separate composition.

6.4.4 Representing repeat prescribing – outside a consultation

A repeat prescription issued outside a consultation (e.g. in response to routine or regular request) is represented by a separate composition.

This composition contains details of the repeat prescription issued. It and may optionally include other related statements and the prescription form or message as an attachment (EhrStatement/reference).

Repeat prescriptions issued during a consultation have a similar structure but are included within the consultation composition and do not require a separate composition.

6.5 Representing contributions to the record made by the computer

6.5.1 Introduction

The computer system may provide decision support advice, create summaries or narrative representations of a record and transform legacy information in ways that make accessible as part of the current system’s record. Information recorded in the record from these actions could reasonable be attributed to the computer or to the computer acting in concert with a user.

Information generated, derived or transformed by the computer for inclusion in the record outside the context of a direct human interaction with the computer should be represented in a separate composition attributed to the computer application. The application can be represented in a role directory entry for this purpose.

Information generated, derived of transformed by the computer under the direct supervision of a user should be included within the appropriate human mediated composition. In this case, the role of the computer application can be represented as a related agent (EhrStatement/participant) associated with the contributions made to the record expressed as compounds (CompoundStatement) or individual statements.

6.5.2 Representing decision support advice

Information about advice offered by a decision support algorithm (and/or the computed basis for that advice) should usually be represented within the composition representing the consultation in which the advice was provided. The role of the decision support algorithm should be indicated by associating the advice with a related agent (EhrStatement/participant) referring to that algorithm and the relevant software by which it was run.

Information about advice offered by a decision support algorithm (and/or the computed basis for that advice) provided directly to the patient (e.g. through a protocol that interacts directly with the patient) should be represented in a separate composition. This composition should be attributed to that protocol in the context of the software used to run it.

Information added to the record as a result of analysis of clinical records by background or offline decision support tools should be represented in a separate composition. This composition should be attributed to those decision support tools.

6.5.3 Representing summaries of other information

A generated summary or narrative text representation of part of the record may itself be stored and considered as a distinct composition. If this type of construct is used this its author will be the software (if automatically generated) or an identified person (if the summary is manually generated).

Summaries generated semi-automatically with human oversight or intervention are attributed to the supervising person and in this case the software may also be identified as a related agent (EhrStatement/participant).

6.6 Representing information not limited to a single event

A record system may support problem orientation or similar views that depend on links between statements or collections of statements. These linkages are represented using link set (LinkSet) elements.

In an idealised view of the record links sets are created within the composition that represent the interactions in which links are stated or revised. Thus the instantaneous view of a problem would be derived from the union of several links sets. This approach ensures that all links are attributed to a person (or other agent) that first established them. However, there are two reasons for seeking a simpler short or medium term solution.

The idealised approach assumes that information about the context in which individual links were created and broken is stored in sending systems. This is not the case and, taking account of the following point this seems unlikely to change in the near future.
Maintaining and communicating links complete with a history of the context of creation and deletion of such links is complex. Furthermore, assigning responsibility for each link has arguable value or relevance.

A person viewing a record and revising links can from one perspective be said to be endorsing those links that they choose not to change.
A decision to move an item from one problem to another may take into account the context of other items in that problem.

Taking account of these factor links associated with problem orientation may be communicated as a snap shot attributed to the process of message generation rather than to a number of individual authors. This approach is supported by including all such link sets in a single composition with the message generation process participating as the author.

6.7 Representing transformed legacy data

A record system may contain information imported from a legacy system.

This information may be represented in one of two ways depending on whether the legacy structure can be reliably and consistently transformed in the compositional model.

The information may apportioned to appropriate compositions by following the preceding rules.
The entire transformed legacy record may be represented as a single composition. In this case, the legacy data composition is attributed to the import software and the activity date of the composition contains the date and time of the import.

6.8 Composition naming

Compositions are named using the code (code) attribute. The values for this code are specified in the relevant vocabulary specification (EhrCompositionName). Table 2 lists applicable composition names takes from this vocabulary under the various composition types identified in this section.

Table 2. Composition names related to different uses of compositions

A single consultation or a series of indistinguishable consultations
Consultations by timing	Consultations by location	Consultations by provider
Night Visit Note Night Visit , Practice Note Night Visit, Deputising Service Note Night Visit, Local Rota Note Twilight Visit Note Acute Visit Note Emergency Consultation Note Follow-up/Routine Visit Note Initial Post Discharge Review Note	Children's Home Visit Note Clinic Note Community Clinic Note Home Visit Note Hotel Visit Note Nursing Home Visit Note Residential Home Visit Note Surgery Consultation Note	Community Nursing Note OOH Attendance Note Out of Hours, Non Practice Note Out of Hours, Practice Note Externally Entered Note Health Visitor Note
		Consultations by mode
		Telephone call from a patient Telephone call to a patient Telephone Consultation Template Entry Third Party Consultation
Actions recorded outside a consultation
Requests and referrals	Reviewing and/or filing reports	Repeat prescribing / dispensing
Discharge Summary Report Health Authority Entry Laboratory Request Other composition Radiology Request Referral Letter Mail to patient	A+E Report Community Nursing Report Day Case Report Discharge Report G.O.S. 18 Report Health Visitor Report Hospital Admission Note Hospital Inpatient Report Hospital Outpatient Report Laboratory Result NHS Direct Report OOH Report Radiology Result Investigation Result Social Services Report Administration Note Mail from patient	Repeat Issue Note
Miscellaneous compositions
Contributions entirely made by the computer	Organising information	Transformed legacy data
Other composition	Other composition	Data Transferred from Other System
EHR Extract transaction

7 Compound statements (CompoundStatement)

7.1 Introduction

7.1.1 Use of compounds

Compound statements allow named collections of other statements within a composition (EhrComposition). Compound statements can be nested within one another allowing rich hierarchical representation of clinical statements.

7.1.2 Authorship of compounds

A compound statement inherits the original author (EhrComposition/author) of the composition that contains it. This inherited authorship also applies to the content of the compound statement.

A compound statement cannot be assigned to a different original author, because everything within a composition is deemed to be authored by a single agent. If a different author needs to be associated with a compound, it must be represented as part of a different composition.

7.1.3 Related agents

A compound statement inherits the participation of related agents (EhrComposition/participant) associated with the composition that contains it.

Additional agents involved in events recorded in a compound statement may be referred to by a related agent (EhrStatement/participant) instance directly associated with it.

Compound statements pass on their related agent participations to all the statements they contain. They also pass on this aspect of their context to other compound statements nested within them.

7.1.4 Inheritance of context

The meaning of a compound statement should not depend on the name of the composition that contains it or the nature of any other compound statement within which it is nested.

The interpretation may be affected by the provenance indicated by the original author of the containing composition or the originating practice of the containing folder. Other associations such as related specimens, attached documents and related agents may also influence interpretation. However, any other aspect of the meaning of compound statement that is substantially affected by its container composition must be explicitly restated in the compound statement and/or the relevant statement within that compound.

For example

A compound statement that contains a blood pressure measurement may have a different significance if it is part of an inpatient discharge report rather than a consultation note. However, it is still a blood pressure measurement.
A compound statement that includes various diagnostic and treatment information stated by a patient or third party should indicate the source of the information rather than assuming uncertainty from the context of “telephone consultation” composition.

7.2 Topics and categories

7.2.1 Using topics and categories

A clinical system may allow a consultation note (or another structured entry in the record) to be subdivided into sections. These subdivisions may relate to:

Topics

A single consultation might cover several distinct topics such as – “immunisation”, “contraceptive advice” and “hayfever”.

Categories

A consultation note or a topic might be divided into several sections such as – “history”, “examination”, “result” and “intervention”.

If a system supports either of these types of subdivision then they should be represented in the message as instances of CompoundStatement containing the relevant parts of the consultation note.

The classCode attribute specifies whether this CompoundStatement is a “topic” or a “category”.
The code attribute specifies:

The title for the topic using any appropriate Read Code.

A title for the category using either one of a specified set of codes. (see code list EhrGP2GPCompoundCode).

7.2.2 Topics and categories are non-semantic organisers

Topics and categories are organisers that collect together related statements. The clinical expectation is that items within a particular topic or category are relevant to the stated title. However, there are no specific rules restricting the possible content of a topic or category.

Topics and categories do not transmit semantics to their constituent statements. The full semantics of each statement within a topic or category must be expressed in the individual statement.

For example

A topic called “Allergy” does not imply that all statements within it refer to an allergy or its cause. This topic may refer to the assumed allergen and also to a drug or other substance used to treat the allergy. Thus it is essential that individual statements are semantically complete and do not use the topic name to imply interpretation.

The following is not safe and shall not be used:

CompoundStatement.classCode=“Topic” .code=“Allergy”

ObservationStatement.code=“Penicillin” .originalText= “Allergic reaction to penicillin”
ObservationStatement.code=“Chlorpheniramine” .originalText= “Treated with chlorpheniramine”

An explicit representation like one of the following should be used:

CompoundStatement.classCode=“Topic” .code=“Allergy”

ObservationStatement.code= “Drug Allergy” .value=“Penicillin” .originalText= “Allergic reaction to penicillin”
ObservationStatement.code=“Chlorpheniramine” .originalText= “Treated with chlorpheniramine”

CompoundStatement.classCode=“Topic” .code=“Allergy”

ObservationStatement.code= “Penicillin Allergy” .originalText= “Allergic reaction to penicillin”
ObservationStatement.code=“Chlorpheniramine” .originalText= “Treated with chlorpheniramine”

The Topic container has no direct semantic effect on its contents thus the statements above could alternatively be represented without the topic compound

ObservationStatement.code= “Drug Allergy” .value=“Penicillin” .originalText= “Allergic reaction to penicillin”
ObservationStatement.code=“Chlorpheniramine” .originalText= Treated with chlorpheniramine

ObservationStatement.code= “Penicillin Allergy” .originalText= “Allergic reaction to penicillin”
ObservationStatement.code=“Chlorpheniramine” .originalText= Treated with chlorpheniramine

A category called “Examination” does not imply that every statement within it is an examination finding.

As with the previous example individual statements should not be assumed to inherit exclusive semantic context from the category title.

7.3 Batteries and other statement clusters

7.3.1 Using batteries and clusters

A clinical system may allow statements to be grouped into logical collections that are inherently interconnected. Two types of grouping are recognised.

Battery

A collection of statements representing result items such as the individual constituents of the blood pressure measurement or a full blood count report.

This type of collection is equivalent to the result battery as used in the NHS Pathology Message Implementation Project.

Cluster

A collection of statements that has a broader scope than a battery. This type of construct can be used to represent nested elements within any template style of data entry and representation.

A Cluster may include batteries but a battery may not include clusters.

If a system supports either of these types of subdivision then they should be represented in the message as instances of CompoundStatement containing the relevant parts of the consultation note.

The classCode attribute specifies whether this CompoundStatement is a “battery” or a “cluster”.
The code attribute specifies:

The title for the battery or cluster using any appropriate Read Code.

For example the code for “full blood count”.

7.3.2 Batteries and clusters are semi-semantic organisers

Batteries and clusters are organisers that collect together logically related statements. At this stage there are no specific rules restricting the possible content of a particular cluster or batteries. However, it is possible that standard templates or archetypes may be developed that constrain or require a particular contents within some named clusters or batteries.

Batteries and clusters may not fundamentally modify the statements they contain. If the name of a cluster or battery implies modification its constituent statements, any implied fundamental modification must also be represented explicitly in each statement. It is unsafe to assume the transmission of major semantic modification by the coded name of a cluster.

For example

A cluster might have the name “Differential diagnosis” implying that the coded statements that it contains represent the possible diagnoses for a given set of symptoms and findings. However, the coded statements within this cluster must explicitly indicate their “uncertainty”.

Batteries and clusters may transmit limited semantic qualifications that affect the interpretation of their constituent statements.

For example

A battery may represent a blood pressure reading taken with the patient in a particular posture (standing or lying), or state (resting or post-exercise). This may be indicated by including coded observations of the posture and state of the patient as well as a battery representing the systolic and diastolic blood pressure.

This is not a fundamental modification since the contained observations are still literally correct observations of the patient’s systolic and diastolic blood pressure. However, the surrounding contextual information of this type significantly influences clinical interpretation.

8 Clinical Statements

8.1 Observation statements (ObservationStatement)

8.1.1 Introduction

The observation statement is used for a very wide range of entries in a patient record.

Any coded clinical statement about and event or observation that has actually occurred is expressed in the message using an instance of this class.

This following sections describe general rules and guidelines for the use of the ObservationStatement class.

8.1.2 Identification, Status and Revision

The identification, status and revision considerations applicable to an observation are the same as those for all statements (see Identification Status and Revision).

8.1.3 Structural Code

In all instances of the ObservationStatement class the classCode and moodCode have fixed values indicating that this represents an observation event (see Observation - Structural Codes)

8.1.4 Observation - Dates and Times

The ObservationStatement includes an optional date-time expression related to the observation: the effectiveTime, indicates the clinically relevant time. This date-time expression can specify a single date, a date range or a duration (see Observation - Dates and Times). The time of the activity from which the observation was derived can optionally be provided using the participant.time field.

Note that these dates and times can be expressed to different levels of precision and can be used to express date ranges and durations

In addition, each ObservationStatement has a system time-stamp, availabilityTime (see Identification Status and Revision).

8.1.5 Primary semantic content

The primary semantic content of each statement is represented by the code and value attributes. The code attribute is always a coded concept descriptor, the value may be a numeric value or range with units, a coded concept descriptor or another type of data appropriate to the specified observation.

The originalText component of the code attribute may also be present as a text rendering of the overall meaning of the observation. Note, however, that the code rubric and originally entered text for coded attributes (e.g. code and in some cases value) are represented by components within the coded expressions. Thus the originalText is only required where there is additional textual information (see Observation - Semantic content).

8.1.6 People, organisations and devices involved in making an observation

If a person, organisation or device has been involved in making, reporting, recording or assisting with the observation, this is recorded by including an instance of EhrStatement/participant for each such agent. This is represented in the same way for all types of statement (see Related Agents).

Note that there is no need to include this information in a statement if the agent or agents are the same as those specified in the containing EhrComposition or CompoundStatement. The role of author should not be represented as a related agent except to identify an additional author not represented as EhrComposition/author of the containing EhrComposition.

8.1.7 Alternative subjects of information

The default assumption about any statement is that it applies to the patient. If a person other than the patient is the subject of an observation, an instance of the class ObservationStatement/subject must be used to refer to the subject of information (see Observations that apply to a person other than the patient). This applies to various types of observations including:

Family history;
Infection disease contacts;
Observations on a foetus or neonate;
Information about donors of transplanted organs.

8.2 Representing specific types of observation

8.2.1 Clinical and social history

8.2.1.1 History - Introduction

Clinical or social history observations include information reported by a patient (or a third-party) and recorded in the record. In the GP domain where longitudinal records are kept some historical information is available in its contemporaneous form.

Clinical or social history observations may concern:

Reported symptoms and/or events relevant to the a current or new problem.
Past diagnoses, medication, procedures, etc.
Responses to a specific enquiry about past history and current risk factors (e.g. tobacco, alcohol, etc).

Statements about clinical and social history are represented using instances of ObservationStatement or for uncoded textual data, NarrativeStatement.

8.2.1.2 History - Dates and times (see Observation - Dates and Times)

participant.time represents the time of history taking. It should be omitted unless it differs from the effectiveTime of the containing EhrComposition.
effectiveTime represents the time of the reported occurrence. The effective time will often be imprecise and should only be expressed to the level of precision that is known.
For example, if during a consultation on 1st June 2001 the patient reported that they broke their leg on May 10th.

The participant.time is 1st June 2001.

However if the containing EhrComposition has this effectiveTime, this date may be omitted from the individual ObservationStatement.

The effectiveTime is 10th May 2001.

8.2.1.3 History - Semantic information

If history information is represented using clinical coding then the code should be conveyed in ObservationStatement.code (see Observation - Semantic content).

History information may in many cases be regarded as uncertain. This may be because the patient indicates that they are not sure about a particular detail or because the person recording an item of history is uncertain of its provenance. If information that is uncertain is represented in a coded form it is essential to represent the uncertainty in an unequivocal manner .

Uncoded history information may be either:

Represented by an instance of NarrativeStatement; or
Represented by instances of ObservationStatement with general codes associated with free text in the originalText component of the code attribute.

8.2.1.4 History - Source of information

The source of history information is the person who provided the history information to the clinician. Usually this assumed to be the patient or in the case of a child a parent or guardian. Where the record explicitly identifies the source of information, this person should be represented as a EhrStatement/informant. A person - such as a parent, partner or other third party - can be identified by type of person and/or their name.

Note the important difference between Source of Information and Subject of Information.

8.2.1.5 History - Subject of information

The subject of information is the person about whom an item of history is observed. This is usually the patient who is the subject of the entire record. However where an observation applies to another person this person must be indicated using the ObservationStatement/subject (see Observations that apply to a person other than the patient).

8.2.2 Surgical history

Surgical history should be represented using instances of ObservationStatement in the same way as other aspects of clinical history. The effectiveTime refers to the time in the past when an operation or procedure was carried out.

The HL7 RIM provides as specific class for procedures. The additional attributes in this class are not required for most GP records of procedures. The distinction between a formal record of a procedure and the observation that a procedure has been done is typically unclear. Furthermore, the coded terminology in use in GP systems allows the distinction between procedure and observation to be made where necessary by a receiving system - without the need for a distinct message construct.

8.2.3 Verbal medication history

A verbal or retrospective medication history may be recorded either using using instances of ObservationStatement in the same way as other aspects of clinical history. Alternatively, where appropriate structured information is available the instances of the MedicationStatement class may be used.

The use of ObservationStatement may be more appropriate where the necessary structured information is not available. Note that in this case effectiveTime refers to the time in the past when the medication was used.

In future, an additional option could be added to MedicationStatement to deal explicitly with retrospective recording of patient reported medication - with associated facilities to indicate uncertainty.

8.2.4 Family history

In this case the subject of the information held in the ObservationStatement is a family member of the patient. This relationship between the family member and the patient must be indicated using ObservationStatement/subject (see Observations that apply to a person other than the patient). Usually ObservationStatement/subject will not refer to an individual person but to an unidentified person in the role of "Family member" or possibly more specifically "Parent", "Father" etc.

Whenever an instance of ObservationStatement/subject is present, the presumption of a recipient should be that the observation does not apply directly to the patient.

Other aspects of family history observations should be represented using ObservationStatement in the same way as general clinical or social history observations.

The effectiveTime refers to the time of the reported event.

8.2.5 Symptoms

8.2.5.1 Symptoms - Introduction

Symptom observations include information reported by a patient (or a third-party) and recorded in the record.

Statements about clinical and social history are represented using instances of ObservationStatement or for uncoded textual data, NarrativeStatement.

8.2.5.2 Symptoms - Dates and times (see Observation - Dates and Times)

effectiveTime represents the time of the occurrence of the symptom. The effectiveTime may be imprecise and should only be expressed to the level of precision that is known.
participant.time represents the time that the symptom was recorded. It should be omitted unless it differs from the effectiveTime of the containing EhrComposition.
For example, if during a consultation on 1st June 2001 the patient reported that they had chest pain that started in May 2001.

The participant.time is 1st June 2001.

However if the containing EhrComposition has the same effectiveTime, this date may be omitted from the individual ObservationStatement.

The effectiveTime.low value is May 2001 representing the fact that the symptom had started in May and at the time of recording was still present.

8.2.5.3 Symptoms - Semantic information

If symptom information is represented using clinical coding then the code should be conveyed in ObservationStatement.code (see Observation - Semantic content).

8.2.5.4 Symptom - Topics

One or more related symptoms may be grouped into a single topic using the CompoundStatement structure (see 7.2.). This topic would have the code value for "Symptom". Note that topics do not transmit semantics to their constituent statements. The full semantics of each statement within a topic must be expressed in the individual statement.

8.2.6 Examination findings

8.2.6.1 Examination - Introduction

Examination findings include observations made by the author of the composition (or a third-party) and recorded in the record.

Statements about examination findings are represented using instances of ObservationStatement or for uncoded textual data, NarrativeStatement.

8.2.6.2 Examination - Dates and times (see Observation - Dates and Times)

effectiveTime represents the time of performing the examination.
participant.time represents the time of recording the results of the examination. It should be omitted unless it differs from the effectiveTime of the containing EhrComposition.
For example, prior to a consultation on 1st June 2001 the patient had 24 hour ambulatory blood pressure monitoring.

The participant.time is 1st June 2001.

However if the containing EhrComposition has this effectiveTime, this date may be omitted from the individual ObservationStatement.

The effectiveTime is 31st May 2001 of duration 24 hours.

8.2.6.3 Examination - Semantic information

If examination information is represented using clinical coding then the code should be conveyed in ObservationStatement.code (see Observation - Semantic content).

8.2.6.4 Examination - Results

The results of the examination are placed in the ObservationStatement.value using the datatypes below.

Quantitative measurement
PQ ::Physical quantity (real number with unit.)
Titre (e.g., 1:64) and other ratios
RTO :: A ratio of two integer numbers.
Index (number without unit)
PQ with a dimensionless unit (e.g., "1" or "%").
Nominal results (e.g. description)
ST a string

8.2.6.5 Examination - Topics

One or more examination statements or compound statements may be grouped into a single topic using the CompoundStatement structure (see 7.2.). This topic would have the code value for "Examination". Note that topics do not transmit semantics to their constituent statements. The full semantics of each statement within a topic must be expressed in the individual statement.

8.2.6.6 Examination - Batteries

Related examination statements may be grouped into batteries using the CompoundStatement structure (see 7.3.). For example the systolic and diastolic blood pressure measurements can be grouped into a blood pressure battery. The title of the compound would be coded with the name of the battery and the individual elements within the battery would be contained in separate coded observations.

8.2.6.7 Examination - Related agents

Where someone other than the author of the composition was involved in the examination then they should be identified as related agents (EhrStatement/participant). For examination findings related agents may participate in selected activities represented by compounds (CompoundStatement) or individual statements.

8.2.6.8 Examination - Subject of information

The subject of information is the person on whom the examination is performed. This is in most instances the patient who is the subject of the entire record. However where an observation applies to another person, for example a foetus, this must be indicated using the ObservationStatement/subject (see Observations that apply to a person other than the patient).

8.2.7 Investigation results

8.2.7.1 Investigation - Introduction

Investigation findings include observations made by the author of the composition (or a third-party) and recorded in the record.

Statements about investigation findings are represented using instances of ObservationStatement or for uncoded textual data, NarrativeStatement

8.2.7.2 Investigation - Dates and times (see Observation - Dates and Times)

effectiveTime represents the time of performing the investigation.
participant.time represents the time of recording the results of the investigation. It should be omitted unless it differs from the effectiveTime of the containing EhrComposition.

8.2.7.3 Investigation - Semantic information

If investigation information is represented using clinical coding then the code should be conveyed in ObservationStatement.code (see Observation - Semantic content).

8.2.7.4 Investigation - Results

The results of the investigation are placed in the value field using any of the datatypes below.

Quantitative measurement
PQ ::Physical quantity (real number with unit.)
Titre (e.g., 1:64) and other ratios
RTO :: A ratio of two integer numbers.
Ranges (e.g., < 3; 12-20)
IVL<PQ> :: Interval of physical quantity.
Ordinals (e.g., stage "IIa","++")
ST a string*.
Index (number without unit)
PQ with a dimensionless unit (e.g., "1" or "%").
Nominal results (e.g. description)
ST a string
Results expressed in fixed font text (as used for microbiology in the NHS PMIP messages to produce text tables representing outcome of a microbiology culture) are express as the Encapsulated Data Text and Line Breaks flavour of the ED datatype.

8.2.7.5 Investigation - Topics

One or more investigation statements or batteries may be grouped into a single topic using the CompoundStatement structure (see 7.2.). This topic would have the code value for "Result". Note that topics do not transmit semantics to their constituent statements. The full semantics of each statement within a topic must be expressed in the individual statement.

8.2.7.6 Investigation - Batteries

Investigations that are part of a battery of tests should be grouped into single compound using the CompoundStatement structure (see 7.3.). For example the constituent results that make up a full blood count are grouped into a compound statement. The title of the compound would be coded with the name of the battery and the individual elements within the battery would be contained in separate coded observations.

8.2.7.7 Investigation - Results (see Observation - Reference Ranges)

The reference range for the results for each investigation result may be passed in the message using an act relationship (InterpretationRange) attached to the instance of the observation (ObservationStatement) containing the investigation result. This act relationship contains a class (InterpretationRange) which contains the details of the reference range for the investigation. Numerical reference range values are placed in the value attribute which has a data type of interval of physical quantities. The units used for the physical quantity must be the same as that used for the approved unit of the result. Textual reference ranges (for example, complex reference range information carried as text in NHS PMIP messages) are placed in the text attribute.

8.2.7.8 Investigation - Related agents

Where someone other than the author of the composition is involved in the investigation then they should be identified as related agents (EhrStatement/participant). For examination findings, related agents may participate in selected activities represented by compounds (CompoundStatement) or individual statements.

8.2.7.9 Investigation - Subject of information

8.2.8 Diagnoses and clinical problems

8.2.8.1 Diagnosis - Introduction

Statements about diagnoses may be represented using instances of ObservationStatement or for uncoded textual data, NarrativeStatement (see 8.5.).

8.2.8.2 Diagnosis - Dates and times (see Observation - Dates and Times)

effectiveTime represents the clinically relevant time relating to the diagnosis. For a diagnosis made in the past the date would be the date on which the diagnosis was made.
participant.time represents the time of recording the diagnosis. It should be omitted unless it differs from the effectiveTime of the containing EhrComposition.

8.2.8.3 Diagnosis - Semantic information (see Observation - Semantic content)

If diagnosis information is represented using clinical coding then the code should be conveyed in ObservationStatement.code.

Where the certainty of a diagnosis needs to be conveyed, it is placed in the ObservationStatement.uncertaintyCode field (see uncertaintyCode). Where this information is processed by a receiving system then the context must be preserved.

Where a diagnosis is qualified, e.g. severity or laterality, this is conveyed in ObservationStatement.code.qualifier construct (see Note on qualifiers and modifiers). Each modifier consists of a name-value pair which are each coded entries.

The originalText attribute may also be present as a text rendering of the overall meaning of the observation. Note, however, that the code rubric and originally entered text for coded attributes (e.g. code and in some cases value) are represented by components within the coded expressions. Thus the originalText is only required where there is additional textual information.

8.2.8.4 Diagnosis - Related agents

Where someone other than the author of the composition is involved in the diagnosis record, then they should be identified as related agents (EhrStatement/participant).

8.2.9 Allergies

Allergies are recorded in the same way as diagnoses. However, because of the way that the coded representation of allergies may be stored on GP systems, special care should be taken to convey the code representation of the allergy.

For example for a patient with an allergy to penicillin the following would be valid representations

ObservationStatement.code= “Penicillin Allergy” .originalText= “Allergic reaction to penicillin”
ObservationStatement.code= “Drug Allergy” .value=“Penicillin” .originalText= “Allergic reaction to penicillin”

ObservationStatement.code= “Drug Allergy” code.qualifier=“Penicillin” .originalText= “Allergic reaction to penicillin”

However the following are not safe and shall not be used:

ObservationStatement.code=“Penicillin” .originalText= “Allergic reaction to penicillin”
ObservationStatement.code=“Penicillin” code.qualifier= “Drug Allergy”

In a similar fashion it would not be valid to use allergies as a topic or category heading to transmit semantics to their constituent statements. The full semantics of each statement within the topic or category must be expressed in the individual statements. A topic called “Allergy” may imply that all statements within it refer to an allergy or its cause. However, it is essential that individual statements are semantically complete and do not use the topic name to imply interpretation.

The following is not safe and shall not be used:

CompoundStatement.classCode=“Topic” .code=“Allergy”

ObservationStatement.code=“Penicillin” .originalText= “Allergic reaction to penicillin”

An explicit representation like one of the following should be used:

CompoundStatement.classCode=“Topic” .code=“Allergy”

ObservationStatement.code= “Drug Allergy” .value=“Penicillin” .originalText= “Allergic reaction to penicillin”

8.3 Medication statements

8.3.1 Introduction

Medication statements and related classes can represent the recommendation, authorisation, discontinuation, prescription, dispensing or administration of a therapeutic substance or appliance. The main classes used to convey information about prescription records are listed below. Note that the hyperlinks in this section are to the message specification rather than to the sections in the implementation guidance.

MedicationStatement. A statement that represents the recommendation, authorisation, discontinuation, prescription, dispensing, administration of a therapeutic substance or appliance.
MedicationStatement/pertinentInformation. Details of the dosage.
MedicationStatement/consumable. Details of a medicinal product. These include, drugs, nutritional supplement, devices used to administer drugs, dressing, appliances and diagnostic reagents.

· EhrSupply. Represents a choice of one or more of the following types of supply action associated with a medication statement.

o Discontinue. Represents a record of a discontinuation or a previously authorised or issued prescription

o Authorise. Represents an authorisation for one or more prescriptions for a specified medication item in a stated dosage.

o Prescribe. Represents an issued prescription.

o Dispense. A record of the actual supply of a medicinal product by the practice. For example personal administration or dispensing.

EhrSupply/consumable. Details of a medicinal product. These include, drugs, nutritional supplement, devices used to administer drugs, dressing, appliances and diagnostic reagents.
EhrSupply/performer. Refers to the agent involved in dispensing or administering the medication product if this is not the author of the record.
EhrSupply/pertinentInformation. Textual annotation to the supply.
Authorise/predecessor. A reference to a previously recorded authorisation which is reauthorised.
Discontinue/reversalOf. Refers to a previous medication statement that comprises a recommendation, an authorisation, a prescription or a combination of these supply related action.
Prescribe/inFulfillmentOf. Includes details of the associated supply authorisation. This is used when the authorisation occurs at the same time as a prescription issue.
Dispense/inFulfillmentOf. A reference to an associated prescription for this medication. This is used when the act of prescribing and dispensing/personal administration are recorded at different times

By using these classes in the way described in the following sections it is possible to represent the different ways that medication records may be present on UK general practice systems.

8.3.2 One-off prescriptions

This section describes the use of medication statements and related classes to convey information about individual prescription items issued by the practice. For details of how these classes are used see Medication - Individual Prescriptions.

Single prescriptions are represented as follows:

A single instance of the MedicationStatement class.
An optional MedicationStatement/consumable class containing details of the kind of medicinal product.
An optional MedicationStatement/pertinentInformation class containing details of the dosage.
A single mandatory instance of Prescribe representing an issued prescription.

An optional EhrSupply/consumable class containing details of the actual medicinal product.

Multiple items on one prescription may be represented by including the MedicationStatement instances for each item within a compound (CompoundStatement).

8.3.3 Repeat prescribing

8.3.3.1 Repeat authorisation

This section describes the use of medication statements and related classes to convey information about an authorisation for a repeat prescription created separately from a record of a prescription issued against that authorisation. For details of how these classes are used see Medication - Repeat Authorisation.

Repeat prescription authorisations are represented using the following classes:

A single instance of the MedicationStatement class.
An optional MedicationStatement/consumable class containing details of the kind of medicinal product.
An optional MedicationStatement/pertinentInformation class containing details of the dosage.
A single mandatory instance of Authorise representing an issued prescription.

An optional EhrSupply/consumable class containing details of the actual medicinal product.
A renewal or change of an authorisation is recorded as a new authorisation with a reference to the previous authorisation through the Authorise/predecessor relationship.

An expired or cancelled authorisation is indicated by its statusCode value.

Where the authorisation and initial prescription are recorded together this can be represented with the prescribing action by including the appropriate additional Authorise instance as well as an instance of Prescribe (see Repeat prescription issues below).

8.3.3.2 Repeat prescription issues

This section describes the use of medication statements and related classes to convey information about an individual prescription issued in the practice which is one of a series of authorised repeats. For details on how these classes are used see Issue of repeat prescription.

Repeat prescription authorisations are represented using the following classes:

A single instance of the MedicationStatement class.
An optional MedicationStatement/consumable class containing details of the kind of medicinal product.
An optional MedicationStatement/pertinentInformation class containing details of the dosage.
A single mandatory instance of Prescribe representing an issued prescription.

An optional EhrSupply/consumable class containing details of the actual medicinal product.
Where the authorisation and initial prescription are recorded together this can be represented with the prescribing action by including the appropriate additional Authorise instance as well as the Prescribe above.
Other prescriptions against an authorisation should refer to the appropriate authorisation using the Prescribe/inFulfillmentOf relationship.

Multiple items on one prescription may be represented by including the MedicationStatement instances within an CompoundStatement. If this prescription is issued outside a consultation this instance of CompoundStatement will be the only component in an instance of EhrComposition specific to that repeat issue. However, if the repeat prescription is issued in a consultation the CompoundStatement representing the prescription should be part of the EhrComposition representing that consultation. Repeat and one-off prescription items should be included in the same CompoundStatement if they are issued together.

8.3.3.3 Cancellation of authorisation

The following section describes the use of medication statements and related classes to convey information about a specific decision to discontinue a medication that was previously authorised for repeat prescribing. Use of this construct is not necessary where the act of discontinuation is not explicitly recorded in the sending system. For details on how these classes are used see Discontinuation of Repeat Authorisation.

Repeat prescription discontinuations are represented using the following classes:

A single instance of the MedicationStatement class.
An optional MedicationStatement/consumable class containing details of the kind of medicinal product.
A single mandatory instance of Discontinue representing the record of a discontinuation.
An optional Discontinue/reversalOf class referring to a previous medication statement containing the authorisation, that is discontinued by this statement.

Whether or not the discontinuation is recorded explicitly the statusCode of any expired or cancelled authorisation should be "complete" indicating an old authorisation that is no longer active.

8.3.4 Supply and administration of medication

8.3.4.1 Medication dispensed by a practitioner

The following table describes the use of medication statements and related classes to convey information about dispensing of a medication by the practice. The same approach can be used to record dispensing of a prescription (issued by the practice) in a pharmacy if this has been reported to the practice and stored in the patient record. For details see Medication - Dispensing.

Prescription dispensing acts are represented using the following classes:

A single instance of the MedicationStatement class.
An optional MedicationStatement/consumable class containing details of the kind of medicinal product.
An optional MedicationStatement/pertinentInformation class containing details of the dosage.
A single mandatory instance of Dispense representing a record of the actual supply of a medicinal product.
An optional EhrSupply/consumable class containing details of the actual medicinal product.
An optional Dispense/infulfillmentOf class is included if this fulfills a prescription issue.
An optional instance of Prescribe representing details of the prescription.
Where the authorisation and initial prescription are recorded together this can be represented with the prescribing action by including the appropriate additional Authorise instance. Otherwise the authorisation is referenced from Prescribe above by the Prescribe/inFulfillmentOf relationship

8.3.4.2 Medication administered by a practitioner

This section describes the use of medication statements and related classes to convey information about personal administration of a medication by a doctor or other health professional in the practice. The approach is similar to that used for dispensing with the main difference being that the dosage moodCode is "EVN" indicating an event of dosage rather than a recommendation "RMD" related to dosage. See Medication - Personal Administration of Medication for details

8.3.4.3 Medication prescribed or supplied by a third party

The following section describes the use of medication statements and related classes to convey information about medication prescription or supply by a third party such as a hospital out patient department or GP in another practice. For details see Medication - Third Party Prescriptions.

Third party prescriptions or supply's are represented using the following classes:

A single instance of the MedicationStatement class.
An optional MedicationStatement/consumable class containing details of the kind of medicinal product.
An optional MedicationStatement/pertinentInformation class containing details of the dosage.
An optional instance of MedicationStatement/component may be included to the record the quantity prescribed or supplied containing a minimal instance of either:

details of the prescription Prescribe

details of the item supplied Dispense

8.3.4.4 Medication recommendations and advice

The following section describes the use of medication statements and related classes to convey information about a recommendation for use of a particular medication without actually prescribing, supplying or administering it. See Medication - Recommendations and Advice.

Recommendations and advice are represented using the following classes:

A single instance of the MedicationStatement class.
A mandatory MedicationStatement/consumable class containing details of the medicinal product.
An optional MedicationStatement/pertinentInformation class containing details of the dosage.

8.4 Other statements

8.4.1 Requests and Referrals (see Requests)

The RequestStatement class may be used to represent a request for a service to be provided to the patient by another party. Request statements may include records of referrals and requests for investigations.

The effectiveTime attribute represents the time when the requested activity is intended to happen.

The participant.time attribute represents the time at which the referral was made or an investigation was requested.

The code attribute is used to convey a code specifying a the nature of the request or referral using a code taken from a clinical coding scheme approved for use in the realms in which the message is used.

The RequestStatement/responsibleParty class may be used to refer to the person or organisation from whom the service was requested. This class uses the mandatory AgentRef class to reference a role in the role directory containing detailed information about a particular person, organisation or device.

8.4.2 Plans (see Plans)

The PlanStatement class may be used to represent an intention or planned action such as a recall for a particular intervention. An instance of this class should be included in any situation where the record contains an explicit indication of an intention to undertake a follow up activity whether this action is clinical or administrative.

The effectiveTime attribute is used to represent the time when the action is planned to happen.

The participant.time attribute represents the time at which the plan was made.

The code attribute is used to convey a code specifying a the nature of the plan using a code taken from a clinical coding scheme approved for use in the realms in which the message is used.

8.4.3 Registration, associated people and organisations

The RegistrationStatement class is used to convey information on registration information about a registered, formal or informal relationship between the patient and another party. The most common use of this in the EHR Extract message is to indicated the patient's registered GP and GP Practice. However, this statement can also indicate other relationships and affiliations including usual GP, other carers, next of kin, etc.

The effectiveTime represents the interval of time during which the indicated relationship was, is or is expected to be applicable.

The class RegistrationStatement/responsibleParty conveys details of a the type of relationship and the party with whom the relationship exists. This may use a role reference (AgentRef) to refer to a role in the roles directory containing detailed information about a particular person, organisation or device.

8.5 Narrative statements

The Narrative statement (NarrativeStatement) is able to accommodate EHR information which is not semantically processable by a computer system. All the contextual information (e.g. authorship) is conveyed in the Composition that conveys this item so no direct participations are represented in association with this class.

The reason that the information is presented in this form may be:

That it is not semantically processable in the sending system.
That the semantics in the sending system cannot be reliably represented in the message
That the information has been degraded from a semantically processable form to allow receipt by an application that does not support the semantics of the sending system.

The content of the Narrative is placed in the text attribute of the class. Three flavours of the ED data type are valid for use in the text field:

Encapsulated Data Plain Text In practice this is represented as though it were of datatype ST .
Encapsulated Data Text and Line Breaks This form of representation is used to represent fixed font with maintained white space and hard line breaks. It has been included in this specification to meet the need for compatibility with UK NHS PMIP tabular text formats. This type of representation can be included in an HTML rendering by enclosing it in a <pre> element tag.
Encapsulated Data Limited HTML This is in restricted to a subset of XHTML specified in a separate document (Restricted Subset of XHTML).

9 Attachments

9.1 Introduction

Any of the classes within the EhrStatement may be associated with an attachment. These are represented using the EhrStatement/reference relationship and an instance of the ExternalDocument class that contains the attached data. The data may be used to include previously communicated message, word processed document, scanned documents, images or other binary files.

9.2 Methods of attachments

This is done using the URL attribute of the reference child of the ED datatype as described in the datatypes document.

9.2.1 References to external information resources

External information resources should be referenced using the ExternalDocument class, which allows the type of the reference to be classified using an EhrAttachmentCode code, and the URL for the external resource is sent in value property of that class.

9.2.2 Inclusion of attachments in the message

Attachments may be included in the message using the ExternalDocument.text element.

9.3 Formats of attached items

9.3.1 Documents

Documents should be attached in either HTML or PDF format. Proprietary word processor formats should be avoided.

9.3.2 EDI Messages

XML EDI messages should be sent as XML within the message (rather than converted to base64) as the contents of the value property of the ExternalDocument class.

9.3.3 Scanned images

9.3.4 Other attachments

10 Linking statements

10.1 Representing problem orientation

Problem oriented records can be represented using the link set construct to link the problem heading and the records that form part of that problem.. The link set exists within a composition and relates record components that may be part of the same composition or in several different compositions. The type of the link set is represented by the value assigned to the code attribute. For a general description on the use of links set see LinkSet.

The link set owner (LinkSet/conditionNamed) is a reference to the medical record that provides the problem name or title to the link set.

The link set also has a number of "members" (LinkSet/component) that are the entries in the medical record pertaining to that problem. Link set members may be from one or more compositions within the patient record. A link set member may have once been the name of the set but is now a regular member. These records have a fixed value of "NAME" in the typeCode attribute.

Link set members may be ordered by the use of the sequenceNumber attribute. The ordering may be total or partial. A total ordering exists if every relationship in link set has a distinct sequence number. If, some relationships in the link set share the same sequence number these are arbitrarily ordered with respect to one another.

10.2 Representing linkages between plans and observations

A plan may be related to an observation in one of two ways.

An observation leads to a plan for some follow up activity.
An observation may state that a plan has been carried out

Possibly this observation may record the result or outcome of the planned activity rather than the activity itself.

The current messge specification represents these two linkages using the same structure. An EhrStatement/sourceOf class links an instance of ObservationStatement to StatementRef which contains a reference to an instance of PlanStatement.

The typeCode attribute of the PlanStatement indicates whether the plan:

Is the outcome of the ObservationStatement
Is fulfilled by the ObservationStatement

The result of this is that in each case the relationship originates in the context of the observation.

This approach allows most types of current plan relationship to be represented. However, additional flexibility may be required in future extensions of this specification. In particular:

To enable a relationship to be asserted to an observation in the context of an observation (rather than requiring the relationship to point from an observation to a plan).
To enable statements other than observations to relate to a plan.

10.3 Representing linkages between referrals, requests and observations

There is a case for an explicit relationship between referrals and requests and observations. This would allow statements relating to the outcome of a referral or the results of a request to be linked to the request statement. This is not supported in the current message specification but could be readily added using a structure identical to that used for linking plans and observations.

10.4 Representing other types of linkage

The message specification allows the structures of LinkSet to be used for other types of linkage between statements. However, extended uses of the this construct will require additions to the vocabulary value set for this class. Immediate requirements for other groupings of statements can be met by using the code value for "Unspecified Problem" and appending details of the nature of the group using the originalText element of the coded data type.

An alternative approach could be employed to support explicitly typed instances of the ActRelationship class between any two statements. This would be an appropriate way of indicating causation or reasoning associations between statements in the record. However, it can be argued that even in this case a specific Act (e.g. LinkSet or similar) should be used to allow the author and other contextual information about the asserted association to be represented independently from the context of the two related statements.

In the short-term, since current UK GP systems do not handle this type of relationship, a final resolution to this debate has not been proposed.

1 A more abstract consideration leads to recognition of grey areas between the definition use and interpretation of different types of information in a record.

2 These projects and initiatives include MIQUEST, PRIMIS, GPRD, PRODIGY and XMLEPR.

3 The term “free text” is used here to mean text that is freely entered by a human (or by a system protocol) which is not directly derivable from a coded or structured value that is also included in the message. The term “free text” is not restricted to “plain text” but also covers text with layout mark-up (i.e. HTML) or text in an attached word-processed document.

4 Taking account of technological progress the boundaries between these types of data may be further blurred. Thus pattern recognition, speech recognition or optical character recognition may convert digital images or signals into text. Natural language processing may convert free text into a codified semantic form and a concept identifier once assigned a discrete meaning can be seen as no less formally defined than a date or number. This project focuses on communication of records as they are today in GP computer systems in the UK. We take the view that solving the problem of communication of this data so that it can be interpreted and processed safely in a receiving systems to the extent currently possible its originating systems is a sufficiently difficult first goal.

5 If a professionally endorsed standard for this type of natural language encoding is adopted by the NHS then this would be permitted. The important point in these guidelines is to emphasise that the message specification allows attachments without passing judgement on the quality of the content or the suitability for further processing.