| ARCHETYPE ID | openEHR-EHR-OBSERVATION.symptom_sign.v0 |
|---|---|
| Concept | Symptom/Sign |
| Description | Reported observation of a physical or mental disturbance in an individual. |
| Use | Use to record details about a single episode of a symptom or reported sign in an individual, as reported by the individual, parent, care-giver or other party. It may be recorded by a clinician as part of a clinical history record as reported to them, observed by the clinician or self-recorded as part of a clinical questionnaire or personal health record. A complete clinical history or patient story may include varying level of details about multiple episodes of an identified symptom or reported sign, as well as multiple symptoms/signs. In the purest sense, symptoms are subjective observations of a physical or mental disturbance and signs are objective observations of the same, as experienced by an individual and reported to the history taker by the same individual or another party. From this logic it follows that we will need two archetypes to record clinical history - one for reported symptoms and another for reported signs. In reality this is impractical as it will require clinical data entry into either one of these models which adds signficant overheads to modellers and those entering data. In addition, there is often overlap in clinical concepts - for example, is previous vomiting or bleeding to be categorised as a symptom or reported sign? In response, this archetype has been specifically designed to proved a single information model that allows for recording of the entire continuum between clearly identifable symptoms and reported signs when recording a clinical history. This archetype has been intended to be used as a generic pattern for all symptoms and reported signs. The 'Specific details' SLOT can be used to extend the archetype to include additional, specific data elements for more complex symptoms or signs. This archetype has been specifically designed to be used in the 'Structured detail' SLOT within the OBSERVATION.story archetype, but can also be used within other OBSERVATION or CLUSTER archetypes and in the 'Associated symptom/sign' or 'Previous episode' SLOT within other instances of this CLUSTER.symptom_sign archetype. Clinicians frequently record the phrase 'nil significant' against specific symptoms or reported signs as an efficient method to indicate that they asked the individual and it was not reported as causing any discomfort or disturbance - effectively used more like a 'normal statement' rather than an explicit exclusion. The 'Nil significant' data element has been deliberately included in this archetype to allow clinicians to record this same information in a simple and effective way in a clinical system. It can be used to drive a user interface, for example if 'Nil significant' is recorded as true then the remaining data elements can be hidden on a data entry screen. This pragmatic approach supports the majority of simple clinical recording requirements around reported symptoms and signs. However if there is a clinical imperative to explicitly record that a Symptom or Sign was reported as not present, for example if it will be used to drive clinical decision support, then it would be preferable to use the CLUSTER.exclusion_symptom_sign archetype. The use of CLUSTER.exclusion_symptom_sign will increase the complexity of template modelling, implementation and querying. It is recommended that the CLUSTER.exclusion_symptom_sign archetype only be considered for use if clear benefit can be identified in specific situations, but should not be used for routine symptom/sign recording. |
| Misuse | Not to be used to record that a symptom or sign was explicitly reported as not present - use CLUSTER.exclusion_symptom_sign carefully for specific purposes where the overheads of recording in this way warrant the additional complexity, and only if the 'Nil significant' in this archetype is not specific enough for recording purposes. Not to be used for recording objective findings as part of a physical examination - use OBSERVATION.exam and related examination CLUSTER archetypes for this purpose. Not to be used for diagnoses and problems that form part of a persisting Problem List - use EVALUATION.problem_diagnosis. |
| Purpose | To record details about a single episode of a reported symptom or sign including context, but not details, of previous episodes if appropriate. |
| References | Common Terminology Criteria for Adverse Events (CTCAE) [Internet]. National Cancer Institute, USA. Available from: http://ctep.cancer.gov/protocolDevelopment/electronic_applications/ctc.htm (accessed 2015-07-13). |
| Copyright | © openEHR Foundation, HiGHmed |
| Authors | Author name: Tony Shannon Organisation: UK NHS, Connecting for Health Email: tony.shannon@nhs.net Date originally authored: 2007-02-20 |
| Other Details Language | Author name: Tony Shannon Organisation: UK NHS, Connecting for Health Email: tony.shannon@nhs.net Date originally authored: 2007-02-20 |
| Other Details (Language Independent) |
|
| Keywords | complaint, symptom, disturbance, problem, discomfort, presenting complaint, presenting symptom, sign |
| Lifecycle | in_development |
| UID | b9dfaccc-56a2-4f06-a3e0-14f96f641f24 |
| Language used | en |
| Citeable Identifier | 1246.145.1309 |
| Revision Number | 0.0.1-alpha |
| protocol | |
| Extension | Extension: Additional information required to capture local content or to align with other reference models/formalisms. For example: local information requirements or additional metadata to align with FHIR or CIMI equivalents. Include: All not explicitly excluded archetypes |
| events | |
| Any event | Any event: Default, unspecified point in time or interval event which may be explicitly defined in a template or at run-time. |
| data | |
| Symptom/Sign name | Symptom/Sign name: The name of the reported symptom or sign. Symptom name should be coded with a terminology, where possible. |
| Nil significant | Nil significant: The identified symptom or sign was reported as not being present to any significant degree. Record as True if the subject of care has reported the symptom as not significant. For example: if the individual has never experienced the symptom it is appropriate to record 'nil significant'; or if the individual commonly experiences the symptom, in some circumstances it may be considered appropriate to record 'nil significant' if the individual has experienced no deviation from their 'normal' baseline. Allowed values: {true} |
| Body site | Body site: Simple body site where the symptom or sign was reported. Occurrences of this data element are set to 0..* to allow multiple body sites to be separated out in a template if desired. This allows for representation of clinical scenarios where a symptom or sign needs to be recorded in multiple locations or identifying both the originating and distal site in pain radiation, but where all of the other attributes such as impact and duration are identical. If the requirements for recording the body site 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 Detailed anatomical location' SLOT in this archetype. If the anatomical location is included in the Symptom name via precoordinated codes, this data element becomes redundant. If the anatomical location is recorded using the 'Structured body site' SLOT, then use of this data element is not allowed - record only the simple 'Body site' OR 'Structured body site', but not both. |
| Structured body site | Structured body site: Structured body site where the symptom or sign was reported. If the anatomical location is included in the Symptom name via precoordinated codes, use of this SLOT becomes redundant. If the anatomical location is recorded using the 'Body site' data element, then use of CLUSTER archetypes in this SLOT is not allowed - record only the simple 'Body site' OR 'Structured body site', but not both. Include: openEHR-EHR-CLUSTER.anatomical_ openEHR-EHR-CLUSTER.anatomical_ openEHR-EHR-CLUSTER.anatomical_ Exclude: All not explicitly included archetypes |
| Description | Description: Narrative description about the reported symptom or sign. |
| Episodicity | Episodicity: Category of this episode for the identified symptom or sign.
|
| Occurrence | Occurrence: Type of occurrence for this symptom or sign?
|
| Episode onset | Episode onset: The onset for this episode of the symptom or sign. While partial dates are permitted, the exact date and time of onset can be recorded, if appropriate. If this symptom or sign is experienced for the first time or is a re-occurrence, this date is used to represent the onset of this episode. If this symptom or sign is ongoing, this data element may be redundant if it has been recorded previously. |
| Onset type | Onset type: Description of the onset of the symptom or sign. The type of the onset can be coded with a terminology, if desired. For example: gradual; or sudden. |
| Duration | Duration: The duration of this episode of the symptom or sign since onset. If 'Date/time of onset' and 'Date/time of resolution' are used in systems, this data element may be calculated, or alternatively, be considered redundant in this scenario. |
| Severity category | Severity category: Category representing the overall severity of the symptom or sign. Defining values such as mild, moderate or severe in such a way that is applicable to multiple symptoms or signs plus allows multiple users to interpret and record them consistently is not easy. Some organisations extend the value set further with inclusion of additional values such as 'Trivial' and 'Very severe', and/or 'Mild-Moderate' and 'Moderate-Severe', adds to the definitional difficulty and may also worsen inter-recorder reliability issues. Use of 'Life-threatening' and 'Fatal' is also often considered as part of this value set, although from a pure point of view it may actually reflect an outcome rather than a severity. In view of the above, keeping to a well-defined but smaller list is preferred and so the mild/moderate/severe value set is offered, however the choice of other text allows for other value sets to be included at this data element in a template. Note: more specific grading of severity can be recorded using the 'Specific details' SLOT. |
| Severity rating | Severity rating: Numerical rating scale representing the overall severity of the symptom or sign. Symptom severity can be rated by the individual by recording a score from 0 (ie symptom not present) to 10.0 (ie symptom is as severe as the individual can imagine). This score can be represented in the user interface as a visual analogue scale. The data element has occurrences set to 0..* to allow for variations such as 'maximal severity' or 'average severity' to be included in a template. Property: Qualified real Units: 0.0..10.0 Limit decimal places: 1 |
| Character | Character: Word or short phrase describing the nature of the symptom or sign. For example: pain could be described as 'gnawing', 'burning', or 'like an electric shock'; a headache could be 'throbbing' or 'constant'. Coding with an external terminology is preferred, where possible. |
| Progression | Progression: Description progression of the symptom or sign at the time of reporting. Occurrences of this data element are set to 0..* to allow multiple types of progression to be separated out in a template if desired - for example, severity or frequency.
|
| Pattern | Pattern: Narrative description about the pattern of the symptom or sign during this episode. For example: pain could be described as constant or intermittent. |
| Modifying factor | Modifying factor: Detail about how a specific factor effects the identified symptom or sign during this episode. |
| Factor | Factor: Name of the modifying factor. Examples of modifying factor: lying on multiple pillows, eating or administration of a specific medication. |
| Effect | Effect: Perceived effect of the modifying factor on the symptom or sign.
|
| Description | Description: Narrative description of the effect of the modifying factor on the symptom or sign. |
| (Precipitating/resolving factor) | (Precipitating/resolving factor): Details about specified factors that are associated with the precipitation or resolution of the symptom or sign. For example: onset of headache occurred one week prior to menstruation; or onset of headache occurred one hour after fall of bicycle. Runtime name constraint:
|
| Factor | Factor: Name of the health event, symptom, reported sign or other factor. For example: onset of another symptom; onset of menstruation; or fall off bicycle. |
| Factor detail | Factor detail: Structured detail about the factor associated with the identified symptom or sign. Include: openEHR-EHR-CLUSTER.health_ openEHR-EHR-CLUSTER.symptom_ |
| Time interval | Time interval: The interval of time between the occurrence or onset of the factor and onset/resolution of the symptom or sign. |
| Description | Description: Narrative description about the effect of the factor on the identified symptom or sign. |
| Impact | Impact: Description of the impact of this symptom or sign. Assessment of impact could consider the severity, duration and frequency of the symptom as well as the type of impact including, but not limited to, functional, social and emotional impact. Occurrences of this data element are set to 0..* to allow multiple types of impact to be separated out in a template if desired. Examples for functional impact from hearing loss may include: 'Difficulty Hearing in Quiet Environment'; 'Difficulty Hearing the TV or Radio'; 'Difficulty Hearing Group Conversation'; and 'Difficulty Hearing on Phone'. |
| Episode description | Episode description: Narrative description about the course of the symptom or sign during this episode. For example: a text description of the immediate onset of the symptom, activities that worsened or relieved the symptom, whether it is improving or worsening and how it resolved over weeks. |
| Specific details | Specific details: Specific data elements that are additionally required to record as unique attributes of the identified symptom or sign. For example: CTCAE grading. Include: All not explicitly excluded archetypes |
| Resolution date/time | Resolution date/time: The timing of the cessation of this episode of the symptom or sign. If 'Date/time of onset' and 'Duration' are used in systems, this data element may be calculated, or alternatively, considered redundant. While partial dates are permitted, the exact date and time of resolution can be recorded, if appropriate. |
| Description of previous episodes | Description of previous episodes: Narrative description of any or all previous episodes. For example: frequency/periodicity - per hour, day, week, month, year; and regularity. May include a comparison to this episode. |
| Number of previous episodes | Number of previous episodes: The number of times this symptom or sign has previously occurred. min: >=0 |
| Previous episodes | Previous episodes: Structured details of the symptom or sign during a previous episode. In linked clinical systems, it is possible that previous episodes are already recorded within the EHR. Systems can allow the clinician to LINK to relevant previous episodes. However in a system or message without LINKs to existing data or with a new patient, additional instances of the symptom archetype could be included here to represent previous episodes. It is recommended that new instances of the Symptom archetype inserted in this SLOT represent one or many previous episodes to this Symptom instance only. Include: openEHR-EHR-CLUSTER.symptom_ |
| Associated symptom/sign | Associated symptom/sign: Structured details about any associated symptoms or signs that are concurrent. In linked clinical systems, it is possible that associated symptoms or signs are already recorded within the EHR. Systems can allow the clinician to LINK to relevant associated symptoms/signs. However in a system or message without LINKs to existing data or with a new patient, additional instances of the symptom archetype could be included here to represent associated symptoms/signs. Include: openEHR-EHR-CLUSTER.symptom_ |
| Comment | Comment: Additional narrative about the symptom or sign not captured in other fields. |
| Other contributors | Hildegunn Siv Aase, Helse Bergen, Norway Grethe Almenning, Bergen kommune, Norway Tomas Alme, DIPS, Norway Anne Pauline Anderssen, Helse Nord RHF, Norway Vebjørn Arntzen, Oslo universitetssykehus HF, Norway (Nasjonal IKT redaktør) Koray Atalag, University of Auckland, New Zealand Silje Ljosland Bakke, Helse Vest IKT AS, Norway (Nasjonal IKT redaktør) Lars Bitsch-Larsen, Haukeland University Hospital, Bergen, Norway Rong Chen, Cambio Healthcare Systems, Sweden Stephen Chu, Queensland Health, Australia Lisbeth Dahlhaug, Helse Midt - Norge IT, Norway Arild Faxvaag, NTNU, Norway Kåre Flø, DIPS ASA, Norway Einar Fosse, UNN HF, Norwegian Centre for Integrated Care and Telemedicine, Norway Samuel Frade, Marand, Portugal Sebastian Garde, Ocean Informatics, Germany Yves Genevier, Privantis SA, Switzerland Gyri Gradek, Senter for medisinsk genetikk og molekylærmedisin, Haukeland Universitetssykehus, Norway Heather Grain, Llewelyn Grain Informatics, Australia Mikkel Gaup Grønmo, FSE, Helse Nord, Norway (Nasjonal IKT redaktør) Dag Hanoa, Oslo universitetssykehus, Norway Knut Harboe, Stavanger Universitetssjukehus, Norway Sam Heard, Ocean Informatics, Australia Kristian Heldal, Telemark Hospital Trust, Norway Andreas Hering, Helse Bergen HF, Haukeland universitetssjukehus, Norway Anca Heyd, DIPS ASA, Norway Erling Are Hole, Helse Bergen, Norway Roar Holm, Helse Vest IKT A/S, Norway Evelyn Hovenga, EJSH Consulting, Australia Tom Jarl Jakobsen, Helse Bergen, Norway Hanne Joensen, Helse Bergen HUS, Norway Gunnar Jårvik, Nasjonal IKT HF, Norway Lars Karlsen, DIPS ASA, Norway Lars Morgan Karlsen, Nordlandssykehuset Bodø, Norway Goran Karlstrom, County Of Värmland, Sweden Shinji Kobayashi, Kyoto University, Japan Nils Kolstrup, Skansen Legekontor og Nasjonalt Senter for samhandling og telemedisin, Norway Elisabeth Kvile, Fysioterapiavdelingen, Haukeland Universitets Sykehus, Norway Siri Laronningen, Kreftregisteret, Norway Sabine Leh, Haukeland University Hospital, Department of Pathology, Norway Heather Leslie, Ocean Informatics, Australia Siv Marie Lien, DIPS ASA, Norway Hallvard Lærum, Direktoratet for e-helse, Norway alberto maldonado, UPV, Spain Luis Marco Ruiz, NST, Spain (Nasjonal IKT redaktør) Ian McNicoll, Ocean Informatics, United Kingdom Lars Ivar Mehlum, Nasjonal IKT HF, Norway Bjørn Næss, DIPS ASA, Norway Andrej Orel, Marand d.o.o., Slovenia Magne Rekdal, DIPS AS, Norway Norwegian Review Summary, Nasjonal IKT HF, Norway Tanja Riise, Nasjonal IKT HF, Norway Jussara Rotzsch, Hospital Alemão Oswaldo Cruz, Brazil Thomas Schopf, University Hospital of North-Norway, Norway Anoop Shah, University College London, United Kingdom Nils Thomas Songstad, UNN HF, BUK, Barneavdelingen., Norway Arild Stangeland, Helse Bergen, Norway Line Sæle, Nasjonal IKT HF, Norway Line Sørensen, Helse Bergen, Norway Rowan Thomas, St. Vincent's Hospital Melbourne, Australia Lene Thoresen, St. Olavs Hospital, Norway Jon Tysdahl, Furst medlab AS, Norway Till Uhlig, Nasjonal kompetansetjeneste for revmatologisk rehabilitering, Revmatologisk avd. , Diakonhjemmet Sykehus, Oslo, Norway John Tore Valand, Haukeland Universitetssjukehus, Norway (Nasjonal IKT redaktør) |
| Translators |
|