FHIR Chat · Being RESTFul in clinical research · implementers

Stream: implementers

Topic: Being RESTFul in clinical research

Matthew Koch (Feb 09 2018 at 13:57):

Hi all - what would a RESTFul URL look like if we wanted to serve up Observations on a per-protocol basis? We work in clinical research, and I'm trying to discover a way to to segment results in a way that's meaningful to consumers of our service.

Would this simply be a search parameter on the root Observation resource?

http://[domain]/fhir/Observations?protocol=123

or would we nest this in another type of resource?

http://[domain]/fhir/[ResearchStudy?]/123/Observations

Suggestions welcome!

Lloyd McKenzie (Feb 09 2018 at 15:42):

You certainly could have an endpoint for each study if you wanted to, though that gets a bit tricky if some data is relevant to multiple studies. The first approach keeps your infrastructure simpler - and allows it to be more easily used by systems that may not care about study. We've defined a standard extension to link resources (including Observation) to studies but haven't defined a standard search criteria. If you wanted to submit a change proposal, we certainly could create a standard search criteria though...

Christiaan Knaap (Feb 14 2018 at 19:02):

And in the meantime several FHIR Servers (e.g. HAPI, Vonk) allow you to use custom searchparameters.

Jalapathi (Feb 15 2018 at 15:02):

hi

Jalapathi (Feb 15 2018 at 15:05):

Hi, Anyone idea about Open Epic api connectivity

Lloyd McKenzie (Feb 15 2018 at 17:46):

@Jalapathi Please read FHIR Rules for asking questions and then post something more specific.

Matthew Koch (Apr 11 2018 at 00:30):

You certainly could have an endpoint for each study if you wanted to, though that gets a bit tricky if some data is relevant to multiple studies. The first approach keeps your infrastructure simpler - and allows it to be more easily used by systems that may not care about study. We've defined a standard extension to link resources (including Observation) to studies but haven't defined a standard search criteria. If you wanted to submit a change proposal, we certainly could create a standard search criteria though...

Thanks for the reply. I certainly agree that the first approach is simpler. What's the standard extension to link resources to studies you mentioned? I wonder if a standard search criteria of ?research study=XX-XXX makes sense...?

Lloyd McKenzie (Apr 11 2018 at 02:40):

Hmm. The only two I can find are http://hl7.org/fhir/extension-questionnaire-studyprotocolidentifier.html and http://hl7.org/fhir/extension-patient-clinicaltrial.html (though you could technically also use http://build.fhir.org/extension-event-partof.html). Can you submit a change request for us to add this as an extension for all request and event resources?

John Moehrke (Apr 11 2018 at 12:01):

I would expect that the linkage to a study would be through the agreement with the Patient to engage in that study. Thus I would expect there to be a Consent (Research type) that identifies the actors, the purpose, and the data. These use-cases have not yet been brought forward to the workgroup that owns Consent. Please contact @David Pyke and join the workgroup to help them improve Consent for these use-cases.

Lloyd McKenzie (Apr 11 2018 at 14:07):

There would be a Consent, but it wouldn't necessarily be expressed in FHIR. There's still a need to be able to link Observations, Procedures, MedicationAdministrations, etc. to say that they're tied to a study.

John Moehrke (Apr 11 2018 at 14:09):

the Consent resource is intended to be as small as an indicator of a paper (or other) consent evidence is held somewhere else (consent on file). But the resource is still useful to identify the data of interest (Consent.provision)

Matthew Koch (Apr 11 2018 at 20:52):

Interesting points here, especially the inclusion of Consent somehow. At this point I think I’ll need to consider how to move forward as there does not appear to be a clear cut way to segment by study currently.

Happy to submit a CR for a standard search criteria (researchstudy) if there is enough interest.

Dwight Walker (Apr 12 2018 at 02:08):

Interesting points here, especially the inclusion of Consent somehow. At this point I think I’ll need to consider how to move forward as there does not appear to be a clear cut way to segment by study currently.

Surely use of patient's myGov could authorize access for doctor or hospital to access patient records. I don't know protocol but there must be a broker or this will bog down in paperwork.

Matthew Koch (Apr 12 2018 at 14:18):

Hmm. The only two I can find are http://hl7.org/fhir/extension-questionnaire-studyprotocolidentifier.html and http://hl7.org/fhir/extension-patient-clinicaltrial.html (though you could technically also use http://build.fhir.org/extension-event-partof.html). Can you submit a change request for us to add this as an extension for all request and event resources?

