- Licence: This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/.
- Custodian Organisation: openEHR Foundation
- Original Namespace: org.openehr
- Original Publisher: openEHR Foundation
- Custodian Namespace: org.openehr
- MD5-CAM-1.0.1: 9f23e120b2c7a218a348e1bb2189aa0a
- PARENT:MD5-CAM-1.0.1: 44D94C2952391723BB72523E4132FF1C
- Original Language: ISO_639-1::en
Coding of the 'Contact type' with a terminology is desirable, where possible. Examples include: pre-employment medical, routine antenatal visit, women's health check, pre-operative assessment, or annual medical check-up.
- Aboriginal and Torres Strait Islander health check
- Aboriginal and Torres Strait Islander health check
- Sharing of health information with relevant healthcare providers
For example: screening if the individual has any issues or concerns about their health and well being.
- Present
- Absent
- Unknown
For example: sleep; mood; diet; or physical activity.
- Stressful life events
- Social connection
- Mood
- Mental health
- Food security
- Housing stability
- Safety at home
- Gambling (self)
- Gambling (others)
- Diet
- Physical activity
- Weight
- Vision
- Hearing
- Teeth
- Sexual health
- Sleep
- Present
- Absent
- Unknown
Coding with an external terminology is optional.
- Diabetes
- Hypertension
- Myocardial infarction
- Stroke
- Kidney disease
- Hearing impairment
- Epilepsy
- Asthma
- COPD
- Rheumatic heart disease
- HBV
- Significant head trauma
- Mental health
- Recurrent cough or chest infections
- Recurrent ear infections/CSOM/(glue ear)/grommets
- Environmental exposure to tobacco smoke (eg at home, in the car)
- Acute rheumatic fever/rheumatic heart disease (in high prevalence setting)
- Growth or development problems
- Headaches or migraines
- Pregnancy complications
- Birth complications
- Problems after birth
- Present
- Depression
- Anxiety
- Feeding/eating
- Present
- Absent
- Unknown
Symptom name should be coded with a terminology, where possible.
- Depression
- Anxiety
- Feeding/eating
For example: onset of headache occurred one week prior to menstruation; or onset of headache occurred one hour after fall of bicycle.
Symptom name should be coded with a terminology, where possible.
For example: onset of headache occurred one week prior to menstruation; or onset of headache occurred one hour after fall of bicycle.
May be used to record a narrative summary of the complete social circumstances or experiences or key aspects of the social summary, which will be supported by additional structured data, or to import textual data from existing/legacy clinical systems. Details of specific structured findings can be included using CLUSTER archetypes in the 'Details' slot.
This information will provide a sense of the level of support, both physically and emotionally, to which an individual may have access.
Coding of the living arrangement with a terminology is preferred, where possible. The value sets for this data element are likely to vary between jurisdictions - it is anticipated that they will usually be set within a use-case specific template. For example: 'lives alone'; 'lives with family'; or 'lives with others'.
For example: employed; unemployed; or not in labour force. Coding with a terminology is desirable, where possible. Detail about each occupation can be recorded within the CLUSTER.occupation_record archetype.
For example: Chief Executive Officer; Carer; or Student. Each of these job titles or roles may be comprised of multiple duties.
Full time equivalent may also be known as 'FTE'. For example: 0.5; 50 %; or "part time".
Proportion- Unitary
- Percent
Coded Text- Full-time
- Part-time
At implementation, it is assumed that if an associated occupation record is added or updated then this date will also be updated.
Coding with a terminology is desirable, where possible. For example: the ISCED classification, such as upper secondary vocational education; post-secondary non-tertiary vocational education; Bachelor’s or equivalent level, professional; Doctoral or equivalent level, academic; post-secondary non-tertiary vocational education; or never attended an educational program.
At implementation, it is assumed that if an associated education record is added or updated then this date will also be updated.
The scope of food security includes access to food that is adequate in quantity and nutritional quality; culturally acceptable; safe; and acquired in socially acceptable ways.
- Food security
- Marginal food security
- Low food security
- Very low food security
- Never smoked
- Current smoker
- Former smoker
Use this data element to record a narrative description of the tobacco smoking habits for this individual or to incorporate unstructured tobacco smoking information from existing or legacy clinical systems into an archetyped format.
- Never smoked
- Current smoker
- Former smoker
Use this data element to record a narrative description of the tobacco smoking habits for this individual or to incorporate unstructured tobacco smoking information from existing or legacy clinical systems into an archetyped format.
Can be a partial date, for example, only a year. For example, this date could represent when the individual commenced smoking every Friday night or at parties.
- Cigarettes
- Hand-rolled cigarettes
- Cigars
- Pipe
- Waterpipe
- Coded Text
- Daily
- Non-daily
Text
For example: the number of 'sticks' or 'full pipes' per day or per week. This data element is redundant if a value is recorded for 'Typical use(mass)'.
>=0; >=0
Units:
- 1/d
- 1/wk
This data element will typically be used for pipes and hand-rolled cigarettes and is redundant if a value is recorded for 'Typical use (units)'.
>=0; >=0; >=0; >=0
Units:
- g/d
- g/wk
- [oz_av]/d
- [oz_av]/wk
>=0
Can be a partial date, for example, only a year. This date could be used by decision support guidance to determine if the individual is at risk of relapse, for example in the first 12 months since quitting.
This data element does not take into account the amount of tobacco smoked. It may be used to calculate the 'Smoking index'.
>=0 yr
The definition of a pack can be recorded in the protocol of this archetype using the 'Pack definition' data element.
>=0
- Current drinker
- Former drinker
- Lifetime non-drinker
Use this data element to record a narrative description of alcohol drinking habits for this individual or to incorporate unstructured alcohol drinking information from existing or legacy clinical systems into an archetyped format.
- Current drinker
- Former drinker
- Lifetime non-drinker
Use this data element to record a narrative description of alcohol drinking habits for this individual or to incorporate unstructured alcohol drinking information from existing or legacy clinical systems into an archetyped format.
For example: '2' as the second episode within a sequence of episodes; or 'Pregnancy with twins' if describing the alcohol consumption during a health event such as during a specific pregnancy.
Count>=1- Text
Can be a partial date, for example, only a year.
Can be a partial date, for example, only a year. This data field will be empty if the episode is current and ongoing.
The typical pattern of use can be made more granular by coding with a terminology or a local value set in a template.
- Coded Text
- Daily
- Non-daily
- Text
Quantity0..7; 0..31; 0..365
Units:- 1/wk
- 1/mo
- 1/a
Interval of QuantityLower constraint: 0..7; 0..31; 0..365
Units:- 1/wk
- 1/mo
- 1/a
Upper constraint: 0..7; 0..31; 0..365
Units:- 1/wk
- 1/mo
- 1/a
0..7; 0..31
Units:
- 1/wk
- 1/mo
>=0; >=0; >=0
Units:
- 1/d
- 1/wk
- 1/mo
>=0
For example: alcohol consumed as a hangover remedy eg 'hair of the dog'.
Can be a partial date, for example, only a year. This date could be used by decision support guidance to determine if the individual is at risk of relapse, for example in the first 12 months since quitting.
Coding with an external terminology is preferred, where possible.
- Never used
- Current user
- Former user
- Current user
- Former user
- Never used
Use this data element to record a narrative description only where the structured data does not adequately reflect the use of contraception for this woman or to incorporate unstructured information from existing or legacy clinical systems into an archetyped format.
- Coded Text
- Predominantly Breastfed
- Predominantly Formula
- Mixed
- Text
If commenced at birth, which will be recorded as 0 days, weeks or months, then this could be captured or displayed in a system as 'Birth'.
>=P0Y
Units:
- Year
- Month
- Week
- Day
Units:
- Year
- Month
- Week
- Day
Units:
- Month
- Week
- Day
Units:
- Year
- Month
For example: passive smoking or industrial noise.
- Environmental exposure to tobacco smoke (eg at home, in the car, etc)
- Breast screening
- Scheduled
- Completed
- Not done
- Unknown
- Declined
Partial dates are allowed.
Coding of the identified 'Condition' with a terminology is desirable, where possible.
- Pregnancy
- Breastfeeding
Decision support would typically raise alerts for 'Active' and ignore a 'Resolved' or 'Refuted' precaution. Clinical systems may choose not to display Precaution entries with a 'Refuted' status in the Precaution list. However, 'Refuted' may be useful for reconciliation of the Precaution list or when communicating between systems. Some implementations may choose to make this field mandatory. 'Resolved' may be used variably across systems, depending on clinical use and context. The free text data type will allow for local variation by enabling other value sets to be applied to this data element in a template - in this situation it is recommended that values should be coded using a terminology.
- Active
- Resolved
Clinical systems might represent this data element by the term 'Gravida' on a clinical form.
0..100
Parity includes all pregnancies that are carried after the fetus is considered viable, as defined in the 'Definition of viability data' element. Stillbirths, late abortions, and all live births are included in the assessment of Parity. In cases of multiple pregnancies, parity is only increased with birth of the last fetus.
0..100
The date of conception will be recorded elsewhere in the health record, for example as part of the record for an IVF procedure.
The details about the menstrual cycle will be recorded elsewhere in the health record, usually captured using the OBSERVATION.menstruation archetype.
Each ultrasound and estimated gestation pair will be captured as a separate instance of this CLUSTER.
Only one 'Agreed EDD' is appropriate at any one time. If the agreed EDD needs to be revised then this should be captured in a new revision of this archetype within a health record.
Clear delineation between the scope of a problem versus a diagnosis is not easy to achieve in practice. For the purposes of clinical documentation with this archetype, problem and diagnosis are regarded as a continuum, with increasing levels of detail and supportive evidence usually providing weight towards the label of 'diagnosis'.
Coding of the name of the problem or diagnosis with a terminology is preferred, where possible.
Coding of the name of the anatomical location with a terminology is preferred, where possible. Use this data element to record precoordinated anatomical locations. If the requirements for recording the anatomical location are determined at run-time by the application or require more complex modelling such as relative locations then use the CLUSTER.anatomical_location or CLUSTER.relative_location within the 'Structured anatomical location' SLOT in this archetype. Occurrences for this data element are unbounded to allow for clinical scenarios such as describing a rash in multiple locations but where all of the other attributes are identical. If the anatomical location is included in the Problem/diagnosis name via precoordinated codes, this data element becomes redundant.
This data element is the only mandated data point in this archetype and should be used as the primary data point to record an anatomical location with a commonly used name. It is strongly recommended that 'Body site name' be recorded as specifically as is anatomically possible. For example: record 'upper eyelid' rather than recording 'eyelid' with 'upper' as a qualifier; 'fifth rib' rather than 'rib' with a numeric qualifier. Use the other data elements for laterality, aspect, region and anatomical line to provide more detail. This data element should be coded with a terminology capable of triggering decision support, where possible - an appropriate termset for use here could comprise individual concepts or a list of precoordinated terms. Free text should be used only if there is no appropriate terminology available. If body site name is already identified in the parent archetype, then this data element may be redundant. Alternatively, a use case has been identified where the value may be duplicated into this element to support semantic querying using this archetype, rather than the data element within the parent.
Use to increase precision of identification of the body site, if required. For example, the upper right quadrant or McBurney's point on the abdominal wall or interphalangeal joint of the great toe. If the 'Body site name' data element uses pre-coordinated terms that include the specific site, then this data element is redundant.
If the identified body site has no laterality, this data element should not have a value. If the 'Body site name' data element uses pre-coordinated terms that include laterality, then this data element is redundant.
- Left
- Right
Partial dates are acceptable. If the subject of care is under the age of one year, then the complete date or a minimum of the month and year is necessary to enable accurate age calculations - for example, if used to drive decision support. Data captured/imported as "Age at time of clinical recognition" should be converted to a date using the subject's date of birth.
If severity is included in the Problem/diagnosis name via precoordinated codes, this data element becomes redundant. Note: more specific grading of severity can be recorded using the Specific details SLOT.
- Coded Text
- Mild
- Moderate
- Severe
- Text
The Active/Inactive and Current/Past data elements have similar clinical impact but represent slightly different semantics. Both are actively used in different clinical settings, but usually not together. If a Current/Past qualifier is recorded, then this data element is likely to be redundant. An exception where a condition can be current but inactive is asthma that is not causing acute symptoms.
- Active
- Inactive
Coding of the specific procedure with a terminology is preferred, where possible.
Substances include, but are not limited to: a therapeutic substance administered correctly at an appropriate dosage for the individual; food; material derived from plants or animals; or venom from insect stings.
Optional[{source=openEHR,FHIR}]
Both an individual substance and a substance class are valid entries in 'Substance'. A substance may be a compound of simpler substances, for example a medicinal product. If the value in 'Substance' is an individual substance, it may be duplicated in 'Specific substance'. It is strongly recommended that both 'Substance' and 'Specific substance' be coded with a terminology capable of triggering decision support, where possible. For example: Snomed CT, DM+D, RxNorm, NDFRT, ATC, New Zealand Universal List of Medicines and Australian Medicines Terminology. Free text entry should only be used if there is no appropriate terminology available.
Optional[{source=openEHR,FHIR,DAM}]
Decision support would typically raise alerts for 'Suspected', 'Likely', 'Confirmed', and ignore a 'Refuted' reaction. Clinical systems may choose not to display Adverse reaction entries with a 'Refuted' status in the Adverse Reaction List. However, 'Refuted' may be useful for reconciliation of the adverse reaction list or when communicating between systems . Some implementations may choose to make this field mandatory. 'Resolved' may be used variably across systems, depending on clinical use and context - there appears to be differing opinion whether this should still be used to raise potential alerts or to display in an Adverse Reaction List. The free text data type will allow for local variation by enabling other value sets to be applied to this data element in a template - in this situation it is recommended that values should be coded using a terminology.
Optional[{source=FHIR, DAM}]
- Coded Text
- Suspected
- Likely
- Confirmed
- Resolved
- Refuted
- Text
This can be regarded as a predictive judgement of a 'worst case scenario'. In most contexts 'Low' would be regarded as the default value.
Optional[{source=DAM, openEHR}]
- Low
- High
- Indeterminate
For example: including reason for flagging a 'Criticality' of 'High risk'; and instructions related to future exposure or administration of the Substance, such as administration within an Intensive Care Unit or under corticosteroid cover.
Optional[{source=openEHR}]
Optional[{source=openEHR,FHIR,DAM}]
Manifestation can be expressed as a single word, phrase or brief description. For example: nausea, rash. 'No reaction'may be appropriate where a previous reaction has been noted but the reaction did not re-occur after further exposure. It is preferable that 'Manifestation' should be coded with a terminology, where possible. The values entered here may be used to display on an application screen as part of a list of adverse reactions, as recommended in the UK NHS CUI guidelines. Terminologies commonly used include, but are not limited to, SNOMED-CT or ICD10.
Optional[{source=FHIR, openEHR,DAM}]
Note: maps to recordedDate in FHIR.
Optional[{source=openEHR, FHIR, DAM}]
This is not limited to activities performed based on medication orders from clinicians, but could also include for example taking over the counter medication.
For example: 'Atenolol 100mg' or 'Tenormin tablets 100mg'. It is strongly recommended that the 'Medication item' is coded with a terminology capable of triggering decision support, where possible. The extent of coding may vary from the simple name of the medication item through to structured details about the actual medication pack used. Free text entry should only be used if there is no appropriate terminology available.
For example: 'tablet', 'capsule', 'cream', 'infusion fluid' or 'inhalation powder'. Coding of the form with a terminology is preferred, where possible. Medicines catalogues may differentiate between administrable form 'solution for injection' and product form 'powder for solution for injection'. The recorded form will depend on the exact context of use but administrable form is likely to be used in most instances.
In some cases, as for liquid or semisolid medications, the denominator of the strength ratio is a physical quantity, for example 2 mg/5 ml. In some of these cases the denominator also reflects the actual volume of the component: 5 ml in the previous example. In this case the 'Strength (concentration)' would be 0.4 mg/ml. In other cases, where the strength involves a denominator which is not a physical quantity, for example 4 mg/tablet, the denominator is expressed as a unitary value '1' with a unit of '1', and 'tablet' is carried in the 'Unit of presentation' element. This arrangement was chosen to align with the approach adopted by the ISO IDMP standard for medication catalogues.
For example: For a presentation strength of '300 µg/0.3 ml', the strength numerator value is '300'. For a presentation strength of '100 mg/tablet', the strength numerator value is '100'.
>=0
The strength numerator is usually recorded using mass, volume or arbitrary units. For example: 'mg', 'ml', 'IU'. For a presentation strength of '300 µg/0.3 ml', the strength numerator unit is 'µg'. For a presentation strength of '100 mg/tablet', the strength numerator value is 'mg'.
For example: For a presentation strength of '300 µg/0.3 ml', the strength denominator value is '0.3'. For a presentation strength of '100 mg/tablet', the strength denominator value is '1'.
>=0
The strength denominator is usually recorded using mass or volume units. For example: 'g', 'ml'. For a presentation strength of '300 µg/0.3 ml', the strength denominator unit is 'ml'. For a presentation strength of '100 mg/tablet', the strength denominator unit is '1'. For this example, the 'Unit of presentation' element is used to record the presentation unit of the medication, 'tablet'.
For example: 'tablet', 'capsule', 'puff', 'inhalation'. In most cases, like for tablets and capsules, the unit of presentation is identical to the Form. For some presentations such as inhalers, the Form may be 'inhalation powder', 'inhalation aerosol' or 'inhaler' while the unit of presentation is 'inhalation', 'puff', or 'dose'.
This element is used for liquid or semisolid medications, or medications intended to be diluted in a liquid before administration. For example: '10 mg/ml', '20 mg/g', '5 %', '10,000 SQ-U/ml'.
For example: '2 tablets at 6pm' or '20mg three times per day'. Please note: this cluster allows multiple occurrences to enable representation of a complete set of dose patterns for a single dose direction.
For example: 1, 1.5, 0.125 or 1-2, 12.5-20.5
- Quantity>=0
- Interval of QuantityLower constraint: >=0
Upper constraint: >=0
For example: 'tablet','mg'. Coding of the dose unit with a terminology is preferred, where possible.
For example: "4 times per day" or "3 to 4 times per hour".
- Quantity>=1; >=1; >=1; >=1
Units:- 1/d
- 1/min
- 1/s
- 1/h
- Interval of QuantityLower constraint: >=1; >=1; >=1; >=1
Units:- 1/d
- 1/min
- 1/s
- 1/h
Upper constraint: >=1; >=1; >=1; >=1
Units:- 1/d
- 1/min
- 1/s
- 1/h
For example: "Every 4 hours" or "Every 4 to 6 hours".
PT0S..PT24H
Units:
- Hour
- Minute
- Second
Termed 'PRN' ("pro re nata", latin: "as the situation arises") or 'PN' ("per necessare", latin: "when required") in some cultures.
Comment: For example: 'oral', 'intravenous', or 'topical'. Coding of the route with a terminology is preferred, where possible. Multiple potential routes may be specified.
This is not limited to activities performed based on medication orders from clinicians, but could also include for example taking over the counter medication.
For example: 'Atenolol 100mg' or 'Tenormin tablets 100mg'. It is strongly recommended that the 'Medication item' is coded with a terminology capable of triggering decision support, where possible. The extent of coding may vary from the simple name of the medication item through to structured details about the actual medication pack used. Free text entry should only be used if there is no appropriate terminology available.
For example: 'tablet', 'capsule', 'cream', 'infusion fluid' or 'inhalation powder'. Coding of the form with a terminology is preferred, where possible. Medicines catalogues may differentiate between administrable form 'solution for injection' and product form 'powder for solution for injection'. The recorded form will depend on the exact context of use but administrable form is likely to be used in most instances.
In some cases, as for liquid or semisolid medications, the denominator of the strength ratio is a physical quantity, for example 2 mg/5 ml. In some of these cases the denominator also reflects the actual volume of the component: 5 ml in the previous example. In this case the 'Strength (concentration)' would be 0.4 mg/ml. In other cases, where the strength involves a denominator which is not a physical quantity, for example 4 mg/tablet, the denominator is expressed as a unitary value '1' with a unit of '1', and 'tablet' is carried in the 'Unit of presentation' element. This arrangement was chosen to align with the approach adopted by the ISO IDMP standard for medication catalogues.
For example: For a presentation strength of '300 µg/0.3 ml', the strength numerator value is '300'. For a presentation strength of '100 mg/tablet', the strength numerator value is '100'.
>=0
The strength numerator is usually recorded using mass, volume or arbitrary units. For example: 'mg', 'ml', 'IU'. For a presentation strength of '300 µg/0.3 ml', the strength numerator unit is 'µg'. For a presentation strength of '100 mg/tablet', the strength numerator value is 'mg'.
For example: For a presentation strength of '300 µg/0.3 ml', the strength denominator value is '0.3'. For a presentation strength of '100 mg/tablet', the strength denominator value is '1'.
>=0
The strength denominator is usually recorded using mass or volume units. For example: 'g', 'ml'. For a presentation strength of '300 µg/0.3 ml', the strength denominator unit is 'ml'. For a presentation strength of '100 mg/tablet', the strength denominator unit is '1'. For this example, the 'Unit of presentation' element is used to record the presentation unit of the medication, 'tablet'.
For example: 'tablet', 'capsule', 'puff', 'inhalation'. In most cases, like for tablets and capsules, the unit of presentation is identical to the Form. For some presentations such as inhalers, the Form may be 'inhalation powder', 'inhalation aerosol' or 'inhaler' while the unit of presentation is 'inhalation', 'puff', or 'dose'.
This element is used for liquid or semisolid medications, or medications intended to be diluted in a liquid before administration. For example: '10 mg/ml', '20 mg/g', '5 %', '10,000 SQ-U/ml'.
For example: '2 tablets at 6pm' or '20mg three times per day'. Please note: this cluster allows multiple occurrences to enable representation of a complete set of dose patterns for a single dose direction.
For example: 1, 1.5, 0.125 or 1-2, 12.5-20.5
- Quantity>=0
- Interval of QuantityLower constraint: >=0
Upper constraint: >=0
For example: 'tablet','mg'. Coding of the dose unit with a terminology is preferred, where possible.
For example: "4 times per day" or "3 to 4 times per hour".
- Quantity>=1; >=1; >=1; >=1
Units:- 1/d
- 1/min
- 1/s
- 1/h
- Interval of QuantityLower constraint: >=1; >=1; >=1; >=1
Units:- 1/d
- 1/min
- 1/s
- 1/h
Upper constraint: >=1; >=1; >=1; >=1
Units:- 1/d
- 1/min
- 1/s
- 1/h
For example: "Every 4 hours" or "Every 4 to 6 hours".
PT0S..PT24H
Units:
- Hour
- Minute
- Second
Termed 'PRN' ("pro re nata", latin: "as the situation arises") or 'PN' ("per necessare", latin: "when required") in some cultures.
Comment: For example: 'oral', 'intravenous', or 'topical'. Coding of the route with a terminology is preferred, where possible. Multiple potential routes may be specified.
This field can be used to record a summary or the conclusion of all the findings, for unstructured family history information recorded in clinical records, or to import textual data from existing/legacy clinical systems.
This field can be used to record a summary or the conclusion of all the findings, for unstructured family history information recorded in clinical records, or to import textual data from existing/legacy clinical systems.
The data elements in this cluster will relate to the individual identified either by name or by alias. Repeat the use of the cluster for other family members.
For example: 'Aunt Susan' or 'Susan Smith'. However, for privacy reasons this may not be appropriate for recording, sharing or public display and in this situation the 'Alias' should be used.
To be used to assist in distinguishing one individual from multiple family members with identical relationships. For example, the label to distinguish one specific sister from three known sisters might be 'eldest sister' 'sister with the red hair' or 'sister #1'.
For example: mother, step-father, maternal grandmother, or paternal uncle. Coding of the relationship with a terminology is preferred, where possible and including specification of maternal and paternal as required.
Record as 'True' if family member is deceased.
Age of death can be useful if the problem/diagnosis which caused their death is being considered as a risk factor for the subject of the health record. For example: death of mother from breast cancer at young age significally increases the risk of breast cancer in a daughter.
Date of death may be useful in some situations in which the month of death may trigger decision support or identify groupings of disease. For example: environmental allergens triggering respiratory exaccerbations; or events such as Christmas.
If more detail is required, suggest using EVALUATION.problem_diagnosis or the ACTION.procedure archetype and specifying the 'Subject of Care' as the family member, rather than the subject of the health record.
Coding of the family member's problem or diagnosis with a terminology is preferred, where possible. May link from this data element to a detailed record of a Problem/Diagnosis using the EVALUATION.problem_diagnosis archetype with the Subject of Care set to the family member, not to the patient.
- Diabetes
- Heart disease
- Cancer
- Mental health
- [...]
For health problems with multiple occurrences, this describes the first nown occurrence.
- Coded Text
- Direct cause or closely related
- Unrelated
- Indeterminate
- Text
May be used to record a narrative summary of the complete clinical examination or key aspects of clinical examination findings, which will be supported by structured data. Details of specific structured findings can be included using CLUSTER archetypes in the 'Examination Detail' slot. This data element may be used to capture legacy data that is not available in a structured format.
Coding of the system or structure examined with a terminology is preferred, where possible.
- Heart
Coding of the system or structure examined with a terminology is preferred, where possible.
- Left ear
- Right ear
Coding of the system or structure examined with a terminology is preferred, where possible.
- Mouth
Coding of the system or structure examined with a terminology is preferred, where possible.
- Both eyes
Coding of the system or structure examined with a terminology is preferred, where possible.
- Left eye
- Right eye
- Present
- Absent
A test result may be for a single analyte, or a group of items, including panel tests. It is strongly recommended that 'Test name' be coded with a terminology, for example LOINC or SNOMED CT. For example: 'Glucose', 'Urea and Electrolytes', 'Swab', 'Cortisol (am)', 'Potassium in perspiration' or 'Melanoma histopathology'. The name may sometimes include specimen type and patient state, for example 'Fasting blood glucose' or include other information, as 'Potassium (PNA blood gas)'.
- POCT Hb
The value for this element is normally supplied in a specialisation, in a template or at run-time to reflect the actual analyte. For example: 'Serum sodium', 'Haemoglobin'. Coding with an external terminology is strongly recommended, such as LOINC, NPU, SNOMED CT, or local lab terminologies.
Optional[{fhir_mapping=Observation.code, hl7v2_mapping=OBX.3}]
- Haemoglobin
For example '7.3 mmol/l', 'Raised'. The 'Any' data type will need to be constrained to an appropriate data type in a specialisation, a template or at run-time to reflect the actual analyte result. The Quantity data type has reference model attributes that include flags for normal/abnormal, reference ranges and approximations - see https://specifications.openehr.org/releases/RM/latest/data_types.html#_dv_quantity_class for more details.
Optional[{fhir_mapping=Observation.value[x], hl7v2_mapping=OBX.2, OBX.5, OBX.6, OBX.7, OBX.8}]
>=0 g/dl
For example: 'Pattern suggests significant renal impairment'. The content of the conclusion will vary, depending on the investigation performed. This conclusion should be aligned with the coded 'Test diagnosis'.
True if the test was performed directly at Point-of-Care (POCT).
Height is measured with the individual in a standing position and body length in a recumbent position.
0..1000; 0..250
Units:
- cm
- in
0..1000; 0..2000; 0..1000000
Units:
- kg
- lbm
- g
0..500; 0..400
Units:
- cm
- in
Body Mass Index is a calculated ratio describing how an individual's body weight relates to the weight that is regarded as normal, or desirable, for the individual's height.
0..1000; 0..1000
Units:
- kg/m²
- [lb_av]/[in_i]2
Most commonly, use of the term 'blood pressure' refers to measurement of brachial artery pressure in the upper arm.
0..1000 mmHg
0..1000 mmHg
0..1000 /min
0..200 /min
0..100; 30..200
Units:
- °C
- °F
- Percent
0..12
0..27
Coding of 'Health risk' with a terminology is preferred, where possible. Free text should be used only if there is no appropriate terminology available. For example: risk of cardiovascular disease, with risk factors of hypertension and hypercholesterolaemia.
- Blood borne virus infection
There may be multiple variations on the assessment of risk. The Choice data type allows for recording of the assessment as either free text or value sets (such as low, medium or hig). The proportion data type allows recording of a percentage, a ratio or a fraction. The quantity data type allows recording of a decimal number.
- Text
- Proportion
- QuantityUnits:
This data element may be thought redundant if the data is recorded and stored using COMPOSITIONs within a closed clinical system. However if this information is extracted from its original COMPOSITION context, for example, to be included in another document or message then the temporal context is effectively removed. This 'Last updated' data element has been explicitly added to allow the critical temporal data to be kept alongside the clinical data in all circumstances. It is assumed that the clinical system can copy the date from the COMPOSITION to reduce the need for duplication of data entry by the clinician.
This is not limited to activities performed based on medication orders from clinicians, but could also include for example taking over the counter medication.
For example: 'Atenolol 100mg' or 'Tenormin tablets 100mg'. It is strongly recommended that the 'Medication item' is coded with a terminology capable of triggering decision support, where possible. The extent of coding may vary from the simple name of the medication item through to structured details about the actual medication pack used. Free text entry should only be used if there is no appropriate terminology available.
For example: 'tablet', 'capsule', 'cream', 'infusion fluid' or 'inhalation powder'. Coding of the form with a terminology is preferred, where possible. Medicines catalogues may differentiate between administrable form 'solution for injection' and product form 'powder for solution for injection'. The recorded form will depend on the exact context of use but administrable form is likely to be used in most instances.
In some cases, as for liquid or semisolid medications, the denominator of the strength ratio is a physical quantity, for example 2 mg/5 ml. In some of these cases the denominator also reflects the actual volume of the component: 5 ml in the previous example. In this case the 'Strength (concentration)' would be 0.4 mg/ml. In other cases, where the strength involves a denominator which is not a physical quantity, for example 4 mg/tablet, the denominator is expressed as a unitary value '1' with a unit of '1', and 'tablet' is carried in the 'Unit of presentation' element. This arrangement was chosen to align with the approach adopted by the ISO IDMP standard for medication catalogues.
For example: For a presentation strength of '300 µg/0.3 ml', the strength numerator value is '300'. For a presentation strength of '100 mg/tablet', the strength numerator value is '100'.
>=0
The strength numerator is usually recorded using mass, volume or arbitrary units. For example: 'mg', 'ml', 'IU'. For a presentation strength of '300 µg/0.3 ml', the strength numerator unit is 'µg'. For a presentation strength of '100 mg/tablet', the strength numerator value is 'mg'.
For example: For a presentation strength of '300 µg/0.3 ml', the strength denominator value is '0.3'. For a presentation strength of '100 mg/tablet', the strength denominator value is '1'.
>=0
The strength denominator is usually recorded using mass or volume units. For example: 'g', 'ml'. For a presentation strength of '300 µg/0.3 ml', the strength denominator unit is 'ml'. For a presentation strength of '100 mg/tablet', the strength denominator unit is '1'. For this example, the 'Unit of presentation' element is used to record the presentation unit of the medication, 'tablet'.
For example: 'tablet', 'capsule', 'puff', 'inhalation'. In most cases, like for tablets and capsules, the unit of presentation is identical to the Form. For some presentations such as inhalers, the Form may be 'inhalation powder', 'inhalation aerosol' or 'inhaler' while the unit of presentation is 'inhalation', 'puff', or 'dose'.
This element is used for liquid or semisolid medications, or medications intended to be diluted in a liquid before administration. For example: '10 mg/ml', '20 mg/g', '5 %', '10,000 SQ-U/ml'.
For example: '2 tablets at 6pm' or '20mg three times per day'. Please note: this cluster allows multiple occurrences to enable representation of a complete set of dose patterns for a single dose direction.
For example: 1, 1.5, 0.125 or 1-2, 12.5-20.5
- Quantity>=0
- Interval of QuantityLower constraint: >=0
Upper constraint: >=0
For example: 'tablet','mg'. Coding of the dose unit with a terminology is preferred, where possible.
For example: "4 times per day" or "3 to 4 times per hour".
- Quantity>=1; >=1; >=1; >=1
Units:- 1/d
- 1/min
- 1/s
- 1/h
- Interval of QuantityLower constraint: >=1; >=1; >=1; >=1
Units:- 1/d
- 1/min
- 1/s
- 1/h
Upper constraint: >=1; >=1; >=1; >=1
Units:- 1/d
- 1/min
- 1/s
- 1/h
For example: "Every 4 hours" or "Every 4 to 6 hours".
PT0S..PT24H
Units:
- Hour
- Minute
- Second
Termed 'PRN' ("pro re nata", latin: "as the situation arises") or 'PN' ("per necessare", latin: "when required") in some cultures.
Comment: For example: 'oral', 'intravenous', or 'topical'. Coding of the route with a terminology is preferred, where possible. Multiple potential routes may be specified.
The 'Topic' could identify a single piece of information or a single skill, or it may be the name of a training course or program that may be delivered over multiple sessions or visits. The name may indicate that the education was transferred to a group or the individual.
- Screen use
- Physical activity and exercise
- Mental health and wellbeing
- Carer support
- Safety/risky behaviours
- Safe sex/contraception
- Smoking cessation
- Substance use/harm minimisation
- Oral and dental health
- Healthy eating, including breastfeeding
- Sugary drinks
- Physical activity and exercise
- Screen use
- Environmental exposure to harmful elements eg tobacco smoke
- Sun protection
- Safe sleeping practices
- Developmental milestones – including language and hearing
- Parenting advice
- Care of teeth and gums
- Mental health and wellbeing
- Carer support
- Social support and services
- [...]
Clear delineation between the scope of a problem versus a diagnosis is not easy to achieve in practice. For the purposes of clinical documentation with this archetype, problem and diagnosis are regarded as a continuum, with increasing levels of detail and supportive evidence usually providing weight towards the label of 'diagnosis'.
Coding of the name of the problem or diagnosis with a terminology is preferred, where possible.
Coding of the name of the anatomical location with a terminology is preferred, where possible. Use this data element to record precoordinated anatomical locations. If the requirements for recording the anatomical location are determined at run-time by the application or require more complex modelling such as relative locations then use the CLUSTER.anatomical_location or CLUSTER.relative_location within the 'Structured anatomical location' SLOT in this archetype. Occurrences for this data element are unbounded to allow for clinical scenarios such as describing a rash in multiple locations but where all of the other attributes are identical. If the anatomical location is included in the Problem/diagnosis name via precoordinated codes, this data element becomes redundant.
This data element is the only mandated data point in this archetype and should be used as the primary data point to record an anatomical location with a commonly used name. It is strongly recommended that 'Body site name' be recorded as specifically as is anatomically possible. For example: record 'upper eyelid' rather than recording 'eyelid' with 'upper' as a qualifier; 'fifth rib' rather than 'rib' with a numeric qualifier. Use the other data elements for laterality, aspect, region and anatomical line to provide more detail. This data element should be coded with a terminology capable of triggering decision support, where possible - an appropriate termset for use here could comprise individual concepts or a list of precoordinated terms. Free text should be used only if there is no appropriate terminology available. If body site name is already identified in the parent archetype, then this data element may be redundant. Alternatively, a use case has been identified where the value may be duplicated into this element to support semantic querying using this archetype, rather than the data element within the parent.
Use to increase precision of identification of the body site, if required. For example, the upper right quadrant or McBurney's point on the abdominal wall or interphalangeal joint of the great toe. If the 'Body site name' data element uses pre-coordinated terms that include the specific site, then this data element is redundant.
If the identified body site has no laterality, this data element should not have a value. If the 'Body site name' data element uses pre-coordinated terms that include laterality, then this data element is redundant.
- Left
- Right
Partial dates are acceptable. If the subject of care is under the age of one year, then the complete date or a minimum of the month and year is necessary to enable accurate age calculations - for example, if used to drive decision support. Data captured/imported as "Age at time of clinical recognition" should be converted to a date using the subject's date of birth.
If severity is included in the Problem/diagnosis name via precoordinated codes, this data element becomes redundant. Note: more specific grading of severity can be recorded using the Specific details SLOT.
- Coded Text
- Mild
- Moderate
- Severe
- Text
The Active/Inactive and Current/Past data elements have similar clinical impact but represent slightly different semantics. Both are actively used in different clinical settings, but usually not together. If a Current/Past qualifier is recorded, then this data element is likely to be redundant. An exception where a condition can be current but inactive is asthma that is not causing acute symptoms.
- Active
- Inactive
Useful if multiple types of recommendations are made at the same time, and within the same data set.
- Stressful life events
- Social connection
- Food security
- Housing stability
- Gambling (self)
- Gambling (others)
- Safety at home
- Mood
- Mental health
- Diet
- Weight
- Physical activity
- Screen time
- Vision
- Hearing
- Teeth
- Sexual health
- Sleep
May be coded, using a terminology, if required.
For example: reduced blood pressure; 10 kilogram weight loss; or diabetes control.
For example: Hypertension; Obesity; or Diabetes Type 2.
Note: this date may not be the date of recording of the goal.
Coding with a terminology is preferred, where possible. For example: target weight achieved; poor diabetes control; or successful completion.
- Text
- Coded Text
- Achieved
- Partially achieved
- Not achieved
Multiple targets are allowed. In some situations, only one target will be required. In some clinical scenarios the goal may require a multifaceted approach with a number of targets contributing to a successful goal outcome. In addition, some goals may require incremental targets to be set sequentially during a period of time.
For example: systolic blood pressure under 140 mmHg; lose 10 kilograms; or HBA1c in the normal range.
Coding of the 'Service name' with a coding system is desirable, if available. For example: 'referral' to an endocrinologist for diabetes management.
- Full blood count
- HbA1c or blood glucose level
- Serum lipids
- Kidney function including eGFR
- Liver function tests
- ACR
- HIV
- HBV
- HCV
- Chlamydia
- Gonorrhoea
- Syphilis screening
- Trichomoniasis
- Hb
Coding of the clinical indication with a terminology is preferred, where possible. This data element allows multiple occurrences. For example: 'Angina' or 'Type 1 Diabetes mellitus'.
Coding of the 'Service name' with a coding system is desirable, if available. For example: 'referral' to an endocrinologist for diabetes management.
Coding of the 'Service type' with a coding system is desirable, if available. If the 'Service name' was coded, it is possible for this data point to be derived from the code. For example: biochemistry or microbiology laboratory, ultrasound or CT imaging.
This data point should be used to describe the named service in more detail, including how it should be delivered, patient concerns and issues that might be encountered in delivering the service.
Coding of the 'Reason for request' with a coding system is desirable, if available. This data element allows multiple occurrences to enable the user to record a multiple responses, if required. For example: 'manage diabetes complications'.
For example: 'The patient's diabetes has recently become more difficult to stabilise and renal function is deteriorating'.
Coding of the clinical indication with a terminology is preferred, where possible. This data element allows multiple occurrences. For example: 'Angina' or 'Type 1 Diabetes mellitus'.
For example: a referral to a specialist may have the intent of the specialist taking over responsibility for care of the patient, or it may be to provide a second opinion on treatment options. Coding of the 'Intent' with a coding system is desirable, if available. This data element allows multiple occurrences to enable the user to record a multiple responses, if required.
Specific definitions of emergency and urgent will vary between clinical contexts, clinical systems and the nature of the request itself, so have not been defined in this archetype. If explicit timing is required then the Service period should be clearly stated.
- Coded Text
- Emergency
- Urgent
- Routine
- Text
This data element allows for recording of the timing for a single service, either as a date and time, a date ranges or a text descriptor which can allow for 'next available. In practice, clinicians will often think in terms of ordering services as approximate timing, for example: review in 3 months, 6 months or 12 months. As clinical systems need more exact parameters to operate on, this '3 months' will usually be converted to an exact date 3 months from the date of recording and stored using this data element. If complex timing or sequences of timings are required, use the CLUSTER.service_direction archetype within the 'Complex timing' SLOT and this data element becomes redundant.
Date/Time
Interval of Date/Time- Text
This date/time is the equivalent to the earliest possible date for service delivery. For example: sometimes a certain amount of time must pass before a service can be performed, for example some procedures can only be performed once the patient has stopped taking medications for a specific amount of time.
This date/time is the equivalent to the latest possible date for service delivery or to the date of expiry for this request. For example: a service may be required to be completed before another event, such as scheduled surgery.
Record as TRUE to record explicity that the request has no expiry date. For example: commonly required for a referral to a specialist for long-term or lifelong care.
Record as TRUE if additional information has been identified and will be forwarded when available. For example: pending test results.
Coding of the 'Service name' with a coding system is desirable, if available. For example: 'referral' to an endocrinologist for diabetes management.
- GP follow-up
- GP review of results of investigations
- Aboriginal health worker/practitioner follow-up
- Practice nurse follow-up
- Dentist
- Medication review
- Smoking cessation
- Audiology
- Dietician
- Physiotherapist or exercise program
- Parenting programs/support services
- Social and emotional wellbeing/mental health
Coding of the 'Service type' with a coding system is desirable, if available. If the 'Service name' was coded, it is possible for this data point to be derived from the code. For example: biochemistry or microbiology laboratory, ultrasound or CT imaging.
This data element allows for recording of the timing for a single service, either as a date and time, a date ranges or a text descriptor which can allow for 'next available. In practice, clinicians will often think in terms of ordering services as approximate timing, for example: review in 3 months, 6 months or 12 months. As clinical systems need more exact parameters to operate on, this '3 months' will usually be converted to an exact date 3 months from the date of recording and stored using this data element. If complex timing or sequences of timings are required, use the CLUSTER.service_direction archetype within the 'Complex timing' SLOT and this data element becomes redundant.
- Date/Time
- Interval of Date/Time
- Text
Coding of the 'Service name' with a coding system is desirable, if available. For example: 'referral' to an endocrinologist for diabetes management.
- Clinical review
- Influenza vaccination
- Asthma plan/cycle of care
- Diabetes cycle of care
- Care plan review
- Cervical screening
- 715 review
Coding of the 'Service type' with a coding system is desirable, if available. If the 'Service name' was coded, it is possible for this data point to be derived from the code. For example: biochemistry or microbiology laboratory, ultrasound or CT imaging.
This data element allows for recording of the timing for a single service, either as a date and time, a date ranges or a text descriptor which can allow for 'next available. In practice, clinicians will often think in terms of ordering services as approximate timing, for example: review in 3 months, 6 months or 12 months. As clinical systems need more exact parameters to operate on, this '3 months' will usually be converted to an exact date 3 months from the date of recording and stored using this data element. If complex timing or sequences of timings are required, use the CLUSTER.service_direction archetype within the 'Complex timing' SLOT and this data element becomes redundant.
- Date/Time
- Interval of Date/Time
- Text