Stream: implementers
Topic: Observation or Extension or Questionnaire
Jay Lyle (Feb 19 2019 at 14:29):
I'm sure this conversation has occurred but I can't find it.
If one wishes to express persistent facts about a patient (e.g., whether the patient has a service-related disability), one could
a) create extensions
b) add observations
c) add a list of questions in a questionnaire
We have dozens of these, and they tend not to be structured or interrelated (explicitly), so observation seems a little heavy, as do extensions. Adding a questionnaire would require an extension, too, but it would only be one. Though questionnaire instance design would complicate the constraint.
How are other implementers addressing these questions?
John Moehrke (Feb 19 2019 at 14:42):
This seems clearly an Observation. Why do you think Observation is "heavy"? It is one of the smallest resources
Lloyd McKenzie (Feb 19 2019 at 15:07):
Observation allows you to capture who mande the statement, when it was made and possibly the basis for making the assertion. So it's best for anything that is either clinical or transient. Patient is really about demographics - if it's not a demographic characteristic, it shouldn't be on the Patient resource. Questionnaire is a data capture tool - you can use it to capture anything. But it doesn't give you data that's understandable across systems that don't share that specific questionnaire version, nor does it let you query based on the data.
Lloyd McKenzie (Feb 19 2019 at 15:09):
Something else that's a possibility would be an extension on Encounter if it's an element that primarily drives encounter-specific behavior
Jay Lyle (Feb 20 2019 at 00:31):
John, any time it's complex (includes dates, methods, etc.), Observation seems right. And perhaps it's right for the simple cases, too (e.g., whether the patient has a service-related disability, with no context or metadata). Status is the only thing we'd absolutely have to impute or not support. Thanks.
Lloyd, this is sort of clinical, and it's used as a patient characteristic: does that mean it's 'demographic' or not? I'm considering an Observation for the element, baked into a VA Patient profile. There would be many such Observation profile components.
Also, you suggest an extension on Encounter rather than an observation - is there some implicit facet that's different there?
Lloyd McKenzie (Feb 20 2019 at 00:56):
Service-related disability sounds like something that isn't encounter-specific. (Something like "valuables location" would be encounter-specific.) Service-related disability seems like it might be coverage-related, but could potentially be categorized as demographic if the primary use is filtering and finding patients.
Jay Lyle (Feb 22 2019 at 00:48):
Most of what I'm looking at is not encounter-specific. I'm chewing on when it's appropriate to use Observation rather than Patient extension. Service-related disability, Unemployable & Purple Heart status all have tenuous links to clinical process, but I'm comfortable calling them "personal characteristics" per Observation Scope & Usage. But Rx cap type? Rx mail preference? Are there heuristics for this sort of thing?
Grahame Grieve (Feb 22 2019 at 01:21):
so you identify the patient using them? If so... patient extension. If not... observatin
Jay Lyle (Feb 22 2019 at 02:03):
There's a criterion. "Identify": meaning, use in a query?
Brian Postlethwaite (Apr 03 2019 at 22:45):
Feels like observation to me, just as other social status things go - e.g. smoking status.
Last updated: Apr 12 2022 at 19:14 UTC
