`expression-based-criteria` check `%previous` is e...
# support
n
I'm trying to use the expression-based-criteria subscription extension to only fire a Subscription when a Consent is in
active
status where it was either previously
draft
OR has no previous state (directly created in
active
status). My filter expression valueString is
"%previous={} or %previous.status='draft'"
and the subscription criteria is
'Consent?status=active'
and it is working properly when a Consent goes from draft->active but it does not work when I directly create a Consent in
active
status. This leads me to believe that
%previous={}
is not doing what I expected. The docs note: https://www.medplum.com/docs/subscriptions/subscription-extensions#expression-based-criteria > Upon the creation of a resource, there won't be a previous version of the resource.
%previous
will be an empty object. How do we check if
%previous
is an empty object in the fhirpath expression? Maybe I want to use the [equivalent operator](https://build.fhir.org/ig/HL7/FHIRPath/#equivalent) ?
Just tested and the equivalent operator does not fix this
r
Not sure if this answers your question completely, but this is how you create a subscription on "create" https://www.medplum.com/docs/subscriptions/subscription-extensions#subscriptions-for-create-only-events
n
Going this route would require me to have 2 subscriptions for the scenario described so definitely not ideal but appreciate that there's a workaround available!
r
Yeah, I do think that a single sub is not supported for this case unfortunately
r
@node, have you tried
%previous.exists()
? This is a function that is in the FHIRPath spec. You can see an example here wrt. write-constraints https://www.medplum.com/docs/access/access-policies#write-constraints
n
Yup tried that and it does not seem to be working either I dug a bit into the fhirpath implementation and poked around - I think there might be a bug in the
exists
&
empty
function implementations Opened this issue to track https://github.com/medplum/medplum/issues/3807
r
Thanks for the issue and PR @node ! We'll take a look
158 Views