# Separating Models from Implementation

**URL:** https://discourse.openehr.org/t/separating-models-from-implementation/2093
**Category:** New to openEHR?
**Created:** [22 November 2021 13:56 UTC](https://discourse.openehr.org/t/separating-models-from-implementation/2093 "2021-11-22T13:56:51Z")
**Posts on this page:** 1
**Showing post:** 77

<div class="post-metadata">

### Author: ![erik.sundvall](https://discourse.openehr.org/user_avatar/discourse.openehr.org/erik.sundvall/32/1961_2.png) [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [2 December 2021 10:02 UTC](https://discourse.openehr.org/t/separating-models-from-implementation/2093/77 "2021-12-02T10:02:53Z")

</div>

In order to not kidnap [the thread about @NeoEHR’s cool generators](https://discourse.openehr.org/t/openapi-schemas-generated-from-bmm-files/2116) I’ll clarify some thoughts here instead, where I believe the core of this discussion fits better.

@borut.jures and @thomas.beale I am not sure I explained my point well enough in [OpenAPI schemas generated from BMM files - #9 by erik.sundvall](https://discourse.openehr.org/t/openapi-schemas-generated-from-bmm-files/2116/9) when refering to @heath.frankel’s comment from 2012 on the wiki page [https://openehr.atlassian.net/wiki/spaces/spec/pages/4915205/Ocean+EhrGate+-+Composition+Builder+programming+example](https://openehr.atlassian.net/wiki/spaces/spec/pages/4915205/Ocean+EhrGate+-+Composition+Builder+programming+example)

Yes developers/integrators need to learn _a little bit_ about openEHR basics (but not much) if they e.g. have a template-specific use-case that is one of their first tasks to interact with an openEHR system.

However it would be great if they did NOT have to switch tooling or start using openEHR-specific path-based ways of interacting with components like the one suggested in the 2012 wiki page or the more elegant/compact `toJson()` method described by @borut.jures in [OpenAPI schemas generated from BMM files - #10 by NeoEHR](https://discourse.openehr.org/t/openapi-schemas-generated-from-bmm-files/2116/10)

By tools/methods they are already used to, I mean…

1. for **integrators/informaticians** creating and maintaining integrations: low code tools like Altova MapForce or Mirth as described in [Graphical data mapping tools supporting openEHR?](https://discourse.openehr.org/t/graphical-data-mapping-tools-supporting-openehr/2096) (these tools work best if supplied with a template specific schema with user friendly node names derived from the template labels - TDS is one such approach, a similar way to do JSON schema for the “structured” (JSON tree) simplified format [described as _structSDT_ in the end of section 3.2 of a spec](https://specifications.openehr.org/releases/ITS-REST/latest/simplified_data_template.html#_json_formats) would also be a great option for such tools
2. for **software developers** : a template-specific litte library of classes with names derived from the template labels. TDO is/was such an approach, template specific openAPI definitions would do the same job in a more modern and programming language-neutral approach. Then they can just generate and import the library/classes and keep using their favourite editor/IDE and get syntax higlighting, auto completion, validation etc based on the template (Instead of string based path/key approaches where errors often are only found at runtime).

So it’s not that we would try to “hide” everything in openEHR, it’s about making the integrator and developer experience more efficient and less error prone.

Edit: @Seref pointed out in a recent SEC-meeting that the simplifications in TDOs etc stopped somewhere around the openEHR data-type lower levels, and there reused a generic part for different use-cases/templates. Perhaps @seref or somebody else that is used to working with this could explain further in a few sentences?

---

_[View the full topic](https://discourse.openehr.org/t/separating-models-from-implementation/2093)._