Stream: implementers
Topic: use of Condition.clinicalStatus
Kenny Blanchette (May 24 2018 at 16:44):
Hi all,
For a condition of category "encounter-diagnosis", is Condition.clinicalStatus intended to represent the status of the condition at the time it was assessed, or at the current time? For instance, if a provider diagnoses a condition (e.g. Influenza) on 1/1/2017 and it was not moved to the patient's Problem List, should this be represented as?
- clinicalStatus "active", assertedDate "1/1/2017"
- clinicalStatus "inactive", assertedDate "1/1/2017"
Or for encounter diagnoses, is it recommended to also represent onsetDate and abatementDate as "1/1/2017"?
Lloyd McKenzie (May 24 2018 at 16:45):
@Michelle (Moseman) Miller
Kenny Blanchette (Jun 01 2018 at 14:37):
@Michelle (Moseman) Miller bumping this. @Lloyd McKenzie is there anyone else that might be able to help, or some additional documentation you could point me to?
Lloyd McKenzie (Jun 01 2018 at 14:59):
The clinical status reflects the status as it was on the asserted date. Whether a given Condition will appear on a problem list is independent of the clinical status. (Some active conditions might not be important enough or relevant to a particular type of care to appear on a given practitioner's problem list for the patient. Other resolved conditions might still be deemed relevant.) So if you're asserting that the patient had something in the past, the clinical status would be resolved, the asserted date would be now and the onset and abatement would capture the period over which you beleive the condition was effective
Rob Hausam (Jun 01 2018 at 15:06):
I'm not sure if that's entirely correct, @Lloyd McKenzie. The comments on assertedDate state that "The assertedDate represents the date when this particular Condition record was created in the EHR, not the date of the most recent update in terms of when severity, abatement, etc. were specified." It's not specifically mentioned, but I think that clinicalStatus would be expected to be updated along with severity, abatement, etc., so over time it wouldn't be statically tied to the assertionDate. This is probably something that we need to clarify in PCWG.
Lloyd McKenzie (Jun 01 2018 at 15:37):
The short definition and long definition aren't terribly well-aligned :( I think the asserted date has to be the date the Condition "as recorded" was deemed to be true. If you're asserting someone has stage 4 lung cancer and you've been tracking it since they were stage 2, you don't want the asserted date to be the date they had stage 2. But agree the wording definitely needs clarification
Rob Hausam (Jun 01 2018 at 15:44):
Kenny Blanchette (Jun 01 2018 at 15:57):
great, thanks! and @Lloyd McKenzie, to your stage 2/4 lung cancer example, my understanding is that you would have two separate records for the Condition. one for stage 2 lung cancer with assertedDate = (last date this was recorded) and clinicalStatus = Resolved (or Inactive) ; and one for stage 4 lung cancer with assertedDate = today and clinicalStatus = Active. would you agree?
Lloyd McKenzie (Jun 01 2018 at 15:58):
That's one possibility. The other is that the same condition will have been updated over time. If you dig into the history you can see that it was once stage 2, but the current record will show stage 4.
Kenny Blanchette (Jun 01 2018 at 16:03):
so that design decision would be up to the implementer?
Lloyd McKenzie (Jun 01 2018 at 16:32):
Yes - based on their business processes. It could also be driven by the user
Michelle (Moseman) Miller (Jun 07 2018 at 19:52):
I'll get GF#17285 added to the Patient Care work group agenda to discuss (maybe even today if time allows).
Michelle (Moseman) Miller (Jun 07 2018 at 19:59):
Speaking from Cerner's perspective, both scenarios are possible. We have point in time diagnoses (for billing, represented using ICD-X) and we have the problems (represented using SNOMED). In our system, the problem might get updated from stage 2 to stage 4, but I would expect multiple diagnoses (per visit or encounter) where one might be stage 2 and another might be stage 4 because diagnoses don't typically get modified after the encounter.
Michelle (Moseman) Miller (Jun 07 2018 at 22:37):
Patient Care discussed GF#17285 tonight. A suggestion was made to rename assertedDate to initialAssertionDate, but this suggestion was countered saying we could just as easily clarify the description / definition instead. Before voting on the change request, Patient Care is inviting implementers to voice their opinion about whether the element should be renamed (or not).
Grahame Grieve (Jun 07 2018 at 22:57):
I don't think that renaming brings any value over a clear definition
Lloyd McKenzie (Jun 07 2018 at 23:44):
Don't you want the date at which the currently reflected assessment was made? If the initial assessment a year ago was stage 1 and the current assessment is stage 4, I presume you'd want the date at which the current state was determined.
Lloyd McKenzie (Jun 07 2018 at 23:45):
Most recent assessment date seems much more useful than initial assessment date when you've got onset date.
Rob Hausam (Jun 08 2018 at 00:52):
I raised that question, too. But the sense of the group was along the lines that meta.lastUpdated likely captured the date of most recent assessment reasonably well, and you have onset, but the missing piece of information (if you don't implement history) is when you started tracking the condition (not when it became noted for the patient, which is onset). And that's how assertedDate has been documented, so that is consistent. I thought the name change would probably make the intended meaning more obvious, but I'm perfectly well persuaded that it's not worth it to do that at this point and that making the documentation even clearer (than it already is) should suffice.
Lloyd McKenzie (Jun 08 2018 at 01:52):
meta.lastUpdated does not capture the date of the most recent assessment. It captures when you stored this copy of the resource on your server. If you receive a record of an assessment that was done 5 years ago today, your system will have a meta.lastUpdated value of "today". Content in meta is typically server-specific.
Rob Hausam (Jun 08 2018 at 14:26):
Yes, I agree, Lloyd - that's exactly right. What you described isn't the most common scenario, but it certainly can occur. I agree that trying to rely on anything in metadata for specific semantics like this probably is not a good idea. So I think we need to give this some further thought (which I believe we'll discuss further next week).
Michelle (Moseman) Miller (Jun 12 2018 at 20:40):
Speaking as PC co-chair, I can add this to the Patient Care agenda for Thursday to revisit.
Speaking as an EHR vender, I will just add:
- Users have a hard enough time documenting the onset date (often leaving it blank), so I think we'd have no luck trying to get users to explicitly document their assessment date.
- Technically, in our mapping/implementation, we're using the system defaulted date/time stamp (not a manually entered date/time) for recordedDate (in DSTU2) and assertedDate (in STU3)
- Going back to the original question, I will just clarify that all of our encounter-diagnosis conditions have a clinicalStatus of active (which reiterates what I mentioned earlier about "billing diagnosis" being immutable -- so their status, stage, etc. don't ever change)
Michelle (Moseman) Miller (Jun 14 2018 at 22:36):
More detailed meeting minutes are available in the GF#17285, but to summarize the resolution (applicable to both AllergyIntolerance and Condition)
1) Move assertedDate from core resource to an extension (because no implementer on the call supported this field)
2) Add recordedDate to the core resource, which is the date when this particular AllergyIntolerance/Condition record was created in the EHR, which is often a system-generated date. The recordedDate is valuable to have in absence of the onset date (for example, when patient doesn't recall when a diagnosis was made) and when FHIR server doesn't support version history (to get version 1's lastUpdated)
Kenny Blanchette (Jul 19 2018 at 21:17):
Thanks @Michelle (Moseman) Miller, appreciate you clarifying this. We used the same approach for encounter-diagnosis conditions, always setting the status to 'active'. We also set the onset date and abatement date to the date of the encounter diagnosis. The main reason for doing so is that quality measures look at these two attributes to determine the prevalence period. If we didn't set abatement date to the date of the diagnosis, then all encounter diagnoses would appear as active and relevant past the date of the diagnosis. Our perspective is that ongoing conditions should also be tracked in the problem list, where there is a workflow to indicate the a problem is no longer active (i.e. historical).
Do you take a similar approach for onset date and abatement date for encounter-diagnoses?
Last updated: Apr 12 2022 at 19:14 UTC
