FHIR Chat · Machine Readable Study Protocol · research

Stream: research

Topic: Machine Readable Study Protocol

Gustav Vella (Aug 06 2018 at 20:00):

So let the party begin: what about a machine readable study protocol by Christmas? What about doing in 4 months what CDISC hasn't done with PRM in 10 years? Doing this in FHIR makes way more sense coz that's the language closest to our EMR and our study subjects are in final account patients at our care centers.

If we take a protocol guideline https://e-protocol.od.nih.gov and take the juicy and hard bits which will really help us, I'd focus on schedule of activites, dosing and administration.

That would be the first agenda

SCHEDULE OF ACTIVITIES (SOA)

The schedule of activities must capture the procedures that will be accomplished at each study visit. This includes any tests that are used for eligibility, participant randomization or stratification, or decisions on study intervention discontinuation. Procedures that contribute to participant eligibility should be distinctly annotated to distinguish between other routine procedures and. study objectives and endpoints should also be annotated. Other procedures should be done sparingly and with consideration, as they may add unnecessary complexity and detract from recruitment.
Allowable windows should be stated for all visits. To determine the appropriate windows, consider feasibility and relevance of the visit time points to study endpoints (e.g., pharmacokinetic (PK) studies may allow little or no variation, with required time points measured in minutes or hours, whereas a 6-month follow-up visit might have a window of several weeks).

Key concepts:

• schedule of activities
• procedures
• study visit
• procedures at each study visit
• tests
• eligibility, randomization, stratification
• Allowable windows for visits
• Relevance of the visit time points to study endpoints

Gustav Vella (Aug 06 2018 at 20:02):

DOSING AND ADMINISTRATION

Describe the procedures for selecting each participant's dose of study intervention and control product. For drugs, that includes the timing of dosing (e.g., time of day, interval), the duration (e.g., the length of time study participants will be administered the study intervention), the planned route of administration (e.g., oral, nasal, intramuscular), and the relation of dosing to meals.

Key concepts:

• procedures for selecting each participant's dose of study intervention and control product
• timing of dosing (e.g., time of day, interval)
• duration (e.g., the length of time study participants will be administered the study intervention)
• planned route of administration (e.g., oral, nasal, intramuscular)
• relation of dosing to meals.

State the starting dose and schedule of the study intervention and control product, including the maximum and minimum duration for those participants who continue in the study. For example, in some oncology trials for participants with no available therapeutic alternatives, intervention continues even after disease progression. In this instance, consider alternative designs that enable participants to rollover to a continued treatment arm and include appropriate instructions to guide this implementation.

Key concepts:

• starting dose
• schedule of the study intervention and control product

If applicable, describe the dose escalation scheme and dose regimen (using exact dose, rather than percentages). State any minimum period required before a participant’s dose might be raised to the next higher dose or dose range. If applicable, the protocol should state the conditions under which a dose change will be made, particularly in regard to failure to respond or to toxic or untoward changes in stipulated indicators (e.g., white blood cell count in cancer chemotherapy). Address dose modifications for specific abnormal laboratory values of concern or other adverse events (AEs) that are known to be associated with the planned study intervention. The protocol must state explicitly the dose-limiting effects that are anticipated. Provide criteria that will be used to determine dose escalations. If a participant is responding positively to the intervention, the protocol should specify whether study intervention administration would progress to still higher doses. If appropriate, provide a dose de-escalation schema with intervention modifications. Do not restate reasons for withdrawal of participants. Cross-reference relevant sections, as appropriate.

key concepts:

• dose escalation scheme
• dose regimen (using exact dose, rather than percentages)
• any minimum period required before a participant’s dose might be raised to the next higher dose or dose range
• conditions under which a dose change will be made
• particularly in regard to failure to respond or to toxic or untoward changes in stipulated indicators (e.g., white blood cell count in cancer chemotherapy).
• dose modifications
• for specific abnormal laboratory values of concern
• for other adverse events (AEs) that are known to be associated with the planned study intervention

