MEDINFO presentations.

[Shinji KOBAYASHI]

Hi folks,

I updated openEHR related presentations in MEDINFO2019 at Wikipage.
There are so many interesting topics.
https://openehr.atlassian.net/wiki/spaces/resources/pages/320634886/MEDINFO2019?atlOrigin=eyJpIjoiOTdkY2U2ZGQwYjAzNDY0OThkMDYyMmUxYmNjYzMzNDQiLCJwIjoiYyJ9

If you find something wrong on this topic, please feel free to fix by
yourself or let me know.
I am looking forward to meet you soon in Lyon, and have much
expectation for social events.

Best regards,
Shinji Kobayashi

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: MEDINFO 2019, Lyon, France.

[Shinji KOBAYASHI]

Hi everyone,

This is a reminder. I heard there would be no extension for submission
in this year. We have to urge to fix the proposal.
If you are interested in submission proposal to the next MEDINFO,
please let me know by e-mail or write to the wikipage bellow.

https://openehr.atlassian.net/wiki/spaces/resources/pages/320634886/MEDINFO2019

Best regards,
Shinji Kobayashi

2018年9月18日(火) 16:21 Heather Leslie :
>> Hi everyone,
>
>
>
> I've just been talking with Silje about our plans for Medinfo from the 
> clinical modelling program.
>
>
>
> We'd like to share our current thinking and ideas for some broader openEHR 
> engagement.
>
>
>
> 3 Panels:
>
> Clinical modelling panel – focus on community engagement, modelling activity 
> and patterns
> Technical/developers panel – focus on the technical and software aspects of 
> openEHR, AQL, GDL perhaps
> Implementers panel – focus on the platform and experience from real-life 
> implementations
>
> There’s almost a tradition now that we’ve held a Clinical modelling and 
> Technical workshop at each Medinfo, but Medinfo’s working definition of a 
> workshop is that the presenters and the audience are meant to be equals and 
> there is a lot of audience participation. While we aspire to this, in reality 
> we really have experts presenting on their latest ideas/work and the audience 
> has variable opportunities to ask questions, which more fits with Medinfo’s 
> definition of a panel. So we are suggesting that we could run a suite of 
> complementary panels covering these 3 areas of openEHR activity.
> @Shinji – I know you have already suggested the developer’s workshop – what 
> do you think of this as an alternative?
>
> Panel exploring how openEHR, FHIR & SNOMED work together – a cross SDO panel!
> Clinical modelling tutorial – teaching participants how easy it is to learn 
> to build a template in half a day
> Possible papers
>
> Medication family of archetypes – Ian, Hildi & Silje
> Physical exam patterns – myself
>
>
>
> What do you think about these options?
>
>
>
> Who else has ideas or proposals?
>
>
>
> @Shinji has already set up a wiki page to help us coordinate our efforts - 
> https://openehr.atlassian.net/wiki/spaces/resources/pages/320634886/MEDINFO2019
>
>
>
> Cheers
>
>
>
> Heather
>
>
>
>
>
> -Original Message-
> From: openEHR-clinical  On Behalf 
> Of Shinji KOBAYASHI
> Sent: Monday, 20 August 2018 11:14 PM
> To: For openEHR clinical discussions ; 
> For openEHR technical discussions 
> Subject: MEDINFO 2019, Lyon, France.
>
>
>
> Dear openEHR colleagues,
>
>
>
> In the next year, MEDINFO 2019 will be in Lyon, France, from 26th to 30th 
> August, 2019.
>
> The application for paper/poster/workshop/tutorial deadline is Nov 12.
>
> This is important, ONLY less than TWO MONTH left for the deadline.
>
> I already launched wiki page for MEDINFO 2019.
>
> https://openehr.atlassian.net/wiki/spaces/resources/pages/320634886/MEDINFO2019
>
> If you have some plan for proposal related with openEHR, please give us 
> comments on the wiki or mail.
>
> I will propose the openEHR developers' workshop, again.
>
> AGAIN. Two month is not so long, rather short.
>
>
>
> Best regards,
>
> Shinji Kobayashi
>
>
>
> ___
>
> openEHR-clinical mailing list
>
> openehr-clini...@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: MEDINFO 2019, Lyon, France.

[Shinji KOBAYASHI]

Hi Heather,

Thank you for reminding.
Developers' workshop has been accepted from 2010. I agree to
reorganise the contents about openEHR, but I guess "developers
workshop' might be an insurance to pass reviews.

Regards,
Shinji Kobayashi
2018年9月18日(火) 16:21 Heather Leslie :
>
> Hi everyone,
>
>
>
> I've just been talking with Silje about our plans for Medinfo from the 
> clinical modelling program.
>
>
>
> We'd like to share our current thinking and ideas for some broader openEHR 
> engagement.
>
>
>
> 3 Panels:
>
> Clinical modelling panel – focus on community engagement, modelling activity 
> and patterns
> Technical/developers panel – focus on the technical and software aspects of 
> openEHR, AQL, GDL perhaps
> Implementers panel – focus on the platform and experience from real-life 
> implementations
>
> There’s almost a tradition now that we’ve held a Clinical modelling and 
> Technical workshop at each Medinfo, but Medinfo’s working definition of a 
> workshop is that the presenters and the audience are meant to be equals and 
> there is a lot of audience participation. While we aspire to this, in reality 
> we really have experts presenting on their latest ideas/work and the audience 
> has variable opportunities to ask questions, which more fits with Medinfo’s 
> definition of a panel. So we are suggesting that we could run a suite of 
> complementary panels covering these 3 areas of openEHR activity.
> @Shinji – I know you have already suggested the developer’s workshop – what 
> do you think of this as an alternative?
>
> Panel exploring how openEHR, FHIR & SNOMED work together – a cross SDO panel!
> Clinical modelling tutorial – teaching participants how easy it is to learn 
> to build a template in half a day
> Possible papers
>
> Medication family of archetypes – Ian, Hildi & Silje
> Physical exam patterns – myself
>
>
>
> What do you think about these options?
>
>
>
> Who else has ideas or proposals?
>
>
>
> @Shinji has already set up a wiki page to help us coordinate our efforts - 
> https://openehr.atlassian.net/wiki/spaces/resources/pages/320634886/MEDINFO2019
>
>
>
> Cheers
>
>
>
> Heather
>
>
>
>
>
> -Original Message-
> From: openEHR-clinical  On Behalf 
> Of Shinji KOBAYASHI
> Sent: Monday, 20 August 2018 11:14 PM
> To: For openEHR clinical discussions ; 
> For openEHR technical discussions 
> Subject: MEDINFO 2019, Lyon, France.
>
>
>
> Dear openEHR colleagues,
>
>
>
> In the next year, MEDINFO 2019 will be in Lyon, France, from 26th to 30th 
> August, 2019.
>
> The application for paper/poster/workshop/tutorial deadline is Nov 12.
>
> This is important, ONLY less than TWO MONTH left for the deadline.
>
> I already launched wiki page for MEDINFO 2019.
>
> https://openehr.atlassian.net/wiki/spaces/resources/pages/320634886/MEDINFO2019
>
> If you have some plan for proposal related with openEHR, please give us 
> comments on the wiki or mail.
>
> I will propose the openEHR developers' workshop, again.
>
> AGAIN. Two month is not so long, rather short.
>
>
>
> Best regards,
>
> Shinji Kobayashi
>
>
>
> ___
>
> openEHR-clinical mailing list
>
> openehr-clini...@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

MEDINFO 2019, Lyon, France.

[Shinji KOBAYASHI]

Dear openEHR colleagues,

In the next year, MEDINFO 2019 will be in Lyon, France, from 26th to
30th August, 2019.
The application for paper/poster/workshop/tutorial deadline is Nov 12.
This is important, ONLY less than TWO MONTH left for the deadline.
I already launched wiki page for MEDINFO 2019.
https://openehr.atlassian.net/wiki/spaces/resources/pages/320634886/MEDINFO2019
If you have some plan for proposal related with openEHR, please give
us comments on the wiki or mail.
I will propose the openEHR developers' workshop, again.
AGAIN. Two month is not so long, rather short.

Best regards,
Shinji Kobayashi

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: The openEHR Asia summit succeeded.

[Shinji KOBAYASHI]

All the presentation will be shared in these days.
Thank you Diego for pointing the livestreaming.

best wishes,
Shinji Kobayashi

2018-07-30 21:17 GMT+09:00 Diego Boscá :

> Conferences were transmitted in real time, they are available at the
> openEHR JP youtube channel
> https://www.youtube.com/channel/UCTIV2k0OhooiuvRgPSqY-iw
>
> 2018-07-30 14:10 GMT+02:00 Ian McNicoll :
>
>> Many congratuations Shinji,
>>
>> The screenshots looked intruiging. Would it be possible to link the
>> presentations, pictures and any videos from the openEHR website? We cna add
>> to the Events section as we did in the past for other events.
>>
>> 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, 30 Jul 2018 at 12:58, Shinji KOBAYASHI  wrote:
>>
>>> Dear openEHR colleagues,
>>>
>>> We completed all the schedule for the first openEHR Asia summit, and
>>> the second general assembly of Japan.
>>> We also celebrated the new board member, Xudong Lu with many kampais.
>>> Congratulations.
>>> In Asia, openEHR activities are supported with ground roots, and
>>> growing steadily.
>>> Dr Ryan Bannez showed his beautiful EMR system based on Marand
>>> EhrScape in Philippines, and 40 clinics adopted that.
>>> Prof Xudong Lu showed 5 big projects plan in China.
>>> I presented openEHR Japan activity and nation-wide EHR project in
>>> Japan, that involving 75 hospitals.
>>> The next openEHR Asia summit will be in China in the next year.
>>>
>>> Best regards,
>>> Shinji Kobayashi
>>>
>>> ___
>>> openEHR-clinical mailing list
>>> openehr-clini...@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_
>>> lists.openehr.org
>>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 654604676 <+34%20654604676>
> www.veratech.es
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es.
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

The openEHR Asia summit succeeded.

[Shinji KOBAYASHI]

Dear openEHR colleagues,

We completed all the schedule for the first openEHR Asia summit, and
the second general assembly of Japan.
We also celebrated the new board member, Xudong Lu with many kampais.
Congratulations.
In Asia, openEHR activities are supported with ground roots, and
growing steadily.
Dr Ryan Bannez showed his beautiful EMR system based on Marand
EhrScape in Philippines, and 40 clinics adopted that.
Prof Xudong Lu showed 5 big projects plan in China.
I presented openEHR Japan activity and nation-wide EHR project in
Japan, that involving 75 hospitals.
The next openEHR Asia summit will be in China in the next year.

Best regards,
Shinji Kobayashi

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

The first openEHR Asia Summit will be broadcast

[Shinji KOBAYASHI]

Dear openEHR members,

We will broadcast our openEHR Asia summit via our youtube channel from
10:00(JST), on the 28th July, 2018.
We also welcome your comments via youtube.

https://www.youtube.com/watch?v=DSyOlTp8pwY
Programme:
10:00-10:15 Overview of openEHR movement and its localisation
programme, Shinji Kobayashi(Japan), English session
10:15-10:45 openEHR Activity in Philippines, Ryan Banez(Philippines),
English session
10:45-11:15 openEHR Activity in China, Xudong Lu(China), English session
11:15-11:45 openEHR Activity in Japan, Shinji Kobayashi(Japan), English session
11:45-12:00 General discussion, English session

Best regards,
Shinji Kobayashi

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR Education Program

[Shinji KOBAYASHI]

Very good time to announce.
We will be broadcasting openEHR tutorial(in Japanese) via our youtube
channel from 10:00(JST) on 27th, July 2018.
https://www.youtube.com/channel/UCTIV2k0OhooiuvRgPSqY-iw
If you are interested in Japanese openEHR tutorial, please watch it.

Best regards,
Shinji Kobayashi

2018-07-25 17:59 GMT+09:00 Ian McNicoll :

> Hi all,
>
> We all recognise the importance of education in this area but it has
> proven difficult to find the right balance that allows an Educational
> program to get off the ground, in a way that supports the small number of
> existing providers, without over-burdening either the Foundation or those
> providers. Evelyn and Pablo did some important groundwork a couple of years
> ago but we felt that a simpler bootstrap process is required at this stage.
>
> A small group of current education providers led by Heather Leslie, Hildi
> McNicoll, Pablo Pazos and with Board representation from Koray Atalag are
> putting the final touches on a proposal which should allow the Foundation
> to start endorsing Education providers, who in turn can certify their
> courses. The Mgt Board is looking at this proposal and although it might
> need some small tweaks, we think this will be the best approach. We expect
> to be able to share this more widely in the next few weeks once the new Mgt
> Board has convened.
>
> Please note that this first tranche of work is all about the endorsement
> of Providers, and wholly focussed on 'vocational training', and not on
> higher education. We are keen to start to pull together shared educational
> material but we need to get these first steps in place.
>
> 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 Tue, 24 Jul 2018 at 12:37, David Moner  wrote:
>
>> [Although this is a transversal topic to openEHR, I send it to the
>> technical list, as it is the most active]
>>
>> Hello,
>>
>> Some time ago (I think it was in 2015), there was some movement towards
>> formalizing an Education Program about openEHR. I thing Evelyn Hovenga
>> and Pablo Pazos were involved.
>> There have not been news about this, so I'm curious if it is still
>> active. If not, I think it is more important than ever, and we should
>> retake it.
>>
>> In the past I was responsible of (trying to) develop a similar program
>> inside the EN 13606 Association, so I'm happy to share the strategies we
>> had there, and to participate in developing an openEHR education and
>> certification plan.
>>
>> Best regards,
>> David
>>
>>
>> --
>> David Moner Cano
>>
>> Web: http://www.linkedin.com/in/davidmoner
>> Twitter: @davidmoner
>> Skype: davidmoner
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re:

[Shinji KOBAYASHI]

Congratulations!
Opereffa, Seref once released, actually motivated to implement EHR.
I appreciate his achievements and do think worth to get PhD.

Regards,
Shinji Kobayashi

2017-10-27 20:27 GMT+09:00 Ingram, David :
> An implementation focused evaluation of openEHR and its integration with
> Bayesian Belief Networks for clinical decision support
>
> One of my most persistent PhD students, Seref Arikan, has published his
> ground-breaking PhD thesis on the UCL online repository.
>
> A fuller announcement and link has been posted in the News Section of the
> openEHR web site at:
>
> http://openehr.org/news_events/community_news
>
> We hope it will make a useful contribution to the ongoing international
> advances in openEHR methodology.
>
> David Ingram
>
> Emeritus Professor of Health Informatics at UCL
>
> President and Chairman of the Board of Governors of the openEHR Foundation
>
> Trustee of the OpenEyes Foundation Charity
>
> Academic Board Member, the Planetearth Institute
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR developers' workshop at medinfo2017, Xiamen China

[Shinji KOBAYASHI]

Dear Xudon,

Could you add something about your presentation here?
https://openehr.atlassian.net/wiki/display/resources/MEDINFO+2017%2C+Xiamen%2C+China
https://openehr.atlassian.net/wiki/display/resources/The+openEHR+Developers%27+workshop+2017

It is nice to hear that you can join us.
I will ask Korean developers, too.

Regards,
Shinji Kobayashi



2016-12-21 23:36 GMT+09:00 XUDONG LU :
> Dear Shinji,
>
> Sorry for late reply. I’m very happy to join in the workshop, and can 
> contribute a presentation on our implementation of openEHR based on 
> relational databases.
>
> Since Medinfo2017 will be held in my home country, I’d like to host or 
> co-host a wonderful social events. Hope to meet you in Xiamen
>
> Best Regards
> Xudong
>
> 在 16/12/13 下午9:29，“Shinji 
> KOBAYASHI” sk...@moss.gr.jp> 写入:
>
> Dear openEHR developers,
>
> We are planing a workshop at the next MEDINFO2017, Xiamen China.
> Would you like to join this workshop?
> 
> https://openehr.atlassian.net/wiki/display/resources/The+openEHR+Developers%27+workshop+2017
>
> If you are interested in this workshop. please feel free to contact me.
> The deadline, Nov 5 is closing and we have to finish until the.
> In addition, we are planning wonderful social events, too.
>
> Regards,
> Shinji Kobayashi
>
>
>
>
> ___
> openEHR-implementers mailing list
> openehr-implement...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

openEHR developers' workshop at medinfo2017, Xiamen China

[Shinji KOBAYASHI]

Dear openEHR developers,

We are planing a workshop at the next MEDINFO2017, Xiamen China.
Would you like to join this workshop?
https://openehr.atlassian.net/wiki/display/resources/The+openEHR+Developers%27+workshop+2017

If you are interested in this workshop. please feel free to contact me.
The deadline, Nov 5 is closing and we have to finish until the.
In addition, we are planning wonderful social events, too.

Regards,
Shinji Kobayashi

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

MEDINFO 2017, Xiamen, China

[Shinji KOBAYASHI]

Dear openEHR mates,

I just started the wiki page for upcoming MEDINFO 2017, Xiamen, China.
https://openehr.atlassian.net/wiki/display/resources/MEDINFO+2017%2C+Xiamen%2C+China

If you are planning to submit / attend MEDINFO2017, please join our
activities.
We will make some events happen in MEDINFO as usual.

* Developers workshop
https://openehr.atlassian.net/wiki/display/resources/The+openEHR+Developers%27+workshop+2017

* Clinical modeling tutorial/workshop
* Social meeting(yes, PARTY)

We all welcome you in any ways.
Moreover, I am planning an additional meeting in Kyoto, Japan, so I
recommend you to transit in Japan on the way to Xiamen, China.

Best regards,
Shinji Kobayashi
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: More generic reference model

[Shinji KOBAYASHI]

Dear Grahame,

I modeled ICF to an archetype for my ice bucket challenge, but forgot to
publish on CKM.
Do you need this?

Shinji Kobayashi

2016-09-12 23:37 GMT+09:00 Grahame Grieve <
grah...@healthintersections.com.au>:

> FHIR terminology servers can (and mostly do) handle all of those
> terminologies, though I don't know if anyone has handled ICF in practice.
>
> And expansions can preserve is-a relationships if you want, though... life
> is complicated and the answer is not automatically 'yes'
>
> Grahame
>
>
> On Mon, Sep 12, 2016 at 6:32 PM, Thomas Beale 
> wrote:
>
>>
>> we also still need a standard approach for non-SNOMED CT terminologies,
>> such as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know of
>> progress on this issue?
>>
>> - thomas
>>
>> On 12/09/2016 07:32, Diego Boscá wrote:
>>
>>> sure thing, that's why we need standard expressions
>>>
>>> 2016-09-12 8:27 GMT+02:00 Bert Verhees :
>>>
>>>> Op 11-9-2016 om 20:32 schreef Diego Boscá:
>>>>
>>>>> In practical terms however, you can't
>>>>> always expect to have all the access that you want to a given external
>>>>> service. e.g. I was banned from W3C once for launching a
>>>>> transformation (more like 10k...) that depended on a online schema.
>>>>>
>>>>
>>>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
> -
> http://www.healthintersections.com.au / grah...@healthintersections.com.au
> / +61 411 867 065
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

A report of openEHR events in Japan

[Shinji KOBAYASHI]

Hi all,

We, openEHR Japan had two events in the last January.
I wrote  a report of the events of them, and please take a look at this.

http://openehr.jp/documents/8

We appreciate the participants and kind supports from Drs Hugh and
Heather Leslie from Australia, Dr Lu from China, localisation team,
management board, and all the openEHR coleagues.

Shinji KOBAYASHI

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype relational mapping - a practical openEHR persistence solution

[Shinji KOBAYASHI]

Hi Ian and all,

We, openEHR Japan had an unconference with Dr Lu and he gave us a
presentation for us about this research.
I will ask him if the slides would be shareble.

Shinji KOBAYASHI

2016-01-25 22:04 GMT+09:00 Ian McNicoll :

> Interesting paper from China
>
>
> http://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-015-0212-0
>
> 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
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Nation wide EHR project by openEHR/ISO13606 got fund in Japan.

[Shinji KOBAYASHI]

Dear all,

Thank you for kind and encouraging messages.
The answers to the questions are bellow

Q: Is it by Ruby on Rails.
A: No, it is pity. The EHR will be built on Hadoop/Hbase.

Q: Is there any article in English?
A: No, I am sorry but there is not even Japanese article in detail, yet. In
this October, JMNA will release a statement about this, and I will
translate it to English.

Q: Which model was adopted, openEHR, ISO 13606?
A: The EHR will accepts various types of messages, such as HL7 v2,
MML(Medical Markup Language), CDA, or even CSV. The message will be stored
in openEHR or ISO13606 based archetypes, but about 40% of them are
specialised for Japan. That was the most difficult part for me, which
archetype should be specialised. ISO branding was so effective to convince
our government.

Q: Is'nt it too small budget for "Nation wide" EHR for Japan?
A: Yes. absolutely. This budget was assigned for the first preliminary
implementation to transform our legacy EHR to openEHR/ISO 13606 based EHR.
We could save money,because we already had a development base and
infrastructure of EHR. We have a plan to expand this EHR to nation wide in
these years, but nobody knows how much budget would be assigned in the next
year and later.

Thanks again for all. It would be our pleasure that this information would
encourage you. I wish all of your success on this openEHR road.
We will talk about more on this in the next year, 'The openEHR unconference'
https://openehr.doorkeeper.jp/events/32830

Kind regards,
Shinji KOBAYASHI

2015-10-09 16:17 GMT+09:00 Vebjørn Arntzen :

> Happy waves have arrived Norway, congratulations Shinji !!
>
> I'm joining Hugh here, please tell us more, or send us a link to a
> description of the nationwide EHR project, if there is any available in
> English.
>
>
>
> Surfing the waves
>
> Vebjørn
>
>
>
> *Fra:* openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org]
> *På vegne av* Hugh Leslie
> *Sendt:* 8. oktober 2015 23:05
> *Til:* openehr-implement...@lists.openehr.org;
> openehr-clini...@lists.openehr.org; openehr-technical@lists.openehr.org;
> openehr-implement...@lists.openehr.org
> *Emne:* Re: Nation wide EHR project by openEHR/ISO13606 got fund in Japan.
>
>
>
> Hi Shinji,
>
> Congratulations I think .
>
> I would like to understand more about this project. 5 million USD is a
> very small budget for a national EHR.  Is this just for the modelling?
>
> What is the purpose of the EHR?
>
> Regards Hugh
>
> Sent by Outlook <http://taps.io/outlookmobile> for Android
>
>
>
> On Thu, Oct 8, 2015 at 5:20 AM -0700, "Shinji KOBAYASHI" 
> wrote:
>
> Dear openEHR colleagues,
>
> We are happy to announce that Japan Medical Network Association(JMNA) was
> designated to implement nation wide EHR with openEHR/ISO 13606 information
> models in competitive bid by Japan agency for medical research and
> development.
>
> To the next March, JMNA will implement EHR system with vendors in Japan by
> this budget, about 5 million USD.
> We, openEHR Japan, will contribute to make models for this EHR project.
>
> I wish this achievement would make happy waves to your countries.
>
> Best Regards,
>
> Shinji KOBAYASHI
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Nation wide EHR project by openEHR/ISO13606 got fund in Japan.

