I just wanted to warn people using UML linked or derived from... http://www.openehr.org/releases/1.0.2/architecture/computable/UML/uml.html
...that the old class MERGED_VERSION class still in UML files although
it has been removed from the specification documents (and VERSION plus
subclasses are a bit different)
P.s. A side question:
It seems impossble to add attestations to IMPORTED_VERSIONs, this
sounds reasonable (e.g. due to problems syncing back those
attestations to other systems without creating a new original
version).
The question I have is if there should be a procedure for attesting
things coming from other systems and how that procedure would look.
Lab results (e.g. OBSERVATIONs) from an external lab could be an
example - should a new local original version of the result be created
and then signed as a sign of reception and reading by the receiving
clinician or should other mechanisms (e.g. creating ACTION objects
referring to the result OBSERVATION).
Hi!
I just wanted to warn people using UML linked or derived from...
[http://www.openehr.org/releases/1.0.2/architecture/computable/UML/uml.html](http://www.openehr.org/releases/1.0.2/architecture/computable/UML/uml.html)
...that the old class MERGED_VERSION class still in UML files although
it has been removed from the specification documents (and VERSION plus
subclasses are a bit different)
which implies that the XMI is out of sync with the HTML generated from it!
As we have no way of working with this old XMI / UML (it is an old version of MagicDraw) we are stuck until a re-engineered model such as yours in the EMF framework is available.
The problem includes UML-generation described at
[http://www.openehr.org/wiki/display/dev/Experimental+generation+of+code+and+documentation+from+UML](http://www.openehr.org/wiki/display/dev/Experimental+generation+of+code+and+documentation+from+UML)
(same as tiny link [http://www.openehr.org/wiki/x/OwAt](http://www.openehr.org/wiki/x/OwAt))
I don't know if the problem is present in the files at...
[http://www.openehr.org/svn/specification/TAGS/Release-1.0.2/architecture/computable/UML/MagicDraw/](http://www.openehr.org/svn/specification/TAGS/Release-1.0.2/architecture/computable/UML/MagicDraw/)
...since I have not generated diagrams from them, but the phrase
MERGED_VERSION is at least present in the zipped XML file there.
I wonder if that is some historic tool artefact?
P.s. A side question:
It seems impossble to add attestations to IMPORTED_VERSIONs, this
sounds reasonable (e.g. due to problems syncing back those
attestations to other systems without creating a new original
version).
I just wanted to warn people using UML linked or derived from... http://www.openehr.org/releases/1.0.2/architecture/computable/UML/uml.html
...that the old class MERGED_VERSION class still in UML files although
it has been removed from the specification documents (and VERSION plus
subclasses are a bit different)
(And the 1.0.1 in the URL and some html page headings is a bit
confusing if this is 1.0.2
Erik asked:
P.s. A side question:
It seems impossble to add attestations to IMPORTED_VERSIONs, this
sounds reasonable (e.g. due to problems syncing back those
attestations to other systems without creating a new original
version).
The particular diagram you refer to has the MERGED_VERSION removed
from it, but it has not been removed from the underlying XMI-files and
is thus available as
[http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140019952491_116477_6153Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140019952491_116477_6153Report.html)
interesting…well, I am just waiting to move to a nice new clean UML expression, so this problem will evaporate
(And the 1.0.1 in the URL and some html page headings is a bit
confusing if this is 1.0.2 :-)
well this bit was intentional (maybe a bad decision) the idea was to indicate that the UML was stuck on 1.0.1 (it is…)
Erik asked:
P.s. A side question:
It seems impossble to add attestations to IMPORTED_VERSIONs, this
sounds reasonable (e.g. due to problems syncing back those
attestations to other systems without creating a new original
version).
Tom answered:
on the contrary, you can - see
[http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109326589721_134411_997Report.html](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109326589721_134411_997Report.html)
I trusted the specification to be more correct than the UML link you
refer to. Look at figure 7 (page 38) in
[http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf](http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf)
and the text/tables in chapter 6.5
The XML specification also follows the1.0.2 common im spec document
and puts attestations only under ORIGINAL_VERSION, not at the VERSION
level as the UML you refer to. See
[http://www.openehr.org/releases/1.0.2/its/XML-schema/documentation/Version.xsd.html](http://www.openehr.org/releases/1.0.2/its/XML-schema/documentation/Version.xsd.html)
It was via the mismatch between the XML spec and my generated UML
diagram I found the differences and then looked in the spec PDF
document...
You have got me there. I think the decision was that ‘attestation’ is only a meaningful concept on original content, i.e. because it is to do with some medical professional signing off on the content. So the UML is broken here. You should always trust the PDF
Thanks for bringing up these errors. In general, the PDF UML (although not even built using a tool!) is 99.5% dependable, with most errors found by now (actually prior to 1.0.2).
