I. Create Executable Rules
The output from the Knowledge Formalization activities is a series of structured recommendations for implementation in a computerized decision support (CDS) system. Although this output specifies much of the structured logic necessary for the CDS design, it is still necessary to refine this specification to deal with the challenges of implementation in the local environment and with the specific technical and system development challenges of EHR system.
GLIDES’ experience was that each implementation organization will pursue somewhat different systems development conventions and frameworks for its EHR system: some use formal rules engines, some prefer to use only particular features of the EHR, some prefer their developers to work from highly specified pseudo-code, etc. Therefore, each organization needed to tailor the final logic specification so that it could be implemented in their particular EHR programming environment.
Creating a Local Logic Specification
Often referred to as the curly braces issue, there is a “zone of localization” in which central specification and knowledge structuring must interact with local standards and workflow without undermining the intent of the guideline authors. To help ensure that the local site design remains consistent with the goals and intention of the guideline formalization work, it is helpful to create a crosswalk table to specify the recommendations, decision variables, actions/directives, data source, and with what actions in the care process each decision would be answered.
This also enables implementers to begin to integrate the GEM output with the design conventions required for their existing EHR systems development processes. It also provides an overall framework for the intervention design process, including exceptions to be applied locally.
Details of the cross-walk process will vary depending on the details and complexity of the guideline to be implemented, as well as the specifics of the local environment (use of rules engines, existing application structure, programming and testing conventions, EHR standards, etc). Consequently, the cross-walk process and supporting tables for documentation should be reviewed and amended for each specific CDS project.
At CHOP, once the detailed data definitions from guideline translation process were defined and validated the rules engine was programmed. Learn more on page 25 of this document.
Deeper Dive
- Overview of typical changes required to implement Asthma CDS across two separate organizations/locations (Yale and Alliance of Chicago)
- Geisinger Localization Process