Hi Pariya,
Glad to hear it helps. If you want to see all of this in action, download
Ocean's open source archeytype designer, and debug the code. vb.net is easy
to follow in syntax, and it should let you see how things are connected
together.
Load an archetype, and view the interface generated for it in the archetype
designer. What happens at the background is quite similar to what I've
described. Though I did not test the debugger, SharpDevelop (
http://www.icsharpcode.net/OpenSource/SD/) should help you out, in case you
don't have access to Visual Studio.
Kind regards
Seref
On Wed, Apr 1, 2009 at 10:07 AM, Pariya Kashfi <hajar.kashfi at
chalmers.se>wrote:
> 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/<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
>>
>>
> ------------------------------
>
> _______________________________________________
> openEHR-technical mailing listopenEHR-technical at
> openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
> --
> <OceanC_small.png>
> *Thomas Beale
> Chief Technology Officer, Ocean Informatics<http://www.oceaninformatics.com/>
> *
>
> Chair Architectural Review Board, *open*EHR
> Foundation<http://www.openehr.org/>
> Honorary Research Fellow, University College
> London<http://www.chime.ucl.ac.uk/>
> *
> *
> _______________________________________________
> 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/<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/20090401/333dcc51/attachment.html>
