Working document



Working document

Order Set Publication Standard

I. Project Identification

a) Project Identifier

b) Project Name

Order Set Publication Specification: A functional and structural standard for structured documents sharing order set content

c) Project Description

Order sets are an integral feature of daily clinical healthcare, multidisciplinary care plans, guideline execution paradigms and publication of clinical care protocols. The purpose of this project is to support a standard for:

1) publication, sharing and maintenance of order sets by authors and authoring institutions

2) distribution of interoperable order set content to providers and institutions who seek to support and standardize care

3) importation and localization of order set knowledge structures into Computerized Physician Order Entry (CPOE) and Care Planning software

4) presentation of order sets for effective clinical deployment in guidelines and care plans

5) organization of order sets as knowledge tools which may be employed as components of executable, interoperable guidelines.

Out of scope: This project is NOT meant to develop or promote messaging standards for HL7 compliant orders nor to specify operations or functions for manipulation of the orders sets developed by this publication specification.

d) Project Classification

Type of product: Specification for a knowledge-based structured document supporting order sets as clinical care plan elements.

Type of development: New development

Scope of participation: Sponsored by Clinical Decision Support TC; in collaboration with Patient Care, Structured Documents and Orders/Observations

Source of resources: HL7 volunteer effort

II. Requirements

Introduction

Order sets can organize and structure complex health care plans into useful units of work for clinicians. An order within an order set can request any clinical activity including referrals (requests for encounters), acts, supplies, procedures and observations among others. Structured observations and goal setting can also be supported from the order set. The sharing of care protocols and regimes authored as phased order sets has a much broader audience for work on error reduction, standardization of care and quality improvement. Order sets in this context can be envisioned as action elements within a care plan, allowing a clinician to organize and request a step in a larger protocol. Definition of the structure and function of orders and order sets for integration into an HL7 RIM compliant medical record is a central issue in development of interoperable functionality necessary to shared guidelines. (The application program interface to this record is conceptually denoted the vMR (virtual medical record) with the standard guideline model.) This document proposes a multi-layered standard that supports the publication and maintenance of order set libraries, the sharing of order sets between collaborating institutions, the structuring of order sets to support effective clinical use, and the importing and interoperation of order sets within advanced clinical guideline and care planning software. The proposal assumes that organizations employing this standard may deploy the depth of specification appropriate to their enterprise needs and the capabilities of their clinical systems architecture and performance.

Use Cases

Layer I

a) Publication and maintenance of order sets

The American College of Physicians desires to develop a repository of problem-based order sets to be used by its members. This parallels comparable guidelines activities by national and international professional organizations as well as private, content-development companies and those developed by academic organizations. Typically, these order sets will be distributed as text documents, to be employed in a large variety of hospital and office-based clinical information systems (CIS). In order to maintain a library of order sets in an organized, up-to-date, and accessible fashion; the order sets should be maintained in a document repository with appropriate descriptive metadata. The electronic documents (order sets) should support computer processing as well as being readable by humans in order to support import procedures into Clinical Information Systems (CIS).

Metadata should support browsing across order sets, understandable context for identifying orders sets for appropriate clinical use, web link to external knowledge sources for expanded “help”, editing and review time stamps, editorial staff responsible for content, designated target populations, acuity flag for clinical classification, version number and diagnoses for application of content. The organization and content of the order sets themselves will assist ACP members in understanding and following standard care protocols and meeting performance measure standards (the Pay 4 Performance program) promoted by the College quality care activities. The ACP repository is designed to be compliant with HL7 phase I standards which allows them to manage and track the editorial needs of their initiative as well as organize and maintain the clinical content.

Layer II

b) Distribution and localization of content

Multiple institutions wish to share order sets with ACP to support their efforts to implement computerized physician order entry (CPOE). Although they have different order master tables and order processing systems, their individual CPOE software supports order set definition from the orders created in their order master table. Furthermore, each platform will also include textual alerts linked with individual orders which can inform the clinician at the time of order processing. The clinical practice committees at each institution download order sets for sharing in compliance with HL7 layer I/II order set standards from the American College of Physicians. (See Appendix B for exemplar order set) At the time that an order set is imported into the recipient institution, each order in the set is compared with the order master and a new master table entry is created if necessary. Alerting text from phase II standards allows the recipient institution to enhance their order master with clinically useful warnings and text alerts linked to orders which may have risk or require clinical evaluation at order processing . For ease of review and browsing, orders are grouped by functional or administrative category. Order sets may be identified as employed by a single clinician, or for general clinical use.