[Shinji KOBAYASHI]

Dear openEHR colleagues,

We are happy to announce that Japan Medical Network Association(JMNA) was
designated to implement nation wide EHR with openEHR/ISO 13606 information
models in competitive bid by Japan agency for medical research and
development.
To the next March, JMNA will implement EHR system with vendors in Japan by
this budget, about 5 million USD.
We, openEHR Japan, will contribute to make models for this EHR project.
I wish this achievement would make happy waves to your countries.

Best Regards,
Shinji KOBAYASHI
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: MEDINFO program

[Shinji KOBAYASHI]

Dear Osama,

To publish the content of MEDINFO tutorial would need permission from
MEDINFO.

Shinji

2015-08-10 19:15 GMT+09:00 Osama Elhassan SeedAhmed Elhassan <
oeelhas...@dha.gov.ae>:

> Dear Shinji,
>
>
>
> Is it possible to record the lectures and upload them on the openEHR
> website?
>
>
>
> Best regards,
>
>
>
> Osama
>
>
>
> *From:* openEHR-technical [mailto:
> openehr-technical-boun...@lists.openehr.org] *On Behalf Of *Shinji
> KOBAYASHI
> *Sent:* Monday, August 10, 2015 2:12 PM
> *To:* For openEHR technical discussions
> *Cc:* For openEHR implementation discussions; For openEHR clinical
> discussions
> *Subject:* Re: MEDINFO program
>
>
>
> Dear Osama,
>
> I am sorry, there are no alternative for the all presentation of openEHR
> in MEDINFO.
>
> I think we have to prepare alternative education chances for all over the
> world. There are some education materials on the openEHR web site.
> http://openehr.org/resources/learning_centre
> I have not heard openEHR movement or meeting in the Middle East, but I am
> trying to propagate the openEHR movement in Japan and the East Asia. I wish
> my movement will wave to the whole Asia.
>
> Anyway, education programme is an emerging topic for us, we will talk
> about at this MEDINFO.
>
>
> --
>
> Shinji KOBAYASHI
>
> The openEHR Japan representative, co-chair of localisation team.
>
>
>
> 2015-08-10 15:42 GMT+09:00 Osama Elhassan SeedAhmed Elhassan <
> oeelhas...@dha.gov.ae>:
>
> Dear Shinji,
>
>
>
> Is there any alternative for those who cannot make it to MEDINFO to
> benefit from the OpenEHR tutorial?
>
>
>
> Best regards,
>
>
>
> Osama
>
>
>
> *From:* openEHR-technical [mailto:
> openehr-technical-boun...@lists.openehr.org] *On Behalf Of *Shinji
> KOBAYASHI
> *Sent:* Monday, August 10, 2015 10:40 AM
> *To:* For openEHR clinical discussions; For openEHR technical
> discussions; For openEHR implementation discussions
> *Subject:* MEDINFO program
>
>
>
> Hello all,
>
> I re-ordered the presentations by time schedule in MEDINFO2015 in Sao
> Paolo, Brasil.
>
> https://openehr.atlassian.net/wiki/display/resources/MEDINFO+2015+-+Sao+Paulo%2C+Brazil
>
> Please have a glance when you make your schedule in MEDINFO.
>
> Regards,
>
> Shinji KOBAYASHI
> Vision
>
> A Healthy Happy and Safe Community
>
> مجتمع صحي آمن وسعيد
> الرؤية Mission
>
> Develop an integrated and sustainable healthcare system that ensures the
> delivery of comprehensive and excellent services to achieve the highest
> international levels of healthcare for individuals and society
>
> تطوير منظومة صحية متكاملة ومستدامة تضمن الشمولية والتميز لتحقيق أعلى
> المعايير العالمية لصحة الفرد والمجتمع
> الرسالة This transmittal is confidential. If you have received this
> transmittal in error, please notify us immediately by reply and immediately
> delete this message. DHA do not accept liability for any errors, omissions,
> information or viruses contained in the transmission of this message.
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> Vision A Healthy Happy and Safe Community مجتمع صحي آمن وسعيد الرؤية
> Mission Develop an integrated and sustainable healthcare system that
> ensures the delivery of comprehensive and excellent services to achieve the
> highest international levels of healthcare for individuals and society تطوير
> منظومة صحية متكاملة ومستدامة تضمن الشمولية والتميز لتحقيق أعلى المعايير
> العالمية لصحة الفرد والمجتمع الرسالة This transmittal is confidential. If
> you have received this transmittal in error, please notify us immediately
> by reply and immediately delete this message. DHA do not accept liability
> for any errors, omissions, information or viruses contained in the
> transmission of this message.
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: MEDINFO program

[Shinji KOBAYASHI]

Dear Osama,

I am sorry, there are no alternative for the all presentation of openEHR in
MEDINFO.
I think we have to prepare alternative education chances for all over the
world. There are some education materials on the openEHR web site.
http://openehr.org/resources/learning_centre
I have not heard openEHR movement or meeting in the Middle East, but I am
trying to propagate the openEHR movement in Japan and the East Asia. I wish
my movement will wave to the whole Asia.
Anyway, education programme is an emerging topic for us, we will talk about
at this MEDINFO.

--
Shinji KOBAYASHI
The openEHR Japan representative, co-chair of localisation team.

2015-08-10 15:42 GMT+09:00 Osama Elhassan SeedAhmed Elhassan <
oeelhas...@dha.gov.ae>:

> Dear Shinji,
>
>
>
> Is there any alternative for those who cannot make it to MEDINFO to
> benefit from the OpenEHR tutorial?
>
>
>
> Best regards,
>
>
>
> Osama
>
>
>
> *From:* openEHR-technical [mailto:
> openehr-technical-boun...@lists.openehr.org] *On Behalf Of *Shinji
> KOBAYASHI
> *Sent:* Monday, August 10, 2015 10:40 AM
> *To:* For openEHR clinical discussions; For openEHR technical
> discussions; For openEHR implementation discussions
> *Subject:* MEDINFO program
>
>
>
> Hello all,
>
> I re-ordered the presentations by time schedule in MEDINFO2015 in Sao
> Paolo, Brasil.
>
> https://openehr.atlassian.net/wiki/display/resources/MEDINFO+2015+-+Sao+Paulo%2C+Brazil
>
> Please have a glance when you make your schedule in MEDINFO.
>
> Regards,
>
> Shinji KOBAYASHI
> Vision A Healthy Happy and Safe Community مجتمع صحي آمن وسعيد الرؤية
> Mission Develop an integrated and sustainable healthcare system that
> ensures the delivery of comprehensive and excellent services to achieve the
> highest international levels of healthcare for individuals and society تطوير
> منظومة صحية متكاملة ومستدامة تضمن الشمولية والتميز لتحقيق أعلى المعايير
> العالمية لصحة الفرد والمجتمع الرسالة This transmittal is confidential. If
> you have received this transmittal in error, please notify us immediately
> by reply and immediately delete this message. DHA do not accept liability
> for any errors, omissions, information or viruses contained in the
> transmission of this message.
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

MEDINFO program

[Shinji KOBAYASHI]

Hello all,

I re-ordered the presentations by time schedule in MEDINFO2015 in Sao
Paolo, Brasil.
https://openehr.atlassian.net/wiki/display/resources/MEDINFO+2015+-+Sao+Paulo%2C+Brazil

Please have a glance when you make your schedule in MEDINFO.

Regards,
Shinji KOBAYASHI
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Video aulas iniciais

[Shinji KOBAYASHI]

Dear Douglas,

This is a lecture from Prof Dipak Kalra and Prof Stan Huff.
http://ocw.kyoto-u.ac.jp/en/international-conference-en/ehr

I wish this would help you.

Shinji KOBAYASHI

2015-07-21 3:40 GMT+09:00 Douglas Fabiano :

> Hi friends.
>
> Where can I video lessons basic for OpenEHR online?
>
> Thanks!
>
> --
>
> |
> Douglas Lourenço
> E-mail: [ douglas...@gmail.com ]
> |*
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR @ StackExchange - getting close

[Shinji KOBAYASHI]

I sent support request to openehr-jp mailing list.

Shinji

2015-06-11 7:56 GMT+09:00 Thomas Beale :
>
> We are getting closer to the next step. We have 76 followers.
>
> We still need 17 questions with 10 votes. We have the requisite number of
> questions, it's just a case of people using their votes on them (don't worry
> if they don't really interest you, they are example questions - to get a
> stackexchange site, the community has to demonstrate interest).
>
> Many of the questions with < 10 votes do have some votes, so we probably
> need a total of about 120 up-votes to get through this stage. I think each
> user gets 5 votes, so that's equivalent to 24 users.
>
> Remember, there is no value in up-voting a question that already has 10 or
> more votes.
>
> - thomas
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Question on Stack Overflow re openEHR Persistence using RoR Active Record

[Shinji KOBAYASHI]

Hi Ian,

i added a comment. It needs tricky codes to implement COMPOSITE patten
with ActiveRecord and RDBMS.
The following example on GitHub is an extract of my project.
https://github.com/skoba/openehr_rm_rails

I will feedback recent experience to openehr-rails repository, until
the next medinfo.

Shinji KOBAYASHI

2015-01-20 8:17 GMT+09:00 Ian McNicoll :
> Rails Multi Table Inheritance, Polymorphic association or Single Table
> Inheritance?
>
> "I'm trying to implement the OpenEHR reference model in Rails
> (ActiveRecord), but I'm finding some problems, since it works with a
> lot of different of different classess, ..."
>
> http://stackoverflow.com/q/27909328/3973688?sem=2
>
> Anyone want to help?
>
> 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
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

CRUD Restlet

[Shinji KOBAYASHI]

Hi Bert,

Thank you for proposing an interesting discussion whether http
response status should be included to API result or not.
I found this similar discussion on stackoverflow.
http://stackoverflow.com/questions/942951/rest-api-error-return-good-practices

I think using response 404 code is simple and easy to implement API.
But I partially agree with you that 404 error is not preferred because
we have to distinguish "NO episode has been recorded" and "the record
shows no episode in his/her life" in EHR as you mentioned.
IMO the former should be 404 response and the latter should be 200
response with null flavor message.

Shinji KOBAYASHI

2015-01-19 20:38 GMT+09:00 Bert Verhees :
> On 19-01-15 11:31, Birger Haarbrandt wrote:
>
> The medrecord openEHR server is also based on REST and worth looking at.
> There was a lot to learn from for me as the API is pretty neat.
>
>
> I will check that too, thanks for the links
>
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

[openEHR-announce] Extension of nominations 31 Jan 2015 - and join up now.

[Shinji KOBAYASHI]

Thank you for gentle explanation, Ian.
It is not clear for me yet that where we are and why we got there, but
it seems quite obvious that we definitely need to go forward from
here, I guess.
To go forward, we have to organise a new board as an engine to drive
our project as soon as possible.
In short, we have to choose 2 individual representative from there
four nominees until Jan 31.

Shinji Kobayashi(me)
Silje Ljosland Bakke
Ian McNicoll
Diego Bosca Thomas

However, we do not know enough information to decide vote for each
candidates. Yes I know me and other candidates, but we have to address
our bio for decision makers like other elections.
Here is my bio.

Shinji KOBAYASHI, MD, PhD
A senior lecturer of the EHR research unit, Kyoto University in Japan.
I have trained as an clinical informatician and a clinical
hematology/oncologist in these 20 years.
* Achievement related with openEHR Projects:
 * Original papers
 KOBAYASHI S, TATSUKAWA A, Ruby implementation of openEHR
specifications. JACIII 16(1): 42-47 (2012)
 * Conferences
 The openEHR Developers' Workshop. MedInfo 2013
 Shinji Kobayashi, Eizen Kimura, Ken Ishihara: Creating Electronic
Health Records within 15 Minutes with Ruby on Rails And ISO
13606/OpenEHR Standardized Clinical Models. MedInfo 2013
 The openEHR Developers' Workshop. MedInfo 2010
* Activity related with openEHR.
 A lead of openEHR.jp(from 2007)
 The openEHR tutorial workshop in Manila(July 2013)
 More than twice a year we have made seminars around openEHR from 2008.
 A qualified member of openEHR localisation and web committee.
* What I would do if I elected.
 I will launch NPO to facilitate openEHR works in Japan this early
2015. My motivation is to propagate and utilise openEHR specification
like ground roots.

Please ask me any question around me. Moreover, could you let us know
a profile of each nominee?

Shinji KOBAYASHI


2015-01-08 22:15 GMT+09:00 Ian McNicoll :
> Hi Heather, Vebj?rn,
>
> The nominations are for election to the new Management Board. None of
> the existing Board members will be automatically appointed. The
> Management Board is the group which is intended to direct Foundation
> affairs in a practical sense and in that role, all of the current
> Interim Board members are effectively 'standing down'.
>
> My understanding is that all of the Interim Board members will remain
> as 'Company Members' ( the legal 'owners' in UK Company law) until
> after the election. The role of Company Members is largely nominal i.e
> somewhat like Trustees / Guarantors in a charity to provide general
> oversight.
>
> The current proposals envisage a small Company Membership but we know
> that there is some debate in the community about whether every
> Individual and Industry member should automatically also be a
> legal'Company Member'. UK not-for-profit law recognises both
> approaches as being valid in different circumstances. The Interim
> Board felt that this discussion still needs to be had but that it was
> more important to get the new Management Board up and running first,
> particularly as the election process should give that group a stronger
> mandate and hopefully introduce fresh perspectives.
>
> I would regard the Management Board as holding the key power and
> responsibility and that this is a new entity. If current Interim Board
> members want to participate they should nominate like anyone else.
>
> Current Interim Board members will carry on in the short term as the
> legal 'Company Members' until that broader constitutional question is
> resolved. This will be an important discussion but is almost wholly
> about how we feel that the aims and philosophy of the Foundation are
> best protected, and not about running the Foundation per-se.
>
> Ian
>
>
>
>
> Dr Ian McNicoll
> office +44 (0)1536 414 994
> fax +44 (0)1536 516317
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
>
> Clinical Modelling Consultant, Ocean Informatics, UK
> Director 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 8 January 2015 at 01:00, Heather Leslie
>  wrote:
>> Thanks Ian,
>>
>> I would be interested to know who is remaining and who is standing down. Is 
>> that information available?
>>
>> I suspect that others in the community might like it too. It may influence 
>> decisions to nominate, or not.
>>
>> Regards
>>
>> Heather
>>
>>> -Original Message-
>>> From: openEHR-technical [mailto:openehr-technical-
>>> bounces at lists.openehr.org] On Behalf Of Ian McNicoll
>>> Sent: Wedn

MedInfo 2015 openEHR tutorials

[Shinji KOBAYASHI]

Hi colleagues,

Can I finalize this developers' workshop proposal?
https://openehr.atlassian.net/wiki/pages/viewpage.action?pageId=4554784

Today is just before one week to the workshop deadline.

Shinji KOBAYASHI

2014-12-18 20:52 GMT+09:00 Shinji KOBAYASHI :
> Hi colleagues,
>
> I am preparing to submit openEHR developers' workshop in this openEHR wiki 
> page.
> https://openehr.atlassian.net/wiki/pages/viewpage.action?pageId=4554784
> If you got interested in participating this workshop, please add your
> name and brief summary(100-200 words) of your project on this wiki
> until Dec 31 2014. Anyone can join this workshop, if you have working
> on development around openEHR.
> Thank you for your concern about this workshop and contributing on
> wiki. I am looking forward to meeting you in Sao Paolo.
>
> Shinji KOBAYASHI
>
> 2014-10-30 17:21 GMT+09:00 Luis Marco :
>> Hi Pablo,
>> I will be in Medinfo therefore we can coordinate together the Spanish
>> language resources ;-)
>> Regards,
>> Luis
>>
>> 2014-10-29 17:14 GMT+01:00 pablo pazos :
>>>
>>> Hi Sam,
>>>
>>> I think right now the tutorial organization is happening in a very organic
>>> way: people are sharing they proposals so others can collaborate or detect
>>> possible overlaps.
>>>
>>> If we need a group to centralize coordination or communication with
>>> MedInfo organizers/chairs, I would propose the people interested no giving
>>> tutorials that is mentioned here:
>>> http://www.openehr.org/wiki/display/resources/MEDINFO+2015+-+Sao+Paulo%2C+Brazil
>>>
>>>
>>> On my part, I don't have resources to have an stand (flight + hotel +
>>> conference fee is not cheap for us), but if I can help in any way, e.g. the
>>> community can use me as an spanish speaker interlocutor, I'll be more than
>>> happy to help and add my grain of sand.
>>>
>>>
>>> About training, I'm doing a small survey to see what people think about
>>> the proposals already discussed on the lists. My goal is to curate that and
>>> to reach a new level of discussions beyond "ideas". I don't have Heather
>>> Grain's email, I'll gladly send her my little survey (Already sent to
>>> Heather L and Evelyn).
>>>
>>> Cheers,
>>> Pablo.
>>>
>>> --
>>> Kind regards,
>>> Eng. Pablo Pazos Guti?rrez
>>> http://cabolabs.com
>>>
>>> 
>>> From: sam.heard at openehrfoundation.org
>>> To: openehr-clinical at lists.openehr.org
>>> Subject: Re: MedInfo 2015 openEHR tutorials
>>> Date: Sun, 26 Oct 2014 04:50:10 +
>>> CC: openehr-technical at lists.openehr.org;
>>> openehr-implementers at lists.openehr.org
>>>
>>> Thanks Pablo
>>>
>>> Good feedback. It has been difficult to keep up with everything and I am
>>> in no way trying to impede any activity. I believe this is the first
>>> International Medinfo in a country where openEHR is up and running.
>>>
>>> My wish is to have a group that coordinate the effort. If you feel you
>>> have this in hand, lets make sure it is public and people know who to go to.
>>>
>>> Are there any plans to have an openEHR stand? This could enable a group of
>>> companies to promote what they are doing?
>>>
>>> Evelyn Hovenga and Heather Grain have been working with Heather Leslie
>>> regarding accrediting training?. have you talked to them? Do we need a group
>>> coordinating this?
>>>
>>> Cheers Sam
>>>
>>> Dr Sam Heard
>>> Chairman, openEHR Foundation
>>>
>>> From: pablo pazos
>>> Sent: ?Thursday?, ?23? ?October? ?2014 ?4?:?57? ?PM
>>>
>>> To: For openEHR clinical discussions
>>> Cc: For openEHR technical discussions, For openEHR implementation
>>> discussions
>>>
>>> Hi Sam,
>>>
>>> I think we are coordinating this already :) IMO that's the point of having
>>> the wiki pages and asking colleagues to add content, proposals and comments.
>>>
>>> I think the idea of a key note is great, and I want to collaborate in any
>>> way I can, but... as you an others may know, I asked several times for
>>> endorsement and support (not talking about money) from the foundation on the
>>> training side, to standardize the contents, to have a formal way of
>>> certification, and spread the standard, but the board w

MedInfo 2015 openEHR tutorials

[Shinji KOBAYASHI]

Hi colleagues,

I am preparing to submit openEHR developers' workshop in this openEHR wiki page.
https://openehr.atlassian.net/wiki/pages/viewpage.action?pageId=4554784
If you got interested in participating this workshop, please add your
name and brief summary(100-200 words) of your project on this wiki
until Dec 31 2014. Anyone can join this workshop, if you have working
on development around openEHR.
Thank you for your concern about this workshop and contributing on
wiki. I am looking forward to meeting you in Sao Paolo.

Shinji KOBAYASHI

