Trying to understand the openEHR Information Model
Hi bert Although risking to be a pleasure killer ;), but on my iPad 3 (and iPhone) I have a little globe symbol to the left of the space bar that allows toggling of languages. As http://www.theipadguide.com/faq/how-can-i-type-different-languages-turn-international-keyboards-ipad explains it requires that you add at least a 2nd keyboard layout. Not sure whether this requires a a newer version of iOS... Cheers Thilo On 22/04/2013, at 5:58, Bert Verhees bert.verhees at rosa.nl wrote: Yes, it is an IPad configured for use in Dutch, and sometimes it spontaneously starts understanding English, and sometimes it mixes both languages, and sometimes it rewrites words silently. There is no quick way I know to change the language, so I look at all words with red lines under them. Sometimes I see a wrong word a few lines back, but it is very hard to get the cursor there. I sometimes have an Android-tablet too ( in fact, my two sons have them, one Apple, one Android), and Android-tablets are as bad. But Android has a language-selector in the keyboard. Since we have tablets, my family removed all computers from the living-space. But, it gave you some pleasure. That is the good thing about it. ;-) Bert Verstuurd vanaf mijn iPad Op 21 apr. 2013 om 21:19 heeft Randolph Neall randy.neall at veriquant.com het volgende geschreven: I meant to write curious instead of anxious, stupid autocorrection of iPad. That is one dangerous--and very amusing--iPad. :-) Speak calmly to it next time. Bert, by this you got my day off to a rollicking start. Randy On Sat, Apr 20, 2013 at 6:17 PM, Bert Verhees bert.verhees at rosa.nl wrote: I am very anxious to learn why the current XPath/XQuery-specifications are not good enough.Verstuurd vanaf mijn iPad I meant to write curious instead of anxious, stupid autocorrection of iPad. Bert Op 21 apr. 2013 om 00:00 heeft Bert Verhees bert.verhees at rosa.nl het volgende geschreven: I am very anxious to learn why the current XPath/XQuery-specifications are not good enough. ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130422/d8322bc0/attachment-0001.html
Openehr vs S3DB
Hi guys Just stumbled across this project http://www.s3db.org/ . Was wandering whether anyone has seen it before and maybe has already thought about its similarities/differences to openehr. Many goals (interoperability, distributed systems, explicit/separate domain models, collaborative, bottom up, ..) and some components and implementation ideas (query language, form generator) seem similar. Obviously S3DB has a different technology focus (semantic web: RDF, SPARQL,...) and origin (life science research/clinical trials). My quick assessment is that S3DB uses a more decentralized/loose/WWWish/adhoc paradigm whereas openehr tries to manage/govern it's central domain models (archetypes) a-priori in a flexible (through reusability, archetype vs template) yet controlled way (via CKM). IMO this difference is due to the different main target areas: clinical medicine (imprecision/wrong data can be lethal) vs translational research (some imprecision is irrelevant in large enough data sets). The following paragraph from one of the S3DB papers (http://europepmc.org/articles/PMC3071752) describes a similar circumstance when comparing S3DB with caBIG. 4.2. Combining approaches to query federation The cancer Biomedical Informatics Grid (caBIG?) is a project aimed at enabling the sharing of cancer-related data using a federated query model, whereby different institutions working on related problems can share data either by adapting their local repositories to a set of data models provided by caBIG or by adopting one of the caBIG applications [39]. The various data sources in caBIG can then be queried simultaneously using the caGrid query language [40]. The caBIG approach offers the advantage of facilitating query assembly because it relies on a set of common data structures; this approach is therefore indicated for knowledge fields that are very well established. The linked data approach [9] does not impose a data model before integration is possible; instead data can be integrated using SPARQL queries as soon as an RDF representation is available. Although the latter approach requires that datasets be linked through the use of common terminologies before the assembly of SPARQL queries, it is better suited for knowledge areas that evolve quickly as it benefits from having novel data immediately available for integration. The two approaches could therefore greatly benefit from each other; indeed, a call for Semantic Web opportunities has been launched by the caBIG community [41]. The semCDI [42] and Corvus [43] projects, for example, have already developed extensive work towards modeling and integrating the various data models available at caBIG including the availability of SPARQL engines. The architecture described in this report could thus be easily integrated with caBIG datasets that are made available as RDF or if a SPARQL endpoint is provided. Indeed, one of the steps in that direction was mapping the terms within TCGA S3DB representation to NCI Thesaurus, also widely used by the caBIG community [44,45]. Keen to hear your thoughts or otherwise just to spread an interesting link... Cheers, Thilo -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121112/a716cd51/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi everybody, I got permission to publish the MedInfo paper and its successor mentioned below. You can find it here (last row of table): http://www.openehr.org/wiki/display/resources/MedInfo+2007+-+Brisbane+Australia Cheers, Thilo After that Helma, her supervisor, Rong and I published a very future-oriented paperhttp://www.ncbi.nlm.nih.gov/pubmed/17911890?ordinalpos=1itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_RVDocSumabout sharing not only archetypes but also GUI artefacts. Helma later extended this idea in a chapter of her thesis and (re)publishedhttp://www.ncbi.nlm.nih.gov/pubmed/19368989it. I will ask her whether we can put the paper and her thesis on the wiki (maybe she reads this anyway... Hello Helma?). This is definitely far away from end-to-end applications and it is unclear whether it will ever be realisable but it still has some very interesting thoughts for our discussion. An extended version of Lisa's EhrView mechanismhttp://openehr.org/wiki/display/dev/openEHR+Composition+XML+to+HTMLwith a repository of XSLT-fragments is - IMO - something that could definitely be realised in the midterm to provide an enhanced read-only view of arbitrary openEHR information. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101213/e533c68a/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
of specifying another mechanism for GUI-concerns. You'd still get layers (if you sensibly use specialisation) but more flexible boundaries during the needed upcoming period of collaborative experimentation and real use. On Mon, Dec 6, 2010 at 22:06, Koray Atalag k.atalag at auckland.ac.nz wrote: I think having these discussions is a great start. But it'd be great if someone from the core group 'owns' this thread and puts some pressure on us. Koray, what makes you exclude yourself from the core group? Shouldn't openEHR be a community with peers trying to solve common problems, where people like you with specific implementation experience can help collaboratively lead a specific exploration tangents at least as well as some official core that is busy prioritizing other important explorations. Whatever that core is I believe it will be actively involved in, and appreciate, the discussions. You already own the problem together with others owning the same problem. I think openEHR should be a platform to facilitate collective ownership of problem solving processes and solutions. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/http://www.imt.liu.se/%7Eerisu/ Tel: +46-13-286733 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Thilo Schuler +61 404 030 143 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101211/6cb40e99/attachment.html
Playing with Open EHR-Gen
[Cave: X-post, please reply to the thread on the implementation list or even better edit the wiki page] Hey guys I started a wiki page about my first experiences with Pablo's framework Here is the link: http://www.openehr.org/wiki/display/impl/Playing+with+Pablo%27s+Open+EHR-Gen+Framework Feel free to participate. Cheers -thilo -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101203/3bd8cae9/attachment.html
new openEHR-based framework
Never mind Pablo After using my grey matter a bit it came to me that credentials must be in the bootstrap file et voila... found it. For anybody interested: this file can be found in grails-app/conf/BootStrap.groovy Tomorrow I will try to load my own little template. Cheers -thilo On Wed, Dec 1, 2010 at 11:42 PM, Thilo Schuler thilo.schuler at gmail.comwrote: Hi Pablo thanks for your answers. Good tip with Google translation, hadn't thought of it... I have your app running on my machine now. I can see the login screen. The hardest bit was to convince my macbook to use jdk 1.6 :)... Otherwise a breeze. I like grails! Could you please tell me a login and password I can use to get into your great application. Thanks a lot -thilo On Tue, Nov 30, 2010 at 12:47 PM, pablo pazos pazospablo at hotmail.comwrote: Hi Thilo, The current performance would make it cumbersome to use it in a productive environment, but it will be great as a prototyping and demonstrating tool. Clinicians can judge the value/completeness of archetypes and templates much better, if they see them as a working GUI. Your framework seems to be very suited for that. In fact I used the framework to show the archetype concept, something like archetypes in action. I will try to get a small template running locally on my computer sometime this week. I will report my experience back to the list. Maybe this helps to decide how the community can leverage your work.* * Great! let me know if you need some help. * * A couple of questions to start (Cave: Will possibly bug you with more questions in the process): - Does it matter what version of grails I use? Now it works only on Grails 1.1.1, you can read the installation page on the wiki: http://translate.google.com/translate?js=nprev=_thl=esie=UTF-8layout=2eotf=1sl=estl=enu=http%3A%2F%2Fcode.google.com%2Fp%2Fopen-ehr-gen-framework%2Fwiki%2FInstalacion You can use google traductor to translate the spanish pages and docs. - Can I use the in-memory DB HSQLDB for testing? Or should I set it up with MySQL. Yes, you can use HSQLDB, you can configure it in grails-app/conf/DataSource.groovy: http://code.google.com/p/open-ehr-gen-framework/source/browse/trunk/open-ehr-gen/grails-app/conf/DataSource.groovy, just uncomment this 2 lines: // dbCreate = create-drop // one of 'create', 'create-drop', 'update' // url = jdbc:hsqldb:mem:devDB and comment the MySQL config. - By looking at your proprietary templates it seems you determine a root archetype (usually of type SECTION) and the included archetypes (each is either fully included -- 'includeAll=true' or only a subset -- specified by one or several paths). Is this generally correct? Yes, it's correct. All the template roots are SECTION or ENTRY, and each EHR domain have only one COMPOSITION that record all the data for all it's templates. You can see in Config.groovy we have a trauma domain, an emergency domain, etc. We want to improve that to define multiple COMPOSITION templates to one domain. Cheers, Pablo. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Thilo Schuler +61 404 030 143 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101202/80e195b1/attachment.html
new openEHR-based framework
Hi Pablo thanks for your answers. Good tip with Google translation, hadn't thought of it... I have your app running on my machine now. I can see the login screen. The hardest bit was to convince my macbook to use jdk 1.6 :)... Otherwise a breeze. I like grails! Could you please tell me a login and password I can use to get into your great application. Thanks a lot -thilo On Tue, Nov 30, 2010 at 12:47 PM, pablo pazos pazospablo at hotmail.comwrote: Hi Thilo, The current performance would make it cumbersome to use it in a productive environment, but it will be great as a prototyping and demonstrating tool. Clinicians can judge the value/completeness of archetypes and templates much better, if they see them as a working GUI. Your framework seems to be very suited for that. In fact I used the framework to show the archetype concept, something like archetypes in action. I will try to get a small template running locally on my computer sometime this week. I will report my experience back to the list. Maybe this helps to decide how the community can leverage your work.* * Great! let me know if you need some help. * * A couple of questions to start (Cave: Will possibly bug you with more questions in the process): - Does it matter what version of grails I use? Now it works only on Grails 1.1.1, you can read the installation page on the wiki: http://translate.google.com/translate?js=nprev=_thl=esie=UTF-8layout=2eotf=1sl=estl=enu=http%3A%2F%2Fcode.google.com%2Fp%2Fopen-ehr-gen-framework%2Fwiki%2FInstalacion You can use google traductor to translate the spanish pages and docs. - Can I use the in-memory DB HSQLDB for testing? Or should I set it up with MySQL. Yes, you can use HSQLDB, you can configure it in grails-app/conf/DataSource.groovy: http://code.google.com/p/open-ehr-gen-framework/source/browse/trunk/open-ehr-gen/grails-app/conf/DataSource.groovy, just uncomment this 2 lines: // dbCreate = create-drop // one of 'create', 'create-drop', 'update' // url = jdbc:hsqldb:mem:devDB and comment the MySQL config. - By looking at your proprietary templates it seems you determine a root archetype (usually of type SECTION) and the included archetypes (each is either fully included -- 'includeAll=true' or only a subset -- specified by one or several paths). Is this generally correct? Yes, it's correct. All the template roots are SECTION or ENTRY, and each EHR domain have only one COMPOSITION that record all the data for all it's templates. You can see in Config.groovy we have a trauma domain, an emergency domain, etc. We want to improve that to define multiple COMPOSITION templates to one domain. Cheers, Pablo. ___ 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/20101201/17fe1f9a/attachment.html
new openEHR-based framework
Subject: Re: new openEHR-based framework From: rong.acode at gmail.com To: openehr-technical at openehr.org Hi Pablo, I was about to ask you to make a proper announcement on the list. Ian beat me on this ;-) Thanks for the excellent work and commitment to the open source community!! I will send you some specific questions later on. Cheers, Rong On 24 November 2010 16:20, pablo pazos pazospablo at hotmail.com wrote: Hi, I have send this same email to the last 21090 discussion, and Ian ask me if I can send it again in another thread, here it is. Just yto give some context, this was written in response to Koray who asks for real-world implementations, and who is studying the complexity/time of building openEHR-based systems. I should clarify that the framework is the core of the system, but not the whole system. The whole trauma application has also DICOM integration, external MPI integration via IHE PDQ, the generate CDA feature (we leave this on the framework too, but is not a part of the core), and the calculation of quality of care indicators. Ian ask me if I can publish the archetypes we use, archetypes, (our own) templates, the code, etc, are all here: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen Cheers, Pablo. Hi Koray, As an example of a real-world implementation, we have build an EHR for trauma care. Our project was developed in one year and four months. The core of the development is an openEHR-based framework, wich takes archetypes and our own templates (with GUI directives), and generate GUI, data binding with RM structures, validation of data against archetypes contraints, and persistence of the RM structures. BTW, this framework has been open sourced: http://code.google.com/p/open-ehr-gen-framework/(sorry docs in spanish only). I've estimated that this particular project without the openEHR overhead could be finished in 6 months. But if I have other project like this today (same size, same complexity, etc), I think we can finish the development en 3 months, using our openEHR-based framework. So, if we have 10 projects this are the numbers: * Without openEHR tools: total of 160 months (13.3 years) * With openEHR tools: total of 56 months (16 months for the first development, 4 months for the rest 9 projects, that's 4,7 years!!!) If we can improve the tools, these times could be improved, and the final solutions have the advantage of separating the knowledge from the software, and we can share and reuse archetypes between diferent projects, that's just great! :D Hope this experience can help you. - -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos ___ 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Thilo Schuler +61 406 113 740 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101129/60bc63e0/attachment.html
new openEHR-based framework
Hey Pablo Thanks for your reply. I have more questions (see inline), partly because I don't speak Spanish. We have some things in common. I have a small project called miniClin, in wich I defined CDA templates based in the CDA structure, and ideas borrowed from openEHR archetypes (like node codes, paths and node occurrences). I've developed a small proof of concept PHP/MySQL app that worked fine (with limitations), and I use the Yupp PHP Framework to build this app (Yupp is an MVC/ORM framework with some ideas borrowed from Grails framework, I developed). Now miniClin is just a paper (sorry, spanish only). In miniClin, the GUI is generated from these CDA templates, the data binder create CDA documents in memory from the template and the data, and a seralizer create the CDA XML file on disk from the memory structure (this project has a lot in common with the EHR-Gen Framework). Some links: - http://code.google.com/p/miniclin/downloads/list - http://code.google.com/p/yupp/ Amazing that you can do all this work in parallel! What made you create a MVC/ORM framework (YUPP) similar to Grails instead of just using Grails (as you did in your open-EHR-Gen framework). What are the benefits besides that you don't need a servlet container to run it? Do you have a link to such a CDA template (enhanced with some openEHR ideas) somewhere? How do o-EHR-Gen and miniclin compare regarding their uses? When do you use one when the other? Is miniclin - as its name suggests - aimed at smaller, more at hoc clinical form based applications? Yes, the DB schema is autogenerated from the domain model classes, so the schema is very generic and doesn't change if you add new archetypes or templates to your app. This generic approach obviously has a side effect on performace, but is also a boost on development time. How long do load and save operations take? Our big goal is to build a tools chain, so anyone can define some archetypes, add them in a template, deploy the archetypes and templates into the Open EHR-Gen Framework, and you will have a complete application for clinical recording. Over this application, anyone can build their own plugins, so you can add integration with other systems, conversion to/from other information models, etc. Sounds fantastic. An exactly what the openEHR community needs to be able to easily demonstrate archetypes in action. How much adaption would it involve get the open-EHR-gen framework running on my computer with another template? I didn't say this before, but this project could never be done without the re-use of Rong's work. The base of all are the AOM implementaion and the ADL-parser from the java-ref-impl. You can see what libs we reuse here: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen/lib I know about Rong's monumental contributions towards openEHR. I will keep in touch -Thilo -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101129/27379d02/attachment.html
Meaningful use criteria
___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Thilo Schuler Morgenrainstrasse 9 CH-8620 Wetzikon Festnetz: +41 (0) 43 49 707 85 Mobil: +41 (0) 79 547 76 48 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100117/9e447fe4/attachment.html
informal poll: openEHR conference
://www.bcs.org.uk/ Health IT bloghttp://www.wolandscat.net/ ___ 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 -- Thilo Schuler Morgenrainstrasse 9 CH-8620 Wetzikon Festnetz: +41 (0) 43 49 707 85 Mobil: +41 (0) 79 547 76 48
Differential display
Hi Dipak, I have quickly looked at EN13606-1 (a draft form 2.10.2006). Could you explain a bit further how it deals with the mix of flexible textual and structured information. Especially in the use case when textual representations are generated from structured input and secondarily changed (contradiction!). Thilo On Tue, Aug 19, 2008 at 3:02 PM, Dipak Kalra d.kalra at chime.ucl.ac.ukwrote: Dear All, If we are to take forward this important area we must first confirm the requirements. These are not clear from the discussion so far. A detailed consideration of this topic took place during the development of EN13606-1, including examination of CDA R2's approach. You might therefore wish to review Part 1 in taking forward this topic. I would be interested to learn of relevant requirements that this does not meet. With best wishes, Dipak Dr Dipak Kalra Clinical Senior Lecturer in Health Informatics CHIME, University College London Holborn Union Building, Highgate Hill, London N19 5LW Phone: +44-20-7288-5966 Fax: +44-20-7288-3322 Study Health Informatics - Modular Postgraduate Degree http://www.chime.ucl.ac.uk/study-health-informatics On 19 Aug 2008, at 01:05, Heath Frankel wrote: Actually the use case is as follows: As part of a clinical encounter the practitioner authors a textual clinical note to be included along with structured content. BP is entered in a structured form and the system copies the result into the textural clinical note automatically as is done in a lot of existing clinical systems (which are traditional primarily texturally oriented, with a little bit of structured data). So the textual clinical note contains a combination of manually entered content and system generated content from structure content, the user has the ability to edit and remove the auto generated content which may deviate from the original content entered in a structured manner. Therefore, the textual note and the structured data need to both be viewable because there is no way of knowing what structured content was duplicated in the textual note and what original content was manually entered in the textual note. Once the structured content is copied into the textual note, it has lost its connection with the original content. This may not seem idealistic but this the reality of what existing systems do and existing users are used to. If openEHR is to be taken up by existing system vendors and accepted by their users, we must support this existing non-idealistic paradigm in a way that does not too much overhead on the system and its implementers. I would suggest that duplication of data is better than accidently hiding data, especially when the users are used to having two ways of displaying the same data. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr- technical- bounces at openehr.org] On Behalf Of Thomas Beale Sent: Tuesday, 19 August 2008 7:59 AM To: For openEHR technical discussions Subject: Re: Differential display I won't contribute much to this discussion, except to say that the 'problem' here is /duplication/ of information - that is, the same information occurring in a document or being created in a system in two different ways, usually narrative and structured, but not always this combination. CDA is always constructed of narrative, with optional structured content which in theory duplicates the narrative content, or may be a subset of it. The problem for clinicians therefore is to get rid of the duplicate stuff for display. So the need to display or not is a consequence of the duplication which is the underlying problem. Perhaps a better name for the 2 parts would be 'primary' and 'duplicate' or 'alternative rendition' or similar. - thomas Thilo Schuler wrote: Hi everybody I know CDA which requires *all* information to be in human-readable, textual form (Level 1). Optionally there can be references to machine-readable entries (Level 3). This design makes sure no information is disclosed from a clinician that views the document only with as simple XSLT-transformed XHTML. I must admit I didn't quite understand the use case. snip This does mimic the CDA approach but does have the added benefit that the displayed information can be structured as well (a requirement from our customers who want to mix the textural content and structured medication orders (ie not duplicate these in the textural display). snip Maybe you could explain it a bit further. But in general I feel - probably similar to Ian and Gerard - it is not a good idea to bring view-related stuff into an archetype. Thus, I wouldn't call it display and non-display. However, think
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Hi all, As some of you know I am interested in XForms and would love to be part of this community effort if and when it starts. Currently I am co-supervising two thesis students working on a project the uses XForms, Grails, and IBM DB2 similar to this http://www.ibm.com/developerworks/xml/library/x-xformsruby1/index.html (but Grails instead of Rails). The goal of the project is to have a generic form-based documentation framework for medical data. Obviously in the longterm I have openEHR data in mind. I don't think we will get as far as auto-generating XForms GUIs for openEHR data, but I hope we can hand-code a XForms GUI for the chronic wound use case I have been building several archetypes and one template for. To speed up the XForms hand-coding I plan to use the IBM XForms Generator (http://www.alphaworks.ibm.com/tech/xfg) to scaffold an initial form, which obviously needs to be customised a lot to respresent as many of the archetype and template constraints as possible. After submission of the instance it will be additionally checked against the whole template data schema (TDS) on the server-side. I did a first test of this generator. For more details look on the wiki: http://www.openehr.org/wiki/display/dev/IBM+XForms+Generator+Test Cheers, Thilo On Mon, Jun 30, 2008 at 5:42 AM, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Thilo, It is interesting you have talked about the idea of scaffolding a GUI. This is exactly the work Ocean is doing at present. We have redeveloped our Web Forms engine to work based on this principle. From a template developed using the Ocean template Designer, we now generate a Form Definition file based on that template using a basic (and modifiable) presentation transformation. This assumes nothing about layout and only specifies the existence of controls within groups and incorporate the AOM constraints for the corresponding data bound object from the reference model. This gives forms engine all the information it needs to generate a basic form at runtime straight from a template. The advantage of having this form definition over simply creating a form straight from the template/archetype as demonstrated by Greg is that we can use the same artefact to customise the layout of the form using an editor. The forms engine can then process both designed (after initial scaffolding) and auto-generated forms as required. The Forms Definition format we are currently using is proprietary, but I would be interested give some time and reason to see how we can import/export into a standard format such as XForms. However, I am sceptical about the use of XForms unless we utilise extensions significantly otherwise we lose way too much information available in the AOM constraints. Heath
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
if there is a lack of space. (I.e. using a detail level mechanism) - Mechanisms like hide_in_ui to skip intermediate things that are meaningful in information modelling but are distracting or unnecessary in a GUI. As you can see these things have a bit of a semantic touch also, but maybe a different kind of semantics than we usually refer to as semantics in this community. When it comes to template design it would be interesting to know if the clinicians always are comfortable only having the on/off (set zero occurrence) of templates (or are there more restrictions available)? Don't you get a lot of it depends-answers whether to include something in a template or not? Do you believe that answers what to kill from (for the use case) overly detailed archetypes templates would be different if the clinicians are aware of the possibilities to change priorities, set conditional statements etc? I don't suggest that these hints necessarily should be created simultaneously with the template editing, but I guess that the very same clinical experts that design the template would be also good candidates to give some GUI-hints after the template creation. Thoughts? When it comes to what I call GUI-hints above I believe it would be useful to specify a model (like the with the AM) and one or many serialization formats of it rather than going straight for a markup language. Artifacts built using that model could then be used for auto generation of GUIs (whenever that is necessary) and as input to other steps specifying things more to the right in the spectrum like dealing with specific widgets, component positioning etc. for example as more intelligent scaffolding in manual editing environments than pure templates would be. More towards that right side one of the ways could be to go for markup-things such as xforms. To dig deper into such a more specific layer at the same time as researching a more general GUI-hint-layer might be a good idea. (I guess the interrelated AM and RM have been researched simultaneously for example in order to find good boundaries...) On Fri, Jun 27, 2008 at 11:30, Sebastian Garde sebastian.garde at oceaninformatics.com wrote: ii) However, it is important to keep this separate from templates. For example, to be able to display what is in a template on different devices ranging from normal to computers via PDAs to potentially your mobile phone, different GUI principles may apply. So essentially to me this sound like it is 1 template to n GUI layout descriptions. The 1 template to n GUI-hint-artifacts principle seems reasonable. (A side note regarding different GUI principles: it would be interesting to see if/how the GUI-semantic hints like the ones above could map to different principles/paradigms) On Sat, Jun 28, 2008 at 13:38, Thilo Schuler thilo.schuler at gmail.com wrote: I am with you on that layers are important and keep the approach more simple in the long time. Yes. On Sat, Jun 28, 2008 at 13:38, Thilo Schuler thilo.schuler at gmail.com wrote: Regarding Greg's comment on problems with the visibility of a certain field: IMHO openEHR should not try to standardise GUIs (meaning sharing GUI hints or presentation artefacts). This is a huge task and we have enough problems solving what we are working on right now. The value of what to start experiments regarding how to standardise right now depends on what one happens to be working on right now :-) I don't suggest that for example Ocean Informatics would need to be pioneering everything if they have other important things to focus on. I do believe that there right now might be an interesting time for some of us in the community to start investigating the possibilities to share some kind(s) of artifacts assisting in GUI creation and maintenance across system implementations. Something that makes this task less huge than it would be in a general software setting is that we're dealing with a fixed AM and RM and a specific application area. Great post Erik. Don't get me wrong, I would love to have standardised rightish artifacts and you argumented well regarding their advantages. The reson I was sceptical is that if we want to solve too many things generically it gets very complicated and not much will happen at all. Therefore your suggestion: fixed RM and AM plus a specific (relatively small) application area or set of use cases is a good simplified starting point. -Thilo One last thing... On Sat, Jun 28, 2008 at 00:18, Thomas Beale thomas.beale at oceaninformatics.com wrote: ... there are more semantic indicators being built into the template designer, some based on the NHS CUI project, that will provide good hints on GUI generation, including some temporal workflow aspects. Are these things or the principles behind them something you can and would like to like detail a bit more or share with the community when time permits? Best regards, Erik Sundvall
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
The advantage of deriving generic user interfaces only from data instances and the underlying archetypes (without knowing the template) is the possibility to edit unknown openEHR data, although the GUI would be simple. Thus, I agree with Chunlan on the position of a generic GUIs on Erik's spectrum. -Thilo On Tue, Jul 1, 2008 at 2:14 AM, Chunlan Ma chunlan.ma at oceaninformatics.com wrote: The Generic User Interfaces, i.e. the GUI_hints that are a bit more towards the left side of the spectrum described by Eric Sundvall, would be archetype specific rather than template specific. I personally think these generic GUI-hints should be processed by a generic form engine that understands archetypes only. For example, if tobacco use status value is Never used, which is local coded text in the substance_use archetype, the Method cluster can be hidden from the form. This generic GUI_hint can be applied to all templates or user interfaces. A more specific form engine is required for context specific user interfaces. Cheers, Chunlan From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Gerard Freriks Sent: Monday, June 30, 2008 11:32 PM To: erisu at imt.liu.se; For openEHR technical discussions Subject: Re: GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts)) My spectrum: - Archetypes (generic documentation patterns) - Templates (context dependent documentation patterns) - Generic User Interfaces (generic presentation patterns) - User Interface (context dependent presentation patterns) Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On Jun 30, 2008, at 3:19 PM, Erik Sundvall wrote: Hi! Thanks for a lot of interesting response regarding GUI-hints and other things. Please excuse a little left-to-right analogy below: There seems too be a scale or spectrum of detail level and use case specificity going from... Left: purely semantic (maximum data set) models = archetypes ...via the nearby... openEHR templates (still purely semantic if we skip the hide_in_ui to keep the template artifacts) ...further far away to... Right: actual GUI in an implemented system with specific widgets positioning etc Currently openEHR specifications describe artifacts at the left side of the spectrum. This discussion has interestingly been broadened further to the right than I was thinking of in my initial questions. If we look at a tool like the Template Designer from Ocean Informatics there is an immediate jump from templates (close to the left) to detailed GUI layout (far right), that jump could be divided into more steps (possibly with some steps persisted and reusable) as suggested by some in this discussion. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
I am with you on that layers are important and keep the approach more simple in the long time. As Heather pointed out, we have to be very careful not to distract the clinicians with GUI fluff from clean modelling. But for review and testing there is no doubt, that a real GUI is of value. At the moment the Ocean Template Desinger does both using the one tool, two artefacts approach, and as Thomas wrote it will become better based on the NHS CUI project. The one tool, two artefacts approach is good as it lets clinicians build and adapt runnable GUIs from their authored templates, but also shows that there can be many possible GUIs created from one template. Having a set of core template tags and several extensions (for GUI/message/... hints) is more a technical design choice for better manageability and doesn't interfere with the layers (separation is done via namespaces). Templates are mostly local artefacts and GUIs even more so. So, as Rong said, theses markup-extensions will only be there to ease local implementation. E.g. Ocean could have used such an extension to create the previously mentioned Hide_in_GUI-Hint in a clean way separated from the core template model. Regarding Greg's comment on problems with the visibility of a certain field: IMHO openEHR should not try to standardise GUIs (meaning sharing GUI hints or presentation artefacts). This is a huge task and we have enough problems solving what we are working on right now. But I can picture a system that scaffolds a basic editable GUI based on unknown openEHR data (provided it has access to the underlying archetypes). This scaffolded view could then be adapted by the local user, and the next time this user tries to access similar openEHR data (meaning same archetypes in the same structure/order) the local system remembers it and the customised view is used to display and edit the data. Customisation could even go as far as choosing certain GUI components (per archetype or per aggregated archetypes) from a (shared!) library... But this is still all implementation specific and not part of the openEHR specs. Cheers, Thilo On Fri, Jun 27, 2008 at 6:46 PM, Tim Cook timothywayne.cook at gmail.com wrote: On Fri, 2008-06-27 at 14:42 +0200, Thilo Schuler wrote: Very interesting - maybe we could have seperate namespaces for the core tags and extensions. Could be a good compromise! While I see the advantages of keeping GUI stuff out of the template, I also see that this more and more complicated as we add additional abstraction layers. Ahhh, true. It is complicated. It is the reason why health informatics is where it is today. The beauty of the openEHR specs is that each portion does one thing well and yet all the parts fit together. If we get carried away and start mixing the layers then the specs get more complex, the tools more difficult to use, applications less likely to inter-operate and there won't be very many implementations. sarcasm If you aren't careful you could end up with something HL7v3. /sarcasm As my buddy Albert E. said; Make everything as simple as possible but no simpler. ;-) --Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Would also want GUI things like hide_in_GUI to be in a separate artifact on top of a template. It is good to hear that Ocean only did that as quick fix to meet customers requirements, which is very plausible. As mentioned before templates are great to initially SCAFFOLD a GUI, which has to be further adapted by humans for the best possible usability results (use-case and device specific). This allows verification of the templates and archetypes from a user point of view and is very important as Richard pointed out. I can understand Josinas comments about clinicians not caring about the difference between semantics and GUI stuff, so a tool like the Template Designer should hide this important separation, where appropriate. Thilo On Fri, Jun 27, 2008 at 10:03 AM, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Erik Personally, I don't think that templates should contain GUI rendering hints as they should remain purely about the semantics. There are others that don't agree with me. The hide on form function in the Template designer was partly to meet requirements for documentation of the templates for some groups using this technology. I am not sure if the hide_in_ui parameter is going to make it into the final template spec - Tom will have something to say about that. Personally, I think that there should be some other artifact that details GUI specs - if we mix up the two things, then the purpose of the template becomes confused. Templates can be used for everything from GUI, to data instance, persistance and query. If we add a whole lot of parameters around GUI, then we will also probably need to add specific things for these other uses and it might get very messy. regards Hugh Erik Sundvall wrote: Hi! On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: Thanks to the java reference implementation I have a demo of importing archetypes to auto generate forms which have the references to the archetype. Nice. Keep up the good work. On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: One thing I noticed in the conversion that I don't have any way of distinguishing between a line of text and multiline text in the archetype (I would generate an appropriate pane in the latter case). Perhaps not a big deal. This might be a useful requirement for the current template specification currently being worked on, or possibly a new kind of related specification. I first thought that templates so far had been considered as purely specifying semantics and that they were not supposed to give hints regarding GUI rendering. But now I see a parameter hide_in_ui in the class T_COMPLEX_OBJECT found in the draft template specification. (A similar function is present in the Template Designer tool from Ocean Informatics there is an option to hide elements instead of constraining them to zero occurrence, in the output file this is persisted as hide_on_form=true.) Could anybody detail it's intended use a bit more? I think GUI rendering hints can be appropriate to specify at the same point in time as template design is taking place. If the hints are to be persisted in the template file or in a separate file I guess could be discussed, keeping it in the file could have maintenance advantages, but probably has some disadvantages too. Thoughts? (And no, GUI hints are not appropriate in Archetypes since they are meant to have a wider reuse and the use cases are not known in the same detail as for templates.) In some of our implementation experiments and in discussions with clinicians a possible need for specifying detail levels in templates have surfaced. Some elements from archetypes are easy to completely dismiss or include for the specific use case in mind when designing a template clinicians will say things like this will always be needed or this will never be needed. Other things could be conditional and trickier you can't have all these details om the form - users would go crazy - let them show up if i click a plus-button or if i tick value x was true. The requirement to use GUI screen area optimally is even more pressing when using small input devices such as PDAs. If there was some way of specifying detail level in the template perhaps using a simple integer (0=default, 1..n=deeper detail with increasing number) then the same template could better support automated or semi-automated design of entry forms different screen sizes etc. One naive/simple but useful way of using the integer could be to add a plus-button for things with detail level 1 and within that subform have further plus buttons for level 2 and so on. The conditional requirements are trickier and probably needs more experimentation and evaluation than can be allowed if a first template specification should be completed and released within reasonable time (we all want that). The conditions might also in some cases
GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))
Very interesting - maybe we could have seperate namespaces for the core tags and extensions. Could be a good compromise! While I see the advantages of keeping GUI stuff out of the template, I also see that this more and more complicated as we add additional abstraction layers. On Fri, Jun 27, 2008 at 2:26 PM, Rong Chen rong.acode at gmail.com wrote: Hi all, My thoughts on this is so far our experience with templates are mostly related to screen forms and GUI widgets. It's probably easiest to relate to screens when engage clinicians for templates reviewing, hence the need for visual presentation of templates from the NHS work. We also want to reuse the semantics in templates to generate messages, reports etc. The question is how much 'generic' semantics can be reused from the templates built for specific purpose - screen templates, message templates and report templates. Surely the content for all types of templates will be quite different and we probably would like to have special syntax to support GUI hints, but do we need special syntax to support other uses? How about indicators for decision support, clinical research data and information lifecycle management? I am thinking about an extendable markup language that can be plugged into the core template language as a way to add extensions to templates if there is any application specific meta-data required. I am also in favour of the idea to store these extra meta-data inside the templates to ease the maintenance. When passing these templates around, the template engines can ignore the extended markup and only process the standard part if they don't recognize the extended syntax. Something like gui_markup_plugin hide_in_GUI path=.../ hide_in_GUI path=.../ /gui_markup_plugin Cheers, Rong On Fri, Jun 27, 2008 at 12:30 PM, Thilo Schuler thilo.schuler at gmail.com wrote: Would also want GUI things like hide_in_GUI to be in a separate artifact on top of a template. It is good to hear that Ocean only did that as quick fix to meet customers requirements, which is very plausible. As mentioned before templates are great to initially SCAFFOLD a GUI, which has to be further adapted by humans for the best possible usability results (use-case and device specific). This allows verification of the templates and archetypes from a user point of view and is very important as Richard pointed out. I can understand Josinas comments about clinicians not caring about the difference between semantics and GUI stuff, so a tool like the Template Designer should hide this important separation, where appropriate. Thilo On Fri, Jun 27, 2008 at 10:03 AM, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Erik Personally, I don't think that templates should contain GUI rendering hints as they should remain purely about the semantics. There are others that don't agree with me. The hide on form function in the Template designer was partly to meet requirements for documentation of the templates for some groups using this technology. I am not sure if the hide_in_ui parameter is going to make it into the final template spec - Tom will have something to say about that. Personally, I think that there should be some other artifact that details GUI specs - if we mix up the two things, then the purpose of the template becomes confused. Templates can be used for everything from GUI, to data instance, persistance and query. If we add a whole lot of parameters around GUI, then we will also probably need to add specific things for these other uses and it might get very messy. regards Hugh Erik Sundvall wrote: Hi! On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: Thanks to the java reference implementation I have a demo of importing archetypes to auto generate forms which have the references to the archetype. Nice. Keep up the good work. On Fri, Jun 27, 2008 at 07:08, Greg Caulton caultonpos at gmail.com wrote: One thing I noticed in the conversion that I don't have any way of distinguishing between a line of text and multiline text in the archetype (I would generate an appropriate pane in the latter case). Perhaps not a big deal. This might be a useful requirement for the current template specification currently being worked on, or possibly a new kind of related specification. I first thought that templates so far had been considered as purely specifying semantics and that they were not supposed to give hints regarding GUI rendering. But now I see a parameter hide_in_ui in the class T_COMPLEX_OBJECT found in the draft template specification. (A similar function is present in the Template Designer tool from Ocean Informatics there is an option to hide elements instead of constraining them to zero occurrence, in the output file this is persisted as hide_on_form=true
Question on the role of EHR reference models for achieving functional interoperability
Hi Georg, I agree with your argument. Distinguishing advanced functional interoperability from PDF like functional interoperability is helpful as the information can be presented in a more or less customised way leveraging the underlying RM classes - Ocean's EHRview (https://wiki.oceaninformatics.com/confluence/display/ocean/EhrView+Demonstration - unfortunately currently unavailable) is an example for such a generic display mechanism. Obviously if the archetypes are known as well more sophisticated customization is possible. Every clinical information system could implement a similar mechanism to display openEHR data (even without archetypes) more or less adapted to their environment. However, this is only helpful for read-only interfaces. To be able to edit the data the archetypes have to be known! Cheers, Thilo On Tue, Jun 24, 2008 at 12:16 PM, Georg Duftschmid georg.duftschmid at meduniwien.ac.at wrote: Dear all, I would like to ask you for your opinion on a statement in ISO/DTR 20514 (Definition, scope and context of the EHR), which says that [...] a standardised EHR reference model is required for achieving functional interoperability [...] (page 7 of ISO 20514). Functional interoperability is defined as the ability of two or more systems to exchange information (so that it is human readable by the receiver). I am now wondering why an EHR reference model is seen to be REQUIRED for achieving functional interoperability. If I exchange bare PDF-documents (without any describing metadata) between two EHR systems, then I would say there is a good chance that these docs are readable by a human receiver and thus functional interoperability should be achieved although clearly an EHR reference model is not used. I agree that an EHR reference model alone is not enough to achieve semantic interoperability (agreed archetypes and terminology are missing) and therefore by using an EHR reference model alone one can still only achieve functional interoperability. However, this seems to me as some kind of advanced functional interoperability, where the receiving EHR system knows the basic components (the RM classes and their attributes) from which EHR information is composed. So I have the impression that an EHR reference model helps to achieve some kind of advanced functional interoperability, but I would not say that it is REQUIRED to achieve functional interoperability (refering to the PDF-exchange as a counter-example). What do you think? Thank you for any comments and best regards, Georg ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
Hi Hugh and Gerard, I very much agree that snomed coding should only be done where it adds value. Since archetypes provide meaning themselves not everything has to be coded (as opposed to HL7 that relies more on external codes). Although for export to non-openEHR formats (or data-mining on openEHR *and* non-EHR data) it could still be useful. But since finding suitable codes can be very tough, such gimmick coding will probably rarely happen in the first instance. Using codes to reduce the number of archetypes is a very valuable use case. Having a generic archetype as a recording pattern (e.g. lab archetype) and using codes to specify the actual analyte makes sense. As mentioned before templates should be used to aggregate these archetypes in a specific testing 'battery'. Looking at the openEHR archetype repository, there is a generic lab archetype and several specialiced ones based on it. However, it seems to me that the specialisations were done mainly to create battery type lab results structures (e.g. laboratory-liver_function) I think keeping the lab archetype to one analyte and aggregating them in a template would be cleaner and better from a query perspective. Specialisations of the generic lab archetype should only be used to add a field that is missing for an unkonventinal lab test. What do you think? Again, I would like to point you to the terminology use case section in the openEHR wiki: http://www.openehr.org/wiki/display/healthmod/Archetypes+and+Terminology#ArchetypesandTerminology-Usecasesforterminologyreferencesinarchetypes Lets fill this use case list in a *collaborative* manner. It is better to have our thoughts in a permanent spot (wiki) than only in a mailing list thread where they get burried and forgotten after a while. No hesitation, add/rearrange etc as you please ... everything is versioned so nothing gets lost! Hugh, could you add the fewer archetypes use case please. Cheers, Thilo On Fri, Jun 13, 2008 at 10:53 AM, Gerard Freriks gfrer at luna.nl wrote: Hi, The way I like to think about it is that there is a generic archetype for lab-tests as a recurring 'pattern'. Each individual lab test procedure is a code from a general coding system. The way Lab-test are reported (quantitative data, in what units of measurement, precision, normal value ranges, semi quantitative data, in what ordinal scale ,etc, etc) will be 'codes' as well, but this time from the Laboratory Resource Description System. The 'patterns' will probably be a special type of Archetype that is of the cluster nature. Batteries have Template nature. Gerard On 13, Jun, 2008, at 6:11 , Hugh Leslie wrote: Hi Daniel I was just using that as an example where its not always useful to code everything. I certainly wasn't trying to say that its not useful to code anything and the example that you give is where it is useful to code. I was just pushing back against those that want to code everything as I believe that we need to code those things that make sense. In terms of battery archetypes, thats another problem because batterys tend to vary between labs (certainly here in Australia anyway.) I would expect that it might be templates that solve this problem with the archetype providing something more generic. Coding of the analytes would then make sense so that you can compare different result sets. This could be also solved by producing archetypes for each analyte and then reusing them for different batteries. This would then mean that P-ALAT is the same archetype where ever it is used. Personally, I think the coded solution is better here as we would have fewer archetypes to manage. regards Hugh -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
Hi Daniel, Hugh et al. A couple of weeks ago I started a section on the wiki to collect use cases for terminology mappings from archetypes: http://www.openehr.org/wiki/display/healthmod/Archetypes+and+Terminology#ArchetypesandTerminology-Usecasesforterminologyreferencesinarchetypes IMHO this is a very important topic and it would be good if the people following this thread could use it to share their ideas in the wiki. Cheers, Thilo On Tue, Jun 10, 2008 at 3:52 PM, Daniel Karlsson daniel.karlsson at imt.liu.se wrote: Hugh, The argument comes when you say that every data point in an archetype needs to be coded and here there are arguments both ways. I would say that it is unnecessary to code every data point. There is little benefit for instance in coding sitting, lying, standing, reclining n a blood pressure archetype. The archetype contrains the value of position to these four values. The values are in context and their meaning is clear to anyone using this archetype. Translation is much easier as the archetype gives an absolute context for the meaning of the term. Coding these terms in SNOMED would be so that you can query your health record for every standing item? Its pretty unlikely that this would be a useful requirement. Coding everything s going to be a very slow and enormously expensive process to get right. It makes translation of archetypes much more difficult, especially for those many countries that don't (yet) have a SNOMED translation. Building archetypes is proving to be a very rapid and useful process. I think that there can be more reasons for binding archetype nodes to external terminologies apart from information re-use requirements in the query for everything standing example, e.g. to be able to express that standing in one archetype has the same meaning as standing in another archetype. Also, I didn't realise that I said that everything necessarily should be coded. Referring to David Markwell's report, he states (more or less) that things in the grey zone should be represented redundantly but he also states that terminology binding requirements should be driven by information re-use requirements. I agree with him on both points. /Daniel ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
Yes, agree on the querying ... and for querying we need structured content! As Sam and I noticed before this has to be considered when designing archetypes. This doesn't mean there shouldn't be free-text fields, this is a very valid requirement in clinical medicine! Thus, when designing archtypes the art is to find the balance between free-text (max. flexibility) and structured content. In my mind we often have to offer *both* in an archetype. If I want to create a local application with lots of DSS I create a template that uses mostly the structured parts of the archetype. If I want maximum freedom I use mostly the free-text parts. Another scenario is that I receive information from another archetype-enabled system: The receiving system doesn't know whether the sending system had used the archtype in a flexible (free-text) or in a structured way. To allow the receiving system to decide whether it can use DSS with this information I see two options: 1) We have a root archetype that optionally offers both (free-text and structured) and we specialise a DSS optimised archetype from it. So only if the DSS optimised archetype was used, much DSS is can be offered. 2) Or we create generic archetype design patterns with switch-like constructs (i.e. if this option option was chosen I can rely on these other attributes to be available as well) so the receiving system's DSS engine can do a kind of archetype-introspection to decide what it can use and what not. Just early thoughts. What do others think? On Mon, Jun 2, 2008 at 9:55 AM, Heath Frankel heath.frankel at oceaninformatics.com wrote: Thilo, I think the key thing that needs to be considered in Archetype design to support Decision Support is querying. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Thilo Schuler Sent: Saturday, 31 May 2008 8:13 PM To: timothywayne.cook at gmail.com; For openEHR technical discussions Subject: Re: Decision Support was: MIE-2008 I am also interested. I wonder how much decision support has to be considered when designing archetypes. In the near and midterm future decision support will probably mostly happen on a local (i.e. template) level, but I still assume that there should be design patterns of the underlying archetypes that make local decision support feasible. -Thilo On Sat, May 31, 2008 at 1:38 AM, Tim Cook timothywayne.cook at gmail.com wrote: On Fri, 2008-05-30 at 15:19 +0100, Sam Heard wrote: I wonder if we should have a particular list for people who are interested in working with openEHR from a decision support point of view. This may not be appropriate just yet but I believe it will generate a considerably different intellectual space. I wonder what others think? I am certainly interested. It is the core of my interest semantic information management in healthcare and my primary driver for being involved in the EGADSS project http://egadss.sourceforge.net/ Though I was out voted by HL7v3 and Arden Syntax MLM proponents so I left the project. -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** ___ 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
I am also interested. I wonder how much decision support has to be considered when designing archetypes. In the near and midterm future decision support will probably mostly happen on a local (i.e. template) level, but I still assume that there should be design patterns of the underlying archetypes that make local decision support feasible. -Thilo On Sat, May 31, 2008 at 1:38 AM, Tim Cook timothywayne.cook at gmail.com wrote: On Fri, 2008-05-30 at 15:19 +0100, Sam Heard wrote: I wonder if we should have a particular list for people who are interested in working with openEHR from a decision support point of view. This may not be appropriate just yet but I believe it will generate a considerably different intellectual space. I wonder what others think? I am certainly interested. It is the core of my interest semantic information management in healthcare and my primary driver for being involved in the EGADSS project http://egadss.sourceforge.net/ Though I was out voted by HL7v3 and Arden Syntax MLM proponents so I left the project. -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
MIE-2008
I like the wiki idea. We need to start using the wiki more. If everybody (in this case the authors) contributes, we will have more and better content and Thomas can concentrate on other important things. Cheers, Thilo On Fri, May 30, 2008 at 11:48 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: Lisa Thurston wrote: Andrew Patterson wrote: Actually, is it possible to have a conferences page on the wiki that is a bit of a one-stop shop for documenting openEHR related contributions to conferences. Somewhere where authors could attach their presentations from last years Medinfo, the MIE 2008 etc - and maybe also lists of future conferences of interest to openEHR folks. I know I can create pages myself on the wiki but I'm still a bit unsure where things are supposed to go in the wiki tree. Andrew, I think this is a really good idea. A link from the homepage or static part of the website into a place on the wiki where users can upload papers and continue the discussion has potential as both a reference and a way to provide feedback and/or engage in discussion on each paper in one location. *I am fine with that - I don't think we had the wiki running when we did the MedInfo pages. Probably we should move that to the wiki as well and make a small web page. How do others feel about this. Note, if we go this way, I am likely to leav it up to conference paper-writers to put their own entries up in the relevant pages! Can we have reactions from a few more people - if the response is positive, I will organise the conference material onto the wiki. - thomas beale * ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Dates and times in an Observation...
Hi Bruno From my point of view your example is completely right. The composition context refers to the setting (encounter etc) when the information was recorded, but the recorded information (eg observation) could have happened before. Good to see you are still interested in openEHR. If I remember correctly, we quickly met in the Belgian Beer Cafe in Brisbane. I am currently at MIE in Goeborg and openEHR archetypes have been mentioned a lot! Cheers, Thilo On Wed, May 28, 2008 at 2:04 PM, Bruno Cadonna cadonna at inf.unibz.it wrote: Hi all, I have a question regarding dates and times in openehr. I read the section Time in the EHR on page 29 of the document The openEHR Reference Model - EHR Information Model. As far as I understood it, OBSERVATION.data.origin and OBSERVATION.data.event[x].time must not necessarily be within the interval COMPOSITION.context.start_time and COMPOSITION.context.end_time or after COMPOSITION.context.start_time. Is this right? An example: A blood pressure measured by a patient on 2008-01-01 (-MM-DD) and reported to her physician on 2008-01-02 during an encounter, would have as COMPOSITION.context.start_time the date 2008-01-02 and as OBSERVATION.data.origin as well as OBSERVATION.data.event[x].time the date 2008-01-01. For the sake of simplicity I omitted the time within the dates. Kind Regards Bruno ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Constant Values and sub Elements
On Mon, May 5, 2008 at 1:56 PM, Timmy K timmyx at gmail.com wrote:
Thanks Thilo,
although this might not be worth it, i will try to model a generic element
as cluster-archetype.
you can try it, but I think in this case it is more complex (takes
longer) and doesn't have added value. Also the archetype editor
currently can't view assembled structures (templates).
also i dont quite understand what you meant with
model the 'spoken default' explicitly with a text ELEMENT that is
preset to the constant value.
how would i do that if i wanted to add a spoken default field to a date
field?
similar to what I send you before just a date element in the cluster
thanks in advance
Timmy
On Mon, May 5, 2008 at 12:36 PM, Thilo Schuler thilo.schuler at gmail.com
wrote:
Timmy,
I guess in your case with so littel elements I would bite the bullet
and model the 'spoken default' explicitly with a text ELEMENT that is
preset to the constant value.
An option would be to model a generic element as a CLUSTER-archetype
(including the 'spoken default' element) and specialize an from it for
every element you need. These specialised CLUSTERS could be assembled
in an OBSERVATION archetype via slots. But it think this would be to
complex for such a simple model and the specialisation would not
provide much added value.
Cheers, Thilo
On Mon, May 5, 2008 at 11:53 AM, Timmy K timmyx at gmail.com wrote:
Hi,
sure, it consist of a parent node and several child nodes, which
describes
the appearance of a patient.
structured by
-common information
weight
birthdate
height
-face
--eyes
color
--mouth
--nose
and so on
all elements have an attribute which says how it should be pronounced
which
is constant.
Thanks for the quick replies.
Timmy
On Mon, May 5, 2008 at 11:35 AM, Ian McNicoll ian at mcmi.co.uk wrote:
Hi Timmy,
Can you explain the domain model in a little more detail?
Ian
On Mon, May 5, 2008 at 9:58 AM, TimmyX TimmyX at gmail.com wrote:
Hello!
Within the context of my bachelor thesis, i am trying to transform
a
domain
model into an archetype, but now i am having some problems and i
hope
maybe
some of you here can help me.
My first question is, is it possible to define constant or hard
coded
values ie. constant text which contains a description?
So far I am trying to add a CODED_TEXT that matches a defined
constraint
ac0001, but i am not sure if this is a valid solution.
ITEM_TREE[at0003] matches { -- ITEM_TREE
items cardinality matches {0..*; unordered} matches
{
CLUSTER[at0004] occurrences matches {0..1}
matches {-- Top
items cardinality matches {0..*;
unordered} matches {
ELEMENT[at0005] occurrences
matches {0..1} matches {-- SpokenDefault
value matches {
DV_CODED_TEXT
matches {
defining_code matches {[ac0001]}-- Top
}
}
and the other question
How do i add sub-elements, is it even possible? ie. I have a Text
field
Top and i want to add a Text field SpokenDefault to it, which
shows
how
to pronounce the word Top. the way i do it right now is creating a
cluster
for every element which is not very effective.
thanks in advance
TimmyX
--
View this message in context:
http://www.nabble.com/Constant-Values-and-%22sub%22-Elements-tp17053994p17053994.html
Sent from the openehr-technical mailing list archive at Nabble.com.
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Dr Ian McNicoll
office +44(0)141 560 4657
fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com
Consultant - IRIS GP Accounts
Member of BCS Primary Health Care Specialist Group ?
http://www.phcsg.org
___
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
___
openEHR
Constant Values and sub Elements
Timmy,
I think this speech recognition stuff is more an interface thing and
IMHO it doesn't belong into an archetype (if you see an archetype as a
means to share interoperable health information). You could have a
seperate XML file that tags every appropriate field to a
'spokendefault' value(what would be the format? - sound file, phonetic
spelling,...) via the at code.
Lets see what others think
-Thilo
On Mon, May 5, 2008 at 4:16 PM, Timmy K timmyx at gmail.com wrote:
Sorry for being that unspecific.. The project i am working on is about
speech recognition. A Software which allows med. experts to fill out a
Form with speech only, so currently the xml File with the Domain Model
generates a Form with Checkboxes, date Fields and so on and it
includes also a spokendefault value which tells the speech recognition
how this Element Name Sounds like. In the End the generated Form can
be controled or navigated with speech.
I would say it has to be computable.
Thanks,
Timmy
Am 05.05.2008 um 15:11 schrieb Ian McNicoll ian at mcmi.co.uk:
Thanks Timmy,
I am still struggling to understand the purpose of the
'pronounciation' attribute. Does this have to be computable or is it
just for designer/user guidance? Can you give little more background
to your project?
Ian
On Mon, May 5, 2008 at 10:53 AM, Timmy K timmyx at gmail.com wrote:
Hi,
sure, it consist of a parent node and several child nodes, which
describes
the appearance of a patient.
structured by
-common information
weight
birthdate
height
-face
--eyes
color
--mouth
--nose
and so on
all elements have an attribute which says how it should be
pronounced which
is constant.
Thanks for the quick replies.
Timmy
On Mon, May 5, 2008 at 11:35 AM, Ian McNicoll ian at mcmi.co.uk wrote:
Hi Timmy,
Can you explain the domain model in a little more detail?
Ian
On Mon, May 5, 2008 at 9:58 AM, TimmyX TimmyX at gmail.com wrote:
Hello!
Within the context of my bachelor thesis, i am trying to
transform a
domain
model into an archetype, but now i am having some problems and i
hope
maybe
some of you here can help me.
My first question is, is it possible to define constant or hard
coded
values ie. constant text which contains a description?
So far I am trying to add a CODED_TEXT that matches a defined
constraint
ac0001, but i am not sure if this is a valid solution.
ITEM_TREE[at0003] matches { -- ITEM_TREE
items cardinality matches {0..*; unordered}
matches {
CLUSTER[at0004] occurrences matches {0..1}
matches {-- Top
items cardinality matches {0..*;
unordered} matches {
ELEMENT[at0005] occurrences
matches {0..1} matches {-- SpokenDefault
value matches {
DV_CODED_TEXT
matches {
defining_code matches {[ac0001]}-- Top
}
}
and the other question
How do i add sub-elements, is it even possible? ie. I have a Text
field
Top and i want to add a Text field SpokenDefault to it, which
shows
how
to pronounce the word Top. the way i do it right now is creating a
cluster
for every element which is not very effective.
thanks in advance
TimmyX
--
View this message in context:
http://www.nabble.com/Constant-Values-and-%22sub%22-Elements-tp17053994p17053994.html
Sent from the openehr-technical mailing list archive at Nabble.com.
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Dr Ian McNicoll
office +44(0)141 560 4657
fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com
Consultant - IRIS GP Accounts
Member of BCS Primary Health Care Specialist Group ? http://www.phcsg.o
rg
___
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
--
Dr Ian McNicoll
office +44(0)141 560 4657
fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com
Consultant - IRIS
Constant Values and sub Elements
Hi TimmyX
an ac constraint has been designed for defining terminology value
sets by query.
In your case several constraining the text ELEMENT to several at codes
should do the job (the Archetype Editor supports that via 'internal
codes' in the constraints tab right to the definition area.
Something like that should do
ITEM_TREE[at0003] matches { -- Tree
items
cardinality matches {0..*; unordered} matches {
CLUSTER[at0004] occurrences matches {0..1} matches {-- Top
items cardinality matches {0..*; unordered} matches {
ELEMENT[at0005] occurrences matches {0..1} matches {--
Default Spoken
value matches {
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0006, -- bla
at0007] -- blub
}
}
}
}
}
}
}
Regarding sub elements you were right: CLUSTERS are the way to do that
in Archetypes! If you have a pattern which is always the same, you
could create a CLUSTER-Archetype and reuse it...
Cheers, Thilo
On Mon, May 5, 2008 at 10:58 AM, TimmyX TimmyX at gmail.com wrote:
Hello!
Within the context of my bachelor thesis, i am trying to transform a domain
model into an archetype, but now i am having some problems and i hope maybe
some of you here can help me.
My first question is, is it possible to define constant or hard coded
values ie. constant text which contains a description?
So far I am trying to add a CODED_TEXT that matches a defined constraint
ac0001, but i am not sure if this is a valid solution.
ITEM_TREE[at0003] matches { -- ITEM_TREE
items cardinality matches {0..*; unordered} matches {
CLUSTER[at0004] occurrences matches {0..1} matches {
-- Top
items cardinality matches {0..*; unordered}
matches {
ELEMENT[at0005] occurrences matches
{0..1} matches {-- SpokenDefault
value matches {
DV_CODED_TEXT matches
{
defining_code
matches {[ac0001]}-- Top
}
}
and the other question
How do i add sub-elements, is it even possible? ie. I have a Text field
Top and i want to add a Text field SpokenDefault to it, which shows how
to pronounce the word Top. the way i do it right now is creating a cluster
for every element which is not very effective.
thanks in advance
TimmyX
--
View this message in context:
http://www.nabble.com/Constant-Values-and-%22sub%22-Elements-tp17053994p17053994.html
Sent from the openehr-technical mailing list archive at Nabble.com.
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Constant Values and sub Elements
Timmy,
I guess in your case with so littel elements I would bite the bullet
and model the 'spoken default' explicitly with a text ELEMENT that is
preset to the constant value.
An option would be to model a generic element as a CLUSTER-archetype
(including the 'spoken default' element) and specialize an from it for
every element you need. These specialised CLUSTERS could be assembled
in an OBSERVATION archetype via slots. But it think this would be to
complex for such a simple model and the specialisation would not
provide much added value.
Cheers, Thilo
On Mon, May 5, 2008 at 11:53 AM, Timmy K timmyx at gmail.com wrote:
Hi,
sure, it consist of a parent node and several child nodes, which describes
the appearance of a patient.
structured by
-common information
weight
birthdate
height
-face
--eyes
color
--mouth
--nose
and so on
all elements have an attribute which says how it should be pronounced which
is constant.
Thanks for the quick replies.
Timmy
On Mon, May 5, 2008 at 11:35 AM, Ian McNicoll ian at mcmi.co.uk wrote:
Hi Timmy,
Can you explain the domain model in a little more detail?
Ian
On Mon, May 5, 2008 at 9:58 AM, TimmyX TimmyX at gmail.com wrote:
Hello!
Within the context of my bachelor thesis, i am trying to transform a
domain
model into an archetype, but now i am having some problems and i hope
maybe
some of you here can help me.
My first question is, is it possible to define constant or hard coded
values ie. constant text which contains a description?
So far I am trying to add a CODED_TEXT that matches a defined
constraint
ac0001, but i am not sure if this is a valid solution.
ITEM_TREE[at0003] matches { -- ITEM_TREE
items cardinality matches {0..*; unordered} matches {
CLUSTER[at0004] occurrences matches {0..1}
matches {-- Top
items cardinality matches {0..*;
unordered} matches {
ELEMENT[at0005] occurrences
matches {0..1} matches {-- SpokenDefault
value matches {
DV_CODED_TEXT
matches {
defining_code matches {[ac0001]}-- Top
}
}
and the other question
How do i add sub-elements, is it even possible? ie. I have a Text
field
Top and i want to add a Text field SpokenDefault to it, which shows
how
to pronounce the word Top. the way i do it right now is creating a
cluster
for every element which is not very effective.
thanks in advance
TimmyX
--
View this message in context:
http://www.nabble.com/Constant-Values-and-%22sub%22-Elements-tp17053994p17053994.html
Sent from the openehr-technical mailing list archive at Nabble.com.
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Dr Ian McNicoll
office +44(0)141 560 4657
fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com
Consultant - IRIS GP Accounts
Member of BCS Primary Health Care Specialist Group ? http://www.phcsg.org
___
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
Fwd: AOM MOF mapping
Has this email gotten through? Wondering since Sam recently described problems with the list (Eric's SNOMED post). Is my assumption regarding MOF (see below) right? -- Forwarded message -- From: Thilo Schuler thilo.schu...@gmail.com Date: Mon, Apr 21, 2008 at 4:12 PM Subject: Re: AOM MOF mapping To: For openEHR technical discussions openehr-technical at openehr.org Adam Sam This is very interesting, kind of relates to my recent post MDA/MDD DSL. For my med student brain I want to clarify that I get what Adam suggests. MOF has the idea of 4-layer meta-modelling. In the case of AOM/MOF mapping this would lead to this: m3 (meta-metamodel) - MOF m2 (metamodel) - AOM and RM (?) [expressed as instance of MOF] m1 (model) - Archetypes m0 (data) - Archetype instances Is that correct? I am especially curious whether the Reference Model (RM) as indicated above also needs to be expressed as MOF in the m2 layer. I would presume so. As Adam, suggested it makes sense to used the EMF infrastructure tools (e.g. have a look at the screen-video http://redmonk.com/tv/eclipse-emf-demo-large/ ) as their meta-metamodel Ecore is supposed to be pretty much EMOF (essential MOF) compliant. @Sam: If I understand you correctly your trial design starts with an CCR-openEHR-template (i.e. several aggregated archetypes plus maybe further constraints). This would be the m1-layer. Before we could do that we would have to create the generic m2-layer. Thilo On Sat, Apr 19, 2008 at 2:26 PM, Sam Heard sam.heard at oceaninformatics.com wrote: Hi Adam This is something we would very much like to do. I would propose the following senario: Develop a template for CCR Document it (html) and enable data entry Transform the template to MOF Create data against the MOF Transform the data entered against the template to CDA Compare the data This would seem useful as a trial. Cheers, Sam Adam Flinton wrote: In a reply wrt On Information and Interoperability I have noted that there is a move underway to try produce an HL7 model (via EMF/MOF) for use in our /OHT eclipse tooling. Has anyone looked at an AOM/MOF mapping? If so any thoughts? E.g. were one to want to sit down do some Eclipse OpenEHR tooling then an obvious contender would be the Eclipse EMF/GMF that would require a AOMEMF mapping given EMF is a subset of MOF then etc. Adam ** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail ** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr Sam Heard Chief Executive Officer Ocean Informatics Director, openEHR Foundation Senior Visiting Research Fellow, University College London Aus: +61 4 1783 8808 UK: +44 77 9871 0980 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
AOM MOF mapping
Sam In your opinion what is the advantage of expressing templates in MOF? Can't the described exersise CCR-openEHR-CDA be done already only with openEHR/Ocean tools? Is to have a more indepedent intermediary format? Thilo On Tue, Apr 22, 2008 at 7:46 AM, Sam Heard sam.heard at oceaninformatics.com wrote: Hi Ed I am sorry if I sounded disparaging in anyway. I was referring to the implementation guide which is the basis for various schematron and other approaches (as I understand it). I am sure that a lot of people will choose CDA and CCD particularly in the near future. I know you are interested in the clinical specifications and have formed a clinical council. I think it would be wonderful to see the European effort line up with the US effort in the clinical specifications area around the CEN and hopefully ISO approach. I understand the difficulties. A small group of enthusiasts working at a distance has got us to this point. The openEHR Foundation is planning to move into formal relationships with a number of agencies and we have the prospect of alignment of a number of initiatives. I believe a small group working on AOM - MOF would be very useful and give a way forward to a single logical representation of clinical content. Clinicians around the globe will appreciate this. Cheers, Sam William E Hammond wrote: Thanks for the response. I am not sure I agree that CCD is a paper, but I guess time will tell which is the way to go. Looks like HL7 needs to decide where it fits in today's world and really promote that position. I for one think CCD has a lot of promise. Ed Sam Heard sam.heard at oceani nformatics.comTo Sent by: For openEHR technical discussions openehr-technical openehr-technical at openehr.org -bounces at openehr. cc org Subject Re: AOM MOF mapping 04/21/2008 06:41 PM Please respond to For openEHR technical discussions openehr-technica l at openehr.org Hi Ed The process is really about bringing the clinical specifications into a common framework. From the openEHR perspective this involves: links to terminology developments to ensure a sustainable approach and transformations to a terminology only syntax if that proves useful links to implementations of these specifications in openEHR, CEN/ISO or CDA CCD is a paper and XML schema exercise to get CCR and CDA into the same semantic space, but there is no coherent approach as each are XML schemas and have a lot of attendant paper guides. As openEHR Archetypes are largely independent of any implementation concerns, it is possible to express the clinical content of the CCR as a Template entirely in terms of standard archetypes. From this, a specific schema (Template Data Schema) can be presented which should ideally map 1:1 with the clinical content of CCR. This allows integration of CCR into the openEHR space in a controlled manner with validation via the TDS. As we have a growing number of Archetype to CDA transforms this allows production of CDA documents from the openEHR environment in a reusable manner. The full 'pipeline' of CCR instance - openEHR - CDA is therefore possible without intervention and with full standardised clinical content validation (as well as any constraints expressed in CCR via the template). openEHR users then have a means of dealing with CCR and CDA documents in the same environment (as well as v2 and XML etc) . If people are ready to accept such transforms as a wonderful thing (or even useful) and we validate the outputs from the CCD perspective (remember it is a single transform per archetype so it should then work in any CDA document (assuming there is some standardisation in that environment) then it should be possible to get the MOF statement from AOM representation of an archetype. This will require some work but it would reduce concerns in the market. By the way, what the pipeline offers to vendors and jurisdictions even as it stands is the possibility of building templates (always from archetypes) and creating a template data schema that maps to their own data model. If the data validates, then they can transform their data to openEHR and from there to CDA, CCR, v2 etc without understanding any of the complexities. Of course integration engines will perform something similar on a case by case
AOM MOF mapping
Adam Sam This is very interesting, kind of relates to my recent post MDA/MDD DSL. For my med student brain I want to clarify that I get what Adam suggests. MOF has the idea of 4-layer meta-modelling. In the case of AOM/MOF mapping this would lead to this: m3 (meta-metamodel) - MOF m2 (metamodel) - AOM and RM (?) [expressed as instance of MOF] m1 (model) - Archetypes m0 (data) - Archetype instances Is that correct? I am especially curious whether the Reference Model (RM) as indicated above also needs to be expressed as MOF in the m2 layer. I would presume so. As Adam, suggested it makes sense to used the EMF infrastructure tools (e.g. have a look at the screen-video http://redmonk.com/tv/eclipse-emf-demo-large/ ) as their meta-metamodel Ecore is supposed to be pretty much EMOF (essential MOF) compliant. @Sam: If I understand you correctly your trial design starts with an CCR-openEHR-template (i.e. several aggregated archetypes plus maybe further constraints). This would be the m1-layer. Before we could do that we would have to create the generic m2-layer. Thilo On Sat, Apr 19, 2008 at 2:26 PM, Sam Heard sam.heard at oceaninformatics.com wrote: Hi Adam This is something we would very much like to do. I would propose the following senario: Develop a template for CCR Document it (html) and enable data entry Transform the template to MOF Create data against the MOF Transform the data entered against the template to CDA Compare the data This would seem useful as a trial. Cheers, Sam Adam Flinton wrote: In a reply wrt On Information and Interoperability I have noted that there is a move underway to try produce an HL7 model (via EMF/MOF) for use in our /OHT eclipse tooling. Has anyone looked at an AOM/MOF mapping? If so any thoughts? E.g. were one to want to sit down do some Eclipse OpenEHR tooling then an obvious contender would be the Eclipse EMF/GMF that would require a AOMEMF mapping given EMF is a subset of MOF then etc. Adam ** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail ** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr Sam Heard Chief Executive Officer Ocean Informatics Director, openEHR Foundation Senior Visiting Research Fellow, University College London Aus: +61 4 1783 8808 UK: +44 77 9871 0980 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
openEHR vs MDA/MDD DSLs
Hi all, just wanna share this: For many of you this might not be something new, but today I consciously noticed to many analogies between the Model Driven Architecture (MDA) or Model Driven Development (MDD) including the trendy Domain Specific Languages (DSL) with openEHR's two model approach (see attached png from http://www.omg.org/cgi-bin/apps/doc?omg/03-06-01.pdf ) Obviously the reasons are partly different (plattform independant code vs semantic interoperability - although the openEHR RM can also be implemented on all plattforms) but especially DSLs try to abstract domain models from technical domain. PIM Metamodel = AOM (while ADL ist a textual DSL for it!) PIM = Archetypes and Templates PSM Metamodel = openEHR Reference Model PSM = Reference model instances. Cheers, Thilo -- next part -- A non-text attachment was scrubbed... Name: mda.png Type: image/png Size: 24191 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080411/9ab29112/attachment.png
xml archetypes to xforms
Hey Lisa, ime et al back from skiing - had 6 sunny days and time. Thanks for the valuable replies. Comments inline... Hi Ime, Thilo and all We investigated using XForms for automatically-generated data entry GUIs last year. There are some features of XForms which made it seem particularly well suited to the task: a lot of built-in entry data validation, ability to validate data against a schema embedded in the XForms definition, ability to decouple the connection between an input widget and the target item in the schema by using an XForms binding item... not to mention being a completely open, platform-independent and XML-based standard (even if there's very limited browser support thus far), etc. It was a while ago, so I have probably forgotten some other pros. IBM enlists these reasons for XFrorms: # XForms is a W3C XML Standard; # XForms is XML and submits XML; # XForms uses W3C XML Schema for validation and data integrity; # XForms uses W3C XPath for data references; # XForms is a Model-View-Control (MVC) architecture; # XForms uses W3C XML Events for loose coupling; # XForms can be embedded in other host languages; # XForms rendering is decided on the glass (write once, render anywhere); # XForms reduces/eliminates need for scripting; # XForms decreases client/server traffic; and # XForms encodes dependencies in data and validates that data is declaratively and relatively easily. Their XForms - DB2 Demos (http://services.alphaworks.ibm.com/DB2pureXMLDemo/) are fascinating but also seem very 'hacky'. Look for example at the HL7 CDA one at http://services.alphaworks.ibm.com/DB2pureXMLDemo/hl7CDAXForms/XFormsDemo.xhtml But gradually it came to feel like we were trying to force XForms to do something it is too generic/low-level to be suited to. The main challenges were: 1. The existing XForms implementations were generally immature/flaky or not in line with the latest XForms specification. Have gotten better but still don't support the whole XForms 1.1 specs. Especially if you try non trivial stuff the chances for bug increase rapidly 2. The openEHR DATA_VALUE types are of a larger grain than most of the XForms widgets, so more than one XForm widget, more than one databinding and more than one binding constraint had to be defined per openEHR ELEMENT. That made the XForms definition very verbose and complicated to read as code. Here encapsulting the code as a custom XBL widget could help - hides complexity. This would also allow to do hidden (from the XForms markup point of view), well-tested scripting where XForms capabilities are not enough. Here is an example of a simple XBL widget: http://www.ibm.com/developerworks/library/x-xformsrte/ Currently only the Firefox XForms extension and partly the Formsplayer IE-plugin support XBL. And since it hasn't been used much also a good chance of flakyness... Here are two links describing using XBL in the above mentioned XForms engines: http://developer.mozilla.org/en/docs/XForms:Custom_Controls and http://www.formsplayer.com/node/378 3. The set of XForms widgets available seemed very limiting when it came to creating graphic entry controls for certain data values or with complex value constraints. For example, we never successfully created a mechanism to populate an externally coded term (would have had to query a terminology web service) using XForms widgets and events. It may be possible, but not at all trivial. Again a well written and tested XBL custom widget could do the job 4. It was a particularly challenging task to model the AOM constraints (for each ELEMENT) as XForms binding constraints and so we experimented with adding the value constraints directly as from the AOM schema using the XForms extension module (but this required an XForms engine that could understand the AOM extensions to really test it and no such engine exists *yet*) What do you mean by XForms extension module? Do you want to add own elements or attributes (in a separate namespace)? IMO, in such a case you would need to create your own XForms engine (or build on an existing one) that understands these add-ons. This is an example: http://www.fh-oow.de/institute/iapg/personen/brinkhoff/paper/W2GIS2007.pdf NB: For #4 it doesn't necessarily matter if you don't want to apply/validate the AOM constraints on the client side, but I think it is important in most cases to have these constraints contained and applied in the XForms definition to make it *usable*. What has your experience been Thilo, Ime? What are your thoughts? I am very interested in any work going on in this area! I can totally understand your concerns. In this work http://www.ncbi.nlm.nih.gov/pubmed/17108529, I fiddled with too immature XUL and XBL. So with XForms and DB2 I plan to start very modestly (more on a fun basis besides boring exam studying) and see were I am going... Generally I still think a
xml archetypes to xforms
Hi Ime and others XForms is an intriguing technology and IMHO (and others' !) it seems very suited to generate forms from templates and their underlying archetypes . I will first point you to two recent sources where XForms where mentioned within the openEHR community: 1. Wiki (look in the comments area): http://www.openehr.org/wiki/display/dev/User+Interface+and+openEHR+data 2. Mailing list thread: http://www.openehr.org/mailarchives/openehr-technical/msg03208.html So there are several people that have thought about or have actually implemented code regarding XForms openEHR archetypes. I will try to list the relevant people that I know of: 1. Carl Alfon from Link?ping University (Sweden) currently writes a thesis on Archetype based EHR GUI. In his practical work he generates XForms using the openEHR ADL parser plus custom code. 2. Adam Flinton from the NHS has an complete Xml forms engine which can be used with (besides others) XForms (Chiba to render into Ajax-ified html). He also offered that this could be open-sourced. 3. Lisa Thurston from Ocean Informatics wrote a set of customizable/extendable XSLT scripts that creates a generic read-only view of openEHR instance data. 4. Heath Frankel (programming lead at Ocean Informatics) and I have thought about using the Template Data Schemas (TDS) that can be generated from templates (using the template designer) as the basis for the XForms model. Tests are needed whether the currenty availble XForms engine implementations support such complex nested schemas... 5. Myself, I have the humble goal (because I have so little time) of writing a XForms GUI for a small template with only a couple of archetypes that connects directly to an IBM DB2 server via web services. Will start with a static one but finally generating it would be awesome... A first test with a trivial 4 field form was successful in retrieving and uploading data from the DB2 server. 6. There are a couple of more ppl generally interested in openEHR GUIs: Helma van der Linden (University of Maastricht), Erik Sundval (University of Link?ping) and Sam Heard Hugh Leslie from Ocean Informatics. I think we should join forces and create a sub-project to share ideas and maybe code for an openEHR XForms Toolkit. I have proposed this in December already but have been slack busy. What is everybody's opinion (especially the people listed) on such a project? Regarding GUI generation in general Hugh has argued that it won't necessarily will be the most usable forms. I think that this is true (and for complex data entry in complicated clinical workflows it will propably never change) and in that case the generated GUI would be a good start to for further hand-coded customization (scaffolding GUI code). However one day we might be surprised by the power of XForms especially once the engines have become even better and special openEHR widget extensions are available (see again http://lib.tkk.fi/Diss/2007/isbn9789512285662/isbn9789512285662.pdf). Will be on a long anticipated and much needed skiing holiday for the next 7 days, so won' t be able to reply until I return. Cheers, Thilo PS: See one more remark inline. On Feb 9, 2008 4:50 PM, Ime Asangansi asangansi at yahoo.com wrote: Hi everybody, I am working on a project that might involve generating xforms from archetypes. While there are many possibilities in doing this (including an internal form schema designer within the OpenMRS that is infopath-based), before making design decisions, I would really like to learn from people who are using archetypes to drive Xforms generation for their app. And how is the seemingly complex archetype 'definition' part handled? Also I would really like to know how the interface in the Ocean/LiU editors are generated? XSLT or ...? No XSLT but going recursively through the object model in the kernel component to create a certain widget for every datatype at the leaf nodes. But others know better. Thirdly, has or is any one working on translating openehr archetype based messages to HL7 v2? I might need to translate (or transform) Xml data to HL7. Thanks, in anticipation. rgds, Ime Never miss a thing. Make Yahoo your homepage. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
persistence
Hi everybody, just a short note: I am more a front-end person (plan to start a OSS GUI project in 2008), although I have an vested interested in a open persistence solution, since I would like to see an end-to-end system demonstrator based on OSS components (GUI, kernel, persistence). IMO (and in Rong's etc) this would really boost openEHR. I believe a generic persistence layer API(s) - as Tom said - is the way to go. This won't happen in one go. So in a truely agile development style this has to happen over several iterations, while every iteration product has to be usable! The reason for this post is that I recently investigated the IBM DB2 9 DBMS . This could be a good starting point or reference to build the API layer on. Reasons for IBM DB2 9 DBMS (http://www-306.ibm.com/software/data/db2/express/) are: - the Express-C version is free and only has restrictions regarding the hardware (max 2 CPUs and 2 GB Ram). Compared to the 'Express' versions of Oracle and Microsoft, with limited DB size etc. - it is a long-around enterprise SQL DBMS, now with additional native XML support (pureXML feature) - it seems to have good documentation (2 books and several recent articles) and a active community - there is a well-maintained performance testing toolkit for it (http://tpox.sourceforge.net/). - the Express-C license can even be used commercially! If the hardware limitations become a problem an upgrade can be bought without having to change the underlying code. Cheers, Thilo On Jan 1, 2008 8:54 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: Bert Verhees wrote: I believe, it is rather sensitive, because, when you publish a persistence-layer, you have a full blown product, which others can use, I think, people fear to put their self out of business if they publish too much knowledge. That, I beleive is the reason because the discussions about this subject often die. I would suggest various reasons: building an enterprise usable persistence layer - one that is highly performant, reliable (in terms of data integrity) and scalable is a serious endeavour. It requires real investmnet, not just for the design and implementation, but for load and performance testing. Trying to do it open source is likely to be a slow project, because it requires concentrated ongoing effort. there is no such things as the perfect back-end for all use contexts, so a single mighty build-it-once-forever open source solution is likely to be flawed from the outset. What would be useful as open source is the binding layer containing an agreed API, e.g. an object db style API, or my current node+path idea (http://www.openehr.org/wiki/pages/viewpage.action?pageId=786487). Because of the different needs of different contexts, commercial implementations are more likely to be the right business model, as long as they conform to the interfaces demanded by the community, possibly be incorporating lightweight open source components. Therefore one of the needs of openEHR (and information processing in general) is a standardised persistence layer API that provides the right kind of sematics without predetermining limiting choices to do with technology, performance or scalability to much. We have recognised this for a long time in openEHR, but not had the effort to implement it. I would describe the levels of interfaces needed as fllows: a virtual EHR API - this is a fine-grained application interface for talking to an openEHR system, including building, saving and retrieving EHR data. It does not contain any persistence primitives, but provides the main interface for any application writer, who should be able to largely forget about everything else an EHR service interface - this is a coarse-grained interface that knows about Compositions, Contributions, queries a persistence layer that is archetype- (i.e. path-) enabled, in the sense of the node+path model described above. For the first two we have developed working versions in our own products, and will release the entire interfaces soon in documentary form. There is not much secret here, and we would expect an openEHR 'standard' for these interfaces to be developed by integrating such APIs built by anyone in the community, or defining alternative/componentised APIs, if it makes sense in some cases. The normal community process is the correct vehicle for doing this (i.e. discussion, proposals, Change Requests, ARB review etc). The 3rd layer above is not standardised at all, and would not have to be openEHR-specific, but needs to know minimally about paths. Creating a specification for this could be useful for creating archetype-based information processing systems in general. This could be done by the same process, but will undoubtedly take longer since more implementation-based evidence is required. Lastly, implementing highly performant database layer is largely a matter of experience. Beginners may think that
persistence
For openEHR I will concentrate on the GUI part. Had to investigate it for a uni project. Just wanted to let everybody know about IBM DB2 9.5, which I think is a fair, uncrippled offer. On Jan 2, 2008 5:18 PM, Bert Verhees bert.verhees at rosa.nl wrote: Thilo Schuler schreef: Hi everybody, just a short note: I am more a front-end person (plan to start a OSS GUI project in 2008), although I have an vested interested in a open persistence solution, since I would like to see an end-to-end system demonstrator based on OSS components (GUI, kernel, persistence). IMO (and in Rong's etc) this would really boost openEHR. I believe a generic persistence layer API(s) - as Tom said - is the way to go. This won't happen in one go. So in a truely agile development style this has to happen over several iterations, while every iteration product has to be usable! The reason for this post is that I recently investigated the IBM DB2 9 DBMS . This could be a good starting point or reference to build the API layer on. If you need any help? Bert ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
persistence
?!?!? On Jan 2, 2008 8:36 PM, Bert Verhees bert.verhees at rosa.nl wrote: Thilo Schuler schreef: For openEHR I will concentrate on the GUI part. Had to investigate it for a uni project. Just wanted to let everybody know about IBM DB2 9.5, which I think is a fair, uncrippled offer. oh On Jan 2, 2008 5:18 PM, Bert Verhees bert.verhees at rosa.nl wrote: Thilo Schuler schreef: Hi everybody, just a short note: I am more a front-end person (plan to start a OSS GUI project in 2008), although I have an vested interested in a open persistence solution, since I would like to see an end-to-end system demonstrator based on OSS components (GUI, kernel, persistence). IMO (and in Rong's etc) this would really boost openEHR. I believe a generic persistence layer API(s) - as Tom said - is the way to go. This won't happen in one go. So in a truely agile development style this has to happen over several iterations, while every iteration product has to be usable! The reason for this post is that I recently investigated the IBM DB2 9 DBMS . This could be a good starting point or reference to build the API layer on. If you need any help? Bert ___ 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
persistence
True, API persistence layer should be generic as said previously mentioned. Although originally it needs to be developed based on a reference DBMS and for this DB2 looks attractive (quick results?) on first sight. On Jan 2, 2008 8:58 PM, Bert Verhees bert.verhees at rosa.nl wrote: Bert Verhees schreef: Thilo Schuler schreef: For openEHR I will concentrate on the GUI part. Had to investigate it for a uni project. Just wanted to let everybody know about IBM DB2 9.5, which I think is a fair, uncrippled offer. oh Sorry, Clicked accidently on Send I hope someone will pick up this subject, I would be glad to help So, if someone considers, DB2, or any other DB, that shoudln't matter, there are many free DB-engines, it should not be visible in the API. Bert On Jan 2, 2008 5:18 PM, Bert Verhees bert.verhees at rosa.nl wrote: Thilo Schuler schreef: Hi everybody, just a short note: I am more a front-end person (plan to start a OSS GUI project in 2008), although I have an vested interested in a open persistence solution, since I would like to see an end-to-end system demonstrator based on OSS components (GUI, kernel, persistence). IMO (and in Rong's etc) this would really boost openEHR. I believe a generic persistence layer API(s) - as Tom said - is the way to go. This won't happen in one go. So in a truely agile development style this has to happen over several iterations, while every iteration product has to be usable! The reason for this post is that I recently investigated the IBM DB2 9 DBMS . This could be a good starting point or reference to build the API layer on. If you need any help? Bert ___ 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 ___ 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
GUIs for openEHR data
Adam This sounds great. Would be a great to start a openEHR GUI project and your stuff sounds like a fantastic basis. Just for curiosity: Why did you prefer chiba over orbeon? Also looked at both and orbeon seemed the more active project. The Java Project needs a simple end-to-end demonstrator to show the power of the kernel component. The open source GUI project could be used for the presentation layer. Custom widgets based on templates/archetypes should be a goal in the long time. In my XUL experiment I played with XBL to create a masked edit. Honkala also suggests it in his thesis (http://lib.tkk.fi/Diss/2007/isbn9789512285662/isbn9789512285662.pdf). Though the current server-side XForms implementations don't support it (yet). Formsplayer and Mozilla XForms (both client side implementation) support it partially. We need to keep this discussion up! Thilo On Dec 6, 2007 12:41 PM, Adam Flinton adam.flinton at nhs.net wrote: Thilo Schuler wrote: Hi As I assume not everybody interested in openEHR GUIs has set watches for the relevant pages in the openEHR wiki, I would like to point to a rather lengthly comment of mine: http://www.openehr.org/wiki/display/dev/User+Interface+and+openEHR+data?focusedCommentId=1540136#comment-1540136 For further remarks etc please use the wiki. - Thilo ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical We in the NHS already have a complete Xml forms engine which allows one to define your view on a chunk of a document using either XForms (using Chiba to render into Ajax-ified html), XSLT (we provide some Ajax javascript or you can write your own) or JSF (Java Server Faces). It is very easy to create forms including adding nodes etc it comes with a complete WYSIWYG Word Style XHTML editor which can be included simply by setting an attribute on XForm (or XSLT rendered HTML) of mediatype=html. I would love to OSS this we should have by now but we're waiting for the OHT (Open Health Tools) to set up their repository. Adam ** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail ** ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Congraturation to our new Web site
Looks great, Helma. Well done! Good that we finally have a wiki (and such a sophisticated one, thanks Atlassian)! I will use it to share the gained knowledge and problems during a real project in which I will (1) design archetypes for the chronic ulcer domain and (2) implement an ExportAdapter to transfer existing ulcer data (proprietary) into a Ocean EhrBank server instance. -thilo On 11/3/07, KOBAYASHI, Shinji skoba at moss.gr.jp wrote: Now, we can access our new web site. It is very smart and cool. Though, it seems to me that took some difficulty and troubles, the web team has successfully finished to establish this site. I praise and appliciate this great work on web team. Thank you! And please take care of yourself. -- KOBAYASHI, Shinji skoba at moss.gr.jp ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
New contribution to Dual Model EHR architectures and archetype development
Hi David, just quickly flicked through your material (will definitely give it a more thorough read and try later). Like Rong I find it impressive too. The mapping/integration seems to be related to work by Rinner et al (TU Vienna) I recently came across: http://www.telemed-berlin.de/telemed2007/Beitraege/TELEMED-2007-03-Rinner.pdf Do you know it? I will be at Medinfo and will definitely listen to the presentation by your group. Cheers, Thilo On 7/10/07, Rong Chen rong.acode at gmail.com wrote: Dear David, It is very impressive work you presented here. I am looking forward to hearing more from your project. Hopefully we will meet in Medinfo. =) By the way, which ACODE components that you are still using in your project? Most of them have been donated to the openEHR Foundation and all recent developments are hosted by the openEHR Java project ( http://svn.openehr.org/ref_impl_java/TRUNK/project_page.htm). If you need any help with migrating dependencies of ACODE components or wish to release your Java components through the openEHR Java project, please let me know. Regards, Rong On 7/10/07, David Moner damoca at gmail.com wrote: Dear all, Our Group of Biomedical Informatics (IBIME) at the Technical University of Valencia, Spain, has been working during the last years in the field of integration and standardization of clinical data for the construction of EHR systems. Our main project has been called LinkEHR, which is a prototype system for managing clinical data in the form of EHR Extracts, following a dual model approach. This system is part of a coordinated project, together with the University of Murcia (Spain), called Semantic Web Technologies-Based Platform for the Management of Standardized Electronic Health Records. The main component of LinkEHR will be LinkEHR-Ed, an archetype editor with integration and standardization capabilities. Its objectives are: 1. to develop archetypes trough a visual interface independent from any particular reference model and direct edition of ADL. It includes the capability of importing a new Reference Model expressed as an XML Schema in order to use it as the guide for development of new archetypes. It also includes the capability of semantic validation of the designed archetypes. 2. to provide tools for the standardization of legacy clinical data by mapping an archetype structure to data sources containing non-standardized clinical data and automatically generation of queries to extract and transform that data in the form of XML EHR extracts compatible with the Reference Model XML-Schema. Although our work is not yet finished, we have decided to announce the existence of a beta version of LinkEHR-Ed. It just covers point 1 of the objectives (the edition and validation of archetypes), since point 2 (mapping archetypes to clinical data sources) is now under visual interface development and testing and we have decided to hide its interface by the moment. Some remarks: LinkEHR-Ed differs of current available archetype tools since it is a technical oriented editor and not a clinical point of view archetype editor. LinkEHR-Ed has already been tested with the OpenEHR reference model and the European CEN EN13606 reference model. LinkEHR-Ed is being developed in Java under the Eclipse Framework and it uses many components developed by ACode people. We expect to make its source code public by the end of the project, the last quarter of this year. You can find more info and download the beta version of LinkEHR-Ed at http://pangea.upv.es/linkehr Direct link for download: http://pangea.upv.es/linkehr/?page_id=10 PDF documentation: http://pangea.upv.es/linkehr/?page_id=9 All comments will be appreciated. Best regards, -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso 3, 3? planta Valencia ? 46022 (Espa?a) ___ 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
Hidden reference model stuff in template
templates' made for/by the NHS- UK and which can be found in the dev-uk-nhs part of the archetype database. So if you look for instance at the 'bloodpressure template (Archetype Id openEHR-EHR-OBSERVATION.blood_pressure.v1 Template ID 945c2617- dc89-4c28-94cf-43ee46c1ecb0), you'll only see the data classes/fields which where archetyped but none of the 'hidden' data classes/field (such date/time of measurement but also performer of committer). These are typical examples of data I would like to present in and/or enter via a GUI. So I guess a template builder isn't suitable for creating GUI's after all (or I've misunderstood this in the first place). Thanks again, Stef Op 31-mei-2007, om 1:50 heeft Thilo Schuler het volgende geschreven: Hi Stef, I have followed the thread and I will try to provide some hopefully useful hints. I will start with the central idea, the two-model-approach, and will try to cover your questions after that: - Archetypes are a way of constraining and plug-and-playing (LEGO principle) a relatively limited number of generic reference model classes of the reference model, that are expected to stay stable over a long period of time. In that way the multitude of quickly changing medical concepts (the medical knowledge) can be expressed and adapted to the current needs, while the building blocks (the reference model classes) stay the same. One big advantage of this approach is that software can be developed based on the reference model without knowing the archetypes in advance (future proof systems). - Analogy: Reference model classes are the LEGO bricks, Archetypes are the LEGO construction plans - The constraining rules (grammar) of *all* archetypes (or more precisely archetype instances) are defined in the archetype model. That is where the name two-model-approach came from: firstly the reference model and secondly the archetype model. - Every archetype (e.g. for blood pressure) is an instance of the archetype model. There could be many notations invented to express this archetype model. They only have to support the full semantics of the archetype model. Of all the theoretically possible notations the archetype editor currently supports ADL and can also transform the archetype into an XML version. - Every piece of medical information (the blood pressure values of person X in simple case) is a bundle of several reference class instances with the attributes set to certain values (to reflect the state of the patient X). The archetype or a combination of archetypes define(s) which classes, how many of them and what combination are in the bundle. Further more it can define things like value ranges for reference class attributes. Like archetyeps hese bundles could also be expressed in several formats, but today mostly XML is used (this is meant when Sam talks about data). - So don't confuse an XML data bundle (validated by the reference model schema) with an archetype expressed in XML. - In a message etc you would send the XML data NOT (!) the XML archetype that the archetype editor can output. Although there are references to the archetypes (that where used during creating) in the data. So the receiving system of the message can also retrieve the archetypes from an archetype server to add meaning to the data. - An archetype can validate (during creation or after reception) that a data bundle conforms to the concept that the archetype describes. So an archetype is a schema of a particular medical concept. Actually the XML schema language was evaluated as a means of expressing archetypes but was found to be not expressive enough. Therefore ADL has been invented. - As it was mentioned before (and as you correctly named hidden reference model stuff) archetypes only contain the constraints on the reference model which FURTHER constrain what is automatically by the reference modle. So if the a reference model class has an attribute of a date type and the archetype doesn't have a further constraint on it, any valid date could go in there. In the archetype you could further constrain that only dates from e.g. 9.9.1999 onwards are valid for that attribute in this context. - The template specification is not released yet, so I could be wrong. But from what I understand templates further constrain and bundle several archetypes to fit a certain organisations data entry needs. In contrast archetypes are mainly designed for interoperability reasons i.e. share common meaning (So archetypes are purposely designed on a higher level to reflect a sensible common denominator of a concept. A common misunderstanding is that archetypes do what templates are thought for. E.g. if a coded term in an archetype has to interchangeable codes associated with it - like one SNOMED and one LOINC - the template could preselect always the LOINC one because organisation has no SNOMED license. - Still
openEHR
Hi Bernard I have just made post the should cover part of your question. As mentioned in this post the kernel component is central to the architecture of an openEHR system as it brings the two models together. For persistence many solutions would be possible. Like XML (that what Ocean Informatics uses in their EhrBank product) or an object-relational-mapping solution. But it should be noted that just instances of the reference model need to be persisted including references to the archetypes used to create the instances. The archetypes can be retrieved again separately when the persisted data is loaded through the kernel. For Java kernel code have a look at http://svn.openehr.org/ref_impl_java/TRUNK/project_page.htm Thilo On 5/31/07, B21Fern at aol.com B21Fern at aol.com wrote: Hi Thilo I saw your most helpful account on openEHR archetypes etc in the technical at openehr.org. Do you know of an account describing an end to end example of it for a medical data value, say blood pressure. How it is really implemented in the database to the interface design and why etc. If we take blood pressure as an example, I assume there will be many archetypes involved and at another level certain amount of say Java classes. Thanks Bernard Fernando (GP)
openEHR
Here one more link to a nice overview written up by Thomas about persistence possibilities and techniques. Most of you will already know this: http://openehr.org/FAQs/t_persistence_notes.htm On 6/1/07, Thilo Schuler thilo.schuler at gmail.com wrote: Hi Bernard I have just made post the should cover part of your question. As mentioned in this post the kernel component is central to the architecture of an openEHR system as it brings the two models together. For persistence many solutions would be possible. Like XML (that what Ocean Informatics uses in their EhrBank product) or an object-relational-mapping solution. But it should be noted that just instances of the reference model need to be persisted including references to the archetypes used to create the instances. The archetypes can be retrieved again separately when the persisted data is loaded through the kernel. For Java kernel code have a look at http://svn.openehr.org/ref_impl_java/TRUNK/project_page.htm Thilo On 5/31/07, B21Fern at aol.com B21Fern at aol.com wrote: Hi Thilo I saw your most helpful account on openEHR archetypes etc in the technical at openehr.org. Do you know of an account describing an end to end example of it for a medical data value, say blood pressure. How it is really implemented in the database to the interface design and why etc. If we take blood pressure as an example, I assume there will be many archetypes involved and at another level certain amount of say Java classes. Thanks Bernard Fernando (GP)
Hidden reference model stuff in template
Hi Stef, I have followed the thread and I will try to provide some hopefully useful hints. I will start with the central idea, the two-model-approach, and will try to cover your questions after that: - Archetypes are a way of constraining and plug-and-playing (LEGO principle) a relatively limited number of generic reference model classes of the reference model, that are expected to stay stable over a long period of time. In that way the multitude of quickly changing medical concepts (the medical knowledge) can be expressed and adapted to the current needs, while the building blocks (the reference model classes) stay the same. One big advantage of this approach is that software can be developed based on the reference model without knowing the archetypes in advance (future proof systems). - Analogy: Reference model classes are the LEGO bricks, Archetypes are the LEGO construction plans - The constraining rules (grammar) of *all* archetypes (or more precisely archetype instances) are defined in the archetype model. That is where the name two-model-approach came from: firstly the reference model and secondly the archetype model. - Every archetype (e.g. for blood pressure) is an instance of the archetype model. There could be many notations invented to express this archetype model. They only have to support the full semantics of the archetype model. Of all the theoretically possible notations the archetype editor currently supports ADL and can also transform the archetype into an XML version. - Every piece of medical information (the blood pressure values of person X in simple case) is a bundle of several reference class instances with the attributes set to certain values (to reflect the state of the patient X). The archetype or a combination of archetypes define(s) which classes, how many of them and what combination are in the bundle. Further more it can define things like value ranges for reference class attributes. Like archetyeps hese bundles could also be expressed in several formats, but today mostly XML is used (this is meant when Sam talks about data). - So don't confuse an XML data bundle (validated by the reference model schema) with an archetype expressed in XML. - In a message etc you would send the XML data NOT (!) the XML archetype that the archetype editor can output. Although there are references to the archetypes (that where used during creating) in the data. So the receiving system of the message can also retrieve the archetypes from an archetype server to add meaning to the data. - An archetype can validate (during creation or after reception) that a data bundle conforms to the concept that the archetype describes. So an archetype is a schema of a particular medical concept. Actually the XML schema language was evaluated as a means of expressing archetypes but was found to be not expressive enough. Therefore ADL has been invented. - As it was mentioned before (and as you correctly named hidden reference model stuff) archetypes only contain the constraints on the reference model which FURTHER constrain what is automatically by the reference modle. So if the a reference model class has an attribute of a date type and the archetype doesn't have a further constraint on it, any valid date could go in there. In the archetype you could further constrain that only dates from e.g. 9.9.1999 onwards are valid for that attribute in this context. - The template specification is not released yet, so I could be wrong. But from what I understand templates further constrain and bundle several archetypes to fit a certain organisations data entry needs. In contrast archetypes are mainly designed for interoperability reasons i.e. share common meaning (So archetypes are purposely designed on a higher level to reflect a sensible common denominator of a concept. A common misunderstanding is that archetypes do what templates are thought for. E.g. if a coded term in an archetype has to interchangeable codes associated with it - like one SNOMED and one LOINC - the template could preselect always the LOINC one because organisation has no SNOMED license. - Still, if all dates are allowed a template wouldn't constrain (and therefore wouldn't mention) a reference model date attribute either. So a GUI designer would have to know the used archetypes and the referenced reference model classes including attributes to sensibly create the GUI. Hope this was of any help, Thilo (openEHR informed medical student)
Eclipse OHF Project OpenEHR Component
This sounds like a very good idea. A coherent environment (including demos, code examples, tutorials etc...) would give openEHRarchetypes the boost that this well-designed architecture deserves. Will ask Tom about it at the MIE. I would like to help, but I am only a med student and no real geek. Live only 3 hours from Esslingen, unfortunately I already have an appointment on this friday morning. -Thilo Grahame Grieve schrieb: The Eclipse Open Healthcare Framework (OHF) Project is an open source project whose aim is to build an e-health computing platform (tools, run-times and community) on which developers can more effectively build useful and interoperable applications? Eclipse is widely known as a tools IDE, or even just a Java development environment. But Eclipse is more than this. Eclipse is a community with a strong open source governance model that develops tools which have strong reuse of the knowledge code for run-time use by developers. We believe that the openEHR community could leverage the Eclipse platform - the tooling, run-time and governance support, to improve the coherence of the the tools, implementations and uptake of openEHR. OHF will propose an openEHR component at the European EclipseCon meeting. We have an OHF FTF meeting in Stuttgart on Oct 13th, where the project will be proposed for formal adoption as an OHF component. I am currently working with Tom Beale to clarify the scope of the proposal, and how it relates to an overall tooling roadmap for openEHR. This notice is an invitation to come to the Stuttgart meeting and have your say, or to work with Tom and I on the proposal in advance. Grahame links: Eclipse OHF: http://www.eclipse.org/ohf EclipseCon: http://www.eclipsecon.org/summiteurope2006/ Stuttgart Meeting announcement: http://www.eclipse.org/newsportal/article.php?id=216group=eclipse.technology.ohf#216 (see http://www.eclipse.org/newsgroups/register.php for access to OHF newsgroup)