Just signed up for an account @ https://gforge.hl7.org/gf/ - currently awaiting approval...

Lloyd McKenzie (Apr 12 2018 at 14:38):

Looks like you're already approved...

Matthew Koch (Apr 12 2018 at 15:05):

I had a "doh" moment and forgot my password, so I can't confirm my account... Trying to use the reset password link...

Lloyd McKenzie (Apr 12 2018 at 15:11):

Addressed offline

Peter Heisig (Apr 19 2018 at 08:56):

(deleted)

Matthew Koch (May 24 2018 at 18:26):

I wanted to add something now that the CR has been approved (hooray!)

In a situation where we are returning Observations, how would we deal with the subject attribute (given our use case of needing to de-identify the Patient for clinical research purposes - hence the push towards ResearchSubject ?)

Example:

{
  "resourceType": "Observation",
       //
       "subject": {
          "reference": "Patient/SMART-99912345"
        },
       //
}

Where SMART-99912345 is something analogous to an MRN (which we don't want to show.) Is there a way to display the observations with a reference to the ResearchSubject they are related to?

Grahame Grieve (May 24 2018 at 18:36):

a given patient can involved in multiple studies. So you'd have to compare the patient reference with whatever research subjects you were interested in

Matthew Koch (May 24 2018 at 18:42):

That makes sense. In my example, I am assuming the result-set is filtered by ResearchStudy, so that scope is taken care of. I'm wondering the best way to represent the patient here while at the same time not exposing their identifier (e.g. MRN.) I'm not sure if this is possible via the subject attribute...

Grahame Grieve (May 24 2018 at 18:44):

the subject refers to a patient by the id of the resource:

"reference" : "Patient/some-id"

Grahame Grieve (May 24 2018 at 18:45):

and then the patient resource will include gender, munged birth date, and no name or identifiers.

Grahame Grieve (May 24 2018 at 18:45):

'some-id' should not be the patient MRN, and this is one of the reasons. If it is, the de-identification service will haev to not only remove names and identifiers and munge the birth date, it will have to maintain a very large table of mrn switches

Matthew Koch (May 24 2018 at 18:46):

Right - I see. We've always traditionally identified patients by MRN so that's why I'm in that headspace. This makes sense. We'll need to decide on a different identifier

Matthew Koch (May 24 2018 at 19:16):

What if the subject is not a Patient?

Matthew Koch (May 24 2018 at 19:26):

I guess this is a dumb question - I rescind it. I was referring to the case where the subject may not be a Patient at the institution but I fail to see how that's possible.

Grahame Grieve (May 24 2018 at 19:28):

we discuss the use of MRNs and their like in the spec itself - MRNs are managed identifiers that humans use - it is nearly always a mistake to use that as the resource id.... something will crop up where the management of the id breaks the rules about persistence of identifies where as database primary / composite keys are exactly what you should use

Grahame Grieve (May 24 2018 at 19:28):

of course, some clinical systems use the MRN as a primary database key....

Lloyd McKenzie (May 24 2018 at 22:15):

ResearchSubject doesn't eliminate the need for Patient. ResearchSubject establishes a linkage between Patient and a particular ResearchStudy - and captures the information specific to that join (e.g. subject status within the study, assigned arm, whether their consent is done, etc.) If there's a need to share "anonymized" information, you'd still have a Patient resource, they just wouldn't have a name (and might have less granular information such as just a year or year + month for date of birth). Systems responsible for anonymizing the data shared would convert from the identified Patient resource to the non-identified resource - and might maintain a linkage to support subsequent reidentification if needed.

Gustav Vella (Aug 05 2018 at 16:56):

I'm not sure whether this is the right thread. Question is related to clinical trials and guys here seem to be acquainted with ResearchSubject & ResearchStudy: I'm trying to associate a lab test with a study visit (eg. screening visit or stratification visit) but can't find the concept of the study visit anywhere. If I take Encounter, I'll have to goof my way spuriously around to bridge a relationship to research study. Any Idea on how best to define a study visit?

Markus Döring (Aug 05 2018 at 17:38):

A question related to clinical trials: Specifically planned dose and
given/administered dose. My understanding is that MedicationRequest
can be used to define the planned dose. MedicationStatement can be
used to document the given dose.
However following the references from ResearchStudy to the
PlanDefinition, it doesn't seem easy to create a reference to
MedicationRequest. Has anyone encountered this issue? Does anyone know
a different way to define Medications and Doses in ResearchStudies?
For the long haul, I’m also after dose modifications and delay in
administration.

Lloyd McKenzie (Aug 06 2018 at 00:00):

@Gustav Vella Study visit is absolutely Encounter. There's agreement to add a generic extension that will let you link the Encounter to a research study. (Or to multiple research studies). You can also point to a particular Activity in one or more study protocols (PlanDefinitions)

Lloyd McKenzie (Aug 06 2018 at 00:02):

@Markus Döring "planned dose" can mean two different things. It can be the protocol-defined dose, in which case it would be in ActivityDefinition. Alternatively, it can be a patient-specific does, in which case MedicationRequest would be appropriate. In general, you'll take the time-agnostic and patient-agnostic PlanDefinition and use it to generate a CarePlan which defines the intended path of a particular patient through the study based on their arm assignment and other characteristics. The CarePlan would have an 'instantiates' relationship to the PlanDefinition. The MedicationRequest would be one of the activities within the plan and could have an 'instantiates' relationship with one of the ActivityDefinitions from the PlanDefinition.

Lloyd McKenzie (Aug 06 2018 at 00:03):

Actual administrations would more likely be captured using MedicationAdministration rather than MedicaitonStatement. The former is precise and represents an individual administration. The latter represents an approximate summary of administrations which will presumably be less common in a research setting.

Gustav Vella (Aug 06 2018 at 07:58):

quote There's agreement to add a generic extension that will let you link the Encounter to a research study. (Or to multiple research studies).

@Lloyd McKenzie First off thanks alot! But I'm still confused. What exactly makes an extension generic - as opposed to a vanilla extension? How are agreements made? Is it written somewhere? Machine semantics need machine readable contracts. I assume that all extensions used in resources require a formal published definition.

Hugh Glover (Aug 06 2018 at 10:14):

I don't have answers to offer but this is at the core of one of the clinical research tracks at the connectathon in Baltimore.

Simone Heckmann (Aug 06 2018 at 11:05):

I assume @Lloyd McKenzie means 'generic' as a well-defined extension to link to a study that can be applied to any ressource...?

Gustav Vella (Aug 06 2018 at 13:17):

Given we have an extension, which points from PlanDefinition to Encounter.
According to your @Lloyd McKenzie answer we can model the planned medication (times and dosage) via ActivityDefiniton.
MedicationStatement has a "context" field via which an Encounter can be referenced as well as a "basedOn" attribute which can point to MedicationRequest.
We'd thus have these cards in the game: ReserachStudy, PlanDefinition, ActivityDefinition, Encounter, MedicationStatement, MedicationRequest.
The game ist to to figure out how to approach Encounter. What direction do you suggest? PlanDefinition (= Trial Protocol) to Encounter (= Vist)
or
Encounter to PlanDefinition via reverse chaining?

I think the former makes more sense because we're after the Encounters = Visits for a given trial.
If we were, say after Adverse Events for a set patients linked to trials on my site, then probably the other way round would make more sense. right?

Now let's say I had use cases for which both approaches made sense - and don't want to kill the server with back chaining - would I write two different versions of the extension? How would the world make sense of this?

Lloyd McKenzie (Aug 06 2018 at 16:06):

The specific extension is http://build.fhir.org/extension-event-researchstudy.html. It'll let you link encounters, procedures, medication administrations, observations, etc. to a study.

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

It won't point from PlanDefinition from Encounter. It'll point from Encounter to Study.

Lloyd McKenzie (Aug 06 2018 at 16:09):

Nothing will ever point from PlanDefinition to Encounter, however Encounter should be able to point to PlanDefinition (or to ActivityDefinition which is pointed to by PlanDefinition) using the event-instantiatesCanonical extension. @Brian Postlethwaite Why is this not supported by Encounter? It certainly should be...

Gustav Vella (Aug 06 2018 at 18:52):

Thanks alot @Lloyd McKenzie - Could I offer you a beer in Amsterdam? ;°>
However this still feels like the fine Art of Goofing Off https://youtu.be/N5AvTQnKnF8
@Markus Döring Take note.

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

You could offer, but I'll probably like you more if you don't insist I drink it :) (Last beer I had was almost a decade ago in France where the locals were most insistent that I had to try the local brew...)

