At a glance
From January to March 2026, I independently designed and built a multi-agent mapping assessment framework for IBM Curam → HL7 FHIR R4. Specialized Copilot roles divide planning, mapping, review, and orchestration; reusable Skills guide domain reasoning, while Python checks and BA feedback evaluate the results.
- Tables processed
- 2,000+
- Effective mappings · Full-set BA review
- 95%+
The challenge
Curam social-services tables and FHIR resources do not map one-to-one. A broad prompt to “map these tables and summarize the results” combines business interpretation, resource selection, generation, and checking in one response. I decomposed those responsibilities into bounded tasks, explicit rules, and review gates, so proposals could be inspected before processing more tables.
My contribution
I defined four cooperating agent roles and four reusable Skills, implemented the validator and progress tracking, and built the Python preparation and Excel export tools. Technical design and implementation were entirely my responsibility; BAs assessed business usefulness.
| Agent | Responsibility |
|---|---|
| Planner | Discover and order inputs, check reference availability, initialize progress. |
| Mapper | Assess one batch; write structured proposals with rationale and extension needs. |
| Reviewer | Challenge semantic fit and precedent use; approve or block the batch. |
| Orchestrator | Delegate mapping and review, run validation, track progress, and select the next batch. |
How the workflow works
- Download HTML Selected tables from CSV
- Parse & normalize Table metadata → JSONL
- Split by table One JSON file per table
- Build batches Word inputs for Copilot
Shared Skills · domain classification · resource selection · precedents · QC
- Mapper agent Propose mappings + rationale
- Python validator Check deterministic rules
- Reviewer agent Challenge semantics & fit
Validation or review failure → pause for correction
- Mapping JSON Cumulative results
- Excel workbook Run export script
- Human BA review Assess business usefulness
The preparation script downloads and normalizes table metadata, checks counts, and generates Word batches—35 tables by default. After planner initialization, one orchestrator prompt drives all remaining batches, invoking mapper and reviewer as subagents around the Python validation gate. Progress distinguishes mapped from reviewed batches; failures pause the run for correction. Excel export is started separately.
Skills that guide the reasoning
Four task-specific SKILL.md files turn domain knowledge into reusable guidance. They define permissible choices, evidence to consider, and mistakes to challenge, aiming to reduce unsupported conclusions and irrelevant output.
| Skill | Guidance |
|---|---|
| Domain classification | Choose from ten business domains using descriptions, attributes, and precedents. |
| FHIR resource selection | Select resource-level targets by semantics; justify candidate choices and rejections. |
| Reviewed precedents | Apply reviewed patterns with explicit differences; do not copy historical decisions blindly. |
| Mapping QC | Specify output, extension, semantic-review, and progress-consistency checks. |
Within this assessment, FHIR Task is reserved for caseworker work items, not workflow-engine runtime records. Each proposal records source context, candidate decisions, precedent use, native mappings, and extension needs. Required extensions force PARTIAL_MATCH, making gaps visible to reviewers.
Evaluation and quality gates
I separated rule validity, semantic fit, and business usefulness into three evaluation layers:
| Evaluation layer | What it checks |
|---|---|
| Python validator | Required fields, duplicates, allowed domains, forbidden targets, extension consistency; optional expected-count check. |
| AI reviewer | Business semantics, candidate reasoning, resource misuse, precedent suitability, and progress consistency. |
| Human BA review | Business usefulness of the full set of mapping results, after Excel handoff. |
The orchestrator advances only after validation and reviewer approval. These checks support a reviewable assessment; the Python script does not yet validate every resource name against the full R4 list or verify every target element path.
Results and business value
Across the project, I processed 2,000+ tables. BA review of the full set found over 95% of mappings effective, and the framework avoided the need to hire two FHIR engineers for this work. The effectiveness figure measures BA-assessed usefulness, not independently verified FHIR conformance.
The final Excel summaries below cover CPIN and DW. Their full/partial/no-match distributions describe fit to FHIR; the high share needing extensions shows why explicit gap reporting mattered.
| Table group | Full match | Partial match | No match | Tables need extensions |
|---|---|---|---|---|
| CPIN | 18.8% | 81.2% | 0.0% | 81.2% |
| DW | 12.7% | 86.7% | 0.6% | 87.3% |
“Tables need extensions” is a separate indicator, not an additional match category. Percentages are shown as reported in the Excel summaries.
What I learned
The central design choice was making generation, evidence, and evaluation separate responsibilities. Next steps are a formal BA acceptance rubric, complete R4 resource/path checks, and a measured single-prompt baseline to quantify error reduction and review effort.
Source and standard
See the implementation snapshot and HL7 FHIR R4 standard. Project-wide outcomes reflect my delivery experience and BA feedback beyond the public artifacts.