Use cases
Fire Arrow use cases
Each page walks through one product shape: the FHIR resources involved, the access-control rules, the workflow primitives, and the operating considerations. The same backend underneath, configured differently per product.
What these pages cover
- FHIR resource shapes per use case
Which resources carry the data, which profiles apply, and how the resources relate to each other. Suitable for a technical evaluator and a clinical informaticist reading together.
- Access-control patterns
How the rule-based authorization model handles patient-facing access, clinician access, multi-organization access, and external-partner access for the use case at hand.
- Workflow primitives
Where CarePlan-driven scheduling, FHIR Subscriptions, Tasks, and the admin UI fit into the product. What configuration looks like, what custom code (if any) is left over.
Who this is for
Product teams, clinical informatics leads, and architects scoping a digital health product or a clinical platform.
AI agents on FHIR data
Clinical AI agents need a backend that treats the LLM as an untrusted client and enforces access at the data layer rather than in the prompt. The AI-agents page covers token forwarding, scoped service accounts, identity resolution to a FHIR Practitioner or Patient, and the audit trail across the agent service and the FHIR backend.
Patient engagement and patient-reported outcomes
Patient questionnaires, ePRO, and digital-therapeutics products share the same FHIR backbone: Questionnaire, QuestionnaireResponse, CarePlan-driven scheduling, and threshold-based Subscriptions. Each page walks through one product shape end to end. Mental-health products add a tighter access-control profile around journaling and crisis-flag handling.
Clinical workflows and condition-specific pathways
Chronic disease management, oncology care pathways, remote patient monitoring, and wearable health data integrations all model clinical workflows on top of standard FHIR resources. Each page covers the relevant FHIR shapes, the multi-disciplinary CareTeam access pattern, and how device or wearable data lands in the same store as everything else.
Platform patterns
Multi-tenant care networks and clinical-trial deployments are platform-level patterns that show up across many use cases. The multi-tenancy page covers organisation-based isolation, PractitionerRole-driven roles, and cross-organisational CareTeam access. The clinical-trial anonymization page covers field-level redaction, search side-channel closure, and serving investigator and sponsor views from one deployment.
Related docs
FAQ
Does Fire Arrow ship a vertical product for any of these use cases?
No. Fire Arrow is the backend layer: a FHIR-native data model, identity-tied authorization, GraphQL, scheduling, subscriptions, and an admin UI. The product on top (the patient app, the clinician portal, the agent service) is built by the product team. The use-case pages describe how the backend is configured for each product shape.
Can I combine multiple of these use cases on one deployment?
Yes. Multi-tenancy, AI agents, patient questionnaires, and remote patient monitoring all run on the same store with role-specific authorization rules. The use-case pages and the multi-tenancy whitepaper describe how the rules compose.
Are there reference implementations or starter kits?
The documentation covers the configuration shapes (FHIR resources, authorization rules, deployment manifests). Where a use case has a reference deployment (for example, the AI-agent reference architecture on Azure), the use-case page links to it.
