C_PRIMITIVE and C_DOMAIN_TYPE
and more!, may be the validValue() method of CDomainType has to be in the LeafContraint class, because if you want to validate primitive data, the CPrimitiveObject class dont have a validValue() method. If validValue() is in LeafConstraint then both CPrimitiveObject and CDomainType inherit validValue(). Pablo Pazos NIB - Original Message - From: Rodrigo Filgueira To: openehr-technical at openehr.org Sent: Tuesday, August 15, 2006 12:19 PM Subject: C_PRIMITIVE and C_DOMAIN_TYPE Should C_DOMAIN_TYPE classes be defined based (using) on C_PRIMITIVE? and more, are any of the C_PRIMITIVE classes used directly as a constraint to an archetype element? these questions refer to the fact that string or integers by themselves do not have any semantic meaning, they acquire meaning inside DATA_VALUE instances, do they not? So as we advance in using and understanding AM we find that more classes may be needed in the PROFILE package in order to validate DATA_VALUES. just thoughts, and doubts, we are trying to understand the model, and how it is used. If you could tell us how you use it, I believe it would be very helpful. thank you -- Rodrigo Filgueira Asistente Docente/Investigador N?cleo de Ingenier?a Biom?dica, FING - UDELAR -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060815/5767115d/attachment.html
Questions about terminology model
Hi rong, When I saw the API and the structure of the openehr_terminology_en I thought something is wrong here, then I see the Java Ref Impl of the mini termserv with your comments about methods that can't be implemented with this terminology model, here I think I'm right :D If you want we can discuss the topic on the mail list or on the wiki, I think we can correct the model in a few weeks, making an implementable and usable model/API. Cheers,Pablo. BTW: congrats for you PHD! Date: Thu, 3 Dec 2009 21:06:05 +0100 Subject: Re: Questions about terminology model From: rong.acode at gmail.com To: openehr-technical at openehr.org Hi Pablo, Yes, you are right. Code sets are language independent. See my comment in the java implementation: http://www.openehr.org/svn/ref_impl_java/TRUNK/mini-termserv/src/main/java/org/openehr/terminology/SimpleCodeSetAccess.java I think I have created an JIRA issue on this but couldn't find it now. Cheers, Rong 2009/11/28 pablo pazos pazospablo at hotmail.com: I need to implement the access for various terminologies, included the OpenEHR terminology. I've derived a class model from the openehr_terminology_en.xml but it seems this model is not compatible with the API proposed in support_im.pdf As an example, in openehr_terminology_en.xml, terminology is the only element that has a language, but in support_im.pdf, the CODE_SET_ACCESS class has an operation has_lang( lang ), but the code sets have no language to do this search. I have a question here, is it correct that a code set have a language? and code sets and codes are not language independent? I think the only language-dependent item is the description of the code, so I think that both openehr_terminology_en.xml and support_im.pdf have some bugs to fix, is it correct? And here are questions based on my ignorance, what's the difference between Group and CodeSet? and what's the difference between Code and Concept? Thanks a lot, Pablo Pazos Gutierrez Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. ___ 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 _ Keep your friends updated?even when you?re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091203/a8fef244/attachment.html
Problems with archetype internal ref
Hi,
I'm trying to support Archetype Internal Refs on my degree thesis project but I
think there is an error on the specs or on the oceans archetype Editor.
In the AOM specs, every CObject has a mandatory node_id attribute, included the
ArchetypeInternalRef.I make an archetype using Oceans Archetype Editor and the
node with the reference looks like this:
CLUSTER[at0008] occurrences matches {0..1} matches {-- Pelvis items
cardinality matches {0..*; unordered} matches { use_node ELEMENT
occurrences matches {0..3}
/data[at0001]/events[at0002]/data[at0003]/items[at0004]/items[at0012] }}
But the use_node internal reference has no node_id.
Anyone one knows where is the problem?Where can I set the intenal ref node_id?
Thanks a lot,Pablo Pazos Gutierrez
_
Windows Live Hotmail: Your friends can get your Facebook updates, right from
Hotmail?.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091206/772601a7/attachment.html
Where can I download the OpenEHR terminology?
I've tried the link from here: http://www.openehr.org/releases/1.0.2/architecture/computable/terminology/terminology.html But points to: http://www.openehr.org/releases/architecture/computable/terminology/terminology.xml And I get a 404. Thanks a lot. Pablo. http://pablo.swp.googlepages.com/ _ Windows Live: Make it easier for your friends to see what you?re up to on Facebook. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091102/056382a1/attachment.html
CEN/ISO 13606 extract tools
Hi, The only people I know that is working on 13606 is here: http://www.linkehr.com/ And they have some free tools to download from there. Cheers, Pablo Pazos Gutierrez www.simplewebportal.net Subject: Re: CEN/ISO 13606 extract tools From: timothywayne.cook at gmail.com To: openehr-technical at openehr.org Date: Tue, 17 Nov 2009 12:48:04 -0200 On Mon, 2009-11-16 at 11:04 -0200, Marcelo Rodrigues dos Santos wrote: Hi all, I created some CEN/ISO extracts and I'd like to validate these files. I'm looking for tools to work with CEN/ISO13606 extracts (parsers, extract generator, ADL editors for this reference model, XML schemas etc.). Could anyone offer help or indicate to me some references? Thanks, Marcelo. I doubt you'll find many, if any open ISO/CEN tools since those standards are not truly open. I would be happy to share some guidance off list with you since you live in a country that mandates free software by law. Cheers, Tim -- *** Timothy Cook, MSc LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == (upon request) Academic.Edu Profile: http://uff.academia.edu/TimothyCook You may get my Public GPG key from popular keyservers or from this link http://timothywayne.cook.googlepages.com/home _ Windows Live: Keep your friends up to date with what you do online. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091117/1ba9348a/attachment.html
Why ISM_TRANSITION of an ACTION is mandatory?
Hi, In the specs I see that ACTION has a mandatory relationship to ISM_TRANSITION.In my project I only use the description field of ACTION to record information about the ACTION and I don't have information to fill the ISM_TRANSITION. My question is: why the ISM_TRANSITION of the ACTION is mandatory instead of optional? Thank you,Pablo. _ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091118/aa2653ae/attachment.html
Why ISM_TRANSITION of an ACTION is mandatory?
Hi Thomas, In our implementation of a Trauma EHR, we don't have an explicit state machine with the status of the action to work with, we only have a record of what was done. Trauma is a quick care act, and the physicians only want to check what actions they do on the patient, and in this case the description of the care act is enough for our record detaile level. I understand in something like give medication in an ICU has to follow a state machine for what was planned, active, suspended, etc, but in trauma a medication is given without a plan and is a one time thing, so it can't be suspended or cancelled. I also want to know the experience of other people modeling their action care entries. Best regards,Pablo Pazos Gutierrez Date: Sun, 22 Nov 2009 19:08:32 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Why ISM_TRANSITION of an ACTION is mandatory? pablo pazos wrote: Hi, In the specs I see that ACTION has a mandatory relationship to ISM_TRANSITION. In my project I only use the description field of ACTION to record information about the ACTION and I don't have information to fill the ISM_TRANSITION. My question is: why the ISM_TRANSITION of the ACTION is mandatory instead of optional? the idea is that all Actions follow a state machine model (documented in the EHR IM spec). Even the simplest one will do this, and it is always useful to know whether the Action puts the relevant Instruction into a new state. If you know the state, you can query for all Instructions that are currently Active, Suspended, Completed etc etc. If you don't know the state, it is probably 'Active'. If we make this optional, many implementers are likely to ignore the state, but it is the single most important thing for clinical users - some people would argue that this is the most important attirbute in the whole model in fact. I am certainly interested to hear other views on this. - thomas beale _ Keep your friends updated?even when you?re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091123/2423fa81/attachment.html
Why ISM_TRANSITION of an ACTION is mandatory?
Ok, I'll do that. Thank you Thomas. Cheers, Pablo. Date: Mon, 23 Nov 2009 07:59:22 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Why ISM_TRANSITION of an ACTION is mandatory? pablo pazos wrote: Hi Thomas, In our implementation of a Trauma EHR, we don't have an explicit state machine with the status of the action to work with, we only have a record of what was done. Trauma is a quick care act, and the physicians only want to check what actions they do on the patient, and in this case the description of the care act is enough for our record detaile level. I understand in something like give medication in an ICU has to follow a state machine for what was planned, active, suspended, etc, but in trauma a medication is given without a plan and is a one time thing, so it can't be suspended or cancelled. In this case I would suggest that the state be marked as 'completed'. This ensures that later queries over the same patient record don't return these medications or interventions as being active or ongoing in any way. - thomas _ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091123/18398c40/attachment.html
Questions about terminology model
I need to implement the access for various terminologies, included the OpenEHR terminology. I've derived a class model from the openehr_terminology_en.xml but it seems this model is not compatible with the API proposed in support_im.pdf As an example, in openehr_terminology_en.xml, terminology is the only element that has a language, but in support_im.pdf, the CODE_SET_ACCESS class has an operation has_lang( lang ), but the code sets have no language to do this search. I have a question here, is it correct that a code set have a language? and code sets and codes are not language independent? I think the only language-dependent item is the description of the code, so I think that both openehr_terminology_en.xml and support_im.pdf have some bugs to fix, is it correct? And here are questions based on my ignorance, what's the difference between Group and CodeSet? and what's the difference between Code and Concept? Thanks a lot, Pablo Pazos Gutierrez _ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091127/7159bef4/attachment.html
Modeling reference ranges
Hi, I'm playing around with archetypes trying to model an observation and its reference ranges, I mean something like blood pressure and some range to define what is hypertension, but I can't found an archetype that defines a reference range for an observation. Any one has experience in modeling something like this? An archetype is the correct place to define a reference range for an observation value? Any ideas? Thak you! Cheers, Pablo Pazos Gutierrez _ Windows Live: Keep your friends up to date with what you do online. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091012/6c551283/attachment.html
Modeling reference ranges
Hi Ian, thanks for the answer. I see, so the reference range is only for lab test results. Yes, what I like to do is something that for certain observation values it display something to the physician. Blood presure was just an example, the observations I have are: - Glasgow Comma Scale: 15 is a problem - Cardiac Frequency: 60 or 100 is a problem - Breath Frequency: 10 or 20 is a problem I'll look to Rong's work. Thanks a lot! Cheers, Pablo. From: ian.mcnic...@oceaninformatics.com Date: Mon, 12 Oct 2009 23:59:32 +0100 Subject: Re: Modeling reference ranges To: openehr-technical at openehr.org CC: openehr-clinical at openehr.org Hi Pablo, The Quantity datatype in the Reference model has built-in support for Reference ranges so these do have to be modelled overtly in archetypes. See http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/data_types_im.pdf This makes sense for lab tests etc where each test will report a reference range (which are often lab/analysis method dependent) along with the results themselves. However, you are talking about something different. There is really no such thing as a reference range for blood pressure, which might indicate hypertension. The definitions of hypertension vary, over time and by locality and the diagnosis will depend on many other factors than just the blood pressure itself. I think what you may be trying to capture is some thing more like a 'trigger blood pressure' which displays an alert to the clinician or initiates some other action if a set of criteria have been reached e.g 3 readings with a diasstolic 100. This is more akin to a guideline or care pathway. You might want to have a look at the work Rong Chen has been doing using archetypes within computerised guidelines for chemotherapy. In this case the archetype does not represent actual patient data but an abstract of ALL patients who might fall within the guideline. See http://www.hst.aau.dk/~ska/MIE2009/papers/MIE2009p0653.pdf Hope this helps, Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at mcmi.co.uk Clinical Analyst Ocean Informatics ian.mcnicoll at oceaninformatics.com BCS Primary Health Care Specialist Group www.phcsg.org 2009/10/12 pablo pazos pazospablo at hotmail.com Hi, I'm playing around with archetypes trying to model an observation and its reference ranges, I mean something like blood pressure and some range to define what is hypertension, but I can't found an archetype that defines a reference range for an observation. Any one has experience in modeling something like this? An archetype is the correct place to define a reference range for an observation value? Any ideas? Thak you! Cheers, Pablo Pazos Gutierrez Windows Live: Keep your friends up to date with what you do online. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical _ Windows Live: Keep your friends up to date with what you do online. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091013/5ec28ffc/attachment.html
Modeling reference ranges
Hi Ian, thanks for the answer. I see, so the reference range is only for lab test results. Yes, what I like to do is something that for certain observation values it display something to the physician. Blood presure was just an example, the observations I have are: - Glasgow Comma Scale: 15 is a problem - Cardiac Frequency: 60 or 100 is a problem - Breath Frequency: 10 or 20 is a problem I'll look to Rong's work. Thanks a lot! Cheers, Pablo. From: ian.mcnic...@oceaninformatics.com Date: Mon, 12 Oct 2009 23:59:32 +0100 Subject: Re: Modeling reference ranges To: openehr-technical at openehr.org CC: openehr-clinical at openehr.org Hi Pablo, The Quantity datatype in the Reference model has built-in support for Reference ranges so these do have to be modelled overtly in archetypes. See http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/data_types_im.pdf This makes sense for lab tests etc where each test will report a reference range (which are often lab/analysis method dependent) along with the results themselves. However, you are talking about something different. There is really no such thing as a reference range for blood pressure, which might indicate hypertension. The definitions of hypertension vary, over time and by locality and the diagnosis will depend on many other factors than just the blood pressure itself. I think what you may be trying to capture is some thing more like a 'trigger blood pressure' which displays an alert to the clinician or initiates some other action if a set of criteria have been reached e.g 3 readings with a diasstolic 100. This is more akin to a guideline or care pathway. You might want to have a look at the work Rong Chen has been doing using archetypes within computerised guidelines for chemotherapy. In this case the archetype does not represent actual patient data but an abstract of ALL patients who might fall within the guideline. See http://www.hst.aau.dk/~ska/MIE2009/papers/MIE2009p0653.pdf Hope this helps, Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at mcmi.co.uk Clinical Analyst Ocean Informatics ian.mcnicoll at oceaninformatics.com BCS Primary Health Care Specialist Group www.phcsg.org 2009/10/12 pablo pazos pazospablo at hotmail.com Hi, I'm playing around with archetypes trying to model an observation and its reference ranges, I mean something like blood pressure and some range to define what is hypertension, but I can't found an archetype that defines a reference range for an observation. Any one has experience in modeling something like this? An archetype is the correct place to define a reference range for an observation value? Any ideas? Thak you! Cheers, Pablo Pazos Gutierrez Windows Live: Keep your friends up to date with what you do online. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical _ Keep your friends updated?even when you?re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091013/17208a5e/attachment.html
Modeling reference ranges
Hi Sam, Thanks for your answer. That's exactly what I've tried to do, look for a constraint to the reference range of a Quantity. I think I can extend my templates to support this requirement, may be using the Assertion model. I'm using a custom template model. I have seen the datatype model, that's exactly what I whant to define with archetype/template model (if it's the right place to do it, now I see the archetypes are not a good place to do so). Thanks a lot! Cheers, Pablo. From: sam.he...@oceaninformatics.com To: openehr-technical at openehr.org; openehr-clinical at openehr.org Subject: RE: Modeling reference ranges Date: Tue, 13 Oct 2009 08:42:33 +0930 Hi Pablo The issue is that you do not see the reference model attributes in the archetype editor. A Quantity data type has a normal range and other reference ranges built in. We do not set the reference ranges in archetypes as these vary and archetypes are the absolute statement about things (what could possibly be true ever, anywhere). So it is in the form or data that you will get access to the reference range. You could set it in a template (not possible in our tools as yet). Generally the reference ranges come with the results from the lab or a dynamic depending on gender, age etc. I hope this is helpful ? have a look at the data type specs for clarification. The UML is at: http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109599337877_94556_1510Report.html You will see an optional normal_range and 0..* other reference ranges as part of a root abstract class DV_ORDERED Cheers, Sam From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Tuesday, 13 October 2009 8:02 AM To: openehr-clinical at openehr.org; openehr-technical at openehr.org Subject: Modeling reference ranges Hi, I'm playing around with archetypes trying to model an observation and its reference ranges, I mean something like blood pressure and some range to define what is hypertension, but I can't found an archetype that defines a reference range for an observation. Any one has experience in modeling something like this? An archetype is the correct place to define a reference range for an observation value? Any ideas? Thak you! Cheers, Pablo Pazos Gutierrez Windows Live: Keep your friends up to date with what you do online. _ Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail?. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091013/b9b7b7fb/attachment.html
How to contribute an archetype
Hi, I have translated the Glasgow Coma Scale archetype to spanish, how can I send it to the CKM? Cheers, Pablo Pazos http://pablo.swp.googlepages.com/ _ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091025/ab04f085/attachment.html -- next part -- A non-text attachment was scrubbed... Name: openEHR-EHR-OBSERVATION.glasgow_coma.v1draft.adl Type: application/octet-stream Size: 7622 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091025/ab04f085/attachment.adl
OpenEHR-ES
Hi, We're trying to build an spanish-speakers community about openEHR , I just create a google group: http://groups.google.com/group/openehr-es We want to translate some docs and presentations to generate enough knowledge to spread the word about OpenEHR, and other EHR related concepts between latin-american and spanish people. Best regards Pablo Pazos Gutierrez http://pablo.swp.googlepages.com/ _ Keep your friends updated?even when you?re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091025/44e9772e/attachment.html
How to contribute an archetype
Hi Heather, It was attached to my previous email. Thank you. Date: Mon, 26 Oct 2009 12:45:30 +1100 From: heather.les...@oceaninformatics.com To: openehr-clinical at openehr.org Subject: Re: How to contribute an archetype CC: openehr-technical at openehr.org Hi Pablo, If you email the translation to me, I can upload it immediately. Archetype upload requires editorial access rights. Regards Heather heather.leslie at oceaninformatics.com On 26/10/2009 11:08 AM, pablo pazos wrote: Hi, I have translated the Glasgow Coma Scale archetype to spanish, how can I send it to the CKM? Cheers, Pablo Pazos http://pablo.swp.googlepages.com/ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. __ Information from ESET NOD32 Antivirus, version of virus signature database 4541 (20091025) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical __ Information from ESET NOD32 Antivirus, version of virus signature database 4541 (20091025) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- Dr Heather Leslie MBBS FRACGP FACHI Director of Clinical Modelling Ocean Informatics Phone (Aust) +61 (0)418 966 670 Skype - heatherleslie Twitter - @omowizard _ Keep your friends updated?even when you?re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091025/835786d7/attachment.html
How to contribute an archetype
Hi Heather, I think that I have the wrong archetype repository, I've downloaded all my archetypes from http://www.openehr.org/svn/knowledge/archetypes/dev/ How can I download all the archetypes from the current CKM? it has a SVN? Having two different repositories online is a bit confusing, I think the openEHR people can kill http://www.openehr.org/svn/knowledge/archetypes/dev/ and make only the current CKM the only valid openEHR archetype repository. Thanks a lot! Pablo Pazos Guti?rrez Date: Mon, 26 Oct 2009 16:18:37 +1100 From: heather.les...@oceaninformatics.com To: openehr-clinical at openehr.org; openehr-technical at openehr.org Subject: Re: How to contribute an archetype Hi Pablo, Thanks for your work. Unfortunately there are a couple of issues. One is that you have translated an archetype that is labelled as 'draft', and that is not the same as the current Glasgow Coma Scale archetype in CKM - it is nearly the same, but there are some subtle differences in description in the Motor responses section. Could you please download the archetype from CKM and update that one with the translation. I have included my recent email to the list for further clarification, below, and to give potential translators some perspective re the approach on CKM. You are very welcome to translate any archetype on CKM, but please be very aware that any archetype that is still draft could change significantly through the review process, and the translation will have to be updated after content publication - just pointing it out to try to avoid duplication of work, not to discourage. Again, many thanks Heather Original Message Subject: Re: French translation Date: Thu, 15 Oct 2009 21:16:06 +1100 From: Heather Leslie heather.leslie at oceaninformatics.com Reply-To: For openEHR clinical discussions openehr-clinical at openehr.org To: For openEHR clinical discussions openehr-clinical at openehr.org Hi Marc (and any other volunteer translators), To be honest, I'm not sure that we have any archetypes translated to French, so we really welcome your involvement. The easiest way for you to translate at present is via the Ocean Archetype Editor - instructions for translation in the Editor can be found on the CKM wiki at http://bit.ly/G2Ivi. (We have been working to enable translation (and translation review) in CKM itself but full functionality is still a little way off.) I would suggest that the best use of your time and skills would be gained from translating the published archetypes first as the content for these archetypes can be regarded as stable. Don't bother translating the archetypes currently in team review as these are clearly in flux, and will have to be redone in the relatively near future. Next priorities would be the core content archetypes eg those for the emergency summary http://bit.ly/BV5uv, but remember that any of these that are still in draft status will be changing over the next few months as they undergo review, so I'd wait a little while for those if I were you. In any case, if you plan to translate an archetype, I'd suggest you just drop me an email and let me know, so we can coordinate and make sure there is not duplication. Once you have translated an archetype it needs to be uploaded to CKM by an Editor - so currently that role resides with Ian McNicoll, Sebastian Garde or myself. So send it as an email attachment and we will ensure that it gets uploaded. Once we finish the translation functionality in CKM, we will be able to enable reviews of each translation to ensure that there is consensus about the translation as well - would you be interested in doing this at some stage in the future? Let me know if you have any questions and thanks again for your generous offer Regards Heather On 14/10/2009 1:40 AM, Marc CUGGIA wrote: French translation Dear Leslie, Thank you for your effort concerning the management of the CKM activity. I saw that in many archertypes, the french translation is often missing. I can spend a little time to fill this gap. Could you tell me how to proceed ? Im MD PhD, and work a while in the ED. Best regards. Dr Marc CUGGIA (MD, PhD, MCU-PH) Inserm U936 Facult? de M?decine, Rue du Pr L?on Bernard 35043 Rennes cedex DIM - CHU Pontchaillou, rue H. Le Guilloux 35033 Rennes Tel : +33(0)299284215 - +33(0)672025620 - Fax : +33(0)299284160 Le 13/10/09 14:14, ? Heather Leslie ? heather.leslie at oceaninformatics.com a ?crit : Dear colleagues, Just thought I'd send an update on CKM activity, with the main focus on the Emergency-related archetypes. We are anticipating that Medication review will be able to commence soon. If you are interested in participating in any Team
How to contribute an archetype
Hi Ian, Thanks a lot, I'll download them from the CKM. Cheers, Pablo Pazos From: ian.mcnic...@oceaninformatics.com Date: Mon, 26 Oct 2009 13:52:29 + Subject: Re: How to contribute an archetype To: openehr-clinical at openehr.org CC: openehr-technical at openehr.org Hi Pablo, The CKM repository is now the official openEHR repository. You can download all the current CKM archetypes via Main menu-Archetypes-Export Archetypes. You need to be registered and logged-in to see this option. You make a fair point about possibly de-commissioning the subversion repository. Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at mcmi.co.uk Clinical Analyst Ocean Informatics ian.mcnicoll at oceaninformatics.com BCS Primary Health Care Specialist Group www.phcsg.org 2009/10/26 pablo pazos pazospablo at hotmail.com Hi Heather, I think that I have the wrong archetype repository, I've downloaded all my archetypes from http://www.openehr.org/svn/knowledge/archetypes/dev/ How can I download all the archetypes from the current CKM? it has a SVN? Having two different repositories online is a bit confusing, I think the openEHR people can kill http://www.openehr.org/svn/knowledge/archetypes/dev/ and make only the current CKM the only valid openEHR archetype repository. Thanks a lot! Pablo Pazos Guti?rrez Date: Mon, 26 Oct 2009 16:18:37 +1100 From: heather.les...@oceaninformatics.com To: openehr-clinical at openehr.org; openehr-technical at openehr.org Subject: Re: How to contribute an archetype Hi Pablo, Thanks for your work. Unfortunately there are a couple of issues. One is that you have translated an archetype that is labelled as 'draft', and that is not the same as the current Glasgow Coma Scale archetype in CKM - it is nearly the same, but there are some subtle differences in description in the Motor responses section. Could you please download the archetype from CKM and update that one with the translation. I have included my recent email to the list for further clarification, below, and to give potential translators some perspective re the approach on CKM. You are very welcome to translate any archetype on CKM, but please be very aware that any archetype that is still draft could change significantly through the review process, and the translation will have to be updated after content publication - just pointing it out to try to avoid duplication of work, not to discourage. Again, many thanks Heather Original Message Subject: Re: French translation Date: Thu, 15 Oct 2009 21:16:06 +1100 From: Heather Leslie heather.leslie at oceaninformatics.com Reply-To: For openEHR clinical discussions openehr-clinical at openehr.org To: For openEHR clinical discussions openehr-clinical at openehr.org Hi Marc (and any other volunteer translators), To be honest, I'm not sure that we have any archetypes translated to French, so we really welcome your involvement. The easiest way for you to translate at present is via the Ocean Archetype Editor - instructions for translation in the Editor can be found on the CKM wiki at http://bit.ly/G2Ivi. (We have been working to enable translation (and translation review) in CKM itself but full functionality is still a little way off.) I would suggest that the best use of your time and skills would be gained from translating the published archetypes first as the content for these archetypes can be regarded as stable. Don't bother translating the archetypes currently in team review as these are clearly in flux, and will have to be redone in the relatively near future. Next priorities would be the core content archetypes eg those for the emergency summary http://bit.ly/BV5uv, but remember that any of these that are still in draft status will be changing over the next few months as they undergo review, so I'd wait a little while for those if I were you. In any case, if you plan to translate an archetype, I'd suggest you just drop me an email and let me know, so we can coordinate and make sure there is not duplication. Once you have translated an archetype it needs to be uploaded to CKM by an Editor - so currently that role resides with Ian McNicoll, Sebastian Garde or myself. So send it as an email attachment and we will ensure that it gets uploaded. Once we finish the translation functionality in CKM, we will be able to enable reviews of each translation to ensure that there is consensus about the translation as well - would you be interested in doing this at some stage in the future? Let me know if you have any questions and thanks again for your generous offer Regards Heather On 14/10/2009 1:40 AM, Marc CUGGIA wrote: Dear Leslie, Thank you for your effort concerning the management
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Erik, great idea. I have created this page: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates With a short description of our templates and how they are used in the framework -- 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 Date: Wed, 1 Dec 2010 13:24:20 +0100 Subject: GUI-directives/hints again (Was: Developing usable GUIs) From: erik.sundv...@liu.se To: openehr-technical at openehr.org CC: lincoln.moura at zilics.com.br; fabiane.nardon at zilics.com.br Hi All! There was a related discussion regarding GUI-directives/hints around june 2008, that I tried to summarize in the post http://www.openehr.org/mailarchives/openehr-technical/msg03755.html As you will see that post is somewhere in the middle of the thread, so you can find other interesting things before and after that post in the archives. Now, if I understand things correctly there is now implementatin experience from at least three projects regarding GUI-hints/directives (please add more if you know any): - Zilics (http://www.openehr.org/mailarchives/openehr-technical/msg03767.html)- GastrOs Endoscopy Application by Koray Atalag et.al. - Open EHR-Gen by Pablo Pazos et.al. What about trying to formalize some recommendations based on this experience, and perhaps even write a piece of specification draft that fits the new ADL 1.5 thinking regarding templates and archetypes. Would it be possible for anybody from any of the three projects to start a wiki page to describe your GUI-directives/hints and then we could compare them all and get a discussion going on the list possibly followed by some community driven development of a draft specification to try out. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 ___ 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/20101202/cf288cb9/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Ian, I think there is a way to customize the GUI without (direct) manual manipulation. If an application can generate expressive HTML, you can do all the customization with CSS (a good web designer can make this work for us). For expressive HTML I mean, HTML code with tags, ids and classes that let you customize every aspect of the way each template/archetype node is displayed: position, size, labels, etc. This is the only way to do GUI customization for projects that generate the GUI on the fly and that are web-based. (like the Open EHR-Gen). Example: This is an inexpressive HTML: form .. a label: input type=text name=xxx ... / input type=submit .. / /form This is an expressive HTML: form id=openEHR-EHR-SECTION.soap class=SECTION div class=SECTION div class=OBSERVATION label forxxxa label:/label input type=text name=xxx ... / /div /div div class=actions input type=submit .. / /div /form Other idea is to use some CMS-like functions, like dragging and dropping generated components on different zone of a web page layout. So, each user can have its own customized GUI. We can create a couple of these layouts, based on some GUI patterns and good practices, and adjust our GUI generators to use one layout or the other to see if the page generated is usable or not. Our Open EHR-Gen Framework has some of this ideas already developed (each node in our GUI-templates have a pageZone attribute that indicates in wich zone of the web layout, this node has to be displayed). See: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates -- 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 From: Ian.McNicoll at oceaninformatics.com Date: Fri, 3 Dec 2010 10:17:57 + Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) To: timothywayne.cook at gmail.com; openehr-technical at openehr.org Hi Tim, I do tend to agree with you that GUI generation can be useful as a startpoint, but that most real-world applications will demand much a richer GUI that will need subsequent, manual intervention. There are 2 other areas where auto-GUI generation can be useful. One is in the area of user-defined forms, a common feature in many applications. The other is in the area of requirements gathering and prototyping, either for EHR aplication development or wider standards development work. Dr Ian McNicoll office / fax +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 3 December 2010 09:35, Tim Cook timothywayne.cook at gmail.com wrote: On Fri, 2010-12-03 at 10:21 +0100, Pariya Kashfi wrote: Dear Tim, Thank you for your response Could you please provide me with more detail about this? Would it need manual adjustment of any css/style file or would it be totally dynamic? Well, you can generate dynamic UIs; but I really doubt that they are useful in any real world situation. :-) Is it based on the templates, archetypes, or both? Archetype based; with a layer of templating for local constraints. I am trying to summarize the answers from different contributors, so that we can have a better image of the situation when it comes to GUI generation. Have you considered that it would be a good idea to conform to MSCUI? --Tim ___ 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101203/497f114b/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
I agree with your comment, but only for v1.5 templates and archetypes. For v1.4 I think that GUI Templates must reference archetypes ids and paths. -- 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 Date: Wed, 8 Dec 2010 15:41:11 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) On 08/12/2010 15:26, pablo pazos wrote: May be if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems. I think the only thing in common of those two type of template is that they reference a set of archetypes to do something. I would suggest that the GUI templates just reference paths found in the openEHR template. - thomas ___ 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/20101208/679651d3/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Thomas, Correct me if I'm wrong: If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different. So an example inheritance/specialisation hierarchy in a running system could be: A bunch of clinical archetypes (mostly international, and some regional ones) ...are used as building blocks in... a structural template (maybe national/regional) often creating a composite SECTION or COMPOSITION [add more structural layers if useful] all correct up to here ...that is then annotated with GUI-hints by... a set of GUI templates with each template fitting a different recurring use case not forgetting that GUI is only one place to deploy a template (e.g. messages etc), so there might be some other kind of 'deployment templates' as well. ...for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools You describe a very big picture and sounds logic, so we'll have: Level 1: archetypes (for model complete data sets about a concept, general and specialized ones)Level 2: structural templates (for localized use of archetypes, general and specialized templates)Level 3: define the use of the structural templatesGUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data. Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA ...). Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates. Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc. Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions. ... If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section? I have a couple ideas that can improve what we've done on the EHR-Gen framework. If you want I can put them in the wiki. Cheers, -Pablo. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101214/13dec05e/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
On 15/12/2010 00:57, pablo pazos wrote: Hi Thomas, ... You describe a very big picture and sounds logic, so we'll have: Level 1: archetypes (for model complete data sets about a concept, general and specialized ones) Level 2: structural templates (for localized use of archetypes, general and specialized templates) Level 3: define the use of the structural templates GUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data. Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA ...). to do non-openEHR message syntaxes, it requires not just another 'template' (in fact, not much be needed here), but a transformation from the operational template (OPT) form to the target form, e.g. CCR XSD or whatever. Doing futurology here, we could have these mapping rules defined inside the Message Templates, or may be just referencing wich tranformation to use (the output syntax) will suffice. But I'm not sure what will be the inside of one of these templates. Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates. Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc. Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions. ... I am not sure what some of these would look like, but I suspect they will come into existence one day... I'm not sure neither, but I'm sure these templates will be part of any openEHR-based EHR. -Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101215/09bc6d96/attachment.html
Adding a new method to the Archetype class
Hi Thomas, I was thinking about your example with blood presure:/data/events[at0006]/data/items[at0004] - human readable form: /data/events[any event]/data/items[Systolic]/data/events[at0031]/data/items[at0004] - human readable form: /data/events[Postural change]/data/items[Systolic] You say that the meaning of each node is given by the path, because it determines the context of each node.But if you have diferent meanings, I think that different ontology terms are needed for each node, but the ontology terms are indexed by the nodeID, instead of the node path. I've an Instruction archetype with a constraint of DvText in the archetype, this example is like the one mentioned by Rong, this node has no nodeID, its path is /narrative, so I can't find a term in the ontology to show the label for this field on the GUI, because I need the nodeID. May be the ontology mapping must be something like ont[lang][pathToAOMNode] instead of ont[lang][AOMnodeID], What do you think? Best regards,Pablo Pazos Gutierrez From: pazospa...@hotmail.com To: ref_impl_java at chime.ucl.ac.uk; ref_impl_java at openehr.org Subject: RE: Adding a new method to the Archetype class Date: Fri, 29 Jan 2010 22:39:17 -0300 Thanks a lot Thomas, Sometimes I'm a little hard-to-understand things, thanks for the patience :D The problem I found in our implementation is that we are not saving the AOM paths in the RM nodes. Now I'm fixing this bug. For the issue with internal refs with no nodeID, do you have taken a look to this on the Archetype Editor?Rong: are you aware of this possible issue on the ADL parser? Best Regards,Pablo. Date: Fri, 29 Jan 2010 10:33:00 + From: thomas.be...@oceaninformatics.com To: ref_impl_java at openehr.org Subject: Re: Adding a new method to the Archetype class On 29/01/2010 06:03, pablo pazos wrote: Hi Thomas, I think I understand your point and Rong's too, but I have some questions to you both. If one constraint is reused inside the same archetype, all constraints with the same nodeID will be semantically equivalent, is this correct? So, in terms of semantics RM validation against an archetype node it will be the same if I check to one node or another (that have the same nodeID). I think this post rm creation kind of validation against an archetype is needed to make semantic interoperability work. May be my solution is not the optimal, but I think some kind of openehr protocol to do this is needed. the 'meaning' of a node is given by its path from the root, not just the node id. So you can have two nodes whose node_id is at0004 for 'systolic pressure', but the paths are as follows: /data/events[at0006]/data/items[at0004] - human readable form: /data/events[any event]/data/items[Systolic] /data/events[at0031]/data/items[at0004] - human readable form: /data/events[Postural change]/data/items[Systolic] you can see here two different data points, both having node_id at0004, but the paths tell you the real meaning For Rong's point I suppose that if I have a RM node that don't have a nodeID, this node must be a primitive node, because for ELEMENT, CLUSTER and ITEM_STRUCTURE, ENTRY, SECTION, etc, I think all had to have a nodeID. Correct me if I'm wrong. the rule is that a node_id is needed: on any node that is a child of a multiple-valued attribute (even if there is only one child for now) any nodes of a single-valued attribute, where there are multiple alternative nodes, and they can't otherwise be distinguished by RM type (e.g. DV_QUANTITY). - thomas Hotmail: Trusted email with Microsoft?s powerful SPAM protection. Sign up now. _ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100130/9c76ff01/attachment.html
AMIA standards news source
Great news, But I would like to see openehr in the sdo list :Dhttps://www.amia.org/standards-development-organizations Pablo Pazos Guti?rrezhttp://informatica-medica.blogspot.com/ Date: Wed, 12 May 2010 00:27:10 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org; openehr-clinical at openehr.org Subject: AMIA standards news source A new and useful resource relating to standards.AMIA is now publishing a twice yearly newsletter as a resource of news from various SDOs. Dipak Kalra is the principal editor, and the first issue was published this weekend. https://www.amia.org/standards-standard-letter-from-the-editor - thomas beale _ Hotmail: Trusted email with Microsoft?s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100512/d1ce5b41/attachment.html
Why is OpenEHR adoption so slow?
Hi Seref and Shinji, I share your opinions. Once in a while, we need discussions like this, since we have to lead ourselves somewhere and combine efforts if we want to support the difussion and adopton of the standard. The domain is complex, the problem is complex, the solution must be complex, but if we add the complexity of the standard to the complexity of understanding another language (the specs are english only), we have a serious problems for a worldwide adoption. I share Shinji's vision, we must support and encourage regional OpenEHR communities, specs translation, and open source multilingual up-to-date tools (most tools available are: or not multiligual or the translations are horrible, or not open source, or not updated recently). I think regional communities can create courses, resources, materials, etc... and share them with other communities, throught OpenEHR foundation. Guidelines to do this must be set from the OpenEHR Foundation Boards (I think they are there to lead the community, to encourage the spread and adoption of the standard, I can't remember the last time I saw an email of the OpenEHR Boards in the mailling lists). Within those guidelines, we can be coordinated, and maybe set year-based goals. And once a year or two we can make some event to share our experiences and progress from our local communities (can be local or regional events, since for most of ours it's hard to travel so far). These ideas are not new, just look at the HL7 coutry based structure. I know this words may sound hard to someone, I just want to support the success of the standard, but I think if we keep doing things the same way, we'll end with a high quality standard with no one to implement it. Kind regards, -- A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ S?gueme en twitter: http://twitter.com/ppazos Date: Tue, 2 Nov 2010 22:25:17 +0900 Subject: Re: Why is OpenEHR adoption so slow? From: sk...@moss.gr.jp To: openehr-implementers at openehr.org Hi Pablo, I also think regional community is necessary for this project. I launched openEHR.jp in 2007 in Japan. This is the first regional community of the openEHR project. We have provided Japanese translation and promotion for multilevel clinical modeling technology. We have implemented on Ruby as OSS and been trying national intractable disease surveillance database by openEHR technology. Your idea, to make a guideline is interesting. We will also try to do it. Cheers, Shinji KOBAYASHI Date: Tue, 2 Nov 2010 12:32:56 + Subject: Re: Why is OpenEHR adoption so slow? From: serefari...@kurumsalteknoloji.com To: openehr-implementers at openehr.org CC: openehr-implementers at chime.ucl.ac.uk; openehr-clinical at openehr.org; openehr-clinical at chime.ucl.ac.uk; openehr-technical at chime.ucl.ac.uk Hi Pablo, A very useful insight into the issues indeed. This is one topic that may end up being a quite long discussion, but I feel it is a topic that is worth laying out, not only today, but every couple of years or so, to see where we are. I'll provide my personal views here. openEHR is not a small specification. It is not a simple one either. Considering the problem it is trying to solve, I do not expect it to be. Therefore, the complexity of implementation is significant. The nature of the problem openEHR is trying to solve inevitably creates the blind men and the elephant situation http://en.wikipedia.org/wiki/Blind_men_and_an_elephant In explaining what openEHR is, we are faced with the problem of communicating the whole picture. In my experience, partial views or decriptions of openEHR lead to confusion, even if every bit of information provided is correct. Technical people and clinicians alike have a hard time seeing the big picture, and who can blaim them? The picture is really, really big. Be warned: the kind of statements I've just started to make are usually perceived so that one gets the message this needs to change. No. When I say openEHR is complex, openEHR is big, openEHR is not easy to implement, I don't mean openEHR is more complex than it needs to be, or openEHR is bigger than it needs to be, or openEHR is harder than it should be to implement. We are attempting to solve a huge problem, and complexity of the solution will enevitably rise in response. The instinct to simplify the solution usually cripples the solution by pruning its support for less frequently required features, but most of the time, this leads to an unsatisfactory outcome. Surprisingly, everyone seems to follow the instinct. In my opinion, tooling and education are the two most important fronts we need to make progress. The mechanics of an MRI is very complex, and yet, due to way it was implemented, it is a practical, useful clinical tool. The implementation of the very complex solution is designed so that without knowing anything
Why is OpenEHR adoption so slow?
deliverables (none of which are anything like perfect today, but the point is that a reasonable process is in place) For this reason, the openEHR Foundation and IHTSDO have been in talks to determine what kind of cooperation could occur in the future, which would a) allow openEHR to work within or alongside the IHTSDO global organisational structure and b) enable IHTSDO to take better advantage of the openEHR knowledge engineering technology, in particular terminology integration. That will be great, more tooling and terminology integration are two things to improve in OpenEHR, it's a good oportunity to do so. These discussions have not yet completed, but some kind of announcement could be expected in the near future. If some better organisational and funding structure can be created, aligned with an accepted standards body, then I think the whole thing will accelerate very fast. - thomas beale Kind regards, Pablo Pazos. http://informatica-medica.blogspot.com/ On 02/11/2010 16:29, pablo pazos wrote: Hi Seref and Shinji, I share your opinions. Once in a while, we need discussions like this, since we have to lead ourselves somewhere and combine efforts if we want to support the difussion and adopton of the standard. The domain is complex, the problem is complex, the solution must be complex, but if we add the complexity of the standard to the complexity of understanding another language (the specs are english only), we have a serious problems for a worldwide adoption. I share Shinji's vision, we must support and encourage regional OpenEHR communities, specs translation, and open source multilingual up-to-date tools (most tools available are: or not multiligual or the translations are horrible, or not open source, or not updated recently). I think regional communities can create courses, resources, materials, etc... and share them with other communities, throught OpenEHR foundation. Guidelines to do this must be set from the OpenEHR Foundation Boards (I think they are there to lead the community, to encourage the spread and adoption of the standard, I can't remember the last time I saw an email of the OpenEHR Boards in the mailling lists). Within those guidelines, we can be coordinated, and maybe set year-based goals. And once a year or two we can make some event to share our experiences and progress from our local communities (can be local or regional events, since for most of ours it's hard to travel so far). These ideas are not new, just look at the HL7 coutry based structure. I know this words may sound hard to someone, I just want to support the success of the standard, but I think if we keep doing things the same way, we'll end with a high quality standard with no one to implement it. ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101104/1fc3b269/attachment.html
Why is OpenEHR adoption so slow?
Hi Thomas, I see we agreed in much of the points, I hope to see other's visions. Governance is a good issue to discuss with the community, but I can't see any governance if the OpenEHR boards are distant from the community, and do not understand their real needs. What I was really talking from the begining of this discussion is that people, institutions, and goverments have needs that OpenEHR can satisfy, but at the same time, OpenEHR as a whole is not aware of their needs, or is not taking actions to do something. There are a lots of ways of funding, just yesterday, we had an event here in Uruguay of ICT developments in healthcare (we showed our Open EHR-Gen Framework and people was amazed about the concept), there was a man called Bob Mayes from AMIA, and their are launching a subarea called GHiP to build and support communities that solve problems in healthcare informatics (with funding from Rockefeller and Bill Gates foundations, tehy have a buck or two :D). GHiP may be a good place to find some cash to build a governance program to the regional OpenEHR communities, and to support development and objective acomplishment in those communities. The governance program must have an item on how to spend the funding, and this item must be agreed by the community. It'd be a good idea if we create some section on the web or the wiki, where we can write some thoughs on the governance subject, also we can put some governance ideas from other communities, discuss them, and see if the community agree them. Again, without the involvement of the boards, this will be a dead-before-born subject. Again, I think we can build some money to improve the tools, like making courses, events (like the IHE Connectathon), selling books, t-shirts, coffe cups, etc (donations are always welcome). I'm against a paid membership, it closes a community that claims to be open, this is not a gym :D well, its why we never did that. I think your ideas are good, the only concern I have is that I think there still has to be a sufficiently strong central part of the organisation to help organise materials, resources, and run the governance structure; at the moment there is not enough funding to do what would be needed to support local orgs. But I would very much like to see openehr.cl, .br, .uy, etc. Just an idea: I think the Service Model is very green yet, but when it go a little more mature, we can make automated tests to test the implementations, and they can have an OpenEHR certificate that the software meets the specification (a paid certificate). we can already test with XML schemas. You are right, the service models will be a key basis for conformance testing, but it will take some more time to get the required maturity. - thomas -- Atte. A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ S?gueme en twitter: http://twitter.com/ppazos -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101104/37279bbe/attachment.html
Why is OpenEHR adoption so slow?
Great Thomas, I'll put there some ideas to discuss with the community. -- Atte. A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ S?gueme en twitter: http://twitter.com/ppazos Date: Mon, 8 Nov 2010 00:30:16 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Why is OpenEHR adoption so slow? Here is a wiki page for governance discussion - http://www.openehr.org/wiki/display/oecom/Community+Governance Bob Mayes is a great guy by the way, he worked for many years in Zimbabwe. - thomas On 05/11/2010 01:21, pablo pazos wrote: Hi Thomas, I see we agreed in much of the points, I hope to see other's visions. Governance is a good issue to discuss with the community, but I can't see any governance if the OpenEHR boards are distant from the community, and do not understand their real needs. What I was really talking from the begining of this discussion is that people, institutions, and goverments have needs that OpenEHR can satisfy, but at the same time, OpenEHR as a whole is not aware of their needs, or is not taking actions to do something. There are a lots of ways of funding, just yesterday, we had an event here in Uruguay of ICT developments in healthcare (we showed our Open EHR-Gen Framework and people was amazed about the concept), there was a man called Bob Mayes from AMIA, and their are launching a subarea called GHiP to build and support communities that solve problems in healthcare informatics (with funding from Rockefeller and Bill Gates foundations, tehy have a buck or two :D). GHiP may be a good place to find some cash to build a governance program to the regional OpenEHR communities, and to support development and objective acomplishment in those communities. The governance program must have an item on how to spend the funding, and this item must be agreed by the community. It'd be a good idea if we create some section on the web or the wiki, where we can write some thoughs on the governance subject, also we can put some governance ideas from other communities, discuss them, and see if the community agree them. Again, without the involvement of the boards, this will be a dead-before-born subject. Again, I think we can build some money to improve the tools, like making courses, events (like the IHE Connectathon), selling books, t-shirts, coffe cups, etc (donations are always welcome). I'm against a paid membership, it closes a community that claims to be open, this is not a gym :D well, its why we never did that. I think your ideas are good, the only concern I have is that I think there still has to be a sufficiently strong central part of the organisation to help organise materials, resources, and run the governance structure; at the moment there is not enough funding to do what would be needed to support local orgs. But I would very much like to see openehr.cl, .br, .uy, etc. Just an idea: I think the Service Model is very green yet, but when it go a little more mature, we can make automated tests to test the implementations, and they can have an OpenEHR certificate that the software meets the specification (a paid certificate). we can already test with XML schemas. You are right, the service models will be a key basis for conformance testing, but it will take some more time to get the required maturity. - thomas -- Atte. A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ S?gueme en twitter: http://twitter.com/ppazos ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Thomas Beale Chief Technology Officer, Ocean Informatics Chair Architectural Review Board, openEHR Foundation Honorary Research Fellow, University College London Chartered IT Professional Fellow
Why is OpenEHR adoption so slow?
Hi All, yesterday I've written some random ideas to create an OpenEHR governance program, to help the creation and development of regional OpenEHR communities, and coordination with those communities. It would be nice if you can take a look at the ideas and make comments about them, or add your own ideas if you note something is missing. http://www.openehr.org/wiki/display/oecom/Community+Governance -- 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 From: pazospa...@hotmail.com To: openehr-technical at openehr.org Subject: RE: Why is OpenEHR adoption so slow? Date: Sun, 7 Nov 2010 22:22:32 -0300 Great Thomas, I'll put there some ideas to discuss with the community. -- Atte. A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ S?gueme en twitter: http://twitter.com/ppazos Date: Mon, 8 Nov 2010 00:30:16 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Why is OpenEHR adoption so slow? Here is a wiki page for governance discussion - http://www.openehr.org/wiki/display/oecom/Community+Governance Bob Mayes is a great guy by the way, he worked for many years in Zimbabwe. - thomas On 05/11/2010 01:21, pablo pazos wrote: Hi Thomas, I see we agreed in much of the points, I hope to see other's visions. Governance is a good issue to discuss with the community, but I can't see any governance if the OpenEHR boards are distant from the community, and do not understand their real needs. What I was really talking from the begining of this discussion is that people, institutions, and goverments have needs that OpenEHR can satisfy, but at the same time, OpenEHR as a whole is not aware of their needs, or is not taking actions to do something. There are a lots of ways of funding, just yesterday, we had an event here in Uruguay of ICT developments in healthcare (we showed our Open EHR-Gen Framework and people was amazed about the concept), there was a man called Bob Mayes from AMIA, and their are launching a subarea called GHiP to build and support communities that solve problems in healthcare informatics (with funding from Rockefeller and Bill Gates foundations, tehy have a buck or two :D). GHiP may be a good place to find some cash to build a governance program to the regional OpenEHR communities, and to support development and objective acomplishment in those communities. The governance program must have an item on how to spend the funding, and this item must be agreed by the community. It'd be a good idea if we create some section on the web or the wiki, where we can write some thoughs on the governance subject, also we can put some governance ideas from other communities, discuss them, and see if the community agree them. Again, without the involvement of the boards, this will be a dead-before-born subject. Again, I think we can build some money to improve the tools, like making courses, events (like the IHE Connectathon), selling books, t-shirts, coffe cups, etc (donations are always welcome). I'm against a paid membership, it closes a community that claims to be open, this is not a gym :D well, its why we never did that. I think your ideas are good, the only concern I have is that I think there still has to be a sufficiently strong central part of the organisation to help organise materials, resources, and run the governance structure; at the moment there is not enough funding to do what would be needed to support local orgs. But I would very much like to see openehr.cl, .br, .uy, etc. Just an idea: I think the Service Model is very green yet, but when it go a little more mature, we can make automated tests to test the implementations, and they can have an OpenEHR certificate that the software meets the specification (a paid certificate). we can already test with XML schemas. You are right, the service models will be a key basis for conformance testing, but it will take some more time to get the required maturity. - thomas -- Atte. A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com
ISO 21090 data types too complex?
Hi All, I think this is a good intelectual interchange, but I really don't know what conclussions will reach. From outside I see people comparing positions and opinions, instead of searching some common point of harmonization. Instead we talk about formats and ways of modeling (it's like the windows vs. linux discussion). Reality is complex, and there are many ways of modeling reality, none is bad when it has a good utility. My experience is that the HL7 ways of modeling things comes from representing XML Schemas in an object oriented way, but is not an schema, nor an UML. When I need to use some HL7 message or a CDA, I just simply model the RIM or the CDA in UML, and implement that. Yes, it would be nicer if the model was already UML, but I know I'm a small ant, and I can't tell a big elephant to change. So I work a little harder to get things done, and it works. In the HL7 UML models I've done, I get rid of a lot of (I think) unnecesary classes, in HL7 dataypes I've only the CD and CS classes to represent codes, I get rid of GTS and use SETTS, for IVLPQ I just use IVLT. When it come to structures like SET, IVL, LIST and BAG, I don't use ANY as a superclass. I separate real datatypes from structures. Just my grain of sand. -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101109/e3ec7a07/attachment.html
ISO 21090 data types too complex?
Hi Charlie, Alongside that I would say that these architectural and process discussions are valuable - There is nothing so practical as a good theory [1] -- interestingly Kurt Lewin was as interested in how to find good theories, as in maintaining a productive balance between theory and practice. My hope is that the healthcare IT community (Ants, elephants and the rest of the menagerie) delivers increasing value while continuing to learn together and from each other. I have some phrases on my own ;) 1. Practical philosofy is just a contradiction, like in army intelligence. 2. All models are wrong. 3. Perfection doesn't exist. I am sure that the learning will involve sacred cows being challenged and passed over, and will involve some discomfort as well as delight. It will involve engineering, economics, politics, personalities, and more Yes, but we cannot make a revolution in every step we take, because: 1. It's has an enourmous cost 2. We see the tree and not the forest We have to find what we have in common in order to make a stronger community, if not, we are just ants that can't work together, and destined to die of hunger. My opinion is that today we have to work to make a stronger community, working on a common objetive. May be then we can make a big anthill of the size of an elephant. Kind regards, Pablo. all the best Charlie [1] http://www.infed.org/thinkers/et-lewin.htm On 9 November 2010 12:13, pablo pazos pazospablo at hotmail.com wrote: Hi All, I think this is a good intelectual interchange, but I really don't know what conclussions will reach. From outside I see people comparing positions and opinions, instead of searching some common point of harmonization. Instead we talk about formats and ways of modeling (it's like the windows vs. linux discussion). Reality is complex, and there are many ways of modeling reality, none is bad when it has a good utility. My experience is that the HL7 ways of modeling things comes from representing XML Schemas in an object oriented way, but is not an schema, nor an UML. When I need to use some HL7 message or a CDA, I just simply model the RIM or the CDA in UML, and implement that. Yes, it would be nicer if the model was already UML, but I know I'm a small ant, and I can't tell a big elephant to change. So I work a little harder to get things done, and it works. In the HL7 UML models I've done, I get rid of a lot of (I think) unnecesary classes, in HL7 dataypes I've only the CD and CS classes to represent codes, I get rid of GTS and use SETTS, for IVLPQ I just use IVLT. When it come to structures like SET, IVL, LIST and BAG, I don't use ANY as a superclass. I separate real datatypes from structures. Just my grain of sand. -- 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 -- Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel +44 1743 232278 / +44 7808 570172 skype: charliemccay linkedin:charliemccay ___ 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/20101109/9fb9cc92/attachment.html
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hi, I would also concur with your statements about the ENTRY sub types, as Sam mentioned we have built an INSTRUCTION index that tracks the current state/care flow step of instructions and their associated ACTIONs providing efficient access to this information. This complexity may be tackled with a good Service Model ,when it's completed. I think that we are looking too much at the model to solve all our problems, but we have a Service Model in draft status that can help to solve issues on the using of the model. The effort required to implement this would have been much greater if these classes were not specifically modelled. Obs., Eval., Inst. Act. are a great ontologic division of the clinical information, with them it'seasy to understand and easy to map to real concepts, I doubt that removing them from the model can help in any way. If these classes weren't modelled, we have to model them in all of our implementations, that's a waste of good modelling. just a couple of opinions. Kind regards, Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101112/619f5ade/attachment.html
Why is OpenEHR adoption so slow?
Hi Erik, Hi! On Fri, Nov 5, 2010 at 10:03, Thomas Beale thomas.beale at oceaninformatics.com wrote: there are zero paid openEHR people, full-time or part-time. That is not such a useful way of looking at openEHR funding. There are a lot of people working with openEHR on paid time during working hours. They are just not funded by the openEHR foundation. This situation is the same for many open source projects etc. Also, there are a lot of people working with openEHR with no payment at all, and the difficulties of having to study the specs, and little tooling and open projects that are not updated with some frequency. That was the whole point of the discution. There were a lot of people that start working with openEHR, but the cost of understand the specifications, trying software (incomplete or not updated), and the complexity of building something based on openEHR that realy works, just discourages people. And we need to do something to change this reality (if we want openEHR be widely adopted). If you define openEHR people as people funded by the foundation you are automatically excluding most of the community from being openEHR people. That might not be the smartest thing to do. Is just people (like us) that works with openEHR. Too often I hear openEHR needs funding with the accompanying thought that the foundation itself needs a lot of money. Yes the foundation might need a little money for server maintenance costs (if we don't want to use free services) and for trademark registrations etc. But the real need is working hours, not money. We need people that update the tools and software projects with some regularity. Yes, it's working hours, that must be payed some way... not everyone works on a university that pays people to investigate on openEHR. Certain organisational behaviours make people and companies donate working time, while other behaviours do the opposite. Some behaviours get the time donations ending up within the original project, other behaviours result in related projects more using and indirectly contributing to the project via related but organisationally independent projects. Not every organization can do this. The reality in here in South America is very diferent to the one you mention. There are things that simply cannot be made without funding, in the other hand, we can't wait to see when openEHR is got to be widely adopted, so I start this discution to see: 1. where are we going? 2. is it worth to invest my free time in this standard or I have to look elsewhere? Many other volunteer organisations understand this difference better than what the openEHR foundation seems to do, at least judging from the few signals one can receive from the not-so-community-present foundation board that has nobody to formally answer to but themselves. In a volunteer project it can be quite OK with natural self appointed leaders, often the founders, but it then has to be matched with other attitudes or safeguards such as... - being very good at communicating and willing to actively explain and discuss decisions - the ability for any participant to branch of and take (a copy) of invested time (work) with them, if the leadership becomes poor ...and so on. I agree. The people who currently put some effort into openEHR, such as myself, are working on exactly the same basis as anyone else in the community. We are just crazy enough to spend more time on it;-) There are a lot of completely sane reasons for investing time in openEHR. I for example believe Ocean Informatics would not at all have been getting assignments all around the globe if it had not chosen to invest time in open specifications. Very few would have heard of that little Australian company. (On the other hand, it could probably have been an even bigger company if everybody, not just a few, within that company understood open source business models better.) Not everyone that is investing free time on openER works in a company that can made some kind of profit. To get back to the real issue of slow openEHR adoption, I believe Seref is closest to the problem: a system trying to do everything openEHR tries to in a well engineered way, really becomes an elephant. It takes time to properly implement an elephant from scratch, especially including all supporting systems. The two organisations that could have provided a real working open implementation of that elephant first would probably have been UCL and Ocean Informatics. Now, instead of joining forces on that, they have both been running their own competing commercial closed source implementation projects (OK UCLs were probably more 13606 than openEHR, but you get the point). They are of course both fully entitled to do so, and it's great that the specifications themselves are open, but I believe it has delayed the arrival of an open demonstrator platform that people can use to
More on ISO 21090 complexity
shorter Tom Beale: Only by ignoring use cases can one design usable data types? I think is more like you don't have to look only the use cases to design usable data types I agree with this vision. Because we can't think of all use cases, so we can never create datatypes that consider all posible cases. So, we need to think more general solutions, seeing not only the use cases. - Pablo. heh. XML forever, it will solve every problem in the world. Just if everyone else does it 'my' way, we'll be right. there is a quote that says XML is like violence. If it doesn't solve your problem, you're not using enough of it. ;) anyway, I prefer ISO dates whenever possible ___ 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/20101118/b45e3a16/attachment.html
More on ISO 21090 complexity
Just one more thought about this. When someone design a custom software system, the information model is not only based on use cases. We all know about general software quality characteristics that we have to think about, like Usability, Maintainability (modifiability, adaptability, etc), Completeness, Conciseness etc, etc (http://en.wikipedia.org/wiki/Software_quality#Maintainability) (this are the basics of software engineering, nothing new to us). So, we have to think of something that:reach something that meets the use cases (complete, adds complexity),but it is also cocise (only needed things, must be simple),and maintainable (generic, good organization, simple extend and change (adapt to other realities that may be not covered by the use cases))etc ... So, the use cases are a part of the puzzle, of course are the base of the design, but not the olny piece of the final puzzle (if we want quality). Kind regards,Pablo. shorter Tom Beale: Only by ignoring use cases can one design usable data types? I think is more like you don't have to look only the use cases to design usable data types I agree with this vision. Because we can't think of all use cases, so we can never create datatypes that consider all posible cases. So, we need to think more general solutions, seeing not only the use cases. - Pablo. heh. XML forever, it will solve every problem in the world. Just if everyone else does it 'my' way, we'll be right. there is a quote that says XML is like violence. If it doesn't solve your problem, you're not using enough of it. ;) anyway, I prefer ISO dates whenever possible ___ 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101119/195afbc0/attachment.html
More on ISO 21090 complexity
It's hard get both: standard by consensus and to base standards on good design practices. I think the point of the discussion is: what model (or way of modeling) is good and why? On one hand we have the HL7 way of modeling things, that do not follows the best known practices but is accepted by many parties. (HL7 models are tight coupled with XML Schemas, for exmple, the choice construcor in the diagrams is a bad way of modeling things that can be modeled better with subclassing in UML, as every developer that works with HL7 v3 knows, this adds complexity to the development). In the other hand we have some models that follow the best design practices, but are acepted by a group of friends. The strong point in one is the weak point in the other. So, in reality, we have to live with a god and with many atheists, and believe in both. -- 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 Subject: Re: More on ISO 21090 complexity To: openehr-technical at openehr.org CC: openehr-technical at openehr.org From: hammo001 at mc.duke.edu Date: Fri, 19 Nov 2010 14:54:32 -0500 Tom, Now I know why HL7 has so much trouble. -- just basic god practice. Shouldn't god be capitalized? I think HL7 needs to pay Tom a consulting fee - for all the advice. W. Ed Hammond, Ph.D. Director, Duke Center for Health Informatics Thomas Beale thomas.beale at oce aninformatics.com To openehr-technical at openehr.org Sent by: cc openehr-technical -bounces at openehr. Subject org Re: More on ISO 21090 complexity 11/18/2010 06:38 AM Please respond to For openEHR technical discussions openehr-technica l at openehr.org On 18/11/2010 06:51, Vincent McCauley wrote: From the point of view of a clinical datatype implementer who has to write actual code, the ISO dataypes provide a level of detail that is both required and sufficient. They are definitely not simple in their definition but are mostly simple in terms of concept representation. The atom at one time looked simple and remains so in concept, though in fact having considerable underlying complexity. The level of detail required depends on your use case which seems to be a major contributor to your divergence of opnion. I see this as one of the major problems of HL7 actually. It seems to think that everything should be driven by use cases. This is not the case. The general drive in all engineering and software development is to have layers of highly reusable elements that work in all situations. Thus the design concept of 'Integer' and 'String' in a programming language is not specific to any particular used. Neither should the concept of 'codedtext', 'ordinal' or 'physical quantity'. The idea that a set of such data types should be built not just for messaging, but apparently with features for other more specific use cases is plain wrong. It is not good modelling. Contextual (i.e. use-case specific) features should always be added in specific classes / locations in models dealing with those specific use cases. The openEHR data types are designed like that - it is just basic god practice. They can be (and are) used in messaging, storage, GUI, business logic. Context specific features are modelled and coded where they are relevant
new openEHR-based framework
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101124/b61e1b2a/attachment.html
new openEHR-based framework
Hi, I think I must add some context to this email. Architecture: http://www.slideshare.net/pablitox/open-ehrgen-un-framework-para-crear-historias-clnicas-electrnicas, page 18 GuiGen:is a GUI generator based on archetypes, our own XML templates (with GUI directives), i18n config files, and RM structures.the GUI is all HTML (the framework is for building web ehr apps)the GUI is generated in real time (we also thought an offline generation of static GUI can be better to reach good performance, but the real time generation could help on testing things more quickly).the GuiGen can handle structured data and multiple occurrences of archetype nodes. here are some screenshots: https://docs.google.com/leaf?id=0B27lX-sxkymfYzI5YzBjMWEtZGI5My00NGNiLThmNmQtOGNhZmE0ZWEwNDllhl=enhere you can find the templates: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen/templates/hce/traumaand the referenced archetypes: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen/archetypes/ehrData Binder:this component creates RM structures from plain data from user's input, archetypes, templates and terminology.in the process of creating the structures, it also validates data against archetypes constraints.it creates structured data from plain data, and create multiple instances for archetype nodes with multiple occurrences.it doesn't handle the whole datatype package, but it supports the more common datatypes like text, coded text, quantities, count, ordinal, dates, boolean, and a few more.all the binding and validation is done on the fly.CKM integration:we have our local CKM in file systemArchetypeManager and TemplateManager load archetypes and templates on demand, and cache them on memory.RM:we implement our groovy based openEHR RM in order to get automatic persistence capabilities from Grails framework.CDR:our clinical data repository is just a MySQL dbms, with an autogeneratd schema from the groovy RM with Grails framework Technology: http://www.slideshare.net/pablitox/open-ehrgen-un-framework-para-crear-historias-clnicas-electrnicas, page 21 Java technologyGrails framework to build our Opeh EHR-Gen Framework with MVC+Services, and a great ORM for persistenceit uses the Groovy PL (is a dynamic, java-based, PL) We want to add some features, like plugin support in order to add functionality to the apps created with the framework, like PIX-PDQ integration, DICOM query-retrieve integration (we have developed some hardcoded integration with both), etc. I hope this can serve to better understanding of our project. -- 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 Date: Wed, 24 Nov 2010 16:28:04 +0100 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
new openEHR-based framework
Hi Thilo, Thanks for your words. 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/listhttp://code.google.com/p/yupp/ Did I understand correctly that you have domain classes for most RM classes that get persisted via Grails ORM mechanism? Thus, it uses a generic stable schema (as long as the RM does not change) and binds the generated RM structure that is created in memory from templates/archetypes/user input to it. This design is opposed to persisting the variable generated RM structures directly via ORM. Yes, we implement the openEHR RM classes as Grails persistent classes. You can find them here: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen/grails-app/domain/hce/core 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. I think this could become a big step for the openEHR community. This will make it possible to author a template/archetypes and create an small clinical application from it relatively quickly. 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. 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 Thank you Pablo for sharing this! Cheers, Thilo Thank you Thilo. Keep in touch, Pablo. On Mon, Nov 29, 2010 at 7:51 AM, pablo pazos pazospablo at hot mail.com wrote: Hi, I think I must add some context to this email. Architecture: http://www.slideshare.net/pablitox/open-ehrgen-un-framework-para-crear-historias-clnicas-electrnicas, page 18 GuiGen:is a GUI generator based on archetypes, our own XML templates (with GUI directives), i18n config files, and RM structures.the GUI is all HTML (the framework is for building web ehr apps) the GUI is generated in real time (we also thought an offline generation of static GUI can be better to reach good performance, but the real time generation could help on testing things more quickly).the GuiGen can handle structured data and multiple occurrences of archetype nodes. here are some screenshots: https://docs.google.com/leaf?id=0B27lX-sxkymfYzI5YzBjMWEtZGI5My00NGNiLThmNmQtOGNhZmE0ZWEwNDllhl=en here you can find the templates: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen/templates/hce/trauma and the referenced archetypes: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen/archetypes/ehr Data Binder:this component creates RM structures from plain data from user's input, archetypes, templates and terminology.in the process of creating the structures, it also validates data against archetypes constraints. it creates structured data from plain data, and create multiple instances for archetype nodes with multiple occurrences.it doesn't handle the whole datatype package, but it supports the more common datatypes like text, coded text, quantities, count, ordinal, dates, boolean, and a few more. all the binding and validation is done on the fly.CKM integration:we have our local CKM in file systemArchetypeManager and TemplateManager load archetypes and templates on demand, and cache them on memory. RM:we implement our groovy based openEHR RM in order to get automatic persistence capabilities from Grails framework.CDR:our clinical data repository is just a MySQL dbms, with an autogeneratd schema from the groovy RM with Grails framework Technology: http://www.slideshare.net/pablitox/open-ehrgen-un
new openEHR-based framework
Hi Thilo,
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?
I started to work with PHP about 9 years ago. In 2004 I developed a small CMS
(SWP-CMS) . In order to make a better CMS I thought a small framework could
help. So I started the Yupp project. In 2007 I started to work with Grails, and
I borrowed some ideas from there, some ideas from Seam (another Java MVC
framework), and some PHP framewokrs like Cake, Zend, etc. The idea was to
create something with the best of the state of the art in MVC frameworks.
Do you have a link to such a CDA template (enhanced with some openEHR ideas)
somewhere?
Now I just have some proof of concept templates. I send you one attached. The
idea is to complete the template definition and to build the XSD to validate
the template structure.
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?
The idea behind miniClin is to create a minimal EHR with CDA support. This
system could run in any system with Apache and PHP (MySQL is optional because
you can persist directly to CDA XML files. The objective of the EHR-Gen is a
framework to build a complete EHR system based on openEHR archetypes.
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?
To generate an empty form from archetypes it takes 2-3 seconds.
To generate an edit form (equal to the empty form but with data loaded from the
DB) it takes 5-10 secs.
To bind data from input and save the RM structures on the DB it takes 7-15 secs.
Obviously, these times depend on the complexity of the archetypes.
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?
You need to build your templates, and add them to the config file
(http://code.google.com/p/open-ehr-gen-framework/source/browse/trunk/open-ehr-gen/grails-app/conf/Config.groovy).
There you'll see a mapping like this:
templates {
hce {
trauma {
INGRESO = ['triage']
ADMISION = ['prehospitalario', 'contexto_del_evento']
ANAMNESIS = ['resumen_clinico']
EVALUACION_PRIMARIA = [
'via_aerea',
'columna_vertebral',
'ventilacion',
'estado_circulatorio',
'disfuncion_neurologica'
]
PARACLINICA = ['pedido_imagenes', 'pedido_laboratorio']
EVALUACION_SECUNDARIA = ['exposicion_corporal_total']
DIAGNOSTICO = ['diagnosticos']
COMUNES = ['movimiento_paciente']
}
emergencia {
ACCIONES = ['adm_sust']
DIAGNOSTICO = ['diagnosticos']
}
ambulatorio {
}
quirurgica {
}
}
}
This mapping has all the clinical processes in your EHR, here you can see the
trauma process, with all it's stages and all the records in each stage. Each
record is a template (you can see the template names here;
http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn/trunk/open-ehr-gen/templates/hce/trauma)
So in trauma.EVALUACION_PRIMARIA stage (primary evaluation), you have the air
way, breathing, circulation and disability records (the ABCD). Here
(https://docs.google.com/leaf?id=0B27lX-sxkymfNGQ5MmU5ZjctMGU3ZC00ODdjLWE0ZWMtNDQ4MmQxMGYzYzRlsort=namelayout=listpid=0B27lX-sxkymfYzI5YzBjMWEtZGI5My00NGNiLThmNmQtOGNhZmE0ZWEwNDllcindex=1)
you can find the generated GUI for the EVALUACION_PRIMARIA-via_aerea template
(this is primary evaluation-airway). You can see some tabs in the top that let
you go to the other records in this primary evaluation stage.
If you change something on the config template mapping, the app will instantly
show the changes without restarting the app, because all (gui, bind, save, etc)
is
new openEHR-based framework
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. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101129/e7acdacc/attachment.html
Articles on Healthcare, Complexity, Change, Process, IT and the role of openEHR etc
Hi Thomas, My opinion is the grade of adoption of a standard depend in some aspects of goverment agencies, in some of the industry and some of the academy. DICOM is a good example of an open standard heavily supported by the industry, that's the point of it success. Can't be OpenEHR a de-facto standard for EHRs? Like DICOM is for imaging. I think yes, but the progress of OpenEHR to solve real the problems and make it usable, is slow. I think OpenEHR is strong on the academy area. It has poor industry penetration (I mean enterprises developing tools and aplying a good part of the OpenEHR specification in their systems, and that these systems where used in some hospitals). I don't know what's the penetration of OpenEHR on goverment agencies. There are some open tools but there is some stillness on making improvements on them. For example, here in Latin America, almost nobody knows about OpenEHR in the industry area, and very very few knows about it in the academy area. There are some ideas that may help de difusion and adoption of OpenEHR: - I think that regional OpenEHR communities are needed to empower the adoption and spreading of the standard. In 2009 I send a message to the mailing lists, but I get no answer from the community (this mail is below). Now we have 36 members from Uruguay, Argentina, Chile, Colombia, Spain, and more. They work on goverment agencies, big enterprises (like IBM), developers and physicians. I think the international OpenEHR community needs to support these regional communities, providing guidelines, general objectives, and following their work. Here in South America, only few people know about OpenEHR, that's a shame. People in goverment are making decissions, without knowing that are good and open standards out there. - Formal training and education in OpenEHR is needed. It's very hard to the newcomer to understand how to use OpenEHR, and people interested on the main ideas of OpenEHR may be dissapointed when they try to use it in a real-world software application. People in the industry must be trained, but how many OpenEHR trainers are out there? In Set-2010 I've done a hands-on OpenEHR tutorial in Argentina, and people (medics and TIC people) where amazed about building their archetypes and having a tool that generates the EHR (this is my degree project). This was done in the context of the Argentine Congress of informatics and Health 2010. Now, the organizers want to make more time to discuss OpenEHR and its posibilities. This is just an example that great things can happen if someone has interest. Regional OpenEHR communities can build courses fucused on the regional needs, may be made some money to support the open tool development (*). - Building and supporting open tools. The current tools have no regular updates. We need developers to build new tools and improve the current tools. We can use the money of the training courses (*) to pay developers to do this job. If this depends only on the free time we have, tools just can die before they are implemented. - In order to help any goverment adoption of OpenEHR, the decission makers have some questions that today OpenEHR can't answer. - What is the state of the standard? - Is it stable? - Wich parts are stable? - Is there any return of investment study done on efective use of OpenEHR? - Or just, how much time and money I have to spend to effectively use OpenEHR in a real world application? (I have to train people to make things happen, not in an investigation project, but in a production project) - What real world products are using OpenEHR? - How these products are using OpenEHR? (they adopt the RM? the AOM? the SM?) There is page on who is using OpenEHR in the portal, but it is outdated. My proposal is to do regular polls on the community in order to know: who is working on what, and how they're using OpenEHR. - Formal links with formal SDOs are needed. I think that OMG is in tune with the way OpenEHR do things. They have the COAS standard, and OpenEHR RM is mapped to COAS. This is a good starting point to have something in common. I think there are very good posibilities in the OpenEHR adoption on the industry adn goverment areas, but we need to build improve the lines of action of the community to reach that. Just my humble opinions. Best regards, - Pablo. Hi, We're trying to build an spanish-speakers community about openEHR , I just create a google group: http://groups.google.com/group/openehr-es We want to translate some docs and presentations to generate enough knowledge to spread the word about OpenEHR, and other EHR related concepts between latin-american and spanish people. Best regards Pablo Pazos Gutierrez http://pablo.swp.googlepages.com/ Date: Fri, 22 Oct 2010 20:19:29 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Articles
Articles on Healthcare, Complexity, Change, Process, IT and the role of openEHR etc
Hi Hugh, I think that there is beginning to be serious industry penetration in many parts of the world. We are seeing this in the Asia Pacific region as well as many countries across Europe. Do you have any concrete examples? I mean, do you know who is working on what? As I say, we need to make some polls to know what people is working, where are this people, and how they are using OpenEHR. With this information updated we can set links between projects and improve collaboration. In Brazil there is work on 13606, and some work on OpenEHR, but now they want to make their own standard based on OpenEHR. In Argentina, Uruguay, Colombia and some other countries here in South Amercia, nobody knows more than the name of OpenEHR, and that's a shame. I think that we will soon start to see a lot more interest in South America as well - certainly there is more than academic interest in Chile and Brazil I believe. Is the OpenEHR boards doing something for this to happen? Or this is just a feeling? I think real actions must take place here to reach success. I think that we will start to see a growing number of enterprise development tools - there are certainly a number of commercial and open source development platforms that are available now and are quite mature. What are those tools you mentions? How do you know they are mature? There are tools, I use them, 1. some have a lot of problems, 2. some are not being updated for a while. I don't want to sound rude, but with feelings and thoughts we can't convince goverments to look at OpenEHR, we need facts and numbers. Soon or later we must focus on formalize this standard. I'm convinced that we need regional groups to focus on regional needs, with action lines provided by the international community. This will empower the standard all around the globe, but we need support. Cheers, Pablo. http://informatica-medica.blogspot.com/ Date: Sat, 30 Oct 2010 22:35:08 +1100 From: hugh.les...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Articles on Healthcare, Complexity, Change, Process, IT and the role of openEHR etc Hi Pablo I think that there is beginning to be serious industry penetration in many parts of the world. We are seeing this in the Asia Pacific region as well as many countries across Europe. I think that we will soon start to see a lot more interest in South America as well - certainly there is more than academic interest in Chile and Brazil I believe. I think that we will start to see a growing number of enterprise development tools - there are certainly a number of commercial and open source development platforms that are available now and are quite mature. regards Hugh On 30/10/2010 2:18 AM, pablo pazos wrote: Hi Thomas, My opinion is the grade of adoption of a standard depend in some aspects of goverment agencies, in some of the industry and some of the academy. DICOM is a good example of an open standard heavily supported by the industry, that's the point of it success. Can't be OpenEHR a de-facto standard for EHRs? Like DICOM is for imaging. I think yes, but the progress of OpenEHR to solve real the problems and make it usable, is slow. I think OpenEHR is strong on the academy area. It has poor industry penetration (I mean enterprises developing tools and aplying a good part of the OpenEHR specification in their systems, and that these systems where used in some hospitals). I don't know what's the penetration of OpenEHR on goverment agencies. There are some open tools but there is some stillness on making improvements on them. For example, here in Latin America, almost nobody knows about OpenEHR in the industry area, and very very few knows about it in the academy area. There are some ideas that may help de difusion and adoption of OpenEHR: - I think that regional OpenEHR communities are needed to empower the adoption and spreading of the standard. In 2009 I send a message to the mailing lists, but I get no answer from the community (this mail is below). Now we have 36 members from Uruguay, Argentina, Chile, Colombia, Spain, and more. They work on goverment agencies, big enterprises (like IBM), developers and physicians. I think the international OpenEHR community needs to support these regional communities, providing guidelines, general objectives, and following their work. Here in South America, only few people know about OpenEHR, that's a shame. People in goverment are making decissions, without knowing that are good and open standards out there. - Formal
new openEHR-based framework
Hi everyone! We are happy to announce the release of a improved version of the Open EHR-Gen Framework, available here: http://code.google.com/p/open-ehr-gen-framework/Now we're updating the docs for this new version. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Wed, 1 Dec 2010 15:21:22 + Subject: Re: new openEHR-based framework To: openehr-technical at openehr.org Thanks Pablo, I was dealing with some monster requirements documents which were perhaps atypical. Ian Dr Ian McNicoll office / fax +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 1 December 2010 15:06, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, it works without copying and pasting chunks. I just uploaded a doc, look for the Tools Translate Document on the menu, and here is the translated template sintax and config: https://docs.google.com/document/pub?id=17-vZ8OElOuWRLTsOXpzOJksW25lw0asQaSq1ZWDr7AU Warning: the automatic translation may break some of the sintax, I have to check it more carefuly. Here is the docs in spanish for gudance: http://code.google.com/p/open-ehr-gen-framework/downloads/list -- 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 From: Ian.McNicoll at oceaninformatics.com Date: Wed, 1 Dec 2010 12:54:55 + Subject: Re: new openEHR-based framework To: openehr-technical at openehr.org Hi Thilo, Having done a load of Slovenian-English translations using Google Docs, I would suggest the following approach. 1. Split the original doc into reasonable size chunks - Google chokes above a certain limit and save as ? MS Word docs or equivalent 2. Upload to Google Docs and open the file 3. Ignore any offer from Google to 'translate this page' , if you have aotmatic trnslation turned on. 4. In Google Docs, Choose Tools-Translate from the top menu. 5. Create the translated doc as a copy and then download to your system. The translation quality is not too bad, although fairly amusing on occasion!! Most of the formatting is retained although Word numberings tend to get lost. Ian Dr Ian McNicoll office / fax +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 1 December 2010 12:42, Thilo Schuler thilo.schuler at gmail.com wrote: 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.com wrote: 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
new openEHR-based framework
Hi everyone! Attached are some screenshots of the new version of the OpenEHR-Gen Framework. In the previous email are some key changes from the previous version of the framework (I thought I send it to the list but I send it only to Ian). -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: pazospa...@hotmail.com To: ian.mcnicoll at oceaninformatics.com Subject: RE: new openEHR-based framework Date: Sun, 3 Apr 2011 16:11:57 -0300 Hi Ian, Some key points of this release: 1. We have upgraded to the last version of the underlying framework, now we use Grails 1.3.7. 2. Added: implementation of the Folder class. We use it to model clinical record domains, like emergency, ambulatory, prehospitalary, etc. 3. Improved: GUI generation, now the GUI is more compact. 4. Added: support to the type=smallText GUI directive for templates, that indicates to display a small text input for DvText nodes on the GUI generation (previously all the DvText nodes were displayed as a textarea/memo control). 5. Changed: now closing a clinical record is an explicit action. Before the records were closed when a patient was moved to another location. Now you can move a patient, but you have to close and sign the record explicitly. 6. Added: validation and error reporting of the occurrences constraint on ITEM_SINGLE nodes. This was not implemented before. 7. General code cleaning and small bugs were fixed. Hope that helps :D From: ian.mcnic...@oceaninformatics.com Date: Sun, 3 Apr 2011 19:57:32 +0100 Subject: Re: new openEHR-based framework To: openehr-technical at openehr.org CC: pazospablo at hotmail.com Congratulations Pablo, Would it be possible to get some headline points for this release? Ian -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110405/a99c5a46/attachment.html
new openEHR-based framework
Hi Thomas, I've uploaded the screenshots here: http://www.subirfacil.com/files/1BIEYWYQ/capturas_openehr-gen.zip Thank you. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 5 Apr 2011 12:34:40 +0100 From: thomas.be...@oceaninformatics.com To: openehr-implementers at openehr.org Subject: Re: new openEHR-based framework Pablo, the list does not allow attachments, especially large ones, can you provide URLs to the screenshots instead? thanks - thomas On 05/04/2011 11:49, pablo pazos wrote: Hi everyone! Attached are some screenshots of the new version of the OpenEHR-Gen Framework. In the previous email are some key changes from the previous version of the framework (I thought I send it to the list but I send it only to Ian). From: pazospablo at hotmail.com To: ian.mcnicoll at oceaninformatics.com Subject: RE: new openEHR-based framework Date: Sun, 3 Apr 2011 16:11:57 -0300 Hi Ian, Some key points of this release: 1. We have upgraded to the last version of the underlying framework, now we use Grails 1.3.7. 2. Added: implementation of the Folder class. We use it to model clinical record domains, like emergency, ambulatory, prehospitalary, etc. 3. Improved: GUI generation, now the GUI is more compact. 4. Added: support to the type=smallText GUI directive for templates, that indicates to display a small text input for DvText nodes on the GUI generation (previously all the DvText nodes were displayed as a textarea/memo control). 5. Changed: now closing a clinical record is an explicit action. Before the records were closed when a patient was moved to another location. Now you can move a patient, but you have to close and sign the record explicitly. 6. Added: validation and error reporting of the occurrences constraint on ITEM_SINGLE nodes. This was not implemented before. 7. General code cleaning and small bugs were fixed. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110405/ab106cf5/attachment.html
openEHR artefact namespace identifiers
Hi! I like the Erik's idea of having a global and unique URI to reference each archetype (also for templates). This will help to build a global archetype server, and the domain of the URI can act as the namespace of the archetype. And, if those domains really exist (like openehr.org), an archetype URI can be equal to real working URL :D, so we can request any archetype directly from the server via HTTP requests. And it'll be great to build automated archetype tests to check the validity of an archetype against a version of the RM, as Thomas said. It'll be great to have this functionality integrated with the archetype editor. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Wed, 6 Apr 2011 23:11:42 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: openEHR artefact namespace identifiers On 05/04/2011 19:16, David Moner wrote: Hello, I like that approach regarding namespaces, it will be needed sooner than later. Related to archetype identifiers there is another problem still to be solved. How they deal with RM evolutions? Current openEHR RM release is 1.0.2 but it can change in the future. Nowhere at archetypes is said which RM version was used to define them. This information should go, at least, at the archetype header, but probably should also be represented at the archetype id. Otherwise we will not be able to differentiate between an archetype for one version of the RM and the same archetype (modified if it is the case) for a different one. It should go in the archetype, that is for sure - but it should be understood only as 'the RM version used when this archetype was authored / quality assured etc' - rather than 'the RM version for which this archetype is valid'. The reason is easy to understand: for some particular archetype, authored at RM 1.0.2 let's say, it may be valid for many RM revisions after that, even RM 2.x, and not only that, it might be perfectly valid for prior revisions e.g. 1.0, 1.0.1, even 0.95 - it can depend a lot on what parts of the RM the archetype happens to use. This is the reason I argued against including the RM version in the archetype id, because it doesn't tell us anything about validity. (We had a long discussion about this on the technical list last year or 2009 I forget which). Now.. if the RM changes, let's say to 2.0.0, then we might assume that there are one or two breaking changes, and that a few archetypes could break. The only way I can see to deal with this is: we stick with the rule that minor RM change numbers never break archetypes (or indeed existing data), i..e 1.0.1 - 1.0.2 - 1.0.3 etc is guaranteed safe we say that a major RM version change, i.e. 2.x, 3.x etc that includes breaking changes there has to be a validity test run on all archetypes. any that don't pass, i.e. are compromised by the change need to be marked in some way, maybe a header field with the meaning 'valid up to RM release xxx' or so. such archetypes would themselves then have to be versioned (.v1 = .v2) It should be remembered that we can undertake many innovations and 'fixes' that don't break anything on the RM, and therefore don't require a major release. So openEHR 2.x, 3.x etc are likely to be extremely rare events. - thomas David 2011/4/5 Ian McNicoll Ian.McNicoll at oceaninformatics.com Hi, About a year ago Thomas published a draft of some detailed artefact identification proposals at http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf to help with the rapidly approaching scenario of having to cope with similarly named artefacts being published by different authorities. We are starting to see this scenario emerging in real-world projects and whilst potential collisions can be managed informally for now, we will need a formal mechanism before long. I would like to raise one aspect which I think might need re-thought on the basis of recent IHTSDO proposal for SNOMED covering the same ground. In the pdf Thomas says When an archetype
openEHR artifact namespace identifiers
Hi Heath, Just analysing OIDs vs. URIs: Usage: OIDs are in use in health informatics and other areas. URIs are in use everywhere in form of URLs Procesing: OIDs lack internal processing URIs can be processed Compatibility with actual identifiers: Inside archetypes, each node can be identified by a path, so if we use URIs to identify an archetype, just appending the path to the URI we get a valid URI to identify a node inside the archetyp. I go with URIs. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: heath.frankel at oceaninformatics.com To: openehr-technical at openehr.org Subject: RE: openEHR artifact namespace identifiers Date: Fri, 8 Apr 2011 10:10:09 +0930 Hi Erik, I was suggesting that we enforce OIDs, in fact my intent was similar to yours, to open up the choice of what is used and not enforce the specially designed ID scheme currently used that requires upgrading to support namespacing making it have the same issues as the standard UID schemes. I like the suggestion of URIs, although I also agree with Tom's later comment that within openEHR implementations we should try to limit the options of the URI schemes used. However, ADL and AOM shouldn't be restricted to this same set, to allow other implementation profiles for other reference models to make their own choices. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Wednesday, 6 April 2011 9:04 PM To: For openEHR technical discussions Subject: Re: openEHR artefact namespace identifiers Hi! On Tue, Apr 5, 2011 at 17:51, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: artefact identification proposals at http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/ am/knowledge_id_system.pdf ... se.skl.epj::openEHR-EHR-EVALUATION.problem.v1 ...Then discussions regarding UUIDs, OIDs etc followed in several messages Is not the simplest thing to just use URIs [ http://en.wikipedia.org/wiki/Uniform_Resource_Identifier ], or even better allowing non-latin characters by using IRIs [ http://tools.ietf.org/html/rfc3987 ]? Then organizations can choose if they want to base IDs on domain-names, UUIDs, OIDs or whatever that fits in a URI (which might be a URN, see list at http://www.iana.org/assignments/urn-namespaces/ ). Some archetype authoring organizations may like names with semantics, some may not, so why enforce any of the views. Now since metadata is going to be well defined inside the file, the need for semantics in identifiers or file names is gone so the main thing left is that we want a _unique_ string. URIs are supposed to be unique. Some URI-examples: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 urn:oid:1.3.6.1.2.1.27 urn:lsid:chemacx.cambridgesoft.com:ACX:CAS967582:1 http://id.skl.se/openEHR/EHR-EVALUATION.problem.v1 http://schema.openehr.org/openEHR/EHR/EVALUATION/problem/v3 urn:nbn:se:liu:diva-38012 I see no point in enforcing usage of OIDs as suggested in some responses. The idea of not changing the ID if/when transferring responsibility of an archetype between authorities sounds very reasonable if the content is unchanged. When I visited Brazil, I noticed that the MLHIM project's development version was using UUIDs for the artifacts (CCDs) that correspond to what is called archetypes in openEHR. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 ___ 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110408/abd75895/attachment.html
openEHR artifact namespace identifiers
Yep, EHR URIs for global operations like referencing a knowledge artifact internal node or in AQL/EQL queries referencing a set of RM nodes are good enough for me. I think our team will start working on querying and reporting in a couple of months when we have a more robust implementation of our openEHR-based tool (http://code.google.com/p/open-ehr-gen-framework/). Then we'll see if the URI approach is enough :D -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Fri, 8 Apr 2011 15:19:47 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: openEHR artifact namespace identifiers On 08/04/2011 14:28, pablo pazos wrote: Hi Heath, Just analysing OIDs vs. URIs: Usage: OIDs are in use in health informatics and other areas. URIs are in use everywhere in form of URLs Procesing: OIDs lack internal processing URIs can be processed Compatibility with actual identifiers: Inside archetypes, each node can be identified by a path, so if we use URIs to identify an archetype, just appending the path to the URI we get a valid URI to identify a node inside the archetyp. I go with URIs. if you have a look at the Architecture Overview spec, this is documented in some detail (more is needed... next release ;-). When Tony Shannon and I met a couple of years ago with Tim Berners-Lee, this was almost the only thing he found significant - that we could point to any knowledge model node or data instance node with a proper URI. Of course you can stick an Oid inside a URI, but I am still very unconvinced about Oids. I don't like making things complex when they can be simple. - thomas beale ___ 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/20110409/caafc24e/attachment.html
Questions about the relationship between Instruction, workflow and Action
Hi everyone! I'm trying to understand how to execute a state machine of a fully structured INSTRUCTION, and I have some questions and thoughts to share with you... The first issue is about archetyping an ACTION that execute and ACTIVITY of an INSTRUCTION. Modeling an ACTION, the Archetype Editor let me archetype the ACTION.ism_transition attribute, but not the ACTION.instruction_details. Both attribute classes (ISM_TRANSITION and INSTRUCTION_DETAILS) are specializations of PATHABLE, so those shouldn't be archetypable (see http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 53).Is this a bug in the AE or is an issue in the specs? If the ACTION.instruction_details attribute can't be archetyped in the AE, how could I know what specific structure the ACTION.instruction_details.wf_details attribute will have? Is the ACTION.instruction_details.wf_details attribute related somehow with the ACTIVITY.description attribute? The description of the ACTION.instruction_details.wf_details attribute says: condition that fired to cause this Action to be done (with actual variables substituted),What is the meaning of with actual variables substituted? This makes me think having an ACTIVITY in memory, creating an instance of an ACTION to record the execution of that ACTIVITY, copying the ACTIVITY.description structure into the ACTION.instruction_details.wf_details, and the update the correspondent fields into the wf_details with actual execution data. Does this make any sense? or I'm just to twisted :D The last one!Now only ACTIONs can change a state on the ISM, but I think an ADMIN_ESTRY could change the state also, e.g. to move a planned procedure to the scheduled state, there is an administrative step of coordinating date time, not a clinical action. Again, does this make any sense?! Thanks a lot! -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111204/c51453b5/attachment.html
Wrong C_DOMAIN_TYPE subclass C_CODED_TEXT in aom and aom1.5?
Hi, I'm working with archetypes that have DV_CODED_TEXT nodes, and those nodes are always constrained by C_COMPLEX_OBJECT, not by C_CODED_TEXT. And the internal constraint is C_CODE_PHRASE. Is there any case that use the C_CODED_TEXT constraint instead of the combination of C_COMPLEX_OBJECT/C_CODE_PHRASE? Thanks! -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111208/41dea152/attachment.html
Wrong C_DOMAIN_TYPE subclass C_CODED_TEXT in aom and aom1.5?
Thank you Thomas, I was creating some docs for the openEHR course and I missed that aom.pdf annex A was just an example!!! (there is where I saw the C_CODED_TEXT) My bad, sorry for that :D -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Thu, 8 Dec 2011 19:16:55 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Wrong C_DOMAIN_TYPE subclass C_CODED_TEXT in aom and aom1.5? On 08/12/2011 16:56, pablo pazos wrote: Hi, I'm working with archetypes that have DV_CODED_TEXT nodes, and those nodes are always constrained by C_COMPLEX_OBJECT, not by C_CODED_TEXT. And the internal constraint is C_CODE_PHRASE. Is there any case that use the C_CODED_TEXT constraint instead of the combination of C_COMPLEX_OBJECT/C_CODE_PHRASE? Thanks! -- Hi Pablo, there are three C_xxx special types, that allow CODE_PHRASE, DV_QUANTITY and DV_ORDINAL to be more conveniently constrained than if the standard C_COMPLEX_OBJECT approach were used: C_CODE_PHRASE, C_DV_QUANTITY and C_DV_ORDINAL. These types are described in the openEHR Archetype Profile (There is no C_CODED_TEXT type defined there). Our experience is that these types are used nearly universally because they express the typical semantics much more easily that the standard ADL would. The parent class C_DOMAIN_TYPE is the plug-in point for more such classes. - thomas ___ 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/20111208/695e5aaf/attachment.html
Questions about the relationship between Instruction, workflow and Action
Hi Sam, thanks for the answer... I'm having several hours of bad sleeping, trying to understand this :D Hi Pablo, The design principles are that the Instruction should remain unaltered by people basing actions on this instructions ? as the action and instructions could be disconnected at any moment. For example, the instruction (medication order) should not be changed by anyone just to give a medication etc. Sounds very reasonable. But I think that sometimes administrative entries could also change the state of an Instruction, like when scheduling a procedure. I asked Heather on that issue (http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-archetype/) and her answer seems reasonable too: generaly scheduling tasks are done on external administrative systems (LIS, RIS, ...) and them a message is sent to the EHR to tell the Instruction had been scheduled. But: how is that change of the Instruction state recorded on the EHR?Receiving a message from an external system could trigger the creation of an ACTION?Is that the way you have implemented that? So the state of the instruction is carried in the record of the action (if appropriate). Is that recorded on ACTION.instruction_details.wf_details? We have decided to name the pathway steps and attach a machine readable state to that step. This makes it much easier for clinicians to model and to see what is going on. You will see an archetype ACTION in the openEHR repository and the careflow_steps are archetyped to provide a name and the current state matches an openEHR code for state. This means that a careflow step being carried out will set the state to a particular machine state. I think I saw that on the ehr_im.pdf as an example for UK GP medicaton order workflow. As I understand it, this can be done by constraining the ACTION.ism_transition attribute, with the Archetype Editor, for all the ACTIONS that will be used to execute ACTIVITIES of the medication order INSTRUCTION. If that's right (?), maybe there's a bug on the specs, because ISM_TRANSITION inherits from PATHABLE, and to be archetyped I think it should inherit from LOCATABLE (see ehr_im.pdf page 53). For the workflow definition, do you use the INSTRUCTION.wf_definition? I can't find an example on how to express a workflow there (maybe something like this could help http://doc.openerp.com/v6.0/developer/3_9_Workflow_Business_Process/index.html). In our openEHR repository we maintain an instruction index ? that is a pointer to all instructions and all actions that relate to that instruction ? and the current state of the instruction. Ok, so at an instance level, we should have all INSTRUCTION instances, the current state of each instruction, and all the ACTIONs executed for each INSTRUCTION/ACTIVITY.That is a great implementation consideration, I'll add that on the openEHR spanish course docs. :D Thanks a lot! Cheers,Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111208/d5cbedfd/attachment.html
13606 revisited - list proposal
Great! this will be THE opportunity to think about an IM 2.0, and the first topic on my wishlist is the simplification of ITEM_STRUCTURE children :D -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Thu, 15 Dec 2011 00:49:20 + From: thomas.beale at oceaninformatics.com To: openehr-technical at openehr.org Subject: 13606 revisited - list proposal At the CIMI meeting last week and elsewhere, I have noticed a lot of interest in the ISO 13606 2012 revision, specifically in a) whether the openEHR and 13606 reference models can be brought together for part 1 of the revision and b) in finalising ADL/AOM 1.5 for providing a new snapshot to ISO for part 2. It seems to me that it would be useful to have a dedicated place to discuss this, so I would like to propose a new mailing list, 13606-alignment at openehr.org Does this seem like a useful idea? - thomas beale ___ 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/20111215/41c00947/attachment.html
13606 revisited - list proposal
That's the simplification we need to the IM 2.0! :D -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: yampeku at gmail.com Date: Thu, 15 Dec 2011 08:30:46 +0100 Subject: Re: 13606 revisited - list proposal To: openehr-technical at openehr.org technically speaking, CLUSTER is already simpler in current 13606 model :) 2011/12/15 pablo pazos pazospablo at hotmail.com: Great! this will be THE opportunity to think about an IM 2.0, and the first topic on my wishlist is the simplification of ITEM_STRUCTURE children :D -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/242f8ce5/attachment.html
13606 revisited - list proposal
Hi Gerard, is good to know! please publish the link to the wiki discussion when available. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Subject: Re: 13606 revisited - list proposal From: gf...@luna.nl Date: Thu, 15 Dec 2011 11:33:17 +0100 To: openehr-technical at openehr.org Dear Pablos, Internally in the EN13606 Association I started to work on this renewal.The EN13606 Association will start to think about all 5 parts of the standard. With respect to 13606 part 1 - the reference model- I think we will have discussions on topics such as:- scope- Folders- Semantic links- the structure below the Entry Class- the type of relationships between the Composition/section classes used to structure documents and the Entry, Cluster and Element classes that define the clinical content. Possibly other members will have their own topics they want to put on the table.In our EN13606 Association meeting in February in Seville we start the discussions after a consultation phase.openEHR will be part of this consultation phase. Any input from openEHR is welcomed.A WIKI page will be started anytime soon on our website.After these discussions our suggestions will be submitted to CEN/tc251 and ISO/tc215. For more information about the EN13606 Association and the Seville meeting I refer to:www.en13606.orgNon-members that want to participate in this meeting are invited to subscribe. Gerard Freriks+31 620347088gfrer at luna.nl On 15 dec. 2011, at 05:03, pablo pazos wrote:Great! this will be THE opportunity to think about an IM 2.0, and the first topic on my wishlist is the simplification of ITEM_STRUCTURE children :D -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos ___ 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/20111215/b2b20f4b/attachment.html
Questions about the relationship between Instruction, workflow and Action
Hi Heather, You give me a lot to thought about. In my mind I was reserving the creation of actions, observations, instructions and evaluations only for clinical staff, now I see that administrative clerks could also create (directly or indirectly) actions on the clinical record. That will suffice for explaining how to implement all the changes in an instruction's state. Thanks a lot for your patience! -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: heather.les...@oceaninformatics.com To: openehr-technical at openehr.org Subject: RE: Questions about the relationship between Instruction, workflowand Action Date: Mon, 12 Dec 2011 15:00:13 +1100 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Sunday, 11 December 2011 8:39 AM To: openehr technical Subject: RE: Questions about the relationship between Instruction, workflow and Action Hi Heather, I asked Heather on that issue (http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-archetype/) and her answer seems reasonable too: generaly scheduling tasks are done on external administrative systems (LIS, RIS, ...) and them a message is sent to the EHR to tell the Instruction had been scheduled. But: how is that change of the Instruction state recorded on the EHR?[HL] The INSTRUCTION for a procedure remains unchanged, unless the clinician changes the nature of the original order and this is carried out with a revision of the committed INSTRUCTION. The ACTION is recording the progress of activity in carrying out the INSTRUCTION ? ie the procedure is planned, scheduled, performed, completed and at each of these pathway steps the appropriate data is captured eg what procedure is scheduled and the scheduled time; and what/ when was actually finally performed etc. What was actually done/performed/administered may be different to what was originally ordered due to clinical circumstances etc ? the ACTION allows this evolution to be captured. Yet through all this the original instruction/order persists as is. I understood that part and agree 100%: We have the record of the original Instruction untouched, or if it need a change from a clinical point of view, this will be a new version/revision of the previous Instruction. Receiving a message from an external system could trigger the creation of an ACTION? [HL] It could trigger the creation of an ACTION if received from a scheduling system and there had been no ACTION created previously. That same newly created ACTION could then be used to record the data against subsequent pathway steps.OR the message could be used to trigger an entry using the existing ACTION containing the Scheduled data against the Scheduled pathway. That's the problematic point I see on the use of an ACTION to record something that is merely administrative and may have no clinical relevancy.[HL] From my point of view, it may be an administrative detail, but just the fact that something has been scheduled (without necessarily details of the time/date/location) is a valuable part of a clinical record. It does have clinical relevance as it records what has been done in the steps required to carry out at order/INSTRUCTION. While a non-clinical person may have technically carried out the ACTION, it is still critical info in the clinical record, still a ?clinical action? IMO.An ACTION should be ... Used to record a clinical action that has been performed, which may have been ad hoc, or due to the execution of an Activity in an Instruction workflow. Every Action corresponds to a careflow step of some kind or another. (http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 73). I think we could analize this topic through an implementation (I think that's what you and Sam have mentioned) with the solution of having messages triggering ACTION creation or recording data on existing ACTIONs.[HL] It is not at all simple to envisage how the flow of INSTRUCTION and various resulting ACTIONS play out, and I can?t pretend to have it all 100% clear, but with implementations (and Heath Frankel certainly has plenty of recent experience) it is proving to work in practice. But I think we need to revise the openEHR specs, to see if this topic is clear enough, because I don't see a clear solution in the standard itself (maybe others could have better luck than mine).Or maybe this is one of those things that are not defined by the standard, like EHR security or RM persistence, and each implementation could create it's own solution. If that's the case, I think Instruction management is an important issue on EHR development and it should be considered on the specs. And my small contribution on this is that maybe ADMIN ENTRIES could also trigger/record
13606 revisited - list proposal
Hi Erik, I want to implement some simplifications of the item_structure in the EHRGen ( http://code.google.com/p/open-ehr-gen-framework/ ) we talked about this: http://www.openehr.org/mailarchives/openehr-clinical/msg02231.html My focus is on the persistence layer, because we persist data using an ORM (object-relational mapping) component, and the complexity of the relational schema is proportional to the complexity of the object model. BTW, the EHRGen has the complete cicle of information implemented: automatic gui generation (based on archetypes and our gui templates), data validation against archetype constraints, data binding (creation of RM structures from user data input and archetypes), persistence of those structures, and getting data to show on a GUI. Now I'm experimenting with semantic queries (common SQL but based on arcehtype ids and paths). Regards,Pablo. Regarding the RM I know Tom is experimenting with simplified ITEM_STRUCTURE as a BMM-schema for the AWB. Are there any other RM-redesign experiments going on anywhere? What is happening in the 13606-world regarding thoughts about practical datatypes? What about (optional) reusable ENTRY subtypes in the 13606 world? (see http://www.openehr.org/mailarchives/openehr-technical/msg05285.html under the heading 2. OBSERVATION et. al. (ISO 13606 CR)) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/428ef9aa/attachment.html
Representing binary values with DV_BOOLEAN
Hi, I think the ideas under points of improvement here: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates, for creating a GUI control library usable from GUI templates, may help on this subject. -- 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 Date: Wed, 2 Feb 2011 14:59:02 +0100 Subject: Re: Representing binary values with DV_BOOLEAN From: erik.sundvall at liu.se To: openehr-technical at openehr.org On Wed, Feb 2, 2011 at 13:32, Thomas Beale thomas.beale at oceaninformatics.com wrote: The GUI / practical issues... I would steer clear of trying to directly infer the GUI control to use from the archetype on its own. I agree that most often such combobox vs radio-style hints would be wrong at an archetype level. I was more thinking of usefulness of a directive at a more local template level e.g. when wanting to ovveride default framework behaviour. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 Even if there was a GUI directive artefact available in the archetype environment, this kind of style rule still won't be found there (although exceptions might be marked in some way), so there is no escaping a set of global style rules in my view. ___ 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/20110202/b483f348/attachment.html
constraint binding error
Hi Peter, Diego, I think the URI way to define constraint bindings can be ambiguous and hide some semantics needed to understand where to find the terminology terms and codes. Please correct me if I'm wrong: One archetype can have this: [ac0001] = terminology:Snomed/2002?subset=DrugForm And another this: [ac0001] = terminology:Snomed/2002?s=DrugForm So, how can a machine know the difference or equivalency of both URIs? (URIs are universal, but not a unique way to identify a terminology or a subset). How can we agree on use one URI or the other in global archetypes? Do we need a centralized terminology/subset URI repository? What do you think? -- 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 From: peter.gummer at oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: constraint binding error Date: Mon, 21 Feb 2011 11:56:11 +1100 Diego Bosc? wrote: I know it is on ADL specs, but why limit it to an URI? Second approach could also be used to identify a subset The URI approach is able to specify subsets, Diego. Here is an example, generated by the current Archetype Editor beta release (available from http://www.openehr.org/svn/knowledge_tools_dotnet/TRUNK/ArchetypeEditor/Help/index.html) : constraint_bindings = [Snomed] = items = [ac0001] = terminology:Snomed/2002?subset=DrugForm - Peter ___ 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/20110220/3b160ff0/attachment.html
constraint binding error
(just to clarify) I know that constraint bindings URIs are not actual working URIs that you can get a-la HTTP, I understand that here they are used as identifiers, that with a mapping somewhere, our system can access the real terminology source. With the centralized service I meant not to get the content of the terminology, instead get the global and unique terminologies identifiers for use in archetypes, so for each terminology and subset we will have only one id (URI/URN). We can have a mapping to an OID too (other global identifier, less human friendly but works). The problems are: - we need some way to define/specify what is the canonical form of a URI/URN, we must agree in a terminology of names (of terminologies :D) and subsets. - Snomed is the same as SNOMED? or ICD10 is the same as ICD 10 or CIE 10 (CIE = ICD in spanish)? - we cannot rely of one tool implementation to take a decision that is not in the specs: other tools can make different decision, so, generated archetype will be inconsistent. -- 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 Date: Mon, 21 Feb 2011 13:42:31 +1100 Subject: Re: constraint binding error From: andrewpatto at gmail.com To: openehr-technical at openehr.org Just to clarify some more, my contention is that you cannot look inside a arbitrary URI to pick out values without looking at the formal 'scheme' dependent spec. So in the case of a 'http' URI, we can read the spec and know what the bits mean - _for the purposes of fetching data from web servers using HTTP_. I can't imagine how that is possibly what is intended by putting a URI into an archetype - we can't seriously be suggesting that everyone who uses the archetype is all going to be descending on some poor webserver named in the URL and fetching data in some arbitrary format? So if you want a URI scheme that has identifiable bits for snomed queries etc, someone needs to specify a urn:snomed:,, spec. If not, all you can do is compare URI's for equality and assume there is some external mechanism for saying what the URI actually means. Andrew ___ 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/20110221/ea26f8b5/attachment.html
constraint binding error
Hi Michael, Not every terminology version is a date. In ICD 10, the version is 10. I think the version to be a valid date is not a problem here. -- 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 From: Michael.Lawley at csiro.au To: openehr-technical at openehr.org Date: Mon, 21 Feb 2011 14:46:43 +1100 Subject: Re: constraint binding error Surely spaces should not be an issue here as these strings do not really identify anything. Instead, one should be using SCTIDs as in: terminology:Snomed?v=2002?s=135394005 Further issues include: * the version should be specified using an ISO 8601 basic representation of MMDD (or MMDDThhmmss Z for development versions), * Snomed is insufficient - is this the International release, or SNOMED CT-AU or ... My understanding of Release Format 2 (see 7.4.4.13 in the Technical Implementation Guide) indicates that the moduleId (also an SCTID) is the appropriate thing to use, and * one may also (almost always) wish to use a ReferenceSet for terminology binding. These are also designated by an SCTID (and would require a moduleId and version as well) This would then give us something like: terminology:SNOMED?m=3250602136107v=20101130s=135394005 On 21/02/11 12:22 PM, Peter Gummer peter.gummer at oceaninformatics.com wrote: Diego Bosc? wrote: and we have also to deal with spaces! terminology:Snomed?v=2002?s=Antiallergenic drugs (product) Spaces are illegal in URIs. The correct form for the subset would be: subset=Antiallergenic%20drugs%20(product) - Peter ___ 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/fcdb2f1b/attachment.html
constraint binding error
Hi Thomas, Maybe we could think of CM/AM in ICD, and CT/CT-AU in Snomed like the country/variant in a locale, (en_UK or en_UK_v1) leaving the version alone (version = a number or date or id or whatever). -- 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 Date: Mon, 21 Feb 2011 11:36:12 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: constraint binding error On 21/02/2011 04:14, pablo pazos wrote: Hi Michael, Not every terminology version is a date. In ICD 10, the version is 10. I think the version to be a valid date is not a problem here. most people consider ICD10 as simply a different terminology from ICD9. There are variants like ICD10AM, ICD9CM and so on... and in theory, there are no 'versions' of these terminologies, at least as far as I know - WHO issues once and that's it (not sure about the AM and CM releases though). - thomas ___ 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/20110221/705a77a5/attachment.html
Change Request on Composition.territory attribute
Hi, We have a case where we need to specify some country subdivision localization for a clinical document (Composition), but the Composition.territory attribute only have a country level. The Composition.territory is contraint by the ISO 3166-1 vocabulary. Can we (maybe) have a Composition.territory constrained by the ISO 3166-2 for a country/subdivision specification? (http://en.wikipedia.org/wiki/ISO_3166-2). Maybe this can be a CR for ADL 1.5. -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110225/c0ce0a39/attachment.html
GUI-directives/hints again (Was: Developing usable GUIs)
Hi Thomas, It's been a while. I've added some thoughs on GUI directives to improve our Open EHR-Gen GUI Templates. It may help to create something more generic than an improvement to our templates. http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates My grain of sand. -- 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 Date: Wed, 15 Dec 2010 20:44:49 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs) On 15/12/2010 00:57, pablo pazos wrote: Hi Thomas, ... You describe a very big picture and sounds logic, so we'll have: Level 1: archetypes (for model complete data sets about a concept, general and specialized ones) Level 2: structural templates (for localized use of archetypes, general and specialized templates) Level 3: define the use of the structural templates GUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data. Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA ...). to do non-openEHR message syntaxes, it requires not just another 'template' (in fact, not much be needed here), but a transformation from the operational template (OPT) form to the target form, e.g. CCR XSD or whatever. Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates. Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc. Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions. ... I am not sure what some of these would look like, but I suspect they will come into existence one day... If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?) to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section? I have a couple ideas that can improve what we've done on the EHR-Gen framework. If you want I can put them in the wiki. please do that - thomas ___ 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/20110128/43dc4c51/attachment.html
CCR model
Hi Koray, here you can find a simplified CCR model from google health: http://code.google.com/intl/es/apis/health/ccrg_reference.html -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: k.atalag at auckland.ac.nz To: openehr-clinical at openehr.org; openehr-technical at openehr.org Subject: CCR model Date: Mon, 11 Jul 2011 01:36:22 + Hi All, I need CCR model ASAP. has anyone worked on this. Possible to share? Cheers, -koray ___ 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/20110711/631f076c/attachment.html
Dual Model EHR implementation
Hi Alberto, we are working on this subject: http://code.google.com/p/open-ehr-gen-framework/ http://code.google.com/p/open-ehr-gen-framework/wiki/Optimizacion http://code.google.com/p/open-ehr-gen-framework/wiki/EstructurasDeDatos http://www.openehr.org/wiki/display/impl/Playing+with+Pablo%27s+Open+EHR-Gen+Framework -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Fri, 3 Jun 2011 14:27:55 +0200 Subject: Dual Model EHR implementation From: albertomorenoco...@gmail.com To: openehr-technical at chime.ucl.ac.uk Dear all, Within the Virgen del Rocio University Hospital we are analysing how to implement a EHR based on Dual Model Approach. When we analysed direct implementation a database based on of either OpenEHR Reference Model or ISO 13606, we have detected that it could have slow performance . Given that we are concerned about this problem, we would like to know possible strategies have been identified by implementers in order to fasten the performance of storage and query. Also the granularity level is one open issue that impacts on the performance, I would like to know if the level of granularity of the archetypes contained within the OpenEHR CKM is able to satisfy the requirements of an EHR with more than 1 million records. Kind Regards Alberto Alberto Moreno Conde GIT-Grupo de Innovaci?n Tecnol?gica Hospital Universitario Virgen del Roc?o Edif. Centro de Documentaci?n Cl?nica Avanzada Av. Manuel Siurot, s/n. C.P.: 41013SEVILLA ___ 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/20110603/836a5915/attachment.html
Dual Model EHR implementation
I agree with Alan. In OpenEHR-Gen, we have modeled almost all the classes between Folder and Datatypes (Folder, Composition, Section, Entry, Item, DvText, etc) and represented all those concepts in our DB schema. Here you can find our data model: http://code.google.com/p/open-ehr-gen-framework/downloads/detail?name=model.png I think my friend Alan refer to our implementation of the OpenEHR-Gen Framework, that automaticaly generates the DB Schema from the Reference Model classes we programed in Grails Framework (http://www.grails.org/). Grails have a great ORM tool (Object-Relational Mapping, this is diferent to the ORM mentioned by Alan). Through this experience, we have seen that this complex structured model have some shortcomings on performance, but it do not take hours or minutes to complete tasks like data binding and saving or data querying, and this can be boosted by good servers, fast disks and a good DBMS. What we are doing now is redesigning the data model, dividing the classes in two groups, one groups just for structure classes, and the second group for content classes. The first group have the classes that are part of the structure but don't have clinical content, like Section or Cluster. The second group have the clinical/demographic content like Element or Composition. Then can infer the structure classes from an archetype, we may not include them into the persistent model, so we'll model only the content classes, and add some metainfo to help reconstruct the complete RM structure as if it has been persisted on the database. So, in the persistent layer we'll have: archetypes, a reduced persistent RM, and metadata. This will be the next step in our open source project. Hope that helps. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: alandma...@gmail.com To: openehr-technical at openehr.org Subject: RE: Dual Model EHR implementation Date: Fri, 3 Jun 2011 11:24:04 -0300 Hi all. IMHO the best approach (or at least what I have done and feel is reasonable) is to take only some of the classes in the reference model and represent them in the database. I have seen some implementations which adopt an automatic code generation approach, direct from the reference model. But that builds certain structures into the database which are unnecessary and/or may hinder performance. When analyzing the openEHR it seems to me it was not conceived with its database implementation in mind (which is an absolutely reasonable approach). The way information is persisted, I guess, is left to implementators and I believe that is probably Alberto?s issue. To solve the multiple database problem, the structure openEHR database structure could be designed using ORM tools such as that in http://www.ormfoundation.org (again, that is what I have used). I agree that archetypes should pose no performance problem at the database level if care is exercised no to try to represent them in the database. In the final analysis, it seems to me that that is what openEHR is all about: separating (represented, archetyped) knowledge from the (storage) structure From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Alberto Moreno Conde Sent: Friday, June 03, 2011 9:28 AM To: For openEHR technical discussions Subject: Dual Model EHR implementation Dear all, Within the Virgen del Rocio University Hospital we are analysing how to implement a EHR based on Dual Model Approach. When we analysed direct implementation a database based on of either OpenEHR Reference Model or ISO 13606, we have detected that it could have slow performance . Given that we are concerned about this problem, we would like to know possible strategies have been identified by implementers in order to fasten the performance of storage and query. Also the granularity level is one open issue that impacts on the performance, I would like to know if the level of granularity of the archetypes contained within the OpenEHR CKM is able to satisfy the requirements of an EHR with more than 1 million records. Kind Regards AlbertoAlberto Moreno CondeGIT-Grupo de Innovaci?n Tecnol?gica Hospital Universitario Virgen del Roc?o Edif. Centro de Documentaci?n Cl?nica Avanzada Av. Manuel Siurot, s/n. C.P.: 41013SEVILLA ___ 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/20110607/0ff6d8b8/attachment.html
Dual Model EHR implementation
Randolph Alan, In our approach we will give a shot to store the group of structure classes I mentioned before, directly on a relational DB, in an atomic way (we will have tables and columns to each field, not a blob to store all the structure). With this approach I think we can boost performance about 70%, the big bottleneck in our implementation is de dynamic data binding (put data input from a user in a RM structure), and with this improvements, 1. this logic will be much more simple, 2. the DB schema wil be simpler also. I hope we'll have some results soon. We'll be evaluating performance on MySQL and Postgres DBMSs. The XML approach is our plan B :D This approach is based on some requirements: We need the clinical data on the production DB (that DB is relational, and the clinical data is stores in the content classes I mentioned before.The repository must support querying data at an atomic level without loading a huge amount of data on memory (for example: find all the patients with systolic BP over 130). In the end we need a complete structure: the structure classes can be infered by arcehtypes and metadata (that can be persisted on filesystem, or could be instanced on memory) There are other options too: 1. use an object-oriented dabatase (an ger rid of the Object-Relational Mapping tool), 2. use a document oriented DB: a. a XML native DB or b. a JSON native DB like http://www.mongodb.org/, 3. mix of relational dbs or oo dbs and filesystem (to store documents XML or JSON). Just my 2 cents. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 7 Jun 2011 16:53:10 -0400 Subject: Re: Dual Model EHR implementation From: randy.ne...@veriquant.com To: openehr-technical at openehr.org Alan, Thanks for clarifying. I thought in your earlier post you had ruled out XML. I was curious what the alternative would be. JSON, as you suggest, would be better. Since writing my post I realized I had not given you credit for one innovation I had not seen before, namely, placing structure classes directly into the DB. That would allow you to keep your JSON content instances relatively small and hence searchable with formal queries, at least to some extent. I could be mistaken, but I think an alternative approach I had heard about on this forum would be to create basically just one blob or just one XML document to contain an entire medical record for a patient, a record that would be extended with each encounter, with the prior instance of the record deleted or at least never referenced again. Again, I will probably be corrected here. Your approach sounds better. Randy On Tue, Jun 7, 2011 at 3:49 PM, Alan March alandmarch at gmail.com wrote: Regarding ?content structures?, these could be persisted as ?objects? in ad hoc field in the database. What kind of objects? And how would any approach of this sort be much better than XML? You'd still have to retrieve, parse or otherwise deserialize the entire blob before you could productively read, or navigate to, the tiniest part of it, taking time and resources. And it would seem that your object would have to be mixed with a lot of instance-level metadata (as in XML), further bloating its size, complexity and internal overhead. And are there non-proprietary ways to do this? I never mentioned blobs. Precisely?XML structures would be one of the best choices (or probably better: a JSON ?object?). If you read on you?ll see that that is precisely what I did in the past. That is why I enclosed the word object with double quotes (meaning to use the concept metaphorically). Serializing (real) runtime objects into XML or JSON ?objects? and storing these ?complex data types? (I should probably have used this terminology) is, to the best of my understanding, the most convenient choice. So I fully agree with your comments. I don't see how the functionality of such objects would greatly exceed that of a PDF text document (possibly including a document-level table of contents), which, at the end of the day, is what a lot of EMR systems essentially amount to. Doctors typically pull up text-based notes often autogenerated from discrete fields never searched upon again and which may even die upon the generation of the note. I understand that one approach is to provide some basic indexed pointers to the blob within the DB, but that does not really overcome the basic problem that blobs pose. Sure. Blobs are ghastly and under no circumstance would I propose their use for storing information of the type we are dealing with here. One could argue that this at least avoids the problems often associated with EAV, but at the expense of easy and efficient access to discrete data elements. If a weight is too heavy to lift one solution is simply not to lift
I'm looking for opportunities to do my master studies
Hi everyone, I've been around the openEHR community since 2006, when I met the medical informatics domain. I've been facinated with this field since then, and I've been learning all I could about it. Now I've have my degree in computer ingeneering, and I want to continue my studies on medical informatics and the application of standards. This email goes to the openEHR lists because I know there is a lot of academic participation, and I would be glad to know if there are any opportunity to take some courses related to my specialization area to start my master degree studies at your university. If you could drop me a line privately, I'll be grateful. Thanks a lot, Pablo. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110613/93584f56/attachment.html
Regarding the use of the dual model approach and openEHR in clinical trial management software
Hi Athanasios, We have implemented the two level modeling approach in our OpenEHR-Gen project: http://code.google.com/p/open-ehr-gen-framework/ It is a generic system (a framework), so it can handle virtually any kind of archetyped data. If you have any questions, I'll be happy to help. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Fri, 10 Jun 2011 14:00:06 +0100 From: athanasios.anastasiou at plymouth.ac.uk To: openehr-technical at openehr.org; openehr-clinical at chime.ucl.ac.uk Subject: Regarding the use of the dual model approach and openEHR in clinical trial management software Hello everyone I was just wondering if there are any projects out there that have been looking at employing the dual model approach to describe clinical trial data or that are using openEHR at the back-end (?) I may be searching in the literature using the wrong (and obvious) terms but nothing much is coming up so far. Looking forward to hearing from you Athanasios Anastasiou ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110623/08776bb1/attachment.html
GUI stuff in AOM/ADL? (Was: future ADL-versions)
Hi Erik, In the past months we have talked about the scope of each artifact. One thing that is clear is that we can have structural templates and GUI templates, that can be defined, shared and used separately, but GUI templates can rely on structural templates, as structural templates rely on archetypes. Here is a reference to the discussion: http://lists.chime.ucl.ac.uk/mailman/private/openehr-technical/2011-January/005787.html -- 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 Date: Thu, 24 Mar 2011 09:05:49 +0100 Subject: GUI stuff in AOM/ADL? (Was: future ADL-versions) From: erik.sundv...@liu.se To: openehr-technical at openehr.org Hi! Yesterday I asked if anybody had any motivated objections to using the openEHR template formalism as a layer to catch some GUI-hints/rules. I bring it up again to get some response :-) The point to have separate concerns in separate artifacts is often good. Regarding GUI-hints it seems reasonable to not have them at the clinical archetype level, and in some cases not at a first clinically focused template level either. But, as we have discussed earlier, through specialisation and/or inclusion it's possible to have several layers of openEHR templates. This means that ADL or some other serialisation format of the archetype object model (that now will include templates) can be used for GUI-related annotations and GUI-related logic in some form. Does anybody have concerns or worries regarding this? You could still have separate artifacts by splitting reusable clinical modeling and use case specific GUI modeling in separate layers of templates. A nice thing with reusing the template formalism for catching GUI stuff is that shared tools and understanding is already in place as opposed to inventing some new purely GUI-related formalism. Also in some cases it's likely that the same groups that are designing archetypes and clinically focused templates will have knowledge of some use cases in which they know what they'd want to happen on the GUI side. Then it would be nice to be able to reuse people, tools, template governance repositories etc. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 P.s. (off topic)I'm not sure it's always optimal to split everything into separate artifacts, especially when it comes boundary problems like terminology bindings. You could argue that the binding should be done in a separate artifact that is neither part of archetypes nor part of terminologies, but I'm not sure that would always make things better. Having the bindings in the archetype forces the archetype authors to revise the bindings at the same time as they revise an archetype and that might be good. On the other hand you could argue that a SNOMED CT refset might be exactly such a third artifact that can be used for managing bindings. But if you would have three different groups maintaining archetypes, refsets and terminology systems then you'd better keep them very well aware of each other's actions... On Wed, Mar 23, 2011 at 21:09, pablo pazos pazospablo at hotmail.com wrote: I agree with Thomas, in order to have a clean design we need to separate the concerns of our artifacts. If we have a solid base to our complete clinical data structures like Archetypes, we can define other upper layer artifacts to model rules, conditions, gui directives, etc. I like this approach because we can solve one problem at a time, instead of having a messy one-fits-all solution. ___ 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/20110324/e3937741/attachment.html
GUI stuff in AOM/ADL? (Was: future ADL-versions)
Hi Koray, I think we are the core group, and if we can agree some basic notation of some basic GUI directives (there are some thoughts of mine on the wiki: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates) and can implement them in a consistent way (we all use heterogeneous technologies), we can lead the definition and improvement of this inside the standard. We have to options: 1. keep waiting for some signal, 2. think outside the box and take the lead. Any one who want #2 and have time to work can drop me a line to coordinate the required work, share experiences and colaborate on this subject. -- 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 From: k.ata...@auckland.ac.nz To: openehr-technical at openehr.org Date: Fri, 25 Mar 2011 16:05:22 +1300 Subject: RE: GUI stuff in AOM/ADL? (Was: future ADL-versions) Hi Eric, good points...As you may remember we had this discussion on this list not so long ago and I don?t remember any action taken after that. I guess we should take lead and come up with some proposal. Perhaps it?d be good to have a wiki space - but I want to repeat myself: someone from core group must guide the group and provide early feedback whether we are on the right track or not. Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Thursday, 24 March 2011 9:06 p.m. To: For openEHR technical discussions Subject: GUI stuff in AOM/ADL? (Was: future ADL-versions) Hi! Yesterday I asked if anybody had any motivated objections to using the openEHR template formalism as a layer to catch some GUI-hints/rules. I bring it up again to get some response :-) The point to have separate concerns in separate artifacts is often good. Regarding GUI-hints it seems reasonable to not have them at the clinical archetype level, and in some cases not at a first clinically focused template level either. But, as we have discussed earlier, through specialisation and/or inclusion it's possible to have several layers of openEHR templates. This means that ADL or some other serialisation format of the archetype object model (that now will include templates) can be used for GUI-related annotations and GUI-related logic in some form. Does anybody have concerns or worries regarding this? You could still have separate artifacts by splitting reusable clinical modeling and use case specific GUI modeling in separate layers of templates. A nice thing with reusing the template formalism for catching GUI stuff is that shared tools and understanding is already in place as opposed to inventing some new purely GUI-related formalism. Also in some cases it's likely that the same groups that are designing archetypes and clinically focused templates will have knowledge of some use cases in which they know what they'd want to happen on the GUI side. Then it would be nice to be able to reuse people, tools, template governance repositories etc. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 P.s. (off topic)I'm not sure it's always optimal to split everything into separate artifacts, especially when it comes boundary problems like terminology bindings. You could argue that the binding should be done in a separate artifact that is neither part of archetypes nor part of terminologies, but I'm not sure that would always make things better. Having the bindings in the archetype forces the archetype authors to revise the bindings at the same time as they revise an archetype and that might be good. On the other hand you could argue that a SNOMED CT refset might be exactly such a third artifact that can be used for managing bindings. But if you would have three different groups maintaining archetypes, refsets and terminology systems then you'd better keep them very well aware of each other's actions... On Wed, Mar 23, 2011 at 21:09, pablo pazos pazospablo at hotmail.com wrote:I agree with Thomas, in order to have a clean design we need to separate the concerns of our artifacts. If we have a solid base to our complete clinical data structures like Archetypes, we can define other upper layer artifacts to model rules, conditions, gui directives, etc. I like this approach because we can solve one problem at a time, instead of having a messy one-fits-all solution. ___ 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/20110325/af79ad43/attachment.html
GUI stuff in AOM/ADL? (Was: future ADL-versions)
That's a good starting point. Here is our effort to make usable GUI templates: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates This is developed, documented and working ok. -- 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 From: yampeku at gmail.com Date: Fri, 25 Mar 2011 14:32:41 +0900 Subject: Re: GUI stuff in AOM/ADL? (Was: future ADL-versions) To: openehr-technical at openehr.org Maybe we could use as inspiration all the available XML to GUI efforts that already exist. Mostly to avoid reinventing the wheel 2011/3/25 pablo pazos pazospablo at hotmail.com: Hi Koray, I think we are the core group, and if we can agree some basic notation of some basic GUI directives (there are some thoughts of mine on the wiki: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates) and can implement them in a consistent way (we all use heterogeneous technologies), we can lead the definition and improvement of this inside the standard. We have to options: 1. keep waiting for some signal, 2. think outside the box and take the lead. Any one who want #2 and have time to work can drop me a line to coordinate the required work, share experiences and colaborate on this subject. -- 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 From: k.atalag at auckland.ac.nz To: openehr-technical at openehr.org Date: Fri, 25 Mar 2011 16:05:22 +1300 Subject: RE: GUI stuff in AOM/ADL? (Was: future ADL-versions) Hi Eric, good points...As you may remember we had this discussion on this list not so long ago and I don?t remember any action taken after that. I guess we should take lead and come up with some proposal. Perhaps it?d be good to have a wiki space - but I want to repeat myself: someone from core group must guide the group and provide early feedback whether we are on the right track or not. Cheers, -koray From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Thursday, 24 March 2011 9:06 p.m. To: For openEHR technical discussions Subject: GUI stuff in AOM/ADL? (Was: future ADL-versions) Hi! Yesterday I asked if anybody had any motivated objections to using the openEHR template formalism as a layer to catch some GUI-hints/rules. I bring it up again to get some response :-) The point to have separate concerns in separate artifacts is often good. Regarding GUI-hints it seems reasonable to not have them at the clinical archetype level, and in some cases not at a first clinically focused template level either. But, as we have discussed earlier, through specialisation and/or inclusion it's possible to have several layers of openEHR templates. This means that ADL or some other serialisation format of the archetype object model (that now will include templates) can be used for GUI-related annotations and GUI-related logic in some form. Does anybody have concerns or worries regarding this? You could still have separate artifacts by splitting reusable clinical modeling and use case specific GUI modeling in separate layers of templates. A nice thing with reusing the template formalism for catching GUI stuff is that shared tools and understanding is already in place as opposed to inventing some new purely GUI-related formalism. Also in some cases it's likely that the same groups that are designing archetypes and clinically focused templates will have knowledge of some use cases in which they know what they'd want to happen on the GUI side. Then it would be nice to be able to reuse people, tools, template governance repositories etc. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 P.s. (off topic) I'm not sure it's always optimal to split everything into separate artifacts, especially when it comes boundary problems like terminology bindings. You could argue that the binding should be done in a separate artifact that is neither part of archetypes nor part of terminologies, but I'm not sure that would always make things better. Having the bindings in the archetype forces the archetype authors to revise the bindings at the same time as they revise an archetype and that might be good. On the other hand you could argue that a SNOMED CT refset might be exactly such a third artifact that can be used for managing bindings. But if you would have three different groups maintaining archetypes, refsets and terminology systems
Use Archetypes and ADL file in Java
Hi Alessandro, Think of ADL as a format for plain text files, an ADL file represent an instance of the AOM classes (that's why you have to parse ADL into AOM). For working with the RM, take the blood pressure observation archetype as an example. In our RM implementation (http://code.google.com/p/open-ehr-gen-framework/) you have an Observation class (http://code.google.com/p/open-ehr-gen-framework/source/browse/trunk/open-ehr-gen/grails-app/domain/hce/core/composition/content/entry/Observation.groovy) you have a data attribute of type History (http://code.google.com/p/open-ehr-gen-framework/source/browse/trunk/open-ehr-gen/grails-app/domain/hce/core/datastructure/history/History.groovy), History can have many Event (http://code.google.com/p/open-ehr-gen-framework/source/browse/trunk/open-ehr-gen/grails-app/domain/hce/core/datastructure/history/Event.groovy), and each Event. Event have a data attribute of type ItemStructure. ItemStructure is an abstract class, so only with the RM implementation, you don't know what is the structure and how to set this information, that information is in the instance of the blood pressure archetype, you can find it here: http://www.openehr.org/knowledge/ In this archetype, you'll see that the Event.data is defined as ItemTree, not as ItemStructure, and ItemTree is a concrete class of ItemStructure. The point here is: you have to process the AOM instance to know what is the concrete RM structure that represent your clinical concept, like blood pressure. Then, you create your RM instance and set data values the same way you create an instance of any object oriented model. Hope that helps. -- 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 Date: Wed, 30 Mar 2011 02:09:04 -0700 From: padiglionestation at gmail.com To: openehr-technical at openehr.org Subject: RE: Use Archetypes and ADL file in Java Pablo Pazos Gutierrez wrote: Hi Alessandro, ADL defines the structure of your clinical data, In practice, ADL defines an instance of the archetype object model (AOM), that instance is the one you can handle from java. But the clinical data values must be set on the reference information model (RM). So, you must have: an implementation of the AOM, an ADLParser that parses ADL to an instance of AOM, and an implementation of the RM, and processing the AOM you can create an empty instance of the RM (empty because you have no clinical data yet). Here you can find a project (my degree thesis) that implements openEHR, and can generate any clinical record (is Java based): http://code.google.com/p/open-ehr-gen-framework/downloads/list -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 29 Mar 2011 06:24:25 -0700 From: padiglionestation at gmail.com To: openehr-technical at openehr.org Subject: Use Archetypes and ADL file in Java Hi everybody I'm Alessandro OpenEhr is I'm working on for my thesis.For the moment I'm using java in the ADLParser file for the openEHR EHRS-. blood_pressure.-OBSERVATION v1.0 adl. I wanted to know, via java objects, how to handle this archetype in java and assign values, such as the systolic pressure. More generally, how can I access the OpenEhr archetypes in java? I attach the file that I have produced so far. Thank you for your attention, good job. Alessandro http://old.nabble.com/file/p31266646/Test_Archetype.java Test_Archetype.java -- View this message in context: http://old.nabble.com/Use-Archetypes-and-ADL-file-in-Java-tp31266646p31266646.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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical Thanks for your reply and for the documents that I have passed.From what I understood ADL class represents an instance of AOM right?If you would like to know how I can map the archetype on an RM? Let me explain better: how ADL I openEHR-EHR-OBSERVATION. blood_pressure. v1. I like adl access its properties via the RM Observation? You can find some examples in this regard? I apologize but I am beginning with OpenEhr. -- View this message in context: http://old.nabble.com/Use-Archetypes-and-ADL-file-in-Java-tp31266646p31275301.html Sent from the openehr-technical mailing list archive at Nabble.com
on the possibility of 'one information model' in e-health
Hi Thomas, I agree that the essence of this issue is to detect generic/reusable patters or ontological components, and then derive our information models from these components. Just two thoughts: 1. A marketing issue: If these patterns are directly derived from some existent IM, then we will have the same trouble of defining one common IM: my model is better than yours, so we'll never agree. I think we must represent and present these patterns as ontological components, trying to avoid the copypaste of the pattern from one o the other IM. I know that de openEHR IM is derived from an ontologial analisys of thereality,so we can see it as a concrete ontology for healthcare information, but it is not presented as a concrete ontology, is presented as an IM to be implemented on software. I don't know if I mess up this explanation, just want to tell that we must be careful in the way we present, represent and name things if we want a global agreement. 2. The current openEHR IM is great for dealing with clinical record information and micro clinical processes (Instructions, Activities, Actions and the associated state machine), but not for the macro processes that embrace the micro clinical processes, and for building computerized information systems we need those processes modeled also. For example, if a traumatized patient comes to the ER in an ambulance, and then is derived to an ICU, we have a global process of trauma care, then we have macro processes like prehospitalary care, emergency care, and ICU care. In each of these macro processes we have multiple workflows excecuted in paralel, and different types processes but interdependent like administrative (patient identification, human resource assignation, etc), clinical (observations, actions, evaluation, etc), accounting (resource ussage), and financial (healthcare costs). so, if we model patters or ontological components, I think these must represent (in a generic way) the macro processes, not only the micro-clinical processes. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 9 May 2011 14:11:07 +0100 From: thomas.be...@oceaninformatics.com To: openehr-clinical at openehr.org Subject: Re: on the possibility of 'one information model' in e-health CC: openehr-technical at openehr.org On 09/05/2011 13:51, pablo pazos wrote: Hi Thomas, I've left a comment in your blog but is not appearing, so I comment your idea here. I don't think today it can be possible to have one information model agreed by all the medical informatics community, but I think if we can agree in a common metamodel like an ontology that represent the more generic concepts in medicine, like people, processes, resources, records, etc, we will be one step closer to a common IM. yes, that's pretty much what I was suggesting. Because if we can agree on that ontology, all the information models in healthcare MUST follow the ontology, so, different information models can live together, but they model the same concepts (semantically speaking). With different models, but semantically equivalent, the point of convergency will be closer. information models, at least abstract ones are in effect an ontology in themselves: they are a description of information that either exists, or we want to exist. So it seems reasonable that a pragmatic UML model, with an appropriate level of abstraction can be used for just this purpose - to describe and agree on key patterns. If this were true, it would mean that the challenges for agreement are: agree on the list of patterns; I have proposed some basic ones; your list above implies another set of candidates to help agreement, some kind of rating system would probably be needed so that at least some 'core' patterns could be agreed, even if some patterns / concepts remained beyond agreement for each pattern, agree its abstract definition. this means defining as much of the pattern in the IM as can be agreed, and not more. An example of one of the patterns, modelled in UML is the 'history of events' one here. Could this or something like it be agreed across e-health for interoperably representing the common concept of a history of events? If sufficient patterns could be agreed, then an 'information model' consisting of these would in effect be a 'common information model' for the medical informatics community - whose scope is interoperable representation of the patterns contained within. It seems to me
Who is using openEHR pages: UPDATES REQUESTED
Hi Thomas, we're developing an open source ehr framework based on openEHR: http://code.google.com/p/open-ehr-gen-framework/ I think this doesn't fall in any category: we started in the academic area, but now we are developing in an independent way. Can you add an opensource category? Thanks. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 17 May 2011 12:40:36 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org; openehr-clinical at openehr.org Subject: Who is using openEHR pages: UPDATES REQUESTED As the number of organisations using openEHR grows, it would be useful to keep the 'Who is using it' pages up to date. Please review the following pages. commercial orgs government programmes academic organisations non-profit organisations It might be appropriate to move this content to wiki pages, which would enable relevant parties to keep the information up to date themselves - please indicate if this is a preferred approach (note that wiki pages are more susceptible to hacking, and also that organisations need to follow some basic rules of acceptable use, particularly commercial organisations). Alternatively, updates can be made on the web pages by sending email to webmaster at openehr.org. - thomas beale ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110527/dc8a639b/attachment.html
occurrences and cardinality in ADL, XML, JSON
Hi Thomas, do you have some examples of the JSON produced with your P_ classes
from a couple AOM instances? It would be nice to see the results.
I don't see why anyone would dislike not to have each node's type specified in
the serialization form when we are talking about a schema-less format (I mean:
we don't need to put each node's class in every instance of a JSON/YAML
serialization from an AOM instance) and if we could agree a specification of
this format (and the specification will have each nodes type, or a mapping to
an AOM object that has a type defined in the AOM specs).
This is not the issue, but I don't like the name persistence for the package,
because I get the idea this is only for persisting something, but what I realy
want to do is to use the serialization for archetype interchange (between a
server and a web browser).
--
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
Date: Sat, 12 Nov 2011 01:04:22 +
From: thomas.be...@oceaninformatics.com
To: openehr-technical at openehr.org
Subject: Re: occurrences and cardinality in ADL, XML, JSON
On 11/11/2011 16:21, pablo pazos wrote:
Hi, I was thinking of this a lot: using a schema-less formats to
represent archetypes and RM instances.
I think if we agree on a common
language/standard/definition, we don't need to define the
types of any node on a JSON/YAML structure, because those
types are defined on the laguage/standard/definition those
structures will follow. And if we define a good serialization
to JSON/YAML of archetypes and RM instances, we don't need a
schema to share instances of those structures, we just need to
implement the serialization definitions, and base the parsing
on the attribute names.
What do you think?
PS: I was thinking of archetypes serialized to JSON because I
want to build a web-based GUI Generation layer completely
implemented with Javascript (JSON objects are javascript
objects), so we can useshare this thin layer to show
archetype-based GUI generation easily, and, if we have a REST
layer that implement EHR-Server services, we can user that GUI
layer to send data input to the server and get information to
show (a complete circle). If anyone want to collaborate on the
JSON format of ADL/AOM please send contact me.
--
Again, I agree with this point of view. But XML people may not
but now I should clarify something...
I should have explained on other thing: what I have done in the
current AOM 1.5 implementation (but not yet documented) is to create
a parallel set of P_XX classes ('P_' means 'persistent') like
P_ARCHETYPE, P_C_OBJECT and so on. These classes formally specify
the serialised form of the archetype so there can be no ambiguity.
It is these classes that current have occurrences, cardinality and
existence defined as String properties. There are a few other
simplifications as well. My proposal is to add these P_XX class
definitions to the specification. It mihgt seem like slight overkill
(and I resisted it for a long time) but once I implemented it, it
seems worthwhile, and it allows us to separate the in-memory
computable version of the AOM from a P_ version whose sole purpose
is serialisation. The Eiffel P_ classes are here;
it is easy to imagine what the Java, Python etc would look like.
So Pablo's argument, applied to the P_ classes would indeed mean
that the serialised form in JSON, YAML (also dADL) is a pure
consequence of the P_AOM classes, and no extra logic is needed. That
is why I built the P_ classes.
- thomas
___
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/2011/2518f9fa/attachment.html
Bosphorus web services beta announcement
Thank you Seref impressive work! I'll try the JSON services to do some javascript gui generation. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 15 Nov 2011 09:45:18 + Subject: Bosphorus web services beta announcement From: serefari...@kurumsalteknoloji.com To: openehr-technical at openehr.org Dear members of the openEHR community, Having reached a point where project Bosphorus has reached a functional state, we have deployed and experimental web service under Opereffa's current server. The web service exposes the archetype parser functionality of Thomas Beale's Eiffel code base with XML and JSON output. There is a simple web application at http://opereffa.chime.ucl.ac.uk/bosphorus/ which uses this web service to display XML and JSON output. The web service is as simple as possible to use: calling http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypeslist returns an XML list of the archetypes in repository, and calling http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetype with the archetype name as the parameter such as: http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetype?archetypeName=openEHR-EHR-CLUSTER.case_identification.v1 returns the XML output. Simply changing the URLS to http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypeslistjson and http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypejson allows access to JSON output. There are known issues in the XML output, which we are fixing at the moment, but we felt that the current state of the code is capable enough to share with the community, to demonstrate the idea of turning key openEHR infrastructure functionality into web services. Thanks to functionality of the Eiffel reference implementation, this web service handles the processing of ADL 1.5 specific features and its XML output is valid according to published XML schemas (version 1.0.1). Please note that the XML or JSON output is only data, therefore its content must be placed into an AOM implementation to become a complete parser output, and we look forward to hearing from implementers, especially in the Java space to collaborate on this. In the near future, we are going to be extending the set of services, and we would be glad to hear about your ideas for new web services in the tooling space. The packaging and release of code will follow soon, but it will take time since Bosphorus has a fairly complicated development setup, requiring Java, C/C++ and Eiffel development setups to be configured jointly. The reference deployment of the web service is therefore the most practical way of experimenting with functionality. There are issues related to serialization of various AOM items, and it you notice errors in the XML output, please let us know so that we can fix them. We would like to thank Thomas Beale of Ocean Informatics for providing access to his Eiffel source code and his contributions to this work, which enables us to share our work with the community. Kind regards Seref Arikan Professor David Ingram, UCL, CHIME ___ 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/2015/f7fc7e65/attachment.html
Bosphorus web services beta announcement
No problem, I'm sure this could be used to GUI generation, since we already had this implemented, but we need to represent our templates with JSON too to do a 100% javascript GUI generator, now I have translate our XML templates to JSON and do a couple of tests. I'll let you know when I have something to show. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 15 Nov 2011 15:27:28 + Subject: Re: Bosphorus web services beta announcement From: serefari...@kurumsalteknoloji.com To: openehr-technical at openehr.org Thanks Pablo, I'm going to be updating the service today, and it is not a production service, but if you have any issues do let me know. It would be interesting to see if this can support a gui generation scenario. Please let us know how it goes! Kind regards Seref On Tue, Nov 15, 2011 at 3:19 PM, pablo pazos pazospablo at hotmail.com wrote: Thank you Seref impressive work! I'll try the JSON services to do some javascript gui generation. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 15 Nov 2011 09:45:18 + Subject: Bosphorus web services beta announcement From: serefari...@kurumsalteknoloji.com To: openehr-technical at openehr.org Dear members of the openEHR community, Having reached a point where project Bosphorus has reached a functional state, we have deployed and experimental web service under Opereffa's current server. The web service exposes the archetype parser functionality of Thomas Beale's Eiffel code base with XML and JSON output. There is a simple web application at http://opereffa.chime.ucl.ac.uk/bosphorus/ which uses this web service to display XML and JSON output. The web service is as simple as possible to use: calling http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypeslist returns an XML list of the archetypes in repository, and calling http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetype with the archetype name as the parameter such as: http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetype?archetypeName=openEHR-EHR-CLUSTER.case_identification.v1 returns the XML output. Simply changing the URLS to http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypeslistjson and http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypejson allows access to JSON output. There are known issues in the XML output, which we are fixing at the moment, but we felt that the current state of the code is capable enough to share with the community, to demonstrate the idea of turning key openEHR infrastructure functionality into web services. Thanks to functionality of the Eiffel reference implementation, this web service handles the processing of ADL 1.5 specific features and its XML output is valid according to published XML schemas (version 1.0.1). Please note that the XML or JSON output is only data, therefore its content must be placed into an AOM implementation to become a complete parser output, and we look forward to hearing from implementers, especially in the Java space to collaborate on this. In the near future, we are going to be extending the set of services, and we would be glad to hear about your ideas for new web services in the tooling space. The packaging and release of code will follow soon, but it will take time since Bosphorus has a fairly complicated development setup, requiring Java, C/C++ and Eiffel development setups to be configured jointly. The reference deployment of the web service is therefore the most practical way of experimenting with functionality. There are issues related to serialization of various AOM items, and it you notice errors in the XML output, please let us know so that we can fix them. We would like to thank Thomas Beale of Ocean Informatics for providing access to his Eiffel source code and his contributions to this work, which enables us to share our work with the community. Kind regards Seref Arikan Professor David Ingram, UCL, CHIME ___ 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 -- next part
Serialisation of openEHR Models
I still want to see the glass of water half full: this is in fact a validation and the recognition of an emblematic member of HL7 that the openEHR approach is useful and needed to reach true interoperability, the name (archetype, data element, ...) is not the important part, neither who invented it first, but the use of the same concept is the key. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 7 Nov 2011 15:50:42 + From: thomas.be...@oceaninformatics.com To: openehr-clinical at openehr.org Subject: Re: Serialisation of openEHR Models On 07/11/2011 13:54, pablo pazos wrote: Last week I attended to an Ed Hammond's talk in Argentina, and in his presentation he mention a new concept to reach true interoperability: the data element. Please see page 13-14: http://www.hospitalitaliano.org.ar/archivos/noticias_archivos/11/Jornadas2011/11_11.01-03-Hammond-Interoperability-BuenosAires.pdf I asked him why this sounds so much like openEHR archetypes and why don't reuse this concept instead of creating a new one (or at least renaming it). He told me everyone want his own standard, that was very sad. Besides that, what I see (and many people on that room that know what is an archetype) is a validation of an important figure on HL7 that archetypes work, do the job, and are necessary for interoperability. So, I think HL7 is very interested on archetypes right now. I hope that soon Mr. Hammond could do a presentation on standarization that show the best of the breed instead of reinventing/renaming the wheel. -- With all respect to Ed (and he deserves a great deal), if in sentences like the one you quoted above you replace 'everyone' with 'HL7', the situation today starts to make more sense. - thomas ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2007/8dd12a40/attachment.html
Questions about the necessity of ITEM_SINGLE
Hi! Your comments are very interesting, and I think we all converge to the same point. For the transition steps mentioned by Thomas, I think we could do quick change with backwards compatibility, adding things without removing the ITEM_STRUCTURE package. We could do a fork also, and start to work in a new model without affecting current tools, and join the specs, tools and archetypes at some point on the future. Now, how do we proceed? I don't know if there's a formal way to do a Change Request to the RM. I don't want to leave this issue to die on the lists. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111004/7588c5be/attachment.html
openEHR course in spanish
Hi Sam, That's the idea first an overview and later all the details and all the fun :D I have an introduction from a workshop I made last year that shows how we create software today, and how our way of creating software is a problem in the healthcare domain. I'll use this introduction with some hidden references to key points of openEHR like having all the clinical knowledge outside the software application instead of having it hardcoded on the software. Good point, I'll try to introduce the tools earlier. But I need practice! (my experience with the ADL Workbench is very limited). Thank you Sam. Cheers,Pablo. From: sam.he...@oceaninformatics.com To: openehr-technical at openehr.org; openehr-clinical at openehr.org; openehr-implementers at openehr.org Subject: RE: openEHR course in spanish Date: Thu, 20 Oct 2011 07:34:48 +0930 Hi PabloThis looks excellent. There is some repetition but it is clear that you are providing an overview in the first classes and drilling down in later classes. I would suggest that you might actually introduce some of the tools a little earlier as people will have more fun if they can build or edit some models.Cheers, Sam From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Tuesday, 18 October 2011 7:36 AM To: openehr clinical; openehr technical; openehr implementers2 Subject: openEHR course in spanish Hi, I'm trying to impart a course on openEHR for spanish speakers audiences, here is the agenda for the course: http://informatica-medica.blogspot.com/2011/10/curso-de-openehr-en-espanol.html Please click on the ENGLISH link on the top-right corner to translate the page. This are my 2 cents in spreading openEHR in the latin-american medical informatics communities. It would be nice to have the feedback of the openEHR community on the topics of the course. Any comments, sugestions, references, resources, etc, are very welcome! -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos ___ 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/20111019/27ba49b2/attachment.html
Questions about the necessity of ITEM_SINGLE
Hi everyone, I've been studying how to simplify the ITEM_STRUCTURE model to enhance the persistence performance of our Open EHR-Gen project (http://code.google.com/p/open-ehr-gen-framework). Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some arguments and hear your comments about it. Semantic argument: As I understand ITEM_SINGLE, the semantics of this class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1). Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the interface of each class can be the same, like: getItems(), setItems(), the ITEM_SINGLE breaks that with getItem() and setItem(). Evolution argument: If I have an archetype with an ITEM_SINGLE, but the concept modeled with this archetype needs to change adding more nodes to the archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I can add any nodes without changing the ITEM_STRUCTURE type. I think this way is more simple to create new archetypes with backwards compatibility. What do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111003/732ac796/attachment.html
openEHR Transition: two procedural and one licensing question
Hi, I think Diego's point is to change this ... directly interacting with the Clinical Knowledge Manager and equivalent repository and review toolsto something like ... to interact with any Clinical Knowledge Manager through a standard API (to be defined). -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 5 Sep 2011 21:49:01 +0100 Subject: Re: openEHR Transition: two procedural and one licensing question From: ian.mcnic...@oceaninformatics.com To: openehr-technical at openehr.org Hi Diego, I understand from Sebastian that you have been exploring the current CKM web services. Do you think these might form the basis for an open repository API or do you have any other comments or alternative suggestions? Ian On Monday, 5 September 2011, Sam Heard sam.heard at oceaninformatics.com wrote: Thanks Diego [Sam Heard] This would be a step forward and would allow for slim and fat systems to offer the same basic calls. My suggestion is for the this point Begin an open source software project for tools, web-based if possible, to author archetypes, templates and terminology reference sets directly interacting with the Clinical Knowledge Manager and equivalent repository and review tools I agree with the first part (create web-based open source tools), but I think that the second part should be clarified. We should define a basic API to access repositories, to avoid doing ad-hoc implementations for each one of the possible repositories ___ 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)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org ___ 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/20110905/d139ddbb/attachment.html
openEHR Transition: two procedural and one licensing question
Hi Shinji, That's exactly what I tried to point in another mail to the lists: local and regional openEHR organizations should be supported by openEHR and we need to put it into the white paper. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 6 Sep 2011 19:13:45 +0300 Subject: Re: openEHR Transition: two procedural and one licensing question From: skoba at moss.gr.jp To: openehr-technical at openehr.org Hi All, I have been suffered by sever jet lag after long trip, while I have been thinking about this new white paper and our local activity. I could not find such localisation activity in this white paper, but please consider and mention about such local activity. I would like to show these two proposals. 1) Local activity support. As a global standard, localisation to each country or area is necessary. My three years experience to implementation of the Ruby codes, archetypes and template, we need lots of localisation efforts for Japanese use. I think this experience may be available to localise for other countries. East Asian countries people is keen in openEHR development and their engagements are promising for their health care. 2) Premature artefact repository CKM provides us well-considered archetypes and templates. This is a great knowledge resource for mankind. However, to incubate archetype as a common concept takes long time like vintage wine. On the other hand, I need more agile movement for daily development. I have developed about 50 archetypes and 6 templates. These artefacts are still premature to evaluate on CKM, but I would like to discuss about my artefacts on line with many people. Yes, it will be a 99% junk repository, but 1% diamond would be a precious for our community. As Major league cannot exist without minor leagues, I think CKM needs such minor artefacts groups. I am preparing to share them on GitHub, because anyone can use repository for each use by fork and merge request is useful. I think the licence of this repository would adopt CC-BY-SA, is this OK, Erik and Ian? Cheers, Shinji KOBAYASHI(in Japan, a path of typhoon.) 2011/9/6 Erik Sundvall erik.sundvall at liu.se: Thanks for replying Sam! Erik Wrote (to openEHR-technical at openehr.org): Was that whitepaper formally ratified by the new board, or by the old board, or is it's current state just a suggestion by Sam? On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at oceaninformatics.com wrote: [Sam Heard] The whitepaper was ratified by the participants in the planning process, the current Board (Profs. Kalra, Ingram and myself) and the new Transitional Board. This is a bit worrying for the period until a broader board can be elected. I was hoping that somebody within the new board would be interested enough and have time to take licensing issues and community feedback seriously, let's hope that the board does a bit more research and community dialogue before ratifying a new version of this whitepaper. Could somebody from the board please confirm that you'll take a serious look at this in the near future? Erik wrote: What is the mandate period of the transitional board? When will the suggested new structure with an elected board start? On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at oceaninformatics.com wrote: [Sam Heard] I for one am very happy to express a date for elections if organisations embrace these arrangements. Clearly if there is no interest in participating from industry or organisations then we would have to think again. I suspect we will then move to election of the Board by Members but it is our wish to provide a means of determining the governance for openEHR?s key sponsors. The aim is to balance the Members with governance from the funders and sponsors. Some may prefer a democratic organisation top to bottom; we do not think this will achieve the best results. So there is no absolute end date set. :-( The if organisations embrace these arrangements part is worrying, especially since we already have seen failed attempts at getting buy-in from organisations. Can't you set an absolute latest date (e.g. at the very latest December 31, 2012) when the new arrangements will start no matter if big organisations have made use of the introductory offer of buying a position in the board? If not, we risk having an interim board forever, and we really don't need any more delays in the journey towards community-driven governance. If you get buy-in from the number of big players you want before that absolute end date then there would be nothing stopping you from doing the transition earlier than the latest date. Erik wrote: The thoughts behind the third point in the Principles of licencing
openEHR Transition Announcement (about regional/national openehr organizations)
Great, please let me know if I can help. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Subject: Re: openEHR Transition Announcement (about regional/national openehr organizations) From: sam.he...@oceaninformatics.com Date: Wed, 7 Sep 2011 07:15:26 +1000 To: openehr-technical at openehr.org Hi Pablo It needs to be added. Thanks Sam Sent from my phone On 07/09/2011, at 1:38 AM, pablo pazos pazospablo at hotmail.com wrote: Hi, Not so long ago we have discussed about a governance and organization model to the openEHR community, and we have talked about regional/national openEHR communities (http://www.openehr.org/wiki/display/oecom/Foundation+Organisational+Structure). I can't find this mentioned in the whitepaper. I think if we want to have a global impact on the ehr scene, we need to support those communities also, and define ways to coordinate the work of the community as a whole. What do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 5 Sep 2011 02:00:45 +0100 From: thomas.be...@oceaninformatics.com To: openehr-announce at openehr.org Subject: [openEHR-announce] openEHR Transition Announcement Dear All, I am writing on behalf of the new Transitional Board of openEHR to share our plans to take openEHR to a new level of operations; a new structure, business model and governance. Our vision is the creation of a thriving community that works collaboratively to benefit humanity through efficient and effective electronic health records (EHRs) that support the highest quality health care for the least effort. Until now, the openEHR Foundation has functioned as an owner of intellectual property, governed by University College London and Ocean Informatics, with board members Prof David Ingram (UCL), Prof Dipak Kalra (UCL) and Dr Sam Heard (Ocean). With the support of the considerable community of Members and via engagement of a new category of sponsoring organisational Member known as ?Associates? - Companies, Universities and Governments - the Transitional Board proposes a number of changes: The openEHR Foundation becomes an operational non-profit organisation with paid key staff and resources; The Board (of governance) of the Foundation is extended to up to 10 people with a shift to election by the openEHR Associates; Members who participate are recognised by their peers, may take on decision-making roles, and have the right to commit changes to the key development assets of the Foundation. The Members will participate individually and, through qualification by peer recognition, will control the development within the three Programmes that are building the key assets: The openEHR specifications of the logical health record and attendant services as well as the methods for describing the content using archetypes (Detailed Clinical Models) and templates; and The openEHR archetypes and templates to be used within systems and for message content between systems to achieve interoperability; and The openEHR software projects, to provide open source development of tools to support the uptake and use of the specifications and templates. A group of Members will be needed to bootstrap each of these programmes and determine the working arrangements that are suitable to the products that they are managing at the current stage of development. The Associates will determine who governs the Foundation by nominating and voting on new members of the Board. The Board will appoint key Operational staff and will approve the leader of each of the Programmes. The Programme Leaders will be appointed by Qualified Members working in that Programme, subject to Board approval. We believe this will create the right balance between the ?ground up? creation of openEHR through participation of Members and ?top down? governance. The first step is to share with you a white paper providing more detail on the proposals and to ensure that the Members are reasonably satisfied that this is the right direction to head. Some key
openEHR Transition Announcement (about regional/national openehr organizations)
Hi Ian, So, my question back, is What sort of support would you like to see, given that significant central resourcing is not likely in the short term? I think we (local/regional organizations working with and on openEHR) need formal support from the openEHR fundation. One basic form of support is to recognize the local/regional openEHR organizatons as such. Other is to recognize our contributions to the community, like mentioning our work on presentations, publications and other public communications (I think a public communications strategy should be traced by openEHR foundation). If we think of money, there are ways of money support without giving real money: we need software tools (archetype template editors), we need access to events far away, we need books, educational resources, etc, etc. The foundation should draw yearly general goals, to the openEHR project as a whole, and to the local/regional representatives. And should follow and coordinate the work and evaluate the results. Those goals could be technical, educational, communicational, among other kinds. Here is a related thread with some other ideas: http://www.openehr.org/mailarchives/openehr-implementers/msg00889.html What do you think? Regards, Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110907/e2f181c7/attachment.html
openEHR Transition: two procedural and one licensing question
I agree with you Shinji, well said! -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Wed, 7 Sep 2011 21:15:34 +0900 Subject: Re: openEHR Transition: two procedural and one licensing question From: skoba at moss.gr.jp To: openehr-technical at openehr.org Hi Sam and all Thank you for comments about localisation. First of all, I emphasize LOCALISATION is not ISOLATION. Only to fork and arrange global resource for local usage is isolation. True localisation is to feed back such experience to enrich core implementation. I think endorsement program at page 4 of white book should include localisation as global promotion, and endorsement / promotion program should have a board like other specification / clinical modeling / software engineering. Because local activity management depends on its own domestic situation, local governance should be decided by local community. However, bad localisation disgrace all of our community and makes people unhappy in its area. So I think local activity requirements are, * Keep contact with global community * Implement openEHR clinical models for domestic use. * Provide proper translation, specialised implementation for their domain. * Promote openEHR specification for their domain.(Web/mailing list) * Governance of local community as good status * Feed back localisation experience to global community. I also think two or three of these conditions are enough to be a local activity. These are my requests from Japan(probably from other local activities, too) * Permit to use openEHR name and logo for domestic promotion. * Publish local activity directory for whom need to contact with them on the openEHR.org web. * Disallow to use openEHR name and logo whenf you think we are not worth to use. * Keep contact with local activities. Cheers, Shinji KOBAYASHI 2011/9/7 Sam Heard sam.heard at oceaninformatics.com: Hi Pablo and Shinji Supporting localization both technical and operational needs to be included. The no language primacy principle is a real winner, different written forms of the same language is not covered as yet. How local groups run is another, clearly these can be national or context based. Thanks for the input. Cheers Sam Sent from my phone On 07/09/2011, at 2:38 AM, pablo pazos pazospablo at hotmail.com wrote: Hi Shinji, That's exactly what I tried to point in another mail to the lists: local and regional openEHR organizations should be supported by openEHR and we need to put it into the white paper. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 6 Sep 2011 19:13:45 +0300 Subject: Re: openEHR Transition: two procedural and one licensing question From: skoba at moss.gr.jp To: openehr-technical at openehr.org Hi All, I have been suffered by sever jet lag after long trip, while I have been thinking about this new white paper and our local activity. I could not find such localisation activity in this white paper, but please consider and mention about such local activity. I would like to show these two proposals. 1) Local activity support. As a global standard, localisation to each country or area is necessary. My three years experience to implementation of the Ruby codes, archetypes and template, we need lots of localisation efforts for Japanese use. I think this experience may be available to localise for other countries. East Asian countries people is keen in openEHR development and their engagements are promising for their health care. 2) Premature artefact repository CKM provides us well-considered archetypes and templates. This is a great knowledge resource for mankind. However, to incubate archetype as a common concept takes long time like vintage wine. On the other hand, I need more agile movement for daily development. I have developed about 50 archetypes and 6 templates. These artefacts are still premature to evaluate on CKM, but I would like to discuss about my artefacts on line with many people. Yes, it will be a 99% junk repository, but 1% diamond would be a precious for our community. As Major league cannot exist without minor leagues, I think CKM needs such minor artefacts groups. I am preparing to share them on GitHub, because anyone can use repository for each use by fork and merge request is useful. I think the licence of this repository would adopt CC-BY-SA, is this OK, Erik and Ian? Cheers, Shinji KOBAYASHI(in Japan, a path of typhoon.) 2011/9/6 Erik Sundvall erik.sundvall at liu.se: Thanks for replying Sam! Erik Wrote (to openEHR-technical at openehr.org
openEHR Transition: Community Knowledge repository
Hi David, I think the current tools are as good as one can imagine for this moment, what I mentioned was of the tools we need to the future, and maybe some ideas to add to the whitepaper. (I wanted to be clear in this point, sometimes my bad english doesn't let me to express my ideas in a clear way, sorry for that). What I meant with freeopen tools was ment for the local and regional CKMs, and with a clear API, we could develope local CKMs that are interoperable with the global CKM (without changing any of the current great work). Thank you David, I'm here to help in any way I can. I'm sure that openEHR is the way to go and I'm sure that we need to move forward together. There are a lot of great professionals in this community and I have learned and grow a lot since the first time I worked with openEHR in 2006. I regret there aren't more coleagues from south america participating on this great community, that's why I insist with the local openEHR communities, to engage this people (and selfishly to don't feel so lonely :D). Cheers, Pablo. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Wed, 7 Sep 2011 20:39:05 +0100 From: rmhi...@live.ucl.ac.uk To: openehr-clinical at openehr.org Subject: Re: openEHR Transition: Community Knowledge repository Hi Pablo - re- your important observation below. It was a difficult decision to go with a proprietary product to underpin the openEHR CKM, but at the time there was no apparent open source tool to provide the first stage functionality required. It is complex and expensive software to develop and maintain and, through the good offices of Sam and Ocean, we secured a free license to support the CKM repository, which we were thereby enabled to make quickly available for experimental use. Of course, open-source tools are not cost and resource neutral options, but it is certainly easier for many to engage along an open source pathway of development. That said, I believe that going with the proprietary CKM was a sensible decision at the time (it was and had to be Dipak's and mine, I should say, and in no way an Ocean decision). It has certainly been fully vindicated, in my eyes, by the free use that has been made of it, which we can observe day by day, within both the openEHR community and several cognate groupings, all over the world, exploring and working with the archetypes now residing in the public CKM repository that Ocean has generously created and maintained throughout, for the openEHR community. Looking forward, Ian's link with Derek Hoy/Snowcloud and the offer he has made, is interesting and potentially a very useful new thread in the tooling agenda for openEHR. I don't think anyone imagines we are near to an ideal tooling environment to support effective clinical engagement with archetype/template/terminology development and support. The field will undoubtedly benefit from concerted and coordinated efforts to create new and better open source tooling in this area - a goal that is dear to many clinicians' hearts, I know - Tony Shannon and Dipak Kalra, to name but two! Forgive my inquisitiveness, Pablo, but I have just located and read your impressive CV and you seem exactly the right sort of person to join with others discussing here, in taking forward an initiative like that for the openEHR community. Once Sam and the new board (fully operational from October 1st) has given time for its current consultation about future governance to evolve into decisions about next steps, I very much hope there will be a way for you to do so. David I -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110909/9c69212d/attachment.html
openEHR Transition: Web-based tools?
Hi Ian, We develop web based systems because we are web developers. In my case I have started my programming skills on web based systems, and now I have learned a lot of tools, frameworks and web standards and I have very little experience on desktop based tools. Said that, I think desktop based tools have the same value and usability as the web based ones. There are tools that by nature have to be web based, but other tools like the template editor is ok on desktop. I have the dream that one day I open just one program (a web browser) and get free access to all the archetypes and templates available in the cloud (multiple CKMs), and may create, edit and share those artefacts also online. Sometimes I think about something like an openEHR facebook, where archetypes are people, templates are groups, and all are related by slots (friend relationships). This is just a dream... -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Fri, 9 Sep 2011 16:10:10 +0100 Subject: openEHR Transition: Web-based tools? To: openehr-technical at openehr.org Hi all, One of the suggestions in the White Paper which appears to have universal support is a move to support much more open-source tools development. Clearly some tooling must be web-based e.g repository management and associated formal and informal discussion e.g. CKM and any new community repository. However, I am much less clear on why we might need web-based primary authoring tools for archetypes and templates. Diego, Pablo and Sam are all keen on this approach but I remain unconvinced that this is really a key requirement, given that archetype authoring is in essence a solitary activity much like any other code development. By all means build in much better integration with repositories and other mechanisms to allow joint working, but even with modern javascript libraries and Flex-style components, HTML-based tooling just feels like it adds a layer of development complexity and probably some usability-clunkiness which is not offset by the benefits. Maybe I am just an old-timer but having waited for may years to get the kind of development environment that Visual Studio, Eclipse and equivalents bring, and that I think is equally required for archetype development, I am loathe for us to get slowed-down by insisting on a 'web-based'. What do others think? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110910/b1bca7a3/attachment.html
openEHR Transition: Web-based tools?
Hi Ian, As I said before: we build web apps because we are web developers. That doesn't mean that web oriented is better than desktop oriented, it depends on the kind of tool you are building. For an editor, maybe desktop is ok. But if you want an editor on the cloud, is ok too (http://phpanywhere.net/). For shared repositores, I think web-based ans with web services (SOAP or REST) is mandatory. I don't think this discussion about web based vs desktop is in the right direction, I prefer to pay atention to our tool chain, and see what approach is best for each link, e.g.: we could have a perfectly integrated ecosystem with the best of both approaches: archetype editor: desktop based (GUI) template editor: desktop based artefact repository: web based EHR backend: desktop based EHR frontend: web based I think our (GUI) template editor will be opensourced soon. I'll let you know. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Sun, 11 Sep 2011 09:38:05 +0100 Subject: Re: openEHR Transition: Web-based tools? To: lavanian at vsnl.net; openehr-technical at openehr.org Hi Dr Lavinian, That was what I had in mind, absolutely integrate with repositories via web-services. I could be persuaded by a full web-based tool if someone could convince that me that difficulties of developing a complex UI are offset by other advantages, that it can operate off-line, that it can quickly implement no-cost, multiple temporary working areas, fully integrate with my other desktop applications and not get mangled by browser updates. I am not at all convinced by the deployment/update argument for web-based tools. It really is not at all difficult to manage packaged downloadable installs, including slip-streamed updates with notifications. I have done this myself with as one developer, 3000 users and a decent install program Perhaps the java environment is harder but my consumer experience of Eclipse and other java apps is not one of horrible complexity. Whilst seamless automatic updating of a web-app is generally helpful, there are situations where such updating conflicts with user wishes, so you end up having to replicate an upgrade only on-demand facility as per Google mail, or 'revert to older version'. But for me the UI issue is critical. I know that javascript and HTML5 developments are improving things all the time but web-based apps are still always more clunky and prone to weirdnesses that you simply do not see with desktop apps. As Seref says this is not the place to document actual UI requirements but I think it is fair to position an archetype/template tool with the UI demands of an Eclipse/VS type application, and as THomas says, no-one is using web apps for this kind of scenario. Pablo - is your web-based template tool visible anywhere? Perhaps you could persuade me that I ma wrong :-) Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org On 11 September 2011 02:25, Dr Lavanian lavanian at vsnl.net wrote: Hi all, Both approaches have their pros and cons. I would suggest a hybrid approach. Have a desktop app with a local Db that updates itself from a web based repository, as per need. This way you could have the security and speed of a desktop app with the 'updatability' of a web model. With warm regards, Dr D Lavanian MBBS,MD CEO and MD HCIT Consultant www.hcitconsultant.com Visit www.medhelp247.com for a life saving medical service Certified HL7 Specialist Executive Member - IAMI Co-Chair, Memberships - HL7 India Member- American Medical Informatics Association Member HIMSS Senior Consultant and Domain Expert - Healthcare Informatics and TeleHealth Former Vice President - Healthcare Products, Bilcare Ltd Former Vice President - Software Division, AxSys Healthtech Ltd Former Co-convener Sub committee on Standards , Governmental Task force for Telemedicine Former Vice President - Telemedicine (Technical), Apollo Hospitals Group Former Deputy Director Medical Services, Indian Air Force Office: +91 20 32345045 Mobile: +91-9970921266 - Original Message - From: pablo pazos To: openehr technical Sent: Saturday, September 10, 2011 11:01 PM Subject: RE: openEHR Transition: Web-based tools? Hi Ian, We develop web based systems because we are web developers. In my case I have started my programming skills on web based systems, and now I have learned a lot of tools, frameworks
openEHR Transition: Web-based tools?
Hi Peter, Web developers can easily tackle those problems, see below: But web based apps bring their own set of problems that desktop apps don't have. Ian has been talking about poor usability. * How do you do keyboard shortcuts in a web application? How do you set keyboard focus to the appropriate widget to maximise ease of use? Both of those can be achieved in a web app, but it's extremely difficult. Just use HTML: http://en.wikipedia.org/wiki/Access_key * How do you recover gracefully when the user's session times out? Imagine you're in the middle of working on an archetype, you spend 20 minutes talking to a colleague or answering emails, and your web session times out. All of your work is gone. There are ways to handle this gracefully, but they are are horribly difficult to program. This problem simply doesn't exist with desktop apps. One way to maintain a session open is to send heartbeats using AJAX: http://en.wikipedia.org/wiki/Ajax_%28programming%29 * How do you design your application so that it performs well without putting half of your business logic into Javascript that is riddled with hacks for handling old browsers? For performance and rich user interaction we have to use AJAX. For compatibility, use standards: http://www.w3.org/ -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110911/c173aafd/attachment.html
openEHR Transition: two procedural and one licensing question
Hi Sam, Let's stay with the issue of how we stop someone copyrighting and charging for a specialised archetype? Or a template that is fundamental to health care (like an antenatal visit)? Cheers, Sam Why we need to define a license to stop someone to copyright or charge for a specialized archetype? I think this could be done by defining user terms to the archetypes downloaded from the CKM (and every CKM around the world must have the same use terms. You can include something like this on the user terms: all artefacts (archetypes, templates, term sets, etc) downloaded from *here* are public and free to use and to specialize. All artefacts derived from those, alse must be free. This is a copyleft scheme. If I want to use artefacts from a public CKM, I must follow those rules. Of course, anyone can create its own CKM and create artefacts from scratch and do whatever they want with those artefacts. I think you can charge for the time you invest in specialize artefacts from public CKMs, but not sell the artifact itself. If you create the artefact from scratch its the creators desition to charge or not. What do you think? Regards, Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110912/1cdf546a/attachment.html
Tools for collaborative working
I agree with you both: we need to get things done and find reliable tools up to the task. Many opensource projects use cloud based services, and don't need/try to make everything open source at the infrastructure level. Jira is great for issue reporting and bug tracking. http://www.atlassian.com/software/jira/ Nabble is great for mailing lists. http://www.nabble.com/ (one thing that bothers me is the 40KB limit of the openEHR lists emails) SVN or Git area great for version control. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Fri, 16 Sep 2011 14:51:33 +0200 From: sebastian.ga...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: Tools for collaborative working I agree with you Thomas, Whether these tools are open source or just free as in beer (for openEHR) - doesn't matter too much...for me it is far more important that the tool does its job. If there are open source tools that really do the job - finevery fine indeed, but if not, I for one, do not want to use tools just because they are open source if we can have better ones that are just free. Not sure where this discussion stems from, but I am reasonably happy with the current Jira, Confluence and SVN approach and do not think that changing this is a huge priority. (It's not like there isn't anything on the foundation's priority list at the moment :-) ) But I may have missed the reasoning why openEHR's current tooling is not sufficient in the first place? Sebastian Am 16.09.2011 14:22, schrieb Thomas Beale: For openEHR, Atlassian hosted solution JiraStudio (not open source) may be worth considering since it solves the problem of physical hosting without (in theory) causing much disruption, since all the tools are the same - Confluence, Jira (particularly) and SVN. Atlassian bitbucket (completely separate from Atlassian mainstream hosted tools) uses Mercurial, a better DVCS than SVN, but its issue tracking etc is minimal. For the price of more disruption, Github would be one place to go, and it is probably the best DVCS there is (it was designed based on the BitKeeper solution we used to use in openEHR). How good the project tracking tools are I don't know, but they are claimed to be good. The main thing that is needed is integrated DVCS, project / issue tracking (with configurable workflows, security etc), wiki, mailing lists and continuous build server. Whether having everything open source is fundamentally important is debatable - in principle it is nicer, but I am more interested in getting work done efficiently, not battling tools that are in early development (certainly my experience with most free issue tracking systems - maybe the Git one is better). - thomas On 16/09/2011 09:29, Ian McNicoll wrote: Hi Tim, Can you give some examples of good open-source tools in this area? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org On 16 September 2011 00:09, Timothy Cook timothywayne.cook at gmail.com wrote: Well, maybe you should consider real open source tools. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/859386ea/attachment.html
Tools for collaborative working
This would be great! One thing I am missing for the java project is a build server, something like Apach Continuum that can check out the latest code, compile, run all the testcases, and publish reports and successful builds somewhere. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/bd4e6d9d/attachment.html
Tools for collaborative working
Hi Bert, I have participated in a lot of open source projects, for a long time, that make use of software in the cloud as infrastructure. These projects are long lasting and because the infrastructure is in the cloud, we as users doesn't have to bother with backward compatibility issues. Cheers, Pablo. I wouldn't trust software which is not open source. You cannot judge if it does its job well, especcially in long lasting use, like f.e. a database, how do you know if it still works if your table reach the million records and the table is 127 fields wide with on the second field a VARCHAR (127), I have seen many strange things in software products. What happens if a vendor gives up, or isn't interested anymore in the specific product, or is bankrupt What happens if a vendor decides to break backwards compatibility, or he is just clumsy? -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/41a43f2f/attachment.html
New release of the Open EHR-Gen framework v0.6
Hi everyone! I'm very pleased to annouce the new version of our openEHR-based framework. Here is a description of the release (spanish only): http://informatica-medica.blogspot.com/2011/09/nueva-version-de-openehr-gen-framework.html English (automatically translated): http://translate.google.com/translate?sl=estl=enjs=nprev=_thl=esie=UTF-8layout=2eotf=1u=http%3A%2F%2Finformatica-medica.blogspot.com%2F2011%2F09%2Fnueva-version-de-openehr-gen-framework.html Enjoy! -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110926/a10078c2/attachment.html
FW: Questions about the relationship between Instruction, workflow and Action
Hi Sam, I'm reviving this thread :D I'm working on a project and we need to define a simple state machine, this is the way I think it should be done and it would be very nice to have you comments about this: The idea is to record physical activity recomended by a clinician. There is one INSTRUCTION (the recommendation) with many ACTIVITIES (each one a recommended sport or activity).We have 4 states: INITIAL, SCHEDULED, ACTIVE and COMPLETED. And there are 2 ACTIONS, one to record the scheduling of the activity and other to record the initiation and end of the activity. (Let's say these are SCHED_ACTION and INIT_END_ACTION). When a recommendation is created (INSTRUCTION and ACITIVITIES), the current state is INITIAL (that should be saved on the repository that you mentioned in your email). Now we need to model the state machine: INITIAL --(schedule)-- SCHEDULED --(start)-- ACTIVE --(finish)-- COMPLETED. So, we create a ISM_TRANSITION on the SCHED_ACTION with current_state = INITIAL and careflow_step = schedule.And in the INIT_END_ACTION we have 2 ISM_TRANSITIONs with curr_state = SHCEDULED and careflow_step = start, and the other, curr_state = ACTIVE and careflow_step = finish. The third part should be to provide the entry point to execute that ISM, so we set the SCHED_ACTION.archetypeId to each ACTIVITY.action_archetype_id, so when the INSTRUCTION is on INITIAL, only a SCHED_ACTION could be executed. And, on any ACTION execution, we update the repository with the action executed and the new state (and we keep all the actions and transitions taken so we can reproduce the process later). What do you think? That's the right way to do it? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: sam.he...@oceaninformatics.com To: openehr-technical at openehr.org Subject: RE: Questions about the relationship between Instruction, workflowand Action Date: Wed, 7 Dec 2011 13:09:31 +0930 Hi Pablo, The design principles are that the Instruction should remain unaltered by people basing actions on this instructions ? as the action and instructions could be disconnected at any moment. For example, the instruction (medication order) should not be changed by anyone just to give a medication etc. So the state of the instruction is carried in the record of the action (if appropriate). We have decided to name the pathway steps and attach a machine readable state to that step. This makes it much easier for clinicians to model and to see what is going on. In our openEHR repository we maintain an instruction index ? that is a pointer to all instructions and all actions that relate to that instruction ? and the current state of the instruction. You will see an archetype ACTION in the openEHR repository and the careflow_steps are archetyped to provide a name and the current state matches an openEHR code for state. This means that a careflow step being carried out will set the state to a particular machine state. Hope this helps. Cheers, Sam From: pazospa...@hotmail.com To: openehr-clinical at openehr.org; openehr-technical at openehr.org Subject: Questions about the relationship between Instruction, workflow and Action Date: Sun, 4 Dec 2011 15:36:36 -0300Hi everyone! I'm trying to understand how to execute a state machine of a fully structured INSTRUCTION, and I have some questions and thoughts to share with you... The first issue is about archetyping an ACTION that execute and ACTIVITY of an INSTRUCTION. Modeling an ACTION, the Archetype Editor let me archetype the ACTION.ism_transition attribute, but not the ACTION.instruction_details. Both attribute classes (ISM_TRANSITION and INSTRUCTION_DETAILS) are specializations of PATHABLE, so those shouldn't be archetypable (see http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 53).Is this a bug in the AE or is an issue in the specs? If the ACTION.instruction_details attribute can't be archetyped in the AE, how could I know what specific structure the ACTION.instruction_details.wf_details attribute will have? Is the ACTION.instruction_details.wf_details attribute related somehow with the ACTIVITY.description attribute? The description of the ACTION.instruction_details.wf_details attribute says: condition that fired to cause this Action to be done (with actual variables substituted),What is the meaning of with actual variables substituted? This makes me think having an ACTIVITY in memory, creating an instance of an ACTION to record the execution of that ACTIVITY, copying the ACTIVITY.description structure into the ACTION.instruction_details.wf_details, and the update the correspondent fields into the wf_details with actual execution data. Does this make any sense? or I'm just to twisted :D The last one!Now only ACTIONs can change a state on the ISM, but I think
