Definitions of Common Clinical Terms

This post has been superseded. Please refer to the updated post on the same topic. 

We all use these words in clinical medicine: observations, assessments, diagnosis, medical condition, adverse event, outcome measure, endpoint. But what do they really mean? The published definitions are all over the map, often imprecise and inconsistent. I have conducted informal polls of medical reviewers at FDA and, guess what, they mean different things to different people. These are highly educated, highly experienced people. The same problem exists in academia and industry. I see this in the wide variability in how these words are used in study protocols.

Standardizing the definitions of these common term has been a topic of interest to me. How can we automate the processing of clinical data if we can't all agree on definitions for these basic terms in clinical medicine? Using best practices for how to define things, I have come up with the following "working definitions" that I think are unambiguous and internally consistent...i.e. enables humans and information systems to clearly distinguish them apart. I'd also like to think they are accurate in how they're used or should be used in clinical medicine. I present them here in no particular order other than some naturally flow from others.

1. Clinical Observation: a measure of the physical, physiological, or psychological state of an individual.

Note: A Clinical Observation is ideally observed by a qualified individual, following a standard process, but without implying a cause. Many clinical observations simply reflect a normal physiological state. e.g. BP 120/80 mmHg.

1(a). Symptom: a Clinical Observation that can only be observed by the patient (e.g. pain). Synonym: Subjective Observation

1(b). Sign: a Clinical Observation that can be observed by someone other than the patient (e.g. blood pressure). Synonym: Objective Observation.

Note: Signs can also be self-observed, for example, fingerstick glucose or blood pressure using an appropriate home monitoring device.

1(c). Outcome Measure: A Clinical Observation that is of interest for some research activity (e.g. clinical or epidemiological study). The outcome measure is intended to support one or more objectives in a research project.  e.g.: Hemoglobin A1C in a diabetes study.

1(d). Patient Reported Outcome (PRO) is an Outcome Measure that is also a Symptom.

2. Endpoint: A combination of 3 concepts: [1] one or more Outcome Measures, [2] a time element describing when the outcome measure is collected, [3] and an algorithm describing how the Outcome Measures are combined for analysis (optional). (Credit goes to Roomi Nusrat, M.D. for this one) Example: Percent change from baseline in HgbA1C measured at 12 weeks.

Note: I find Outcome Measure and Endpoint often used interchangeably. Sometimes they are very close: e.g. Viral Load (outcome measure); Viral Load at 6 weeks (endpoint).

2(a). Composite Endpoint: an Endpoint with two or more distinct Outcome Measures.

3. Medical Condition: a disease, injury, or disorder that interferes with well-being. It is associated with a pathophysiology. It is also associated with a duration (i.e. an event).

Note: Medical conditions are the target of medical interventions (one notable exception is Pregnancy; though not a disorder it is the target of prenatal care to help prevent pregnancy-related complications). Medical conditions explain the presence of abnormal clinical observations. We often confuse a clinical observation (e.g. low serum sodium at a single point in time) with the medical condition that gives rise to it (e.g. hyponatremia). I write about this distinction in more detail in a previous post.

3(a). Adverse Event: A Medical Condition that emerges or worsens following a Medical Intervention. Note: there is no presumption of causality.

3(b). Adverse Reaction: An Adverse Event that is caused or worsened by a Medical Intervention. Here causality is presumed.

3(c). Treatment Emergent Adverse Event: [I'm putting this here as a placeholder as I'm still looking for a good definition.  I think the key features of a TE AE is that it is an Adverse Event associated with a specific Medical Intervention, and some algorithm is defined to establish the temporal association. I welcome suggestions].

3(d). Indication: A Medical Condition that is the target of a Medical Intervention; i.e. the reason the Medical Intervention is performed.

4. Medical Intervention: An activity intended to affect (e.g. treat, cure, prevent, diagnose, mitigate) a Medical Condition. e.g. Drug Administration, Surgery, Device implantation.

5. Assessment: An analysis of one or more Clinical Observations to characterize a Medical Condition.
Note: Sometimes assessment is used to mean the collection of a clinical observation. I would like to see us move away from this use as it is confusing. The clinical process is first observe or measure clinical observations then assess one or more clinical observations to identify/characterize medical conditions.

6. Diagnosis: this is an overloaded term in clinical medicine. It has two definitions depending on whether it's used to mean a process or a thing.

Diagnosis (the process): An Assessment to identify the presence of a Medical Condition.
Diagnosis (the thing): A Medical Condition identified for the first time via an Assessment.

So we can say: Q. What did the diagnosis (diagnostic assessment process) show? A: Adult Onset Diabetes Mellitus.  OR
Q. What is the diagnosis? A: Adult Onset Diabetes Mellitus.

Note: Because Diagnosis (the thing) is a Medical Condition, one can define a start/onset date as the date of the first Clinical Observation associated with the condition, as well as the diagnosis date, which is the date the diagnostic assessment was complete, i.e. the date the Medical Condition was first identified via an assessment. As we all know, these are often not the same.

One interesting question is can a Medical Condition be an Outcome Measure in a study? The way they are defined here, Outcome Measures are always Clinical Observations, not Medical Conditions. A stroke prevention study might define Stroke as the primary Outcome Measure, but is it really? A close inspection reveals that it's really the symptoms and signs of the stroke that are important (i.e. what we can observe/measure). Stroke is clinically very heterogenous and can present in many different ways, so we need to describe what Clinical Observations are most likely indicative of a stroke? (e.g. paralysis, numbness, visual loss, etc.) These, then, are the true Outcome Measures. So when we see a Medical Condition as an Outcome Measure, there needs to be an adjudication process (i.e. Assessment) to define the Clinical Observations that need to be measured and analyzed to assure the Medical Condition is present.