Layer III

c) Order set presentation and clinical use

Order set presentation standards are important to physicians and other clinical users who may need to use CPOE systems from multiple vendors across multiple settings of care. Major software vendor have developed order processing software for CPOE in compliance with HL7 layer I-III standards. For example, as an initiative to support implementation of CPOE in small rural hospitals, a vendor has contracted with a clinical middleware company to provide starter order sets for these organizations. These will be deployed on the vendor order platform which is web-based software employing low cost presentation tools. The middleware vendor maintains a library of current clinically reviewed orders sets employing HL7 layer I standards to manage the content. Layer III standards control clinical presentation features which are integral to the clinical utility of the order sets.

Order sequencing specified by the middleware vendor, along with default pre-selection of common orders and logical grouping of order actions (orders which must be selected all at once, and orders which are mutually exclusive when selected) all make the order set more clinically useful and attractive for the clinician. Embedded alerts from layer II standards enhance the understanding and proper selection of orders appropriate for the clinical scenario. Hot links by order allow for an expanded web-based help function relevant to each order when used in the clinical setting.

Layer IV

d) Interoperation

The SAGE consortium has developed an interoperable model for the sharing of executable clinical guidelines between SAGE compliant vendor systems. This model employs a number of guideline action features, including the employment of dynamic, problem-oriented order sets to support protocol work sessions.

The order sets are prepared in (order) sessions as multi-disciplinary templates, including nursing, medical, pharmacy and allied health actions items. The order sets have been professionally reviewed and are a component of problem oriented care plans, wherein each order set serves to organize one session or phase of the overall plan of care. Problem and session encoding of order sets assure that order sets are employed in relevant clinical contexts and care plans, and the order sessions may be merged when multiple guidelines apply to a single patient

In addition to library, sharing and presentation features, SAGE order sets employ embedded decision logic features which may turn orders “default on or off” within the set at the time of order processing (sanction logic) Order items within the set may specify an order for a medication or service, allow confirmation and recording of clinical observations or setting of a goal. Goal setting within a care plan allows for later determination of clinical outcomes and determination of variance from care standards.

Service coding of each order item within the order set and order master allows the guideline software to determine whether an instance of an order is already active (supporting alerts for orders already issued), an observation is already recorded or a goal is already set, and to manage merging of order sets to eliminate duplication. Level of recommendation flags allow dynamic prioritization of orders within sets by SAGE decision support features, so that multiple treatment options may be placed in perspective for the clinician. Order collectives defined within layer III allow groups of order items to be manipulated as a block by the SAGE decision engine for purposes of alerting, prompting and changing default actions for the clinical user. SAGE order sets are distributed as guideline knowledge constructs compliant with HL7 level I-IV standards on the SAGE guideline CD.

III. Definitions

Order set

“An order set is a pre-filled ordering template, or electronic protocol that is derived from evidence based best practice guidelines.” (1)

In the article proposing this definition, the authors provide a cursory description of their methodology and data structure.

“Once a guideline is accepted, the contents of the guidelines are translated into a workflow that can then be adapted into one or more order sets and automated through the computerized provider order entry (CPOE) system.”

“Each record in the table represents one order and contains all high level information about the order such as, order description, department, type of order, frequency, dose, order entry date, etc. This table also houses essential, frequently used attributes needed in order set analysis such as order set name, ordering health care professional, the patients current clinical service and patient location at the time the order set was placed.”

The electronic health record interest group of HL-7 has recently published a proposed electronic health record functional description[i]. They state order sets “supports delivery of effective healthcare,” improve efficiency, facilitate management of chronic conditions, and improve patient safety[ii]. They provide the following functional description of order sets:

“Order sets allow a care provider to choose common orders for a particular disease state or circumstance according to best practice criteria for assembling the order set without having to generate each order individually. The EHR may recommend order sets in certain conditions or as the result of other clinical information being entered into the EHR. Or the order sets may simply be available for use by the ordering care provider.”

An order set is not merely a collection of orders. The collection of proposed acts within the order set has been developed and edited to promote consistent and effective organization of health care activity.

Acuity is a metadata string which denotes the chronicity of the setting for order set employment. Options include “Acute”, “Chronic”, and “Emergency”

