1. Networking and Health Information Exchange
Welcome to Networking and Health Information Exchange, Supporting Standards for EHR Application. This is Lecture a.
Unit 7 covers “Supporting Standards for EHR Application” about the additional standards that are available to support interoperability across different applications that relate to or are interactive with the Electronic Health Record.
Lecture a presents a Clinical Decision Support Standard, the Arden Syntax.
Supporting Standards for EHR Applications
Lecture a
This material (Comp 9 Unit 7) was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated by Normandale Community College, funded under Award Number 90WT0003.
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit

2. Supporting Standards for EHR Applications Learning Objectives
Understand the clinical decision support standard Arden Syntax
The Objective for lecture a of Supporting Standards for EHR Application, is to:
Understand the clinical decision support standard Arden Syntax,

3. Clinical Decision Support (CDS)
Apply information technology to address, in a systematic manner, questions (and other information needs) that arise during patient care and clinical research
Seek to improve clinical and public health outcomes. CDS can inform and alter healthcare decisions, and standardize decisions and procedures for clinical research
Clinical Decision Support or CDS applies knowledge to data to provide information to the user. With CDS, we apply information technology to address, in a systematic manner, questions (and other information needs) that arise during patient care and clinical research.
The medical literature has advanced at an accelerated pace. Over a million articles are introduced each year, and no human can keep up. The scope of knowledge overpowers the human mind, and computer-supported decision support is necessary for safe and quality care. Meaningful Use requires the use of decision support. Developers and users of CDS systems seek to improve clinical and public health outcomes. CDS can inform and alter healthcare decisions and standardize decisions and procedures for clinical research. Effective use of CDS, however, depends on the ability to access and understand specifically, the data contained in the EHR and required by the CDS algorithm.

4. CDS
Concise, accurate, and unambiguous factual information and advice containing evidence and recommendations
Addresses information needs at the point and time of decision-making
Computer-based representations of general medical knowledge, application-specific decision logic, and accurate, standardized representations of current patient data and clinical states
CDS further provides concise, accurate, and unambiguous factual information (accepted, scientific knowledge or consensus expert opinions) and advice containing evidence and recommendations and addresses information needs at the point and time of decision-making. Accomplishing these goals requires computer-based representations of general medical knowledge (content or domain knowledge), application-specific decision logic (clinical algorithms), and accurate, standardized representations of current patient data and clinical states.
Decision support provides knowledge – facts – and advice based on those facts at the point and time of decision making. The challenge is to represent knowledge in such a way that it can be applied appropriately by a computer using timely patient data.

5. CDS – Continued
Peer-reviewed, scientific literature, carefully derived expert consensus, and evidence-based knowledge
Data mining – including patient signs and symptoms, clinical data, decisions, treatment and outcome
CDS uses knowledge bases derived primarily from the peer-reviewed, scientific literature; carefully-derived expert consensus may suffice; and evidence-based knowledge obtained for clinical data with outcomes. Clinical Trials produce and prove new knowledge. Data mining, including patient signs and symptoms, clinical data, decisions, treatment and outcome is rapidly becoming a major source of knowledge.

6. Link Between Data and Knowledge
The most effective application of Clinical Decision Support Systems comes from a service-oriented architectural framework in which the CDSS service is encapsulated from the EHR. Triggers associated with specific data elements interact with the CDS service component, passing the required and specified data elements. This process is a pull, where the functionality of CDSS is invoked by the application. The CDSS module does its work, then pushes the response back into the clinical application. The CDS module contains and accesses the appropriate knowledge to carry out the request.
CDSS supports both a push and pull framework.
Source: W. Ed Hammond

7. Some Decision Support Tools
Knowledge reference framework and knowledge representation
Arden Syntax
GELLO
Clinical Guidelines
Guideline Interchange Format (GLIF) [HL7]
Guideline Elements Model (GEM) [ASTM]
Disease Management Protocols
Infobutton [HL7]
Evidence-Based Care Plans
Some decision support tools are:
Knowledge reference framework and knowledge representation such as Arden Syntax or GELLO;
Clinical Guidelines: Guideline Interchange Format (GLIF) and Guideline Elements Model (GEM);
Disease Management Protocols;
Infobutton; and
Evidence-Based Care Plans.
Two SDOs have contributed primarily to decision support standards. HL7 has contributed Arden Syntax, GELLO, GLIF, and Infobuttons; ASTM has contributed GEM. We will later discuss each of these standards, as well as some approaches to disease management and evidence-based care plans.

