Stream: Da+Vinci+PDex+Plan-Net
Topic: SearchParameters DerivedFrom
Fred Harmon (Dec 14 2020 at 13:29):
I'm trying to help our QA team understand how to test search parameters for Plan Net and better understand why they exist. What I could not explain was how plan net search parameters differ from those they are based on/extended from. For example, Plannet_sp_organization_name (https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/SearchParameter-organization-name.html), why does this exist or why was this search parameter created?
How can I tell if there is a difference between the way searching by code "name" on an Organization in R4 would be different than what Plan Net has created? Do the constraints differ than the underlying search such that when they test they can tell we've correctly implemented plan net versus just having core R4 support? The "derivedFrom" links don't seem to work on these pages (ex http://hl7.org/fhir/SearchParameter/Organization-name).
Thanks
Fred
Saul Kravitz (Dec 14 2020 at 14:19):
hi @Fred Harmon . Good questions. I find this one of the weaker aspects of the FHIR IG package in general (and probably Plan-net in particular).
The Plan-Net search parameters represent a pruned set of VhDir search parameters, tweaked to reflect the Plan-Net IG.
Two of the SPs (Organization:coverage-area and PractitionerRole:network) are novel, and refer to extensions introduced in the Plan-Net IG.
The only differences in the 'native' SPs included id in Plan-Net are the chaining on *:location, which includes "address-postalcode",
"address-city", "address-state". The only way to tell the difference is to eyeball the definitions, I'm afraid. Ideally, the subset of the SPs that are in the base resource that are required by the profile would be referenced directly in the CapStmt, and only those that differed would be redefined. I don't think we did any worse than USCore in this area, but I share your (implied) opinion that this isn't very good.
Last updated: Apr 12 2022 at 19:14 UTC
