Numerous papers have proposed or described models and clinical guideline systems (CGS) to support computer-executable guidelines. Comprehensive comparative reviews of different CGSs, notably the reviews of Peleg et al. [1
] and de Clerq et al. [2
] and the more current review of Isern and Moreno [3
] have assisted in defining high-level requirements of guideline systems. In addition, Sweidan et al. [4
] deal with evaluation measures associated with clinical software that could be applied to CGSs. However, as the Isern and Moreno review points out, no model appears to have been deployed as production-level software that assists patient management on a daily basis: though one commercial product, Arezzo [5
] is based on the PROforma model [6
], no peer-reviewed publications describing its use in routine healthcare have appeared to date.
Apart from content-related issues such as guideline quality and comprehensiveness, and their acceptance by clinicians, software-engineering challenges include integration with existing electronic medical record systems (EMRs), and non-clinical hospital software (e.g., scheduling, billing, resource utilization and inventory systems).
Translating the undoubted theoretical advantages of computerized guidelines into better patient care will eventually require switching from models and prototypes to robust operational implementations. To be successful, we believe that such efforts can benefit from careful study of existing software technologies and engineering efforts relevant to CGSs. Benefits include the following:
• System requirements become defined at a much more detailed and granular level, leading in turn to more comprehensive technical specifications. (As defined by Weigers [7
], requirements define the "what", while specifications define the "how".) For example, while practically all systems claim to support guideline repositories, production-level sub-requirements include whether and how such repositories support secure access to authorized users, how permissions (read/write vs. read-only, user groups, roles, etc.) are managed, how its content can be searched, and whether it supports version control/audit trail of changes. In existing CGS-related systems, HeCaSe2 [8
] has a security model, and the Vaidurya search engine [9
] supports search (in part by using standard biomedical vocabularies), but we are not aware of a repository that supports all of the above sub-requirements.)
• Additional requirements may emerge that are of no concern in research prototypes. Such chores rarely constitute "publishable research", but their implementation is essential for production-capable systems. For example
- Security infrastructure related to guideline content and execution must be closely integrated with the EMR within which it is embedded (or with which it communicates, if a separate system): the former cannot be inconsistent with the latter with respect to individual permissions.
- Audit trails must record actions taken by clinicians with respect to individual patients and guidelines at various stages of guideline execution. Clinicians may entirely comply with, ignore, or modestly vary from a guideline: in case of adverse patient outcome, the audit trail may determine legal culpability.
- The system must be highly scalable in terms of ability to deal with large numbers of patients in different stages of varied clinical conditions concurrently.
• Study of successes and failures can provide insight as to which approaches may work (both in the short and long-term), and which may be inadvisable.
• Awareness of general-purpose technologies/tools may allow their repurposing for clinical-guideline infrastructure rather than attempting to create tools de novo. Such awareness also helps to determine what tasks or sub-tasks lie within the purview of a guideline framework, and which do not. We refer to such technologies throughout the paper where relevant.
In this paper, we will avoid detailed recapitulation of themes that have been discussed extensively in the guideline literature (e.g., procedural vs. declarative knowledge). If a particular requirement is broadly accepted in the literature, we will simply take it as a given, and cite relevant previous work. We will then focus on sub-requirements that, we believe, have either not been considered in the literature at all (i.e., are novel), or which may have been proposed but whose implications may have not been adequately explored: here, either supporting or (occasional) contrary evidence from existing projects will be presented.