Any specific instructions to study participants about when or how to prepare and take the dose(s) should be described, including how delayed or missed doses should be handled. Include any specific instructions or safety precautions for administration of the study intervention. Discuss the maximum hold time once thawed/mixed, if appropriate, before administration.
While much of the above section is specific to drugs, similar considerations apply to certain devices. For example, some devices have adjustable settings including those related to energy delivery to participants. Other devices must be sized correctly for individual participants. Similar to the discussion above for dosage of drugs, such considerations should be described for devices, as applicable.

Key concepts:

• how delayed or missed doses should be handled.

Is that a start?

Lloyd McKenzie (Aug 06 2018 at 21:31):

That's quite the way to kick off the thread :)

Lloyd McKenzie (Aug 06 2018 at 21:37):

I think there's a few interesting things we can pursue. One is absolutely defining how to represent clinical protocols in FHIR - not positioned as "let's do this because CDISC hasn't" - I don't think that framing is helpful. Rather "let's make sure the things we need are actually in FHIR and use some of our requirements to exercise FHIR in a way that it hasn't been previously". Part of that will likely include ability to map to and from what CDISC can do.

The reality is that FHIR may well be able to model protocols to a greater level of sophistication than authors can be bothered with and than clinical systems will care to engage with. So something else to consider is what level of protocol exposure will let us drive the degree of EHR behavior we need.

A second area to explore is how much change would we actually need in the EHR and how much can we leverage things like SMART and CDS Hooks to let us "plug in" to the EHR to do things without EHRs needing to change much, if at all.

A third area to explore is defining data expectations - what can Questionnaire/QuestionnaireResponse, SDC and profiles do in terms of simplification of data collection processes?

Hugh Glover (Aug 07 2018 at 08:29):

All good stuff!

Take a look at Scenario 4 of the Clinical Research Stream of the Connectthon. While its couched in terms of ODM I think the core question is demonstrating a schedule of activities in FHIR.

I'm wary of the "lets represent a protocol in FHIR" because a Protocol is quite a substantial beast but the elements Gustav has pulled out are a good subset.

Gustav Vella (Aug 07 2018 at 10:08):

@Hugh Glover thanks for feedback. Is there any work product/outcome in term of resources/profiles for Scenario 4?

Gustav Vella (Aug 07 2018 at 10:27):

@Lloyd McKenzie
as to first point. That set is the minimal level of exposure we need. I'd add adverse events and basic ResearchSubject linking to medical record. In the coming weeks I'll make a suggestion for modifications needed http://build.fhir.org/researchsubject.html#statemachine here. I still have to test things out to be absolutely positvely sure that they are really are missing.

second point. scopes & launch context is tricky. but there are feasible workarounds eg for my app the parameters are

• patientid: identifier of current patient context from which the app was launched
• username: name of current EHR user launching the app
• fhirbase: URL of the FHIR server endpoint

For example:
https://{app-launch-url}?patientid=12345&username=jdoe&fhirbase={fhir-server-url}
While the fhirbase parameter can be set statically at setup time, both username and patientid must be populated by the EHR at runtime. Most EHR vendors offer placeholders to create dynamic launch urls.

we'll need to help end users with a shortlist of what to demand from their vendors and offer them workarounds if their vendors don't comply.

third point. yes ! the stuff going on with questionnaires right now will help.

Hugh Glover (Aug 07 2018 at 12:47):

Its on my list to start doing some prep, and there will be a section on the BR&R confluence pages to hold it.

Lloyd McKenzie (Aug 07 2018 at 14:36):

Don't really understand linking ResearchSubject to the medical record. The only link for ResearchSubject is its existence. All other linkages would be through Patient to ResearchSubject and to Study.

Christine D (Aug 07 2018 at 15:14):

@Lloyd McKenzie as a data modeler, I wholeheartedly agree...ResearchSubject would be a role that a Patient can play. And in a perfect world, we would have all of those connections in the data. But it's not what we are seeing in the data we receive. There are some situations where the patient is anonymized. The data sources don't have a patient number - they only know our subject ID - so that's all they provide. Having to go through Patient forces either the data source or the data consumer to create "fake" data, just to fill in the gaps. Sigh...

Gustav Vella (Aug 07 2018 at 15:18):

