For guideline implementation, support for both declarative and procedural approaches is necessary. Guideline frameworks such as PROforma , GLIF  and Asbru  use a declarative approach (which may or may not use XML syntax) for higher-level specification, while employing an expression language (e.g., GELLO  for GLIF) for low-level procedural tasks. The specification may be executed by a runtime interpreter or (in the case of PROforma) compiled to code in a general-purpose language (e.g., Prolog) that is then executed by an off-the-shelf interpreter.
One area that we believe has remained under-emphasized in frameworks is the ability to support real-life complexity. Complexity and the solutions that can address it have several related dimensions some of which we address in this section.
This refers to capabilities within a language that support the development of a large body of code as separate units, possibly by developers working semi-independently, with features such as namespaces (which allow different developers to define variables and functions with possibly identical names without having to worry about name-collisions, and information hiding , where a caller of a routine does not need to know any more than what is passed in and what is returned-allowing the internals of the latter to be modified if needed without any impact on the calling code. Developers using modern programming language take such capabilities for granted, but it is worth remembering that the current official Arden Syntax standard still lacks basic subroutine capability, a feature that FORTRAN has possessed since 1956. This may explain the reluctance of most EMR vendors to support it: it offers few advantages over their proprietary technology. Modularity is supported by CGSs to varying degrees in some frameworks. For example, GLIF and GLARE  are intended to support modularity through a distributed architecture while HeCaSe2 supports a distributed architecture of quasi-independent, intercommunicating "agents" or processes.
Support of design patterns
Design Patterns  are higher-level abstractions that embody algorithmic solutions. An example (implemented in Proteus) is an "at least N" compound-Boolean filter, which yields a result of True if at least N of its input parameters are true: such filters are used in the Jones Criteria for rheumatic fever and for diagnosis of Ventilator Associated Pneumonia (VAP). Peleg and Tu  have described the application of design patterns for transformation of clinical guidelines from narrative to executable form.
Code base reuse
Reuse of code goes beyond the ability to reuse code written in the language of the CGS itself. One must be able to reuse pre-existing compiled, operational code libraries, even those created elsewhere, without having to rewrite the logic in the guideline/expression language. (With proprietary, compiled code, rewriting may not even be feasible.) For example, vendors provide code that accesses drug databases for drug/drug or drug/laboratory interactions; a variety of dosing algorithms determine drug dosage by adjusting for physiological and pathological states (e.g., age, impaired renal or liver function).
This implies ability to implement modules using the tool/language most appropriate to the task- this could include not just traditional programming languages, but statistical or mathematical packages, and use them as black-box modules within the larger framework of a guideline.
While certain CGSs, e.g., SpEM , rely on production rules , alternative approaches exist that may be more appropriate on occasion. These include neural networks , decision trees , statistical approaches including Bayesian reasoning ), and temporal reasoning and representation of temporal uncertainty . Further, these may be employed in the form of commercial black-box libraries or compiled open-source packages.
Many of the above issues are discussed more briefly by Peleg et al. . Issues 2-4 above come under the rubric of extensibility. Today's mainstream programming environments provide extensibility in straightforward ways: in the case of Java, for example, through the Java Native Interface (JNI) . On platforms such as Windows, many libraries are bundled with COM (Common Object Model) or .NET wrappers whose contents (which include skeletal documentation and function parameters) can be browsed within coding environments.
Two challenges, though seemingly unrelated, could be resolved by allowing a guideline to take parameters, in a fashion similar to subroutines in program code.
Adapting guidelines to local practices or patient circumstances
If the modality only allows representing guidelines with all of their details pre-specified, the likelihood of their being used at other locations diminishes. Therefore, some CGSs, e.g., Asbru, support the notion of Goal or Intention for activities . An example would an activity with the goal "administration of ACE inhibitor to lower blood pressure by at least 10 mmHg", while leaving the medication regime details (ACE agent, dose) to the clinician.
Representing non-evidence-based states within guidelines
Sutton et al., in an evaluation of PROforma  also advocate the ability to "conceal inessential details" by allowing variation within a guideline (e.g., an observation period of N weeks, where N, a parameter, is a number that can be institution/user-specified. (PROforma currently lacks such a capability.) Such flexibility is required because of absence of conclusive evidence in literature, so that certain decisions are best left to clinician-users.
Many general-purpose programs (notably tax-computation software) support parameterized customization through mechanisms such as templates or wizards, and future CGSs should support parameterization of parts of guidelines similarly. Batet et al.  describe a CGS for home care services that supports both modularization (using a distributed architecture) and parameterization with respect to individual intervention plans.
Complex coordination: relation with business workflow systems
The high-level-design operations provided in guideline languages closely resemble those in "workflow languages", which are intended to address complex coordination. A workflow is a machine-interpretable model of a "progression of steps (tasks, events, interactions) that comprise a work process, involve one or more persons, and create or add value to the organization's activities."  Mulyar et al.  have in fact evaluated guideline languages in depth with respect to their support of a variety of workflow coordination patterns, which were originally characterized by van der Aalst et al. .
A workflow is an extension of a flowchart, with nodes representing activities (tasks) or decision points and the edges represent flow of control (e.g., branching, looping) or sequencing of activities. The extension comes from the ability to specify that certain operations may execute in parallel, or that certain activities (or a certain number of activities) must complete before a decision point can be evaluated, in addition to operations, e.g., suspend, delay or terminate an operation, etc. (Individual packages may also support specific operations such as sending e-mail, writing data, etc.) The graphical nature of workflows makes them a natural fit for a visual-programming metaphor, though a machine-friendly counterpart (typically based on an XML dialect) also exists.
Business workflow frameworks are fairly mature and widely used products. Standards such as the XML-based Business Process Execution Language for Web Services (WS-BPEL)  and Business Process Markup Notation (BPMN)  are supported by vendors such as Oracle, HP and IBM, and tend to be programmer-oriented. Microsoft Office 2010 SharePoint Server , enterprise integration software such as Microsoft BizTalk and Enterprise Resource Planning (ERP) systems such as SAP  include proprietary workflow languages with workflows intended to be authored primarily by non-programmer domain experts (e.g., business analysts). Microsoft provides native workflow support within the Windows operating system through Windows Workflow Foundation : WWF workflows can be authored in Visual Studio.
The study of business-workflow technology provides important lessons for CGS implementers because it deals efficiently with many issues that CGS implementers, have yet to address systematically. Below, we summarize these issues: the parallels to patient-care workflow are obvious.
Extensibility allows developers to add to the capabilities of the base software through custom code written in one's programming language of choice. Workflows are generally executed in interpreted mode by a runtime workflow-execution engine. However, they provide an Application Programming Interface (API) that allows developers to implement custom tasks (with well-defined inputs and outputs) using traditional languages. The compiled code is added to the authoring environment's toolbox, to be reused in any workflow. There are very few limits on what custom tasks may do: Vadaparty  describes a custom-task set for WWF created at Merrill Lynch that invokes multiprocessor parallel hardware over a network to execute complex finance-related tasks in a manner transparent to the non-programmer workflow author.
Integration refers to the ability of the system to inter-operate with external software packages. These systems allow communication with external systems by a variety of methods, including ODBC and Web services (which may run on multiple hardware platforms). CGSs need to inter-operate with Electronic Health Record (EHR) and Computerized Provider Order Entry systems in order to access (and optionally modify) patient-related data.
This refers to the ability of the system to execute a large number of instances (workflows, guidelines) concurrently without noticeable performance degradation. Business workflow engines routinely execute thousands of diverse workflows that are critical to business operations, and can invoke parallel hardware.
The systems are capable of recovery from hardware- or network-related error conditions. Design of Web-service-based workflow can allow for resource unavailability, and synchronization/communications failures.
Persistence of Data is the ability to create and retrieve data that outlives the software process that created it (i.e., when the hardware is shut down for maintenance). Workflow software uses DBMS technology to persist workflow state: CGSs may also use their own data stores (e.g., to store electronic guidelines), but should ideally store patient-related data in an EHR where possible.
The workflow systems allow devising algorithms that rely on human input in a decision-making capacity. Certain tasks involve human actions (e.g., loan approval sign-off by one or more geographically distributed persons). Certain steps may allow for human override in case of unforeseen circumstances, sometimes through a consultative process. This capability is particularly important in medicine: numerous papers, e.g., Hurwitz , have highlighted the reluctance among clinicians to use clinical guidelines because of the fear that they will not be in charge.
The ability to maintain an electronic audit trail includes logging of context and human actions takes place at all decision points, especially human overrides, much as alert overrides in Computerized Physician Order Entry (CPOE) systems are logged.
Productive development environment
Mature authoring, validation and testing tools are integral to sound workflow systems. The more complex a workflow, the more likely are errors of consistency (e.g., circular or conflicting logic) to be introduced in its design. Many commercial and open-source tools, notably for WS-BPEL, support inconsistency diagnosis through static analysis and logical-error taxonomies , validation (e.g., ActiveVOS  and testing (e.g., Oracle BPEL Test Framework ).
While Greenes  notes the complexity of workflow management, Fox et al.  emphasize that workflow-management, decision-making and care-planning (all of which are involved in complex guidelines) are aspects of clinical work that clearly benefit from computer support. Fox et al. in fact point out that BPMN is a good fit for defining plans formally.
Finally, there is nothing intrinsically unique to the "business" domain about many business-workflow engines: WS-BPEL and BPMN are in fact general-purpose, and their use for clinical applications deserves serious exploration. One way to do this is for CGSs to "compile" guideline definitions into a general-purpose workflow language, with medicine-specific functionality being implemented as calls to custom tasks. This would allow the numerous vendor/third-party tools to be leveraged without needing to re-invent the numerous wheels necessary to make CGSs production-grade. It might also simplify integration with administrative systems, many of which utilize BPEL (or are BPEL-ready): The current version of BPMN (version 2) is also accumulating open-source support (e.g., Activiti  and jBPM ,
CGSs need to operate in one of two modes:
1. Simulated (testing) mode. Most CGSs support some form of testing, in the form of tracing through the guideline's different paths. Certain clinical consultation systems (e.g., QMR ) implement this capability comprehensively, to serve as a teaching aid.
2. Online Mode. Here the guideline operates with actual patients, either interactively in a dialog with the user, in batch on a set (or population) of patients, or unobtrusively as an event-driven agent activates on a particular pattern of inputs. (Alerting mechanisms in CPOEs operate in the last fashion: as stated earlier, HeCaSe2 has an agent-based architecture.)
During interactive mode, the ability to provide explanation of actions is important, as suggested by Tolchinsky et al.  and Fox et al. , with the text of explanations customized to the user role. More advanced capabilities would include the ability of the inferencing mechanism to learn (through machine-learning algorithms) from the inferences and decisions that the clinicians make in different situations.
Support for multiple guideline versions
Unlike most decision-support systems, a patient going through a guideline workflow may stay within that workflow for long periods. For example, a workflow related to management of infertility could last more than a year, because pregnancy takes time to establish. The clinical aspects of the workflow may no longer apply (e.g., because of the availability of a new and better treatment, recommendations may have changed), and so a new clinical sub-workflow may supersede the old one.
However, workflows also have administrative aspects (inventory adjustment, service itemization, reimbursement from the insurer/payer), whose management can be more complex: for different patients, multiple versions of the same administrative sub-workflow may run simultaneously. For example, even if a reimbursement agreement has changed since the patient has begun treatment, the contract with the payer may require the old agreement to stay in force.
Therefore, depending on the nature of the guideline/workflow, the execution engine may need to enforce one of two strategies:
Replace the old version with the current version for all instances/patients (This is technically challenging because many patients are in the middle of a flow, and there must be rules that specify what is to be done if, for example, a patient is in a guideline branch that is now obsolete.)
Allow multiple versions of the same broad workflow to coexist and run at the same time, the choice of version depending on the patient.
The knowledge representation employed by advanced business-workflow engines supports hierarchical versioning, with an individual version represented as a "child" of a base version, and differences between the base and child modeled as atomic change units analogous to the "deltas" used in software version control , along with the metadata at the base level that specifies which of the above strategies is to be followed if changes occur. Every active instance is associated with its current version, and its current position/branch within the version, and the path taken to get to this position. The runtime execution engine will implement the desired strategy for a given instance if changes occur to the guideline. While most engines use proprietary approaches, there are attempts, e.g., Juric et al. , to apply such techniques to standard representation languages such as WS-BPEL.
Isern and Moreno point out that most CGSs incorporate visual (graphical) editors for guideline authoring. However, these editors are not available freely, as open-source or otherwise, making their usability and robustness difficult to evaluate. User interfaces that are optimal for novices may be less productive for advanced users, who might prefer rapid typing to manipulating graphical icons , so usable interfaces could allow switching between text and graphical mode, with round-trip engineering : modification of code leads to changes in the graphic, and vice versa.
In text mode, high-productivity Integrated Development Environments (IDEs) such as Eclipse™ and Microsoft Visual Studio™ offer aids such as auto-completion, auto-indent, outlining with collapsing/expansion of code segments, color-based syntax highlighting macros to improve typing productivity, and browsing of class/code libraries. Given that these tools have a large user base, and that they are highly customizable by developers (e.g., by incorporation of plug-ins), CGS developers would be well advised to leverage such tools as the basis for authoring environments.
Adequate documentation to teach and promote best practices for guideline authoring and maintenance are also desirable.
The Isern and Moreno review suggests the possibility of supporting Web-based editing and collaborative authoring by diverse subject-matter experts: CGSs currently lack these features. While software that supports Web conferencing (e.g., Citrix GotoMeeting , Mikogo  is widely used, collaborative authoring that supports an orderly change process with conflict resolution and change trail maintenance is challenging to implement well; early versions of Google Wave , for example, suffered from poor user acceptance.
Another practical problem is that many IDE productivity features for both textual and graphical editing are difficult to achieve in the presence of a network communication delay. In the more than seven years of their existence, both the Eclipse and Visual Studio IDEs have remained desktop-based. (Google Docs, which supports collaborative editing of the same document, has 30-second refresh latency before another person's edits can be seen.) One approach is to augment Web-based editing with instant messaging and voice chat, e.g., Ajax.org's Cloud9 project , and to permit only one writer per file (e.g., Borland CodeWright), thereby minimizing the risk of conflicting edits.
One aspect of collaborative authoring is achievement of consensus. Deshpande et al.  have described Web support of Delphi rating, a well-known consensus-development methodology, which was deployed prior to the Conference for Guidelines Standardization.
Sutton et al., in their evaluation of PROforma , emphasized the future need for structure preservation: the models used in knowledge acquisition should be identical or highly similar to those used for design and implementation. This is similar to requirements traceability , a software-engineering process to ensure that a software product's implemented features remain synchronized with previously defined requirements.
Integration with existing systems: use of standards
The need for CGSs to communicate bi-directionally (i.e., read/write) with EMR and administrative systems well established. Several lessons have been learned regarding integration for Decision Support Systems (DSS) deployment in clinical and business contexts (e.g., Enterprise Resource Planning (ERP).
Incomplete integration is worse than no integration at all: by increasing the user's cognitive burden as to which steps are electronic and which remain manual, perceived workload is increased rather than reduced.
DSS is successful to the extent that it is non-obtrusive and reduces caregiver workload, so that the default action is the desired one, and takes little or no human effort to perform. Miller et al.  point out in the context of consultation systems that the failure to embed them as integral components of normal clinician workflow impaired their acceptability. Effective embedding relies on adequate integration.
Thus, a system smart enough to recognize what tasks need execution should be smart enough to perform those tasks if possible, relying on users only for confirmation/override; e.g., a useful reminder system goes beyond telling the physician to schedule a vaccination or order a glycated hemoglobin, and volunteers to schedule or order it, unless the physician says no, through communication with the scheduling system.
A practical problem is that, because integration standards are immature (HL7 vMR or virtual Medical Record ), not widely accepted by all vendors (HL7 v3) or non-existent (links to administrative systems), CGS implementers must work with proprietary vendor APIs, and extensive mapping of guideline elements to elements in the local electronic systems must be performed manually, as described by Peleg et al.  and Isern et al. : the latter used the ontology editor Protégé  for mapping. Both efforts utilize standard biomedical vocabularies (UMLS in the latter case.) The SEBASTIAN decision-support framework of Kawamoto and Lobach  uses Web services to partially insulate the guideline framework from the specifics of individual APIs . Ongenae et al.  describe a system that utilizes a rule-based engine (built with Drools ) combined with standard medical controlled vocabularies and representation languages.
Knowledge life cycle management (KLCM)
In the context of decision support, a knowledge artifact is a discrete entity created by author(s) that contributes toward behavior changes in the software based on its knowledge. The artifacts may evolve from a hazy concept, expressed in plain text, to an actionable form, and finally into something that can be encoded into the software application to realize its purpose, moving progressively from one state to another. The knowledge artifacts and their associated metadata are the main constituents of knowledge repositories. KLCM is the ability to maintain knowledge artifacts current and accurate from inception to retirement.
In the clinical guideline area, several papers have dealt with different aspects of KLCM, such as creation and evaluation (Cecamore et al. ), content refinement (Haynes and Wilczynski ), analysis of barriers to implementation (Goud et al. ), sharing (Paterno et al. ), and repository design (the Morningside initiative ).
Agile methods are a group of software engineering approaches which emphasize short iterations (2-6 weeks) of development with simultaneous ongoing automated and user-testing so that the software's evolution remains closely aligned to the user expectations . The agile methodologies potentially bear on KLCM, because a guideline can be verified and tested even as it is being fleshed out, allowing rapid iterations of refinement.
We have addressed some of the sub-requirements of guideline repositories in the Introduction: security and management of user privileges, version control and audit trail of changes, and searchable content (possibly assisted by controlled vocabularies). High-end version-control systems possess all of the above capabilities built in (including text-word search, but not vocabulary-assisted search). However, many commercial systems (e.g., Visual Studio Team Foundation Server) and open-source systems (Apache Subversion) have programmable APIs that can be utilized to provide extensibility: several third-party authoring environments (e.g., Adobe RoboHelp , a tool for creation of online documentation) "plug in" into these systems.
It is possible that repository indexing of the searchable content may be augmented by user-specified terms. The system should also allow leveraging the user community as a resource for feedback about quality and errors: most version systems are closely coupled with feature/defect tracking subsystems (e.g., Bugzilla  for open-source projects).