Input to object model based on the UK LRA experience

The following is extracted from the document, 'The LRA Technical Model Developer's Design Manual Part 1: Model Design' (Version 0.6.1), describing the LRA's key design patterns for care record content models.  It is posted here as a potential starting point for discussing CIMI's input to potential future AOM versions.  Much of the below is likely already addressed in the current AOM - where this is the case, comments from AOM experts would be welcome.  All are welcome to comment or suggest changes to the below, based on what they feel might be appropriate for CIMI's future AOM.

1      Technical Analysis of Care Record Information Requirements

This section provides guidance on the analysing care record information requirements, according to the following sequence, in order to select and elaborate the most appropriate design choice for representing the requirement. 

• Identifying the type of care record information.
• Understanding and representing temporality requirements.
• Understanding and representing subject of information requirements.
• Understanding and representing uncertainty and negation requirements.

1.1    Care Record Information Types

This section describes the main types of care record information which are represented for the purpose of meaning-based information retrieval using terminologically bound and semantically linkable specialisations of the EN 13606-1:2007 ELEMENT class.  The ELEMENT hierarchy is in turn based on some of the main axes of the SNOMED CT hierarchy.

1.1.1     Finding Observations

Clinical findings are observations about a patient made by a Care Professional, patient, or a carer. They include information provided by the patient or carer, clinical observations, clinical findings on examination, investigation results and administrative findings. They also include findings resulting from formal assessment procedures such as whether a patient has been assessed under a section of the Mental Health Act.

The LRA Care Components model makes a distinction between 'finding observations' and 'property observations'. This distinction is based on whether the finding is recorded as a nominal statement (e.g. 'family history of asthma', 'pain in chest or exertion', 'tender in right iliac fossa') or as a combination of a name and a separate value (e.g. 'systolic blood pressure' = 130 mmHg, 'pulse rate' 65/min).

This distinction affects the information model requirement, as it determines whether there is a need for a separate value field. Thus nominal statements are represented using a FINDING_OBSERVATION_ELEMENT (which does not have a value); while name-value pairs are represented using a PROPERTY_OBSERVATION_ELEMENT (which has a value). This distinction also affects the terminology binding, since the set of SNOMED CT expressions that can be sensibly used to represent a nominal clinical finding is disjoint from the set of expressions that can be used to label values. Many values named by SNOMED CT expressions are best represented using quantities or ordinal scales. However, in other cases, the value itself may also be coded using a SNOMED CT expression and there may be a close resemblance between these information model supported name-value pairs and the attributes in a post-coordinated expression.

This section is concerned only with the use of the FINDING_OBSERVATION_ELEMENT. Therefore, it covers any finding which is often described in the record by a phrase or nominal statement in which there is no discrete boundary between the representation of the act of observation and the result observed. A separate section discusses the use of the PROPERTY_OBSERVATION_ELEMENT.

SNOMED CT contains a hierarchy of 'clinical findings' that fit neatly into this section. However, there are also concepts in the 'event' hierarchy which may be recorded as nominal statements and thus fit within the same logical class (e.g. 'death', 'exposure to toxin'). In the broader scope of the LRA the use of the FINDING_OBSERVATION_ELEMENT may also extend to observations that would not usually be thought of as 'clinical' in nature.

Some types of observation clearly fall into one of these categories. However, there are many borderline cases where there are two different ways that the same information may be recorded. From a general semantic perspective, the distinction is far from clear-cut and there are many cases where comparison of data recorded in these different ways may be highly relevant. This requires an extension to the current SNOMED CT concept model, to more completely capture these equivalences. However, in many cases the comparison depends on knowledge (e.g. normal values determine whether a given systolic blood pressure is equivalent to the nominal statement 'systolic blood pressure normal'). This is outside the scope of the current work but is an area where developments may eventually support more sophisticated querying, provided the methods of recording are consistent.

1.1.1.1    Class Description

The FINDING_OBSERAVATION_ELEMENT class is an OBSERVATION_ELEMENT whose coded meaning is constrained to represent a SNOMED CT finding or event situation.  The focus concept of the finding situation must be subsumed either by 404684003 | clinical finding | or by 272379006 | event |.

FINDING_OBSERVATION_ELEMENT is used to represent both normal and abnormal clinical states found on examination or deduced from clinical reasoning (e.g. 'clear sputum', 'normal breath sounds', 'poor posture', 'diabetes mellitus') and events to which the patient or service user may have been to subject (e.g. 'physical abuse', 'exposure to mercury').

The value attribute is constrained to the null flavor NA | not applicable | so as to prohibit its use within the LRA whilst maintaining conformance to EN 13606-1:2007.

1.1.1.2    Significant Attributes

The class attributes deemed to be of significance to LRA Technical Model design are listed below.

Name	Data type	Multiplicity	Description
synthesised	BL	1..1	This attribute value shall be TRUE if this RECORD_COMPONENT has been created in order to comply with this standard, but this point in the EHR hierarchy has no corresponding node in the EHR from which it was extracted. Within the LRA this attribute is used to indicate a RECORD_COMPONENT instance that has been derived in some way from a pre-existing RECORD_COMPONENT.
meaning	CD.CV.SCT	1..1	A coded representation of the primary semantically processable meaning conveyed by the ELEMENT. Contains a SNOMED CT expression representing the finding situation (i.e. the finding or event and its context).
obs_time	IVL<TS>	0..1	The date and time, or interval, at which the finding observation actually occurred or was true, if different from the session time of the COMPOSITION.
value	ANY	1.1	The value attribute is constrained to the null flavor NA | not applicable | so as to prohibit its use within data capture or meaning based information retrieval.

1.1.1.3    Terminology Binding Constraints

The coded expression maintained by the FINDING_OBSERVATION_ELEMENT meaning attribute must conform to the following default semantic expression constraint:  

243796009 | situation with explicit context | :

{ 246090004 | associated finding | = ( ( < 404684003 | clinical finding | ) OR ( < 272379006 | event | ) ) , 408729009 | finding context | = < 410514004 | finding context value | , 408731000 | temporal context | = < 410510008 | temporal context value | , 408732007 | subject relationship context | = < 125676002 | person | }

To enable the creation of conformant instance expressions for particular finding situations, individual FINDING_OBSERVATION_ELEMENTs restrict further the values of the associated finding (as described section 5.1) and the values of the context attributes.   Individual FINDING_OBSERVATION_ELEMENTs also may add literal expression constraints restrict the literal form of the instance expression. 

A finding situation comprises a clinical finding (e.g. wheeze, fractured tibia, ulcer of foot, etc) and the context of the finding which may be represented either explicitly or implicitly by the instance expression.  When a clinical finding is represented in a patient record, certain assumptions are usually made about what it means in relation to the person who is the subject of that record. Thus, a finding of "wheezing" in a record, it is assumed to mean that the subject of that record was wheezing at the time of examination. However, other contexts alter significantly the meaning of the finding situation.  For example:

• Family history of diabetes mellitus
• History of bronchitis
• No headache
• No family history of diabetes mellitus

An instance expression may state explicitly that the finding is present and occurring currently (i.e. at the time of examination session) and applies to the subject of the record (the patient).  This context is represented explicitly in the normal form by the following attributes and applied to the associated finding by the situation with explicit context:

• finding context
• temporal context
• subject relationship context

Alternatively a contracted form of the instance expression may omit the associated context in which case a 'soft default' context applies that means that the finding is present and occurring currently (or at a stated time in the past) and applies to the subject of the record. 

Unlike instance expressions, semantic expression constraints specified in the intermediate form by the LRA always state explicitly all context constraints. 

Use of these attributes is explained fully in the SNOMED CT Technical Implementation Guide.  [12]  Their specific use within the LRA is detailed in sections 4.2, 4.3 and 4.4 of this document. 

1.1.2     Property Observations

Property observations record the results of measurements, investigation or other observations where there is requirement to separately specify the nature of the observation (e.g. 'systolic blood pressure', 'pulse rate') and its value (e.g. 130 mm[Hg], 65/min).  The expressed value may represent a result or a parameter setting and may either have been measured or asserted.

The LRA Care Components model makes a distinction between 'finding observations' and 'property observations'. This distinction is based on whether the finding is recorded as a nominal statement (e.g. 'family history of asthma', 'pain in chest or exertion', 'tender in right iliac fossa') or as a combination of a name and a separate value (e.g. 'systolic blood pressure' = 130 mmHg, 'pulse rate' 65/min). This distinction affects terminology binding, since the set of SNOMED CT expressions that can be sensibly used to label values are observable entities and measurement procedures rather than clinical findings.

This section is concerned only with the use of the PROPERTY_OBSERVATION_ELEMENT. It covers findings which are specified with a distinct value. A separate section discusses the use of the FINDING_OBSERVATION_ELEMENT to represent nominal statements. This distinction between these types of observations is explained in more detail in the section 4.1.1.

SNOMED CT contains a hierarchy of 'observable entities' that directly address the requirements for property observations. However, the coverage of 'observable entities' is currently incomplete and needs to be complemented by use of concepts from the 'measurement procedures' and 'evaluation procedures' hierarchies. This class therefore also permits evaluation procedures and laboratory procedures to be used as the focus concept as a proxy to represent the observable resulting from the procedure.

The value attribute may be expressed as a quantity (with units), an interval (with units), an ordinal scale or where appropriate by another SNOMED CT expression.

1.1.2.1    Class Description

The PROPERTY_OBSERVATION_ELEMENT class is an OBSERVATION_ELEMENT whose coded meaning is constrained to represent a SNOMED CT observable situation and whose value attribute represents an observed or asserted data value. 

The focus concept of the observable situation must be subsumed either by 363787002 | observable entity | or by 386053000 | evaluation procedure | or 108252007 | laboratory procedure | (for any 'observation' that does not have a corresponding 'observable entity').

PROPERTY_OBSERVATION_ELEMENT is used to represent the results of investigations undertaken to find out more information about a patient's state of health or wellbeing (e.g. 'blood glucose concentration', 'jugular venous pressure', 'Apgar at 10 minutes') and device or procedure related parameter settings (e.g. 'haemodialysis blood flow rate'). 

The value attribute may be assigned a value of any data type other than QSET<TS> or any specialisation of QSET<TS>.   

1.1.2.2    Significant Attributes

The class attributes deemed to be of significance to LRA Technical Model design are listed below.

Name	Data type	Multiplicity	Description
synthesised	BL	1..1	This attribute value shall be TRUE if this RECORD_COMPONENT has been created in order to comply with this standard, but this point in the EHR hierarchy has no corresponding node in the EHR from which it was extracted. Within the LRA this attribute is used to indicate a RECORD_COMPONENT instance that has been derived in some way from a pre-existing RECORD_COMPONENT.
meaning	CD.CV.SCT	1..1	A coded representation of the primary semantically processable meaning conveyed by the ELEMENT. Contains a SNOMED CT expression representing the observable situation (i.e. the property observed and its context).
obs_time	IVL<TS>	0..1	The date and time, or interval, at which the property observation actually occurred or was true, if different from the session time of the COMPOSITION.
value	ANY	1.1	The value of the observed property specified by the meaning code. The attribute may be assigned any data type other than QSET<TS> or any specialisation of QSET<TS>.

Common patterns for Property Observations defined in this document constrain these fields.

1.1.2.3    Terminology Binding Constraints

The coded expression maintained by the PROPERTY_OBSERVATION_ELEMENT meaning attribute must conform to the following default semantic expression constraint:  

243796009 | situation with explicit context | :

{ 246090004 | associated finding | = ( ( < 363787002 | observable entity | ) OR ( < 386053000 | evaluation procedure | ) OR ( < 108252007 | laboratory procedure | ) ) , 408729009 | finding context | = < 410514004 | finding context value | , 408731000 | temporal context | = < 410510008 | temporal context value | , 408732007 | subject relationship context | = < 125676002 | person | }

To enable the creation of conformant instance expressions for particular finding situations, individual PROPERTY_OBSERVATION_ELEMENTs restrict further the values of the associated finding (as described section 5.1) and the values of the context attributes.  Individual PROPERTY_OBSERVATION_ELEMENTs also may add literal expression constraints restrict the literal form of the instance expression.  The constraint permits an evaluation procedure or laboratory procedure to be the focus concept when it is used as a proxy for the observable entity resulting from the procedure.

When a property observation is represented in a patient record, certain assumptions are usually made about what it means in relation to the person who is the subject of that record. Thus, if the finding "systolic blood pressure 120 mm[Hg]" is present in a record, it is assumed to mean that the subject of that record was found to have this. This assumed meaning might be stated in full as "the subject of the record currently has a systolic blood pressure of 120 mm[Hg]".  However, other contexts may alter significantly the meaning of the observable situation.  For example:

• Target blood pressure
• Result of genetic screening applied to a family member.
• Result of infectious disease testing applied to a partner or other contact

As with clinical findings (section 4.1.1.3), instance expressions may represent the finding context, temporal context and subject relationship context explicitly or implicitly in which case the soft default applies.  The contracted form that omits explicit reference to the context attributes is more usual in written records.  Semantic expression constraints specified in the intermediate form by the LRA always state explicitly all context constraints.  The use of context attributes is explained fully in the SNOMED CT Technical Implementation Guide.  [12]  Their specific use within the LRA is detailed in sections 4.2, 4.3 and 4.4 of this document. 

The value attribute also may specify a SNOMED CT coded expression in which case it must conform to the following constraint:  

( << 281296001 | result comments | ) OR ( << 260245000 | findings values | )

However, caution must be exercised before choosing this pattern of representation by applying the following test(s). 

• If a requirement for the representation of an observation can be satisfied only by a BOUND_DATA_ELEMENT with a meaning attribute that specifies an observable situation and a value attribute whose value is not a SNOMED CT coded expression then a PROPERTY_OBSERVATION_ELEMENT must be used. 
• Otherwise, if a requirement for the representation of an observation can be satisfied either by a BOUND_DATA_ELEMENT with a meaning attribute that specifies an observable situation and a value attribute whose value is a SNOMED CT coded expression (conforming to the above constraint) or by a BOUND_DATA_ELEMENT with a meaning attribute that specifies a finding situation then a FINDING_OBSERVATION_ELEMENT must be used.

Where a care record information requirement can in theory be satisfied either by PROPERTY_OBSERVATION_ELEMENT with a value containing a SNOMED CT coded expression or by a FINDING_OBSERVATION_ELEMENT, the second approach is designed to favour the latter so that representations are not arbitrarily divided into a 'question' (meaning) and an 'answer' (value).  This increases the likelihood of generating comparable data from multiple sources.  Weighing against this is the observation that requirements (and thus requirement owner expectations) often favour a 'question / answer' framing – in particular this is the case for requirements based on established assessment exercises.  To address this expectation gap subsequent SNOMED CT and LRA releases are expected to include mechanisms for:

1. detecting logical equivalence between findings represented using FINDING_OBSERVATION_ELEMENT and findings represented using PROPERTY_OBSERVATION_ELEMENT, and / or
2. allowing the association of FINDING_OBSERVATION_ELEMENTs and (semantically inert) SNOMED CT observable situation concepts.

1.1.3     General Activities

Activities or procedures are described in the NHS Care Record Elements document (v3) as follows:

Therapeutic, preventative, investigative, informative, curative or palliative actions or interventions delivered to or acted upon a person to determine, support, clarify or effect change upon, their health status.

Within the LRA, any activity not intended to result in an observation and not associated with the supply or administration of a material is represented using GENERAL_ACTIVITY_ELEMENT.  Such activities include:

• Treatments: procedures that are intended to have a therapeutic, preventative, curative or palliative effect; includes invasive, non-invasive, psychosocial and cognitive treatments.
• Provision of advice and information to patients and carers: the activity of providing advice and information about a patient's health or social care, to the patient or to their specified carer.  
• Administrative Procedures: procedures, typically of a clerical nature, that support the investigation and/or treatment of a patient.

1.1.3.1    Class Description

The GENERAL_ACTIVITY_ELEMENT class is an ACTIVITY_ELEMENT whose coded meaning is constrained to represent any procedure situation not represented by one of the other non-abstract specialisations of ACTIVITY_ELEMENT.

The inherited value attribute is constrained to the null flavor NA | not applicable | so as to prohibit its use within the LRA whilst maintaining conformance to EN 13606-1:2007.

1.1.3.2    Significant Attributes

The class attributes deemed to be of significance to LRA Technical Model design are listed below.

Name	Data type	Multiplicity	Description
synthesised	BL	1..1	This attribute value shall be TRUE if this RECORD_COMPONENT has been created in order to comply with this standard, but this point in the EHR hierarchy has no corresponding node in the EHR from which it was extracted. Within the LRA this attribute is used to indicate a RECORD_COMPONENT instance that has been derived in some way from a pre-existing RECORD_COMPONENT.
meaning	CD.CV.SCT	1..1	A coded representation of the primary semantically processable meaning conveyed by the ELEMENT. Contains a SNOMED CT expression representing the nature of the procedure situation (i.e. the procedure and its context).
obs_time	IVL<TS>	0..1	The date and time, or interval, at which the activity described was undertaken or was true, if different from the session time of the COMPOSITION.
value	ANY	1.1	The value attribute is constrained to the null flavor NA | not applicable | so as to prohibit its use within data capture or meaning based information retrieval.

1.1.3.3    Terminology Binding Constraints

The coded expression maintained by the GENERAL_ACTIVITY_ELEMENT meaning attribute must conform to the following default semantic expression constraint:  

243796009 | situation with explicit context | :

{ 363589002 | associated procedure | = ( ( < 71388002 | procedure | ) AND ( ! < 386053000 | evaluation procedure | ) AND ( ! < 108252007 | laboratory procedure | ) AND ( ! < 432102000 | administration of substance | ) AND ( ! < 433590000 | administration of substance via specific route | ) AND ( ! < 33633005 | prescription of drug | ) AND ( ! < 75658007 | prescription of therapeutic agent | ) AND ( ! < 103742009 | renewal of prescription | ) AND ( ! < 243704004 | provision of appliances | ) AND ( ! < 183253002 | provision of medical equipment | ) AND ( ! < 404919001 | wheat-free diet | ) AND ( ! < 223456000 | provision of a special diet | ) AND ( ! < 440298008 | dispensing of pharmaceutical/biologic product | ) ) , 408730004 | procedure context | = < 288532009 | context values for actions | , 408731000 | temporal context | = < 410510008 | temporal context value | , 408732007 | subject relationship context | = < 125676002 | person | }

To enable the creation of conformant instance expressions for particular finding situations, individual GENERAL_ACTIVITY_ELEMENTs restrict further the values of the associated finding (as described section 5.1) and the values of the context attributes.  Individual GENERAL_ACTIVITY_ELEMENTs also may add literal expression constraints to enable the creation of conformant instance expressions representing particular finding situations.

When a procedure is mentioned in a patient record, assumptions are made about what it means in relation to the subject of that record. Thus, in the absence of other information, the mention of the procedure "cholecystectomy" may be assumed to mean that "the subject of the record had a cholecystectomy at a stated time".  Use of other contexts changes significantly the meaning of the procedure situation.  For example:

• Hip replacement planned
• History of vasectomy
• Nutritional assessment completed
• Appendectomy not done

The default context for a procedure means that the procedure was completed, was performed on the subject of record (the patient or service user), and was done in the present time or at a stated past time.  This is implied by all procedure instance expressions in which the context is omitted.  The context is represented explicitly in normal form instance expressions and in all semantic expression constraints by applying the following attributes to the associated procedure using the situation with explicit context wrapper:

• procedure context
• temporal context
• subject relationship context

Use of these attributes is explained fully in the SNOMED CT Technical Implementation Guide.  [12]  Their specific use within the LRA is detailed in sections 4.2, 4.3 and 4.4 of this document. 

1.1.4     Investigation Activities

Investigation activities are procedures that are undertaken with the primary aim of finding out more information about a patient or service user's state of health or wellbeing and which therefore result (or are intended to result) in one or more observations. Investigations include invasive, non-invasive, psychosocial and cognitive investigation procedures.

Within the LRA, activities intended to result in an observation are represented using the INVESTIGATION_ACTIVITY_ELEMENT.

1.1.4.1    Class Description

The INVESITIGATION_ACTIVITY_ELEMENT class is an ACTIVITY_ELEMENT whose coded meaning is constrained to represent a SNOMED CT procedure situation that resulted in (or is intended to result) in one or more observations (of type OBSERVATION_ELEMENT).  The focus concept of the observable situation must be subsumed either by 386053000 | evaluation procedure | or 108252007 | laboratory procedure | or by 363787002 | observable entity | (for any evaluation activity that does not have a corresponding 'evaluation procedure').

The value attribute is constrained to the null flavor NA | not applicable | so as to prohibit its use within the LRA whilst maintaining conformance to EN 13606-1:2007.

1.1.4.2    Significant Attributes

The class attributes deemed to be of significance to LRA Technical Model design are listed below.

Name	Data type	Multiplicity	Description
synthesised	BL	1..1	This attribute value shall be TRUE if this RECORD_COMPONENT has been created in order to comply with this standard, but this point in the EHR hierarchy has no corresponding node in the EHR from which it was extracted. Within the LRA this attribute is used to indicate a RECORD_COMPONENT instance that has been derived in some way from a pre-existing RECORD_COMPONENT.
meaning	CD.CV.SCT	1..1	A coded representation of the primary semantically processable meaning conveyed by the ELEMENT. Contains a SNOMED CT expression representing the nature of the procedure situation (i.e. the procedure and its context).
obs_time	IVL<TS>	0..1	The date and time, or interval, at which the activity described was undertaken or was true, if different from the session time of the COMPOSITION.
value	ANY	1.1	The value attribute is constrained to the null flavor NA | not applicable | so as to prohibit its use within data capture or meaning based information retrieval.

1.1.4.3    Terminology Binding Constraints

The coded expression maintained by the INVESTIGATION_ACTIVITY_ELEMENT meaning attribute must conform to the following default semantic expression constraint:  

243796009 | situation with explicit context | :

{ 363589002 | associated procedure | = ( ( < 386053000 | evaluation procedure | ) OR ( < 108252007 | laboratory procedure | ) OR ( < 363787002 | observable entity | ) ) , 408730004 | procedure context | = < 288532009 | context values for actions | , 408731000 | temporal context | = < 410510008 | temporal context value | , 408732007 | subject relationship context | = < 125676002 | person | }

