Decision Support from Local Data: Creating Adaptive Order Menus from Past Clinician Behavior

Abstract

Objective

Reducing care variability through guidelines has significantly benefited patients. Nonetheless, guideline-based clinical decision support (CDS) systems are not widely implemented or used, are frequently out-of-date, and cannot address complex care for which guidelines do not exist. Here, we develop and evaluate a complementary approach - using Bayesian network (BN) learning to generate adaptive, context-specific treatment menus based on local order-entry data. These menus can be used as a draft for expert review, in order to minimize development time for local decision support content. This is in keeping with the vision outlined in the US Health Information Technology Strategic Plan, which describes a healthcare system that learns from itself.

Materials and Methods

We used the Greedy Equivalence Search algorithm to learn four 50-node domain-specific BNs from 11,344 encounters: abdominal pain in the emergency department, inpatient pregnancy, hypertension in the urgent visit clinic, and altered mental state in the intensive care unit. We developed a system to produce situation-specific, rank-ordered treatment menus from these networks. We evaluated this system with a hospital-simulation methodology and computed Area Under the Receiver-Operator Curve (AUC) and average menu position at time of selection. We also compared this system with a similar association-rule-mining approach.

Results

A short order menu on average contained the next order (weighted average length 3.91–5.83 items). Overall predictive ability was good: average AUC above 0.9 for 25% of order types and overall average AUC .714–.844 (depending on domain). However, AUC had high variance (.50–.99). Higher AUC correlated with tighter clusters and more connections in the graphs, indicating importance of appropriate contextual data. Comparison with an association rule mining approach showed similar performance for only the most common orders with dramatic divergence as orders are less frequent.

Discussion and Conclusion

This study demonstrates that local clinical knowledge can be extracted from treatment data for decision support. This approach is appealing because: it reflects local standards; it uses data already being captured; and it produces human-readable treatment-diagnosis networks that could be curated by a human expert to reduce workload in developing localized CDS content. The BN methodology captured transitive associations and co-varying relationships, which existing approaches do not. It also performs better as orders become less frequent and require more context. This system is a step forward in harnessing local, empirical data to enhance decision support.

1. INTRODUCTION⁺

A currently popular approach to improving the quality of health care is to make sure that similar cases are handled in similar ways, i.e., to reduce the variability of care. [1] Frequently this is accomplished through propagation of external protocols into practice, through mechanisms such as Clinical Decision Support (CDS). [2]

Unfortunately, computable CDS content is extremely expensive and time-consuming to create [3], maintain [4], and localize [5]. Consequently CDS has been much more slowly adopted than other components of Health Information Technology (HIT) [6]. Even when CDS available, the content is frequently inappropriate or incorrect. [7] Various projects are being undertaken to standardize computable CDS content in order to reduce the local implementer’s work (e.g., [8]).

Still, standardized CDS does not address the following issues: the frequency of content change in medicine, physician attitudes toward guidelines, and terminology challenges. First, much content, both routine and complex, is not distilled into guidelines. [9] This might be quite common; in one study, the literature provided answers to primary care providers’ routine clinical questions only 56% of the time. [10] Second, studies have shown that physicians value colleagues' advice at least as much as guidelines. [11] This might be because medicine is locally situated, and colleagues can provide a local frame of reference through which to decide if and how external guidelines relate to particular local cases. [12] Third, standardized content databases require translation of codes into standard terminologies, which is difficult and frequently causes failures in interoperability.

Electronic Medical Record (EMR) data is rapidly proliferating [13], in part due to the Meaningful Use incentive program. [14] These data offer the opportunity to harness local physician wisdom-how care is actually delivered - to augment and suggest protocols, vastly decreasing human effort in developing CDS content and making knowledge available in complex scenarios. It is possible to partially reconstruct physician decisions by aggregating the millions of treatment events in medical record systems. Such locally generated CDS content avoids the three issues discussed above. This fits into the Office of the National Coordinator for HIT’s strategic plan, which centers on building a “learning healthcare system” that can perform dynamic analysis of existing healthcare data to glean various information, including best practices. [15]

1.1. The Wisdom of the Crowd

