|Home | About | Journals | Submit | Contact Us | Français|
The detection and prevention of Risks Against Patient Safety (RAPS) are ever-increasing issues in health care. One aspect of the many measures taken against RAPS is the comparison of the actual care practice against descriptions of best practice given in clinical guidelines and protocols (CGPs). In order to perform such comparisons automatically, CGPs need to be modelled in a computer-executable form. In addition, the execution of the CGP model must be integrated with the care process at the site of application, and with risk-assessment tools used by the hospital’s risk manager to explore what-if scenarios. In this paper, we describe the modelling and execution of CGPs in Asbru within the EU project Remine, which develops a high-performance platform for the prediction, detection and monitoring of RAPS.
Risks Against Patient Safety (RAPS) are a serious issue in today’s health care. Besides causing avoidable and sometimes serious disadvantages on the side of the patient, damage claims for assumed or actual errors in treatment are an important financial factor in today’s health sector.
Standardising treatment in Clinical Guidelines and Protocols (CGPs) is seen as an important means to improve health care. If properly applied, CGPs lead to improved quality of care while controlling cost . When translated into a computer-executable form, they can be integrated within an existing patient data management system (PDMS), which improves the degree of adherence in daily practice .
In this paper we describe a method to model computer-executable CGPs (Section 3) after discussing related work (Section 2). Section 4 concludes with advantages and limitations of CGP modelling and execution within the realm of RAPS.
Several projects deal with the prediction, detection, and monitoring of RAPS. The ALERT project2 analyses data from electronic healthcare records (EHRs) through text mining and epidemiological computing and detect ‘signals’, such as combinations of drugs and suspected adverse drug reactions (ADRs) that require further investigation. The PSIP project 3 analyses the data of patients with an abnormal stay or new admissions on the presence of ADRs as explanation for these abnormal events. The care flow of these patients is analysed, documenting the reason why such an adverse event occurred. The DEBUG IT project4 intends to combine information obtained by data mining with knowledge sources including guidelines. In contrast, the ReMINE project5 focuses on modelling protocols in their original form. Splitting the process of creating protocols from clinical evidence and past practice from the process of transforming the protocols into computer-executable form increases the manageability of each of the two complex tasks.
In order to integrate CGPs into the clinical workflow and with EHRs, several guideline representation languages (e.g., Asbru, EON, GLIF, PROforma, GEM; see [2, 3] for overviews and comparisons) have been developed. Asbru [4, 5] faired favorably in these comparisons. It is used for the work described in this paper.
For formalizing CPGs into languages like Asbru, several tools exist. The Document Exploration and Linking Tool / Addons (DELT/A) supports the translation of HTML documents into any XML language .
In order to break the complexity of the modelling process into manageable tasks, we developed an intermediate representation called Many-Headed Bridge between Guideline Representations (MHB) . In contrast to other approaches, it maintains concise references between small parts of knowledge in the original guideline, in MHB, and in the Asbru model to be created from the MHB model.
The creation of a formal model of a CGP in Asbru or a similar representation poses a major challenge to the team performing this task. Both medical and computer science expertise is required. The reason for this only lies in part in the fact that modelling complex knowledge with formal precision is a generally hard task. Much heavier weighs the fact that all protocols, even those perceived as very concise by physicians, contain enormous amounts of background knowledge and assumptions about their applications which are uncovered in the modelling process.
At the same time, this costly analysis process, which is inevitably coupled to the modelling proper, creates many insights into potential problems in the original CGP. Not all of them will trigger serious problems in practice, but most form of ambiguity, missing or implied information, multiple ways of interpretation, deviations of documents, which are assumed to communicate the same, etc. are considered to contribute to risks against patient safety.
In order to cope with all these challenges when modelling a CGP in Asbru, we defined specific steps to perform (see Figure 1 for an overview). These steps are now described in detail.
Each MHB model decomposes a CGP into a series of information chunks. Each chunk has aspects grouped into eight different dimensions: control flow, data flow, temporal aspects, evidence base, background information, resources, patient-related aspects, and document structure.
Using the Document Exploration and Linking Tool with Add-ons (DELT/A) , the user marks a piece of text in the original guideline, which is displayed as HTML in the left-hand window in DELT/A, and selects a suitable macro at the bottom of the DELT/A window. Each of the macros represents a simple pattern in MHB, e.g., a particular aspect of a chunk.
When a macro is activated, it combines the selected text in the original guideline with additional user input and predefined parts and inserts the result in the MHB file. This allows the efficient creation of MHB file with little chances to introduce errors such as typos.
Every macro includes DELT/A-links, which connect the newly inserted elements in the MHB file with the corresponding text in the original guideline. Clicking on one of these links in the MHB file will bring up the corresponding text in the left-hand window. Likewise, clicking in the automatically created link in the original text will bring up the corresponding MHB chunk in the right-hand window.
After marking up a CGP, there is a consolidation step to remove inconsistencies and to detect and fill holes in the model. Such “holes” are frequently seen where certain aspects of a domain are considered too trivial to repeat for physicians, but in a formal and automatically executable model, they need to be included.
Using a complementary information extraction tool named OMA, we create a table of used task names, which shows which of them are referred to in some part of the CGP, and which are defined somewhere in the CGP. Clearly, every task which is mentioned somewhere needs to be defined, and every task which is defined somewhere should be referred to (“used”) somewhere in the CGP. The same check is performed for data entities.
By clarifying issues at this early stage of the modelling, and by acquiring the missing information, we save time in the further modelling process, and – most importantly – the model is still on an abstraction level at which it can be communicated to non-IT experts such as physicians.
After the consolidation, we create an Asbru model from the MHB model. This process resembles the one described above, except for the fact that the MHB model is shown at the left-hand side and the Asbru model is created in the window at the right hand, again using macros and inserting links between the two files.
After creating the Asbru model, we use the OMA tool again to create a merge of original guideline text, MHB model, and Asbru. This is enabled by the links between the three documents. Using this presentation, we can show how each sentence of the CGP contributes to the final model, and what the original foundation of each part of the final model is.
Modelling a CGP in Asbru serves the detection and prevention of potential future risks and the detection and evaluation of deviation from the optimal care in the past on several different levels. The modelling process itself uncovers implicit knowledge, contradictions between different document versions, deviating interpretations, missing links to patient records at the point of application, and other features of the original CGP which are not hard errors themselves but contributing factors to RAPS.
Running the CGP model on artificial test cases, or on selected patient records from the past, allows the risk manager to predict problematic situations before any real person is at risk. If the Execution Engine is integrated into the system used at a place of care, it can suggest the treatment recommended in the modelled CGP. This will lead to improved adherence to the CGP, which in turn will improve the quality of care.
The comparison of the actual clinical interventions with those prescribed in the CGP requires a comprehensive model of the knowledge domain in addition to a high-quality formal model of the CGP. This is the major limiting factor in the application of CGP modelling and execution for RAPS prevention. Future work will thus focus on better integration of domain ontologies with the execution of CGPs.
This work is partially supported by “Fonds zur Förderung der wissenschaftlichen Forschung FWF” (Austrian Science Fund), grant L290-N04. The research leading to these results has received funding from the European Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement n°216134 and the European Commission’s IST program, under contract number IST-FP6-508794.
2Early detection of adverse drug events by integrative mining of clinical records and biomedical knowledge.
3Patient Safety through Intelligent Procedures in Medication; http://www.psip-project.eu/.
4Detecting and Eliminating Bacteria UsinG Information Technology.
5High performances prediction, detection and monitoring platform for patient safety risk management; http://www.remine-project.eu/.