FHIR Chat · validate narrowed refererence type

Stream: conformance

Topic: validate narrowed refererence type

Jens Villadsen (Jan 14 2020 at 22:38):

I've narrow down the available reference types in my Communication profile. While the profile states it, it does not seem to be the case that the validator takes such restriction into account. I've invoked the validator as follows:
java -jar org.hl7.fhir.validator.jar comm.xml -version 3.0.2 -ig https://docs.ehealth.sundhed.dk/latest/ig -
where comm.xml looks like the following:

 <Communication xmlns="http://hl7.org/fhir">
                <id value="2002"/>
                <meta>
                    <versionId value="1"/>
                    <lastUpdated value="2019-12-05T14:53:13.251+00:00"/>
                    <profile value="http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-message" ></profile>
                </meta>
                <extension url="http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-communication-senderCareTeam">
                    <valueReference>
                        <reference value="http://organization.inttest.ehealth.sundhed.dk/fhir/CareTeam/143520"/>
                    </valueReference>
                </extension>
                <extension url="http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-thread-id">
                    <valueString value="9cace983-d0b0-4f40-a1fb-b8fefac5525f"/>
                </extension>
                <extension url="http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-title">
                    <valueString value="Message to Patient from CareTeam CGI"/>
                </extension>
                <extension url="http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-priority">
                    <valueCode value="routine"/>
                </extension>
                <status value="completed"/>
                <category>
                    <coding>
                        <system value="http://ehealth.sundhed.dk/cs/message-category"/>
                        <code value="message"/>
                    </coding>
                    <text value="Besked"/>
                </category>
                <recipient>
                    <reference value="CodeSystem/96"/>
                </recipient>
                <sent value="2019-11-25T13:30:10+01:00"/>
                <payload>
                    <contentString value="This is a 8. test message from CareTeam to Patient from CGI"/>
                </payload>
            </Communication>

I would have it expected to fail as the profile (https://docs.ehealth.sundhed.dk/latest/ig/StructureDefinition-ehealth-message.html) states that the allowed recipient reference types are Patient and Practitioner. In the example above I've used a CodeSystem reference. Why does the validator (v4.1.44-SNAPSHOT (Git# 5332a8ad603d)) not fail that - aint that a bug? (The HAPI JPA server also seems to ignore this kind of restriction when validating) @Grahame Grieve. @James Agnew It seems that it requires that I am required to do an extension on my class extending Communication in order to get this picked up by BaseHapiFhirDao.validateChildReferences. Is that correctly understood?

Jens Villadsen (Jan 15 2020 at 08:11):

I seem to remember that we had a discussion around this before but I can't remember what the result was

Grahame Grieve (Jan 15 2020 at 11:46):

the outcome is that the validator jar can't determine what the type of the target resource is, so can't validate it

Jens Villadsen (Jan 15 2020 at 13:06):

and that is because that basically it isn't spec'ed that eg. a REST call to CodeSystem/1 is allowed to return other resources than CodeSystems ... right?

Jens Villadsen (Jan 15 2020 at 13:18):

Can the validator (or more precisely ,HAPI JPA) be instrumented to a sort of 'expected referencetype' behaviour? Meaning that it would fail the example above given that CodeSystem is not a proper reference type according to the profile?

Jens Villadsen (Jan 15 2020 at 13:33):

I also guess a rough way to enforce is to add FhirPath invariants to it as I know the context of where the services run -> in a setup where all the services behave as expected, being that the endpoint CodeSystem/96 returns CodeSystems and nothing else

Jens Villadsen (Jan 16 2020 at 12:15):

I've tweaked the instance validator to do it now (with a big thanks to Anders Havn). It actually 'only' required to remove code from the instance validator.

Jens Villadsen (Jan 16 2020 at 13:43):

@Grahame Grieve expect a PR ;)

Grahame Grieve (Jan 16 2020 at 22:14):

I'm about to commit a very big change to the InstanceValidator...

Grahame Grieve (Jan 16 2020 at 22:14):

maybe you should describe the change here?

Jens Villadsen (Jan 22 2020 at 13:35):

discussion ended up here: https://chat.fhir.org/#narrow/stream/179167-hapi/topic/Host.20Validator.20in.20HAPI

Grahame Grieve (Jan 30 2020 at 20:24):

@Jens Villadsen from the next release of the validator, you'll be able to use -assumeValidRestReferences to get the validator to infer the type from the reference

Jens Villadsen (Jan 30 2020 at 21:00):

Awesome

Jens Villadsen (Jan 30 2020 at 22:04):

@Grahame Grieve I guess I'll have to make a new PR to HAPI then, extending the wrapper classes

Grahame Grieve (Jan 30 2020 at 22:04):

yes.

Jens Villadsen (Jan 30 2020 at 22:06):

// if we == null, we inferred ft from the reference. if we are told to treat this as gospel

lol ;)

Jens Villadsen (Jan 30 2020 at 23:12):

@Grahame Grieve - I've added the feature in the PR to the wrapper now

Jens Villadsen (Mar 20 2020 at 14:45):

Question nr 1) does FhirPath ofType work on references?
Question nr 2) if the answer to question nr 1 is yes, does FhirPath and assumeValidRestReferences then work in combination with ofType?