To enable the creation of conformant instance expressions for particular finding situations, individual INVESTIGATION_ACTIVITY_ELEMENTs restrict further the values of the associated finding (as described section 5.1) and the values of the context attributes.  Individual INVESTIGATION_ACTIVITY_ELEMENTs also may add literal expression constraints to enable the creation of conformant instance expressions representing particular finding situations.  The constraint permits an observable entity to be the focus concept when it used as a proxy for the procedure used to observe that entity.

The context may be omitted from instance expressions (in which case the default applies) or it may be explicitly stated using the appropriate context attributes as described in section 4.1.3.3.  All semantic expression constraints must specify explicitly the permitted contexts.

1.1.5     Material Activities

Within the LRA materials activities are those activities associated with the supply or administration of materials (represented by instances of MATERIAL_ENTITY_ELEMENT).  This applies to all procedures that involve or require reference to specific substances or device and includes the management of aids, appliances, orthoses and prostheses, as well as medications.

Material activities are represented using the MATERIAL_ACTIVITY_ELEMENT.

1.1.5.1    Class Description

The MATERIAL_ACTIVITY_ELEMENT class is an ACTIVITY_ELEMENT whose coded meaning is constrained to represent a SNOMED CT procedure situation involving the administration of a product or substance or the provision of a material entity to a subject.  Instances of material entity (including products and substances) are represented by the MATERIAL_ENTITY_ELEMENT.

The value attribute is constrained to the null flavor NA | not applicable | so as to prohibit its use within the LRA whilst maintaining conformance to EN 13606-1:2007.

1.1.5.2    Significant Attributes

The class attributes deemed to be of significance to LRA Technical Model design are listed below.

Name	Data type	Multiplicity	Description
synthesised	BL	1..1	This attribute value shall be TRUE if this RECORD_COMPONENT has been created in order to comply with this standard, but this point in the EHR hierarchy has no corresponding node in the EHR from which it was extracted. Within the LRA this attribute is used to indicate a RECORD_COMPONENT instance that has been derived in some way from a pre-existing RECORD_COMPONENT.
meaning	CD.CV.SCT	1..1	A coded representation of the primary semantically processable meaning conveyed by the ELEMENT. Contains a SNOMED CT expression representing the nature of the supply or administration procedure situation (i.e. the supply or administration procedure and its context).
obs_time	IVL<TS>	0..1	The date and time, or interval, at which the supply or administration activity described was undertaken or was true, if different from the session time of the COMPOSITION.
value	ANY	1.1	The value attribute is constrained to the null flavor NA | not applicable | so as to prohibit its use within data capture or meaning based information retrieval.

1.1.5.3    Terminology Binding Constraints

The coded expression maintained by the MATERIAL_ACTIVITY_ELEMENT meaning attribute must conform to the following default semantic expression constraint:  

243796009 | situation with explicit context | :

{ 363589002 | associated procedure | = ( ( 432102000 | administration of substance | ) OR ( 433590000 | administration of substance via specific route | ) OR ( 33633005 | prescription of drug | ) OR ( 75658007 | prescription of therapeutic agent | ) OR ( 103742009 | renewal of prescription | ) OR ( 243704004 | provision of appliances | ) OR ( 183253002 | provision of medical equipment | ) OR ( << 404919001 | wheat-free diet | ) OR ( << 223456000 | provision of a special diet | ) OR ( 440298008 | dispensing of pharmaceutical/biologic product | ) ) , 408730004 | procedure context | = < 288532009 | context values for actions | , 408731000 | temporal context | = < 410510008 | temporal context value | , 408732007 | subject relationship context | = < 125676002 | person | }

To enable the creation of conformant instance expressions for particular finding situations, individual INVESTIGATION_ACTIVITY_ELEMENTs restrict further the values of the associated finding (as described section 5.1) and the values of the context attributes.  Individual MATERIAL_ACTIVITY_ELEMENTs also may add literal expression constraints to enable the creation of conformant instance expressions representing particular finding situations.

The context may be omitted from instance expressions (in which case the default applies) or it may be explicitly stated using the appropriate context attributes as described in section 4.1.3.3.  All semantic expression constraints must specify explicitly the permitted contexts.

An administration of substance via specific route focus concept can be refined by the application of an additional concept model attribute, route of administration, as discussed in section 5.1.2.4.

1.1.6     Material Entities

Material entities are defined as physical entities acting in the capacity of passive recipients of actions performed by other physical entities acting in the capacity of active subjects.  Such actions include extraction, manufacture, supply, distribution, administration, use, investigation, disposal, etc. 

Material entities are represented using the MATERIAL_ENTITY_ELEMENT.  Physical entities acting (typically with some degree of autonomy) in the capacity of active subjects are represented as specialised instances of class IDENTIFIED_ENTITY (see section 4.1.11).  A physical entity may therefore be represented using either class depending on the capacity in which it acts.  Note that although patients or service users act as recipients of care activities, their participation is not passive (and usually requires consent) and as such they are also represented using specialised instances of IDENTIFIED_ENTITY.

1.1.6.1    Class Description

The MATERIAL_ENTITY_ELEMENT class is a BOUND_DATA_ELEMENT whose coded meaning is constrained to represent a physical entity (i.e. an independent physical continuant) that that is either a: 

• therapeutic pharmaceutical or biologic product; 
• substance of relevance to health and social care, including active ingredients of drugs and medicaments, biological and dietary substances and allergens;
• specimen; or
• device, e.g. durable equipment, implantable devices, disposable supplies, etc. 

The value attribute is redefined to represent the amount of the material entity present within a mixture or compound regardless of any amount administered or supplied.

1.1.6.2    Significant Attributes

The class attributes deemed to be of significance to LRA Technical Model design are listed below.

Name	Data type	Multiplicity	Description
synthesised	BL	1..1	This attribute value shall be TRUE if this RECORD_COMPONENT has been created in order to comply with this standard, but this point in the EHR hierarchy has no corresponding node in the EHR from which it was extracted. Within the LRA this attribute is used to indicate a RECORD_COMPONENT instance that has been derived in some way from a pre-existing RECORD_COMPONENT.
meaning	CD.CV.SCT	1..1	A coded representation of the primary semantically processable meaning conveyed by the ELEMENT. Contains a SNOMED CT expression representing the nature of the physical entity.
value	QTY	0..1	The amount of the material entity present within a mixture or compound regardless of the amount involved in any associated activity.

1.1.6.3    Terminology Binding Constraints

The coded expression maintained by the MATERIAL_ENTITY_ELEMENT meaning attribute must conform to the following default semantic expression constraint:  

( ( << 373873005 | pharmaceutical / biologic product | )

OR ( << 49062001 | device | )

OR ( << 123038009 | specimen | )

OR ( << 105590001 | substance | )

OR ( << 276339004 | environment | )

)

The code 373873005 | pharmaceutical / biologic product | subsumes the UK drug extension concepts (dm+d). 

1.1.7     Record Artefacts

A record artefact is a virtual construct which is used to organise or label the content of a care record so as to aid navigation, viewing and readability without affecting the meaning of the content.  Record artefacts, which are represented using the RECORD_ARTEFACT_ELEMENT, may be linked to aid navigation. However, in the case of electronic records, the same content may appear under multiple headings.

From the perspective of meaning based retrieval, the fact that an item of clinical content, such as 'asthma' is associated with a particular record artefact, such as an artefact representing a record heading of 'Family History' has no significance.  A finding of 'Family history of asthma' may only be deduced from the value of the meaning attribute of the FINDING_OBSERVATION_ELEMENT and not from any 'meaning' that might be implied by the record artefact.

Record artefacts, nevertheless, add value in enabling a human reader to easily locate a finding of say 'Family history of asthma' listed under a 'Family History' heading within a record or report.  The heading can also be used to signify to the reader that the explicit meaning of the information differs from say another entry listed under 'Past History'.

Uses of the record artefacts include:

• Labelling different clinical findings to indicate their roles in a particular encounter or episode of care (e.g. 'primary diagnosis', 'secondary diagnosis', etc).
• Naming particular sections of a procedure note or clinical assessment to organise the information for input or review (e.g. 'history of present complaint', 'review of systems', etc).
• Specifying record nodes that represent problems or issues to which collections or relevant entries can be attached.

Record artefact labels can be relevant to retrieval and reuse for particular purposes. For example, when composing a discharge summary or extracting activity statistics from a record it is important to distinguish between the 'primary diagnosis' and 'secondary diagnoses'. However, these labels do not alter the nature or veracity of the finding. Thus a patient with 'Type 1 diabetes mellitus', has the same condition whether it is recorded as the 'Primary diagnosis' or 'Secondary diagnosis'. The only difference is whether this is the main reason for the current episode of care.  

Record artefact labels and their targets are linked using COMPONENT_RELATIONSHIP_ELEMENT instances. 

1.1.7.1    Class Description

The RECORD_ARTEFACT_ELEMENT class is a BOUND_DATA_ELEMENT whose coded meaning is constrained to represent the name of a SNOMED CT record artefact type. The focus concept must be subsumed by 419891008 | record artifact |.  Instances of RECORD_ARTEFACT_ELEMENT are used to organise or label other ELEMENTs so as to aid navigation, viewing and readability but are not permitted to affect the meaning of the content. 

Examples of RECORD_ARTEFACT_ELEMENT include 'Problems' and 'Primary diagnosis.

The value attribute is constrained to the null flavor NA | not applicable | so as to prohibit its use within the LRA whilst maintaining conformance to EN 13606-1:2007.

1.1.7.2    Significant Attributes

The class attributes deemed to be of significance to LRA Technical Model design are listed below.

Name	Data type	Multiplicity	Description
synthesised	BL	1..1	This attribute value shall be TRUE if this RECORD_COMPONENT has been created in order to comply with this standard, but this point in the EHR hierarchy has no corresponding node in the EHR from which it was extracted. Within the LRA this attribute is used to indicate a RECORD_COMPONENT instance that has been derived in some way from a pre-existing RECORD_COMPONENT.
meaning	CD.CV.SCT	1..1	A coded representation of the primary semantically processable meaning conveyed by the ELEMENT. Contains a SNOMED CT expression representing the type of record artefact.
value	ANY	1..1	The value attribute is constrained to the null flavor NA | not applicable | so as to prohibit its use within data capture or meaning based information retrieval.

1.1.7.3    Terminology Binding Constraints

The coded expression maintained by the RECORD_ARTEFACT_ELEMENT meaning attribute must conform to the following default semantic expression constraint:  

< 419891008 | record artefact |

1.1.8     Semantic Links

Semantic links represent asserted binary relationships between RECORD_COMPONENT instances. For example, a semantic link can be used to indicate that a particular instance of a one finding is believed to have been caused by a specific disorder or action. They can also represent the reason for a particular action.

Semantic links are represented using the COMPONENT_RELATIONSHIP_ELEMENT.  This is a composite structure containing two LINK instances, one to reference the subject of the relationship and the other to reference the object.  The relationship type is maintained by the meaning attribute.  The SNOMED CT link assertion hierarchy (< 416698001 | link assertion |) defines a number of appropriate concepts and work is currently in progress to investigate the requirement for any additional concepts that the LRA might require.  Appendix B of the Care Component Specification [] lists a set of candidate concepts which following further development to ensure semantic consistency will be proposed for inclusion in the International Edition of SNOMED CT or its UK Extensions.  In the intervening time the COMPONENT_RELATIONSHIP_ELEMENT meaning attribute is bound to a value set containing those concepts subsumed by the link assertion hierarchy plus a limited set of (currently) non-SNOMED CT concepts defined in section 6.2 of this document. 

1.1.8.1    Class Description

The COMPONENT_RELATIONSHIP_ELEMENT class is an ELEMENT whose coded meaning is constrained to represent an asserted relationship between two other RECORD_COMPONENTs.  The association role links collection is therefore constrained to two member LINKs, one of which references the subject RECORD_COMPONENT and the other the object.

Because the COMPONENT_RELATIONSHIP_ELEMENT is a RECORD_COMPONENT in its own right, it can be asserted, revised or maintained separately from both the related RECORD_COMPONENTs.

1.1.8.2    Significant Attributes

The class attributes deemed to be of significance to LRA Technical Model design are listed below.

Name	Data type	Multiplicity	Description
meaning	CD.CV.SCT	1..1	A coded representation of the primary semantically processable meaning conveyed by the ELEMENT. Contains a SNOMED CT expression representing the type of relationship between the subject and object COMPONENT_RELATIONSHIP_ELEMENT.
obs_time	IVL<TS>	0..1	The date and time, or interval, at which the relationship was asserted, if different from the session time of the COMPOSITION.
value	ANY	1..1	The value attribute is constrained to the null flavor NA | not applicable | so as to prohibit its use within data capture or meaning based information retrieval.
links-> foreach(role.code = LraRoleCode. SUBJECT).target	II	1..1	Reference to the RECORD_COMPONENT that is the subject of the relationship.
links-> foreach(role.code = LraRoleCode. OBJECT).target	II	1..1	Reference to the RECORD_COMPONENT that is the object of the relationship.

1.1.8.3    Terminology Binding Constraints

The coded expression maintained by the COMPONENT_RELATIONSHIP_ELEMENT meaning attribute must conform to the following default semantic expression constraint:  

< 416698001 | link assertion |

1.1.9     Unbound Data

Unbound data is any data not described using a SNOMED CT coded concept or expression.  This includes text, images, multi-media and terms and expressions codified using systems other than SNOMED CT (e.g. ICD-10, OPCS, etc).  The LRA also specifies a controlled set of unbound domain model elements which are not specified directly by the underlying Reference Model and whose semantics are outside the scope of terminological representation using SNOMED CT.  These elements which include Text, InterpretationRange and FutureEventTime behave in effect as reusable domain model attributes.

1.1.9.1    Class Description

The UNBOUND_DATA_ELEMENT class is an ELEMENT whose data value is not described by (i.e. bound to) a SNOMED CT coded concept or expression.  The value attribute supports any type of content including text (plain or with mark up) or binary data intended to be presented for human viewing or some other form of interpretation.  Also it supports terms and expressions codified using systems other than SNOMED CT.

It is important to note that the data content of an UNBOUND_DATA_ELEMENT is not necessarily unstructured (i.e. not machine processable).  It may be processable by dedicated text (e.g. NLP), media or other data processing software that understands the content structure. Furthermore such processing may result in the output of assertions that can be expressed using one or more specialised instances of BOUND_DATA_ELEMENT and therefore amenable to meaning-based retrieval.  However, from the perspective of meaning-based retrieval within the record, the content of the originating UNBOUND_DATA_ELEMENT is semantically opaque.

1.1.9.2    Significant Attributes

Name	Data type	Multiplicity	Description
synthesised	BL	1..1	This attribute value shall be TRUE if this RECORD_COMPONENT has been created in order to comply with this standard, but this point in the EHR hierarchy has no corresponding node in the EHR from which it was extracted. Within the LRA this attribute is used to indicate a RECORD_COMPONENT instance that has been derived in some way from a pre-existing RECORD_COMPONENT.
obs_time	IVL<TS>	0..1	The date and time, or interval, at which the relationship was asserted, if different from the session time of the COMPOSITION.
value	ANY	1..1	The data value of the element.

1.1.10  Entries

An entry, as defined by EN 13606-1:2007, represents:

The information recorded in an EHR as a result of one clinical action, one observation, one clinical interpretation, or an intention.  This is also known as a clinical statement.

Examples of an entry include a symptom, an observation, one test result, a prescribed drug, an allergy reaction, a diagnosis, a differential diagnosis, a differential white cell count and a blood pressure measurement.

Entries are represented using the EN 13606-1:2007 defined ENTRY class.  Within the LRA, ENTRYs define reusable sets of ELEMENTs and are contained directly by COMPOSITIONs. 

1.1.10.1 Class Description

The ENTRY class contains (as ITEMs) the information acquired and recorded for a single observation or observation-set (battery or time series), a single clinical statement such as a portion of the patient's history or an inference or assertion, or a single action that is intended or has actually been performed. An ENTRY may have zero ITEMs if it is a revision of an ENTRY previously recorded in error.

By implication of the Reference Model, each and every ELEMENT instance within an ENTRY must share the same information provider (i.e. source of information) and refer to the same subject of information.

The items collection of the ENTRY class is constrained for use by the LRA to contain member instances of type ELEMENT only.

1.1.11  Participating Roles

The individuals, organisations and devices that actively participate in health and social care activities do so via the designated roles they play.  For example, a person entity instance may be designated and play the role of a care professional in one part of a subject of care's record and yet be designated and play the role of a third party in another part.  Where necessary, roles provide the means by which participating entities can be identified. 

Roles are represented using predefined specialisations of the abstract IDENTIFIED_ENTITY class defined by EN 13606-1:2007.  Individuals and organisations are always represented by the roles they play.  Physical or software devices acting in the capacity of active subjects also are represented as specialised instances IDENTIFIED_ENTITY.  Physical entities acting in the capacity of passive recipients of actions performed active subjects are represented using the MATERIAL_ENTITY_ELEMENT (see section 4.1.6). 

1.1.11.1 Class Description

Any Identified Party, which may be an Organisation, Person, or Device or Software.

1.1.12  Compositions

A composition, as defined by EN 13606-1:2007, represents:

The set of information committed to one EHR by one agent, as a result of a single clinical encounter or record documentation session.

Examples of compositions include progress notes, laboratory test result forms, radiology reports, referral letters, clinic visits, clinic letters, discharge summaries, functional health assessments and diabetes reviews.

Compositions are represented using the EN 13606-1:2007 defined COMPOSITION class.

1.1.12.1 Class Description

A COMPOSITION represents the set of RECORD_COMPONENTs composed (authored) during one clinical encounter or documentation session, and committed within one EHR.

The COMPOSITION is constrained for use within the LRA to comprise a set of ENTRY instances each of which contains one or more ELEMENTs.

From the perspective of meaning based information retrieval the most significant attribute is the session_time.  As well as recording explicitly the date and time or interval during which the clinical encounter or documentation session occurred, the session_time indicates the date and time, or interval, at which the recorded activity occurred or was true unless specified explicitly by the ELEMENT obs_time. If stated, the obs_time may be less precise (e.g. the year in which a past illness occurred) and may refer to a period of time or to a point in time.

1.1.12.2 Significant Attributes

The class attributes deemed to be of significance to LRA Technical Model design are listed below.

Name	Data type	Multiplicity	Description
synthesised	BL	1..1	This attribute value shall be TRUE if this RECORD_COMPONENT has been created in order to comply with this standard, but this point in the EHR hierarchy has no corresponding node in the EHR from which it was extracted. Within the LRA this attribute is used to indicate a RECORD_COMPONENT instance that has been derived in some way from a pre-existing RECORD_COMPONENT.
session_time	IVL<TS>	0..1	The date and time or interval during which the clinical encounter or documentation session occurred.

1.2    Representing Temporality

A recorded observation or activity may be a contemporary record of an event (i.e. one that was created during or shortly after the event); or it may be a retrospective record of an event that occurred at some time in the past; or it may be a record of some prospect that it is anticipated may occur at some time in the future.  Similarly the time at which the event occurred or is anticipated to occur may be known (and specified with a given level of precision) or unknown.  This temporality of the information therefore needs to capture and express:

• the time of the session during which the information was recorded;
• the time of the event, if known, or otherwise indicate that it is unknown;
• whether the information is contemporary or retrospective or whether it asserts some anticipated event; and
• the period of validity of a prospect (such as a plan or goal) or entity.

The temporality and the context of the finding or procedure represented by the observation or action also must align.

The attributes used to represent the temporality of care record information are:

• COMPOSITION session_time and ELEMENT obs_time (which together can be used to infer the event time): 
• the temporal context and finding or procedure context of the meaning attribute value for representing contemporary and retrospective information;
• finding or procedure context and the UNBOUND_DATA_ELEMENT FutureEventTime for representing prospective events; and
• UNBOUND_DATA_ELEMENT ValidPeriod for representing the period of validity of a prospect or entity

1.2.1     Session Time

The session_time of the containing COMPOSITION represents the date and time or interval during which the clinical encounter or documentation session occurred.  It also records the time during which the information represented by each ELEMENT within a COMPOSITION occurred or was true unless stated explicitly by the obs_time.

1.2.2     Event Time

The date and time of an event is stated using the COMPOSITION session_time or the obs_time.  The obs_time records date and time or interval at which the event represented by the ELEMENT actually occurred or was true when different from the session time.  By implication, therefore, the time of the event is taken to be the session_time unless specified otherwise by the obs_time and the obs_time is stated only if its value differs from the session time.  If stated, the obs_time may be less precise than the session_time especially for events that occurred in the past, e.g. the year in which a past illness occurred.  The obs_time may also be stated explicitly to indicate the precise time of each of a number of observations or activities within an extended encounter.  The rule for determining the time of an event that is not part of a battery (see section 4.2.2.2) is specified by the following OCL definition constraint:

context ELEMENT

def: let eventTime() : IVL<TS> =

-- if self.obs_time not is stated

if self.obs_time.oclIsUndefined() then

self.composition.session_time

else

-- if obs_time is stated with null flavor (e.g. UNK | unknown |)

-- this selection is included to highlight the return of an unknown obs_time

if self.obs_time.isNull() then

let unknown: IVL<TS> = self obs_time

else

self.obs_time

endif

endif

1.2.2.1    Event Time Unknown

To indicate that the event time is unknown the obs_time is stated with a null flavor UNK | unknown |.   This indicates that there exists an obs_time which although unknown is nevertheless distinct from the session_time. 

1.2.2.2    Derived Event Times

For batteries in which a property observation serves as a grouper (e.g. blood pressure) for a number of property observation parts (e.g. systolic pressure and diastolic pressure) and all of the parts have a common event time then each part must be stated with an obs_time of null flavor DER | derived |.  This indicates that the event time of each part is derivable, i.e. either from the COMPOSITION session_time or, if stated, from the obs_time of the property observation representing the battery. 

1.2.2.3    Event Times Specified by Observable Entities

LRA ELEMENT models do not represent explicitly SNOMED CT concepts that specify the times of past or current events, such as 248986005 | estimated date of conception (observable entity) |.  Instead the event, such as 13693004 | conception (observable entity) |, is itself is represented and the event time specified as described in this section.