8. Arden Syntax Is an HL7/ANSI Standard
Current version is 2.8
Arose from the need to make medical knowledge available for decision making at the point-of-care
Makes the knowledge and logic explicit
Allows sharing within and between institutions
Standardizes the way medical knowledge is integrated into health information systems
The name, "Arden Syntax", was adopted from Arden House, located about 90 minutes north of Manhattan in Orange County, New York. Originally purchased by Edward Henry (E. H.) Harriman in 1885, the estate was given to Columbia University by his son, William Averell Harriman, in 1950 following its use by the Navy in World War II. A group of medical informaticians from several leading universities and hospitals, IBM personnel, and others involved in defining a standard for representing and processing medical conditions and recommendations met there. The "Arden Syntax" name was chosen in recognition of important milestones achieved at Arden House in the development and refinement of the syntax and its implementation.
The work on the Arden Syntax moved into ASTM in 1992 and was transferred in 1999 to HL7, where it became an HL7 standard. Work on that standard continues at HL7. The current version is 2.8, and version 2.9 is in final stages.
Arden Syntax arose from the need to make medical knowledge available for decision-making at the point-of-care; to make the knowledge and logic explicit; to allow sharing within and between institutions; and to standardize the way medical knowledge is integrated into health information systems.

9. Medical Logic Module (MLM)
MLM is a stream of text stored in an ASCII file in statements called slots
Slots consist of
Slotname
Slotbody
Slots are grouped into three categories:
Maintenance
Library
Knowledge
Arden is a "rules syntax" specification that allows rules to be individually published independently of a computer system and subsequently imported into computer systems for healthcare use. Arden implementation guides are published in a modular format by content providers, a guide for each rule.
Arden v2.6 Syntax is a formalism for procedural knowledge representation in clinical decision support systems. This lecture presents v2.6 of the Arden Syntax. HL7 is now developing a “Fuzzy Arden Syntax” that uses XML and was released as v2.7.
A medical logic module (MLM) is simply a text document identifying appropriate data elements engaged in the logic, the logic expressions, and the actions to be taken during a given event. MLMs are called by an event monitor when the condition they are written to help occurs.
MLM contains slots that are defined for specific purposes. MLM is a stream of text stored in an ASCII file in statements called slots. Slots are made up of a slotname and slotbody. Slots are grouped into three categories: maintenance, library and knowledge. Maintenance identifies the MLM, versions, authors, etc.; library includes purpose, name and keywords; and the knowledge is expressed via a logic algorithm.

10. Maintenance Example
• title: Contrast CT study in patient with renal failure;; • filename: ct_contr.mlm;; • version: 1.00;; • institution: Duke Medical Center;; • author: John Doe, MD;; • specialist: Jane Doe, MD;; • date: ;; • validation: testing;;
This slide illustrates a slot from the Maintenance category. It contains:
Title: Contrast CT study in patient with renal failure;;
MLM filename: ct_contr.mlm;;
Arden syntax version: 1.00;;
Institution: Duke Medical Center;;
Author: Dr. John Doe, M.D.;;
Specialist: Dr; Jane Doe, M.D.;;
Date: ;;
Validation: testing;;
Note the syntax of the slot. Name tags are terminated by a colon (:) and contents are terminated by double semicolons (;;).

11. Library Example library:
purpose: To alert the health care provider of new or worsening serum creatinine level.;;
explanation: If the creatinine is at or above a threshold (1.35 mg/dl), then an alert…;;
keywords: renal insufficiency; renal failure;;
citations: Proceedings of the Fifteenth Annual Symposium on Computer Applications in Medical Care; 1991 Nov 17-20; Washington, D.C. New York: IEEE Computer Society Press, 1991.;;
links: URL “NLM Web Page”,
This is an example of the library slot. Again, name tags are terminated by a colon (:) and contents are terminated by double semicolons (;;). It contains:
Purpose: To alert the health care provider of new or worsening serum creatinine level;;
Explanation: If the creatinine is at or above a threshold (1.35 mg/dl), then an alert… ;;
Priority (optional) – not included in this example;;
Keywords: renal insufficiency; renal failure ;;
Citations: Proceedings of the Fifteenth Annual Symposium on Computer Applications in Medical Care; 1991 Nov 17-20; Washington, D.C. New York: IEEE Computer Society Press, 1991.;;
Links: URL “NLM Web Page”,

12. Knowledge Example Type “data_driven” Coded and required
Presently only one type slot defined
Type: data_driven
“data_driven”
Implies that these slots follow:
Data
Priority
Evoke
Logic
Action
Urgency
The knowledge slot contains:
Type – coded and required. Presently only data-driven type is defined. This type requires these additional slots be defined:
Data – structured,
Priority - coded, optional,
Evoke – structured,
Logic – structured,
Action – structured, and
Urgency – structured.
Action is an action produced when the logic slot concludes true.

