A Path expression language for #FHIR

Dec 1, 2015

Since the beginning of working with FHIR, we’ve had a number of contexts in the specification where we’ve need to refer to a particular element within a resource, or make rules on the properties of the elements in a resource. Over time, that list has grown, and within the specification we now have the following places for this: * search parameter paths - used to define what contents the parameter refers to

  • invariants in ElementDefinition, used to apply co-occurance and other rules to the contents
  • slicing discriminator - used to indicate what element(s) define uniqueness
  • error message locations in OperationOutcome

In addition, Smart on FHIR’s cds-hooks has a template approach which really needs something like this, and we have an identified need for patch which needs something like this. In addition, implementations may find other uses for this as well - I know I have several places where I need to refer to content in a resource dynamically. One really important context is a formal mapping specifications

Up to now, we’ve used a mix of XPath and informal dotted notations. Feedback from implementers is that this is a barrier to adoption, and we need a better approach. XPath is a problem because:

  • XPath is XML specific
  • We’ve used XPath2 features in our XPaths, and XPath2 is very poorly supported to the point
  • XPath is overkill for the simply use cases, and too hard for the complex use cases

As for JSON, there’s a raft of variations around “XPath for JSON”, but none of them seem to be on any standards path. And what we really need is a single language that works for both XML and JSON, and is easy to use for simple cases, and powerful enough for the difficult cases. It become clear, working with implementers after the publication of DSTU2, that it was time to address this. And it was clear that we need to define our own language for this (this is contentious - surely, people say, there is already something out there for this, so we waited for 3 years before acting on this, but eventually we couldn’t wait).

So we’ve defined a little expression language for these purposes. Several of us have implemented processing engines for it, to validate the approach. It’s not part of the formal specification right now, but it’s certainly something we expect to make part of it.

Useful Links:

Note: we’ve not formalised any of this yet - including the name “FHIRPath”. Discussion and suggestions on names, syntaxes, and approaches is all welcome