Validation and Processing
All submitted data is validated and processed to ensure it meets FHIR and network interoperability standards. Validation occurs before storage or routing, and each submission generates either a success response or an OperationOutcome detailing issues found.
Processing includes basic integrity checks and job tracking, with normalization and deduplication handled in subsequent stages of the data pipeline.
Validation
Each submission is checked for completeness, conformance, and authorization.
| Validation Type | Description | Common Handling |
|---|---|---|
| FHIR Schema Validation | Ensures submitted resources conform to FHIR R4 structure definitions and required fields. | Invalid resources return a 422 Unprocessable Entity response with a detailed OperationOutcome. |
| Reference Integrity | Verifies that linked resources such as patient, practitioner, and encounter are valid and accessible. | Missing or invalid references cause the submission to fail validation. |
| Consent and Authorization | Confirms that appropriate consent and access controls are in place for the submitted patient. | Failing consent checks results in a 403 Forbidden response. |
| Vocabulary Validation | Checks coded fields against supported terminologies (for example, LOINC, SNOMED CT, RxNorm). | Invalid or unmapped codes are flagged or rejected, depending on tenant policy. |
Processing and Response Handling
Validated submissions are queued for processing and tracked through asynchronous jobs when applicable.
| Process | Description | Common Handling |
|---|---|---|
| Asynchronous Processing | Large or batched submissions are processed in the background. | Responses include a 202 Accepted status with a job URL for polling or webhook notifications. |
| Synchronous Processing | Used only for lightweight requests requiring immediate confirmation. | Returns the created or updated resource on success. |
| Error Handling | Validation or processing errors are returned as OperationOutcome resources. | Includes issue codes and diagnostics to assist troubleshooting. |
| Audit Logging | All submissions are logged with timestamps, identifiers, and processing outcomes. | Enables full traceability for compliance. |
Post-Submission Steps
After successful processing:
- Data enters the normalization and deduplication workflow to align codes, metadata, and identifiers.
- Normalized records become available for retrieval through Patient360 and network queries.
- Rejected submissions remain viewable in audit logs with error context for correction.
Implementation Details
- Invalid submissions return detailed OperationOutcome responses.
- Required metadata (for example, patient identifiers) must be included in every request.
- Async jobs can be monitored using the returned status endpoint.
- Processing times vary by payload type, size, and tenant configuration.