A clinical platform, FHIR all the way down.
ThrustCore is a FHIR R4-native clinical backend: 50+ resource types behind one API, SMART on FHIR authentication, and clinical terminology built in — a complete clinical information system, ready to run or to build on.
- FHIR R4 resource types
- 50+
- MCP tools
- 54
- Terminology
- EN · SK · ID
- Tenancy
- Multi-organization
Clause 1 — Architecture
One FHIR backbone, three surfaces.
Everything speaks FHIR. The staff portal, the patient app, and AI tooling consume the same R4 API — there is no second, private data model.
Surface · Patients
Patient mobile app for iOS & Android: appointments, records, care-team messaging.
Surface · Staff
Staff web portal with 25+ clinical and operational modules.
Surface · AI
AI assistants via the Model Context Protocol, 54 tools.
API
FHIR R4 API: SMART on FHIR authorization · real-time messaging · row-level tenant isolation.
Data
Multi-tenant PostgreSQL: clinical records · HR workforce · GS1 inventory · communication.
Fig. 1 — Every arrow is the same protocol.
Clause 2 — Conformance
Standards, taken literally.
Standards are how clinical systems stay honest. Everything below is implemented, not planned.
| Standard | Scope | Implementation |
|---|---|---|
| HL7 FHIR R4 | 50+ resource types | From Patient and Appointment to CarePlan and Consent. The exact list is declared by the server's CapabilityStatement, and the public API reference is generated from it. |
| SMART on FHIR | ES256 JWT | Token-based authorization with ES256-signed JWTs, organization context, and role-based access for staff and patients. |
| Clinical terminology | ICD-10 · ICD-9-CM · SNOMED CT | ICD-10 diagnoses, ICD-9-CM procedures, and SNOMED CT practice specialties, with English, Slovak, and Indonesian translations. |
| National frameworks | SATUSEHAT ready | Adapts to national interoperability programmes. Implemented today for Indonesia's SATUSEHAT: the Indonesian ICD-10 set and Kemenkes dual coding on clinical resources. |
| GS1 EPCIS 2.0 | Event-based inventory | Event-based inventory for medications and supplies: receiving, movement, and dispensing recorded as standard EPCIS events. |
| HR Open Standards | Workforce v4.3 | Staff scheduling, shifts, time and absence for clinical teams; person and timecard models mapped to the HR Open Standards v4.3 vocabulary. |
| Model Context Protocol | 54 tools | An MCP server exposes the platform to AI assistants: 54 tools for reading and writing clinical data under the same authorization as any other client. |
Clause 3 — Applications
What you can build on it.
A hospital management system
Patient administration, scheduling and queueing, clinical records, HR and inventory: the modules exist; compose them.
A clinic information system
Run it as delivered: staff portal and patient app for outpatient practices, multi-organization from day one.
A FHIR research platform
A standards-complete sandbox for health informatics research and teaching, with realistic synthetic data and a real CapabilityStatement.
SATUSEHAT integration
A compliant clinical core for Indonesian providers working with the national health data exchange.
AI clinical tooling
Assistants that query and act on clinical data through MCP instead of scraping a proprietary API.
Clause 4 — Properties
Built like infrastructure.
Modern stack
A serverless TypeScript API over PostgreSQL, with React web and React Native mobile clients.
Multi-tenant by design
Organization-level isolation enforced in the database with row-level security; one deployment serves many providers.
Security & consent
ES256-signed tokens, role-based privileges with audit logging, and GDPR-aligned consent management.
Real-time
Live appointment queues and patient–care-team messaging, pushed as they happen.
Document management
Medical documents stored and managed as FHIR resources, with in-app preview for PDFs, images, and office formats.
Multi-language
English, Slovak, and Indonesian across the apps and the terminology layer.
Clause 5 — Exhibit
The staff portal.
Clause 6 — Reference
Documentation that cannot drift.
The API reference at docs.thrustcore.eu is generated from the server's own CapabilityStatement. If the docs say a search parameter exists, the server declares it.