Re: Choosing appropriate composition archetypes for recording smoking and drinking summary
Thanks Ian for sharing the details. We can use it as a reference in the future. regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in On Wed, Jun 19, 2019 at 8:00 PM Ian McNicoll wrote: > Ultimately this is going to be about the context if use, and what you are > trying to do. Smoking history will be asked in many different places and in > many potentially different applications. > > If you are working with a single app, then the lifestyle_factors > composition is probably the sensible place as a default but in a multi-app > platform environment, you may want people to be able to ask about smoking > status in the context of a condition or disease pathway composition. > Ultimately it is really about your wish/ability to maintain a single source > of truth about smoking status > > Here is an approach we took for a coProduced Patient Health Record > > https://ckm.apperta.org/ckm/templates/1051.57.165/orgchart > > all of the templates are here > > https://ckm.apperta.org/ckm/#showProject=1051.61.34 > > and the underlying document is at https://apperta.org/coPHR/ > > but we took a different approach for a condition focussed pathway document > on Acute coronary syndrome - the key thing is that the archetype is > identical in both cases. > > Knitt > > > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: i...@freshehr.com > twitter: @ianmcnicoll > > > > Director, freshEHR Clinical Informatics Ltd. > CCIO inidus Ltd. i...@inidus.com > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > Hon. Senior Research Associate, CHIME, UCL > > > On Wed, 19 Jun 2019 at 14:32, Thomas Beale > wrote: > >> >> Hi Dileep, >> >> it would be interesting if you could publish anything about your virtual >> folder design, because more is being added to the RM to standardise how >> FOLDERs are used to represent episodes, mainly based on how DIPS (Norway) >> and Code24 (NL) do it. See SPECRM-55 and SPECRM-56 >> <https://openehr.atlassian.net/projects/SPECRM/versions/12516/tab/release-report-all-issues>. >> THis is certainly not complete, and indeed we have not yet published a >> guide for how to use Folders to do this (there probably is not yet full >> agreement anyway). Nevertheless, both these vendors have sophisticated >> approaches to using FOLDERs for episodes, and it would be good to have any >> other ideas to add to the mix so that we could either standardise a single >> approach, or else describe a small number of extant approaches such that >> client software can figure out what kind of episode representation it is >> dealing with. >> >> ANother thing, just for reference: from a formal point of view, what gets >> committed due to an encounter is always be a Contribution, i.e. an openEHR >> change set (thinking in DVCS, e.g. Git terms). A Contribution can contain >> any / all of: >> >>- completely new TLO(s) >>- new version(s) of any existing TLO(s) >>- change(s) to any existing TLO(s) >>- logical deletion(s) of any TLO(s) >>- changes to path structure of any TLO with such a structure (= >>directory) >> >> Here, TLO = 'top-level object', which can be the following from the EHR >> model >> <https://specifications.openehr.org/releases/RM/latest/ehr.html#_change_control_in_the_ehr> >> : >> >>- COMPOSITION >>- directory, consisting of FOLDERs >>- EHR_STATUS >>- EHR_ACCESS >> >> And from the Demographic model >> <https://specifications.openehr.org/releases/RM/latest/demographic.html>: >> >>- PARTY >>- PARTY_RELATIONSHIP >> >> ANd from the Task Planning model >> <https://specifications.openehr.org/releases/PROC/latest/task_planning.html> >> : >> >>- COMPOSITION containing WORK_PLAN or TASK_PLAN >> >> It is of course very common that the result of an encounter is just one >> new COMPOSITION, or one new version of one existing COMPOSITION - but just >> as with Git or any other versioning system, this requires a Contribution >> since it is still a change set. >> >> Full versioning semantics here >> <https://specifications.openehr.org/releases/RM/latest/common.html#_change_control_package>, >> for reference. >> >> - thomas >> >> >> On 05/06/2019 12:15, Dileep V S
Re: Choosing appropriate composition archetypes for recording smoking and drinking summary
Dear Thomas, We have made a document for internal use. Will polish it over the weekend and share it with you. Regards On Wed 19 Jun, 2019, 7:03 PM Thomas Beale, wrote: > > Hi Dileep, > > it would be interesting if you could publish anything about your virtual > folder design, because more is being added to the RM to standardise how > FOLDERs are used to represent episodes, mainly based on how DIPS (Norway) > and Code24 (NL) do it. See SPECRM-55 and SPECRM-56 > <https://openehr.atlassian.net/projects/SPECRM/versions/12516/tab/release-report-all-issues>. > THis is certainly not complete, and indeed we have not yet published a > guide for how to use Folders to do this (there probably is not yet full > agreement anyway). Nevertheless, both these vendors have sophisticated > approaches to using FOLDERs for episodes, and it would be good to have any > other ideas to add to the mix so that we could either standardise a single > approach, or else describe a small number of extant approaches such that > client software can figure out what kind of episode representation it is > dealing with. > > ANother thing, just for reference: from a formal point of view, what gets > committed due to an encounter is always be a Contribution, i.e. an openEHR > change set (thinking in DVCS, e.g. Git terms). A Contribution can contain > any / all of: > >- completely new TLO(s) >- new version(s) of any existing TLO(s) >- change(s) to any existing TLO(s) >- logical deletion(s) of any TLO(s) >- changes to path structure of any TLO with such a structure (= >directory) > > Here, TLO = 'top-level object', which can be the following from the EHR > model > <https://specifications.openehr.org/releases/RM/latest/ehr.html#_change_control_in_the_ehr> > : > >- COMPOSITION >- directory, consisting of FOLDERs >- EHR_STATUS >- EHR_ACCESS > > And from the Demographic model > <https://specifications.openehr.org/releases/RM/latest/demographic.html>: > >- PARTY >- PARTY_RELATIONSHIP > > ANd from the Task Planning model > <https://specifications.openehr.org/releases/PROC/latest/task_planning.html> > : > >- COMPOSITION containing WORK_PLAN or TASK_PLAN > > It is of course very common that the result of an encounter is just one > new COMPOSITION, or one new version of one existing COMPOSITION - but just > as with Git or any other versioning system, this requires a Contribution > since it is still a change set. > > Full versioning semantics here > <https://specifications.openehr.org/releases/RM/latest/common.html#_change_control_package>, > for reference. > > - thomas > > > On 05/06/2019 12:15, Dileep V S wrote: > > Dear Gerard, > > Thanks for your response. Your point of a composition being designed to > record a complete encounter is worth another discussion. > > I personally feel that it is one way of implementing your CDR, but there > could be other equally effective approaches that work better in other > situations. For example in the CDR service component of our platform > (EHR.Network), we have gone with generic reusable templates such as > complaints, diagnosis, medication summary, medication order etc. The > application can compose the complete schema for different encounter/event > use cases using a combination of these generic templates. The data gathered > in any event is grouped together under episodes and events using the > virtual folder service. > > This approach ensures the generic nature of the platform, while > maintaining it's extensibility over time. It also helps us contain the > proliferation of templates and keeps our library of commonly used stored > queries to a manageable level. > > May be there are other better approaches than either of these that are > already being used by others. I feel the approach to choose will depend > upon the requirements and so maintaining flexibility for the implementer > will be crucial. > > > ___ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Re: Significance of UID, template_id & concept in templates
Thanks Thomas/Ian, I will review the documents that Thomas has mentioned and comeback if there are any other questions. Meanwhile, from the template indexing errors that I got from Ethercis, I feel that Ethercis uses concept in some internal constructs. It seems to expect UID & concept to be unique. regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in On Wed, Jun 19, 2019 at 7:46 PM Ian McNicoll wrote: > Thomas is correct. > > Right now the template ID is generally the source of truth from a > technical pov but some systems also expect and use the uid. I don't think > 'concept' is actually used practically speaking. > > Ian > > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: i...@freshehr.com > twitter: @ianmcnicoll > > > > Director, freshEHR Clinical Informatics Ltd. > CCIO inidus Ltd. i...@inidus.com > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > Hon. Senior Research Associate, CHIME, UCL > > > On Wed, 19 Jun 2019 at 14:31, Thomas Beale > wrote: > >> Hi Dileep, >> >> the identification section of the AOM2 spec >> <https://specifications.openehr.org/releases/AM/latest/AOM2.html#_archetype_identification> >> gives a reasonable explanation. In ADL2/AOM2, a template is just an >> archetype, not something different, so all the archetype rules apply. More >> on ADL2 templates here >> <https://specifications.openehr.org/releases/AM/latest/AOM2.html#_templates>. >> ALl of the rules for ADL2/AOM2 should be the same for .oet / ADL 1.4 based >> templates (e.g. when is a new UID required etc). >> >> hope this helps. >> - thomas >> On 18/06/2019 21:05, Dileep V S wrote: >> >> Hi, >> >> Please see a snippet from an OPT that we have. I see that there are 3 >> different pieces of identification - UID, template_id & concept. >> Template_id seems to have been picked up automatically from the template >> file name and UID automatically generated by the template designer. >> >> The concept is something that the person creating the template can >> optionally give and can be different from the template_id. >> >> >> 0c8e4361-ed54-4555-b2d9-9680c1f2bb46 >> >> >> EHRN Medication summary.v0 >> >> EHRN Medication summary.v0 >> >> What are the intended purpose of each of these? Can we have two templates >> with different sets of these data without creating a conflict? For example >> can I have two versions of the same template with different UIDs and >> template_id, but same concept? How about two with different UIDs and same >> template_id or two with same UID and different template_ids. >> >> What situations can cause a conflict on the server? >> >> regards >> Dileep V S >> *Founder* >> HealtheLife Ventures LLP >> m: +91 9632888113 >> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 >> w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com >> <http://ayushehr.com> e: dil...@healthelife.in >> >> ___ >> openEHR-clinical mailing >> listopenEHR-clinical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> >> -- >> Thomas Beale >> Principal, Ars Semantica <http://www.arssemantica.com> >> Consultant, ABD Project, Intermountain Healthcare >> <https://intermountainhealthcare.org/> >> Management Board, Specifications Program Lead, openEHR Foundation >> <http://www.openehr.org> >> Health IT blog <http://wolandscat.net/> | Culture blog >> <http://wolandsothercat.net/> | The Objective Stance >> <https://theobjectivestance.net/> >> ___ >> openEHR-clinical mailing list >> openEHR-clinical@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > ___ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Significance of UID, template_id & concept in templates
Hi, Please see a snippet from an OPT that we have. I see that there are 3 different pieces of identification - UID, template_id & concept. Template_id seems to have been picked up automatically from the template file name and UID automatically generated by the template designer. The concept is something that the person creating the template can optionally give and can be different from the template_id. 0c8e4361-ed54-4555-b2d9-9680c1f2bb46 EHRN Medication summary.v0 EHRN Medication summary.v0 What are the intended purpose of each of these? Can we have two templates with different sets of these data without creating a conflict? For example can I have two versions of the same template with different UIDs and template_id, but same concept? How about two with different UIDs and same template_id or two with same UID and different template_ids. What situations can cause a conflict on the server? regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Re: Choosing appropriate composition archetypes for recording smoking and drinking summary
Dear Gerard, Thanks for your response. Your point of a composition being designed to record a complete encounter is worth another discussion. I personally feel that it is one way of implementing your CDR, but there could be other equally effective approaches that work better in other situations. For example in the CDR service component of our platform (EHR.Network), we have gone with generic reusable templates such as complaints, diagnosis, medication summary, medication order etc. The application can compose the complete schema for different encounter/event use cases using a combination of these generic templates. The data gathered in any event is grouped together under episodes and events using the virtual folder service. This approach ensures the generic nature of the platform, while maintaining it's extensibility over time. It also helps us contain the proliferation of templates and keeps our library of commonly used stored queries to a manageable level. May be there are other better approaches than either of these that are already being used by others. I feel the approach to choose will depend upon the requirements and so maintaining flexibility for the implementer will be crucial. regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in On Tue, Jun 4, 2019 at 5:04 PM GF wrote: > Hi, > > Afaik. > Composition is to document one complete encounter. > > I use the ENTRY to start documenting the Documentation process. > And CLUSTERS to deal with Pannels with Clinical Statements. > > > Gerard Freriks > +31 620 34 70 88 > +31 182 22 59 46 > gf...@luna.nl > > Kattensingel 20 > 2801 CA Gouda > the Netherlands > > On 4 Jun 2019, at 06:25, Dileep V S wrote: > > > What would be the composition archetype recommended for a template to > record summaries such as Smoking & drinking? The best that I could think of > is the encounter composition. Do let me know if any other is better suited. > > On a related note, are there any rules or best practices in choosing the > appropriate composition archetype to use for building templates? Are we > planning to have more composition archetypes such as Medication list & > problem list for use with all kinds of different templates? > > regards > > > ___ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Re: Choosing appropriate composition archetypes for recording smoking and drinking summary
Thanks Leslie, Do you feel Health summary( https://ckm.openehr.org/ckm/archetypes/1013.1.1969) will be appropriate for things like menstrual summary? regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in On Wed, Jun 5, 2019 at 3:13 PM Heather Leslie < heather.les...@atomicainformatics.com> wrote: > Hi Dileep, > > > > The Lifestyle factors COMPOSITION is the one that has been built to carry > smoking and alcohol data, plus other lifestyle related data such as > physical exercise, nutrition etc – see > https://ckm.openehr.org/ckm/archetypes/1013.1.1648 > > > > The intent for COMPOSITION design is to build ones that will support > querying for the broad types of clinical data that we store. For example, > Report has been specialised for a couple of extremely commonly used type of > reports but I would not advise building one for every type of report, > rather query on the Report COMPOSITION plus relevant ENTRY archetypes. > > > > This is not a precise science but we are trying to be pragmatic – to > balance the reuse of generic archetypes with clear and safe querying. > > > > Hope this helps > > > > Regards > > > > Hetehr > > > > > > *From:* openEHR-clinical *On > Behalf Of *Dileep V S > *Sent:* Tuesday, 4 June 2019 6:25 AM > *To:* For openEHR clinical discussions > > *Subject:* Choosing appropriate composition archetypes for recording > smoking and drinking summary > > > > Hi, > > > > What would be the composition archetype recommended for a template to > record summaries such as Smoking & drinking? The best that I could think of > is the encounter composition. Do let me know if any other is better suited. > > > > On a related note, are there any rules or best practices in choosing the > appropriate composition archetype to use for building templates? Are we > planning to have more composition archetypes such as Medication list & > problem list for use with all kinds of different templates? > > > > regards > > Dileep V S > > *Founder* > > *HealtheLife Ventures LLP* > > m: > > +91 9632888113 > > a: > > 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 > > w: > > ehr.network, <http://ehr.network>ayushehr.com e: dil...@healthelife.in > > > ___ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Choosing appropriate composition archetypes for recording smoking and drinking summary
Hi, What would be the composition archetype recommended for a template to record summaries such as Smoking & drinking? The best that I could think of is the encounter composition. Do let me know if any other is better suited. On a related note, are there any rules or best practices in choosing the appropriate composition archetype to use for building templates? Are we planning to have more composition archetypes such as Medication list & problem list for use with all kinds of different templates? regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Re: Mandatory fields in service_request.v1
Thank you regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in On Thu, May 30, 2019 at 5:30 PM Ian McNicoll wrote: > 'timing' is intended to carry some sort of parsable timing structure such > as GTS http://www.vico.org/HL7_V2_5/v251/hl7v251typGTS.htm but I never > use this. GTS is horrible and we have found it much more appropriate to > model times inside the archetype - see medication orders/ dose and timings > for a good example. > > I believe there is a CR to make timing optional - for now I just put in > some kind of dummy timing structure to get around the mandation. > > Ian > > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: i...@freshehr.com > twitter: @ianmcnicoll > > > > Director, freshEHR Clinical Informatics Ltd. > CCIO inidus Ltd. i...@inidus.com > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > Hon. Senior Research Associate, CHIME, UCL > > > On Thu, 30 May 2019 at 12:44, Dileep V S wrote: > >> Hi, >> >> I am using [openEHR-EHR-INSTRUCTION.service_request.v1] in a template and >> notice that it has two mandatory nodes - narrative >> & current_activity:0/timing. >> >> Narrative expects a human readable narrative of the request (mandatory >> for all instructions). But I am not sure what the 'timing' node expects. It >> takes any text value, but I am not sure what to put there. >> >> regards >> >> Dileep V S >> *Founder* >> HealtheLife Ventures LLP >> m: +91 9632888113 >> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 >> w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com >> <http://ayushehr.com> e: dil...@healthelife.in >> ___ >> openEHR-clinical mailing list >> openEHR-clinical@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > ___ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Mandatory fields in service_request.v1
Hi, I am using [openEHR-EHR-INSTRUCTION.service_request.v1] in a template and notice that it has two mandatory nodes - narrative & current_activity:0/timing. Narrative expects a human readable narrative of the request (mandatory for all instructions). But I am not sure what the 'timing' node expects. It takes any text value, but I am not sure what to put there. regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Re: Downloading previous versions of archetypes from CKM
Hi Ian/Marcus, Thanks everybody for a healthy discussion that I am sure will help many implementors. My idea was not to belittle what the community has achieved with the limited resources. That would be unkind on my part to all the community members who have(and continue to) invested their time and knowledge to get to where we are today. But as more an more real world implementors are beginning to commit to the OpenEHR philosophy, it is important for them to be aware of it's limitations and hedge adequately against them. So if we are able to evolve some best practice recommendations out of this discussion, we would have taken one more step forward. My two bits after reading through the discussions. This is a complex problem that may not have a full solution immediately. It is going to be a combination of tools, people & processes for some more time till the tools mature. CKM does some bits and the implementors need to take over from there and evolve local processes. Sharing of such local processes will help others and mature the community tooling over time. Thanks once again regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in On Tue, May 28, 2019 at 4:59 PM Ian McNicoll wrote: > Hi Marcus, > > Thanks for your support. > > I would love to see NHSX support something like this, especially as I know > the FHIR folks are going down that road and we need something that goes > well beyond just openEHR artefacts and into termsets, valuesets, rules etc. > Every community working on health semantics will need something like this, > and we will all need to be able to reference artefacts from other standards > groups. > > I have been looking at NPM but Bit https://bit.dev/ might be interesting > and fit better with our paradigm which is more about components than code > per-se. > > Ian > > Ian > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: i...@freshehr.com > twitter: @ianmcnicoll > > > > Director, freshEHR Clinical Informatics Ltd. > CCIO inidus Ltd. i...@inidus.com > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > Hon. Senior Research Associate, CHIME, UCL > > > On Tue, 28 May 2019 at 12:22, Marcus Baw wrote: > >> Interesting discussion and I agree with Ian that the openEHR community >> should remember to give itself credit for what HAS been done, with very >> little resource, rather than beating themselves up about what tooling is >> missing from the ecosystem. >> >> An automated archetype package and dependency manager, as well as >> archetype version migration tools, would be great to have. It should work >> like package managers in other language ecosystems such as NPM, RubyGems, >> PyPi etc. We need to get some resources behind this idea, maybe we could >> collectively encourage the new NHSx to think in this direction? >> >> Marcus >> >> On Tue, 28 May 2019 at 12:12, Ian McNicoll wrote: >> >>> Hi Paul, >>> >>> Nicely summed up. >>> >>> You definitely need to manage your CDR artefacts in just the same way as >>> any other software libraries. This is currently more manually intensive >>> than it should be but one can see how it could be largely automated >>> >>> However, maintaining coherent semantics is much more challenging as you >>> need to consider how each new app or datastream fits into both some sort of >>> attempt to keep a longitudinal record, with the need to preserve condition/ >>> episode or pathway data quality. That is hard and will require human beings >>> to design and continually adapt. For LHCRE purposes and beyond I have made >>> a start at a baseline architecture of templates that should be applicable >>> to a broad set of communities but it will require customisation, depending >>> on local circumstances. e.g can we apply the rule that there should only be >>> a single allergies list for the whole community? Do we have sufficient >>> vendor buy-in, and clinical buy-in, and the governance structures to >>> resolve any differences of opinion or to challenge poor data quality. As >>> GPs we have been used to this sort of challenge within our own practices - >>> are we able to scale up to a wider community of practice. >>> >>> Ian >>> Dr Ian McNicoll >>> mobile +44 (0)775 209 7859 >>> office +44 (0)1536 414994 >>> skype: ianmcnicoll >>> email: i...@freshehr.
Re: Downloading previous versions of archetypes from CKM
> > to download, for example click on the Details Button underneath each > archetype revision in the revision history. > You can also keep track of all the changes in the git repository at https://github.com/openEHR/CKM-mirror Thanks Sebastian. That is what I was looking for regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in On Tue, May 28, 2019 at 11:49 AM Sebastian Garde < sebastian.ga...@oceaninformatics.com> wrote: > To download, for example click on the Details Button underneath each > archetype revision in the revision history. > > You can also keep track of all the changes in the git repository at > https://github.com/openEHR/CKM-mirror > > While I obviously agree with the aim of everybody using the same > archetypes, it is probably still a bit of a lofty aim. > > Nonetheless a lot of progress has actually been made and it is my > understanding at least that many of the more commonly required archetypes > are published. Even so, I would see the RM as the core schema, and that > doesn’t change if you use different archetypes. > > > > Pablo, yes, agree with funding, but it always seems that everybody wants > something. > > Re automating comparisons, maybe we should look into exposing this via the > api as well somehow. > > Nonetheless, the semantic version and also the log message should at least > give an indication of the type of change and impact. > > I think Ian and Bjorn have some packaging ideas to better support > implementers – this is somewhat the other side of the modelling coin, but > important of course as well. > > Sebastian > > > > *Von:* openEHR-clinical *Im > Auftrag von *Dileep V S > *Gesendet:* Dienstag, 28. Mai 2019 07:11 > *An:* For openEHR clinical discussions > > *Betreff:* Re: Downloading previous versions of archetypes from CKM > > > > Hi, > > > > Thank you for all the responses. It has helped me clear a couple of of > things that need to be keep in mind while using resources from OpenEHR CKM. > Just to summarize, > >1. Archetypes in v0 are to be treated as initial suggestions and can >change anytime and without any pattern. Published ones from v1 are more >stable and the changes managed better. >2. Using V0 is at one's own risk and so keeping a local copy would be >advisable >3. CKM allows viewing and comparing version history using archetype >history > > The above raises some additional questions > >1. What are the specific steps/links to download older version of >archetypes from the CKM. The archetype history allows comparison between >versions. But I could not find any link to view/download older versions. >2. Majority of the archetypes in CKM are unpublished v0 versions. So >it is difficult to build any meaningful CDR currently using only published >archetypes. What will be the best strategy to keep moving forward with >creating real solutions while keeping the spirit of OpenEHR relevant. >3. Managing copies of the archetypes that are used separately by >different users is bound to create fragmented schema across openEHR >compliant CDRs, thereby defeating the fundamental premise of interoperable >schema among OpenEHR CDRs. > > regards > > [image: https://drive.google.com/uc?id=0BxQc41y9yqs6bkE5a1JQQVBjZG8] > > Dileep V S > > *Founder* > > *HealtheLife Ventures LLP* > > m: > > +91 9632888113 > > a: > > 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 > > w: > > ehr.network, <http://ehr.network>ayushehr.com e: dil...@healthelife.in > > > > > > On Tue, May 28, 2019 at 2:15 AM Sebastian Garde < > sebastian.ga...@oceaninformatics.com> wrote: > > Hi > > > > The v1 to v0 migration was a once off thing that was decided to be the > best for never before published archetypes. > > I’ve never been a big fan of v0 because of the all the complications it > has, but at least it tells you clearly that all bets are off regarding this > archetype because it is under development and anything goes, including > changes to its archetype id, if required. > > V0 is also consistent with SemVer (although you could do it differently as > well, e.g. 1.0.0-alpha). > > After publication to v1, the governance is more formal and follows > semantic versioning of patch, minor and major versions. > > > > It may not always be nice, but unless someone can provide a comprehensive, > clean and perf
Re: Downloading previous versions of archetypes from CKM
> > An ideal scenario would be to have a record of the archetypes someone is > using, and when a new revision is published, run the diff between that and > the revision the implementer is using, and notify of possible > incompatibilities, that way we can know exactly what's wrong and fix > accordingly. User can have an option to maintain this list in their CKM account and use it for comparison regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in On Tue, May 28, 2019 at 11:27 AM Pablo Pazos wrote: > Adding to what was commented, there is a gap between implementers and the > CKM/modeling process. > > + implementers will use any archetype, even drafts, that are published on > the CKM, because those might match the requirements, so for that > implementer the archetype might be OK. > + implementers can't approve archetypes to move from draft to published, > can make suggestions to improve them, but not change their status. > + the modeling process allows those draft archetypes to change anytime in > any way, generating potential incompatibilities with the revisions > downloaded by implementers, and that can only be checked manually, by each > implementer, for each modified archetype. I did this and could take a whole > day to review an archetype and analyze incompatibilities. > + for implementers is difficult to track archetypes they (we) are using, > to see when an archetype that we use changes and compare to find potential > incompatibilities. Current tools allow to follow an archetype and be > notified by email when changes are done, and the CKM has a compare tool, > but is all a manual process. An ideal scenario would be to have a record of > the archetypes someone is using, and when a new revision is published, run > the diff between that and the revision the implementer is using, and notify > of possible incompatibilities, that way we can know exactly what's wrong > and fix accordingly. > > Another point is that AFAIK current clinical modelers are voluntary, which > I think the Foundation should consider funding to have more archetypes > reviewed and published, than having most in draft. There is some money on > the Foundation, let's use it to help the community, and also give something > back to our core clinical modelers. We need a dedicated team for these > things. > > On Tue, May 28, 2019 at 2:11 AM Dileep V S wrote: > >> Hi, >> >> Thank you for all the responses. It has helped me clear a couple of of >> things that need to be keep in mind while using resources from OpenEHR CKM. >> Just to summarize, >> >>1. Archetypes in v0 are to be treated as initial suggestions and can >>change anytime and without any pattern. Published ones from v1 are more >>stable and the changes managed better. >>2. Using V0 is at one's own risk and so keeping a local copy would be >>advisable >>3. CKM allows viewing and comparing version history using archetype >>history >> >> The above raises some additional questions >> >>1. What are the specific steps/links to download older version of >>archetypes from the CKM. The archetype history allows comparison between >>versions. But I could not find any link to view/download older versions. >>2. Majority of the archetypes in CKM are unpublished v0 versions. So >>it is difficult to build any meaningful CDR currently using only published >>archetypes. What will be the best strategy to keep moving forward with >>creating real solutions while keeping the spirit of OpenEHR relevant. >>3. Managing copies of the archetypes that are used separately by >>different users is bound to create fragmented schema across openEHR >>compliant CDRs, thereby defeating the fundamental premise of interoperable >>schema among OpenEHR CDRs. >> >> regards >> Dileep V S >> *Founder* >> HealtheLife Ventures LLP >> m: +91 9632888113 >> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 >> w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com >> <http://ayushehr.com> e: dil...@healthelife.in >> >> >> On Tue, May 28, 2019 at 2:15 AM Sebastian Garde < >> sebastian.ga...@oceaninformatics.com> wrote: >> >>> Hi >>> >>> >>> >>> The v1 to v0 migration was a once off thing that was decided to be the >>> best for never before published archetypes. >>>
Re: Downloading previous versions of archetypes from CKM
Hi, Thank you for all the responses. It has helped me clear a couple of of things that need to be keep in mind while using resources from OpenEHR CKM. Just to summarize, 1. Archetypes in v0 are to be treated as initial suggestions and can change anytime and without any pattern. Published ones from v1 are more stable and the changes managed better. 2. Using V0 is at one's own risk and so keeping a local copy would be advisable 3. CKM allows viewing and comparing version history using archetype history The above raises some additional questions 1. What are the specific steps/links to download older version of archetypes from the CKM. The archetype history allows comparison between versions. But I could not find any link to view/download older versions. 2. Majority of the archetypes in CKM are unpublished v0 versions. So it is difficult to build any meaningful CDR currently using only published archetypes. What will be the best strategy to keep moving forward with creating real solutions while keeping the spirit of OpenEHR relevant. 3. Managing copies of the archetypes that are used separately by different users is bound to create fragmented schema across openEHR compliant CDRs, thereby defeating the fundamental premise of interoperable schema among OpenEHR CDRs. regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in On Tue, May 28, 2019 at 2:15 AM Sebastian Garde < sebastian.ga...@oceaninformatics.com> wrote: > Hi > > > > The v1 to v0 migration was a once off thing that was decided to be the > best for never before published archetypes. > > I’ve never been a big fan of v0 because of the all the complications it > has, but at least it tells you clearly that all bets are off regarding this > archetype because it is under development and anything goes, including > changes to its archetype id, if required. > > V0 is also consistent with SemVer (although you could do it differently as > well, e.g. 1.0.0-alpha). > > After publication to v1, the governance is more formal and follows > semantic versioning of patch, minor and major versions. > > > > It may not always be nice, but unless someone can provide a comprehensive, > clean and perfect set of archetypes, that’s what life will be for a while. > CKM aims to support the processes around the development, review and > publication of the archetypes etc. as much as possible. > > In CKM, the revision history of an archetype links back to any previous > (or next) major version of the archetype. See e.g. the Blood pressure v2 > archetype. You can get any (trunk) revision of the archetype that was ever > uploaded to CKM from there and compare any two revisions. Archetypes that > were updated in the last couple of years will have the SemVer version in it > as well, and there is always the canonical hash (the one used in the > template) you can use to determine the right version of the archetype if > required. > > > > I hope this answer your questions below and provides a bit of context in > between. > > > > Regards, > > Sebastian > > > > *From:* openEHR-clinical *On > Behalf Of *Pablo Pazos > *Sent:* Montag, 27. Mai 2019 20:37 > *To:* For openEHR clinical discussions > > *Subject:* Re: Downloading previous versions of archetypes from CKM > > > > You might also have problems with some archetypes that went from .v1 to .v0 > > > > In the archetype history you can see the previous versions, but some will > have a broken history, for instance some archetypes changed name and > archetype id but serve the same purpose as the old archetypes, which broke > any implementation of the previous archetype. Also there is no clear > history of archetypes changing ID or merging archetypes. > > > > Because of those issues is difficult to trust what is on the CKM in the > long term. I decided to work with older archetypes to keep my baseline > clean and stable, do modifications on those if required, and create our own > archetypes when required. > > > > I'm not sure if this is because how the CKM manages archetypes, or because > the modeling process have flaws in the version management. > > > > On Mon, May 27, 2019 at 5:01 AM Dileep V S wrote: > > Hi, > > I had used some archetypes from CKM in my templates some time back. Now > when I am revising & reviewing them I notice that some of the archetypes > have newer versions an so my templates give error as they are unable to > locate the older versions that they use. So I have a few questi
Downloading previous versions of archetypes from CKM
Hi, I had used some archetypes from CKM in my templates some time back. Now when I am revising & reviewing them I notice that some of the archetypes have newer versions an so my templates give error as they are unable to locate the older versions that they use. So I have a few questions on the best practices for using CMK resources 1. Can I access older versions of archetypes from CKM? and how? 2. Should I maintain a copy of the archetype versions that are used in my templates separately? 3. Are archetype versions incremental improvements? If yes should the AQL not support multiple versions to maintain backward compatibility as the templates evolve? regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: <http://ayushehr.com>ehr.network, <http://ehr.network>ayushehr.com <http://ayushehr.com> e: dil...@healthelife.in ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Re: Appropriate archetype for pulse recording in vitals
Sorry, It is my mistake. I got confused regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: healthelife.in e: dil...@healthelife.in On Wed, Apr 3, 2019 at 8:06 PM Grant Forrest wrote: > I might be missing something very obvious here, but is pulse not for the > heart rate and respiration for the respiratory rate ? > > Cheers > > Grant > > On 03/04/2019 09:39, Dileep V S wrote: > Hi, > > CKM includes two archetypes - > > > openEHR-EHR-OBSERVATION.pulse.v1 & > > > openEHR-EHR-OBSERVATION.respiration.v1, Both of which seem to be capturing > very similar data. > > Which is recommended for general vitals recording of pulse rate? What is > the reason why we have 2 very similar archetypes? > > regards > > > [https://drive.google.com/uc?id=0BxQc41y9yqs6bkE5a1JQQVBjZG8] > Dileep V S > Founder > HealtheLife Ventures LLP > m: +91 9632888113 > a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 > w: healthelife.in<http://healthelife.in/> e: dil...@healthelife.in > <mailto:dil...@healthelife.in> > > > > ___ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org openEHR-clinical@lists.openehr.org> > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > > -- > > Dr J Grant Forrest > Part Time Postgraduate MPhil Student/Health Informatics > University of Strathclyde > e grant.forr...@strath.ac.uk<mailto:grant.forr...@nhs.net> > m 07510 355203 > ___ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Appropriate archetype for pulse recording in vitals
Hi, CKM includes two archetypes - openEHR-EHR-OBSERVATION.pulse.v1 & openEHR-EHR-OBSERVATION.respiration.v1, Both of which seem to be capturing very similar data. Which is recommended for general vitals recording of pulse rate? What is the reason why we have 2 very similar archetypes? regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: healthelife.in e: dil...@healthelife.in ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Moving towards the use of SNOMED CT in place of local codes for better interoperability
Hi, Many of the archetypes in the CKM use local codes extensively (Diagnosis certainty in problem diagnosis, severity category in symptom sign etc.). SNOMED CT seems to include reasonable replacements for a large number of these already. Will it not make sense for reducing the use of local codes in archetypes as that will improve interoperability of OpenEHR modeled data beyond the OpenEHR ecosystem and also reduce management overhead for the modelling community? Do we have any specific reasons for not leaving such nodes as text with recommendations for use of coding terminology? regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: healthelife.in e: dil...@healthelife.in ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Re: Archetypes for consent, end-of-life planning and advance decision to refuse treatment
Hi Ian/Paul, Thank you both for the responses(especially Ian for the detailed response). We are still in early days and am sure we can learn from your experiences as we make progress at our end. I will surely be taking on your offer of help at an appropriate time. regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: healthelife.in e: dil...@healthelife.in On Fri, Nov 23, 2018 at 6:14 PM Paul Miller wrote: > Hi Dileep > > Just with reference to the ReSPECT Template to let you know I will be > working with the development team on implementing this in some applications > in the New Year. It may be as we do that that we need to change the > template, but hopefully it is 'good enough' for first of type examples > currently. > > The ReSPECT template is very UK specific, I think, but there may be > lessons to be learned or elements of the template that could be usefully > used in other contexts. > > Please get in touch with me if you decide to use any of it or have any > comments/queries. > > Best wishes > > Paul > > Dr Paul Miller > Glenburn Medical Practice > Fairway Avenue > Paisley > PA2 8DX > Tel: 0141 884 7788 > http://www.glenburnsurgery.scot.nhs.uk/ > > SCIMP Clinical Lead > Tel: 07711 346 928 > http://www.scimp.scot.nhs.uk/ > Twitter @SCIMP_GP > > > On Fri, 23 Nov 2018 at 10:19, Ian McNicoll wrote: > >> Hi Dileep, >> >> My apologies for the slow reply. >> >> These are good questions! The issue of 'source of truth' is still 'in >> development' in the UK. Typically there is a paper document which is the >> formal source of truth with electronic copies held at different >> institutions with varied attempts /approaches to synchronising or >> developing an electronic source of truth. So a messy space but the forward >> direction in many places is to have a patient orientated single source of >> truth. >> >> So, for instance, this national (Scotland) project >> >> >> https://www.mobihealthnews.com/content/former-skyscanner-cto-joins-nhs-scotland-build-national-digital-platform-%E2%80%98world-first%E2%80%99 >> >> is going to use the new Respect End of life care form as the first app to >> be built on the digital platform (based on openEHR). >> >> http://ckm.apperta.org/ckm/#showProject=1051.61.31 >> >> This is a UK-wide project. >> >> There is also some older modelling work at >> >> http://ckm.apperta.org/ckm/#showProject=1051.61.4 >> >> but some of this has been superceded by new requirements. >> >> 2. The rules around engagement and authority change continually but >> clearly these kind of decisions need to be very clearly documented and >> reflected in archetypes/templates - you will see how that is handled in the >> Respect example. >> >> 3. Mental Health - feshEHR has done a little bit of work in this space >> for some English trusts and there is a plan to do some more. You might also >> want to contact Martin van den Meer at Code24 in the Netherlands >> https://www.code24.nl/ as they have extensive experience with mental >> health care plans. >> >> There are no plans to move the UK end of life care archetypes and >> templates to the international CKM. Most of these are quite specific to UK >> practice / legislation but they can be freely downloaded and used/adapted >> from the Apperta UK CKM >> >> Ian >> >> Dr Ian McNicoll >> mobile +44 (0)775 209 7859 >> office +44 (0)1536 414994 >> skype: ianmcnicoll >> email: i...@freshehr.com >> twitter: @ianmcnicoll >> >> >> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org >> Director, freshEHR Clinical Informatics Ltd. >> Director, HANDIHealth CIC >> Hon. Senior Research Associate, CHIME, UCL >> >> >> On Mon, 12 Nov 2018 at 14:03, Dileep V S wrote: >> >>> Dear Ian, >>> >>> We are in discussions with a state government in India for the use of >>> our EHR.Network platform for implementing a public Mental Health Management >>> System(MHMS) in line with the Indian National mental healthcare act >>> 2017(MHA). >>> >>> Some of the requirements of this system are registration of advance >>> directives, consent and designated persons. As the MHA defines mental >>> healthcare as a right, these directives hold a very critical role in care >>> related decisions. >>> >>> While exploring options and trying to understand how others have gone >>> ahead with suc
Archetypes for consent, end-of-life planning and advance decision to refuse treatment
Dear Ian, We are in discussions with a state government in India for the use of our EHR.Network platform for implementing a public Mental Health Management System(MHMS) in line with the Indian National mental healthcare act 2017(MHA). Some of the requirements of this system are registration of advance directives, consent and designated persons. As the MHA defines mental healthcare as a right, these directives hold a very critical role in care related decisions. While exploring options and trying to understand how others have gone ahead with such requirements, we came across some archetypes that (I think) you had posted in the following link http://ckm.apperta.org/ckm/ retrieveResources?list=true. Can you give some background on how these were used and if you believe that they are still relevant? Is there any plans to port these to the OpenEHR CKM for more wider use? My specific questions are 1. Were these meant to be used as the source of ultimate truth or just for information at point of care? 2. In our case there is a formal registration process with submission and approval by people in authority. Was this envisaged when creating the above archetypes? 3. Are you aware of any previous OpenEHR implementations for Mental health care? Thanks in advance regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: healthelife.in e: dil...@healthelife.in ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Archetypes for Ayurveda and yoga
Hi, We are working on a OpenEHR based EHR solution for Ayurveda and Yoga practices. As the fundamental tenets of Ayurveda are different from the allopathy, we are in the process of creating a different set of archetypes as per their practice requirements. We would like to make them available to anybody else who may find them useful. What is the best way to do this? Is it appropriate to add them to the OpenEHR CKM? or is that only for Allopathy specific archetypes? What should be the general framewok as like us others may be trying to adapt OpenEHR RM to other such practices around the world? In case you have not heard of Ayurveda, please try these links https://chopra.com/articles/what-is-ayurveda https://en.wikipedia.org/wiki/Ayurveda regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: healthelife.in e: dil...@healthelife.in ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Re: openEHR related News: Ripple Foundation launches EtherCIS to the world of Healthcare
A big thank you to all the people behind Ethercis and Ripple. You work, I am sure, would herald the turning point in the long life of OpenEHR and is bound to accelerate it's adoption, especially in countries like India, where the healthcare market is very cost sensitive. We have been testing Ethercis for a couple of months now and have found it to be extremely promising. Apart from the product quality, Christian has been extremely supportive and understanding of any issues that we have faced. Special thanks to Ian for taking personal initiative to look for ways for helping us make progress. Happy to be part of a great community. regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: healthelife.in e: dil...@healthelife.in On Thu, Jul 27, 2017 at 9:49 PM, Tony Shannon < tony.shannon@ripple.foundation> wrote: > Dear openEHR Colleagues, > > At long last I'm pleased to announce some news to the openEHR community, > which I hope you will find of interest/value to you. > > Those of you who know me, know I have been championing openEHR for quite > some time, I believe it is key to the future of healthcare. > You may also know that I have been an advocate for an open source > implementation of openEHR in action for quite some time too. > > In my opinion if we want openEHR to truly transform the world of healthIT > and healthcare, we need to make the related tools very easily available > around the world. > > So, building on some great work began years ago with Seref Arikan > (Opereffa) and aligned to the leading edge open source work of Pablo Pazos > with Cabolabs EHRServer. > I'm very pleased to announce the public release of EtherCIS, as an > internationally leading open source example of the openEHR standard in > action, including support for AQL. > http://ripple.foundation/2017/07/ripple-foundation-launches- > ethercis-world-healthcare/ > > Over the last 2 years, the work to get EtherCIS to this point has been > done within the context of a broad open platform push (begun out of Leeds > in England). > Initially known as the Ripple Open Source Initiative, the effort has since > evolved to become the work of the non profit Ripple Foundation which I > lead. > http://ripple.foundation > > We have supported the development of EtherCIS in the context of developing > and testing of a highly usable/open source "showcase stack", which we will > share more details on later. > > For now I wanted to thank a few folk who have made this development > possible, > Of course the many many folk who have brought openEHR to the point that is > already at... you know who you are , I know many of you as friends and > again a word of thanks today. > Dr Ian McNicoll who has helped with his usual good humoured leadership of > the openEHR mission and supporting/overseeing the openEHR aspects to our > work, > Marand for their ongoing help with their openEHR EHRscape service which is > a key part of our Ripple showcase. > and last by by no means least.. > Christian Chevalley without whom , this world leading open source example > of the openEHR standard in action would not have been possible. > > Christian may wish to say a few words about his work here shortly, but > suffice to say Christian has put his heart and soul into this very valuable > work and working with us to open source this work, has gifted something > very useful to the world. > I appreciate all he has done to make this public release of EtherCIS > possible, which I believe to now be the leading open source example of > openEHR in action. > > > We believe that openEHR has been designed to support the needs of 21st > Century Healthcare. > We know openEHR is in action around the world and the change that is > needed has begun. > You may have seen some of our recent/related openEHR videos which we hope > you like and hope you share. http://ripple.foundation/news/ > > We believe the time has come for an open source implementation of openEHR > in action to take openEHR to the next level, around the world. > We wanted to share this news with the openEHR community to encourage you > and your colleagues to review all of our work and EtherCIS in particular. > We now invite you to review it, critique it, spread the word about it and > help us improve it. > > We hope this news is of interest and value to your own work. > EtherCIS has arrived.. > The time for openEHR is now... > > Kind Regards > > Tony > > Dr. Tony Shannon > Director, Ripple Foundation ripple.foundation > tony.shannon@ripple.foundation > > > ___ > openEHR-clinical mailing list > o
