Design a FHIR data model

Install this skill

npx skills add StanfordSpezi/SpeziVibe --skill fhir-data-model-design

Or install all skills: npx skills add StanfordSpezi/SpeziVibe --skill '*'. See the Getting Started guide for tool-specific options.

Explore this skill in browser chat. Each button opens a new conversation; bring any earlier briefs with you and save the results yourself.

Try in ClaudeTry in ChatGPT

Need to paste the prompt yourself?

Browser prompt for fhir-data-model-design

Please act as the SpeziVibe `fhir-data-model-design` skill and walk me through it interactively.

STEP 1 — Fetch the skill instructions from this URL and read them carefully:
https://raw.githubusercontent.com/StanfordSpezi/SpeziVibe/main/skills/fhir-data-model-design/SKILL.md

If the skill references other files or other skills by name, fetch them from the same repository:
- Files inside this skill (e.g. `references/foo.md`): https://raw.githubusercontent.com/StanfordSpezi/SpeziVibe/main/skills/fhir-data-model-design/<relative-path>
- Other skills (e.g. `biodesign-needs-finding`): https://raw.githubusercontent.com/StanfordSpezi/SpeziVibe/main/skills/<skill-name>/SKILL.md

STEP 3 — Walk me through the skill interactively. When a step would normally save a markdown file to a project, show the file content in a code block instead so I can copy it. Don't simulate my answers — wait for me to respond.

If you cannot fetch the skill instructions or their reference files, ask me to paste them before proceeding.
Ask me to paste or attach any existing briefs you need. Do not claim to have read files, run commands, created a project, or tested an integration from this chat. Help me prepare the decisions and instructions, then hand off file and code work to my coding tool.

If your chat can’t open the skill link, open the instructions in a new tab and paste them into the chat.

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