FHIR Chat · constraint on careteam (ctm-1) · hapi

Stream: hapi

Topic: constraint on careteam (ctm-1)

Jens Villadsen (Sep 16 2019 at 23:25):

Either there's something I don't get or there's a bug somewhere (it might even be both).
When posting the following (and the referenced resources do exist):

{
  "resourceType": "CareTeam",
  "participant": [
    {
      "member": {
        "reference": "Practitioner/1"
      },

      "onBehalfOf": {
        "reference": "Organization/2"
      }
    }
  ]
}

• the validator component keeps stating "CareTeam.participant.onBehalfOf can only be populated when CareTeam.participant.member is a Practitioner [onBehalfOf.exists() implies (member.resolve() is Practitioner)]" - which is the constraint ctm-1. I just can't seem to understand why? Funny thing is that seems not to be a problem if I first create the participant, and then afterwards update the participant to be onBehalfOf.

James Agnew (Sep 17 2019 at 00:11):

Are you able to replicate this on our public server?

Grahame Grieve (Sep 17 2019 at 00:16):

which FHIR version is this?

Grahame Grieve (Sep 17 2019 at 02:47):

ok so I looked into this. It's an interesting constraint - if the validator cannot resolve member, then the constraint fails.

Grahame Grieve (Sep 17 2019 at 02:48):

I think that this is not right, and probably not what PA meant (@Brian Postlethwaite @Cooper Thompson ) so I think that this should be fixed as a technical correction to:

Grahame Grieve (Sep 17 2019 at 02:48):

onBehalfOf.exists() implies (member.resolve().empty() | member.resolve() is Practitioner)

Brian Postlethwaite (Sep 17 2019 at 03:15):

I agree, however that's a Patient Care resource, @Michelle (Moseman) Miller

Grahame Grieve (Sep 17 2019 at 04:08):

oops

Jens Villadsen (Sep 17 2019 at 06:30):

@James Agnew - I tried at your public test server and it doesn't fail. Could it be that it runs with a config that resembles the one from the hapi-fhir-starter project - because by default it does not have validation enabled. https://github.com/hapifhir/hapi-fhir-jpaserver-starter/blob/cc7a56be2047bb323c9126a5d259f18c55763df8/src/main/resources/hapi.properties#L45

Jens Villadsen (Sep 17 2019 at 06:34):

@Grahame Grieve if this is my chance to learn some fhirpath, could you explain why it currently does fail? does the "member.resolve"-part expect that member is contained within the resource? You added tthe member.resolve().empty(), but member is a reference and not empty.

Grahame Grieve (Sep 17 2019 at 09:25):

resolve() hunts down the resource from whereever. So this says if there's an onBehalfOf, what the member points to must be a Practitioner. So if resolve() can't find the practitioner, that won't be true, and the invariant fails.

member.resolve().empty() would be true if resolve() didn't work

Jens Villadsen (Sep 17 2019 at 09:55):

so how should resolve() actually be implemented in this case? The member is a "reference": "Practitioner/1" - which pretty clearly is a relative reference with the type embedded in the reference. Shouldn't this be sufficient enough?

Jens Villadsen (Sep 17 2019 at 09:57):

@Grahame Grieve on a side note, when can the org.hl7.fhir.core be expected contain this fix?

Grahame Grieve (Sep 17 2019 at 09:58):

contain what fix?

Jens Villadsen (Sep 17 2019 at 09:59):

the technical correction

Grahame Grieve (Sep 17 2019 at 09:59):

The member is a "reference": "Practitioner/1" - which pretty clearly is a relative reference with the type embedded in the reference

well, it's intuitively obvious, but it's not actually clear.

Jens Villadsen (Sep 17 2019 at 10:02):

I had an idea that https://www.hl7.org/fhir/references.html#literal sort of stated that

Grahame Grieve (Sep 17 2019 at 10:03):

right. it's only sort of

Jens Villadsen (Sep 17 2019 at 10:03):

But then again - I can't seem to find a place that says that relative references are required to contain a valid type prefix

Grahame Grieve (Sep 17 2019 at 10:03):

