Hi Sebastian,
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.
well, queries will be archetype-dependent, that is the idea.
Any structural change or re-coding local terms made in those archetypes will require change in the software.
this depends on how the software is designed. If it is designed to use AQL queries, then it should not require changes, only the query might require changes.
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.
normally, you would use both the value and the defining_code fields of a DV_CODED_TEXT object.
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.
that is correct - and what these documents are about at http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts
Under the collaboration of openEHR and IHTSDO, these will be further developed into a basis for reliable sharing and improved identification.
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.
this is normal - if two organisations want to share data, they need to share archetypes concerning that data. It doesn’t matter what mechanism they use, this must be the case. Doing anything that works means relying on some external (to both) or shared resource - whether it is archetypes or SNOMED or ICD or anything else. What does not need to be shared is templates - each institution can happily create as many as it wants, based on the same archetype repository. Each institution can also create its own private archetypes for data
- not intended to be shared
- intended to be shared one day, when the private archetypes will be shared
- intended to be shared , but not processed by the receiver in an intelligent way (but display would still be possible)
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.
yes, this is because the archetype acts as the name space for the at-codes.
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.
but you are still pre-supposing that each place is developing essentially the same archetypes independently. This won’t work, and isn’t sustainable in terms of work anyway - it will obviously be less work to develop shared archetypes once (and of better quality) rather than develop the same thing many times.
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.
for many reasons this is also useful. But if A & B really don’t want to cooperate, or share, or agree on anything, it is kind of hard to help them!
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?
The openEHR terminology is used for attribute codes in the model where it is thought that the possible set of codes is universally applicable and unlikely to change, or only very slowly. Any coded attribute that has a value set that could be contextually dependent is going to require a more dynamic and sophisticated approach to terminology. At the moment this is done in archetypes, because there is nowhere else to do it. However, the future approach may be that it could be done in SNOMED national extensions, or lower level extensions of SNOMED.
