References lack a type arc

[dbooth-boston]

(Background material copied from: https://github.com/fhircat/fhir_rdf_validator/blob/master/tutorial/FHIRR5.md#references )

FHIR references require two additions:

1) The Reference data type includes the reference attribute, a "Literal reference, Relative, internal or absolute URL". If this is a relative reference, it is relative to the parent of the resource, not the resource itself. As an example, if the resource at the URL https://fhirserver.org/Observation/o12345 contains a reference to "Patient/P1111, the full URI reference would be "https://fhirserver.org/Patient/P1111" instead of "https://fhirserver.org/Observation/Patient/P1111", which is what you would get with a normal web page. As a consequence, ".." needs to be prepended to any relative Reference.reference entry.

As opposed to R4, which injected a "link" arc between the subject and the object, we want to make the connection as direct as possible.

2) When possible, R4 Specification also add a "type arc" in the form <http://hl7.org/fhir/Patient/f001> a fhir:Patient . Sometimes this is explicitly available

Sample 1 JSON

{
  "resourceType": "Observation",
  "id": "obs1",
  "subject": {
     "reference": "Patient/f001",
     "display": "P. van de Heuvel"
  }
}

Sample 1 RDF R5

@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix fhir:  <http://hl7.org/fhir/> .
@prefix exObs:  <http://build.fhir.org/Observation/> .
@prefix exPt:  <http://build.fhir.org/Patient/> .

exObs:obs1  a  fhir:Observation ;
    fhir:nodeRole             "fhir:treeRoot" ;
    fhir:Observation.subject  exPt:f001 ;
    fhir:Observation.subject  [ 
        fhir:Reference.display    "P. van de Heuvel" ;
        fhir:Reference.reference  "Patient/f001"  
        ] ;
    fhir:Resource.id          "obs1" .

exPt:f001  a  fhir:Patient .

Example

Sample 2 JSON

{
  "resourceType": "Observation",
  "id": "bmd",
  "subject": {
    "reference": "http://example.org/nonfhirurl/bmd",
    "type": "Patient"
  }
}

Sample 2 RDF R5

@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix fhir:  <http://hl7.org/fhir/> .
@prefix exObs:  <http://build.fhir.org/Observation/> .
@prefix ex:  <http://example.org/nonfhirurl/bmd> .

exObs:bmd  a  fhir:Observation ;
    fhir:nodeRole             "fhir:treeRoot" ;
    fhir:Observation.subject  ex: ;
    fhir:Observation.subject  [ 
        fhir:Reference.reference  "http://example.org/nonfhirurl/bmd" ;
        fhir:Reference.type       "Patient"  
        ] ;
    fhir:Resource.id          "bmd" .

ex:  a  fhir:Patient .

Example

Sample 3 JSON

{
  "resourceType": "Observation",
  "id": "bmd",
  "subject": {
    "reference": "http://example.org/nonfhirurl/bmd"
  }
}

Sample 3 RDF R5

@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix fhir:  <http://hl7.org/fhir/> .
@prefix exObs:  <http://build.fhir.org/Observation/> .
@prefix ex:  <http://example.org/nonfhirurl/> .

exObs:bmd  a fhir:Observation ;
    fhir:nodeRole             "fhir:treeRoot" ;
    fhir:Observation.subject  ex:bmd ;
    fhir:Observation.subject  [ 
        fhir:Reference.reference  "http://example.org/nonfhirurl/bmd"  
        ] ;
    fhir:Resource.id          "bmd" .

[ericprud]

One particularly challenging corner case is that nothing says that "reference": "Patient/f001" references, get this, a Patient. FHIR servers are supposed to follow a convention there, and odds are that, if you've got (FHIR-style) relative URLs, you're operating in a FHIR server's address space. But "reference": "http://outthere.example/Patient/f001" could be referencing anything.

Lack of power comes with lack of responsibility.

We can't make the reference names tell us what the real type is, but we can say we're only interested in the cases where they do, or at least provide extra features where they do.

[gaurav]

If anybody's curious, here's a (quick and possibly incomplete) list of references from FHIR r4 and FHIR r5 example files: references.txt

[dbooth-boston]

Apparently I missed the fact that a FHIR Reference -- at least now anyway -- already has an optional "type" property, such as "type": "Patient" in the "Sample 2 JSON" above. When that property is present, the actual type of the referenced resource must be that specified type.

@ericprud , does the preprocessor already make use of this "type" property to emit a type arc, and use it in preference to microparsing the refererence URL (if it is a relative URL)? If so, it sounds like we are already doing all that we can, short of dereferencing the reference URLs to find out what kind of resource is returned.

[ericprud]

@ericprud , does the preprocessor already make use of this "type" property to emit a type arc

Yes, there's a genFhirReference function invoked on every reference property. It might need some improvement; I've not dug into it. One option would be to make the behavior on absolute URLs dependent on some config option.

  genFhirReference(fhirObj) {
    let typ, link
    if (!fhirObj.reference.includes('://') && !fhirObj.reference.startsWith('/')) {
      typ = 'type' in fhirObj ? fhirObj.type : fhirObj.reference.split('/', 1)[0]
      link = '../' + fhirObj.reference
    } else {
      link = fhirObj.reference;
      typ = fhirObj.type
    }
    let rval = { '@id': link };
    if (typ) {
      rval['@type'] = 'fhir:' + typ
    }
    return rval
  }
}

[dbooth-boston]

ACTION: DBooth to ask the FHIR community about requiring a type property when a ref is an absolute URI

[dbooth-boston]

I asked on zulip, and Lloyd McKenzie replied: "You can parse the URL of the absolute reference. It's required to be [base]/[type]/[id] or the version-specific variant. If you parse from the right you can get the type." https://chat.fhir.org/#narrow/stream/291844-FHIR-Validator/topic/Requiring.20the.20type.20of.20a.20Reference/near/287238355

It looks like we should try this in the preprocessor.

[dbooth-boston]

This issue is not specific to RDF, so it does not affect our R5 proposals.

[dbooth-boston]

dbooth: Grahame pointed out that this would be a breaking change to make the "type" property required in the case of an absolute URL reference, so it isn't a change we can make. And we can live with it anyway. eric: This would mostly affect validation of local internal hospital networks. dbooth: Close the issue with no change? eric: Close with a note saying we do not validate cases with absolute URLs beyond what FHIR requires for validation.

[dbooth-boston]

AGREED: Close #95 with no change.

https://www.w3.org/2022/07/28-hcls-minutes.html#t07