Matthew Koch (Aug 07 2018 at 17:37):

@Lloyd McKenzie - Now that the researchstudy extension is defined (http://build.fhir.org/extension-event-researchstudy.html), can we leverage / incorporate it as a search parameter for a resource (e.g. Observation)? For example, would this be considered valid?

http://fhir-server.test/api/observations?researchstudy=XX-YYYY&_count=50

Matthew Koch (Aug 07 2018 at 17:47):

Here are a few more I'd like to get some feedback on the validity of, assuming the researchstudy search parameter above is valid:

• Querying for observations that occurred between a specific period of time:

http://fhir-server.test/api/observations?researchstudy=XX-YYYY&_count=50&context:Encounter.status=finished&context:Encounter.date=le2006-06-30&context:Encounter.date=ge2006-06-20

• Querying for observations for a specific ResearchSubject, using the Patient link:

http://fhir-server.test/api/observations?researchstudy=XX-YYYY&_count=50&patient._has:ResearchSubject:identifier=HASHID123

Lloyd McKenzie (Aug 07 2018 at 18:39):

Seems like a reasonable request. Submit a change request and we can define a standard SearchCriteria too

Matthew Koch (Aug 07 2018 at 23:08):

Is this required? Or can we just start using the resource in the search params? @Geoff Low - what say you?

Matthew Koch (Dec 04 2018 at 14:02):

@Lloyd McKenzie - This was submitted. https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=19717

Matthew Koch (Dec 04 2018 at 14:37):

The specific extension is http://build.fhir.org/extension-event-researchstudy.html. It'll let you link encounters, procedures, medication administrations, observations, etc. to a study.

Just an FYI, this link is broken.

Christiaan Knaap (Dec 05 2018 at 08:12):

I guess this extension was meant: http://build.fhir.org/extension-workflow-researchstudy.html
SearchParameter resources can be created by yourself, also on extensions. Some of the servers allow you to use your own searchparameters for search. Let me know if you need help in creating the correct criteria.

Geoff Low (Dec 05 2018 at 09:11):

Apologies, completely missed this stream.

I'd just echo that I'd envisioned that data access would most probably be via a ResearchSubject basis; the ResearchSubject.id would be the foreign key in the interrogating system (with a link to the ResearchStudy and Patient resource through which you'd be able to access the data) - this would allow the inquisitor to check the status of the subject enrolment prior to accessing the data.

Is the link here intended for the assessment of standard of care versus research purposes? Most of my thoughts (probably blinkered by my view of the world) are that we would always request the data through the lens of a subject, rather than at the individual resource. My thinking hitherto now has been that the Research experiments would leverage the health resources in the EHR - the EHR would be the eSource; the majority of the resources would be populated/defined as part of standard of care.

Some of the resources would be added to the healthcare system prompted via a ServiceRequest spurred by a CarePlan relating to the specific protocol (ResearchStudy). Some of the biggest use cases are Relevant Medical Histories, Concomitant Medications, Labs/Vitals (especially with complex oncology studies) so maybe I'd recommend adding the extension AdverseEvent/Condition/ServiceRequest as well?

Is it worth getting on a call to discuss?

Matthew Koch (Dec 06 2018 at 14:58):

I guess this extension was meant: http://build.fhir.org/extension-workflow-researchstudy.html
SearchParameter resources can be created by yourself, also on extensions. Some of the servers allow you to use your own searchparameters for search. Let me know if you need help in creating the correct criteria.

Thanks! So are you saying that we don't need a "standard" search param here? If that is the case I am happy to explore using custom search parameters for our use cases. Can you point me in the right direction?

John Moehrke (Dec 06 2018 at 17:54):

I think the query mechanism is more proper REST. Adding an extension to all resources would result in modifying clinical data each time that clinical data is identified as relevant to a new clinical trial. The methods of REST as selected by FHIR would have your Research Study point at the relevant clinical data, not have the clinical data point at the ResearchStudy. Thus a service that supports the special query parameter (research-study) agrees to follow the breadcrumbs in the research study to find all the data relevant.

Geoff Low (Dec 07 2018 at 11:15):

I'm assuming (from the perspective of provenance) that the downstream research system would keep a record of the source datapoint (Resource, attribute and version) - accessing the Resource for the purposes of using in a Research Study should not mutate the resource itself. Data ownership in clinical research is a bit of a sticky wicket; in my opinion the use of EHR data in research should be an agent for individuals having clearer ownership of their data; at the moment the EDC vendor, Investigator and Sponsor probably all consider the data captured as part of a study as 'their' data.
I understand where this extension may have come from; Clinical Research domains are always qualified with context (study, site, subject and temporal) - I suspect people are wanting to have a one stop shop for that context in a resource instance.

John Moehrke (Dec 07 2018 at 14:06):

I'm assuming (from the perspective of provenance) that the downstream research system would keep a record of the source datapoint (Resource, attribute and version) - accessing the Resource for the purposes of using in a Research Study should not mutate the resource itself. Data ownership in clinical research is a bit of a sticky wicket; in my opinion the use of EHR data in research should be an agent for individuals having clearer ownership of their data; at the moment the EDC vendor, Investigator and Sponsor probably all consider the data captured as part of a study as 'their' data.
I understand where this extension may have come from; Clinical Research domains are always qualified with context (study, site, subject and temporal) - I suspect people are wanting to have a one stop shop for that context in a resource instance.

I agree. And this is one usecase that we used in the design of Provenance. Specifically using Provenance in the way it is designed, pointing at the data, it will not get in the way of the clinical trial algorithm analysis; but is always there to enable proof of provenance and authority to use. Note that one only needs one Provenance instance to cover an extraction of data. That Provenance would describe the extraction, and point (.target) at ALL of the data extracted. Further Provenance.policy can point at the documentation for that authorized extract... Would love to see this profiled, and added to the specification. As the owner of Provenance, I welcome this..

Lloyd McKenzie (Dec 11 2018 at 02:24):

Whether the search parameter is necessary depends on what you're trying to do. If you start from ResearchSubject and navigate to Patient you'll be able to easily find all information associated with the patient - but not all information associated to the patient will necessarily have been deemed relevant to the study. And if you want to filter to only see study-relevant data, you'll need to be able to filter based on the extension.

John Moehrke (Dec 11 2018 at 14:17):

The ResearchStudy or ResearchSubject can point at the relevant data.. having the data point at the ResearchStudy or ResearchSubject is not proper REST. Modifying the medical data to add a pointer to ResearchStudy will affect the medical-record integrity. We should have one model, that which has ResearchStudy or ResearchSubject pointing at the relevant data.
I would recommend looking at Consent, as the Consent resource is designed to support pointing at explicit data, referencing kinds of data, and referencing tagged data. Any logic that a research study needs is also needed in Consent, so lets make improvements there if you need them. The Consent resource has within scope the support of Clinical Research. Both in recording participation agreement, and in recording authorization to access data. (Likely two related instances given the different activity being authorized).
I will argue further that ResearchStudy and ResearchSubject should not duplicate this, but rather leverage Consent. These resources do reference Consent, but they must utilize that consent's .provisions rather than inventing another model of identifying data that is relevant and authorized.

Lloyd McKenzie (Dec 11 2018 at 16:04):

We have two guidelines for the direction of relationships:
1. The record created second should point to the record created first
2. The many should point to the one
If you're recording an Observation, an AdverseEvent or any other record and want to say "this is related to Study X", both of those rules mean that the Observation, AdverseEvent or other resource should point to the study, not the other way around.

Lloyd McKenzie (Dec 11 2018 at 16:04):

Consent is completely separate from the determination of whether a particular record is considered "relevant" to a particular study.

Matthew Koch (Dec 12 2018 at 14:24):

Whether the search parameter is necessary depends on what you're trying to do. If you start from ResearchSubject and navigate to Patient you'll be able to easily find all information associated with the patient - but not all information associated to the patient will necessarily have been deemed relevant to the study. And if you want to filter to only see study-relevant data, you'll need to be able to filter based on the extension.

Yes, what we are after here is study specific data. My thoughts are that if you are building a RESTful web service, the endpoints exposed have to be descriptive enough for someone to reason about. If I say I want lab result data for my research study returned, I should be able to do that in a reasonably simple way and make sense of the web service URL I am looking at.

An example use case would be exposing an endpoint / query string that looks like this
GET
[base]/observations?researchstudy=12-345&category=laboratory&patient:_has:ResearchSubject:identifier=12345
Where the above is considered "valid."

The server accepting a request like this has to decide what to do with it. Assuming it's set up to appropriately surface data as FHIR resources (bundles, most likely) AND the source system can properly differentiate what is and is not "study specific data", can we do this using FHIR in it's current state? In other words, if this is well documented and expressed in an IG why would it not be considered a satisfactory approach?

Matthew Koch (Dec 12 2018 at 14:26):

I'm assuming (from the perspective of provenance) that the downstream research system would keep a record of the source datapoint (Resource, attribute and version) - accessing the Resource for the purposes of using in a Research Study should not mutate the resource itself. Data ownership in clinical research is a bit of a sticky wicket; in my opinion the use of EHR data in research should be an agent for individuals having clearer ownership of their data; at the moment the EDC vendor, Investigator and Sponsor probably all consider the data captured as part of a study as 'their' data.
I understand where this extension may have come from; Clinical Research domains are always qualified with context (study, site, subject and temporal) - I suspect people are wanting to have a one stop shop for that context in a resource instance.

Re: mutating, I'm not suggesting we alter the underlying data in any way, but isn't this what profiling is for? Creating a set of rules specific to an implementation?

John Moehrke (Dec 12 2018 at 14:44):

Re: mutating... The quality of the data captured during clinical practice is defined by rules of clinical practice. It might have clinical practice defined profiles. But the quality of that data is set by the clinical practice.
when along comes a research project, it must deal with the quality of data that exists. It can't expect that the data can be magically improved. It could filter the data that comes back to it, but I suspect that needs to be a decision of that specific project.
there is a common de-identification processing of that data that could also be done. Is de-identification what you are calling mutating?

Lloyd McKenzie (Dec 12 2018 at 15:11):

We'd need to define a search parameter based on the researchstudy extension, but that seems appropriate. Can you submit a change request for us to define a standard one in R5?

Lloyd McKenzie (Dec 12 2018 at 15:13):

Flagging data as study-relevant isn't mutating. If an EHR is set up to support a clinical study, it's reasonable to expect it to allow new and existing data to be flagged as associated with a study. Alternatively, someone might have to go through and supplement data extracted from the EHR to identify which data is study-relevant. In any case, having the records point to the study is reasonable.

John Moehrke (Dec 12 2018 at 15:54):

well, we disagree... I think the very same task can be done in the ResearchStudy resource to update it to point at the data... Either way some action is happening to identify study-relevant... I am arguing that the evidence of study-relevant seems more logical in the ResearchStudy, than ALL the other data.

Lloyd McKenzie (Dec 12 2018 at 15:57):

That's equivalent to saying we should update the Encounter to point to all data that's relevant to the encounter. It's contrary to our design principles and not terribly practical. The ResearchStudy is going to live on one system and there could be millions of records distributed across hundreds of systems that are relevant to it. There's no way you're going to have the ResearchStudy point to every single one of them.

John Moehrke (Dec 12 2018 at 15:57):

The advantage of the model I am refering to is that your ResearchStudy 'relevance' can be managed against a read-only FHIR api... Yours requires that the FHIR api allow research studies to change data.

Lloyd McKenzie (Dec 12 2018 at 15:59):

Research studies are gathering the data. When you record an Observation that's related to an encounter, you flag it with the encounter. When you record an Observation that's related to a study, you flag it with the study. There's no "change" involved.

John Moehrke (Dec 12 2018 at 15:59):

Your model breaks digital-signatures everywhere (in every clinical data repository)... something you keep bringing up to others when they try to architect something that would break digital signatures. (see your comment seconds ago on a different thread)

Lloyd McKenzie (Dec 12 2018 at 16:01):

Why would it break digital signatures any more than pointing to an encounter. You're assuming that linking to the study is something that happens after-the fact. Generally speaking, it wouldn't

Hugh Glover (Dec 12 2018 at 16:57):

I take the point about ResearchStudy and ResearchSubject needing to take account of Consent, but I think we may be making a mistake in assuming all the consent and relationship happens within the queries. In the conversations I've had the popular suggestion is that the "owners" of the EHR will stand up a FHIR server that delivers what the clinical trial is allowed to see. The only "pointing" of one set of data to another that will happen is indirectly by getting a number of shared references of varying sorts. Once the data is acquired it will be assembled into a new database that can create whatever associations it wants.

Lloyd McKenzie (Dec 12 2018 at 17:02):

And what they're allowed to see is distinct from what's been linked to the study. The extension supporting linking to the study actually allows differentiation between what records were created because of the study vs. what's been deemed as study-relevant.

Lloyd McKenzie (Dec 12 2018 at 17:03):

As a side point, the issue of linking things after the fact is no different for studies than it is for episodes or encounters. Existing records sometimes need to be updated to point to those things too. If you're in a digital signature world, that's going to present some complexities, but they're far less than the complexity of trying to update the Encounter every time someone takes a blood pressure.

Hugh Glover (Dec 12 2018 at 17:18):

Yes we need to keep clear that having something specifically done for a study does not say anything about who is allowed access to that data.

Matthew Koch (Dec 12 2018 at 22:05):

We'd need to define a search parameter based on the researchstudy extension, but that seems appropriate. Can you submit a change request for us to define a standard one in R5?

@Lloyd McKenzie
Here's where I'm confused, see here:
1C4CD798-2FCD-4315-B0A0-87BC33B31F51.jpeg

Lloyd McKenzie (Dec 12 2018 at 22:16):

Right. The extension that does the linking exists in the core spec. However, there's no SearchParameter in the core spec to let you search based on that extension - and that's what you're looking for. You're free to define your own search parameters, but if you want a standard one, you'll need to submit a change request.

Geoff Low (Dec 14 2018 at 13:56):

In general, I'm not sure attaching a reference from a ResearchStudy to a resource makes sense; in the majority of the cases the resources (be they Observations, Conditions, MedicationAdministration/MedicationStatement) are captured into source system, entirely unrelated to their use in a clinical study. I agree we need to associate these resources to a clinical study, but my inclination is still to do it through the lens of the ResearchSubject.

Could we have something like a ResearchCarePlan associated with the ResearchSubject that, once the resource has been associated to a given study (by some clinical adjudication), is linked via a supportedBy attribute or similar. That could also link to the signed consent agreement or similar. Maybe the reference could also include the profile in the URI so any data ablation before retrieval (eg Patient MRN should not be shared with a research consumer) could be achieved.

I wonder if attaching the researchStudy to the resource itself could end up leaking details about other studies ongoing? Just a thought

Lloyd McKenzie (Dec 14 2018 at 18:12):

You can use the existing 'basedOn' relationship to point to a study-specific CarePlan. Leakage can be an issue regardless of the type of link - e.g. Encounter or EpisodeOfCare. That's managed by data filtering based on permissions, not through centralized management of links.

Christiaan Knaap (Dec 17 2018 at 07:03):

@Matthew Koch :
Defining the searchparameter means:
- create a SearchParameter resource, in your favorite editor, in XML or JSON
- fill out the required fields, most notably type (reference), target (Observation) and expression.
- expression is FhirPath, you can experiment with e.g. https://github.com/brianpos/FhirPathTester
- your expression would look something like 'Observation.extension.where(url='http://hl7.org/fhir/StructureDefinition/workflow-researchStudy').value', but I haven't tested it.
- add it to the server.
As I happen to know most about Vonk, here's how to do it there:
- add to a running instance with the Administration API
- or administer your SearchParameter (along with your profiles, examples and IG) on Simplifier and connect the two.

Matthew Koch (Dec 19 2018 at 14:35):

@Matthew Koch :
Defining the searchparameter means:
- create a SearchParameter resource, in your favorite editor, in XML or JSON
- fill out the required fields, most notably type (reference), target (Observation) and expression.
- expression is FhirPath, you can experiment with e.g. https://github.com/brianpos/FhirPathTester
- your expression would look something like 'Observation.extension.where(url='http://hl7.org/fhir/StructureDefinition/workflow-researchStudy').value', but I haven't tested it.
- add it to the server.
As I happen to know most about Vonk, here's how to do it there:
- add to a running instance with the Administration API
- or administer your SearchParameter (along with your profiles, examples and IG) on Simplifier and connect the two.

Thanks for this. How would you reference the fact that you are using a custom SearchParameter in an IG?

Geoff Low (Dec 20 2018 at 08:42):

@Matthew Koch - have you connected with @Hugh Glover ? I know he wants to talk to you about this - if there's going to be a research IG it should be shepherded by the BR&R group.

Matthew Koch (Dec 20 2018 at 12:41):

Sorry for the slow response here. I'll do my best to reply.

Ever since FHIR became a part of the discussion internally, we've been trying to find ways to best leverage the technology, both as defined in the spec and via the quite robust extensibility mechanisms FHIR offers. We have a specific use case around data sharing we are trying to build out. I feel that the best way to communicate expectations and give general guidance about how we intend to accomplish this is via an IG. As I understand it, this need not be something that aspires to cover all research cases, but could be scoped to a specific problem or application. To be fair this could probably be outlined better in what we've got so far. That being said, can I hear from you both, or anyone else seeing this, if a governing body or group is required to oversee all IG creation for a given domain? I'll also note that we are attempting to describe how we intend to use FHIR given the current state of the platform and the tools available, not necessarily shape future change to the core specification.

John Moehrke (Dec 20 2018 at 13:59):

An IG can be writen by anyone anywhere. If you write your IG inside the HL7 organization, then HL7 rules apply. If you write your IG in the IHE organization, then IHE rules apply. If you write your IG within your household, ... Most visible case is Argonaut, which was a bunch of providers and vendors that got together because they had a common goal. Standards organizations like HL7 and IHE add a governance and transparency that has benefits to your IG being used by others outside of those writing your IG. Having written an IG in a closed group does not forbid you from bringing it to a standards organization, however that standards organization will then apply their governance and transparency, which might very much produce a different IG. (Like Argonaut has now become US-Core). So anyone wanting an IG does need to weigh their ability to gather the proper experts to get best accuracy, vs using a standards group (HL7, IHE) to get the most broadly re-usable.
To your question of scope. The best IG are very focused on a tight set of use-cases. It is far better to start too constrained, and later relax rules. Plus starting with a tightly constrained use-case will usually get people more passionate about that use-case. As long as your experts are all excited about solving for that tightly constrained use-cases.

Lloyd McKenzie (Dec 20 2018 at 16:20):

In the end, the scope of the IG determines the size of the community it applies to and the effort to get consensus from (and adoption by) that community. Standards organizations can sometimes help that process, but not always. Whether it works best to start small and grow or start broad and tighten if necessary can also vary depending on the community. Sometimes you can do both in parallel. FHIR doesn't dictate an approach.

Geoff Low (Dec 20 2018 at 23:52):

And I don't think it should dictate an approach; I've seen enough solving the same problem in different locations in the CR realm (with the corollary being it never really gets solved, but a bunch of people are setup in consulting for life) - I think for something so pivotal we should have a best foot forward approach. We've had EHR use as a 'nice-to-have-someday' with eSource as a first class citizen in Clinical Research. I don't want difficulty in choosing the one true path to get in the way of this happening. TBH it may be a difficult task to motivate the BR&R group sufficiently - they have a number of irons in the fire (excuse the pun) - but I think with enough motivating from some key opinion(ated) leaders we should be able to get some momentum. Just my $0.02

Matthew Koch (Jun 20 2019 at 14:20):

Hi @Christiaan Knaap - Thanks again for the outline of how to define a search param earlier in this thread. I was looking at the "expression" piece. Would it not just be Observation.extension('http://hl7.org/fhir/StructureDefinition/workflow-researchStudy') ? Then, in the URI, we'd have something like api/observations?researchstudy=XXXX - do I need the extra bits (using where / .value) / etc?

Matthew Koch (Jun 20 2019 at 17:56):

I just validated in the FHIRPath utility you linked and your expression is good to go :) Thanks. I think I just needed some practice with FHIRPath.

Matthew Koch (Oct 29 2019 at 12:05):

Hello again! Is there a way to represent that a ResearchSubject is being treated at a specific “Site”, (which is linked on ResearchStudy) or would this be done through Encounter somehow? @Lloyd McKenzie

Lloyd McKenzie (Oct 29 2019 at 14:03):

Typically each "study site" will have their own ResearchStudy instance that reflects what's happening at that particular site and will have its own status (one study site might still be recruiting, another might not). The StudySubject would be tied to the site-specific ResearchStudy and those would then be aggregated within the overall ResearchStudy. @Hugh Glover @Rik Smithies

Matthew Koch (Oct 31 2019 at 12:08):

Thats interesting. Is that how this is handled in the BR&R group ? @Hugh Glover @Myron Finseth @Boris Brodsky

Hugh Glover (Nov 01 2019 at 10:57):

It is theoretically correct, but there is a lot of push back from people about using the ResearchStudy resource to represent a site. It doesn't make sense to most people. I think the solution may be to create a ResearchSite profile of ResearchStudy. With that proviso Lloyd is correct that each "site" may have its own version of many things that start off as being at an overall study level - protocol version, recruitment targets etc etc.

We are also expanding the definition of status on the ResearchSubject to allow better representation of the subject journey through the milestones and associated statuses. I don't think we have it quite right yet, but there may be something committed to the current build on this today.

Last updated: Apr 12 2022 at 19:14 UTC