Handle FHIR QuestionnaireResponse Resource

[sjpadgett]

Describe the feature

As I muddle my way through this whole FHIR Questionnaire implementation, my destination of import is capturing the answer response along with making available the Questionnaire to the FHIR API leading to an example SMART app.

Currently I've implemented FHIR Questionnaire in Portal and Encounters. The encounter implementation saves the answer response to a forms table rather than the questionnaire response table. I wanted to keep the workflow contained to the normal encounter form workflow and patterns for consistency.
For the portal though, I want to follow the same response management that the FHIR API would follow killing two birds one might say.
The hardest part of portal is the user audit. I hope to design a pattern that will be available for reporting to and audit by the original requester of the questionnaire for the API as well. At that point the response is historically saved using the completed status(in-progress | completed | amended | entered-in-error | stopped) and user meta data.

For those interested in the FHIR API, SMART and these features in general, I'd hope they would chime in if having concerns for my approach or questions. The more folks involved the better the outcome IMO.

[sjpadgett]

I'm working on the encounter report which I will also create a vertical table for answers and observations and manage in new QuestionnaireResponse service.

[sjpadgett]

So encounter report is finished:
Form:

Report

[sjpadgett]

Column version which is better IMO

[mdsupport]

@sjpadgett, Have you explored Bootstrap's masonary layout? It seems to offer combination of list and grid.

Re. QuestionnaireResponse - Like EDI, these are documents. So aren't they best stored in either original (xml?) or json format? Since LHC widget includes LOINC validations, it would be good if we are not only able to save the response but are also able to submit a prior response to the widget for editing.

Should we need to search by specific keys, like Couch or other document stores, mysql/maria keeps getting better in their SELECT options.

I understand the current display/edit libraries are based on "layouts" which in a way are closer to HL7v2 while FHIR is exclusively HL7v3. I would humbly suggest that the project start building document oriented code for future.

[sjpadgett]

So aren't they best stored in either original (xml?) or json format?

There are many layers of which lForms is only one. I don't see LOINC panels as necessarily primary for assessments/questionnaires where the main focus is the FHIR Questionnaire resource endpoints. Currently storage strategy is allowing for all the various forms of the resource whether I use lForms to render or a rendering engine I plan to develop. So regardless if I render in lforms or from an endpoint, the questionnaire/response FHIR resource is stored using FHIR json.

Current plan is to import questionnaires as FHIR json from endpoint, file holding the json, LOINC panels, external FHIR server or select a questionnaire from our repository.
The portal can import questionnaires to our repository or auto create a document template to schedule to a portal patient.

Besides storing the FHIR json objects as part of the resource I plan to store question/answers to vertical table for analytics/search.
I'm unsure what you mean by

building document oriented code for future

Maybe you can expand on that.
Attached are some files of various parsing schemes I'm exploring.
parsing_results.zip

[sjpadgett]

all done

[sjpadgett]

Reopen for more to come