Stream: committers
Topic: Substantive changes from workflow
Lloyd McKenzie (Oct 25 2018 at 03:37):
@Brian Postlethwaite @Bryn Rhodes @Eric Haas @Paul Knapp @Hugh Glover @Michelle (Moseman) Miller @Elliot Silver @Melva Peters I've just created a series of tracker items (GF#19510 - GF#19518) that request the same set of changes to a bunch of request and event resources. These changes were approved by workflow some time ago. The first is most critical - changing 'context' to 'encounter' to ensure consistency with Observation for a rather important element. The second change of adding the notion of 'reported' would still be good but isn't as critical. Note that the first may also involve tweaking search parameters. Substantive changes are supposed to be complete by EOD on Nov. 1. If you don't have a call before then but feel the change will be non-controversial within your workgroup, feel free to pre-apply.
Melva Peters (Oct 25 2018 at 15:50):
Pharmacy has already added the "reported" element to MedicationRequest but needs to be updated to match pattern. I expect that we can vote on the context change on Monday.
Eric Haas (Oct 25 2018 at 18:40):
OO changed all context to encounter
Eric Haas (Oct 25 2018 at 18:45):
OO to consider these as an event-extension for all OO resources will bring up Oct 30th call. I did not see an event extension present....
Lloyd McKenzie (Oct 25 2018 at 20:22):
Extension doesn't exist yet. It will. Just note what resources you want to be in the context for it.
Elliot Silver (Oct 26 2018 at 19:38):
I don't like the name "reported[x]" since that overlaps with whether the item has been reported on.
Also, how do we record Encounter for a resource which could be created as part of multiple events. Specifically, if a patient visits the department twice for the same imaging study or lab order (imaging with and without contrast; blood panel fasting and not fasting, etc.). Should encounter be 0..*?
Lloyd McKenzie (Oct 26 2018 at 19:40):
The encounter for a lab order is generally the encounter it's created in, not the encounters used to fulfill it. If reported[x] doesn't work for your work group, you can use something different. (It won't get in for Observation this round anyhow - and that's probably where it would be most problematic.)
Elliot Silver (Oct 26 2018 at 19:42):
Actually, the reported[x] concept is weird for ImagingStudy. What does it mean? "I told you I had images done, but you don't have records for them"? "Here are images done elsewhere, so we should flag them as hearsay imaging"?
Lloyd McKenzie (Oct 26 2018 at 20:02):
Totally fine if that's not core (or even an extension) for ImagingStudy. Essentially you need to answer the question of how would existing systems deal with a patient saying "I had an X-Ray done over at such-and-such a hospital last week". If they'd create an ImagingStudy instance, then you need 'reported'. If they'd capture it as a note or just nod their head and say "that's nice" without recording anything, no need for the element.
Elliot Silver (Oct 26 2018 at 21:43):
ImagingStudy aside, I'd like the "reported" element renamed to something less likely to conflict with other uses of "report" (like, this X has been reported on). If this change is for any normative resources, we need to discuss now, otherwise it can wait.
Lloyd McKenzie (Oct 26 2018 at 22:00):
We already have reportedBy on quite a few resources
Michelle (Moseman) Miller (Oct 26 2018 at 23:00):
Just an FYI that I'm running this by the Patient Care co-chairs to get a feel for how controversial it may be...
Lloyd McKenzie (Oct 27 2018 at 00:05):
One of the reasons for the change is that you might want to tie a record to both an Encounter and multiple episodes of care. Right now, that's not possible. With the change, you can.
Lloyd McKenzie (Oct 27 2018 at 00:05):
If they really feel that linking to episodeOfCare is core for some of their resources (i.e. most systems currently support that), they could add a core element for that too.
Eric Haas (Oct 27 2018 at 13:27):
Hos won’t of reported work for medstatemeht procedure observation? I’m starting to think that it is already covered medstatemnt. And observation. I’m struggling to see it being used for media or task need to look at devicestatement.
Eric Haas (Oct 27 2018 at 13:27):
Procedure may need it but I’m just guessing
Eric Haas (Oct 27 2018 at 13:29):
How would it be reported not ‘hos won’t ‘
Eric Haas (Oct 27 2018 at 13:30):
Where is this element defined and used now?
Lloyd McKenzie (Oct 27 2018 at 14:54):
What's "hos won't"?
Eric Haas (Oct 27 2018 at 17:01):
How would
Eric Haas (Oct 27 2018 at 17:01):
iPhone :-)
Lloyd McKenzie (Oct 27 2018 at 19:30):
For Med statement, you might have a code that differentiated "reported" vs. "inferred" statements. For Observation, probably outside the 80%, but I can see "reported" being used to distinguish direct device/clinician measurements from deferred patient reporting (e.g. when patient is on holiday or leave of absense). For procedure, it'd be the difference between recording a surgery, councelling, etc. based on clinical knowledge of occurrence vs. patient or care provider reporting "this happened".
Eric Haas (Oct 27 2018 at 20:37):
In O. If the performer == patient RelatedPerson. Then it’s reasonable to infer its was reported depending on the use case eg an ehr
Eric Haas (Oct 27 2018 at 20:39):
I’m not seeing an extension very useful since you would have to keep track of both for consistency. And it would be potentially confusing
Michelle (Moseman) Miller (Oct 28 2018 at 05:27):
@Lloyd McKenzie I'm in the process of pre-applying the change from context to encounter on all PC resources. I see the event-episodeOfCare extension, but is it OK to use the "event" extension for "request" resources (and non-workflow resources - like CareTeam)?
Lloyd McKenzie (Oct 28 2018 at 16:11):
@Eric - it depends on the context of the observation. If it's a white blood cell count, almost certainly. If it's weight and the patient has a dedicated device that auto-reports into their iPhone app, not necessarily.
Lloyd McKenzie (Oct 28 2018 at 16:12):
@Michelle (Moseman) Miller That'll be fine for now.
Michelle (Moseman) Miller (Nov 01 2018 at 22:44):
@Lloyd McKenzie Patient Care voted to approve the first half of the tracker (to change context to encounter), but didn't tackle the second half of the tracker (reported element). Just wanted to confirm that I should leave the tracker in a Deferred status, pre-applied = yes, leading up to R4. The alternative was splitting the tracker into 2 separate trackers where one is Applied and the other is Deferred.
Grahame Grieve (Nov 01 2018 at 22:48):
yes pre-applied and deferred
Lloyd McKenzie (Nov 01 2018 at 22:51):
2 trackers would actually be cleaner in terms of reporting substantive changes for each release...
Last updated: Apr 12 2022 at 19:14 UTC
