I’m not in favour of obfuscating the archetype/template distinction with exports. I think it doesn’t make sense to offer a very simple template with a basic composition. I think it does however make sense to offer some common usecase e.g. result of a BP measurement as a template (bp observation, result-report composition). And export that as OpenAPI (or json-schema, XML, or webtemplate). But the implementer has to be aware that his implementation has to match the context (actual measured bp of the subject of the ‘ehr’, not e.g. a target bp) of the template, or stuff will go horribly wrong for that patient. It is fine to not constrain out many of the elements in the bp observation archetype, as we’d normally do, and leave that up to the implementer. But mandatory elements should at least stay mandatory (shouldn’t be a problem, BP archetype has none, report-result composition has only very straightforward stuff: e.g. start-time: who would want to record a BP without recording the time of the measurement, that has no value).
This would even be very valuable to many openEHR implementers.
We all don’t think it makes much sense to export only archetypes. Since the implementer will have to supply the context information and this will bring back all the complexity of openEHR. And will realistically never be interoperable with native openEHR. But I also think it’s not up to us to keep people from trying. Maybe they come up with something simpler, better, cheaper, faster than openEHR and I’d be all for that. So we should not block export of archetypes. But realistic, it is not. So I wouldn’t enjoy spending time on helping people, who don’t understand the complexity to do this. And I wouldn’t want to be responsible for contributing to another ehealth related clinical disaster.