Re: Run-time name constraints and appropriate use of terminologies

[Ian McNicoll <Ian.McNicoll@oceaninformatics.com>]

PART 1 of Sebastian's latest reply to me ...

============================================================

.... My main approach and views while I'm looking over archetypes and specifications is from a technical perspective, as I'm working as software developer.

About the name attribute issue: whether or not to use purpose() or directly name/defining_code attributes is not so relevant, as the concern I have is in fact that the name holds the type and the semantics of the (owner) object. I think I understand the principles behind that (as you already explained in previous emails) and also the RM design as well as the design aspects on CKM archetypes made by Sergio. But when it comes to software development, if I want to get the meaning of that object the only solution is to know the item-structure beforehand, thus that piece of software handling PARTY_IDENTITY will be highly dependent on the archetype itself. Any structural change or re-coding local terms made in those archetypes will require change in the software. Even worst, if I make the software rely on the DV_TEXT/value instead of DV_CODED_TEXT/defining_code (which is a bad ideea from my perspective) I will get problems only by changing the language of the archetype or just by renaming the node on the template level.

Indeed, at-code gives us language-neutral terminology, designers or archetype owners have the flexibility to do whatever they need in an archetype, but they will have to agree on using and sharing archetypes and templates. Still, if there is no common ground to share and safely transfer semantics (and what I mean here is the knowledge provided by a specific archetype) between parties I don't see interoperability working that smoothly.

Let me give you an example of what and how can go wrong:
Suppose there is hospital A will going to use CKM archetypes and another hospital B developing their own ones. A is going to exchange openEHR information with hospital B, one of the topic being is PATIENTs. As A will going to use openEHR-DEMOGRAPHIC-PERSON.person.v1and openEHR-DEMOGRAPHIC-CLUSTER.person_identifier_iso.v1 the 'legal identity' type is modeled by that famous

    identities[openEHR-DEMOGRAPHIC-CLUSTER.person_identifier_iso.v1]/name/defining_code = 'local:at0027'

B is going for other, CKM similar but not the same, in-house developed, archetypes; for the sake of exercise the original (and only) language will be dutch: openEHR-DEMOGRAPHIC-PERSON.b_persoon.v1 and openEHR-DEMOGRAPHIC-CLUSTER.b_persoon_identifier.v1 and will use the following path to test legal identity:

    identities[openEHR-DEMOGRAPHIC-CLUSTER.b_persoon_identifier.v1]/name/value = 'juridische identiteit'

As time passes B learns that he must use internal codes to be more efficient on handling or exchanging data so he publish a new modified version: openEHR-DEMOGRAPHIC-PERSON.b_persoon.v2 and the path becomes:

    identities[openEHR-DEMOGRAPHIC-CLUSTER.b_persoon_identifier.v2]/name/defining_code = 'local:at0008'

Notice, it is at0008 because it is completely different archetype, and that was the code rightfully assigned by the archetype tool used in the B organization. 

Now, as you might see already, if B wants to exchange data with A, they will have to share archetypes because only looking to the at-codes is not enough (at0027 vs at0008) - i.e. A must access and read openEHR-DEMOGRAPHIC-PERSON.b_persoon.v2 in order to validate and use terminology associated with at0008. Suppose that is not an issue and A accomplished that reading... but now the question is how can A understand what should be the right code associated with legal identity. Previously, in his own domain, A used (instructed by the application level) to look for at0027 but there is no clue for him how to locate the same concept in B domain.

I guess in this case a quite good solution (as you already mentioned) is to use term bindings to a common external terminology. It will not enforce but probably just facilitate common semantics. Without it, the above use-case will be quite a challenge to solved for good. Still, adopting this solution requires agreement between A and B on using a common external terminology service which might add some adoption issues (maybe even scalability) on top of whole openEHR solution.

Another solution, which I was referring on in my previous email is to use openehr terminology directly instead of local at-codes. This will be pretty similar (at least from my point of view) to the way the way Entry package is regulated (see for instance ISM_TRANSITION class attributes), the only difference being that over there specifications (instead of archetypes) are 'enforcing' terminology. Beside this, like you already mentioned, it will also allow re-use of some terms accross demographic archetypes. On the other hand, can you tell me how come there is openEHR terminology for instructions, audit change types, composition categories, etc instead of coding those terms locally on the archetype level? Is it

You nicely concluded saying that we have "a mechanism that is semantic precise, within the context of the archetype and allows us to bind to external terminologies as and when they become available, without enforcing their use" while my point is that for these demographic name-based-typing it will be even safer to use an openEHR terminology instead, as that is always available within an openEHR environment.

=================================

Part 2 to follow ...

Ian

Dr Ian McNicoll
office / fax  +44(0)141 560 4657

mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
ian@mcmi.co.uk

Clinical Analyst  Ocean Informatics

Honorary Senior Research Associate, CHIME, University College London
openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland


_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical