Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-37648

Better approach for large lists of participants in Encounter.participants

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • R5
    • Patient Administration
    • Encounter
    • Hide

      PA WGM Jan 2024:

      The Operations for large resources looks good for how we might be able to leverage this in Encounter, however we are still missing:

      • How to detect the large list in the first place - specific exception?
      • How to request the complete list anyway
      • Update the core properties outside the list

      Some examples of properties we expect may get large are:

      • Encounter.participants
      • Encounter.location
      • Account.coverage

       

      There are two options we could consider for allowing a client to detect large resources: (or both/either options at server discretion):

      a) Error/exception

      This should really be a specific error code to be able to (http status?, and op outcome issue type - (http://hl7.org/fhir/issue-type too-long or too-costly?)

      The error/exception approach has implications on searching, as if one resource is too large, that may need to abort the entire search. (an option, though not preferred)

      b) Auto-subset

      If the server decides that the resource is too large to return complete, then the server should return the resource with the subset meta tag (and maybe another meta tag to indicate this specific type of subsetting?), and exclude ANY participants or locations, and the client would require the use of the $filter operation to request the content.

      • How can the client know which property was "too large" - an extention?

      Either of these still don't provide a way for the client to get the large resource.

      Recommend adding additional fields to the $filter operation to support these.

      How do we "limit" the list coming back to something that the client is looking for.

      property (e.g. "Encounter.participant")

      filter - start/end date

      Extension indicating which properties have been filtered

      "Encounter.participant" // at worst include an indexer

      "CodeSystem.concept.concept.concept"

      "Questionnaire.item.item.item"

      The remaining issue is how to update the large resource excluding the large set - is patch the only option - we thought that required the complete retrieval.

      Maybe permit update with subset, provided the extension for the "missing" backbone is indicating it, and then require the $add/ $remove to update the backbone.

      Group currently has no way to update the core elements, or is that use add with nothing to do it.

      Show
      PA WGM Jan 2024: The Operations for large resources looks good for how we might be able to leverage this in Encounter, however we are still missing: How to detect the large list in the first place - specific exception? How to request the complete list anyway Update the core properties outside the list Some examples of properties we expect may get large are: Encounter.participants Encounter.location Account.coverage   There are two options we could consider for allowing a client to detect large resources: (or both/either options at server discretion): a) Error/exception This should really be a specific error code to be able to (http status?, and op outcome issue type - ( http://hl7.org/fhir/issue-type too-long or too-costly?) The error/exception approach has implications on searching, as if one resource is too large, that may need to abort the entire search. (an option, though not preferred) b) Auto-subset If the server decides that the resource is too large to return complete, then the server should return the resource with the subset meta tag (and maybe another meta tag to indicate this specific type of subsetting?), and exclude ANY participants or locations, and the client would require the use of the $filter operation to request the content. How can the client know which property was "too large" - an extention? Either of these still don't provide a way for the client to get the large resource. Recommend adding additional fields to the $filter operation to support these. How do we "limit" the list coming back to something that the client is looking for. property (e.g. "Encounter.participant") filter - start/end date Extension indicating which properties have been filtered "Encounter.participant" // at worst include an indexer "CodeSystem.concept.concept.concept" "Questionnaire.item.item.item" The remaining issue is how to update the large resource excluding the large set - is patch the only option - we thought that required the complete retrieval. Maybe permit update with subset, provided the extension for the "missing" backbone is indicating it, and then require the $add/ $remove to update the backbone. Group currently has no way to update the core elements, or is that use add with nothing to do it.

    Description

      We've run into issues where the participant list of an Encounter can get very large for long stay admissions.  Typically there are a reasonable number of active participants, but there maybe a large number of historical participants.  For example, if a patient has been admitted for a year, the nurses they had in their first weeks of the stay may still be listed with a period.end of a 11 months ago.

       

      There are a few possible approaches we could consider:

      1. Add CareTeam as an allowed type for the participant.actor reference.  Then a system could move the participant list to the CareTeam.  This kinda moves the problem.
      2. Include participants on EncounterHistory, and have guidance that Encounter.participants is just currently active participants.  Though maybe we also want recent and imminent as well?
      3. Other options are welcome

      Attachments

        Activity

          People

            Unassigned Unassigned
            cooper.thompson Cooper Thompson
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: