FHIR Chat · Relating feasibilities to studies · research

Stream: research

Topic: Relating feasibilities to studies


view this post on Zulip Gustav Vella (Oct 13 2021 at 20:09):

Given the following 2 feasibility scenarios, where sites are executing queries for a CRO, Sponsor or ResearchNetwork:

Scenario 1

  • All data for that query is available in the local FHIR CDR
  • No quality control required. I.E. there is no need to look into the individual patient records
  • Result: Aggregate Info (patient count and counts on specific criteria) are sent out to the requester.

Scenario 2

  • Not all data is available in a structured way in my CDR
  • The query can only help reduce the search space
  • I have to view individual records, view medical notes and decide on a patient to patient basis whether the patient fulfilled the criteria or not.
    Result: Aggregate Info (patient count and counts on specific criteria) are sent out to the requester after completing a screening process.

Both scenarios are not immediately part of a Research Study - but are activities which may lead to a site in participating in one. Yet, for both cases the sites need to issue automated standard reports to IRB, invoices to the CRO/Sponsor/ Research Network requesting the feasibility. These activities are identical or similar to other activities for research studies already modelled around the concept of ResearchStudy and implemented on the sites involved.

Also, Scenario 2 involves processes which are identical to those in pre-screening. All these processes are modelled around ResearchSubject and ResearchStudy. Hence, I’d like to deal with both activities within processes established for Research Studies.

There are good reasons for terminating the feasibility “studies” once the process is completed in some cases but there are also good reasons for using the same business ID and letting the process follow through once the trial is actually initiated and once the site decides to participate (approval process on site, Recruitment, ….)

In most cases it makes more sense to terminate the fesibility “studies” and loosely relate them to the proper study.

I have two questions:

  1. What’s the general thought on how to draw the line between feasibility and proper studies in the conceptual world of FHIR - are they studies of their own or part of a study?
  2. Would the partOf reference https://hl7.org/fhir/2021May/researchstudy-definitions.html#ResearchStudy.partOf be the appropriate way to loosely relate both Studies?
    The short description says “Part of larger study” - which makes sense here
    The Definition says “A larger research study of which this particular study is a component or step” - that would also make sense
    The requirements description says “Allows breaking a study into components (e.g. by study site) each with their own PI, status, enrollment, etc.” - the example is not what I’m looking for and extremely rare - but it’s just an example. ‘Breaking a study into components’ fits.

Glad to hear your thoughts.

view this post on Zulip Mike Hamidi (Oct 18 2021 at 17:19):

@Gustav Vella I would think if the ResearchStudy definition aligns. A feasibility study would be done prior to the main study. With that in mind, it also becomes a timing concept in respect to the broader ResearchStudy (1..*). This leaves the question if the feasibility study (being prior) is part of the larger main study using ResearchStudy.partOf (i.e., chicken before the egg). I also noticed that the "RelatesTo" may be another option if the practicality of existing ResearchStudy elements do not work. However, I would suspect that ResearchStudy.primaryPurposeType="feasibility-study" could fulfill this condition.

"Extension: RelatesTo
Many clinical studies have a component sub-study and the partOf attribute should be used for this. There may also be documents such as a PDF of the protocol or consent forms and these should be linked using relatedAretfact. However there may be more complex relations to other studies people organizations or artefacts and the RelatesTo extension is provided to record these."

I welcome additional feedback from others as well.

view this post on Zulip Gustav Vella (Oct 19 2021 at 14:54):

Mike Hamidi said:

However, I would suspect that ResearchStudy.primaryPurposeType="feasibility-study" could fulfill this condition.

Focussing on primaryPurposeType, which presently takes the following values: treatment | prevention | diagnostic | supportive-care | screening | health-services-research | basic-science | device-feasibility I think adding feasibility-study totally makes sense.

If no one totally opposes, I'll put a jira for that change.

view this post on Zulip Gustav Vella (Oct 19 2021 at 15:05):

Mike Hamidi said:

This leaves the question if the feasibility study (being prior) is part of the larger main study using ResearchStudy.partOf (i.e., chicken before the egg). I also noticed that the "RelatesTo" may be another option if the practicality of existing ResearchStudy elements do not work.
...
"Extension: RelatesTo
Many clinical studies have a component sub-study and the partOf attribute should be used for this. There may also be documents such as a PDF of the protocol or consent forms and these should be linked using relatedAretfact. However there may be more complex relations to other studies people organizations or artefacts and the RelatesTo extension is provided to record these."

I'd say the ResearchStudy.partOf might fit for screening (if the screening is a seperate study - as does sometimes happen) but does not fit for a feasibility - the feasibility is work done prior to confirm that a specific study is feasible. If that Artefact is still of any value and needs to be related to the trial for posterity, adaptation purposes/ reuse or whatever, I'd go for Extension: relatesTo

view this post on Zulip Mike Hamidi (Oct 19 2021 at 16:50):

@Gustav Vella I would try primaryPurposeType as the low-hanging fruit. If that does not work, then the relatesTo may be adaptable. In such a case, the ResearchStudy between feasibility and primary can be linked.

view this post on Zulip Lloyd McKenzie (Oct 19 2021 at 17:50):

I think it depends on the perspective of the sponsoring organization. If they consider the feasibility-study to be a 'part' of the overall process, using part-of is legitimate. (Particularly if any of the data gathered in the preliminary study is going to be used as part of the final analysis.) In other cases, the two might be considered completely distinct and relatesTo is a better fit.

view this post on Zulip Gustav Vella (Feb 08 2022 at 22:11):

A straw-poll before I submit a Jira: Any feelings about adding 'feasibility-study' to primaryPurposeType in ResearchStudy?

It presently takes the following values: treatment | prevention | diagnostic | supportive-care | screening | health-services-research | basic-science | device-feasibility

would be good to have some feedback here before.

Gustav Vella said:

Mike Hamidi said:

However, I would suspect that ResearchStudy.primaryPurposeType="feasibility-study" could fulfill this condition.

Focussing on primaryPurposeType, which presently takes the following values: treatment | prevention | diagnostic | supportive-care | screening | health-services-research | basic-science | device-feasibility I think adding feasibility-study totally makes sense.

If no one totally opposes, I'll put a jira for that change.

view this post on Zulip Lloyd McKenzie (Feb 08 2022 at 23:10):

Do you have a proposed definition for it?

view this post on Zulip Lloyd McKenzie (Feb 08 2022 at 23:10):

(that clearly differentiates it from the others)

view this post on Zulip Mike Hamidi (Feb 09 2022 at 20:07):

A couple starting points are 1) "Feasibility studies are relied on to produce a set of findings that help determine whether an intervention should be recommended for efficacy testing." (Am J Prev Med. Source), and 2) "to capture preliminary safety and effectiveness
information on a near-final or final device design; to adequately plan an appropriate pivotal study. (FDA IDE Source )
The definition could be modified to apply to the case here.

view this post on Zulip Lloyd McKenzie (Feb 09 2022 at 20:27):

One of the challenges is that 'device-feasibility' is already a code. So if we want to introduce a more generic code, we'd have to ensure there was a specialization relationship between them.

view this post on Zulip Mike Hamidi (Feb 09 2022 at 21:00):

Good point. @Lloyd McKenzie


Last updated: Apr 12 2022 at 19:14 UTC