# openEHR Conformance / Conformance Levels / Conformance Scopes

**URL:** <https://discourse.openehr.org/t/openehr-conformance-conformance-levels-conformance-scopes/1616>\
**Category:** Tooling\
**Created:** [8 June 2021 21:44 UTC](https://discourse.openehr.org/t/openehr-conformance-conformance-levels-conformance-scopes/1616 "2021-06-08T21:44:45Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [9 June 2021 13:45 UTC](https://discourse.openehr.org/t/openehr-conformance-conformance-levels-conformance-scopes/1616/3 "2021-06-09T13:45:22Z")

</div>

Good post - I agree with nearly everything you said. I’d suggest that since to actually perform a conformance test, at least one (or some particular mixture of) concrete serial formats are implicated, that the serial formats are one dimension of a ‘technology profile’.

For example, vendor A’s system might run on Oracle only, and support JSON and XML.  
Vendor B might run on any mainstream RDBMS, but only support XML.  
Vendor C might only run over Linux/MongoDB/etc, and support JSON.  
Vendor D - .Net, …  
and so on.

From a procurement perspective, the particular technology infrastructure usually includes things like OS, DB, virtualisation / container management, and arguably, serial formats.

I’m sure this is not the only way to analyse this…

---

_[View the full topic](https://discourse.openehr.org/t/openehr-conformance-conformance-levels-conformance-scopes/1616)._