Stream: implementers
Topic: CarePlan addresses
Kirstine Rosenbeck Gøeg (Jun 25 2020 at 13:27):
I need to define a Careplan that addresses both a primary and a number of secondary conditions. What would you suggest in terms of design? If I include a rank as an extension, it becomes separate from the CarePlan.addresses field. I could also define an extension that has both the rank and the reference to condition - however, that would be overlapping with the addresses attribute, which is a problem in an interoperability framework, because the condition that a CarePlan adresses could then be found in different fields. Finally, I could slice CarePlan.adresses - and point to a primaryConditionProfile and a ConditionProfile respectively. I do not like this option, because the primaryConditionProfile and ConditionProfile would be so similar that they do not really need two different profiles.
What I really need is a structure similar to the Encounter.diagnosis.
BTW: I agree with the arguments in an earlier stream (https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Type.20of.20Condition), that the context defines the rank/use of a condition - but a CarePlan gives such a context - just like an encounter does.
Lloyd McKenzie (Jun 25 2020 at 14:40):
Define an extension on CarePlan.addresses that specifies a rank
Last updated: Apr 12 2022 at 19:14 UTC