1.2.3     Representing Contemporary and Retrospective Information

The temporal context of the meaning attribute value is used to indicate whether a recorded observation or activity is a contemporary record of an event occurring at the time of the session and which was therefore considered to be current at the session_time; or whether it is a retrospective record of an event that occurred at some time in the past.  The primary use of this attribute, is to indicate that an entry contains retrospective information (e.g. past history), without specifying an actual date of an occurrence. [8] The default constraint for the temporal context is:

408731000 | temporal context | = < 410510008 | temporal context value |

The permissible value is restricted further depending upon whether the information represents a contemporary or retrospective record of the event as described in the following sections. 

For contemporary and retrospective observations the finding context of the meaning attribute is used to indicate whether the associated clinical finding is known or unknown and if known whether it is present or absent as defined by the following constraint:

408729009 | finding context | = ( (< 36692007 | known | ) OR (<< 261665006 | unknown | ) )

For activities the procedure context of the meaning attribute is used to indicate the degree of completion, or status of the associated procedure.  Activities that have actually occurred or are in the process of occurring (versus being planned or cancelled) are indicated using an appropriate subtype of post-starting action status as defined by the following constraint:

408730004 | procedure context | = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) OR (<< 410537005 | action status unknown | ) )

1.2.3.1    Representing Contemporary Information

Contemporary information is indicated by a temporal context value that conforms to the following constraint:

408731000 | temporal context | = ( ( << 410512000 | current or specified | ) AND ( ! < 410513005 | past | ) )

The permissible value is restricted further depending upon whether the time of the event is known or unknown. 

The finding or procedure context must conform to the constraint specified above.

1.2.3.1.1     Contemporary Information with Known Event Time

For contemporary information that includes the date and time, or interval, at which the event occurred (i.e. either implicitly by specifying the session_time and omitting the obs_time or explicitly by specifying a value for the obs_time) the constraint is restricted to exclude values that imply current unspecified or past specified times only:  

408731000 | temporal context | = ( ( << 410512000 | current or specified | ) AND ( ! < 410585006 | current – unspecified | ) AND  ( ! < 410587003 | past - specified | ) )

1.2.3.1.2     Contemporary Information with Unknown Event Time

If the date and time or interval of the event is unknown and therefore specified by obs_time with a null flavor UNK | unknown |, the temporal context value must conform to the following constraint which excludes those temporal context values that imply a specified time only:

408731000 | temporal context | = ( (<< 410512000 | current or specified | ) AND ( ! < 410586007 | specified time | ) )

1.2.3.2    Representing Retrospective Information

Retrospective information is indicated by a temporal context value that conforms to the following constraint:

408731000 | temporal context | = ( (<< 410511007 | current or past | ) AND ( ! < 15240007 | current | ) )

The permissible value is restricted further depending upon whether the time of the event is known or unknown or if a negative past history is being recorded.

For activities that have occurred (or not occurred) in the past the value of the procedure context is further constrained to exclude the concept in progress and its subtypes: 

408730004 | procedure context | = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) OR (<< 410537005 | action status unknown | ) AND (! < 385651009 | in progress | ) )

1.2.3.2.1     Retrospective Information with Known Event Time

Retrospective information that includes the date and time, or interval, at which the event is reported to have occurred (i.e. either implicitly by specifying the session_time and omitting the obs_time or explicitly by specifying a value for the obs_time) is represented by a temporal context that conforms to the following constraint that excludes temporal context values that imply a past unspecified time only:  

408731000 | temporal context | = ( (<< 410511007 | current or past | ) AND ( ! < 410588008 | past - unspecified | ) AND ( ! < 15240007 | current | )  )

The finding or procedure context must conform to the constraint specified above.

1.2.3.2.2     Retrospective Information with Unknown Event Time

If the date and time or interval of the past event is unknown and therefore specified by obs_time with a null flavor UNK | unknown |, the temporal context value must conform to the following constraint which excludes those temporal context values that imply a past - specified time only:

408731000 | temporal context | = ( (<< 410511007 | current or past | ) AND ( ! < 410512000 | current or specified | ) )

The finding or procedure context must conform to the constraint specified above.

1.2.3.2.3     Retrospective Information Representing Negative Past History

For observation instances representing negative past history

• the obs_time must be stated with null flavor UNK | unknown |; 
• the temporal context value must conform to

408731000 | temporal context | = ( (<< 410589000 | all times past | ) ); and

• for observations the finding context value must conform to

408729009 | finding context | = ( (<< 410516002 | known absent | ) OR (= < 428263003 | NOT suspected | ) ); or

• for activities the procedure context value must conform to

408730004 | procedure context | = ( (<< 385660001 | not done | ) )

Note that the finding or procedure context should not be constrained at design time to permit only a negative past history, however, if expressed by an instance the above constraints apply.  Furthermore, any instance conforming to the above constraints is deemed to represent a negative past history.

1.2.4     Representing Prospective Information

Prospects describe expectations of possible future events rather the actual events themselves.  For observations these include goals, expectations and risks.  For activities prospects include plans, requests and other intentions.  Prospects are indicated by the use of certain finding context values and procedure context values for observations and activities respectively.  Representing the timing of future events, if known, involves the use the UNBOUND_DATA_ELEMENT FutureEventTime. 

1.2.4.1    Finding Context for Prospective Observations

For observations the prospect of a finding is indicated using one of the finding context values (or a subtype thereof) specified by the following constraint:

408729009 | finding context | = ( (<< 410519009 | at risk | ) OR (<< 410517006 | expectation | ) OR (<< 410518001 | goal | ) )

1.2.4.2    Procedure Context for Prospective Activities

For activities the procedure context of the meaning attribute is used to indicate the degree of completion, or status of the associated procedure.  Activities that have yet to occur are indicated using an appropriate subtype of pre-starting action status for the procedure context value as defined by the following constraint:

408730004 | procedure context | = ( (< 410522006 | pre-starting action status | ) OR ( < 410537005 | action status unknown | ) )

An instance example of a planned hip replacement representing using a post-coordinated procedure with explicit context is shown below. 

Example 1 Planned hip replacement

=  243796009 | situation with explicit context |:

{ 363589002 | associated procedure | = 397956004 | prosthetic arthroplasty of the hip | , 408730004 | procedure context | = 397943006 | planned | , 408731000 | temporal context | = 15240007 | current | , 408732007 | subject relationship context | = 410604004 | subject of record | }

1.2.4.3    Temporal Context for Prospects

For prospects the temporal context is used to indicate whether the prospect represents a current or a past (i.e. historic) expectation.  Typically a prospect will represent a current expectation of a possible future event.  Importantly, the temporal context of the prospect does not represent the future context of the anticipated event. 

The constraint on the temporal context of prospects therefore conforms to the temporal context constraint specified previously under section 4.2.3.  This constraint may be restricted further according to whether the prospect is a contemporary (as section 4.2.3.1) or a retrospective (as section 4.2.3.2) record and whether the event time is known (as sections 4.2.3.1.1and 4.2.3.2.1) or unknown (as sections 4.2.3.1.2 and 4.2.3.2.2). 

1.2.4.4    Future Event Time

In conformance with EN 13606, the times of expected future events are formally specified using a separate ELEMENT to help ensure that such dates and times can be reliably and safely identified by decision support systems. 

A prospect (e.g. expectation, goal, risk, intended event, etc) is represented as an observation or activity with an appropriate finding or procedure context value as described above.  The time(s) of the expected future event, if known, is specified by semantically linking an instance of the UNBOUND_DATA_ELEMENT FutureEventTime to the prospect.  A FutureEventTime may specify the point in time or time interval of a single event or it may specify a timing pattern for a number of future events such as a periodic repeating interval for a prescribed medication administration. 

LRA ELEMENT models do not therefore represent explicitly SNOMED CT concepts such as the following that imply expected future events:

• 185353001 | appointment date (finding) |
• 161714006 | estimated date of delivery (observable entity) |
• 390901002 | negotiated date for cessation of smoking (observable entity) |
• 355381000000108 | date of next anticoagulant clinic appointment (procedure) |
• 356051000000109 | date of next disease modifying antirheumatic drug monitoring clinic appointment (procedure) |

1.2.5     Representing Other Types of Timing Information

1.2.5.1    Representing Period of Validity

The period of validity such as the start and end date of a plan or the expiration date of a drug is represented by semantically linking an instance of UNBOUND_DATA_ELEMENT ValidPeriod to the observation, activity or material entity.

LRA ELEMENT models do not therefore represent explicitly SNOMED CT concepts that represent valid periods such as the following:

• 427416004 | therapeutic substance expiration date (observable entity) | or
• 116767008 | blood product unit expiration time (observable entity) |

1.2.5.2    Representing Course Timing

The timing of an ongoing (i.e. current) or past course of events, such as a course of medication, is represented by semantically linking an instance of UNBOUND_DATA_ELEMENT CourseTiming to an activity or observation instance that represents an exemplar rather than actual event. 

Use of the CourseTiming element is for specifying current or past courses only.  Prospective courses that specify the intended timing of future events are represented using FutureEventTime as described in section 4.2.4.4. 

1.2.5.3    Representing Time Series

A series of individually timed events is represented by specifying an activity or observation element with an upper bound multiplicity of greater than 1 and using the obs_time of each recorded instance to record the time of the particular event that it represents.

1.2.6     Property Observations

As stated in section 4.1.2.2, the PROPERTY_OBSERVATION_ELEMENT value attribute is prohibited from being assigned a time based type (i.e. a QSET<TS> or any specialisation thereof) and therefore cannot be used to represent the time of past, current or prospective events.  This does not preclude the use of the attribute to represent a duration as a physical quantity with a time unit. For example, the duration of stress test should be represented as a PROPERTY_OBSERVATION_ELEMENT value with the unit expressed in seconds, minutes or other suitable time unit.

1.3    Representing Subject of Information

Within the LRA the subject of a finding or procedure are represented using either one or a combination of the subject relationship context value of the BOUND_DATA_ELEMENT meaning attribute and a subject_of_information RELATED_PARTY instance associated with the containing ENTRY. 

The subject relationship context attribute represents the relationship between the subject of a clinical finding or procedure and the subject of the record.

The RELATED_PARTY representation serves two different functions: 

• Firstly in all instances it can be used to identify the related party that is the subject of the ENTRY - this is useful even if the nature of the relationship is defined using the SNOMED CT subject relationship context elsewhere.
• Secondly for ENTRYs whose ELEMENT content is not SNOMED CT encoded (and hence a subject relationship context is not defined), the subject_of_information is able to specify the relationship type.

Table 1 specifies the co-occurrence constraints for representing subject of information in the form of a truth table.  The purpose of the constraints is to ensure that the structural and terminological representations do not conflict with or duplicate one another. 

Table 1 Truth table for representing subject of information

Condition	Information represented by a BOUND_DATA_ELEMENT	yes	yes	yes	no	no	no
Subject of information = subject of record	yes	no	no	yes	no	no
Requirement to identify the subject of information	N/A	no	yes	N/A	no	yes
Result:	Use SNOMED CT subject relationship context	yes	yes	no	no
Use EN 13606 subject_of_information: RELATED_PARTY	no	yes	no	yes

If the information is represented by a BOUND_DATA_ELEMENT and the subject is the subject of the record then the subject of the information is indicated by the subject relationship context of the meaning attribute with a value that conforms to the following constraint:

408732007 | subject relationship context | = 410604004 | subject of record |

If the subject is not the subject of the record then the subject of the information is indicated by the subject relationship context with a value that conforms to the following constraint:

408732007 | subject relationship context | = << 303071001 | person in the family |

If the information is represented by an UNBOUND_DATA_ELEMENT then the subject of the information is implied to be the subject of the record unless indicated otherwise by a subject_of_information RELATED_PARTY instance associated with the containing ENTRY.  

If the subject of information represented by an UNBOUND_DATA_ELEMENT is not the subject of the record then the subject of information is indicated by the relationship attribute of the associated RELATED_PARTY instance with a value that conforms to the constraint:

<< 303071001 | person in the family |

The subject_of_information RELATED_PARTY instance associated with the containing ENTRY must be used for both BOUND_DATA_ELEMENTs and UNBOUND_DATA_ELEMENTs if there is a requirement to identify the subject of information.  However for BOUND_DATA_ELEMENTs the value of RELATED_PARTY relationship attribute must be set to null flavor DER | derived | to indicate that the information derivable – in this case from the subject relationship context of the BOUND_DATA_ELEMENT meaning attribute).  This avoids having to duplicate the value. 

The instance expression below represents the observation that the father of the subject of the record has ischemic heart disease. The fact that this observation applies to the father (rather than the record subject) is represented by a subtype of person in the family.   

Example 2 Father has ischemic heart disease

408732007 | subject relationship context | = 66839005 | father |

243796009 | situation with explicit context |:

{ 246090004 | associated finding | = 414545008 | ischemic heart disease | , 408729009 | finding context | = 410515003 | known present | , 408731000 | temporal context | = 15240007 | current | , 408732007 | subject relationship context | = 66839005 | father | }

For unbound data the RELATED_PARTY subject_of_information attribute would specify the value:

66839005 | father |

Within an instance of a BOUND_DATA_ELEMENT it is also possible to represent a family history of ischemic heart disease using the following simpler, close to user form. 

Example 3 Family history of ischemic heart disease

57177007 | family history of |: 246090004 | associated finding | = 414545008 | ischemic heart disease |

This can be refined to indicate the affected family member is the father as in the following instance expression. 

Example 4 Father has ischemic heart disease

57177007 | family history of |:

246090004 | associated finding | = 414545008 | ischemic heart disease |

, 408732007 | subject relationship context | = 66839005 | father |

This expression has exactly the same meaning as the first, more verbose, example and conforms to the semantic expression constraint for a subject of information that is not the subject of the record.

1.4    Representing Uncertainty and Negation

Technical Models may need to support uncertainty and / or negation requirements.  As shown in section 4.2.3 the finding context of contemporary and retrospective observations is used to assert the presence or absence of the associated finding with varying degrees of certainty.  Similarly the procedure context can be used to assert that a procedure was not done. 

1.4.1     Uncertainty and Negation in Observation Instances

An observation instance with a finding context value conforming to the following constraint indicates that the finding is / was actually present (versus being ruled out or considered):

408729009 | finding context | = (<< 410515003 | known present | )

Known present subsumes the term probably present as well as definitely present and confirmed present.  A finding about a patient who is said to probably have asthma can therefore be represented as in the following instance expression.

Example 5 Patient (i.e. subject of record) is said to probably have asthma

= 243796009 | situation with explicit context |:

{ 246090004 | associated finding | = 195967001 | asthma | , 408729009 | finding context | = 410592001 | probably present | , 408731000 | temporal context | = << 410585006 | current - unspecified|, 408732007 | subject relationship context | = 410604004 | subject of record | }

Negative history or negative past history, on the other hand, is indicated by a finding context value that conforms to:

408729009 | finding context | = ( (<< 410516002 | known absent | ) OR (<< 428263003 | NOT suspected | ) )

As noted in section 4.2.3.2.3 a negative past history also requires that the obs_time state a null flavor UNK | unknown | and that the temporal context value conforms to the constraint:  

408731000 | temporal context | = ( (<< 410589000 | all times past | ) )

Note that only the most general constraint should be applied to the finding context of an OBSERVATION_ELEMENT as it cannot be known in advance whether an instance will affirm or negate a stated finding:

408729009 | finding context | = ( (<<  36692007 | known | ) OR (<< 261665006 | unknown | ) )

1.4.2     Uncertainty and Negation in Activity Instances

An activity instance with a procedure context value conforming to the following constraint indicates that the procedure is either in progress or has ended:

408730004 | procedure context | = ( (< 410523001 | post-starting action status | ) )

In progress subsumes the term started and suspended while ended subsumes done and discontinued.  A procedure that has been completed is thus represented by a procedure context conforming to the constraint:

408730004 | procedure context | = (<< 385658003 | done |  )

To assert that a procedure was not done, the procedure context value must conform to:

408730004 | procedure context | = (<< 385660001 | not done | )

For a negative past history this also requires that the obs_time state a null flavor UNK | unknown | and that the temporal context value conforms to the constraint:  

408731000 | temporal context | = (<< 410589000 | all times past | )

To assert that the action status of a procedure is unknown, the procedure context value must conform to:

408730004 | procedure context | = (<< 410537005 | action status unknown | )

Only the most general constraint should be applied to the procedure context of an ACTIVITY_ELEMENT as the status of the activity cannot be known in advance:

408730004 | procedure context | = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) OR (<< 410537005 | action status unknown | ) )

2      Technical Model Refinement

2.1    Refinement of Clinical Focus

The clinical focus concept of the BOUND_DATA_ELEMENT meaning attribute is the value of the associated finding or procedure attribute of the situation with explicit context.  For OBSERVATION_ELEMENTs and ACTIVITY_ELEMENTs the following steps may be taken to increase the expressiveness and specificity of the clinical focus concept to help satisfy a given care record information requirement:  

• selecting for the focus concept, the SNOMED CT concept that most closely matches the stated requirement;                                                                                                                                Refinements
• including and applying values to SNOMED CT concept model attributes that add detail and specificity to the focus concept; and
• 'indirect' use of concept model attributes such as the application of laterality to a finding or procedure - in this case, the laterality logically applies to the finding or procedure site (this is a close to user representation).

Refinement by the application of values to concept model attributes and the indirect use of concept model attributes only applies focus concepts that belong to a SNOMED CT hierarchy for which concept model attributes are defined.  This includes focus concepts belonging to the following hierarchies: 

• Clinical finding
• Procedure
• Pharmaceutical/biologic product
• Event
• Specimen

The current SNOMED CT Concept Model does not specify any defining attributes for concepts in the following hierarchies that can participate as 'focus concepts' in LRA designs and consequently attribute refinement cannot be applied to any focus concepts that belong to them.   

• Observable entity
• Record artefact

The concept model attributes that may be refined depend on hierarchy to which the focus concept belongs not on whether the concept is the value of an associated finding or the value of an associated procedure.  Consequently an evaluation procedure or laboratory procedure focus concept acting as an associated finding within a PROPERTY_OBSERVATION_ELEMENT can still only be refined using the concept model attributes that define it as some type of procedure.  Equally, an observable focus concept acting as an associated finding within a PROPERTY_OBSERVATION_ELEMENT or an associated procedure within an INVESTIGATION_ACTIVITY_ELEMENT cannot be refined. 

The following sections describe the refinement of a number of selected concept model attributes of clinical finding, procedure and pharmaceutical / biologic product focus concepts to address some commonly encountered care record information requirements. 

This guidance is not exhaustive and likely to be expanded in future versions of this document to provide guidance on other concept attribute refinements used where specialised or extended within the LRA.  For further guidance on the attributes described the reader is recommended to consult the SNOMED CT User Guide [10] and various domain-specific editorial policy / modelling guides.

2.1.1     Refinement of Clinical Findings

The following guidance applies to FINDING_OBSERVATION_ELEMENTs in which the focus concept within the meaning attribute is a subtype of clinical finding. 

2.1.1.1    Finding Site  

The finding site attribute specifies the body site affected by a condition.  The refinement of a clinical finding with a finding site is defined by the following constraint.

< 404684003 | clinical finding |:

363698007 | finding site |

= ( << 442083009 | anatomical or acquired body structure |  )

The finding site value is taken from either the anatomical structure hierarchy or the acquired body structure hierarchy both of which are subsumed by the top level concept of body site.  

2.1.1.2    Finding Laterality  

The laterality attribute is used in the pre-coordinated definition of body structure concepts.  In post-coordinated expressions, it can potentially be used to modify body structures, procedures, diseases, and findings.  Laterality applied to a finding site directly conforms to the following constraint:

< 404684003 | clinical finding |:

363698007 | finding site |

= ( << 442083009 | anatomical or acquired body structure |  )

         : 272741003 | laterality | = < 182353008 | side |

When applied to disease or finding concepts that refer to a single body structure, the laterality is actually modifying the underlying body site rather than the finding itself. The general constraint for the indirect application of laterality is expressed as a literal expression constraint with the following form.

< 404684003 | clinical finding |: 272741003 | laterality | = < 182353008 | side |

The body structure to which the laterality is applied, either directly or indirectly, must be bilaterally symmetrical body structure, i.e. exist on opposite sides of the body.

Fracture of left femur and right tibia may therefore be represented as shown in the following instance expression.

Example 6 Fracture of left femur

