Stream: implementers
Topic: CarePlan for risk mitigation following a RiskAssessment
Vladimir Smirnov (Aug 23 2018 at 14:09):
We are building a CDS module for general risk assessment based on lifestyle factors and EHR data. As we understand, the RiskAssessment is the correct resource to represent the outcome. In addition, we plan to provide self-management recommendations and proposals for further diagnostic tests / health services. RiskAssessment has a 'mitigation' field, but it's text-only. Instead, generating a structured CarePlan seems to be a better option. Is there a way to reference the RiskAssessment from the plan, or the other way around?
CarePlan is a request resource that, according to the workflow pattern, should reference the event resource that prompted its generation. However, a CarePlan may only reference a Condition, not RiskAssessment or anything else. Perhaps we should generate a Condition with verification status 'provisional' for every predicted risk outcome, build a separate CarePlan for each, and link it back to respective Condition? However, a Condition represents a problem that is necessarily present in a patient with some degree of verification. Is it appropriate to use Condition for risks, problems that haven't even yet manifested? A Condition is specified by terminology code and qualifying status fields on the resource (clinical and verification status). Among the value sets defined for the qualifying fields, there is no value of "at risk". Therefore, we should place the qualifier element in the code, by constructing a post-coordinated expression from the risk outcome code (i.e. 'lung cancer') and '30207005 | Risk of (contextual qualifier) |'?
Is it a viable proposal of making the 'mitigation' a choice type on the RiskAssessment, providing either 'mitigationString' or 'mitigationCarePlan'? Of course, link to CarePlan could be implemented as extension.
Bryn Rhodes (Aug 23 2018 at 14:38):
In the CarePlan itself, you could use the supportingInfo element to reference the RiskAssessment.
Vladimir Smirnov (Aug 31 2018 at 17:41):
But isn't 'supportingInfo' meant for supplementary material that is part of the plan, such as bibliographic references to care standards, or internal regulations of the organization? It appears to be semantically wrong to put the RiskAssessment reference there.
Instead, some approaches we have been considering, up for potential discussion, and in hopes of being helpful for someone in the future:
- Link the CarePlan to a Goal resource that '.addresses' the RiskAssessment, and has a code of post-coordinated expression deriving from 315233008 |Primary prevention (procedure)|. This is the cleanest solution that doesn't diverge from the standard.
- Put extension in the CarePlan, which would link it to the RiskAssessment. This would eliminate the need for an extra resource in between, and follows the pattern of Request resources linking back to Events.
- Put extension in the RiskAssessment.prediction, providing a link to CarePlan for mitigation. This would be the most straightforward way, and the least in line with common FHIR approaches.
So far, the first option (via Goal) appears the most preferable.
Vladimir Smirnov (Aug 31 2018 at 19:40):
CarePlan and Goal both have the '.addresses' field. While Goal can address any of Condition, Observation, MedicationStatement, NutritionOrder, ProcedureRequest or RiskAssessment, the CarePlan addresses only Condition. Has it ever been considered to keep type lists similar in both resources? CarePlan doesn't always need an explicitly specified Goal, but a link between the plan the event it addresses is a nesessary requirement. Was this design decision made to promote explicit statement of goals for care plans, or simply to protect CarePlan from growing too much?
Lloyd McKenzie (Aug 31 2018 at 21:14):
Feel free to submit a change request :)
Last updated: Apr 12 2022 at 19:14 UTC