13. Data Slot Terms in the MLM that are matched to terms in the database
Use of { } implies flexibility in mapping to the institution’s local database
Mapping terms in this way separates the logic in the MLM from institution-specific information
The data slot identifies what data is involved in the logic and decision-making, and must be matched to the terms contained within the application database. The required data elements are identified within a set of “curly brackets” ({}). This has been a sore point for the Arden syntax, because it requires mapping for a local database and terminology set to a global construct. Mapping terms in this way separates the logic in the medical logic models (MLM) from institution-specific information. It has been referred to as the “curly bracket problem”. If semantic interoperability existed, then MLMs would be shareable globally. The potential for the number of MLMs would be thousands if not millions. Note: The curly brackets problem will be solved in v2.9 by incorporating the Health Level (HL) & Reference Information Model (RIM) into the standard.

14. Data Slot Read statement Examples of operators Without an operator
Obtains a list of values from the database
With an operator
Obtains a single value from the database
Examples of operators
First, last, min, max, count, average, sum
The data slot identifies the required data and invokes the extraction of the actual values of the data item from the application database [EHR].
The Read command is used to obtain a value for the identified data element.
A read statement without an operator will contain a list of data elements that obtains a list of all values for that data element from the database.
A read statement with an operator returns a single value.
Typical operators include first, last, minimum, maximum, count, average and sum; can you think of any other operator that you might use?

15. Evoked Slot Triggers an MLM Example The occurrence of an event
Timed execution after an event
Periodic repetition after an event
Direct call from another MLM
The evoked slot will trigger the logic operation of an MLM.
Examples of triggers include:
The occurrence of an event.
Timed execution after an event,
Periodic repetition after an event, and
Direct call from another MLM.

16. Evoked Slot - Example
data: creatinine_storage := event {'32506','32752'; /*isolated creatinine*/...'32506','33801';/* chem 20*/};
evoke: creatinine_storage;;
In this example, the data element is creatinine which could be the value from either data element or if the creatinine was measured as a single test (these are the codes for the data element), or could be part of a Chem 20, where the creatinine was part of a battery.
The evoked slot also sets the date time of creatinine storage.
The text between the asterisks (/*…*/) is a comment.

17. Evoked Slot – More Examples
Evoke: 3 days after time of creatinine storage;
Evoke: every q day for 7 days starting at time of creatinine storage;
Evoke: every 1 day starting at time of K_storage until K>=3;
This slide shows three other examples of an evoked slot:
Three days after the time the creatinine was taken.
Every day for seven days, starting at the time of the creatinine storage.
Every day starting at the time of creatinine storage and going for three days.
You can see some sophistication in time specifications.

18. Logic Slot Set of medical criteria Logical algorithm
Ends with a “conclude statement”
The logic slot contains a logic expression and ends with a conclude statement. The logic slot specifies the medical criteria by using a logical algorithm, and ends with a conclude statement.
The following slides will include some examples.

19. Logic Slot: If …Then … If <expr1> then
If <expr1> then <block1>
<block1>
endif;
elseif <expr2> then <block2>
elseif <expr3> then <block3> …
elseif <exprN> then <blockN>
else
else <blockE>
<block2>
endif
This logic slot shows three examples of logic:
One type of logic statement is IF … THEN statements.
The permissible constructs include if expression then execute a block of code; if then else constructs; and if elseif … and nested logic sets.

20. Logic Slot – Looping Statements
While <expr> do <block> enddo;
for <expr> do <block> enddo;
Looping statements are permitted. Looping statements are “do while” statements and “for loops”.

21. Logic Slot – Call Statements
var1 := call my_mlm with param1, param2;
var1 := call my_event with param1, param2;
var1 := call my_interface_function with param1, param2;
Call Statements permit linking to other MLMs including passing parameters. Examples of Call Statements are:
var1 := call my_mlm with param1, param2;
var1 := call my_event with param1, param2;
var1 := call my_interface_function with param1, param2;

22. Example – Call Statements
/* Define find_allergies external function*/
find_allergies := INTERFACE {\\RuleServer\AllergyRules\my_institution\find_allergies.exe};
/* Lists two medications and their allergens */
med_orders:= ("PEN-G", "aspirin");
med_allergens:= ("penicillin", "aspirin");
/* Lists three patient allergies and their reactions */
patient_allergies:= ("milk", "codeine", "penicillin" );
patient_reactions:= ("hives", NULL, "anaphylaxis");
/* Passes 4 arguments and receives 3 lists as values */
(meds, allergens, reactions):= call find_allergies with med_orders, med_allergens, patient_allergies, patient_reactions;
This slide includes specific examples of call statements. In a later unit we will talk about a Service Oriented Architecture framework approach. This construct supports that concept by providing service-specific functions with a defined call and defined return.

