In the US Core Implementation Guide for DiagnosticReport, specific implementation guidance, it says: "The DiagnosticReport.category binding must support at a minimum the 3 concepts of Cardiology, Radiology, and Pathology. Other categories may be supported"

I have two concerns:

1. Are these the right concepts (Common procedures that are a mixture between Radiology and Cardiology: Nuclear medicine stress test, Interventional Radiology Cath)? Two different organizations may classify a single procedure two different ways.

2. If the procedures will be inconsistently mapped between these three concepts, is it worth making it a requirement? If it is a requirement, clients will rely on this mapping in order to refine their requests and filter out results they think they don't need.

These two things combined (Requirement to map to these ambiguous categories) will lead to servers filtering out results without the client knowing because a procedure is not mapped to the category the client expected.

Potential Solutions:

• We make the required categories less-specific (like imaging vs lab)... it will limit the ambiguity, but we won't get the value that a more-specific category grants us.

• Don't provide a required valueset at all (but still require support for a category search)... Organizations will each use their own categorizations (discoverable using ValueSet.$expand), which will still not be consistent, but it can be more precise (they already would have to do this for other categories, like GI or Micro).

• Make the category search parameter optional with an example valueset... Clients can still search by code, which eliminates ambiguity, but they still have to work with each server to figure out what LOINC codes to use, or what category codes the server uses.

• Just keep doing what is proposed (require category mapping to Rad/Card/Path)... Easy for clients, but concerns noted above. Also more work for organizations that have to do all the extra mapping/maintenance.

What I propose we should do:

• Make Category search parameter optional and have the valueset be an example. As proposed in the US Core IG, it isn't useful/clean enough to require support for those specific values.