Despite the incompleteness of guidelines and poor maintenance of expert-curated CDS, individual physician behavior is not reliable either. Studies show that care continues to be widely variable and that physicians’ treatment does not align well with guidelines. [16] Therefore we suggest two important goals in the design of a CDS tool based on local wisdom.

First, the average behavior of many physicians is usually much better than any individual physician. Condorcet’s jury theorem, upon which voting theory is grounded, proves that when each member in a group of independent decision makers is more than 50% likely to make the correct decision, averaging those decisions ultimately leads to the right answer. [17] If we believe that a physician is more likely than chance to make the correct decision, we can trust the averaged decision. The theorem does have two important caveats. First, it is only guaranteed to apply to binary choices (plus an unlimited number of irrelevant alternatives). [18] Thankfully, many high-level medical decisions are of this type (e.g., “do I anticoagulate this patient or not? ”). Second, crowd wisdom can become crowd madness when decision-makers are not truly independent but are influenced by some outside entity. [19] And of course, practitioners are influenced by colleagues, formularies, available equipment, local culture, etc. The Dartmouth Atlas project has found that the quality of care in a region is profoundly influenced by the ‘ecology’ of healthcare in that region, including resources and capacity, social norms, and the payment environment. [20]

This leads out second goal design requirement. Even when averaging decisions, it is impossible to guarantee that results are not influenced by these caveats. Therefore we do not seek to replace manual content development with automatically generated CDS content. Instead, our goal is to complement content development with knowledge distilled from EMR data. To this end, it was important to choose a data mining approach which produces output that a human expert could understand and update before inserting it into a clinical system.

1.2. Mining EMR Data

A handful of studies have explored methods to abstract treatment decisions captured in EMR data into knowledge bases [21–25] or to find knowledge on-demand [26]. The majority of work in abstracting EMR data have used variations of Amazon.com’s pairwise association-rule mining (ARM) algorithm [27], which has shown good results when capturing global linkages where little variability exists (e.g., drugs used for HIV treatment). [28] However, researchers have struggled with both transitive associations and the long, static lists of associations that do not take context into account. In one case, the results of such an approach required a great deal of manual editing before incorporation into a decision support system. [29] Other studies have used this approach only as a rudimentary starting point for content developers. For example, the condition-treatment linkages in RxNorm were ‘jumpstarted’ by this approach. [24]

Bayesian Networks (BNs) are an appealing alternative for mining wisdom from EMR data. BNs are a powerful multivariate, probabilistic reasoning paradigm that naturally model interactions among associations. BNs have a two-phase lifecycle. First, they are constructed, either by hand-which has been widespread in medical informatics research (see e.g., [30]) - or more recently from databases of observational data. [31] Such ‘structure learning algorithms’, as they are called, take into account transitive associations and co-varying relationships that pairwise rule mining cannot. Therefore, BN structure learning might be able to make sense out of the tangled correlations in clinical data that have hampered other approaches. The second phase of the BN lifecycle is its use-rather than being static networks or rules, BNs enable rapid, iterative exploration of decisions as context evolves.

In a previous study, we piloted a BN approach to produce static order menus for complications of inpatient pregnancy. [32] Our results were very promising, but our scenarios were fixed, they only explored one small domain of medicine, and they relied on the opinion of a single nurse practitioner to evaluate our results. In this study, we more fully flesh out our previous work to use BNs to learn the typical successions of orders made by clinicians for a variety of types of cases. Next, we build a recommendation system that responds adaptively to suggest the most common next orders based on what has been ordered and diagnosed previously. Third, we evaluate this system on hospitalization order-entry data in a multitude of scenarios across four domains. Finally, we undertake a brief comparison of this dynamic approach to a static ARM-like approach.

1.3. Objective

Our goal was to develop a methodology to produce adaptive, patient-tailored, situation-specific treatment advice from order-entry data, which can be used as a draft for expert review, in order to minimize development time for local decision support content. We used Bayesian Networks because of their adaptive nature and their ability to account for transitive associations and co-varying relationships. Also, they are human-readable and could therefore be curated by a human expert. We built and evaluated a recommendation system that dynamically suggests the most common next order based on what has been ordered previously. We also compared it to a static ARM-like approach.

2. MATERIAL AND METHODS

2.1. Bayesian Networks and Induction from Data

