On 17/02/2018 21:53, A Verhees wrote:
I know Thomas, but they have dependencies to other classes in the RM.
To data types, to support.
that should not be the case - that's exactly what we are avoiding. If we
missed something it is an error. But note - most of the RM 'Support IM'
model moved to BASE.
By the way, I have never seen use for translation details except for
the archetype metadata. But maybe i missed it. That is possible, if
so, excuse me for this example.
We think it will get used for Task Plans, and maybe GDL guides.
The terminology service also has dependencies to rm data types, only
because of codephrase. Wouldn't it be possible to avoid that?
Yes, there is a new class TERMINOLOGY_CODE that is used in BASE instead
of CODE_PHRASE; eventually, the RM should just use that. If you found
any use of CODE_PHRASE in BASE, please let us know.
This also creates a circular dependency at construction of several RM
classes. They need the OpenEhr terminology when constructed, and the
terminology needs the RM codephrase.
The archetype_Id is inherited from object_id, but why is that
necessary? What is the advantage?
Not much admittedly, since OBJECT_ID is just an identifier with a
concrete String representation, but it does mean that an OBJECT_REF can
point to any kind of OBJECT_ID, including an ARCHETYPE_ID.
Of course it is not only design, it is also the developers, they
create those large libraries, but they are inspired by the theoretical
architecture-plan, and maybe they need to do that to avoid circular
library references.
yes, as I say, there should be absolutely none of these. Any you see
need to be reported.
There is, in my opinion a need to split the RM. Rongs did that a few
years ago, he had an Ehr-RM and a (was it...) common RM. A step in a
good direction.
So splitting up the RM instead of making it larger would be my idea.
The first is not easy to do, but the second is, and helps us avoiding
further problems and avoiding creating unnecessary large libraries.
We are not intending to make the RM any larger, not sure why you think
we are.
- thomas
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
