Ontology-driven Patient Information Capture (OPIC)
Introduction
OPIC system supports multiple types of data entry requirements, such as admission notes, progress notes for a patient, and discharge summary reports along with the functionality to support the input and storage of multi-modal patient data in form of EEG, EKG, and MRI reports.
PRISM is the first use case for OPIC, as it requires the ability to uniformly capture patient information across the four EMUs and store the data in a common format with real-time access by researchers to support cohort identification.
OPIC uses epilepsy ontology as reference terminology for the creation of a Web-based interface for uniform entry of patient information in epilepsy enters (Sahoo et al., 2012).
Architecture
The OPIC system is built using agile methodology for rapid and iterative development in close consultation with the users. The Ruby on Rails (RoR) web development framework has been used to implement OPIC with a Model-View-Controller (MVC) architecture pattern (Figure 2).
The MVC pattern involves a strict separation of the application logic from the user interface, which enable OPIC to seamlessly adapt to changing requirements of a clinical study (e.g. addition of blood oxygen level parameter for patient evaluation) or updates to the ILAE epilepsy and seizure classification system.
This implementation approach ensures that OPIC is a flexible and user-centered system that can be used nationally as well as internationally to support effective capture of patient information. In the following subsections we describe the design and implementation of OPIC.
The OPIC system uses domain-specific epilepsy and seizure ontology (EpSO), a web-accessible and flexible patient data capture system that is supported by a common terminological system to facilitate data re-usability, sharing, and integration.
OPIC leverages the EpSO class hierarchy (Figure 3) to automatically reconcile variations in use of terms describing clinical findings also. For example, “fast ripples” is a special type of “high frequency oscillation” EEG feature that is typically analyzed in evaluating surgical outcomes for refractory patients.
Similar to the drug information example, OPIC automatically identifies all terms linked to a clinical description by traversing the “parent-child” links in EpSO and retrieves the associated patient records that use either “fast ripples” or “ripples” in their description of intra-cranial EEG data.
- Input Data Validation
- Logical Skip Patterns
- Indexing Ontology Terms
- Dynamic Table Interface for Medication Information
- Dynamic Report Generation and Database Support
OPIC Schema
The OPIC system contains 46 relational tables: 18 of them are used to store information to populate form hierarchy, multi-level drop down menus and check-box lists, 1 table stores report status information, 1 table stores de-identification mapping information, and the rest 26 tables store report data. Each table that stores report data has a corresponding model in the MVC architecture. Base upon the requirement, some information which appears only once in the report will be stored in one table regardless they are from one section or not; otherwise, one small section corresponds one table in the database.
The automatic generated id is the primary key, report_id and section_id is the foreign key. Figure B.1 presents a fragment of dependencies between tables that store report data
[2]
