Skip to main content
Back to Prompt Library
implementation

Build the application

Inspect the original prompt language first, then copy or adapt it once you know how it fits your workflow.

Linked challenge: Build a FHIR Care-Team On-Call Task Routing Engine

Format
Code-aware
Lines
89
Sections
11
Linked challenge
Build a FHIR Care-Team On-Call Task Routing Engine

Prompt source

Original prompt text with formatting preserved for inspection.

89 lines
11 sections
No variables
1 code block
## Build
Route urgent research protocol tasks to on-duty study coordinators using FHIR R5 Task and CareTeam structures. Audit assignment latencies and log message transfers across institutional shifts.

## User
Clinical Trials Operations Specialist

## Workflow
1. Ingest protocol milestone alerts formatted as FHIR R5 Task objects.
2. Retrieve current on-call personnel shifts from a CareTeam schedule registry.
3. Apply availability, role qualifications, and shift boundaries to route task ownership.
4. Generate updated FHIR Task resources with assigned performers and delivery confirmation timestamps.

## Interface
Task assignment dashboard with live shift timelines, open protocol tickets, and re-routing triggers.

## Data
Synthesize FHIR R5 CareTeam, Practitioner, and Task resources following HL7 FHIR Foundation specifications.
Starter examples below are synthetic. They are not downloaded records.

## Source
[HL7 FHIR overview](https://hl7.org/fhir/overview.html)
Reference FHIR R5 Foundation CareTeam participant types and Task status codes to maintain standard conformance.

## Tools
semantic-kernel, pydantic, fastapi.
semantic-kernel orchestrates deterministic skills for shift schedule parsing and task assignment execution.
Hosted or local model connector supported by Semantic Kernel to synthesize handover notes.

## Deliverables
Submit runnable source, pinned dependencies, setup commands, a working interface, example outputs, and a recorded end-to-end demo. Include tests and an action log.

## Acceptance
- Consumes valid FHIR Task objects and parses current status and priority codes.
- Matches task domain to eligible active practitioners within the active shift schedule.
- Produces updated Task payload containing valid reference to assigned Practitioner.
- Maintains an immutable routing decision log for operational compliance audits.

## Starter Examples
```json
[
  {
    "input": {
      "task_id": "TASK-BIO-01",
      "priority": "urgent",
      "focus": "SpecimenCollectionReview",
      "care_team": {
        "id": "TEAM-ONC",
        "members": [
          {
            "practitioner_id": "PRAC-A",
            "role": "coordinator",
            "status": "on_shift"
          },
          {
            "practitioner_id": "PRAC-B",
            "role": "coordinator",
            "status": "off_shift"
          }
        ]
      }
    },
    "expected_output": {
      "task_id": "TASK-BIO-01",
      "status": "assigned",
      "assigned_to": "PRAC-A",
      "escalated": false,
      "routing_reason": "practitioner_active_on_shift"
    }
  },
  {
    "input": {
      "task_id": "TASK-BIO-02",
      "priority": "stat",
      "focus": "AdverseEventAudit",
      "care_team": {
        "id": "TEAM-ONC",
        "members": [
          {
            "practitioner_id": "PRAC-B",
            "role": "coordinator",
            "status": "off_shift"
          }
        ]
      }
    },
    "expected_output": {
      "task_id": "TASK-BIO-02",
      "status": "held",
      "assigned_to": null,
      "escalated": true,
      "routing_reason": "no_active_member_on_shift"
    }
  }
]
```

## Safety
Research administration operational simulator; operates on synthetic practitioner data; no emergency medical triage.
Use mock external writes. Require human review before any real deployment.

Adaptation plan

Keep the source stable, then change the prompt in a predictable order so the next run is easier to evaluate.

Keep stable

Hold the task contract and output shape stable so generated implementations remain comparable.

Tune next

Update libraries, interfaces, and environment assumptions to match the stack you actually run.

Verify after

Test failure handling, edge cases, and any code paths that depend on hidden context or secrets.