Stream: biopharma
Topic: New Clinical Trial Resources
Wayne Kubick (Nov 17 2016 at 10:07):
I understand from Lloyd that the latest FHIR build now includes initial draft resources for Research Study and Research Subject. These are being used for the Structured Data Capture stream used by PCORI. Please check them out and comment.
Lloyd McKenzie (Nov 17 2016 at 10:20):
http://build.fhir.org/researchstudy.html and http://build.fhir.org/researchsubject.html
Pascal Pfiffner (Nov 17 2016 at 10:49):
Uuuuuh, thanks Wayne and Lloyd, splendid!!
Pascal Pfiffner (Nov 17 2016 at 10:52):
I'll need to re-evaluate Consent on whether it's now suitable for informed consent; we still use Contract for informed consent in our DSTU-2 implementation, so would not work with ResearchSubject.consent.
Lloyd McKenzie (Nov 17 2016 at 10:54):
Yeah, I'm hoping that Consent is going to evolve in a more general direction and will eventually support Consent for activity beyond just Consent for information disclosure. Contract seems non-ideal
Pascal Pfiffner (Nov 17 2016 at 11:07):
Agreed 👍🏼
John Moehrke (Nov 17 2016 at 13:25):
The team working on Consent are eager to make it useful. Please provide your comments, suggestions, concerns. We can't hit a target we don't see.
Geoff Low (Nov 17 2016 at 18:14):
@Sam Hume FYI
Geoff Low (Nov 18 2016 at 11:07):
Neither of those URLs ever finish loading, is there somewhere else I could see them?
Lloyd McKenzie (Nov 18 2016 at 11:10):
That's the only place they're hosted at the moment. FHIR requires a semi-modern browser (newer version of IE or Chrome or Firefox). Maybe try using a different browser?
Josh Mandel (Nov 18 2016 at 23:34):
These look like a good start. Some questions/comments:
1. For ResearchStudy, are you imagining that this might provide data to fuel a search site like https://clinicaltrials.gov/ ? Or is that clearly out of scope? The intro text doesn't make it clear. But if it's in-scope, I'd suggest reviewing the details provided there.
2. Principal Investigator should end in "pal", not "ple".
3. Why is "study arm" in ResearchSubject a string and not a coding?
Josh Mandel (Nov 19 2016 at 09:15):
From clinicaltrials.gov, I'd consider things like study collaborator, primary/secondary outcome measures, brief + official title, summary + detailed description, study design (allocation, endpoint, intervention, masking, purpose), a list of interventions separate from arms, so each arm can point to the (set of) interventions it uses, a list of publications, an indicator of whether the study is still recruiting (this is not derivable from period.end), details about how many people have been enrolled.
Lloyd McKenzie (Nov 19 2016 at 21:29):
Brief title is there, detailed description is there, allocation, intervention, masking and purpose are there, as are interventions and publications and enrollment (not all of those things will live on the ResearchStudy itself. Keep in mind that what we capture needs to be the content that's going to be core for all times of research studies - clinical & pre-clinical across all jurisdictions
Josh Mandel (Nov 20 2016 at 21:59):
Thanks for these details, Lloyd. I selected those attributes because I was having trouble seeing where they appeared. Where do things like publications and interventions appear? And masking, etc? I couldn't find them.
Josh Mandel (Nov 20 2016 at 22:00):
Also I'm not sure I understand your point about what's in scope -- are you saying that supporting a trial registry is out of scope for this resource?
Lloyd McKenzie (Nov 21 2016 at 06:36):
Look at the mappings to see where stuff lives. A trial registry is certainly in scope, but core probably wouldn't contain anything that would be specific to a registry but wouldn't be used in the day-to-day execution of a study.
Pascal Pfiffner (Nov 21 2016 at 14:17):
Finally got to take a look; looking great already, thanks Lloyd! Some thoughts on ResearchStudy:
- identifier, could this be 0..*? It's possible that a trial is registered in multiple repositories, e.g. ClinicalTrials.gov and WHO's
- status, would it make sense to be able to discern between *enrolling*, *no longer enrolling*, *data collection complete*, *data published* or similar? (I made these up on the spot, just checking whether it's desirable at all). Or have a separate enrollmentStatus or similar?
- site, maybe add a primarySite; or make site a backbone element with a reference and allowing to specify a site as the primary site?
- extending this thought to investigators: since there usually is one site PI, maybe this could really be a backbone element ResearchStudySite that has a PI and can be marked primary?
- something that will more and more become important are the publications coming from a study. Is the intention that that would go into relatedArtifacts?
- same would apply to documents that relate to the trial (like IRB approval, FDA approval, ...); relatedArtifacts?
- lastly, acronym; many of the larger trials have an acronym; make this a property, or a standard extension?
Pascal Pfiffner (Nov 21 2016 at 15:06):
In a ResearchKit environment, the goal for us is to be able to represent all the sections of the consent document, for which we right now are using Contract.term. It sounds like Consent is not aimed at being able to represent a contract document, but rather represent a signed consent. So our needs would probably be best met by some changes to Contract, rather than Consent.
ResearchKit knows a handful of different section types, so for term.type we use http://researchkit.org/docs/Constants/ORKConsentSectionType for system and e.g. DataGathering for code.
We use term.text for a short (1-2 sentence) explanation of the section. Then we use an extension for a title and another extension for the full text (1+ paragraphs) of the section. We'd make this a markdown element.
We use other extensions to specify which static image and which animation video to show at the top of each section – I guess this really can stay a custom extension.
Lastly, for subject we use a contained Group and in Group.characteristic we define simple eligibility criteria (such as "Are you over 18?"). If we'd use ResearchStudy this abuse could go away and the same Group would reside in ResearchStudy.enrollment.
So, @Lloyd McKenzie , does it sound like using Contract to model the consent we like people to sign, using ResearchStudy.enrollment to define eligibility criteria (which in a ResearchKit app are asked before guiding through consent), then once consented creating creating a Consent resource referencing our contract, creating a ResearchSubject resource referencing a Patient and referencing the consent is a sensible way to model enrollment?
Grahame Grieve (Nov 21 2016 at 20:22):
@Brett Marquard @Nagesh Bashyam note
Josh Mandel (Nov 21 2016 at 20:39):
Look at the mappings to see where stuff lives
But http://build.fhir.org/researchstudy-mappings.html doesn't show any of this @Lloyd McKenzie
Geoff Low (Nov 25 2016 at 12:46):
First off, this is great that you are building this.
- With respect to the
identifierstudies are usually referred to using a sponsor assigned identifier (eg CSOM230BBE01T for https://clinicaltrials.gov/ct2/show/NCT01895296), but are also registered in one or more clinical trial registries; of which clinicaltrials.gov, WHO, EudraCT are examples. sponsorshould be multiple valued, sponsor and collaborators per the @Josh Mandel comment is the pattern used by ct.gov.- Study Phase might be useful
armand Research plan (protocol) should be linked; soarmshould have an attribute that is an Identifier. IsPlanDefinitionintended to be able to be turned into an execution plan, a la the BPMN capability mentioned in IHE RPE?- I assume that the
principalInvestigatoris the Study Investigator, but there would also be one or more nominated site Investigators probably through theResearchStudySiteconcept per @Pascal Pfiffner - I think there would be value in having the concept of inclusion/exclusion criteria, with the basic stub of a study condition/conditions on the inclusion element. Having this information exposed in a structured fashion would make FHIR an interesting mechanism for finding studies.
ResearchSubject.identifier- can you clarify what is meant by "Business Identifer for event"?
Pascal Pfiffner (Nov 25 2016 at 15:09):
Structured eligibility criteria is definitely a want, but oh so many obstacles...
Geoff Low (Nov 26 2016 at 16:38):
Oh, I agree. We've done projects in the past within the PhUSE group to try and develop a model using RDF to be able to reason out INC/EXC (and, yes, I'm well aware that we were in no way the first to have a go at that, EHR4CR were another group ). Unsurprisingly, we hit a wall pretty quickly as how people phrase the criteria ends up in the worst sort of branching logic you could imagine. That said, condition is important (and should probably be required in cases where we are beyond Phase I, and it seems to me that it is about as low lying fruit as we could go) - find me the ResearchStudy instances where eligibilityStatement.inclusionCriteria.primaryCondition is Type I IDDM. Again, maybe that's not a current use case, but it should be I think. Recruiting subjects to studies is one of the most costly activities you'll undertake, which is strange given that most a Study Participants view the experience favourably.
Pascal Pfiffner (Nov 28 2016 at 20:24):
Yes indeed, being able to specify (primary) conditions would already go a long way to get us from an "excruciating long" list of potential trials to merely a "rather long" list. I did not read that point right. Just thinking out loud: a bunch of inc/exc Condition, Observation, Medication and maybe even Procedure could be interesting to work with.
Geoff Low (Dec 02 2016 at 08:34):
Absolutely agreed. I've not been aligned with the SDC group in the past - so I lack context on what's been discussed. As a vendor in the Bipharma industry I can seen the value of including the eligibility criteria as both a consumer and a producer of Resources.
Lloyd McKenzie (Dec 05 2016 at 02:19):
@Pascal Pfiffner 'identifier' - done
'status' - Not sure about this. Realistically there are a bunch of sub-elements to a study, each with a status. Not sure we can capture all the nuances in store. Certainly something for the group to discuss.
'site/primarySite' - we could have an element or a flag
'relatedArtifacts' - Dunno what the proper balance is here between distinct core elements, extensions and relatedArtifacts. I think this is sort of a place-holder and we'll need further discussion
'acronym' - I was nervous about putting something like this into core. It seemed odd to assert that 80% of systems that deal with trials would support a distinct element for this purpose. Figured I'd leave it to the experts to argue this one
'consent' - this bit is under evolution. Neither contract nor consent are ideal fits at the moment, but my hope is that Consent will eventually become a good fit.
Agree with your thoughts on Group/ResearchSubject/Patient
@Josh Mandel I hadn't defined the mapping properly. They should show up once the next commit gets processed
@Geoff Low
- we can figure out how sophisticated to make sponsor. I'm fine with making it repeat. I'm a bit more leary of making it overly sophisticated, but we can see what RCRIM thinks the 80% is
- we'll have to figure out how the notion of "Arm" should be represented in ActivityDefinition. It may need to be a standard extension for the purpose. (The idea of "arm" isn't common for PlanDefinition in general)
- My expectation is there would be a ResearchStudy instance for the overall study as well as for each study site, so the site-specific investigator would be identified on the site-specific instance
- inclusion/exclusion criteria are intended to be handled through Group. It's semi-structured there and can be made more structured through extensions
- "business identifier for event" is a standard description. We can override it with a definition that's more intuitive/useful
Pascal Pfiffner (Dec 05 2016 at 10:30):
Sounds great and welcome back!
- agree on status, probably makes sense to discern status and enrollment status. The latter is per site, could be something to put on that element if we created one (CT.gov does per-site-status as well) or we use nested research studies as you mention. I haven't thought that through entirely.
- good points on `acronym. I'm thinking that if a study/trial has one, everyone will refer to it via acronym, but not all trials have one. IMHO this field could be core without causing anxiety; it's a well known concept for trials, if your system doesn't support it the field is left empty with you knowing that your system probably should support it. You're likely right however that it's not supported by 80% of the systems.
Also, studies often have a short title (needs to be specified in Swiss IRB submissions for example); people are using this inconsistently as far as I can tell. CT.gov has a brief title and an official title field, with trials usually specifying a shorter title in the _brief_ field, so not simply the acronym. Some trials have put their acronym into the other identifiers section, but often the acronym is not captured standalone (on CT.gov).
Long story short, title, shortTitle and acronym are distinct data elements a trial could have. Need to discuss what should be core.
Lloyd McKenzie (Dec 05 2016 at 14:45):
@Pascal Pfiffner 'Group' has status, though I'm not sure that covers enrollment terribly well.
- We try to be cautious about adding things that are "easy to ignore". The general philosophy in FHIR is to only include things in core that we expect the vast majority of systems to support. Exceptions to that approach need to be thought about very carefully or the resource becomes over-complex. (And ResearchStudy is at very high risk for that :))
Geoff Low (Dec 05 2016 at 15:47):
@Lloyd McKenzie Thanks. I think we'd need to make the distinction between a primary Sponsor and collaborators, maybe as sponsorType attribute (with possible values Primary, Collaborator, ???)? I would want to search for studies by PharmaA, and limit it to cases where sponsorType is Primary or Collaborator.
Last updated: Apr 12 2022 at 19:14 UTC
