Linking Guidelines to Electronic Health Record Design for Improved Chronic Disease Management

Abstract

The promise of electronic decision support to promote evidence based practice remains elusive in the context of chronic disease management. We examine the problem of achieving a close relationship of Electronic Health Record (EHR) content to other components of a clinical information system (guidelines, decision support and work-flow), particularly linking the decisions made by providers back to the guidelines. We use the openEHR architecture, which allows extension of a core Reference Model via Archetypes to refine the detailed information recording options for specific classes of encounter. We illustrate the use of openEHR for tracking the relationship of a series of clinical encounters to a guideline via a case study of guideline-compliant treatment of hypertension in diabetes. This case study shows the contribution guideline content can have on problem-specific EHR structure and demonstrates the potential for a constructive interaction of electronic decision support and the EHR.

INTRODUCTION

A good case can be made for the use of Electronic Health Records (EHRs) in Chronic Disease Management (CDM). A case study that looked into the effect of using electronic data exchange in a diabetes coordinated care environment found that communication between health care providers increased, they had better access to data, and there was a small improvement in patients’ health over a short period of time [1]. The question remains, is it possible to reap further benefits in CDM via the use of guidelines? PRODIGY Phase Two results estimate that if all General Practitioners (GPs; i.e., “family physicians”) prescribed the same way as PRODIGY-compliant GPs on three ‘tracer conditions’, the savings would be approximately £14 million per quarter [2]. Experience in PRODIGY Phase Two, however, indicates challenges for achieving effective decision support for CDM [2–3]. These challenges include the need to provide guidance using information across successive consultations; provision of structured guidance within a minimal user interaction; and providing guidance-positioning information [3]. The Phase Three architecture aims to address these problems – a key feature being clinical scenarios (patient states) with sets of available actions associated with each scenario. Actions taken indicate scenario transitions for following consultations. Despite the innovations, however, recent evaluation using the scenario-based decision support in general practice shows no effect on management of chronic conditions [4], most likely due to the significant barriers to its usability [5].

Three of the authors have had a related experience from work in one of the Australian Commonwealth’s HealthConnect projects [6]. We observed that, in concert with domain experts, one can design an event summary data collection form that describes all information that is potentially needed for a given event (e.g., GP contact with a diabetes patient). However, clinicians find these unwieldy because the form documents a maximal data set, too much to record in a given consultation, and it is unclear when to record which information. The authors suggest that a promising way of solving this problem is to introduce more specific linkage of the associated guidelines to the EHR content items. In this way, information that is considered a priority for a given encounter can be clearly identified in the point-of-care application.

In this paper, we present a model and architecture aimed at facilitating the development of systems to achieve the yet-unrealised potential of guidelines in CDM. Our approach emphasises representation of the content to be recorded in the EHR specific to the role of any given consultation in the CDM process with clear linkage of each provider decision back to the guideline. This model and architecture exploits the openEHR approach to allow extension of the Reference Architecture for specific EHR refinement as requirements are identified.

GUIDELINES

Guidelines are natural-language documents resulting from a process of consolidating and localising medical evidence. A widely accepted definition of clinical guidelines is: “systematically developed descriptive tools or standardized specifications for care to assist practitioner and patient decisions about appropriate health care for specific clinical circumstances” [7]. The technology of electronic guidelines is advancing beyond merely making the guideline be “on line” as multimedia or hypermedia. Such representations include GLIF (GuideLine Interchange Format) [8] and EON [9]. Object-oriented GLIF3 enables guidelines to be abstracted into three levels: (1) conceptual (flowchart representation for human-readability), (2) computable (algorithm), and (3) implementable (integration into a clinical information system). Moreover, GLIF3 supports linkage to other domain ontologies such as the HL7 v3 Reference Information Model (RIM), medical vocabularies (e.g. UMLS) and knowledge bases. EON is also object-oriented, uses flowchart representation and an ontology approach to mapping patient data encoded in guidelines to an external EHR. EON also supports reusability of medical domain knowledge, temporal queries and abstractions.

