Building Software on a CDR: 5 Lessons Learned

The shift from managing a private database to building on an openEHR Clinical Data Repository (CDR) is an impactful architectural decision for a software supplier to make. It represents a move away from proprietary silos toward a ‘data-first’ ecosystem and a transition to a more flexible development cycle.

Cadasto was born out of years of experience using an openEHR CDR as a foundation for healthcare IT. With this background in mind, we would like to share five things we learned. With these lessons, other software companies can make a flying start with a platform like Cadasto as their foundation.

1. A Shift from Traditional Development Practices

In traditional development, engineers often design the database schema as they code the features. When you adopt a CDR, you must treat data and application as two separate, yet connected, entities. This requires a fundamental shift in both mindset and workflow. This shift comes with clear benefits, making your development cycle significantly more flexible and less prone to breaking when clinical requirements evolve.

2. Leverage Standardised Archetypes

Do not define your own clinical structures. There are plenty of archetypes available in the openEHR Clinical Knowledge Manager (CKM), free to use and peer-reviewed by professionals in the field. By using these pre-modeled archetypes for your applications, it becomes natively interoperable. As a software supplier, this also provides you with a strong Unique Selling Point: your system can speak the same language as other global health tools using the same archetypes.

3. Invest in Training

Building on an openEHR CDR is a philosophy, not just a library. Depending on your team’s experience, this may require some training. Provide dedicated time for your team to understand the why and how of openEHR and its Reference Model. This does not just go for your developers. Knowledge of why an openEHR CDR is used and how it works must be shared within the entire organisation. It needs to become a part of the story you tell. Those suppliers who view openEHR as a core competency will find that their development velocity increases once the team understands how it works and why it works as it does.

4. Is an openEHR CDR Right for You?

Is a CDR right for your specific product? If you are building a simple administrative tool, adopting a full clinical data platform may be unnecessary. However, if your software handles complex longitudinal records or multi-disciplinary care plans, a CDR is highly beneficial (and some might even say crucial for data availability requirements). Use the platform for what it is best at: managing the clinical data that requires long-term persistence.

5. Show the Market

From a strategic perspective, do not just sell your app’s features: sell the freedom of the data. Vendor lock-in is a very real and painful issue and software suppliers have a big role to play to facilitate longterm change. By building on a CDR, you offer data availability and reusability. You can guarantee your customers that their data remains structured and accessible even if they change software providers in the future. This builds a level of trust that proprietary competitors cannot match.

To Conclude…

Transitioning to a CDR foundation is a commitment to a future where data is permanent and reusable across systems and applications are agile. As a software supplier, you can transition from acting as a vendor that stores data to a true partner that enables future-proof, data-driven care.