= ( 243796009 | situation with explicit context |:

{ 246090004 | associated finding | = ( 71620000 | fracture of femur |: 272741003 | laterality | = 7771000 | left | ) , 408729009 | finding context | = 410515003 | known present | , 408731000 | temporal context | = 410584005 | current - specified | , 408732007 | subject relationship context | = 410604004 | subject of record | }

Laterality can be used to modify clinical finding concepts that involve more than one body site, but only if both sites have the same value for laterality (both left, both right, or both bilateral).

Clinical findings that involve multiple sites with differing values for laterality must be represented as separate observation instances rather than being post-coordinated within a single instance.  A second fracture, say of the right tibia, would therefore require another finding observation instance as shown.

Example 7 Fracture of right tibia

= 243796009 | situation with explicit context |:

{ 246090004 | associated finding | = ( 31978002 | fracture of tibia |: 272741003 | laterality | = 24028007 | right | ) , 408729009 | finding context | = 410515003 | known present | , 408731000 | temporal context | = 410584005 | current - specified | , 408732007 | subject relationship context | = 410604004 | subject of record | }

Laterality constraints must be specified if there is a requirement to specify unambiguously the side of the body to which the finding or procedure applies.

2.1.1.3    Causative Agent

This attribute identifies the direct causative agent of a disease. It does not include vectors, e.g. a mosquito that transmits malaria.  Permissible values for the attribute are specified by the following constraint:

< 404684003 | clinical finding |:

246075003 | causative agent |

= ( ( < 410607006 | organism | )

OR ( < 78621006 | physical force | )

OR ( < 105590001 | substance | )

OR ( < 373873005 | pharmaceutical / biologic product | )

OR ( < 260787004 | physical object | ) )

The causative agent constraint is used and further refined in the domain model representation of allergy and adverse reaction events and propensities.  This is illustrated by the following instance expression that represents an adverse reaction propensity to penicillin. 

Example 8 Adverse reaction to penicillin

= 243796009 | situation with explicit context |:

{ 246090004 | associated finding | = (419511003 | propensity to adverse reactions to drug |: 246075003 | causative agent | = 373270004 | penicillin -class of antibiotic- | ) , 408729009 | finding context | = 410515003 | known present | , 408731000 | temporal context | = 410512000 | current or specified | , 408732007 | subject relationship context | = 410604004  | subject of record | }

2.1.2     Refinement of Procedures

The following guidance applies to ACTIVITY_ELEMENTs and PROPERTY_OBSERVATION_ELEMENTs in which the focus concept within the meaning attribute is a subtype of procedure. 

2.1.2.1    Method

This attribute represents the action performed to accomplish the procedure. It does not include the access (e.g. percutaneous), approach (e.g. translumbar), equipment (e.g. sutures), or physical forces (e.g. laser energy).

< 71388002 | procedure |:

 260686004 | method | = < 129264002 | action |

2.1.2.2    Procedure Site

The procedure site – Direct attribute identifies the anatomical structure or site at which the action of the procedure is directly aimed.  Permissible values for the attribute are specified by the following constraint:

< 71388002 | procedure |:

, 405813007 | procedure site - Direct | 

= ( << 442083009 | anatomical or acquired body structure |  )

The attribute should be used for body structures that are to be removed or have been removed by a procedure with a method of removal-action or one of its subtypes (e.g. excision, surgical biopsy, etc.).  Removals of tissue lesions (cysts, tumours, etc.) also are considered to be removals of the site, and should therefore use procedure site - direct.

The procedure site – Indirect attribute identifies the anatomical site which is acted upon, but is not the direct object of the procedure. Typically a procedure also specifies the direct site of the action.  Permissible values for the attribute are specified by the following constraint:

< 71388002 | procedure |:

, << 405813007 | procedure site - Direct | 

= ( << 442083009 | anatomical or acquired body structure |  )

2.1.2.3    Procedure Laterality

The laterality attribute is used in the pre-coordinated definition of body structure concepts.  In post-coordinated expressions, it can potentially be used to modify body structures, procedures, diseases, and findings.  Laterality applied to a procedure site directly conforms to the following constraint:

< 71388002 | procedure |:

, << 363704007 | procedure site |

= ( << 442083009 | anatomical or acquired body structure |  ):

272741003 | laterality | = < 182353008 | side |

The procedure site attribute subsumes both procedure site – Direct and procedure site – Indirect.  The general constraint for indirect application of procedure laterality is expressed as follows:

<  71388002 | procedure |:

272741003 | laterality | = < 182353008 | side |

Laterality can be used to modify procedure concepts that involve more than one body site, but only if both sites have the same value for laterality (both left, both right, or both bilateral).  Procedures that involve multiple sites with differing values for laterality must be represented as separate activity instances rather than being post-coordinated within a single instance.   

2.1.2.4    Route of Administration

The route of administration of a substance is a defining attribute of administration of substance via specific route (procedure) and its descendants as specified by the following constraint.

<< 433590000 | administration of substance via specific route |:

410675002 | route of administration | < 284009009 | route of administration value |

This constraint therefore applies only to those MATERIAL_ACTIVITY_ELEMENTs in which the focus concept within the meaning attribute is a subtype of administration of substance via specific route.  

2.1.3     Refinement of Pharmaceutical / Biologic Products

The following guidance applies to MATERIAL_ENTITY_ELEMENTs in which the focus concept within the meaning attribute is a subtype type of pharmaceutical / biologic product. 

2.1.3.1    Has Dose Form

Has dose form specifies the dose form of a product with a value from the set specified by the following constraint:

< 373873005 | pharmaceutical / biologic product |:

411116001 | has dose form | < 105904009 | type of drug preparation |

3      Technical Model Patterns

3.1    Primary Design Patterns

A Primary Design Pattern is a class template designed for instantiating individual Domain Model or Constrained Domain Model elements (i.e. domain model classes) that conform to the pattern. A Primary Design Pattern can be created from and assert additional constraints, as described in this document, on any non-abstract Reference Model class.  For non-abstract specialisations of BOUND_DATA_ELEMENT, for example, the meaning attribute may be further constrained to represent a common usage pattern of the class, e.g. family history, plan, goal, etc.

3.1.1     BOUND_DATA_ELEMENT Primary Design Patterns

The following sections describe a selected number of primary design patterns for BOUND_DATA_ELEMENTs.  Each pattern encapsulates a particular set of the design choices described in section 4 with the aim of providing a generalised solution to a commonly encountered requirement type.  Having selected and applied the pattern the next steps are to refine it by applying one or more of the methods described in section 5 and to consider its links with other elements using the secondary design patterns described in section 6.2 (note that determination of secondary design patterns ).

3.1.1.1    Pattern Index

Table 1 lists a number of selected BOUND_DATA_ELEMENT primary design patterns.  The patterns are listed under a number of categorisations including care record information type, current / past history, and subject of record such that a given pattern may appear in more than one categorisation. 

Table 2 Selected BOUND_DATA_ELEMENT Primary Design Patterns

Categorisation	Pattern
Finding Observation	Finding Observation – Current or past
Finding Observation - Current
Finding Observation - Past
Finding Observation - Family History of
Property Observation	Property Observation – Current or past
Property Observation - Current
Property Observation - Past
General Activity	General Activity - Current
General Activity - Past
General Activity - Family History
Investigation Activity	Investigation Activity - Current
Investigation Activity - Past
Current or Past	Finding Observation – Current or past
Property Observation – Current or past
Finding Observation - Family History of
General Activity - Family History of
Current	Finding Observation - Current
Property Observation - Current
General Activity - Current
Investigation Activity - Current
Past History	Finding Observation - Past
Property Observation - Past
General Activity - Past
Investigation Activity - Past
Family History	Finding Observation - Family History of
General Activity - Family History of

3.1.1.2    Pattern Definitions

3.1.1.2.1     Finding Observation – Current or past

Field
Constraint

uid

type

FINDING_OBSERVATION_ELEMENT

session_time

COMPOSITION

obs_time

Clinically relevant date and time where available

meaning

= 243796009 | situation with explicit context |:

{ 246090004 | associated finding | = ( ( < 404684003 | clinical finding | ) OR ( < 272379006 | event | ) ) ,

408729009 | finding context | = ( ( < 36692007 | known | ) OR ( << 261665006 | unknown | ) ) ,

408731000 | temporal context | = < 410510008 | temporal context value |,

408732007 | subject relationship context | = 410604004 | subject of record |

}

[2.1.1.2.2 (file://\\2.1.1.2.2)]&nbsp;&nbsp;&nbsp;&nbsp;FindingObservation-Current\\">[2.1.1.2.2 (file://\\2.1.1.2.2)]     Finding Observation - Current |Field Constraint

[\\uid (file://\\uid)]

type

FINDING_OBSERVATION_ELEMENT

session_time

COMPOSITION

obs_time

Clinically relevant date and time where available

meaning

= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding |\ = ( ( < 404684003 | clinical finding | )\ OR ( < 272379006 | event | ) )\ , 408729009 | finding context |\ = ( (< 36692007 | known | )\ OR ( << 261665006 | unknown | ) )\ , 408731000 | temporal context |\ = ( ( << 410512000 | current or specified | ) AND ( ! < 410513005 | past | ) )\ , 408732007 | subject relationship context | = 410604004 | subject of record | }

2.1.1.3    Finding Observation - Past Field Constraint

uid

type

FINDING_OBSERVATION_ELEMENT

session_time

COMPOSITION

obs_time

Clinically relevant date and time where available

meaning

= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding |\ = ( ( < 404684003 | clinical finding | )\ OR ( < 272379006 | event | ) )\ , 408729009 | finding context |\ = ( ( < 36692007 | known | )\ OR ( << 261665006 | unknown | ) )\ , 408731000 | temporal context |\ = ( << 410511007 | current or past | ) AND ( ! < 15240007 | current | ) )\ , 408732007 | subject relationship context | = 410604004 | subject of record | } 2.1.1.4    Finding Observation - Family History of  Field Value uid type FINDING_OBSERVATION_ELEMENT session_time COMPOSITION obs_time Clinically relevant date and time where available meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding |\ = ( ( < 404684003 | clinical finding | )\ OR ( < 272379006 | event | ) )\ , 408729009 | finding context |\ = ( ( < 36692007 | known | )\ OR ( << 261665006 | unknown | ) )\ , 408731000 | temporal context | = < 410510008 | temporal context value |\ , 408732007 | subject relationship context | = << 303071001 | person in the family | } 2.1.1.5    Property Observation – Current or past Field Constraint uid type PROPERTY_OBSERVATION_ELEMENT session_time COMPOSITION obs_time Clinically relevant date/time required value SOME VALUE - QUANTITY/ORDINAL/CODED Meaning = 243796009 | situation with explicit context |: { 246090004 | associated finding | = ( ( < 363787002 | observable entity | ) OR ( < 386053000 | evaluation procedure | ) OR ( < 108252007 | laboratory procedure | ) ) , = ( ( < 36692007 | known | ) OR ( << 261665006 | unknown | ) , 408731000 | temporal context | = < 410510008 | temporal context value | , 408732007 | subject relationship context | = 410604004 | subject of record | } 2.1.1.6    Property Observation - Current  Field Constraint uid type PROPERTY_OBSERVATION_ELEMENT session_time COMPOSITION obs_time Clinically relevant date/time required value SOME VALUE - QUANTITY/ORDINAL/CODED Meaning = 243796009 | situation with explicit context |: { 246090004 | associated finding | = ( ( < 363787002 | observable entity | ) OR ( < 386053000 | evaluation procedure | ) OR ( < 108252007 | laboratory procedure | ) ) , = ( ( < 36692007 | known | ) OR ( << 261665006 | unknown | ) , 408731000 | temporal context | = ( ( << 410512000 | current or specified | ) AND ( ! < 410513005 | past | ) ) , 408732007 | subject relationship context | = 410604004 | subject of record | } 2.1.1.7    Property Observation - Past  Field Constraint uid type PROPERTY_OBSERVATION_ELEMENT session_time COMPOSITION obs_time Clinically relevant date/time required value SOME VALUE - QUANTITY/ORDINAL/CODED Meaning = 243796009 | situation with explicit context |: { 246090004 | associated finding | = ( ( < 363787002 | observable entity | ) OR ( < 386053000 | evaluation procedure | ) OR ( < 108252007 | laboratory procedure | ) ) , = ( ( < 36692007 | known | ) OR ( << 261665006 | unknown | ) , 408731000 | temporal context | = ( << 410511007 | current or past | ) AND ( ! < 15240007 | current | ) ) , 408732007 | subject relationship context | = 410604004 | subject of record | } 2.1.1.8    General Activity - Current   Constraint uid type GENERAL_ACTIVITY_ELEMENT session_time COMPOSITION obs_time Clinically relevant date and time where available Meaning = 243796009 | situation with explicit context |: { 363589002 | associated procedure |   = ( ( < 71388002 | procedure | ) AND ( ! < 386053000 | evaluation procedure | ) AND ( ! < 108252007 | laboratory procedure | ) AND ( ! < 432102000 | administration of substance | ) AND ( ! < 433590000 | administration of substance via specific route | ) AND ( ! < 33633005 | prescription of drug | ) AND ( ! < 75658007 | prescription of therapeutic agent | ) AND ( ! < 103742009 | renewal of prescription | ) AND ( ! < 243704004 | provision of appliances | ) AND ( ! < 183253002 | provision of medical equipment | ) AND ( ! < 404919001 | wheat-free diet | ) AND ( ! < 223456000 | provision of a special diet | ) AND ( ! < 440298008 | dispensing of pharmaceutical/biologic product | ) ) , 408730004 | procedure context |  = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) ) , 408731000 | temporal context | = ( ( << 410512000 | current or specified | ) AND ( ! < 410513005 | past | ) ) , 408732007 | subject relationship context | = 410604004 | subject of record | } 2.1.1.9    General Activity - Past  Field Value uid type GENERAL_ACTIVITY_ELEMENT session_time COMPOSITION obs_time Clinically relevant time where available – prior to COMPOSITION Meaning = 243796009 | situation with explicit context |: { 363589002 | associated procedure |   = ( ( < 71388002 | procedure | ) AND ( ! < 386053000 | evaluation procedure | ) AND ( ! < 108252007 | laboratory procedure | ) AND ( ! < 432102000 | administration of substance | ) AND ( ! < 433590000 | administration of substance via specific route | ) AND ( ! < 33633005 | prescription of drug | ) AND ( ! < 75658007 | prescription of therapeutic agent | ) AND ( ! < 103742009 | renewal of prescription | ) AND ( ! < 243704004 | provision of appliances | ) AND ( ! < 183253002 | provision of medical equipment | ) AND ( ! < 404919001 | wheat-free diet | ) AND ( ! < 223456000 | provision of a special diet | ) AND ( ! < 440298008 | dispensing of pharmaceutical/biologic product | ) ) , 408730004 | procedure context | = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) OR (<< 410537005 | action status unknown | ) AND (! < 385651009 | in progress | ) ) , 408731000 | temporal context | = ( << 410511007 | current or past | ) AND ( ! < 15240007 | current | ) ) , 408732007 | subject relationship context | = 410604004 | subject of record | } 2.1.1.10 General Activity - Family History of  Field Value uid type GENERAL_ACTIVITY_ELEMENT session_time COMPOSITION obs_time Relevant clinical date and time Meaning = 243796009 | situation with explicit context |: { 363589002 | associated procedure | = ( ( < 71388002 | procedure | ) AND ( ! < 386053000 | evaluation procedure | ) AND ( ! < 108252007 | laboratory procedure | ) AND ( ! < 432102000 | administration of substance | ) AND ( ! < 433590000 | administration of substance via specific route | ) AND ( ! < 33633005 | prescription of drug | ) AND ( ! < 75658007 | prescription of therapeutic agent | ) AND ( ! < 103742009 | renewal of prescription | ) AND ( ! < 243704004 | provision of appliances | ) AND ( ! < 183253002 | provision of medical equipment | ) AND ( ! < 404919001 | wheat-free diet | ) AND ( ! < 223456000 | provision of a special diet | ) AND ( ! < 440298008 | dispensing of pharmaceutical/biologic product | ) ) , 408730004 | procedure context | = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) OR (<< 410537005 | action status unknown | ) AND (! < 385651009 | in progress | ) ) , 408731000 | temporal context | = < 410510008 | temporal context value | =  << 303071001 | person in the family | } 2.1.1.11 Investigation Activity - Current Field Constraint uid type INVESTIGATION_ACTIVITY_ELEMENT session_time COMPOSITION obs_time Clinically relevant time where available Meaning = ( 243796009 | situation with explicit context |: { 363589002 | associated procedure | = ( ( < 386053000 | evaluation procedure | ) OR ( < 108252007 | laboratory procedure | ) OR ( < 363787002 | observable entity | ) ) , 408730004 | procedure context |  = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) )   , 408731000 | temporal context | = ( ( << 410512000 | current or specified | ) AND ( ! < 410513005 | past | ) ) , 408732007 | subject relationship context | = < 125676002 | person | }) 2.1.1.12 Investigation Activity - Past Field Constraint uid type INVESTIGATION_ACTIVITY_ELEMENT session_time COMPOSITION obs_time Date and time specified or unspecified Meaning = 243796009 | situation with explicit context |: { 363589002 | associated procedure | = ( ( < 386053000 | evaluation procedure | ) OR ( < 108252007 | laboratory procedure | ) OR ( < 363787002 | observable entity | ) ) , 408730004 | procedure context | = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) OR (<< 410537005 | action status unknown | ) AND (! < 385651009 | in progress | ) ) , 408731000 | temporal context | = ( << 410511007 | current or past | ) AND ( ! < 15240007 | current | ) ) , 408732007 | subject relationship context | =  410604004 | subject of record | } 2.2    Secondary Design Patterns A secondary design pattern describes the semantic relationship between a RECORD_COMPONENT instance that is the subject of the relationship and a RECORD_COMPONENT instance that is the object of the relationship within a Domain Model.  A given relationship may be involved in one or more secondary design patterns; and a given RECORD_COMPONENT may be involved as a subject and / or object in zero or more Secondary Reuse Patterns. This area of the guidelines is under development and the following sections summarise those limited areas where design guidance can be given. 2.2.1     Finding Observation Links Findings may be the source or target of any number of COMPONENT_RELATIONSHIP_ELEMENTs. These relationships are used in any case where there is a requirement to indicate or assert an association between two findings or between a finding and any other type of record component. The SNOMED CT concept  416083004 | has reason  is recommended for use as shown in the following example. No guidance on any other link assertion sub-types is included as a matter of policy pending further study of the whole area for LRA Release 3. Example: Renal failure due to past history of pyelonephritis Table:  Chronic renal failure  Field Value uid f7b5adf0-7e0c-4038-a47f-aa37edaac572 type FINDING_OBSERVATION_ELEMENT session_time COMPOSITION obs_time Flavor of null:UNK or DER Meaning = 243796009 | situation with explicit context |: { 246090004 | associated finding | = 90688005 | chronic renal failure syndrome | , 408729009 | finding context | = 410515003 | known present | , 408731000 | temporal context | = 15240007 | current | , 408732007 | subject relationship context | = 410604004 | subject of record | } Table:  'has reason'  Field Value uid 7ec1df29-0899-46ed-9044-22cee994b936 type COMPONENT_RELATIONSHIP_ELEMENT session_time COMPOSITION obs_time Flavor of null:UNK or DER Meaning = 416083004 | has reason | sourceUid f7b5adf0-7e0c-4038-a47f-aa37edaac572 targetUid 8be02600-e112-4693-b676-ae6fa477d05b Table: Past history of pyelonephritis  Field Value uid 8be02600-e112-4693-b676-ae6fa477d05b type FINDING_OBSERVATION_ELEMENT session_time COMPOSITION obs_time Flavor of null:UNK or DER Meaning = 243796009 | situation with explicit context |: { 246090004 | associated finding | = 45816000 | pyelonephritis | , 408729009 | finding context | = 410515003 | known present | , 408731000 | temporal context | = 410513005 | past | , 408732007 | subject relationship context | = 410604004 | subject of record | } 2.2.2     Property Observation Links Property observations may be the source or target of any number of COMPONENT_RELATIONSHIP_ELEMENTs. These relationships are used in any case where there is a requirement to indicate or assert an association between two property observations or between a property observations and any other type of record component. Many of the uses of relationships for Property Observation will be similar to those used for finding observations. However, relationships may also be used for several purposes that are specific to (or at least more commonly required with) property observations. Linking a property observation to the activity (e.g. measurement procedure) from which it was derived. Linking a property observation to a specific clinical perspective (e.g. a blood pressure taken during an operative procedure) Linking several property observations into a logical group (e.g. the systolic and diastolic components of a blood pressure). Relating a property observation to a request for an investigation. As already indicated, guidance will be available in a LRA Release 3 revision of this document. 2.2.3     Investigation Links Procedures may be the source or target of any number of COMPONENT_RELATIONSHIP_ELEMENTs. These relationships are used in any case where there is a requirement to indicate or assert an association between two procedures or between a procedure and any other type of record component. The nature of relationship is specified by the meaning field. The time that the relationship was asserted is specified by the session_time field. If the relationship itself has a clinically relevant time this can be specified using the obs_time field. Some uses of relationships are similar for all types of activity: Linking subsidiary parts of more general procedure together (e.g. linking anaesthetic related activities to a surgical procedure). Linking a procedure to finding, problem or disorder it is intended to address (e.g. associating a prescription for antibiotics with a specified infection). Linking records are different stages or preparing for and completing and activity (e.g. request, plan, start and completion). Some relationships are specific to investigation activities: Linking an investigation activity to property observation resulting from that activity. As already indicated, guidance will be available in a LRA Release 3 revision of this document. 2.2.4     Record Artefact Links The following concepts required to support use of record artefacts  Concept Usage 416271009 | has problem member | A link between a record entry and a problem (represented as a record artefact) of which it forms a part. 416586004 | has problem name | A link between the record artefact that represent a problem and another record component which provides the current name for that problem. 100999 | has record role | Proposed addition A link between a record component and a record artefact which asserts a role the record component has in the record as a whole 2.3    Common Patterns of Clinical Recording This section describes common patterns of clinical recording which can be constructed from primary and secondary design patterns, applying additional constraints as necessary. The patterns which are adapted from the common patterns detailed SNOMED CT Bindings for Common Recording Patterns [8], serve as design specifications for LRA Domain Models and many of them are implemented as such.   Each pattern describes its rationale based on common recording and clinical practice and specifies any primary and secondary patterns from which it is constructed.    2.3.1     Problems and Issues 2.3.1.1    Introduction Problems and Issues are needs or related requirements to be resolved or noted, and are perceived as a problem or issue by a patient, carer or a Care Professional. The description of Problems in the NHS Care Record Elements document has been used as the base on which this area has been defined for LRA. A problem or issue may be the reason that the patient seeks help from a Care Professional or may be an ongoing problem which the patient is coping with. This can be either the patient's complaint or the Care Professional's observation, and includes items such as disease states, medical conditions, and responses and reactions to therapies. Whilst a Problem or Issue is a key element of the NHS Care Record, it may be related to information recorded elsewhere. The Problem or Issue will typically be as recalled by the patient or as identified by a Care Professional (e.g. as a Diagnosis or a Finding). As the patient's condition develops, more may be known about a Problem or Issue and this may lead to that Problem or Issue being renamed.  Following the approach used in the Care Record Element document (and by primary care in the UK), a problem is modelled as an aspect of an item of clinical data, in other words the Problem Member is a pointer to where this relevant clinical data has been recorded. The definition of Problems and Issues in the NHS Care Record Elements document covers the tracking of unmet needs, as well as organisation aspects of the medical record. General Practice systems in the UK implement Larry Weed's problem orientated medical record. The representation of problems requires three different types of information and the relationships between them to be represented. The types of information are: The problem header The problem title Problem membership 2.3.1.2    Problem header The Problem header is represented in LRA as a RECORD_ARTEFACT_ELEMENT. There is one problem header for each discrete problem or issue. The header itself does not contain specific clinical information and exists only as a node to which other record components are linked to represent the problem title and problem membership. The meaning field of the record artefact must contain the following fixed expression. 162991000000102 | Problems and Issues | The problem header element acts is a node which represents each problem that appears in the problem list. However, the name of the problem (as shown in the problem list) is carried in a separate record component that is linked to the problem header. This enables the name to change without changing the organisation of other items of information related to the problem. 2.3.1.3    Problem name The problem name is the clinical label currently assigned to a given item in the problem list. The problem name is a record element in its own right and can also be considered as a problem member. It is recognisable as the problem name because it is linked to the problem header by a COMPONENT_RELATIONSHIP_ELEMENT with a meaning field containing the following fixed expression: 416586004 | has problem name | The problem name is usually a clinical finding (such as the name of a disorder) represented by a FINDING_OBSERVATION_ELEMENT. However, where appropriate, a procedure represented using a GENERAL_ACTIVITY_ELEMENT (or another specialisation of ACTIVITY_ELEMENT) may be used to name a problem. Previous sections of this document provided guidance on the use of both of these LRA care record information types. The problem name may change over a period of time. Initially the problem name may be the main complaint as expressed by the patient (e.g. chest pain), and may progress to a specific clinical label (e.g. acute anteroapical myocardial infarction). When the problem is created and each time the problem name changes, the relevant finding is linked to the problem header as the problem name. The previous name is thus replaced but the same finding may remain a valid member of the problem.  The problem name may be any record component that conforms to the Care Components model. The representation of a finding or procedure is not altered by the decision to use it as the name of a problem. 2.3.1.4    Problem members Problem members are any type of record component that are linked to the problem header by a COMPONENT_RELATIONSHIP_ELEMENT with a meaning field containing the following fixed expression: 416271009 | has problem member | The same record component may be a member of more than one problem. 2.3.1.5    Refinement The problem name and problem members may be refined in any way permitted for the relevant focus concept. This includes support for direct lateralisation where this is appropriate. See details and examples in the sections on Clinical Findings. The need for a succinct name to appear in a problem list may limit the practical use of complex post-coordinated expressions as problem names. The problem header must not be refined. 2.3.1.6    Links to problem name and problem members The problem name and problem members are linked to the problem header using instances of the COMPONENT_RELATIONSHIP_ELEMENT which conform to one of the following constraints: Table Problem name relationship  Field Value uid c4344375-4e12-42ed-8e5e-822f4cfd987e type COMPONENT_RELATIONSHIP_ELEMENT session_time COMPOSITION obs_time Use clinically significant time where available meaning = 416586004 | has problem name | sourceUid Refers to the problem header targetUid Refers to the problem name Table Problem member relationship  Field Value uid e385b47e-349b-40ef-9e8c-8d9aae49a52b type COMPONENT_RELATIONSHIP_ELEMENT session_time COMPOSITION obs_time Use clinically significant time where available meaning = 416271009 | has problem member | sourceUid Refers to the problem header targetUid Refers to the problem member At any point in time there will be only one current instance of the problem name relationship. However, there may be any number of active instances of the problem member relationships (and any number of previous problem name relationships). Problem names and problem members are subject to same constraints that would apply to record component of the Care Record Information types.  There is no specific Primary Pattern or other guidance as part of this Problems section of the document. The pattern for Problems and Issues is illustrated in the diagram below. 2.3.1.7    Examples Pattern example: Renal failure problem group This example represents a single problem list entry ("renal failure") with a collection of four other record entries represented as part of the same problem. Table: Problem header  Field Value uid 53b7c478-29b1-4402-bb26-d657ccbfcbff type RECORD_ARTEFACT_ELEMENT session_time COMPOSITION obs_time 10/09/2009 - time 14:25 meaning = 162991000000102 | Problems and Issues | Table Chronic renal failure (Problem Name)  Field Value uid 9ea18251-9595-4cd2-92aa-4b7763a0f27e type FINDING_OBSERVATION_ELEMENT session_time COMPOSITION obs_time 10/09/2009 - time 14:25 meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 90688005 | chronic renal failure syndrome |, 408729009 | finding context | = 410515003 | known present |, 408731000 | temporal context | = 15240007 | current |, 408732007 | subject relationship context | = 410604004 | subject of record | } 1      Technical Model Refinement 1.1    Refinement of Clinical Focus The clinical focus concept of the BOUND_DATA_ELEMENT meaning attribute is the value of the associated finding or procedure attribute of the situation with explicit context.  For OBSERVATION_ELEMENTs and ACTIVITY_ELEMENTs the following steps may be taken to increase the expressiveness and specificity of the clinical focus concept to help satisfy a given care record information requirement:   selecting for the focus concept, the SNOMED CT concept that most closely matches the stated requirement;                                                                                                                                Refinements including and applying values to SNOMED CT concept model attributes that add detail and specificity to the focus concept; and 'indirect' use of concept model attributes such as the application of laterality to a finding or procedure - in this case, the laterality logically applies to the finding or procedure site (this is a close to user representation). Refinement by the application of values to concept model attributes and the indirect use of concept model attributes only applies focus concepts that belong to a SNOMED CT hierarchy for which concept model attributes are defined.  This includes focus concepts belonging to the following hierarchies:  Clinical finding Procedure Pharmaceutical/biologic product Event Specimen The current SNOMED CT Concept Model does not specify any defining attributes for concepts in the following hierarchies that can participate as 'focus concepts' in LRA designs and consequently attribute refinement cannot be applied to any focus concepts that belong to them.    Observable entity Record artefact The concept model attributes that may be refined depend on hierarchy to which the focus concept belongs not on whether the concept is the value of an associated finding or the value of an associated procedure.  Consequently an evaluation procedure or laboratory procedure focus concept acting as an associated finding within a PROPERTY_OBSERVATION_ELEMENT can still only be refined using the concept model attributes that define it as some type of procedure.  Equally, an observable focus concept acting as an associated finding within a PROPERTY_OBSERVATION_ELEMENT or an associated procedure within an INVESTIGATION_ACTIVITY_ELEMENT cannot be refined.  The following sections describe the refinement of a number of selected concept model attributes of clinical finding, procedure and pharmaceutical / biologic product focus concepts to address some commonly encountered care record information requirements.  This guidance is not exhaustive and likely to be expanded in future versions of this document to provide guidance on other concept attribute refinements used where specialised or extended within the LRA.  For further guidance on the attributes described the reader is recommended to consult the SNOMED CT User Guide [10] and various domain-specific editorial policy / modelling guides. 1.1.1     Refinement of Clinical Findings The following guidance applies to FINDING_OBSERVATION_ELEMENTs in which the focus concept within the meaning attribute is a subtype of clinical finding.  1.1.1.1    Finding Site   The finding site attribute specifies the body site affected by a condition.  The refinement of a clinical finding with a finding site is defined by the following constraint. < 404684003 | clinical finding |: 363698007 | finding site | = ( << 442083009 | anatomical or acquired body structure |  ) The finding site value is taken from either the anatomical structure hierarchy or the acquired body structure hierarchy both of which are subsumed by the top level concept of body site.   1.1.1.2    Finding Laterality   The laterality attribute is used in the pre-coordinated definition of body structure concepts.  In post-coordinated expressions, it can potentially be used to modify body structures, procedures, diseases, and findings.  Laterality applied to a finding site directly conforms to the following constraint: < 404684003 | clinical finding |: 363698007 | finding site | = ( << 442083009 | anatomical or acquired body structure |  )          : 272741003 | laterality | = < 182353008 | side | When applied to disease or finding concepts that refer to a single body structure, the laterality is actually modifying the underlying body site rather than the finding itself. The general constraint for the indirect application of laterality is expressed as a literal expression constraint with the following form. < 404684003 | clinical finding |: 272741003 | laterality | = < 182353008 | side | The body structure to which the laterality is applied, either directly or indirectly, must be bilaterally symmetrical body structure, i.e. exist on opposite sides of the body. Fracture of left femur and right tibia may therefore be represented as shown in the following instance expression. Example 6 Fracture of left femur = ( 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 71620000 | fracture of femur |} Laterality can be used to modify clinical finding concepts that involve more than one body site, but only if both sites have the same value for laterality (both left, both right, or both bilateral). Clinical findings that involve multiple sites with differing values for laterality must be represented as separate observation instances rather than being post-coordinated within a single instance.  A second fracture, say of the right tibia, would therefore require another finding observation instance as shown. Example 7 Fracture of right tibia = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 31978002 | fracture of tibia |} Laterality constraints must be specified if there is a requirement to specify unambiguously the side of the body to which the finding or procedure applies. 1.1.1.3    Causative Agent This attribute identifies the direct causative agent of a disease. It does not include vectors, e.g. a mosquito that transmits malaria.  Permissible values for the attribute are specified by the following constraint: < 404684003 | clinical finding |: 246075003 | causative agent | = ( ( < 410607006 | organism | ) OR ( < 78621006 | physical force | ) OR ( < 105590001 | substance | ) OR ( < 373873005 | pharmaceutical / biologic product | ) OR ( < 260787004 | physical object | ) ) The causative agent constraint is used and further refined in the domain model representation of allergy and adverse reaction events and propensities.  This is illustrated by the following instance expression that represents an adverse reaction propensity to penicillin.  Example 8 Adverse reaction to penicillin = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = (419511003 | propensity to adverse reactions to drug |} 1.1.2     Refinement of Procedures The following guidance applies to ACTIVITY_ELEMENTs and PROPERTY_OBSERVATION_ELEMENTs in which the focus concept within the meaning attribute is a subtype of procedure.  1.1.2.1    Method This attribute represents the action performed to accomplish the procedure. It does not include the access (e.g. percutaneous), approach (e.g. translumbar), equipment (e.g. sutures), or physical forces (e.g. laser energy). < 71388002 | procedure |:  260686004 | method | = < 129264002 | action | 1.1.2.2    Procedure Site The procedure site – Direct attribute identifies the anatomical structure or site at which the action of the procedure is directly aimed.  Permissible values for the attribute are specified by the following constraint: < 71388002 | procedure |: , 405813007 | procedure site - Direct |  = ( << 442083009 | anatomical or acquired body structure |  ) The attribute should be used for body structures that are to be removed or have been removed by a procedure with a method of removal-action or one of its subtypes (e.g. excision, surgical biopsy, etc.).  Removals of tissue lesions (cysts, tumours, etc.) also are considered to be removals of the site, and should therefore use procedure site - direct. The procedure site – Indirect attribute identifies the anatomical site which is acted upon, but is not the direct object of the procedure. Typically a procedure also specifies the direct site of the action.  Permissible values for the attribute are specified by the following constraint: < 71388002 | procedure |: , << 405813007 | procedure site - Direct |  = ( << 442083009 | anatomical or acquired body structure |  ) 1.1.2.3    Procedure Laterality The laterality attribute is used in the pre-coordinated definition of body structure concepts.  In post-coordinated expressions, it can potentially be used to modify body structures, procedures, diseases, and findings.  Laterality applied to a procedure site directly conforms to the following constraint: < 71388002 | procedure |: , << 363704007 | procedure site | = ( << 442083009 | anatomical or acquired body structure |  ): 272741003 | laterality | = < 182353008 | side | The procedure site attribute subsumes both procedure site – Direct and procedure site – Indirect.  The general constraint for indirect application of procedure laterality is expressed as follows: <  71388002 | procedure |: 272741003 | laterality | = < 182353008 | side | Laterality can be used to modify procedure concepts that involve more than one body site, but only if both sites have the same value for laterality (both left, both right, or both bilateral).  Procedures that involve multiple sites with differing values for laterality must be represented as separate activity instances rather than being post-coordinated within a single instance.    1.1.2.4    Route of Administration The route of administration of a substance is a defining attribute of administration of substance via specific route (procedure) and its descendants as specified by the following constraint. << 433590000 | administration of substance via specific route |: 410675002 | route of administration | < 284009009 | route of administration value | This constraint therefore applies only to those MATERIAL_ACTIVITY_ELEMENTs in which the focus concept within the meaning attribute is a subtype of administration of substance via specific route.   1.1.3     Refinement of Pharmaceutical / Biologic Products The following guidance applies to MATERIAL_ENTITY_ELEMENTs in which the focus concept within the meaning attribute is a subtype type of pharmaceutical / biologic product.  1.1.3.1    Has Dose Form Has dose form specifies the dose form of a product with a value from the set specified by the following constraint: < 373873005 | pharmaceutical / biologic product |: 411116001 | has dose form | < 105904009 | type of drug preparation | 2      Technical Model Patterns 2.1    Primary Design Patterns A Primary Design Pattern is a class template designed for instantiating individual Domain Model or Constrained Domain Model elements (i.e. domain model classes) that conform to the pattern. A Primary Design Pattern can be created from and assert additional constraints, as described in this document, on any non-abstract Reference Model class.  For non-abstract specialisations of BOUND_DATA_ELEMENT, for example, the meaning attribute may be further constrained to represent a common usage pattern of the class, e.g. family history, plan, goal, etc. 2.1.1     BOUND_DATA_ELEMENT Primary Design Patterns The following sections describe a selected number of primary design patterns for BOUND_DATA_ELEMENTs.  Each pattern encapsulates a particular set of the design choices described in section 4 with the aim of providing a generalised solution to a commonly encountered requirement type.  Having selected and applied the pattern the next steps are to refine it by applying one or more of the methods described in section 5 and to consider its links with other elements using the secondary design patterns described in section 6.2 (note that determination of secondary design patterns ). 2.1.1.1    Pattern Index Table 1 lists a number of selected BOUND_DATA_ELEMENT primary design patterns.  The patterns are listed under a number of categorisations including care record information type, current / past history, and subject of record such that a given pattern may appear in more than one categorisation.  Table 2 Selected BOUND_DATA_ELEMENT Primary Design Patterns Categorisation Pattern Finding Observation Finding Observation – Current or past Finding Observation - Current Finding Observation - Past Finding Observation - Family History of Property Observation Property Observation – Current or past Property Observation - Current Property Observation - Past General Activity General Activity - Current General Activity - Past General Activity - Family History Investigation Activity Investigation Activity - Current Investigation Activity - Past Current or Past Finding Observation – Current or past Property Observation – Current or past Finding Observation - Family History of General Activity - Family History of Current Finding Observation - Current Property Observation - Current General Activity - Current Investigation Activity - Current Past History Finding Observation - Past Property Observation - Past General Activity - Past Investigation Activity - Past Family History Finding Observation - Family History of General Activity - Family History of 2.1.1.2    Pattern Definitions 2.1.1.2.1     Finding Observation – Current or past Field Constraint uid type FINDING_OBSERVATION_ELEMENT session_time COMPOSITION obs_time Clinically relevant date and time where available meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( ( < 404684003 | clinical finding | ) OR ( < 272379006 | event | ) ) , | | | 408729009 | finding context | = ( ( < 36692007 | known | ) OR ( << 261665006 | unknown | ) ) , | | | 408731000 | temporal context | = < 410510008 | temporal context value |, | | | 408732007 | subject relationship context | = 410604004 | subject of record | | | | } 2.1.1.2.2     Finding Observation - Current Field Constraint uid type FINDING_OBSERVATION_ELEMENT session_time COMPOSITION obs_time Clinically relevant date and time where available meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( ( < 404684003 | clinical finding | ) OR ( < 272379006 | event | ) ) , 408729009 | finding context | = ( (< 36692007 | known | ) OR ( << 261665006 | unknown | ) ) , 408731000 | temporal context | = ( ( << 410512000 | current or specified | ) AND ( ! < 410513005 | past | ) ) , 408732007 | subject relationship context | = 410604004 | subject of record | } 2.1.1.3    Finding Observation - Past Field Constraint uid type FINDING_OBSERVATION_ELEMENT session_time COMPOSITION obs_time Clinically relevant date and time where available meaning = 243796009 | situation with explicit context |:

