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 Molecular Profile Verifier
Format
Code-aware
Lines
76
Sections
11
Linked challenge
Build a FHIR StructureDefinition Molecular Profile Verifier
Prompt source
Original prompt text with formatting preserved for inspection.
76 lines
11 sections
No variables
1 code block
## Build
Validate custom genomics research observation instances against FHIR StructureDefinition rules. Detect schema deviations, cardinality errors, and missing mandatory molecular codes.
## User
Clinical Interoperability Engineer
## Workflow
1. Ingest FHIR R5 StructureDefinition profiles specifying required molecular observation attributes.
2. Parse incoming research observation JSON objects to check datatype conformity and cardinality.
3. Inspect terminology bindings to verify standard code systems for gene symbols and sequence types.
4. Generate conformance reports highlighting valid elements and actionable validation errors.
## Interface
Developer terminal CLI and web-based diff viewer comparing observed resources against StructureDefinition.
## Data
Use official HL7 FHIR R5 core StructureDefinition JSON schemas downloaded from the published standard.
Starter examples below are synthetic. They are not downloaded records.
## Source
[HL7 FHIR overview](https://hl7.org/fhir/overview.html)
Directly implements StructureDefinition constraints, cardinality checks, and terminology bindings from FHIR specification Section 2.1.15.3.1.
## Tools
pydantic-ai, fastapi, pytest.
Provides deterministic type validation and model enforcement matching FHIR StructureDefinition constraints.
Local open LLM or standard hosted API used only for generating human-readable remediations.
## 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
- Validates JSON payloads against FHIR R5 Observation StructureDefinition cardinality rules.
- Flags missing mandatory fields such as 'status', 'code', and 'resourceType'.
- Produces a structured conformance score with explicit JSON-pointer error locations.
## Starter Examples
```json
[
{
"input": {
"resourceType": "Observation",
"status": "final",
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "48018-6",
"display": "Gene studied [Identifier]"
}
]
},
"valueString": "BRCA1"
},
"expected_output": {
"conforms": true,
"schema": "FHIR-R5-Observation",
"missing_elements": [],
"cardinality_violations": [],
"conformance_score": 1
}
},
{
"input": {
"resourceType": "Observation",
"valueString": "BRCA1"
},
"expected_output": {
"conforms": false,
"schema": "FHIR-R5-Observation",
"missing_elements": [
"status",
"code"
],
"cardinality_violations": [
"Observation.status: minimum cardinality 1, found 0"
],
"conformance_score": 0.33
}
}
]
```
## Safety
Technical schema validation of synthetic research payloads; strictly excludes clinical health records.
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.