I welcome comments to refine these and make them more useful. I think the interesting part comes in converting these definitions into OWL representations, to enable computers to reason across the data. This remains a research interest of mine. Maybe I'll get into that in a future post.

Improving the Study Data Tabulation Model

This post looks at some ways of improving the Study Data Tabulation Model (SDTM).  Why? The Therapeutic Area (TA) standardization initiative has shown that new domains and variables are needed to standardize TA-specific clinical data, yet new domains and variables pose significant implementation challenges.  An almost endless cycle of new domains and variables seem inevitable as more and more TAs are tackled. We need to step back and critically look at changes to make implementation easier and more consistent across studies and sponsors. Others are expressing the need to slow down and make some corrections (see this post by W. Kubick).

SDTM in its current state is too brittle. It is not flexible enough to accommodate new clinical data requirements efficiently. I have suggested in a previous post that we need a new exchange standard, one that is based on a highly relational information model for study data. A more robust exchange standard can handle new clinical data requirements more easily, often with a simple additions of new terms to a standard terminology. However, getting there won't be easy. The suggestions here describe a possible interim solution. Some of the changes are minor. Others are quite major and likely to be controversial. I don't know if this is the right approach, but it makes sense to me as a consumer of clinical data for over 25 years. I believe the status quo is not sustainable. We need to do something.

In another post, I described the "clinical data lifecycle" that reflects how clinical data are generated and used in clinical practice, and how they are documented in a patient's medical record. I described the 4 parts of the traditional SOAP note of a clinical encounter, analogous to a subject visit in a clinical trial:

1. Subjective Observations
2. Objective Observations
3. Assessment
4. Plan 

These describe the major categories of data for a new and improved SDTM. Let's examine each in some detail. 

Clinical observations provide a snapshot in time of the physical, physiological, or psychological state of an individual. Subjective observations are those that only the individual can make (e.g. pain). Objective observations can be made by others. By themselves, observations are not attributed to any one specific cause or underlying medical condition. Many, in fact, simply measure the normal physiological state. Observations must undergo an assessment to identify and characterize one or more medical conditions that best explain the observations. The medical condition(s) form the basis for the care plan and its execution. The care plan is designed to address (e.g. treat, cure) the medical condition(s). When the care plan involves an experimental intervention as part of clinical research, then this forms the basis of a study protocol. This simple model for clinical data forms a continuous feedback loop with various stopping rules (not shown here). 

But exactly how do we leverage this model to improve the SDTM? The goal is to make SDTM more stable and flexible, i.e. enable it to incorporate new clinical data content requirements more easily and (hopefully) greatly lower the need for new variables and new domains.  This will make implementation easier and SDTM datasets more useful. By its very nature, this is a high level discussion that only scratches the surface of the changes that could be made. I admit that the devil is in the details.  

We start with a proposal to improve cross-references. 

1. SDTM should incorporate unique identifiers for each record in each domain. 

Clinical data are richly inter-related and unique record identifiers simplify the ability to reference other relevant records. The --SEQ variable is currently used for this purpose but by itself is not unique. (Ideally, the identifier is globally unique, so that a record in one study can reference a record in another study. This brings us closer to creating a web of clinical data, which is an important component of the semantic web. But I digress.)

We need to refine the definition of observations. SDTM describes observations as findings, interventions, and events, and each corresponds to an individual row in a tabulation. If we agree that a clinical observation is a measure of the physical, physiological, or psychological state of an individual, interventions and events are not observations. Clinical events are instead medical conditions that explain the clinical observations, not the observations themselves. For example, a low serum sodium measured via a lab test (observation) may indicate, after a proper assessment, the presence of hyponatremia due to a Syndrome of Inappropriate Anti-Diuretic Hormone (SIADH) secretion (medical condition). Medical conditions are identified and characterized through assessments of clinical observations. I discuss the importance of distinguishing clinical observations and medical conditions in another post. So what about interventions? In the purest sense, all clinical observations are "interventions," since the act of observing is always associated with a process, protocol, or procedure. This process of observing "intervenes" in the subject's normal set of activities and can therefore be considered an "intervention" in the strictest sense. However, we generally limit the use of the term medical intervention to an activity whose intent is to affect in some way (e.g. treat) a medical condition. Therefore, the important information classes to support the clinical data lifecycle are  similar to what we have now: observations (i.e. findings in SDTM), interventions, and medical conditions (types of events), but they are defined somewhat differently and than the current SDTM. The next needed change is:

2. SDTM should add an assessment domain to capture important assessment information. 

We've discussed that clinical observations serve as input to an assessment. Each assessment record should link to the clinical observations that serve as input, and the medical condition(s) that serve as output. Practically speaking, this is important because sometimes one needs information about that assessment to ensure the assessment is reliable, i.e. performed correctly and without bias. Who made the assessment? What are their qualifications? What observations were used in the assessment? Were the observations the appropriate ones? Are there any important observations that are missing and should have been done? When was the assessment performed? What process was followed (e.g. was there a formal adjudication process)? What criteria (e.g. diagnostic criteria, rating scale) were used? Currently there is no single, systematic way in the SDTM to capture the information associated with assessments. The end result is a patchwork of variables (many of them custom variables that wind up in SUPPQUAL's) that try to fill this gap. There is a recognized need to document adjudication data and this approach I think does that. As an aside, adverse events are adverse medical conditions that emerge or worsen following a medical intervention. These are identified by an assessment (often not documented) of relevant observations. Currently we routinely confuse an adverse event and the observations that support the presence of an adverse event. This can lead to erroneous interpretations of clinical observations. 