2.1.1.4    Finding Observation - Family History of

 Field
Value

uid
type	FINDING_OBSERVATION_ELEMENT
session_time	COMPOSITION
obs_time	Clinically relevant date and time where available
meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding |\ = ( ( < 404684003 | clinical finding | )\ OR ( < 272379006 | event | ) )\ , 408729009 | finding context |\ = ( ( < 36692007 | known | )\ OR ( << 261665006 | unknown | ) )\ , 408731000 | temporal context | = < 410510008 | temporal context value |\ , 408732007 | subject relationship context | = << 303071001 | person in the family | }

2.1.1.5    Property Observation – Current or past

Field
Constraint

uid
type	PROPERTY_OBSERVATION_ELEMENT
session_time	COMPOSITION
obs_time	Clinically relevant date/time required
value	SOME VALUE - QUANTITY/ORDINAL/CODED
Meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding |\ = ( ( < 363787002 | observable entity | )\ OR ( < 386053000 | evaluation procedure | )\ OR ( < 108252007 | laboratory procedure | ) )\ , = ( ( < 36692007 | known | )\ OR ( << 261665006 | unknown | )\ , 408731000 | temporal context |\ = < 410510008 | temporal context value |\ , 408732007 | subject relationship context | = 410604004 | subject of record | }

2.1.1.6    Property Observation - Current

 Field
Constraint

uid
type	PROPERTY_OBSERVATION_ELEMENT
session_time	COMPOSITION
obs_time	Clinically relevant date/time required
value	SOME VALUE - QUANTITY/ORDINAL/CODED
Meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding |\ = ( ( < 363787002 | observable entity | )\ OR ( < 386053000 | evaluation procedure | )\ OR ( < 108252007 | laboratory procedure | ) )\ , = ( ( < 36692007 | known | )\ OR ( << 261665006 | unknown | )\ , 408731000 | temporal context |\ = ( ( << 410512000 | current or specified | ) AND ( ! < 410513005 | past | ) )\ , 408732007 | subject relationship context | = 410604004 | subject of record | }

2.1.1.7    Property Observation - Past

 Field
Constraint

uid
type	PROPERTY_OBSERVATION_ELEMENT
session_time	COMPOSITION
obs_time	Clinically relevant date/time required
value	SOME VALUE - QUANTITY/ORDINAL/CODED
Meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding |\ = ( ( < 363787002 | observable entity | )\ OR ( < 386053000 | evaluation procedure | )\ OR ( < 108252007 | laboratory procedure | ) )\ , = ( ( < 36692007 | known | )\ OR ( << 261665006 | unknown | )\ , 408731000 | temporal context |\ = ( << 410511007 | current or past | ) AND ( ! < 15240007 | current | ) )\ , 408732007 | subject relationship context | = 410604004 | subject of record | }

2.1.1.8    General Activity - Current

 
Constraint

uid
type	GENERAL_ACTIVITY_ELEMENT
session_time	COMPOSITION
obs_time	Clinically relevant date and time where available
Meaning	= 243796009 | situation with explicit context |: Unknown macro: { 363589002 | associated procedure |  \ = ( ( < 71388002 | procedure | )\ AND ( ! < 386053000 | evaluation procedure | )\ AND ( ! < 108252007 | laboratory procedure | )\ AND ( ! < 432102000 | administration of substance | )\ AND ( ! < 433590000 | administration of substance via specific route | )\ AND ( ! < 33633005 | prescription of drug | )\ AND ( ! < 75658007 | prescription of therapeutic agent | )\ AND ( ! < 103742009 | renewal of prescription | )\ AND ( ! < 243704004 | provision of appliances | )\ AND ( ! < 183253002 | provision of medical equipment | )\ AND ( ! < 404919001 | wheat-free diet | )\ AND ( ! < 223456000 | provision of a special diet | )\ AND ( ! < 440298008 | dispensing of pharmaceutical/biologic product | )\ )\ , 408730004 | procedure context |\  = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) )\ , 408731000 | temporal context |\ = ( ( << 410512000 | current or specified | ) AND ( ! < 410513005 | past | ) )\ , 408732007 | subject relationship context | = 410604004 | subject of record | }

2.1.1.9    General Activity - Past

 Field
Value

uid
type	GENERAL_ACTIVITY_ELEMENT
session_time	COMPOSITION
obs_time	Clinically relevant time where available – prior to COMPOSITION
Meaning	= 243796009 | situation with explicit context |: Unknown macro: { 363589002 | associated procedure |  \ = ( ( < 71388002 | procedure | )\ AND ( ! < 386053000 | evaluation procedure | )\ AND ( ! < 108252007 | laboratory procedure | )\ AND ( ! < 432102000 | administration of substance | )\ AND ( ! < 433590000 | administration of substance via specific route | )\ AND ( ! < 33633005 | prescription of drug | )\ AND ( ! < 75658007 | prescription of therapeutic agent | )\ AND ( ! < 103742009 | renewal of prescription | )\ AND ( ! < 243704004 | provision of appliances | )\ AND ( ! < 183253002 | provision of medical equipment | )\ AND ( ! < 404919001 | wheat-free diet | )\ AND ( ! < 223456000 | provision of a special diet | )\ AND ( ! < 440298008 | dispensing of pharmaceutical/biologic product | )\ )\ , 408730004 | procedure context |\ = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) OR (<< 410537005 | action status unknown | ) AND (! < 385651009 | in progress | ) )\ , 408731000 | temporal context |\ = ( << 410511007 | current or past | ) AND ( ! < 15240007 | current | ) )\ , 408732007 | subject relationship context | = 410604004 | subject of record | }

2.1.1.10 General Activity - Family History of

 Field
Value

uid
type	GENERAL_ACTIVITY_ELEMENT
session_time	COMPOSITION
obs_time	Relevant clinical date and time
Meaning	= 243796009 | situation with explicit context |: Unknown macro: { 363589002 | associated procedure |\ = ( ( < 71388002 | procedure | )\ AND ( ! < 386053000 | evaluation procedure | )\ AND ( ! < 108252007 | laboratory procedure | )\ AND ( ! < 432102000 | administration of substance | )\ AND ( ! < 433590000 | administration of substance via specific route | )\ AND ( ! < 33633005 | prescription of drug | )\ AND ( ! < 75658007 | prescription of therapeutic agent | )\ AND ( ! < 103742009 | renewal of prescription | )\ AND ( ! < 243704004 | provision of appliances | )\ AND ( ! < 183253002 | provision of medical equipment | )\ AND ( ! < 404919001 | wheat-free diet | )\ AND ( ! < 223456000 | provision of a special diet | )\ AND ( ! < 440298008 | dispensing of pharmaceutical/biologic product | )\ )\ , 408730004 | procedure context |\ = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) OR (<< 410537005 | action status unknown | ) AND (! < 385651009 | in progress | ) )\ , 408731000 | temporal context |\ = < 410510008 | temporal context value |\ =  << 303071001 | person in the family | }