A Care plan is an ordered assembly of expected or planned Acts (in Definitional mood), including observations, services, appointments, procedures and setting of goals, usually organized in phases or sessions, which have the objective of organizing and managing health care activity. Care plans are often focused upon on or more health care problems, with the expectation of one or more favourable outcomes. Care plans may include orders sets as actionable elements, usually supporting a single session or phase

MESH (1968, NLM): N 04.590.233.624 Patient care planning - “Usually a written medical and nursing care program designed for a particular patient.”

Creation date [xml: CreationDate]is the date the order set was created

Date of Last Review [Lastreview]: is the date of last order set review for content

Date Valid Until [ValidUntil]: the order set is valid for use until this date

Date last edited is the date the order set was last reviewed or modified

Boolean collective [BooleanCollective; AND, OR, XOR supported] is a feature of order set specification layer III which identifies named sets of orders (collectives) to be manipulated and controlled at time of order set presentation. This supports menu options which may enforce exclusivity/concurrency of order set item at the time of order session processing.

The implicit assumption of order set construction is that all order items by default may be selected by the clinician as independent choices. Hence the usual case is that each order item within an order set is linked by an “inclusive OR” (any item or no item may be selected). Boolean collectives may override this default at order selection and allows adjacent order items within the order set to be required for selection as a group, or individually. All order set items flagged as “AND” will be required to be selected as a unit or not at all. All items flagged as “XOR” will require selection of at most of a single item from the group at time of order selection.

When employed by decision enabled (layer IV) systems, this feature supports the identification of a set of order items from the order set which serve a common purpose for clinical decision support. All order items within a collective may be manipulated ‘en bloc’, supporting alerts, manipulation of pre-selection flags, and other presentation features which enhance the decision support features of order sets.

Is Personal is a data flag indicating whether the order set is institutional (Boolean false) or owned by an individual (Boolean true)

Order display group: a textual category linked to each order set item; vendor software employs these tags to organize and display orders with similar actions or intent within an order set for ease of clinical browsing and to aid understanding and order selection. They may express intent, such as “Diagnostic” or “Treatments”, or be organizational in nature, such as “Laboratory” or “Radiology”.

Order set item [Orderitem]: is the recurring element of the order body consisting of the order, observation or goal embedded within order specification, management and logic layers.

Order set management layer (layer III) consists of the order sequence number, full text order, Boolean collective and pre-selection keys, and comprises the information designed to help manage the order session for maximum clinical utility.

Order set Header: Each order set has a single header which identifies the order set, specifies the patient population for whom the order set is useful, links the order set to the guideline problem of focus, identifies the protocol session whose management this supplements, and contains editorial information for authorship and proper maintenance.

Order set key [OSKey] uniquely defines an order set and may be employed to nest an order set as an order set item within another order set

Full text order [FullItemText] will be a complete textual description of the order, observation or goal including purpose, instructions, frequency, priority, repetitions, etc. All order set items with full text description but a “null” order set specification layer will be considered non-actionable by the order session and will be descriptive only and function as comments to the user when an order set is displayed.

Order specification layer consists of the RIM specification fields for the order, medication order, observation or goal, permitting a decision engine to identify the coded subject of the order item, the dose, route, frequency, repetition and other structured elements which are needed for guideline decision logic.

Order set item [OrderItem] consists of the full RIM compliant definition of an Order, Medication order, Observation or Goal to be set. It may also be a pointer to an order set, allowing the nesting of order sets within order sets.

Order logic layer consists of all those elements of the order set item which are employed to dynamically alter order set content by order sanctioning or to enhance clinical order information employing alerting text.

Order alerting text [OrderAlertText] is a text message which is displayed as an informational item with an order set item at the time of the order session. The alerting text may be a static element of the order set or may be dynamically populated at the initiation of the order session by a decision support program.

Order session is a CIS program function which supports a clinician in the process of order selection, order confirmation and order processing. Order session is not a focus of this standard.

Order sanction decision logic [OrderSanctionLogic] is a decision criterion or knowledge construct which may employ patient record data in order to sanction (remove) an order set item in an order set at the time an order session is active.

Order set title [OSTitle] is a descriptive name for the use of this order set

Owner [OSOwner]is an unique identifier for the clinical author responsible for this order set

Population [OSPopulation] defines the set of age and gender restrictions which pertain to the effective clinical use of this order set