@Lloyd McKenzie yeah sorry the wording: The real subject only becomes a research subject in a FHIR aware EMR with the existence of ResearchSubject. In practice you'd have an app to generate that coz the emr does not speak fhir an has no concept of a subject or a tiral. In germany you'd be translating V2 messages to FHIR resources. Our app obviously runs on a FHIR Serever and invoke it as described in previous post. From the perspective of the clinician the app links patients to trials and makes them study subjects. You have these relationships: PID 1234 <--> Trial xyz <--> ScreeningID 015, Subject ID 4673 and status of patient in the trial...

That's where you hook in: the absolute minimum you have to implement before building apps for the fancy stuff - visits, screening tests, study medication etc.

Lloyd McKenzie (Aug 07 2018 at 16:22):

In FHIR, ResearchSubject is less a role and more a 'participation' - it represents a particular patient's involvment in a particular study rather than a generic capacity to be involved in studies. In an anonymized situation, you're not creating "fake" data - you're creating an anonymized view of data - you're going to similarly anonymize everything else because it won't just be the patient resource that will require anonymization - you'll need to think about narrative in all of the resources and in some cases you may need to anonymize other things too. ResearchSubject doesn't have any "person" data at all - it's all about the activity of involvment in the study.

Hugh Glover (Aug 08 2018 at 15:58):

I've crated a dummy data set for a schedule of activities at (http://confluence.hl7.org/display/BRR/Connectathon+2018-08+Scenario+4). This is intended as a starting point to throw things at. For instance do we also want to consider recruitment at this point? Do we want sample inclusion and exclusion criteria? ...

Christine D (Aug 09 2018 at 14:18):

@Hugh Glover Would this help us get an idea of the contents of the ODM file? https://docs.openclinica.com/3.1/technical-documents/openclinica-and-cdisc-odm-specifications/mapping-openclinica-elements-odm

Markus Döring (Aug 12 2018 at 19:37):

https://simplifier.net/test20171092

@Gustav Vella Can you please take a look and give feedback?

Gustav Vella (Aug 12 2018 at 19:40):

extension https://simplifier.net/test20171092/ResearchStudy-reference/~json looks good - you elaborated on suggestion by @Lloyd McKenzie

Lloyd McKenzie (Aug 12 2018 at 19:43):

The study reference is a standard extension - http://build.fhir.org/extension-event-researchstudy.html

Gustav Vella (Aug 12 2018 at 19:43):

The trial has 3 Investigational Substances - you modeled 2 .. https://simplifier.net/test20171092/ActivityDefinition-example1/~json

Gustav Vella (Aug 12 2018 at 19:44):

looks good . Is it possible to put the dates relative and not absolute?

Gustav Vella (Aug 12 2018 at 19:45):

I mean relative to the beginning of treatment? .. ok but still that's an approach

Gustav Vella (Aug 12 2018 at 19:49):

@Lloyd McKenzie you are right - would be great if you make that official soon. What @Markus Döring did is limited to encounter

Gustav Vella (Aug 12 2018 at 20:02):

Cool so you partially covered a few basic concepts

Lloyd McKenzie (Aug 12 2018 at 20:04):

@Gustav Vella - it is an "official" extension. It will be published as part of R4 at the end of the year.

Gustav Vella (Aug 12 2018 at 20:05):

https://simplifier.net/test20171092/activitydefinition-example-2 - so here same question. It would be interesting to define the schedule relative to start of treatment

Gustav Vella (Aug 12 2018 at 20:06):

But that would be on a higher level up in the hierarchy. It kicks off the schedule for all 3 Substances

Gustav Vella (Aug 12 2018 at 20:07):

maybe http://build.fhir.org/codesystem-research-subject-status.html#research-subject-status-on-study-intervention

Gustav Vella (Aug 12 2018 at 20:07):

cf. On-study-intervention: The person is receiving the treatment or participating in an activity (e.g. yoga, diet, etc.) that the study is evaluating.

Markus Döring (Aug 12 2018 at 20:11):

@Gustav Vella Mentioning the kickoff for the schedule, do you mean one kickoff for the whole study or a separate one for every participant?

Gustav Vella (Aug 12 2018 at 20:12):

