# Formal methods for Evaluation of Interoperability &Maintainability?

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2008-02-07 12:52 UTC
**Views:** 1
**Replies:** 1
**URL:** https://discourse.openehr.org/t/formal-methods-for-evaluation-of-interoperability-maintainability/12767

---

## Post #1 by @Charles_McCay

All

I do not recognize this description of RMIMs as modifications to the HL7 RIM. RMIMs express constraints on the HL7 RIM – the RMIM is a static model that is defined as a constraint on the RIM, with all the semantics defined in the RIM and associated vocabularies. There is NO additional semantics introduced in the refinement process, just a restriction on the set of conforming structures.

It is true that the HL7 XML ITS uses the association names from the RMIM for the XML element names, as a pragmatic choice to aid implementation. It would be perfectly possible to write an ITS that used the underlying RIM association names. This was considered and felt to be less useful by those doing implementations

I am yet to see an openEHR XML ITS for instance data, but am sure that a similar implementation trade-off between serializing the underlying reference model or serializing based in the archetype definitions would be worth considering

All the best

Charlie

Charlie McCay, charlie@RamseySystems.co.uk
Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES
tel +44 1743 232278 / +44 7808 570172 skype: charliemccay linkedin:charliemccay


[details="(attachments)"]

![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png)

[/details]

---

## Post #2 by @thomas.beale

Charlie McCay wrote:
>
> All
>
> I do not recognize this description of RMIMs as modifications to the
> HL7 RIM\. RMIMs express constraints on the HL7 RIM – the RMIM is a
> static model that is defined as a constraint on the RIM, with all the
> semantics defined in the RIM and associated vocabularies\. There is NO
> additional semantics introduced in the refinement process, just a
> restriction on the set of conforming structures\.
>
> It is true that the HL7 XML ITS uses the association names from the
> RMIM for the XML element names, as a pragmatic choice to aid
> implementation\. It would be perfectly possible to write an ITS that
> used the underlying RIM association names\. This was considered and
> felt to be less useful by those doing implementations
>
> I am yet to see an openEHR XML ITS for instance data, but am sure that
> a similar implementation trade\-off between serializing the underlying
> reference model or serializing based in the archetype definitions
> would be worth considering
>

\*Charlie,

all the XSDs for openEHR data are here:
http://www.openehr.org/releases/1.0.1/its/XML-schema/index.html

see the top group\. These schemas hold for all openEHR data, regardless
of archetype, template or terminology\.

There is a different kind of machine\-generated schema which we call the
Template Data Schema \(TDS\); any openEHR template can have this generated
for it\. This enables messages to be created specific to a template, e\.g\.
a specific kind of path result\. The data that conform to a TDS can be
machine converted into standardised openEHR data for addition to an
openEHR system\. The key in all this is that TDSs are completely machine
generated, not hand\-built; the source of truth is always the archetypes
and templates\. The descriptions and diagrams on this page provide a
high\-level explanation\.

\- thomas beale

---


**Canonical:** https://discourse.openehr.org/t/formal-methods-for-evaluation-of-interoperability-maintainability/12767
**Original content:** https://discourse.openehr.org/t/formal-methods-for-evaluation-of-interoperability-maintainability/12767