We are developing an ontology-driven system for collecting, recording, and managing patient histories. It consists of a web application with an RDF triple store database populated with representations in OWL of the entities that medical histories are about. It also represents the processes involved in collecting patient histories, including the questions, answers, and other information artifacts involved. It replaces paper questionnaires previously used for both general health and oral health history. The underlying ontology will be made publicly available. This abstract discusses the system, focusing on the ontological models underlying it.
The UB dental school conducts education and research in addition to providing patient care. Our patient history system collects and stores data in a way that preserves its meaning independent of any one use. Its representations of the patient's history are independent of how that information was produced (i.e., the particular software used). Storing OWL representations in a triple store with reasoning makes the data readily available for queries and logical inference.
Rather than recreating paper forms in software as a list of questions, our system dynamically adjusts which questions are shown based on preceding answers. It captures provenance of any data that it records and explicitly represents the question-taking process, its participants, its sub-processes, and its results. Every answer is linked to the person who recorded it, the time, the patient it’s about, etc.
The data model uses science-based ontologies associated
with the OBO Foundry including Ontology of Biomedical
Investigations (OBI), Information Artifact Ontology (IAO),
Ontology for General Medical Science (OGMS), and Oral
Health and Disease Ontology (OHD) (Scheuermann et al,
2009)
The system facilitates collecting general health history, oral history, family history, etc. When a patient visits our clinic for the first time, that encounter includes creating a record of the patient’s history. A provider asks the patient questions and records the answers in the system. When a student in the provider role finishes history-taking, a faculty member reviews and approves the student's work. Some non-student providers can approve their own work, but all entries pass through the unapproved state and require approval before they become part of the patient's record.
Updating a history is similar: a provider reviews it with the patient and makes any necessary changes. The system retains the entire history of changes to the record. 3
The model underlying this system contains representations of information artifacts such as questionnaires and their contents (questions, acceptable answers); specifications governing how and when these things are to be displayed during use of the system; and workflows realized in the system. It also contains representations of entities and processes relevant to the patient's health (the patient's body, its disorders), and information about healthcare processes (a historytaking, the encounter it is a part of). 3.1
Figure 1 shows our representation scheme for the questions, potential answers, and groupings of those elements that comprise a questionnaire. Here we focus on a single question, though a questionnaire typically includes multiple groups of questions, multiple questions per group, and specifications for ordering those.
The questionnaire (form1) instantiates IAO: document. It has as parts question group specifications (questiongroup1, e.g.), which have as parts question specifications. A question specification (e.g. question1, about myocardial infarction) is an IAO: directive information entity that includes the text of the question and has as part an answer group specification with acceptable answers. There are a many answer group specification types. answer-group-1 is an instance of the simplest: a list of labeled possible answers, one of which is to be selected as the answer. Each is an answer specification, (answer-spec3, et al). 3.2
Figure 2 shows our representation of answers, the processes that produce them, and their participants.
The patient (patient1) has the role patient role throughout the visit. Each provider the patient interacts with during the visit realizes the provider role during that interaction. The patient’s visit to the dental clinic (encounter1) is an OGMS: health care encounter that usually has other encounters as parts. The OGMS: clinical history taking in which patient1 and provider1 participate (history-taking1) is one of the parts of encounter1. history-taking1 has processual parts that are instances of history question taking. Each has a question specification (e.g. question1 from Figure 1, shown here without its text) as input and produces as output a medical history answer (answer1).
Every instance of medical history answer is created as the output of a history question taking. Answer instances are connected to, but distinct from, instances of answer specification. There is only one answer specification for the short text answer “yes” (i.e. answer-spec3) but many medical history answers will use/denote it (e.g. answer1). answer1 is about a myocardial infarction that inhered in the patient at some time. When this question is answered “no” rather than “yes,” there’s no individual disorder that the answer’s about.
This discussion ignores temporal considerations for simplicity’s sake. Note that every answer is a unique instance and the output of a unique process of asking the question. The answer persists even when the world and knowledge about it changes, for example because a patient who had never had a myocardial infarction as of their first visit does experience one between their first and second visits to the clinic. When the patient’s history is updated to reflect this, the old answer remains part of the record and a brand new
We are developing a medical history application based on a carefully constructed ontological model that represents not only the things that a patient history is about, but also elements of the history-taking process, including the questionnaire and its contents. The result is a flexible, easily-queried knowledge base of patient histories with semantic representations that facilitate its use for research and in conjunction with other information systems. This work is ongoing. We continue to develop the software and representation.