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??
pass_through and implementation directives in general
On 01/02/2012 07:25, Erik Sundvall wrote: On Tue, Jan 31, 2012 at 14:42, Thomas Beale thomas.beale at oceaninformatics.com mailto:thomas.beale at oceaninformatics.com wrote: Erik, which file do you mean here? Where is this alias? Oh, never mind, it was just a sidetrack, focus on other things if you don't get it. Let's not spend more email electrons, CPU cycles and brainpower on this part of the thread. What I meant was that a serialized archetype- or template-file that uses a lot of similarly prefixed URIs could use internal aliases (defined in that specific archetype- or template-file) for long URI prefixes. This is done by many other RDF and XML serialization approaches to increase readability. But let's not do anything like that for ADL now. Maybe those of us that are interested in e.g. XML and YAML (that already have built-in prefix/namespace mechanisms) could look at this later. that's what I wanted to check. I expect it would be useful in ADL archetypes - essential, if we are going to connect semantic net to archetypes - we just need a bit more solid theory on some of this stuff, to see how it should be done. I would guess at least that the AUTHORED_RESOURCE class should have some generic schema namespacing / alias capability, which is easy enough to do. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120201/e18b48b9/attachment.html
pass_through and implementation directives in general
names come from a) a central controlled vocabulary and additionally b) local values being allowed - this could be done by registering the vocabularies at different jurisdictional levels. Initially, I think we could just work off a central wiki page, with perhaps a few key tags defined in the AOM spec itself (if we can figure them out in time) - values could also potentially be defined in this controlled vocabulary, i.e. in the form - tag1 = value1 | value2 | value3 etc - or in other ways, e.g. tag1 = string; javascript syntax - specialised archetypes and templates could override the value of an existing tag with another legal value for that tag - but we probably need to allow locally defined values as well for tags with a fixed value set - specialised archetypes and templates can add directives containing new (locally-defined) tags and values - there may need to be a way to 'remove' a tag setting from an archetype This is obviously pretty 'soft' computing, and therefore open to some dangers, but if we manage it as a community in a sensible way, it could bring a lot of value. The use of specialisation to add new directives I think is the key to making it work properly with respect to localisation. thoughts? - thomas beale ___ 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/20120201/931710f8/attachment.html
Python / Django experience??
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120201/04f1a9e3/attachment.html
