Biomedical scientist, knowledge architect, software engineer
With respect to the past research in this area, mainly focused on representing the tasks involved in a CPG, but poorly addressing the more general and practical issue of the CPGs implementation, our focus in the Guide project shifted towards a different conceptual and architectural paradigm based on two major patterns coming form the software engineering literature: Separation of Concerns (SoC) [5.1]. SoC is the core of software engineering, in general, and of object-oriented software development in particular.
The Separation of Concerns paradigm refers to the ability to identify, encapsulate, and manipulate only those parts of software that are relevant to a particular concept, goal, or purpose.
Concerns are the primary motivation for organizing and decomposing software into manageable and comprehensible parts. But SoC is not only a software engineering paradigm, it is a general approach that can be applied to human resources [5.2] indicating that each individual exhibits different concerns that are normally associated with his/her skills, attitude or past experience: “not everybody is equal, not everybody performs the same job with the same ability”. Moreover, it has been observed in working environment that separating people with common skills in different working groups increases productivity and reduces management costs, but only if the groups do not overlap and have clear "contracts" that define their operability and their concerns. In the heathcare domain the knowledge creation/conversion process, aiming at developing a knowledge-based information system, is carried out by three kinds of actors:
medical expert: he manages all medical aspects related to healthcare activities. Usually medical experts are physicians trained in formalizing medical knowledge through a given method (for the Guide method see next chapter);
organizational expert: he manages organizational aspects related to the health care activities. Usually organizational experts are people trained to formalize workflow processes in an health care organization, maps of resources, organization charts and so on;
knowledge formalization expert: he represents the link between experts and the various representation formalisms. Knowledge formalization experts are usually knowledge engineers trained to define knowledge and process models at different levels of abstractions. They normally define meta-models that will be instantiated by medical and organizational experts.
The SoC paradigm allows minimizing the common ground needed in order to make the three actors communicating, hiding specific details as much as possible. In fact, poor communication is mainly a knowledge gap problem. The proposed approach allows actors to concentrate on their specific domain without taking care about details of other domains which are not part of their know-how and everyday effort.
The above described approach refers to the knowledge formalization process that leads to medical and organizational “behavioral models” (process models) and common grounding knowledge models in general. To put in practice such models there is the need of considering the patient’s issue. In fact, while formalization is usually based on ideal cases and processes, during the execution the system must be able to face real patients and resource instances.
Figure 1 - The high level view of the Guide project platform. Three independent concerns are depicted: Guideline Management System, Workflow Management System and Health Care Record Management System. The three concerns are able to communicate each others through the common ground, depicted in the middle, which is composed by a set of data types and terminologies/ontologies and a set of contracts describing the allowed types and structure of communication content.
Figure 1 represents a possible high level view of the project structure. The Health Care Record Management System (HCRMS) or simply the Electronic Patient Record (EPR) is depicted as one of the main components together with the Guideline Management System (GLMS) and with the Workflow Management System (WfMS). GLMS deals with the representation and execution (in term of evidence-based medical decision support) of medical knowledge, while WfMS deals with the representation and execution (in term of work/resources allocation) of organizational knowledge. Ontologies and terminologies together with data types are wrapped by contracts and represent the common ground, fundamental for communication between the different concerns (EPR, GL, Wf). In fact, communication is message-based according to specific contracts. Each concern has the same level of importance and has its own representation models and languages. Moreover, the strong separation between medical and organizational issues allows improving not only the software product (reducing crosstalk and powering parallelization) but also the quality of interaction between the system and the domain experts, who usually have different skills and background. In the following paragraph, after an introduction about the global architecture and contracts that have been implemented for the project together with the GLMS architecture, we illustrate how a CPG can be formalized into models and used in real-world settings. In most cases, the EPR and the WfMS are developed and implemented by third parties, before planning the integration with a medical decision support system.
The Guide Project (TGP) is a distributed environment aiming at the complete management of computerized CPGs life cycle with respect to patient’s and healthcare professionals’ issues. In fact, it is, a knowledge management system allowing formalization of medical, organizational and health care record models (information, processes and knowledge) which will be adapted, combined and distributed in order to implement a full process-based Health Knowledge System (figure 2). In fact, TGP main goal is to support the daily process-oriented examination, diagnosis, treatment, and care of the patient, meanwhile taking care of organizational processes (resources management).
Figure 2 - The process of models definition, adaptation, dissemination and enactment has the same structure for each concern. Each step consists in a well defined knowledge transformation.
For each of the specified concerns we can define a complete process which will take from knowledge models conceptualization/formalization, through adaptation and dissemination, to enactment. It is basically an application of the three fundamentals processes of the knowledge management (see paragraph 1.2). The behavior is similar to the water-fall model, each level transmits knowledge in different forms (formal/semiformal models and documentation) to the subsequent one after an optional transformation process. In the first step, i.e. the formalization, the knowledge is transformed from implicit/tacit to explicit and more important computerizable models. During the second step, i.e. dissemination, explicit knowledge models are adapted and refined according to a more specific setting. Finally in the third phase, i.e. enactment, knowledge models are transformed into interaction between users and systems, users and users and systems and systems.
Figure 3 - The Guide project knowledge models water-fall. Each step consist in a specific knowledge transformation.
The knowledge flow is mainly one-way but it is possible to obtain model adaptation feedback from the dissemination level to the formalization one.
Figure 4 - The Guide project knowledge models water-fall with a feed-back between the dissemination level and the formalization level. This is a powerful model for fostering knowledge models evaluation.
Such feedback is a powerful method for:
Let me explain the three different levels in detail:
The above specified levels, represented in Guide by macro-components, can be organized in a potentially infinite number of configurations aiming at the complete management of the computerized CPGs life cycle. Figure 5 shows a complex example in which formal/semi-formal models are defined by different organizations and are disseminated at a national level (Italian level in this case). To be trusty, these models should be certified by an health authority or scientific organization. Each Italian Region can access the models and the documentation in order to perform new adaptations and then to distribute the modified resources to the HCOs. At the local level, healthcare organizations (HCOs) may decide to adopt one of such CPGs. Site specifications may be performed by individual HCOs before putting CPGs at work in the clinical practice through the enactment level.
Figure 5 - A possible configuration of the three Guide macro-components. This has been defined to deal with the Italian national health service.
Figure 6 - Guide formalization level architecture. Through the NewGuide editor and other tools, it is possible to formalize clinical practice guidelines models, their properties, and refer to existing ontologies and terminologies. The knowledge base is shared though services.
Computerized CPGs lifecycle starts with the formalization of the CPGs. Such step, in the Guide platform, is performed through the NewGuide graphical editor application, through which the CPG is represented as a set of decision flow-charts that refer to conceptual entities typically embodied in medical terms from vocabularies and ontologies. or entries of knowledge bases. These terminologies are usually defined outside the NewGuide editor through external specialized applications:
![]() |
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. The content in this page is derived from Paolo Ciccarese's PhD Thesis work (2006). |