Problem code [ProblemCode] is the terminological concept (semantic class is finding or disorder, eg from SNOMED CT) which identifies the clinical focus of this order set and the associated protocol or care plan.

A protocol may be modeled in part as a sequence of order sessions during which appropriate order sets are employed, generally linked by the problem focus of the protocol.

Pre-selection flag [PreselectionFlag] (Is this order item pre--selected: choices = YES, NO or MANDATORY (REQUIRED)) is a data flag that determines whether this order set item will be pre-selected, de-selected or required at the time an order session is begun. Orders considered central to a protocol will be pre-selected, while optional and infrequent orders will be deselected at the time the order session is begun. Mandatory should be used only with caution in selected cases.

Replaces is a link to the identifier of an earlier order set which is now superseded by the current order set.

Resource link [Resourcelink] is a embedded web services URL attached to the order or the order set which can direct web software to information services relevant to the clinical situation.

Sequence number [SequenceNumber] is an integer indicating the placement of this order set item within the order set.

Session code [SessionCode] is the concept code (semantic class is procedure, eg from SNOMED CT) defining the order session within the larger episode of a protocol, care plan or guideline. Examples include 32485007 Admission to hospital or 37894004 “Evaluation&Management new outpatient”.

Strength of recommendation [StrengthofRecommendation] flag is a clinical order priority score that may be assigned as a default by the order set author, but which may be altered programmatically at the time of order processing by guideline decision logic.

Version is an alpha numeric string denoting current version designation of the linked order set.

IV. Assumptions

Orders are requests and authorization for service from an ordering agent (user) to an action agent (a person, department, or system that will carry out the order). Orders are selected, submitted and processed by a clinician during an order (processing) session during which the clinician interacts with clinical information system (CIS) software designed for order processing. Order sets are logically grouped orders organizing and supporting a unit of clinical work or care planning.

Orders may require detail information provided by the clinician during order processing.

The internal order functionality of the order set and order processing software is a property of the CIS. This will be presumed to include features such as:

Order presentation, modification and authentication

Order duplication checking and alerting

Medication order interaction checking and alerting

Medication allergy checking and alerting

Within these assumptions, such CIS features may be enhanced with order set standards but these functions are not the primary goal of this standard.

V. Relationship of order sets to the HL7 RIM

In the HL7 process of defining the relationship of published order sets to the HL7 RIM, a Domain Analysis Model (DAM) for order set publication is created. The Class diagram for the Order Set Publication DAM is included in Appendix C. Normally, in the absence of existing RIM-based models, this DAM would then be mapped directly to the RIM. From the mappings of the DAM to the RIM, an HL7 Domain Message Information Models (DIM or DMIM) would be created. Finally, this DIM would be constrained to a very succinct Refined Message Information Model (RMIM) that is used to actually create XML structures.

In this project, which focuses on how to publish an XML document that contains order set specifications, a generalized document DMIM is required, similar to the RMIM created for CDA documents. Within the document DMIM, support is required for the actual content specification. In this case, a Care Plan RMIM has been proposed.

The major purpose of the Order Set DAM in this project will be to help create, validate and extend the document DMIM and associated RMIM’s required for publishing HL7 order set specifications in an XML document.

HL7 documents are created with document headers, which hold the metadata about the document (document context), and document bodies, which hold the actual content to be communicated. This paradigm has been followed in the order set publication model. The header would include information about:

• when the document was created and changed

• who created the document, e.g. authors, authenticators

• what patient characteristics apply, e.g. age, gender, diseases and settings

• what provider characteristics apply, e.g. licensing, specialty

• a list of references cited in the document

The content section or body of the document would include one or more HL7 Order Sets and associated goals. An HL7 Order Set, as a subset of an HL7 supported guideline, is a pre-coordinated set of acts in Definition mood prepared to support a complex set of actions when instantiated for a patient within an active care plan. Each Order set may have one or more goals proposed, which are explained in more depth below.

What this means is that an HL7 Order Set contains instances of HL7 Acts that are in Definition mood (and Goals in Goal mood), similar to what one would find in a master file of orders. On import to a clinical system, these instances of Acts in Definition mood would be instantiated into the clinical ordering system, incorporating the additional features required by the vendor application software. From HL7’s perspective, what happens inside the clinical ordering system is unknown; it’s a “black box.” However, during order processing for a patient, the status of these orders may be tracked externally in messages or CDA documents exported from the “black box” ordering application.