A BN is a directed graph of vertices (nodes) and edges connecting those vertices. Embedded in each node is a conditional probability table (CPT), which specifies the probability of each node state given the state of each parent. In this work, we learn BNs that represent the probabilistic relationships among orders and diagnoses. Then, as specific orders are placed and diagnoses made in a specific case, we instantiate the variables corresponding to those actions in the network (known as evidence), which revises the probabilities for other orders in the BN to the posterior probability that they would be placed conditioned on the previous actions. This allows us to rank remaining orders by their probability of occurring. In our interface, we present these to the user as orders are placed, in descending order of probability. We do not present diagnoses on the order menus, because the goal is to suggest treatments, leaving diagnosis to clinicians. An example of a simple BN, the underlying probabilistic relationships, and the revised posterior probabilities given evidence is shown in Figure 1. The methodology, Iterative Treatment Suggestion (ITS), is summarized in Table 1. We implemented this methodology in Java using the SMILE toolkit [33], a freely available toolkit for network inference. A prototype of this interface can be seen in Figure 2.

Figure 1.

An example Bayesian Network (left), the conditional probability tables associated with it (middle), and the posterior probabilities given the evidence of ‘Abdominal Pain’ (right).

Table 1.

A formal description of the ITS methodology for suggesting orders via a Bayesian network. This parallels the graphical example in Figure 2.

Algorithm: Iterative Treatment Suggestion (ITS)

Where:

G is a Bayesian Network Model

O is a set of possible orders, initially including all orders in G

D is a set of possible diagnoses, including all diagnoses in G

E is a set of evidence, initially containing all D set to false

Do:

1. Update beliefs (compute the posterior probability of all O ∉ E).

2. Create a list of all O ∉ E in descending order of posterior probability, optionally stopping at a predefined threshold.

3. Display the list and D to the user and wait for the user to choose an order or diagnosis from the list.

4. Move the order from O to E, or set the diagnosis to true in E.

Until the user closes the session

Figure 2.

A prototype implementation of Iterative Treatment Suggestions (ITS). The panel shows the current evidence (labeled 0 or 1) and the possible orders in descending probability order. As orders and diagnoses are placed (the toggle button), the evidence is revised and the posterior probability of possible orders given the network is recalculated.

2.2. Inducing Bayesian Networks from Data

A common approach to induce a Bayesian network from data (called structure learning) is a greedy search-and-score methodology. From a set of disconnected nodes, edges are added, removed, and reversed until a network is found that best explains a training dataset according to a scoring function. Here we used the BDeu scoring function. [34] A greedy search is used because a complete exploration of all possible graphs is combinatorial, and so is therefore not possible on networks of more than a few nodes. [35]

The most powerful greedy search is arguably the Greedy Equivalence Search (GES). [36] Rather than searching Bayesian networks, it searches what are known as ‘equivalence classes’ of Bayesian networks. These are groups of Bayesian networks that all are probabilistically equivalent. If an optimal Bayesian network exists for the given dataset, GES will always find it. Therefore, we used a GES implementation in the freely available Tetrad toolkit. [37]

2.3. Hospital Simulation Methodology

To evaluate ITS in the myriad of evolving clinical situations, we chose to compare how well the suggestion menus predict the actual next action taken in a hospitalization. Therefore we wrote a program to simulate hospitalizations on our test set using the ITS methodology. As in ITS (Table 1), our program places each order in the hospitalization in succession, adding it to the ‘evidence’ in the network, and recalculating the posterior probabilities for variables in the network. It also adds diagnoses as evidence at the appropriate time step in the hospitalization. After each order in the hospitalization, our program records the posterior probabilities in the menu (step 2), in order to calculate performance in predicting the next order. To determine order succession within each hospitalization, we used the time and session information in our order-entry data. Where two orders had the same recorded time, we used both possible orderings and kept the higher-scoring combination. In the event an order was placed more than once, subsequent placements were ignored (because our system allows orders to be entered as evidence only once).

Using the recorded posterior probabilities and the actual next order placed, we were able to compute the Area Under the Receiver-Operator Curve (AUC). This measures discriminability, equivalent to the probability that when an order is placed, it will be ranked higher than at previous times. We used the approach in Hanley and McNeil [38] to calculate the AUC directly without first calculating the full ROC curve. The formula is as follows:

