# Join or comment CDR Catalyst initiative from Karolinska
**URL:** https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859
**Category:** General Discussion
**Tags:** integration, interoperability, cdr, ai
**Created:** [21 May 2026 09:14 UTC](https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859 "2026-05-21T09:14:33Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [21 May 2026 09:14 UTC](https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859/1 "2026-05-21T09:14:33Z")
Dear community,
we need to speed up how new and old kinds of data enter Karolinska’s and Region Stockholm’s joint openEHR CDR and associated FHIR- server and other parts of our data platform and also result in implemented clinical applications.
We want to be as open and collaborative as possible. Our focus is to together with the rest of the world fight disease and unnecessarily early deaths, rather than competing in [care](https://rankings.newsweek.com/worlds-best-hospitals-2026) or [smartness](https://rankings.newsweek.com/worlds-best-smart-hospitals-2026) through secrecy. We believe there are other organizations with similar thoughts (that may be on our radar or not). Thus we are openly reaching out for collaboration regarding tooling and AI-context/harness by publishing a draft describing our “CDR Catalyst” initiative for comment and discussion here.
It is also a form of information to the market since we might solve the resouce need for this as a combination of current staff, new permanent+temporary employments and procured services.
Here is a link to the public Google Docs “living” document that is open to comment for anybody:
> **[Market\_info\_\_CDR\_Catalyst\_\_Region\_Stockholm.docx](https://docs.google.com/document/d/1PInC38hj47q4zZX7aavGVM6s8sNDU1z3/edit?usp=sharing&ouid=112660550613841635682&rtpof=true&sd=true)**
>
> CDR Catalyst \[Request for comments and collaboration – continuously updated online version\] At Karolinska University Hospital we want to be as open and collaborative as possible. Our focus is to together with the rest of the world fight disease and...
P.S.
In case you can’t or don’t want to access the Google Docs version [here is also a frozen copy of version 0.4 as a word (docx) file](https://discourse.openehr.org/uploads/short-url/4viP44cDNgICuzQqQwqJddOIdIh.docx) (6.4 MB), do note that the file may be outdated compared to the living google document linked further up.
---
### Author:  [@martin.grundberg](https://discourse.openehr.org/u/martin.grundberg)
#### Post date: [25 May 2026 06:20 UTC](https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859/2 "2026-05-25T06:20:55Z")
Great initiative Erik!
To what degree have you been able to extract data from your existing EHR and load it into the CDR? What types of data, what archetypes (or templates), any insights so far?
---
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [25 May 2026 08:05 UTC](https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859/3 "2026-05-25T08:05:22Z")
Hi @martin.grundberg! The principles and some experiences from current EHR (TakeCare) conversion are outlined farily well in the presentations linked from [GitHub - regionstockholm/poc\_tc2openEHR · GitHub](https://github.com/regionstockholm/poc_tc2openEHR) (as mentioned in the CDR catalyst document) and also briefly in the [poster abstract A13 from EHRCON2025](https://link.springer.com/article/10.1186/s12919-026-00367-3#Sec51)
After the PoC we continued with what was describeed as “Phase 2” in the [EHRCON2025 presentation](https://github.com/regionstockholm/poc_tc2openEHR/blob/main/EHRCON2025-10-17-Store-legacy-EHR-content-openEHR-Sundvall%2BMcNicoll.pdf) and have there covered more kinds of data. However we will pause the TakeCare part for a while now and the same people will instead focus on another legacy system called “Obstetrix” (maternity & birth focused EMR) due to external factors making that more urgent.
---
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [25 June 2026 08:38 UTC](https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859/4 "2026-06-25T08:38:32Z")
We are soon going to publish a job ad for several of the roles needed in the CDR catalyst initiative, see attached draft. Please comment here before 10:00 CET tomorrow morning (Friday). Or send mail jointly to my boss jens.eriksberger@regionstockholm.se and me erik.sundvall@regionstockholm.se
[CDR catalyst job ad.docx](https://discourse.openehr.org/uploads/short-url/8OFogJIW5Sa3iJfZyTKnCgGpcP8.docx) (27.5 KB)
What have we forgotten? What should be better explained/specified? Are any requirements or meritous requests too tight or not tight enough?
---
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [21 August 2026 14:51 UTC](https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859/5 "2026-08-21T14:51:29Z")
And here we go, swedish vacations are over and the real ad has now gone live. Please apply if you would find this interesting and actually fit the requirements: [Experienced healthcare IT experts, doers and leaders](https://regionstockholm.varbi.com/en/what:job/jobID:948838/)
I know EU/EES-citizens (or persons of other nationalites with a Swedish work permit) can apply, will check rules regarding others.
---
### Author:  [@rubentalstra](https://discourse.openehr.org/u/rubentalstra)
#### Post date: [30 August 2026 11:43 UTC](https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859/6 "2026-08-30T11:43:46Z")
Hi @erik.sundvall,
Question from my side: is building on an existing open-source CDR an option for Catalyst, or is starting from scratch part of the point?
I’m asking because I built [FerroEHR](https://github.com/rubentalstra/FerroEHR) over the past months. It started as a deep dive into EHRbase to understand how a CDR works from the inside, and turned into a full implementation of its own ([the announcement thread](https://discourse.openehr.org/t/ferroehr-a-new-rust-based-openehr-cdr-looking-for-testers/17230) has the details). Short version: Rust, ITS-REST 1.1.0 with canonical JSON and XML, AQL 1.1, PostgreSQL 18, one static binary, no JVM. The RM/BASE/AM types and codecs are generated straight from the published machine-readable specs, ADL 2.4 and OPT 1.4 both work, and there’s an admin console that talks to the server strictly over the public REST API.
It’s **MIT licensed** , on purpose. So if Catalyst wants a codebase to start from instead of a blank repo, you can take it, fork it, or embed it without needing anything from me. I’d rather build together than watch a fork drift, but that’s your call to make, not mine.
The numbers aren’t mine to assert either. I also built [Veredictum](https://github.com/rubentalstra/Veredictum), an independent conformance instrument (1,143 spec-cited cases), and FerroEHR’s results are on the public board: 1,004 of 1,142 driven cases pass. The single failure is an AQL bug I filed against my own product ([FerroEHR#2940](https://github.com/rubentalstra/FerroEHR/issues/2940)). The run is reproduced by an attested GitHub workflow: [Conformance board — Veredictum](https://veredictum.eu/conformance-board.html)
Happy to talk.
---
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [2 September 2026 06:14 UTC](https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859/7 "2026-09-02T06:14:28Z")
Hi @rubentalstra ! Very nice to see your performant CDR effort and openEHR specification scrutiny!
Karolinska will likely keep using several CDRs for different purposes and product mix will likely change over time. Right now we have Better’s CDR provided via Tieto as main CDR for entering data. Previously we used a solution from Cambio (and might get one again bundled with a Cambio Cosmic / Cambio Open Platform package). We have also used Ehrbase for some purposes.
For some parts of the CDR Catalyst goals we’d likely want some multimodel database (likely a copy of the current production CDR database content) that efficiently can handle
- big terminologies (like SNOMED CT and big biomedical ontlogies)
- and CDR content (health records etc)
- and embeddings for AI
- and freetext search
- and graph based queries
…in the same process/memory space so that we don’t need to serialise and toss big structures between different environments. I know @borut.jures saw that and created [https://arcehr.com/](https://arcehr.com/) and I belive something along those lines is highly interesting for several of our use cases. We’ll try to be as open as possible with needs and use cases to help the market mature. I’ll respond more in [Performance of an openEHR CDR based on a graph database](https://discourse.openehr.org/t/performance-of-an-openehr-cdr-based-on-a-graph-database/17224) to keep this thread cleaner.
---
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [2 September 2026 17:30 UTC](https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859/8 "2026-09-02T17:30:24Z")
At Karolinska University hospital we are extremely happy to welcome @thomas.beale as a partner in our team to help with CDR Catalyst (described above) and other of our challenges! We’d like to remind everybody that you also can join this team since we have an ad open for more international top talent as mentioned above: [Experienced healthcare IT experts, doers and leaders](https://regionstockholm.varbi.com/en/what:job/jobID:948838/)
Or if you are already happy working at another place and interested in open solutions you can of course join the effort via collaboration and joint work on shared challenges.
P.s. This recruitment, now via consultancy framework agreement call-off, has been in the works for a quite a while and is related partly to happenings after the post /ad [Interoperability Lead Developer & Integration Architect at Karolinska University Hospital, Sweden](https://discourse.openehr.org/t/interoperability-lead-developer-integration-architect-at-karolinska-university-hospital-sweden/11653) approach that we then had to tweak some due to the complexity of international (non EU) recruitment. Public healthcare can be flexible but it takes some time to sort out legal ways…
---
### Author:  [@Ricky\_Sun](https://discourse.openehr.org/u/Ricky_Sun)
#### Post date: [19 September 2026 00:36 UTC](https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859/9 "2026-09-19T00:36:39Z")
Thanks, Erik, for publishing this so openly and in such concrete detail.
Disclosure first: I work at Ultipa, where we build a real-time graph database whose native query language is ISO GQL (ISO/IEC 39075). Please read what follows with that in mind. These aren’t a product pitch. Three parts of the document overlap closely with problems we’ve worked on, so here are some notes.
1. AGQL: build on GQL rather than beside it
I’d suggest keeping AGQL a strict superset of ISO GQL: archetype-aware syntactic sugar that desugars to plain GQL.
- AQL CONTAINS maps naturally onto GQL path patterns.
- Archetype and template IDs map onto label expressions or node predicates.
- A stored query is translated once, when it’s saved, which matches your point that stored queries are the ones that count in production.
- Any conformant GQL engine could run them, with no AGQL-specific runtime to maintain.
A shared, openly licensed mapping of the RM onto a property graph, plus an AQL→GQL test suite (AQL in, expected results out) on the same Vital Signs data Borut uses, would let every engine be compared on identical queries. Is anyone already working on that?
1. One planner for terminology and records, able to run from either side
We agree with your point that the best plan “can’t be determined without looking at both knowledge graph and EHR simultaneously”. Take \<\< 73211009 |Diabetes mellitus| in problem lists:
- For a small cohort, the cheapest plan walks up the IS-A hierarchy from each patient’s recorded codes.
- For a population query, expanding the descendant set first wins.
- An engine can only choose between these when both sides share one planner with statistics on both. Split across two systems, the choice is frozen in application code, usually as “ship the whole descendant list”.
A related point: evaluating subsumption at query time, rather than from materialized closure tables, makes your remark literally true that non-breaking terminology updates can enrich the graph “without the already recorded data instances changing”. A new SNOMED release changes answers without rewriting patient data. The trade-off is that query-time inference costs something on every query, while materialization costs on every release, so most systems end up mixing the two.
1. Scope patients inside the traversal and the vector search
For GraphRAG, the patient/cohort restriction has to be a pre-filter inside both the graph traversal and the vector search, not a post-filter on results. Post-filtering either leaks data or quietly returns too little.
One case worth adding to evaluation criteria: approximate vector indexes (e.g. HNSW) under a very selective filter, such as one patient’s notes among millions. Unless the engine falls back to exact search over the allowed set, they can return fewer than k results without any error.
Happy to go deeper on any of these, here or in the performance thread.
Ricky @ Ultipa
---
### Author:  [@John1](https://discourse.openehr.org/u/John1)
#### Post date: [1 October 2026 15:11 UTC](https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859/10 "2026-10-01T15:11:10Z")
Thank you Erik for sharing this so openly. As a physician who builds AI systems, I think the “complacency bias” risk in Stage 2a also applies at design time, in the AI-assisted mapping tools of Stage 0.
One simple idea: show evidence with each AI-suggested mapping (sample source values, target path, SNOMED CT concept), and sometimes add known-wrong test mappings to the review queue. Then you can measure if reviewers are still really checking.
Question: for the Obstetrix pilot, will midwives who used the system help review the mappings? They often know how fields were really used, which can differ from the documentation.
---
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [1 October 2026 15:32 UTC](https://discourse.openehr.org/t/join-or-comment-cdr-catalyst-initiative-from-karolinska/16859/11 "2026-10-01T15:32:46Z")
Thanks @John1. I agree that it is easy to just accept an AI suggestion also while mapping/designing. One way that has been suggested (and tested by others) is to have another agent based on other AI-model than the mapper review so that we get an additional AI-check in addition to the human(s).
Yes we usually have clinicians (including midiwifes in this case) review at least conversion samples in the finished system before going live. When possible we often try to roll out in small scale with a few users first. Several of our informaticians also have clinical background.
P.s. do you have any reference to the systems you build and perhaps a full name? We have quite a lot of spambots registering accounts, and yours was registered some minutes ago. This would help forum maintainers filter a bit.