@Markus Döring no start of treatment date means the date the research subject starts treatment in the trial. it's relative to the enrollment of that patient

Gustav Vella (Aug 12 2018 at 20:15):

Patients are not recruited at once but in a recruitment window - say 6 or 12 months depending on how difficult it would be to get all the subjects you need. Regarding the Visit Schedule, what's really tricky is that there could be a tolerable delay, where you'd reset the schedule for the following visits relative to that delay. Say the subject has an infection or any other adverse event, you'd have to wait till the study subjects are in a state to continue treatment with the investigational drug (it all depends on what is stipulated by the protocol)

Gustav Vella (Aug 12 2018 at 20:17):

but the delay has a tolerable range "Allowable Window" - if the patient delays too long - depending on the trial they'd fall out for the major statistical analysis and would remain in the trial with the "Intent to Treat". The Allowable windows of delay in the schedule may be different for each investigational drug in the same trial.

Gustav Vella (Aug 12 2018 at 20:20):

Falling out of the allowable window of delay for a substance may have consequences for the further treatment. Eg. in CLL protocols - which you are using as examples here - it would no longer makes sense to have the patient endure a painful bone marrow biopsy at final assessment (last visit of the treatment phase) once the patient is no longer fully compliant with the regimen/study protocol

Gustav Vella (Aug 12 2018 at 20:27):

We model and calculate the allowable windows for all visits within the application for each trial. It would make sense for the sponsor to publish that data in FHIR for an EDC system to import to at least reduce that part of the burden. With regards to the rules for calculating a new schedule and deactivating certain procedures: that is presently all proprietary. There again a standardized machine readable version would be of great benefit - especially if both your EDC as well as your EMR are aware of the FHIR API.

Gustav Vella (Aug 14 2018 at 16:19):

@Simone Heckmann you hinted using the timing element. If we were to use that (i.e BackboneElement) to model a schedule, it would also handle offsets http://build.fhir.org/datatypes.html#Timing
I can declare an offset in ActivityDefinition https://www.hl7.org/fhir/activitydefinition-definitions.html#ActivityDefinition.timing_x_

The MedicationRequest .definition field allows a reference to ActivityDefinition - thus linking from specific to abstract. Absolute offset (real date) would be stored in MedicationStatement. The application would check MedicationStatement.effective against ActivityDefinition.timing - the result would have to be < than Timing.offset for continuation on the schedule per protocol.

The Schedule is a property of the trial. On enrollment, the schedule becomes a property of the research subject. I really am at a loss how to stuff that information in ResearchSubject.

A possible approach: The Schedule is in ActivityDefinition. Pat. enrolls and the application would create mulltiple MedicationReqests and Encounters. You put the absolute dates in there. Every time you have an offset you recalculate the dates. Would that be an approach?

Lloyd McKenzie (Aug 14 2018 at 16:35):

The study points to a protocol (PlanDefinition). The specific schedule for a ResearchSubject would be a CarePlan. If we wanted to support ResearchSubject having a pointer to the CarePlan describing the patient's schedule (whether as core or as extension), that would be reasonable.

Lloyd McKenzie (Aug 14 2018 at 16:35):

Encounters are events - they won't exist until the patient shows up.

Gustav Vella (Aug 14 2018 at 16:43):

Yeah CarePlan - I keep forgetting that. Thanks!

Markus Döring (Aug 14 2018 at 16:46):

@Lloyd McKenzie Thank you for pointing out the CarePlan - I forgot about that one.

The reference between ResearchSubject and CarePlan sounds like a good idea to me.
However it would already be possible to chain the resources together by using the reverse chaining concept wouldn't it?
Meaning: The Patient is referenced in the ResearchSubject and vice reverse chaining it would be possible to get the CarePlan.

So the concrete reference would be mostly saving time and server resources - or do I miss something?

Gustav Vella (Aug 14 2018 at 16:47):

It would be easier to model and more intuitive

Lloyd McKenzie (Aug 14 2018 at 17:02):

