= openEHR参照モデル Entry型についてのFAQ = openEHR Reference Model - Entry Types FAQ [[TOC]] Contents * What are 'Entries'? * What Entry types are there in openEHR? * Why not just have one Entry type? * A possible confusion: Observations and Evaluations o Some Examples - basic o Grey-zone Examples == Entryって何？ == What are 'Entries'? openEHRの参照モデルでは，CEN EN13606-1やHL7 CDAのモデルと同じように'Entry'型が「臨床上の表現(clinical statement)」に対応したモデルです。EntryはEHRのコンポジションや文書といった「実データ」を保持します。Entryは（しばしばコード化された）一つのデータのみを保持します。つまり診断や，もっと一般的なのもとしては定義された構造による様々なデータポイント，たとえばアプガースコアやBarthel係数，出生前検査などです。openEHRではEHRはEntryは5つの型に分類され，もうひとつ総称型EntryがCEN 13606の構造として将来マッピングされ，広くつかわれることとになるでしょう。 In the openEHR Reference Model, as well as in models like CEN EN13606-1 and HL7 CDA, the 'Entry' type in the model corresponds to a 'clinical statement'. Entries hold the 'hard data' of the EHR Composition or document. Entries may contain only a single (often coded) datum, such as a diagnosis, or more usually, they contain a number of data points in a defined structure, e.g. Apgar result, Barthel index, ante-natal visit. In openEHR the Entry has been specialised into 5 types in the EHR and one generic entry for mapping in future to CEN 13606 structures should these become widely used. == どのようなEntry型がopenEHRにありますか？ == What Entry types are there in openEHR? openEHR参照モデルでは6種類のEntry型を定義しています。このうち5つは[http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/ehr_im.pdf openEHR EHR情報モデル(the openEHR EHR Information Model)]に記載されていて、以下の図に示されています。 The openEHR Reference Model defines 6 kinds of Entry. Five of these are found in the openEHR EHR Information Model, and are illustrated below. [[Image(design_of_ehr-5.png)]] [http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html 詳細なUML] [http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html Detailed UML] * OBSERVATION(観察） - 患者の世界からの情報を記録するためのものです。臨床家や検査室などで計測されたもののすべてや、患者の症候やイベント、関連するものについての報告です。 * EVALUATION(評価) - 見解や(通常は臨床における）状態を要約するためのものです。問題点や診断，リスク評価，目的など一般的には「観察」された根拠に基づくものです。 * INSTRUCTION(指示) - オーダ-，処方，指示などの要求された介入を表すためのものです. * ACTION(行動) - 行動を記録するためのもので，「指示」されたことを行うためのものです。例えば，薬剤管理や手順などがそうです。 * ADMIN_ENTRY(管理記録） - 管理のためのイベントを記録するためのものです。例えば，入院，退院や承諾などです。 * OBSERVATION - for recording information from the patient's world - anything measured by a clinician, a laboratory or by them, or reported by the patient as a symptom, event or concern * EVALUATION - for recording opinions and summary statements (usually clinical), such as problems, diagnoses, risk assessments, goals etc that are generally based on Observation evidence * INSTRUCTION - for recording orders, prescriptions, directives and any other requested interventions * ACTION - for recording actions, which may be due to Instructions, e.g. drug administrations, procedures etc. * ADMIN_ENTRY - for recording administrative events, e.g. admission, discharge, consent etc 6番目の型はGENERIC_ENTRYとよばれるもので，レガシーなものをマッピングするためや，CEN EN13606，HL7 CDAメッセージとリレーショナルデータベースを統合した構造で表すために設計されています。 The 6th type is called GENERIC_ENTRY, and is designed for mapping into and out of legacy and integration structures such as CEN EN13606, HL7 CDA, message and relational databases. The UML model of this type is here; it is documented in the openEHR Integration IM. All of these types are extremely generic and archetypes are used to define the specific business/domain content models under each of these types - see archetype mindmap for examples. [top] Why not just have one Entry type? The types of information generated in the clinical process are qualitatively different; they have different relationships to time, to actors, and consequently have different structures. There have been various models of these over the years, from Lawrence Weed's POMR "SOAP" headings to more recent models such as the Danish G-EPJ. The openEHR model uses a similar set to some of these models. The exact types used in openEHR are based on an analysis of the process that creates health information. The following diagram illustrates the process metaphor and a more formal definition of the information categories it generates. Entry types * observation: information created by an act of observation, measurement, questioning, or testing of the patient or related substance (tissue, urine etc), including by the patient himself (e.g. taking own blood glucose measurement), in short, the entire stream of information captured by the investigator, used to characterise the patient system; * opinion: thoughts of the investigator about what the observations mean, and what to do about them, created during the evaluation activity, including all diagnoses, assessments, speculative plans, goals; * instruction: opinion-based instructions sufficiently detailed so as to be directly executable by investigator agents (people or machines), in order to effect a desired intervention (including obtaining a sample for further investigation, as in a biopsy); * action: a record of intervention actions that have occurred, due to instructions or otherwise; * administrative event: a record of a business event occurring within the administrative context, such as admission, booking, referral, discharge etc. The various Entry types have differing structural models due to the fact that they record qualitatively different things. See the EHR Information Model and UML for details. The need to support basic patterns When clinical modellers are building content models of common things they record, the various Entry types provide help. For example, the Observation type includes a 'History of Events' structure for its data, enabling the time of any observation to be recorded in a standard way. If there are no available Entry types, clinical content is likely to be built in an ad hoc, non-interoperable way, and it is also significantly more arduous. For example, if we try to create an archetype for the concept of 'apgar recording', it is quite easy using the openEHR Observation type because the History structure provides exactly what is needed to represent the samples in time. A further refinement is a clear separation of the data, state and protocol, i.e. the primary values being measured (BP for example), the patient state (exertion, position) and the method of measurement (instrument etc). Two people independently modelling the same content, such as 'BP measurement' using archetype tools based on the above model of Observation are almost guaranteed to model the timing and separation of values, patient state and methd in the same way, since it is provided in the reference model. Similar considerations apply to recordings of typical things like orthostatic blood pressure (requiring 2 samples), time-based data coming from vital signs monitors and so on. An archetype model of glucose tolerance test is interesting - it needs both a time base (3 samples) and the 'state' attribute on Events to indicate the patient state at each point - after 8 hour fast, after 75mg glucose challenge etc. Without any of this basic support in the reference model, the archetype author, as well as software developers are forced to come up with solutions to the basic patterns of history-of-events and the data/state/protocol pattern. These patterns are so ubiquitous in medicine and science in general that they have been included in the openEHR reference model. Other universal patterns occur in the Instruction and Action types, enabling the standardised recording of various dates, times, participations and changes of state of Instructions. [top] The problem of 'status' Another issue well known in the recording of information in health systems is that of 'status' of information: is it the actual value X, a negation of X, a risk of X, no/low risk of X, family history of X, fear of X, recommendation to do P, past procedure P, scheduled to have P...? Undifferentiated statements recorded using index terms (often coded) e.g. 'cancer' etc risk confusing automatic processing, such as by query engines, decision support and NLP modules (commonly used on narrative data). We can go a long way toward solving the possible confusion by seeing that all of these statement have sensible mappings into the Entry types used in openEHR (and other similar models for that matter, e.g. the Danish G-EPJ). Some examples of disease/condition recordings: Phenomenon Entry type measured/observed actual value of X Observation of X no/not X Observation of excluded P or types of X, e.g. allergies family history of X Evaluation that patient is at risk of X no family history of X Evaluation that X is an excluded risk risk of X Evaluation that patient is at risk of X no risk of X Evaluation that patient is not at risk of X fear of X Observation of Fear, with X mentioned in the description Examples of intervention-related recordings: Intervention Entry type P distant past/unmanaged/passively documented Observation of P present in patient P recent past Action of P having been done to/for patient P proposed Evaluation, subtype Proposal of P suggested/likely for patient P ordered Instruction of P for patient for some particular date in the future. The use of the openEHR Entry types significantly reduces the risk that in querying 'family history of X' can be mistaken for X being observed in the patient, since the former is an Evaluation, while the latter is an Observation. Family history of X and diagnosis of X are both Evaluations, but distinguished by archetype (family history, diagnosis). Similarly, a past hip replacement cannot be confused with a proposed or booked one, since both the Entry types and archetypes will be different. Querying for clinical opinions is easy: it will be Evaluations only, or a subset, determined by archetype. [top] A possible confusion: Observations and Evaluations In the openEHR Entry model, two types are used for 'observations' and 'evaluations'. As with any general terms, these terms are overloaded, causing confusion for some people. In the openEHR model, these two types have a clear purpose. The Observation type is used to record any information derived from the world outside the clinician's head (or any other clinical reasoning device) - i.e. any kind of phenomemon or state of interest to the clinical investigator in the care of the patient. Accordingly, the design of the Observation type defines its data as a History-of-events structure, since all phenomena observed in the external world are situated in time, and in many cases, there are multiple samples to be recorded. In theory, such information should be repeatably observable using the same protocol and assuming a sufficient level of skill or training on the part of the observer. In contrast, the Evaluation type is used for recording clinical thinking rather than events from the outside world. Consequently, it does not oblige a historical timing structure. This is not to say that 'time' is irrelevant to clinical thinking. Indeed, many typical clinical assessments include all manner of times, as shown by this diagnosis archetype. However, the times in such evaluations are not the primary recording instance of phenomenon or event time of events that may be referred to in the Evaluation, but instead are summarised times, dependent on the kind of assessment being recorded. It may be that no event time is recorded in an Evaluation, such as for the goal archetype, where the only time indicated is future proposed date of achievement. Observation and Evaluation UML Thus the Observation type provides the structures for recording phenomena, including statements the patient may make, anything measured or sensed by the clinician, or via using a machine. The history structure provides a standardised way to include the event origin time, and offsets of each event in the series, if it is more than one. In addition, it provides 'state' and 'protocol' (the latter inherited from CARE_ENTRY) which allow the state of the patient (e.g. position, exertion level) and the method (e.g. pulse oximeter) to be recorded alongside the primary data (e.g. heartrate). The history structure of a typical observation is illustrated to the right. History structure [top] Some Examples - basic Below are various examples of Observations and Evaluations. Experience has shown that it is easy to tell the difference for most types of information, but that there is a grey zone in the middle of recordings that might be of either type. We deal with the more obvious ones first. Clinical Statement Entry type Example archetype Comments simple measurement Observation Body mass index Dimensions The simplest 'point' measurements are still situated in time: there is always at least one 'event' or time-point. The openEHR model guarantees that the event-time information in single-point measurements is the same as for mult-sample measurements. time-series measurement Observation Blood pressure measurement Apgar score Body Temperature Glucose Tolerance test Many phenomena have the potential form of a series of samples in time difference over time Observation Body weight The History part of the model accommodates changes over time. maxima, minima, rolling averages etc Observation Body Temperature The 'math function' attribute in the INTERVAL_EVENT class accommodates all kinds of time-based averages and finite duration states. diagnosis Evaluation problem-diagnosis Times of some events may be mentioned, but the structure of the Entry is not the time-history of an observed phenomenon, but a report or summary, often of several phenomena, supporting a conclusion, which is the point of the Entry. adverse reaction Evaluation Adverse reaction Adverse reaction assessment is an assessment of condition or propensity of the patient to react to particular substances. [top] Grey-zone Examples Some of the examples below have confused people. One reason for confusion is that a single phenomenon may lead to a recording of an instance of the phenomenon, and/or a diagnosis of a condition. Clinical Statement Entry type Example archetype Comments Physician: "I hear mitral regurgitation" Observation Auscultation There will be an observation since it is a real-world phenomenon that has been observed e.g. by listening. There seems to be an element of 'inference' about it; this is the clinician's assessment of the heart sounds heard to be leaking of blood through the mitral valve of the left side of the heart. Evaluation problem-diagnosis A diagnosis of mitral valve disease may be made; this will usually describe the severity, indicate what studies were done to establish the nature of the disease etc. This is not the same statement as any of the original observations, but would normally summarise them. Patient: "I have been diagnosed with diabetes" Observation Story Anything interesting the patient says may be recorded in the story, depending on the clinician and system. Evaluation problem-diagnosis The clinician may or may not record a 'story'; if his assessment is that the patient is indeed diabetic, he would normally record a diagnosis; this has the same status as any other diagnosis recorded by a clinical professional. Allied health professional: "The patient is incontinent" Observation Barthel Index Facts about the patient's capabilities in living independently are recorded as Observation(s), and gathered according to a protocol, such as a questionnaire, functional test by occupational therapist etc. How good the information is may depend on the protocol, but in all cases, the result is an observation of various phenomenon in time. Evaluation problem An assessment will be made about the subject based on all the information gathered; some of the evidence might lead to the establishment of a problem of incontinence. Summary The Observation type provides the timing structure that is universally applicable to all phenomona sensed from the real world; it also provides the data/state/protocol combination that characterises many measurement situations. These features mean that some basic aspects of software and data schemas can be standardised for such information. The Evaluation type provides a free-form structure which is completely structured by archetyping. The distinction in types helps ensure queries do not mix up different 'statuses'. The key criterion for distinguishing Observations from Evaluations is whether the recording is of information being captured from the outside world (in a repeatable way), or not. Using only a single unstructured type would lose these advantages. It doesn't prevent such information being expressed, but it means that even the universal aspects such as time, events, math functions, interval widths etc, are likely to be expressed differently in each instance. This is not useful for a standardised EHR environment, although it can be useful for an integration environment, where data from various source systems is being federated into a standardised EHR, and each source's idea of e.g. observation time is different.