FHIR Chat · Automatic status updates based on elements · fhir/infrastructure-wg

Stream: fhir/infrastructure-wg

Topic: Automatic status updates based on elements


view this post on Zulip David Pyke (Jun 10 2019 at 17:07):

I was hopeful that this problem has already been solved.
We would like it if Consent resources were made active/inactive based on the contents of Consent.provision.period where if there are no currently provisions (based on Consent.provision.period), the resource is marked inactive (and vice-versa). Is that possible?

view this post on Zulip Grahame Grieve (Jun 10 2019 at 17:27):

it's not an API thing, so we haven't done it directly. You could say something in narrative - did you have more in mind?

view this post on Zulip David Pyke (Jun 10 2019 at 17:34):

I'm not sure we'd need more, it was just a question to the group if that kind of thing is a new issue or if we can just say "server to monitor consents and update status as appropriate"

view this post on Zulip Grahame Grieve (Jun 10 2019 at 17:36):

we haven't had such a case before, where status is directly linked to a period

view this post on Zulip Grahame Grieve (Jun 10 2019 at 17:36):

typically, status is not directly linked

view this post on Zulip David Pyke (Jun 10 2019 at 17:41):

I was hoping that Medication or other resources that may be time limited had looked into/solved this issue

view this post on Zulip Grahame Grieve (Jun 10 2019 at 17:45):

the record remains active even if the period during which it was applicable is past.

view this post on Zulip David Pyke (Jun 10 2019 at 17:47):

So, we'll just have to leave it to local inspection if there are any active consents after a query

view this post on Zulip Lloyd McKenzie (Jun 10 2019 at 17:58):

If you have an active prescription that's intended to expire at a particular date, it's up to the server to decide whether/when to transition the prescription to "completed" based on the assumption that the patient is (likely) not taking the medication anymore. There's no requirement for servers to do this and, thus far, I'm not aware of any implementation guides that set an expectation to do this.

view this post on Zulip Brian Postlethwaite (Jun 11 2019 at 06:59):

And the timing of when that flag was actually tripped, during an update, some server based update that updated the record on expiry, some process that does the review/marking etc.

view this post on Zulip John Moehrke (Jun 11 2019 at 12:29):

All this agreed... is there some text that warns that the .status element does not automatically move to inactive upon time based expiration? with recommendation that this could be automated? If we had this kind of language it would be good for it to appear similarly in all places where expiration results in .status changes.

view this post on Zulip Grahame Grieve (Jun 11 2019 at 14:52):

I don't think we've said that anywhere, but I don't think we've really had any assertion that it should. Do you see other similar resources

view this post on Zulip John Moehrke (Jun 11 2019 at 15:04):

We are looking at Consent that can have a time horizon (I allow access for 12 months)... and figure it might be rather similar to a medication authorization (drug x is authorized for 12 months). So rather than invent unique human text, we are just asking if there is common text so that the reader of FHIR can see similar explaination.

view this post on Zulip Grahame Grieve (Jun 11 2019 at 15:34):

we don't have a resource for Authorization, to my knowledge

view this post on Zulip Brian Postlethwaite (Jun 12 2019 at 16:46):

Period's don't always dictate direct active status...
An encounter could be complete, but post encounter activities are still going for a while during the billing cycle.


Last updated: Apr 12 2022 at 19:14 UTC