Menu
Plan health data concepts, entities, relationships, interoperability needs, and governance choices for digital health products.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Turn planning outputs into a milestone-based implementation plan that sequences features, maps them to available packages or modules, and hands off to a coding agent for implementation.
Walk through the full process of building a digital health app — from planning to implementation.
Choose between React Native and Apple-native for a digital health app, clone the matching Spezi starter template, and move existing planning briefs into the cloned repo so the coding agent has full context for implementation.
Set up and maintain a persistent, LLM-managed knowledge base for a digital health project — turning clinical observations, papers, interviews, and planning docs into a compounding, interlinked wiki.
Guide a user through Stanford Biodesign's needs-finding process to define, scope, and refine a rigorous health-app need statement without jumping prematurely to solutions.
Plan healthcare privacy, research, and regulatory compliance for a digital health product, including HIPAA, IRB, FDA, GDPR, governance, and operational controls.
| name | health-data-model-planning |
| description | Plan health data concepts, entities, relationships, interoperability needs, and governance choices for digital health products. |
Plan a health data model with a strong bias toward FHIR before committing to storage, code structures, or client-specific architecture.
Use this skill when you need to:
Start with the domain, but assume that clinically meaningful data will often benefit from a FHIR-oriented design unless there is a strong reason not to.
Clarify:
In digital health, prefer asking "How would this map to FHIR?" early rather than treating interoperability as a late-stage add-on.
Default questions:
It is fine to decide that some concepts remain app-internal, but make that an explicit choice.
Do not encourage teams to hand-roll FHIR models, parsers, or mapping infrastructure unless there is a compelling gap.
When implementation starts, generally recommend reusing mature ecosystem libraries, for example:
@stanfordspezi/spezi-firebase-fhirIf the user is already working in a concrete stack, recommend modeling choices that fit those existing libraries instead of inventing parallel abstractions.
Identify the main concepts, such as:
For each entity, define:
Map how the entities relate, for example:
Note:
For important entities, define lifecycle states such as:
Also define:
Use FHIR as the default lens for clinically relevant data, and only move away from it when the extra complexity is not justified.
Assess:
When possible, push the user toward:
Review:
Produce a concise data model planning brief with:
Save the brief as docs/planning/data-model-brief.md in the project repository.