$$AUC(\overrightarrow{T},\overrightarrow{F})=\frac{\sum _t^{\overrightarrow{T}}\sum _f^{\overrightarrow{F}}\{\begin{array}{cc}\hfill 1\hfill & \hfill t>f\hfill \\ \hfill 0.5\hfill & \hfill t=f\hfill \\ \hfill 0\hfill & \hfill t<f\hfill \end{array}}{\Vert \overrightarrow{T}\Vert *\Vert \overrightarrow{F}\Vert }$$ (1)

Here T⃗ is a list of posterior probabilities for true instances of a particular order, and F⃗ the corresponding list for false instances.

We also computed the average position an order appears in the menu at the time it is selected. This measures accuracy by reporting the average list length required for 100% precision. The value is between one and the total number of orders in the network, where one is the top of the menu (and is therefore the best outcome).

2.4. Comparison with Association Rule Mining

To compare our approach to pairwise association rule mining (ARM), we developed a variant of the ITS hospital simulation methodology. It performs the same analysis of average menu position but it uses a static menu of orders, which are arranged in descending frequency of co-occurrence with the main diagnosis in each domain (e.g., pregnancy in inpatient pregnancy). To facilitate direct comparison, the orders selected by GES were used to generate the menu in each domain.

2.5. Evaluation

2.5.1. Data Source

For evaluation, we chose four modalities of medicine: inpatient medicine, the emergency department (ED), the urgent visit clinic (UVC), and the intensive care unit (ICU). Each modality reflects a different aspect of medicine. Inpatient care focuses more on treatment than diagnosis in a longer-term stay, the ED involves a shorter stay involving both diagnosis and treatment, the UVC involves a very brief ‘stay’ focused on diagnosis, and the ICU involves tightly-correlated actions for very specific care.

We extracted data for four domain-specific BNs from the four selected modalities as follows:

1. Choosing chief diagnosis: We focused our domains on the most frequent diagnosis/complaint for the four modalities: visits involving pregnancy in inpatient medicine, back pain in the ED, hypertension in the UVC, and ‘altered mental state’ in the Medical ICU (MICU).

2. Data extraction: We extracted and de-identified 3 years of inpatient order-entry data from the local county hospital in Indianapolis (2007–2009) and chose visits that corresponded with each domain. This involved 9228 ED back pain, 1821 UVC hypertension, 4843 inpatient pregnancy, and 1546 ‘altered mental state’ MICU visits.

3. Variable selection: For each domain, we selected 50 variables: the 40 most frequent orders and the 10 most frequent co-occurring diagnoses and complaints. Orders were of low granularity, which ensured sufficient data for predictive power; for example, medication orders only included the type of medicine (e.g., vancomycin), not the route, dose, or frequency. The diagnoses and ,complaints used in our networks can be seen in Table 2. Note that sometimes less than ten are shown because fewer than ten diagnoses/complaints co-occurred with the diagnosis.

4. Train/test split: We split each data set into a training (2/3 of admissions) and test set (1/3).

Table 2.

The co-occurring diagnoses and complaints in each domain-specific network, listed by their prevalence in the test sets. 0% indicates the co-occurrence was only present in the training set. These were used as evidence as they appeared in the test cases, and were not part of the predictive evaluation.

Pregnancy, Inpatient		Back pain, ED		Hypertension, UVC		Medical ICU
Postpartum	89%	Vehicle Accident	4%	Med Refill	27%	Hypotension	<1%
Cesarean Section	4%	Neck Pain	3%	Diabetes Mellitus	16%	AIDS	0%
Spont Vag Delivery	2%	Abdominal Pain	3%	Back Pain	6%	Drug Abuse	0%
Tubal Ligation	1%	Chest pain	2%	Abscess	6%	Diabetes Mellitus	0%
Pre-Eclampsia	1%	UTI	2%	Coronary Artery Disease	4%	Encephalopathy	0%
Preterm Labor	1%	Headache	1%	Toothache	4%	Anemia	0%
Abdominal Pain	1%	Knee Pain	1%	Cellulitis	4%	Hypoglycemia	0%
C-Section Repeat	<1%	Hypertension	1%	Headache	3%	Hypokalemia	0%
Failed Induction	<1%	Med Refill	1%	COPD	3%	Sepsis	0%
Failed induction	0%	Shoulder Pain	<1%	Hyperlipidemia	<1%

2.5.2. Computational Approach

Using these four data sets, we applied and evaluated the BN and ARM methods as follows:

1. Network induction. Via GES (Section 2.2), we induced four Bayesian networks using each of the four training sets. Because GES will discard nodes that do not have predictive power, sometimes the resulting networks contained fewer than 50 nodes. This was most notable in the ICU network, where only 25 orders were retained.

2. Hospitalization simulation. We ran our ITS hospital-simulation program (Section 2.3) on each the each of the four networks using their corresponding test set, which collected statistics on AUC and average position in the menu at time of selection.

3. Visualization. We wrote a program to export the networks into Gephi format. Gephi is an open-source network visualization tool. [39] We wrote a Gephi script to select the Markov Blankets for a set of nodes. A Markov Blanket of a node is its parents, children, and siblings, and is frequently used as a heuristic for the set of most relevant variables in prediction. [40] This allowed us to visually examine nodes in a graph and their most important neighbors.

4. Comparison to association rule mining. We ran our ARM-based hospital-simulation (Section 2.4), which collected statistics on average position in a static menu at time of selection.

3. RESULTS AND DISCUSSION

A standard desktop computer induced each network (step 1) in less than 30 minutes and ran the ITS hospital-simulation program (step 2) in an average of 5 minutes. Table 3 shows summary statistics: average AUC and average menu position, weighted by the frequency of each order. Figure 3 shows trendlines of the average position vs. order rank by frequency. For each domain, the 10 orders in which the system performed best and worst (by AUC) are shown in Table 4.

Table 3.

For each domain, the weighted average AUC (area under the receiver-operator curve) and position in menu at time of order, where 1 is the top suggestion). Weighting is by frequency of order.

