Stream: IG creation
Topic: Snapshot and Differential views --- for SearchParameters!
Saul Kravitz (Jan 02 2020 at 22:25):
SearchParameters are the Rodney Dangerfield of the FHIR IG specifications -- they don' t get no respect. (OK, Capability Statements get even less respect). Designing/understanding SearchParameters requires all of the same insights as designing/understanding the structure of the resources.
As a user, there is no place (within the IG world) that one can see the COMPLETE set of SearchParameters for a resource, or which SearchParameters have been redefined in the derived profile. For a deep nesting of profiles Profile B-->Profile A--> US Core Profile --> R4 Profile...it is quite an odyssey to figure out the existing search parameters.
I suggest that an IG should include both Snapshot and Differential views of the search parameters for each profiled resource.
Eric Haas (Jan 03 2020 at 03:13):
I think we defined the SPs in US Core pretty thoroughly as SHOULDs and SHALLs and went a step further and defined whether ands, or and includes as well as combinations. I don't think there is an IG out there that has done that to this level. But this does expose the shortcomings of how SPs are defined elsewhere including the FHIR Spec as well. (The spec's sp tables take some getting used to and hide most of the details. )
If you mean to have a differential and snapshot view for only a set of selected SPs defined in a IG - I think that is doable but if SPs are exposed in all their detail only in the IG's I Think folks will be clamoring for more detail in the FHIR Spec as well. Technically this might make the spec an order of magnitude bigger than it already is and may not be manageable due to the volume of new files.
Lloyd McKenzie (Jan 03 2020 at 17:12):
Search parameters aren't characteristics of a profile, they're characteristics of a server's capabilities for a particular resource. I.e. search parameters exist at the level of Observation. You can't define different search parameters for lab results vs. vitals vs. other types of Observations. Expectations around search parameters are covered by CapabilityStatements. And those don't have snapshot or differential. A CapabilityStatement lists all expectations about what search parameters must be supported.
Eric Haas (Jan 03 2020 at 20:26):
If the sp is derived from another. You certainly could have a differential view.
Lloyd McKenzie (Jan 03 2020 at 20:45):
Not as the resources are defined, no. There's no record of any delta.
Lloyd McKenzie (Jan 03 2020 at 20:57):
Not as the resources are defined, no. There's no record of any delta.
Eric Haas (Jan 03 2020 at 21:26):
I meant you could generate a delta programmatically. But I agree there is nothing in the resource definition that defines it.
Lloyd McKenzie (Jan 03 2020 at 21:52):
Generating a delta would be challenging. The key elements are the expression and description and neither of those would be easy to diff.
Eric Haas (Jan 03 2020 at 22:38):
I’m not sure I’d try to derive a so and then rewrite the expression. I’m talking about all the extra stuff like ands , ors, comps, mods and includes
Lloyd McKenzie (Jan 03 2020 at 23:11):
You have to specify the expression even if deriving I think?
Saul Kravitz (Jan 03 2020 at 23:38):
I think you are missing the point. Unless you expect each profile to recapitulate all search parameters that are needed from the profiled resource, the poor implementer is left to perform the recursive union of all search parameters that are available.
Why not provide a listing of all available search parameters in the IG, including those defined in the IG, and those defined in the resources that are profiled in the IG? For example, the Formulary IG uses MedicationKnowledge which has a 'code' SP. The only way to know this is to read both the FormularyIG and the R4 specification, unless the formulary recapitulates the 'code' SP.
Lloyd McKenzie (Jan 03 2020 at 23:39):
A profiled resource won't list any search parameters at all. Search parameters aren't tied to profiles. They're tied to CapabilityStatements. And CapabilityStatements will list each and every search parameter (for each and every resource) that systems that conform to that CapabilityStatement are expected to implement.
Lloyd McKenzie (Jan 03 2020 at 23:40):
There is no recursive search. The CapabilityStatement will list everything relevant. There's no mechanism for inheriting search parameters from a higher-level CapabilityStatement (though you can assert conformance with another CapabilityStatement).
Eric Haas (Jan 04 2020 at 04:07):
Well I think you could summarize / aggregate all the conformance in a single view but that would be bit of effort. It might be simpler faster to just run a series of test queries on a server to discover its capabilities. In fact that is what Crucible does. You get actual vs expected. .
Eric Haas (Jan 04 2020 at 04:10):
I think the audience for ig capstatements is pretty small but important group. The server implementing the ig and the testers.
Grahame Grieve (Jan 04 2020 at 19:42):
I can see what @Saul Kravitz is getting at, but it seems difficult to know quite where it would fit, since it's not profile specific
Eric Haas (Jan 04 2020 at 23:39):
In US Core we actually expose the derived SP definitions in the narrative which would be akin to snapshot in my opinion. They are all referenced in the CapStatements and in the Profile narratives. We also added in a bunch of conformance language around the different bits. I think it would be possible to highlight the elements that are specific to the base definition which would be like the delta. But I question whether clients would use it or just do their own discovery by trial and error?
Last updated: Apr 12 2022 at 19:14 UTC