2.1.1.11 Investigation Activity - Current

Field
Constraint

uid
type	INVESTIGATION_ACTIVITY_ELEMENT
session_time	COMPOSITION
obs_time	Clinically relevant time where available
Meaning	= ( 243796009 | situation with explicit context |: Unknown macro: { 363589002 | associated procedure |\ = ( ( < 386053000 | evaluation procedure | )\ OR ( < 108252007 | laboratory procedure | )\ OR ( < 363787002 | observable entity | ) )\ , 408730004 | procedure context |\  = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) )  \ , 408731000 | temporal context |\ = ( ( << 410512000 | current or specified | ) AND ( ! < 410513005 | past | ) )\ , 408732007 | subject relationship context | = < 125676002 | person | } )

2.1.1.12 Investigation Activity - Past

Field
Constraint

uid
type	INVESTIGATION_ACTIVITY_ELEMENT
session_time	COMPOSITION
obs_time	Date and time specified or unspecified
Meaning	= 243796009 | situation with explicit context |: Unknown macro: { 363589002 | associated procedure |\ = ( ( < 386053000 | evaluation procedure | )\ OR ( < 108252007 | laboratory procedure | )\ OR ( < 363787002 | observable entity | ) )\ , 408730004 | procedure context | = ( (< 410523001 | post-starting action status | ) OR (<< 385660001 | not done | ) OR (<< 410537005 | action status unknown | ) AND (! < 385651009 | in progress | ) )\ , 408731000 | temporal context |\ = ( << 410511007 | current or past | ) AND ( ! < 15240007 | current | ) )\ , 408732007 | subject relationship context | =  410604004 | subject of record | }

2.2    Secondary Design Patterns

A secondary design pattern describes the semantic relationship between a RECORD_COMPONENT instance that is the subject of the relationship and a RECORD_COMPONENT instance that is the object of the relationship within a Domain Model.  A given relationship may be involved in one or more secondary design patterns; and a given RECORD_COMPONENT may be involved as a subject and / or object in zero or more Secondary Reuse Patterns.

This area of the guidelines is under development and the following sections summarise those limited areas where design guidance can be given.

2.2.1     Finding Observation Links

Findings may be the source or target of any number of COMPONENT_RELATIONSHIP_ELEMENTs. These relationships are used in any case where there is a requirement to indicate or assert an association between two findings or between a finding and any other type of record component.

The SNOMED CT concept  416083004 | has reason  is recommended for use as shown in the following example. No guidance on any other link assertion sub-types is included as a matter of policy pending further study of the whole area for LRA Release 3.

Example: Renal failure due to past history of pyelonephritis

Table:  Chronic renal failure
 Field
Value

