fhir-data-model-design
Maps clinical data types to specific FHIR R4 resources, terminology bindings, and relationships. Unlike most other skills, this one is expert-driven — it provides recommendations rather than asking Socratic questions.
What It Produces
For each FHIR resource used:
- Profile (base FHIR or specific IG profile URL)
- Clinical use description
- Key fields with types and value set bindings
- Terminology bindings (LOINC, SNOMED CT, RxNorm, ICD-10-CM)
- Sample FHIR JSON with realistic values
Plus:
- Terminology bindings table
- Resource relationships
- FHIR REST API patterns (read, search, write, transaction bundles)
- Data flow descriptions
- Implementation notes and known gaps
Output
Produces docs/planning/fhir-data-model.md.
Example
AI: What clinical data does your app track? List every type —
vitals, labs, questionnaires, medications, conditions.
You: Blood pressure, heart rate, daily step count, and a
weekly PHQ-9 depression screening.
AI: Based on that, here's the FHIR resource mapping:
Blood pressure → Observation (US Core Blood Pressure profile)
LOINC: 85354-9, components: systolic 8480-6, diastolic 8462-4
Heart rate → Observation (US Core Heart Rate profile)
LOINC: 8867-4
Step count → Observation
LOINC: 55423-8
PHQ-9 → QuestionnaireResponse + Observation (score)
Questionnaire canonical: http://loinc.org/q/44249-1
Score LOINC: 44261-6
Sample FHIR JSON for a blood pressure reading:
{
"resourceType": "Observation",
"status": "final",
"category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
"code": {"coding": [{"system": "http://loinc.org", "code": "85354-9"}]},
"component": [
{"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 120, "unit": "mmHg"}},
{"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 80, "unit": "mmHg"}}
]
}
Limitations
- Assumes FHIR R4; older versions not addressed
- Does not resolve individual terminology codes (provides system URIs; you look up specific codes)
- Does not provide clinical validation of terminology — flags where clinical review is needed
- Does not address storage layer details (database choice, indexing)
- Does not implement backend API code — provides the specification