An Ontology-based Framework for Radiation Oncology Patient Management

1. An Ontology-based Framework for Radiation Oncology Patient Management DLMcShan1, MLKessler1and BAFraass2 1University of Michigan Medical Center, Ann Arbor, MI, 2Cedar-Sinai Medical Center, Los Angeles, CA University of Michigan Medical School University of Michigan Medical School SU-E-T-27 AAPM 2011 BACKGROUND MATERIALS AND METHODS RESULTS Radiation oncology has become quite sophisticated in terms of its use of advanced imaging technology and the use of that data to design highly tailored treatment plans that will be delivered by advanced computer-controlled treatment machines. However, an(often missing) piece of technology is overarching support for the management of the patient care in terms of the desired treatment goals and how they dictate the various process steps (human and machine) involved in preparation, delivery and monitoring of the patient care. This level of support is particularly important for more complex treatments involving adaptive-individualized treatment adjustments based on updated information about the patient over the course of treatment. To provide this level of management, the approach introduced here centers on an ontology knowledge database to form the key resource for a framework that will be used to maintain patient context and to integrate with other departmental systems. The major advantages of using an ontology (in lieu of a traditional relational database) lies in its ability to maintain maximum flexibility in data organization, its ability to provide a common understanding between humans and machine processing, and its ability to be queried to retrieve both explicit knowledge and implicit knowledge deduced from the established relationships. In addition to providing support for management of complex treatment scenarios, our approach allows the use of sophisticated clinical decision support tools such as guideline support, reasoning, machine learning (over time), and use of Bayesian statistical analysis. • Ontology: For a given domain, defines concepts, properties, relationships, and instances. Concepts represent objects within a given domain. They are further defined by adding properties, relationships, and constraints. All data is added as instances of these objects. • Design Tool: Protégé Ontology Editor http://www.protege.stanford.edu • Using OWL (Web Ontology Language) http://www.w3.org/TR/owl-ref/ • Multiple domains described with specialized ontologies (see Figure 1) • The ontology has been defined with an OWL ontology model using Protégé. An Oracle database is loaded with the ontology model and is populated with instances of the model(i.e. actual data). The model is not intended to be a complete model of the data captured within the department. Instead, the ontology model provides mappings to external data sources which can then be used by the framework to provide a unified data access To retrieve and update ontology data, SPARQL queries are messaged to the ontology access components • Technologies: • Database: Oracle 11g – Database Semantic Technology supporting OWL/RDF • Messaging: • Google Protocol Buffers – message serialization • AMQP – Advanced Message Queuing Protocols • Query/Rules: SPARQL, SPARUL, SWRL, Jess • Reasoning engines: DIG reasoner, Pellet • Languages: Java, Spring, Jena, Haskell, C++, C, Fortran, Python Initial ontology construction has been based on both standardized and departmental concepts. Guidelines used include making the ontology of sufficient (and extensible) scope to tie together key concepts with enough depth to be useful for study retrieval (queries), and with enough attribution to identify related source material (files, URLs, PACS systems, other databases, etc.) Integration of this new knowledge-modeling mechanism into our clinical/research infrastructure framework is underway. An initial implementation is based on interfacing to our in-house developed planning system environment (Figure 2). Current efforts focus on modeling and implementing more sophisticated management of planning and delivery for adaptive therapies based on biomarker assessments that identify or predict changed response to the dose received during treatment. In these complex protocols, treatment plans must be organized by treatment directives that specify treatment goals, must include detailed knowledge of prior treatment, and manage all new patient-specific data acquired during the treatment course. Figure 3 presents a graph of these related portions of the ontology. . Organizational Ontology Equipment Ontology Upper Ontology Workflow Ontology Planning Ontology Treatment Ontology Medical Ontology Case Ontology Oncology Framework Schematic PURPOSE • To describe the technology and implementation of an ontology framework for radiation oncology patient management. • Desired framework functionality: • Consolidate key data from multiple data sources • Provide access to this data via SPARQL queries • Maintain status, dates, and data locking • Provide logging of changes and actions • Provide rules-based validation and consistency checking • Provide links to associated image sets / planning / dose / DVH files Figure 3. Ontology graph from Protégé showing relationships of a Plan as part of a treatment Scenario that describes a treatment Path consisting of Pathlets. Each Pathlet represents an evaluation point within the Course of treatment. CONCLUSIONS An ontology-based knowledge base has been developed as the information framework of a new radiation oncology patient management system. The ontology provides the extensible means to describe and manage highly complex adaptive treatment protocols for unique and advanced clinical studies. In conjunction with the framework, data can be populated frommultiple data sources. The framework designallows distributed implementations utilizing advantages of specialized hardware (clusters, GPU). Finally, the ontology design can be shared with others and can lead to community efforts toward developing common concepts and terminology. Figure 2. Schematic of ontology framework. Clients (of various types) access “middleware” services. The acyclic graph “Data Cache” denotes a cached copy of the ontology for a specific case. Color indicates model nodes related to access to a specific data source. Lowest level represents the various data sources. Figure 1. Multiple connected ontologies