Research Professor, Radiology, University of Leipzig, Germany.
Model Guided Therapy (MGT) is a methodology complementing Image Guided Therapy (IGT) with additional vital patient-specific data. It brings patient treatment closer to achieving more precise diagnosis, more accurate assessment of prognosis, and a more individualised planning, execution and validation of a specific therapy.
MGT in its simplest instantiation is an intervention with a subset, a single or a set of voxels representing locations within the patient’s body. With this view, it is an extension from Image (pixel) Guided Therapy (IGT) to Model (voxel) Guided Therapy.
a) interventions within a subset of a voxel, e.g. cells, organelles, molecules etc.
b) interventions with a voxel, e.g. small
tissue parts of an organ or lesion etc.
c) interventions with a set of voxels, e.g. part of functional structures of organs, organ components, soft tissue, lesions etc.
Considering the needs of therapy specifically, the workflows for diagnosis and therapy need to be linked via the Patient Specific Model (PSM). In addition to demographic data, the PSM comprises the core information data set of the electronic medial record. The building of this data set, i.e. the PSM, commences in the diagnostic workflow, making use for example of computer aided diagnosis and associated technologies. Subsequently, it proceeds in all phases of the therapeutic workflow including after care.
By default, the broader the spectrum of different types of interventional/surgical workflows which have to be considered, the more effort has to go in designing appropriate PSMs and associated services. The following list contains some examples of modelling tools and aspects, derived from different types of surgical workflows, which may have to be considered:
• Geometric modelling including volume and surface representations
• Properties of cells and tissue
• Segmentation and reconstruction
• Biomechanics and damage
• Tissue growth
• Tissue shift
• Prosthesis modelling
• Fabrication model for custom prosthesis
• Properties of biomaterials
• Pharmakokinetics and Pharmakodynamics of normal and pathologic tissue
• Atlas-based anatomic modelling
• Template modelling
• FEM of medical devices and anatomic tissue
• Collision response strategies for constraint deformable objects
• Variety of virtual human models
• Lifelike physiology and anatomy
• Modelling of the biologic continuum
• Animated models
• Multi-scale modelling
• Fusion/integration of data/images
• Coordinate systems between different models including patient, equipment and the OR
• Modelling of workflows
MGT is based on the gathering of all available medical information concerning a patient and, with the use of modern engineering principles and information technology, the construction of a patient-specific medical model. When implemented, a PSM is a multi-level data structure (e.g. matrices, tensors, graphs, lists, tables, fractales and other mathematical artifacts) combining n-D n-dimensional and multi resolutional data of a patient in a coherent, reproducible and adaptable manner. Based on this patient-specific medical model, diagnostic and prognostic determinations and therapeutic decisions can be made, and responses to therapeutic treatments can be monitored and recorded. MGT requires the transition from an image-centric world-view driven by imaging technology to the model-centric world-view driven by the needs of the patient and the medical profession.
Appropriate use of Information and Communication Technology (ICT) and Mechatronic (MT) systems is considered by many experts as a significant contribution to improve workflow and quality of care in the Operating Room (OR). Different imaging modalities and a wide spectrum of other information sources need to be digitally integrated to build a suitable patient model. This will require an IT architecture supporting Surgical Assist System (SAS) which can be adapted to specific surgical interventions and patient care situations.
A proper design of a TIMMS, taking into account modern software engineering principles such as service oriented architecture, will clarify the architectural and functional features of a SAS in general and its components in particular. Such a system must provide a highly modular structure in order to be able to adapt to different clinical workflows and specific variances in their execution. Modules may be defined on different granulation levels. Adaptability is achieved through a design concept-based on cognitive/intelligent agents.
The construction of the patient-specific medical model will be used as the central construct within a TIMMS, which may be described as an adaptive SAS. Ideally, the PSM engines and repositories will be integrated by a suitable TIMMS infrastructure to support the planning, execution and validation of an intervention. In the long-term, TIMMS can be expected to serve as a facilitator for a Model-based Medical Evidence (MBME) methodology providing a complement to Evidence-Based Medicine (EBM).
Considering the software engineering principles such a system needs to be designed to provide a highly modular structure. Modules may be defined at different granulation levels. A first list of components (e.g. high and low level modules) comprising engines and repositories of an SAS, which should be integrated with a TIMMS, is currently being compiled in a number of R&D institutions.
Figure 1 shows a concept of a logical structural model (meta architecture) of a high level generic modular architecture of an SAS. The high level modules are abstracted from many specific CAS/IGT systems which have been developed in recent years. In general, a combination of these can be found in most R&D as well as commercial SAS. A central position in figure 1 is occupied by the “Kernel for workflow and knowledge and decision management”. It provides the strategic intelligence for preoperative planning and intraoperative execution. Often this module (or parts thereof) is integrated into some of the other engines, as the need may have demanded. In any case, adaption of the therapeutic workflow to an actual patient care situation will be based on the PSM and realised by the Kernel.
All of the engines, tools, repositories, ICT infrastructure, data sources - including the operative team - are linked through a distributed network, providing for the full functionality of TIMMS, including planning, guidance, learning and data mining and processing.
The ICT infrastructure used by TIMMS includes structures, objects, processes and interfaces from well established sources, to ensure compatibility and interoperability. This includes, but is not limited to:
Interfaces are provided for the input of data and information from the outside world which are then processed and utilised by the functional components of TIMMS and stored within the repositories.
A possible physical realisation of interfaces required between major functional groups within and outside TIMMS is shown in Figure 2. Appropriate use of standards (for example S-DICOM) allows for the implementation of flexible pilot systems and in turn contributes to their further developments.
Interfaces are also provided for the output of various models, intervention records, report data and information that have been synthesised within the TIMMS structure. Each possible realisation implies to give special attention to security, safety, systems recovery issues and the infrastructure for rapid prototyping. Only a subset of the indicated engines and repositories of TIMMS are typically implemented in a real clinical setting (see Figure 3 as an example).
Significant hardware and software infrastructure is required to support research, particularly in IGT areas, that involve medical imaging and navigation. Hardware support can include a number of different imaging systems (CT, MRI, X-ray, ultrasound, etc.) and several 3D tracking systems based on a variety of technologies (optical, electromagnetic, etc.). Software support includes standards such as DICOM, as well as open such as VTK, ITK, DCMTK, 3D Slicer, OpenTracker, and IGSTK. In contrast, there is no off-the-shelf-robot system—with an open interface—that is suitable for medical use and no mature open source packages for robot control.
Standards for creating and integrating information about patients, equipment and procedures are vitally needed when planning for an efficient OR and TIMMS. The DICOM Working Group 24 (WG24) has been established to develop DICOM objects and services related to Image Guided Surgery (IGS). To determine these standards, it is important to define day-to-day, step-by-step surgical workflow practices and create surgery workflow models per procedures or per variable cases.
As the boundaries between radiation therapy, surgery and interventional radiology become bleak, precise patient models will become the greatest common denominator for all therapeutic disciplines. In addition to imaging, the focus of WG24 should, therefore, also be to serve the therapeutic disciplines by enabling modelling technology to be based on standards. A more detailed discussion which emphasises a model-centric world-view of therapeutic disciplines as a complement to the traditional image-centric world-view of diagnostic radiology is presented in figure 3.
Following the inauguration of WG24 on June 25, 2005 during CARS 2005 in Berlin, the following roadmap has been agreed on by the members of WG24:
1. Identify and build up a user community of IGS disciplines in WG24. Initially five surgical disciplines (Neuro, ENT, cardiac, orthopaedics, thoracoabdominal and interventional radiology) are selected. Anaesthesia is included as long as surgery is affected.
2. Encourage experts from vendor and academic institutions to join WG24. Vendors of endoscopic and microscopic devices as well as implants (templates) should be included in addition to the classic vendors of medical imaging and PACS.
3. Compile a representative set of surgical workflows (with a suitable high level of granularity and appropriate workflow modeling standards and surgical ontologies) as a work reference for the scope of WG24. Initially, 3-5 workflows, characteristic for each discipline, should be recorded with sufficient level of detail. Workflow tools can be provided by the Innovation Center Computer Assisted Surgery, Leipzig, Germany.
4. Derive potential DICOM services from these surgical workflows.
5. Design an information/knowledge model based on Electronic Medical Record (EMR) related work and identify IOD extensions to DICOM. Because of similarities to the IHE activities, a close relationship to IHE should be established.
6. Take account of the special image communication (1D - 5D) requirements for surgery and mechatronic devices. A close cooperation with WG 2 and 17 should be established.
7. Work in close cooperation with DICOM experts from radiology, cardiology, radiotherapy and related fields which are represented in WG1 - WG23.
8. Encourage close cooperation with working groups in the International Society for Computer Aided Surgery (ISCAS), Japan Institute of CARS (JICARS), German Society for Computer- and Robot-Assisted Surgery (CURAC), European Federation for Medical Informatics (EFMI), European Association for Endoscopic Surgery, American College of Surgery, International Society for Surgery, etc.
9. Disseminate knowledge gained following the roadmap through workshops, conferences and special seminars. Special presentations should be planned each year for CARS, SPIE, RSNA, DICOM-Meeting, and at a minimum for one surgical conference.
10. Connect to integration profiles specified for surgery by IHE activities.
The first two work items WG24 is involved with are “Polygonal Segmentation” (cooperatively with Working Group 17 (3D)) and “Implants”. DICOM always combines Objects with the Services they are using in Service Object Pair Classes (SOP-Classes). WG24 is therefore working on the Services which are needed for Polygonal segmentation Storage/Retrieval and implant usage (repositories and implant planning). Both SOP-Classes are making use of a common Surface Mesh Module. They are considered as supplements for DICOM in Surgery.