Hi,
Thanks to Seref for this comprehensive and very helpful reply. I
appreciate it.
I had totally missed rm-type-name which with this explanation is
now clear for me.
P.S: what keeps me going while I'm overwhelmed and confused by all
specifications and documents is this mailing list and responsive
members like Seref and Thomas ;)
-Pariya
On Mar 31, 2009, at 11:01 PM, Thomas Beale wrote:
>
> just one modification of Seref's comprehensive answer... you can
> tell what archetypes were used in any top-level entity, i.e.
> Composition, Party, Directory, EHR Access etc - see the architecture
> overview. Archetype ids and node ids in the data are all that is
> needed to reconnect the data with the relevant archetypes (usually
> via templates; the template id is also in the data, but can be
> ignored as well).
>
> - thomas beale
>
>
>
> Seref Arikan wrote:
>>
>> 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/
>>
>>
>>
>>
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>>
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>
>
> --
> <OceanC_small.png> Thomas Beale
> Chief Technology Officer, Ocean Informatics
>
> Chair Architectural Review Board, openEHR Foundation
> Honorary Research Fellow, University College London
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Regards
Pariya
PhD Student
Department of Computing Science and Engineering
Chalmers University of Technology
http://www.cs.chalmers.se/~hajar.kashfi/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090401/71dfb63a/attachment.html>
