External applications (part 2)

This description applied to RetroGuide (retrospective component of the HealthFlow system, but it is still valid to the overall HealthFlow system (which indludes retrospective mode (RetroGuide) as well as prospective mode (FlowGuide)

For full info, see this book: http://www.amazon.com/dp/3639100999

 

1 External applications revisited

1.1.1 Phase 2: Scenario development

In the scenario development phase, a workflow editor is used to create or modify a RG scenario. Key concepts, such as the scenario’s flowchart and code layers, RGEAs, variables, and conditions, were introduced in section 3.1. This section will describe their use in greater detail. The end product of this phase is a scenario with a fully populated code layer so that the scenario is executable.

The scenario development phase is the key methodological step where collaboration of the requestor and the analyst occurs. The flowchart layer is the key facilitator of this collaboration. Although a complex scenario can be created from scratch in one editing session, RG was designed to support a gradual and iterative scenario development process where an initial, simple scenario version is progressively extended into more complex versions. The requestor usually suggests the flowchart of the initial version. Any fundamental changes originating either from the requestor or the analyst are reflected in the flowchart layer through addition of new analytical steps (nodes in the flowchart), modification of existing steps, or addition of new transition conditions (arrows in the flowchart).

In the most common collaboration setting, the requestor deals with the flowchart layer, whereas the analyst is responsible for the code layer. The flowchart layer enables annotation of the nodes or arrows with textual comments. Without requiring knowledge of RG’s code layer, the requestor can use these annotation fields to specify the required EHR data elements, details of any single analytical step, and/or transition conditions, using free-text comments. Use of these annotation fields is important in the initial version of the scenario. This version usually is not executable since only the flowchart layer is specified by the requestor. The analyst uses the annotations to insert the proper RGEAs into the nodes, define any necessary variables, and translate verbally specified transition conditions into computable syntax. The requestor can easily review these added code-layer attributes; moreover, after some basic scenario authoring training, an advanced requestor can author these attributes himself. The workflow editor also has a built-in validation feature which can check the consistency of the scenario definition (e.g., unconnected flowchart nodes or other missing, required, definition elements). The annotation fields also can be used to document any changes made to the code layer of a particular flowchart node or arrow.

The above account describes tasks primarily meant for the requestor. The following sections describe the use of RGEAs, variables, and conditions, meant primarily for the analyst or the advanced-requestor during scenario development.

1.1.1.1 Use of external applications

Section 3.1 gave a basic account of RG external applications, and specified a few categories of simple RGEAs (data-get applications, position manipulating applications, and comparison applications). Table 3.4 contains a more complete list of important RGEAs. The table lists two additional categories: (1) RGEAs which support assigning values to scenario variables; and (2) RGEAs related to report generation, which is described later in Section 3.2.4.

The data-get category of RGEAs has yet another important aspect which is related to a

 

——————————————————————–

Table 3.4 List of RGEAs

image

Data-get RGEAs

· Find_coded_event*

· Find_coded_value_under_specific_observation*

· Find_coded_event_with_flag*

· Find_drug_prescription*

· List_next_X_events

· Patient_is_male

· Get_patient_age_at_current_EHR_position

Position manipulating RGEAs

· Jump_to_timestamp

· Jump_to_first_EHR_event

· Jump_to_last_EHR_event

· Jump_to_next_timepoint

· Jump_forward/backward_X_hours_from_curr_position

RGEAs related to variables

· Remember_time_stamp

· Remember_numeric_value

· Assign_value_to_variable

· Increase_counter_variable

Data comparison RGEAs

· Evaluate_two_timestamps_difference_criterion

RGEAs related to report generation

· PtList_Harvester

· Write_DR_Top_note

· Collect_statistical_data_item

Applications marked with * also have corresponding “ReverseFind_” and “_group” variants. “Reverse_find_” variant will perform a search backwards in time, and “_group” variant enables specification of a set of codes (using simple enumeration) to be searched as opposed to only a single code search.

—————–

 

 

 

 

separate data-get conceptual scenario layer (as defined in section 2.3.1 and listed in Table 2.11). The RG framework can accommodate structural changes to the underlying EDW structure (or other EHR data source) by adjusting appropriately the data-get RGEAs (rewriting them to reflect the EDW structural change). Thus, by changing the appropriate RGEAs, an older scenario can still be executed against a structurally changed EDW [18].

RGEAs can have input and output parameters. Parameters offer a way of passing information, and are closely connected to variables, which were briefly described in section 3.1. Parameters are directly supported by workflow technology. The utilized XPDL standard defines three types of parameters: IN, OUT, and INOUT. IN parameters are read-only, input parameters, and they offer a way of passing data to an external application. OUT parameters are write-only, output parameters, and they can pass information from an external application back to the execution engine. INOUT parameters have properties of both and are the most flexible.

There are two additional conventions which apply to the current set of RGEAs. First, most RGEAs have an output parameter called ParsingResult which stores the succeed/fail type of the overall result of the application execution. Second, each RGEA which needs to know or can modify the current EHR position implements an appropriate INOUT parameter for this purpose.

A detailed description of RGEAs, including their parameters, can be found in Appendix A. The current set of RGEAs represents a significant end-product of this research project. The initial set was extended multiple times as additional RG case studies were implemented, and it offers an interesting break-down of possible, atomic, analytical tasks which can be used as an inspiration for other researchers.

1.1.1.2 Use of variables

There are two categories of variables: System variables, which are present in each scenario by default, and user-defined variables, which serve a specific analytical purpose within a given analysis.

System variables have a “S_” prefix. Currently, there are two system variables. The first is the S_ParsingResult variable, which stores the success/failure result of the last executed RGEA for which such output is defined. It is implemented as an integer variable. A zero value designates a false/failure outcome, whereas a nonzero value conveys a true/success outcome. In the data-get RGEA, the sign and the absolute value of the parsing result designates the EHR position where the desired event was found. S_ParsingResult is heavily used in transition conditions. The second system variable, S_CurrPosition, is the technical implementation of the current EHR position pointer described in section 3.1.

User-defined variables can be used for many different purposes. The introductory section mentioned the three most common purposes for variables (remembering a timestamp, numeric, or count value) and RG’s suggested variable naming conventions. User-defined variables are declared in a special workflow process properties screen within a workflow editor, where the user specifies the variable name, variable type (e.g., string, number, or Boolean value), and desired initial value. Three examples of variable use from the case studies (presented in Chapter 4) are described below.

In the first example, the analysis of the results from a computerized glucose management protocol uses a user-defined, temporal variable to store the time of enrollment into the protocol. This timestamp value is important for many later steps within this analysis. The scenario declares an integer type variable, t010_glc_prot_ enrollment, and in the same node that searches for the glucose protocol enrollment code, it also calls the Remember_timestamp_as_position RGEA with t010_glc_prot_ enrollment as a parameter.

In fact, in order to remember a certain event, two general approaches can be taken. The scenario can work with the position of the event in the ordered list of events (position in EHR), or it can use the actual timestamp of that event. For the event position, an integer variable type would be used, similar to the implementation of the concept of current EHR position. The second strategy, absolute timestamp, would use a string or a date-time variable type. Both approaches are possible and each approach has implications for the RGEAs which operate with the remembered temporal events. For example, the event position approach offers easy implementation of temporal jumps to particular positions (even if several events share the same timestamp, which is often the case in a single, structured EHR form). On the other hand, if concurrency is important and all events from a particular time point must be parsed, the position approach mandates the existence and the use of RGEAs such as Jump_to_ Previous/Next_TimeStamp(). Most RGEAs are currently implemented to expect the position-type integer value and have the ability, if necessary, to retrieve the actual timestamp of a given event at a certain EHR position.

A second example of user-defined variable comes from the osteoporosis case study. A variable, v_099_age_at_first_fracture, is used to remember the age of the patient at the time of her first fracture, which is later used to test for certain desired values and scenario branching. The patient age would be obtained by first using the application Find_ICD_Dg_group (‘fractures.csv’) to find the position in the EHR where the first fracture occurred, and then, if found, calling another application, Get_Pt_Age_at_Current_Position(v099_age_at_first_fracture), to store the calculated patient age at the current position in the variable.

The third example of a user-defined variable is a Boolean variable which also can be found in the osteoporosis analysis. Boolean variables can be used to remember the result of a subanalysis performed earlier in the scenario for later use. The osteoporosis analysis evaluates multiple criteria for the OMW1 quality improvement “yes/no” outcome measure. A Boolean variable, b01_OMW1_compliant, is used to remember patient compliance status (true or false). Later steps in the analysis investigate noncompliant patients in some greater detail. The variable enables reuse of the result without reproducing the elaborate OMW1 criteria, and even combining the result with additional conditions. For example, the transition condition “b01_OMW1_compliant=0 AND t_second_fracture>0” will capture patients who were noncompliant and experienced a second fracture later. In fact, some built-in features in the timestamp remembering RGEA applications (see appendix A for details) enable using timestamp variables in a “Boolean” fashion as well, as demonstrated by this condition example.

1.1.1.3 Use of conditions

Transition conditions represent another mechanism which extends the flowchart representation paradigm. Section 3.1 mentioned their use to direct the flow of logic and especially their use to implement branching scenario logic. Although they are a more complex mechanism, conditions are usually quickly understood, and an advanced requestor can easily author the conditions himself. A novice requestor can use a flowchart arrow’s annotation fields in the same way as was described previously for nodes and free-text descriptions of RG external applications. In this case, the analyst must translate these annotations into computable condition expressions.

Although the concept of a transition condition is well defined in workflow technology, the XPDL language does not define any specific syntax for its formulation and leaves the syntax and the interpretation to the workflow engine. The Enhydra Shark [19] workflow engine uses JavaScript syntax to formulate and parse conditions. Any variables can be used in condition expressions together with the basic Boolean (AND, OR, XOR) and numeric (>, <, ≥, ≤, =) operators. An example of a transition condition and the annotation within the JaWE workflow editor is shown in Figure 3.1.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: