FHIR Chat · HAPI's QuestionnaireResponse `questionnaire` query param? · Argo Patient Lists

Stream: Argo Patient Lists

Topic: HAPI's QuestionnaireResponse `questionnaire` query param?

Isaac Vetter (Aug 28 2020 at 21:33):

Hey Guys, Playing around with Hapi's Questionnaire/Response. Eric pointed out that questionnaire is a standard search param on the QuestionnaireResponse resource ... and therefore we could eliminate the proposed second extension in Group.member.entity.extension which concretely defines a QuestionnaireResponse for each patient in the group.

Josh Mandel (Aug 28 2020 at 21:34):

Instead issuing a series of searches?

Josh Mandel (Aug 28 2020 at 21:35):

Can you provide an example of what this would look like?

Isaac Vetter (Aug 28 2020 at 21:36):

So, I created a Questionnaire and a QuestionnaireResponse in HAPI, but the ?questionnaire query param doesn't work. I strongly suspect that the problem is user error, but I'm not sure what it is.

Any suggestions?

Isaac Vetter (Aug 28 2020 at 21:37):

Hey Josh! Happy Friday! I do have examples of the two extensions in which Group.member.entity.extension concretely associates a QR with a Patient. The alternative would be a Group like this:

Isaac Vetter (Aug 28 2020 at 21:38):

{
  "resourceType": "Group",
  "extension": [
    {
      "url": "http://registry.fhir.org/argonaut/patientlistsquestionnairev1",
      "valueReference": "http://hapi.fhir.org/baseR4/Questionnaire/1169270"
    }
  ],
  "identifier": [
    {
      "system": "http://example.org",
      "value": "dba0a9f9-82cb-4d42-ad92-3250756a9420"
    }
  ],
  "active": true,
  "type": "person",
  "actual": true,
  "name": "ICU List",
  "managingEntity": {
    "reference": "Organization/example-organization-2",
    "display": "Dairyland Hospital"
  },
  "member": [
    {
      "entity": {
        "identifier": {
          "system": "http://example.org",
          "value": "456"
        },
        "display": "Name = Daniel Crimson (MRN = 456)",
      },
      "inactive": false
    },
    {
      "entity": {

Isaac Vetter (Aug 28 2020 at 21:39):

and a follow-up query like:

QuestionairreResponse?questionnaire=1169270

which, per FHIR should return all of the QuestionnaireResponses for that Questionnaire (but which HAPI is not).

Josh Mandel (Aug 28 2020 at 21:49):

Are you saying the API guarantee would be that this questionnaire is only ever used with this specific list? So if I had three lists of patients and I wanted to fill in the same information about all of them I would define three different questionnaires with identical content? I can see how one might thread this needle but it is a little bit surprising and fragile, since normally we think about a questionnaire as being reusable.

Isaac Vetter (Aug 28 2020 at 21:51):

Yeah.

Eric Haas (Aug 30 2020 at 00:55):

@Josh this measns the url is unique for each group. We can define the Q as being derivedfrom a standard Q. Let me review how we did this for adaptive Questionnaires. I personally think this simplication is worth it . Just fetch the whole gaggle of QAs. Why is it fragile? The server needs to do all the work on the back end in either case.

Josh Mandel (Aug 30 2020 at 01:01):

Fragile in the sense that many servers can't enforce an invariant like "never allow Questionnaire 123 to be answered except for patients currently in Group 456".

Josh Mandel (Aug 30 2020 at 01:03):

Like, there's no good way to enforce this (in sync, consistently) as groups and memberships change.

Josh Mandel (Aug 30 2020 at 01:05):

(re: tracking the relationship among multiple questionnaires derived from the same core content, yes http://build.fhir.org/questionnaire-definitions.html#Questionnaire.derivedFrom can capture this.)

Eric Haas (Aug 30 2020 at 01:32):

I'm trying to find a way to avoid two extensions. All you need is a Q and a patient id. . Why do we need a QR ref? I doubt very much the QR is made ahead of time and stored for later use/fetching. Assuming the server create the QRs on the fly, the server needs to index the patients to Q somehow anyway.

Eric Haas (Aug 30 2020 at 01:36):

sooooo. why not fetch QR based on URL and Patient ?

Josh Mandel (Aug 30 2020 at 01:41):

Questionnaire Url and patient? That sounds fine -- I thought the proposal was to omit patient from the query.

Eric Haas (Aug 30 2020 at 01:41):

although answering my own questions. The QR ids are basically a way to index this and expose to client. So I guess is "moving the deck chairs"

Eric Haas (Aug 30 2020 at 01:44):

Well my initial thought was to do that, but if as you suggest syncing this is problematic then can do the Patient + Q url. query. I guess will find out whether 2 extensions or 1 is more palatable for servers.

Isaac Vetter (Sep 01 2020 at 22:19):

The reason to not fetch QR with both questionnaire and patient id is performance. I want/need to be able to query for many QR at once. I agree that the certainty provided by the second extension in the Group (pointing to a QR per patient) makes an integration less brittle. That's what we're prototyping out.

Josh Mandel (Sep 01 2020 at 22:30):

We could also supply a list of patient IDs in the query.

Josh Mandel (Sep 01 2020 at 22:30):

Or a batch of queries.

Eric Haas (Sep 01 2020 at 23:23):

I've come full circle and see the utility of exposing the QR for each patient. I have a basic client that doew a the simple stuff - trying to get it deployed and hope to dig into the Q an QR stuff soon.

Last updated: Apr 12 2022 at 19:14 UTC