FHIR Chat · Representing status with Task resource

Stream: bulk data

Topic: Representing status with Task resource

Josh Mandel (May 06 2019 at 04:44):

I just went through the exercise of trying to represent the example status response from http://hl7.org/fhir/R4/async.html#3.1.6.4.0.4 with the Task resource. I can't say I'm psyched about it, and none of our ballot commenters requested a change to the status representation.

{
  "resourceType": "Task",
  "status": "in-progress",
  "intent": "order", // this seems really wrong, but it's required
  "executionPeriod": {
    "start": "[instant"],
    "end": "[instant]"
  },
  "extension": [{
    "url": "http://hl7.org/fhir/StructureDefinition/async-request-url",
    "valueUrl": "[base]/Patient/$export?_type=Patient,Observation"
  },{
    "url": "http://hl7.org/fhir/StructureDefinition/async-requires-access-token",
    "valueBoolean": true
  }],
  "output": [{
    "type": {
      "coding": [{
        "system": "http://hl7.org/fhir/resource-types",
        "code": "Patient"
      }]
    },
    "extension": [{
      "url": "http://hl7.org/fhir/StructureDefinition/async-request-output-type",
      "valueCode": "output"
    }]
    "valueUrl": "https://serverpath2/patient_file_1.ndjson"
  }, {
    "type": {
      "coding": [{
        "system": "http://hl7.org/fhir/resource-types",
        "code": "Observation"
      }]
    },
    "valueUrl": "https://serverpath2/observation_file_1.ndjson"
  }, {
    "type": {
      "coding": [{
        "system": "http://hl7.org/fhir/resource-types",
        "code": "Observation"
      }]
    },
    "extension": [{
      "url": "http://hl7.org/fhir/StructureDefinition/async-request-output-type",
      "valueCode": "error"
    }],
    "valueUrl": "https://serverpath2/operationoutcome_file_1.ndjson"
  }]
}

Grahame Grieve (May 06 2019 at 10:37):

That's a lit more useful than Task was last time we looked at that. It's possible to support both based on mime types... I'm not sure how useful it is

Lloyd McKenzie (May 06 2019 at 12:54):

Curious about the choice to use extensions rather than additional input/output parameters

Josh Mandel (May 06 2019 at 13:52):

They're "complex" parameters --- each output or error file needs a type, a url, and an indication of whether it includes successful vs error responses (currently we model this as an outputs array and an errors array).

Mohammad Jafari (May 06 2019 at 14:02):

I agree that all the extensions make this look a bit complex and counterintuitive. But we should be able to update the Task resource or profile it to make this easier.
To summarize some of the points from yesterday, using Task resource has the following benefits:
- Using existing FHIR backend (e.g. persistence model) to store and archive results.
- Using versioning on the resource to track change of status and partial results.
- Using FHIR search on Tasks for admin reporting.
- Using Subscription to receive async notifications on partial updates and status changes to the Task resource.
One can even bulk export all the Tasks for analytics on the history of all previous bulk exports :P

Grahame Grieve (May 06 2019 at 14:03):

:thumbs_up: only for the last line !

Josh Mandel (May 06 2019 at 15:05):

I think the brass-tacks question is whether we'd contemplate making this change to "bulk data" particularly -- or just try to work with FHIR r5 to make this kind of change. (My strong leaning is: address this in fhir R5 core infrastructure.)

Grahame Grieve (May 06 2019 at 15:09):

we could make space for this by making some note about the use of mime type when requesting this thing?

Josh Mandel (May 06 2019 at 15:10):

In other words, a note like "future versions of fhir may require a fhir-specific mime type for async requests"?

Josh Mandel (May 06 2019 at 15:11):

(Ideally I was expecting we'd remove most of the details about how async requests work from the bulk data IG, deferring to definitions in FHIR R4+.)

Josh Mandel (May 06 2019 at 15:12):

we'd still have examples, but a lot of the duplicative content with fhir R4 async.html would be stripped.

Grahame Grieve (May 06 2019 at 15:19):

well I agree about that. But we can say things in the IG that are ahead of R5. I was more thinking of some statement like 'future versions this specification or the base FHIR specification may describe the use of other mime types as options and/or replacement for this json object"

Josh Mandel (May 06 2019 at 15:24):

Perfect -- will capture this.

Mohammad Jafari (May 06 2019 at 19:57):

What would the mime type look like for Task vs. the current JSON result format? Which one are we expecting to be associated with application/fhir+json?

Josh Mandel (May 06 2019 at 20:07):

In future state, if R5's async.html documents Task as the status response, it'd use application/fhir+json.

nicola (RIO/SS) (May 06 2019 at 20:59):

it's much easier to mix things than "unmix" them later, i think it's false-similarity

Josh Mandel (May 07 2019 at 17:52):

Is there something else you'd propose @nicola (RIO/SS) ?

nicola (RIO/SS) (May 07 2019 at 20:11):

@Josh Mandel Nothing new - just specialized resource for this specific operation - i.e. turn current JSON result into Resource

Josh Mandel (May 07 2019 at 20:22):

Gotcha -- that's clear enough, thanks!

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Representing status with Task resource · bulk data