Domain	Weighted Average:
	AUC	Position
Inpatient Pregnancy	.844	3.91
Medical Intensive Care Unit	.781	5.72
Back pain in the Emergency Department	.765	5.83
Hypertension in the Urgent Visit Clinic	.741	4.88

Figure 3.

The average position in the list at the time of order vs. the frequency rank of the order in the test sets.

Table 4.

Order name, AUC, and average menu position (#) of the best and worst order predictions in each domain. ‘Best’and ‘worst’ are chosen by AUC (higher is better). Menu position, showing the average location in the suggestion menu just before selection, is also reported (lower is better).

Pregnancy, Inpatient			Back Pain, ED			Hypertension, uvc			Altered Mental State, MICU
Name	AUC	#	Name	AUC	#	Name	AUC	#	Name	AUC	#
Sitz Bath	1.00	1.0	Abdomen CT	1.00	1.0	aPTT	1.00	1	Vancomycin Level	0.94	7.6
Cold Pack	1.00	1.1	Pelvis CT	1.00	1.2	Cardiac Markers	0.99	1.4	Ventilator Adjustment	0.94	2.7
Naloxone Inj	1.00	1.2	Peripheral Smear	0.96	11.6	ESR Test	0.97	6.7	Phosphorus Test	0.93	2.1
Lung Exercise	0.99	1.1	Cardiac Markers	0.96	2.2	Protime	0.95	1.8	Magnesium Level	0.91	2.9
Morphine (PCA)	0.99	2.0	Blood Cell Profile	0.95	1.7	Blood Culture	0.93	13.2	Basic Metabolic Panel	0.90	4.3
Ext. UC Monitor	0.99	1.0	Lipase	0.94	3.4	Drug Abuse Urine Test	0.92	3.7	Cardiac Markers	0.84	11.2
Ibuprofen	0.98	1.1	Vaginal Infection Test	0.93	5.7	BNP Test	0.91	6.8	Esomeprazole	0.84	6.9
Ext. FHT Monitor	0.97	1.1	Chest CT	0.92	9.4	Blood Cell Profile	0.88	2.3	Glucose	0.82	7.5
Docusate Na	0.96	1.2	Spine Cervical CT	0.92	4.7	Urine Culture	0.83	11.3	IV Fluids	0.82	1.7
I&O Monitoring	0.94	1.2	Comp. Metabolic	0.92	3.3	Dental Consult	0.82	6.4	Vancomycin	0.81	4.3
NPO	0.73	1.5	Phys. Therapy Consult	0.64	12.4	Hgb A1c	0.72	22	Zosyn	0.72	11.5
IV Lock	0.73	9.8	Lumbar Spine CT	0.63	29.4	Medicine Consult	0.69	2.6	NPO	0.71	12.7
Syphilis Screen	0.73	9.5	Knee Xray	0.62	23.4	Med Follow-up Consult	0.67	5.2	SCD	0.71	7.1
Ice Chips	0.72	15.8	Wrist Xray	0.61	38.1	Dermatology Consult	0.66	13.5	EKG	0.70	10.5
IV Fluids	0.71	1.1	Sports Med. Consult	0.60	31.7	Lateral Chest Xray	0.62	6.3	Restraints	0.68	3.5
Drugs Urine Test	0.71	27.8	EPIC Referal	0.59	29.0	Physl Therapy Consult	0.57	21.4	Frontal Chest Xray	0.68	3.7
Oxytocin Protocol	0.68	23.8	Neurosurgery Consult	0.59	13.8	Head CT	0.56	28.0	Albuterol	0.63	17.7
Type and Screen	0.65	13.2	Medicine Consult	0.58	5.8	TSH	0.50	22.0	Furosemide	0.55	15.3
Lortab 5/500	0.60	2.9	Med Follow-up Consult	0.57	6.5	T4-Free Level	0.50	28.0	Prealbumin	0.51	12.5
Morphine	0.50	22.7	Lumbar Spine MRI	0.53	17.5	Knee Xray	0.50	23.8	Arterial blood gas	0.50	5.7

Figures 4–6 show portions of the graph structure (step 3). Figure 4 shows the Markov Blankets around some nodes in the pregnancy network with high AUC. Figure 5 shows nodes with high AUC and their parents and children in the other three networks. Figure 6 does the same with nodes of low AUC. Note that arrow directions should not be interpreted as showing causality, only a statistical association.

Figure 4.

A portion of the inpatient pregnancy networks. This figure shows the Markov blankets of C-Section Operative Note, Ext. UC Monitor, and Sitz Bath, three nodes with high AUC in Table 4. These three Markov Blankets comprise the majority of the total graph, and the graph forms one single connected component - indicating strong relationships between all nodes in this network. Orders are purple; problem/complaints are yellow. Node/label size is proportional to AUC, and edge weight is an approximation of the strength of relationship. Notice the highly-correlated clusters, e.g. Sitz bath and other postpartum treatments (cold pack, ice chips, lanolin, etc).

Figure 6.

Low AUC nodes from Table 4 with their parents and children in all domains but inpatient. Notice the linear chains, multiple subnetworks, connection to infrequent diagnoses, and transitive relationships. This indicates appropriate context is lacking for these nodes.

Figure 5.

High AUC nodes from Table 4 with their parents and children in all domains but inpatient. MICU is blue, UVC is green, and ED is red. Problems/complaints are yellow. Node/label size is proportional to AUC, and edge weight is an approximation of the strength of the relationship. Here, notice the logical clusters and intuitively correct relationships.

Finally, Table 5 and Figure 7 compare the BN approach (step 2) to an ARM approach (step 4). Table 5 shows the weighted and unweighted average difference in list length between ARM and BN. Figure 7 shows average menu position vs. order rank by frequency using ARM. It is directly comparable to Figure 3 for the BN approach.

Table 5.

For each domain, the weighted average position in menu at time of order, where 1 is the top suggestion, for the BN and ARM approaches. Weighting is by frequency of order. Also shows the weighted and unweighted difference in average list length (ARM-BN).

Domain	Weighted Average Position:			Unweighted
	BN	ARM	Difference	Difference
Inpatient Pregnancy	3.91	5.67	+1.76	+2.73
Medical Intensive Care Unit	5.72	5.95	+0.23	+1.14
Back pain in the Emergency Department	5.83	9.87	+4.04	+7.64
Hypertension in the Urgent Visit Clinic	4.88	6.06	+1.18	+4.04

Figure 7.

Using an association rule mining approach, the average position in the list at the time of order vs. the frequency rank of the order in the test sets.

3.1. Analysis of BN Approach

The evaluation of our treatment suggestion system on four domain-specific BNs against test cases drawn from the same environments showed fairly strong overall performance. In particular, our treatment suggestion menus correctly suggest common orders in a short list: 3.91–5.83 items (Table 3). A length of five accurately suggests more than the top 20 inpatient pregnancy orders and emergency department back pain orders (Figure 3). Also, the system’s average AUC is high (74%–84%, also in Table 3), meaning that common orders are ranked higher at the time they are ordered than prior to ordering.

There was high variance in performance on individual orders (AUC 0.5–0.99), both across and within domains (Tables 3 and 4). Within a domain, some orders are suggested almost exactly when they should be, such as a cold pack in pregnancy visits and a pelvis CT in the ED. Other orders appear at the bottom of long menus and are not predicted much better than chance, such as a neurology consult in the ED. Performance varied across domains as well. Inpatient pregnancy had a weighted average AUC .884 and menu position 3.91 (Table 3), and even the least frequent orders required a menu length of only half the total orders (Figure 3). In the other domains, average AUC and menu length were notably worse and the least frequent orders required a menu length containing at least 75% of possible orders.

Figures 4–6 shed light on this phenomenon. For high AUC nodes (Figures 4 and 5), the network diagrams are tight clusters with connections that make intuitive sense. For example, postpartum is directly connected to adjuncts like simethicone, toothache is connected to a dental consult, and related tests like magnesium and phosphorus levels are linked. This clustering and intuitiveness indicates that the correct amount of context was provided for these nodes. The pregnancy network formed one giant cluster, which likely explains its high overall performance. The low-performing nodes in the other networks were either part of smaller subnetworks, or, in the case of the MICU, relied on infrequent diagnoses that were not in the test set (Figure 6). Relationships among low-performing nodes are frequently almost linear and have non-intuitive connections, indicating transitive associations due to missing context. For example, restaints is directly connected to vancomycin (see Figure 6, MICU) - both might be appropriate when a patient has an infection causing delirium, but they are not predictive of each other. Also a general medicine consult does not directly predict a diagnosis of diabetes (see Figure 6, UVC), nor does a lumbar spine x-ray directly suggest a knee x-ray. The context needed likely includes: additional well-chosen orders and diagnoses, external information about patient health status, test results, and family history. This points to the need for additional data sources and more principled feature selection.

Another interesting discovery is that AUC is not always strongly correlated with menu position. Two examples can be seen in Table 4. A peripheral blood smear in the emergency department has high AUC but an average menu position of 11.6, and an order for Lortab (a narcotic painkiller) in inpatient pregnancy appears near the top of the suggestion menus but has AUC of only 0.60. In the first case, we suspect that although the blood smear’s probability increases just prior to it actually being ordered, it is never high enough to outweigh other orders. In the second case, we believe the order stays at the top of the menu until it is picked because it has a high prior probability. We therefore conclude that choosing order-specific probability thresholds might be appropriate.

3.2. Comparison to ARM

Our results confirm previous results regarding ARM approaches: while an ARM approach can readily detect the most common associations, the strength of less common associations depend on context (e.g., previous orders and diagnoses) that ARM cannot capture.

In Table 5, there is a relatively small difference in weighted average menu length between the two approaches (Table 5), especially in smaller domains like the ICU (difference +0.23 items). This indicates similar performance for the most common orders. However, the unweighted difference is larger (+1.14–+7.64 items), suggesting that the BN approach is having more impact on less common orders.

Comparing Figure 7 (ARM) to Figure 3 (BN) confirms this. Figure 3 displays a slow increase in menu length as more orders are included, but Figure 7 shows a much steeper rise. With the BN approach, a length of five accurately suggests an average of 16 orders (Figure 3). The same menu length with the ARM approach accurately suggests only 9 orders on average (Figure 7). Performance degrades rapidly as menu length increases. This confirms the BN approach’s overall superior performance.

3.3. Limitations and Future Directions

This research is predicated on the assumption that average patterns in the data represent reasonably good care for future patients. As detailed in the Background, in many decision-making problems, average patterns do in fact represent ‘crowd wisdom,’ [41] but `crowd madness’-the domination of bad decisions in a group - can occur as well. Automatically discriminating wisdom from madness is important future work. Presently the ‘wisdom’ discovered should be reviewed by experts and aligned with guidelines before deployment.

The other principal limitation is that our models currently rely only on a small set of orders and diagnoses. We do not include other important factors such as test outcomes and physiologic changes. Also, we evaluated the networks using time-stamped data but the algorithm we used to learn networks does not utilize time information. Additionally, among orders and diagnoses, we choose the most frequent. All of this biases our system to short-term decisions that can be made with minimal context. We believe accuracy will be improved significantly with context-aware feature selection and temporal extensions to BN structure learning.

Our system and evaluation do not currently accommodate multiple orders of the same item within a hospitalization. Upon examination of our training sets, only orders in the ICU occurred multiple times on average per hospitalization. However, in the ICU, 16 orders (e.g. ventilator protocol changes, IV fluids, and common tests) do occur with multiplicity, and for this we need to develop a more complex methodology. We are exploring use of a ‘temporal window’ around the actual occurrence of the order in which we consider it a true instance.

The BN approach requires networks remain relatively small, or data requirements and computational complexity become intractable. [42] We do not believe this makes them unattractive to ‘big data’ problems, but it will require an approach to intelligently create sets of largely independent domain-specific networks. We also plan to explore structure-learning algorithms that scale to larger data sets.

Our comparison to ARM was a side-by-side comparison that might have unfairly benefitted ARM. For one, only items chosen by GES were used in the menu - and some of the dropped associations might have been incorrect transitive associations. Also, including less common orders might show even more difference between BN and ARM. Further comparison is important future work.

Finally, our evaluation measures - AUC and menu position - only capture two aspects of the approach’s predictive performance - discriminability and precision. There are many other classification evaluation measures (see for example [43]). For this methodology, it would also be valuable to measure the menu’s utility as a decision-making aid. This could be done computationally using a decision-theoretic approach like decision curve analysis [44], or by soliciting feedback regarding sample menus from potential users.

4. CONCLUSION

The proliferation of medical data in EMRs offers an opportunity to abstract these data for use in clinical decision support. Both the challenges associated with creating localized decision support and the incompleteness of guideline recommendations make this an important task. Existing approaches using pairwise association rule mining produce long static lists that accurately capture only common, direct associations.

In this work, we have developed and implemented a system using Bayesian network learning to discover the typical successions of orders made by clinicians from local order-entry data, which we have used as an adaptive recommendation system to suggest the most common next orders based on what has been ordered and diagnosed previously. We used a hospitalization-simulation evaluation methodology to determine how well our system reproduces reasonable behavior in four medical domains.

Our system performed fairly well on average in all domains but had variance that suggested future improvements. It performed best in inpatient pregnancy (weighted average AUC .844, weighted average menu position 3.91) and worst in the urgent visit clinic (weighted average AUC .741, weighted average menu position 4.88). Our system had near-perfect performance on some orders (e.g., cold pack in inpatient pregnancy) but very poor performance on others (e.g., arterial blood gas monitoring in the medical intensive care unit). Higher performance appears to correlate with the presence of more factors needed to predict the order.

Comparing our system to an ARM-based equivalent, we found that only the most common orders are accurately suggested by both systems, and that a menu length of five suggested only about half as many orders accurately in ARM vs. BN. This confirms that despite the future work needed in our system, it does outperform existing approaches.

This study is a step forward in clinical knowledge-abstraction systems. Such a system could eventually be part of the envisioned “learning health system,” in which a variety of clinical users-including researchers, administrators, and physicians - could dynamically analyze vast amounts of data for improved decision-making. This could be used for e.g., workload reduction in developing localized CDS, or as a method to quickly analyze local practice patterns.

• Local wisdom can complement expert-curated decision support to reduce workload.

• We reconstruct physician decisions by aggregating events in medical record systems.

• Our approach finds complex data relationships and creates dynamic order menus.

• We simulate the menus in a test set; many scenarios show strong performance (AUC>.9).

• Our approach increasingly outperforms a simpler approach as orders become rarer.