Python / Django experience??
Hi, We started archetype development in the NHS using Subversion and it got in a real mess very quickly. As Pablo says the version and dependencies are not the same as in code. I think we need to consider what are the tools that are needed now to make openEHR more attractive to clinical application developers, and what are the functions of those tools. Let's ensure that businesses can thrive working in the openEHR environment and make sure we try and fill the gaps as the first priority. Cheers, Sam From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Wednesday, 8 February 2012 4:14 AM To: openehr technical Subject: RE: Python / Django experience?? Hi Erik and all, On Thu, Feb 2, 2012 at 18:19, pablo pazos pazospablo at hotmail.com wrote: I don't know if this is crazy talk or if it's seems reasonable to you. Please let me know :D Not crazy, but maybe overly complicated. Maybe I don't present the idea in the best way, but in the end is just some services to advertise/discover artifact repositories/servers, services to do distributed queries, and services for notifications (subscribe/notify). Some of this ideas are in use out there for zillions since Internet born and evoluted. Perhaps it would be a good idea to use a layered approach? 1. An existing distributed version control system (DVCS) like GIT (and an agreed directory structure and naming conventions within it) for storing versioning and distributing archetype source files etc. About using some version control system (VCS), I don't think this is a good solution because the semantics of archetype version are not the same semantics as in plain text versioning (here changing one character will create a new version of the artifact). With VCS you can handle local/internal evolution of an archetype in development, but for a global/public archetype versioning system, IMO this is not the right tool to handle archetype versions (and other artifact versions). I think we need to define the versioning system/semantics/context of an artifact, and then implement this spec on design tools or in each artifact repository. If I'm not mistaken, a discusion about this topic took place a while ago and I don't know if there was consensus on the proposals. Kind regards, Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120208/ae2c06be/attachment.html
Python / Django experience??
Hi Sam, Pablo and everybody else! On Tue, Feb 7, 2012 at 21:59, Sam Heard sam.heard at oceaninformatics.comwrote: We started archetype development in the NHS using Subversion and it got in a real mess very quickly. It would be interesting to know _why_ it got into a mess and what the alternatives were at the time. Was subversion the problem or was it the development process and lack of tooling? If you put raw subversion or software-developer-targeted tools in the hands of clinicians I find it very likely to get messy... What I was proposing included... 4. Clinician-friendly GUIs with CKM-like functions that hides/incorporates layers 1,2, and 3 to end users that want CKM. I do not suggest quitting the use of the current CKM until an equal or better alternative is available (including functions corresponding to the CKM today). So if the CKM works today I do not see why changing storage backend from the current (commercial) asset management system to a DVCS based system would create any more mess. Sticking with several instances of uncoordinated CKMs (running at Netha, openEHR, SKL etc) will probably slowly get us into a real merging mess, but perhaps not recognized at first. For EHR data the current openEHR RM versioning system described in the specifications is based on DVCS principles instead of logically disconnected EHRs that just exchange extracts, messages or distributed searches from time to time. That makes initial design more complicated than for traditional monolithic EHRs, but it makes later connection and cooperation a lot easier. I don't see why archetyping would be so very different in this sense. As Pablo says the version and dependencies are not the same as in code. EHR content is not code either, but in openEHR we use DVCS principles for handling it anyway. I'd guess the long-time requirements for trying to merge and cross-pollinate global archetyping assets to achieve real semantic interoperability is a complex problem that is closer to the global Linux development and merging efforts than to an asset management system designed for a single organisation. Archetypes and sets of archetypes/templates are supposed to be coherent and computable and might from a management point of view be closer to code than you think. Everyone is of course allowed to have their own beliefs, now I have stated mine. :-) I think we need to consider what are the tools that are needed now to make openEHR more attractive to clinical application developers, and what are the functions of those tools. Agree. Now we have the CKM let's use that. Once you have done a couple of big merge effort of archetypes from different CKMs then a need for more coherent backend versioning semantics and merging/synchronization system might become more obvious, but I might be wrong of course. Let?s ensure that businesses can thrive working in the openEHR environment and make sure we try and fill the gaps as the first priority. Sure. Use the CKM now, but don't discourage discussions of future backend enhancements just because that is not the priority of a certain business or company right now. On Thu, Feb 2, 2012 at 18:19, pablo pazos pazospablo at hotmail.com wrote:About using some version control system (VCS), I don't think this is a good solution because the semantics of archetype version are not the same semantics as in plain text versioning (here changing one character will create a new version of the artifact). Since archetypes can be digitally signed, changing a single character may actually create the need for a new version technically. That does not mean that every little change will need to change the version number field inside the archetype file if the DVCS system can be used for such between-internal-version-number-tracking instead (for those that use bleeding edge archetypes that are not formally released). Manual version numbering (that we discussed in an earlier thread) is a separate issue having more to do with official releases or merging into some official release branches. With VCS you can handle local/internal evolution of an archetype in development, but for a global/public archetype versioning system, IMO this is not the right tool to handle archetype versions (and other artifact versions). If you keep the issues of manually assigned version numbers (inside files) and technical versions (labelled by checksums in GIT) separate, would that make the solution more attractive? A DVCS is great for distributed (and temporarily disconnected) cooperation and distribution of artifacts (including complete version history available at all places that may want it). On Wed, Feb 8, 2012 at 01:32, pablo pazos pazospablo at hotmail.com wrote: Now I don't see that these problems could be solved by combining some available tools, Not all problems. A CKM-like GUI is one of the things that needs to be added. I think we need to define something new. For some parts probably
Python / Django experience??
So this sounds like a knowledge index service rather than a repository. Is this where you get the correlation with RLUS? Heath On 01/02/2012 7:51 PM, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: Hi Heath, RLUS, as I understand it is designed to operate with EHR instance data, rather than knowledge artefacts, so is not suitable per-se, but there is a fair degree of cross-over in some of the querying and location requirements and it might serve as a decent start point for discussion. but are there other 'standards' that are more applicable to distributed knowledge repositories. Basic requirements 1. Query across multiple repositories using multiple criteria, based on something similar to the CKM ontology. 2. Establish references to remote assets, almost certainly caching the referenced asset locally 3. Establish subscriptions to remote assets, to enable change notification etc 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 Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org On 31 January 2012 23:00, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Ian, Interested in how you think RLUS can support a Knowledge service? Heath On 01/02/2012 2:21 AM, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: Hi Pablo, Your initial ideas on a possible service layer would be very interesting. I think we are starting to see a need to support cross repository service layer but possibly split between formally governed assets and those that are in early or experimental stages of development (as we envisage with CKI). The requirements for governed cross-repository assets will be rather more demanding. Have you seen this HL7/OMG proposal? http://hssp-rlus-normative.wikispaces.com/home Might be a useful start point. 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 Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org On 31 January 2012 15:27, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, it would be nice to share a common API or service layer that both groups can rely on, so we can make our tools compatible in some way. I have an informal list of requirements that this tool should support, maybe we can start sharing our requirements and see if we can agree on a common interface (API/services). -- 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: Tue, 31 Jan 2012 14:57:20 + Subject: Re: Python / Django experience?? To: openehr-technical at openehr.org Thanks Pablo, I will be interested to see how your app develops. We have a few Python volunteers so hope to have something visibly quite soon. 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 Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org On 31 January 2012 14:45, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, we are planning to work in this area but not with those technologies, I think it will be PHP or Java/Groovy. What we want is just that: a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. Firstly for the openEHR-ES community, to engage doctors and nurses in archetype development, and later to show how to use that knowledge in an EHR tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/ ). Later it could be a general use tool. This will be part of our tool chain: http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png And it'll serve as a continuation for the students of our openEHR course, to embrace and don't lose the momentum
Python / Django experience??
Hi! On Thu, Feb 2, 2012 at 18:19, pablo pazos pazospablo at hotmail.com wrote: I don't know if this is crazy talk or if it's seems reasonable to you. Please let me know :D Not crazy, but maybe overly complicated. Perhaps it would be a good idea to use a layered approach? 1. An existing distributed version control system (DVCS) like GIT (and an agreed directory structure and naming conventions within it) for storing versioning and distributing archetype source files etc. 2. A set of tools (that can also be run in batch mode or by commit hooks in the DVCS) that can validate and convert sources to alternative formats and create html pages (and other formats) for listing and browsing the resulting assets 3. A search function (maybe also using existing online search services) that can be used by both humans and machines (via an API) 4. Clinician-friendly GUIs with CKM-like functions that hides/incorporates layers 1,2, and 3 to end users that want CKM. #1 is available already including free hosting possibilities (but without provider-lock in since the whole version history is replicated) #2 I think e.g. Seref, Tom and others have come very far with already The output from #1 #2 could be served as static files on any webserver and thus make it easy for any organization to set up. No API more than normal HTTP will be needed for read operations, for write operations the API of the DVCS will likely be enough. #3 should be considered carefully before putting too much resources into new development. If processes in step #2 can create good enough labeling/tagging/ontology-linking to resources or meta-resources (like auto-generated descriptive web pages) then both existing online search engines and locally run ones could just pick that up using standard mechanisms #4 will need more work, I don't know if any parts of the CKM can be useful and open sourced to help such an effort. It would be nice if the discussions relating to an artifact (e.g. an archetype) could be stored and versioned in the same backend system as the artifact itself, there are GIT/DVCS-based wikis that might do part of the job. The key benefit of a DVCS based approach is the distributed nature that allows creative initiatives without asking for centralized permission. It allows easy (auditable) cross-pollination of ideas and code/archetypes between developers or regional developer organisations in a way that is a lot harder with centralized approaches like Subversion, the current CKM etc. It's hard to describe, but techies can have a look at some active projects at Github to get a feel for it. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 On Thu, Feb 2, 2012 at 18:19, pablo pazos pazospablo at hotmail.com wrote: Hi all, What I've been thinking is to share the same interface/protocol to do simple tasks on distributed CKMs like: Adding an artifact (archetype, template, termset, terminology service, process definition, gui template, etc.), lets think only about archetypes for now. Updating an archetype (with version management) Listing all the archetypes Listing all the archetypes for one RM type (i.e. composition, entry, action, etc.) Listing all the archetypes that archetype_id match a regexp Listing all the archetypes that match some text (free text search) Retrieve archetype in ADL/XML/JSON/YAML by archetype_id Ian, about the requirements you mention: Basic requirements 1. Query across multiple repositories using multiple criteria, based on something similar to the CKM ontology. For this I think something like DNS protocol will do the job (http://en.wikipedia.org/wiki/Domain_Name_System). DNS could do a distributed search by redirecting the query if some server doesn't have the answer. So, if we have a service to register artifacts on CKM servers (service 1. on the list above), with an artifact registered notification protocol, and another protocol for CKM server discovery, we could implement the distributed search. 2. Establish references to remote assets, almost certainly caching the referenced asset locally This would be the a mix of adding and artifact and artifact registered notification protocol. 3. Establish subscriptions to remote assets, to enable change notification etc And this would be included in the CKM server discovery protocol, that could defined like some services provided by the NDP protocol, using messages like RA, NS, NA, ... to discover CKM servers to create a CKM network over Internet: http://fengnet.com/book/CCIE%20Professional%20Development%20Routing%20TCPIP%20Volume%20I/ch02lev1sec5.html I think some of these services could be found also in the ICMP protocol:?http://www.networksorcery.com/enp/protocol/icmp.htm Just to clarify my thoughts, I don't think we need a network protocol!!! I think we could create our protocols to handle artifacts in a distributed way reusing some ideas from those proven
Python / Django experience??
Hi Erik and all, On Thu, Feb 2, 2012 at 18:19, pablo pazos pazospablo at hotmail.com wrote: I don't know if this is crazy talk or if it's seems reasonable to you. Please let me know :D Not crazy, but maybe overly complicated. Maybe I don't present the idea in the best way, but in the end is just some services to advertise/discover artifact repositories/servers, services to do distributed queries, and services for notifications (subscribe/notify). Some of this ideas are in use out there for zillions since Internet born and evoluted. Perhaps it would be a good idea to use a layered approach? 1. An existing distributed version control system (DVCS) like GIT (and an agreed directory structure and naming conventions within it) for storing versioning and distributing archetype source files etc. About using some version control system (VCS), I don't think this is a good solution because the semantics of archetype version are not the same semantics as in plain text versioning (here changing one character will create a new version of the artifact). With VCS you can handle local/internal evolution of an archetype in development, but for a global/public archetype versioning system, IMO this is not the right tool to handle archetype versions (and other artifact versions). I think we need to define the versioning system/semantics/context of an artifact, and then implement this spec on design tools or in each artifact repository. If I'm not mistaken, a discusion about this topic took place a while ago and I don't know if there was consensus on the proposals. Kind regards,Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120207/e819e19b/attachment.html
Python / Django experience??
Hi Sam, I agree: we need to consider what are the tools that are needed now to make openEHR more attractive to clinical application developers, and what are the functions of those tools. Here we agreed on the tool chain we need to start openEHR development and promotion. We need a CKM with some special characteristics. The current CKM is great, but we need a completly open source solution to generate confidence from the goverment and institutions. In order to create a good and open CKM, I thought about the minimum functionalities needed (see my email from 2/2/2012), and IMO is better if we could define a common service layer in order to provide this functionality and create a CKM that is capable of interconnecting with other CKMs around the world. The idea of having several CKM instances is to maintain independency, so we don't incur in political issues (having one centralized CKM generates political problems and we end up unable to use available tools). And, if we have several CKM instances (maybe different implementations of the same interfaces and funcionalities) and we want to interconnect them, we need to define some kind of protocol (I don't see another solution). And yes, protocols are tough but we need them. Now I don't see that these problems could be solved by combining some available tools, I think we need to define something new. I hope others can convince otherwise, but this is how I feel right now. -- 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: Python / Django experience?? Date: Wed, 8 Feb 2012 06:29:26 +0930 Hi, We started archetype development in the NHS using Subversion and it got in a real mess very quickly. As Pablo says the version and dependencies are not the same as in code. I think we need to consider what are the tools that are needed now to make openEHR more attractive to clinical application developers, and what are the functions of those tools. Let?s ensure that businesses can thrive working in the openEHR environment and make sure we try and fill the gaps as the first priority. Cheers, Sam -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120207/554bcea7/attachment.html
Python / Django experience??
Hi All I want to ensure that the technical possibilities do not overwhelm the clinical reality in this space. It is a very new space and, for interoperability and sharing of applications, we need to align ideas for shared data specifications as part of the process. It has been and remains attractive to consider code repository support for this activity, but I think a much less sophisticated approach that engages leaders in an alignment process is most important. The key decision in these early days is what to put in the parent archetype and what to keep for localisation through specialisation or templates. Cheers, Sam From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Friday, 3 February 2012 2:50 AM To: openehr technical Subject: RE: Python / Django experience?? Hi all, What I've been thinking is to share the same interface/protocol to do simple tasks on distributed CKMs like: 1. Adding an artifact (archetype, template, termset, terminology service, process definition, gui template, etc.), lets think only about archetypes for now. 2. Updating an archetype (with version management) 3. Listing all the archetypes 4. Listing all the archetypes for one RM type (i.e. composition, entry, action, etc.) 5. Listing all the archetypes that archetype_id match a regexp 6. Listing all the archetypes that match some text (free text search) 7. Retrieve archetype in ADL/XML/JSON/YAML by archetype_id Ian, about the requirements you mention: Basic requirements 1. Query across multiple repositories using multiple criteria, based on something similar to the CKM ontology. For this I think something like DNS protocol will do the job (http://en.wikipedia.org/wiki/Domain_Name_System). DNS could do a distributed search by redirecting the query if some server doesn't have the answer. So, if we have a service to register artifacts on CKM servers (service 1. on the list above), with an artifact registered notification protocol, and another protocol for CKM server discovery, we could implement the distributed search. 2. Establish references to remote assets, almost certainly caching the referenced asset locally This would be the a mix of adding and artifact and artifact registered notification protocol. 3. Establish subscriptions to remote assets, to enable change notification etc And this would be included in the CKM server discovery protocol, that could defined like some services provided by the NDP protocol, using messages like RA, NS, NA, ... to discover CKM servers to create a CKM network over Internet: http://fengnet.com/book/CCIE%20Professional%20Development%20Routing%20TCPIP% 20Volume%20I/ch02lev1sec5.html I think some of these services could be found also in the ICMP protocol: http://www.networksorcery.com/enp/protocol/icmp.htm Just to clarify my thoughts, I don't think we need a network protocol!!! I think we could create our protocols to handle artifacts in a distributed way reusing some ideas from those proven protocols that our machines run everyday to connect to the Internet and access distributed resourses. How this stuff could work in reality? 1. We need a set of root CKM servers, always online, that could answer our queries or redirect to some another server that could answer (like DNS). 2. In those servers (could be only one, like openEHR.org CKM), other servers could advertise themselves to form part of the CKM network, this could be done like an ICMP or NDP router advertisement. Those servers could download also a list of servers currently connected to the network, and update the list anytime. 3. The children servers could be not always online, so each entry on the root server registry should have a lifetime, that when reached, the entry is eliminated from the list (like in ICMP http://www.networksorcery.com/enp/protocol/icmp/msg9.htm ). This could trigger a notification to the other members of the network, to update their server list. 4. When an artifact is added to a server, it should notify other servers in the network, so they could know what server has the original copy of the artifact, and maybe they can make a copy of the artifact that sould be read-only on those servers that cache a copy. The cached archetype could have a lifetime, that when reached, a new copy of that archetype should be downloaded from the original server, if the server is still online, or renew the lifetime if the original server is offline. 5. Then a query received by any CKM could be responded or redirected to other server, and all servers in the network could keep up with all the archetypes created worldwide. I don't know if this is crazy talk or if it's seems reasonable to you. Please let me know :D Kind regards, Pablo. -- next part -- An HTML attachment was scrubbed... URL
Python / Django experience??
Hi All, Over the past week I managed to install a test server for myself using the instructions provided by Athanasios, Drek and Ian (thank you guys very much). I have explored a bit and was wondering that aside from the threads of email, is there a wiki page or something similar somewhere that can be used to keep track of the features requested and their priorities, and perhaps can act as a journal of what we came upon and how we decided to approach problems? Surely emails can be searched, and Ian and Athanasios have already explained the main stories, but I just thought to ask before going to the list archives. This will also be very helpful in keeping momentum as we are interrupted with our daily responsibilities. Cheers, Reza On Sat, Feb 4, 2012 at 11:17 PM, Sam Heard sam.heard at oceaninformatics.comwrote: Hi All ** ** I want to ensure that the technical possibilities do not overwhelm the clinical reality in this space. It is a very new space and, for interoperability and sharing of applications, we need to align ideas for shared data specifications as part of the process. It has been and remains attractive to consider code repository support for this activity, but I think a much less sophisticated approach that engages leaders in an alignment process is most important. ** ** The key decision in these early days is what to put in the parent archetype and what to keep for localisation through specialisation or templates. ** ** Cheers, Sam ** ** *From:* openehr-technical-bounces at openehr.org [mailto: openehr-technical-bounces at openehr.org] *On Behalf Of *pablo pazos *Sent:* Friday, 3 February 2012 2:50 AM *To:* openehr technical *Subject:* RE: Python / Django experience?? ** ** Hi all, ** ** What I've been thinking is to share the same interface/protocol to do simple tasks on distributed CKMs like: ** ** 1. Adding an artifact (archetype, template, termset, terminology service, process definition, gui template, etc.), lets think only about archetypes for now. 2. Updating an archetype (with version management) 3. Listing all the archetypes 4. Listing all the archetypes for one RM type (i.e. composition, entry, action, etc.) 5. Listing all the archetypes that archetype_id match a regexp 6. Listing all the archetypes that match some text (free text search)** ** 7. Retrieve archetype in ADL/XML/JSON/YAML by archetype_id ** ** ** ** Ian, about the requirements you mention: Basic requirements 1. Query across multiple repositories using multiple criteria, based on something similar to the CKM ontology. ** ** For this I think something like DNS protocol will do the job ( http://en.wikipedia.org/wiki/Domain_Name_System). DNS could do a distributed search by redirecting the query if some server doesn't have the answer. So, if we have a service to register artifacts on CKM servers (service 1. on the list above), with an artifact registered notification protocol, and another protocol for CKM server discovery, we could implement the distributed search. 2. Establish references to remote assets, almost certainly caching the referenced asset locally ** ** This would be the a mix of adding and artifact and artifact registered notification protocol. 3. Establish subscriptions to remote assets, to enable change notification etc And this would be included in the CKM server discovery protocol, that could defined like some services provided by the NDP protocol, using messages like RA, NS, NA, ... to discover CKM servers to create a CKM network over Internet: http://fengnet.com/book/CCIE%20Professional%20Development%20Routing%20TCPIP%20Volume%20I/ch02lev1sec5.html I think some of these services could be found also in the ICMP protocol: http://www.networksorcery.com/enp/protocol/icmp.htm ** ** ** ** Just to clarify my thoughts, I don't think we need a network protocol!!! I think we could create our protocols to handle artifacts in a distributed way reusing some ideas from those proven protocols that our machines run everyday to connect to the Internet and access distributed resourses. ** ** ** ** *How this stuff could work in reality?* ** ** 1. We need a set of root CKM servers, always online, that could answer our queries or redirect to some another server that could answer (like DNS). 2. In those servers (could be only one, like openEHR.org CKM), other servers could advertise themselves to form part of the CKM network, this could be done like an ICMP or NDP router advertisement. Those servers could download also a list of servers currently connected to the network, and update the list anytime. 3. The children servers could be not always online, so each entry on the root server registry should have a lifetime, that when reached
Python / Django experience??
Hi all, What I've been thinking is to share the same interface/protocol to do simple tasks on distributed CKMs like: Adding an artifact (archetype, template, termset, terminology service, process definition, gui template, etc.), lets think only about archetypes for now.Updating an archetype (with version management)Listing all the archetypesListing all the archetypes for one RM type (i.e. composition, entry, action, etc.)Listing all the archetypes that archetype_id match a regexpListing all the archetypes that match some text (free text search)Retrieve archetype in ADL/XML/JSON/YAML by archetype_id Ian, about the requirements you mention: Basic requirements 1. Query across multiple repositories using multiple criteria, based on something similar to the CKM ontology. For this I think something like DNS protocol will do the job (http://en.wikipedia.org/wiki/Domain_Name_System). DNS could do a distributed search by redirecting the query if some server doesn't have the answer. So, if we have a service to register artifacts on CKM servers (service 1. on the list above), with an artifact registered notification protocol, and another protocol for CKM server discovery, we could implement the distributed search. 2. Establish references to remote assets, almost certainly caching the referenced asset locally This would be the a mix of adding and artifact and artifact registered notification protocol. 3. Establish subscriptions to remote assets, to enable change notification etc And this would be included in the CKM server discovery protocol, that could defined like some services provided by the NDP protocol, using messages like RA, NS, NA, ... to discover CKM servers to create a CKM network over Internet: http://fengnet.com/book/CCIE%20Professional%20Development%20Routing%20TCPIP%20Volume%20I/ch02lev1sec5.html I think some of these services could be found also in the ICMP protocol: http://www.networksorcery.com/enp/protocol/icmp.htm Just to clarify my thoughts, I don't think we need a network protocol!!! I think we could create our protocols to handle artifacts in a distributed way reusing some ideas from those proven protocols that our machines run everyday to connect to the Internet and access distributed resourses. How this stuff could work in reality? We need a set of root CKM servers, always online, that could answer our queries or redirect to some another server that could answer (like DNS).In those servers (could be only one, like openEHR.org CKM), other servers could advertise themselves to form part of the CKM network, this could be done like an ICMP or NDP router advertisement. Those servers could download also a list of servers currently connected to the network, and update the list anytime.The children servers could be not always online, so each entry on the root server registry should have a lifetime, that when reached, the entry is eliminated from the list (like in ICMP http://www.networksorcery.com/enp/protocol/icmp/msg9.htm ). This could trigger a notification to the other members of the network, to update their server list.When an artifact is added to a server, it should notify other servers in the network, so they could know what server has the original copy of the artifact, and maybe they can make a copy of the artifact that sould be read-only on those servers that cache a copy. The cached archetype could have a lifetime, that when reached, a new copy of that archetype should be downloaded from the original server, if the server is still online, or renew the lifetime if the original server is offline.Then a query received by any CKM could be responded or redirected to other server, and all servers in the network could keep up with all the archetypes created worldwide. I don't know if this is crazy talk or if it's seems reasonable to you. Please let me know :D Kind regards,Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120202/3d5bc75e/attachment.html
Python / Django experience??
Hi! On Wed, Jan 11, 2012 at 12:10, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. One of the most interesting things about GIT-like systems is their distributed/decentralized nature where there is not necessarily a single main master repository. (This category of versioning systems are often called DVCS, see http://en.wikipedia.org/wiki/Distributed_Version_Control_System, GIT is just an example from that category Mercurialhttp://en.wikipedia.org/wiki/Mercurialis another example.) Instead of centralization there is very good support for merging multiple branches/forks/origins. I think this mode of operation will suit future archetype development where we might expect considerable activity in many regional archetyping centres and then multi-source merges and good multi-branch change tracking will be useful. The git command-line interface itself would be quite a horrible experience to most archetype authors though so the DVCS needs to be wrapped in something better (CKM-like) for end users. Something like GIT (or Mercurial) itself might work well as a service layer for communication between regional archetyping repositories though, we probably won't need to add much there except some sensible rules for directory structures, file naming etc. Communication protocols etc for GIT are already defined - exposing the repository via a regular webserverhttp://book.git-scm.com/4_setting_up_a_public_repository.html directory is one option. Every regional site will via GIT or Mercurial automatically get a complete history of any other repository it wishes to mirror. But don't let this stop Dropbox plans if that works better now, I just wanted the above to be visible on the future-sensing radar for tech-list subscribers. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120201/640d64f4/attachment.html
Python / Django experience??
On 01/02/2012 09:13, Erik Sundvall wrote: Hi! On Wed, Jan 11, 2012 at 12:10, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. One of the most interesting things about GIT-like systems is their distributed/decentralized nature where there is not necessarily a single main master repository. (This category of versioning systems are often called DVCS, see http://en.wikipedia.org/wiki/Distributed_Version_Control_System, GIT is just an example from that category Mercurialhttp://en.wikipedia.org/wiki/Mercurialis another example.) Instead of centralization there is very good support for merging multiple branches/forks/origins. I think this mode of operation will suit future archetype development where we might expect considerable activity in many regional archetyping centres and then multi-source merges and good multi-branch change tracking will be useful. The git command-line interface itself would be quite a horrible experience to most archetype authors though so the DVCS needs to be wrapped in something better (CKM-like) for end users. Something like GIT (or Mercurial) itself might work well as a service layer for communication between regional archetyping repositories though, we probably won't need to add much there except some sensible rules for directory structures, file naming etc. Communication protocols etc for GIT are already defined - exposing the repository via a regular webserverhttp://book.git-scm.com/4_setting_up_a_public_repository.html directory is one option. Every regional site will via GIT or Mercurial automatically get a complete history of any other repository it wishes to mirror. Yes Erik, and GIT does it's best (unlike SVN) to help you merge even after a lot of branching: see: http://progit.org/book/ch3-2.html for a nice explanation
Python / Django experience??
Hi Heath, RLUS, as I understand it is designed to operate with EHR instance data, rather than knowledge artefacts, so is not suitable per-se, but there is a fair degree of cross-over in some of the querying and location requirements and it might serve as a decent start point for discussion. but are there other 'standards' that are more applicable to distributed knowledge repositories. Basic requirements 1. Query across multiple repositories using multiple criteria, based on something similar to the CKM ontology. 2. Establish references to remote assets, almost certainly caching the referenced asset locally 3. Establish subscriptions to remote assets, to enable change notification etc 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 Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org On 31 January 2012 23:00, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Ian, Interested in how you think RLUS can support a Knowledge service? Heath On 01/02/2012 2:21 AM, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: Hi Pablo, Your initial ideas on a possible service layer would be very interesting. I think we are starting to see a need to support cross repository service layer but possibly split between formally governed assets and those that are in early or experimental stages of development (as we envisage with CKI). The requirements for governed cross-repository assets will be rather more demanding. Have you seen this HL7/OMG proposal? http://hssp-rlus-normative.wikispaces.com/home Might be a useful start point. 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 Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org On 31 January 2012 15:27, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, it would be nice to share a common API or service layer that both groups can rely on, so we can make our tools compatible in some way. I have an informal list of requirements that this tool should support, maybe we can start sharing our requirements and see if we can agree on a common interface (API/services). -- 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: Tue, 31 Jan 2012 14:57:20 + Subject: Re: Python / Django experience?? To: openehr-technical at openehr.org Thanks Pablo, I will be interested to see how your app develops. We have a few Python volunteers so hope to have something visibly quite soon. 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 Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org On 31 January 2012 14:45, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, we are planning to work in this area but not with those technologies, I think it will be PHP or Java/Groovy. What we want is just that:?a very lightly-governed archetype?collaboration, simple review and discussion space to enable early?communication between possible archetype developers. Firstly for the openEHR-ES community, to engage doctors and nurses in archetype development, and later to show how to use that knowledge in an EHR tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/). Later it could be a general use tool. This will be part of our tool chain:?http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png And it'll serve as a continuation for the students of our openEHR course, to embrace and don't lose the momentum after the course. -- 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, 11 Jan 2012 11:10:57 + Subject: Python / Django experience
Python / Django experience??
Hi Ian, Interested in how you think RLUS can support a Knowledge service? Heath On 01/02/2012 2:21 AM, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: Hi Pablo, Your initial ideas on a possible service layer would be very interesting. I think we are starting to see a need to support cross repository service layer but possibly split between formally governed assets and those that are in early or experimental stages of development (as we envisage with CKI). The requirements for governed cross-repository assets will be rather more demanding. Have you seen this HL7/OMG proposal? http://hssp-rlus-normative.wikispaces.com/home Might be a useful start point. 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 Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org On 31 January 2012 15:27, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, it would be nice to share a common API or service layer that both groups can rely on, so we can make our tools compatible in some way. I have an informal list of requirements that this tool should support, maybe we can start sharing our requirements and see if we can agree on a common interface (API/services). -- 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: Tue, 31 Jan 2012 14:57:20 + Subject: Re: Python / Django experience?? To: openehr-technical at openehr.org Thanks Pablo, I will be interested to see how your app develops. We have a few Python volunteers so hope to have something visibly quite soon. 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 Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org On 31 January 2012 14:45, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, we are planning to work in this area but not with those technologies, I think it will be PHP or Java/Groovy. What we want is just that: a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. Firstly for the openEHR-ES community, to engage doctors and nurses in archetype development, and later to show how to use that knowledge in an EHR tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/). Later it could be a general use tool. This will be part of our tool chain: http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png And it'll serve as a continuation for the students of our openEHR course, to embrace and don't lose the momentum after the course. -- 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, 11 Jan 2012 11:10:57 + Subject: Python / Django experience?? To: openehr-technical at openehr.org Hi all, Would any of you with Python / Django experience be interested in helping with a small open-source project to establish a 'Clinical Knowledge Incubator' website under the auspices of the Foundation? The intention is to establish a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. This is not intended to compete with a more formally-governed repository such as CKM but to allow archetypes, requirements and specification documents to be shared and discussed prior to more formal governance and development processes kicking in. The site will be based on the open source Snowcloud Clinical Templates framework see clinicaltemplates.org. The work needing done to adapt this for openEHR is broadly .. 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution
Python / Django experience??
Hi Ian, we are planning to work in this area but not with those technologies, I think it will be PHP or Java/Groovy. What we want is just that: a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. Firstly for the openEHR-ES community, to engage doctors and nurses in archetype development, and later to show how to use that knowledge in an EHR tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/). Later it could be a general use tool. This will be part of our tool chain: http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png And it'll serve as a continuation for the students of our openEHR course, to embrace and don't lose the momentum after the course. -- 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, 11 Jan 2012 11:10:57 + Subject: Python / Django experience?? To: openehr-technical at openehr.org Hi all, Would any of you with Python / Django experience be interested in helping with a small open-source project to establish a 'Clinical Knowledge Incubator' website under the auspices of the Foundation? The intention is to establish a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. This is not intended to compete with a more formally-governed repository such as CKM but to allow archetypes, requirements and specification documents to be shared and discussed prior to more formal governance and development processes kicking in. The site will be based on the open source Snowcloud Clinical Templates framework see clinicaltemplates.org. The work needing done to adapt this for openEHR is broadly .. 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. 2. Add the ability to import from openEHR ADL/XML and .opt XML ) into the native XML format. Derek Hoy, the Snowcloud developer, has already partially implemented this but it does need further work. Derek has been good enough to offer further support and guidance. 3. At some point some sort of integration with CKM would be interesting. I will be taking an interest in the developments but have very limited Python skills. Anyone interested? 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 Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland 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/20120131/e4138f6c/attachment.html
Python / Django experience??
Thanks Pablo, I will be interested to see how your app develops. We have a few Python volunteers so hope to have something visibly quite soon. 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 Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org On 31 January 2012 14:45, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, we are planning to work in this area but not with those technologies, I think it will be PHP or Java/Groovy. What we want is just that:?a very lightly-governed archetype?collaboration, simple review and discussion space to enable early?communication between possible archetype developers. Firstly for the openEHR-ES community, to engage doctors and nurses in archetype development, and later to show how to use that knowledge in an EHR tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/). Later it could be a general use tool. This will be part of our tool chain:?http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png And it'll serve as a continuation for the students of our openEHR course, to embrace and don't lose the momentum after the course. -- 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, 11 Jan 2012 11:10:57 + Subject: Python / Django experience?? To: openehr-technical at openehr.org Hi all, Would any of you with Python / Django experience be interested in helping with a small open-source project to establish a 'Clinical Knowledge Incubator' website under the auspices of the Foundation? The intention is to establish a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. This is not intended to compete with a more formally-governed repository such as CKM but to allow archetypes, requirements and specification documents to be shared and discussed prior to more formal governance and development processes kicking in. The site will be based on the open source Snowcloud Clinical Templates framework see clinicaltemplates.org. The work needing done to adapt this for openEHR is broadly .. 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. 2. Add the ability to import from openEHR ADL/XML and .opt XML ) into the native XML format. Derek Hoy, the Snowcloud developer, has already partially implemented this but it does need further work. Derek has been good enough to offer further support and guidance. 3. At some point some sort of integration with CKM would be interesting. I will be taking an interest in the developments but have very limited Python skills. Anyone interested? 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 Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland 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
Python / Django experience??
This will be part of our tool chain:?http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png Hi Pablo, there's a minor typo in your otherwise great diagram: decision in stead of decition. Cheers, Roger
Python / Django experience??
Hi Ian, it would be nice to share a common API or service layer that both groups can rely on, so we can make our tools compatible in some way.I have an informal list of requirements that this tool should support, maybe we can start sharing our requirements and see if we can agree on a common interface (API/services). -- 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: Tue, 31 Jan 2012 14:57:20 + Subject: Re: Python / Django experience?? To: openehr-technical at openehr.org Thanks Pablo, I will be interested to see how your app develops. We have a few Python volunteers so hope to have something visibly quite soon. 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 Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org On 31 January 2012 14:45, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, we are planning to work in this area but not with those technologies, I think it will be PHP or Java/Groovy. What we want is just that: a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. Firstly for the openEHR-ES community, to engage doctors and nurses in archetype development, and later to show how to use that knowledge in an EHR tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/). Later it could be a general use tool. This will be part of our tool chain: http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png And it'll serve as a continuation for the students of our openEHR course, to embrace and don't lose the momentum after the course. -- 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, 11 Jan 2012 11:10:57 + Subject: Python / Django experience?? To: openehr-technical at openehr.org Hi all, Would any of you with Python / Django experience be interested in helping with a small open-source project to establish a 'Clinical Knowledge Incubator' website under the auspices of the Foundation? The intention is to establish a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. This is not intended to compete with a more formally-governed repository such as CKM but to allow archetypes, requirements and specification documents to be shared and discussed prior to more formal governance and development processes kicking in. The site will be based on the open source Snowcloud Clinical Templates framework see clinicaltemplates.org. The work needing done to adapt this for openEHR is broadly .. 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. 2. Add the ability to import from openEHR ADL/XML and .opt XML ) into the native XML format. Derek Hoy, the Snowcloud developer, has already partially implemented this but it does need further work. Derek has been good enough to offer further support and guidance. 3. At some point some sort of integration with CKM would be interesting. I will be taking an interest in the developments but have very limited Python skills. Anyone interested? 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 Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http
Python / Django experience??
Thanks a lot Roger, it has been corrected, now the working link is: http://4.bp.blogspot.com/-9_P5lrqSaH4/TygHTXUDOnI/E_c/ebyHliBiuaA/s1600/openEHR+Toolchain+ppazos+sm.png The diagram is part of this entry on the outcomes of our first openEHR course in spanish: http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.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 Date: Tue, 31 Jan 2012 16:05:39 +0100 Subject: Re: Python / Django experience?? From: roger.erens at e-s-c.biz To: openehr-technical at openehr.org This will be part of our tool chain: http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png Hi Pablo, there's a minor typo in your otherwise great diagram: decision in stead of decition. Cheers, Roger ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/53f657e8/attachment.html
Python / Django experience??
Hi Pablo, Your initial ideas on a possible service layer would be very interesting. I think we are starting to see a need to support cross repository service layer but possibly split between formally governed assets and those that are in early or experimental stages of development (as we envisage with CKI). The requirements for governed cross-repository assets will be rather more demanding. Have you seen this HL7/OMG proposal? http://hssp-rlus-normative.wikispaces.com/home Might be a useful start point. 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 Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org On 31 January 2012 15:27, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, it would be nice to share a common API or service layer that both groups can rely on, so we can make our tools compatible in some way. I have an informal list of requirements that this tool should support, maybe we can start sharing our requirements and see if we can agree on a common interface (API/services). -- 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: Tue, 31 Jan 2012 14:57:20 + Subject: Re: Python / Django experience?? To: openehr-technical at openehr.org Thanks Pablo, I will be interested to see how your app develops. We have a few Python volunteers so hope to have something visibly quite soon. 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 Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org On 31 January 2012 14:45, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, we are planning to work in this area but not with those technologies, I think it will be PHP or Java/Groovy. What we want is just that:?a very lightly-governed archetype?collaboration, simple review and discussion space to enable early?communication between possible archetype developers. Firstly for the openEHR-ES community, to engage doctors and nurses in archetype development, and later to show how to use that knowledge in an EHR tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/). Later it could be a general use tool. This will be part of our tool chain:?http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png And it'll serve as a continuation for the students of our openEHR course, to embrace and don't lose the momentum after the course. -- 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, 11 Jan 2012 11:10:57 + Subject: Python / Django experience?? To: openehr-technical at openehr.org Hi all, Would any of you with Python / Django experience be interested in helping with a small open-source project to establish a 'Clinical Knowledge Incubator' website under the auspices of the Foundation? The intention is to establish a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. This is not intended to compete with a more formally-governed repository such as CKM but to allow archetypes, requirements and specification documents to be shared and discussed prior to more formal governance and development processes kicking in. The site will be based on the open source Snowcloud Clinical Templates framework see clinicaltemplates.org. The work needing done to adapt this for openEHR is broadly .. 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. 2. Add the ability to import from openEHR ADL/XML and .opt XML ) into the native XML format. Derek Hoy, the Snowcloud developer, has already partially implemented this but it does need further work. Derek has been
Python / Django experience??
Hi all, Would any of you with Python / Django experience be interested in helping with a small open-source project to establish a 'Clinical Knowledge Incubator' website under the auspices of the Foundation? The intention is to establish a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. This is not intended to compete with a more formally-governed repository such as CKM but to allow archetypes, requirements and specification documents to be shared and discussed prior to more formal governance and development processes kicking in. The site will be based on the open source Snowcloud Clinical Templates framework see clinicaltemplates.org. The work needing done to adapt this for openEHR is broadly .. 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. 2. Add the ability to import from openEHR ADL/XML and .opt XML ) into the native XML format. Derek Hoy, the Snowcloud developer, has already partially implemented this but it does need further work. Derek has been good enough to offer further support and guidance. 3. At some point some sort of integration with CKM would be interesting. I will be taking an interest in the developments but have very limited Python skills. Anyone interested? 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 Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org
