Python / Django experience??
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://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ 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/20120207/17d8c078/attachment.html
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
openEHR service specifications - EHR service
Over the last few years the number of openEHR implementations, both commercial and research, has grown. There should now be a significant amount of experience with service interfaces, and it seems time to get moving on defining some openEHR standards for them. In the interests of 'starting small', I would suggest that the EHR service is the best starting point. See here http://www.openehr.org/wiki/display/spec/openEHR+Service+Model#openEHRServiceModel-EHRandRelatedServices for one view of what this is, but even this description may change, as the world apparently progresses toward a more RESTful stateless architecture style. In summary, one view of an 'EHR service' is the interface to the EHR data store: a place to put and retrieve EHRs. Obviously lots of other services are needed to build a whole solution (as described in the page above), but this one has a small interface and is not complicated to understand. It seems reasonable to work towards a standard version by posting service definitions from existing systems / products, and following some discussion, to attempt to create a merged consensus version. Note: more than one service interface is ok! For example, a stateless REST style interface is just one approach; a stateful interface is just as valid for some purposes. Other flavours may also make sense. As an example of an EHR service interface, the Ocean Informatics one is posted here http://www.openehr.org/wiki/display/spec/Ocean+Informatics+EHR+Service+Interface, and is only about a dozen functions long. It would be great to see some other service interfaces posted - please do that here http://www.openehr.org/wiki/display/spec/EHR+Service+Specification - i.e. add an entry like the Ocean one, and then add a child page. Once we get a feel for the diversity (or unanimity), we might be able to make some quick progress toward a proper openEHR EHR service. - thomas beale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120207/2016c981/attachment.html
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