y

Jens Villadsen (Sep 17 2019 at 10:03):

shouldn't that be part of the spec?

Grahame Grieve (Sep 17 2019 at 10:05):

you think that the spec should say that a FHIR Server cannot reference a resource by a relative URL unless it serves it up using the FHIR Api?

Jens Villadsen (Sep 17 2019 at 10:05):

no ...

Grahame Grieve (Sep 17 2019 at 10:05):

so that's why the validator doesn't assume that a relative reference works that way

Jens Villadsen (Sep 17 2019 at 10:08):

im saying the reference should be valid - I said nothing about how it should be served

Jens Villadsen (Sep 17 2019 at 10:09):

so it should be valid to reference it that way

Grahame Grieve (Sep 17 2019 at 10:09):

what is 'valid' in this case? Is it allowed to reference a file on disk like /resources/old-archive/something.xml?

Jens Villadsen (Sep 17 2019 at 10:10):

i guess the valid part should be to check if the path to the file contained the /resources/old-archive/ part

Jens Villadsen (Sep 17 2019 at 10:11):

for starters

Jens Villadsen (Sep 17 2019 at 10:12):

so for instance, if the reference was "reference": "Patient/1"instead, its not a practitioner ... but this part might not be part of the FhirPath validation part, right?

Jens Villadsen (Sep 17 2019 at 10:13):

this can be verified at another level

Jens Villadsen (Sep 17 2019 at 10:13):

before the fhirpath engine gets to it, right

Grahame Grieve (Sep 17 2019 at 10:18):

I didn't follow all that. So "/resources/old-archive/something.xml" is a valid reference. You have to fetch from the url to find out what it is. And that's perfectly valid.

So then, we never say that if the resource reference looks like [Type]/[id] that it must be of the implied type. I say that in many places in my server implementation because I know that my server doesn't support anything else.

But the validator can only make that assumption if the standard says it, and it doesn't. Or if it actually fetches from the URL, and checks the type - which is what it tries to do.

Should the standard say that? Maybe.... it would be a reasonable constraint, but it's very difficult to make it now, given that the normative parts of R4 allow for a reference like [Type]/[id] to reference a resource with a different type than what's implied

Jens Villadsen (Sep 17 2019 at 10:31):

yikes ... I get that there are now normative parts that are sort of untouchable, and a pity that this is part of it. I actually thought that if resources were served on a RESTful FHIR server, that they had to be served under [Type]/ (while still allowing for [CustomType]/ - that would however not be part of the FHIR std).

James Agnew (Sep 17 2019 at 10:32):

REST servers have to work that way. I believe the issue is more that the validator can't make assumptions that it's talking to a rest server, since it works in all kinds of contexts.

Jens Villadsen (Sep 17 2019 at 10:32):

Should the standard say that? Maybe.... it would be a reasonable constraint, but it's very difficult to make it now, given that the normative parts of R4 allow for a reference like [Type]/[id] to reference a resource with a different type than what's implied

Should this then be part of a best-practice IG if it cannot be changed in the spec? As you say, its a 'reasonable constraint'

Jens Villadsen (Sep 17 2019 at 10:34):

@James Agnew right, I'm actually a bit puzzled to hear that the validator actually thinks that it is allowed to fetch those resources (using REST?)

James Agnew (Sep 17 2019 at 10:34):

Put differently: there is no rule that an arbitrary FHIR resource that you got from an arbitrary place has to have references that conform to the FHIR Rest spec

James Agnew (Sep 17 2019 at 10:35):

Well, that's the whole idea here.. resolve() just means "try to get that target, however you would do it in whatever context you're working in". The intent of the invariant here is presumably that it wants to not fail if the validator is working in a context where it's not feasible to fetch the target.. but the issue you've found is that this logic isn't working

Grahame Grieve (Sep 17 2019 at 10:36):

the FHIRPath statement is clear: verify that the target is a Practitioner. And by the rules of the spec, that can't be verified unless the resource can actually be fetched

Grahame Grieve (Sep 17 2019 at 10:37):

can that be fixed? well, under the rules: if everyone agrees

