On Capturing Information about Medical Conditions

In today's post, I discuss Medical Conditions in some detail, with a focus on an important question: how do we best capture information about medical conditions as they evolve over time? This is an important question because understanding how medical conditions change over time is key to understanding how medical interventions affect those conditions. As usual, I focus on subject level clinical data collected in clinical trials but I think this is equally valid for other use cases.

I define a Medical Condition as a disease, injury, disorder, or transient physiologic state that interferes or may interfere with well-being. A medical condition persists in time. Medical conditions also evolve over time. The practice of medicine focuses on minimizing the impact of medical conditions to one's health. 

So how do we best document the evolution of medical conditions over time? My thinking on this topic is heavily influenced by a very useful paper, which I encourage you to read. It's titled "Toward an Ontological Treatment of Disease and Diagnosis," by Richard H. Scheuermann, Ph.D., et. al. It provides precise definitions for common terms such as a Disorder, Pathological Process, Disease, etc. This precision the authors argue is important to enable automated analysis and reasoning across aggregated clinical data from multiple sources. 

Their definition of Disease is: A disposition to undergo pathological processes that exists in an organism because of one ore more disorders in that organism. A disorder in turn is something that is wrong with the body and is associated with a pathological process. For example, Epilepsy is a disease that disposes the individual to recurrent seizures (disorder/pathological process). As another example, consider Systemic Lupus Erythematosis, a disease that disposes the individual to multi-organ autoimmune damage that may be manifested by multiple disorders: dermatitis, arthritis, pericarditis, nephritis, etc. One has to understand the underlying disorders in order to fully understand the disease. 

Notice that my definition of a medical condition includes both diseases and disorders, because sometimes one doesn't know the disease, rather just the disorder that is manifest, but it's useful to draw that distinction when one can. Understanding the disease can help select the best treatment for the underlying disorder. For example, the disorder may be a bone fracture from an injury, but additional observations may disclose the disease Osteoporosis, which would affect the treatment plan.  

So the clinical data flow in my mind goes something like this:  clinical observations give rise to an assessment to identify/characterize one or more disorders, which may enable the identification of a disease. 

One begins to see how to organize the data for maximal use downstream. Clinical observations are grouped together during an assessment to identify and categorize a disorder and possibly a disease. Both disorders and diseases are events that persist in time, so each is associated with a start and end date. Each also has a diagnosis date, i.e. the date an assessment first identified the condition. Severity is an observation that can be associated with both disorders and diseases, and that changes over time. 