You could have a CarePlan that points to the Patient that is the ResearchSubject and also have the CarePlan point to the ResearchStudy saying "this plan is relevant to the study". But nothing prevents there from being 10+ such CarePlans. If you want to say "This is the authoritative CarePlan for this ResearchSubject", an explicit link would be needed.

Gustav Vella (Aug 14 2018 at 17:11):

So you are arguing that an extension does make sense here... right?

Lloyd McKenzie (Aug 14 2018 at 20:04):

Either extension or core element - you'll have to decide how common it is for systems that track a particular patient's involvement in a study to have a fully-defined schedule for each patient.

Christine D (Aug 21 2018 at 12:22):

A couple questions have emerged....
1. How does Appointment factor into this? Are you envisioning that we go from PlanDefinition/ActivityDefinition (to get the number of visits and their frequency for the trial requirements) to CarePlan to AppointmentRequest (requested visit for subject) to Appointment (scheduled visit for subject) to Encounter (if/when visit actually happens)?
2. We are struggling with fitting the trial setup and visit schedule into PlanDefinition and ActivityDefinition. It may be a definition issue. Suggestions?

Bryn Rhodes (Aug 21 2018 at 14:01):

On the second item (since it seems like it would impact the first), can you elaborate on the issue?

Christine D (Aug 22 2018 at 12:57):

@Lorraine Spencer what are your thoughts on this?

Christine D (Aug 23 2018 at 14:15):

@Bryn Rhodes From Lorraine: If we want a protocol level plan that accounts for visits AND activities required within the visits, I still do not see a resource for Visit under which to nest Activities and scheduling (for example acquisition of vitals must precede venipuncture).

Bryn Rhodes (Aug 23 2018 at 14:32):

Can it be modeled with a nested action? So something like:

Bryn Rhodes (Aug 23 2018 at 14:32):

<PlanDefinition>
  <action id="visit-1-group">
    <title value="Visit 1 Group"/>
    <action id="visit-1">
      <title value="Visit 1"/>
      <definition value="ActivityDefinition/visit-definition"/>
    </action>
    <action value="visit-1-activities">
      <title value="Visit 1 Activities"/>
      <relatedAction>
        <actionId value="visit-1"/>
        <relationship value="concurrent"/>
      </relatedAction>
      <action value="record-vitals">
        <title value="Record Vitals"/>
        <definition value="ActivityDefinition/record-vitals-definition"/>
      </action>
      <action value="venipuncture">
        <title value="Venipuncture"/>
        <relatedAction>
          <actionId value="record-vitals"/>
          <relationship value="after"/>
        </relatedAction>
        <definition value="ActivityDefinition/venipuncture"/>
      </action>
    </action>
  </action>
</PlanDefinition>

Bryn Rhodes (Aug 23 2018 at 14:32):

That would then be realized as a RequestGroup with the same pattern and relationships.

Lloyd McKenzie (Aug 23 2018 at 15:30):

@Christine D There's no such thing as AppointmentRequest. You'd have a CarePlan that indicated when you expected visits to occur. The actual booking (and confirming participants) would happen through Appointment/AppointmentResponse. When the actual visit occurred, you'd have the Encounter.

Christine D (Aug 23 2018 at 15:58):

Apologies as I meant Appointment Request (with a space, the process). Thanks for clarifying the flow from CarePlan to Appointment to Encounter.

Lloyd McKenzie (Aug 23 2018 at 16:29):

Note that there doesn't have to be a CarePlan (and doesn't even have to be an Appointment). But if you're trying to derive things strictly from a protocol and include all the steps, that would be the flow.

Hugh Glover (Aug 28 2018 at 12:13):

@Bryn Rhodes Why a RelatedAction and not a nested Action? To me RelatedAction with a relationship value of "Concurrent" implies it happens to be going on at the same time, not that it is part of the composition of the "parent" action.

Bryn Rhodes (Aug 29 2018 at 19:31):

So that's a good point, but we have so far tried to avoid mixing groups and actions. The description of the action element is "an action or group of actions", and for simplicity we've tried to stick to that separation (we've even talked about an invariant that would enforce it). It's a discussion worth having though, it might make sense to support nested actions but we would need to document the expected semantics.

Last updated: Apr 12 2022 at 19:14 UTC