The next suggested change is ....

3. SDTM needs a single approach to describe clinical observations. 

This is a big one, because newly-identified clinical observations for therapeutic areas are triggering an ever increasing number of new variables and domains and this is not sustainable. Each observation is recorded ideally without bias (and standard processes or protocols may exist to minimize bias) and without interpretation by the observer regarding its cause. The standard components of a clinical observation are well known and they define the metadata needed for each observation. These can help guide changes to the generic findings domain in the SDTM (the model, not the I.G.).  For example, is the observation planned or protocol-specified? Is there a documented process or method for making the observation (and a link to that process). Was a device used (link to information about the device), was a biospecimen collected and analyzed? (link to biospecimen information). Observations are often grouped or nested, so grouping and nesting information is needed. Regarding terminology for clinical observations, the Logical Observation Identifier Names and Codes (LOINC) should be adopted as the single terminology to describe a clinical observation. The LOINC was developed for this purpose. The lab portion of the LOINC is quite robust, but the clinical portion will likely need to grow over time to accommodate the range of clinical observations needed for clinical research. This means creating a robust process to register new clinical observations with the LOINC as new codes are needed. Using the LOINC will also help harmonize clinical data used for research with clinical data used for other purposes, since LOINC is used widely in health care. Ideally there is a single clinical observation domain containing sufficient metadata to allow subsetting in multiple ways for analysis purposes (e.g. lab, EKG, CT, MRI, etc). Clearly size limitations of an observations domain quickly become an issue, but these should diminish as data are routinely loaded and stored in databases prior to use, which can then deliver observation data to the analyst in manageable chunks. In the meantime, continued splitting into multiple clinical observation domains may be necessary, but only as necessary to meet data exchange and data management requirements. 

4. SDTM should have a single approach to describe all Medical Conditions. 

By medical condition I mean a disease, injury, or disorder that interferes with well-being. A medical condition is associated with an underlying pathophysiological process. It has a beginning and an end. Medical conditions are the target of medical interventions, whereas clinical observations are not. (Pregnancy is a notable exception in that it is not a disorder but is the target of medical intervention, i.e. prenatal care, to minimize complications.) The medical conditions domain contains past and current medical conditions including medical conditions that emerge during the study. Important information about each medical condition include the following (it is worth noting that not all this information will be known about every medical condition, but there should exist a standard way of describing it if it is available). Date of first symptom/sign (onset date), date of diagnosis (date the medical condition was first identified via an assessment), a link to the assessment record if one exists, a link to the clinical observations that were used for the assessment, date of resolution (end date, which for ongoing medical conditions will be null). Date of reporting (cutoff date). Severity at the time of the last assessment, change in severity since the previous assessment. Is the condition ongoing at the time of reporting? Is the condition the reason for the study (the indication). Is the medical condition considered an adverse event, i.e. any adverse medical condition that emerges or worsens following a medical intervention? Is there a plan to address/treat the medical condition (link to the plan). In the case of the indication, the plan is documented in the protocol. The plan links to the clinical observations and medical interventions performed following the execution of plan. From the medical conditions domain, medical history, adverse events, and clinical events domains can be derived using standard algorithms.

5. SDTM needs a single approach to describe planned medical interventions. 

This includes a link to the medical condition that triggers the intervention, the reason for the intervention (treat, cure, mitigate, diagnose, prevent), the type of intervention (drug administration, device, surgery, etc.) and a link to the planned clinical observations to assess the effect of the intervention on the medical condition. 

Following its execution, the outcome of the care plan is documented as additional clinical observations that lead to additional assessments in a continuous loop. The cycle ends according to stopping rules. Reasons for stopping include  [1] death, [2] resolution of the medical condition, [3] arbitrarily (protocol specified). 

Some of these suggestions constitute major changes. But by organizing the data more closely with the way they are generated and used in clinical practice, the data become more useful and the ability to incorporate new clinical data content is improved without needing frequent upgrades to the model. Adding new clinical content should be as simple as adding new controlled terms to a dictionary. This is critically needed as clinical data content requirements continue to expand with no end in sight. 

I appreciate your comments.  

Distinguishing Clinical Observations and Medical Conditions

As the pharmaceutical industry moves quickly towards standardized clinical study data, I continue to see confusion in how clinical observations and medical conditions are represented. In clinical medicine there is a sharp distinction between these two concepts, yet in standardized study data submissions they are often lumped together.

A clinical observation is just that: someone observes a clinical symptom or sign of a patient. The observer may be the patient (in which case it's called a symptom) or someone else (in which case it's called a sign). Often a medical device is involved in the observation (blood pressure cuff, thermometer, x-ray, MRI, etc.). Often the observer follows a procedure to provide some level of consistency in making the observation. A headache, a rash, a fever, an elevated blood pressure, a low serum sodium, a round hyper intense lesion on an MRI are all examples of clinical observations.

Then we have medical conditions, which are diseases or injuries or other conditions that interfere with well-being. The Free Medical Dictionary defines a medical condition as:  A disease, illness or injury; any physiologic, mental or psychological condition or disorder (e.g., orthopaedic; visual, speech or hearing impairments; cerebral palsy; epilepsy; muscular dystrophy; multiple sclerosis; cancer; coronary artery disease; diabetes; mental retardation; emotional or mental illness; specific learning disabilities; HIV disease; TB; drug addiction; alcoholism). A biological or psychological state which is within the range of normal human variation is not a medical condition.  

