Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

guidance on client caching questionnaire content #22

Open
kjohnsen-epic opened this issue Jul 1, 2024 · 1 comment
Open

guidance on client caching questionnaire content #22

kjohnsen-epic opened this issue Jul 1, 2024 · 1 comment
Labels
architecture guidance Architectural Guidance

Comments

@kjohnsen-epic
Copy link

kjohnsen-epic commented Jul 1, 2024

Related to some of the language on https://build.fhir.org/ig/HL7/davinci-dtr/OperationDefinition-questionnaire-package.html-
We were designing a provider side data model for DTR, and the example $questionnaire-package responses I’ve been looking at so far have been from 5 to 500kb, which is more than enough that I wouldn’t want to simply store everything.

To deal with that I’ve been trying to understand what message content is safely cacheable / reusable. The ones I’ve been considering so far are:

  • If I see Questionnaire URL + version + status=active, I think it’s safe to store that only once and reuse it in future exchanges, since services can’t change the content at that point. For example I store “MCG Knee Replacement v2” once instead of every time.
  • Same for Library URL + version + status. For example I store “FHIRHelpers v4” once instead of every time.

Are my assumptions correct there, and should we include guidance to this effect?

Are there other cacheable pieces?

@kjohnsen-epic
Copy link
Author

Talking to Bryn, he mentioned we should have guidance, but it needs to be taken on a case-by-case basis:

  1. Questionnaires may be modular, meaning they potentially have different assemblies depending on whether the references are versioned
  2. ValueSets may be definitions or expansions (or both, and potentially multiple expansions) so we need a way to both distinguish and assure fit
  3. Libraries may be computable, executable, or both

@brynrhodes brynrhodes added the architecture guidance Architectural Guidance label Jul 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture guidance Architectural Guidance
Projects
Development

No branches or pull requests

2 participants