uid	f7b5adf0-7e0c-4038-a47f-aa37edaac572
type	FINDING_OBSERVATION_ELEMENT
session_time	COMPOSITION
obs_time	Flavor of null:UNK or DER
Meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 90688005 | chronic renal failure syndrome |\ , 408729009 | finding context | = 410515003 | known present |\ , 408731000 | temporal context | = 15240007 | current |\ , 408732007 | subject relationship context | = 410604004 | subject of record | } Table:  'has reason'  Field Value	uid	7ec1df29-0899-46ed-9044-22cee994b936
type	COMPONENT_RELATIONSHIP_ELEMENT
session_time	COMPOSITION
obs_time	Flavor of null:UNK or DER
Meaning	= 416083004 | has reason |
sourceUid	f7b5adf0-7e0c-4038-a47f-aa37edaac572
targetUid	8be02600-e112-4693-b676-ae6fa477d05b	Table: Past history of pyelonephritis  Field Value	uid	8be02600-e112-4693-b676-ae6fa477d05b
type	FINDING_OBSERVATION_ELEMENT
session_time	COMPOSITION
obs_time	Flavor of null:UNK or DER
Meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 45816000 | pyelonephritis |\ , 408729009 | finding context | = 410515003 | known present |\ , 408731000 | temporal context | = 410513005 | past |\ , 408732007 | subject relationship context | = 410604004 | subject of record | }	2.2.2     Property Observation Links Property observations may be the source or target of any number of COMPONENT_RELATIONSHIP_ELEMENTs. These relationships are used in any case where there is a requirement to indicate or assert an association between two property observations or between a property observations and any other type of record component. Many of the uses of relationships for Property Observation will be similar to those used for finding observations. However, relationships may also be used for several purposes that are specific to (or at least more commonly required with) property observations. Linking a property observation to the activity (e.g. measurement procedure) from which it was derived. Linking a property observation to a specific clinical perspective (e.g. a blood pressure taken during an operative procedure) Linking several property observations into a logical group (e.g. the systolic and diastolic components of a blood pressure). Relating a property observation to a request for an investigation. As already indicated, guidance will be available in a LRA Release 3 revision of this document. 2.2.3     Investigation Links Procedures may be the source or target of any number of COMPONENT_RELATIONSHIP_ELEMENTs. These relationships are used in any case where there is a requirement to indicate or assert an association between two procedures or between a procedure and any other type of record component. The nature of relationship is specified by the meaning field. The time that the relationship was asserted is specified by the session_time field. If the relationship itself has a clinically relevant time this can be specified using the obs_time field. Some uses of relationships are similar for all types of activity: Linking subsidiary parts of more general procedure together (e.g. linking anaesthetic related activities to a surgical procedure). Linking a procedure to finding, problem or disorder it is intended to address (e.g. associating a prescription for antibiotics with a specified infection). Linking records are different stages or preparing for and completing and activity (e.g. request, plan, start and completion). Some relationships are specific to investigation activities: Linking an investigation activity to property observation resulting from that activity. As already indicated, guidance will be available in a LRA Release 3 revision of this document. 2.2.4     Record Artefact Links The following concepts required to support use of record artefacts  Concept Usage	416271009 | has problem member |	A link between a record entry and a problem (represented as a record artefact) of which it forms a part.
416586004 | has problem name |	A link between the record artefact that represent a problem and another record component which provides the current name for that problem.
100999 | has record role |	Proposed addition A link between a record component and a record artefact which asserts a role the record component has in the record as a whole	2.3    Common Patterns of Clinical Recording This section describes common patterns of clinical recording which can be constructed from primary and secondary design patterns, applying additional constraints as necessary. The patterns which are adapted from the common patterns detailed SNOMED CT Bindings for Common Recording Patterns [8], serve as design specifications for LRA Domain Models and many of them are implemented as such.   Each pattern describes its rationale based on common recording and clinical practice and specifies any primary and secondary patterns from which it is constructed.    2.3.1     Problems and Issues 2.3.1.1    Introduction Problems and Issues are needs or related requirements to be resolved or noted, and are perceived as a problem or issue by a patient, carer or a Care Professional. The description of Problems in the NHS Care Record Elements document has been used as the base on which this area has been defined for LRA. A problem or issue may be the reason that the patient seeks help from a Care Professional or may be an ongoing problem which the patient is coping with. This can be either the patient's complaint or the Care Professional's observation, and includes items such as disease states, medical conditions, and responses and reactions to therapies. Whilst a Problem or Issue is a key element of the NHS Care Record, it may be related to information recorded elsewhere. The Problem or Issue will typically be as recalled by the patient or as identified by a Care Professional (e.g. as a Diagnosis or a Finding). As the patient's condition develops, more may be known about a Problem or Issue and this may lead to that Problem or Issue being renamed.  Following the approach used in the Care Record Element document (and by primary care in the UK), a problem is modelled as an aspect of an item of clinical data, in other words the Problem Member is a pointer to where this relevant clinical data has been recorded. The definition of Problems and Issues in the NHS Care Record Elements document covers the tracking of unmet needs, as well as organisation aspects of the medical record. General Practice systems in the UK implement Larry Weed's problem orientated medical record. The representation of problems requires three different types of information and the relationships between them to be represented. The types of information are: The problem header The problem title Problem membership 2.3.1.2    Problem header The Problem header is represented in LRA as a RECORD_ARTEFACT_ELEMENT. There is one problem header for each discrete problem or issue. The header itself does not contain specific clinical information and exists only as a node to which other record components are linked to represent the problem title and problem membership. The meaning field of the record artefact must contain the following fixed expression. 162991000000102 | Problems and Issues | The problem header element acts is a node which represents each problem that appears in the problem list. However, the name of the problem (as shown in the problem list) is carried in a separate record component that is linked to the problem header. This enables the name to change without changing the organisation of other items of information related to the problem. 2.3.1.3    Problem name The problem name is the clinical label currently assigned to a given item in the problem list. The problem name is a record element in its own right and can also be considered as a problem member. It is recognisable as the problem name because it is linked to the problem header by a COMPONENT_RELATIONSHIP_ELEMENT with a meaning field containing the following fixed expression: 416586004 | has problem name | The problem name is usually a clinical finding (such as the name of a disorder) represented by a FINDING_OBSERVATION_ELEMENT. However, where appropriate, a procedure represented using a GENERAL_ACTIVITY_ELEMENT (or another specialisation of ACTIVITY_ELEMENT) may be used to name a problem. Previous sections of this document provided guidance on the use of both of these LRA care record information types. The problem name may change over a period of time. Initially the problem name may be the main complaint as expressed by the patient (e.g. chest pain), and may progress to a specific clinical label (e.g. acute anteroapical myocardial infarction). When the problem is created and each time the problem name changes, the relevant finding is linked to the problem header as the problem name. The previous name is thus replaced but the same finding may remain a valid member of the problem.  The problem name may be any record component that conforms to the Care Components model. The representation of a finding or procedure is not altered by the decision to use it as the name of a problem. 2.3.1.4    Problem members Problem members are any type of record component that are linked to the problem header by a COMPONENT_RELATIONSHIP_ELEMENT with a meaning field containing the following fixed expression: 416271009 | has problem member | The same record component may be a member of more than one problem. 2.3.1.5    Refinement The problem name and problem members may be refined in any way permitted for the relevant focus concept. This includes support for direct lateralisation where this is appropriate. See details and examples in the sections on Clinical Findings. The need for a succinct name to appear in a problem list may limit the practical use of complex post-coordinated expressions as problem names. The problem header must not be refined. 2.3.1.6    Links to problem name and problem members The problem name and problem members are linked to the problem header using instances of the COMPONENT_RELATIONSHIP_ELEMENT which conform to one of the following constraints: Table Problem name relationship  Field Value	uid	c4344375-4e12-42ed-8e5e-822f4cfd987e
type	COMPONENT_RELATIONSHIP_ELEMENT
session_time	COMPOSITION
obs_time	Use clinically significant time where available
meaning	= 416586004 | has problem name |
sourceUid	Refers to the problem header
targetUid	Refers to the problem name	Table Problem member relationship  Field Value	uid	e385b47e-349b-40ef-9e8c-8d9aae49a52b
type	COMPONENT_RELATIONSHIP_ELEMENT
session_time	COMPOSITION
obs_time	Use clinically significant time where available
meaning	= 416271009 | has problem member |
sourceUid	Refers to the problem header
targetUid	Refers to the problem member	At any point in time there will be only one current instance of the problem name relationship. However, there may be any number of active instances of the problem member relationships (and any number of previous problem name relationships). Problem names and problem members are subject to same constraints that would apply to record component of the Care Record Information types.  There is no specific Primary Pattern or other guidance as part of this Problems section of the document. The pattern for Problems and Issues is illustrated in the diagram below. 2.3.1.7    Examples Pattern example: Renal failure problem group This example represents a single problem list entry ("renal failure") with a collection of four other record entries represented as part of the same problem. Table: Problem header  Field Value	uid	53b7c478-29b1-4402-bb26-d657ccbfcbff
type	RECORD_ARTEFACT_ELEMENT
session_time	COMPOSITION
obs_time	10/09/2009 - time 14:25
meaning	= 162991000000102 | Problems and Issues |	Table Chronic renal failure (Problem Name)  Field Value	uid	9ea18251-9595-4cd2-92aa-4b7763a0f27e
type	FINDING_OBSERVATION_ELEMENT
session_time	COMPOSITION
obs_time	10/09/2009 - time 14:25
meaning	= 243796009 | situation with explicit context |:	Unknown macro: { 246090004 | associated finding | = 90688005 | chronic renal failure syndrome |, 408729009 | finding context | = 410515003 | known present |, 408731000 | temporal context | = 15240007 | current |, 408732007 | subject relationship context | = 410604004 | subject of record | }	Table: Problem name relationship  Field Value	uid	146b964b-19da-479a-a32d-4a4f80060ec2
type	COMPONENT_RELATIONSHIP_ELEMENT
session_time	COMPOSITION
obs_time	UNSPECIFIED
meaning	= 416586004 | has problem name |
sourceUid	53b7c478-29b1-4402-bb26-d657ccbfcbff
targetUid	9ea18251-9595-4cd2-92aa-4b7763a0f27e	Table: First Problem member relationship: chronic renal failure  Field Value	uid	feead09d-d953-4141-b558-ca03b61e9b97
type	COMPONENT_RELATIONSHIP_ELEMENT
session_time	COMPOSITION
obs_time	UNSPECIFIED
meaning	= 416271009 | has problem member |
sourceUid	53b7c478-29b1-4402-bb26-d657ccbfcbff
targetUid	9ea18251-9595-4cd2-92aa-4b7763a0f27e	Table: Past history of pyelonephritis  Field Value	uid	265b00d9-5c8d-42d3-a511-a44d7d098370
type	FINDING_OBSERVATION_ELEMENT
session_time	COMPOSITION
obs_time	UNSPECIFIED
meaning	= 243796009 | situation with explicit context |:	Unknown macro: { 246090004 | associated finding | = 45816000 | pyelonephritis | , 408729009 | finding context | = 410515003 | known present | , 408731000 | temporal context | = 410513005 | past | , 408732007 | subject relationship context | = 410604004 | subject of record | } Table Second Problem member relationship: Past history of pyelonephritis  Field Value uid feead09d-d953-4141-b558-ca03b61e9b97 type COMPONENT_RELATIONSHIP_ELEMENT session_time COMPOSITION obs_time UNSPECIFIED meaning = 416271009 | has problem member | sourceUid 53b7c478-29b1-4402-bb26-d657ccbfcbff targetUid 265b00d9-5c8d-42d3-a511-a44d7d098370   Table: history of clinical finding: = blood in urine  Field Value uid 0e3e3e95-b49b-45ba-9fd5-a7a868282119 type FINDING_OBSERVATION_ELEMENT session_time COMPOSITION obs_time UNSPECIFIED meaning = ( 417662000 | history of clinical finding |: 246090004 | associated finding | = 34436003 | blood in urine | ) Table: Third Problem member relationship: history of clinical finding:= blood in urine  Field Value uid d9d725bd-b699-43cc-b3ca-9dc1464e3242 type COMPONENT_RELATIONSHIP_ELEMENT session_time COMPOSITION obs_time UNSPECIFIED meaning = 416271009 | has problem member | sourceUid 53b7c478-29b1-4402-bb26-d657ccbfcbff targetUid 0e3e3e95-b49b-45ba-9fd5-a7a868282119 Table: Systolic Blood pressure  Field Value uid cb86a109-5d0a-4f57-98ef-7acf366d97c8 type PROPERTY_OBSERVATION_ELEMENT session_time 09/07/2009 - time 09:00 obs_time UNSPECIFIED meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 271649006 | systolic blood pressure |\ , 408729009 | finding context | = 410515003 | known present |\ , 408731000 | temporal context | = 15240007 | current |\ , 408732007 | subject relationship context | = 410604004 | subject of record | } value 120 Unit: mm[Hg] Table: Fourth Problem member relationship: Systolic Blood pressure  Field Value uid 05fa2678-c06e-4819-bea8-f07cdd0649bf type COMPONENT_RELATIONSHIP_ELEMENT session_time COMPOSITION obs_time UNSPECIFIED meaning = 416271009 | has problem member | sourceUid 53b7c478-29b1-4402-bb26-d657ccbfcbff targetUid cb86a109-5d0a-4f57-98ef-7acf366d97c8   Table: Diastolic Blood pressure  Field Value uid 92f54432-af4f-4b93-b44c-414ff6c574fb type PROPERTY_OBSERVATION_ELEMENT session_time 09/07/2009 - time 09:00 obs_time UNSPECIFIED meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 271650006 | diastolic blood pressure |\ , 408729009 | finding context | = 410515003 | known present |\ , 408731000 | temporal context | = 15240007 | current |\ , 408732007 | subject relationship context | = 410604004 | subject of record | } value 85 Unit: mm[Hg]   Table: Fifth Problem member relationship: Diastolic Blood pressure  Field Value uid 357d3ffb-a135-4e84-b5ed-c6479dd46233 type COMPONENT_RELATIONSHIP_ELEMENT session_time COMPOSITION obs_time UNSPECIFIED meaning = 416271009 | has problem member | sourceUid 53b7c478-29b1-4402-bb26-d657ccbfcbff targetUid 92f54432-af4f-4b93-b44c-414ff6c574fb 2.3.2     Diagnoses 2.3.2.1    Introduction The definition that follows has been modified from the description of Diagnoses in the NHS Care Record Elements document (v3) document, by the addition of the underlined text, to clarify the distinction between a diagnostic decision and a treatment decision. Diagnoses are decisions about the nature of a condition arrived at as a result of a synthesis of signs, symptoms, investigations (i.e. findings), and theoretical knowledge. Conditions that may be diagnoses include diseases, disorders, syndromes and physiological states such as pregnancy. The recording of a Diagnosis should be seen as being true at a particular point in time. A Care Professional will make a Diagnosis using the information available at that time. Diagnoses will potentially progress over time as new information becomes available. Diagnoses are represented by a pair of related record components. One of these contains the clinically relevant name of the diagnosis (e.g. pyelonepthritis); the other tags this as a diagnosis with a particular status (e.g. primary diagnosis). The diagnosis name is a FINDING_OBSERVATION_ELEMENT which represents the clinical nature of the diagnosis. This component follows the general pattern for representing clinical findings, given later in this guidance document. In common with other finding observations, a diagnosis name is intended to fully represent the clinically relevant nature of a clinical finding. It needs to be distinguished as a diagnosis name of a particular type by appropriate qualification. No terminology guidance can yet be offered in this area pending further study during the LRA Release 3 development phase. 2.3.3     Current Conditions The history of the current condition is an account of the symptoms as experienced by the patient. The informer may be the patient or someone other than the patient (e.g. a parent or carer). The pattern needs to capture detailed history of the current complaint or condition. The questions asked may result in positive or negative responses. It may be necessary to record extensive amounts of data relating to the condition and the anatomical or physiological system that is affected. The main issues in this pattern are the detail to which symptom information is recorded and the requirement to record negative or normal symptoms. This pattern needs to support both current data as well as historical data. Some symptoms may have existed for some time or may have existed at a point in time and are now resolved. Pattern usage therefore extends to the past medical history and system review pattern in that they both record patient history. The history of current conditions findings is represented in LRA using instances of the FINDING_OBSERVATION_ELEMENT class. The clinical focus concept in the meaning field represents the nature of the finding. . The history of the current condition may also contain relevant past history information. This should follow the patterns described in the guidance in this document on Error! Reference source not found.. 2.3.3.1    Instance Examples Table: Patient reported seeing blood in their urine recently  Field Value uid type FINDING_OBSERVATION_ELEMENT session_time 29/06/2009 - time 11:00 obs_time Flavor of null=UNK meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 34436003 | blood in urine |  )\ , 408729009 | finding context | = 410592001 | probably present |\ , 408731000 | temporal context | = 6493001 | recent |\ , 408732007 | subject relationship context | = 410604004 | subject of record | } Table: Patient reported pain in left loin  Field Value uid type FINDING_OBSERVATION_ELEMENT session_time 29/06/2009 - time 10:00 obs_time Flavor of null=UNK meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 271857006 | loin pain |} 2.3.4     Current Medications LRA representation of medications is under development and therefore no guidance can be provided in this version of the guidance. 2.3.5     Review of Systems (admission note on patient's symptoms)   After the presenting history has been taken, a systems review may be undertaken to elicit additional undeclared symptoms. It is usual to review all the systems in a comprehensive history. It is often sufficient to ask a few high level questions to check that each system is asymptomatic, but it may be necessary to ask detailed questions to explore areas where significant history may exist. The pattern needs to capture history details of all the major systems. The questions asked may result in positive or negative responses or may be left unanswered. Depending on whether the patient has relevant symptoms relating to a particular system, it may be necessary to record more or less data about an individual system. This pattern is related to the past medical history and history of the current complaint pattern in that they all record patient history. The main issues in this pattern are the degree to which summary type information is recorded and the requirement to record negative or normal symptoms. Some symptoms may have existed for some time or may have existed at a point in time but may no longer be present. The pattern needs to represent this historical data using the SNOMED CT 'temporal context' attribute and the obs_time information model attribute in a similar way to the 'past medical history' pattern. System review findings are represented using instances of the FINDING_OBSERVATION_ELEMENT class. 2.3.5.1    Primary Design Patterns Used The Review of Systems common recording pattern uses the following primary design patterns: Finding Observation – Current or past Finding Observation - Current Finding Observation - Past 2.3.5.2    Instance Examples History of haematuria: (post-coordinated form) Note: that this is the same representation as example 1 in the 'past medical history' pattern. Field Value uid type FINDING_OBSERVATION_ELEMENT session_time 29/06/2009 - time 10:00 obs_time Null favour = UNK meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 53298000 | haematuria syndrome |, 408729009 | finding context | = 410515003 | known present |, 408731000 | temporal context | =  410513005  | past|} History of haematuria: (pre-coordinated form) Field Value uid type FINDING_OBSERVATION_ELEMENT session_time 29/06/2009 - time 10:00 obs_time Null favour = UNK meaning = 53298000 | haematuria syndrome | No history of cough: Field Value uid type FINDING_OBSERVATION_ELEMENT session_time 29/08/2009 - time 10:00 obs_time Null favour = UNK meaning = 413350009 | finding with explicit context |: Unknown macro: { 246090004 | associated finding | = 49727002 | cough |, 408729009 | finding context | = 410516002 | known absent |, 408731000 | temporal context | =  410589000 | all times past | } 2.3.6     Examination Findings 2.3.6.1    Introduction Clinical examination is the process by which a health care professional investigates the body of a patient for signs of disease. The pattern needs to capture examination details of all the major systems. Depending on whether the patient has relevant findings relating to a particular system it may be necessary to record more or less data about an individual system. 2.3.6.2    Primary Design Patterns Used The Examination Findings common recording pattern uses the following primary design patterns: Finding Observation - Current Finding Observation - Past 2.3.6.3    Instance examples The following example shows the representation of two findings (absence of tenderness in the right loin and severe tenderness in the left loin) and three property observations (a raised temperature and systolic and diastolic blood pressure). Table:  Not tender in right renal area  Field Value uid type FINDING_OBSERVATION_ELEMENT session_time COMPOSITION obs_time 10/07/2009 - time 12:15 meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 102830001 | renal angle tenderness |} Table:  Tender in left renal area  Field Value uid type FINDING_OBSERVATION_ELEMENT session_time COMPOSITION obs_time 10/07/2009 - time 12:15 meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 102830001 | renal angle tenderness |} Table:  Systolic Blood pressure  Field Value uid type PROPERTY_OBSERVATION_ELEMENT session_time 10/07/2009 - time 12:15 obs_time 10/07/2009 - time 12:00 meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 271649006 | systolic blood pressure |, 408729009 | finding context | = 410515003 | known present |, 408731000 | temporal context | = 15240007 | current |, 408732007 | subject relationship context | = 410604004 | subject of record | } value 150 Unit: mm[Hg] Table: Diastolic Blood pressure  Field Value uid type PROPERTY_OBSERVATION_ELEMENT session_time 10/07/2009 - time 12:15 obs_time 10/07/2009 - time 12:00 meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 271650006 | diastolic blood pressure | , 408729009 | finding context | = 410515003 | known present | , 408731000 | temporal context | = 15240007 | current | , 408732007 | subject relationship context | = 410604004 | subject of record | } value 105 Unit: mm[Hg] Table:  Body temp 37.5  Field Value uid 0021df8d-f294-4438-81f7-54a2a45b4274 type PROPERTY_OBSERVATION_ELEMENT(Q) session_time COMPOSITION obs_time 10/07/2009 - time 12:15 meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 386725007 | body temperature |\ , 408729009 | finding context | = 410515003 | known present |\ , 408731000 | temporal context | = 15240007 | current |\ , 408732007 | subject relationship context | = 410604004 | subject of record | } value 37.5 Unit: Cel 2.3.7     Procedure Notes 2.3.7.1    Introduction Procedure note represent contemporaneous records of a procedure. This includes surgical procedures as well as other procedures and the proposed approach is intended to support notes kept at differing levels of detail. In the simplest case, a record of the procedure as a whole is terminology bound and the remainder of the note is represented as narrative text. Where subsidiary information needs to be queried, retrieved and reused this is also captured in the note using terminology bound care record elements (but outside the scope of this guidance document). Procedure notes are related to past records of procedures including past surgical history. Procedure notes are also related to examination findings. Indeed, a detailed procedure note will often include examination findings arising from observations made during the procedure. The procedure as a whole represented as an activity. However, a procedure note may also include finding and property observations. The way in which these are represented should be consistent with the general approach to representation of examination findings. Observations about an organ made during a surgical procedure may be qualitatively different from those made on a routine examination. However, they should be represented using the same types of record component with similar terminology bindings. 2.3.7.2    Primary Design Patterns Used The Procedures Notes common recording pattern uses the following primary design patterns: Finding Observation - Current 2.3.7.3    Refinement Recording information with a specific date and time The actual date and/or time (or period) at or during which the procedure was carried out must be recorded as the obs_time. The 'temporal context' value in the meaning field should be the concept 'specified time' or one of its subtypes. The 'procedure context' must indicate whether the procedure was 'done' (i.e. completed) or is at some other stage (e.g. in progress). For recording information without a specific date see section 4.2.3.1.2. The 'procedure context' must indicate whether the procedure was 'done' (i.e. completed) or is at some other stage (e.g. in progress). A detailed narrative description of the procedure may be included in one or more UNBOUND_ELEMENTs linked to the GENERAL_ACTIVITY_ELEMENT Elements of the detailed procedure note that need to be coded to support separate retrieval, reuse and analysis should be represented by other terminology-bound record components linked to the GENERAL_ACTIVITY_ELEMENT class. These linked elements may be of any of the kinds described in the section of this guidance on Common Types of Clinical Information. For example, an observation made during a procedure should be represented using instances of FINDING_OBSERVATION_ELEMENT or PROPERTY_OBSERVATION_ELEMENT. Guidance on representing the linkage is under study for LRA Release 3. 2.3.8     Past Medical History Past medical history is an account of a patient's past or concurrent medical conditions or problems and is usually confined to major illnesses. This is usually obtained by questioning the patient or a relative. The main issue regarding the representation of past history is the relationship between the SNOMED CT temporal context attribute and the obs_time field of the information model. The SNOMED CT temporal context is only relevant when there is no stated obs_time. If there is a known obs_time then this should always be the actual (or approximate) time and the SNOMED CT temporal context should not change this interpretation. Where the obs_time is known, this should be stated. In these cases, the temporal context may be 'current - specified' or 'past - specified'. In cases where there is no stated obs_time, the SNOMED CT temporal context indicates the time of the observation relative to the session_time (or the best available proxy for the time of recoding). Therefore, when recording past history without an obs_time, the temporal context 'past' indicates the finding was already regarded as in the past at the time of entry (session_time). This pattern is related to clinical findings patterns, including those that are the labels for diagnoses or problems as historical findings, diagnoses and problems, which have become part of the patient's medical history. It is similar to the past surgical history and medication history patterns in its use of the SNOMED CT temporal context attribute. Past medical history is represented using instances of the FINDING_OBSERVATION_ELEMENT class. The clinical focus concept in the meaning field represents the nature of the past medical condition. The session_time represents the time of recording. The obs_time field and the 'temporal context' of the meaning field together represent the fact that this is past rather than current information. This information must be represented using one of the patterns described below. The pattern used to record past information depends on whether the actual or approximate date of occurrence is known and clinically relevant. The pattern used to retrieve past information depends on whether the requirement relates only to information explicitly recorded as past history or also includes information originally entered as current but which is now in the past. 2.3.8.1    Primary Design Patterns Used The Past Medical History common recording pattern uses the following primary design patterns: Finding Observation - Past 2.3.8.2    Examples Specified time in the past Table:  Patient reported seeing blood in their urine  Field Value uid 62eb5afb-4b86-4091-abe9-027997840999 type FINDING_OBSERVATION_ELEMENT session_time 29/06/2009 - time 11:00 obs_time 28/06/2009 Meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 34436003 | blood in urine |\ , 408729009 | finding context | = 410515003 | known present |\ , 408731000 | temporal context | = 4105847003 | past - specified |\ , 408732007 | subject relationship context | = 410604004 | subject of record | } Notes: Other values of | finding context | may be used to indicate uncertainty about whether the conditions specified was present. For example, 410590009 | known possible | would indicate a possible past history of haematuria syndrome). Unspecified time in the past Table: Patient reported seeing blood in their urine   Field Value uid type FINDING_OBSERVATION_ELEMENT session_time 29/06/2009 - time 11:00 obs_time Flavor of null: UNK Meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 34436003 | blood in urine |} No history of haematuria Table: Patient reported never having seen blood in their urine  Field Value uid type FINDING_OBSERVATION_ELEMENT session_time 29/06/2009 - time 11:00 obs_time Flavor of null:UNK Meaning = 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 34436003 | blood in urine |} 2.3.9     Past Surgical History Past surgical history is an account of a patient's past surgical procedures. This is usually obtained by questioning the patient or a relative. This pattern is related to surgical procedures which over time become part of the patient's surgical history. It is also related to the past medical history pattern with which it has close similarities. Items of past surgical history are represented using instances of the GENERAL_ACTIVITY_ELEMENT class. The clinical focus concept in the meaning field represents the nature of the surgical procedure. The session_time represents the time of recording. The obs_time field and the 'temporal context' of the meaning field together represent the fact that this is past rather than current information. For all past surgical history and any other common patterns for past procedures For guidance on recording past procedures with known date and unknown dates and for recording past procedure history see section 4.2.3.2. 2.3.9.1    Primary Design Patterns Used The Past Surgical History common recording pattern uses the following primary design patterns: General Activity - Past Examples History of hip replacement: Table: history of hip replacement-past --not specified Field Value uid type GENERAL_ACTIVITY_ELEMENT session_time 29/06/2009 - time 11:00 obs_time Flavor of null:UNK meaning = 243796009 | situation with explicit context |: Unknown macro: { 363589002 | associated procedure | = 397956004 | prosthetic arthroplasty of the hip |, 408730004 | procedure context | = 385658003 | done |, 408731000 | temporal context | = 410513005 | past | } Table: history of hip replacement-past-specified Field Value uid type GENERAL_ACTIVITY_ELEMENT session_time 29/06/2009 - time 11:00 obs_time Flavor of null:UNK meaning = 243796009 | situation with explicit context |: Unknown macro: { 363589002 | Associated procedure | = 397956004 | prosthetic arthroplasty of the hip |, 408730004 | procedure context | = 385658003 | done |, 408731000 | temporal context | = 410587003 | past - specified| } 2.3.10  Family History This pattern is used to represent significant family history. The pattern is similar to the pattern for past medical history. The only significant difference is that it specifically refers to a family member other than the subject of the record. A similar pattern should be used for representing a history of contact with a person or animal known to have a significant infectious disease. The released data within SNOMED CT contains a pre-coordinated hierarchy for 'family history of' which contains the following first level descendants: 416702002 | family history observation | 416471007 | family history of clinical finding | 297249002 | family history of procedure | 287351000000105 | family history of substance misuse (situation) | 407559004 | family history unknown | 271393002 | family smoking history | 160266009 | no family history of | The family history of observation and finding hierarchies are populated with the more common family history conditions that are of interest to the medical community and the content is modelled so that the normal form of family history of diabetes mellitus is the same as if a post-coordinated expression is created using the situation with explicit context. Note in particular the last concept, which is the root of a hierarchy containing negative family history. Where the required pre-coordinated content is missing in the family history hierarchy, post-coordinated expressions should be created using the rules below. LRA compliant systems must be able to receive, retrieve and reuse family history, based on the SNOMED CT context model representation of family history. In addition to this representation of family member relationships, the LRA reference model has an RELATED_PARTY class. This allows an association between clinical data and specific subjects of information other than the patient. The reference model assumes that the identification of people, organisations and relevant roles of these entities with be provided by PDS and SDS. However, roles that directly impact the meaning of clinical information fall within the scope of this guidance on modelling clinical information. For example, the relationship between a patient and a family member may be expressed as part of a SNOMED CT expression about family history. Therefore, where these roles are represented for an identified entity, LRA requires the relevant SNOMED CT concept to be used. Family history must be represented either as a pre-coordinated concept or as a post-coordinated SNOMED CT expression that conforms to the constraints specified in the following sections. Where required, a specific family member may be identified using information model classes. Most items of family history are represented by instances of the FINDING_OBSERVATION_ELEMENT class. However, if an item of family history refers specifically to a procedure, an instance of the GENERAL_ACTIVITY_ELEMENT class should be used. Where a named member of the family is referenced, this should be through the RELATED_PARTY class, as described in the LRA Technical Model Infrastructure Specification Part 2: Participations LRA document. This representation is additional too (and not a replacement for) the terminology based representation of family history described in the following sections. 2.3.10.1 Primary Design Patterns Used The Family History common recording pattern uses the following primary design patterns: Finding Observation - Family History General Activity - Family History Examples In the example below, the pre-coordinated expression is equivalent to the context dependant post- coordinated expression below it. 160303001 | FH: Diabetes mellitus | Table: Family history of diabetes Field Value| uid | | | type | FINDING_OBSERVATION_ELEMENT | | session_time | 29/06/2009 - time 11:00 | obs_time Flavor of null:UNK meaning 413350009 | finding with explicit context |: Unknown macro: { 246090004 | associated finding | = 73211009 | diabetes mellitus |, 408729009 | finding context | = 410515003 | known present |, 408731000 | temporal context | = 15240007 | current |, 408732007 | subject relationship context | = 303071001 | person in the family | } 2.3.11  Allergies and Adverse Reactions Allergies and intolerances are described in Representation in Electronic Patient Records of Allergic Reactions and Intolerance of Pharmaceutical Products. This document represents an HL7 Version 3 based model which includes terminology requirements. The document distinguishes between 'Recording an ADR or allergic response to an Item of Medication' and 'Recording a clinician's opinion about future risk of (or propensity to) an allergy or other ADR if the patient is exposed to a substance'. The document states the following: It is possible to record allergies using SNOMED CT in a pre-coordinated or post coordinated form. While both methods of recording allergies are possible, the handling of the allergy codes by systems should follow the post-coordinated model. For safety, systems should only use pre-coordinated terms where they are identified and warranted by the supplier to be computationally equivalent to the post-coordinated term bearing in mind their use in other systems. The document also discusses the mapping from pre-coordinated legacy codes, but this process is not within the current scope of this work. Allergy and adverse reaction patterns are related to other clinical findings that involve substances, physical forces or organisms, e.g. poisoning, infections and radiation damage. Allergy and adverse reaction patterns are also related to other conditions where there is a relationship between a manifestation of a disorder and an underlying disorder which for periods of time may not be manifest. Examples of this include epilepsy, sickle cell trait and many genetic dispositions. Allergies and adverse reactions are a source of significant and avoidable ill health. Since they may result from uninformed clinical actions they offer an early opportunity for substantial benefits from effective clinical information systems. Erroneous interpretation of information related to allergies and adverse reactions has a high impact and thus consistent of representation and handling of this information in LRA compliant systems is extremely important. Concerns have been expressed in the past about the appropriateness of SNOMED CT defining relationship for allergies, adverse reactions and substances. Although these have been greatly improved over the last few years it is important to note that defining relationships do not (and are not designed to) convey knowledge about cross-reactivity of different substances. Therefore, post-coordinated representations that explicitly identify the causative (or suspected causative) agent need to be accompanied by and related to appropriate clinical knowledge resources. Both allergy propensity and adverse reactions must be represented using the FINDING_OBSERVATION_ELEMENT class. 2.3.11.1 Refinement Due to the requirements for inter system transfer of data and the patient safety aspects of supporting clinical decision support on this data, the terminology implementation is limited to the post-coordinated representation of both allergy propensity and adverse reactions with a limited number range of focus concepts and a controlled terminology model. Both allergy propensity and adverse reactions must be represented using a post-coordinated refinement that complies with the following general constraint.  ( << 418038007 | propensity to adverse reactions to substance | ) OR ( << 282100009 | adverse reaction to substance | ) ): 246075003 | causative agent | = ( ( < 105590001 | substance | ) OR ( < 373873005 | pharmaceutical / biologic product | ) ) , 246090004 | associated finding | = ( ( 404684003 | clinical finding | ) OR ( 272379006 | event | ) Separate common patterns are defined later in this section for propensity to adverse reactions to substance and adverse reaction to substance event. More specific constraints apply to the causative agent refinement based on the nature of the clinical focus concept. These are specified below. 2.3.11.1.1  Causative agent refinement constraint for drugs ( << 419511003 | propensity to adverse reactions to drug | ) OR ( << 62014003 | adverse reaction to drug | ) ): 246075003 | causative agent | = ( ( ^ 801000001139 | NHS dm+d AMP subset | ) OR ( ^ 701000001134 | NHS dm+d VMP subset | ) OR ( ^ 601000001138 | NHS dm+d VTM subset | ) OR ( ^ 12021000006137 | Drug - allergy and adverse reaction subset | ) 2.3.11.1.2  Causative agent refinement constraint for food substances  ( << 418471000 | propensity to adverse reactions to food | ) OR << 370540009 | adverse reaction to food | )  246075003 | causative agent | = ^ 2001000000137 | Food allergens subset | 2.3.11.1.3  Causative agent refinement constraint for non-food substances  ( << 418038007 | propensity to adverse reactions to substance | ) OR ( 282100009 | adverse reaction to substance | ) 246075003 | causative agent | = ^ 1991000000135 | Non-food substance allergens subset | The agents that may be used to qualify the causative agent attribute of the post-coordinated expressions are described in Representation in Electronic Patient Records of Allergic Reactions and Intolerance of Pharmaceutical Products document. The agents may either be drugs, food allergens, non food allergens or general agents. Agent constraints for general agents (those that are not part of the drug constraint below) are not mandated. It is allowable to use codes outside the constraints; however it should be noted that decision support may not be supported. There is overlap of content between the subsets used for food, non food and drug. Note that it is entirely reasonable for a food to be an ingredient of a drug. Clinical decision support systems should be aware of this when deciding which allergy records to involve in clinical decision support processes. 2.3.11.2 Primary Design Patterns Used The Allergies and Adverse Reactions common recording patterns use the following primary design patterns, refined by explicitly specifying and applying values to the causative agent concept model attribute (as described in section 5.1.1.3): Finding Observation – Current or past Table: Problem name relationship  Field Value| uid | 146b964b-19da-479a-a32d-4a4f80060ec2 | | type | COMPONENT_RELATIONSHIP_ELEMENT | | session_time | COMPOSITION | obs_time UNSPECIFIED meaning = 416586004 | has problem name | sourceUid 53b7c478-29b1-4402-bb26-d657ccbfcbff targetUid 9ea18251-9595-4cd2-92aa-4b7763a0f27e Table: First Problem member relationship: chronic renal failure  Field Value uid feead09d-d953-4141-b558-ca03b61e9b97 type COMPONENT_RELATIONSHIP_ELEMENT session_time COMPOSITION obs_time UNSPECIFIED meaning = 416271009 | has problem member | sourceUid 53b7c478-29b1-4402-bb26-d657ccbfcbff targetUid 9ea18251-9595-4cd2-92aa-4b7763a0f27e Table: Past history of pyelonephritis  Field Value uid 265b00d9-5c8d-42d3-a511-a44d7d098370 type FINDING_OBSERVATION_ELEMENT session_time COMPOSITION obs_time UNSPECIFIED meaning = 243796009 | situation with explicit context |:	Table Second Problem member relationship: Past history of pyelonephritis  Field Value	uid	feead09d-d953-4141-b558-ca03b61e9b97
type	COMPONENT_RELATIONSHIP_ELEMENT
session_time	COMPOSITION
obs_time	UNSPECIFIED
meaning	= 416271009 | has problem member |
sourceUid	53b7c478-29b1-4402-bb26-d657ccbfcbff
targetUid	265b00d9-5c8d-42d3-a511-a44d7d098370	Table: history of clinical finding: = blood in urine  Field Value	uid	0e3e3e95-b49b-45ba-9fd5-a7a868282119
type	FINDING_OBSERVATION_ELEMENT
session_time	COMPOSITION
obs_time	UNSPECIFIED
meaning	= ( 417662000 | history of clinical finding |: 246090004 | associated finding | = 34436003 | blood in urine | )	Table: Third Problem member relationship: history of clinical finding:= blood in urine  Field Value	uid	d9d725bd-b699-43cc-b3ca-9dc1464e3242
type	COMPONENT_RELATIONSHIP_ELEMENT
session_time	COMPOSITION
obs_time	UNSPECIFIED
meaning	= 416271009 | has problem member |
sourceUid	53b7c478-29b1-4402-bb26-d657ccbfcbff
targetUid	0e3e3e95-b49b-45ba-9fd5-a7a868282119	Table: Systolic Blood pressure  Field Value	uid	cb86a109-5d0a-4f57-98ef-7acf366d97c8
type	PROPERTY_OBSERVATION_ELEMENT
session_time	09/07/2009 - time 09:00
obs_time	UNSPECIFIED
meaning	= 243796009 | situation with explicit context |:	Unknown macro: { 246090004 | associated finding | = 271649006 | systolic blood pressure | , 408729009 | finding context | = 410515003 | known present | , 408731000 | temporal context | = 15240007 | current | , 408732007 | subject relationship context | = 410604004 | subject of record | }	value	120 Unit: mm[Hg]	Table: Fourth Problem member relationship: Systolic Blood pressure  Field Value	uid	05fa2678-c06e-4819-bea8-f07cdd0649bf
type	COMPONENT_RELATIONSHIP_ELEMENT
session_time	COMPOSITION
obs_time	UNSPECIFIED
meaning	= 416271009 | has problem member |
sourceUid	53b7c478-29b1-4402-bb26-d657ccbfcbff
targetUid	cb86a109-5d0a-4f57-98ef-7acf366d97c8	Table: Diastolic Blood pressure  Field Value	uid	92f54432-af4f-4b93-b44c-414ff6c574fb
type	PROPERTY_OBSERVATION_ELEMENT
session_time	09/07/2009 - time 09:00
obs_time	UNSPECIFIED
meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 271650006 | diastolic blood pressure |\ , 408729009 | finding context | = 410515003 | known present |\ , 408731000 | temporal context | = 15240007 | current |\ , 408732007 | subject relationship context | = 410604004 | subject of record | }	value	85 Unit: mm[Hg]	Table: Fifth Problem member relationship: Diastolic Blood pressure  Field Value	uid	357d3ffb-a135-4e84-b5ed-c6479dd46233
type	COMPONENT_RELATIONSHIP_ELEMENT
session_time	COMPOSITION
obs_time	UNSPECIFIED
meaning	= 416271009 | has problem member |
sourceUid	53b7c478-29b1-4402-bb26-d657ccbfcbff
targetUid	92f54432-af4f-4b93-b44c-414ff6c574fb	2.3.2     Diagnoses 2.3.2.1    Introduction The definition that follows has been modified from the description of Diagnoses in the NHS Care Record Elements document (v3) document, by the addition of the underlined text, to clarify the distinction between a diagnostic decision and a treatment decision. Diagnoses are decisions about the nature of a condition arrived at as a result of a synthesis of signs, symptoms, investigations (i.e. findings), and theoretical knowledge. Conditions that may be diagnoses include diseases, disorders, syndromes and physiological states such as pregnancy. The recording of a Diagnosis should be seen as being true at a particular point in time. A Care Professional will make a Diagnosis using the information available at that time. Diagnoses will potentially progress over time as new information becomes available. Diagnoses are represented by a pair of related record components. One of these contains the clinically relevant name of the diagnosis (e.g. pyelonepthritis); the other tags this as a diagnosis with a particular status (e.g. primary diagnosis). The diagnosis name is a FINDING_OBSERVATION_ELEMENT which represents the clinical nature of the diagnosis. This component follows the general pattern for representing clinical findings, given later in this guidance document. In common with other finding observations, a diagnosis name is intended to fully represent the clinically relevant nature of a clinical finding. It needs to be distinguished as a diagnosis name of a particular type by appropriate qualification. No terminology guidance can yet be offered in this area pending further study during the LRA Release 3 development phase. 2.3.3     Current Conditions The history of the current condition is an account of the symptoms as experienced by the patient. The informer may be the patient or someone other than the patient (e.g. a parent or carer). The pattern needs to capture detailed history of the current complaint or condition. The questions asked may result in positive or negative responses. It may be necessary to record extensive amounts of data relating to the condition and the anatomical or physiological system that is affected. The main issues in this pattern are the detail to which symptom information is recorded and the requirement to record negative or normal symptoms. This pattern needs to support both current data as well as historical data. Some symptoms may have existed for some time or may have existed at a point in time and are now resolved. Pattern usage therefore extends to the past medical history and system review pattern in that they both record patient history. The history of current conditions findings is represented in LRA using instances of the FINDING_OBSERVATION_ELEMENT class. The clinical focus concept in the meaning field represents the nature of the finding. . The history of the current condition may also contain relevant past history information. This should follow the patterns described in the guidance in this document on Error! Reference source not found.. 2.3.3.1    Instance Examples Table: Patient reported seeing blood in their urine recently  Field Value	uid
type	FINDING_OBSERVATION_ELEMENT
session_time	29/06/2009 - time 11:00
obs_time	Flavor of null=UNK
meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 34436003 | blood in urine |  )\ , 408729009 | finding context | = 410592001 | probably present |\ , 408731000 | temporal context | = 6493001 | recent |\ , 408732007 | subject relationship context | = 410604004 | subject of record | }	Table: Patient reported pain in left loin  Field Value	uid
type	FINDING_OBSERVATION_ELEMENT
session_time	29/06/2009 - time 10:00
obs_time	Flavor of null=UNK
meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 271857006 | loin pain |}	2.3.4     Current Medications LRA representation of medications is under development and therefore no guidance can be provided in this version of the guidance. 2.3.5     Review of Systems (admission note on patient's symptoms)   After the presenting history has been taken, a systems review may be undertaken to elicit additional undeclared symptoms. It is usual to review all the systems in a comprehensive history. It is often sufficient to ask a few high level questions to check that each system is asymptomatic, but it may be necessary to ask detailed questions to explore areas where significant history may exist. The pattern needs to capture history details of all the major systems. The questions asked may result in positive or negative responses or may be left unanswered. Depending on whether the patient has relevant symptoms relating to a particular system, it may be necessary to record more or less data about an individual system. This pattern is related to the past medical history and history of the current complaint pattern in that they all record patient history. The main issues in this pattern are the degree to which summary type information is recorded and the requirement to record negative or normal symptoms. Some symptoms may have existed for some time or may have existed at a point in time but may no longer be present. The pattern needs to represent this historical data using the SNOMED CT 'temporal context' attribute and the obs_time information model attribute in a similar way to the 'past medical history' pattern. System review findings are represented using instances of the FINDING_OBSERVATION_ELEMENT class. 2.3.5.1    Primary Design Patterns Used The Review of Systems common recording pattern uses the following primary design patterns: Finding Observation – Current or past Finding Observation - Current Finding Observation - Past 2.3.5.2    Instance Examples History of haematuria: (post-coordinated form) Note: that this is the same representation as example 1 in the 'past medical history' pattern. Field Value	uid
type	FINDING_OBSERVATION_ELEMENT
session_time	29/06/2009 - time 10:00
obs_time	Null favour = UNK
meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 53298000 | haematuria syndrome |, 408729009 | finding context | = 410515003 | known present |, 408731000 | temporal context | =  410513005  | past|}	History of haematuria: (pre-coordinated form) Field Value	uid
type	FINDING_OBSERVATION_ELEMENT
session_time	29/06/2009 - time 10:00
obs_time	Null favour = UNK
meaning	= 53298000 | haematuria syndrome |	No history of cough: Field Value	uid
type	FINDING_OBSERVATION_ELEMENT
session_time	29/08/2009 - time 10:00
obs_time	Null favour = UNK
meaning	= 413350009 | finding with explicit context |: Unknown macro: { 246090004 | associated finding | = 49727002 | cough |, 408729009 | finding context | = 410516002 | known absent |, 408731000 | temporal context | =  410589000 | all times past | }	2.3.6     Examination Findings 2.3.6.1    Introduction Clinical examination is the process by which a health care professional investigates the body of a patient for signs of disease. The pattern needs to capture examination details of all the major systems. Depending on whether the patient has relevant findings relating to a particular system it may be necessary to record more or less data about an individual system. 2.3.6.2    Primary Design Patterns Used The Examination Findings common recording pattern uses the following primary design patterns: Finding Observation - Current Finding Observation - Past 2.3.6.3    Instance examples The following example shows the representation of two findings (absence of tenderness in the right loin and severe tenderness in the left loin) and three property observations (a raised temperature and systolic and diastolic blood pressure). Table:  Not tender in right renal area  Field Value	uid
type	FINDING_OBSERVATION_ELEMENT
session_time	COMPOSITION
obs_time	10/07/2009 - time 12:15
meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 102830001 | renal angle tenderness |}	Table:  Tender in left renal area  Field Value	uid
type	FINDING_OBSERVATION_ELEMENT
session_time	COMPOSITION
obs_time	10/07/2009 - time 12:15
meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 102830001 | renal angle tenderness |}	Table:  Systolic Blood pressure  Field Value	uid
type	PROPERTY_OBSERVATION_ELEMENT
session_time	10/07/2009 - time 12:15
obs_time	10/07/2009 - time 12:00
meaning	= 243796009 | situation with explicit context |:	Unknown macro: { 246090004 | associated finding | = 271649006 | systolic blood pressure |, 408729009 | finding context | = 410515003 | known present |, 408731000 | temporal context | = 15240007 | current |, 408732007 | subject relationship context | = 410604004 | subject of record | }
value	150 Unit: mm[Hg]	Table: Diastolic Blood pressure  Field Value	uid
type	PROPERTY_OBSERVATION_ELEMENT
session_time	10/07/2009 - time 12:15
obs_time	10/07/2009 - time 12:00
meaning	= 243796009 | situation with explicit context |:	Unknown macro: { 246090004 | associated finding | = 271650006 | diastolic blood pressure | , 408729009 | finding context | = 410515003 | known present | , 408731000 | temporal context | = 15240007 | current | , 408732007 | subject relationship context | = 410604004 | subject of record | }
value	105 Unit: mm[Hg]	Table:  Body temp 37.5  Field Value	uid	0021df8d-f294-4438-81f7-54a2a45b4274
type	PROPERTY_OBSERVATION_ELEMENT(Q)
session_time	COMPOSITION
obs_time	10/07/2009 - time 12:15
meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 386725007 | body temperature |\ , 408729009 | finding context | = 410515003 | known present |\ , 408731000 | temporal context | = 15240007 | current |\ , 408732007 | subject relationship context | = 410604004 | subject of record | }
value	37.5 Unit: Cel	2.3.7     Procedure Notes 2.3.7.1    Introduction Procedure note represent contemporaneous records of a procedure. This includes surgical procedures as well as other procedures and the proposed approach is intended to support notes kept at differing levels of detail. In the simplest case, a record of the procedure as a whole is terminology bound and the remainder of the note is represented as narrative text. Where subsidiary information needs to be queried, retrieved and reused this is also captured in the note using terminology bound care record elements (but outside the scope of this guidance document). Procedure notes are related to past records of procedures including past surgical history. Procedure notes are also related to examination findings. Indeed, a detailed procedure note will often include examination findings arising from observations made during the procedure. The procedure as a whole represented as an activity. However, a procedure note may also include finding and property observations. The way in which these are represented should be consistent with the general approach to representation of examination findings. Observations about an organ made during a surgical procedure may be qualitatively different from those made on a routine examination. However, they should be represented using the same types of record component with similar terminology bindings. 2.3.7.2    Primary Design Patterns Used The Procedures Notes common recording pattern uses the following primary design patterns: Finding Observation - Current 2.3.7.3    Refinement Recording information with a specific date and time The actual date and/or time (or period) at or during which the procedure was carried out must be recorded as the obs_time. The 'temporal context' value in the meaning field should be the concept 'specified time' or one of its subtypes. The 'procedure context' must indicate whether the procedure was 'done' (i.e. completed) or is at some other stage (e.g. in progress). For recording information without a specific date see section 4.2.3.1.2. The 'procedure context' must indicate whether the procedure was 'done' (i.e. completed) or is at some other stage (e.g. in progress). A detailed narrative description of the procedure may be included in one or more UNBOUND_ELEMENTs linked to the GENERAL_ACTIVITY_ELEMENT Elements of the detailed procedure note that need to be coded to support separate retrieval, reuse and analysis should be represented by other terminology-bound record components linked to the GENERAL_ACTIVITY_ELEMENT class. These linked elements may be of any of the kinds described in the section of this guidance on Common Types of Clinical Information. For example, an observation made during a procedure should be represented using instances of FINDING_OBSERVATION_ELEMENT or PROPERTY_OBSERVATION_ELEMENT. Guidance on representing the linkage is under study for LRA Release 3. 2.3.8     Past Medical History Past medical history is an account of a patient's past or concurrent medical conditions or problems and is usually confined to major illnesses. This is usually obtained by questioning the patient or a relative. The main issue regarding the representation of past history is the relationship between the SNOMED CT temporal context attribute and the obs_time field of the information model. The SNOMED CT temporal context is only relevant when there is no stated obs_time. If there is a known obs_time then this should always be the actual (or approximate) time and the SNOMED CT temporal context should not change this interpretation. Where the obs_time is known, this should be stated. In these cases, the temporal context may be 'current - specified' or 'past - specified'. In cases where there is no stated obs_time, the SNOMED CT temporal context indicates the time of the observation relative to the session_time (or the best available proxy for the time of recoding). Therefore, when recording past history without an obs_time, the temporal context 'past' indicates the finding was already regarded as in the past at the time of entry (session_time). This pattern is related to clinical findings patterns, including those that are the labels for diagnoses or problems as historical findings, diagnoses and problems, which have become part of the patient's medical history. It is similar to the past surgical history and medication history patterns in its use of the SNOMED CT temporal context attribute. Past medical history is represented using instances of the FINDING_OBSERVATION_ELEMENT class. The clinical focus concept in the meaning field represents the nature of the past medical condition. The session_time represents the time of recording. The obs_time field and the 'temporal context' of the meaning field together represent the fact that this is past rather than current information. This information must be represented using one of the patterns described below. The pattern used to record past information depends on whether the actual or approximate date of occurrence is known and clinically relevant. The pattern used to retrieve past information depends on whether the requirement relates only to information explicitly recorded as past history or also includes information originally entered as current but which is now in the past. 2.3.8.1    Primary Design Patterns Used The Past Medical History common recording pattern uses the following primary design patterns: Finding Observation - Past 2.3.8.2    Examples Specified time in the past Table:  Patient reported seeing blood in their urine  Field Value	uid	62eb5afb-4b86-4091-abe9-027997840999
type	FINDING_OBSERVATION_ELEMENT
session_time	29/06/2009 - time 11:00
obs_time	28/06/2009
Meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = 34436003 | blood in urine |\ , 408729009 | finding context | = 410515003 | known present |\ , 408731000 | temporal context | = 4105847003 | past - specified |\ , 408732007 | subject relationship context | = 410604004 | subject of record | }	Notes: Other values of | finding context | may be used to indicate uncertainty about whether the conditions specified was present. For example, 410590009 | known possible | would indicate a possible past history of haematuria syndrome). Unspecified time in the past Table: Patient reported seeing blood in their urine   Field Value	uid
type	FINDING_OBSERVATION_ELEMENT
session_time	29/06/2009 - time 11:00
obs_time	Flavor of null: UNK
Meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 34436003 | blood in urine |}	No history of haematuria Table: Patient reported never having seen blood in their urine  Field Value	uid
type	FINDING_OBSERVATION_ELEMENT
session_time	29/06/2009 - time 11:00
obs_time	Flavor of null:UNK
Meaning	= 243796009 | situation with explicit context |: Unknown macro: { 246090004 | associated finding | = ( 34436003 | blood in urine |}	2.3.9     Past Surgical History Past surgical history is an account of a patient's past surgical procedures. This is usually obtained by questioning the patient or a relative. This pattern is related to surgical procedures which over time become part of the patient's surgical history. It is also related to the past medical history pattern with which it has close similarities. Items of past surgical history are represented using instances of the GENERAL_ACTIVITY_ELEMENT class. The clinical focus concept in the meaning field represents the nature of the surgical procedure. The session_time represents the time of recording. The obs_time field and the 'temporal context' of the meaning field together represent the fact that this is past rather than current information. For all past surgical history and any other common patterns for past procedures For guidance on recording past procedures with known date and unknown dates and for recording past procedure history see section 4.2.3.2. 2.3.9.1    Primary Design Patterns Used The Past Surgical History common recording pattern uses the following primary design patterns: General Activity - Past Examples History of hip replacement: Table: history of hip replacement-past --not specified Field Value	uid
type	GENERAL_ACTIVITY_ELEMENT
session_time	29/06/2009 - time 11:00
obs_time	Flavor of null:UNK
meaning	= 243796009 | situation with explicit context |:	Unknown macro: { 363589002 | associated procedure | = 397956004 | prosthetic arthroplasty of the hip |, 408730004 | procedure context | = 385658003 | done |, 408731000 | temporal context | = 410513005 | past | }

Table: history of hip replacement-past-specified
Field
Value

uid
type	GENERAL_ACTIVITY_ELEMENT
session_time	29/06/2009 - time 11:00
obs_time	Flavor of null:UNK
meaning	= 243796009 | situation with explicit context |: Unknown macro: { 363589002 | Associated procedure | = 397956004 | prosthetic arthroplasty of the hip |, 408730004 | procedure context | = 385658003 | done |, 408731000 | temporal context | = 410587003 | past - specified| }

2.3.10  Family History

This pattern is used to represent significant family history.

The pattern is similar to the pattern for past medical history. The only significant difference is that it specifically refers to a family member other than the subject of the record.

A similar pattern should be used for representing a history of contact with a person or animal known to have a significant infectious disease.

The released data within SNOMED CT contains a pre-coordinated hierarchy for 'family history of' which contains the following first level descendants:

• 416702002 | family history observation |
• 416471007 | family history of clinical finding |
• 297249002 | family history of procedure |
• 287351000000105 | family history of substance misuse (situation) |
• 407559004 | family history unknown |
• 271393002 | family smoking history |
• 160266009 | no family history of |

The family history of observation and finding hierarchies are populated with the more common family history conditions that are of interest to the medical community and the content is modelled so that the normal form of family history of diabetes mellitus is the same as if a post-coordinated expression is created using the situation with explicit context. Note in particular the last concept, which is the root of a hierarchy containing negative family history.

Where the required pre-coordinated content is missing in the family history hierarchy, post-coordinated expressions should be created using the rules below. LRA compliant systems must be able to receive, retrieve and reuse family history, based on the SNOMED CT context model representation of family history.

In addition to this representation of family member relationships, the LRA reference model has an RELATED_PARTY class. This allows an association between clinical data and specific subjects of information other than the patient. The reference model assumes that the identification of people, organisations and relevant roles of these entities with be provided by PDS and SDS. However, roles that directly impact the meaning of clinical information fall within the scope of this guidance on modelling clinical information. For example, the relationship between a patient and a family member may be expressed as part of a SNOMED CT expression about family history. Therefore, where these roles are represented for an identified entity, LRA requires the relevant SNOMED CT concept to be used.

Family history must be represented either as a pre-coordinated concept or as a post-coordinated SNOMED CT expression that conforms to the constraints specified in the following sections. Where required, a specific family member may be identified using information model classes.

Most items of family history are represented by instances of the FINDING_OBSERVATION_ELEMENT class. However, if an item of family history refers specifically to a procedure, an instance of the GENERAL_ACTIVITY_ELEMENT class should be used.

Where a named member of the family is referenced, this should be through the RELATED_PARTY class, as described in the LRA Technical Model Infrastructure Specification Part 2: Participations LRA document. This representation is additional too (and not a replacement for) the terminology based representation of family history described in the following sections.

2.3.10.1 Primary Design Patterns Used

The Family History common recording pattern uses the following primary design patterns:

• Finding Observation - Family History
• General Activity - Family History

Examples

In the example below, the pre-coordinated expression is equivalent to the context dependant post- coordinated expression below it.

160303001 | FH: Diabetes mellitus |

Table: Family history of diabetes
Field
Value

uid
type	FINDING_OBSERVATION_ELEMENT
session_time	29/06/2009 - time 11:00
obs_time	Flavor of null:UNK
meaning	413350009 | finding with explicit context |: Unknown macro: { 246090004 | associated finding | = 73211009 | diabetes mellitus |, 408729009 | finding context | = 410515003 | known present |, 408731000 | temporal context | = 15240007 | current |, 408732007 | subject relationship context | = 303071001 | person in the family | }

2.3.11  Allergies and Adverse Reactions

Allergies and intolerances are described in Representation in Electronic Patient Records of Allergic Reactions and Intolerance of Pharmaceutical Products. This document represents an HL7 Version 3 based model which includes terminology requirements. The document distinguishes between 'Recording an ADR or allergic response to an Item of Medication' and 'Recording a clinician's opinion about future risk of (or propensity to) an allergy or other ADR if the patient is exposed to a substance'.

The document states the following:

It is possible to record allergies using SNOMED CT in a pre-coordinated or post coordinated form. While both methods of recording allergies are possible, the handling of the allergy codes by systems should follow the post-coordinated model. For safety, systems should only use pre-coordinated terms where they are identified and warranted by the supplier to be computationally equivalent to the post-coordinated term bearing in mind their use in other systems.

The document also discusses the mapping from pre-coordinated legacy codes, but this process is not within the current scope of this work.

Allergy and adverse reaction patterns are related to other clinical findings that involve substances, physical forces or organisms, e.g. poisoning, infections and radiation damage.

Allergy and adverse reaction patterns are also related to other conditions where there is a relationship between a manifestation of a disorder and an underlying disorder which for periods of time may not be manifest. Examples of this include epilepsy, sickle cell trait and many genetic dispositions.

Allergies and adverse reactions are a source of significant and avoidable ill health. Since they may result from uninformed clinical actions they offer an early opportunity for substantial benefits from effective clinical information systems. Erroneous interpretation of information related to allergies and adverse reactions has a high impact and thus consistent of representation and handling of this information in LRA compliant systems is extremely important.

Concerns have been expressed in the past about the appropriateness of SNOMED CT defining relationship for allergies, adverse reactions and substances. Although these have been greatly improved over the last few years it is important to note that defining relationships do not (and are not designed to) convey knowledge about cross-reactivity of different substances. Therefore, post-coordinated representations that explicitly identify the causative (or suspected causative) agent need to be accompanied by and related to appropriate clinical knowledge resources.

Both allergy propensity and adverse reactions must be represented using the FINDING_OBSERVATION_ELEMENT class.

2.3.11.1 Refinement

Due to the requirements for inter system transfer of data and the patient safety aspects of supporting clinical decision support on this data, the terminology implementation is limited to the post-coordinated representation of both allergy propensity and adverse reactions with a limited number range of focus concepts and a controlled terminology model.

Both allergy propensity and adverse reactions must be represented using a post-coordinated refinement that complies with the following general constraint.

 ( << 418038007 | propensity to adverse reactions to substance | ) OR ( << 282100009 | adverse reaction to substance | ) ):