This is a reasonable definition, although I disagree with the last sentence in that certain temporary  but normal physiologic states can be considered medical conditions. For example, I think pregnancy is a medical condition because, although it is within the range of normal human variation, it is a state that benefits from medical intervention (pre-natal care, obstetrical care) to minimize complications to the mother and child. 

Herein lies the major distinction between clinical observations and medical conditions. Clinical observations serve as input to an assessment (often conducted by a health care professional) to determine that a medical condition exists. Medical conditions are listed on a patient's problem list and are the focus of medical interventions. Clinical observations are not. 

Take for example an elevated blood pressure (clinical observation). Does this mean the patient has hypertension (medical condition)? Not necessarily. If the patient is obese, perhaps the wrong device was used. A normal sized cuff on an obese patient may give falsely elevated readings. Repeating the blood pressure measurement using a larger cuff may in fact reveal a normal blood pressure. It is also well known that anxiety of visiting the doctor may temporarily raise the blood pressure, so repeated measurements over time in a more relaxed setting could demonstrate normal serial blood pressures. 

Adverse Events are medical conditions temporally associated with a medical intervention. Here again, an assessment is necessary to determine that one or more observations indicate the presence of an adverse event. 

Study data standards continue to mix the two. In an earlier post, I described how BRIDG has the same problem. As another example, I was recently reviewing the Therapeutic Area User's Guide (TAUG) for Multiple Sclerosis. It advocates placing past clinical observations related to the MS diagnosis in the medical history (MH) domain. The past medical history portion of a typical history and physical evaluation is reserved for past medical conditions, not for past clinical observations. I think they should be separate. Unfortunately there is no good place in the SDTM to place past clinical observations.

Why keep them separate? Medical conditions have metadata that differ from clinical observations. For example, one may want to know which observations were used to identify the medical condition, who did the assessment, the date the medical condition began (i.e. the date of the earliest observation associated with the medical condition), the date of diagnosis (when the medical condition was first identified, which is often later than the onset date) etc. Was it associated with a medical intervention, and if so which ones? Is the medical condition considered adverse? From such a "medical condition" domain, one could derive AE, CE and MH.

I also think we need a single unambiguous way to represent all clinical observations, past and present. This is still lacking in clinical research, which results in multiple domains and new domains as data for more and more therapeutic areas are standardized. Key metadata for clinical observations are the date the observation was made, who made it, was it planned or unplanned, what procedure (if any) was used, what device (if any) was used, relevant metadata about the procedure/method/anatomic location, relevant metadata about the device, any associated observations (e.g. diastolic BP and systolic BP). We do not need an imaging domain, as others have suggested. Imaging is simply a method to obtain an observation.

Study Data Exchange: The Unsustainable Path

The current state of study data exchange, based on a tabular representation of study data, is in trouble. The CFAST experience is demonstrating that the requirements for new therapeutic areas (TAs) result in an ever increasing need for new variables and domains. The burden to industry and FDA to adapt to these changes is too great. Rapid changes in implementation guides  (IGs) and the data model itself are quickly exceeding an organization's ability to keep up. As new IG versions emerge, there will be a need to update the TA user guides, not to mention updates to validation rules, databases, etc. The resources needed to do that are quite formidable.

I believe the solution is to adopt a more robust, relational data model for study data exchange that is capable of incorporating new requirements easily, often by simply adding new terms to standard terminologies, rather than adding new variables and domains. The time to do this is now because the current approach is not sustainable. For example, the latest version supported by the most currently published FDA validation rules is SDTM v1.3/SDTM IG 3.1.3 yet the SDTM v1.4 is already published and work is well underway on SDTM v1.5. When I was at FDA, I was the chair of the Change Control Board (CCB) for the validation rules and I can say that it is extremely challenging to keep up with this rate of change, even if the Agency moves towards a paradigm of updating and maintaining just the business rules, as is currently planned.

Let me further illustrate the challenges of sustaining the current path with a simple analogy. Imagine that we want to exchange a person's contact information, similar to what is stored in an electronic address book. What should the exchange standard look like for these data? Here's a simple data model for contact information:

Assume that we add controlled terminology for certain concepts such as State, Zip Code, Area Code, and we have a perfectly reasonable and functional model. However, how do we handle a new requirement, such as exchanging both home and business addresses, phone numbers and email addresses? The current model doesn't support this requirement, so we update the model. We introduce new variables for home and business addresses, phone numbers, and emails. We get something like this:

Problem solved. Requirement met. We can group these data elements into logical groupings or "domains" and suddenly we start seeing the similarity to the SDTM:

However, validation rules, databases, and tools developed under the first model all need to be updated to accommodate the second model. This takes time and expense.

Yet new requirements continue to emerge. Now we want to exchange mobile phone information, so we update the model yet again to add new variables and a new MB domain:

And the cycle repeats for new TAs: update the IG, the validation rules, databases, tools.

There is a better approach: adopt a more robust relational data model as shown here:

Furthermore, we introduce controlled terminology for email type, address type, phone type (e.g. home, work, mobile), and we can accommodate all the requirements described thus far without a change in the model but rather simply adding new controlled terms to these concepts. More importantly, future requirements are also incorporated easily. Let's say many of the contacts are corporate executives with summer homes and we want to capture second home information? We add a new controlled term to the Address Type concept (i.e. second home) and we're done. No changes to IGs, validation rules, databases etc. are necessarily needed.

