Stream: questionnaire
Topic: Autopopulation - why does the EHR need to map questions?
Isaac Vetter (Apr 26 2018 at 14:08):
Hi Everyone,
Epic implemented the IHE RFD profile many, many years ago. Like the FHIR SDC IG, the basic workflow is that the EHR bundles up patient data (in a CDA) and pushes that data to the questionnaire/form owner when the form is requested. This allows the manager of the form to pre-populate some questions with data from the CDA/Bundle.
Ultimately, our implementation of RFD has seen surprisingly limited implementations for a few reasons:
1) There's too much data - the EHR sends all the data, not just what the form needs. Especially for inpatient, our CCDs can be massive, slowing down the process of generating, transmitting and parsing the document.
2) It's not the right data. Any given form/questionnaire only needs a small number of very specific data elements. As the form changes or the EHR's support of the standard data model (CDA, FHIR, etc) increases, the EHR must adjust what it sends.
I think that CDS Hooks handles these problems well because the responsibility for gathering and mapping data is owned by the system that knows and controls what data is needed (the external cds service). The analogy is that the form owner should be querying the FHIR server to gather data. The Form Filler ought not to be responsible for interpreting the information needed by the form that it doesn't own.
Can the form manager be enabled to query the form filler's FHIR server in lieue of the form filler attempting to map and provide the data up front?
Isaac
Lloyd McKenzie (Apr 26 2018 at 17:17):
We're going to be talking about better approaches to pre-population/auto-population with the SDC project shortly after cologne. One of the possibilities is to allow a Questionnaire to define a Batch of queries that could be executed that would provide the data needed (partially?) populate the form. Whether the client would take it upon itself to run the queries and then invoke the "populate" operation passing in the Bundle, or whether the form filler would do a call-back to invoke the queries, I'm not sure. Perhaps there'd be use-cases for both approaches.
Brian Postlethwaite (Apr 26 2018 at 21:22):
That's exactly the approach that we've implemented with custom extensions @Lloyd McKenzie , and works pretty well to date.
We pass the Questionnaire resource to the FHIR server along with the smart on fhir context to populate and return as a QuestionnaireResponse.
This was the FHIR server is able to run only the queries that it needs to for extracting the data, and nothing else apart from what was explicitly asked for is returned.
Brian Postlethwaite (Apr 26 2018 at 21:23):
Happy/keen to discuss this in Cologne if it comes up.
Isaac Vetter (Apr 27 2018 at 14:25):
Hey @Brian Postlethwaite - If you get a chance, would you mind explaining this a bit more:
pass the Questionnaire resource to the FHIR server along with the smart on fhir context
I'm not a fan of the SDC actor terminology, but for the hope of clarity -
1) The Form Filler requests the questionnaire from the Form Manager.
2) The Form Manager responds to this request with the FHIR Questionnaire as well as a SMART json object (incl. context and access_token).
3) The Form Filler queries the FHIR server to auto-populate the form.
4) The user completes the form. The Form Filler system POSTs the QuestionnaireResponse to the Form Receiver.
Did I get that right?
Which SDC actor is the FHIR server? the OAuth server?
Isaac
Grahame Grieve (Apr 27 2018 at 23:57):
"The Form Manager responds to this request with the FHIR Questionnaire as well as a SMART json object " - not my expectation. why would the form manager have a smart json object - a json object that says what about what?
Grahame Grieve (Apr 27 2018 at 23:58):
I would expect that there are multiple fhir servers in play here - the form manager, the form filler's data store(s), and the form reciever
Grahame Grieve (Apr 27 2018 at 23:58):
might have to oauth to all of them
Alex Goel (May 02 2018 at 18:36):
Hi Everyone,
Epic implemented the IHE RFD profile many, many years ago. Like the FHIR SDC IG, the basic workflow is that the EHR bundles up patient data (in a CDA) and pushes that data to the questionnaire/form owner when the form is requested. This allows the manager of the form to pre-populate some questions with data from the CDA/Bundle.
Ultimately, our implementation of RFD has seen surprisingly limited implementations for a few reasons:
1) There's too much data - the EHR sends all the data, not just what the form needs. Especially for inpatient, our CCDs can be massive, slowing down the process of generating, transmitting and parsing the document.
2) It's not the right data. Any given form/questionnaire only needs a small number of very specific data elements. As the form changes or the EHR's support of the standard data model (CDA, FHIR, etc) increases, the EHR must adjust what it sends.I think that CDS Hooks handles these problems well because the responsibility for gathering and mapping data is owned by the system that knows and controls what data is needed (the external cds service). The analogy is that the form owner should be querying the FHIR server to gather data. The Form Filler ought not to be responsible for interpreting the information needed by the form that it doesn't own.
Can the form manager be enabled to query the form filler's FHIR server in lieue of the form filler attempting to map and provide the data up front?
Isaac
Hi Isaac,
This is a great point about RFD, it's simply too limited. However I think that there are use cases where the Form Filler needs to be able to handle the data without interaction from the Form Manager. E.g. if your Form manager is a jurisdictional form manager providing data to multiple sites, you probably don't want to unnecessarily send patient data to the Form manager for pre-population. It makes much more sense for the Form filler to pre-populate the form to avoid sharing of patient data.
Alex Goel (May 02 2018 at 18:39):
I would expect that there are multiple fhir servers in play here - the form manager, the form filler's data store(s), and the form reciever
I assumed the expectation was that these would be 3+ separate servers. FM, FF, FR, and a data store hit by the FF. Is "1) The Form Filler requests the questionnaire from the Form Manager." likely a GET or a POST? Is the request a GET, then the response a POST?
Grahame Grieve (May 05 2018 at 04:40):
response - you mean outcome of filling in the form? a post is most likely for me
Last updated: Apr 12 2022 at 19:14 UTC
