I mean any kind of archetype, but in particular different archetypes for the same concept, eg blood pressure.
Thy can have internally the same atXxxx code for different nodes.
I mean the the harmonization of data elements is done manually by human beings, in order to allow data exchange by different systems.
I find it awkward that similar to archetypes, the message or CDA content for clinical concepts that are equal are coded / defined differently. This prevents reuse and prevents consistency.
Now you mention reuse and consistency and I understand you better, also because I know you are working on DCM.
The context of your message becomes more clear.
The atxxxx codes are generated in the archetype-editors, so there is no semantics to them. The room for explanations of the node, as you know, is in the ontology-section.
I think, this is the idea behind it:
It is a requirement that those at-codes are unique inside an archetype (except from internal references), if they would be allowed to be not unique, it could easily come to messed up archetype-paths.
Because they need to be unique, it is very inconvenient for archetype-editors to let them define manually by humans. The checks for at-codes for being unique would drive the human archetype designer crazy, especially in large archetypes.
The at-nodes do not identify data points outside an archetype, that purpose is being served by the archetype-path, which also contains the archetypeids being involved (in case of slots, more then one)
The items in ontology are very limited, only text and description. I must agree that this is not much, especially if you want the at-nodes being explained by code systems.
But on the other hand, it is easy to introduce a sanity-rule. Let the text be a code, and let the description be the indicator of the code-system involved.
I must agree that it is not forced, thus weak. Better was to extend the ontology with appropriate items. Do you think that would be a good idea?
I mean any kind of archetype, but in particular different archetypes for the same concept, eg blood pressure.
Thy can have internally the same atXxxx code for different nodes.
as a general thing they don't although it's not formally prevented. It's because nodes are uniquely identified by their paths, not just the local node id. That's the bullet-proof node identifier, and that's why bindings in archetypes today are mostly to paths, not just to single at-codes.
I mean the the harmonization of data elements is done manually by human beings, in order to allow data exchange by different systems.
I find it awkward that similar to archetypes, the message or CDA content for clinical concepts that are equal are coded / defined differently. This prevents reuse and prevents consistency.
That's correct. It's better to just use archetypes, and generate CDA schemas, which are not in themselves any good to model with; or even better native message schemas - which reduce data conversion costs and increase patient safety. There's no real justification for introducing difficult to work with documents and schemas when seamless model-based artefacts can be generated, and used directly in software and messages. That approach is the future - generated downstream products from models - it's the only sustainable approach.
It's true that the only attributes for each term in the ontology are its at-code, plus its text and description. But this is not all that you can do with a term.
* You can bind at-codes to terminology codes, to define the meaning of a node in various terminologies.
* In ADL 1.5, you can add 'attributes' to a terms. These attributes are arbitrary code-value pairs. The openEHR Archetype Editor is still stuck on ADL 1.4 so it doesn't support this yet, but it does provide pretty much the same functionality by allowing arbitrary keys other than "code", "text" and "description" on the terms. This is a bit of a hack, but in the future when the archetypes using these non-standard term keys are converted to ADL 1.5, it should be a very straightforward process to move the non-standard keys automatically into the attributes section.
Thanks Peter, for your information. As soon as ADL 1.5 is official, I will study what I can do with it. I hear a lot of good things about this new version.