FHIR Chat · Referential integrity · hapi

Stream: hapi

Topic: Referential integrity


view this post on Zulip Grahame Grieve (Jun 07 2021 at 03:33):

hey @James Agnew I'm giving a talk about referential integrity on FHIR APIs at DevDays today.(/tomorrow)

I've got a question for you. HAPI has an interceptor that allows you to manage for some referential integrity constraints to be broken, but I was surprised that to my way of thinking, it only covers half the problem. You can say that you allow for resources to be deleted if some paths would be broken, but you can't say, 'this path X, I'm OK for whatever it points to be broken, but not other paths'.

Have I missed something?

view this post on Zulip Brian Postlethwaite (Jun 07 2021 at 04:06):

Has versioning been covered in there too?

view this post on Zulip Grahame Grieve (Jun 07 2021 at 04:50):

not my subject, so I'm not sure.

view this post on Zulip James Agnew (Jun 07 2021 at 09:39):

@Grahame Grieve I'm not sure Im actually getting the meat of your question, but:

We do also support all or nothing. I.e. you can turn on referential integrity so that all reference paths are enforced and you can't delete a resource unless nothing is pointing at it. This is the default behaviour. You can also globally turn it off so that you'll never be blocked from deleting resources because something points at the thing you're deleting. There is also a similar setting for creates, where you can configure the server to not prevent you from creating a resource if it has a reference to a target that doesn't actually exist (but this isn't the default either).

The interceptor was added based on a customer request, and the logic made sense to me - There are a few places where references don't actually need to indicate live links, they just need to indicate what the live link was at the time the resource was created. AuditEvent.target would be an example of that. So when you use the interceptor you could let a Patient be deleted if only an AuditEvent points at it, but you'd still be blocked if an Observation also does.

view this post on Zulip Grahame Grieve (Jun 07 2021 at 09:46):

I totally get what it does. it's what it doesn't do. I'd like to have an interceptor that let me say, require that Observation.subject is valid when a new Observation is posted, but decide that I don't care if DiagnosticReport.baseOn refers to a resource that I'll never get

view this post on Zulip Grahame Grieve (Jun 07 2021 at 10:58):

@James Agnew

view this post on Zulip James Agnew (Jun 07 2021 at 14:23):

Oh I see.. So you're looking for the equivalent of the selective enforcement, but for resource creates as opposed to resource deletes.

That isn't supported, but would be easy enough to add for sure.

view this post on Zulip Grahame Grieve (Jun 07 2021 at 14:34):

ok thanks

view this post on Zulip Jens Villadsen (Jun 07 2021 at 14:59):

Eg. black/whitelist of ignored fields expressed in fhirpath?

view this post on Zulip Grahame Grieve (Jun 07 2021 at 15:08):

something like that


Last updated: Apr 12 2022 at 19:14 UTC