FHIR Chat · Create for self-referential resource with referential int...

Stream: implementers

Topic: Create for self-referential resource with referential int...

Rick Geimer (Nov 18 2021 at 17:01):

I've got a chicken and egg problem. I have a resource that references another resource in an extension sort of like this (actual resource and extension changed to protect the innocent):

This works fine, except the for CEO it would be self-referential:

When I PUT (corrected, was POST) the self-referential resource to HAPI with referential integrity turned on I get an error saying that Practioner/ceo does not exist so the create operation fails.

I'm pretty sure this is a HAPI bug, but wanted to see what others think before I bug James.

Josh Mandel (Nov 18 2021 at 17:22):

I would expect the valueReference to say either Practitioner/ceo or # rather than ceo, because a bare resource ID is not iself a valid reference (but I don't know whether any of these is expected to work in HAPI -- it's a fun edge case at any rate, though maybe the right answer here is chair :-))

Paul Church (Nov 18 2021 at 17:37):

I don't think you can POST that with ref integrity. A create POST has no way to rewrite references to the created resource. You could do this inside a transaction bundle, making the self reference point to the fullUrl of the entry.

For example, the Google implementation will accept this and do what you want, with referential integrity enabled:

{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "request": {
        "method": "POST",
        "url": "Patient"
      },
      "fullUrl": "Patient/me",
      "resource": {
        "resourceType": "Patient",
        "link": [
          {
            "other": {
              "reference": "Patient/me"
            },
            "type": "seealso"
          }
        ]
      }
    }
  ]
}

Paul Church (Nov 18 2021 at 17:39):

The created resource looks like this, so it did put the uuid into the reference:

{
  "id": "9a7f77f0-134e-42a7-a9a4-69ef627f5320",
  "link": [
    {
      "other": {
        "reference": "Patient/9a7f77f0-134e-42a7-a9a4-69ef627f5320"
      },
      "type": "seealso"
    }
  ],
  "meta": {
    "lastUpdated": "2021-11-18T17:35:45.905271+00:00",
    "versionId": "MTYzNzI1Njk0NTkwNTI3MTAwMA"
  },
  "resourceType": "Patient"
}

Paul Church (Nov 18 2021 at 17:43):

I tried posting the above bundle to hapi.fhir.org and got a java.lang.StackOverflowError so....who knows

Lloyd McKenzie (Nov 18 2021 at 17:59):

Why are you including the reference at all? The ceo just doesn't have a "reports-to"...

Rick Geimer (Nov 18 2021 at 18:08):

Sorry, @Josh Mandel I meant Practitioner/ceo. Fortunately I still had a few minutes to edit it, so fixed the example above.

Rick Geimer (Nov 18 2021 at 18:10):

@Lloyd McKenzie this is a contrived example for a different self-referential use case. I'm just trying to see if create on a self-referential resource is suppose to work in FHIR at all. If not then it should likely be documented somewhere.

Rick Geimer (Nov 18 2021 at 18:12):

@Paul Church interesting solution using the transaction Bundle. Thanks! That's a potential workaround. Another we found is to make it an identifier reference.

Josh Mandel (Nov 18 2021 at 18:14):

Paul's right that POST here shouldn't work -- but if you can use PUT (specifying the id of the resource) that could work (I don't know whether it does).

Rick Geimer (Nov 18 2021 at 18:16):

Thanks Josh, I'm relaying the issue from someone else, I assumed they used POST but you are correct that shouldn't work because you can't supply an id on POST. Will see if they tried create on PUT.

Rick Geimer (Nov 18 2021 at 18:22):

They used PUT to create the resource, so my comments about POST above are a red-herring. Create on PUT with referential integrity on is not working in HAPI, so again just trying to see if that is a valid thing to do in FHIR, even if not recommended.

Basically the use case involves a profile that requires [1..1] all resources of a given type to have an extension with a reference to the managing resource instance, and having a separate profile just for the top level resource is not desirable, hence the self-reference.

Josh Mandel (Nov 18 2021 at 18:27):

Worth asking on #hapi with a specific failing example

Rick Geimer (Nov 18 2021 at 18:29):

Will do if we agree that it SHOULD work per the FHIR spec. Will also try Josh's suggestion about using "#" in the reference. @Grahame Grieve , thoughts here?

Paul Church (Nov 18 2021 at 18:53):

The PUT version works on google but does not appear to work on HAPI.

I don't see how "#" is a valid option, it only applies inside a contained resource to point to the container. Are there implementations that treat it as a general-purpose self-reference?

Grahame Grieve (Nov 18 2021 at 19:01):

I think vaguely in a general theoretical sense a resource should be able to refer to itself, but it's certainly a weird edge case, and i don't think that the specification anticipates that you can do a naked POST that works like that

Rick Geimer (Nov 18 2021 at 19:05):

Agree that POST will not work, so the question is about create on PUT.
So I'll take "vaguely in a general theoretical sense a resource should be able to refer to itself" to mean that HAPI should not outright reject it. @James Agnew ?

Rick Geimer (Nov 18 2021 at 19:10):

And <reference value="#"/> doesn't see to work when I call $validate
<diagnostics value="Unable to resolve resource '#'"/>

Grahame Grieve (Nov 18 2021 at 22:33):

<reference value="#"/> doesn't see to work when I call $validate ==> <diagnostics value="Unable to resolve resource '#'"/>

good

Lloyd McKenzie (Nov 19 2021 at 04:24):

Do we have a 'real' use-case where self-referencing is necessary/useful?

Grahame Grieve (Nov 19 2021 at 04:26):

Sounds like Rick has one but it's so bad he's embarrassed about it

Rick Geimer (Nov 19 2021 at 20:43):

Checking to see if I can discuss the actual use case publicly.

Brian Postlethwaite (Nov 19 2021 at 21:51):

If you try validating that reference to # in the dotnet validator it used to get a stack overflow (not sure if it still does as I have a check for it) specifically where resource was being posted without Id, as the resource itself was resolving and therefore try validate itself again.

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Create for self-referential resource with referential int... · implementers