Does the more robust relational data model solve all our problems? No. New requirements may yet emerge that may necesitate changes to the underlying model (e.g. birth date, marital status), but the goal is to design the relational model as flexible as possible to make the need for such changes as infrequent as possible, to minimize the implementation burden.

Getting back to study data exchange. I believe we are in dire need of a new, more robust data model that represents all clinical observations and assessments in a single standard representation so that new clinical data requirements for additional therapeutic areas can be incorporated easily by adding new terms to a dictionary and without having to change the underlying model. The current approach is not sustainable and I foresee the entire therapeutic area standardization effort collapsing under its own weight. I think it is already starting to happen.

Aristotle and How Best to Define Things

The great challenge in automating analysis of biomedical data is the fact the people use different words for the same thing and the same word for different things. Having clear, unambiguous definitions, or semantics, is of course critical. I wrote a bit about this in a post on the Interoperability Problem. In today's post, I discuss how to best define things. It turns out Aristotle figured this out long ago. But first I discuss the context in which these definitions matter.

Also in a previous post, I explored using BRIDG as a computable ontology. Since then, I have continued to work on various projects (both within and outside of PhUSE) to represent study information using RDF. I keep running up against the same limitation: the need for a computable study ontology based on clear, unambiguous, computable definitions. For example, in the PhUSE project to represent eligibility criteria using RDF, the criteria need to link to a subject's screening data collected in a study. Where does one link to?

It turns out that the Open Biomedical Ontologies provides an Ontology for Biomedical Investigations (OBI). I'm in the process of evaluating this ontology to see if it meets our needs. I think it holds great promise. One advantage is that the OBI, as are other ontologies that make up the OBO, is based on a single, common reference ontology called the BFO (Basic Formal Ontology). This helps establish interoperability of biomedical data from various sources that are expressed using any of the ontologies in the OBO. I'm in the middle of reading a book on the BFO and I will hopefully have more to say about it in future posts.

In the meantime, to continue our work, we have built a mini human study ontology containing only the sufficient classes and relationships to support these projects. For this I have turned to BRIDG to use existing classes wherever possible. Unfortunately, I keep running into problems with the way many BRIDG classes are defined. I find the current BRIDG definitions don't easily lend themselves to an unambiguous OWL representation.  We have discussed this in previous BRIDG working group meetings. It's clear to me that many BRIDG definitions need to be refined before a useful OWL representation can be developed.

Let me explain with some examples. But before I do so, I ran across an interesting chapter in the BFO book on good practices in developing ontologies. One of them is the principle of applying "Aristotelian Definitions" to concepts. I've never heard of the phrase before and this is what I understand.  An Aristotelian definition is one that has the following form:

S = def. a G that D's.

Where G (for genus) is the immediate parent term of S (for species) in the ontology and D stands for differentia, which is to say D describes what it is about G that makes it an S. Ideally, the differentia itself is described in terms that are already defined in the ontology.

Consider Aristotle's own definition of Human, as described in the BFO book:
human (S) = is an Animal (G) that is rational (D).

As the BFO book points out "...following this Aristotelian definitional structure ensures that the set of definitions in an ontology precisely mirror the hierarchy of greater and lesser generality among its universals."

Now let's take a look at BRIDG definitions relevant to a Study Subject. The latest version 4.0 documents the following:

BiologicEntity

Any individual living (or previously living) being. Person A human being.

Subject

An entity of interest, either biological or otherwise.

StudySubject

A physical entity which is the primary unit of operational and/or administrative interest in a study.

For the purposes of discussion, I use the colon (":") to describe a resource in RDF (e.g. an OWL class or property).  

It's clear to me that :Person is a :subClassOf :BiologicEntity. If the :BiologicEntity has a property :species with a value :HomoSapiens then a reasoning engine can conclude that the :BiologicEntity is also a :Person. I see no problem there.  

It's also clear a BRIDG Subject may or may not be a Biologic Entity. But what does it mean for a Subject to be an entity "of interest?" Is a Person that is being considered for recruitment into a trial a Subject? If so, one can define an activity called :RecruitmentActivity and a property called :undergoes and then create an Aristotelian definition that a :Subject is an :Entity that :undergoes a :RecruitmentActivity. This makes sense for a Human Subject but not so much for animals or non-biologic things. How does one resolve this?

One way to sidestep the issue is to define a :subClassOf :Subject called :HumanSubject and create the relationships above only for the HumanSubject class. So the Aristotelian definitions becomes: 

A :HumanSubject is a :Person that undergoes a :RecruitmentActivity. 

So then how is a :HumanSubject related to a :StudySubject? It's not clear, since StudySubjects can be non-human. One way to resolve this is to create a subClassOf :StudySubject called :HumanStudySubject and then one can say that a :HumanStudySubject is a :subClass of :HumanSubject.  More specifically, one can define a property called :participatesIn and say that a :HumanStudySubject is any :HumanSubject that :participatesIn any :Study.  (:participatesIn can be defined as sub-property of :undergoes, i.e. :undergoes any protocol-specified activity, including informed consent or screening). 

So for the purposes of our mini-ontology, we have the following computable, Aristotelian definitions. I'd appreciate feedback on these. 

BiologicEntity

Any individual living (or previously living) Entity.

(i.e. an :Entity (G) that is living or was previously living (D)) 

Person

A human being. A BiologicEntity that has species homo sapiens.

Subject

An Entity, either biologic or otherwise, of interest for investigation in a Study.