2014-10-30 17:21 GMT+09:00 Luis Marco :
> Hi Pablo,
> I will be in Medinfo therefore we can coordinate together the Spanish
> language resources ;-)
> Regards,
> Luis
>
> 2014-10-29 17:14 GMT+01:00 pablo pazos :
>>
>> Hi Sam,
>>
>> I think right now the tutorial organization is happening in a very organic
>> way: people are sharing they proposals so others can collaborate or detect
>> possible overlaps.
>>
>> If we need a group to centralize coordination or communication with
>> MedInfo organizers/chairs, I would propose the people interested no giving
>> tutorials that is mentioned here:
>> http://www.openehr.org/wiki/display/resources/MEDINFO+2015+-+Sao+Paulo%2C+Brazil
>>
>>
>> On my part, I don't have resources to have an stand (flight + hotel +
>> conference fee is not cheap for us), but if I can help in any way, e.g. the
>> community can use me as an spanish speaker interlocutor, I'll be more than
>> happy to help and add my grain of sand.
>>
>>
>> About training, I'm doing a small survey to see what people think about
>> the proposals already discussed on the lists. My goal is to curate that and
>> to reach a new level of discussions beyond "ideas". I don't have Heather
>> Grain's email, I'll gladly send her my little survey (Already sent to
>> Heather L and Evelyn).
>>
>> Cheers,
>> Pablo.
>>
>> --
>> Kind regards,
>> Eng. Pablo Pazos Guti?rrez
>> http://cabolabs.com
>>
>> 
>> From: sam.heard at openehrfoundation.org
>> To: openehr-clinical at lists.openehr.org
>> Subject: Re: MedInfo 2015 openEHR tutorials
>> Date: Sun, 26 Oct 2014 04:50:10 +
>> CC: openehr-technical at lists.openehr.org;
>> openehr-implementers at lists.openehr.org
>>
>> Thanks Pablo
>>
>> Good feedback. It has been difficult to keep up with everything and I am
>> in no way trying to impede any activity. I believe this is the first
>> International Medinfo in a country where openEHR is up and running.
>>
>> My wish is to have a group that coordinate the effort. If you feel you
>> have this in hand, lets make sure it is public and people know who to go to.
>>
>> Are there any plans to have an openEHR stand? This could enable a group of
>> companies to promote what they are doing?
>>
>> Evelyn Hovenga and Heather Grain have been working with Heather Leslie
>> regarding accrediting training?. have you talked to them? Do we need a group
>> coordinating this?
>>
>> Cheers Sam
>>
>> Dr Sam Heard
>> Chairman, openEHR Foundation
>>
>> From: pablo pazos
>> Sent: ?Thursday?, ?23? ?October? ?2014 ?4?:?57? ?PM
>>
>> To: For openEHR clinical discussions
>> Cc: For openEHR technical discussions, For openEHR implementation
>> discussions
>>
>> Hi Sam,
>>
>> I think we are coordinating this already :) IMO that's the point of having
>> the wiki pages and asking colleagues to add content, proposals and comments.
>>
>> I think the idea of a key note is great, and I want to collaborate in any
>> way I can, but... as you an others may know, I asked several times for
>> endorsement and support (not talking about money) from the foundation on the
>> training side, to standardize the contents, to have a formal way of
>> certification, and spread the standard, but the board went silent. I'm very
>> pragmatic and I don't know why this is so difficult, for me this is treated
>> in a very political way and should be something technical.
>>
>> With that being said, for me, talking about training under the foundation
>> banner is at least weird.
>>
>> Maybe this is not a good place or time to mention this, but is how I
>> honestly feel about the proposal.
>>
>> I long to see the work I try to do to create awareness about the standard
>> to be supported by the foundation. To be honest, the only support I got is
>> from the Chilean Association of Healthcare Informatics (

MedInfo 2015 openEHR tutorials

[Shinji KOBAYASHI]

Hi,

What I should offense to is health threating entities/events. I
believe we have wisdom enough to fight against them.
And then, it would be more constructive that we think about what we
can do for healthcare and our community rather than what our community
do for us.
Having workshop and tutorials would be good contribution and make
something happen to outreach.

To Pablo and Latin Americans,
I always respect your contributions and am much interested in your
woks. I am looking forward to meeting you and sharing passion with us.

To Bert,
Thank you for proof-reading. English is too difficult for me,
Japanese. My understanding is openEHR specs are oriented to base of
the standards. Could you let me know the better phrase?

Regards,
Shinji KOBAYASHI


2014-10-25 8:51 GMT+09:00 Bert Verhees :
> In Europe, politicians are afraid to make errors, they are not able to judge
> if a specification has a high quality. So they go for standards. This is in
> many countries like this.
>
> That is why HL7 always try to standardize their efforts, and the higher the
> better. In Europe you go first to your national body, then to the European
> body, then to ISO.
>
> Alternatives with a little bit less status are Oasis, W3, OMG, and also from
> there you can go to ISO.
>
> I have never heard that OpenEhr tried to become a standard. In these ten
> years, they never did, or they did it in silence, or I just missed it, was
> on holiday when the announcement was done.
>
> But if I am right, then is that a reason why it will never become important
> on government-level in the Netherlands. And in many other countries this is
> the same.
>
> No politician in the Netherlands wil ever invest millions in a specification
> which did not made it to ISO. That is why the Netherlands invested 500
> millions Euro in a HL7v3 standard. Because it is an ISO standard, or it was
> in the traject to become one. Really, 500 millions Euro, half a billion
> Euro. Just for a message system for the Netherlands, based on HL7v3. And the
> laugh, it failed.
>
> But that doesn't matter, the politicians are safe, they favored ISO
> standards. The companies are safe, they got their money, got well paid, and
> did what they were asked for. No one ever got fired for choosing an ISO
> standard.
>
> Why did it fail? Ten years they had spent 50 million Euro, every year. It is
> a long story, but I can summarize it in a few words. I think they did not
> want to succeed. They failed for political reasons, they did not want to do
> concessions with the majority in parliament. So the parliament blew it off.
> They had chosen to fail.
>
> It would be good for the OpenEhr developing companies if a OpenEhr did more
> to be acceptable for governments.
>
> Bert
>
>
>
>
> Op vrijdag 24 oktober 2014 heeft Dra Carola Hullin Lucay Cossio
>  het volgende geschreven:
>
>> Dear All,
>>
>> Please take this observation as a help DISCUSSION rather a critic: but the
>> standards difinition is not an awareness issues, instead is a GAP between
>> contexts.
>> In Latino America and Caribe, there is minimal understanding of what a
>> standard isas displayed on Pablo?s answer, so the real use of openEHR
>> never is achieved because of this gap.
>>
>> I was last week in INFOLAC2014 ,where the goverment of Uruguay and several
>> local authorities discussed about standards but the issue was a different
>> one. So, I believe that OpenEHR as foundation and its initial team of
>> founders of this conceptual and technical framework should lead the training
>> contents and validity that developing countries are using.
>>
>> I was surprise that Uruguay invested 4 million dollars and the concept of
>> openEHR was missing: lost of investment again.
>>
>> http://www.agesic.gub.uy/innovaportal/file/1443/1/agesic_agendadigital_2011_2015.pdf
>>
>>
>> Hope this contextual information help to get a good quality training
>> package from the foundation so then it can be shared around the world.
>>
>> Cheers Carol
>> (LATAM)
>>
>>
>>
>> 
>> From: pazospablo at hotmail.com
>> To: bert.verhees at rosa.nl; openehr-technical at lists.openehr.org
>> Subject: Re: MedInfo 2015 openEHR tutorials
>> Date: Fri, 24 Oct 2014 19:23:40 +
>>
>> Bert, I'm aware of the definition and I use terms in a very specific way,
>> I said standard because  that definition fits what openEHR is.
>>
>>
>> Anyway, we are not discussing definitions but a much broader subject: the
>> board being silent in front on community efforts that need them.
>>
>>
>> Pablo Pazos
>>
>>

MedInfo 2015 openEHR tutorials

[Shinji KOBAYASHI]

Hi Pablo, and all

Thank you for cooperation. I am working on the developers' workshop
proposal based on the last proposal to MEDINFO2013. Please modify and
add your description for your project.
The Spanish tutorial sounds muy bien.

Shinji


2014-10-21 23:06 GMT+09:00 pablo pazos :
> Hi!
>
> I was about to send a message to the lists to coordinate the tutorials
> topics to minimize overlap.
>
> Thanks for creating the page Shinji! That will help a lot for doing that
> coordination.
>
> I'll add a list of topics and anyone can mark his/her preference for giving
> a tutorial about it, so we can detect collisions.
>
>
> For the spanish speakers, the MedInfo organization wants to have some
> tutorials in spanish to encourage the LatAm community to participate in the
> conference. Also until december they have a preferential price for LatAm
> colleagues (still pricey but it's MedInfo :).
>
>
> Cheers,
> Pablo.
>
>
> --
> Kind regards,
> Eng. Pablo Pazos Guti?rrez
> http://cabolabs.com
>
>> From: skoba at moss.gr.jp
>> Date: Tue, 21 Oct 2014 22:56:46 +0900
>> Subject: Re: MedInfo 2015 openEHR tutorials
>> To: openehr-technical at lists.openehr.org
>> CC: openehr-implementers at lists.openehr.org;
>> openehr-clinical at lists.openehr.org
>
>>
>> Dear colleagues,
>>
>> I updated Wiki description about MEDINFO 2015 and made the developers'
>> workshop 2015 page.
>> http://www.openehr.org/wiki/display/resources/MEDINFO+2015
>>
>> Could you all please take a look and add comments or describe your plan?
>>
>>
>> Shinji KOBAYASHI
>>
>> 2014-08-05 10:22 GMT+09:00 pablo pazos :
>> > Of course! I should have think of Jussara before. I'll talk with her and
>> > her
>> > fellow openEHR.br colleagues to see if we can get this organized.
>> >
>> > BTW, just to start the coordination I would like to do a workshop
>> > focused on
>> > openEHR data store and query. And if there's interest, another one
>> > focused
>> > on UI: generation, manipulation, processing, models, etc. (we're
>> > presenting
>> > a paper on this topic at the InfoLac congress, this year is in Uruguay!
>> > lucky me: http://infolac2014.org/index.php/en/)
>> >
>> > --
>> > Kind regards,
>> > Eng. Pablo Pazos Guti?rrez
>> > http://cabolabs.com
>> >
>> > 
>> > From: sam.heard at oceaninformatics.com
>> > To: openehr-clinical at lists.openehr.org;
>> > openehr-technical at lists.openehr.org
>> > Subject: Re: MedInfo 2015 openEHR tutorials
>> > Date: Mon, 4 Aug 2014 08:30:32 +
>> > CC: openehr-implementers at lists.openehr.org
>> >
>> >
>> > Hi Pablo
>> >
>> > I wonder if Jusara could organise a submeeting in an academic/industry
>> > forum
>> > prior to MedInfo?
>> >
>> > Cheers Sam
>> >
>> > Sent from Windows Mail
>> >
>> > From: pablo pazos
>> > Sent: ?Saturday?, ?2? ?August? ?2014 ?9?:?06? ?AM
>> > To: For openEHR clinical discussions, For openEHR technical discussions
>> > Cc: For openEHR implementation discussions
>> >
>> > Thanks for the info Heather!
>> >
>> > I think we should do something similar to the previous workshops for
>> > devs,
>> > something simple to get newcomers to understand how to work with
>> > archetypes
>> > in software (parsing, processing, validating data, extracting paths,
>> > etc),
>> > and more specific topics for skilled openEHR devs (persistence options,
>> > REST
>> > APIs, querying, reporting, UI generation, ...).
>> >
>> > I would love to see a hands-on tutorial in which we can program live and
>> > help newcomers to pass the first barrier in openEHR software
>> > development:
>> > lose the fear of archetypes.
>> >
>> > Also I would like to know how we want to present this, should we submit
>> > the
>> > proposals individualy and then organize or should we coordinate and make
>> > one
>> > proposal with all the workshops/tutorials?
>> >
>> > Thanks!
>> >
>> > --
>> > Kind regards,
>> > Eng. Pablo Pazos Guti?rrez
>> > http://cabolabs.com
>> >
>> > 
>> > From: heather.leslie at oceaninformatics.com
>> > To: openehr-technical at lists.openehr.org;
>> > opene

MedInfo 2015 openEHR tutorials

[Shinji KOBAYASHI]

Dear colleagues,

I updated Wiki description about MEDINFO 2015 and made the developers'
workshop 2015 page.
http://www.openehr.org/wiki/display/resources/MEDINFO+2015

Could you all please take a look and add comments or describe your plan?


Shinji KOBAYASHI

2014-08-05 10:22 GMT+09:00 pablo pazos :
> Of course! I should have think of Jussara before. I'll talk with her and her
> fellow openEHR.br colleagues to see if we can get this organized.
>
> BTW, just to start the coordination I would like to do a workshop focused on
> openEHR data store and query. And if there's interest, another one focused
> on UI: generation, manipulation, processing, models, etc. (we're presenting
> a paper on this topic at the InfoLac congress, this year is in Uruguay!
> lucky me: http://infolac2014.org/index.php/en/)
>
> --
> Kind regards,
> Eng. Pablo Pazos Guti?rrez
> http://cabolabs.com
>
> 
> From: sam.heard at oceaninformatics.com
> To: openehr-clinical at lists.openehr.org; openehr-technical at 
> lists.openehr.org
> Subject: Re: MedInfo 2015 openEHR tutorials
> Date: Mon, 4 Aug 2014 08:30:32 +
> CC: openehr-implementers at lists.openehr.org
>
>
> Hi Pablo
>
> I wonder if Jusara could organise a submeeting in an academic/industry forum
> prior to MedInfo?
>
> Cheers Sam
>
> Sent from Windows Mail
>
> From: pablo pazos
> Sent: ?Saturday?, ?2? ?August? ?2014 ?9?:?06? ?AM
> To: For openEHR clinical discussions, For openEHR technical discussions
> Cc: For openEHR implementation discussions
>
> Thanks for the info Heather!
>
> I think we should do something similar to the previous workshops for devs,
> something simple to get newcomers to understand how to work with archetypes
> in software (parsing, processing, validating data, extracting paths, etc),
> and more specific topics for skilled openEHR devs (persistence options, REST
> APIs, querying, reporting, UI generation, ...).
>
> I would love to see a hands-on tutorial in which we can program live and
> help newcomers to pass the first barrier in openEHR software development:
> lose the fear of archetypes.
>
> Also I would like to know how we want to present this, should we submit the
> proposals individualy and then organize or should we coordinate and make one
> proposal with all the workshops/tutorials?
>
> Thanks!
>
> --
> Kind regards,
> Eng. Pablo Pazos Guti?rrez
> http://cabolabs.com
>
> 
> From: heather.leslie at oceaninformatics.com
> To: openehr-technical at lists.openehr.org; openehr-clinical at 
> lists.openehr.org
> Subject: RE: MedInfo 2015 openEHR tutorials
> Date: Fri, 1 Aug 2014 01:54:59 +
> CC: openehr-implementers at lists.openehr.org
>
> Hi Pablo,
>
>
>
> We have kept info on Conferences in the wiki:
> http://www.openehr.org/wiki/display/resources/Conferences
>
>
>
> See Medinfo 2013:
> http://www.openehr.org/wiki/display/resources/MEDINFO+2013+-+Copenhagen,+Denmark.
> 2 half day sessions were held then ? one clinical modelling focussed and the
> other technical
>
>
>
> Regards
>
>
>
> Heather
>
>
>
> From: openEHR-technical [mailto:openehr-technical-bounces at 
> lists.openehr.org]
> On Behalf Of pablo pazos
> Sent: Friday, 1 August 2014 12:14 AM
> To: openeh technical; openEHR Clinical
> Cc: openehr implementers
> Subject: RE: MedInfo 2015 openEHR tutorials
>
>
>
> Hi Shinji!
>
>
>
> By chance, do you have the agendas of the previous openEHR developer's
> workshops?
>
>
>
> It would be nice to see what has been done, do a little bit of introduction
> workshops for beginners and do some new cool stuff for skilled openEHR devs.
>
>
>
> BTW, maybe a good place to coordinate and share info about ideas would be
> the openEHR wiki.
>
>
>
> Thanks!
>
> --
> Kind regards,
> Eng. Pablo Pazos Guti?rrez
> http://cabolabs.com
>
> 
>
> From: skoba at moss.gr.jp
> Date: Wed, 30 Jul 2014 10:25:16 +0900
> Subject: Re: MedInfo 2015 openEHR tutorials
> To: openehr-clinical at lists.openehr.org
> CC: openehr-technical at lists.openehr.org;
> openehr-implementers at lists.openehr.org
>
> Hi Pablo and all,
>
> We had developers' workshop at Medinfo2007, 2010 and 2013, and I organized
> developers' workshop 2010, and 2013.
>
> I think the combination of clinical workshop/tutorial half day and
> developers' workshop half day would be better.
>
> I have to write up until the tutorial/workshop dead line, 15 Jan, 2015.
>
> Shinji KOBAYASHI
>
>
>
> 2014-07-29 13:52 GMT+09:00 pablo pazo

Archetype Naming proposals - do we need V0?

[Shinji KOBAYASHI]

Thank you for kind explanation.
I was afraid about conflict of file name and file name conversion
between OSs, but it looks no matter.

Shinji

2014-10-07 1:40 GMT+09:00 Thomas Beale :
> On 06/10/2014 16:52, Shinji KOBAYASHI wrote:
>>
>> Hi Thomas Beale,
>>
>>> openEHR-EHR-ADMIN_ENTRY.encounter.v1 =>
>>> org.openEHR::openEHR-EHR-ADMIN_ENTRY.encounter.v0.0.1 =>
>>> review & changes => org.openEHR::openEHR-EHR-ADMIN_ENTRY.encounter.v1.0.0
>>
>> Would file name nomenclature be changed? There is no spec for file
>> name of archetype, but archetype ids have been assigned to file names.
>> Whereas, : is not available for file name in Windows OS (and old Mac OS).
>>
>
> well, as mentioned before, filenames don't matter, but of course when a tool
> generates a file, it should use an obvious name, something related to the
> id. And you are right - ':' won't work on Windows (we'll never stop cursing
> the stupid Windows directory and file-naming will we). So it will need
> to be something else, maybe just using the '-' character. So for that
> reason, we had better add a file-system friendly variant of the full id...
>
> I'll repeat to make it very clear to everyone: tools shouldn't care what the
> filenames, are, they're only there for humans to understand, e.g. if
> emailing a file manually. Tools should all do what the AE, TD and AWB do
> today: look in a configured directory (tree) for .adl or .adls files, and
> read the first couple of non-comment lines to get the meta-data. In the AWB
> at least I do this in a 'fast parse' phase, with a dumb mini-parser that
> reads file headers. It never looks at the file names at all - every filename
> that matches the regex '.*\.adl' or '.*\.adls' is matched.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Archetype Naming proposals - do we need V0?

[Shinji KOBAYASHI]

Hi Thomas Beale,

>openEHR-EHR-ADMIN_ENTRY.encounter.v1 => 
>org.openEHR::openEHR-EHR-ADMIN_ENTRY.encounter.v0.0.1 =>
>review & changes => org.openEHR::openEHR-EHR-ADMIN_ENTRY.encounter.v1.0.0

Would file name nomenclature be changed? There is no spec for file
name of archetype, but archetype ids have been assigned to file names.
Whereas, : is not available for file name in Windows OS (and old Mac OS).

Shinji

2014-10-02 7:28 GMT+09:00 Thomas Beale :
> On 01/10/2014 16:44, Sebastian Garde wrote:
>
> Hi Sebastian,
>
> I realise you are physically not too far away from me in Germany and we even
> share the same name, so I hope you won't shoot the messenger here, but I
> have to say the following...
>
> The consequence of what you are saying would be that we cannot publish any
> v1 archetype if it is already on CKM without an analysis if there have been
> any breaking changes anywhere during the development and review process
> (which would be the case in most cases I suspect).
>
> However, this is the case with or without any of the changes being discussed
> here: It doesn't matter if draft archetypes become v0 for a while: once they
> are published they'd be v1 again anyway - and likely incompatible with the
> previous v1.
>
>
> but none of the existing CKM archetype ids has a namespace, so the new ids
> will be distinguishable from the old. It would be useful to have some real
> data on who has used any CKM draft (i.e. 'old') archetypes in real systems
> to know is there is in fact a problem here or not.
>
> Anyway, the renaming should follow the model:
>
> openEHR-EHR-ADMIN_ENTRY.encounter.v1 =>
> org.openEHR::openEHR-EHR-ADMIN_ENTRY.encounter.v0.0.1 => review & changes =>
> org.openEHR::openEHR-EHR-ADMIN_ENTRY.encounter.v1.0.0
>
> so there is no way for the first and last versions to get mixed up that I
> can see.
>
> If on the other hand, you leave the CKM draft archetypes as v1 and they are
> published subsequently, there is also no guarantee whatsoever that the
> published version is compatible with any draft revision (or any of the draft
> revisions with each other).
> Either way, if you use them now, no, you cannot just replace a draft
> archetype with the next revision of the draft archetype or its subsequently
> published revision. You cannot do it now, because there is no guarantee that
> they'd be compatible and you cannot do it with or without v0.
>
> So, while I certainly acknowledge the problem (more below), it is not a
> problem that is caused or increased by migrating draft archetypes to v0.
>
> And in fact solving this problem is one of the core reasons for the proposed
> revisioning rules.
> You will know exactly where you are at and how compatible two archetypes
> are.
>
> So, if you as a company use draft archetypes, this is the risk you have
> taken - draft archetypes just cannot be assumed stable or backwardly
> compatible just because they happen to be expressed in (more or less)
> correct ADL.
> The impression that draft archetypes are stable has of course been given by
> the lack of activity in getting draft archetypes published on the
> international CKM.
> The industry sprint will hopefully change the momentum of this considerably.
>
> The problem you describe is more or less the same for every vendor that uses
> unstable archetypes, which for lack of alternatives, will most likely be
> about every vendor.
>
> However, I can see some ideas for a solution to this problem, because you
> can clearly identify all archetypes under the new revisioning rules vs those
> that are not.
> Most importantly, archetypes under the proposed revisioning scheme will have
> a namespace whereas the old ones don't.
>
>
> ah, you got there before me ;-)
>
> - thomas
>
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Archetype Naming proposals - do we need V0?

[Shinji KOBAYASHI]

Hi Ian and Sebastian,

The rule figured by Sebastian and the explanation by Ian looks very
clear, thank you.
But we will need to additional rule/guide to make it clear what is
'major' or 'minor', in the next step.
For example, if the archetype was converted from ADL 1.4 to 1.5(or
later), is this minor change or major change?
ADL conversion may break compatibility for machine readability, but
not change in clinical semantics.
If an archetype was changed to be semantically incompatible, I think
they should not be assigned for same archetype id.

regards,
Shinji


2014-10-02 1:16 GMT+09:00 Ian McNicoll :
> Hi Shinji,
>
> For clarity ...
>
> CKM 'revisions' have nothing to do with the official openEHR
> major.minor.path numbers. They are an internal format to do with the local
> workflows inherit in openEHR. We have discussed changing CKM 'revision' to
> something else to make this clearer.
>
> The official major.minor.patch number proposals are intended to be neutral
> to the use of CKM or any other repository tool, even the use of a simple Git
> repo, and make no assumptions about how the assets are organised within that
> repo e.g a git-based repo may have a quite different Trunk/branching method
> and use branch names/ tags to handle internal workflow.
>
> The aim of the openEHR major.minor.patch scheme is to ensure that where an
> archetype is used outside of a repo, in tooling or in applications, that the
> consumer can be very confident about the exact provenance of the archetype
> and especially its stability.
>
> So ignore what CKM does internally, that is not important in this context.
> In the future each archetype in CKM (and we hope other controlled repos)
> will also label every asset and version of the asset using major.minor.patch
> -XX + build, alongside what ever local internal versioning scheme they
> require.
>
> Ian
>
> On 1 October 2014 17:00, Sebastian Garde
>  wrote:
>>
>>
>> On 01.10.2014 17:02, Shinji KOBAYASHI wrote:
>>
>> Hi Ian,
>>
>> I would prefer https://github.com/flazz/semver/ , but not explain :)
>> CKM shows archetype revision history tree, but the version is not changed.
>> For example, openEHR-EHR-OBSERVATION.blood_pressure version has been
>> kept 1 in these years, but it has 26 revision up.
>> I think it is non-sense to change version by each revision commit, but
>> meaningful change should be reflected to the version number, such as
>> adding item, fixed typo, translation to other language completed.
>>
>> Hi Shinji,
>>
>> With the new revision rules a la SemVer we now have:
>>
>> The major version would change with an incompatible change (=the current
>> v1, v2, etc identifier)
>> The minor version for a compatible change which could change the meaning
>> even if only slightly
>> The patch version for e.g. fixing a typo in a translation.
>>
>> There are some grey areas, but the intention is clear I think.
>> In CKM, you can do this with the new revision rules. CKM will suggest a
>> new revision number based on this general idea.
>> In any case you can always go higher - if you think a patch change is so
>> significant because of the wording that has changed, it can also be a minor
>> (or even major) version increase, i.e. instead of going from v1.0.0 to
>> v1.0.1, you go to v1.1.0
>>
>> To take the example of the BP archetype that you mention:
>> The archetype was published in Rev 16 in 2009.
>> Since then it has encountered several more changes to it like adding a
>> couple of translations.
>> None of these would be a breaking change to my knowledge. So, in the old
>> rules it just remains v1.
>> With the new revision rules, the archetype would have been published as
>> v1.0.0 in 2009 and would now maybe be v1.2.4 (or whatever) - which means it
>> had a number of patches and 2 minor version changes in total, none of them
>> backwardly incompatible.
>>
>> Is this the kind of stuff you are missing? If so, this is exactly what the
>> revisioning rules are there for.
>> Cheers
>> Sebastian
>>
>>
>>
>> Shinji
>>
>> 2014-10-01 23:05 GMT+09:00 Ian McNicoll :
>>
>> Hi Shinji,
>>
>> Github is your friend - see https://github.com/npm/node-semver
>>
>> but I agree, it is tricky.
>>
>> However it is simply not possible to manage the transition between stable
>> and published archetypes safely by just using numbering alone. We need to
>> very explicitly flag that unstable state so that it can be parsed safely -
>> this is what the '-' gives us. We did look at al

Archetype Naming proposals - do we need V0?

[Shinji KOBAYASHI]

Sorry, I have misused "exclusive" to "explicit". It is explicit
mistake. much sorry to confusing you.

Shinji ashamed.

2014-10-02 0:02 GMT+09:00 Shinji KOBAYASHI :
> Hi Ian,
>
> I would prefer https://github.com/flazz/semver/ , but not explain :)
> CKM shows archetype revision history tree, but the version is not changed.
> For example, openEHR-EHR-OBSERVATION.blood_pressure version has been
> kept 1 in these years, but it has 26 revision up.
> I think it is non-sense to change version by each revision commit, but
> meaningful change should be reflected to the version number, such as
> adding item, fixed typo, translation to other language completed.
>
> Shinji
>
> 2014-10-01 23:05 GMT+09:00 Ian McNicoll :
>> Hi Shinji,
>>
>> Github is your friend - see https://github.com/npm/node-semver
>>
>> but I agree, it is tricky.
>>
>> However it is simply not possible to manage the transition between stable
>> and published archetypes safely by just using numbering alone. We need to
>> very explicitly flag that unstable state so that it can be parsed safely -
>> this is what the '-' gives us. We did look at all sort of numbering schemes
>> and alternatives to Semver but eventually came back to the view that this is
>> pretty well how it has to work. One big advantage of sticking with Semver is
>> that we can take advantage of work  like the NPM parser, apart from the
>>
>> The 'exclusive revision history' (if I understand you correctly) comes from
>> the Build identifier, identified by a '+'
>>
>> So an unstable archetype may be
>>
>> v1.0.1-unstable+145567345
>>
>> and after some internal authoring or reviewing goes to
>>
>> v1.0.1-unstable+35634512
>>
>> The build identifier is not guaranteed to be sequential and there may well
>> be breaking changes between the first and second iteration.
>>
>> From the developer perspective I can know exactly which build of the
>> archetype I am using in my system, and that it is unstable. I would be very
>> unwise to use this in any production system but may of course need it in a
>> testing phase, or need to support its use within tooling.
>>
>> I am not wedded to -unstable , but I think you will find that if you try to
>> work with some other number=based system, you always hit a problem ,and that
>> some kind of pre-release signifier is required.
>>
>> If we agreed that openEHR would only officially support -unstable (or
>> -alpha) and -rc, that would greatly simplify the parsing.
>>
>> Ian
>>
>>
>> Ian
>>
>>
>> Implementers do not have to parse what comes next
>>
>> On 1 October 2014 14:34, Shinji KOBAYASHI  wrote:
>>>
>>> Hi Ian.
>>>
>>> I have read once SemVer, but it is still confusing about suffix.
>>> especially "alpha.11 > alpha.beta > beta.1" sequence. This needs
>>> tricky grammar rule to parse.
>>>
>>> Hi Sebastian,
>>>
>>> I think revision history should be exclusive, even it is unstable version.
>>>
>>> Regards,
>>> Shinji
>>>
>>>
>>> 2014-10-01 21:26 GMT+09:00 Ian McNicoll :
>>> > Hi Shinji,
>>> >
>>> > Can I suggest you read the semver.org specifications? Semver is now used
>>> > pretty widely in systems and tooling (including the nodeJS Package
>>> > Manager
>>> > NPM). We have taken the - suffix directly from those specifications and
>>> > in
>>> > other respcts we are now following semver exactly so there should be
>>> > open
>>> > source parsers out there that can be used.
>>> >
>>> >
>>> > Semver exists because we have to treat semantic specifications
>>> > differently
>>> > from normal software builds. In normal software alpha, beta, pre-release
>>> > and
>>> > indeed the numbering chosen do not need to have any computable
>>> > significance.
>>> > Windows 9 is only called Windows 9 for marketing reasons ,not because it
>>> > represents a breaking change. My recent Yosemite Beta 3-> Beta 4 update
>>> > may
>>> > make all sorts of breaking changes but is still a Beta and appears to be
>>> > only a build different from the Developer Pre-release Yosemite
>>> > candidate.
>>> >
>>> > When we are dealing with Semantic artefacts such as APIs or archetypes,
>>> > the
>>> > numbering scheme and 

Archetype Naming proposals - do we need V0?

[Shinji KOBAYASHI]

Hi Ian,

I would prefer https://github.com/flazz/semver/ , but not explain :)
CKM shows archetype revision history tree, but the version is not changed.
For example, openEHR-EHR-OBSERVATION.blood_pressure version has been
kept 1 in these years, but it has 26 revision up.
I think it is non-sense to change version by each revision commit, but
meaningful change should be reflected to the version number, such as
adding item, fixed typo, translation to other language completed.

Shinji

2014-10-01 23:05 GMT+09:00 Ian McNicoll :
> Hi Shinji,
>
> Github is your friend - see https://github.com/npm/node-semver
>
> but I agree, it is tricky.
>
> However it is simply not possible to manage the transition between stable
> and published archetypes safely by just using numbering alone. We need to
> very explicitly flag that unstable state so that it can be parsed safely -
> this is what the '-' gives us. We did look at all sort of numbering schemes
> and alternatives to Semver but eventually came back to the view that this is
> pretty well how it has to work. One big advantage of sticking with Semver is
> that we can take advantage of work  like the NPM parser, apart from the
>
> The 'exclusive revision history' (if I understand you correctly) comes from
> the Build identifier, identified by a '+'
>
> So an unstable archetype may be
>
> v1.0.1-unstable+145567345
>
> and after some internal authoring or reviewing goes to
>
> v1.0.1-unstable+35634512
>
> The build identifier is not guaranteed to be sequential and there may well
> be breaking changes between the first and second iteration.
>
> From the developer perspective I can know exactly which build of the
> archetype I am using in my system, and that it is unstable. I would be very
> unwise to use this in any production system but may of course need it in a
> testing phase, or need to support its use within tooling.
>
> I am not wedded to -unstable , but I think you will find that if you try to
> work with some other number=based system, you always hit a problem ,and that
> some kind of pre-release signifier is required.
>
> If we agreed that openEHR would only officially support -unstable (or
> -alpha) and -rc, that would greatly simplify the parsing.
>
> Ian
>
>
> Ian
>
>
> Implementers do not have to parse what comes next
>
> On 1 October 2014 14:34, Shinji KOBAYASHI  wrote:
>>
>> Hi Ian.
>>
>> I have read once SemVer, but it is still confusing about suffix.
>> especially "alpha.11 > alpha.beta > beta.1" sequence. This needs
>> tricky grammar rule to parse.
>>
>> Hi Sebastian,
>>
>> I think revision history should be exclusive, even it is unstable version.
>>
>> Regards,
>> Shinji
>>
>>
>> 2014-10-01 21:26 GMT+09:00 Ian McNicoll :
>> > Hi Shinji,
>> >
>> > Can I suggest you read the semver.org specifications? Semver is now used
>> > pretty widely in systems and tooling (including the nodeJS Package
>> > Manager
>> > NPM). We have taken the - suffix directly from those specifications and
>> > in
>> > other respcts we are now following semver exactly so there should be
>> > open
>> > source parsers out there that can be used.
>> >
>> >
>> > Semver exists because we have to treat semantic specifications
>> > differently
>> > from normal software builds. In normal software alpha, beta, pre-release
>> > and
>> > indeed the numbering chosen do not need to have any computable
>> > significance.
>> > Windows 9 is only called Windows 9 for marketing reasons ,not because it
>> > represents a breaking change. My recent Yosemite Beta 3-> Beta 4 update
>> > may
>> > make all sorts of breaking changes but is still a Beta and appears to be
>> > only a build different from the Developer Pre-release Yosemite
>> > candidate.
>> >
>> > When we are dealing with Semantic artefacts such as APIs or archetypes,
>> > the
>> > numbering scheme and suffixes have very specific meanings and rules, to
>> > do
>> > with backward compatibility.
>> >
>> > The -suffix is necessary to make it very clear that this is a
>> > pre-release
>> > artefact and that the normal versioning rules do not apply. What comes
>> > after
>> > the suffix does not really matter and
>> >
>> > The prime responsibility we have as archetype authors is to make sure
>> > that
>> > developers know whether they are working with a stable, published
>> > archetype
>> &

Archetype Naming proposals - do we need V0?

[Shinji KOBAYASHI]

Hi Ian.

I have read once SemVer, but it is still confusing about suffix.
especially "alpha.11 > alpha.beta > beta.1" sequence. This needs
tricky grammar rule to parse.

Hi Sebastian,

I think revision history should be exclusive, even it is unstable version.

Regards,
Shinji


2014-10-01 21:26 GMT+09:00 Ian McNicoll :
> Hi Shinji,
>
> Can I suggest you read the semver.org specifications? Semver is now used
> pretty widely in systems and tooling (including the nodeJS Package Manager
> NPM). We have taken the - suffix directly from those specifications and in
> other respcts we are now following semver exactly so there should be open
> source parsers out there that can be used.
>
>
> Semver exists because we have to treat semantic specifications differently
> from normal software builds. In normal software alpha, beta, pre-release and
> indeed the numbering chosen do not need to have any computable significance.
> Windows 9 is only called Windows 9 for marketing reasons ,not because it
> represents a breaking change. My recent Yosemite Beta 3-> Beta 4 update may
> make all sorts of breaking changes but is still a Beta and appears to be
> only a build different from the Developer Pre-release Yosemite candidate.
>
> When we are dealing with Semantic artefacts such as APIs or archetypes, the
> numbering scheme and suffixes have very specific meanings and rules, to do
> with backward compatibility.
>
> The -suffix is necessary to make it very clear that this is a pre-release
> artefact and that the normal versioning rules do not apply. What comes after
> the suffix does not really matter and
>
> The prime responsibility we have as archetype authors is to make sure that
> developers know whether they are working with a stable, published archetype
> which has followed the versioning rules, or an unstable archetype where
> those rules are temporarily suspended.
>
> It is impossible to do this clearly with a numbering schema alone which is
> why the - suffix is well-established in SemVer and the tools which use it.
>
> In normal circumstances unstable archetypes would never be used in
> production systems.
>
> Ian
>
>
> On 1 October 2014 13:04, Shinji KOBAYASHI  wrote:
>>
>> Hi Ian,
>>
>> I prefer V0, because it would be easier to adopt for other developers
>> who do not know openEHR well.
>> For parser implementation, 1.0.0-unstable is not a good design,
>> because it is not clear that which is the later release amongs,
>> unstable, testing, pre-release, release-candidate, draft, etc...
>> I would suggest 0.9.9 instead of 1.0.0-unstable. We can revise the
>> revision 0.9.9 after it released, to 0.9.9.9. or 0.9.9.99.
>>
>> Shinji
>>
>> 2014-10-01 19:23 GMT+09:00 Ian McNicoll :
>> >
>> > Hi all,
>> >
>> > Apologies for cross-posting in both clinical and technical but this does
>> > neatly cross that divide.
>> >
>> > We are getting close in CKM to implementing the ADL1.5 archetype naming
>> > /versioning rules proposed at
>> >
>> >
>> > http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification
>> >
>> > mostly by adding the metadata to the ADL other_details section, which
>> > means
>> > we can carry the information in ADL 1.4 archetypes without disturbing
>> > current systems.
>> >
>> > These latest proposals are now very much in line with the de-facto
>> > standard
>> > SemVer 2.0 see http://semver.org which allows
>> >
>> > major revision
>> > minor revision
>> > patch
>> > build
>> >
>> > but one of the questions which remains controversial is whether to
>> > support a
>> > major revision of V0 (as allowed in SemVer).
>> >
>> > In Semver, V0 is allowed for very immature ?first draft? semantic
>> > artefacts/APIs prior to initial release but SemVer allows for any
>> > revision
>> > to appended with a pre-release modifier
>> >
>> > e.g. v2.0.0-alpha or v1.0.0-unstable
>> >
>> > This is recognised as meaning that the artefact is unstable and the
>> > version
>> > numbering cannot be relied on e.g to assert backward compatibility.
>> >
>> > In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their
>> > ?stability? and lack of commitment to the versioning rules.
>> >
>> > So the question for us in the openEHR world is whether tooling should
>> > support v0.0.0, or simply use v1.0.0-unstable
>> >
>> > V0 Advantages
>> >

Archetype Naming proposals - do we need V0?

[Shinji KOBAYASHI]

Hi Ian,

I prefer V0, because it would be easier to adopt for other developers
who do not know openEHR well.
For parser implementation, 1.0.0-unstable is not a good design,
because it is not clear that which is the later release amongs,
unstable, testing, pre-release, release-candidate, draft, etc...
I would suggest 0.9.9 instead of 1.0.0-unstable. We can revise the
revision 0.9.9 after it released, to 0.9.9.9. or 0.9.9.99.

Shinji

2014-10-01 19:23 GMT+09:00 Ian McNicoll :
>
> Hi all,
>
> Apologies for cross-posting in both clinical and technical but this does
> neatly cross that divide.
>
> We are getting close in CKM to implementing the ADL1.5 archetype naming
> /versioning rules proposed at
>
> http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification
>
> mostly by adding the metadata to the ADL other_details section, which means
> we can carry the information in ADL 1.4 archetypes without disturbing
> current systems.
>
> These latest proposals are now very much in line with the de-facto standard
> SemVer 2.0 see http://semver.org which allows
>
> major revision
> minor revision
> patch
> build
>
> but one of the questions which remains controversial is whether to support a
> major revision of V0 (as allowed in SemVer).
>
> In Semver, V0 is allowed for very immature ?first draft? semantic
> artefacts/APIs prior to initial release but SemVer allows for any revision
> to appended with a pre-release modifier
>
> e.g. v2.0.0-alpha or v1.0.0-unstable
>
> This is recognised as meaning that the artefact is unstable and the version
> numbering cannot be relied on e.g to assert backward compatibility.
>
> In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their
> ?stability? and lack of commitment to the versioning rules.
>
> So the question for us in the openEHR world is whether tooling should
> support v0.0.0, or simply use v1.0.0-unstable
>
> V0 Advantages
>
> 1. The archetype is clearly marked as immature
> 2. Full compliance with SemVer
> 3. Supported in current test build of CKM
>
> V0 Disadvantages
>
> 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to
> support V0
> 2. Add another layer of complexity to the archetype naming/versioning rules
> 3. Question arises of whether / if to convert current draft V1 CKM
> archetypes to V0 with overhead of explanation to current users.
> 4. Adds complexity where V0 archetypes are being used within templates, when
> the archetype is published and needs to be updated to V1 within these
> templates.
>
>
> V1- Advantages
>
> 1. Compliant with SemVer
> 2. Does not need any changes to Archetype Editor.
> 3. Easier transition between draft and publication states when used within
> templates i.e does not need V0->v1 change
>
>
> V1- Disadvantages
> 1. Does not so clearly differentiate ?first draft? archetype from others
>
>
> Before a final decision is made, we are interested in feedback from the
> community on whether V0 should be implemented in CKM and other openEHR
> tools, although in practice V1- will do an identical job in terms of version
> number governance.
>
> Regards,
>
> Ian McNicoll
> Heather Leslie
> Sebastian Garde
> Thomas Beale
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

MedInfo 2015 openEHR tutorials

[Shinji KOBAYASHI]

Hi Pablo and all,

We had developers' workshop at Medinfo2007, 2010 and 2013, and I organized
developers' workshop 2010, and 2013.
I think the combination of clinical workshop/tutorial half day and
developers' workshop half day would be better.
I have to write up until the tutorial/workshop dead line, 15 Jan, 2015.

Shinji KOBAYASHI


2014-07-29 13:52 GMT+09:00 pablo pazos :

> Hi all!
>
> Since next MedInfo is in Brazil (near Uruguay) I'll be attending for sure.
> I also might present a paper or two and want to propose an openEHR related
> tutorial.
>
> Is other people planning to present openEHR papers or tutorials? It would
> be great if we can coordinate tutorials (and topics) together so we can
> have our "openEHR day" at MedInfo.
>
> What do you think?
>
> We have 1 year to plan this, and that's not a lot of time!
>
> I hope we can join forces and do something nice for the south american
> openEHR community. We are eager to learn from others that already have
> openEHR working in the real world, and learn from their success and
> failures.
>
> --
> Kind regards,
> Eng. Pablo Pazos Guti?rrez
> http://cabolabs.com <http://cabolabs.com/es/home>
> <http://twitter.com/ppazos>
>
> ___
> 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-technical_lists.openehr.org/attachments/20140730/a311abd6/attachment.html>

Ocean's Template Designer and allowedType rules

[Shinji KOBAYASHI]

Thank you pablo.
These are encouraging.

Cheers,
Shinji


2013/11/28 pablo pazos 

> Hi Shinji, I've created a script to traverse an OPT and generate paths
> like this:
>
>
> /content[archetype_id=openEHR-EHR-SECTION.referral_details.v1]/items[archetype_id=openEHR-EHR-INSTRUCTION.request-referral.v1]/protocol[at0008]/items[archetype_id=openEHR-EHR-CLUSTER.individual_professional.v1]/items[archetype_id=openEHR-EHR-CLUSTER.person_name.v1]/items[at0013]/items[at0002]/items[at0003]/value
>  DV_TEXT
>
>
> This path was generated from the "Demo hide-on-form" OPT that is in the
> CKM. Don't know if the syntax is 100% valid, but changing the algorithm is
> easy.
>
> Algorithm:
> https://github.com/ppazos/cabolabs-ehrserver/blob/master/src/groovy/com/cabolabs/archetype/OperationalTemplateIndexer.groovy
> Test: https://github.com/ppazos/cabolabs-ehrserver/tree/master/test
> OPTs: https://github.com/ppazos/cabolabs-ehrserver/tree/master/opts
>
>
> --
> Kind regards,
> Eng. Pablo Pazos Guti?rrez
> http://cabolabs.com <http://cabolabs.com/es/home><http://twitter.com/ppazos>
>
> > From: skoba at moss.gr.jp
> > Date: Fri, 15 Nov 2013 10:55:49 +0900
> > Subject: Re: Ocean's Template Designer and allowedType rules
> > To: openehr-implementers at lists.openehr.org
> > CC: openehr-technical at lists.openehr.org
>
> >
> > Hi Heath,
> >
> > I have a related question about OPT.
> > Could you explain path calculation algorithm for OPT?
> >
> > Best wishes,
> > Shinji KOBAYASHI
> >
> > 2013/11/15 Heath Frankel :
> > > Hi Pablo,
> > >
> > > The OET format is an internal format. You should export the template
> as an
> > > OPT and you will get a AOM and RM based output.
> > >
> > >
> > >
> > > Heath
> > >
> > >
> > >
> > > From: openEHR-technical [mailto:
> openehr-technical-bounces at lists.openehr.org]
> > > On Behalf Of pablo pazos
> > > Sent: Friday, 15 November 2013 1:06 AM
> > > To: openeh technical; openehr implementers
> > > Subject: Ocean's Template Designer and allowedType rules
> > >
> > >
> > >
> > > Hi all,
> > >
> > >
> > >
> > > I'm playing with the TD v2.7.60Beta to include openEHR template
> support to
> > > CaboLabs EHRServer (http://www.youtube.com/watch?v=D-hs-Ofb8SY)
> > >
> > >
> > >
> > > I opened the Blood Pressure archetype and tryied to constraint the Any
> Event
> > > node of type EVENT to allow only POINT_EVENT, and I get this rule:
> > >
> > >
> > >
> > > 
> > >
> > > 
> > >
> > > PointInTime
> > >
> > > 
> > >
> > > 
> > >
> > >
> > >
> > > Shouldn't "PointInTime" be "POINT_EVENT"?
> > >
> > >
> > >
> > > Is there any reason for the TD to not use openEHR datatype names?
> > >
> > >
> > >
> > > Where can I find all the names used to constraint allowedTypes in TD?
> > >
> > >
> > >
> > > Thanks!
> > >
> > >
> > > --
> > > Kind regards,
> > > Eng. Pablo Pazos Guti?rrez
> > > http://cabolabs.com
> > >
> > >
> > > ___
> > > openEHR-implementers mailing list
> > > openEHR-implementers at lists.openehr.org
> > >
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
> >
> > ___
> > openEHR-technical mailing list
> > openEHR-technical at lists.openehr.org
> >
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131128/9bad0ce5/attachment-0001.html>

Ocean's Template Designer and allowedType rules

[Shinji KOBAYASHI]

Thank you Ian. This is quite informative.

Regards,
Shinji

2013/11/15 Ian McNicoll :
> Hi Shinji,
>
> Look at the SemanticHealthNet Heart Failure Summary template at
> http://openehr.org/ckm/#showTemplate_1013.26.14_2, and press the "Show
> Pathjs" button , you will see all of the paths within the template.
>
> Also you might find it helpful to look open a complex template in
> Template Designer and look at the Path property in the Properties box.
>
> Ian
>
> On 15 November 2013 04:00, Shinji KOBAYASHI  wrote:
>> Hi Heath,
>>
>> I am trying to implement opt_parser on Ruby.
>> Parsing OPT XML file is easy, but the path of each node is not defined.
>> There are many path example around archetypes, but template path has
>> only few example.
>> Moreover, OPT has nested archetype tree. I am confused much.
>>
>> Best wish,
>> Shinji
>>
>> 2013/11/15 Heath Frankel :
>>> Hi Shinji,
>>> Can you be more specific about your question?
>>>
>>> Heath
>>>
>>> -Original Message-
>>> From: openEHR-implementers
>>> [mailto:openehr-implementers-bounces at lists.openehr.org] On Behalf Of 
>>> Shinji
>>> KOBAYASHI
>>> Sent: Friday, 15 November 2013 12:26 PM
>>> To: For openEHR implementation discussions
>>> Cc: For openEHR technical discussions
>>> Subject: Re: Ocean's Template Designer and allowedType rules
>>>
>>> Hi Heath,
>>>
>>> I have a related question about OPT.
>>> Could you explain path calculation algorithm for OPT?
>>>
>>> Best wishes,
>>> Shinji KOBAYASHI
>>>
>>> 2013/11/15 Heath Frankel :
>>>> Hi Pablo,
>>>>
>>>> The OET format is an internal format. You should export the template
>>>> as an OPT and you will get a AOM and RM based output.
>>>>
>>>>
>>>>
>>>> Heath
>>>>
>>>>
>>>>
>>>> From: openEHR-technical
>>>> [mailto:openehr-technical-bounces at lists.openehr.org]
>>>> On Behalf Of pablo pazos
>>>> Sent: Friday, 15 November 2013 1:06 AM
>>>> To: openeh technical; openehr implementers
>>>> Subject: Ocean's Template Designer and allowedType rules
>>>>
>>>>
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> I'm playing with the TD v2.7.60Beta to include openEHR template
>>>> support to CaboLabs EHRServer
>>>> (http://www.youtube.com/watch?v=D-hs-Ofb8SY)
>>>>
>>>>
>>>>
>>>> I opened the Blood Pressure archetype and tryied to constraint the Any
>>>> Event node of type EVENT to allow only POINT_EVENT, and I get this rule:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>   
>>>>
>>>> PointInTime
>>>>
>>>>   
>>>>
>>>> 
>>>>
>>>>
>>>>
>>>> Shouldn't "PointInTime" be "POINT_EVENT"?
>>>>
>>>>
>>>>
>>>> Is there any reason for the TD to not use openEHR datatype names?
>>>>
>>>>
>>>>
>>>> Where can I find all the names used to constraint allowedTypes in TD?
>>>>
>>>>
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> --
>>>> Kind regards,
>>>> Eng. Pablo Pazos Guti?rrez
>>>> http://cabolabs.com
>>>>
>>>>
>>>> ___
>>>> openEHR-implementers mailing list
>>>> openEHR-implementers at lists.openehr.org
>>>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.o
>>>> penehr.org
>>>
>>> ___
>>> openEHR-implementers mailing list
>>> openEHR-implementers at lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr
>>> .org
>>>
>>>
>>> ___
>>> openEHR-implementers mailing list
>>> openEHR-implementers at lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> --
> Dr Ian McNicoll
> office +44 (0)1536 414 994
> fax +44 (0)1536 516317
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
>
> Clinical Modelling Consultant, Ocean Informatics, UK
> Director 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-implementers mailing list
> openEHR-implementers at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Ocean's Template Designer and allowedType rules

[Shinji KOBAYASHI]

Hi Heath,

I am trying to implement opt_parser on Ruby.
Parsing OPT XML file is easy, but the path of each node is not defined.
There are many path example around archetypes, but template path has
only few example.
Moreover, OPT has nested archetype tree. I am confused much.

Best wish,
Shinji

2013/11/15 Heath Frankel :
> Hi Shinji,
> Can you be more specific about your question?
>
> Heath
>
> -Original Message-
> From: openEHR-implementers
> [mailto:openehr-implementers-bounces at lists.openehr.org] On Behalf Of Shinji
> KOBAYASHI
> Sent: Friday, 15 November 2013 12:26 PM
> To: For openEHR implementation discussions
> Cc: For openEHR technical discussions
> Subject: Re: Ocean's Template Designer and allowedType rules
>
> Hi Heath,
>
> I have a related question about OPT.
> Could you explain path calculation algorithm for OPT?
>
> Best wishes,
> Shinji KOBAYASHI
>
> 2013/11/15 Heath Frankel :
>> Hi Pablo,
>>
>> The OET format is an internal format. You should export the template
>> as an OPT and you will get a AOM and RM based output.
>>
>>
>>
>> Heath
>>
>>
>>
>> From: openEHR-technical
>> [mailto:openehr-technical-bounces at lists.openehr.org]
>> On Behalf Of pablo pazos
>> Sent: Friday, 15 November 2013 1:06 AM
>> To: openeh technical; openehr implementers
>> Subject: Ocean's Template Designer and allowedType rules
>>
>>
>>
>> Hi all,
>>
>>
>>
>> I'm playing with the TD v2.7.60Beta to include openEHR template
>> support to CaboLabs EHRServer
>> (http://www.youtube.com/watch?v=D-hs-Ofb8SY)
>>
>>
>>
>> I opened the Blood Pressure archetype and tryied to constraint the Any
>> Event node of type EVENT to allow only POINT_EVENT, and I get this rule:
>>
>>
>>
>>
>>
>>   
>>
>> PointInTime
>>
>>   
>>
>> 
>>
>>
>>
>> Shouldn't "PointInTime" be "POINT_EVENT"?
>>
>>
>>
>> Is there any reason for the TD to not use openEHR datatype names?
>>
>>
>>
>> Where can I find all the names used to constraint allowedTypes in TD?
>>
>>
>>
>> Thanks!
>>
>>
>> --
>> Kind regards,
>> Eng. Pablo Pazos Guti?rrez
>> http://cabolabs.com
>>
>>
>> ___
>> openEHR-implementers mailing list
>> openEHR-implementers at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.o
>> penehr.org
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr
> .org
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Ocean's Template Designer and allowedType rules

[Shinji KOBAYASHI]

Hi Heath,

I have a related question about OPT.
Could you explain path calculation algorithm for OPT?

Best wishes,
Shinji KOBAYASHI

2013/11/15 Heath Frankel :
> Hi Pablo,
>
> The OET format is an internal format. You should export the template as an
> OPT and you will get a AOM and RM based output.
>
>
>
> Heath
>
>
>
> From: openEHR-technical [mailto:openehr-technical-bounces at 
> lists.openehr.org]
> On Behalf Of pablo pazos
> Sent: Friday, 15 November 2013 1:06 AM
> To: openeh technical; openehr implementers
> Subject: Ocean's Template Designer and allowedType rules
>
>
>
> Hi all,
>
>
>
> I'm playing with the TD v2.7.60Beta to include openEHR template support to
> CaboLabs EHRServer (http://www.youtube.com/watch?v=D-hs-Ofb8SY)
>
>
>
> I opened the Blood Pressure archetype and tryied to constraint the Any Event
> node of type EVENT to allow only POINT_EVENT, and I get this rule:
>
>
>
>
>
>   
>
> PointInTime
>
>   
>
> 
>
>
>
> Shouldn't "PointInTime" be "POINT_EVENT"?
>
>
>
> Is there any reason for the TD to not use openEHR datatype names?
>
>
>
> Where can I find all the names used to constraint allowedTypes in TD?
>
>
>
> Thanks!
>
>
> --
> Kind regards,
> Eng. Pablo Pazos Guti?rrez
> http://cabolabs.com
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Meeting at Medinfo?

[Shinji KOBAYASHI]

Hi Heather,

Meeting 20, night sounds very good for me, because developers'
workshop will be late
on the last day, 23 Friday.
I am very happy we can meet you again at Copenhagen.

Shinji

2013/8/1 Heather Leslie :
> Dear Colleagues attending Medinfo,
>
>
>
> Hugh, Ian, Sebastian and I will be attending from Ocean this year.
>
>
>
> We?d love to catch up with our openEHR colleagues informally one evening,
> maybe even for a meal if we can organise it.
>
>
>
> The program overview is here:
> http://www.medinfo2013.dk/Program%20at%20a%20glance
>
>
>
> Perhaps we could meet after the opening reception on Tuesday night, 20th?
>
>
>
> What do you think?
>
>
>
> Regards
>
>
>
> Heather
>
>
>
> Dr Heather Leslie
> MBBS FRACGP FACHI
> Director/Head of Consulting
> Ocean Informatics
> Phone (Aust) +61 418 966 670
> Skype - heatherleslie
> Twitter - @omowizard
>
>
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Updated ADL, AOM 1.5 and new ODIN specifications

[Shinji KOBAYASHI]

Hi Thomas Beale,

At first, I am much sorry about lacking links.
http://www.rugson.org/pdf/PSRCPattaya2012.pdf
In this presentation, serialisation formats were compared with
features and metrics, such as size and (de)serialise performance.

And the second, to address binary data in ODIN format, I think using
typing system might be good.
ex.
 my_binary_data = (Binary:Base128)<211234blurblur>

2013/4/26 Thomas Beale :
>
> Shinji-san,
>
> thanks for the feedback.
>
>
> On 25/04/2013 15:39, Shinji KOBAYASHI wrote:
>
> Hi Thomas Beale,
>
> My comments:
> 1) Page 33, A2
>  JSON is no Java Simple Object Notation. JavaScript Object
> Notation(http://www.json.org/)
>
>
> oops, getting old, memory going
>
>
> 2) How to encode binary data?
>  In order to serialise binary data as text format, it need to encoding
> system, such as Base64. What encoding system will you adopt to ODIN?
>
>
> I wonder why not Base 128, since ODIN already assumed UTF-8 strings. The
> real question is: how to detect that we have some binary data?
>
> ODIN works on the idea that every leaf type is inferrable syntactically. In
> theory we could just do
>
> my_binary_data = 
>
> where some characters will be from the non-printing characters in the 0-127
> range. That wouldn't be a problem, but it could be a problem to distinguish
> from Integers, since some binary encoded data might come out to be
>
> my_binary_data = <952>
>
> So I think some other marker is needed in ODIN. Maybe something simple like
>
> my_binary_data = <#952#>
>
>
>
>
> 3) FYI: This presentation slides show the comparison of seven
> serialisation techniques.
> XML, JSON, Java binary serialize, Protocol Buffers, Apache Avro,
> Protostuff, and Rugson.
>
>
> I guess you meant to include a link? I found this at Rugson.org..
>
>
> I think one of the best feature of ODIN to compare these serialisation
> techniques is that has strict type system, object oriented.
>
>
>
> I have to admit, I don't know how any data format without dynamic type
> markers can be used with real data...
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Updated ADL, AOM 1.5 and new ODIN specifications

[Shinji KOBAYASHI]

Hi Thomas Beale,

My comments:
1) Page 33, A2
 JSON is no Java Simple Object Notation. JavaScript Object
Notation(http://www.json.org/)
2) How to encode binary data?
 In order to serialise binary data as text format, it need to encoding
system, such as Base64. What encoding system will you adopt to ODIN?
3) FYI: This presentation slides show the comparison of seven
serialisation techniques.
XML, JSON, Java binary serialize, Protocol Buffers, Apache Avro,
Protostuff, and Rugson.
I think one of the best feature of ODIN to compare these serialisation
techniques is that has strict type system, object oriented.

Regards,
Shinji


2013/4/25 Thomas Beale :
>
> I have updated the ADL and AOM 1.5 specifications to reflect recent
> proposals for artefact identification. The main changes are that in the AOM,
> the archetype id as we know it today is constructed from pieces of
> meta-data, of which the version identifier is one.
>
> A more interesting change for most people may be that I have now removed the
> 'dADL' part of the ADL specification and given it a new name and its own
> specification. For those who don't know or remember, dADL is a pure, generic
> object serialisation syntax - yes - another thing like JSON, etc. It's new
> name is Object Data Instance Notation (ODIN) and the new spec can be found
> here. You can see this specification is in a new 'syntaxes' group at the
> bottom of the main table in the main specification baseline here.
>
> I have set up an ODIN project at the openEHR Github, here, with the idea
> that we could collect the parsers and serialisers from various languages in
> this project, or else point to them from here.
>
> Some may ask why we have ODIN (dADL), given that there is XML, JSON, YAML
> and other syntaxes. There are reasons: when dADL was first invented (about
> 2002), there was nothing except XML to use, and it is not a particularly
> clean object serialisation syntax, nor realistically human readable. dADL
> was designed to be properly object oriented, human readable and writable, to
> have rich leaf data types, to support Xpath pathing, and to enable much
> smaller texts than XML.
>
> Amazingly, dADL / ODIN still has stronger leaf data types, as well as
> dynamic typing (a key feature lacking in JSON) and object identifiers.
>
> For anyone interested in putting together ODIN parsers/serialisers for the
> various languages, please make yourself known, and let's discuss how to do
> it. A survery of such syntaxes indicates that there is growing interest in
> non-XML / post-XML data syntaxes (e.g. recent Dr Dobbs article), and I think
> ODIN could have its place in the wider world.
>
> - thomas beale
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Updated ADL, AOM 1.5 and new ODIN specifications

[Shinji KOBAYASHI]

Hi Thomas Beale,

Could you show me some examples of ODIN?
I would like to work on it and create machine readable features by Cucumber.
Cucumber (http://cukes.info/)  provides a behavior driven development
environment for many languages.

Regards,
Shinji

2013/4/25 Thomas Beale :
>
> I have updated the ADL and AOM 1.5 specifications to reflect recent
> proposals for artefact identification. The main changes are that in the AOM,
> the archetype id as we know it today is constructed from pieces of
> meta-data, of which the version identifier is one.
>
> A more interesting change for most people may be that I have now removed the
> 'dADL' part of the ADL specification and given it a new name and its own
> specification. For those who don't know or remember, dADL is a pure, generic
> object serialisation syntax - yes - another thing like JSON, etc. It's new
> name is Object Data Instance Notation (ODIN) and the new spec can be found
> here. You can see this specification is in a new 'syntaxes' group at the
> bottom of the main table in the main specification baseline here.
>
> I have set up an ODIN project at the openEHR Github, here, with the idea
> that we could collect the parsers and serialisers from various languages in
> this project, or else point to them from here.
>
> Some may ask why we have ODIN (dADL), given that there is XML, JSON, YAML
> and other syntaxes. There are reasons: when dADL was first invented (about
> 2002), there was nothing except XML to use, and it is not a particularly
> clean object serialisation syntax, nor realistically human readable. dADL
> was designed to be properly object oriented, human readable and writable, to
> have rich leaf data types, to support Xpath pathing, and to enable much
> smaller texts than XML.
>
> Amazingly, dADL / ODIN still has stronger leaf data types, as well as
> dynamic typing (a key feature lacking in JSON) and object identifiers.
>
> For anyone interested in putting together ODIN parsers/serialisers for the
> various languages, please make yourself known, and let's discuss how to do
> it. A survery of such syntaxes indicates that there is growing interest in
> non-XML / post-XML data syntaxes (e.g. recent Dr Dobbs article), and I think
> ODIN could have its place in the wider world.
>
> - thomas beale
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Developers' workshop at MEDINFO2013 in Copenhagen.

[Shinji KOBAYASHI]

Hi all,

Our proposal of openEHR developers' workshop  for MEDINFO 2013 has
been accepted as workshop!
I wish to meet you in Copanhagen!

Regards
Shinji KOBAYASHI

2012/10/11 Rong Chen :
> Hi Shinji,
>
> Great initiative! I would like to contribute to the workshop proposal
> based on our recent development on CDS.
>
> Cheers,
> Rong
>
> On 10 October 2012 17:17, Shinji KOBAYASHI  wrote:
>> Dear all,
>>
>> I would like to propose a workshop at the next MEDINFO.
>> If you are interested in this plan, please reply on this mailing
>> list or direct to me.
>> We had two good workshops at MEDINFO in  2007 and 2010.
>> The coming MEDINFO will be held at 20-23 August 2013.
>> http://www.medinfo2013.dk/
>>
>> The paper and proposal deadline is closing, 10 December, 2012.
>> However, I think we have enough time to discuss to have a good
>> workshop proposal.
>> In the contrast of established paper discussion, workshop can discuss
>> about on going materials. Even though we can get information about
>> openEHR related development, face-to-face discussion could share
>> more experience.
>> At this workshop, I think it does not matter what you did, but what you are
>> doing. I wish to share our passion.
>>
>> Regards,
>> Shinji KOBAYASHI
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Regarding new CKM version webservice

[Shinji KOBAYASHI]

I confirmed, the web services working, too.

2013/3/8 Sebastian Garde :
> These 4 webservices should work now as expected (using the /ckm url).
> Sebastian
>
>
> On 07.03.2013 15:58, Sebastian Garde wrote:
>
> Hi Shinji,
>
> I don't think anything has changed there (once it works again).
>
> Regards
> Sebastian
>
> On 07.03.2013 14:43, Shinji KOBAYASHI wrote:
>
> Hi Sebastian,
>
> Thank you.
>
> I use getArchetypeIdsFromPartialId API to query archetypes by key word.
> Does web service APIs change?
>
> Regards,
> Shinji
>
> 2013/3/7 Sebastian Garde :
>
> Hi Shinji,
>
> No, they are certainly not obsolete.
> This was just a curly bracket that moved one up accidentally.
> I have fixed this locally and will be deploy asap.
>
> Cheers
> Sebastian
>
>
> On 07.03.2013 13:36, Shinji KOBAYASHI wrote:
>
> These web service APIs are not wroking now. Are they obsoleted?
> getArchetypeIdsFromPartialId
> getArchetypeIdsFromPartialIdWithPositioning
> getAllArchetypeIds
> getAllArchetypeIdsWithPositioning
>
> I would be very happy, if new APIs are figured.
>
> Regards,
> Shinji
>
> 2013/3/7 Shinji KOBAYASHI :
>
> Thank you, Diego.
>
> getArchetypeIdsFromPartialId API seems not working here, but I will study
> more.
>
> Regards,
>
> 2013/3/7 Diego Bosc? :
>
> Hello all,
>
> Just to warn all potential CKM webservice users, CKM webservice
> endpoint has changed from
> 'http://openehr.org/knowledge/services/.' to
> 'http://openehr.org/ckm/services/..'
> Changing the endpoint solves the problem. The webservice itself seems
> to be the same. Are there any changes planed for it?
>
> Regards
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> --
>
> Dr. Sebastian Garde
> Dr. sc. hum., Dipl.-Inform. Med, FACHI
> Senior Developer
> Ocean Informatics
>
> Skype: gardeseb
>
>
> --
>
> Dr. Sebastian Garde
> Dr. sc. hum., Dipl.-Inform. Med, FACHI
> Senior Developer
> Ocean Informatics
>
> Skype: gardeseb
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> --
>
> Dr. Sebastian Garde
> Dr. sc. hum., Dipl.-Inform. Med, FACHI
> Senior Developer
> Ocean Informatics
>
> Skype: gardeseb

Regarding new CKM version webservice

[Shinji KOBAYASHI]

Hi Sebastian,

Thank you.

I use getArchetypeIdsFromPartialId API to query archetypes by key word.
Does web service APIs change?

Regards,
Shinji

2013/3/7 Sebastian Garde :
> Hi Shinji,
>
> No, they are certainly not obsolete.
> This was just a curly bracket that moved one up accidentally.
> I have fixed this locally and will be deploy asap.
>
> Cheers
> Sebastian
>
>
> On 07.03.2013 13:36, Shinji KOBAYASHI wrote:
>
> These web service APIs are not wroking now. Are they obsoleted?
> getArchetypeIdsFromPartialId
> getArchetypeIdsFromPartialIdWithPositioning
> getAllArchetypeIds
> getAllArchetypeIdsWithPositioning
>
> I would be very happy, if new APIs are figured.
>
> Regards,
> Shinji
>
> 2013/3/7 Shinji KOBAYASHI :
>
> Thank you, Diego.
>
> getArchetypeIdsFromPartialId API seems not working here, but I will study
> more.
>
> Regards,
>
> 2013/3/7 Diego Bosc? :
>
> Hello all,
>
> Just to warn all potential CKM webservice users, CKM webservice
> endpoint has changed from
> 'http://openehr.org/knowledge/services/.' to
> 'http://openehr.org/ckm/services/..'
> Changing the endpoint solves the problem. The webservice itself seems
> to be the same. Are there any changes planed for it?
>
> Regards
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> --
>
> Dr. Sebastian Garde
> Dr. sc. hum., Dipl.-Inform. Med, FACHI
> Senior Developer
> Ocean Informatics
>
> Skype: gardeseb

Regarding new CKM version webservice

[Shinji KOBAYASHI]

These web service APIs are not wroking now. Are they obsoleted?
getArchetypeIdsFromPartialId
getArchetypeIdsFromPartialIdWithPositioning
getAllArchetypeIds
getAllArchetypeIdsWithPositioning

I would be very happy, if new APIs are figured.

Regards,
Shinji

2013/3/7 Shinji KOBAYASHI :
> Thank you, Diego.
>
> getArchetypeIdsFromPartialId API seems not working here, but I will study 
> more.
>
> Regards,
>
> 2013/3/7 Diego Bosc? :
>> Hello all,
>>
>> Just to warn all potential CKM webservice users, CKM webservice
>> endpoint has changed from
>> 'http://openehr.org/knowledge/services/.' to
>> 'http://openehr.org/ckm/services/..'
>> Changing the endpoint solves the problem. The webservice itself seems
>> to be the same. Are there any changes planed for it?
>>
>> Regards
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Regarding new CKM version webservice

[Shinji KOBAYASHI]

Thank you, Diego.

getArchetypeIdsFromPartialId API seems not working here, but I will study more.

Regards,

2013/3/7 Diego Bosc? :
> Hello all,
>
> Just to warn all potential CKM webservice users, CKM webservice
> endpoint has changed from
> 'http://openehr.org/knowledge/services/.' to
> 'http://openehr.org/ckm/services/..'
> Changing the endpoint solves the problem. The webservice itself seems
> to be the same. Are there any changes planed for it?
>
> Regards
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Developers' workshop at MEDINFO2013 in Copenhagen.

[Shinji KOBAYASHI]

Dear guys,

It remains 2 weeks to the deadline of MEDINFO 2013 submission.
I am working on writing a workshop proposal at wiki page.
http://www.openehr.org/wiki/display/resources/The+openEHR+developers%27+workshop+2013%28DRAFT%29
I would be very happy, if you left a comment on this page.

TO speakers of this workshop, please let me know your contents:
* Name
* Affiliation
* Presentation title
* Short summary of you presentation (about 100-300 words)

Please feel free to join us and share our workshop proposal.

Regards,
Shinji KOBAYASHI

2012/11/29 Shinji KOBAYASHI :
> * Name
> * Affiliation
> * Presentation title
> * Summary of you presentation (100-300 words)

translating the openEHR website [From Gunnar Klein]

[Shinji KOBAYASHI]

Hi Thomas,

I forked GitHub web-site project. Can I make /jp sub-directory to work
under top?
Could you please point it out where should be?
Japanese translation would appeal capability of translation much, I will try it.

Regards,
Shinji

2012/12/18 Thomas Beale :
> accountability

translating the openEHR website [From Gunnar Klein]

[Shinji KOBAYASHI]

Hi Thomas and Gunner,

Having translated portal would appeal wider range, especially for beginners.
On the other hand, openEHR.jp site has another accountability as the
domestic
artefacts repository. We can have two sites for their responsibility.

1)http://www.openehr.org/jp/
 Translated version of official openEHR.org site.
2) http://www.openehr.jp/
 Repository of Japanese artefacts, such as translated documents,
presentation/education materials,
seminar information.

My answer to the questions.
1) The workflow on GitHub seems reasonable for me, but we need to try it to
prove that it works.
2) Your suggested URL openehr.org/jp is good for us, Japanese community,
but I think redirection
openehr.org/jp to openehr.jp is not useful as described before.
Localisation has two dimension just
you mentioned, language and geographical location. I do not have good idea
for Spanish community,
but I think it is a common problem for international language community,
even in English.
There are many English speaking countries, but localisation is necessary,
just now Koray is trying.