What are the implications for the SDTM? In a previous post I argue for a single Medical Condition domain that describes each medical condition, past and present, for each subject. Each record is a medical condition (e.g. a disease or disorder) and has standard attributes such as start date, end date, diagnosis date, etc. One needs to group and link all the disorders that pertain to a given disease. So for schizophrenia, one would list all the known psychotic episodes for that subject and link them to the schizophrenia disease record. Same thing with Multiple Sclerosis. The M.S. record would link to all the known relapses (disorders). There would also be links to the observations that were used to characterize the disorder, and an optional link to the assessment (i.e. adjudication) record that contains details of that assessment. Each disease/disorder should have standard outcome measures (clinical observations) and validated methods to observe and document severity at given points in time. For example, Parkinson's Disease has the UPDRS (Unified Parkinson's Disease Rating Scale). Diabetes has the Hemoglobin A1C and others. Once again we need universal resource identifiers (URI's) to facilitate linking all these data. 

What we have now is the ability to plot all of a subject's clinical observations in a clinical trial over time, i.e. the patient profile. But this lacks important information in how assessments were performed to link observations to disorders and diseases to assess changes to the disease over time. When one looks at the various Therapeutic Area User Guides each takes a different approach in documenting changes to medical conditions over time. This proposed single approach I think is applicable for all therapeutic areas. Once we have a clear, standard representation of the changes to a medical condition over time, then I think it will be easier to automate analyses that look at the effects of various interventions, including experimental interventions of course. 

As usual, I welcome your comments. 

Definition of Common Clinical Terms v2

Back in May I proposed some working definitions of common clinical terms. Since then additional thinking and feedback has led to some refinements. I'm reposting and cross-referencing the two versions. The changes are highlighted in bold and red. 

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. enabling 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 a Person or individual. (Synonym=finding)

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 individual to whom the observation belongs (e.g. pain). Synonym: Subjective Observation

1(b). Sign: a Clinical Observation that can be observed by someone other than the individual (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. The former is a clinical concept (what's measured by the clinician), the latter is an analysis concept (what's plugged into a formula. 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, disorder, or transient physiologic state that interferes or may interfere with well-being. A medical condition persists in time. 

Medical conditions are the target of medical interventions.  Medical conditions explain the presence of 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: An adverse Medical Condition that emerges or worsens following a Medical Intervention. Note: there is no presumption of causality. (Some medical conditions may not be considered adverse; see the Pregnancy discussion below.)

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: An Adverse Event temporally associated with a specific Medical Intervention. It assumes that some algorithm or rule is defined to establish the temporal association.

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. 

Pregnancy deserves special mention. Is it a medical condition? The definition of medical condition has been expanded to include pregnancy by adding the language "transient physiologic state." I think most clinicians will agree that pregnancy is a medical condition because it benefits from medical intervention (e.g. prenatal care) to minimize complications to the mother and unborn child. Is pregnancy an adverse event in a trial? It depends on whether it's considered "adverse" as in unexpected and undesired. That is a judgment call made by the assessor. 

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.

Rethinking the Three CDISC General Observation Classes

*Please note this post has been updated to reflect updates to some clinical definitions referenced in this post. The links have been updated as well. These do not change the overall message and conclusions. 

The CDISC Study Data Tabulation Model (SDTM) is now on version 1.4 with future versions already in design to accommodate data for additional therapeutic area requirements. As these data from more and more therapeutic areas are standardized, I see an almost endless cycle of new variables, new domains, version upgrades and their associated implementation costs and challenges. I think it is worth exploring improvements to the model so that new requirements could be incorporated more easily, perhaps as easily as adding new terms to dictionaries and decreasing the need for changes to the model or for nonstandard variables. But what does that improved model look like? Here are some thoughts. I certainly welcome comments.

First let's look at where we are today. The SDTM has been quite consistent over time in defining three general observation classes in clinical studies: Interventions, Findings, and Events. Here is how they are described in SDTM 1.4:

• The Interventions class ... captures investigational, therapeutic and other treatments that are administered to the subject (with some actual or expected physiological effect) either as specified by the study protocol (e.g., “exposure”), coincident with the study assessment period (e.g., “concomitant medications”), or other substances self-administered by the subject (such as alcohol, tobacco, or caffeine). 

• The Events class ... captures planned protocol milestones such as randomization and study completion, and occurrences, conditions, or incidents independent of planned study evaluations occurring during the trial (e.g., adverse events) or prior to the trial (e.g., medical history). 

• The Findings class ... captures the observations resulting from planned evaluations to address specific tests or questions such as laboratory tests, ECG testing, and questions listed on questionnaires. The Findings class also includes a sub-type “Findings About” which is used to record findings related to observations in the Interventions or Events class. 

It turns out these definitions do not completely align with the way clinicians generally think about observations. Furthermore, this categorization does not follow well-established conventions for documenting, storing, and using clinical data in practice. I think it is useful to re-examine these concepts, because I believe it leads to a better and more useful data model.

In another post, I discuss definitions of common clinical terms. Here are two I'd like to revisit. 

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

Medical Condition:  a disease, injury, disorder, or transient physiologic state that interferes or may interfere with well-being. A medical condition persists in time. 

How do these definitions work? Health care processes focus on identifying Medical Conditions that afflict patients. Once the Medical Condition is identified, one can then determine how best to deal with it. Sadly, patients don't walk into a clinic or hospital with a sign on their forehead saying "I have Multiple Sclerosis." The clinician acts as a detective, documenting clues that can lead to the correct diagnosis. Those clues are clinical observations. The clues must be put together, like a jigsaw puzzle, to determine the most likely diagnosis (i.e. medical condition) that afflicts the patient. This in turn determines the plan (interventions) to make the patient better or keep them from getting sick. 

This process gives rise to the clinical data lifecycle that in turn, and over many decades, is routinely documented in patient records. It goes by the mnemonic SOAP. Here are the SOAP components:

Subjective observations - what are the observations that the patient reports?

Objective observations - what are the observations that the clinician observes (which may include the use of tools, such as a BP cuff, ophthalmoscope, laboratory diagnostic device, imaging device)

Assessment - what medical condition is mostly likely associated with the observations? What are important attributes of the medical condition, such as severity, measured at the time the assessment is made?

Plan - how should the medical condition be treated? This usually involves some interventions (drug administration, surgery, device implantation etc.)

If one applies the working definition of a clinical observation to the CDISC general observation classes, only the Findings class fits as a true clinical observation that would typically be documented in the "O" section of a SOAP note in a patient's record. 

Let's now look at Interventions. The word Intervention comes from the verb to intervene, which is defined by Merriam Webster Dictionary as "to become involved in something ... in order to have an influence on what happens."As it is commonly used in health care, an intervention is some activity that intends to change or alter or affect in some way a Medical Condition. Usually the intent is to treat, but other purposes of Interventions can be to prevent, cure, diagnose, or mitigate. Examples of Interventions include a drug administration, surgery, or device implantation. 

It turns out that observations and interventions are very similar from a process perspective. Both have a performer, are associated with some process for carrying out the activity, both may involve one or more devices, and both may involve collecting and analyzing a biospecimen. Observation and Intervention records therefore need to link to information about these other classes as needed. In fact an observation is a type of intervention because the observation wouldn't occur unless the observer takes some intervening action. From a modeling perspective, it makes sense to treat observations as interventions. They are distinguished by the purpose or intent of the intervention: affect/identify a disease vs. observing the state of an individual. 

So what about CDISC Events? Except for certain administrative events in the SDTM, events are in fact Medical Conditions. Think of Medical History (MH) data: Hypertension, Diabetes Mellitus, Hypothyroidism. All medical conditions. Think of events that go in the Clinical Events (CE) domain or the Adverse Events (AE) domain, all Medical Conditions (or at least they should be. Sometimes in practice, an observation about an event is confused with the event itself. More on this later.)

Medical Conditions all share common attributes: They persist in time, i.e. they have a start date and an end date (which is null if the condition is ongoing or its status is unknown). For practical reasons, the start date would be the date of the first clinical observation associated with the condition, although in reality the pathophysiology is usually well underway by the time the first symptom or sign appears. It also has a diagnosis date, which corresponds with the date the assessment was completed that first identified the medical condition. This can be much later than the start date. 

Let's look at adverse events briefly. An AE is a medical condition that is temporally associated with an Intervention. It is identified after an assessment of one or more clinical observations. The assessor concludes that a medical condition is present. It is not an observation! In reality, the assessment is not often documented so many people don't think of it. When the onset of an AE is critical information, e.g. renal graft failure following transplant, then a formal adjudication process may exist to ensure the right clinical observations were collected and the correct diagnostic criteria were applied during the assessment to conclude that renal graft failure has occurred.

In other cases, an observation about an AE is mistaken for the AE itself. Take the example of "hyponatremia." This is a clinical disorder characterized by low serum sodium, normal serum osmolality, and possibly a constellation of other clinical observations, such as change in mental status, seizures etc. Does a low serum sodium (observation) mean the patient has hyponatremia (the medical condition)? Maybe, maybe not. It requires an assessment by a qualified assessor to determine that association. Maybe the serum osmolality was abnormal; maybe it's lab error. One doesn't always need details of the assessment, but sometimes it's important.

Our high level concept maps looks like this:

Now we're starting to see a picture of what new and improved SDTM domains look like. These were discussed in a previous post. 

1. Medical Condition domain...can contain everything you may want to know about the medical conditions that afflicts the subject, e.g. start date, link to the observation record considered the first sign/symptom of the condition, date of diagnosis (with a link to the assessment record that led to the diagnosis), severity, toxicity grade, seriousness, end date, etc. Because medical conditions commonly fluctuate in severity or toxicity over time, a severity or toxicity rating is typically the severity or toxicity measured at the time the assessment is made. It is a finding about the medical condition.   
2. Assessment Domain: can contain everything you may want to know about an assessment, date of the assessment, assessor (link to qualifications), observations used for the assessment, link to diagnostic criteria used for the assessment, link to the rating scale used, link to the outcome of the assessment, i.e. medical condition record.
3. New and improved Interventions domain containing everything you may want to know about the intervention: date performed, purpose of the intervention (observe; affect), performer (link to qualifications), device used (link to device info); procedure/process done (link to procedure info); biospecimen collected and/or analyzed (link to biosopecimen information), observation result (if observation). 
4. Every medical condition is associated with a Plan (i.e. care plan). One can consider a Planned Interventions domain where each record is linked to the Medical Condition for which the planned intervention is intended. There should be an ability to link from the planned intervention to the actual intervention record(s). 

There are lots of links across these new domains. These would be facilitated by having unique resource identifiers for each record in each new domain. 

If enough attributes are present for each suggested new domain, I hypothesize that new clinical data requirements can be more easily met using this model. As a next step, I would like to create some domains based on dummy data and explore what adding new data requirements might look like.

Thank you for reading and for your comments. 

Deciding When to Change the SDTM

I frequently come across proposals to change or upgrade the SDTM. Experience has shown that changes to the SDTM are a big deal. Even minor changes cause a ripple effect that result in substantial resources (e.g. time and money) for stakeholders to implement. It's often years before a change can be fully implemented industry-wide. Often the change results in updates to the model, the implementation guide, the I.G., and significant change management costs, e.g. training, upgrades to information systems and tools and business processes. Here we are well into the 2nd decade of the SDTM lifecycle and what the industry needs most is stability in the standard. We need to be creative in incorporating new requirements that do not change the standard and avoid those that are not absolutely necessary. Or we need to take a critical look at the underlying model and make major changes (SDTM 2.0?) that hopefully will result in a more stable standard (see my previous post). We recognize that some change is inevitable, but change that can be accomplished through other means should be pursued. Stakeholders need a stable standard.

So here I propose an approach to limit certain types of changes. But first, I discuss fundamental principles about exchange and analysis standards. These principles explain the reasoning behind my suggested approach.

First of all, let's consider what is an exchange standard vs. an analysis standard? Here are some working definitions:

Exchange Standard

• A standard way of exchanging data between computer systems.  It describes the information classes/attributes/variables/data elements, and relationships necessary to achieve the unambiguous exchange of information between different information systems (interoperability).

Analysis Standard

• A standard presentation of the data intended to support analysis. It includes extraction, transformation, and derivations of the exchanged data.

Exchange standards exist to support interoperability. Here I use the HIMSS definition: "The ability of different information technology systems and software applications to communicate, exchange data, and use the information that has been exchanged.

Exchange and analysis standards meet very specific and different needs:

• A good exchange standard promotes machine readability, understandability, and business process automation at the expense of end user (human) readability
• A good analysis standard promotes human readability and use/analysis of the data using analysis tools. It maintains strict traceability with the exchanged data

As an analogy, consider data as pieces of furniture. The exchange standard is the truck that moves the furniture from point A to point B. The size and configuration of the truck is dependent on the contents. The furniture is packed in a way so it can be moved efficiently. It cannot readily be used in its packed environment. The analysis standard describes how to organize the furniture at its destination to maximize its usefulness. For example, a dining room table goes in the dining room. A desk goes in the den, etc. Furniture may need to be assembled (i.e. transformed) from its packed state to its useful state. 

Because of the different use case associated with each type of standard, it comes as no surprise that the individual requirements are very different. Often they are competing or contradictory. Here are some examples: 

Exchange Standard	Analysis Standard
No duplication of data/records (minimize errors, minimize file size)	Duplicate data (e.g. demographics and treatment assignment in each dataset)
No derived data (minimize errors, avoid data inconsistencies, promote data integrity)	Derived data (facilitate analysis)
Very standard structure (highly normalized, facilitate data validation and storage)	Variable structure to fit the analysis
Numeric codes for coded terms (machine readable, facilitate data validation)	No numeric codes (human understandable)
Multi-dimensional (to facilitate creation of relational databases and reports of interest)	Two-dimensional  (tabular) containing only relationships of interest for specific analysis (easier for analysis tools)
Standard character date fields (ISO 8601: ensures all information systems can understand them)	Numeric date fields (facilitates date calculations, intervals, time-to-event analyses)

So where does the SDTM fall? It was originally designed as an exchange standard for study data submissions and certainly that is its main purpose currently. However, because similar data from multiple subjects exist together into domains make them suitable for simple analyses as well. In fact, FDA reviewers have been performing simple analyses using SDTM datasets for years. More recently, the FDA has developed standard analysis panels that use native SDTM datasets as input. So the answer is: SDTM is both an exchange standard and an analysis standard (for simple, standard analyses; ADaM data are used for complex and study-specific analyses)

Here is the important observation from the above discussion. Since the requirements are different for exchange and analysis, SDTM is being pulled in two directions, and cannot perform either role optimally. We must choose which role is more important. How often have we heard the discussion: should SDTM have derived data? Well, it depends what use case you think is more important. As an analysis standard, of course it should have derived data. As an exchange standard, this is generally not a good idea. 

In an ideal world, the SDTM as an exchange standard would be retired and replaced by a next generation exchange standard that is based on a more robust relational data model that strictly meets data exchange requirements (e.g. BRIDG+XML, HL7 FHIR, RDF/OWL). The data would come in, it would be loaded and stored in a data warehouse, and tools transform the data into useful, manageable chunks for the analysts. This future state would free the existing SDTM to take on more analysis/end-user friendly features (e.g. non-standard variables in parent domains, numeric dates, demographic/treatment arm information in each domain), but these enhanced SDTM views would be generated by tooling. 

The reality is we do not live in an ideal world and SDTM as an exchange standard is here to stay for the foreseeable future. Therefore, for the foreseeable future, changes to the SDTM should stress data management requirements. Changes to make SDTM more end-user friendly for analysis should be resisted as they invariably will make data exchange more complicated and costly. Requirements to make SDTM data more user-friendly should be handled by better tooling by the recipient to facilitate post-submission data transformations needed for analysis. Going back to the furniture analogy, it's not efficient to ship the dining table and chairs in the exact arrangement they will be used at the destination; rather, we need more and better furniture unpackers at its destination. 

So, I propose the following algorithm to evaluate proposed structural changes to the SDTM (i.e. those that do not add new content). As always, I welcome your thoughts.

Five Reasons to use the RDF for Study Data

The currently supported file format to exchange clinical trial data with the FDA is the SAS Transport version 5. It is generally well recognized that this format is obsolete and should be replaced with a more modern format. There is one effort underway to identify a new format. This post makes a case for considering the Resource Description Framework (RDF) for representing and exchanging study data. I have been learning quite a bit about the RDF for the past several years. Although I am not an expert, I've been able to appreciate the benefits RDF offers over other potential solutions.

The RDF provides a general approach for describing data of any kind. It is the foundation of the "semantic web." Multiple serialization formats exist for the RDF, including RDF/XML, turtle, and JSON-LD. Numerous freely available converters exist on the Web. Just do a Google search for "RDF format converter."

When I say RDF, I actually mean a suite of related standards that "play nicely together" and exist to ensure the meaning or semantics exist and travel with the data. These include the RDF, OWL (Web Ontology Language), SPARQL (the query language of the semantic web), and SPIN (SPARQL inference notation).

So why use the RDF? There are several considerations to keep in mind. First, I'd like to point out the Yosemite Project. It is an effort to improve semantic interoperability of all structured healthcare information by using the RDF. It provides numerous compelling arguments in favor of the RDF. Then there is a lot of activity exploring the use of the RDF in the biomedical information space. For example, there is existing work in expressing CDISC standards in the RDF. There is an ongoing effort to develop an RDF representation of HL7 FHIR. There are numerous other efforts to express other standards, such as MedDRA, SNOMED CT and other terminologies using the RDF.

It is worth mentioning that it is not absolutely necessary that data be exchanged using the RDF. Other standards may be acceptable as long as they have an unambiguous representation in the RDF and can be easily converted to/from RDF. This helps ensure a level of semantic clarity that is often lacking in existing standards due to unrecognized ambiguous definitions or naming of concepts. In a previous post, I describe best practices for defining concepts in a way that facilitate an unambiguous RDF/OWL representation. Converting to an RDF representation (particularly OWL), in my experience, tends to surface semantic ambiguities that previously may have gone unrecognized and impede semantically interoperable data exchange.

Here are the five reasons.

Reason #1. As the industry considers retiring the current exchange format, any new format should be capable of accommodating new content requirements easily while maintaining backwards compatibility as much as possible. Switching to a new format is going to be costly, so it's important to pick one that is useful over the long haul. Tools must be modified to be able to read and write data using the new format. The standard must be robust to accommodate current requirements and flexible enough to accommodate new requirements easily as they emerge, as change is inevitable. The RDF is capable of supporting this. Ontologies and vocabularies may need updating, but the underlying tools that interact with the updated ontologies don't change, because the underlying standard, the RDF, is the same. This is extremely powerful. Incorporating new content requirements has turned out to be a major roadblock in implementing existing standards. I would argue that this reason alone is the major reason for testing and transitioning to the RDF for study data exchange.

Reason #2. Standardizing study data often requires mapping data that exist in legacy formats. The RDF provides powerful mapping capabilities, using standard predicates (i.e. relationships between variables and data points) such as owl:equivalentClass and owl:sameAs. One can also leverage other existing ontologies such as SKOS (Simple Knowledge Organization System). By entering a single RDF triple in a database, one can assert an existing variable as equivalent to standard variable and the mapping is essentially complete from a computational standpoint.

Reason #3. Standardizing study data requires implementing not just a single standard, but a suite of exchange, terminology, and analysis standards. One needs to link all these standards together in a web of data and metadata. For example, a variable from Exchange Standard A has permissible terms from Terminology B. All of these are currently documented using various formats across various sources. Integrating all the necessary standards for implementation is very labor intensive, particularly as each standard evolves and different versions emerge. All the necessary standards can be expressed in the RDF, which is uniquely designed to link data across multiple sources.  One can link multiple standards in one single ontology, which is published and maintained on the web as a resource. This would greatly simplify implementation and maintenance.

Reason #4. The RDF (and related standards) can be used to represent not only the study data, but the metadata, including definitions for derived data, the validation rules, and even the analysis plan. Any kind of information can be represented using RDF and this enables computers to link everything together for easy access and analysis. FDA guidances, regulations, and statutes can be expressed in the RDF. Why is this useful? If study data are expressed in the RDF, one can link to the relevant guidance recommendations expressed in the RDF and computers can help determine if the data are guidance-compliant. For example, an FDA guidance could have a series of RDF triples describing the recommended properties of a nonclinical skin toxicity study. A computer can then compare those recommendations with the actual properties of a study and identify any discrepancies. To my knowledge, no other existing standard is capable of supporting this important use case, which is currently a very time consuming, manual process. It is often very costly when discrepancies are identified too late, after studies are well underway or complete.

Reason #5. Another advantage is that RDF data can reside on the web and be easily accessible, easily queried, and easily combined with other RDF data. Assuming security concerns are appropriately addressed (i.e. proprietary data must reside behind firewalls and accessible only to authorized entities), this supports a future state where data are no longer exchanged, but users are simply provided access to the data on the web. RDF and related standards already support this distributed nature of managing and querying data from multiple sources.

Many of these benefits will take time to realize, but I think it's important to take a long-term perspective. I admit my analysis comes from a novice who has only begun to scratch the surface of the RDF and what it offers. I welcome thoughts from true RDF experts. I strongly encourage those not that familiar with the RDF to learn more about it. I have personally found this resource to be quite useful. There are clearly major technical challenges to overcome, but in my humble opinion, RDF represents the most promising alternative for the future of study data exchange. It would enhance computable semantic interoperability and open a new era in managing and integrating data from multiple sources, which in my view is the key for the next major phase of medical discoveries.

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.