246075003 | causative agent |

= ( ( < 105590001 | substance | )

OR ( < 373873005 | pharmaceutical / biologic product | ) )

, 246090004 | associated finding | =

( ( 404684003 | clinical finding | )

OR ( 272379006 | event | )

Separate common patterns are defined later in this section for propensity to adverse reactions to substance and adverse reaction to substance event.

More specific constraints apply to the causative agent refinement based on the nature of the clinical focus concept. These are specified below.

2.3.11.1.1  Causative agent refinement constraint for drugs

( << 419511003 | propensity to adverse reactions to drug | ) OR ( << 62014003 | adverse reaction to drug | ) ):

246075003 | causative agent |

= ( ( ^ 801000001139 | NHS dm+d AMP subset | )

OR ( ^ 701000001134 | NHS dm+d VMP subset | )

OR ( ^ 601000001138 | NHS dm+d VTM subset | )

OR ( ^ 12021000006137 | Drug - allergy and adverse reaction subset | )

2.3.11.1.2  Causative agent refinement constraint for food substances

 ( << 418471000 | propensity to adverse reactions to food | ) OR << 370540009 | adverse reaction to food | ) 

246075003 | causative agent | = ^ 2001000000137 | Food allergens subset |

2.3.11.1.3  Causative agent refinement constraint for non-food substances

 ( << 418038007 | propensity to adverse reactions to substance | ) OR ( 282100009 | adverse reaction to substance | )

246075003 | causative agent | = ^ 1991000000135 | Non-food substance allergens subset |

The agents that may be used to qualify the causative agent attribute of the post-coordinated expressions are described in Representation in Electronic Patient Records of Allergic Reactions and Intolerance of Pharmaceutical Products document. The agents may either be drugs, food allergens, non food allergens or general agents.

Agent constraints for general agents (those that are not part of the drug constraint below) are not mandated. It is allowable to use codes outside the constraints; however it should be noted that decision support may not be supported.

There is overlap of content between the subsets used for food, non food and drug. Note that it is entirely reasonable for a food to be an ingredient of a drug. Clinical decision support systems should be aware of this when deciding which allergy records to involve in clinical decision support processes.

2.3.11.2 Primary Design Patterns Used

The Allergies and Adverse Reactions common recording patterns use the following primary design patterns, refined by explicitly specifying and applying values to the causative agent concept model attribute (as described in section 5.1.1.3):

• Finding Observation – Current or past