Regards,
Shinji



2012/12/18 Thomas Beale 

>
>   Subject:
> Re: translating the openEHR website - Also a localised content?
> From:
> "Gunnar Klein, NTNU"  
> Date:
> 17/12/2012 16:47
> To:
>  lists.openehr.org>
> Dear Tom and other techies,
>
> A wonderful idea with translated content and the general work flow
> described sounds feasible to me. However, I think it would make sense not
> to require the various non English language sites to follow exactly the
> master openEHR. Firstly, because it would make sense to launch some content
> in several languages before everything is translated, and in several cases
> I think all the content will never be translated, some of the technical
> stuff will be better read in original English in some countries. However,
> the "LOCALISED" openEHR web pages may also contain material that relates to
> national work, in particular of course as directly related to openEHR
> implementations. Documents may be uploaded in various languages with
> content that it will not always make sense to translate.
>
> Regarding the excellent Japanese initiative, I suggest they should be
> offered to move the content to the main site but with the openEHR.jp as a
> pointing entry. Such sites may be establsiehed in other countries also but
> I think they shall generally not have there own content but be pointers to
> the openEHR.org. Especially where the same language is used in several
> countries and continents it may be a complicated proliferation which in one
> sense is welcome. An offer to one person or a small group of 2-3 persons
> per geographical area to work directly with the openEHR international site
> makes sense to maintain some control over content of the foundation content.
>
> Best regards
>
> Gunnar
>
> On 17/12/2012 15:29, Thomas Beale wrote:
>
>
> we are trying to work out the best approach to translations of the openEHR
> website. The mechanism for the website itself is probably straightforward:
>
>- for each language xx, we create a copy of the current website under
>a directory /xx/, and push this to the Github repo that contains the
>website
> - or perhaps separate repos, one per language?
>- the people who want to do the translation work clone the repo,
>replace the EN text with their language and upload the changes
>- we push the changes to the main website
>
> Most URLs in the website are relative, so this should work. Clearly
> changes on the main website need to be reflected over time on the other
> websites, but we can rely on proper commit comments in the Git repo to take
> care of that.
>
> *First question *- does this seem a reasonable workflow to  adopt?
>
> The *second question *that I can see is: what is the starting URL &
> location? Taking Japan as an example:
>
> Shinji's group already has openEHR.jp. Currently it is their own website.
> However, with a translated form of the international website, would it make
> sense for openEHR.jp to point to www.openEHR.org/jp? If so, then the
> translated international website would need a prominent link back to the
> current openEHR.jp. OR... if they prefer to land on the current openEHR.jp,
> what URL should get a user to www.openEHR.org/jp - presumably just that.
>
> These questions apply to all languages, but not all locations or languages
> equate to a country. For example, if we made www.openEHR.org/es, I am
> sure we only want one of those, even though there can technically be some
> small differences between the Spain / Central & South America variants. But
> there is no openEHR.es and openEHR.org.es (which appears to be taken)
> would correspond to Spain only.
>
> In the end, I think the best we may be able to do is to provide a
> www.openEHR.org/xx for each language translation, and it will be up to
> local openEHR.orgs to add links or Apache rewrite rules to connect to these
> locations. So multiple Spanish-s