Current guideline models vary depending on the type of processes they try to express. A typology of four modelling formalisms used by guideline models is identified in [10]: (1) flowcharts for algorithmic problem-solving processes; (2) disease-state maps to relate decisions made during the course of patient care; (3) sequencing of activities in care plans that aim to meet goals; and (4) work-flows to model care processes in an organisation. We take the position that, in general, engineering of a given guideline for use in clinical information systems with electronic decision support produces a number of artefacts (figure 1).

Figure 1.

Artefacts from engineering of guidelines

Guidelines allow us to specify what needs to be recorded (EHR content), when to record, and how to evaluate/make decisions (computer interpretable clinical guidelines, CIGs), and what needs to be done (workflow schemas that may include a combination of clinician and system dependent actions). Also, we can produce a human-readable electronic version of the guideline as hypermedia. Maintaining a clear relationship among these artefacts during the execution of the system is key to successful computer support in CDM.

EHR ARCHITECTURE

A record architecture is defined as a “set of principles governing the logical structure and behaviour of healthcare record systems to enable communication of the whole or part of a healthcare record” [11]. We use the openEHR [12] architecture as the basis for our EHR approach. OpenEHR has evolved from the Australian Good Electronic Health Record (GEHR) [13] and provides a method of implementing the clinical content of records through a two-level model framework: (1) a Reference Model (that represents generic data structures), and (2) Archetypes (to be discussed below).

The openEHR reference model defines the content of all information that occurs in the “clinical statement” context as entry instances, sub-typed into three classes: observation, evaluation and instruction. Observations are clinical statements due to observation of a phenomenon and may be measurable or subjective statements. Evaluations are clinical statements created as a result of interpretation or analysis of observations, hypotheses, diagnoses, goals, etc; and instructions are statements of actions to be carried out. These entries have a direct relationship to components of CIGs as shown in figure 2 – guideline computational requirements dictate what content the EHR must accommodate.

Figure 2.

The guideline informs EHR content

While the guideline informs facets of the EHR, existence of these components in the EHR can allow the point-of-care application to better promote the guideline with workflow and decision support.

OpenEHR uses archetypes, formal structured constraint definitions of clinical concepts (expressed using constraints on instances of an underlying reference model), which define the particular configuration or desired composition of instances of those concepts. For example, an entry archetype may be for the concept “blood pressure”, and constrains the particular arrangement of instances underneath that entry object as having two content item children for the systolic and diastolic values, and further constrains the valid range of their values and unit type. Such archetypes then serve as building blocks for producing instances of EHRs (see figure 3). These archetypes can be used to allow for guideline-specific and case-specific information to be recorded in a general and extensible EHR framework.

Figure 3.

Archetype/Reference Model

Using OpenEHR’s structural components, such as organisers, we can then define how these content entries within a record should be navigationally structured. In the case of patient-provider encounters, we can define an organiser archetype that allows content entries within the EHR to be organised under Problem-SOAP headings (figure 4). Moreover, we can further specialise the encounter transaction archetype with specific rationale links into guideline decision rule representation. The rationale construct allows the clinician and/or the electronic Decision Support System (DSS) to record (possibly automatically) justification for decision points made during the patient’s care. The rationale construct includes:

Figure 4.

Structure for an Encounter archetype instance

• an optional free-text justification statement from the clinician;

• identifier for the guideline used;

• the precise step in the guideline that was taken;

• a set of indications for the decision (observations and/or evaluations).

Values for any of these items can be a link item provided by the openEHR framework. For instance, indications for prescribing an ACE inhibitor may be diabetes and hypertension, which can be identified by a navigational path, as defined by the openEHR reference model [12].

IMPLEMENTATION

