Event-Driven Retrieval
Event-driven retrieval delivers clinical records as they become available rather than requiring the requester to initiate a retrieval action. Organizations subscribe to defined event types and receive notifications when new documents or updates are available. In this model, Health Gorilla monitors network responses and delivers changes through webhook-based subscriptions or polling endpoints, supporting near-real-time data delivery and reduced query volume.
Key Characteristics
| Attribute | Behavior |
|---|---|
| Response model | Automatic delivery triggered by new events |
| Data storage | Stored and normalized in Health Gorilla before delivery (for standard data sources) |
| Record formats | Delivered as FHIR R4 bundles or as document metadata and Binary content |
| Identity handling | Identity validated and linked through MPI |
| Delivery mechanism | Webhooks (preferred) or polling endpoints |
| Notification payload | Event details and links for retrieval |
| Viewer visibility | Displayed in Patient Viewer once processed |
| Audit visibility | Full lifecycle visible in audit logs |
Use Cases
Event-driven retrieval is commonly used when:
- Near-real-time delivery is required for care coordination
- Systems need to monitor for new records after an initial query
- Workflows depend on continuous updates rather than periodic polling
- Volume and performance requirements make full retrieval inefficient
General Workflow
Event-driven retrieval follows a publish-and-notify model.
- A subscription is created for defined event types
- Health Gorilla monitors network and source responses
- New documents or updates trigger an event
- A notification is delivered through webhook or polling channel
- The retrieving system uses the included links to fetch records
- Documents are processed and made available for viewing or ingestion
Common Outcomes
| Result Behavior | Explanation |
|---|---|
| Immediate delivery of new records | New documents appear after initial retrieval |
| Multiple notifications for the same patient | Additional source systems responding at different times |
| No notifications after subscription | No new clinical activity within the request criteria |
| Gaps or delays | Variable response timing from external networks |
| Webhook errors | Delivery endpoint unavailable or unresponsive |
Outcome Expectations
Event-driven retrieval supports:
- Continuous record updates without manual re-queries
- Reduced workload and API traffic compared with repeated retrieval requests
- Faster visibility into new care events
- Predictable, structured notification and auditing patterns
Best Practices
- Use webhooks for the most reliable asynchronous delivery
- Implement retry logic for webhook reception failures
- Monitor subscription configuration and expiration
- Validate notification timestamp and event type before download
- Use audit history to confirm delivery status and processing path