Hi Pariya,
Comments are inline, and corrections are most welcommed in case I am wrong
about any of them :)
On Tue, Mar 31, 2009 at 12:49 PM, Pariya Kashfi <hajar.kashfi at
chalmers.se>wrote:
> Hi,I've three basic questions about IM and AOM:
> Assuming that a connection between GUI forms and templates( consequently
> Archetypes) has been established, still the connection
> between Information Model and Archetype Model is not clear for me.
>
The archetype model is an object model that represents the ADL in an object
oriented environment that implements AOM. Let me try to explain with more
concrete examples: you have an adl file that describes the structure of an
archetype. The adl file describes which RM classes are used in the
archetype, and also constraints on them. So ADL says that you have a member
with type HISTORY, that should have EVENTs, which conform to following
conditions.
Now, you need a way of making use of this description to create a model of
the clinical concept described in the archetype. The question is how can you
use this ADL file, how can you process it to create the described model? So
you need to connect the following: (ADL) ----------> (RM class instances as
described in the ADL). The AOM is a well defined method for representing the
ADL in an environment where object orientation is supported, like JAVA or
C#, or C++.
An implementation of ADL therefore gives you a set of objects which you can
process in order to make use of the information in the ADL text file. For
example, when you parse the following ADL file (only a part of it is given):
*****************************************************************************************************************************************
archetype (adl_version=1.4)
openEHR-EHR-OBSERVATION.soap_investigations_sa.v3draft
concept
[at0000] -- SOAP-Objective_Investigation
language
original_language = <[ISO_639-1::en]>
description
original_author = <
["name"] = <"unknown">
>
details = <
["en"] = <
language = <[ISO_639-1::en]>
purpose = <"For test purposes">
use = <"">
misuse = <"">
>
>
lifecycle_state = <"0">
other_contributors = <>
other_details = <
["references"] = <"">
>
definition
OBSERVATION[at0000] matches { -- SOAP-Objective_Investigation
data matches {
HISTORY[at0001] matches { -- Event Series
events cardinality matches {1..*; unordered} matches {
*****************************************************************************************************************************************
You can see that the adl above is represented like this in memory (using
Eclipse debugger):
********************************************************************************************************************************
archetype Archetype (id=1588)
adlVersion "1.4" (id=1601)
archetypeId ArchetypeID (id=1602)
concept "at0000" (id=1604)
definition CComplexObject (id=1605)
description ResourceDescription (id=1607)
inputPathMap HashMap<K,V> (id=1609)
invariants null
isControlled false
ontology ArchetypeOntology (id=1610)
originalLanguage CodePhrase (id=1612)
parentArchetypeId null
pathInputMap HashMap<K,V> (id=1614)
pathNodeMap HashMap<K,V> (id=1615)
revisionHistory null
translations null
uid null
******************************************************************************************************************************
If you expand the object tree in memory (that is given to you by parser),
you'll see that the whole adl file is represented consistently in a well
defined way using AM (please check AM pdf in documentation to see how adl is
represented)
At this point, you have something that describes the exact same thing that
ADL describes, only in an object model. So what can you do with it? How do
you go from here to RM instances that will hold the healthcare information?
How about this:
***************************************
definition CComplexObject (id=1605)
anyAllowed false
assumedValue null
attributes ArrayList<E> (id=1622)
nodeID "at0000" (id=1623)
occurrences Interval<T> (id=1624)
parent null
path "/" (id=1626)
rmTypeName "OBSERVATION" (id=1627)
***************************************
This is again from Eclipse debugger. The definition field of the AM object
has a CComplexObject, which seems to have some attributes.Check out
rmTypeName -> "OBSERVATION". This means that you'll be creating an instance
of an Observation to hold real life data. The Observation class is defined
in RM documentation (
http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf) and if you
further expand this fields of this AM instance, you'll see that the
constraints about attributes of the Observation class are also there. So the
AM tells you which RM classes you'll be instantiating, and what kind of
constraints exist for attributes of these instances.
Based on the implementation at hand, things may get a little bit tricky, so
I won't go into that discussion. But another thing you can do with AOM
instances at this point is, you can create a user interface representation.
Now we are in dangerous territory, since templates are more associated to UI
related things than archetypes, but I'll express my own point of view and
say that even if you use templates, at the end you'll be looking at
something very similar to this AOM objects, so an approach that relies on
using AOM instances to create gui artifacts should survive under similar
conditions. That rmTypeName attribute will occur in other places in AOM, for
example for DVText. Creating a textbox for for getting data that will go
into a DVText instance at some point makes sense, this may not be true 100%
time, but lets keep it very simple for now.
So you did parse an archetype, you got back a set of AOM instances, and you
presumably used them to create some sort of data entry functionality to get
back some real life data. Now you can put that data in a RM instance, which
is pointed at by the relevant node in the archetype, and expressed by the
AOM object. What you do with that RM instance is context dependent I guess,
since I can imagine some uses other than persisting it (processing it
etc..).
The only connection I could find between these two models is based on
> Locatable class which has been inereited in both categories: AOM and IM.
> Does it mean that after data entry, validation will be done using archetype
> object in memory, and then data will be set in RMObject, to be set in EHR
> composition?
> Moreover, I did not manage to find enough description on the relation
> between different classed on Archetypes( namely sections, compositons,...)
> and what is presented in IM, like Composition. My perception is that
> archetype constraints like composition, section, ... will be used to
> validate entered info. Is there any document explaining the relation between
> IM and AOM ?
>
Check the link I've given above, and other specs (like data types etc)
>
> On the other hand, as far as I understood, the only information about
> archetypes that is stored in EHR, is the archetype Id that will be stored in
> the EHR composition through the RMObject. Is that right? Does it mean that
> later on, by retrieving every EHR related Archetypes will
> be accessible using these IDs?
>
I'm taking the risk of not checking the specifications and responding from
the top of my head. As far as I can remember, a link to the relevant
archetype is kept in the EHR entity, and it makes sense, since you'd like to
know what kind of constraints are valid for the information you're storing
in the composition. I would say that your assumption about data entry,
validation and finally data ending up in RM object is correct, though I
would not be surprised someone came up with alternative flows (this is a big
standard)
All the information you'd need is out there, but it takes some time to learn
where to look for a particular answer. Hope this helps
Kind regards
Seref
Regards
Pariya
PhD Student
Department of Computing Science and Engineering
Chalmers University of Technology
http://www.cs.chalmers.se/~hajar.kashfi/<http://www.cs.chalmers.se/%7Ehajar.kashfi/>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090331/a823b8a5/attachment.html>