23. Conclude Statement conclude true; conclude false; Terminate the rule
Go to the action slot
conclude false;
Do not go to the action slot
Every logic slot must end with a conclude statement. The conclude terminates the rule. In addition, conclude true goes to the action slot for action to take if the logic condition is satisfied; conclude false terminates the rule and does not go to the action statement.

24. Logic Slot - Example logic: endif; if last_creat is not present then
alert_text := "No recent creatinine available. Consider ordering creatinine before giving IV contrast.";
conclude true;
elseif last_creat > 1.5 then
alert_text := “No recent creatinine available. Consider ordering creatinine before giving IV contrast.";
else conclude false;
endif;
In this example, if the record does not contain a creatinine value, show the alert message “No recent creatinine available. Consider ordering creatinine before giving IV contrast.“, and end the logic rule. If there is a value of creatinine and that value is greater than 1.5 then show the alert message “No recent creatinine available. Consider ordering creatinine before giving IV contrast.“, and end the logic rule. Else conclude false and end the logic rule.

25. Action Slot Carries out action if logic slot concludes true
Examples of actions
Write message to screen
Store a message in a file
Call another medical logic module
The action slot defines the action to be taken. Examples include:
Write message to screen;
Store a message in a file; and
Call another medical logic module.

26. Action Slot - Example action:
write “Last creatinine: " || last_creat " on: " || time of last_creat;
This action example results in the following display:
Last creatinine: 2.36 on: T06:30:00
The double filter bars will print the value of the data element after the filter bar.

27. Action Slot - Example data: ed_email := destination ‘ed@duke.edu’;
write at ed_ “Patient who may qualify for study registered today. Pt #: “|| patient_no;
Another action slot example will send an to The contents of the will be:
Patient who may qualify for study registered today. Pt#:
ed_ defines the address of the destination target.

28. Urgency Slot Determines importance of action if MLM concludes true
Coded slot with value from 1 (low urgency) to 99 (high urgency)
The urgency slot defines the importance of the action. The urgency may trigger different paths for the message – i.e. a page, a call, or an .

29. MLM – Time and Duration
Time data refers to points in time (time stamp)
Duration is an interval of time
Duration expressed as years, months, days, hours, minutes, seconds
Comparisons using time and duration
<time> is before <time>; <time> is after <time>; <time> is equal <time>; <time> is within <time> to <time>; <time> is within <duration> preceding <time>; <time> is within the past <duration>
The concept of time is important in decision logic. We need to be able to measure intervals of time between events. Duration can be expressed in:
Years,
Months,
Days,
Hours,
Minutes, or
Seconds.
The ability to compare times is also important: These comparisons are supported:
<time> is before <time>; <time> is after <time>; <time> is equal <time>; <time> is within <time> to <time>; <time> is within <duration> preceding <time>; <time> is within the past <duration>.

30. Operators Assignment: potassium : = 3.3
Comparison: =(EQ),>(GT),<(LT),>=(GE).<=(LE),<>(NE)
Logical
and, or, not
Mathematical
+ - * / () abs int sqrt log exp sine cosine tangent arcsin arccos arctan
The slide gives some typical operators that may be expressed in the logic statement. They include:
Assignment of a value to a data element potassium := 3.3
Comparisons such as equal, greater than, less than, greater than or equal; less than or equal, not equal;. These comparisons are represented by symbols.
Logical AND, OR, NOT
Mathematical operations +, -, *, / (plus, minus, multiply, divide)
Grouping (),
Absolute,
Square root,
Log,
Exponent,
and various trig functions.

31. Supporting Standards for EHR Applications Summary – Lecture a
Introduced the Arden Syntax which has been around for a long period of time.
The Arden Syntax is easy to use and has considerable power
One of the complaints of Arden Syntax is that it does not handle complex expressions, particularly those involving timing such as intervals after other events
This concludes Lecture a of Supporting Standards for EHR Application.
In this lecture, we introduced the Arden Syntax which has been around for a long period of time. The Arden Syntax is easy to use and has considerable power. One of the complaints of Arden Syntax is that it does not handle complex expressions, particularly those involving timing such as intervals after other events.
The Arden Syntax is used by several notable healthcare systems throughout the United States.

32. Supporting Standards for EHR Applications References – Lecture a
Acknowledgement: Material for this lecture was synthesized from Hl7 International Arden Syntax Standard.
Images
Slide 6: Source: W. Ed Hammond
No audio.

33. Supporting Standards for EHR Applications Lecture a
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated by Normandale Community College, funded under Award Number 90WT0003.
No audio.
Health IT Workforce Curriculum Version 4.0