Developers' workshop at MEDINFO2013 in Copenhagen.

[Shinji KOBAYASHI]

Hi Nadim,

Thank you for joining us.
I am looking forward to your further inforomation.

Regards
Shinji


2012/12/3 Nadim Anani :
> Dear Shinji,
>
> I would like to join Rong Chen in presenting openEHR-based clinical decision 
> support and will send you the information you asked for below after 
> coordinating with Rong.
>
> Kind regards,
> Nadim
>
>
>
>
> Nadim Anani, MSc, PhD student
> Centrum f?r h?lsoinformatik / Health Informatics Centre (HIC)
> LIME
> Karolinska Institutet
> SE-17177 Stockholm, Sweden
>
> Tel. +46-8-524-83607
> Email: nadim.anani at ki.se
>
> -Original Message-
> From: openEHR-implementers [mailto:openehr-implementers-bounces at 
> lists.openehr.org] On Behalf Of Shinji KOBAYASHI
> Sent: den 28 november 2012 18:33
> To: For openEHR implementation discussions; For openEHR technical discussions
> Subject: Re: Developers' workshop at MEDINFO2013 in Copenhagen.
>
> Dear guys,
>
> I updated wiki page for openEHR developers' workshop at medinfo 2013.
> http://www.openehr.org/wiki/display/resources/The+openEHR+developers%27+workshop+2013%28DRAFT%29
>
> To finish our workshop proposal, could you let me know your information.
> * Name
> * Affiliation
> * Presentation title
> * Summary of you presentation (100-300 words)
>
> Please feel free to join us and share our workshop proposal.
>
>
> Regards
> Shinji KOBAYASHI
>
> 2012/10/17 Erik Sundvall :
>> Hi Shinji and everybody!
>>
>> We have some interesting openEHR developer related things to show from
>> Link?ping University. In addition to our general openEHR REST approach
>> we would be happy to show
>> - how you can support storage and retrieval of post-coordinated
>> terminology bound openEHR data and also
>> - how to create your own EHR visualizations based on AQL and 
>> javascript/HTML5.
>>
>> Daniel Karlsson and I plan to attend the Medinfo workshop (some others
>> from Link?ping may also join later).
>>
>> Best regards,
>> Erik Sundvall
>> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
>>
>>
>> On Thu, Oct 11, 2012 at 9:02 PM, Shinji KOBAYASHI  
>> wrote:
>>> Dear all,
>>>
>>> I am very happy to hear your responses.
>>> I setup MEDINFO 2013 conference wiki and developers' workshop wiki.
>>> http://www.openehr.org/wiki/display/resources/MEDINFO+2013+-+Copenhag
>>> en%2C+Denmark
>>> http://www.openehr.org/wiki/display/resources/The+openEHR+developers%
>>> 27+workshop+2013
>>>
>>> Daniel, thank you very much, you correct my misunderstanding about the 
>>> deadline.
>>> I am very happy to know we have more one month moratorium.
>>> Rong, Ian, Pablo, can you have presentation with us?
>>> If you can, I will ask you your affiliation and session titles.
>>>
>>> Please feel free to join us, guys.
>>>
>>> Regards,
>>> Shinji KOBAYASHI
>>>
>>> ___
>>> openEHR-implementers mailing list
>>> openEHR-implementers at lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.
>>> openehr.org
>>
>> ___
>> openEHR-implementers mailing list
>> openEHR-implementers at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.o
>> penehr.org
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Developers' workshop at MEDINFO2013 in Copenhagen.

