openEHR-clinical Digest, Vol 35, Issue 38

Ian McNicoll ian at freshehr.com
Sun Mar 15 18:58:08 EDT 2015


Actually GitHub does not care if you are a not-for-profit or not. It is the
private repos that are paid-for.

I think it might be quite difficult to define not-for-profit fairly in this
environment.

Is Pablo's training need not-for-profit?

As William says, if I am developing archetypes for a commercial
organisation and getting paid for that work but sharing them publicly - is
that not-for-profit?

Ian





Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian at freshehr.com
twitter: @ianmcnicoll

Director, freshEHR Clinical Informatics
Director, openEHR Foundation
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 14 March 2015 at 22:01, Marcus Baw <marcusbaw at gmail.com> wrote:

> Non profits with a free CKM licence would be public not private. This is
> the github model
> On 14 Mar 2015 20:50, "WILLIAM R4C" <wgoossen at results4care.nl> wrote:
>
>> And how would you handle commercial entities willing to share archetypes
>> and not for profit organizations that keep "their" archetypes legacy?
>>
>> Vriendelijke groet,
>>
>> Dr. William Goossen
>>
>> Directeur Results 4 Care BV
>> +31654614458
>>
>> > Op 14 mrt. 2015 om 21:22 heeft
>> openehr-clinical-request at lists.openehr.org het volgende geschreven:
>> >
>> > Send openEHR-clinical mailing list submissions to
>> >    openehr-clinical at lists.openehr.org
>> >
>> > To subscribe or unsubscribe via the World Wide Web, visit
>> >
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>> >
>> > or, via email, send a message with subject or body 'help' to
>> >    openehr-clinical-request at lists.openehr.org
>> >
>> > You can reach the person managing the list at
>> >    openehr-clinical-owner at lists.openehr.org
>> >
>> > When replying, please edit your Subject line so it is more specific
>> > than "Re: Contents of openEHR-clinical digest..."
>> >
>> >
>> > Today's Topics:
>> >
>> >   1. Re: How to fix CKM biggest issue (Marcus Baw)
>> >   2. RE: How to fix CKM biggest issue (pablo pazos)
>> >
>> >
>> > ----------------------------------------------------------------------
>> >
>> > Message: 1
>> > Date: Sat, 14 Mar 2015 19:53:57 +0000
>> > From: Marcus Baw <marcusbaw at gmail.com>
>> > To: For openEHR clinical discussions
>> >    <openehr-clinical at lists.openehr.org>
>> > Subject: Re: How to fix CKM biggest issue
>> > Message-ID:
>> >    <CAGoUAhqcAuwPZKxLStOMMmAZ7yhE-gE8f0vuHhtPDVN6HMhiJQ at mail.gmail.com>
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > Re: GitHub, for me the point is not that GitHub itself is proprietary or
>> > open source, it's that anyone doing an open source project can have
>> free GH
>> > repos. Perhaps this 'freemium pricing model' is a model that the CKM
>> > pricing could follow so that nonprofits could develop and review
>> > archetypes, while commercial entities would pay. This is the same as the
>> > Confluence/Atlassian model too.
>> >
>> > And the other point about GitHub is that the underlying technology (Git)
>> > definitely IS open source and free. Worth noting that GitHub is only
>> one of
>> > many online Git hosting services (Bitbucket etc does the same thing in
>> the
>> > same way, and there are FOSS alternatives like GitLab)
>> >
>> > M
>> >
>> >> On 14 March 2015 at 16:13, Ian McNicoll <ian at freshehr.com> wrote:
>> >>
>> >> Hi Marcus/ Pablo,
>> >>
>> >> I think the comparison/ contrast to Github is instructive, because, of
>> >> course GitHub is a hugely successful product which is highly
>> supportive of
>> >> open-source development, but it is not itself open-source. It is a
>> >> proprietary tool. If you truly feel that tooling to support
>> collaborative
>> >> working itself necessitates an open source license then you should
>> close
>> >> your Github accounts and look elsewhere.
>> >>
>> >> I would very much like to see a future where levels of sponsorship,
>> >> industry engagement, national funding etc, etc made it possible for
>> CKM and
>> >> other similar tools to be open-sourced but we are simply not in that
>> >> position right now. All of the key authoring tools are open-sourced or
>> >> free, (and all, I understand, will be open-sourced within a short
>> period).
>> >>
>> >> CKM was built to perform a very specific role i.e to help
>> informaticians
>> >> manage the complex process of crowd-sourcing clinical input, working
>> out
>> >> the impact of version changes, handling translation work, term-binding
>> >> work, terminology building, particularly at international or national
>> >> level. It is not needed to build an archetype, build a template or
>> build a
>> >> termset. It is not needed to display an archetype or template or
>> termset.
>> >> All of the resources are mirrored to GitHub and all of the
>> specifications
>> >> and information necessary to perform these activities are freely
>> available.
>> >>
>> >> CKM is a highly specialised tool with limited focus, primarily on
>> national
>> >> and international asset management. It is not needed to build openEHR
>> >> systems, any more than GitHub is needed to build open source software.
>> >>
>> >> Alternative repository management tools are starting to appear, such as
>> >> the 13606 Assocn. CIMM. I am sure David and Diego will not mind me
>> saying
>> >> that, as things stand, CIMM is a fair way off providing CKM -style
>> >> functionality.
>> >>
>> >> I think we are in danger of confusing some real and significant issues
>> >> around community engagement with the Foundation governance process.
>> The
>> >> issue of CKM licensing is model has, in my view, no practical impact
>> on the
>> >> concern that Pablo raised. Don't confuse the tool with the process.
>> >>
>> >> Even then I think we need to be aware that there are probably two quite
>> >> different requirements here.
>> >>
>> >> We need a  much better way for good candidates for international
>> >> archetypes to find their way into the international repository,
>> probably to
>> >> Incubators in the first instance. Some of the upcoming technical
>> changes to
>> >> the tool will help this but we also need to develop clear policies of
>> how
>> >> and when this is appropriate. The Foundation repository is primarily
>> >> designed to manage set of archetypes as a 'source of truth' with new
>> >> content flowing through in a relatively controlled but coherent
>> fashion.
>> >> Managing the governance of these 'semantic assets' requires much more
>> care
>> >> and precision than 'source code'
>> >>
>> >> This is quite different from the position in e.g Github which is
>> >> essentially a tool which allows some degree of socialisation between
>> >> otherwise siloed repositories. This is great for allowing assets and
>> source
>> >> code to be exposed, forked and re-used but it lacks the control and
>> >> coherence that is required by 'managed' national and international
>> >> standards development.
>> >>
>> >> I actually think we need both kinds of environment, and there is
>> nothing
>> >> to say that both environments need to be instantiated in the same tool.
>> >>
>> >> @Marcus - there is actually very little metadata in archetypes. The
>> >> translation support that Silje asked for is already supported in the
>> AOM,
>> >> and in some archetype editors such as LinkEHR. It is not supported in
>> the
>> >> openEHR archetype editor but as this is an open source tool, I will be
>> >> working on that problem later today :).
>> >>
>> >> I think there is a lot to be said for using Git to manage some of the
>> >> versioning and asset management activities we need, indeed I do that
>> all
>> >> the time when working on local projects, but none of this kind of
>> metadata
>> >> is carried in archetypes anyway. The kind of versioning and governance
>> >> metadata that we do need is equivalent to the metadata used by
>> RubyGems or
>> >> npm, needed for distributed source control, and the new versioning
>> metadata
>> >> that will be carried in archetypes is compliant with Semver which
>> underpins
>> >> npm.
>> >>
>> >> ADL is actually a very readable language, given the complexity of
>> >> information it needs to convey.
>> >>
>> >> It is, of course, unfamiliar but it is perfectly possible to produce
>> xml,
>> >> json, yaml ... serialisations of the Archetype Object Model which is
>> the
>> >> real source of truth.
>> >>
>> >> XML serialisation is fully supported by the LinkEHR and openEHR
>> Archetype
>> >> Editors, Thomas's Archetype Workbench exports these other formats and
>> the
>> >> template designer output is all expressed as XML.
>> >>
>> >> The problem is that these non-ADL serialisations are actually much more
>> >> difficult to read and understand than raw ADL, once, of course, you get
>> >> your head around ADL.
>> >>
>> >> @Pablo - CKM does make use of a proprietary document management system
>> but
>> >> the real challenge here is not technical, it is how we find a funding
>> model
>> >> that would sustain the kind of professional support that a tool like
>> CKM
>> >> requires. This is not a hacker project, it requires sustained
>> investment,
>> >> proper maintenance and a proper business model. So far it has not been
>> >> possible to persuade the wider informatics community to collaborate on
>> the
>> >> kind of joint funding that would make commercial sense to a prospective
>> >> supplier.
>> >>
>> >> This is an important discussion. I'm glad to hear people being
>> supportive
>> >> of all the great work that has been done, particularly by Heather
>> Leslie
>> >> and Sebastian Garde. It is not easy to develop a first-of-kind product.
>> >>
>> >> I think we have a great opportunity to discuss how to expand CKM
>> editorial
>> >> capacity, review current editorial policy around community involvement
>> and
>> >> to see how other non-CKM applications might fill some of the gaps that
>> have
>> >> been identified. I will certainly raise this via the new Board and, of
>> >> course, discuss further with Heather in our capacities as CKM editors
>> and
>> >> Heather's position as Clinical program lead.
>> >>
>> >> Let's not mix that discussion up with an equally important issue of
>> how we
>> >> can secure the funding necessary to sustain development and support for
>> >> repository tooling in the future. I don't think there would be much
>> >> objection to the principle that an open-source licensing model would be
>> >> preferred but that can only happen if the commercial model makes sense
>> for
>> >> potential providers.
>> >>
>> >> Ian
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Dr Ian McNicoll
>> >> mobile +44 (0)775 209 7859
>> >> office +44 (0)1536 414994
>> >> skype: ianmcnicoll
>> >> email: ian at freshehr.com
>> >> twitter: @ianmcnicoll
>> >>
>> >> Director, freshEHR Clinical Informatics
>> >> Director, openEHR Foundation
>> >> Director, HANDIHealth CIC
>> >> Hon. Senior Research Associate, CHIME, UCL
>> >>
>> >>> On 14 March 2015 at 13:20, Marcus Baw <marcusbaw at gmail.com> wrote:
>> >>>
>> >>>
>> >>>> On 14 March 2015 at 04:53, pablo pazos <pazospablo at hotmail.com>
>> wrote:
>> >>>>
>> >>>> For me the biggest concern, besides the limited publishing
>> capabilities
>> >>>> or non editors, is that the CKM is made over proprietary software,
>> that
>> >>>> doesn't allow us to create our own instances of the CKM for free,
>> and share
>> >>>> archetypes in a distributed / versioned way, like GitHub does.
>> >>>
>> >>>
>> >>>
>> >>> ?Pablo, you've nailed the problem here. *The CKM is proprietary*.
>> >>>
>> >>> Yet:
>> >>> "All contributions to CKM is on a voluntary basis, and all CKM
>> content is
>> >>> open source and freely available under a Creative Commons licence?"
>> From
>> >>> openEHR Foundation website:
>> >>> http://www.openehr.org/programs/clinicalmodels/documentation
>> >>>
>> >>> There's a disconnect there. I have in the past been in the middle of
>> >>> trying to explain openEHR to open source 'purists' and been left with
>> some
>> >>> uncomfortable questions to answer about the tooling used not being
>> freely
>> >>> available.  (no, despite what may appear to be my OSS zealotry I am
>> >>> actually not even close to being a Richard Stallman-esque OSS purist)
>> >>>
>> >>> 'community' computing is very definitely moving away from anything
>> that
>> >>> is dependent on proprietary platforms, towards cross-platform, open
>> source,
>> >>> generic systems. Open source languages, and Git for version control.
>> >>>
>> >>> *If we could find some way to wrap ADL in a more readable language
>> then
>> >>> perhaps we really could just use GitHub for archetype sharing one
>> day!*
>> >>> One of the primary reasons for reliance on a GUI is that ADL in its
>> raw
>> >>> form is so unreadable. If it could be read and understood in a text
>> editor
>> >>> then there would be less need for a GUI. I accept that clinician led
>> review
>> >>> would still benefit from a GUI.
>> >>>
>> >>> Another benefit of using a mature version control system such as Git
>> is
>> >>> that some of the metadata about archetype authoring and details of
>> who did
>> >>> a certain translation could reside in the version control commit
>> history
>> >>> and would therefore not need to reside inside the archetype itself.
>> This
>> >>> would reduce the size of archetypes, and would also obviate some of
>> the
>> >>> problems such as the one Silje mentioned on another thread - in which
>> there
>> >>> isn't room to record more than one translator.
>> >>>
>> >>> BTW this post is very definitely not intended as a criticism of any
>> >>> individuals, and I recognise the massive amount of hard work that has
>> gone
>> >>> before to even get where we are now.
>> >>>
>> >>> Marcus
>> >>>
>> >>> _______________________________________________
>> >>> openEHR-clinical mailing list
>> >>> openEHR-clinical at lists.openehr.org
>> >>>
>> >>>
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>> >>
>> >>
>> >> _______________________________________________
>> >> openEHR-clinical mailing list
>> >> openEHR-clinical at lists.openehr.org
>> >>
>> >>
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>> > -------------- next part --------------
>> > An HTML attachment was scrubbed...
>> > URL: <
>> http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150314/b525d7d1/attachment-0001.html
>> >
>> >
>> > ------------------------------
>> >
>> > Message: 2
>> > Date: Sat, 14 Mar 2015 17:22:35 -0300
>> > From: pablo pazos <pazospablo at hotmail.com>
>> > To: openEHR Clinical <openehr-clinical at lists.openehr.org>
>> > Subject: RE: How to fix CKM biggest issue
>> > Message-ID: <SNT151-W26B41FD43BBEF174D9B78FC8040 at phx.gbl>
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > Hi Ian,
>> > As I said, my opinion is about the technical aspects, and I tried to
>> separate this view from the management process problems, so I think there
>> would be no confusion, just another complementary opinion.
>> > For me the problem with the process is the one mentioned by Gustavo: I
>> can't get my archetypes on the CKM directly to share them with others, in
>> my case with students. If I want to teach them about the whole archetype
>> management process, I can't do much with the current CKM functionalities
>> besides archetypes translation. I want them to upload, review, translate,
>> approve, download, create new versions, upload new versions, etc, etc.I
>> would say this is another use case for the CKM that currently is not part
>> of the CKM, because you mention that the challenges are about "funding" and
>> "professional support". I don't think my use case needs neither of both,
>> but I think it can generate qualified professionals capable of doing such
>> work. So IMO what you mention and my use case are two faces of the same
>> coin. Without accessibility to all the functionalities of the CKM to
>> everyone (the tool aspect), it would be difficult to generated the
>> knowledge needed to manage the knowledge on the central CKM and on each
>> country (process aspect). After having trained professionals, "funding" is
>> a total different beast.
>> > GitHub is not open source, but anyone can download it and create local
>> repositories that can be versioned in a distributed way, even without using
>> Github servers. Also I can create my own GitHub like servers (
>> https://about.gitlab.com/).
>> > I mentioned GitHub because everyone knows it. But Git, the core
>> technology of GitHub is open source: http://git-scm.com/
>> > Basically what GitHub adds to Git is the cool views and the social
>> aspect, but technically speaking, Git does all the versioning management
>> work (repos, branches, pull requests, etc.).
>> > About Git not being a "managed", I think all the contrary, pull request
>> reviews are just that: a way to control what should or shouldn't be part of
>> the main source of truth, a.k.a. master branch.
>> >
>> > For the record, I'm not trying to troll the initial discussion by
>> setting the focus on technical aspects.
>> >
>> > --
>> > Kind regards,
>> > Eng. Pablo Pazos Guti?rrez
>> > http://cabolabs.com
>> >
>> > From: ian at freshehr.com
>> > Date: Sat, 14 Mar 2015 16:13:18 +0000
>> > Subject: Re: How to fix CKM biggest issue
>> > To: openehr-clinical at lists.openehr.org
>> >
>> > Hi Marcus/ Pablo,
>> > I think the comparison/ contrast to Github is instructive, because, of
>> course GitHub is a hugely successful product which is highly supportive of
>> open-source development, but it is not itself open-source. It is a
>> proprietary tool. If you truly feel that tooling to support collaborative
>> working itself necessitates an open source license then you should close
>> your Github accounts and look elsewhere.
>> > I would very much like to see a future where levels of sponsorship,
>> industry engagement, national funding etc, etc made it possible for CKM and
>> other similar tools to be open-sourced but we are simply not in that
>> position right now. All of the key authoring tools are open-sourced or
>> free, (and all, I understand, will be open-sourced within a short period).
>> >
>> > CKM was built to perform a very specific role i.e to help
>> informaticians manage the complex process of crowd-sourcing clinical input,
>> working out the impact of version changes, handling translation work,
>> term-binding work, terminology building, particularly at international or
>> national level. It is not needed to build an archetype, build a template or
>> build a termset. It is not needed to display an archetype or template or
>> termset. All of the resources are mirrored to GitHub and all of the
>> specifications and information necessary to perform these activities are
>> freely available.
>> > CKM is a highly specialised tool with limited focus, primarily on
>> national and international asset management. It is not needed to build
>> openEHR systems, any more than GitHub is needed to build open source
>> software.
>> > Alternative repository management tools are starting to appear, such as
>> the 13606 Assocn. CIMM. I am sure David and Diego will not mind me saying
>> that, as things stand, CIMM is a fair way off providing CKM -style
>> functionality.
>> > I think we are in danger of confusing some real and significant issues
>> around community engagement with the Foundation governance process.  The
>> issue of CKM licensing is model has, in my view, no practical impact on the
>> concern that Pablo raised. Don't confuse the tool with the process.
>> > Even then I think we need to be aware that there are probably two quite
>> different requirements here.
>> >
>> > We need a  much better way for good candidates for international
>> archetypes to find their way into the international repository, probably to
>> Incubators in the first instance. Some of the upcoming technical changes to
>> the tool will help this but we also need to develop clear policies of how
>> and when this is appropriate. The Foundation repository is primarily
>> designed to manage set of archetypes as a 'source of truth' with new
>> content flowing through in a relatively controlled but coherent fashion.
>> Managing the governance of these 'semantic assets' requires much more care
>> and precision than 'source code'
>> > This is quite different from the position in e.g Github which is
>> essentially a tool which allows some degree of socialisation between
>> otherwise siloed repositories. This is great for allowing assets and source
>> code to be exposed, forked and re-used but it lacks the control and
>> coherence that is required by 'managed' national and international
>> standards development.
>> > I actually think we need both kinds of environment, and there is
>> nothing to say that both environments need to be instantiated in the same
>> tool.
>> > @Marcus - there is actually very little metadata in archetypes. The
>> translation support that Silje asked for is already supported in the AOM,
>> and in some archetype editors such as LinkEHR. It is not supported in the
>> openEHR archetype editor but as this is an open source tool, I will be
>> working on that problem later today :).
>> > I think there is a lot to be said for using Git to manage some of the
>> versioning and asset management activities we need, indeed I do that all
>> the time when working on local projects, but none of this kind of metadata
>> is carried in archetypes anyway. The kind of versioning and governance
>> metadata that we do need is equivalent to the metadata used by RubyGems or
>> npm, needed for distributed source control, and the new versioning metadata
>> that will be carried in archetypes is compliant with Semver which underpins
>> npm.
>> > ADL is actually a very readable language, given the complexity of
>> information it needs to convey.
>> > It is, of course, unfamiliar but it is perfectly possible to produce
>> xml, json, yaml ... serialisations of the Archetype Object Model which is
>> the real source of truth.
>> > XML serialisation is fully supported by the LinkEHR and openEHR
>> Archetype Editors, Thomas's Archetype Workbench exports these other formats
>> and the template designer output is all expressed as XML.
>> > The problem is that these non-ADL serialisations are actually much more
>> difficult to read and understand than raw ADL, once, of course, you get
>> your head around ADL.
>> > @Pablo - CKM does make use of a proprietary document management system
>> but the real challenge here is not technical, it is how we find a funding
>> model that would sustain the kind of professional support that a tool like
>> CKM requires. This is not a hacker project, it requires sustained
>> investment, proper maintenance and a proper business model. So far it has
>> not been possible to persuade the wider informatics community to
>> collaborate on the kind of joint funding that would make commercial sense
>> to a prospective supplier.
>> > This is an important discussion. I'm glad to hear people being
>> supportive of all the great work that has been done, particularly by
>> Heather Leslie and Sebastian Garde. It is not easy to develop a
>> first-of-kind product.
>> > I think we have a great opportunity to discuss how to expand CKM
>> editorial capacity, review current editorial policy around community
>> involvement and to see how other non-CKM applications might fill some of
>> the gaps that have been identified. I will certainly raise this via the new
>> Board and, of course, discuss further with Heather in our capacities as CKM
>> editors and Heather's position as Clinical program lead.
>> > Let's not mix that discussion up with an equally important issue of how
>> we can secure the funding necessary to sustain development and support for
>> repository tooling in the future. I don't think there would be much
>> objection to the principle that an open-source licensing model would be
>> preferred but that can only happen if the commercial model makes sense for
>> potential providers.
>> >
>> > Ian
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Dr Ian McNicoll
>> > mobile +44 (0)775 209 7859
>> > office +44 (0)1536 414994
>> > skype: ianmcnicoll
>> > email: ian at freshehr.com
>> > twitter: @ianmcnicoll
>> >
>> > Director, freshEHR Clinical Informatics
>> > Director, openEHR Foundation
>> > Director, HANDIHealth CIC
>> > Hon. Senior Research Associate, CHIME, UCL
>> >
>> > On 14 March 2015 at 13:20, Marcus Baw <marcusbaw at gmail.com> wrote:
>> >
>> > On 14 March 2015 at 04:53, pablo pazos <pazospablo at hotmail.com> wrote:
>> > For me the biggest concern, besides the limited publishing capabilities
>> or non editors, is that the CKM is made over proprietary software, that
>> doesn't allow us to create our own instances of the CKM for free, and share
>> archetypes in a distributed / versioned way, like GitHub does.
>> >
>> > ?Pablo, you've nailed the problem here. The CKM is proprietary.
>> >
>> > Yet:
>> > "All contributions to CKM is on a voluntary basis, and all CKM content
>> is
>> > open source and freely available under a Creative Commons licence?"
>> From openEHR Foundation website:
>> http://www.openehr.org/programs/clinicalmodels/documentation
>> >
>> > There's a disconnect there. I have in the past been in the middle of
>> trying to explain openEHR to open source 'purists' and been left with some
>> uncomfortable questions to answer about the tooling used not being freely
>> available.  (no, despite what may appear to be my OSS zealotry I am
>> actually not even close to being a Richard Stallman-esque OSS purist)
>> >
>> > 'community' computing is very definitely moving away from anything that
>> is dependent on proprietary platforms, towards cross-platform, open source,
>> generic systems. Open source languages, and Git for version control.
>> >
>> > If we could find some way to wrap ADL in a more readable language then
>> perhaps we really could just use GitHub for archetype sharing one day! One
>> of the primary reasons for reliance on a GUI is that ADL in its raw form is
>> so unreadable. If it could be read and understood in a text editor then
>> there would be less need for a GUI. I accept that clinician led review
>> would still benefit from a GUI.
>> >
>> > Another benefit of using a mature version control system such as Git is
>> that some of the metadata about archetype authoring and details of who did
>> a certain translation could reside in the version control commit history
>> and would therefore not need to reside inside the archetype itself. This
>> would reduce the size of archetypes, and would also obviate some of the
>> problems such as the one Silje mentioned on another thread - in which there
>> isn't room to record more than one translator.
>> >
>> > BTW this post is very definitely not intended as a criticism of any
>> individuals, and I recognise the massive amount of hard work that has gone
>> before to even get where we are now.
>> >
>> > Marcus
>> >
>> >
>> > _______________________________________________
>> >
>> > openEHR-clinical mailing list
>> >
>> > openEHR-clinical at lists.openehr.org
>> >
>> >
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>> >
>> >
>> >
>> > _______________________________________________
>> > openEHR-clinical mailing list
>> > openEHR-clinical at lists.openehr.org
>> >
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>> > -------------- next part --------------
>> > An HTML attachment was scrubbed...
>> > URL: <
>> http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150314/8fb32974/attachment.html
>> >
>> >
>> > ------------------------------
>> >
>> > Subject: Digest Footer
>> >
>> > _______________________________________________
>> > openEHR-clinical mailing list
>> > openEHR-clinical at lists.openehr.org
>> >
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>> >
>> > ------------------------------
>> >
>> > End of openEHR-clinical Digest, Vol 35, Issue 38
>> > ************************************************
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150315/4f32abc9/attachment-0002.html>


More information about the openEHR-clinical mailing list