16 comments on “Wear Sunscreen

  1. Thoughtful and appropriately provocative, Dave. For my part, I think we need to go even farther, moving away from the CRF so that all healthcare data can potentially become research data. I’m also a bit wary of depending too much on BC’s — they are only part of the answer (in healthcare as well as research). I’m also not sure we have the right models yet. But I agree that we have to confront our fears to leap ahead. Well stated by a Chicago columnist, Mary Schmich.

    1. Wayne
      Agree re the CRF but one step at a time 🙂 Also agree re the model but I struggle (as I have said to you before) as to the model that we do need, I need some clever people to discuss this with
      Dave

    2. Interesting thought Wayne. I think potentially using all healthcare data in research is feasible, but I also think that one must be very careful about the kind of research. Observational, retrospective, etc. – OK for generating hypotheses, but that’s probably it. As designed, the intended uses of EHR healthcare data generally do not include research, which speaks to quality data being “fit for their intended uses” (IOM). I think healthcare data are the equivalent of spontaneous reports – you get what you get, with all the inherent biases, missing information, and varying definitions. For example, I recently became involved with a vascular access device events registry, and learned that catheter infections may be ID’ed by culture, but sometimes just by symptoms. As hospital-acquired infections are not reimbursable in the US, these may not be entered in the EHR as infections at all, or may be entered as coming from sources other than the catheter. Establishing the incidence of catheter infection becomes impossible, and worse, there is nothing in the data to tell us that. So… it’s a great goal, but we should be careful about what we mean by “research.”

      1. Armando
        I think CIMI has a lot to offer. I have not investigated in depth but I see CIMI model as simple another representation of the BC ‘knowledge’ It would be wonderful if we could ‘export’ into the BC representation. One aspect I would be cautious of is the construction of a BC using BRIDG that may make things slightly more complicated (essentially the aligning / mapping of the CIMI structure to a BC structure). That said, we should look at this.
        Dave

  2. Great article Dave! I mostly agree with you. In ODM 2.0 (which will/should also be the base of the future submission format) we want to introduce a lot of the features of FHIR, especially the references and the web services. In my opinion, ODM and FHIR could be one standard in 10 years or so. Essentially, a FHIR resource (or an “observation” within it) is mostly a BC. We need to look into that.
    But essentially, the BC should be independent of the syntactic format, the latter being only there to transport it. So we could use XML, JSON, RDF, …

    However, as long as the FDA is sticking to two-dimensional tables and SAS-XPT, there is no much hope we can make any real progress at all I am afraid. But we still keep fighting for a better world …

    1. Jozef
      Thanks.
      As I said to you in Vienna, I am not convinced about ODM2.0 yet. This is why I touched on REST & micro services … would CDISC be better defining those such that vendors could implement allowing better tool integration (in effect ODM split into smaller parts rather than one big encompass all). I already have turtle and JSON import/export BCs/Forms/Terminology and it makes me think “smaller is better”. We need to discuss this.

      As for the tabular problem, if we (CDISC) organise well, may be we can work around the tabular structure.

      Dave

  3. I agree on the splitting…
    My own idea is that ODM 2.0 would allow data to reside somewhere else and can just be referenced – probably using (but not limited to) RESTful WS. For example:

    The same could be applied to whole groups of data, complete forms, …
    Maybe the return value can even be a FHIR . Why not?

    But these are just my personal ideas, not synchronized with the team yet.

  4. Comment posted on behalf of Jason Housley (due to tech issues)

    “Excellent piece……as you know, we share the same views, and whether its BCs or not, more precise, solid, consistent, homogenous standards are required as oppose to frameworks. The thought that in 2016 we still go to our CROs and specify ‘how’ we would like to see our acquisition modules, SDTMs, ADaMs, tables and listings fills me with sadness – generating ‘specifications’ fills me with dread. We have created a false industry of ‘transformation’, ‘model design’ and bespoke compliance. The fact is, what domain it fits in, the CAT, SCAT, the codelist, horizontal/vertical etc, matters not – as long as its the same, industry wide, we can focus on the data and the science……Remember the ATM of Clinical Trials? I remember asking the question at an ESUG I was chairing 8 years ago – “Who would object to having a single, out-of-the box, standard, non flexible core?” There were over 100 pairs of hands in the room, none of which went up – we all want to do it, but we know it is difficult – not in terms of content, but in terms of inertia – which is a shame.”

  5. Great article Dave. I very much like the application of BCs, and of splitting transport from the data. It makes the standards much more technology-agnostic and, given how fast that changes, independence would seem to make sense. The vital signs example in the graphic is straight-forward, as they can mostly stand on their own. How would you see BCs working for something like AEs, or Con Meds, where there are many more data points, some of which are required to understand the rest of the data, and some of which are optional? Do BCs include a place for use instructions, assumptions and the like? For the data to be consistent and interpretable, they should be implemented similarly.

    This leads to the idea that, when they are implemented, the rules and assumptions for capturing the data need to be visible. These usually have less impact at a study level, but become critical when pooling data. For example, if one study had the sites capture diagnoses, and another study had them capture symptoms, the resulting data would contain a mix of flu and symptoms of flu, with no way to tell how much flu there was. Yes, I know we don’t account for this now – I believe this is a huge problem with how we use data today.

    One caveat wrt focusing development on BCs is that they may have natural relationships with each other that need to be defined somewhere. I have the same concerns around CDE development – data elements standardized independently from each other risk being combined inappropriately. I’ve seen examples of this. I have a rant on this at . kestrelconsultants.blogspot.com

    As you say, step-by-step, day-by-day, and if we include ways to define most (all?) of the factors influencing how the data should be used, we can end up with a far richer resource. I look forward to future developments!

    1. Kit
      The diagnosis versus symptoms, we do need to think about this but I and pretty sure Diane Wold has done some of this already. But we have a better chance of being able to detect this with well structured / defined data models. Again, first off we may not be able to, iterate and improve.
      WRT relationships. Agree we need these. May be not first iteration (as you say, leaves us no worse off than today). Then add in. We will hit some early on. Obvious one(s) are Study < -> Subject < -> Observation(s).
      Dave

      1. As I understand it, BCs are standard templates for clinical observations (SDTM findings). Adverse events and Con Meds are not observations, rather AEs are types of medical conditions that explain (are the cause of) clinical observations, and ConMeds are interventions used to affect (e.g. treat) medical conditions. I think the current paradigm in SDTM of calling events and interventions as observations is not correct. I write extensively about this in my blog. For example, a diagnosis is an assessment, performed by a qualified entity, of multiple observations leading to the identification of a medical condition. A symptom is a subjective observation (i.e. the observer is the patient).

        1. Armando
          From the pragmatic perspective BCs will need to encompass the range of items you describe. From my perspective this is getting our model right. Your last two posts are helping me get some clarity around this but this needs some serious discussion.
          For those you have not seen Armando’s posts they are well worth a read:
          http://aolivamd.blogspot.co.uk/2016/05/definitions-of-common-clinical-terms.html
          http://aolivamd.blogspot.co.uk/2016/05/improving-study-data-tabulation-model.html
          Dave

  6. I think we all are aligned that something has to change. The utopia side of my brain aligns with Wayne that we need to fundamentally change the way we collect information. I have always found the words EDC, eCTD, and eCRF comical as they are all prefaced with ‘electronic’. Yet we are still living in the same paper world we were 20 years ago, but we just put the paper in a virtual world and not really changed anything. We still have screens collecting square data (not the way a clinician thinks by the way), two dimensional data, and tables on a virtual 8.5×11 (or A4) piece of paper. We have to change the way we collect information so it matches the way clinicians process information.
    However, I am also a realist and understand that we can’t “boil the ocean”. The real hard question is where do we start? We aren’t going to change collection any time soon and the reality is that we still need to produce SDTM for submissions in the short term. I’m not going to jump to the technical implementation because honestly I don’t have the expertise as some who have responded. I’m going to focus on where – and I believe it starts in 1) helping companies implement a flexible operational model that can provide what the FDA needs in the short term separating structure from presentation but delivering them together. We just need to determine how we drive this forward as there are a lot of opinions, a lot of options, and some hard work to do.

    1. Chris
      Agree with the perspectives. The key point you raise is how we start looking and fixing this. But start we need to do. If we sit and watch the hole we are in just gets a little deeper every day.
      Dave

Leave a Reply

Your email address will not be published. Required fields are marked *