For the last year and a half I've been working for HiGHmed, mainly on testing EHRBASE for conformance with the openEHR Specifications. In that area I've designed a Conformance Testing Specification, basically a huge set of test cases and data sets, which was initially implemented by Vita Systems using Robot Framework. The idea of having an abstract specification with those test cases was to allow any openEHR Software Provider to implement those test cases using the any technology and be able to self-assess their openEHR Products.
During that time we had many discussions about openEHR Conformance Verification, and even Certification of products. From those discussions, mainly inside the SEC, and new things I was thinking and trying out, I've found many elements that are needed in order to reach a formal openEHR Product Certification. Latelly I've been summarizing all those ideas, components and specifications into one concentrated document. The goal of such document is to define and clarify some concepts related with Conformance Verification and Certification that go beyond the execution of a set of test cases against an openEHR-based product, and that might be unclear or unknown by different openEHR stakeholders.
This is the first version of this document and it's open for comments and corrections. Please let me know what you think, and if you have any questions, drop me an email: pablo.pazos@cabolabs.com
Check the document:
openEHR Conformance Framework Design (latest)
openEHR Conformance Framework Design (2022-01-25)
Please note the scope of this openEHR Conformance document is wider than the current scope of the official openEHR Conformance work done by Thomas Beale for the openEHR Foundation, since the current specifications focus only on Clinical Data Repositories, and the openEHR Conformance document we published tries to include any type of product that could be openEHR compliant. We are sure the scope of the official openEHR Conformance will be broader in the future, specially by request of software providers of non-CDR systems that will need to certify their implementations too. We are preparing the ground for that!