Oracle Health Data + FHIR
Mapped a nested FHIR Patient resource into a flat destination record, preserving source values and checking required output fields.
Problem & approach
Situation
FHIR resources contain nested objects and arrays that do not directly match a simple reporting or downstream record format.
Goal
Extract selected patient fields into a documented flat schema without inventing missing detail or changing source values.
Solution
Retrieved test Patient JSON, mapped source paths to destination fields, flattened selected values, and checked required output fields.
How the data flows
A small integration exercise from source resource to checked destination record.
- FHIR sourcePublic test Patient JSON
- Field mappingSource paths → target fields
- TransformationExtract + flatten selected values
- ValidationCheck required destination fields
- DestinationFlat record + check status
Follow the integration
Open each artifact to inspect the pipeline, field mapping, and validation output.
Key design decisions
Mapping layer
Document source JSON paths for identifiers, demographics, names, and language. Distinguish direct mappings from nested-value extraction.
Preservation layer
Keep source values intact, including partial dates. Avoid adding precision that is absent from the original resource.
Validation layer
Check required destination values after transformation. These exercise-specific checks confirm selected output requirements, not full FHIR conformance or production readiness.
What the project delivers
- A test Patient resource retrieved from the public FHIR environment.
- Documented source-to-destination field mappings.
- A flat record extracted from nested JSON.
- Four configured integration checks reported as passed in the project output.
- A traceable example of data mapping, preservation, and validation.