Thank you @Sidharth_Ramesh for this post! I’ve been working on this and tried to get feedback from others and published an ERD excerpt for the flattened body temperature tables.
We heard about the performance issues in Catalonia which are the consequence of the “two-level” data model used for storage.
I asked myself whether the two level openEHR data model needs a two level storage model? What if tables are generated and migration is done using tools like Liquibase? Using CI would allow for automated inclusion of OPT changes without human intervention (I heard this is something clinical modelers like about the current implementations).
We can generate SQL tables based on OPTs and archetypes. And we don’t have to stop with SQL. We can generate “Archetypes as code” (see here, and here for TypeScript version). I imagine developers would just use these SDKs when interacting with openEHR CDR but be able to use their own UI framework and backend in Java/Kotlin/C#/TypeScript/Dart/PHP (these are the languages I have SDKs for).
CDR vendors might not be able to publicly post anything that would contradict their current implementation – it would be bad for their business. New CDRs being built are free to take different approaches.