Hi all,
when will this be available in the openEHR CKM?
Cheers,
Birger
Am 01.03.2017 um 10:15 schrieb Thomas Beale:
On 01/03/2017 09:03, Bert Verhees wrote:
Dear all of the technical mailing list,
I made a new message tothis list (specialized ;-), so it will be
discussed separately.
I do that because in the other message, I describe a real problem
which needs a solution, and this message is about thinking about a
solution in the archetype-framework, which will takes for years to
come (if it will come, maybe I am wrong in my proposal).
---------------------
When talking about specializing. Specializing an archetype is nothing
more then copying an archetype and add/change some constraints in them.
Only in older ADL 1.4 tools. In ADL2, specialisation is fully defined
<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_specialisation>
and implemented in the ADL Workbench, and more recently in the
ADL-designer project <https://github.com/openEHR/adl-designer>. it
works just like an OO programming language. There are dozens of
examples in the test archteypes
<https://github.com/openEHR/adl-archetypes/tree/master/ADL2-reference/features>,
and also in the CKM archetypes, which when they are read into ADL
Workbench, are re-engineered into differential form.
This has been the case for over 5 years, with the implementation in
ADL Workbench being available for around 4. (You can see the revision
history
<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_amendment_record>
of the AOM2 spec).
Using this technology is just a case of moving to ADL/AOM2.
- thomas
How different is that in programming languages, where the
parent-classes are read to understand the child class. There is no
need to process all the sourcecode of the child-classes to adapt the
changes in a parent class.
This is regarded as a big advantage for Object Oriented Programming.
Easier to maintain code (and one definitely need a test framework).
Imagine that dreaded generic labtest archetype in the other message,
I wrote today.
How convenient would maintainability become if specializations where
really and life-inherited from parent archetypes?
Would we need a big part of the LOINC-database of specialized labtest
archetypes then, or would we just need to change the identifier and
add the appropriate terminology binding?
Maybe we could, in case of lab-test, just created the child
archetypes only in memory and on the fly, needing only a few keywords
to describe the changes. We could take a look at hibernate for Java
(or many other ORM-frameworks).
They do not deliver the classes needed for handling specific
databases, they offer a framework to create/generate those classes.
One could argue that specializations are not always inherited like
classes in programming languages. That is true. What I suggest here
maybe limited to the cases where it is real inheritance.
Best regards
Bert Verhees
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
*Birger Haarbrandt, M.Sc.*
Peter L. Reichertz Institut für Medizinische Informatik
Technische Universität Braunschweig und
Medizinische Hochschule Hannover
Carl-Neuberg-Str. 1
30625 Hannover
T +49 (0)531 391-2129
F +49 (0)531 391-9502
birger.haarbra...@plri.de
http://www.plri.de
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org