Hi Thomas, I've added a proposal to the page on the wiki
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model
I'm also thinking about the ENTRY model, to lift up the data/description
attributes from all entry subclasses to the ENTRY, to have a
ENTRY.data:DATA_STRUCTURE attribute, so all subentries could define the data as
ITEM_STRUCTURE or as a HISTORY.
Maybe to have the flexibility to define ACTIONS and other entries to have a
data attribute of class ITEM_STRUCTURE or HISTORY to track time of events
instead of inventing DV_DATE/DV_DATETIME ELEMENTs on
ACTION/EVALUATION/INSTRUCTION archetypes is a good idea. What do you think?
--
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
Date: Thu, 15 Dec 2011 15:48:07 +0000
From: thomas.be...@oceaninformatics.com
To: openehr-technical at openehr.org
Subject: Re: 13606 revisited - list proposal
I have started a wiki
page for this 'lower RM' simplification. The top contains the
existing models, feel free to add to the 'problem' list (why are we
simplifying?). If you have a candidate solution to offer, please put
it under a new heading - you will see a 'Candidate B' ready to be
used by someone. If we proceed in that fashion, I think we can keep
the proposals clear.
NOTE: I have only half done my proposal, Candidate A, so don't
bother looking at it yet.
- thomas
On 15/12/2011 14:54, pablo pazos wrote:
Hi Erik,
I want to implement some simplifications of the
item_structure in the EHRGen (
http://code.google.com/p/open-ehr-gen-framework/ ) we talked
about this:
http://www.openehr.org/mailarchives/openehr-clinical/msg02231.html
My focus is on the persistence layer, because we persist
data using an ORM (object-relational mapping) component, and
the complexity of the relational schema is proportional to
the complexity of the object model.
BTW, the EHRGen has the complete cicle of information
implemented: automatic gui generation (based on archetypes
and our gui templates), data validation against archetype
constraints, data binding (creation of RM structures from
user data input and archetypes), persistence of those
structures, and getting data to show on a GUI.
Now I'm experimenting with semantic queries (common SQL
but based on arcehtype ids and paths).
Regards,
Pablo.
> Regarding the RM I know Tom is experimenting with
simplified
> ITEM_STRUCTURE as a BMM-schema for the AWB. Are there
any other
> RM-redesign experiments going on anywhere?
>
> What is happening in the 13606-world regarding thoughts
about
> practical datatypes?
>
> What about (optional) reusable ENTRY subtypes in the
13606 world? (see
>
http://www.openehr.org/mailarchives/openehr-technical/msg05285.html
> under the heading "2. OBSERVATION et. al. (ISO 13606
CR)")
_______________________________________________
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/20120131/d3898636/attachment.html>