[Shinji KOBAYASHI]

Dear guys,

I updated wiki page for openEHR developers' workshop at medinfo 2013.
http://www.openehr.org/wiki/display/resources/The+openEHR+developers%27+workshop+2013%28DRAFT%29

To finish our workshop proposal, could you let me know your information.
* Name
* Affiliation
* Presentation title
* Summary of you presentation (100-300 words)

Please feel free to join us and share our workshop proposal.


Regards
Shinji KOBAYASHI

2012/10/17 Erik Sundvall :
> Hi Shinji and everybody!
>
> We have some interesting openEHR developer related things to show from
> Link?ping University. In addition to our general openEHR REST approach
> we would be happy to show
> - how you can support storage and retrieval of post-coordinated
> terminology bound openEHR data and also
> - how to create your own EHR visualizations based on AQL and javascript/HTML5.
>
> Daniel Karlsson and I plan to attend the Medinfo workshop (some others
> from Link?ping may also join later).
>
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
>
>
> On Thu, Oct 11, 2012 at 9:02 PM, Shinji KOBAYASHI  wrote:
>> Dear all,
>>
>> I am very happy to hear your responses.
>> I setup MEDINFO 2013 conference wiki and developers' workshop wiki.
>> http://www.openehr.org/wiki/display/resources/MEDINFO+2013+-+Copenhagen%2C+Denmark
>> http://www.openehr.org/wiki/display/resources/The+openEHR+developers%27+workshop+2013
>>
>> Daniel, thank you very much, you correct my misunderstanding about the 
>> deadline.
>> I am very happy to know we have more one month moratorium.
>> Rong, Ian, Pablo, can you have presentation with us?
>> If you can, I will ask you your affiliation and session titles.
>>
>> Please feel free to join us, guys.
>>
>> Regards,
>> Shinji KOBAYASHI
>>
>> ___
>> openEHR-implementers mailing list
>> openEHR-implementers at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Developers' workshop at MEDINFO2013 in Copenhagen.

[Shinji KOBAYASHI]

Dear all,

I am very happy to hear your responses.
I setup MEDINFO 2013 conference wiki and developers' workshop wiki.
http://www.openehr.org/wiki/display/resources/MEDINFO+2013+-+Copenhagen%2C+Denmark
http://www.openehr.org/wiki/display/resources/The+openEHR+developers%27+workshop+2013

Daniel, thank you very much, you correct my misunderstanding about the deadline.
I am very happy to know we have more one month moratorium.
Rong, Ian, Pablo, can you have presentation with us?
If you can, I will ask you your affiliation and session titles.

Please feel free to join us, guys.

Regards,
Shinji KOBAYASHI

Developers' workshop at MEDINFO2013 in Copenhagen.

[Shinji KOBAYASHI]

Dear all,

I would like to propose a workshop at the next MEDINFO.
If you are interested in this plan, please reply on this mailing
list or direct to me.
We had two good workshops at MEDINFO in  2007 and 2010.
The coming MEDINFO will be held at 20-23 August 2013.
http://www.medinfo2013.dk/

The paper and proposal deadline is closing, 10 December, 2012.
However, I think we have enough time to discuss to have a good
workshop proposal.
In the contrast of established paper discussion, workshop can discuss
about on going materials. Even though we can get information about
openEHR related development, face-to-face discussion could share
more experience.
At this workshop, I think it does not matter what you did, but what you are
doing. I wish to share our passion.

Regards,
Shinji KOBAYASHI

openEHR terminology - problems and solutions

[Shinji KOBAYASHI]

Hi Thomas and all,

I extracted data sets from XML file and made rails app.
http://openterminology.herokuapp.com/
At this time, data were not protected, but they can be restored as
default anytime.
What about this for translation?

Cheers,
Shinji

2012/6/24 Thomas Beale :
>
> A few weeks ago some of us had a look at the openEHR terminology, and
> identified some of the problems on this wiki page. One of the (obvious)
> conclusions was that the Archetype Editor 'terminology' needs to be its own
> thing, since it is full of GUI terms. The rest of the terminology (derived
> from the openEHR Terminology spec) needs to be treated differently.
>
> In the long term, some of it might be replaced by SNOMED CT terms for some
> of the things like 'participation types'; some of it will remain, and would
> go into an openEHR SNOMED CT extension.
>
> In the shorter term we have to be more pragmatic, and the obvious approach
> seems to be to start from the Java project version of the terminology files,
> now located in the knowledge2 repository.
>
> On inspection of these, there are some obvious errors and shortcomings,
> notably a new 'multimedia types' group in the openEHR terminologies
> containing extra IANA media types (aka MIME types) that should have gone
> into the IANA media types codeset in the other file. We need to address
> these problems ASAP, and I think that can be done simply. We also need to
> decide on the file format, and translation approach. The wiki page gives
> some ideas on this.
>
> The Archetype Editor should therefore start using these standard files for
> the main openEHR vocabularies and codesets, and limit the contents of its
> own terminology to its own (localisable) UI strings & error messages, as for
> any normal application. This probably should morph into the standard i18n
> format for Microsoft applications, rather than maintaining its own form.
>
> - thomas
>
> On 24/06/2012 10:09, Peter Gummer wrote:
>
> pablo pazos wrote:
>
> I have some proposals that might improve some aspects of the AE:
> ...
> - the translation is very poor, how can I translate the GUI terms?
>
> That would be great, Pablo.
>
> Under the directory where Archetype Editor is installed, there's a directory
> called "Terminology". You can edit the terminology.xml that you find there.
> It's pretty straightforward to edit the XML directly, but there's a program
> called openEHR_Translation.exe in the same directory which you'll probably
> find makes it easier.
>
> If you send me your improved copy of terminology.xml, I'll commit your
> changes to the Archetype Editor Subversion repository.
>
>
> - is there some way to do a search on the AE GUI that consumes a search
> service on the CKM to find, download and edit/specialize archetypes from the
> CKM directly from the AE?
>
> In the Tools | Options dialog, select the File Locations tab. Turn on the
> "Enable Internet Search" check box. (The URL should be
> http://openehr.org/knowledge/services/ArchetypeFinderBean?wsdl)
>
> Then, under the File menu, you'll see an option to "Open from Web?" This
> allows you to get archetypes directly from CKM.
>
> Peter
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

How about creating an openEHR test base?

[Shinji KOBAYASHI]

Hi Pablo, Seref and all,

I think many implementation on the same API would make competitive and
innovative environment.
While re-invention of wheel is considered as waste of time,
implementation by many ways
sometimes makes innovation. Ruby on Rails is a web development
framework, which affect
many development framework, but web frameworks has been generated
before/after RoR.
All of them aim to product Web with ease, but approaches are not same.
I am glad to have
such environment with you on the openEHR.
Licensing is a sensitive matter to share artefacts. It subjects not
only code bases, but also on
API like Oracle/Google issues.
However, my artefacts are under Apache 2.0 or other open licenses.

Cheers,
Shinji.

2012/5/11 pablo pazos :
> Hi guys,
>
> Seref, I was thinking a lot about what you said "There are various bits of
> functionality implemented in different projects...", and that rang a bell
> somewhere.
>
> I think we are implementing the same things again and again because the
> technology we choose can't handle what is already implemented, and I believe
> this is a great opportunity to start creating common services providing this
> funcionality to our systems, so we only implement service clients not the
> same functionality in an alternative way.
>
> There is a great deal of functionality developed by Rong & company (and
> other projects, .Net, Ruby, ...), and some of the functionality can be
> exposed as public services somewhere (like archetype flattening, AOM 2 ADL
> serialization, RM 2 XML serialization, etc.).
>
> Is there some posibility that the foundation could host those services?
> What do you think?
>
>
> I'm willing to dedicate time to this, because I think this will be
> beneficial for all (also for creating the proposed "test set" that started
> this topic).
>
> --
> 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
>
> 
> Date: Tue, 8 May 2012 08:52:04 +0100
>
> Subject: Re: How about creating an openEHR test base?
> From: serefarikan at kurumsalteknoloji.com
> To: openehr-technical at lists.openehr.org
>
>
> Interesting point again. There are various bits of functionality implemented
> in different projects, but the projects have different open source licences.
> I'm not Rong of course, but his code uses mpl, and since I've used his code
> when I started Operaffa, Opereffa is mpl too (though it'll be apache very
> soon).
> So you'd need to check how licensing issues need to be handled if you use
> Rong's code, assuming your work is not under mpl.
>
> I think you've touched another important point Pablo
>
> Kind regards
> Seref
>
>
> On Mon, May 7, 2012 at 10:37 PM, pablo pazos  
> wrote:
>
> Hi Rong,
>
> That's great news, but we have our own RM implementation because it handles
> ORM too.
> But I think I can adapt your xml-binding component to use our RM impl, what
> do you think?
>
>
> --
> 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
>
>> Date: Mon, 7 May 2012 21:08:57 +0200
>
>> Subject: Re: How about creating an openEHR test base?
>> From: rong.acode at gmail.com
>> To: openehr-technical at lists.openehr.org
>
>>
>> On 7 May 2012 16:39, pablo pazos  wrote:
>> > Hi Seref, I've a tool that generates composition instances from
>> > archetypes
>> > and data, what I don't have is a way to generate a valid XML form from
>> > those
>> > compositions.
>> >
>>
>> Hi Pablo,
>> The xml-binding component in the Java reference implementation does
>> just that. It binds RM object instance to generated XML objects that
>> can be serialized according to published XSD.
>> /Rong
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> ___ openEHR-technical mailing
> list openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

openEHR on GitHub (was Re: How about creating an openEHR test base?)

[Shinji KOBAYASHI]

Hi Thomas Beale,

Our, Ruby implementation repository has already moved on GitHub for
our convenience
last year for our convenience.
I was wondering if we could move our repository under
github://openehr/ruby-impl-openhr.
It would be comprehensive rather than under skoba/ruby-impl-openehr
for publicity.

Regards,
Shinji Kobayashi

2012/5/7 Thomas Beale :
>
> yes, we will obviously migrate over to Github in the coming months. I have a
> slight concern about how to avoid chaos, and I do think we need to think
> carefully about how we organise Git projects/subprojects in general. The
> openEHR terminology is not large (at all), but looks like it will become
> more than one file, according to a discussion the other day (I will write
> this up and post it before doing anything), but I was thinking it needs to
> be part of a broader openEHR knowledge repository. Although... I have listed
> it as a distinct 'component' of the specification program - maybe it should
> have its own repository anyway. Translations of it will multiply the number
> of files substantially as time goes on, so that is another reason perhaps
> for a separate repository.
>
> I think test archetypes & templates probably should be separate from test &
> example data, so that is two repositories right there. That would give us:
>
> open terminology
> test archetypes & templates
> test & example data
>
> We need to add existing active software projects:
>
> Java ref implem project
> ADL Workbench
> (Ocean) Archetype Editor
> Opereffa
>
> Not sure about the following:
>
> LiU modelling tools
>
> Ruby I think is on its own repository; the Python implementation I believe
> is no longer openEHR, but some kind of custom fork in its own repositories.
> openEHR on .Net is on codeplex.
>
> Any others?
>
> - thomas
>
>
> On 07/05/2012 10:55, Erik Sundvall wrote:
>
> Hi Tom!
>
> Could we use the openEHR github project (that you registered) for
> hosting a subproject with the openEHR Terminology? I believe it can
> make ongoing branching/patching more visible and easier to
> merge/administrate.
>
> There is no hurry to move existing test-archetypes there, but for new
> efforts (terminology, RM-instance-examples etc) me might as well start
> there (perhaps as a separate subproject).
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Suggestion to replace use of generics with inheritence in future RM versions

[Shinji KOBAYASHI]

Hi Peter,

2012/3/22 Peter Gummer :
> Shinji KOBAYASHI wrote:
>
>> Ruby implementation might be one of the proof for replace of generics.
>> I had much struggled to implement generics and got the conclusion
>> that we do not need it.
> Ruby doesn't have generics at all, right, Shinji?

It is right. I felt generics is very convenient, when I used Java, such as

 Iterator it = someRmArrayInstance.iterator()

But I found it must be cut off by 'Occam's razor' in Ruby.

 it = some_rm_array.iterator

This code looks curious for Java/Eiffel/C# user who are similar to generics,
but it is enough for encapsulated object instance.
I think this depends on language environment, but nested generics seems
complicated codes for me.

 List >

Generics is useful to declare what instance is, but it breaks encapsulation.
As regards to Bartrand Meyer's paper, 'a good balance' is a good design.

Cheers,
Shinji

> There's a comparison of generics and inheritance in an appendix of Bertrand 
> Meyer's "Object Oriented Software Construction", 2nd edition. 
> (http://se.ethz.ch/~meyer/publications/acm/geninh.pdf seems to be the 
> original paper that the appendix is based upon.)
>
> Generics can be simulated in a language with inheritance, but there is a cost:
> * Duplication of code.
> * Extra verbosity.
>
> I don't want to have either forced upon me. If I'm unfortunately forced to 
> use a language that doesn't support generics, then I can always simulate it 
> the generics with inheritance. But I certainly wouldn't want the specs to be 
> obfuscated by hacks like that, thanks very much ;-)
>
> Peter
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Suggestion to replace use of generics with inheritence in future RM versions

[Shinji KOBAYASHI]

Hi Seref,

Ruby implementation might be one of the proof for replace of generics.
I had much struggled to implement generics and got the conclusion
that we do not need it. I felt low latency between UK and Japan!
However, inheritance could be harmful, because it has too tight restriction
for changes. Interface would be better.

Cheers,
Shinji(50msec latency)

2012/3/21 Seref Arikan :
> Greetings,
> Looking at the UML page Tom has posted a few minutes ago made me remember
> something I had in mind for some time.
>
> With hope of avoiding any flame wars and attempts to discuss elegance of
> various approaches in OO approach, may I suggest that the specs use
> inheritence instead of generics in the future? This is purely based on the
> current state of some key technologies.
>
> At the moment XSD has no generics support and Java's generics (or
> parameterized types) support has a feature (read: problem) called type
> erasure.
> XSD is the basis for both system to system and tool to tool communication,
> and that will not change for a significant time. So XSD based
> marshalling/unmarshalling to code will be reality for a while.
>
> Java is.. well it is Java, and its handling of generics won't change for at
> least a few more years. Most uses of the generics seem to use upper bounds
> for type parameters, so those cases should not be too hard to replace with
> inheritance with the upper bound as the type of fields that use generics at
> the moment. For unbounded type parameters (which are rare) we could define
> some assumed types in the implementing systems and either use an abstract
> class or find another workaround. That'd be a nice OO practice.
>
> This is a note I wanted to write somewhere. It may cause issues in terms of
> existing code bases and data, it may not be worth the effort, but in a world
> where algorithmic stock trading can justify a $1.5 billion cable between
> London and Tokyo to improve latency by 60ms, I should have the luxury of
> leaving my mark about this design choice (
> http://www.extremetech.com/extreme/122989-1-5-billion-the-cost-of-cutting-london-toyko-latency-by-60ms
> )
>
> Kind regards
> Seref
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL

[Shinji KOBAYASHI]

Hi Sam,

As regards to world-wide economic recession, getting fund for R&D
is far difficult.
I am challenging some funds from our government or funds in Japan,
such as this.
http://www.jsps.go.jp/english/e-meeting/index.html
This fund aims to support conference in Japan, but I think it would be
better in Singapore or Kuala Lumpur with less cost.
However, lottery might be more promising. sigh.

Regards,
Shinji

2012/3/19 Sam Heard :
> Hi Shinji
>
> We could not get sponsorship for the conference, which is a shame. For that
> reason it looks like that will not happen until we have Associates and some
> core funding.
>
> I would like to organise some Google handouts at different times each month
> - probably 3/month suiting Asia, Europe/Africa and the Americas. Would
> others be interested in meeting for a chat every month, with Video. We could
> use GoToWebinar for some more formal gatherings.
>
> Cheers, Sam
>
>> -Original Message-
>> From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
>> technical-bounces at lists.openehr.org] On Behalf Of Shinji KOBAYASHI
>> Sent: Friday, 2 March 2012 10:40 AM
>> To: For openEHR technical discussions
>> Subject: Re: openEHR conference - proposal for Lake Bled, Slovenia 2012
>> - POLL
>>
>> Hi all,
>>
>> Can I resume this topic?
>> I am much looking forward to meeting this conference.
>> I know there are many problems, but just to do it very great for us.
>>
>> Regards,
>> Shinji
>>
>> 2012/1/13 Thomas Beale :
>> > On 13/01/2012 08:14, Ian McNicoll wrote:
>> >> I do like the idea but I would prefer that each conference has its
>> >> own very clear identity, albeit that some sessions could be shared,
>> >> along with venue etc. A couple of the MIE conferences have operated
>> >> this way with local informatics conferences being co-hosted/located
>> >> with the European event, with some joint sessions but otherwise a
>> >> very clear individual agenda and focus.
>> >>
>> >
>> > Right - that could be a solution.
>> >
>> > - thomas
>> >
>> > ___
>> > openEHR-technical mailing list
>> > openEHR-technical at openehr.org
>> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL

