Details
-
Change Request
-
Resolution: Not Persuasive
-
Medium
-
US Da Vinci DTR (FHIR)
-
1.0.0 [deprecated]
-
Clinical Decision Support
-
Persisting Results [deprecated]
-
-
Bob Dieterle / Ben Hamlin : 12-0-2
Description
We should list the 'preferred' solution first - i.e. saving a QuestionnaireResponse. There should also be documentation that explains that if you're saving a QuestionnaireResponse, that saving a 'completed' QR is exactly the same as saving a work-in-progress. The only difference is that the status is 'completed'. (There's no need for any additional documentation/explanation.) The bit " and/or as a human readable format that is supported by the EHR" needs to be removed. If you're storing a QuestionnaireResponse, then it's a proper FHIR resource with the relevant extensions. If you can't do that, then you're using the DocumentReference approach.
The less-preferred solution should indicate that it's a follow-on from storing work-in-progress on the payer as a DocumentReference and that we use a different approach for interim content than final content because final content must be stored as a non-computable PDF. It should be explained that a human will have to figure out how to link the PDF to the relevant order as per whatever convention is used by the EHR - unless a custom convention has been worked out between the EHR and the SMART App.
A bare QuestionnaireResponse is never persisted on the payer system. The only thing stored in the payer is the DocumentReference that contains the base-64-encoded Questionnaire.
Formal transmission of the QuestionnaireResponse (or PDF version of it) happens as part of PAS or an X12 claim, not a RESTful POST.