illustrates a symptom detail algorithm with five major steps. The first step identifies the detail of interest. The second step identifies interventions of potential interest. The third step identifies finding responses of interest, called features. The fourth step identifies interventions that trigger interesting features, providing time-value series for the next step. The fifth step uses a Bayesian network to inspect the series, finally merging with the previously developed algorithm for general symptom trends.
1. Identifying details of interest
The simulator would typically calculate a series of time-value pairs, and apply the query’s logic to the series, following the previously described algorithm.7
In the process of solving the Bayesian network, the state of that network’s root node is determined. Although most Bayesian networks applications do not define a root node concept, our networks always have a node that broadly summarizes the content the simulator requires. In the example of chest pain, the root node might have separate states indicating presence or absence of exertional chest pain.
The report template is a string with embedded references to nodes named in the query’s logic. The simulator replaces these references with text associated with nodes’ states, producing a report to return to the presentation system. The simulator assembles an XML structure with this string tagged as the main result.
The detail list may contain any number of items. The simulator scans this list for details where the root node state matches the solution of the root node in the query’s logic. If the detail does not identify a root node state, it matches all root node states. Any non-empty subset of items matched to the root node state will include items with one or more distinct types. The subset could have multiple items with the same type. For each unique type in the subset, the simulator adds a <Detail> tag to the XML document, with the type identified as an attribute of the tag, e.g.:
<Detail type= “Palliative”>…</Detail>
If the detail report template is not empty, then the simulator uses the parent query’s logic to supply phrases to replace any node references in the template. The simulator places the template solution between the <Detail> tags, and marks it as text. This mechanism will often suffice for details regarding quality, radiation, and severity of a symptom.
If the detail report template is empty, then the detail must identify a query object. In this case, the query object id is embedded in the detail tag.
The final XML result looks like this:
<HText>I have chest pain with exertion.</HText>
<Detail type= “Quality”>
The presentation system receives this XML result and displays the content marked by the <HText> tag as the virtual patient’s response to the original query. The presentation system may draw attention to the available details with hyperlinks or any suitable control. The user reviews the result of the query, and selects any details to pursue. When the user selects a detail with pre-specified text, the presentation system immediately returns that text. When the user selects a detail that references a query id, the presentation system sends that key back to the simulator.
In addition, the presentation system could allow the user to search for details using free text. For instance, the user might ask, “How does nitroglycerin affect your pain?” The natural language matching program would identify the query as a palliation detail involving a specific intervention, sublingual nitroglycerin. The presentation system would return the ids of the detail query and the intervention.
2. Identifying interventions of potential interest
The second step identifies interventions of potential interest when the virtual patient responds to the detail query. If the user requests information about specific interventions, then this step finds the intersection of the requested set of interventions and the set of interventions that the virtual patient has actually used. Otherwise, all of the interventions that the patient uses now, or has used in the past, are of potential interest.
This step prepares the virtual patient to either answer the question about specific interventions, or survey all of the medications it has taken in search of any that are relevant to the detail. If the patient does not use an intervention identified with a query, then a default negative answer is returned.
3. Identifying findings and features of interest
The simulator uses the detail query id to locate a query object. This object may have the same structure as the general query, or it may use the shape source attribute to identify a finding, a finding feature, and site. The simulator uses these shape source data to locate a finding attached to the patient.
Findings describe relatively low-level physiologic data, such as diastolic or systolic blood pressure, glucose level, or myocardial oxygen supply. Findings are divided into Specific Findings, which are typically related to diagnoses. For instance, different myocardial oxygen supply parameters might correspond to different simulated stages of coronary artery disease.
Specific Findings comprise any number of Specific Features, such as baseline value, circadian rhythm, and response to medication. Specific Features have at least one Pattern (triggering event and a list of time-value pairs). Within a Finding, every Specific Finding’s list of Specific Features should describe the same list of Features, but the Specific Feature data differ between Specific Findings. The Finding structure is:
Specific Finding List
4. Identifying intervention-triggered effects
By comparing an intervention selected in step 2 with the list of trigger interventions located in step 3, the simulator may locate one or more related time-value series. If none are located, the intervention from step 2 has no effect. If one or more time-value series are located, then the simulator can compare the dose associated with each to the dose actually taken by the patient, interpolating as necessary to predict the effect of the patient’s dose. For instance, a Finding structure can describe in one Pattern the vasodilating effect of 0.3 mg of nitroglycerin and, in a second Pattern, the effect of 0.6 mg of nitroglycerin. If the patient uses some intermediate dose, such as 0.45 mg, the simulator can predict the vasodilating effect as intermediate in duration and efficacy between the effects of 0.3 and 0.6 mg doses.
If the virtual patient does not currently use an intervention, the simulator determines whether the patient used the intervention during the time interval described in the original general question. If the intervention has any overlap in time with the symptom, the patient is allowed to describe the intervention’s effect in detail.
At the conclusion of this step, the simulator has a list of interventions relevant to the patient and the Finding and Feature specified by the user’s query, and a time-value series associated with each intervention.
5. Merging with the general trend algorithm
The process that generates a general symptom trend uses a Bayesian network (the logic attribute of a Query object) to analyze a time-value series generated by repeatedly sampling a virtual patient’s symptom status. This Bayesian network can use a variety of predefined analysis nodes to describe different qualities of the time-value series, such as its duration, the time of maximum value, and the maximum value. The Bayesian network can also access any other descriptive information about the patient, such as the presence or absence of specific diseases or interventions.
After setting node states that directly reflect input data, the simulator obtains a stochastic solution to the Bayesian network. For each node having an indeterminate state, a random number between 0 and 1 is recovered (if the node has been resolved before and consistency is desired) or generated. The number is used to assign one of the possible states. The node states in the solution provide text fragments to insert in the report.
Although the times in details’ time-value series may be much shorter than those in the general temporal response data, most predefined analytic nodes require few if any changes are required to manage details. At this step, for each detail query object, for each intervention, the logic Bayesian network evaluates the intervention’s time-value series. The report generated by this evaluation is appended to a report listing the effects of each intervention. The complete report is a list of interventions and effects on the details of interest.