[Shinji KOBAYASHI]

Hi all,

Can I resume this topic?
I am much looking forward to meeting this conference.
I know there are many problems, but just to do it very great for us.

Regards,
Shinji

2012/1/13 Thomas Beale :
> On 13/01/2012 08:14, Ian McNicoll wrote:
>> I do like the idea but I would prefer that each conference has its own
>> very clear identity, albeit that some sessions could be shared, along
>> with venue etc. A couple of the MIE conferences have operated this way
>> with local informatics conferences being co-hosted/located with the
>> European event, with some joint sessions but otherwise a very clear
>> individual agenda and focus.
>>
>
> Right - that could be a solution.
>
> - thomas
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

https://github.com/openEHR

[Shinji KOBAYASHI]

Hi all,

GitHub is very good site to incubate source codes.
Anyone can fork source codes, commit and merge them.
As Ian mentioned, I have thought GitHub could be a incubation
repository for archetypes, which were premature than CKM repository.
However, license issue must be fixed to do, at first. Apache 2.0 license
is very good.

Best regards,
Shinji

2012/3/2 Ian McNicoll :
> Excellent. I was just thinking yesterday that as well as regularly
> outputting CKM to a Git repository, we also ought to bring together
> other legacy material e.g the NHS and any other artefacts people want
> to share e.g some of the vendor-developed archetypes that I have been
> working on but which are very suitable for wider use.
>
> We will need to clearly differentiate repositories which are inert,
> from those which are active but uncontrolled, and those which are
> tightly governed - the latter will not really exist until we have
> proper namespacing established.
>
> As far as the openEHR CKM repository is concerned, given current
> development schedules, an automated update to Github is unlikely to
> appear any time soon but I will commit to doing so manually on a
> regular basis or when any significant changes occur e.g new uploads or
> publications.
>
> Ian
>
>
>
> On 1 March 2012 16:19, Thomas Beale  
> wrote:
>>
>> yep, it's me, I forgot to set anything up. For the moment I am sole member
>> and admin. We might need a little bit of planning about how to use the
>> openEHR space I think - I am just thinking of how to make sure we have a
>> fairly comprehensible (to outsiders) Github presence, while of course
>> allowing open use.
>>
>> Once the software group gets a plan together, let me know and I will add
>> some other admins etc.
>>
>> - thomas
>>
>>
>> On 01/03/2012 15:45, Erik Sundvall wrote:
>>
>> Hi!
>>
>> I found that somebody had registered openEHR as organisation name on
>> Github, good!
>> https://github.com/openEHR
>>
>> Now I just wonder who is the admin since the site does not say it.
>>
>> I know that I hinted to Tom a long time ago that it would be worth
>> getting the org name reserved there, are you the admin Tom?
>>
>> Perhaps we could try to get several openEHR projects connected to the
>> organisation account (after some discussion first of course).
>>
>> Best regards,
>> Erik Sundvall
>> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
>>
>> P.s. Software interested tech-list subscribers, make sure you are also
>> subscribed to...
>> openehr-implementers at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>> ...since that is where the "software program" of openEHR is going to
>> host discussion according to board decisions.
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> --
> Dr Ian McNicoll
> office +44 (0)1536 414 994
> fax +44 (0)1536 516317
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
>
> Clinical Modelling Consultant,?Ocean Informatics, UK
> Director/Clinical Knowledge Editor openEHR Foundation 
> ?www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> SCIMP Working Group, NHS Scotland
> BCS Primary Health Care ?www.phcsg.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Did anybody implement AQL with a LL parser framework?

[Shinji KOBAYASHI]

Hi Seref and Thomas,

This is a piece of work of Prof Subash Bhalla Laboratory in Aizu
university in Japan.
http://www.u-aizu.ac.jp/e-intro/e-faculty/e-undergraduate/e-undergraduate3/e-bhalla.html
They use Scala with Java library.(not Ruby ;)
I can refer you to them anytime.

Cheers,
Shinji

2012/2/5 Seref Arikan :
> Shinji,
> Great piece of work! Did I miss that bit in the AQL specs, or are you
> supporting some functions of your own, such as devide?
>
>
> On Sun, Feb 5, 2012 at 7:53 AM, Shinji KOBAYASHI  wrote:
>>
>> Hi Seref,
>>
>> This is the demo site for AQBE dynamic query generation.
>> http://wako3.u-aizu.ac.jp:8080/aqbe/
>> It is wonderful.
>>
>> Regards,
>> Shinji
>>
>> 2012/1/5 Seref Arikan :
>> > Thanks Shinji,
>> > In general, Antlr has some convenient features, infinite lookahead being
>> > one
>> > of them. I've quickly checked, and Treetop does not seem to support left
>> > recursion either. So you must have modified the grammar to make it work.
>> > I'm referring to grammar rules such as
>> > A : A | B;
>> >
>> > Tom made the point earlier. At one point it would be good to unify
>> > various
>> > AQL implementation experiences. I'll check out the papers.
>> >
>> > Best regards
>> > Seref
>> >
>> >
>> >
>> > On Thu, Jan 5, 2012 at 2:21 AM, Shinji KOBAYASHI 
>> > wrote:
>> >>
>> >> Hi Seref,
>> >>
>> >> My ADL parser does not include AQL parsing.
>> >> I used Treetop, which is an Ruby implementation of PEG/Packrat parsing
>> >> algorithm,
>> >> not LL/LR. PEG/Packrat parser algorithm was described in this paper.
>> >> http://bford.info/pub/lang/packrat-icfp02/
>> >>
>> >> Antlr is an implementation of PEG parser by LL techniques. I do not
>> >> know Antlr so much.
>> >>
>> >> Packrat parser does not need to separate scanner/parser/lexer and is
>> >> capable to
>> >> infinite look ahead recursive.
>> >>
>> >> I do not know why are you parsing AQL, but this proceeding about
>> >> querying
>> >> EHR
>> >> by archetype might be helpful for your research.
>> >> http://web-ext.u-aizu.ac.jp/labs/sw-db/7108/71080109.pdf
>> >>
>> >> Best regards,
>> >> Shinji
>> >>
>> >> 2012/1/5 Seref Arikan :
>> >> > Greetings,
>> >> > The AQL grammar from the wiki has direct and indirect left recursion.
>> >> > Which
>> >> > means without changes in the grammar, LL parser generators (both
>> >> > JavaCC
>> >> > and
>> >> > Anltr) can't generate parsers for this grammar.
>> >> >
>> >> > I'm curious if anybody has refactored this grammar for LL parser
>> >> > generators.
>> >> > Shinji? Your latest release includes an AQL parser does not it? Could
>> >> > you
>> >> > please share your method? I can always look at the code, but you'd
>> >> > probably
>> >> > save me time :)
>> >> >
>> >> > I'm interested in experiences of others too.
>> >> >
>> >> >
>> >> > Kind regards
>> >> > Seref
>> >> >
>> >> >
>> >> > ___
>> >> > openEHR-technical mailing list
>> >> > openEHR-technical at openehr.org
>> >> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>> >> >
>> >> ___
>> >> openEHR-technical mailing list
>> >> openEHR-technical at openehr.org
>> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>> >
>> >
>> >
>> > ___
>> > openEHR-technical mailing list
>> > openEHR-technical at openehr.org
>> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>> >
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>

Did anybody implement AQL with a LL parser framework?

[Shinji KOBAYASHI]

Hi Seref,

This is the demo site for AQBE dynamic query generation.
http://wako3.u-aizu.ac.jp:8080/aqbe/
It is wonderful.

Regards,
Shinji

2012/1/5 Seref Arikan :
> Thanks Shinji,
> In general, Antlr has some convenient features, infinite lookahead being one
> of them. I've quickly checked, and Treetop does not seem to support left
> recursion either. So you must have modified the grammar to make it work.
> I'm referring to grammar rules such as
> A : A | B;
>
> Tom made the point earlier. At one point it would be good to unify various
> AQL implementation experiences. I'll check out the papers.
>
> Best regards
> Seref
>
>
>
> On Thu, Jan 5, 2012 at 2:21 AM, Shinji KOBAYASHI  wrote:
>>
>> Hi Seref,
>>
>> My ADL parser does not include AQL parsing.
>> I used Treetop, which is an Ruby implementation of PEG/Packrat parsing
>> algorithm,
>> not LL/LR. PEG/Packrat parser algorithm was described in this paper.
>> http://bford.info/pub/lang/packrat-icfp02/
>>
>> Antlr is an implementation of PEG parser by LL techniques. I do not
>> know Antlr so much.
>>
>> Packrat parser does not need to separate scanner/parser/lexer and is
>> capable to
>> infinite look ahead recursive.
>>
>> I do not know why are you parsing AQL, but this proceeding about querying
>> EHR
>> by archetype might be helpful for your research.
>> http://web-ext.u-aizu.ac.jp/labs/sw-db/7108/71080109.pdf
>>
>> Best regards,
>> Shinji
>>
>> 2012/1/5 Seref Arikan :
>> > Greetings,
>> > The AQL grammar from the wiki has direct and indirect left recursion.
>> > Which
>> > means without changes in the grammar, LL parser generators (both JavaCC
>> > and
>> > Anltr) can't generate parsers for this grammar.
>> >
>> > I'm curious if anybody has refactored this grammar for LL parser
>> > generators.
>> > Shinji? Your latest release includes an AQL parser does not it? Could
>> > you
>> > please share your method? I can always look at the code, but you'd
>> > probably
>> > save me time :)
>> >
>> > I'm interested in experiences of others too.
>> >
>> >
>> > Kind regards
>> > Seref
>> >
>> >
>> > ___
>> > openEHR-technical mailing list
>> > openEHR-technical at openehr.org
>> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>> >
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>

openEHR mailing lists - moving

[Shinji KOBAYASHI]

Hi Tom,

Yes, learning cost is very important. The reason why I am moving my Ruby works
to GitHub is learning and maintenance cost.
The most attractive point in Launchpad is translation related
features, but I think
it does not matter.
Thank you for your reply.

Regards,
Shinji

2012/1/25 Thomas Beale :
> On 24/01/2012 02:53, Shinji KOBAYASHI wrote:
>> Hi Tom,
>>
>> What about launchpad? (http://launchpad.net)
>> I think launchpad has enough features as you mentioned.
>>
>> Cheers,
>> Shinji
>
> It may well. I personally don't have experience of using more than a
> couple of the available technologies, so we need community members help
> to make such decisions.
>
> There is no strict necessity for all software projects to be in the same
> place, but if they are all in different places, it obviously makes
> supplying any common adminstrative and educational support more
> difficult. E.g. let's say for example we decided to stick with Atlassian
> for everything, then everyone could learn Jira via some webinars. If
> some or all projects are on Github, then people on those projects can
> help teach each other about using those environments.
>
> One thing I do know is that the work of learning how to use these kinds
> of environments should not be under-estimated.
>
> - thomas
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR mailing lists - moving

[Shinji KOBAYASHI]

Hi Tom,

What about launchpad? (http://launchpad.net)
I think launchpad has enough features as you mentioned.

Cheers,
Shinji

2012/1/20 Thomas Beale :
> On 20/01/2012 11:10, Koray Atalag wrote:
>
> Hi Tom,
>
>
>
> I used SourceForge before to host projects (yes that?s correct not just
> software development but collaborative project sites) in past which offers
> for free lists and many more, such as Web pages, SVN/Mercurial, blog and
> Wiki and many more. I reckon the licensing might be an issue for non FOSS
> projects but I believe in the case of openEHR that?s a non issue?? I must
> admit the SVN is not as fast and there?s limited administration capability
> but hey it?s still great value for nothing. Plus the platform also allows
> for ?donations? which I think might create few bucks to look after things
> like administration etc. until an appropriate funding mechanism becomes
> available.
>
>
>
> Cheers,
>
>
>
>
> some of us have been thinking of moving to Github for software development.
> This is more modern than SVN, but essentially the same idea. Now that you
> mention it, I think the lists in such a place might actually be a good
> enough replacement for the technology / project specific lists we have, i.e.
> java, Eiffel, .Net and so on.
>
> It would be interesting to know what the interest is in moving to GIT,
> staying with SVN, doing something else, etc is.
>
> However, we still have some main community lists which have large
> memberships, are not attached to any particular project, and have to have
> good admin and spam management, so (as a part-time admin) I am very loathe
> to let go of mailman lists for these. This applies to openehr-technical,
> openehr-clinical, openehr-announce, openehr-implementers,
> openehr-decisionsupport and the forthcoming openehr-13606 lists - 6 in all.
> The above strategy would mean we can locate the java / python / ruby /
> eiffel / .Net lists on GIT / other FOSS sites, so it certainly helps.
>
> Further thoughts?
>
> - thomas
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>

Did anybody implement AQL with a LL parser framework?

[Shinji KOBAYASHI]

P.S.
I leaned much from Andrew W. Appel, the chapter 3 of "Modern Compiler
Implementation in ML"

2012/1/5 Shinji KOBAYASHI :
> Hi Seref,
>
> Left recursive rule is theoretically rewrite to equivalent right recursive.
> In ADL grammar, cADL has left recursive rule that cannot be parsed by LL,
> so I converted them to right recursive rules.
> For example of left recursive to explain(shorten for convenience)
>
> arithmetic_expression:
> ? arithmetic_leaf
> | arithmetic_node
>
> arithmetic_node:
> ?arithmetic_expression '+' arithmetic_leaf
> |...
>
> arithmetic_leaf:
> ?(an arithmetic element)
>
> I converted this grammar to this right recursive rule.
>
> arithmetic_expression:
> ? arithmetic_leaf
> | arithmetic_node
>
> arithmetic_node:
> ?arithmetic_leaf ?'+' arithmetic_expression
> |...
>
> These conversions were the most tough points.
> I wish I could help you.
>
> Regards,
> Shinji
>
> 2012/1/5 Seref Arikan :
>> Thanks Shinji,
>> In general, Antlr has some convenient features, infinite lookahead being one
>> of them. I've quickly checked, and Treetop does not seem to support left
>> recursion either. So you must have modified the grammar to make it work.
>> I'm referring to grammar rules such as
>> A : A | B;
>>
>> Tom made the point earlier. At one point it would be good to unify various
>> AQL implementation experiences. I'll check out the papers.
>>
>> Best regards
>> Seref
>>
>>
>>
>> On Thu, Jan 5, 2012 at 2:21 AM, Shinji KOBAYASHI  wrote:
>>>
>>> Hi Seref,
>>>
>>> My ADL parser does not include AQL parsing.
>>> I used Treetop, which is an Ruby implementation of PEG/Packrat parsing
>>> algorithm,
>>> not LL/LR. PEG/Packrat parser algorithm was described in this paper.
>>> http://bford.info/pub/lang/packrat-icfp02/
>>>
>>> Antlr is an implementation of PEG parser by LL techniques. I do not
>>> know Antlr so much.
>>>
>>> Packrat parser does not need to separate scanner/parser/lexer and is
>>> capable to
>>> infinite look ahead recursive.
>>>
>>> I do not know why are you parsing AQL, but this proceeding about querying
>>> EHR
>>> by archetype might be helpful for your research.
>>> http://web-ext.u-aizu.ac.jp/labs/sw-db/7108/71080109.pdf
>>>
>>> Best regards,
>>> Shinji
>>>
>>> 2012/1/5 Seref Arikan :
>>> > Greetings,
>>> > The AQL grammar from the wiki has direct and indirect left recursion.
>>> > Which
>>> > means without changes in the grammar, LL parser generators (both JavaCC
>>> > and
>>> > Anltr) can't generate parsers for this grammar.
>>> >
>>> > I'm curious if anybody has refactored this grammar for LL parser
>>> > generators.
>>> > Shinji? Your latest release includes an AQL parser does not it? Could
>>> > you
>>> > please share your method? I can always look at the code, but you'd
>>> > probably
>>> > save me time :)
>>> >
>>> > I'm interested in experiences of others too.
>>> >
>>> >
>>> > Kind regards
>>> > Seref
>>> >
>>> >
>>> > ___
>>> > openEHR-technical mailing list
>>> > openEHR-technical at openehr.org
>>> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>> >
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical at openehr.org
>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>

Did anybody implement AQL with a LL parser framework?

[Shinji KOBAYASHI]

Hi Seref,

Left recursive rule is theoretically rewrite to equivalent right recursive.
In ADL grammar, cADL has left recursive rule that cannot be parsed by LL,
so I converted them to right recursive rules.
For example of left recursive to explain(shorten for convenience)

arithmetic_expression:
   arithmetic_leaf
| arithmetic_node

arithmetic_node:
  arithmetic_expression '+' arithmetic_leaf
|...

arithmetic_leaf:
 (an arithmetic element)

I converted this grammar to this right recursive rule.

arithmetic_expression:
   arithmetic_leaf
| arithmetic_node

arithmetic_node:
  arithmetic_leaf  '+' arithmetic_expression
|...

These conversions were the most tough points.
I wish I could help you.

Regards,
Shinji

2012/1/5 Seref Arikan :
> Thanks Shinji,
> In general, Antlr has some convenient features, infinite lookahead being one
> of them. I've quickly checked, and Treetop does not seem to support left
> recursion either. So you must have modified the grammar to make it work.
> I'm referring to grammar rules such as
> A : A | B;
>
> Tom made the point earlier. At one point it would be good to unify various
> AQL implementation experiences. I'll check out the papers.
>
> Best regards
> Seref
>
>
>
> On Thu, Jan 5, 2012 at 2:21 AM, Shinji KOBAYASHI  wrote:
>>
>> Hi Seref,
>>
>> My ADL parser does not include AQL parsing.
>> I used Treetop, which is an Ruby implementation of PEG/Packrat parsing
>> algorithm,
>> not LL/LR. PEG/Packrat parser algorithm was described in this paper.
>> http://bford.info/pub/lang/packrat-icfp02/
>>
>> Antlr is an implementation of PEG parser by LL techniques. I do not
>> know Antlr so much.
>>
>> Packrat parser does not need to separate scanner/parser/lexer and is
>> capable to
>> infinite look ahead recursive.
>>
>> I do not know why are you parsing AQL, but this proceeding about querying
>> EHR
>> by archetype might be helpful for your research.
>> http://web-ext.u-aizu.ac.jp/labs/sw-db/7108/71080109.pdf
>>
>> Best regards,
>> Shinji
>>
>> 2012/1/5 Seref Arikan :
>> > Greetings,
>> > The AQL grammar from the wiki has direct and indirect left recursion.
>> > Which
>> > means without changes in the grammar, LL parser generators (both JavaCC
>> > and
>> > Anltr) can't generate parsers for this grammar.
>> >
>> > I'm curious if anybody has refactored this grammar for LL parser
>> > generators.
>> > Shinji? Your latest release includes an AQL parser does not it? Could
>> > you
>> > please share your method? I can always look at the code, but you'd
>> > probably
>> > save me time :)
>> >
>> > I'm interested in experiences of others too.
>> >
>> >
>> > Kind regards
>> > Seref
>> >
>> >
>> > ___
>> > openEHR-technical mailing list
>> > openEHR-technical at openehr.org
>> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>> >
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>

Did anybody implement AQL with a LL parser framework?

[Shinji KOBAYASHI]

Hi Seref,

My ADL parser does not include AQL parsing.
I used Treetop, which is an Ruby implementation of PEG/Packrat parsing
algorithm,
not LL/LR. PEG/Packrat parser algorithm was described in this paper.
http://bford.info/pub/lang/packrat-icfp02/

Antlr is an implementation of PEG parser by LL techniques. I do not
know Antlr so much.

Packrat parser does not need to separate scanner/parser/lexer and is capable to
infinite look ahead recursive.

I do not know why are you parsing AQL, but this proceeding about querying EHR
by archetype might be helpful for your research.
http://web-ext.u-aizu.ac.jp/labs/sw-db/7108/71080109.pdf

Best regards,
Shinji

2012/1/5 Seref Arikan :
> Greetings,
> The AQL grammar from the wiki has direct and indirect left recursion. Which
> means without changes in the grammar, LL parser generators (both JavaCC and
> Anltr) can't generate parsers for this grammar.
>
> I'm curious if anybody has refactored this grammar for LL parser generators.
> Shinji? Your latest release includes an AQL parser does not it? Could you
> please share your method? I can always look at the code, but you'd probably
> save me time :)
>
> I'm interested in experiences of others too.
>
>
> Kind regards
> Seref
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>

Outcomes & conclusions of the openEHR course in spanish (& ideas for the future)

[Shinji KOBAYASHI]

Hi Pablo, and all

I perfectly agree your idea. I have thought as you mentioned.
I am planning my tool-chains on my Ruby implementation, too.
Certification criteria are very difficult to evaluate. Training course
would be a homework to localize.

Shinji Kobayashi

2012/1/4 pablo pazos :
> Hi everyone,
>
> Recently we have ended the first edition of the course with a huge success.
> And now we are thinking about the next steps to take.
>
> Here is a post on my blog about the conclusions and future
> actions:?http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.html
> (yo can see it in english by clicking ENGLISH on the top right corner of the
> blog).
>
>
> I want to share with the community a couple of ideas mentioned there. It
> would be very nice to know what you think.
>
> openEHR certification:
>
> The first idea is on standarizing openEHR training, and to think about an
> openEHR certification. I think this could be very good for the community and
> for the openEHR organization too.
>
> It could be possible to create a mail list for openEHR trainers
> (openehr-trainers at openehr.org)? So we could discuss about the topics and
> ways of evaluation, and come out with an standard minimal program to all
> openEHR courses.
>
> If we reach a standard minimal program for openEHR courses, could we get
> formal support from openEHR.org to issue internationally valid openEHR
> certificates? (obviously this is a question for the future, but IMO we need
> to start thinking about it now).
>
>
> 10 projects to adopt openEHR:
>
> We thought about 10 projects (or so) in two areas: software and clinical
> modeling.
>
> Because openEHR propose a tool-chain based process of creating EHRs, we need
> to have each one of the links of that chain in order to adopt and implement
> openEHR easily.
>
> Now there is a little tooling available, and some of it is not open source.
> In projects at a national level we need to use open source software, because
> each country will need to make it's own customizations to each tool.
>
> In the other hand, we need to model other things that are clinical knowledge
> too, like processes and rules to enable CDS, in order to support full EHR
> implementation (e.g. I think we could recommend ways to express rules based
> on archetype ids and paths, and create software tools to support that
> specification, but we need to work the openEHR services specs first).
>
> There is a diagram on my blog post that shows the tools we propose to 1.
> develope if there is no tool that support its functionality or it's
> closed-source, 2. improve the current open source tools.
>
> On the clinical modeling side, we have engaged doctors and nurses on the
> creation and translation of archetypes. Now there are two of our students
> that already commited archetypes to the CKM: Dr. Domingo Liotta and Dr.
> Leonardo Der Jachadurian.
>
> I hope we could propose to create prototypes of those projects in out local
> universities and coordinate the projects so we do not overlap each other,
> with the objective of completing the tool chain with open source
> developments.
>
>
>
> What do you think?
>
>
> --
> 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
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

