# Formal methods for Evaluation of Interoperability &Maintainability?

**URL:** <https://discourse.openehr.org/t/formal-methods-for-evaluation-of-interoperability-maintainability/12767>\
**Category:** Technical (archive)\
**Created:** [7 February 2008 12:52 UTC](https://discourse.openehr.org/t/formal-methods-for-evaluation-of-interoperability-maintainability/12767 "2008-02-07T12:52:18Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Charles\_McCay](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/c/aca169/32.png) [@Charles\_McCay](https://discourse.openehr.org/u/Charles_McCay)\
**Post date:** [7 February 2008 12:52 UTC](https://discourse.openehr.org/t/formal-methods-for-evaluation-of-interoperability-maintainability/12767/1 "2008-02-07T12:52:18Z")

</div>

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](mailto:charlie@RamseySystems.co.uk)  
Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES  
tel +44 1743 232278 / +44 7808 570172 skype: charliemccay linkedin:charliemccay

> **(attachments)**
>
> ![OceanCsmall.png](https://discourse.openehr.org/images/transparent.png)

---

<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:** [7 February 2008 22:40 UTC](https://discourse.openehr.org/t/formal-methods-for-evaluation-of-interoperability-maintainability/12767/2 "2008-02-07T22:40:54Z")

</div>

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](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