Seref Arikan wrote:
(...)
>
> Things become interesting after this point. In the context of the java
> reference impl. and immutable rm classes, we can now create rm
> instances since we now have data, and we can persist them. If we were
> think of the simplest use case of just storing information and loading
> it back, would we need RM instances here? How about saving a custom
> represention of user input like an xml file to disk, and reading back
> for updates? As long as the link to original archetype is preserved,
> updates can be checked for validity.
In the database you save the "composition", which is a representation of
the data provided by the user using your form generated by the
archetypes and templates. How you save the composition on the database
depends on your implementation. In our case, we save the compositions in
XML in the database, indexed by patient id. This is efficient and useful
when you want to retrieve compositions of a particular patient, but it
is inefficient for population queries ("get all the patients with high
blood pressure in the last 3 months", for example). To allow this kind
of queries, we have mechanisms that allow to flag data of interest and
save them in indexed tables to fast queries. But again, how you save and
load the information depends on your implementation and usage. You could
just save the composition as XML files and create a stylesheet to show
the XML file on the screen without parsing them into java objects.
Fabiane
>
> In short, I'd be very happy to hear your description of the flow for a
> very basic scenario "in the context of java ref. impl". Especially how
> you'd use the RM classes (in immutable/mutable form) and when.
>
> Those of you who are active in development of archetype based systems
> can provide very useful feedback for others to follow
>
> Kind regards
> Seref
>
> Ps( the use of templates is deliberately excluded here, to keep things
> within a smaller scope)
> ------------------------------------------------------------------------
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
