Hi there,
I’ve been documenting my experience building a minimal Clinical Information System on EHRBase, and wanted to share the resulting article series with the community.
Repository: github.com/platzhersh/open-cis
The Series
-
Part 1: Introduction - Two-level modeling explained, the Lego analogy for archetypes/templates, and project motivation.
-
Part 2: The Clinical Modeling Stack - ADL, BMM, OPT walkthrough, and understanding archetype node IDs.
-
Part 2b: FLAT Format Deep Dive - Practical differences between EHRBase and Better Platform: Content-Type headers, template ID handling in paths, validation behavior, and datatype syntax variations. This one documented several gotchas I wish I’d known earlier.
-
Part 3: Going SDK-less (coming soon) - Direct REST integration with EHRBase using Python/FastAPI. What’s straightforward (EHR creation, AQL queries) vs. what’s painful (composition building without type safety).
-
Part 4: The SDK Landscape (coming soon) - Survey of Java (Archie, EHRBase SDK, CaboLabs), JavaScript/TypeScript options, and the Python gap.
Stack
Vue 3 + TypeScript + shadcn-vue
↓ REST
FastAPI + Python + Pydantic
↓ ↓
PostgreSQL EHRBase
(app data) (clinical data)
Separate databases for application state vs. clinical data - mirroring how production deployments often work.
Looking for Feedback
Particularly on the FLAT format findings (Part 2b) - did I miss nuances? And for those working on Python tooling: what would make a Python SDK actually useful for your workflows?
Happy to answer questions or discuss implementation details.
Cheers
Chris