# Building an open CIS — Article Series on Implementing a Minimal CIS with EHRBase

**Category:** [Apps](https://discourse.openehr.org/c/app-dev/8)
**Created:** 2026-01-15 16:20 UTC
**Views:** 107
**Replies:** 3
**URL:** https://discourse.openehr.org/t/building-an-open-cis-article-series-on-implementing-a-minimal-cis-with-ehrbase/11690

---

## Post #1 by @platzhersh

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](https://github.com/platzhersh/open-cis)

### The Series

1. **[Part 1: Introduction](https://medium.com/@platzh1rsch/building-open-cis-a-minimal-clinical-information-system-on-openehr-7d3c5d75bae8)** - Two-level modeling explained, the Lego analogy for archetypes/templates, and project motivation.

2. **[Part 2: The Clinical Modeling Stack](https://medium.com/@platzh1rsch/building-open-cis-part-2-the-clinical-modeling-stack-221c019e65ca?sk=1d3216e585487a0ae623645edec7bbc6)** - ADL, BMM, OPT walkthrough, and understanding archetype node IDs.

3. **[Part 2b: FLAT Format Deep Dive](https://medium.com/@platzh1rsch/building-open-cis-part-2b-template-formats-and-the-flat-format-deep-dive-0ed3ff0acfed?sk=fd29cdd22e79dee8818b84fc94ea7429)** - 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.

4. **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).

5. **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

---

## Post #2 by @ian.mcnicoll

I have only had a quick look but I think you have done a great job.  For a next step I woukd include  a fhir terminology server and hook it up to the cdr.  Terminology handling is pretty well minimal for any clinical system.

---

## Post #3 by @platzhersh

Thank you @ian.mcnicoll ! I will dive into this on another rainy weekend probably :smiley:  (or when it becomes more current at work)

---

## Post #4 by @platzhersh

Just wanted to give a small update, I’ve released version 0.1.0 of my python sdk, called oehrpy. It is available on pypi now: https://pypi.org/project/oehrpy/

Here’s the medium article about it: https://medium.com/@platzh1rsch/building-open-cis-part-5-oehrpy-a-python-sdk-for-openehr-c9c90f46d075?sk=0ff94b61db0437d8e24dfa75895d2f55

Feedback welcome.

@ian.mcnicoll the FHIR Terminology topic is up next for me to take a look into.

---


**Canonical:** https://discourse.openehr.org/t/building-an-open-cis-article-series-on-implementing-a-minimal-cis-with-ehrbase/11690
**Original content:** https://discourse.openehr.org/t/building-an-open-cis-article-series-on-implementing-a-minimal-cis-with-ehrbase/11690