FHIR Chat · docs / Issue #37 Prefetch as Parameters · cds hooks

Stream: cds hooks

Topic: docs / Issue #37 Prefetch as Parameters

---

Github Notifications (May 05 2017 at 03:59):

euvitudo opened Issue #37

I would like to suggest that Prefetch be defined as a Parameters resource. This way we can include any kind of resource, including OperationOutcomes, esp. for those pre-fetch requests that fail. This would also increase the flexibility in specifying the type of parameter value (i.e., value[x], resource
or part), including not limiting the parameter value to a resource.

Github Notifications (May 05 2017 at 04:10):

euvitudo edited Issue #37

I would like to suggest that Prefetch be defined as a Parameters resource. This way we can include any kind of resource, including OperationOutcomes, esp. for those pre-fetch requests that fail. This would also increase the flexibility in specifying the type of parameter value (i.e., value[x], resource
or part), including not limiting the parameter value to a resource.

Github Notifications (May 05 2017 at 04:32):

euvitudo edited Issue #37

I would like to suggest that Prefetch be defined as a Parameters resource. This way we can include any kind of resource, including OperationOutcomes, esp. for those pre-fetch requests that fail (to possibly address a comment by @Josh Mandel in #5 ). This would also increase the flexibility in specifying the type of parameter value (i.e., value[x], resource
or part), including not limiting the parameter value to a resource.

Github Notifications (May 05 2017 at 15:55):

jmandel commented on Issue #37

I'm not sure I follow. You're describing changes to the "request", but the desired behavior (like "including OperationOutcomes") is about the response. Could you show an example of what you mean @Phillip Warner? For example, could you translate the following?

``
{
"id": "http://hooks.fhir.me:8082/cds-services/patient-hello-world",
"url": "http://hooks.fhir.me:8082/cds-services/patient-hello-world",
"enabled": true,
"hook": "patient-view",
"prefetch": {
"patientToGreet": "Patient/{{Patient.id}}",
"recentSBP": "Observation?patient={{Patient.id}}&code=8480-6&_sort:desc=date&_limit=1"
}
}

In this example, it's perfectly possible for the server to respond with a Patient resource for the `patientToGreet` and an OperationOutcomes if the `recentSBP` fails (or a bundle, if things work; and the bundle can also include an OperationOutcome in Bundle.entry where mode=`outcome`, if the request worked but the server has some outcome notes to share).  
~~~

Josh Mandel (May 05 2017 at 15:58):

(For those following along here in zuip: Note that I' updated my response in github to ask a more precise set of questions.)

Github Notifications (May 05 2017 at 16:27):

euvitudo commented on Issue #37

This is specifically with the request to the CDS Service. In #5 you mention:

CDS Services need a clear way to tell the difference between "this query wasn't run by the EHR as part of prefetch" vs. "the query was run and returned no results, or an error".

For example (not a very good example, but it conveys the intent of the suggestion), if you have an invalid patient id (the prefetch fails on this) you then submit the following to the CDS Service:

{
  "hookInstance": "d1577c69-dfbe-44ad-ba6d-3e05e953b2ea",
  "fhirServer": "http://hooks.smarthealthit.org:9080",
  "hook": "patient-view",
  "redirect": "http://hooks2.smarthealthit.org/service-done.html",
  "user": "Practitioner/example",
  "context": [

  ],
  "patient": "1288992",
  "prefetch": {
    "patientToGreet": {
      "response": {
        "status": "400 Not Found"
      },
      "resource": {
        "resourceType": "OperationOutcome",
        "id": "15060",
        "issue": [
          {
            "severity": "warning",
            "code": "informational",
            "details": {
              "text": "Resource request returns no results.",
              "coding": [
                {
                  "system": "urn:oid:1.2.3.4.5",
                  "code": "1234",
                  "display": "Resource request returns no results."
                }
              ]
            }
          }
        ]
      }
    }
  }
}

If, however, you're using a Parameters, this would look like:

{
  "hookInstance": "d1577c69-dfbe-44ad-ba6d-3e05e953b2ea",
  "fhirServer": "http://hooks.smarthealthit.org:9080",
  "hook": "patient-view",
  "redirect": "http://hooks2.smarthealthit.org/service-done.html",
  "user": "Practitioner/example",
  "context": [

  ],
  "patient": "1288992",
  "prefetch": {
    "resourceType": "Parameters",
    "parameter": [
      {
        "name": "patientToGreet",
        "resource": {
          "resourceType": "OperationOutcome",
          "id": "15060",
          "issue": [
            {
              "severity": "warning",
              "code": "informational",
              "details": {
                "text": "Resource request returns no results.",
                "coding": [
                  {
                    "system": "urn:oid:1.2.3.4.5",
                    "code": "1234",
                    "display": "Resource request returns no results."
                  }
                ]
              }
            }
          ]
        }
      }
    ]
  }
}

Using this, a CDS Service can use a well-known format for understanding the failed prefetch operation and take appropriate action.

As a further note, the Discovery might look like this:

{
  "services": [
    {
      "hook": "patient-view",
      "name": "Static CDS Service Example",
      "description": "An example of a CDS service that returns a static set of cards",
      "id": "static-patient-greeter",
      "prefetch": {
        "resourceType": "Parameters",
        "parameter": [
          {
            "name": "patientToGreet",
            "valueString": "Patient/{{Patient.id}}"
          },
          {
            "name": "medications",
            "valueString": "MedicationOrder?patient={{Patient.id}}"
          }
        ]
      }
    }
  ]
}

Github Notifications (May 05 2017 at 16:42):

jmandel commented on Issue #37

Thanks - I see what you're describing now! Could you help me understand what you see as the benefits of this approach?

Github Notifications (May 05 2017 at 18:10):

euvitudo commented on Issue #37

• Using Parameters is similar with the current prefetch definition (discovery and request) specified in the existing CDS Hooks API, and provides a richer set of semantics for reasoning about potential errors, empty responses, etc.
• The ability to explicitly convey a datatype, a Resource, or a multi-part parameter; explicit types are easier to reason about.
• It is more consistent with Clinical Reasoning, as they use Parameters to pass input.

Github Notifications (May 05 2017 at 18:41):

jmandel commented on Issue #37

OK. For history here: we used to use Parameters for _all CDS Hooks operations_, and after careful evaluation, we decided they were verbose and not providing a lot of value...

Github Notifications (May 05 2017 at 18:48):

kpshek commented on Issue #37

Thanks for the additional details @Phillip Warner.

@Josh Mandel is correct that we haven't used the Parameters resource, having made this change a year ago.

Regarding Clinical Reasoning, @brynrhodes, @Isaac Vetter, and myself have been working together for the past several months to see how we can better align both projects. We'll be posting a write-up for our proposals to the two communities for feedback which aims to address your comment on the two projects.

As an aside, and I know you called this out as not a good example , but we should never see a 404 on a patient prefetch for a patient-view hook. Since the EHR is in complete control in this use case, not finding the patient whose chart the clinician just opened would be a major issue.

Github Notifications (May 05 2017 at 18:50):

kpshek edited Issue #37

I would like to suggest that Prefetch (in CDS Request) be defined as a Parameters resource. This way we can include any kind of resource, including OperationOutcomes, esp. for those pre-fetch requests that fail (to possibly address a comment by @Josh Mandel in #5 ). This would also increase the flexibility in specifying the type of parameter value (i.e., value[x], resource
or part), including not limiting the parameter value to a resource.

---

Last updated: Apr 12 2022 at 19:14 UTC