Introducing Better Platform CDR 5.0, ODR 5.0, and new MCP Server 0.9 preview 

As your clinical and operational data grows, so does your need to search it efficiently, run it at scale and use it safely with AI. This release tackles all three with smarter search, stronger multi-tenant operations and governed AI access. MCP Server 0.9 preview lets you ask questions of your own records in plain language using the AI model your organisation has approved, with every answer limited to what the signed-in user is allowed to see.

EHR Server is now called the Clinical Data Repository (CDR), which stores longitudinal clinical data in openEHR, and Demographics Server is now the Operational Data Repository (ODR), which stores demographic, operational and terminology data in FHIR. Together they form the data backbone of Better Platform. CDR 5.0 and ODR 5.0 strengthen these core layers, and MCP Server opens them to approved AI models and agents through the Model Context Protocol.

CDR 5.0: stronger foundations 

Standards come first in CDR 5.0. When openEHR published ITS-REST 1.1.0 in July 2026, the first release of the REST specification since 2022, we committed to supporting it in our next major release. CDR 5.0 delivers on that commitment. Item tags, the new Admin API and the simplified data formats follow the standard, so applications built to the specification work with CDR 5.0 without custom integration. 

CDR 5.0 also brings: 

• A new Admin Console, rebuilt with a modern look, faster navigation and a clearer view of system state. 

• Java 25 and Spring Boot 4. A modern, supported stack for security and reliability. 

• See the full list of changes in the CDR 5.0 release notes. 

CDR 5.0: semantic and hybrid search 

CDR 5.0 introduces hybrid search, which combines keyword matching with AI-powered semantic search. A query finds records that contain its terms, and also records that say the same thing in other words: synonyms, abbreviations, drug names and the free text clinicians actually write. 

For example, a semantic search for something like “high blood pressure” could return data that mentions hypertension, raised BP or amlodipine. Or, another example, a search for “metallic taste” could surface notes such as “reports dysgeusia since starting treatment” or “complains everything tastes of coins”. 

Under the hood, the CDR combines lexical (BM25) matching with neural vector search. An AI model turns clinical data into embeddings (numerical representations of meaning) and stores them in a vector index. Each query is embedded the same way, and the CDR returns the records closest to it alongside those that match its words. You choose hybrid mode per query, through the new composition_fulltext predicate in AQL. 

The new full-text predicates search the whole content of a clinical record, including numeric and boolean values. They also match terms in the other languages defined in the record’s template, which matters for multilingual health systems. 

Semantic search complements AQL. For numeric criteria, such as systolic readings above a threshold, AQL remains the precise tool. Semantic search covers the language around those numbers. 

You bring the AI model. Semantic search is designed for bring-your-own-model, so you decide which model creates the embeddings and where it runs. 

Read more in the CDR 5.0 release notes. 

ODR 5.0: multi-tenant and standards-first 

ODR 5.0 brings full multi-tenancy, FHIR R5 merge semantics and a modern stack. The rename changes the jar and container image only: role names and FHIR canonical URLs stay the same. 

• Multi-tenancy throughout. Every resource is explicitly partitioned, now including terminology resources, StructureDefinitions (profiles) and SearchParameters, so each tenant can have its own. Tenants are created and managed at runtime with $partition-management, and one tenant can be reindexed without affecting the others. 

• External indexer. A standalone process handles full or large-scale OpenSearch rebuilds, for smoother upgrades and disaster recovery in large installations. 

• Patient $merge follows FHIR R5. Preview a merge before running it, validate source versions, run it asynchronously, and record Provenance for every merge. 

• Type-level history search. _history requests support full search parameters, the _since, _before and _at filters, and ABAC enforcement. 

• Java 25 and Spring Boot 4. A modern, supported stack for security and reliability. 

• See the full list of changes in the ODR 5.0 release notes. 

MCP Server 0.9 preview: AI that answers from your records 

MCP Server 0.9 is a new Better Platform component, available in preview. One server opens CDR, ODR and terminology to any MCP-compatible client through the Model Context Protocol (MCP), an emerging open standard that lets AI systems securely access, query and use external data through well-defined interfaces. The same tools also power the in-app chat. 

What is included

In total, this preview ships 53 tools across:

How it works 

A user asks a question in an MCP client or the in-app chat. The LLM breaks it down and calls MCP tools. Every call runs with the user’s own sign-in and passes ABAC authorisation and validation before it touches data. The results go back to the LLM, which composes the answer. 

The server is safe by design: 

• Grounded answers. Answers come from AQL and REST calls against your data. 

• Provenance. Every AI output traces back to the records it came from. 

• Your access policies apply. The AI sees only what the signed-in user is authorised to see under ABAC. 

• Reads run, writes wait. Writes to records or definitions are held for confirmation, with a dry-run preview first. 

• Checked before saving. AQL and compositions can be validated against archetypes and templates before anything runs or is saved. 

• Writes are verified. Composition writes are read back and compared with what was sent. 

• Bring your own LLM. Use the model your organisation has approved. 

Example 

A clinician asks: “Which of my patients still have high blood pressure despite treatment?” The model might split this into three questions and pick a tool for each. 

1. Whose readings are still too high? execute_aql finds the latest blood pressure per patient and filters on the numbers. 

2. Who is already on medication? execute_aql again, this time on active prescriptions. 

3. What do the notes say about their medication? execute_aql a third time, now with Better’s semantic full-text search (composition_fulltext in hybrid mode). It searches the free-text notes for these patients and finds phrases such as “missed doses”, “stopped because of side effects” and “cannot afford the prescription”. A structured query can’t see these, because they exist only as free text. 

The answer comes back as a list: patient, latest reading, current medication and any relevant notes. 

Read more in the MCP Server documentation. 

What’s next 

This release advances two threads of our roadmap: Foundations, strengthening standards-based, scalable data operations, and Frontiers, bringing governed, bring-your-own-model AI closer to the data layer. In the releases ahead, we will keep strengthening the platform around open standards while expanding how AI can work safely with healthcare data.

Want to explore MCP Server 0.9 preview, semantic search or what these updates could mean for your organisation? Book a meeting with our team.