Grahame Grieve (Sep 17 2019 at 10:37):

might happen with this issue

Jens Villadsen (Sep 17 2019 at 10:37):

This would require arbitrarily bootstrapping of the validator providing it a context of where it could fetch resources - be that wherever

Grahame Grieve (Sep 17 2019 at 10:37):

yes, that's how the validator is written

Jens Villadsen (Sep 17 2019 at 10:38):

I have no recollection of me bootstrapping the validator

Jens Villadsen (Sep 17 2019 at 10:38):

Put differently: there is no rule that an arbitrary FHIR resource that you got from an arbitrary place has to have references that conform to the FHIR Rest spec

James Agnew (Sep 17 2019 at 10:41):

Jens, how are you using the validator here? ie. running in a HAPI server and using RequestValidatingInterceptor, manually creating a FhirValidator and injecting a FhirInstanceValidator module, using the command line validator, etc?

Grahame Grieve (Sep 17 2019 at 10:47):

ok. moved the dsicussion on the reference issue to the implementers channel.

Jens Villadsen (Sep 17 2019 at 10:50):

@James Agnew We're creating a custom FhirValidator and injecting it into the RequestValidatingInterceptor

Jens Villadsen (Sep 17 2019 at 10:51):

so, declaring a bean in fhirserverconfig with the name myInstanceValidatorDstu3

Jens Villadsen (Sep 17 2019 at 10:51):

and extending the FhirInstanceValidator

Grahame Grieve (Sep 17 2019 at 10:51):

and are you providing a fetcher?

James Agnew (Sep 17 2019 at 10:51):

Is this in a JPA server or a non-JPA server?

I curious here because despite all this, I'd expect all this to work, at least in a JPA server... This might be an issue with HAPI's wrapper.

Grahame Grieve (Sep 17 2019 at 10:52):

it's still possible it's an issue in the validator. I got distracted by the spec issue and haven't finished testing yet

Jens Villadsen (Sep 17 2019 at 10:54):

JPA server

James Agnew (Sep 17 2019 at 10:55):

Can you upload an example to the public test server so that you can link to its ID with /$validate at the end?

Jens Villadsen (Sep 17 2019 at 10:57):

http://hapi.fhir.org/baseDstu3/CareTeam/2574263/_history/1

Jens Villadsen (Sep 17 2019 at 10:58):

http://hapi.fhir.org/baseDstu3/CareTeam/2574263/_history/1/$validate

Jens Villadsen (Sep 17 2019 at 11:11):

Is this in a JPA server or a non-JPA server?

I curious here because despite all this, I'd expect all this to work, at least in a JPA server... This might be an issue with HAPI's wrapper.

As we are in micro service setup with FHIR servers scattered all around we also provide custom logic on the ResourceLinkExtractor

Jens Villadsen (Sep 17 2019 at 11:12):

This is sort of related to fetching resources located elsewhere

Jens Villadsen (Sep 17 2019 at 11:13):

where we do an HTTP HEAD with the proper authentication mechanisms bootstrapped into the call (shipping bearer tokens around in the current call context)

Jens Villadsen (Sep 17 2019 at 11:23):

http://hapi.fhir.org/baseDstu3/CareTeam/2574263/_history/1/$validate

@James Agnew here you go

Jens Villadsen (Sep 17 2019 at 11:24):

I guess we might should provide some of the same logic into the validator if needed

James Agnew (Sep 17 2019 at 11:25):

tx- i'll take a look at this a bit later

Jens Villadsen (Sep 18 2019 at 12:49):

@Grahame Grieve - I found this: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=12707 - isn't this related?

Grahame Grieve (Sep 18 2019 at 12:50):

certainly looks like it....

Grahame Grieve (Sep 18 2019 at 12:51):

not sure what what the deal is...

Jens Villadsen (Sep 18 2019 at 12:51):

just seems like you have stumbled across this before

Grahame Grieve (Sep 18 2019 at 12:52):

y. not sure what I did then... probably fixed an issue in resolve() and overlooked the real error

Last updated: Apr 12 2022 at 19:14 UTC