A clinical decision support system may employ published order sets as actionable elements involved in improving guideline adherence. These order set documents will be instantiated into the clinical information system order master and accessed by the decision support software for order processing in a similar manner.

Order processing

Master files (or Acts in Definition mood) are not actually changed as a clinician creates specific orders. Rather, the clinician creates new instances of Acts that are “copied” from the Acts in Definition mood. In other words, during an order session, a clinician processes the order set and confirms or denies the “activation/commitment” of items in the order set as the plan is instantiated for a patient. This action is called, “creating a care plan for the patient” and produces instances of Acts in “Intent” mood. Usually, during an order session, instances of some or all of these Acts are also created in “Order or Request” mood and processed through an order management system. The order management system may elicit “promises” from a department or person who is then responsible for filling the order. These “promises” are instances of HL7 Acts with much of the same information about the acts, but are instantiated in “Promise” mood. When the order is actually filled, a new instance of the basic act is created in “Event” mood.

In summary, during order processing, each act in intent mood become instantiated as requests (orders), promises, and events as appropriate. These acts (requests, promises, and events) are linked with ActRelationships as they are created back to the elements of the (active) care plan. This order set processing, from the point of view of the HL7 RIM, consists of a generation of new act instances in various moods of the “HL7 Business Cycle of Act Instances,” all linked back to the “original” instances of the act in definition mood (order set) and intent mood (care plan):

Definition > Intent > Request (order) > Promise > Event

Therefore, the Post-condition of an Order Set Publishing use case describes an order management and order tracking process that must be supported by the initial XML document published by the Order Set author and that is imported into a clinical system by a clinical provider.

Goal setting

Of critical importance in today’s environment of evidence-based medicine is whether the application of an order set generated the desired outcomes, i.e. has met the desired goals for the patient. One or more goals for individual observations may be proposed with an order set. For example, if the goal were to walk 20 feet on August 1, then, in HL7, this goal would be represented as an observation of walking ability with a value of 20 feet and an effective date of August 1. When the order set is processed by the clinician, the goal would be validated for the patient in question. Also, within the order set observations would be ideally scheduled to measure progress against the goal. In addition, goal variance calculation observations may included in the Order Set that measure the difference between an observation and the goal, e.g. patient walked 18 feet against a goal of 20 feet which allows one to derive a goal variance of (18ft minus 20ft) or (-2ft).

In summary, overall alignment of HL7 Published Order Sets with the HL7 RIM and RIM-base document and content structures supports the needs of practicing evidence-based medicine in a standards-based environment.

Proposed Order set definition

Order set header [cardinality, (1:1)]

Layer I Metadata

Order set key II (Instance identifier)

Order set title String

Order set description String

Use case scenario String

Acuity CS: (Acute, chronic or

emergency)

Population

Age and gender restrictions(1:N) Age IVL(Integer:integer)

CS: Gender

Owner String

Dates of review:

creation, edit, valid, archived

Replaces II

Version String

(Order set) Resource link URL

Layer II Metadata

Is Personal Boolean

Layer IV Order Session Index

Problem code CD: as in SNOMED CT [Clinical finding]

Session code CD: as in SNOMED CT [Procedure]

Order set body

Order set item [cardinality, (1:N)]

Order set management layer (1:1)

Layer II Localization

Full text order String

Order alerting text String

Order display group (1:N) String

Layer III Presentation

Sequence number INT

Boolean collective (1:N) CS: [AND, OR, XOR]

Pre-selection flag CS: [NO, YES, REQUIRED, MANDATORY]

(Order) Resource link URL

Order specification layer (1:1)

Layer IV Interoperation

[one of:

Order set key (pointer to nested order sets) II

RIM standard order specification (RMIM for Order includes medication order)

RIM standard observation (RMIM Observation)

RIM standard goal (RMIM Goal)

]

Order logic layer (1:1)

Layer IV Interoperation

Order sanction decision logic ED: Decision criterion

Strength of recommendation CS

References

Kamal J, Rogers P, Saltz J, Mekhjian HS. Information Warehouse as a Tool to Analyze Computerized Physician Order Entry Order Set Utilization: Opportunities for Improvement. In: AMIA 2003 Symposium Proceedings; 2003; Washington, DC; 2003. p. 336-41.

Appendix A

Related HL7 version 3 information

