Stream: implementers
Topic: Propose to add $everything operation to Careplan
Kenneth Myhra (Feb 21 2022 at 09:17):
Hey!
I haven't done much research on this, but would it be resonable to propose to add the operation $everything to the CarePlan resource?
For example CarePlan/[id]/$everything seems to be a nice addition.
Josh Mandel (Feb 21 2022 at 15:05):
How would you define it?
Kenneth Myhra (Feb 22 2022 at 08:55):
@Josh Mandel I would define it like this:
This operation is used to return all the information related to the CarePlan. The response is a bundle of type "searchset". At a minimum the CarePlan resource itself is returned, along with any other resources that the server has which are releated to the CarePlan, and that are accessible for the given user.
Josh Mandel (Feb 22 2022 at 14:31):
Will there be some guidance about what kind of information ought to be returned? For example if a care plan is related to diabetes care, would this data set include all of a person's at home glucose measurements, laboratory based A1C measurements, diabetes medications, comorbidity risk assessments etc? I'm just trying to get a handle on the level of interoperability you are expecting here.
Kenneth Myhra (Feb 23 2022 at 15:22):
@Josh Mandel I think these are fair questions. Currently we have just been thinking from a technical point of view that it would be nice to get all locally stored references on a CarePlan resolved and included in the searchset bundle. At the moment I do not really have a more concrete use case, maybe @Sven Christiansen could elaborate more on the functional use cases.
Sven Christiansen (Feb 24 2022 at 06:44):
@Josh Mandel I will try to give you some more background information. We are establishing a high level CarePlan that is going to be stored in a national register. The purpose is that this CarePlan shall be “visible” to the Patient himself as well as all PractionerRoles that are part of the CarePlan (end even future ones). Practitioners can establish this plan, modify it by adding new Activities and Goals.
Some of the resources that are referenced are stored in the same national register (as part of the CarePlan), and other resources are referenced to the FHIR-server where they are located.
At the moment, and even in the future, we want to have flexibility in which resources that are stored as part of the (national) CarePlan and which are referenced externally. And it may even be that some of a specific resource type are stored on this FHIR server and other of the same type are stored elsewhere. Thus, there is no way of being static to which referenced resources that should be “included”.
This is why we thought that “-everythng” could be a good idea.
Here are examples of resources that at the moment are referenced and stored on the same national FHIR-server: CareTeam, PractitionerRole, Condition, Goal, MedicationRequest and Task. (In the future more specific CarePlan.activity references will be used i.e. other than the “general” Task).
Josh Mandel (Feb 24 2022 at 16:39):
In other places where $everything exists, we tend to have a "Compartment definition" that explains what belongs, at least as a starting point. E.g.
- for
Encounter/:id/$everything, https://build.fhir.org/compartmentdefinition-encounter.html - for
Patient/:id/$everything, https://build.fhir.org/compartmentdefinition-patient.html
without these definitions or something like them, the value of standardizing an "everything" operation shrinks. There's not strict rule against it; I'm just sharing some perspective.
In your use case, will each patient have multiple care plans in the national register, which need to be partitioned so that access can be granted to one but not the others? If not... maybe just support Patient/:id/$everything on your national server and the CarePlan and all related data can be shared that way?
Michele Mottini (Feb 24 2022 at 17:28):
Use normal searches with includes and revincludes, it is more flexible and already specified and implemented. Having a new $everything won't buy you much
Josh Mandel (Feb 24 2022 at 18:29):
I agree @Michele Mottini.
Standard REST API > Patient-everything >> New-careplan-flavored everything
in terms of interoperability and level of effort to get things going.
Kenneth Myhra (Feb 25 2022 at 10:51):
I agree with include and revinclude and think we should start out with those instead of trying to push forward a $everything operation for CarePlan at this moment. @Sven Christiansen might disagree, but until we have some more experience on which needs and use cases there will be I think include/revinclude is the best way to go forward at the moment.
Last updated: Apr 12 2022 at 19:14 UTC