StudySubject

An Entity which is the primary unit of operational and/or administrative interest in a study. The StudySubject undergoes (is subjected to) Study-specified activities as described in the StudyProtocol.

(i.e. a :Subject (G) that undergoes/is subjected to Study-specified activities (D) as described in the Study Protocol). 

HumanStudySubject

A StudySubject who is also a Person.

And then it can follow that: 

EligibleSubject

A HumanStudySubject who satisfies all Study-specific Eligibility Criteria.

Determining Study Eligibility

There is great interest in automating processes to determine eligibility in a study. There are two major use cases that I'm aware of. The first is to assess protocol feasibility and facilitate recruitment into trials. In this case, one would like to query multiple EHR sources to identify potentially eligible subjects. The second use case is during study conduct. During the screening phase, data are collected and used to perform an eligibility analysis. The eligibility rules form the analysis plan for the eligibility analysis, the result of which is a binary outcome: true (eligible) or false (not eligible).  Those who pass continue on to experimental treatment. Automating this analysis would facilitate enrollment and decrease the risk of both false positive and false negative enrollment errors.

Modeling eligibility criteria using RDF is the subject of a project within the PhUSE Semantic Technologies Working Group. I encourage interested individuals to participate in those regular calls to help refine and test our approach. We could use more help. In a previous post, I discussed how using the owl:restriction class can be used to determine eligibility, but it turns out this supports only the simplest criteria. OWL 2 introduces property chains, and we were able to model a few more criteria, but not enough. Here I describe a much more powerful strategy: using SPARQL Inference Notation (SPIN). I credit my colleague Ron Katriel for suggesting we use SPIN. I am now busily soaking up everything I can learn about SPIN. It is quite powerful.

The diagram below illustrated the classic subClass relationship between a Subject and an EligibleSubject. The challenge before the working group is: how does one automate determining which members of the superclass Subject belong in the subClass EligibleSubject using RDF?

Without getting into the details of SPIN, it is possible to write eligibility rules using SPARQL, the query language of the semantic web, and embed them into RDF triples so that the computable eligibility rules exist with the data and can be used to identify eligible subjects.

In the PhUSE working group, we are taking an imaginary study ABCD. It has the following eligibility criteria:
Subject must be female.
Subject must have Diabetes Mellitus for at least 2 years.
Subject must have a positive Hepatitis B Surface Antigen (HBSAg) test
Subject must have a negative RPR test for syphilis.
Subject must have a systolic blood pressure of less than or equal to 140 mmHg.

First we created a simple study ontology to relate subjects with the study and its activities (in this case subject observations). Then we populated it with dummy data for 5 subjects. Then we wrote SPARQL queries for each criterion. This allows us to define a subClass of subjects that meet a criterion ("EligibilityCriterionSubject").
The query to define the subClass of Subjects that have systolic BP <= 140 mgHg looks like this:

CONSTRUCT {

    ?this a ec2:SBPLTE140Subject .

}

WHERE {

    ?this a ec2:Subject_ABCD .

    ?q a ec2:SystolicBP .

    ?r a ec2:SystolicBPOutcome .

    ?this ec2:undergoes ?q .

    ?q ec2:hasOutcome ?r .

    ?r ec2:hasValue ?v .

    FILTER (?v <= 140) .
}

The query to define the subClass of Subjects with Diabetes Mellitus for at least 2 years looks like this:

CONSTRUCT {

    ?this a ec2:DiabetesMellitus2YRSubject .

}

WHERE {

    ?this a ec2:Subject_ABCD .

    ?q a ec2:DiabetesMellitus .

    ?q ec2:medConditionInterval ?r .

    ?r time:hasBeginning ?s .

    ?s time:inXSDDateTime ?dmstart .

    ?this ec2:hasPersonMedicalCondition ?q .

    ?this ec2:studyInterval ?t .

    ?t time:hasBeginning ?u .

    ?u time:inXSDDateTime ?sstart .

    BIND (smf:duration("y", ?dmstart, ?sstart) AS ?dmdur) .

    FILTER (xsd:integer(?dmdur) >= 2) .

}

Each query is embedded in an RDF triple of the form:

:Subject_ABCD spin:rule "query" . 

The class of EligibleSubjects for Study ABCD is defined as the owl:intersection of the individual classes for each of the EligibilityCriterionClass. 

