Dear all, as some of you may have noticed, the openEHR Architectural Review Board was created some months ago, and is now in action (see http://www.openehr.org/about_openehr/t_arb.htm). Its job is to manage changes to openEHR.
The ARB is currently processing a number of CRs (Change Requests) which have been raised and are targetted to openEHR release 1.0 (for the list, see http://www.openehr.org/repositories/spec/latest/publishing/CM/CRs/CR_by_release.html - toward bottom). As part of the process, we feel that certain CRs would benefit from community feedback - in particular, anything which actually changes models or specifications, and would cause changes in current openEHR software projects being. (Note: CRs which are processed by the ARB alone are generally to fix errors in documentation or software, and don't appear to require much decision-making as such. In other words, we try not to waste your time with no-brainers!). To add some focus to this process, I have suggested making a post for each CR to the openEHR technical group, in order to start a discussion thread. There will accordingly be a series of posts like this one, each for an openEHR CR. We anticipate two kinds of response: - technical feedback - feedback about timing of implementation, impact, etc The CR to be considered in this post is CR-000101- Improve Modelling of Structure classes. See <http://www.openehr.org/repositories/spec/latest/publishing/CM/CRs/CR-000101.txt> . This CR proposes a change to the Data structure classes which makes for more efficient data representation. The current model is at <http://www.openehr.org/repositories/spec/latest/publishing/architecture/reference_model/data_structures/im/REV_HIST.html> The PDF attached to this post shows the proposed change, in the form of a UML diagram for the data structure classes. In the PDF, the 2nd UML diagram is the important one; if you compare it to the existing model you will see that in the new model, each data structure type (ITEM_TABLE etc) now has its own connection to the appropriate CLUSTER or ELEMENT type. Previously, ITEM_LIST would have had a CLUSTER then a bunch of ELEMENTs; now it just has a list of ELEMENTs. There are of course still far more efficient ways to implement these data structure classes; my preferred proposal for the future is that the model specifies only interfaces, and implementors do whatever they want; they just have to implement one method, namely the "as_hierarchy" method you see in the class ITEM_STRUCTURE - this is the one that guarantees that each data structuer can be converted to a CEN / openEHR / CDA hierarchical CLUSTER/ELEMENT form, as required for interoperable EHR Extracts / Documents. However, the simpler change proposed here is probably preferable for the moment. The DSTC in Brisbane, Australia is currently working on an openEHR implementation, and have analysed the XML data resulting from the current model; their analysis shows that this proposed change would reduce the amount of duplication in XML structures; I would expect anyone working with openEHR and XML would come to a similar conclusion; implementors' comments very welcome. Close of RFC: 23 July 2004. regards, - Thomas Beale -- ___________________________________________________________________________________ CTO Ocean Informatics (http://www.OceanInformatics.biz) Hon. Research Fellow, University College London openEHR (http://www.openEHR.org) Archetypes (http://www.oceaninformatics.biz/adl.html) Community Informatics (http://www.deepthought.com.au/ci/rii/Output/mainTOC.html) -------------- next part -------------- A non-text attachment was scrubbed... Name: CR-000101-a.pdf Type: application/pdf Size: 25263 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20040709/c84314a4/attachment.pdf>