Content of an order based on an RMIM derived from the HL7 RIM.

Definitions from HL-7 version 3

“An order for a service is an intent directed from a placer (intent author) to a filler (service performer). -- Historical note: in previous RIM versions, the order mood was captured as a separate class hierarchy, called Patient_service_order, and later Service_intent_or_order.”

“Order: An Observation-order is a request for the performance of an Observation. Typically the request is made by a clinician, and recorded within one computer system, and then transmitted to a second system for performance.”

Order sets versus Templates

The HL-7 clinical document architecture from the Structured Document TC provides us with templates and insight into a potential process of standardizing order sets. “Templates are sets of definitions, which are aggregated for a purpose. These expressions often take the form of batteries or aggregate lists.” This may imply that an order set should employ template standards as a distribution format since it is a test battery or aggregated list.

This does raise some questions that we may have to address:

_ What exactly is an order set, and how does it differ from other templates?

_ How does a specialty society define a collection of order sets for use with one or more HL7 specifications?

_ What is the formalism by which order sets are expressed?

_ What is the process by which externally defined order sets are registered or housed within HL7?

_ When does an instance of a customizable order set become a new order set?

_ How do we accommodate thousands of order sets, to identify relationships and overlaps among them?

See appendix for references from the HL7 version 3 proposal.

Appendix B

American College of Physicians

Initial Workup: Order set for hypertension

Order set header

|Order set key |ACP00001 |

|Title |Essential Hypertension (d 226) Order Set |

|Description |New patient evaluation for problem essential hypertension |

|Use case |Doctor Bob has just finished a new patient history and physical in his |

| |office. The only identified problem for the patient is documented |

| |hypertension. Doctor Bob selects the ACP order set from the web for |

| |Essential Hypertension to expedite his diagnostic and therapeutic |

| |planning. He prints his selected orders with detail for the office staff |

| |who transmit these to the clinical laboratory. |

|Population | |

|Age restrictions |15-elderly |

|Gender restrictions |None |

|Owner |Thom Kuhn |

|Dates of review |Last review date |

|Reference |JNC VII clinical guideline (URL:......) |

Order set body: (Full text order; Alert text)

| |

|INITIAL |

| |

|Diagnosis |

| |

|Laboratory tests to: |

| |

|Document target disease |

|Ambulatory BP monitoring; |

|Consider for white coat hypertension |

| |

|Document related comorbidities |

|Serum creatinine |

|Urinalysis |

|Electrocardiogram |

|Lipid profile |

|BUN |

|Echocardiography |

|Serum electrolytes or potassium |

| |

|Exclude other diseases in differential diagnosis |

|Serum potassium |

|Hematocrit |

|Renal sonography |

|Urinary potassium |

|Plasma renin and aldosterone |

|Spot urine for metanephrine |

|Dexamethasone suppression test |

|Captopril-enhanced isotopic renography or renal duplex sonography |

|Aortography |

|Abdominal CT or MRI |

|Adrenal scinti scanning |

| |

|Establish baseline before starting treatment |

|Complete blood count |

|Serum glucose |

|Serum creatinine |

|Serum electrolytes |

|Urinalysis |

|Lipid profile |

|Uric acid |

|EKG |

| |

|Treatment |

| |

|Treatment for: |

| |

|Primary disease |

| |

|Nondrug |

|Weight loss |

|Exercise |

|Reduce sodium intake |

|Moderate intake of alcohol in patients who drink |

|Relaxation therapies |

| |

|Drug |

|Diuretic |

|Hydrochlorothiazide |

|Chlorothiazide |

|Chlorthalidone |

|Metolazone |

| |

|Indapamide |

|Furosemide |

|Bumetanide |

|Ethacrynic acid |

|Torsemide |

|Potassium-sparing diuretic |

|Spironolactone |

|Triamterene |

|Amiloride |

|Beta-blocker |

|Acebutalol |

|Atenolol |

|Betaxolol |

|Bisoprolol |

|Carteolol |

|Metoprolol |

|Nadolol |

|Penbutolol |

|Pindolol |

|Proranolol |

|Timolol |

|Alpha-/beta-blocker |

|Carvedilol |

|Labetalol |

|ACE inhibitor |

|Benazepril |

|Captopril |

|Enalapril |

|Fosinopril |

|Lisinopril |

|Moexipril |

|Perindopril |

|Quinapril |

|Ramipril |

