Stream: implementers
Topic: Condition that change over time
Kirstine Rosenbeck Gøeg (May 19 2020 at 07:34):
I am working on a model for conditions to use in home care settings in Denmark. I have not been able to find precise documentation about how to handle conditions that change over time (which is often the case for the prolonged health issues we see in elderly care). In my model, it is very important to be able to track, both the time that the condition was first recorded, but also the time that it was last modified. My suggestion is to use Condition.recordedDate for the date that the condition was first recorded and use Condition.encounter to point to the encounter in which it was last modified. I suggest this solution because the documentation on Condition.encounter reads as follows in the comment section: “This record indicates the encounter this particular record is associated with. In the case of a "new" diagnosis reflecting ongoing/revised information about the condition, this might be distinct from the first encounter in which the underlying condition was first "known".”
I would appreciate your opinion on whether my solution adheres to the intended use of the Condition resource. (And BTW I plan to use a similar model for tracking change in CarePlans - comments on that will be appreciated as well)
(Just to avoid comments on the clinical aspects – I know that it is always debatable whether a condition that changes, is in fact a new condition. We have a set of principles that guides that already 😉)
Jay Lyle (May 19 2020 at 11:33):
@Michelle (Moseman) Miller This sounds reasonable to me, but we may wish to broaden the mouseoverlanguage ("created") and tighten the definition ("associated"). Alternate approaches: use the reference from the Encounter (reason or diagnosis), or the meta.lastUpdated in Encounter.period.
Scott Rossignol (May 19 2020 at 12:17):
Kirstine Rosenbeck Gøeg
Does the condition change only once? Otherwise your pointer in Condition.encounter would only be useful for the last encounter where the condition changed. Condition.encounter is a reference and not a list.
Is this a candidate for "stage"? If the conditions always progress along a pathway then this seems feasible.
Kirstine Rosenbeck Gøeg (May 19 2020 at 12:55):
Thanks for your answers.
@Jay Lyle in my understanding, the reference from Encounter to Condition tells what the reason for the encounter was, not when or even whether the Condition content was changed. Could you explain in more words how meta.lastUpdated in Encounter.period is an alternative if there is no relationship between Encounter and Condition?
@Scott Rossignol I know that it is a reference and not a list. In my use case, the condition can change many times, and as such I know that the model only works, if I have access to all the automatic versions of the record (all the historic instances with their different meta.lastUpdated, meta.versionId). Even if I had a list, it would not tell precisely what changed in the condition at the different encounters anyway. My goal is two-fold, I need a current condition for a patient, where I can see when there last was a significant modification/evaluation of the condition (and who took the responsibility for that modification ), and when it was first recorded. For secondary purposes, I am interested in the full history - but as this is a more technical/administrative use case anyway, I assume that I have access to all the historical instances, that would make this possible.
Using Condition.stage is actually a quite good alternative, if you are sure that the only clinically significant change that you want to keep track of is a stage. In my use case, the significant change could be that Condition.clinicalStatus or Condition.severity was changed or that Condition.abatement was recorded.
Petter Wolff (May 19 2020 at 13:22):
Condition is an event resource, so its use for describing the 'current' state of the Patient is not advised, I would say. Some application heuristic might be needed which checks several of the Patient's Conditions, or another resource altogether, when an assessment of the Patient's status for a particular care context is required.
CarePlan, on the other hand, should be used to track state of the Patient's healthcare journey, with some kind of version control (e.g. using the 'replaces' reference)
Jay Lyle (May 19 2020 at 13:53):
- I think I still like your proposed solution best (Condition.encounter), if we can determine there's no reason not to talk about modifying the definition. Would you be interested in lodging a tracker?
others:
-
I'm talking about an inferred relationship based on time (meta.lastUpdated within Encounter.period). That could break if the edits are not done during the Encounter, but to assert an explicit relationship would face the same problem: how and when is that relationship established? Would the provider "re-open" the Encounter to do that?
-
Agreed, Encounter.reason and diagnosis have specific semantics and may not be right, but if a condition is updated based on an Encounter, it seems that one of them might be right. I don't know how tight that fit is.
-
stage has pretty specific semantics, and doesn't include Encounter in scope.
-
"when there last was a significant modification/evaluation of the condition (and who took the responsibility for that modification)" sounds like Provenance.
Lloyd McKenzie (May 19 2020 at 15:31):
Typically you use Provenance to look for what happened in the past. Condition.recorded is when the condition was first created - not when last updated. To see when a particular server's record was changed, you can use Condition.meta.lastUpdated
Kirstine Rosenbeck Gøeg (May 20 2020 at 07:56):
@Petter Wolff Yes, I know that Conditions is an event-resource. I did not mean "current" in its strict sense.
Thanks for bringing up the "replaces" reference. However, I believe that finding out what replaces what, is very difficult to manage in real life. Lets say we have a ulcer treatment, which is described in a care plan. The nurse that delivers the treatment decides that another bandage should be used from now and forward, and changes the CarePlan accordingly e.g. the description in the attribute CarePlan.activity.detail.description. How would you document this change? Is it a new care plan that replaces an old one, is it the same care plan in a new version only managed using the server's record i.e. meta.lastUpdated, or do we use the same mechanism as described for Condition i.e. saying that the encounter that it was created as part of changed, OR as also suggested in this thread create a Provenance resource, and using this to track the change?
@Jay Lyle Very good points. You point to something that have worried me, namely, how to establish the reference, if the change to the documentation i.e. the change in Condition, takes place after the conclusion of the encounter. It still holds true in a clinical sense, but it might be difficult to handle system-wise. Thanks for mentioning the Provenance resource, I had not considered that, and I think that might open for an alternative design altogether. I will need to consider it further.
@Lloyd McKenzie I know. One of my goals is to be able to distinguish (all the potentially many) server versions, and the times/versions that signify a clinical change in Condition or CarePlan.
Petter Wolff (May 20 2020 at 09:09):
I don't really have a suggestion regarding how to version control a CarePlan when making changes to it - it's like you say, complicated. If you intend for a CareTeam to change the care based on a changed detail.description field, there might be a need for a human decision as to whether the change is big enough to warrant a version (major, minor) bump.
Jose Costa Teixeira (May 20 2020 at 09:19):
I think we should extend the context of the eventHistory extension to support Condition.
Jose Costa Teixeira (May 20 2020 at 09:22):
EventHistory is a standard extension that supports what I read as the request here- what/when/by whom were the relevant changes to the resource
Jose Costa Teixeira (May 20 2020 at 09:23):
meta.lastUpdated tells when something has changed, not when something relevant has changed
Jose Costa Teixeira (May 20 2020 at 09:26):
@Kirstine Rosenbeck Gøeg I think that should answer your original question for Condition.
Jose Costa Teixeira (May 20 2020 at 09:26):
CarePlan is more of a "request" resource (Condition is an event) so you can also use an extension - relevantHistory
Jose Costa Teixeira (May 20 2020 at 09:27):
for relevantHistory there is already a tracker item to change the extension to support CarePlan
https://jira.hl7.org/browse/FHIR-26963
Jose Costa Teixeira (May 20 2020 at 09:28):
The extensions would be these:
http://build.fhir.org/extension-event-eventhistory.html
http://build.fhir.org/extension-request-relevanthistory.html
Lloyd McKenzie (May 20 2020 at 15:10):
There's no rule about when you must define a new CarePlan (that replaces an old one) vs. just changing the existing resource. Such rules are driven by business context. From a pure FHIR interface perspective, it's totally fine to take a CarePlan and change the subject, the author and the full plan content and treat that as a simple update of the same record. However, the business rules of most environments would frown on that. The Condition and CarePlan resources are ones that are expected to evolve over time, so it's completely reasonable to change activities in a plan (or add or remove activities) and still call it the same plan. Seeing what it used to look like would require history. Capturing who changed what and why would be covered by Provenance.
Kirstine Rosenbeck Gøeg (May 25 2020 at 06:37):
Thank you for all your suggestions. Choosing a good solution is the next challenge. I wonder if anyone in my Danish network, have something to add to this discussion @Jens Villadsen @Irene Zuschlag @Torben M. Hagensen @Jesper Haffgaard @Annika Sonne Hansen @Thor Schliemann
Jens Villadsen (Sep 09 2021 at 20:33):
@Lloyd McKenzie I would be surprised if your application security/state transfer model would let you make such state change - ie. changing the subject from John to Jane without barfing. Frowning on that would be a mild interpretation :grimacing:
Lloyd McKenzie (Sep 09 2021 at 20:35):
Oh, I agree that business rules, and even laws and regulations would prevent the change. I'm saying that FHIR doesn't declare any such rules. What's allowed as an update vs. what must be 'new' is totally driven by business context. IGs might set expectations, but the FHIR core spec generally won't.
Jens Villadsen (Sep 09 2021 at 20:35):
:+1:
Last updated: Apr 12 2022 at 19:14 UTC
