After submitting an eICR, expect a Reportability Response (RR) document to be returned from the public health agency or routing intermediary; the RR indicates whether the condition is reportable in the relevant jurisdiction(s).
Parse the RR Composition resource to extract the reportability determination — the RR profile defines specific sections and extensions that convey jurisdiction-specific reportability status (verify section codes against the current eCR IG).
Identify the jurisdiction-level reportability information within the RR, as a single eICR may trigger reportability determinations from multiple state or local health departments.
Extract any external resources or relevant reportable condition information returned in the RR and surface them to the clinical care team as appropriate.
Store the RR alongside the originating eICR for audit and provenance purposes, linking them by the eICR document identifier.
Handle error or 'may be reportable' statuses in the RR gracefully — not all responses will be definitive, and workflows should account for indeterminate outcomes.
Known gotchas
The RR may arrive asynchronously after the eICR submission — build polling or notification handling rather than assuming a synchronous response.
Reportability status is jurisdiction-specific; an eICR submitted near a state border may yield multiple RR entries with differing determinations from different jurisdictions.
The RR Composition profile extensions for reportability status are eCR-IG-specific and not standard FHIR base elements — a generic FHIR parser will not surface them without IG-aware processing.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp