Stream: research
Topic: Using profiles as Views?
Rob Mulders (Jun 11 2019 at 12:52):
Hi all, I am visiting an academic hospital next week and they have the following question about FHIR: after storing all patients from the EHR in a FHIR-server with profile PatientEHR, they want researchers to be able to fetch a limited set of attributes as defined in their profile PatientResearch. The search should work on the same data as stored via PatientEHR, but returns only the data as described in PatientResearch. Is this possible in FHIR and if yes, where can I find the specs?
John Moehrke (Jun 11 2019 at 13:43):
There is some support being built into FHIR for supporting Research. There is no "PatientResearch", so I can't really understand your question. There is a ResearchStudy that defines a specific project, and a ResearchSubject which is a linkage to a subject. These are early developments so now is a good time to engage to produce a future outcome. You might want to start https://www.hl7.org/fhir/researchstudy.html
Lloyd McKenzie (Jun 11 2019 at 15:49):
It is possible for a FHIR server to "trim" what data elements are exposed based on who's asking and what authorization they (currently) hold. It's also possible to use the '_elements' parameter to filter what elements are returned. However, there isn't currently a way to pass a reference to a profile as part of a query and ask for the server to filter the results such that they comply with the profile. (That's a super-hard problem and quite challenging to do in a generic and performant manner.)
John Moehrke (Jun 11 2019 at 15:59):
because we are using HTTP REST, one can orchestrate multiple services. So one could have a low level service interface that is raw FHIR to a FHIR Server. With an intermediary service that is assembling the result and possibly doing other things like de-identification. etc... by doing it this way you separate concerns and functions while having a consistent API (based on FHIR) between all of the service layers.
Sebastiaan Knijnenburg (Jun 11 2019 at 16:36):
@Rob Mulders There is a pop-up session on exactly this topic this afternoon at the dev-days, that was triggered by the discussions at the last HL7 WGM NL (see https://chat.fhir.org/#narrow/stream/179170-smart/topic/SMART.20for.20research.2Fquality.20purposes). Will keep you posted on the results!
Gustav Vella (Jun 11 2019 at 17:37):
Hi Rob,
the topic of your posting is a bit misleading. I guess it's not a Profile you need but a Composition+Bundle.
Hi all, I am visiting an academic hospital next week and they have the following question about FHIR: after storing all patients from the EHR in a FHIR-server with profile PatientEHR, they want researchers to be able to fetch a limited set of attributes as defined in their profile PatientResearch.
From a compliance perspective, you'd want the researcher requests to be signed off by the local IRB - so you'd define a Composition Resource and a Bundle. It defines explicitly and expressively what you'll be sharing. Ideally write a Clear Implementation guide for that because your IRB will want to understand what you are sharing without having to understand to much about FHIR.
The search should work on the same data as stored via PatientEHR, but returns only the data as described in PatientResearch. Is this possible in FHIR and if yes, where can I find the specs?
You define a FHIR Task to pseudonymize the data and pass it on to a research repository or application. If you use VONK you could also write a plugin to do that. But there are many ways to do that with other tools.
Gustav Vella (Jun 11 2019 at 17:50):
In practice however you might need more than that - you'd usually want to view that data - ideally in the clinical context - before you pass on the stuff to the research domain (possibly in a reporting SMART on FHIR app) and perform a data review.
Also, In practice you'll get big gaps in your structured data and your EMR will have no means of raising that data in the granularity needed by your researchers. So in our case we add additional data points for Unstructured and Semistructured data in a report, prefill the available structured data in the Form App and add the missing data in the Clinical Context.
Gustav Vella (Jun 11 2019 at 17:57):
B.t.w - if you really have to sell the benefits of FHIR to your IRB stakeholders, Data Provenance (Practitioner Info) and History (Autdittrail) - are covered by the FHIR spec Also, you can validate on the basis of the profiles to a certain point on the item value level what's really going through to your research database.
Lloyd McKenzie (Jun 11 2019 at 18:02):
I don't see why you'd need either Composition or Bundle. The IRB would need to sign off on the types of requests allowed (and who could make them), but I wouldn't necessarily expect them to sign each set of information disclosed - nor would you want to force the shared data to have to be a FHIR document. Real-time query and/or Bulk Data would be more appropriate interfaces for sharing.
Gustav Vella (Jun 11 2019 at 18:40):
The IRB would need to sign off on the types of requests allowed (and who could make them),
Exactly but the Scope is defined in my Composition. He just signs that off once for each individual research /shring use case - but not for each instance / request. What he also does is makes sure that the data only gets shared if consent given 'yes' (key part for each research bundle)
Is there any good reason why you would NOT do it that way?
but I wouldn't necessarily expect them to sign each set of information disclosed.
not each instance. but we do have an individual review for each project setup.
nor would you want to force the shared data to have to be a FHIR document.
agree..assumed from Rob's message that they have all in there
Real-time query and/or Bulk Data would be more appropriate interfaces for sharing.
Possibly - have no first hand experience with both approaches yet. Most hospitals I work with don't allow real time queries on their Central FHIR CDR. even from their own local research environment.
Lloyd McKenzie (Jun 11 2019 at 18:50):
The need to sign things doesn't necessarily mean you need Composition. You could easily sign off on a protocol (expressed as PlanDefinition) without bringing FHIR documents into it at all. Generally, I try to avoid the overhead of FHIR documents unless it's strictly needed.
Rob Mulders (Jun 12 2019 at 08:03):
Thanks all for the fast answers! @John Moehrke , in my question PatientResearch is their own defined profile, inheriting things from their own defined PatientEHR, which in turn inherits things from nl-core-Patient from Nictiz, which in turn inherits things from Patient (core). Under PatientResearch their might be a self defined profile for each (set of) study/studies, but only if necessary.
Rob Mulders (Jun 12 2019 at 08:05):
@Gustav Vella like Lloyd says I don't want to go the way of Composition and FHIR documents, because the UMC wants to use Real time REST (for applications like Castor) and Bulk export.
Rob Mulders (Jun 12 2019 at 08:13):
@Lloyd McKenzie you wrote "a way to pass a reference to a profile as part of a query and ask for the server to filter the results such that they comply with the profile is not available" but it would be a killer feature for research! Because in that case, the UMC would be able to use the workflow in Simplifier to ask, grant, deliver, audit and evaluate the whole data sequence for researchers, with full compliance cycle for each different request.
Rob Mulders (Jun 12 2019 at 08:18):
By the way, not only for research, but also for Quality Registers it would be awesome. The QR's in The Netherlands start to publish the definition of their data-requests (like IKNL at https://simplifier.net/Oncolinq), and if they do it the right way (inheriting from the nl-core profiles), we would be one step further in the jungle of data delivery from hospitals to QR's.
Rob Mulders (Jun 12 2019 at 08:25):
@Sebastiaan Knijnenburg thanks, I missed the HL7NL session, but will be there on the next WGM and next DevDays.
Lloyd McKenzie (Jun 12 2019 at 14:11):
@Rob Mulders There's nothing that stops you from defining a custom feature from passing in a profile as a custom search parameter. HL7 has declined to do so as a standard search parameter (and all of the open source implementations have declined to implement such a thing) because it has the potential to be totally evil from a performance perspective. To just filter elements, we already have _elements. Which means that if you want to pass a profile, there's a desire to do more (limitations on bindings, slicing, etc.) Applying those to output results can be super-expensive. The validation process that simply checks for validity against a profile can clock in at a second or more per instance (and it's a super complex set of code). Attempting to manipulate an instance to comply with a profile would be even worse and could be non-computable. As an example, imagine that the instance has 3 Patient.name instances. The query profile demands there be only 1. How is the server supposed to know which one to return?
@Chris Grenz has done some work in this space, but I'm not aware of anyone else who's even tried.
Chris Grenz (Jun 12 2019 at 15:06):
Slowly working on an open source library for extracting search parameters from profiles and then optimizing validation to support the "search by profile" concept. There are some general concepts about how a profile can be used for redaction here: https://github.com/chrisgrenz/FHIR-Primer/wiki/Predictable-Resource-Redaction
Chris Grenz (Jun 12 2019 at 15:07):
Lloyds example is specifically disallowed: "the server will not silently sample an unordered list"
Chris Grenz (Jun 12 2019 at 15:07):
Built a working example of this in the past, but it's not public code unfortunately.
Bram Wesselo (Jun 19 2019 at 09:39):
@Sebastiaan Knijnenburg Any news/results from the dev-days session?
Last updated: Apr 12 2022 at 19:14 UTC