[openEHR-announce] CIMI group goes with openEHR archetypes & UML profile

[Shinji KOBAYASHI]

Just translated to Japanese.
http://openehr.jp/news/19

Cheers,
Shinji

2011/12/14 Stef Verlinden :
> Congratulations to all who made this possible and to ourselves
>
> This is a crucial 'breaktrough' which will pave the way towards future proof
> health records which will be widely accepted and used.
>
>
> Cheers,
>
>
> Stef
>
> Begin doorgestuurd bericht:
>
> Van: Thomas Beale 
> Onderwerp: [openEHR-announce] CIMI group goes with openEHR archetypes & UML
> profile
> Datum: 14 december 2011 10:38:14 GMT+01:00
> Aan: openehr-announce 
>
> [press release from the CIMI group]
>
> The Clinical Information Modeling Initiative is an international
> collaboration that is dedicated to providing a common format for detailed
> specifications for the representation of health information content so that
> semantically interoperable information may be created and shared in health
> records, messages and documents. CIMI has been holding meetings in various
> locations around the world since July, 2011. All funding and resources for
> these meetings have been provided by the participants. At its most recent
> meeting in London, 29 November - 1 December 2011, the group agreed on the
> following principles and approach.
>
> Principles
>
> 1.?CIMI specifications will be freely available to all. The initial use
> cases will focus on the requirements of organisations involved in providing,
> funding, monitoring or governing healthcare and to providers of healthcare
> IT and healthcare IT standards as well as to national eHealth programs,
> professional organisations, health providers and clinical system developers.
>
> 2.?CIMI is committed to making these specifications available in a number of
> formats, beginning with the Archetype Definition Language (ADL) from the
> openEHR Foundation (ISO 13606.2) and the Unified Modeling Language (UML)
> from the Object Management Group (OMG) with the intent that the users of
> these specifications can convert them into their local formats.
>
> 3.?CIMI is committed to transparency in its work product and process.
>
> Approach
>
> ADL 1.5 will be the initial formalism for representing clinical models in
> the repository.
>
> CIMI will use the openEHR constraint model (Archetype Object Model:AOM).
> Modifications will be required and will be delivered by CIMI members on a
> frequent basis.
>
> A set of UML stereotypes, XMI specifications and transformations will be
> concurrently developed using UML 2.0 and OCL as the constraint language.
> A Work Plan for how the AOM and target reference models will be maintained
> and updated will be developed and approved by the end of January 2012.
>
> ?Lessons learned from the development and implementation of the HL7 Clinical
> Statement Pattern and HL7 RIM as well as from the Entry models of 13606,
> openEHR and the SMART (Substitutable Medical Apps, Reusable Technologies)
> initiative will inform baseline inputs into this process.
>
> A plan for establishing a repository to maintain these models will continue
> to be developed by the group at its meeting in January.
>
> Representatives from the following organizations participated in the
> construction of this statement of principles and plan
>
> B2i Healthcare www.B2international.com
> Cambio Healthcare Systems www.cambio.se
> Canada Health Infoway/Inforoute Sant? Canada www.infoway-inforoute.ca
> CDISC www.cdisc.org
> Electronic Record Services www.e-recordservices.eu
> EN 13606 Association www.en13606.org
> GE Healthcare www.gehealthcare.com
> HL7 www.hl7.org
> IHTSDO www.ihtsdo.org
> Intermountain Healthcare www.ihc.com
> JP Systems www.jpsys.com
> Kaiser Permanente www.kp.org
> Mayo Clinic www.mayoclinic.com
> MOH Holdings Singapore www.moh.com.sg
> National Institutes of Health (USA) www.nih.gov
> NHS Connecting for Health www.connectingforhealth.nhs.uk
> Ocean Informatics www.oceaninformatics.com
> openEHR Foundation www.openehr.org
> Results4Care www.results4care.nl
> SMART www.smartplatforms.org
> South Korea Yonsei University www.yonsei.ac.kr/eng
> Tolven www.tolven.org
> Veterans Health Administration (USA) www.va.gov/health
>
> Further Information
>
> In the future CIMI will provide information publicly on the Internet. For
> immediate further information, contact Stan Huff (stan.huff at imail.org)
>
>
> ___
> openEHR-announce mailing list
> openEHR-announce at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-announce
>
>
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

open source openEHR-related EHR systems; How do you want to be cited...

[Shinji KOBAYASHI]

Hi Erik and all

We will release the first stable branch at this Xmass, coming Dec 24.
The status is like Java/Eiffel reference implementation.
Release 1.0 notes:
* ADL 1.4 parser
* Implementation of AOM 1.0.2 specifications(partially 1.1)
* Implementation RM 1.0.2 specification
* Change license from MPL 1.1 to Apache 2.0

We are engaging to develop web based EHR system for sample with
Ruby on Rails.

Regards,
Shinji

2011/12/13 Erik Sundvall :
> Hi Shinji!
>
> What is ths status of the Ruby implementation? Is it currently an EHR
> system where you can enter, store and retrieve EHR data, or is it an
> implementation of the RM+AM like the Java ref-impl, that can be used
> as a component to build EHR systems?
>
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
>
> On Mon, Dec 12, 2011 at 12:14, Shinji KOBAYASHI  wrote:
>> Hi,
>>
>> please add this article in press.
>>
>> Shinji Kobayashi and Akimichi Tatsukawa, Ruby Implementation of the
>> openEHR specifications, Journal
>> of Advanced Computational Intelligence and Intelligent Informatics, in press.
>>
>> Project site: http://openehr.jp/projects/show/ref-impl-ruby
>> GitHub: https://github.com/skoba/ruby-impl-openehr
>>
>> Shinji
>>
>> 2011/12/8 Erik Sundvall :
>>> Hi!
>>>
>>> We now getting the LiU EEE paper "Applying REST Architecture to
>>> Archetype-based EHR systems" (by Erik Sundvall, Mikael Nystr?m, Daniel
>>> Karlsson, Martin Eneling, Rong Chen and ?H?kan ?rman) finished for
>>> submission, and in a background passage we mention other openEHR based EHR
>>> systems (where you can enter and query pateint data) that are open source:
>>>
>>> "...the situation has changed to the better and more open source
>>> alternatives [opereffa, openEHRgen, GastrOS, oship/MLHIM] that explores
>>> different approaches to implement openEHR systems..."
>>>
>>> Now, if you are involved one of the mentioned systems?[opereffa, openEHRgen,
>>> GastrOS, oship/MLHIM], what is your favorite or most up to date paper or
>>> other reference that you think describes your system best and that you would
>>> prefer that people considered citing in academic papers?
>>>
>>> If you feel that we have missed listing an open source openEHR system with
>>> non-viral permissive licence, then please enlighten us!
>>>
>>> Best regards,
>>> Erik Sundvall
>>> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical at openehr.org
>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

open source openEHR-related EHR systems; How do you want to be cited...

[Shinji KOBAYASHI]

Hi,

please add this article in press.

Shinji Kobayashi and Akimichi Tatsukawa, Ruby Implementation of the
openEHR specifications, Journal
of Advanced Computational Intelligence and Intelligent Informatics, in press.

Project site: http://openehr.jp/projects/show/ref-impl-ruby
GitHub: https://github.com/skoba/ruby-impl-openehr

Shinji

2011/12/8 Erik Sundvall :
> Hi!
>
> We now getting the LiU EEE paper "Applying REST Architecture to
> Archetype-based EHR systems" (by Erik Sundvall, Mikael Nystr?m, Daniel
> Karlsson, Martin Eneling, Rong Chen and ?H?kan ?rman) finished for
> submission, and in a background passage we mention other openEHR based EHR
> systems (where you can enter and query pateint data) that are open source:
>
> "...the situation has changed to the better and more open source
> alternatives [opereffa, openEHRgen, GastrOS, oship/MLHIM] that explores
> different approaches to implement openEHR systems..."
>
> Now, if you are involved one of the mentioned systems?[opereffa, openEHRgen,
> GastrOS, oship/MLHIM], what is your favorite or most up to date paper or
> other reference that you think describes your system best and that you would
> prefer that people considered citing in academic papers?
>
> If you feel that we have missed listing an open source openEHR system with
> non-viral permissive licence, then please enlighten us!
>
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>

occurrences and cardinality in ADL, XML, JSON

[Shinji KOBAYASHI]

Hi Thomas and colleagues,

I would like to discuss about the other serialization form of archetype, too.
I thought YAML could be an alternative of them.
However, JSON/YAML are based on weakly typing languages, do not have
established scheme definition, such as XSD/ADL.

inline.

2011/11/11 Thomas Beale :

> ~~ first question: occurrences and cardinality? 
> but the upper limit is commonly unbounded, i.e. '*' in typical UML-like
> syntax. We could do:
>
> occurrences = <
> ??? lower = <2> -- Integer field
> ??? upper_bounded =  -- Boolean field

I think upper_bounded is typo for upper_unbounded, but this format has the
most conformance to INTERVAL specification of assumed types library.
I agree this, because this form is easier to parse and generate an
INTERVAL instance.
I also agree with the first way of XML scheme with the same reason.

BTW, Rubyist might be prefer this format(YAML):

occurrence:
  2..

> ~ second question:existence 
> Thus in JSON/dADL it could be:
>
> some_attr = <
> ??? existence = 
>>

I prefer shorter method.
To keep backward compatibility, new "exist" property
would be defined as Boolean, because it looks more narrative.
e.g.

attribute.exist == true?
attribute.existence == 1..1

Shinji Kobayashi

openEHR Transition: two procedural and one licensing question

[Shinji KOBAYASHI]

Hi Sam and all

Thank you for comments about localisation.
First of all, I emphasize LOCALISATION is not ISOLATION.
Only to fork and arrange global resource for local usage is isolation.
True localisation is to feed back such experience to enrich core
implementation.
I think endorsement program at page 4 of white book should include
localisation as global promotion, and endorsement / promotion program
should have a board like other specification / clinical modeling / software
engineering.
Because local activity management depends on its own domestic situation,
local governance should be decided by local community. However, bad
localisation disgrace all of our community and makes people unhappy in its area.
So I think local activity requirements are,
* Keep contact with global community
* Implement openEHR clinical models for domestic use.
* Provide proper translation, specialised implementation for their domain.
* Promote openEHR specification for their domain.(Web/mailing list)
* Governance of local community as good status
* Feed back localisation experience to global community.
I also think two or three of these conditions are enough to be a local activity.

These are my requests from Japan(probably from other local activities, too)
* Permit to use openEHR name and logo for domestic promotion.
* Publish local activity directory for whom need to contact with them
on the openEHR.org web.
* Disallow to use openEHR  name and logo whenf you think we are not
worth to use.
* Keep contact with local activities.

Cheers,
Shinji KOBAYASHI

2011/9/7 Sam Heard :
> Hi Pablo and Shinji
> Supporting localization both technical and operational needs to be included.
> The no language primacy principle is a real winner, different written forms
> of the same language is not covered as yet.
> How local groups run is another, clearly these can be national or context
> based.
> Thanks for the input.
> Cheers Sam
>
> Sent from my phone
> On 07/09/2011, at 2:38 AM, pablo pazos  wrote:
>
> Hi Shinji,
>
> That's exactly what I tried to point in another mail to the lists: local and
> regional openEHR organizations should be supported by openEHR and we need to
> put it into the white paper.
>
> --
> 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
>
>> Date: Tue, 6 Sep 2011 19:13:45 +0300
>> Subject: Re: openEHR Transition: two procedural and one licensing question
>> From: skoba at moss.gr.jp
>> To: openehr-technical at openehr.org
>>
>> Hi All,
>>
>> I have been suffered by sever jet lag after long trip, while I have
>> been thinking about this new white
>> paper and our local activity. I could not find such localisation
>> activity in this white paper, but please
>> consider and mention about such local activity.
>> I would like to show these two proposals.
>> 1) Local activity support.
>> As a global standard, localisation to each country or area is
>> necessary. My three years experience
>> to implementation of the Ruby codes, archetypes and template, we need
>> lots of localisation efforts
>> for Japanese use. I think this experience may be available to localise
>> for other countries. East Asian
>> countries people is keen in openEHR development and their engagements
>> are promising for their
>> health care.
>>
>> 2) Premature artefact repository
>> CKM provides us well-considered archetypes and templates. This is a
>> great knowledge resource
>> for mankind. However, to incubate archetype as a common concept takes
>> long time like vintage wine.
>> On the other hand, I need more agile movement for daily development. I
>> have developed about 50
>> archetypes and 6 templates. These artefacts are still premature to
>> evaluate on CKM, but I would
>> like to discuss about my artefacts on line with many people. Yes, it
>> will be a 99% junk repository,
>> but 1% diamond would be a precious for our community. As Major league
>> cannot exist without
>> minor leagues, I think CKM needs such minor artefacts groups.
>> I am preparing to share them on GitHub, because anyone can use
>> repository for each use by fork
>> and merge request is useful.
>> I think the licence of this repository would adopt CC-BY-SA, is this
>> OK, Erik and Ian?
>>
>> Cheers,
>> Shinji KOBAYASHI(in Japan, a path of typhoon.)
>>
>> 2011/9/6 Erik Sundvall :
>> > Thanks for replying Sam!
>> >
>> > Erik Wrote (to openEHR-technical at openehr.org):
>> >>> Was that whitepaper formally ratified by the new board, or by the o

openEHR Transition: two procedural and one licensing question

[Shinji KOBAYASHI]

Hi All,

I have been suffered by sever jet lag after long trip, while I have
been thinking about this new white
paper and our local activity. I could not find such localisation
activity in this white paper, but please
consider and mention about such local activity.
I would like to show these two proposals.
1) Local activity support.
As a global standard, localisation to each country or area is
necessary.  My three years experience
to implementation of the Ruby codes, archetypes and template, we need
lots of localisation efforts
for Japanese use. I think this experience may be available to localise
for other countries. East Asian
countries people is keen in openEHR development and their engagements
are promising for their
health care.

2)  Premature artefact repository
CKM provides us well-considered archetypes and templates. This is a
great knowledge resource
for mankind. However, to incubate archetype as a common concept takes
long time like vintage wine.
On the other hand, I need more agile movement for daily development. I
have developed about 50
archetypes and 6 templates. These artefacts are still premature to
evaluate on CKM, but I would
like to discuss about my artefacts on line with many people. Yes, it
will be a 99% junk repository,
but 1% diamond would be a precious for our community. As Major league
cannot exist without
minor leagues, I think CKM needs such minor artefacts groups.
I am preparing to share them on GitHub, because anyone can use
repository for each use by fork
and merge request is useful.
I think the licence of this repository would adopt CC-BY-SA, is this
OK, Erik and Ian?

Cheers,
Shinji KOBAYASHI(in Japan, a path of typhoon.)

2011/9/6 Erik Sundvall :
> Thanks for replying Sam!
>
> Erik Wrote (to openEHR-technical at openehr.org):
>>> Was that whitepaper formally ratified by the new board, or by the old board,
>>> or is it's current state just a suggestion by Sam?
>
> On Mon, Sep 5, 2011 at 17:58, Sam Heard  
> wrote:
>> [Sam Heard] The whitepaper was ratified by the participants in the planning
>> process, the current Board (Profs. Kalra, Ingram and myself) and the new
>> Transitional Board.
>
> This is a bit worrying for the period until a broader board can be
> elected. I was hoping that somebody within the new board would be
> interested enough and have time to take licensing issues and community
> feedback seriously, let's hope that the board does a bit more research
> and community dialogue before ratifying a new version of this
> whitepaper. Could somebody from the board please confirm that you'll
> take a serious look at this in the near future?
>
> Erik wrote:
>> What is the mandate period of the transitional board? When will the
>> suggested new structure with an elected board start?
>
> On Mon, Sep 5, 2011 at 17:58, Sam Heard  
> wrote:
>> [Sam Heard] I for one am very happy to express a date for elections if
>> organisations embrace these arrangements. Clearly if there is no interest in
>> participating from industry or organisations then we would have to think
>> again. I suspect we will then move to election of the Board by Members but
>> it is our wish to provide a means of determining the governance for
>> openEHR?s key sponsors. The aim is to balance the Members with governance
>> from the funders and sponsors. Some may prefer a democratic organisation top
>> to bottom; we do not think this will achieve the best results.
>
> So there is no absolute end date set. :-(
>
> The "if organisations embrace these arrangements" part is worrying,
> especially since we already have seen failed attempts at getting
> buy-in from "organisations".
>
> Can't you set an absolute latest date (e.g. at the very latest
> December 31, 2012) when the new arrangements will start no matter if
> big organisations have made use of the introductory offer of buying a
> position in the board? If not, we risk having an interim board
> forever, and we really don't need any more delays in the journey
> towards community-driven governance. If you get buy-in from the number
> of big players you want before that absolute end date then there would
> be nothing stopping you from doing the transition earlier than the
> "latest date".
>
> Erik wrote:
>> The thoughts behind the third point in the "Principles of licencing" are
>> understandable, but as stated over and over again, e.g. at...
>> http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal?focusedCommentId=13041696#comment-13041696
>> ...the SA part of CC-BY-SA won't help against copyright and patent abuse.
>> Only fighting possible upcoming bad patents in particular and bad patent
>> laws in general might 

Multiple archetypes in a single concept as a way to create an archetype collaborative

[Shinji KOBAYASHI]

Hi Ian,

The repository Diego pointed out seems the Cambodian TB archetypes.
Kong Saran is an lead of this project.

2011/8/5 Ian McNicoll :
> Hi Shinji,
>
> Are the Cambodian TB archetypes visible or downloadable anywhere?
>
> The tension in any archetype development is between modeling the
> specific use-case e.g a TB - public health reporting application,
> which is relatively easy and the more complex but ultimately
> preferable approach of creating interoperable archetypes which make
> use of clinical data collected as part of front-line activity and
> requirements.
>
> Ian
>
> Dr Ian McNicoll
> office +44 (0)1536 414 994
> fax +44 (0)1536 516317
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
>
> Clinical Modelling Consultant,?Ocean Informatics, UK
> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> BCS Primary Health Care ?www.phcsg.org
>
>
>
>
> On 5 August 2011 11:27, Shinji KOBAYASHI  wrote:
>> Otherwise, I think these archetype developed for tuberculosis need
>> more discussion.
>>
>> 2011/8/5 Shinji KOBAYASHI :
>>> HI Joaquin,
>>>
>>> I remember that Cambodia group developed TB archetype at Kano labo in
>>> Waseda university.
>>> We can share information at our openehr.jp site.
>>> http://openehr.jp/news/9
>>>
>>> 2011/8/5 Blaya, Joaquin Andres :
>>>> Thank you for all of the responses. ?I have forwarded them to the OpenMRS 
>>>> developer team. ?A couple of other questions arose that I was hoping to 
>>>> get cleared up.
>>>>
>>>> 1. Are there tools or a portal for archetypes where different users can 
>>>> share their archetypes?
>>>> 2. Have archetypes for Tuberbulosis, HIV and Malaria been created that can 
>>>> be used in OpenMRS?
>>>>
>>>> Thanks again,
>>>>
>>>> Joaquin
>>>>
>>>> ___
>>>> Chief Technology Officer, eHealth Systems Chile
>>>> Research Fellow, Harvard Medical School/Partners In Health
>>>> Moderator, GHDOnline.org
>>>>
>>>> ___
>>>> openEHR-technical mailing list
>>>> openEHR-technical at openehr.org
>>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>>>
>>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>

Multiple archetypes in a single concept as a way to create an archetype collaborative

[Shinji KOBAYASHI]

Otherwise, I think these archetype developed for tuberculosis need
more discussion.

2011/8/5 Shinji KOBAYASHI :
> HI Joaquin,
>
> I remember that Cambodia group developed TB archetype at Kano labo in
> Waseda university.
> We can share information at our openehr.jp site.
> http://openehr.jp/news/9
>
> 2011/8/5 Blaya, Joaquin Andres :
>> Thank you for all of the responses. ?I have forwarded them to the OpenMRS 
>> developer team. ?A couple of other questions arose that I was hoping to get 
>> cleared up.
>>
>> 1. Are there tools or a portal for archetypes where different users can 
>> share their archetypes?
>> 2. Have archetypes for Tuberbulosis, HIV and Malaria been created that can 
>> be used in OpenMRS?
>>
>> Thanks again,
>>
>> Joaquin
>>
>> ___
>> Chief Technology Officer, eHealth Systems Chile
>> Research Fellow, Harvard Medical School/Partners In Health
>> Moderator, GHDOnline.org
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>

Multiple archetypes in a single concept as a way to create an archetype collaborative

[Shinji KOBAYASHI]

HI Joaquin,

I remember that Cambodia group developed TB archetype at Kano labo in
Waseda university.
We can share information at our openehr.jp site.
http://openehr.jp/news/9

2011/8/5 Blaya, Joaquin Andres :
> Thank you for all of the responses. ?I have forwarded them to the OpenMRS 
> developer team. ?A couple of other questions arose that I was hoping to get 
> cleared up.
>
> 1. Are there tools or a portal for archetypes where different users can share 
> their archetypes?
> 2. Have archetypes for Tuberbulosis, HIV and Malaria been created that can be 
> used in OpenMRS?
>
> Thanks again,
>
> Joaquin
>
> ___
> Chief Technology Officer, eHealth Systems Chile
> Research Fellow, Harvard Medical School/Partners In Health
> Moderator, GHDOnline.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>

short presentation on openEHR Tool chain

[Shinji KOBAYASHI]

Thank you, Tom.
I will add this slides for our congress, JCMI 2010 in Nov 20, which
Dipak will join.

Best regards,
Shinji

2010/11/17 Thomas Beale :
>
> On the Getting started page, a new presentation is available explaining the
> openEHR knowledge development tool chain. It is less than 10 slides, and
> since quite a few people have requested it after recent presentations, I
> have made it generally available.
>
> Direct links: PPT, PDF
>
> - thomas beale
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>