|
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@...
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@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
RE: Python / Django experience??
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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/AAAAAAAAE-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/pablopazosgutierrezBlog: http://informatica-medica.blogspot.com/Twitter: http://twitter.com/ppazos> From: Ian.McNicoll@...> Date: Wed, 11 Jan 2012 11:10:57 +0000 > Subject: Python / Django experience?? > To: openehr-technical@...> > 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@...> > 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@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
Re: 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@...
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@...> 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/AAAAAAAAE-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@...
>> Date: Wed, 11 Jan 2012 11:10:57 +0000
>> Subject: Python / Django experience??
>> To: openehr-technical@...
>
>>
>> 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@...
>>
>> 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@...
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
Re: Python / Django experience??
|
|
RE: Python / Django experience??
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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/pablopazosgutierrezBlog: http://informatica-medica.blogspot.com/Twitter: http://twitter.com/ppazos> From: Ian.McNicoll@...> Date: Tue, 31 Jan 2012 14:57:20 +0000 > Subject: Re: Python / Django experience?? > To: openehr-technical@...> > 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@...> > 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@...> 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/AAAAAAAAE-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@...> >> Date: Wed, 11 Jan 2012 11:10:57 +0000 > >> Subject: Python / Django experience?? > >> To: openehr-technical@...> > > >> > >> 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@...> >> > >> 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@...> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@...> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical _______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
RE: Python / Django experience??
|
|
Re: 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/homeMight 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@...
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@...> 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@...
>> Date: Tue, 31 Jan 2012 14:57:20 +0000
>> Subject: Re: Python / Django experience??
>
>> To: openehr-technical@...
>>
>> 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@...
>>
>> 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@...> 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/AAAAAAAAE-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@...
>> >> Date: Wed, 11 Jan 2012 11:10:57 +0000
>> >> Subject: Python / Django experience??
>> >> To: openehr-technical@...
>> >
>> >>
>> >> 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@...
>> >>
>> >> 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@...
>> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical>> >
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical@...
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@...
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
Re: 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@...> 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@...
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@...> 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@...
>> Date: Tue, 31 Jan 2012 14:57:20 +0000
>> Subject: Re: Python / Django experience??
>
>> To: openehr-technical@...
>>
>> 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@...
>>
>> 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@...> 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/AAAAAAAAE-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@...
>> >> Date: Wed, 11 Jan 2012 11:10:57 +0000
>> >> Subject: Python / Django experience??
>> >> To: openehr-technical@...
>> >
>> >>
>> >> 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@...
>> >>
>> >> 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@...
>> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>> >
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical@...
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@...
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
Re: Python / Django experience??
Hi! On Wed, Jan 11, 2012 at 12:10, Ian McNicoll <Ian.McNicoll@...> 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 Mercurial is 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 webserver 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.
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
Re: 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@...> 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
> Mercurial< http://en.wikipedia.org/wiki/Mercurial>is 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
> webserver< http://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
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
Re: 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@...
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@...> 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@...>
> 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@...
>>
>> 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@...> 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@...
>> >> Date: Tue, 31 Jan 2012 14:57:20 +0000
>> >> Subject: Re: Python / Django experience??
>> >
>> >> To: openehr-technical@...
>> >>
>> >> 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@...
>> >>
>> >> 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@...> 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/AAAAAAAAE-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@...
>> >> >> Date: Wed, 11 Jan 2012 11:10:57 +0000
>> >> >> Subject: Python / Django experience??
>> >> >> To: openehr-technical@...
>> >> >
>> >> >>
>> >> >> 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@...
>> >> >>
>> >> >> 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@...
>> >> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical>> >> >
>> >>
>> >> _______________________________________________
>> >> openEHR-technical mailing list
>> >> openEHR-technical@...
>> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical>> >
>> > _______________________________________________
>> > openEHR-technical mailing list
>> > openEHR-technical@...
>> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical>> >
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical@...
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@...
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
RE: Python / Django experience??
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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
>
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.
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
RE: Python / Django experience??
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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 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
>
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 _______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
 Re: 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@...> wrote:
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
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
>
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
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
Re: 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@...> 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@...
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@...> 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@...>
> 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@...
>>
>> 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@...> 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@...
>> >> Date: Tue, 31 Jan 2012 14:57:20 +0000
>> >> Subject: Re: Python / Django experience??
>> >
>> >> To: openehr-technical@...
>> >>
>> >> 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@...
>> >>
>> >> 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@...> 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/AAAAAAAAE-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@...
>> >> >> Date: Wed, 11 Jan 2012 11:10:57 +0000
>> >> >> Subject: Python / Django experience??
>> >> >> To: openehr-technical@...
>> >> >
>> >> >>
>> >> >> 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@...
>> >> >>
>> >> >> 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@...
>> >> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>> >> >
>> >>
>> >> _______________________________________________
>> >> openEHR-technical mailing list
>> >> openEHR-technical@...
>> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>> >
>> > _______________________________________________
>> > openEHR-technical mailing list
>> > openEHR-technical@...
>> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>> >
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical@...
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@...
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
Re: Python / Django experience??
Hi!
On Thu, Feb 2, 2012 at 18:19, pablo pazos < pazospablo@...> 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@... http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
On Thu, Feb 2, 2012 at 18:19, pablo pazos < pazospablo@...> 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 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.
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@...
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
RE: Python / Django experience??
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Erik and all, > On Thu, Feb 2, 2012 at 18:19, pablo pazos < pazospablo@...> 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. _______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
RE: Python / Django experience??
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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 Hi Erik and all,
> On Thu, Feb 2, 2012 at 18:19, pablo pazos <pazospablo@...> 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. _______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
RE: Python / Django experience??
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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/pablopazosgutierrezBlog: http://informatica-medica.blogspot.com/Twitter: http://twitter.com/ppazos
From: sam.heard@...To: openehr-technical@...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 _______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
|
Re: Python / Django experience??
Hi Sam, Pablo and everybody else! On Tue, Feb 7, 2012 at 21:59, Sam Heard <sam.heard@...> wrote:
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@...> 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@...> 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 yes, but using available components is always a help.
I hope others can convince otherwise, but this is how I feel right now.
I am trying. :-)
Lets hope we get more input from many others before rushing into implementation. My belief is that the global future change-tracking and merging problem needs to be considered at an early stage, but I am sure that I don't see the whole picture or all problems myself yet, so let's think together.
_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
|
