2016-09-17

Rethinking the Three CDISC General Observation Classes

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 a previous post, I discussed 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 an individual. 
    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).

    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

          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.








          2016-05-18

          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.  




          2016-03-16

          Distinguishing Clinical Observations and Medical Conditions

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

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

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

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

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

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

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

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

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

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

          2016-03-02

          Study Data Exchange: The Unsustainable Path

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

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

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


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


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


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

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


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

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


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

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

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