|Trandolapril |

|Angiotensin-receptor antagonist |

|Candesartan |

|Eprosartan |

|Irbesartan |

|Losartan |

|Telmisartan |

|Valsartan |

|Calcium antagonist |

|Amlodipine |

|Diltiazem |

|Verapamil |

|Felodipine |

|Isradipine |

|Nicardipine |

|Nisoldipine |

|Nifedipine |

|Peripheral adrenergic inhibitors |

|Reserpine |

|Guanethidine |

|Guanadrel |

|Central alpha-agonist |

|Methyldopa |

|Clonidine |

|Guanabenz |

|Guanfacine |

|Alpha-blocker |

|Prazosin |

|Doxazosin |

|Terazosin |

|Phenoxybenzamine |

|Vasodilator |

|Hydralazine |

|Minoxidil |

|Catecholamine synthesis inhibitor |

|Methyltyrosine |

|Combination drug therapy |

|ACE inhibitors plus diuretic |

|Lotensin HCT |

|Capozide |

|Vaseretic |

|Prinzide |

|Zestoretic |

|Monopril HCT |

|Uniretic |

|Accuretic |

|Adrenergic neuron antagonists |

|Reserpine/Hydrochlorthiazide |

|Reserpine/chlorothalidone |

|Reserpine/polythiazide |

|Reserpine/chlorothiazide |

|Alpha 1-blockers plus diuretic |

|Minizide |

|Alpha 2-agonists |

|Combipres |

|Clorpres |

|Aldoril |

|Angiotensin receptor blockers |

|Atacand HCT |

|Teveten HCT |

|Avalide |

|Hyzaar |

|Benicar HCT |

|Micardis HCT |

|Diovan HCT |

|Beta-blockers plus diuretic |

|Tenoretic |

|Ziac |

|Lopressor HCT |

|Corzide |

|Inderide |

|Inderide-LA |

|Timolol-HCTZ |

|Other diuretics |

|Moduretic |

|Aldactazide |

|Dyazide |

|Maxzide |

|Vasodilators |

|Hydrazide |

|Apresazide |

|Drugs for hypertensive crises |

|Diazoxide |

|Enalapril |

|Labetalol |

|Nicardipine |

|Nitroglycerin |

|Nitroprusside |

|Trimethapan |

| |

|Consultation |

| |

|Consultation for: |

| Primary disease |

|(Link to Consultation for Diagnosis) |

|Hypertension specialist for Uncontrolled BP |

|Nephrologist for Uncontrolled BP |

|When procedure or expertise is needed to clarify diagnosis in patients with end-organ complications |

|Endocrinologist for Uncontrolled BP |

|Cardiologist |

|Ophthalmologist |

| |

|Related comorbidities |

|Consult cardiologist for heart failure |

|Consult nephrologist for worsening renal failure |

| |

|Patient Education |

| |

|Diet/lifestyle counseling |

|Weight loss |

|Reduce sodium intake |

| |

|Nondrug and drug RX counseling |

|Encourage home BP monitoring |

|Discuss disease and adherence to therapy |

| |

|Specific resources |

|American Heart Association: High Blood Pressure |

| |

|American Heart Association: How Can I Reduce High Blood Pressure? |

| |

|American Heart Association: Making Healthy Food Choices |

| |

|American Heart Association: A Special Message for Women |

| |

|American Heart Association: Ten Ways to Control Your High Blood Pressure |

| |

|American Heart Association: What Is High Blood Pressure? |

| |

|JAMA Patient Page: Hypertension |

| |

|Medline Plus: Essential Hypertension |

| |

|Medline Plus: High Blood Pressure |

| |

|NHLBI: Cardiovascular Information for Patients and the General Public |

| |

|NHLBI: Facts About ALLHAT: New Findings About Drugs to Lower High Blood Pressure and Cholesterol |

| |

|NHLBI: High Blood Pressure Detection |

| |

|NHLBI: Your Guide to Lowering Blood Pressure |

| |

|National Kidney Foundation: High Blood Pressure: What You Should Know |

| |

|National Women's Health Inforamtion Center: High Blood Pressure in African American Women - Easy to Read |

American Heart Association: High Blood Pressure



American Heart Association: How Can I Reduce High Blood Pressure?

-----------------------

n Functional Descriptors.pdf available at in the electronic health records special interest group documents section.

y Ibid. Section C.1.4.3

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download