2017-02-17

SDTM Data in RDF: Activities in Clinical Trials

PhUSE has approved a new project to evaluate and demonstrate the potential value of using RDF for SDTM data. It's called SDTM Data as RDF.  The project is headed by Tim Williams and myself and it will kick off at the upcoming PhUSE Computational Science Symposium just outside Washington DC.  As many of you know, I'm an advocate for using the RDF for study data. One of the goals of this new project is to develop a simple Study Ontology that, when combined with study data in RDF, can be used to generate high quality, highly standardized and valid SDTM datasets. If successful, it will address a major ongoing problem: high variability in SDTM implementation across studies and applications. 

To achieve that goal, we will develop a simple study ontology using OWL that will support SDTM dataset creation using standard SPARQL queries. It will leverage existing BRIDG classes as needed. We are starting with two domains: DM and VS and, if successful, the ontology will be extended to support other SDTM domains as well as non-standard data that currently wind up in SUPPQUAL or custom SDTM domains. If successful, the project outcome can provide a compelling reason to use RDF for study data today to solve a major SDTM implementation challenge that sponsors currently face. As the project progresses, I plan to discuss modeling challenges and how RDF/OWL can address them. Today I discuss Activities in clinical trials.   

A clinical trial is at its most fundamental construct a collection of activities and the rules that describe when those activities are performed. There are also rules that describe how those activities are grouped (e.g. into arms, visits, epochs, etc.) to facilitate study conduct and analysis.

Our mini Study Ontology divides study Activities into these subClasses:
  1. Observations -- symptoms, signs, tests, etc. that measure the physical, mental, or physiological state of a subject
  2. Analyses -- activities that take as input one or more Observations and generates analysis results
  3. Interventions -- activities that are performed on a subject with the usual intent of modifying or identifying a medical condition (e.g. drug administration, device implantation, surgery)
  4. Administrative Activities: e.g. informed consent, randomization, etc.
The Analysis class has a couple of interesting subclasses: 
  1. Assessment - this activity analyzes the results of Observations to identify (e.g. diagnose) and/or characterize (e.g. severity assessment) a Medical Condition.
  2. Rule - this activity analyzes the results of Observations to determine the start of another Activity. This includes eligibility criteria, which takes screening data and determines whether the subject advances to the next Activity, usually randomization. It also includes more generic start rules such as "take study medication within two hours of headache onset." 
All Activities have outcomes, so there is a class ActivityOutcome. For Observations, the outcome is the result. For Assessments, the outcome is the identification and characterization of a Medical Condition. Many tests in medicine combine Observation outcomes with Assessment outcomes. For example, consider a CT scan of the head. The Observation might be a 2 cm lesion in the right frontal lobe that enhances with contrast, and has mass effect (obliteration of the sulci and a shift of midline structures). The Assessment, performed by a trained Neuroradiologist, establishes the presence of a cerebral tumor. Additional observations and assessments are then needed to confirm the diagnosis and further characterize the tumor (e.g. Grade 3 Astrocytoma). 

The MedicalCondition class contains all the medical conditions that afflict the Subject (including past conditions). By medical condition I mean a disease (e.g. Epilepsy) or a disorder (e.g. Seizure) or a transient physiologic state that benefits from medical Interventions (e.g. Pregnancy). There are two main subclasses: Indication (the reason an Intervention is performed, such as a Drug Administration), and AdverseEvent (a medical condition that begins or worsens after an Intervention is performed). 

So the "core" study ontology looks like this (class view only):

--Entity
     -- Person
               --HumanStudySubject
--Activity
     --AdministrativeActivity
     --Analysis
          --Assessment
          --Rule
     --Observation
     --Intervention
--ActivityOutcome
--MedicalCondition
     --Indication
     --AdverseEvent

You can imagine a host of properties/predicates that link these together, e.g. HumanStudySubject participatesIn Activity. Activity hasOutcome ActivityOutcome are just two.  

As the PhUSE project advances, we will be testing to see if all study activities will fit in this model. In the meantime, I welcome your comments here but please consider getting involved in the project. We can guarantee all of us will learn a lot and maybe find a better way of implementing the SDTM. And finally, come to the PhUSE CSS if you can! I hope to see you there. 

2016-11-02

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. 

2016-10-18

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.

2016-09-17

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. 



          2016-08-09

          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.






          2016-06-01

          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.



          2016-05-23

          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.