Separating Models from Implementation

@ToStupidForOpenEHR Now I found the thread on Twitter, I started in the Discourse end. sorry about possible confusion/sidetracking added.

I find your original request there very reasonable. I believe that what you are asking for is exactly what the TDS/TSS approach did/does using normal XML-schema and XML instances (that any XML tool understood, without being an openEHR-specific tool). We’d need a JSON schema-based equivalent nowadays. (And likely a similar GraphQL approach.) Would the approach discussed in post #12 above achieve what you are asking for?

The Web template JSON-files are semantically a schema like TDS but in a custom JSON structure, not in a format that non-openEHR tools like Altova can ingest. Let’s fix that by creating a way to generate proper (template specific) JSON schema (that can be used in regular non-openEHR tools).

The openEHR vendor Better has separated out some generic things (user, language etc) into a context (ctx) object that can be reused in API calls and automatically populate some COMPOSITION and VERSION values from that. That kind separation would likely be clever to allow if we want a simpler format for specific templates.

3 Likes