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 StructureDefinition Conformance and Sequence Evidence Auditor

Format
Code-aware
Lines
72
Sections
11
Linked challenge
Build a FHIR StructureDefinition Conformance and Sequence Evidence Auditor

Prompt source

Original prompt text with formatting preserved for inspection.

72 lines
11 sections
No variables
1 code block
## Build
Inspect research observation payloads against FHIR R5 StructureDefinition rules. Validate sequence annotation properties and generate conformance scorecards for multi-center registries.

## User
Health Informatics Specialist

## Workflow
1. Ingest FHIR JSON resources representing molecular and genomic observations.
2. Validate required element cardinality and terminology bindings against FHIR R5 specifications.
3. Detect missing data types, invalid code systems, or malformed narrative sections.
4. Produce an interoperability audit report with remediation instructions.

## Interface
Interactive browser portal presenting conformance issues with interactive schema diffs.

## Data
Create synthetic FHIR Observation and DiagnosticReport JSON documents containing both valid and intentionally invalid elements.
Starter examples below are synthetic. They are not downloaded records.

## Source
[HL7 FHIR overview](https://hl7.org/fhir/overview.html)
Adopts FHIR StructureDefinition rules governing element optionality, cardinality, datatypes, and narrative metadata.

## Tools
dspy, pydantic, fastapi.
DSPy compiles robust prompt programs to inspect ambiguous JSON conformance violations and generate structured fix instructions.
Local or hosted LLM with prompt evaluation support for strict validation rule synthesis.

## 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
- Flags missing mandatory FHIR metadata elements including status and code.
- Verifies compliance with StructureDefinition cardinality constraints.
- Emits machine-readable validation scorecards and suggested corrections.

## Starter Examples
```json
[
  {
    "input": {
      "resourceType": "Observation",
      "id": "obs-001",
      "status": "final",
      "code": {
        "coding": [
          {
            "system": "http://loinc.org",
            "code": "48018-6"
          }
        ]
      }
    },
    "expected_output": {
      "valid": true,
      "errors": [],
      "conformance_score": 1,
      "human_review_required": false
    }
  },
  {
    "input": {
      "resourceType": "Observation",
      "id": "obs-002",
      "code": {}
    },
    "expected_output": {
      "valid": false,
      "errors": [
        "Missing required field: status",
        "Coding array is empty in code attribute"
      ],
      "conformance_score": 0.33,
      "human_review_required": true
    }
  }
]
```

## Safety
Research informatics conformance verification tool without live clinical EHR connections.
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.