FHIR Chat · Constraints / rule sets on SearchParameter · implementers

Stream: implementers

Topic: Constraints / rule sets on SearchParameter

Kenneth Myhra (May 31 2019 at 10:47):

I am looking into the SearchParameter 'composition' on Bundle and it has a constraint that that is only expressed textually: The first resource in the bundle, if the bundle type is "document" - this is a composition, and this parameter provides access to search its contents.

As far as I see it should be trivial to express this as a constraint on the SearchParameter using i.e. FhirPath. For me it would make sense to use this constraint primarily when indexing the resource.
So I am wondering if there has been a discussion to add such a constraint attribute to the SearchParameter resource or if I am overlooking something in the specification that would enable this?

Kenneth Myhra (Jun 03 2019 at 07:46):

GForge #22653

Paul Church (Jun 03 2019 at 16:17):

I've been looking at Bundle-composition and Bundle-message in detail recently - they're quite unusual search parameters. They are the only place I can find where an explicit array index appears as part of a search param (in the base spec), they specifically index contained resources, and their definitions depend on the bundle type and express very specific requirements/assumptions about what the bundle type implies.

If the spec had richer support for this case, would it be used in more places? If not, would a more simple spec be better with these unusual cases relaxed to something like "composition: searches the contents of any Composition in the bundle"?

Lloyd McKenzie (Jun 03 2019 at 16:45):

We don't want any composition inside the Bundle. The first Composition in a document Bundle has special meaning. It represents the metadata for "This" document. Any other Compositions would be content of the document but wouldn't describe the document.

Lloyd McKenzie (Jun 03 2019 at 16:48):

The only places where the first resource has special meaning are for documents and messages. It's certainly possible we could come up with another usecase in the future, but we don't have any specific plans as yet

Rick Geimer (Jun 03 2019 at 19:22):

Discussed on FHIR-I today, but decided we need more input from server vendors.

Kenneth Myhra (Jun 03 2019 at 19:47):

Example of a SearchParameter with the attribute 'constraint' added:

{
    "resourceType": "SearchParameter",
    "id": "Bundle-composition",
    "name": "composition",
    "code": "composition",
    "base": [
        "Bundle"
    ],

    // Proposing to add this attribute
    "constraint": "Bundle.type = 'document' and Bundle.entry[0].resource.resourceType = 'Composition'",

    "type": "reference",
    "expression": "Bundle.entry[0].resource",
    "xpath": "f:Bundle/f:entry[0]/f:resource",
    "xpathUsage": "normal",
    "target": [
        "Composition"
    ],
    "multipleOr": true,
    "multipleAnd": true,
    "modifier": [
        "missing",
        "type",
        "identifier"
    ]
}

Paul Church (Jun 03 2019 at 19:49):

Is the evaluation of the constraint essential to the document/message use case? If Bundle-composition searched any bundle whose entry[0].resource was a Composition, the client could add &type=document to their query.

If constraints are needed, then I agree they should be explicit and encoded as fhirpath to be evaluated by the server.

I'm not convinced that constraints are a good idea, based on the balance of complexity vs. usefulness. Arbitrary fhirpath constraints are very broad and would be a big door to open just to support this. Are there more use cases than just Bundle, or use cases where the constraint is not something trivially expressed with an extra search term like &type=document?

Lloyd McKenzie (Jun 03 2019 at 20:18):

In theory we could have squished both parameters into one - at the expense of everyone using the new search parameter always needing to filter on Bundle type. However, Bundle is now normative, so we're past the point where we can debate whether that would be a good idea or not.

Kenneth Myhra (Jun 03 2019 at 21:10):

To be able to evaluate the SearchParameter in the document/message use case the constraint is very much needed from my point of view. So, although we could use the target attribute to infer what types are allowed in entry[0].resource, there is no way to express type=document or type=message without the constraint attribute. There is also the option of modifying the expression in the expression attribute to use an iif, but that would probably break current implementations.

okyere sharaf deen (Jun 10 2019 at 17:00):

hello, please i am new to fhir, i am a developer, our team would like to implement fhir in our health application, can someone please help me with the step my step procedure of how to comply with hl7 fhir, i have read so many documents and cant make any sense of it. please help if you can

Grahame Grieve (Jun 10 2019 at 17:29):

there's no real general introduction because the kind of problems you might encounter vary so wildly. Do you have a relational database? what platform is the application in?

Lloyd McKenzie (Jun 10 2019 at 17:56):

Complying with FHIR can be done in a wide variety of ways. Do you know who you want to operate with and in what context? There are often additional implementation guides that provide further expectations in different countries and for different use cases.

Last updated: Apr 12 2022 at 19:14 UTC