When you run inferences using a standard semantic web tool (we are using TopBraidComposer), the system correctly identifies 3 subjects with a positive HepB antigen test, 3 subjects with Diabetes Mellitus (two of which have had the diagnosis >2 yrs, and so forth. The intersection of all these classes results in only one subject (Subject0001) that is a member of all the individual EligibilityCriterionSubject sub-classes and is therefore a member of the EligibleSubject class for that study. 

Since the query is expressed in SPARQL, the ability to perform a distributed query across multiple data sources is straightforward, at least in theory. Of course the data being queried should be in RDF, although I understand there is a way to convert SPARQL to SQL to query local databases. 

We're still working on the ontology for this imaginary study, and plan to add more complex eligibility criteria in the future. For example, we want to add additional timing variables to support rules such as: Subject must have a Systolic BP <=140 measured during the two week screening period.

Please email me or leave a comment below if you wish to see the most current working copy of the study ontology/knowledgebase. It is evolving quickly. 

Managing Study Workflow using RDF

In a previous post, I discussed the owl:Restriction class and how it can be used to define and identify eligible subjects in a study. Here I illustrate other uses of this class to help manage the study workflow.

A computable, or machine-readable and interpretable study protocol is fundamental to automating processes to collect and analyze study data. A computable protocol provides sufficient detail for information systems to determine what is supposed to happen and help identify gaps in protocol execution. It would enhance protocol compliance and enable automation of analyses that look for protocol violations and their impact on the objectives. 

At its core, a study protocol is a collection of activities to be performed on study subjects. It describes what data are collected, and the rules that determine when those activities occur. Current standards fall short in representing this workflow in a computable format. I explore here a possible solution using RDF and OWL. I must emphasize I am not an RDF expert so the discussion is by its nature at a high level. The details are my best attempt to describe how it might work. I hope that experts in semantic web technologies will read and comment on this proposed solution, and weigh in on the possible benefits of this approach. You will see slightly different uses of the owl:Restriction class that I discussed previously. 

The proposed approach is straightforward. If you think of a protocol as a collection of activities, each activity has a rule determining when it can begin. The system must be able to identify which activity is "next" and inform the site what to do next. The system must also have the ability to document digitally when an activity ends (i.e. when the activity is considered complete). Each activity has a unique ID so that it can reference other activities. In RDF this is the URI (uniform resource identifier). So a start rule can say Start B when A is complete and StudyDay is 12-17. There will always be one activity with no start rule, so that's the one the system presents first for execution. As activities are marked complete, the next activity is enabled for execution, and so on. Now for each subject, you throw all of these activities and their associated rules in a bowl and pick out individual activities until you find which one you do next. Computers are great at doing this sort of thing quickly. You repeat until all activities that were supposed to be done are completed. Then the study is over for that subject. The grouping of activities into arms, epochs, elements, etc. for any given subject for analysis purposes can all be derived.

My idea to use RDF to represent this workflow emerged while reading the book “Semantic Web for the Working Ontologist,” (excellent book, by the way. I highly recommend it) I came across an example in Chapter 11 on Basic OWL that describe how to model Questions and Answers in OWL (you'll find it on page 222). As I read it, a light went off. In reality I had to read it several times to fully understand it.  I thought, this example is entirely relevant to clinical trials. The exercise describes a group of questions (activities) that are asked generally in sequence, but some questions are asked only when other questions are completed and answered in a certain way. That is, some questions have prerequisites before the system can ask them. So there are concepts for a Question, an Answered Question, an Enabled Question (ready to be asked by the system). Only when a particular answer is obtained and documented does another question become an Enabled Question. 

So how does this apply to clinical trials? Here's how it might work. Let's review a few common study activities.

• Obtain informed consent
• Collect screening clinical observations
• Determine eligibility
• Allocate to Treatment (Drug or Placebo)
• Administer Treatment (Drug)
• Collect a treatment-related clinical observation on Study Day 14. 

Most rules can typically be expressed as conditional (if… then…) statements, e.g. IF informed consent is signed THEN conduct screening activities. Some activities do not have start rules. For example “obtain informed consent” has no start rule. This activity is performed by default at the start of most studies. Some activities depend on the study day or is triggered by the occurrence of another activity. IF StudyDay = 7 THEN perform a complete blood count. IF <headache occurs> THEN <administer study drug>. Some activities are unplanned and also have no start rules (e.g. unplanned clinical observations in response to an unexpected change in the patient’s medical condition). These are added as the study progresses. Activities can also be grouped and nested. Rules to determine eligibility are in effect rules on whether to start the Allocation activity, since only eligible subjects are allocated to experimental treatment.

The basic structure of study activities can be represented by classes and properties in OWL. The basic schema for the study activities is as follows. Throughout this example I use the namespace s: to refer to elements (classes, properties) that relate to an ontology of a study, and the namespace t: to refer to the elements of the particular example study used here (i.e. instance data).  A particular study will have Study Activities and Study Activity Outcomes.  A StudyActivity is considered completed when an Outcome is documented in the system. An outcome could be "unable to complete" if the subject is lost to follow-up, for example. 

First, we establish the StudyActivity and StudyActivityOutcome as OWL classes.

s:StudyActivity a owl:Class.

s:StudyActivityOutcome a owl:Class.

Typical activities and possible outcomes are the following:

Activity                                                         ActivityOutcome

Informed Consent                                       InformedConsentSigned

Screening                                                    Sub-activities completed

     Hemoglobin                                           14.0 mg/dL

     Hematocrit                                             42%

     Platelet Count                                        300K /cm3

     Fasting Blood Glucose                          102 mg/dL

     Eligibility Assessment                           True (i.e. Eligible Subject)

Randomization                                           Placebo

Substance Administration                          Placebo one daily for 3 months

Before a StudyActivity is performed, the Outcome might be one of several outcome options. We therefore define a class called StudyActivityOutcomeOption as a subclass of StudyActivityOutcome. We define a property called s:hasOption as follows. It describes the list of possible outcomes relevant to that activity. For observations, it defines the value set. 

s:hasOption a owl:ObjectProperty;

           rdfs:domain s:StudyActivity;

           rdfs:range s:StudyActivityOutcomeOption.

When a StudyActivity is complete it has a documented outcome, which is a subclass of StudyActivityOutcomeOption. Another way of saying it is the selected outcome is a subset of the outcome options. So we define a class called StudyActivitySelectedOutcome. We also define a property called s:hasOutcome. If an StudyActivity has a documented outcome, it's considered a CompletedStudyActivity, a subclass of StudyActivity. The RDF looks like this:

s:StudyActivitySelectedOutcome rdfs:subClassOf s:StudyActivityOutcomeOption.
s:CompletedStudyActivity a owl:Class.
s:CompletedStudyActivity rdfs:subClassOf s:StudyActivity.

s:hasOutcome a owl:ObjectProperty;

           rdfs:domain s:CompletedStudyActivity;

           rdfs:range s:StudyActivitySelectedOutcome.

I think s:hasOutcome is a subproperty of s:hasOption. (I defer discussion of sub properties here, but in reviewing the definition of sub properties, I think this is true). 

Because certain activities cannot begin until other activities are complete, we need the concept of a CompletedStudyActivity. This is a subclass of StudyActivity:

One way a study activity is complete (i.e. is a CompletedStudyActivity) is if it has a documented s:StudyActivityOutcome through the :hasOutcome property.  That is it's any StudyActivity that has a triple in the database of the form :StudyActivity :hasOutcome :StudyActivityOption.  Given the meaning of rdfs:domain and rdfs:range for the :hasOutcome property, this makes the study activity a completed study activity and the study activity option a study activity selected outcome. 

A StudyActivity can have one or more subactivities, which themselves are each a StudyActivity. So we define a class called SubActivity as a subclass of StudyActivity, and we define a property called s:hasSubActivity as follows:

s:hasSubActivity a owl:ObjectProperty;

           rdfs:domain s:StudyActivity;

           rdfs:range s:SubActivity.

Any StudyActivity that is a range of the s:hasSubActivity property is automatically a SubActivity.

Another way a StudyActivity is complete is if all of its SubActivities are complete. This can be expressed as a restriction on the values that the s:hasSubActivity property can have: 

s:CompletedStudyActivity owl:equivalentClass [a owl:Restriction;
                 owl:onProperty s:hasSubActivity;
                 owl:allValuesFrom s:CompletedStudyActivity].

I think the use of an allValues owl Restriction here means that a StudyActivity is a CompletedStudyActivity if all of its SubActivities are only CompletedStudyActivities.

Those activities that cannot begin until other activities are complete are described to have Prerequisites. We therefore define a new property called :hasPrerequisite:

s:hasPrerequisite a owl:ObjectProperty;

            rdfs:domain s:StudyActivity;

            rdfs:range s:StudyActivityOutcomeOption.

It's important to define the prerequisite as an outcome option (and not the activity itself) to allow branching. Depending on the selected outcome, different activities may subsequently be enabled for a particular subject.

Any StudyActivity for which all of its prerequisite activities have been completed (ie. have only associated StudyActivitySelectedOutcome(s)) becomes an EnabledStudyActivity. These are the activities that are performed next in a study. EnabledStudyActivity is defined as an owl restriction class on the property :hasPrerequisite.

s:EnabledStudyActivity a owl:Class.

s:EnabledStudyActivity owl:subclassOf s:StudyActivity.

s:EnabledStudyActivity owl:equivalentClass [a owl:Restriction;

           owl:onProperty s:hasPrerequisite;

           owl:allValuesFrom s:StudyActivitySelectedOutcome].

(note lines 2&3 have been corrected since the original posting to address a reader comment)

I think this means that a StudyActivity is an EnabledStudyActivity if all of its prerequisites have documented only StudyActivitySelectedOutcome(s) (i.e. all values for the hasPrerequisite property, wherever it's used, comes from the Study Activity Selected Outcome class.

So let's look at some instance activities for any given subject in my hypothetical study.

• Obtain informed consent
• Collect screening clinical observations
• Determine eligibility
• Allocate to Drug Treatment
• Administer Drug Treatment
• Collect a treatment-related clinical observation on Study Day 14. 

The very first activity, informed consent, has no prerequisites. This can be represented in the systems as the following:

t:InformedConsent a s:StudyActivity.

t:InformedConsent a [a owl:Restriction;

           owl:onProperty s:hasPrerequisite;

           owl:cardinality 0].

It basically says that the InformedConsent activity has no prerequisites. For reasons I don't fully understand, the definition of an EnabledStudyActivity (which is defined using an owl:allValuesFrom restriction) will include the InformedConsent activity because of the way the allValuesFrom restriction is evaluated for empty sets. So the system determines InformedConsent is Enabled and surfaces it in the system for action.

Once the appropriate triple is entered in the database saying that the activity is completed, i.e.,

t:InformedConsentX s:hasOutcome t:InformedConsentSigned.

the system infers it is a CompletedStudyActivity.

Meanwhile, the t:Screening activity has a Prerequisite in the system of a t:InformedConsentSigned activity outcome. As soon as the system detects that the informed consent was signed, t:Screening now infers it is an EnabledActivity and is presented to the study team for action.

Now t:Screening has multiple sub-activities as documented in the database using the s:hasSubActivity property. When every sub-activity has documented triples entered in the database in the form :subactivityX s:hasOutcome t:selected-outcomeX, the system infers that t:Screening is a CompletedStudyActivity.

Now here's one piece I haven't yet figured out. The system needs to automatically generate and enter a triple in the database stating that the screening activity hasOutcome a selected outcome. This is necessary to enable the next study activity: determine eligibility. I welcome any ideas on how to do this.

In summary, it seems possible to use OWL to model an executable study workflow. I would appreciate comments from OWL experts on whether this approach would work. I think it would be informative to get this ontology documented and working using dummy instance data. However, I find the logic rather complex and I honestly am not sure if I have it right. It may very well need substantial modification, but the overall strategy makes sense to me. I'd also like to figure out how to weave in study days in the workflow, as many activities depend on the study day. I welcome thoughts on this issue.