We are currently experimenting with an early prototype to demonstrate the interrelation of guideline-specialised EHR content and other guideline artefacts. Information about the guideline as well as the collated indications is automatically populated by the DSS whenever the clinician chooses to comply with its recommendations (with provision for explanation of variation from the guideline where some aspect of the guideline intention is preserved). Furthermore, such information is used to link back to the online guideline document and enable clinicians to view the hypermedia guideline document with the specific decision point highlighted. The prototype system architecture is shown in figure 5. Our application uses the BREEZE workflow engine, BRED workflow editor and the ELVIN notification middleware from the Distributed Systems Technology Centre (DSTC) [14].

Figure 5.

An architecture for EHR-workflow-decision support-application interaction.

CASE STUDY – HYPERTENSION IN DIABETES

We illustrate our method using a case study of guideline-compliant treatment of hypertension in diabetes with reference to the guideline algorithm from the Texas Diabetes Council (Texas Department of Health) [15]. In contrast to problems such as post-stroke rehabilitation [16] where workflow support features highly in the coordination of care among service providers, management of hypertension in diabetes presents more opportunities for clinical decision support and guidance with only some aspect of workflow support required.

We illustrate the interaction required between the EHR and electronic decision support, and provide segments of the EHR transactions produced during three patient-provider encounters. In particular, we track the relationship of these encounters to the guideline. EHR transactions are encoded in XML (a fragment of which is shown in figure 6), but for the sake of readability, we illustrate them in abbreviated textual format in this paper. We designate a transaction relating to an encounter as a “contact note”.

Figure 6.

EHR transaction for Encounter 1.

For the first encounter, the physician is presented with two problems: proteinuria and hypertension. Problem entries in this contact note transaction are collated by the DSS as well as queried from a separate “Current Problems” transaction (a persistent transaction recording all the patient’s diagnoses) to determine indications for a particular drug. (Other relevant transactions such as “allergies/drug intolerances” may also be queried). An ACE inhibitor is recommended due to presence of proteinuria, hypertension and diabetes type 1 – these are recorded as link items within the “Indications List” as part of the rationale for the medication order instruction. The name of the guideline used and the precise step from which it came are also recorded. A similar process applies for recording the rationale for targets. Moreover, the second SOAP note’s plan refers to the first SOAP note since the ACE inhibitor is used to address both the proteinuria and hypertension problems. We implement this reference by providing a link item.

After four weeks, the patient is reassessed and found to have poor tolerance of the ACE inhibitor with marginal improvement in hypertension and proteinuria level. Verapamil has been recommended by the guideline for substitution due to its renal protective effects. References to the step and links to relevant indications are recorded in figure 7.

Figure 7.

EHR transaction for Encounter 2.

For the third encounter, the blood pressure target is still not reached. Complying with the guideline’s recommendation, Beta Blocker has been chosen as an additional agent due to the patient’s history of a myocardial infarction (MI). Figure 8 shows the recording of the precise decision step that was taken and indications as the rationale.

Figure 8.

EHR transaction for Encounter 3.

DISCUSSION AND CONCLUSION

The natural-language artefact of a guideline document can be engineered into a number of on-line and computational artefacts. In the operation of a chronic disease management system, the artefacts sourced from a common guideline must coordinate – notably, as a guideline is followed across a series of consultations, the EHR content should provide clear documentation of the decisions taken (drugs prescribed, targets set, and return visits scheduled). The relationship of those decisions to precise steps in the guideline must be readily reconstructable. Toward this end we have discussed the coordination and linking of the EHR structure with the computer interpreted clinical guideline (decision support rules) with a brief illustration in the context of management of hypertension in diabetes.

While we make no claim of overcoming the usabilty problems reported in [5], application of the openEHR architecture as we have outlined provides an open framework for a range of researchers and vendors to explore further the problem of effective support for chronic disease management. The architecture supports integration of EHR content, workflow models, computable guidelines and guideline hypermedia, while allowing the application designer to choose a usable balance of compliance encouragement and human judgement.