Stream: Orders and Observation WG
Topic: Signs and Symptoms
Sridhar (Dec 01 2021 at 21:36):
Reposting this question from Implementers to this group: For capturing signs and symptoms, as I follow FHIR specification, I was looking at Observation Resource. What is the appropriate observation.category value for signs and symptoms? I understand this element is extensible, but is there a value from the 9 concepts in the value set that is more appropriate than extending it using a sign and symptoms SNOMED-CT code?
Sridhar (Dec 01 2021 at 21:37):
I am leaning towards "Exam", but is that the right way to go?
Lloyd McKenzie (Dec 02 2021 at 01:48):
@Hans Buitendijk @Eric Haas
Eric Haas (Dec 02 2021 at 03:29):
I think exam is close but signs and symptoms can be determined via procedures too. IRL this is all fuzzy math.
Lloyd McKenzie (Dec 02 2021 at 03:45):
When EHRs expose them, what category do they want to use - given that they typically require searching by category when searching Observations so they know what internal system/table to hit?
Sridhar (Dec 02 2021 at 06:05):
@Eric Haas , I am sorry, but I do not understand how signs and symptoms are determined via procedures? Can you please explain?
On the other hand, would it just be better to make use of Condition resource for the signs/symptoms to circumvent this 'confusion'?
Sridhar (Dec 02 2021 at 06:05):
Or is it better to explicitly add "Signs and Symptoms" to the value set for Observation category?
Hans Buitendijk (Dec 02 2021 at 15:34):
I'm also trying to understand how procedures would document signs/symptoms. The procedure would document the performance of the procedure when more is needed than what an Observation would handle. E.g., a catherization. And then either Procedure.partOf or Observation.partOf would relate the two. But the actual documentation of the sign/symptom would be Observation, and at some point a Condition would be created if there is a clear diagnosis, working, or rule-out in flight.
Within the existing list I would start with exam, but would like between OO and Pt Care determine whether we should add something to cover sign/symptom more specifically, particularly in light of the Observation/Condition boundary discussion in flight that could inform that. I'll submit a JIRA to that end and will put in the link here.
Hans Buitendijk (Dec 02 2021 at 18:04):
The JIRA can be found here: https://jira.hl7.org/browse/FHIR-34408
Sridhar (Dec 05 2021 at 12:37):
Thanks @Hans Buitendijk I will continue to watch the response to the JIRA
Eric Haas (Dec 06 2021 at 16:25):
Warning Observation category codes in OO is a pandora's box - don't hold your breath
Gay Dolin (Mar 04 2022 at 01:03):
Following - hard to believe - "Signs and Symptoms" or "Symptom" is not already an Observation.category concept. Given that Observation.category is not required and a decent category code is not declared in the resource, perhaps it is better to not use a category at all. For example, is there additional value derived with "Symptom: Headache" over "Headache"
Rob Hausam (Mar 04 2022 at 16:57):
I agree that category is definitely not required - and tends to be a Pandora's Box to figure out what, if anything, to do with it, as Eric said. Basically, if in your application(s) for some reason you need to have a category for 'symptom' then you are free to do that (even though there isn't a code for it in the observation-category code system and value set) - and if you don't need that, then you don't need to worry about using a category at all. If someone really wants to add 'symptom' to the observation-category code system, then that could be proposed - and I wouldn't object (just don't set your expectations too high about what it buys you).
Stephen Chu (Mar 04 2022 at 21:42):
@Rob Hausam - not sure that I understand your statement re "category is definitely not required". It does offer a useful way to search for specific category of Observation data, e.g. history and physical exam related observations
Rob Hausam (Mar 04 2022 at 22:17):
@Stephen Chu My point really comes down to that it depends on your definition of "useful". I agree that it could potentially be useful if those who are creating the resource instances and those who are searching for them have agreed on and are using the same set of category coders. But we've had really not much success in coming to agreed sets of common categories - certainly at the base resource level, anyway. The primary use case (the original one) for 'category' is when the application or system doesn't understand the code system that is being used in 'code' - but that's a problematic situation in itself, and if possible it's much better to understand and be able to use the codes and code system properties that are used in 'code', because that's where the actual meaning of the instance is specified. Broader types of "categories" that might be needed for analysis or other purposes can then be defined based on the sets of codes that would be applicable for those categories.
Jay Lyle (Mar 07 2022 at 15:24):
The existing categories seem to be process-oriented: how was the Observation captured. If the signs & symptoms in question are captured in an exam, exam sounds good.
The term "Signs and Symptoms" is orthogonal: they can be captured in a lot of contexts. A vital sign is a sign; Complaint sounds like a symptom, and it precedes Exam.
To Rob's point, my impression is that Category is an ex-post-facto classification, a tag: you can assign all the tags you want and they should not be necessary to understand in order to process the resource.
But I don't see any language in the spec that says that. Do other WGs have language we could adopt?
Michael Tan (Mar 11 2022 at 10:04):
This could be Pandora's box. If you mention "symptoms" then I think of Adverse Event Reporting ( ICSR) and the Symptoms described in MedDRA. This is used Internationally to report to the WHO in the Uppsala Monitoring Center. There they also use a kind of category to classify the different kinds of symptoms. I don't know how this relates to your thoughts about the catergories you are thinking.
Last updated: Apr 12 2022 at 19:14 UTC
