Clarify patient/category search for DiagnosticReport about us-core HOT 8 OPEN

@brettmarquard the other example you linked to says:

SHALL support searching using the combination of the patient and code search parameters:

... which I take to mean that a client can supply any code it wants, and the search should work. (So in that case, for DiagnosticReport notes, the code isn't "fixed in place" to a single value.)

from us-core.

That particular profile is 'scoped' to lab only -- is this page more clear for the generic DiagnosticReport Notes profile?
https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-diagnosticreport-note.html

from us-core.

Note that the same issue comes up on other pages where the text says "by category" but the example suggests that only a single (fixed) category value needs to be supported. E.g. http://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-careplan.html#mandatory-search-parameters

from us-core.

The mentioned profiles (us-core-careplan, and us-core-diagnosticreport-lab) have 'fixed' categories. @jmandel Should we add a note in implementation guidance to make that clear?

from us-core.

The quick start is generated using a script and template. And the search parameter is fixed in the formal notation. but not in the text since is describing the parameter in general. also mention in the implementation notes. Do you have a suggestion for making it clearer. WE will try to avoid manually editing these and update the script if possible.

from us-core.

My suggestion would be instead of

SHALL support searching using the combination of the patient and category search parameters:

to say

SHALL support searching using the patient search parameter with a fixed category

Or something to that effect. If you want to try to address this purely within the "Implementation Notes," then state "The server SHALL support queries with a fixed category of http://hl7.org/fhir/us/core/CodeSystem/careplan-category|assess-plan and MAY support other categories."

from us-core.

I will need to defer this til later not trivial change to the script right now.

from us-core.

This won't be resolved prior to STU comment period -- @Healthedata1 will review new ways to generate.

from us-core.