Help list openEHR procurements, related documents and things to think of!

[Erik Sundvall]

Hi!

I have started a wikipage about "Procurement of openEHR-related systems":
https://openehr.atlassian.net/wiki/spaces/resources/pages/416514052/Procurement+of+openEHR-related+systems
(As a preparation for an upcoming, not yet started procurement)

Please help me list things there, it may help many others in similar situations 
now and in the future.

Hope to see some of you at Medinfo 2019 next week.


Best regards,

Erik Sundvall　

Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 
010-1036252 in Sweden)
RÖ:　
erik.sundv...@regionostergotland.se<mailto:erik.sundv...@regionostergotland.se> 
(previously lio.se) http://www.regionostergotland.se/cmit/
LiU:　erik.sundv...@liu.se<mailto:erik.sundv...@liu.se/t_blank>　
http://www.imt.liu.se/~erisu/<http://www.imt.liu.se/~erisu//t_blank>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

openEHR modeling for physical activity data etc. from personal health platforms (like Google Fitness, Apple Health, Samsung Health, Withings, Garmin, Polar, Strava, MyFitnessPal etc.)

[Erik Sundvall]

Hi!

Those of you interested in openEHR modeling for physical activity data etc. 
from personal health platforms (like Google Fitness, Apple Health, Samsung 
Health, Withings, Garmin, Polar, Strava, MyFitnessPal etc.) may want to take a 
look at some of the info, links, mindmaps etc at 
https://github.com/regionostergotland/openehr_definitions/tree/master/mindmaps

Feel free to join the discussion and experimentation.


Best regards,

Erik Sundvall

Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 
010-1036252 in Sweden)
RÖ:　
erik.sundv...@regionostergotland.se<mailto:erik.sundv...@regionostergotland.se> 
(previously lio.se) http://www.regionostergotland.se/cmit/
LiU:　erik.sundv...@liu.se<mailto:erik.sundv...@liu.se/t_blank>　
http://www.imt.liu.se/~erisu/<http://www.imt.liu.se/~erisu//t_blank>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Automation with openEHR & SNOMED-CT ontology reasoning

[Erik Sundvall]

Hi all openEHR+Snomed CT hackers!

Doing the inference described below using a reasoner and openEHR with AQL+api 
calls as a bridge to EHR content would be pedagogical.

Who in the openEHR community will get a demo video out first?

Good luck with this little challenge!

Best regards,
Erik Sundvall


Från: Yosemite Project 
Skickat: måndag, mars 25, 2019 3:25 fm
Till: yosemiteproj...@googlegroups.com; i...@lists.hl7.org; w3c semweb HCLS
Ämne: Tutorial on FHIR/RDF with SNOMED-CT ontology, including 90-second video

I am pleased to announce a short hands-on tutorial on using FHIR/RDF
with the SNOMED-CT ontology:
http://tinyurl.com/fhir-rdf-snomed-tut

Try it out! A 90-second video also demonstrates the steps:
https://youtu.be/NjNdo0GyieU

The tutorial is based on a previous webinar by Harold Solbrig:
https://goo.gl/6WYH1C

P.S. We are also interested in hearing about other projects that are
using or planning to use FHIR/RDF. Please email da...@dbooth.org .

Enjoy!
David Booth
Yosemite Project

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

Re: Unique paths for slots problem if slots are filled with same archetype

[Erik Sundvall]

Hi all!

The issue (and some possible solutions/workarounds) is now described at 
https://openehr.atlassian.net/browse/SPECPR-279

Feel free to add information, comments etc there.

//Erik Sundvall


3 nov. 2018 kl. 15:12 skrev GF mailto:gf...@luna.nl>>:

Either it is solve using standardised basic Archetypes or via the RM.
The RM route is the preferred one.

When thinking about it, then…
Data in any Patient Record is either:
- de novo data stored at a session
- re-used pre-existing data (Reported data, used data in processes, etc.) This 
data is pre-existing data that is re-used. When querying for a concept it must 
be possible to restrict it to new data and/or re-used data.
Again this can be solved via standardised basic Archetypes or the RM.
The RM is the best option.

Gerard   Freriks
+31 620347088
  gf...@luna.nl<mailto:gf...@luna.nl>

Kattensingel  20
2801 CA Gouda
the Netherlands

On 3 Nov 2018, at 12:23, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:


I've just been thinking more about this problem. I agree we need to fix it, and 
it seems fairly likely adjusted rules for forming paths and storing archetype 
markers in data will be needed.

But... the archetype structure mentioned is a hack for getting around the lack 
of order-tracking attributes in the RM. We've had a look at this before (e.g. 
here<https://openehr.atlassian.net/wiki/spaces/spec/pages/60358659/RM+additions+for+workflow+process>)
 but I would suggest we need to think soon about additions to the ENTRY class 
or package to properly model requester and receiver meta-data.

- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto: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: Templates for application form development

[Erik Sundvall]

Hi!

I have also updated the
https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets
wikipage to include

   - references to some previous GUI discussions and
   - Region Östergötlands current use case and initial
   Ethercis-OPT-introspector+Angular-based design plans (See heading "OPT form
   renderer needed for pilot testing of surgery process supporting system"
   near the end of the page.

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se)
http://www.regionostergotland.se/cmit/
Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/

On Mon, Mar 12, 2018 at 11:48 PM, Pablo Pazos <pablo.pa...@cabolabs.com>
wrote:

> Thanks Thomas, I added a paragraph about the UI generation modes at the
> end, I forgot to mention that yesterday.
>
> On Mon, Mar 12, 2018 at 9:40 AM, Thomas Beale <thomas.be...@openehr.org>
> wrote:
>
>> Pablo,
>>
>> Good work - I've included a reference to this doc in the original wiki
>> page
>> <https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets>,
>> and added a few ideas about how to use it. It is very close to what I was
>> thinking of.
>>
>> - thomas
>>
>> On 12/03/2018 07:31, Pablo Pazos wrote:
>>
>> Hi all,
>>
>> I manage to translate / update part of the work we did some years ago in
>> terms of UI definition and generation for the openEHR stack.
>>
>> Here is the doc, feedback is very welcome!
>>
>> https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe
>> -_T9H6UMsGNkiZoU7Iw/edit?usp=sharing
>>
>>
>>
>> --
>> Thomas Beale
>> Principal, Ars Semantica <http://www.arssemantica.com>
>> Consultant, ABD Team, Intermountain Healthcare
>> <https://intermountainhealthcare.org/>
>> Management Board, Specifications Program Lead, openEHR Foundation
>> <http://www.openehr.org>
>> Chartered IT Professional Fellow, BCS, British Computer Society
>> <http://www.bcs.org/category/6044>
>> Health IT blog <http://wolandscat.net/> | Culture blog
>> <http://wolandsothercat.net/>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145 <+598%2099%20043%20145>
> skype: cabolabs
> <http://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>
> ___
> 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: Templates for application form development

[Erik Sundvall]

Hi!

I agree that in many use-cases it is better to have a separate template
intended for GUI/application hints overlayed on a "normal" data content
definition template. (Quick experimentation may be an exception.)

That is why I added "layers of templates" in my previous comment - sorry
for not explaining in detail. So a GUI-hint-annotated template based on
another "normal" content aggregation/constraint-focused template would be a
way to do it. I guess the effect in a resulting operational template (OPT)
is essentially the same no matter how many layers of templates you choose
to work with, right? So a form/GUI-renderer based on OPTs does not care how
you layer the design, but your maintenance headaches might be affected if
not separating things at design time.

I agree with Diego and Bert and suggest starting experimenting in the AM
end (for example using annotations with GUI-hints in templates) and see how
far that takes us, before possibly considering extending the RM (or
whatever *M).

Annotations do not require any changes to AM or RM, the mechanism is
already defined in the specifications. Conventions regarding patterns or
prefixes in annotation keys and/or annotation values will likely give
enough to start with.

A (not so very thought through yet) possible example of annotation use for
application building is available in picture 40 (and supported by picture
36 in
https://drive.google.com/file/d/1kxXeJMe0ltfLlchGA0Lm8mfOD-PQDLFy/view?usp=sharing


//Erik

mån 19 feb. 2018 kl. 10:22 skrev Bert Verhees :

> On 18-02-18 23:09, GF wrote:
> > Is it an idea to annotate nodes with instructions for display.
>
> Personally I think having special templates/archetypes for display is
> better. Templates are create per purpose, and mixing purposes in a
> single template does  seem good idea to me
>
>
> ___
> 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: Templates for application form development

[Erik Sundvall]

sön 18 feb. 2018 kl. 23:10 skrev GF <gf...@luna.nl>:

> Is it an idea to annotate nodes with instructions for display.
>

Yes, using (mostly shared/standardised) annotations for GUI-rendering hints
in templates (or layers of templates) has been a major idea in previous
GUI-related discussions in openEHR mailing lists.

//Erik

(We should link to some old list posts on the topic in that wiki page Tom
created)






>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 18 Feb 2018, at 15:16, Erik Sundvall <erik.sundv...@liu.se> wrote:
>
> This is an Interesting topic!
>
> Standardised methods for representing application GUI behaviour/appearance
> in an open vendor neutral way is one of the few still missing pieces in the
> openEHR ecosystem needed in order to avoid vendor lock in.
>
> Some clever choise of split point is likely fruitful since some parts are
> closer to openEHR data/query definitions and some will be closer to
> GUI-implementation/visualisation/layout frameworks (like Angular etc) that
> should likely not be reinvented by openEHR but that (sometimes at an
> annoying speed) keep changing versions and popularity faster than the
> RM/AM/AQL related data definition framework should...
>
> When designing this, perhaps some (2-5) existing currently popular GUI
> frameworks could be initial targets for output from the process, and the
> selection could be updated over time. Perhaps for example
> https://angular.io/ and https://reactjs.org/ are two starting candidates
> for experimentation? (Both have partially declarative design, but other
> suggestions are of course welcome) Then mechanisms in those platforms could
> be reused rather than reinvented.
>
> Also looking at the things done in the format used/shared by Marand and
> DIPS is an interesting input for gathering requirements.
>
> //Erik Sundvall
>
> sön 18 feb. 2018 kl. 11:51 skrev Thomas Beale <thomas.be...@openehr.org>:
>
>>
>>
>> On 17/02/2018 20:11, Pablo Pazos wrote:
>> > I think SET has a lot of applications, including result
>> > sets. Of course that should interior from LOCATABLE to be archetypable.
>> >
>> > I'm not sure on the types associated with the UI. I have a
>> > specification for UITenplates that includes some of that, I can share
>> > it :)
>> >
>>
>> I think any existing UI/template specification / app modelling would be
>> useful to share - possibly on the wiki - let me know if you need a page
>> there.
>>
>> My aim would be to get closer to an IDE application building tool for
>> clinical people to at least build a POC application that works,
>> something like Balsamiq but with real data connections built in.
>> Marand's EhrExplorer does some of this, and it would also be useful to
>> extract some of the semantics of that tool into a standard specification
>> to support this kind of thing.
>>
>> - thomas
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
> --
> Sent from mobile.
> ___
> 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

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

Re: Templates for application form development

[Erik Sundvall]

This is an Interesting topic!

Standardised methods for representing application GUI behaviour/appearance
in an open vendor neutral way is one of the few still missing pieces in the
openEHR ecosystem needed in order to avoid vendor lock in.

Some clever choise of split point is likely fruitful since some parts are
closer to openEHR data/query definitions and some will be closer to
GUI-implementation/visualisation/layout frameworks (like Angular etc) that
should likely not be reinvented by openEHR but that (sometimes at an
annoying speed) keep changing versions and popularity faster than the
RM/AM/AQL related data definition framework should...

When designing this, perhaps some (2-5) existing currently popular GUI
frameworks could be initial targets for output from the process, and the
selection could be updated over time. Perhaps for example
https://angular.io/ and https://reactjs.org/ are two starting candidates
for experimentation? (Both have partially declarative design, but other
suggestions are of course welcome) Then mechanisms in those platforms could
be reused rather than reinvented.

Also looking at the things done in the format used/shared by Marand and
DIPS is an interesting input for gathering requirements.

//Erik Sundvall

sön 18 feb. 2018 kl. 11:51 skrev Thomas Beale <thomas.be...@openehr.org>:

>
>
> On 17/02/2018 20:11, Pablo Pazos wrote:
> > I think SET has a lot of applications, including result
> > sets. Of course that should interior from LOCATABLE to be archetypable.
> >
> > I'm not sure on the types associated with the UI. I have a
> > specification for UITenplates that includes some of that, I can share
> > it :)
> >
>
> I think any existing UI/template specification / app modelling would be
> useful to share - possibly on the wiki - let me know if you need a page
> there.
>
> My aim would be to get closer to an IDE application building tool for
> clinical people to at least build a POC application that works,
> something like Balsamiq but with real data connections built in.
> Marand's EhrExplorer does some of this, and it would also be useful to
> extract some of the semantics of that tool into a standard specification
> to support this kind of thing.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
-- 
Sent from mobile.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Erik Sundvall]

Great work! A very good contribution both as code (with widely usable
licence) and in practice as a specification debugging effort!

//Erik Sundvall

P.s. Regarding Javascript I’d recommend looking at the related Typescript
superset instead for anybody wanting to do implement openEHR RM or AM on
client side in browsers. It will  likely feel more familiar for Java (and
Eiffel) people and others wanting to do generics, type checking etc.

Is anybody out there working on or planning a Typescript (or possibly
JavaScript) based openEHR library implementation with a permissive open
source licence (like Apache 2)? I guess many thoughts and design patterns
from Archie could be reused... Such a library could be used for e.g.
https://angular.io/ and/or https://nodejs.org/en/ based projects.



lör 3 feb. 2018 kl. 22:12 skrev Peter Gummer <peter.gum...@gmail.com>:

> Interaction with a JavaScript front-end could be done with any back-end
> programming language — it doesn’t have to be Java.
>
> So your point is that Archie's serialisation and deserialisation to JSON
> will will assist this? I believe Thomas’s Eiffel implementation already has
> JSON serialisation, since about 5 years ago.
>
> Peter
>
>
> > On 3 Feb 2018, at 23:03, Pieter Bos <pieter@nedap.com> wrote:
> >
> > Or a Java app with rest api and a JavaScript frontend. Let the java
> application take care of parsing, validating, flattening, operational
> template creation etc and send json to your front end. Archie has built-in
> json serialization and deserialization support.
> >
> > Pieter
> >
> > Op 3 feb. 2018 om 12:05 heeft Seref Arikan <
> serefari...@kurumsalteknoloji.com<mailto:serefari...@kurumsalteknoloji.com>>
> het volgende geschreven:
> >
> > Hi Peter,
> >
> > Presumably via use of a transpiler or a bytecode to js/webassembly
> compiler.
> >
> > On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer <peter.gum...@gmail.com
> <mailto:peter.gum...@gmail.com>> wrote:
> > On 1 Feb 2018, at 05:13, Thomas Beale <thomas.be...@openehr.org thomas.be...@openehr.org>> wrote:
> >
> > ... But the main interest is that we will be able to build new tools
> such as a Java/JS replacement for the ADL Workbench, and of course things
> like a high-quality, BMM-driven runtime archetype validating kernel for EHR
> systems, workflow implementations and many other components.
> >
> > Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how
> Archie (written in Java, disappointingly) would enable JavaScript
> implementations. JavaScript has nothing in common with Java (apart from the
> name).
> >
> > Peter
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: Hand coding templates in ADL 1.4

[Erik Sundvall]

Hi!

Great to hear about your project! Please tell us a bit more if you have
time, what are the pilot use-cases? (I am curious since we are planning
some tests in Sweden too...)

It is true that adl 1.4 is currently more used, but for new projects it is
good to track the ADL 2 development. There are tools to automatically
convert archetypes between 1.4 and 2.0, so it is possible to set up
workflows starting from the either the 1.4 or 2.0 end.

The ADL 2 tools are moving forward, so if your modellers will want to use
web-based tools, then plan for 2.0 fairly soon.
I hope you have seen :
-
https://openehr.atlassian.net/wiki/display/dev/Online+archetype+and+template+tools

and
- https://twitter.com/marandlab/status/826832144672686081

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se)
http://www.regionostergotland.se/cmit/
Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/

On Sun, Feb 12, 2017 at 1:11 PM, Pieter Bos <pieter@nedap.com> wrote:

> The editing tools for adl 2 are still limited. However the template
> editing by hand is easier in adl 2 than the earlier template xml formats
> because it's the same adl with a few extra language constructs for
> templates.
>
> And you can convert the ckm to adl 2 quite easily.
>
> Pieter Bos
>
>
> Op 12 feb. 2017 om 12:04 heeft Diego Bosc? <yamp...@gmail.com<mailto:yamp
> e...@gmail.com>> het volgende geschreven:
>
> Hello Dileep,
>
> If you stick with ADL 1.4 then you could use LinkEHR Studio (
> http://linkehr.com) to create templates from other RM such as demographic
> model. The same tool can be used to import OET and export OPT for any given
> RM.
>
> Regards
>
> El 12/2/2017 9:44, "Dileep V S" <dil...@healthelife.in dil...@healthelife.in>> escribi?:
> Hi,
>
> We are exploring OpenEHR as part of a public health management pilot
> project in India and have some questions that I am unable to find proper
> answers.
>
> After studying the available libraries, tools and opensource server
> implementations, ADL 1.4 seems to be more widely supported than the newer
> ADL 2.0. The shared archetype repository (CKM) still contains only 1.4
> version archetypes. In light of this, I am assuming that for anybody
> planning to adopt OpenEHR, it will be advisable to stick to ADL1.4 for now.
>
> Further I have learned the following wrt. ADL 1.4 standards
>
> File formats for 1.4 version
>
>   *   Archetypes  - ADL 1.4
>   *   Templates - OET
>   *   Operational template - OPT 1.4
>
> Modelling tools - Archetype editor, template designer
>
> I am stuck with trying to answer the following questions. It would be
> great if somebody can help.
>
>   1.  Can we hand create templates that are not supported by the template
> designer? For example demographics?
>   2.  If yes how do we convert the hand coded OETs to OPTs?
>   3.  Where do we get more details on OET file syntax?
>
> Thanks
>
> Dileep
> HealtheLife Ventures LLP
> bamgalore
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org<mailto:openEHR-
> techni...@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org<mailto:openEHR-
> techni...@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: Converting Archetype into Nosql Schemes

[Erik Sundvall]

Hi!

We have performed and published some studies regarding the combination of
openEHR and noSQL and can probably help you, if we get some more
information about your ultimate implementation/thesis goal. So please tell
us a little bit more about the context and goal of your work.

Getting into oenEHR implementation can be a bit tricky and time consuming,
especially if you plan to do everything from scratch. I would recommend
starting by building something based on existing open
source implementations or published experiments, and
then extend/improve them by adding suitable noSQL parts and other things
that you might find missing.

If you are using a noSQL backend for storage, it will most likely have a
query language capable querying any kind of structured document. So
you  might not need to make separate tables for different kinds archetypes
and templates.

Perhaps it would be useful to focus on suitable ways of storing any kind
of reference model (RM) based documents/objects and then exploring how
to query them with the native query languages/mechanisms of your noSQL
solution. After that, or in parallel, you will likely want to explore how
to translate openEHR AQL queries to the native query language of your noSQL
backend.

Best regards,
Erik Sundvall

fredag 14 oktober 2016 skrev Eric Browne <eric.bro...@montagesystems.com.au
>:

> Hello Fadoua,
>
> Although I am not able to directly help with your request, you may be
> interested in a tool to view/edit operational template XML files developed
> under the current release (ADL1.4), such as those on the openEHR CKM site.
> This runs on Windows, Linux and MacOS and might help you explore some of
> the bundle of models that have already been developed around the world. It
> is based on a generic XML authoring tool XMLmind, augmented with a plugin I
> developed specifically for viewing openEHR Operational Templates.
>
> I've written a brief blog article at http://healthbase.info/blog/?p=390
> describing how to obtain and install it.
>
> Other pointers that might be more relevant to your question:-
>
> https://openehr.atlassian.net/wiki/display/resources/Persistence+FAQs
> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4636072/
> http://www.ep.liu.se/ecp/070/009/ecp1270009.pdf
>
> regards,
> eric
>
> Eric Browne
> eric.bro...@montagesystems.com.au <javascript:;>
> ph +61 414 925 845
> skype: eric_browne
>
>
> > On 14 Oct 2016, at 2:59 am, Fadoua Khennou <khennoufad...@gmail.com
> <javascript:;>> wrote:
> >
> > Hello,
> >
> > I am a Phd student, working on the implementation of OpenEhr standard
> with Nosql technologies in order to study the performances for such
> plateformes.
> >
> > And because i have just got familiar with archetypes in the ADL
> workbench and Ocean informatics, i would like to know is there an automatic
> way of generating from  operational template the adequate sql or nosql
> tables?
> >
> > If not should i integrate any other tools or modules in order to do this
> conversion?
> >
> > Thanks in advance for your response.
> >
> >
> > My regards,
> > Fadoua
> >
> >
> > --
> > Cordialement,
> >
> > KHENNOU Fadoua
> > __
> > Phd student at USMBA-Fes, Morocco
> > Transmission and Processing of Information laboratory
> > __
> > ___
> > openEHR-technical mailing list
> > openEHR-technical@lists.openehr.org <javascript:;>
> > http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org <javascript:;>
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>


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

Re: RM in OWL

[Erik Sundvall]

The master thesis of Roland Hedayat could also be of interest in this
context, see
http://www.diva-portal.org/smash/get/diva2:310787/fulltext01.pdf

Copy of abstract text below.

Best regards,
Erik Sundvall

Abstract

Semantic Web Technologies in the Quest for Compatible Distributed Health
Records

Roland Hedayat

There is a proliferation of patient bound Electronic Health Record (EHR)
data in systems that are incompatible - challenging the goal of granting
authorized access to the accumulated medical history of a patient, whenever
requested, and whichever the source, in order to secure a safe treatment.

A common semantic representation is a prerequisite for validating
the semantics of one EHR system against another. Therefore, assessing the
semantic compatibility between systems implies having a formal method for
extracting their semantics, and for validating the consistency of their
combined semantics. A guiding hypothesis is that Semantic Web Technologies
and Ontology Web Language (OWL) are potential bridging technologies between
the EHRs and medical terminologies, and can be used to represent the
combined semantics of the systems to be integrated. Furthermore, that
automatic reasoners can perform semantic validation of the combined
subsystems.

Some experimental steps in this direction are taken, preceded by a
discussion on Medical Terminologies, Ontologies, EHR-systems and their
interrelationships, and a summary overview of Description Logics, the
Semantic Web and the Web Ontology Language, OWL.

The OpenEHR reference model is transformed from an XML-schema
representation to OWL, and a couple of archetypes are transformed into OWL
in a manual procedure. Subsequently, validation runs with a formal reasoner
on the transformed results were performed, demonstrating the feasibility of
the process.

The problems of EHR semantic interoperability are complex. Awareness of the
necessity of applying formal semantic methods when dealing with inherently
semantic problems will catalyze the process of solving them.

Handledare: Daniel Karlsson

Ämnesgranskare: Hans Åhlfeldt

Examinator: Anders Jansson

IT 10 007

onsdag 13 juli 2016 skrev Matheus Wichman <matheus.wich...@gmail.com>:

> I uploaded my ontologies to a Git repository, you can download here
> https://bitbucket.org/uhospital/openehr-rm.
>
> Yes, my approach to handle generics was to create a specialized version
> for every possible T type. For example, to create a DV_INTERVAL locked to
> DV_QUANTITY I would subclass DV_INTERVAL adding a restriction so lower and
> upper properties only accepts DV_QUANTITY values.
>
> My other problem was with lists. The OWL language doesn't have a
> construction for data containers, only RDF do (through rdf:list). I tried
> to use a linked list like described here
> <http://protege.stanford.edu/conference/2006/submissions/abstracts/7.1_Drummond_listsInProtegeOWL.pdf>
>  but
> I would not be able to create inferences. Currently, lists are represented
> just with multiples values for a single property.
>
> 2016-07-13 4:03 GMT-03:00 Seref Arikan <serefari...@kurumsalteknoloji.com
> <javascript:_e(%7B%7D,'cvml','serefari...@kurumsalteknoloji.com');>>:
>
>> Hi Matheus,
>>
>> I'd be interested to hear about your problems. I'd also be curious to
>> learn how you handled generics/parameterized types. Unless one defines a
>> meta layer in owl with semantics for generics, I guess the only option is
>> to materialize every possible type parameter T to its own type.
>>
>> All the best
>> Seref
>>
>>
>> On Tue, Jul 12, 2016 at 7:26 PM, Matheus Wichman <
>> matheus.wich...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','matheus.wich...@gmail.com');>> wrote:
>>
>>> Hi Seref,
>>>
>>> The ontologies available on the link you posted were developed using an
>>> old specification of RM.
>>>
>>> I converted the current RM to OWL, like Isabel did. However I had some
>>> problems to represent list structures.
>>>
>>> 2016-07-12 13:02 GMT-03:00 Seref Arikan <
>>> serefari...@kurumsalteknoloji.com
>>> <javascript:_e(%7B%7D,'cvml','serefari...@kurumsalteknoloji.com');>>:
>>>
>>>> Greetings,
>>>>
>>>> I was wondering if there is any projects out there that provide an OWL
>>>> version of the RM.
>>>>
>>>> I found this page: http://trajano.us.es/~isabel/EHR/ where an OWL
>>>> version is kindly provided, though I'll need to get in touch with the
>>>> author to clarify the terms and conditions of use.
>>>>
>>>> There are papers out there that use an OWL representation of archetypes
>>>> etc 

Personal Health Record using CHBase (related to Health Vault)

[Erik Sundvall]

Hi!

The Swedish Government is financing and handing out a Personal Health Record 
service/platform to the Swedes. Now developers can find info about it at 
http://developer.halsaformig.se/

It seems to be based on CHBase http://www.getrealhealth.com/chbase/ that uses 
many of the API features equal or similar to Microsoft Health Vault.

The health-related PHR models are fairly simple (not many datapoints/details) 
and there are not very many models. The main ones are listed at 
http://developer.halsaformig.se/Reference/DataTypeMapping  and if you register 
for a free developer-account at https://developer.chbase.com/ you can read more 
details, for example this:

  *   Extending data types at 
https://developer.chbase.com/chbase/en-US/docs/Develop/Dn783274 that tells many 
things* including that any datatype can be extended by arbitrary XML as long as 
there is a transform backt to HTML registered with URI.
  *   HL7 FHIR integrations are being worked on.

Now to the questions:

  *   Have any of you already looked into openEHR mappings to/from CHBase or 
Microsoft Health Vault?
  *   The extension mechanism in CHBase is very permissive, using free-form 
XML, that could of course lead to semantc chaos with several overlapping 
incompatible extensions for the same kind of clinical data. I guess it could 
aslo be used to carry some suitable forms of openEHR-data in a more diciplined 
reusable manner. Any thoughts about that?
  *   Would it be a good idea to define a canonical way of storing openEHR data 
in CHBase/HealthVault so that all openEHR-based systems interacting with those 
products do it the same way and thus can exchange the semantically richer 
openEHR-based data as extensions via the PHRs? (Useful in the cases where that 
is the one of the few viable ways due to legal restrictions etc. Of course that 
is an unnecessary detour in the cases when you are allowed to do direct native 
communication between openEHR systems.)

(I guess this would be a suitable task for master-thesis students or beginning 
PhDs


Best regards

Erik Sundvall　

Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 
010-1036252 in Sweden)
RÖ:　
erik.sundv...@regionostergotland.se<mailto:erik.sundv...@regionostergotland.se> 
(previously lio.se) http://www.regionostergotland.se/cmit/
LiU:　erik.sundv...@liu.se<mailto:erik.sundv...@liu.se/t_blank>　
http://www.imt.liu.se/~erisu/




*) Excerpt from https://developer.chbase.com/chbase/en-US/docs/Develop/Dn783274 
below:


When building your application, you may find that you need to store additional 
information with an existing data type. For example, if you are using the 
Height data type, but you want to keep track of whether people were sleeping 
immediately before height was measured because the spine compresses during the 
day. The question is whether to:

  *   Incorporate this information into the existing base data type
  *   Use some other existing data type
  *   Ask the CHBase developers to create a new data type
  *   Extend the existing data type

To determine the appropriate course of action, inquire in the CHBase 
Forum<http://forum.chbase.com/>.

If the response to your inquiry is that the additional information should be 
stored as an extension of an existing type, you use the 
Extensions<https://developer.chbase.com/chbase/en-us/docs/sdk/P_CHBase_SDK_CommonItemData_Extensions>
 property of the 
CommonItemData<https://developer.chbase.com/chbase/en-us/docs/sdk/T_CHBase_SDK_CommonItemData>
 object returned by the HealthRecordItem . . :: . . 
CommonData<https://developer.chbase.com/chbase/en-us/docs/sdk/P_CHBase_SDK_HealthRecordItem_CommonData>
 property, which is a collection of 
HealthRecordItemExtension<https://developer.chbase.com/chbase/en-us/docs/sdk/T_CHBase_SDK_HealthRecordItemExtension>
 objects. By default, there's nothing in this list. If you have an instance and 
you add an extension instance to it, the framework saves that instance to the 
server and returns it when you read that instance back out.

CHBase data types can be extended by inserting XML into the 
HealthRecordItemExtension or by using a custom extension class. In the first 
method, you work with the XML details, which can be a bit clumsy. In the second 
method, you encapsulate the information in a class.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMED

[Erik Sundvall]

You can do some very clever things with Snomed CT especially if using
"post-coordination" in a good way. Sadly many current EHR-systems can't
utilize that power of Snomed CT fully. Clever archetyping with e.g. some
built in post-coordination-generating logic combined with some extended
(AQL?)querying-capabilities in openEHR storage systems could help
openEHR-based systems jump ahead of a lot of the EHR competitors regarding
efficient Snomed CT use...

It is often good to look at Snomed CT when designing archetypes. Especially
the high quality parts of Snomed CT (there is constant maintenance and
cleanup going on). I believe this is happening more already when designing
archetypes today.

Regarding licensing I believe there has been a discussion going on between
IHTSDO and the openEHR foundation for a long time, perhaps the management
board has an update?

I believe we might need to add a function to repositories/CKMs that removes
Snomed bindings/codes from archetypes if downloaded by non-licensed users.
(A lot of the structure/content itself is based on (non protected) general
medical knowledge and I believe IHTSDO concludes it can be partly reused
without license, thus not stopping global use of Snomed-inspired
archetypes.)

Others will surely add more to the discussion.

//Erik Sundvall

Sent from mobile...

fredag 29 april 2016 skrev Bert Verhees <bert.verh...@rosa.nl>:

> Part two is of course, generating templates, and we almost have the GUI's
> in place.
>
> It is the enormous collection of medical datastructures which can be the
> source of many generated EPD-software.
>
> Bert
>
> On 29-04-16 08:50, Bert Verhees wrote:
>
>> Hi,
>>
>> I got an idea when reading the nice story from Heather on LinkedIn. In
>> fact it is hers idea, but in a opposing way.
>>
>> https://www.linkedin.com/pulse/journey-interoperability-part-i-heather-leslie
>>
>> https://www.linkedin.com/pulse/journey-interoperability-part-ii-heather-leslie
>>
>> I wonder in how far it is feasible and useful to create archetypes from
>> SNOMED concepts, it would be possible to generate them, with attributes and
>> so on.
>> In a few hours time, one would have a complete forest with archetypes,
>> including ontology in more languages.
>> Maybe some smart handling, filtering, combining can create a better
>> collection, also looking at the paths, so that there are similar paths for
>> similar situations, to keep the number of different datapoints low, which
>> can help creating a faster key-value storage.
>>
>> I don't know how it is about copyright, with members, and licensing, that
>> should be looked at.
>>
>> The argument that SNOMED is fragmented should not count, I think (however
>> without having an expertise on this), because, when working with
>> handwritten archetypes will always be incomplete and fragmented.
>>
>> Bert
>>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


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

SV: CAMSS assessment of openEHR

[Erik Sundvall]

Hi!

Sadly I don't think it is very often you see goverment initiatives etc actually 
looking for standardisation at the "clinical" layer in the sense of 
documentation models that openEHR archetyping covers.

They often look for a technical standard (capable of defining messages and 
code-value-paitinig etc) plus some set of terminology systems. They often 
believe that such a combination will solve the interoperability problems 
efficiently.

I do not think they usually consider the quality of the clinical content or the 
processes, ecosystems, communities and update mechanisms used to produce those 
message defintitions or documentation patterns. Neither do they consider how 
well message definitions match what clinicians actually want to enter in EHR 
systems and later query for. (They probably think that is the job of each EHR 
vendor and that mapping-wizards will do the magic of converting from EHR 
entries to messages and back, as usual.)

Sometimes this applies: 
https://coiera.com/2015/05/12/a-modest-e-health-proposal-to-government/ I don't 
know if that is valid for the Norwegian situation now or not.

Please share good examples of national initiatives actually assesing the 
clinical qualities of different approaches. That could be userful and 
interesting to look at.

Best regards,
Erik Sundvall


Från: openEHR-technical [openehr-technical-boun...@lists.openehr.org] för Ian 
McNicoll [i...@freshehr.com]
Skickat: den 9 april 2016 09:38
Till: For openEHR technical discussions
Ämne: Re: CAMSS assessment of openEHR

Hi Silje,

As far as I can see the specification process is fully documented at 
http://openehr.org/programs/specification/ but it is a technical specification 
and therefore highly detailed.

but in terms of ' standards' development, which I thought was the initial 
remit, surely the clinical modelling layer is just as significant (possibly 
more so)?

Ian

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

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 6 April 2016 at 13:20, Bakke, Silje Ljosland 
<silje.ljosland.ba...@nasjonalikt.no<mailto:silje.ljosland.ba...@nasjonalikt.no>>
 wrote:
I think they’re only interested in the specs, not archetypes. And I think the 
point is that it should be possible to learn how the processes work without 
being shown. :)

Regards,
Silje

Fra: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]
 På vegne av Ian McNicoll
Sendt: 5. april 2016 23:04
Til: For openEHR technical discussions
Emne: Re: CAMSS assessment of openEHR

Just to add. I sense that there is a real difficulty for those involved in the 
reviews in understanding anything other than traditional ISO/CEN type 
standards/specification processes.

Do we have an opportunity to show them how an archetype review process works, 
or to show how the specifications review process works?

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859<tel:%2B44%20%280%29775%20209%207859>
office +44 (0)1536 414994<tel:%2B44%20%280%291536%20414994>
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 5 April 2016 at 23:01, Ian McNicoll 
<i...@freshehr.com<mailto:i...@freshehr.com>> wrote:
Hi Silje,

Thomas and Erik have answered substantial aspects related to specification 
review.

2.   A.18: “Is relevant documentation of the development and approval 
process of the specification archived and identified?”

The Clinical content review process and governance structures is documented at:

https://openehr.atlassian.net/wiki/display/healthmod/Archetype+authoring%2C+review+and+publication
https://openehr.atlassian.net/wiki/display/healthmod/Content+publication%2C+terminology+binding+and+language+translations
https://openehr.atlassian.net/wiki/display/healthmod/CKM+Governance+Environment

3.   A.23: “Is relevant documentation of the development and approval 
process of technical specification or standards publicly available (e.g. 
preliminary results, committee meeting notes)?”

All Clinical content development and approval process is accessed via the 
international CKM tool at openehr.org/ckm<http://openehr.org/ckm>. All reviewer 
and editorial comments, publication decisions and historica

Re: CAMSS assessment of openEHR

[Erik Sundvall]

Adding some thoughts below.

On Mon, Apr 4, 2016 at 4:02 PM, Thomas Beale <thomas.be...@openehr.org>
wrote:
>
> 4.   A.26: “Does the maintenance organisation for the technical
> specification or standard have sufficient finances and resources to be sure
> of freedom from short- to medium-term threats?”
>
> ·   Unable to find any info about this.
>
>
> What does the question mean?
>
>
Most SEC members are financed by their "home" organisations where thay are
employed, for example EHR systems providers (vendors/projects) and
healthcare organizations. It is in the interest of those organizations to
stay up to date and also to keep the openEHR specifications updated. Most
work is done online and in teleconferences (cheap). Server resources etc
are financed by the openEHR foundation that has recurring membership
incomes.

So yes, there is enough resources to keep things going at current pace.


> 5.   A.27: “Does the technical specification or standard have a
> defined policy for version management?”
>
> ·   The change process has a description about version numbering, but
> we can’t find anything about handling different versions, compatibility,
> etc.
>
>
> Eveything is versioned in openEHR; the release strategy
> <http://www.openehr.org/programs/specification/releasestrategy>describes
> the rules of versions assignment to releases. Other than that, we would
> need to know the specific question to be able to answer better.
>

Additionally, most openEHR artifacts follow http://semver.org/


> 7.   A.48: “Does the technical specification or standard address
> backward compatibility with previous versions?”
>
> ·   Can’t find any info about this on the web pages.
>
>
> see the above link to release strategy.
>

Backwards compatibility for clinical content (already stored EHR data) is
one of openEHRs real strengths. Breaking changes to the RM (technical
reference model) level are uncommon (and migration strategies are usually
provided for any such changes). The more frequent hanges at the AM level
(archetypes and templates) do not break the readability of content based on
previous archetypes etc (since the RM and everything built on the RM stays
the same).

Also the maximal-dataset approach and broad clinical review used for
international archetyping also produces a lower number of surprising
changes in implemented systems due to reduction of the, in other approaches
more commonly occuring, finding of: "Ouch, I didn't consider that less
common usecase when designing my initial datamodel".

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se
) http://www.regionostergotland.se/cmit/
Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Advantage of ISO

[Erik Sundvall]

I forgot to discuss/kill the "fear-of-patent" thought here. At
Stackoverflow (
http://stackoverflow.com/questions/32010122/are-the-hl7-fhir-hl7-cda-cimi-openehr-and-iso13606-approaches-aiming-to-solve)
I wrote:
"The computable resources from openEHR are Apache 2 licensed and that
licence (apache.org/licenses/LICENSE-2.0) has an anti-patent clause (#3).
The ADL (Archetype definition language) grammar and the UML sourcecode are
such resources. Yes, the written documentation is currently CC-BY-ND but
the archetype formalism (AOM/ADL) and the Reference Model (RM) have been
scientifically published years ago and are thus impossible to claim any
patents on. It might still be a good idea (for PR reasons not patent
reasons) to let ISO to make a version of AOM/ADL2.0 into a formal standard."

Bert then replied:

"I need to clarify a bit more, the Apache-Licence speaks only for the
publisher (not filing patent-claims against the user of the published
work). But in this special case, where the suspicion has risen that the
publisher would have secret patents, this should be sufficient. So I agree
with you, also on your other arguments."

That was an angle new to me that I had not noticed before, so lets dive in:

Already published things can never be patented (you can only patent "new"
inventions). So would then the (somewhat paranoid) fear still left be the
suspicion that the openEHR foundation (or Ocean Informatics or UCL) already
had (a now still valid) patent regarding something in openEHR before
publishing? I guess that can be easily checked for example at:
https://www.epo.org/searching/free/espacenet.html and
http://patft.uspto.gov/ for anybody that does want to take their word for
it... (Patent search left as exercise to the interested reader...)

Are there any other patent fears/arguments that we can get out into the
light of this open forum?

// Erik

P.s. By the way, feel free to answer and upvote the original stackexchange
question itself now at 0 from previous -2 :-) Also remember to post new
useful openEHR-related questions.



On Fri, Sep 4, 2015 at 10:45 PM, Erik Sundvall <erik.sundv...@liu.se> wrote:

> Thank you Ian, that was a very constructive contribution to the
> discussion. I had started writing a response with some of those thoughs:
>
> Since this issue of "ownership" keeps coming up, let's deal with it in a
> sensible and polite manner and get it over with even if it requires some
> time and patience. Doing it in an open forum like this is perfect. Let all
> fears and haunting thoughts come out into the light so that they can be
> studied and discussed in detail.
>
> And Gerard, please select less questionable and easily misunderstood
> wording than "proprietary" to describe the issue, so that we can understand
> the real core issue. There are plenty of other wordings to choose from that
> will reduce risks of misunderstanding.Otherwise possibly good intentions in
> an "ownership-discussion" will likely be interpreted as you deliberately
> wanting to spread FUD
> <https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt> regarding
> openEHR, and that is probably not the way you want to be percieved.
>
> Generally speaking; it is natural to feel suspicious if you don't
> understand how decisions affecting you are being made and you don't know
> how you can influence (or if needed try to replace) the decisionmakers.
> Also, it is pretty natural that it is hard to fully understand other
> people's suspicions if you are one of the decision makers or if you for
> good reasons (experience, knowing their intentions etc) already fully trust
> them. (I have seen this from both angles over time.)
>
> That is why perpetual open licenses are such a help, no one can ever take
> away the thing you or your project is dependent on.
>
> With licences that are both "forkable" (no ND-clause) and non-contageous
> (no SA-clause) like Apache 2 and CC-BY (and CC0) you have even more
> protection - you don't even have to trust the decision makers to go the
> right way in the future with the project you invested time and resources
> in. If they misbehave grossly you can together with enough of the
> disgruntled community start a new future for a copy of the project under a
> new name.
>
> For fully forkable projects the "who is the IP owner"-arguments ar always
> completely irrelevant, don't you agree? Wouldn't the argument regarding
> "proprietary" be obviously rediculous in such a context?
>
> For some reason, that I have not yet fully understood, previous and
> current leadership of openEHR has not yet dared taking the step to skip all
> ND- and SA- clauses. (Like an anxious over-protective parent afraid to give
> their now fairly grown teenager enough trust and fre

Re: Advantage of ISO

[Erik Sundvall]

Thank you Ian, that was a very constructive contribution to the discussion.
I had started writing a response with some of those thoughs:

Since this issue of "ownership" keeps coming up, let's deal with it in a
sensible and polite manner and get it over with even if it requires some
time and patience. Doing it in an open forum like this is perfect. Let all
fears and haunting thoughts come out into the light so that they can be
studied and discussed in detail.

And Gerard, please select less questionable and easily misunderstood
wording than "proprietary" to describe the issue, so that we can understand
the real core issue. There are plenty of other wordings to choose from that
will reduce risks of misunderstanding.Otherwise possibly good intentions in
an "ownership-discussion" will likely be interpreted as you deliberately
wanting to spread FUD
<https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt> regarding
openEHR, and that is probably not the way you want to be percieved.

Generally speaking; it is natural to feel suspicious if you don't
understand how decisions affecting you are being made and you don't know
how you can influence (or if needed try to replace) the decisionmakers.
Also, it is pretty natural that it is hard to fully understand other
people's suspicions if you are one of the decision makers or if you for
good reasons (experience, knowing their intentions etc) already fully trust
them. (I have seen this from both angles over time.)

That is why perpetual open licenses are such a help, no one can ever take
away the thing you or your project is dependent on.

With licences that are both "forkable" (no ND-clause) and non-contageous
(no SA-clause) like Apache 2 and CC-BY (and CC0) you have even more
protection - you don't even have to trust the decision makers to go the
right way in the future with the project you invested time and resources
in. If they misbehave grossly you can together with enough of the
disgruntled community start a new future for a copy of the project under a
new name.

For fully forkable projects the "who is the IP owner"-arguments ar always
completely irrelevant, don't you agree? Wouldn't the argument regarding
"proprietary" be obviously rediculous in such a context?

For some reason, that I have not yet fully understood, previous and current
leadership of openEHR has not yet dared taking the step to skip all ND- and
SA- clauses. (Like an anxious over-protective parent afraid to give their
now fairly grown teenager enough trust and freedom.) In my mind I sometimes
guess and sense that they have a fear that someone will do some kind of
hostile forking, creating yet another incompatible standard. Who knows,
maybe they fear that Gerard and the 13606-association, CIMI or some other
organization wants to fork all the hard work done by openEHR and manage to
lure the mindshare of the openEHR-community over to another organization? -
There you see an example of the suspicion-mechanism described above: I do
not understand the reasoning for not dropping ND or SA from the license of
different artifacts, thus I start suspecting and guessing things...
Probably not the most constructive way of reasoning, but that is a way our
minds often work; filling out the blanks with guessing.


In the case of openEHR suspicions of biased leadership possibly favoring a
single company or other party (intentionally or just by lack of broader
perspectives/understanding) or perhaps having a hidden patent/IP-claim
coming up were easier to understand some years ago before openEHR, as now,
had several different (often competing) companies and organizations inside
specification comittee and management.


Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se)
http://www.regionostergotland.se/cmit/
Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/


On Fri, Sep 4, 2015 at 7:55 PM, Ian McNicoll <i...@freshehr.com> wrote:

> Hi all,
>
> Gerard is quite correct that I raised this issue in the context of Bert's
> email because he had mentioned the problems of openEHR being perceived as
> 'proprietary', by some potential customers.
>
> Bert had referred to a StackOverflow question, where I had felt the need
> to edit Gerard's statement that 'openEHR is a ... proprietary
> specification'. I have also had cause to have similar statements corrected
> on other occasions where it has been made in official EU and national
> publications. On each occasion the owners of the document have agreed that
> this statement is misleading and unjustified.
>
> @Gerard - thank you for your explanations. What you mean by 'proprietary'
> , I now understand, is that you have concerns that the legal  'ownership'
> of the not-for-profit o

Re: difference and relationship between openEHR and EN13606

[Erik Sundvall]

By the way feel free to add some of the

onsdag 26 augusti 2015 skrev Erik Sundvall erik.sundv...@liu.se:

 Hi!

 Where can one find proposals/diagrams describing the refreshed RM
 (reference model) in the new 13606 revision? Will 13606 keep using the
 old data types or harmonize more with CIMI or OpenEHR?

 Is there now consensus/majority regarding using ADL/AOM 2.0 for 13606? If
 so, great!

 When it comes to simplifying the RM (or perhaps moving complexity to
 another meta/design-pattern layer) I think CIMI has gone further than
 13606. Are there any plans of aligning 13606 with CIMI?

 //Erik Sundvall

 onsdag 26 augusti 2015 skrev Kalra, Dipak d.ka...@ucl.ac.uk
 javascript:_e(%7B%7D,'cvml','d.ka...@ucl.ac.uk');:

 Dear Ian,

 Thanks also for your helpful reflections. I agree that once the standard
 is close to final we should perform and publish a detailed comparison and
 cross mapping between the reference models, as an aid to system
 implementers and tool makers.

 With best wishes,

 Dipak Kalra

 On 26 Aug 2015, at 17:20, Ian McNicoll i...@freshehr.com wrote:

 Thanks Dipak,

 A very clear and helpful statement of current and future intent. I too
 agree that we should not focus negatively on the differences and that they
 are mutually reinforcing but people do ask and it's important that we are
 clear that while 13606 and openEHR share a number of tools, technologies,
 philosophies and even people + good relationships), they are not currently
 interchangeable or directly interoperable.

 From a high-level perspective they are indeed very similar but the
 detailed differences do matter to implementers, and I think we need to be
 clear to the market about these differences.

 Thanks too for the perspective on AQL adoption - makes complete sense to
 me in the 13606 context.

 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 26 August 2015 at 15:33, Kalra, Dipak d.ka...@ucl.ac.uk wrote:

 Dear All,

 This is an interesting discussion, and I would like to stress the
 complementarity of the two.

 openEHR is, as others have said, an important consolidator of the
 state-of-the-art in best practices for the design of an electronic health
 record architecture, repositories and the underpinning of EHR systems. An
 important advantage is that it specifications are publicly accessible, and
 of course it has a vibrant community and a large number of tools to support
 its use.

 13606 has always had a good relationship with openEHR, but is primarily
 intended to be an interface standard between heterogeneous EHR systems, and
 is therefore optimised for that purpose (e.g. for mappings), which means
 its reference model is definitely simpler. There are many countries and
 situations where it is essential to have a formal international standard in
 order for it to be acceptable as part of a national strategy. Some vendors
 have also indicated that they like the inevitable stability of a standard,
 which changes infrequently. 13606 also has a community and tools, and of
 course many of its community are also part of openEHR, and vice versa.

 If one takes a high-level look at the many different globally-used
 representations of health data, it is easy to see that these two reference
 models are indeed very similar. Whilst near to the ground we can easily be
 tempted to focus on their minor differences, I believe it is of greater
 value to society and to our field if we can regard them - and champion them
 - as a mutually reinforcing pair of models.


 The specification of archetypes is very mature, and during the revision
 we expect to upgrade to the latest AOM (which is 2.0). This part of the
 standard will also remain focused on a logical representation supporting
 archetype interchange.


 As has been pointed out, AQL could in theory have been added to the
 standard, since it could “work with 13606. However, another important
 imperative for a standard is that it has reached a sufficient level of
 maturity and stability. It was also felt important by the working groups of
 CEN and ISO that we do not introduce something very novel into this
 revision process. I did suggest that we consider adding a sixth part to the
 standard to support the distributed analysis of electronic health records
 (such as communicating queries). It was felt wiser, and I support this
 view, not to introduce something new to these five parts of the standard,
 but once it has finished its revision to propose a new work item to CEN and
 ISO on the querying of EHRs. AQL will inevitably be an important
 contribution to that new work item, and hopefully by the time we are ready
 for it the AQL specification will be very mature and there will be much
 more experience

Re: difference and relationship between openEHR and EN13606

[Erik Sundvall]

Hi!

Where can one find proposals/diagrams describing the refreshed RM
(reference model) in the new 13606 revision? Will 13606 keep using the
old data types or harmonize more with CIMI or OpenEHR?

Is there now consensus/majority regarding using ADL/AOM 2.0 for 13606? If
so, great!

When it comes to simplifying the RM (or perhaps moving complexity to
another meta/design-pattern layer) I think CIMI has gone further than
13606. Are there any plans of aligning 13606 with CIMI?

//Erik Sundvall

onsdag 26 augusti 2015 skrev Kalra, Dipak d.ka...@ucl.ac.uk:

 Dear Ian,

 Thanks also for your helpful reflections. I agree that once the standard
 is close to final we should perform and publish a detailed comparison and
 cross mapping between the reference models, as an aid to system
 implementers and tool makers.

 With best wishes,

 Dipak Kalra

 On 26 Aug 2015, at 17:20, Ian McNicoll i...@freshehr.com
 javascript:_e(%7B%7D,'cvml','i...@freshehr.com'); wrote:

 Thanks Dipak,

 A very clear and helpful statement of current and future intent. I too
 agree that we should not focus negatively on the differences and that they
 are mutually reinforcing but people do ask and it's important that we are
 clear that while 13606 and openEHR share a number of tools, technologies,
 philosophies and even people + good relationships), they are not currently
 interchangeable or directly interoperable.

 From a high-level perspective they are indeed very similar but the
 detailed differences do matter to implementers, and I think we need to be
 clear to the market about these differences.

 Thanks too for the perspective on AQL adoption - makes complete sense to
 me in the 13606 context.

 Ian

 Dr Ian McNicoll
 mobile +44 (0)775 209 7859
 office +44 (0)1536 414994
 skype: ianmcnicoll
 email: i...@freshehr.com javascript:_e(%7B%7D,'cvml','i...@freshehr.com');
 twitter: @ianmcnicoll

 Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
 javascript:_e(%7B%7D,'cvml','ian.mcnic...@openehr.org');
 Director, freshEHR Clinical Informatics Ltd.
 Director, HANDIHealth CIC
 Hon. Senior Research Associate, CHIME, UCL

 On 26 August 2015 at 15:33, Kalra, Dipak d.ka...@ucl.ac.uk
 javascript:_e(%7B%7D,'cvml','d.ka...@ucl.ac.uk'); wrote:

 Dear All,

 This is an interesting discussion, and I would like to stress the
 complementarity of the two.

 openEHR is, as others have said, an important consolidator of the
 state-of-the-art in best practices for the design of an electronic health
 record architecture, repositories and the underpinning of EHR systems. An
 important advantage is that it specifications are publicly accessible, and
 of course it has a vibrant community and a large number of tools to support
 its use.

 13606 has always had a good relationship with openEHR, but is primarily
 intended to be an interface standard between heterogeneous EHR systems, and
 is therefore optimised for that purpose (e.g. for mappings), which means
 its reference model is definitely simpler. There are many countries and
 situations where it is essential to have a formal international standard in
 order for it to be acceptable as part of a national strategy. Some vendors
 have also indicated that they like the inevitable stability of a standard,
 which changes infrequently. 13606 also has a community and tools, and of
 course many of its community are also part of openEHR, and vice versa.

 If one takes a high-level look at the many different globally-used
 representations of health data, it is easy to see that these two reference
 models are indeed very similar. Whilst near to the ground we can easily be
 tempted to focus on their minor differences, I believe it is of greater
 value to society and to our field if we can regard them - and champion them
 - as a mutually reinforcing pair of models.


 The specification of archetypes is very mature, and during the revision
 we expect to upgrade to the latest AOM (which is 2.0). This part of the
 standard will also remain focused on a logical representation supporting
 archetype interchange.


 As has been pointed out, AQL could in theory have been added to the
 standard, since it could “work with 13606. However, another important
 imperative for a standard is that it has reached a sufficient level of
 maturity and stability. It was also felt important by the working groups of
 CEN and ISO that we do not introduce something very novel into this
 revision process. I did suggest that we consider adding a sixth part to the
 standard to support the distributed analysis of electronic health records
 (such as communicating queries). It was felt wiser, and I support this
 view, not to introduce something new to these five parts of the standard,
 but once it has finished its revision to propose a new work item to CEN and
 ISO on the querying of EHRs. AQL will inevitably be an important
 contribution to that new work item, and hopefully by the time we are ready
 for it the AQL specification will be very mature

Re: difference and relationship between openEHR and EN13606

[Erik Sundvall]

Oh, that got sent too early, sorry. I meant to say:

Feel free to add some of these descriptions to the stack overflow question:
http://stackoverflow.com/questions/32010122/are-the-hl7-fhir-hl7-cda-cimi-openehr-and-iso13606-approaches-aiming-to-solve

Two people thought the question was bad enough to down-vote it, but I think
this discussion shows it to be useful, so maybe that can change.

//Erik

onsdag 26 augusti 2015 skrev Erik Sundvall erik.sundv...@liu.se:

 By the way feel free to add some of the

 onsdag 26 augusti 2015 skrev Erik Sundvall erik.sundv...@liu.se
 javascript:_e(%7B%7D,'cvml','erik.sundv...@liu.se');:

 Hi!

 Where can one find proposals/diagrams describing the refreshed RM
 (reference model) in the new 13606 revision? Will 13606 keep using the
 old data types or harmonize more with CIMI or OpenEHR?

 Is there now consensus/majority regarding using ADL/AOM 2.0 for 13606? If
 so, great!

 When it comes to simplifying the RM (or perhaps moving complexity to
 another meta/design-pattern layer) I think CIMI has gone further than
 13606. Are there any plans of aligning 13606 with CIMI?

 //Erik Sundvall

 onsdag 26 augusti 2015 skrev Kalra, Dipak d.ka...@ucl.ac.uk:

 Dear Ian,

 Thanks also for your helpful reflections. I agree that once the standard
 is close to final we should perform and publish a detailed comparison and
 cross mapping between the reference models, as an aid to system
 implementers and tool makers.

 With best wishes,

 Dipak Kalra

 On 26 Aug 2015, at 17:20, Ian McNicoll i...@freshehr.com wrote:

 Thanks Dipak,

 A very clear and helpful statement of current and future intent. I too
 agree that we should not focus negatively on the differences and that they
 are mutually reinforcing but people do ask and it's important that we are
 clear that while 13606 and openEHR share a number of tools, technologies,
 philosophies and even people + good relationships), they are not currently
 interchangeable or directly interoperable.

 From a high-level perspective they are indeed very similar but the
 detailed differences do matter to implementers, and I think we need to be
 clear to the market about these differences.

 Thanks too for the perspective on AQL adoption - makes complete sense to
 me in the 13606 context.

 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 26 August 2015 at 15:33, Kalra, Dipak d.ka...@ucl.ac.uk wrote:

 Dear All,

 This is an interesting discussion, and I would like to stress the
 complementarity of the two.

 openEHR is, as others have said, an important consolidator of the
 state-of-the-art in best practices for the design of an electronic health
 record architecture, repositories and the underpinning of EHR systems. An
 important advantage is that it specifications are publicly accessible, and
 of course it has a vibrant community and a large number of tools to support
 its use.

 13606 has always had a good relationship with openEHR, but is primarily
 intended to be an interface standard between heterogeneous EHR systems, and
 is therefore optimised for that purpose (e.g. for mappings), which means
 its reference model is definitely simpler. There are many countries and
 situations where it is essential to have a formal international standard in
 order for it to be acceptable as part of a national strategy. Some vendors
 have also indicated that they like the inevitable stability of a standard,
 which changes infrequently. 13606 also has a community and tools, and of
 course many of its community are also part of openEHR, and vice versa.

 If one takes a high-level look at the many different globally-used
 representations of health data, it is easy to see that these two reference
 models are indeed very similar. Whilst near to the ground we can easily be
 tempted to focus on their minor differences, I believe it is of greater
 value to society and to our field if we can regard them - and champion them
 - as a mutually reinforcing pair of models.


 The specification of archetypes is very mature, and during the revision
 we expect to upgrade to the latest AOM (which is 2.0). This part of the
 standard will also remain focused on a logical representation supporting
 archetype interchange.


 As has been pointed out, AQL could in theory have been added to the
 standard, since it could “work with 13606. However, another important
 imperative for a standard is that it has reached a sufficient level of
 maturity and stability. It was also felt important by the working groups of
 CEN and ISO that we do not introduce something very novel into this
 revision process. I did suggest that we consider adding a sixth part to the
 standard to support the distributed analysis of electronic

AQL ANTLR4-grammar

[Erik Sundvall]

Hi!

At Medinfo2015 i have been positively surprised by all the different
openEHR implementations that I had not heard of before.

AQL capability is present or planned in both some of the previously and
recently known openEHR implemetnations

It would be good to collaborate around testing, updates and practial
application of shared AQL grammar resources so that it becomes easier to
support AQL in openEHR implementations.

When implementing AQL in the LiU-EEE REST demonstrator we used Java CC,
that was a bit messy and uncomfortable working with. Using ANTLR4 seems
like a potentially better way to go now, (including better tooling etc) so
let's help each other with ANTLR4 grammar and application.

Related wiki-pages:

   -
   https://openehr.atlassian.net/wiki/display/spec/AQL-+Archetype+Query+Language
   - https://openehr.atlassian.net/wiki/display/spec/ANTLR+AQL+grammar - Is
   the v0.0.28: Aql.g
   
https://openehr.atlassian.net/wiki/download/attachments/4915228/Aql.g?version=2modificationDate=1413556925000api=v2.
   available from there the latest AQL ANTLR-grammar that anybody is aware of?

Please respond and tell the rest of us what kind of plans, ideas and
experiences you have regarding AQL parsing/implementation/translation etc.

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se)
http://www.regionostergotland.se/cmit/
Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: ADL versions 1.4, 1.5 and 2.0

[Erik Sundvall]

And now some ADL 2.0-related news: as of yesterday you can explore the ADL
2.0 capable developer-pre-release of the openEHR web based archetype- and
template-editors (templates can also be exported to OPT 1.4)

Have a look at the presentation from Medinfo yesterday:
https://goo.gl/7Cd52R

When the web-client source code has been moved to the right place, we'll
post info to the lists.

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se)
http://www.regionostergotland.se/cmit/
Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/

On Thu, Aug 13, 2015 at 9:30 AM, Bert Verhees bert.verh...@rosa.nl wrote:

 Thanks Thomas, for the clarification. Very useful.

 Bert
 Op 13 aug. 2015 06:26 schreef Thomas Beale 
 thomas.be...@oceaninformatics.com:


 Dave,

 I'll try to answer a few.

 Firstly, please treat the active specifications as what you find by going
 to the home page 'Specifications' button (top left), i.e. the HTML specs
 here
 http://www.openehr.org/programs/specification/releases/currentbaseline#ADL2
 .

 Second point, 'ADL 1.5' was what we used for a long time as the moniker
 for 'next generation ADL', until we realised that we introduced breaking
 changes due to CIMI, OMG/AML and openEHR development work. So 'ADL / AOM 2'
 is the 'modern' archetype formalism.

 We never released any interim version, although some people think we
 should, as per this page
 https://openehr.atlassian.net/wiki/display/ADL/ADL+1.4+Migration+Roadmap
 .

 The ADL / AOM 2 specs referred to above are not yet quite complete -
 there are a few more additions to the documents, and 2 very minor potential
 semantic changes - semantic slots and smarter annotations. I would expect
 these specs to be ready for release formal TRIAL in the next 4 weeks.

 Why does ADL2/AOM2 exist? It addresses various limitations in ADL1.4,
 including lack of proper modelling for specialisation, templating, proper
 versioning and id rules, and proper value sets. A full list is here
 https://openehr.atlassian.net/wiki/display/ADL/Evolution+from+ADL+1.4.

 The ADL Workbench http://www.openehr.org/downloads/ADLworkbench/homewill
 reliably (in most cases) convert ADL 1.4 archetypes to ADL 2 form. This
 transform is not trivial, so anyone who wants to do this conversion should
 use this tool, or the command line version.

 CIMI is using only ADL/AOM 2, and CIMI will become a working group of
 some kind in HL7 (agreed but not finalised yet), so HL7 will potentially
 use ADL 2 at some point (but I assume jut the CIMI workgroup for some
 time).

 ADL/AOM2 is the basis for the OMG Archetype Modelling Language (AML)
 specification, which has entered the standards track a few months ago.

 On the ground in openEHR implementation space, ADL 1.4 is being used. New
 tools that are internally ADL 2 will / do generate ADL 1.4 OPTs to enable
 these systems to keep running. The ADL Workbench doesn't yet do this but
 will.

 There is an XML Schema for ADL / AOM 2 here
 https://github.com/openEHR/specifications/tree/master/ITS/AOM2/XML-schema,
 also reachable from the current specifications page
 http://www.openehr.org/programs/specification/releases/currentbaseline.

 The tougher question to answer is when systems will move to ADL 2. THere
 are two questions: EHR systems, and tools. Tools can move faster, and are
 already being changed. CKM also incorporates some ADL 2 features already.
 EHR systems will move more slowly and carefully for obvious reasons, which
 is why we need ADL 1.4 OPT support in next gen tools. I would expect some
 vendors to eventually support ADL 1.4 and ADL2, and existing ADL 1.4 based
 deployments may stay on ADL 1.4.

 - thomas

 On 12/08/2015 04:32, Barnet David (HEALTH AND SOCIAL CARE INFORMATION
 CENTRE) wrote:

 All



 Hope everyone is well.

 I have a few questions on ADL versions



 Is there a general view as to when archetypes will be created in an ADL
 version other than version 1.4?



 I’ve sampled CKMs from various countries  found all archetypes (that I
 sampled) were in the ADL 1.4 format.



 Some questions:

 Is anyone planning to use anything other than ADL 1.4 in the near future?



 How will CKMs cope with multiple ADL versions in a single CKM?



 When will tools be available to create archetypes in 1.5 and 2.0?



 How will the export format change from ADL 1.4 to 1.5 and 2.0?



 Will I be able to import an archetype in 1.5 or 2.0 into my CKM?



 Is there an XML schema available for 1.5 and 2.0?



 When do we expect archetypes in 1.5  2.0 to be the norm?



 What’s the driver to move to archetypes created to DL version 1.5 or 2.0?



 Are all the answers in the published document
 http://www.openehr.org/releases/trunk/architecture/am/adl2.pdf ?



 Regards



 Dave Barnet
 Health and Social Care Information Centre

 NHS England, UK



 --
 [image

Re: VERSION.lifecycle_state options

[Erik Sundvall]

Hi!

Is a new type of VERSION.lifecycle_state the best to solve the described
use-case? Won't the correcting a typo change or we forgot a thing
use-cases etc still always be there even for things written as binding
contracts?

Is it perhaps enough to have the final plan fixed/fixated by applying
digital signatures on the VERSION using the ATTESTATION
http://www.openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1433773264996_418417_8398
class, thus marking the contractual agreement with digital signatures so
that nothing be changed without the system (and/or users) noticing it.

The application can then, for the type of change-sensitive documents
described by Sebastian, perform signature checks and show warnings or
refuse to update info unless the change is signed by the same persons or
organisations that signed the previously signed version.

To me it seems natural that binding contracts and signatures belong
together.

Heath's use-case something to indicate a version was moved distinct from
deleted won't be solved by signatures though, so
https://openehr.atlassian.net/browse/SPECPR-83 is still valid.

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se)
http://www.regionostergotland.se/cmit/
Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/

On Thu, Jun 11, 2015 at 10:30 AM, Sebastian Iancu sebast...@code24.nl
wrote:

 Hi,

 I can rephrase my question: How can I indicate that a version should not
 be changed under any circumstances? How have other openEHR implementations
 handling this issue (if ever occurred)?

 The use case I have is in mental-care in NL is that care providers are
 setting up a care plan (which consists of many type of documents,
 anamnesis, goals, planned schedule for evaluations, planned interventions,
 actions, etc). During the initial phase of documenting and planning most of
 these are in draft-mode (they are complete, but perhaps need approvals,
 reviews or some are sometimes just considered as proposals), but at some
 point in time some of them they need to be fixated, any later change should
 be forbidden. It is like a contractual relation between care providers
 and/or patient, it requires some sealed papers.

 Whats the best way to handle this? I'm not convinced this is a
 modeling/archetype/template issue, I rather think is something that is part
 of application layer, business logic, etc. but requires a 'flag' on the
 backend data; hence my question/hint about VERSION.lifecycle_state. If I
 would have the option to set it to 'final', I would of course only use it
 for those object that is applicable (when I can guaranty that no change is
 necessary/allowed); most of the time I would probably still rely on
 'complete'. Other openEHR implementations may not need to use this 'final'
 feature if they allow in their versions may always be altered.

 I'm ok to give (if necessary) a different name than 'final', as long it
 reflects the use case I described above. I'm also ok to make a compromise
 and use 'incomplete' where I actually need 'draft' (although I see it as
 two different meanings). Alternatively I could also use 'complete' instead
 of 'draft' as long as I have and 'final' that pairs it.

 @Heath: thanks for your examples and thoughts.

 Regards,
 Sebastian



 On 6/11/2015 1:22 AM, Heath Frankel wrote:

 Hi Sebastian,
 To your general question, yes we needed something to indicate a version
 was moved distinct from deleted. This ensured that we couldn't undelete the
 version. There was a PR for this which included a new change type also.

 To your usecases, I agree these are necessary but have concern about the
 term final. It doesn't seem to have the level meaning necessary for you use
 case as it is overloaded with pathology result status where a final can be
 corrected. Perhaps immutable is more specific. Similarly with draft, seems
 too similar to incomplete. What about unapproved or similar?

 As with all out terminologies, having too many similar options makes it
 hard to select the correct one unless the usecases are very clearly
 specified. I think you have very distinct usecases, we just need to get the
 right term to ensure it best reflects the usecase.

 Regards

 Heath

  On 11 Jun 2015, at 12:03 am, Sebastian Iancu sebast...@code24.nl
 wrote:

 Hello all,

 Does anybody (with an openEHR persistence system/solution) encountered
 the need to record other states than 'incomplete', complete', 'deleted' for
 a VERSION.lifecycle_state?

 The use case is that in some circumstances a version need to become
 immutable and any change should be forbidden. Imagine a care plan that was
 already 'inform-consented' - it should not be allowed to be changed in any
 way, neither logically deleted (unless perhaps some administrative
 reasons). In contrast, by current version of specifications

CRUD Restlet

[Erik Sundvall]

Hi Bert!

Are you sure you have understood the difference between service orientation
and resource orientation? The background chapter in our paper I referred to
earlier briefly touches upon what a resource is, Fielding's dissertation
explains it in detail.

Why do you see the status 404 as an evil error status but 200 as some
totally other kind of status? Both are normal status codes telling
different things. If you consider 404 being an error or just a plain there
is no such resource/patient-id-message depends on context and your
perspective and what you expected to find at that uri. If you are sending
an invalid call to the resource/service you'll most likely get another
status code than 404. 404 often indicates that you sent a proper valid
request to a fully functional server server but asked for something that is
not there.

http://example.org/registry-x/id/123456 is a pointer to a specific
resource, either it exists or not. 404 says it does not. In the
implementation you describe it seems like patient IDs are modelled as
resources.

Most (good) REST designs will let you get information about usage and
status/availability of the containing resource (probably a or registry
id-query resource/service in your case) by chopping of the last piece of
the URL, for example http://example.org/registry-x/ or
http://example.org/registry-x/id/ if that is what you want to know the
status/availability of.

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region ?sterg?tland: erik.sundvall at regionostergotland.se (previously lio.se)
http://www.regionostergotland.se/cmit/
Link?ping University: erik.sundvall at liu.se, http://www.imt.liu.se/~erisu/

On Sun, Jan 18, 2015 at 11:21 AM, Bert Verhees bert.verhees at rosa.nl wrote:


  https://developers.google.com/drive/web/handle-errors


 This is exactly my point, 404 is for handling errors, someone not being in
 a hospital-register is not an error. To check if someone is, and he isn't,
 that is not necessarily an error.
 It may even be a good thing, that someone never has been ill in a specific
 hospital.
 The only thing that a computer, without value judgment can say, is that
 the call iss successful (HTTP-status 200), and the answer is No, he is not
 in the register. That is information.

 To call an non-existing service, that is an error, and should return 404.
 That is what Restlet also has implemented.

 Bert


 ___
 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/20150118/ef185396/attachment-0001.html

Upcoming EHR procurment in Sweden

[Erik Sundvall]

Hi!

I just want to notify EHR vendors and other interested parties that there
is now a (from Swedish perspective) big procurement/buying process
starting. It is the three largest healthcare regions in Sweden covering 5
million of Sweden's 9 million inhabitants, it is the regions containing
Sweden's largest cities Stockholm (Stockholms l?ns landsting), Gothenburg
(V?stra G?talandsregionen) and Malm? (Region Sk?ne) that together will
attempt to get a good deal for a new (probably) all comprehensive
EHR/Health-IT-system covering for example both primary and secondary care.
I hear rumors that the deal or procurement might be open for other Swedish
regions to join.

Personally I hope that whoever wins this battle will be open to using real
open/shared detailed clinical modeling via something like CIMI, ISO13606 or
openEHR and open/shared clinical query capabilities comparable to AQL, and
a way to share decision support rules between systems. Either by using some
powerful enough RM+AM system internally or by creating reusable (not too
manually resource demanding) conversion mechanisms between internal
models/queries/rules and international shared models/queries/rules.

If the procurement organisation sees enough value in such shared
models/queries/rules or not, I guess is still an open question that
probably will be affected by how different actors present the value of this
compared to potential benefits of proprietary such models and systems.

A press release in Swedish with some names and contact information is
available at
http://www.mynewsdesk.com/se/region_skane/pressreleases/nu-laeggs-grunden-foer-ett-gemensamt-informationssystem-foer-sjukvaarden-1105218
(and
via a non-perfect Google translation
https://translate.google.com/translate?sl=svtl=enjs=yprev=_thl=svie=UTF-8u=http%3A%2F%2Fwww.mynewsdesk.com%2Fse%2Fregion_skane%2Fpressreleases%2Fnu-laeggs-grunden-foer-ett-gemensamt-informationssystem-foer-sjukvaarden-1105218edit-text=act=url
)

According to an article at...
http://computersweden.idg.se/2.2683/1.604479/nu-lyfter-de-tre-stora-vardregionerna-it-miljon
(and
via a non-perfect Google translation
https://translate.google.com/translate?hl=svsl=svtl=enu=http%3A%2F%2Fcomputersweden.idg.se%2F2.2683%2F1.604479%2Fnu-lyfter-de-tre-stora-vardregionerna-it-miljon
)
...there will first be a requirements gathering process (around one year?)
and then procurement follows.The article states that they are looking a bit
at Denmark and Finland that recently have bought new systems.

One could hope that they will also have a look at some recent Norwegian
Nasjonal IKT developments involving open specifications and archetypes,
e.g. http://arketyper.no/ckm/. I guess a similar procurement battle is
going on in (or coming to) Norway.

It is worth noting that Sweden is a member of IHTSDO and that Snomed CT has
been translated and is available in Swedish. I hope vendors will show
proper capabilities to make use of powerful terminology systems and
ontologies and that requirement gathering staff will describe what they
want to use the systems for now and in the future.

As always the requirements gathering is likely to be influenced by what is
already available on the market and by marketing actions of involved
players.

This message contains no secrets so feel free to forward it to other
persons and organisations.

Good luck to both vendors and requirement gathering staff!

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region ?sterg?tland: erik.sundvall at regionostergotland.se (previously lio.se
) http://www.regionostergotland.se/cmit/
Link?ping University: erik.sundvall at liu.se, http://www.imt.liu.se/~erisu/

P.s. to openEHR vendors:
If...
you in a connectathon-like demo can demonstrate real interoperabilty
between several openEHR-capable systems and that complete EHR content for
patients, decision rules, archetypes, templates etc can be moved from one
system to several competing (and/or open source) systems without too much
hassle
...then...
the procurement argument of avoiding vendor lock-in will be more
interesting. Such a demo would be interesting for some of us working in
other Swedish regions too.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150116/5db71c4b/attachment-0001.html

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

[Erik Sundvall]

Hi and seasons greetings!

I find the openEHR board nomination process a bit confusing and pretty
different to what I am used to in other community settings.

When joining as an openEHR individual member you first have to wait until
your application has been approved, this might be logical in some ways, but
it means you will need to remember to get back to the member site some days
later and then do your nominations (a nomination dropout risk).

Also you can not even view nominations without logging in. After logging in
I did not find any list of members possible to nominate, but after
navigating around a while I found these four nominations:
- Bosca Tomas, Diego
- McNicoll, Ian
- Bakke, Silje Ljosland
- Kobayashi, Shinji

I guess these nice persons were nominated by individual members, I did not
find any information regarding if industry members have nominated any
candidates.

I did not find any information regarding if any of the current board
members are considered already nominated or not (I guess not, since Ian is
on the current board and has been nominated separately).

The strangest thing, unless I misunderstood the submission form:
The form is rigged primarily to nominate yourself, and it is optional
to Include
name in list of event registrants - does that mean that there may be
people secretly nominated? Very strange at least from a Swedish
community/NGO/volunteer-org perspective.

I would like to nominate Thomas Beale for example, can I do that? By
replacing my own name that is pre-filled in the form I guess it is possible
to nominate someone else but it is far from obvious from form-texts
regarding your nomination etc.

In the community settings I am used to, the nominations are open so that
any member can nominate any member, then the nominated persons are asked if
they would accept a nomination or not, then there is a vote among the
remaining nominated persons.

I would suggest some changes
- Listing all current nominations (including from both industry and
individual members) without login requirement
- Allowing at least logged in members to see who else is a member (so that
we know who can be nominated and can encourage people to become members if
they are not listed)
- Making it possible to nominate other people than yourself
- Clarifying if anybody not on the visible nomination list is considered to
be nominated
- Send out nomination reminders regularly (perhaps including a list of the
then nominated persons)

Best regards,
Erik Sundvall

Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Li?: erik.sundvall at regionostergotland.se (lio.se changing name 1 Jan 2015)
LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/

On Tue, Dec 23, 2014 at 12:58 AM, sam.heard at openehrfoundation.org wrote:

  Happy Xmas everybody,

 Thank you to the new members and Industry Partners that have joined up so
 far. We have three nominations for the Management Board at this stage. Two
 of the companies have asked for an extension for the joining date to allow
 transition to the new Calendar year.

 The Board considered their request at the last Board meeting and agreed.
 Consequently the closure date for nominations has been extended to the 31
 Jan 2015.

 Please join up by going to http://members.openehr.org We need a broad
 and representative group to vote for the Management Board. Your involvement
 is crucial. The funds also help us with the provision of some of the
 fundamentals (web site, CKM etc).

 Have a great break over Xmas but make sure you contribute to the MedInfo
 workshops by the middle of January. Keep an eye on the lists for details.

 Looking forward to working with you all in 2015!

 Cheers, Sam

 Dr Sam Heard
 Chairman, openEHR Foundation


 ___
 openEHR-announce mailing list
 openEHR-announce at lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-announce_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141228/dfe62a4f/attachment.html

Does anyone implemented a transformation between AQL and XML?

[Erik Sundvall]

Hi!

Sorry for joining the discussion late. (Vacation season)

During the development of LiU EEE (https://github.com/LiU-IMT/EEE) we (in
addition to AQL-to-XQuery-translation) actually created a simple
XML-representation of the AQL parse-tree for initial debugging/analysis
purposes. I do not think we maintained this XML-debugging feature in the
later parts of application development so it is most likely buggy or
defunct. You may play around with the code in
https://github.com/LiU-IMT/EEE/blob/master/src/main/java/se/liu/imt/mi/eee/AQL_Parser/AqlParser.jj
and set the return type to XML instead of XQuery_EEE_0_1.

Be warned: messing around in JavaCC is error prone. ANTLR is probably nicer
and has good tooling support. It would be a good community contribution for
somebody to make an open source implementation of an ANTLR-based AQL
parse-tree generator and query language transformation engine :-)

Best regards,
Erik Sundvall

Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Li?: erik.sundvall at regionostergotland.se (lio.se changing name 1 Jan 2015)
LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/

On Wed, Dec 17, 2014 at 9:52 PM, pablo pazos pazospablo at hotmail.com wrote:

 Great! Thanks for the info.

 --
 Kind regards,
 Eng. Pablo Pazos Guti?rrez
 http://cabolabs.com http://cabolabs.com/es/home
 http://twitter.com/ppazos

 --
 Date: Wed, 17 Dec 2014 21:50:22 +

 Subject: Re: Does anyone implemented a transformation between AQL and XML?
 From: serefarikan at kurumsalteknoloji.com
 To: openehr-technical at lists.openehr.org

 Ok, I think I see what you mean now.

 AQL is not part of the official specification and there is not much other
 than the grammar for the implementers so you're right about not having a
 lot to work with.
 On the other hand, if you're going to do AQL, you're going to have to have
 a parser. Marand has kindly provided an ANTLR grammar here:
 https://openehr.atlassian.net/wiki/display/spec/AQL-+Archetype+Query+Language

 To use this grammar, you're going to have to invest into learning ANLTR
 and inevitably into parser generators. Not an easy topic if you're not
 familiar with it but I personally think it is worth it.

 due to way ANTLR works, Marand's grammar should get you really close to
 what you're asking without much effort. You'll probably have more of a
 challenge when trying to map the output of the parser to your query
 mechanism.

 So the obvious pointer is the ANTLR grammar, the rest depends on your
 efforts :)

 All the best
 Seref


 On Wed, Dec 17, 2014 at 8:31 PM, pablo pazos pazospablo at hotmail.com
 wrote:

 Hi Seref, what I asked here was if anyone did implemented that, so I don't
 have to :)

 As I said, my experience tells me it requires more hours-man to work with
 a syntax, a model and a parser than having XML and parse parts of it when
 required (so I can have 1. many ad-hoc parsers, 2. no model just ad-hoc
 data structures, 3. no API, 4. no parser e.g. it requires a lot of time to
 find a problem update the jj, generate the parser and test).

 Hope that clarifies my vision.

 Of course, I didn't started yet to do anything about AQL support, just
 trying to make the community aware that I'll do so and maybe generate some
 collaboration momentum. Maybe the syntax definition is very stable and
 there are a lot of good parsers for Java, but the syntax definition I found
 seems to be old (
 https://openehr.atlassian.net/wiki/display/spec/Archetype+Query+Language+Grammar
  
 https://openehr.atlassian.net/wiki/display/spec/AQL-+Archetype+Query+Language)
 and I don't know about AQL parsers for Java (just found this old
 discussion, no response about the parser:
 http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2009-March/004400.html
 ).

 I'm sure I need to do more research, but I doubt I can find the basic
 building blocks, even to start working with AQL directly.

 Please if you know where I can find stuff to help me, any pointers will be
 very welcome!

 --
 Kind regards,
 Eng. Pablo Pazos Guti?rrez
 http://cabolabs.com http://cabolabs.com/es/home
 http://twitter.com/ppazos

 --
 Date: Wed, 17 Dec 2014 19:03:28 +

 Subject: Re: Does anyone implemented a transformation between AQL and XML?
 From: serefarikan at kurumsalteknoloji.com
 To: openehr-technical at lists.openehr.org

 Hi Pablo,
 Sorry but I still don't get it :) How are you going to do the following
 without an AQL parser?:

 AQL (syntax) =(transformation)= XML (syntax)


 If you have an xml form of AQL and use only that, you'd have to force your
 users write queries in the xml form of AQL which would defeat the whole
 purpose of the AQL.

 So I'm still not seeing how you're gaining anything with an XML form of
 AQL.

 Best regards
 Seref


 On Wed, Dec 17, 2014 at 4:17 PM, pablo pazos pazospablo at hotmail.com
 wrote:

 Hi Seref,

 Yes! Just need

Licensing of specs and artifacts

[Erik Sundvall]

 that W3C licensing disallows forks does not dictate that openEHR
needs to go the same direction. Using only CC-BY or CC-0 on the specs might
be a good FUD-killer, nobody then needs to trust that openEHR governance
will stay fit in the future. If the openEHR organization gets overtaken or
deadlocked, then forking can occur and progressive people/companies that
want to develop new improved versions can do that (if they call the new
thing something else than openEHR). Whether such possibilities put bad or
healthy pressures on an organization is of course open to debate. W3C seems
to see forking as a risk or consider themselves big/trusted enough to not
get deadlocked/overtaken. Many open source projects on the other hand see
forking-possibilities as a healthy emergency safeguard against potentially
poor future governance/leadership.

I agree with Bert in the Linkedin-discussion, that it will most likely be
possible to continue creating openEHR-compatible software from currently
published CC-BY-ND licensed specifications, even if there is a ?hostile
takeover? or deadlock of the organization. Especially if all computable
specification items (class definitions etc.) are released under Apache 2
license (I believe that is the current intention). What is published is
already out there and free to use, it can never be taken back.

The ND-clause mainly causes problems for those that in a deadlock/takeover
situation want to fork the project and keep working on _new_ future/updated
versions of the specification. What the ND actually in practice would
protect openEHR against is less obvious to me though. Thus the ND only adds
to the confusion/FUD without bringing any obvious big benefit. (W3C gets
away with it though.) Compatibility issues are better managed through
testing and certification than licensing. Licenses won?t stop errors, or
non-conformance.

Phew? amazing if you had the energy to read all the way down to here.

Tom, regarding what it means to sell Share-Alike (SA) artifacts, I think
you can compare that to http://www.gnu.org/philosophy/selling.html

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Li?: erik.sundvall at lio.se http://www.lio.se/itc/ 
http://www.lio.se/testbadd
LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/




On Thu, Oct 2, 2014 at 4:14 PM, Grahame Grieve 
grahame at healthintersections.com.au wrote:


 Controlling Conformance: CC-0 just means 'public domain', no copyright.
How do you exert any kind of control (which you mention) over the
conformance not being messed with?


 The point of a trademark is that you can control what the name means. We
say that we define what conformance to FHIR means. We expect that
conformance will be messed with - that's just how it works. But no one else
is allowed to say what it means to be conformant to FHIR because hl7 owns
that trademark

 Also, we don't assert any rights around copying, but that doesn't mean
that hl7 isn't the recognised author.

 Copyright: I don't see any harm in having a copyright notice if the
original author(ity) demands it, e.g. Nehta is like this. Copyright is kind
of useless in the land of software and formal models anyway, it's the
licence that counts.


 Well, the way I understand it,  with FHIR now, someone can asset a
copyright on a derived work, but they could not effectively enforce
copyright provisions on the content they include from the FHIR spec. There
might not be much left...


 Attribution: Current thinking has been that if archetypes are
copyrighted to whomever, the licence-to-use would require attribution,
which just means listing authors. I think the value here is that artefact
users know that wide consultation and expertise went into the artefact.


 I don't think there's any relationship between attribution and copyright.
We could choose to attribute if we wanted to. Actually, we do it at the
spec level:  http://hl7.org/implement/standards/fhir/credits.html#credits


 Would't that 'contributors' list disappear under the new FHIR approach?


 No, they're still the contributors.

 Grahame

 -
 http://www.healthintersections.com.au / grahame at healthintersections.com.au
/ +61 411 867 065
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/af556f4a/attachment-0001.html

How to start

[Erik Sundvall]

Hi!

On Wednesday, August 14, 2013, Thomas Beale wrote:

 do you have content you want on that learning centre page? If so, let's
 put it up there.


Well, the appendix at http://www.biomedcentral.com/1472-6947/13/57#sec9 is
our attempt to create a very compact openEHR intro, if you feel that it is
useful, then feel free to link to it from the learning centre page or some
other place.

The illustrations/figures created by us (and the text) are CC-BY licensed
and can thus be freely reused in other contexts or translated provided that
the source is attributed.

//Erik




 On 08/08/2013 21:27, Erik Sundvall wrote:

 Hi!

 On Wed, Aug 7, 2013 at 3:21 AM, Lexis Nexis lexisnexis5490 at gmail.com 
 javascript:_e({}, 'cvml', 'lexisnexis5490 at gmail.com'); wrote:

  Is there a tutorial book I can purchase or some examples? Step-by-step 
 tutorial is best.

  Skim through the 
 documenthttp://www.openehr.org/releases/1.0.2/architecture/overview.pdf to get
 an overview then go back to that and other documents for more detail
 when needed. Also there are some videos 
 athttp://www.openehr.org/resources/learning_centre if you prefer
 watching over reading.

 If you don't mind using alpha-versions of work in progress, then feel
 free to do some openEHR hands-on experiments 
 usinghttps://github.com/LiU-IMT/EEE described in the 
 paperhttp://www.biomedcentral.com/1472-6947/13/57 (Appendix B 
 athttp://www.biomedcentral.com/1472-6947/13/57#sec9 is a very compact
 openEHR intro, perhaps too compact.)

 I hope the instructions at https://github.com/LiU-IMT/EEE/wiki/install
 helps you get it up and running. Try running and modifying AQL queries
 on the provided example content for example.




-- 
V?nliga h?lsningar, / Best regards,
Erik Sundvall
Tel: +46-72-524 54 55
LiO: erik.sundvall at lio.se http://www.lio.se/Verksamheter/IT-centrum/
LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130815/edcfaa72/attachment-0001.html

How to start

[Erik Sundvall]

Hi!

On Wed, Aug 7, 2013 at 3:21 AM, Lexis Nexis lexisnexis5490 at gmail.com wrote:
 Is there a tutorial book I can purchase or some examples? Step-by-step 
 tutorial is best.

Skim through the document
http://www.openehr.org/releases/1.0.2/architecture/overview.pdf to get
an overview then go back to that and other documents for more detail
when needed. Also there are some videos at
http://www.openehr.org/resources/learning_centre if you prefer
watching over reading.

If you don't mind using alpha-versions of work in progress, then feel
free to do some openEHR hands-on experiments using
https://github.com/LiU-IMT/EEE described in the paper
http://www.biomedcentral.com/1472-6947/13/57 (Appendix B at
http://www.biomedcentral.com/1472-6947/13/57#sec9 is a very compact
openEHR intro, perhaps too compact.)

I hope the instructions at https://github.com/LiU-IMT/EEE/wiki/install
helps you get it up and running. Try running and modifying AQL queries
on the provided example content for example.

Best regards,
Erik Sundvall
Tel: +46-72-524 54 55
LiO: erik.sundvall at lio.se http://www.lio.se/Verksamheter/IT-centrum/
LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/

P.s. to list readers: I Hope to see many of you openEHR people at
Medinfo in Copenhagen soon!

TDS (and TDD) implementations?

[Erik Sundvall]

Hi!

Which projects and products out there support TDS (Template Data Schema)?
And do they support conversion of TDDs (Template Data Documents) to
standard canonical openEHR RM instances (in e.g. XML)? Is there any
available XSLT, webservice or other thing that can convert bidirectionally
between TDD and openEHR RM-based instances?

What about a TDS specification? Is there any published or  work-in-progress
document? If not is there any entity, group or person that could/should be
sponsored or bribed to produce such a thing? :-) It seems to be on the
roadmap http://www.openehr.org/programs/specification/roadmap and described
there anyway...

I think TDS is an essential component in the toolbox in practical openEHR
integration projects but without a public spec, it will be harder to take
seriously and hard to make compatible implementations.

(ExampleTDS-info for people not familiar with the approach:
http://www.mz.gov.si/fileadmin/mz.gov.si/pageuploads/eZdravje/Novice/gradiva_predstavitve_dogodkov/Open_EHR/7_integration.pdf
)

Best regards,
Erik Sundvall
Tel: +46-72-524 54 55
LiO: erik.sundvall at lio.se http://www.lio.se/Verksamheter/IT-centrum/
LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130530/2aad8459/attachment-0001.html

New ADL/AOM proposals to solve some old problems

[Erik Sundvall]

Very interesting thoughts Tom!

My initial impression of the proposal is very positive. If I understand
things correctly this will enable shorter and more
readable serializations not only in ADL but also in other formalisms.

If we consider ADL being a
DSLhttp://en.wikipedia.org/wiki/Domain-specific_language mainly
targeted for constraining health-related RMs then simplifications towards
that goal are welcome.

The only potential catch is implementation issues. Have you already tried
implementing a parser for this in some language? (If so, please provide a
link.) I guess the suggestion could make some implementation parts easier
and some a bit trickier.

Best regards,
Erik Sundvall
LiO: erik.sundvall at lio.se http://www.lio.se/Verksamheter/IT-centrum/
LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/

P.s. [/daydreaming] It might be interesting to connect a future updated AOM
1.5 in Java with (de)serialization using Jackson, see
https://github.com/FasterXML Jackson already supports several highly
configurable serialization format options, perhaps ADL or ODIN databindings
would be possible too ;-) RM bindings might be a more interesting use case
than AM bindings though...


On Wed, Apr 24, 2013 at 7:03 PM, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:


 In openEHR we use custom syntax in archetypes to express ordinal
 constraints, quantity constraints and coded text constraints - i..e
 constraints on what are probably the most ubiquitous data types in health.

 I have been mulling over feedback from previous debates here and in CIMI
 about the 'undesirability' of this syntax.

 I have posted some new ideas on how to solve this 
 herehttp://www.openehr.org/wiki/display/spec/ADL+1.5+Power+Syntax+Proposals
 .

 The executive summary is:

- let's treat 'code' as a built in type, like a Date or a Uri; this
then makes an AOM type that constrains this trivial;
 - ADL can be augmented in a generic way to enable tuples to be
constrained, which would better solve the Quantity constraint problem
- The Ordinal constraint syntax would be replaced by a combination of
both of the above.

 Feedback welcome.

 - thomas


 ___
 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/20130425/0eaf65da/attachment.html

Trying to understand the openEHR Information Model

[Erik Sundvall]

Hi Gavin and others!

On Mon, Apr 15, 2013 at 4:39 PM, gjb gjb at crs4.it wrote:

 I thought about this a few years ago and came to the conclusion that
 the GUI/Client would need quite a bit of savvy HCI.
 The person working on the data need to be kept informed
 of how/when the system maybe changing under him.

 Google documents has now come along and does something like that.
 You're busy editing one section of an article then a networked
 colleague begins to edit the same thing.
 GDocs tells you who it is and how to communicate with them by a
 secondary channel (EHR would be the primary channel).
 You can both still keep editing but at least you know you are
 going to have double check the result afterwards.
 Conflict resolution is best avoided by timely human intervention
 rather than automated attempts afterwards.

 And GDocs does well even when clients go offline for a short time.
 [...]
 Gavin Brelstaff - CRS4


Some of the magic behind multi-user/multi-device editing in Google docs
is referred to as operational transformation algorithms.

Have a look at for example:
http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation
or http://en.wikipedia.org/wiki/Operational_transformation

Very interesting stuff when you look closer at it. Some years ago one of
our student projects used some of that power provided in Google Wave to
experiment with an experimental partial implementation of a multi-user
archetype editor. In that case the operational transformation operated on
XML pieces. The simplest case is operations on plain text - that case is
usually described in explanations. Open source implementations of
operational transformation working with for example pieces of JSON are also
available (http://sharejs.org/).

In the upcoming (BMC accepted) paper Applying representational state
transfer (REST) architecture to archetype-based electronic health record
systems (and briefly in my thesis) - I mention the thought of using
operational transformation in the EHR editing stage taking place before
doing real openEHR contribution commits. This would be a possibly
interesting replacement or upgrade of the Contribution Builder component
described in the paper. It would allow for simultaneous shared multi-user
and multi-device data entry for many (but not all) use cases. It won't
scale to thousands of users simultaneously preparing the same contribution
for the same patient but it should scale well for a handful of simultaneous
users per patient if they are somewhat aware of each others duties and
responsibilities. The possibility to flag openEHR content as incomplete
would allow snapshots from the shared contribution build to be persisted in
the proper EHR at a regular interval and/or actively triggered by the user
when they need to shift attention to other things. Later when considered
complete, another version could be marked as complete, be signed
and committed.

If anybody currently has time or resources (e.g. master thesis students) to
pursue an operational transformation openEHR data entry approach in an open
source project, then don't hesitate to contact me for more detailed
discussions and potential cooperation. A bit wiser from my work with the
repeatedly delayed REST implementation and publication approach, I'd prefer
to do such experimentation in an incremental, multi-site, open, public way
instead of only having a big publication/delivery in the end.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/

P.s. Qoute from the upcoming paper Applying representational state
transfer (REST) architecture to archetype-based electronic health record
systems:

 Shared contribution builds is another interesting potential future work.
 The current contribution builder design works best if a contribution build
 is personal and the user uses one device at a time for editing it. For more
 dynamic teamwork or multimodal or multidevice data entry, using systems
 based on Operational Transformation (OT) would likely enhance the user
 experience. OT is a lock-free resolution mechanism that is used for example
 in collaborative systems like Google Docs and Apache Wave (formerly Google
 Wave). Since OT involves many small transactions a use of approaches like
 WebSockets for accessing shared contribution builds is anticipated. When
 explored properly, specific OT application recommendations should be added
 to the architecture.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130416/08fb3a55/attachment.html

openEHR Subversion = Github move progress

[Erik Sundvall]

Hi!

Apache as something called The Apache Attic for unmaintained old projects
in order to keep the code/assets somewhere, see
http://attic.apache.org/Perhaps we could simply have an openEHR attic
project at github where each
unmaintained previous project gets a sub-directory-tree.

Would creating an attic be an OK plan?

I am cross-posting this suggestion to the openehr-implementers mailing list
where we can continue the discussion and qualified members could cast a
formal vote as described on...
http://www.openehr.org/programs/software/governance
...and...
http://www.apache.org/foundation/voting.html

If no major objections or counter-proposals are seen within a week from
now I'll assume lazy consensus and create an Attic project.

I think an attic is where things like the liu_knowledge_tools could go
for example. Future web-policies at universities and other places are not
always guaranteed to maintain old URLs and content.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733



On Fri, Mar 22, 2013 at 12:13 AM, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:


 The last of what I think are the active Subversion repositories on the old
 openEHR.org server has been converted to GitHub now (the Archetype Editor).
 Repositories which appear to be inactive but could be converted if anyone
 wants:

- liu_knowledge_tools (Linkoping has a more recent version of this
AFAIK)
- the original 'knowledge' repository containing a lot of old NHS
archetypes
- knowledge_tools_java - not sure about this one.
- ref_impl_python

 For those who have links, checkouts or other pointers to any openEHR SVN
 repositories, please now refer to the Github openEHR 
 repositorieshttps://github.com/openEHR
 .

 Any questions like 'where did xxx go?', feel free to post them here.

 - thomas beale

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130325/288216b3/attachment.html

Nice GDL work! + Now let's not repeat 'Desperately seeking data'. Time to reduce technical debt in local archetyping?

[Erik Sundvall]

Hi!

Very nice work Rong et.al. - and wonderful to see a full open source
release of the tool so that it can be extended and experimented with by
others. Credit to you, your team and Cambio for releasing this!

Now let's hope that the community uses this wisely and avoids running into
the same decision support interoperability costs as arden syntax and MLMs
did [1] the last time there was a hype about interoperable decision rules.
GDL attempts to avoid similar problems by using archetyped data.

The potential for easy/low-cost sharing of decision support solutions based
on the GDL approach is dependent on the use of shared archetypes. I have
seen examples of local archetyping projects all over the world using the
global archetypes as inspiration but not understanding that it is in
their own long term interest to plan and fund contributions of their
extensions and improvements back to the global work. In my thesis I
described this as a form of technical debt, see details in [2] below.

This is not a critique of GDL, just a reminder of other important work that
the success of GDL and other archetype-based reusable solutions are likely
dependent on.

On Tue, Mar 12, 2013 at 1:37 PM, Rong Chen Rong.Chen at cambio.se wrote:

 Personally I am very fond of the idea to host GDL rules in CKM. CKM?s
 support of change management, distributed review, indexing and search,
 translation and release sets management (including archetypes/templates,
 rules and term refsets) will immediately benefit the development of rules.


Perhaps an openEHR GitHub repository dedicated to GDL rule sharing, divided
into suitable subdirectories, can be a fast and good start for rule sharing
to begin with while considering other potential solutions?

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733


*[1] Desperately seeking data - *Excerpt from page 13-14 of section 1.3.2
in http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-87702

*That the lack of semantic interoperability has an impact on reuse costs
was illustrated by Hripcsak et al [Hripcsak 93] that for good reasons
included the words ?Desperately seeking data? in their description of
problems when linking a knowledge-based system (KBS) to a clinical
database. The KBS provided alerts, interpretations, research screening, and
quality assurance functions. The system used Arden Syntax Medical Logic
Modules (MLMs) that were intended to make medical rules [...] reusable
between different EHR systems. The MLMs contained both reusable medical
knowledge-based logic rule sections and location specific data slot
sections used to find and access actual data in the local databases. *

*Defining and maintaining KBS-database links consumed a lot more resources
than the medical logic in the MLMs in terms of coding, maintenance, and
performance.*

*Experiences like ?Desperately seeking data? and others [Ahmadian 2011] make
it very interesting to also look at ways of standardizing the way data is
stored in addition to standardizing ?instructions? like MLM-based decision
support rules. *
*Similar issues arise repeatedly when trying to reuse data for other kinds
of decision making [Mawilmada 2012] and for computer instructions, for
example when creating summaries or drawing a graphical EHR overview on a
screen. *


*[2] Technical debt - *Excerpts from pages 80-83 of section 14.3 in
http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-87702

*The best documented origin of a definition of ?technical debt? comes from
Ward Cunningham [Cunningham 2009] that used the metaphor of debt to explain
to his boss that if the design team failed to continuously update the
design to become aligned with increased updated knowledge of the problem at
hand, than they were continually going to stumble over that disagreement.
That would slow the team down, which was like paying interest on a loan. *

*Cunningham argues that technical ?loans? in the form of rushed solutions
can be well motivated by business needs or by wanting to get initial
experience of the problem space. Loans let you ?do something sooner than
you might otherwise, but then until you pay back that money you'll be
paying interest? and if you keep borrowing and never repay by refactoring
and updating the design then ?eventually all your income goes to interest
and your purchasing power goes to zero?. He continues: ?By the same token,
if you develop a program for a long period of time by only adding features
and never reorganizing it to reflect your understanding of those features,
then eventually that program simply does not contain any understanding and
all efforts to work on it take longer and longer. In other words, the
interest is total -- you'll make zero progress?.*

*[...]*

*When deciding to connect semantically incoherent systems it will not
always be obvious to decision makers where (in which system) debt is built
up (in things like new import/export conversion boxes to create and
maintain). The debt

Regarding new CKM version webservice

[Erik Sundvall]

Hi!

Nice to see the CKM product and the openEHR installation of it being updated!

On Fri, Mar 8, 2013 at 10:00 AM, Sebastian Garde
sebastian.garde at oceaninformatics.com wrote:
 In Archetype Editor: Under Tools/Options set the URL for shared repository
 to http://openehr.org/ckm/services/ArchetypeFinderBean?wsdl

Just a thought:
Some time in a distant future when rethinking/refactoring archetype
handling beyond the CKM product it might be a good idea to exclude
specific company-bound product names (like CKM) and specific
implementation-bound techniques (like Bean) from openEHR
foundation-controlled URIs.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

Questions about commit and AUDIT_DETAILS

[Erik Sundvall]

Hi!


On Tue, Jan 29, 2013 at 9:48 PM, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:

 The point isn't for the server to know what is committed to itself, but
 for other systems to know where data that they are sent copies of, was
 originally committed.


That was my understanding too. I think of the system id as an identifying
logical domain for versioning where there is a guarantee that the same
version_tree_id (e.g. 3 in 1298745::my.system::3) will never be reused for
another commit. In such a domain there should be some mechanism to get the
latest version and to assign new non-conflicting version_tree_id's committs
in the domain thus has to be synchronized one way or another so that
additional writes with same ID get detected and stopped.

If those conditions are fulfilled it matters less if things are done on
client or server side, but I would guess that it in many cased will be far
easer to implement on the server side than to have a distributed sync for
clients.


 Maybe we need to contemplate capturing both the user device network id and
 the server id.


In the LiU EEE implementation of the REST architecture described in my
thesis (http://www.imt.liu.se/~erisu/2013/phd/) we use the normal
http-server log to record user agent (device and browser/agent) and
originating IP. The URIs and HTTP redirections are designed in a way that
makes it easy to identify the HTTP-log entry associated with a certain
commit, so if you have a VERSION of an object and have access to the
HTTP-logs you can easily track this for system audit purposes. Since the
dates are included in the audit_details of every openEHR VERSION it is also
easy to figure out which log file to look in if you happen to have an
ordinary log rotation and archiving system.

I am not sure that it would always be a too good idea to cram user-agent,
IP etc into the CONTRIBUTION or audit_details that are persisted in the EHR
and SOMETIMES transferred in EHR extracts. 1) Those details may give away
unwanted or unneccearily detailed info to other organisations that you are
sharing EHR extracts with. 2)

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130130/c5fecf9b/attachment.html

PhD thesis online: Scalability and Semantic Sustainability in Electronic Health Record Systems

[Erik Sundvall]

Hi!

My thesis entitled Scalability and Semantic Sustainability in Electronic
Health Record Systems is now available online. It contains many
openEHR-related papers and discussions (see abstract included below).

Permanent link to electronic version of the thesis:
http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-87702

Public PhD defence will be held the 15:th of February, in Link?ping,
Sweden. Faculty opponent: prof. Dipak Kalra, UCL.
Temporary event-information page: http://www.imt.liu.se/~erisu/2013/phd/
(That page also contains a form where you have the possibility to indicate
interest in online participation or in getting a recording.)

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

Abstract
This work is a small contribution to the greater goal of making software
systems used in healthcare more useful and sustainable. To come closer to
that goal, health record data will need to be more computable and easier to
exchange between systems.
Interoperability refers to getting systems to work together and semantics
concerns the study of meanings. If Semantic interoperability is achieved
then information entered in one information system is usable in other
systems and reusable for many purposes. Scalability refers to the extent to
which a system can gracefully grow by adding more resources. Sustainability
refers more to how to best use available limited resources. Both aspects
are important.

The main focus and aim of the thesis is to increase knowledge about how to
support scalability and semantic sustainability. It reports explorations of
how to apply aspects of the above to Electronic Health Record (EHR)
systems, associated infrastructure, data structures, terminology systems,
user interfaces and their mutual boundaries.

Using terminology systems is one way to improve computability and
comparability of data. Modern complex ontologies and terminology systems
can contain hundreds of thousands of concepts that can have many kinds of
relationships to multiple other concepts. This makes visualization
challenging. Many visualization approaches designed to show the local
neighbourhood of a single concept node do not scale well to larger sets of
nodes. The interactive TermViz approach described in this thesis, is
designed to aid users to navigate and comprehend the context of several
nodes simultaneously. Two applications are presented where TermViz aids
management of the boundary between EHR data structures and the terminology
system SNOMED CT.

The amount of available time from people skilled in health informatics is
limited. Adequate methods and tools are required to develop, maintain and
reuse health-IT solutions in a sustainable way. Multiple levels of
modelling including a fixed reference model and another layer of flexible
reusable ?archetypes? for domain specific data structures, is an approach
with that aim used in openEHR and the ISO 13606 standard. This approach,
including learning, implementing and managing it, is explored from
different angles in this thesis. An architecture applying Representational
State Transfer (REST) to archetype-based EHR systems, in order to address
scalability, is presented. Combined with archetyping this architecture also
aims at enabling a sustainable way of continuously evolving multi-vendor
EHR solutions. An experimental open source implementation of it, aimed for
learning and prototyping, is also presented.

Manually changing database structures used for storage every time new
versions of archetypes and associated data structures are needed is likely
not a sustainable activity. Thus storage systems that can handle change
with minimal manual interventions are desirable. Initial explorations of
performance and scalability in such systems are also reported.

Graphical user interfaces focused on EHR navigation, time-perspectives and
highlighting of EHR content are also presented ? illustrating what can be
done with computable health record data and the presented approaches.

Desirable aspects of semantic sustainability have been discussed,
including: sustainable use of limited resources (such as available time of
skilled people), and reduction of unnecessary risks. A semantic
sustainability perspective should be inspired and informed by research in
complex systems theory, and should also include striving to be highly aware
of when and where technical debt is being built up. Semantic sustainability
is a shared responsibility.

The combined results presented contribute to increasing knowledge about
ways to support scalability and semantic sustainability in the context of
electronic health record systems. Supporting tools, architectures and
approaches are additional contributions.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130127/c844652f/attachment.html

Questions about the XSD-files.

[Erik Sundvall]

Hi!

I see several use cases for sending and storing XML pieces smaller
than compositions etc as valid XML documents.

What about creating a separate (but official) file with those root
elements in the same namespace as the other schema components? That
way implementers can choose if they want that part or not.

Can you create a draft of such a file Bert and post it on the wiki or
mailing list?

Also, what is needed to turn the LinkEHR demographics XSD into an
official openEHR one? (Technically and process-wise...)

// Erik

P.s. Bert, I think you may have interpreted the tone of some
comments/replies as more hostile than they were intended by the
senders. It is sometimes hard to understand what you and others asking
for so it takes some rounds of questions to clarify that.

On Wed, Nov 28, 2012 at 9:29 AM, Bert Verhees bert.verhees at rosa.nl wrote:
 On 11/27/2012 10:42 PM, Seref Arikan wrote:
 When you do not have a root element definition in an XSD, you can't create
 XML documents which will be valid according to that XSD. What Bert is saying
 is, if we had a bunch of root elements in the XSDs, it would allow us create
 valid XML with these root elements.
[...]
 I just want root-elements for every concrete class which can be root in a
 XML-instantiation.
[...]
 It is maybe 10 lines added, and none changed or removed. If Heath wants to
 keep that items line, it is not in my way.
 And the lines I want added will be in no ones way. It is a recommendation to
 add these.

Understanding how to commit contributions to an EHR Server with XML

[Erik Sundvall]

On Mon, Oct 8, 2012 at 9:50 AM, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:

 to enable this, a small piece of extra XSD would be needed, to define a
 contribution as a single XML artefact. This doesn't currently exist,


Except as an experiment at:
http://www.openehr.org/wiki/download/attachments/786486/EEE-v1.xsd?version=1modificationDate=1349637658932
...as described in my mail 12 hours ago, did that mail reach the list?

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121008/65aee544/attachment.html

Understanding how to commit contributions to an EHR Server with XML

[Erik Sundvall]

Hi!

A CONTRIBUTION points to the IDs of it's contained VERSIONED_OBJECTs and
the VERSIONED_OBJECTs at the same time points to their
 related CONTRIBUTION, thus it is probably easiest to finalize them in the
same transaction in most systems if they are stored/retrieved as  separate
objects. (You have probably already figured that out, I am just trying to
avoid misunderstandings by newcomers that might be reading.)

In the LiU EEE REST based approach we have added a temporary writing space
called Contribution Builder where you can add/modify a collection
of VERSIONED_OBJECTs until you are satisfied and then make a call to get
them committed into the EHR in a combined CONTRIBUTION.

Another option is of course to send a collection of VERSIONED_OBJECTs (from
a client) with e.g. a bit of XML-wrapping (also including metadata for
the CONTRIBUTION). We have not finished specifying and testing an XML
serialization for that yet, but that could of course be done (now we use a
Java-based object as collection to pass data from the Contribution Builder).

I have now uploaded an old XSD (from some experiments 2010) containing
definition of CONTRIBUTIONs (and some other stuff) as an attachment to
http://www.openehr.org/wiki/display/dev/Persistence - It should be
considered as an experimental non-official pre-alpha version...

(The LiU EEE REST design paper has been submitted for review, see
http://www.openehr.org/wiki/display/projects/Projects+Home Contact me if
you need a personal login to our tiny demo-server.)

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733


On Sat, Oct 6, 2012 at 5:13 PM, pablo pazos pazospablo at hotmail.com wrote:

  Hi all,

 I found there is no CONTRIBUTION XSD defined on the openEHR XDS, and if it
 exists, I can't commit CONTRIBUTIONs using only one XML message, because
 CONTRIBUTION references (using OBJECT_REF) the VERSIONs I need to commit,
 but each VERSION also references (by OBJECT_REF) the container CONTRIBUTION.

 The main problem here is: the instances of those classes (CONTRIBUTION and
 VERSIONCOMPOSITION) are distributed objects. So if I send 2 messages to
 the EHR Server, one to create the CONTRIBUTION and other to create
 VERSIONs, the fisrt CONTRIBUTION.versions will be empty on the server, so
 invalid for a while (until it's VERSIONS are committed).

 So, I'm beginning to suspect that I need a little protocol to be defined
 here. The other option is to define my own XSD for an envelope that could
 include both, CONTRIBUTION and it's VERSIONs. I prefer to define a protocol
 than new custom XSDs.

 Does anyone that implemented a service like this came to the same
 conclusion?

 All your comments will be of great help, thank you.

 --
 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 http://twitter.com/ppazos

 --
 From: pazospablo at hotmail.com
 To: openehr-technical at lists.openehr.org
 Subject: Understanding how to commit contributions to an EHR Server with
 XML
 Date: Fri, 5 Oct 2012 15:14:15 -0300


  Hi all,

 I'm studying the change_control package to create a simple example of data
 commit to an EHR Server (to be used in a future course). I'm also reading
 the service examples published on the wiki (Ocean  Marand EHR Services).

 As I understand it, when an EMR app (local) wants to commit data to an EHR
 Server (global/shared), all committed data (e.g. a list of
 VersionCompositon) should be referenced by a Contribution. Also, each
 VersionComposition references the container Contribution. All references
 are managed using OBJECT_REF instances.

 My idea is to make the commits using XML messages (following openEHR XSDs)
 with only one message per commit.
 I don't know if I can represent both references using openEHR XML
 (Contribution-Version  Version-Contribution).

 I suppose this operation [1] on the Ocean's EHR Services is resolving
 both references internally: void CommitContribution(HierObjectId ehrId,
 AuditDetails commitAudit, OriginalVersion[] versions)

 Another assumption on that service, is the AuditDetails has the
 Attestation to sign all the committed Versions (the signature for all the
 Versions is calculated using the same AuditDetails object).

 I've seen Version XML examples where the Version has a reference to a
 Contribution, but the referenced Contribution is a mistery for me :) (it
 could be really helpful if someone can share an XML example of a
 Contribution).


 Any ideas, pointers  corrections are very welcome!

 (BTW: I don't want to implement a full version-controlled environment,
 just want to make a simple commit process the right way).


 [1]
 http://www.openehr.org/wiki/display/spec/Ocean+Informatics+EHR+Service+Interface

 --
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez

lessons from Intermountain Health, and starting work on openEHR 2.x

[Erik Sundvall]

Hi!

On Thu, Sep 13, 2012 at 11:15 AM, David Moner damoca at gmail.com wrote:

 2012/9/13 Erik Sundvall erik.sundvall at liu.se

 It would be great if e.g most of the future ISO 13606 version could be a
 true subset of openEHR instead of the current confusing situation.


 This is something I discussed with Thomas some time ago, it would be one
 of the best harmonisation solutions, but probably with a slightly different
 interpretation. Since 13606 has more generic classes (eg. the generic ENTRY
 can represent all of OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead
 of 13606 being a subset of openEHR I think that openEHR should be a
 specialized model of 13606.


I don't care if one is called a specialisation of the other, or a subset
the other way around :-) as long as it all works properly in software.

Would thoughts along the lines of
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+-+CIMI+version+1 work
for the ISO 13606 use cases you are thinking of? Or do you need something
like the yellow boxes in Candidate C at..
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model?focusedCommentId=37978115#openEHR2.xRMproposals-lowerinformationmodel-CandidateCsimplificationandclassrenamingforeasierexplanationandimplementation


The main issue is probably on which class the data attribute fits if we
want the openEHR entry types to specialize the 13606 entry class - in e.g.
OBSERVATIONS you may not want to use the same attribute name for another
datatype.

In Candidate C the CARE_ENTRY could share the same interface as ENTRY
but it is not a direct specialization of ENTRY in implementation languages
without multiple inheritance (like Java).

Another option would of course be to call the current data-field of
OBSERVATION something else than data and make a call for the data field on
an observation return some kind of summary/conversion adhering to 13606
structures (in a way inspired by the as_hierarchy in the DATA_STRUCTURE
class, see 3.2.1 in
http://www.openehr.org/releases/1.0.2/architecture/rm/data_structures_im.pdf
)


 Obviously this would require a deep analysis and changes of the models,
 but that could be the idea.


Yep, deeper analysis of the thoughts above would also be neccesary.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121007/3fb7a612/attachment.html

lessons from Intermountain Health, and starting work on openEHR 2.x

[Erik Sundvall]

Hi!

On 12/09/2012 17:43, Heath Frankel wrote:
 We need a depreciation scheme that allows us to say that something
 is no longer recommended for use in a particular release and removed
 in a subsequent release. This gives implementations time to migrate to
 the new recommendation. It also means we can get some experience
 with what the new recommendation is before we remove the deprecated
 approach.

Yes, what about using that approach (deprecation scheme etc) for a stable
or production grade series of versions - v 1.0.3, v 1.1 and so on...
...and at the same time start working on an experimental 2.x series.

This is how it is often done in big open source projects (with a lot bigger
user base than openEHR has). Critical systems, in production use, seldom
jump over to the new 2.x series while it is young, they wait for it to
mature. BUT they have been able to follow and comment on the 2.x
development all along the way so that they can be prepared without
constraining the options by insisting on full backwards compatibility. The
1.x branch could also slowly make changes to prepare for a simplified
future transition to 2.x including adding transformation tools.

If we want 13606, CIMI and openEHR modelling to merge somewhere in 2.x, the
we can not express too much protectionism from openEHRs side. (I think I
have heard people complaining about HL7 protectionism on these lists...)
Truly good changes (simplifications, increased archetyping flexibility etc)
should not be stopped by protectionism, but of course things should be well
tested in implementation before new specifications are finalized. It would
be great if e.g most of the future ISO 13606 version could be a true subset
of openEHR instead of the current confusing situation.

In the openEHR 1.x to 2.x case perhaps we will understand each other better
if we discuss concrete examples rather than expressing unspecified fears
from both sides, I'll start one below. Feel free to add other examples (a
concrete example of proposed data type changes for example).

When you look at
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model,
do
you then think that the discussed changes at e.g. ENTRY and ITEM_STRUCTURE
level will reduce bloat and misunderstandings, at the same time as it
increases flexibility and understanding? Would that be truly good for
openEHR archetyping and implementation?

Ian, an experienced archetype developer, has been asking for this
increased flexibility, see:
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model?focusedCommentId=32210974#comment-32210974.
(I think Sam also mentioned similar thoughts on the lists earlier.) I had
guessed that those proposed changes are big and breaking enough to go for
2.x rather than a soft deprecation 1.x series, what is the opinion of
those of you that have big systems running? Do they fit in a 1.x series
upgrade path?

I thought anything that breaks paths would likely be considered a big
change. (In the example above, the transition path including automated data
conversion is pretty clear though.) It is probably better to break these
paths in an experimental 2.x series now rather than waiting five+ years and
try to squeeze it in to 1.8 or something. :-)

 HL7 [...] look what happened when they offered a major upgrade. [...]
 The big issue was the effort for vendors to transition existing systems

I think that might be a somewhat unfair comparison:
1. The proposed openEHR 2.0 changes I have seen so far are not deviating
from the basic design principles and design patterns in openEHR. The basic
approach does _NOT_ change the same way as HL7 did between v2 and v3.
2. The number of vendors using openEHR now is _a lot_ smaller than the ones
that used HL7 v2
3. The number of vendors we want to join the openEHR approach in the future
is _a lot bigger_ than the ones that have existing openEHR-based production
systems.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120913/1a6a3d54/attachment.html

lessons from Intermountain Health, and starting work on openEHR 2.x

[Erik Sundvall]

Hi!

On Thu, Sep 6, 2012 at 12:47 AM, Sam Heard
sam.heard at oceaninformatics.com wrote:
 I will be pushing the backward compatibility angle very hard indeed - this
 can be a pain for those who want to progress.

Don't push too hard on backward compatibility without a clear
definition of what you mean by it and what you want to apply it to. A
fresh re-start (based on implementation experience by openEHR, 13606,
other CIMI actors etc) can make future systems a lot better than if
they have to be constrained by the wrong kind of backward
compatibility philosophy (e.g. add but never remove-bloatware). :-)

The openEHR RM includes an attribute with RM version in stored
records, so in one way a storage system can be lifelong and
backwards-preserving even if the RM changes, but queries etc will need
to be rewritten to fit several model versions if you have a mix.

What you could focus on is the _understand_ any issues for current
systems, of course, but make sure that understand does not mean
_constrain_ the future options for change and simplification.
Demanding a list of this old construct could be converted to this new
construct this way and this construct is _not_ algorithmically
convertible is constructive and educating. But forbidding breaking
changes is not constructive, so I hope (and think) that is not what
you meant.

Going from 1.x to 2.x in software usually _does_ include many breaking
changes. If an non-breaking update/refresh is also needed, then a
1.0.3 or 1.4 version of the openEHR specifications could be produced
in parallel - but don't put the wrong constraints on 2.0!

 I personally guarantee there
 will be no official publication of openEHR 2.0 or ADL 1.5 until we
 absolutely understand any issues for current systems.

Can a chairman really personally guarantee any decisions in a
democratic organization? If you are the CEO or owner of a commercial
company you may have some veto rights in that company, but in the
kinds of democratic organisations I am used to, the chairman does not
have a veto right. What kind of organisation do you want openEHR to
be?

 This does not spring
 from a technical concern - rather our community's commitment to life long
 health records. These are after all the asset of the most value in the
 health care enterprise. There are now 60,000 people with openEHR records in
 one Australian repository, some with as many as 2000 compositions.

That system won't break just because new specifications are published.
System upgrades are not mandatory and do not have to be rushed.

If breaking specification changes are not allowed now when there are
relatively few records, archetypes and implementations, how would it
sound later when there are many more archetypes, implementations and
millions of records? Would breaking changes ever be allowed? Better to
break things early than late, if necessary, when aiming for somewhat
global adoption...

Resisting change favors old implementors with existing systems, but
simplifying/strengthening models and thus future implementation (and
maintenance), makes life easier for new actors wanting to enter the
openEHR scene. So there is probably no neutral ground ;-)

What an interesting dilemma to deal with :-)

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733



 On 5/09/2012 10:49 AM, Thomas Beale wrote:
 for those interested, I have been spending this month with Dr Stan Huff's
 group at Intermountain Health in Salt lake City. I have at least a dozen
 potential change requests / issues for openEHR. Mostly small, but important
 in their way. That has come from the evidence of their systems, and our
 performing a cross-review during this month. The comparison has shown that
 we (i.e. openEHR and Intermountain) have essentially the same multi-level
 modelling system, with different details. Plus I have learned a lot in terms
 of their design philosophy and thinking.

 Essentially we can think of these as distilled wisdom/lessons from various
 incarnations of Stan's leading edge 3M/ASN.1 environment over 15 years, up
 to the most recent, the Qualibria system using 'CDL' (the ADL equivalent).

 I'll put these into the openEHR Jira SPEC-PR issue tracker for everyone to
 see over the next couple of weeks, plus on the mailing lists for more
 general things I have learned here.

 The new openEHR Spec programme should get up and running in the next few
 weeks, which will mean that people here who want to nominate for working on
 the various specs (i.e. working toward openEHR v2.0) should have a think
 about doing that. The governance details are mostly worked out, so it just
 needs people.

 I know some people feel that the specs have not been changing for too long
 (myself included) but on the other hand, they have stood up amazingly well
 over the last few years, and we have a huge amount of industry knowledge
 accumulated, most of which I think is captured on the PR issue tracker, and
 at least

Github repositories for openEHR

[Erik Sundvall]

Hi!

There is now a little sandbox project in openEHRs Github space that
you can fork and then play around with in order to learn collaboration
and versioning via Github at https://github.com/openEHR/Sandbox Please
have a look and test.

Later there will likely be other more serious sub-projects under the
https://github.com/openEHR/ umbrella, e.g. various software projects,
specification source files and perhaps source files for parts of the
openehr web and experimantal knowledge repositories.

Several openEHR-related projects already use github or are in the
process of moving there, some are seen by searching
https://github.com/search?q=openehr

Regarding software we'll have mail discussion on the implementers list
(openehr-implementers at openehr.org) regarding criteria (licenses,
sustainability etc) for moving projects from private repositories to
the openEHR space, so please join that mailing list if you are
interested in contributing to the discussion. Whatever criteria we end
up with will then be discussed with the openEHR board.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

SMART platform and RDF

[Erik Sundvall]

Hi!

Interesting work, and nice to see many OWL/archetype-experts working
together!

Are you planning to design any transformations of AQL-queries to SPARQL
that matches your instance data format? (If so, we have a REST-based
framework with a dedicated spot to put that translator in.)

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733


On Tue, Jul 3, 2012 at 12:59 PM, Kathrin Dentler k.dentler at vu.nl wrote:

 Dear all,

 Here in Amsterdam we are working on expressing archetypes as OWL graphs,
 and actually I think that it would be ideal to host them under the openEHR
 domain in future.

 We transform archetypes from ADL to OWL, with the work of Catalina Costa
 from Medical University of Graz (previously in Universidad de Murcia) and
 Leonardo Lezcano from the Universidad de Alcal? as a starting point. Please
 consult our paper [1] that has been accepted for the KR4HC workshop for
 details. It is not yet camera ready, but it gives an overview of some
 advantages of representing archetypes in OWL.

 Currently Alberto Maldonado from IBIME, Technical University of Valencia,
 is doing a research visit in our group. He is working on generating OWL
 data (individuals) that are compliant with the OWL representation of
 archetypes from both legacy XML data and archetype compliant XML EHR
 extracts. The idea is to have normalized clinical data expressed in OWL in
 order to ease its reuse in clinical research (mainly clinical trials) and
 quality measurement.

 Best regards,
 Kathrin Dentler

 [1] 
 http://www.few.vu.nl/~kdr250/**prohealth12kr4hc_archetypes_**owl.pdfhttp://www.few.vu.nl/~kdr250/prohealth12kr4hc_archetypes_owl.pdf



 Op 03-07-12 10:19, Ian McNicoll schreef:

  There is quite a bit of interest in the UK in adapting the US-based
 SMART platform www.smartplatforms.org for UK use. One aspect of SMART
 involves the definition of a fairly simple API which serves RDF graphs
 of archetype like objects e.g Blood pressure, allergy. The SMART guys
 are aware of openEHR and have been quite support of it in the CIMI
 work, and I understand that they do not see the clinical content
 definitions underpinning the APIs as core business.

 It seems to me that there is an interesting possibility of using
 openEHR archetypes (probably templated) to define the clinical content
 which is to be expressed as RDF graphs. This will give a much more
 adaptable and extensible approach + better model governance etc.

 It seems to me that the key requirement is to be able to create a
 run-time artefact, in the same way that we create Template data schema
 but to output RDF rather than XSD. Is this correct and if so, does
 anyone have any experience with this?

 The other interesting aspect is that because the SMART API returns
 mostly ENTRY-level components, these need to be wrapped in some
 COMPOSITION level metadata. Does it make sense that we actually return
 very lean EHR Extracts?

 Ian



 --

 Kathrin Dentler

 AI Department |   Department of Medical Informatics
 Faculty of Sciences   |   Academic Medical Center
 Vrije Universiteit|   Universiteit van Amsterdam
 k.dentler at vu.nl   |   k.dentler at amc.uva.nl

 http://www.few.vu.nl/~kdr250/



 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://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/20120705/aa7da333/attachment.html

How about creating an openEHR test base?

[Erik Sundvall]

Hi!

I agree that we need some RM instances etc initially. We have
versioned compositions in the demo server for our LiU EEE-system. We
don't know if they are 100% according to spec since they have not been
extensively tested. I'll upload some of them to the wikipage after a
deadline I have this week (remind me if they are not there next monday
;-)  I can give a limited number of people access to them now via
REST-interfaces (HTTP via a browser works fine).  Mail me off-list if
you are in a hurry.

Would EHR-data reflecting a number realistic patient stories be
interesting to collaborate on as a second step? I am in desperate need
of such EHR data in order to create and test EHR-visualisations.
Getting real patient data is a pain to get access to and if we get
it we can never share it. Could we share the effort of creating a
number of such EHR instances (and perhaps write a shared academic
paper about it) - If so let's first check/discuss some of the options
for data entry and once that is fixed we can involve more clinicians
to create and improve/review the stories. A shared set could be reused
in several projects and make them more comparable too.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733


On Mon, May 7, 2012 at 12:48 AM, pablo pazos pazospablo at hotmail.com wrote:
 Hi Diego  Peter,

 What Diego said about evolving tests for ADL1.5 is true, we don't want to
 test the tools or the specs, we want to test our implementations (EHRs,
 services, repositories, etc).

 I agree this overlaps in some way with the CKM content (archetypes and
 templates), but our focus is on flat archetypes and operative templates,
 things that will be used by systems, not on source ADL archetypes with
 slots, abstract types and other things that makes implementation a pain in
 the 4$$... you know waht I mean.

 I agree what Diego said in the last message: we want RM instances (XML) in
 the repo, which will be valid against XSDs (that we need to test and fix,
 XSDs will be included in the repo too). JSON instances will be welcome too
 :D

 To give more context, this is taken from a private message to Erik:

 What I have in mind is to create something like a unit test for openEHR
 applications and services, with archetypes, rm instances and term sets. E.g.
 having a test set with some archetypes, a template, some term sets and a
 couple of instances in xml and json formats, and create some small software
 that can handle those test sets, validating instances to schemas, validating
 structures to archetypes, etc. and maybe geting data from the instances and
 doing something with it, 


 --
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos

 From: yampeku at gmail.com
 Date: Mon, 7 May 2012 00:23:44 +0200

 Subject: Re: How about creating an openEHR test base?
 To: openehr-technical at lists.openehr.org


 Pablo also mentioned 'RM instances in a variety of formats', which are
 not 'artefacts'.

 2012/5/7 Peter Gummer peter.gummer at oceaninformatics.com:
  Diego Bosc? wrote:
 
  I would say the scope of that repository is different, as that is part
  of the test for current evolving 1.5 syntax and does not include
  'real' archetypes
 
  My understanding was that Pablo was not proposing real archetypes
  either. In his original post, Pablo proposed a test base with sample
  artifacts.
 
  How would this be different from the purpose of the existing
  http://www.openehr.org/svn/knowledge2 repository? The only difference that 
  I
  can see is that Pablo has proposed adding a greater variety of artefacts
  (OPTs, etc.), so it seems natural to add them to the existing repository.
 
  - Peter

 ___
 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?

[Erik Sundvall]

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).

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733


 We have already discussed last week with Rong  Sebastian about moving the
 openEHR terminology there, and how to manage it more effectively, so the
 scope of this knowledge repository is going to continue to grow anyway. So
 any community input on how to expand this repository? and manage it is
 welcome from my point of view (I realise the above might only be a subset of
 your original scope Pablo, so there are probably some things that still need
 to be done elsewhere.)

13606 revisited - list proposal

[Erik Sundvall]

Hi!

When looking for the summary attribute (an ITEM_STRUCTURE) I found
that it was missing some of my diagram printouts.

It is clearly defined on page 31 of...
http://www.openehr.org/releases/1.0.2/architecture/rm/data_structures_im.pdf
... but missing in the diagram (figure 8) on page 25 ind that document
and missing on all relevant diagrams (including mine) on
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model

That can definitely be confusing. Or have I missed something else?

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733


On Tue, Mar 27, 2012 at 10:12, Ian McNicoll
Ian.McNicoll at oceaninformatics.com wrote:
 I am struggling a little to understand your concern about the Summary
 attribute (other than that is is not supported in the tools!). ?The current
 definition? ?optional summary data expressing e.g. text
 or image which summarises entire history.??seems to me to meet your needs
 perfectly. I am obviously misunderstanding your requirement or we have
 different interpretations of the definition. How would you like to broaden
 the definition?

13606 revisited - list proposal

[Erik Sundvall]

Thanks!

On Tue, Mar 27, 2012 at 12:53, Erik Sundvall erik.sundvall at liu.se wrote:
 When looking for the summary attribute (an ITEM_STRUCTURE) I found
 that it was missing some of my diagram printouts.
...
On Tue, Mar 27, 2012 at 16:54, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:

 this one?


Yes that one. Thanks.

On Tue, Mar 27, 2012 at 12:53, Erik Sundvall erik.sundvall at liu.se wrote:
 That can definitely be confusing. Or have I missed something else?

I had obviously missed something when only looking inside the boxes ;-)
Nice to have a partial blindness cured over the Internet without too much
pain ;-)

// Erik
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/eff733fc/attachment.html

openEHR - Persistence of Data

[Erik Sundvall]

Hi!

On Thu, Feb 16, 2012 at 23:26, pablo pazos pazospablo at hotmail.com wrote:
 Other models I didn't try yet are Object Oriented DBs and
 Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs
 are a good option, fast for store highly hierarchical structures,
 but you need to write some ugly queries if you want your data back :D

Not necessarily that ugly... we curently auto-convert AQL to XQuery
and execute towards an XML database. Those queries are very readable.

Then the question is what kind of client system you are aiming at. For
some use cases you don't really need to map things back to
openEHR-RM-objects, in web browser based GUIs for example you can keep
treating the data as documents, document fragments, fragment lists
etc. and use DOM manipulations, jQuery or similar approaches for most
data manipulation needs.

Good luck with your work M?rcio and please keep us informed!

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

Python / Django experience??

[Erik Sundvall]

 yes, but using available components is always a
help.


 I hope others can convince otherwise, but this is how I feel right now.


I am trying. :-)

Lets hope we get more input from many others before rushing into
implementation. My belief is that the global future change-tracking and
merging problem needs to be considered at an early stage, but I am sure
that I don't see the whole picture or all problems  myself yet, so let's
think together.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120208/bd8b23e8/attachment.html

Python / Django experience??

[Erik Sundvall]

Hi!

On Thu, Feb 2, 2012 at 18:19, pablo pazos pazospablo at hotmail.com wrote:
 I don't know if this is crazy talk or if it's seems reasonable to you. Please 
 let me know :D

Not crazy, but maybe overly complicated.

Perhaps it would be a good idea to use a layered approach?
1. An existing distributed version control system (DVCS) like GIT (and
an agreed directory structure and naming conventions within it) for
storing versioning and distributing archetype source files etc.
2. A set of tools (that can also be run in batch mode or by commit
hooks in the DVCS) that can validate and convert sources to
alternative formats and create html pages (and other formats) for
listing and browsing the resulting assets
3. A search function (maybe also using existing online search
services) that can be used by both humans and machines (via an API)
4. Clinician-friendly GUIs with CKM-like functions that
hides/incorporates layers 1,2, and 3 to end users that want CKM.

#1 is available already including free hosting possibilities (but
without provider-lock in since the whole version history is
replicated)

#2 I think e.g. Seref, Tom and others have come very far with already

The output from #1  #2 could be served as static files on any
webserver and thus make it easy for any organization to set up. No API
more than normal HTTP will be needed for read operations, for write
operations the API of the DVCS will likely be enough.

#3 should be considered carefully before putting too much resources
into new development. If processes in step #2 can create good enough
labeling/tagging/ontology-linking to resources or meta-resources (like
auto-generated descriptive web pages) then both existing online search
engines and locally run ones could just pick that up using standard
mechanisms

#4 will need more work, I don't know if any parts of the CKM can be
useful and open sourced to help such an effort. It would be nice if
the discussions relating to an artifact (e.g. an archetype) could be
stored and versioned in the same backend system as the artifact
itself, there are GIT/DVCS-based wikis that might do part of the job.

The key benefit of a DVCS based approach is the distributed nature
that allows creative initiatives without asking for centralized
permission. It allows easy (auditable) cross-pollination of ideas and
code/archetypes between developers or regional developer organisations
in a way that is a lot harder with centralized approaches like
Subversion, the current CKM etc. It's hard to describe, but techies
can have a look at some active projects at Github to get a feel for
it.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733



On Thu, Feb 2, 2012 at 18:19, pablo pazos pazospablo at hotmail.com wrote:
 Hi all,

 What I've been thinking is to share the same interface/protocol to do simple
 tasks on distributed CKMs like:

 Adding an artifact (archetype, template, termset, terminology service,
 process definition, gui template, etc.), lets think only about archetypes
 for now.
 Updating an archetype (with version management)
 Listing all the archetypes
 Listing all the archetypes for one RM type (i.e. composition, entry, action,
 etc.)
 Listing all the archetypes that archetype_id match a regexp
 Listing all the archetypes that match some text (free text search)
 Retrieve archetype in ADL/XML/JSON/YAML by archetype_id



 Ian, about the requirements you mention:

 Basic requirements

 1. Query across multiple repositories using multiple criteria, based
 on something similar to the CKM ontology.

 For this I think something like DNS protocol will do the job
 (http://en.wikipedia.org/wiki/Domain_Name_System). DNS could do a
 distributed search by redirecting the query if some server doesn't have the
 answer. So, if we have a service to register artifacts on CKM servers
 (service 1. on the list above), with an artifact registered notification
 protocol, and another protocol for CKM server discovery, we could
 implement the distributed search.

 2. Establish references to remote assets, almost certainly caching the
 referenced asset locally

 This would be the a mix of adding and artifact and artifact registered
 notification protocol.

 3. Establish subscriptions to remote assets, to enable change notification
 etc

 And this would be included in the CKM server discovery protocol, that
 could defined like some services provided by the NDP protocol, using
 messages like RA, NS, NA, ... to discover CKM servers to create a CKM
 network over Internet:
 http://fengnet.com/book/CCIE%20Professional%20Development%20Routing%20TCPIP%20Volume%20I/ch02lev1sec5.html
 I think some of these services could be found also in the ICMP
 protocol:?http://www.networksorcery.com/enp/protocol/icmp.htm


 Just to clarify my thoughts, I don't think we need a network protocol!!! I
 think we could create our protocols to handle artifacts in a distributed way
 reusing some ideas from those proven

Python / Django experience??

[Erik Sundvall]

Hi!

On Wed, Jan 11, 2012 at 12:10, Ian McNicoll 
Ian.McNicoll at oceaninformatics.com wrote:

 1. Add some sort of persistence/ repository back-end for archetypes
 and associated documentation e.g Github and/ or Dropbox. There is a
 very nice Python API for the latter which I got working. This does not
 need to be be particularly complex. Github would probably be a better
 solution but the limited versioning afforded by Dropbox is probably
 sufficient.


One of the most interesting things about GIT-like systems is their
distributed/decentralized nature where there is not necessarily a single
main master repository. (This category of versioning systems are often
called DVCS, see
http://en.wikipedia.org/wiki/Distributed_Version_Control_System, GIT is
just an example from that category
Mercurialhttp://en.wikipedia.org/wiki/Mercurialis another example.)
Instead of centralization there is very good support
for merging multiple branches/forks/origins. I think this mode of operation
will suit future archetype development where we might expect considerable
activity in many regional archetyping centres and then multi-source merges
and good multi-branch change tracking will be useful.

The git command-line interface itself would be quite a horrible experience
to most archetype authors though so the DVCS needs to be wrapped in
something better (CKM-like) for end users. Something like GIT (or
Mercurial) itself might work well as a service layer for communication
between regional archetyping repositories though, we probably won't need to
add much there except some sensible rules for directory structures, file
naming etc. Communication protocols etc for GIT are already defined - exposing
the repository via a regular
webserverhttp://book.git-scm.com/4_setting_up_a_public_repository.html
directory
is one option. Every regional site will via GIT or Mercurial automatically
get a complete history of any other repository it wishes to mirror.

But don't let this stop Dropbox plans if that works better now, I just
wanted the above to be visible on the future-sensing radar for tech-list
subscribers.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120201/640d64f4/attachment.html

pass_through and implementation directives in general

[Erik Sundvall]

Hi!

Ok, if implementation experience says it is better to have separate
sections for human readable annotations and machine-targeted program
directives then I guess that is a good approach. Are there any tools that
support this now?

If going for an RDF-like URI based approach for program directives or
implementation_directives then those serialization formats that aim for
human readability (e.g. ADL and YAML) may want to use some kind of
URI-prefixing-mechanism to make the directives shorter and more readable.
(Similar approaches are used in XML (namespaces) and many
RDF serialization formats.)

I assume program directives will include both pass_through and more
purely GUI-oriented directives. Will they contain everything
annotation/directive-like that is intended to be machine processable and
human language independent? Is that a correct and shared view of the
purpose?

Are both annotations and program directives supposed to be attributes
of the class AUTHORED_RESOURCE? I don't find them in the current
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/common_im.pdfbut
I guess that might be a matter of time constraints - or are they going
to be only a part of AOM/ADL itself? I just want to check what the future
thoughts are.

Is program directives the best name? Annotations is very a very generic
and useful name, but that word is already taken for the human readable
stuff. Could anything from the following list inspire somebody with a more
native feel for English to come up with alternate name suggestions?
- directives (shorter and more general than program directives).
- instructions
- notes
- meta...something
- commands
- processing...
- triples
- links
- extensions
- ...

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733


On Tue, Jan 31, 2012 at 00:07, Heath Frankel 
heath.frankel at oceaninformatics.com wrote:

 Hi Erik,
 No problem with your RDF approach but I agree with Thomas that the purpuse
 of view directives. (or more generally,  program directives) is very
 different from annotations. XML Schema separates these two concepts.
 Ocean has reused annotations in the template designer for these kind of
 directives for some time as well as the hard coded hide-on-form, and it is
 from this experience that we have proposed this separate section.
 Heath
 On 31/01/2012 8:12 AM, Erik Sundvall erik.sundvall at liu.se wrote:

 Please rewind to
 http://www.openehr.org/mailarchives/openehr-technical/msg05530.html and
 the followup messages in that thread.

 Using an RDF like URI-based approach still seems to be an option. No
 registering hassle or new sections in adl, just alternate use of the
 existing annotation section.

 // Erik
  Den 30 jan 2012 14:31 skrev Thomas Beale 
 thomas.beale at oceaninformatics.com:

  On 30/01/2012 03:16, Heath Frankel wrote:

  Hi Pablo,

 ** **

 If I understand correctly, the pass_through attribute is only for data
 displaying on a screen (as you mention the use for data grouping or
 collapsing). If that's right, I don't think that should be part of the
 generic template structure, because templates are meant to represent other
 elements than data views/GUI, like messages, reports, etc.

 ** **

 No, that is not what I are saying.  I are saying it can be used for more
 than display purposes such as data views, messages, reports etc.

 ** **

 As you mention  screen layout and binding are consistent with the XML
 schema or class it will bind to I feel maybe this is a little attached
 to Oceans implementation, e.g. in our implementaition we don't have binding
 with XML Schemas .

 ** **

 Ocean doesn?t bind to XML schema either, I used this as an example of
 why you may want to ensure your presentation view is consistent with a data
 view derived from the same template artefact.

 ** **

 The use of the annotation-like structure for view directives allows us
 to separate these kind of directives from true annotations and the data
 definition itself whilst providing flexibility for specifying a set of
 directives that we know of now but may improve on later such as
 pass_through, add to in the future, and also use in local environments.  We
 need to remember that templates where inteded for local use cases but are
 now also becoming important at jurisdictional levels for shared use.


 Heath,

 the options for passthrough today (ADL/AOM 1.5) seem to be the following:

- leave it where it is today, specified on C_COMPLEX_OBJECT
- move it to be an annotation within the new annotations section of
ADL 1.5 archetypes, with a key such as 'view_directive'
- create an entirely new section, structured the same (?) as the
annotations section, within the archetype for view / other directives

 The potential problems with including a new view-directives section
 within archetypes include:

- it makes the archetype dependent on those directives. They would
need

pass_through and implementation directives in general

[Erik Sundvall]

Please rewind to
http://www.openehr.org/mailarchives/openehr-technical/msg05530.html and the
followup messages in that thread.

Using an RDF like URI-based approach still seems to be an option. No
registering hassle or new sections in adl, just alternate use of the
existing annotation section.

// Erik
 Den 30 jan 2012 14:31 skrev Thomas Beale 
thomas.beale at oceaninformatics.com:

  On 30/01/2012 03:16, Heath Frankel wrote:

  Hi Pablo,

 ** **

 If I understand correctly, the pass_through attribute is only for data
 displaying on a screen (as you mention the use for data grouping or
 collapsing). If that's right, I don't think that should be part of the
 generic template structure, because templates are meant to represent other
 elements than data views/GUI, like messages, reports, etc.

 ** **

 No, that is not what I are saying.  I are saying it can be used for more
 than display purposes such as data views, messages, reports etc.

 ** **

 As you mention  screen layout and binding are consistent with the XML
 schema or class it will bind to I feel maybe this is a little attached
 to Oceans implementation, e.g. in our implementaition we don't have binding
 with XML Schemas .

 ** **

 Ocean doesn?t bind to XML schema either, I used this as an example of why
 you may want to ensure your presentation view is consistent with a data
 view derived from the same template artefact.

 ** **

 The use of the annotation-like structure for view directives allows us to
 separate these kind of directives from true annotations and the data
 definition itself whilst providing flexibility for specifying a set of
 directives that we know of now but may improve on later such as
 pass_through, add to in the future, and also use in local environments.  We
 need to remember that templates where inteded for local use cases but are
 now also becoming important at jurisdictional levels for shared use.


 Heath,

 the options for passthrough today (ADL/AOM 1.5) seem to be the following:

- leave it where it is today, specified on C_COMPLEX_OBJECT
- move it to be an annotation within the new annotations section of
ADL 1.5 archetypes, with a key such as 'view_directive'
- create an entirely new section, structured the same (?) as the
annotations section, within the archetype for view / other directives

 The potential problems with including a new view-directives section within
 archetypes include:

- it makes the archetype dependent on those directives. They would
need to be limited to universal directives, because most UI/presentation,
as well as other implementation directives are locally specific, and there
can clearly be more than one, for a given archetype.
- we don't yet know what structure such a directives section should
really take

 Potential benefits:

- the section can be specified within the AOM  ADL docs, i.e. no new
specs required
 - making a new section in archetypes  templates means that we don't
need any new tools to process these directives - the main archetype
compiler would do it
 - we could make it so that *applying more local directives was done
by defining correct inheritance rules for the implementation-directives
section* - i.e. use inheritance

 As I think about this, I am starting to be persuaded that continuing to
 use inheritance to achieve local additions and overrides is a good thing -
 it works for the rest of the archetype. If we commit to this path, the
 remaining question is: is the current annotations section structure
 sophisticated enough to contain implementation directives? An example of
 the annotations section from a current test archetype is as follows:

 annotations
 items = 
 [en] = 
 items = 
 [/data[at0001]/items[at0.8]] = 
 items = 
 [design note] = this is a design note on
 allergic reaction
 [requirements note] = this is a requirements
 note on allergic reaction
 [medline ref] = this is a medline ref on
 allergic reaction
 
 
 [/data[at0001]/items[at0.10]] = 
 items = 
 [design note] = this is a design note on
 intelerance
 [requirements note] = this is a requirements
 note on intolerance
 [national data dictionary] = NDD ref for
 intolerance
 
 
 [/data[at0001]/items[at0002]] = 
 items = 
 [design note] = this is a SPECIALISED design
 note on Statement
 [NEW TAG] = this is a SPECIALISED design note
 on Statement
 
 
 
 
 

 So let's imagine that a new section could be of a similar structure. The
 first thing to note is that it is 

Did anybody implement AQL with a LL parser framework?

[Erik Sundvall]

Hi!

We implemented an AQL parser using JavaCC. My colleague Mikael Nystr?m made
some transformations to make the published AQL grammar work in JavaCC.
Mikael is on vacation right now, but I'm sure he does not mind sharing his
experiences once he gets back.

I do think it would be interesting to switch to ANTLR sooner or later in
order to share efforts between projects with different
implementation/target-languages and because the ANTLRWorks environment
http://www.antlr.org/works/index.html looks promising compared to the
pretty bad JavaCC-plugin in e.g. Eclipse.

Our parser (and thus also the modified grammar) will soon be open sourced
so you are free to use it. So if you are not in an extreme hurry I'd
suggest using or getting inspiration from what we have already done.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733


On Wed, Jan 4, 2012 at 16:37, Seref Arikan 
serefarikan at kurumsalteknoloji.com wrote:

 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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120105/65a8a13f/attachment.html

13606 revisited - list proposal

[Erik Sundvall]

Hi!

Could we discuss some openEHR+13606 2.0 ideas also using UML-ish diagrams
via e.g. http://yuml.me/ if it helps in some cases? (Don't worry it has
nothing to do with YAML despite the name...)

I'll try to provoke some thoughts by inserting a start diagram as a png in
the message now...

...but if it fails to get through the mailservers you also have it at
http://yuml.me/386f608e
The yellow stuff is what I guess could be in a 13606-1(a?) healthcare
a-specific update and the rest in a new 13606-6 or 13606-1b
healthcare-specific part.

I have likely missed some details (and did not have time to add datatypes
to all attributes, but they are in the openEHR specs).

The online editable sourcecode is attached by the end of this mail and
also versioned at
http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model.
It can be edited there to add or change things in order to describe
alternative approachess, and then pasted to
http://yuml.me/diagram/scruffy/class/draw2 . So dig in and hack on... :-)

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

Diagram source code used at http://yuml.me/diagram/scruffy/class/draw2:

[note: No change suggestions in ACTION and INSTRUCTION except that
ITEM_STRUCTURE type is replaced by ITEM]
[CONTENT_ITEM{bg:yellow}]]^[SECTION|0..* items: List
CONTENT_ITEM{bg:yellow}]
[CONTENT_ITEM]^[ENTRY|data: ITEM{bg:yellow}]]
[CONTENT_ITEM]^[ABSTRACT_CARE_ENTRY|0..1 protocol: ITEM;0..1 guideline_id:
OBJECT_REF;0..1 workflow_id: OBJECT_REF;language: CODE_PHRASE;encoding:
CODE_PHRASE;subject: PARTY_PROXY;0..1 provider: PARTY_PROXY;0..1
other_participations: List PARTICIPATION; ]
[ABSTRACT_CARE_ENTRY]^[CARE_ENTRY|data: ITEM]
[CARE_ENTRY]-[note:CARE_ENTRY Replaces both ADMIN_ENTRY and EVALUATION.]
[ABSTRACT_CARE_ENTRY]^[OBSERVATION|data: EVENTS;0..1 state: EVENTS]
[ABSTRACT_CARE_ENTRY]^[INSTRUCTION]
[ABSTRACT_CARE_ENTRY]^[ACTION]
[ENTRY]-[note:ENTRY replaces GENERIC_ENTRY and is intended also for
'healthcare a-specific' stuff as indicated useful by 13606 experiences]
[EVENTS|origin;0..1 period;0..1 duration]++-events[EVENT|time;0..1 state:
ITEM; data: ITEM]]
[EVENTS]-[note: HISTORY renamed to EVENTS]
[EVENT]^[INTERVAL_EVENT|width;0..1 sample_count;math_function]
[ITEM{bg:yellow}]^[ELEMENT|0..1 null_flavor;0..1 value
DATA_VALUE{bg:yellow}]
[ITEM]^[CLUSTER|1..* items: ITEM;0..1 structure: CODE_PHRASE{bg:yellow}]
[CLUSTER]-[note: 'structure' indicates if the cluster is to be validated
and interpereted as e.g. a table or list - defaulting to tree if not
provided]
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111219/066471db/attachment.html

13606 revisited - list proposal

[Erik Sundvall]

Hi!

On Fri, Dec 16, 2011 at 09:32, David Moner damoca at gmail.com wrote:
 In any case, this generic design is a result of the current scope of 13606:
 EHR exchange and not a complete EHR implementation specification.

Thanks for reminding me.

I tend to forget that the 13606 purpose never was to make internal
system semantics interoperable. It's easy to forget the intentional
13606 focus when usually thinking of mappings and interoperability
issues based on examples like the ones on slides 12 and 13 of...
http://www.imt.liu.se/~erisu/2011/openEHR-TBMI19-lecture.pdf

As you know, if you want to truly bi-directionally share things for
which it is impossible to define deterministic conversion
algorithms/programs (thus maintaining patient safety in automated
conversions), then just defining a standard message- or extract format
will be a lost cause (no matter how determined politicians are and no
matter how much you pay IT-consultants to try to do the job). Instead
the semantics of the end point systems will need to be aligned sooner
or later.

Anyway it wouldn't hurt if a new or refreshed internationally
recognized standard could be used by those vendors and system owners
that actually _want_ to agree on the internal clinical semantics of
efficiently implementable systems all the way down to some of the
technical (e.g. openEHR inspired) details. I think there is now a
market for such a standard (or new standard part) helping those that
have given up beliefs in mapping of incompatible semantics.

 From our
 experience, interoperability between legacy systems (standard-based or not)
 is much easier using a generic model for exchange. The harsh truth is that
 the quality of the data and the design of information structures in existing
 EHR systems is quite bad or unclear, thus making really complicated the
 process of automatically transforming it to a very specific reference model.
 This is not the case when we use 13606.

I suspect this is an intentional difference between current 13606 and
openEHR; to faithfully capture the current (incompatible) situation
versus aiming to change the current situation.  Can those different
goals really meet in one RM or do we need two standardized RMs?
http://dilbert.com/strips/comic/2011-08-02/

A side-track question: Do you feel that the archetyped approach with
13606 really helps in the current mappings/transformations that you
work with more than what just using e.g. RDF+OWL would help? Or does
the archetype stuff and RM mostly complicate things?

 A different thing is if 13606 scope changes during the revision. In that
 case, I agree that reducing layers of modelling by introducing specific
 classes will make the systems more efficient.

Is there an opening for scope-change or not within the formal
13606-revision or would one need to start a completely new standard in
order to define a standard for aligning internal EHR system semantics?

Could one add a new part (13606 part-6 or 1b?) to the specification
containing detailed RM semantics (inspired by openEHR) and at the same
time align that new part and a more general healthcare a-specific
model (a revised 13606 part-1(a)?) in a way that clearly defines a
deterministic (and tested) conversion algorithm from the detailed
clinically focused RM (6 or 1b) to the healthcare a-specific RM
(1a)?

It would be nice to have the different parts under the same roof, a
revised 13606, since they could share an AM based on AOM 1.5.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

Could YAML replace dADL as human readable AOM serialization format?

[Erik Sundvall]

Hi!

On Thu, Dec 15, 2011 at 12:44, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
 I have to say, the more I look at YAML, the more I wonder what the
 designers were thinking. For example, in this section of the spec,
 http://yaml.org/spec/current.html#id2532720
 multi-line quoted strings are only allowed if the 'key' is also quoted
 (the strange looking JSON approach);
 if the key is not quoted (i.e.
 'simple') then the value can't be quoted either. That's just nonsense!

Are you sure that is what it says?

Double quoted scalars are restricted to a single line when contained
inside a simple key.

Is it not rather that you may not use a multiline double quoted string
as a KEY (at all). It does NOT forbid you to use multiline?double
quoted strings in the value, no matter if or how you quote your keys.

I have certainly seen?double?quoted values for unquoted keys coming
from serializers claiming to be specification conformant.

Are any of your keys so long and complicated that they would need
multiline quoted strings?

 I am glad I am only implementing a serialiser, not a parser...

In many less exotic languages they are already implemented :-)
Then you configure them and then throw your object trees at them.

An example of very unfinished work in progress, using poorly readable
ordering and based on the openEHR java-ref-impl (and probably exposing
too many fields) is attached below.

Best regards,
Erik Sundvall
erik.sundvall at liu.se?http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

!http://www.openehr.org/releases/1.0.2/class/openehr.am.archetype.ARCHETYPE
adl_version: '1.4'
archetype_id: openEHR-DEMOGRAPHIC-PERSON.person.v1
concept: at
original_language: ISO_639-1::pt-br
translations:
  en:
language: ISO_639-1::en
author: {email: sergio at lampada.uerj.br, organisation: Universidade
do Estado do Rio de Janeiro - UERJ, name: Sergio Miranda Freire}
description:
  original_author: {email: sergio at lampada.uerj.br, organisation:
Universidade do Estado do Rio de Janeiro - UERJ, name: Sergio Miranda
Freire  Rigoleta Dutra Mediano Dias,
date: 22/05/2009}
  other_contributors: ['Sebastian Garde, Ocean Informatics, Germany
(Editor)', 'Omer Hotomaroglu, Turkey (Editor)', 'Heather
  Leslie, Ocean Informatics, Australia (Editor)']
  lifecycle_state: Authordraft
  details:
  - language: ISO_639-1::en
purpose: Representation of a person's demographic data.
keywords: [demographic service, person's data]
use: Used in demographic service to collect a person's data.
copyright: ? openEHR Foundation
original_resource_uri: {}
  - language: ISO_639-1::pt-br
purpose: Representa??o dos dados demogr?ficos de uma pessoa.
keywords: [servi?o demogr?fico, dados de uma pessoa]
use: Usado em servi?o demogr?ficos para coletar os dados de uma pessoa.
copyright: ? openEHR Foundation
original_resource_uri: {}
  other_details: {references: 'ISO/TS 0:2008(E) - Identification
of Subject of Care - Technical Specification - International
  Organization for Standardization.'}
definition:
  attributes:
  - rm_attribute_name: details
children:
- includes:
  - expression:
  left_operand: {item: archetype_id/value, reference_type:
CONSTANT, type: STRING}
  right_operand:
item: {pattern: '(person_details)[a-zA-Z0-9_-]*\.v1'}
reference_type: CONSTANT
type: String
  operator: OP_MATCHES
  precedence_overridden: false
  type: BOOLEAN
  rm_type_name: ITEM_TREE
  occurrences: [1, 1]
  node_i_d: at0001
  any_allowed: false
  path: /details[at0001]
any_allowed: false
path: /details
  - rm_attribute_name: identities
children:
- includes:
  - expression:
  left_operand: {item: archetype_id/value, reference_type:
CONSTANT, type: STRING}
  right_operand:
item: {pattern: '(person_name)[a-zA-Z0-9_-]*\.v1'}
reference_type: CONSTANT
type: String
  operator: OP_MATCHES
  precedence_overridden: false
  type: BOOLEAN
  rm_type_name: PARTY_IDENTITY
  occurrences: [1, 1]
  node_i_d: at0002
  any_allowed: false
  path: /identities[at0002]
any_allowed: false
path: /identities
  - rm_attribute_name: contacts
children:
- attributes:
  - rm_attribute_name: addresses
children:
- includes:
  - expression:
  left_operand: {item: archetype_id/value, reference_type:
CONSTANT, type: STRING}
  right_operand:
item: {pattern: '(address)([a-zA-Z0-9_-]+)*\.v1'}
reference_type: CONSTANT
type: String
  operator: OP_MATCHES
  precedence_overridden: false
  type: BOOLEAN
  - expression:
  left_operand: {item: archetype_id/value, reference_type:
CONSTANT, type: STRING}
  right_operand:
item

13606 revisited - list proposal

[Erik Sundvall]

Hi!

On Thu, Dec 15, 2011 at 08:52, David Moner damoca at gmail.com wrote:
 The unofficial renewal process of 13606 (or pre-SDO process, as you prefer
 :-) will start next February at the EN 13606 Association General Assembly in
 Seville with an open and public consultation.

Is there any formal link between the 13606 Association and the actual
standardisation process or is the pre-SDO process to be seen as
traditional lobbying?

Perhaps the best thing would be if the 13606 Association and openEHR
could bring forward a unified co-authored suggestion to the SDO
process rather than two suggestions? Perhaps we can use the new
mailing list Thomas suggested for mail conversations combined with the
wiki of the EN 13606 Association, instead of having separate mailing
lists and separate wikis for the alignment discussions in each
community?

 Before that, to prepare a
 draft starting point, during January a consultation will be made to key
 actors, implementers and users of the standard, including openEHR.

A great thing would be to actually have at least two independent
_implementations_ of change suggestions (both AM and RM) after initial
discussions but before any revisions to the standard are made. That is
how some other SDOs work with technical artefacts and it could avoid
some of the previous suboptimal approaches.

I assume AOM 1.5 is a candidate for AM? Is anybody already working on
an AOM 1.5 implementation in addition to Tom's Eiffel version? Are
there people interested in updating the Java implementation (or some
other implementation) before or during the SDO process?

Regarding the RM I know Tom is experimenting with simplified
ITEM_STRUCTURE as a BMM-schema for the AWB. Are there any other
RM-redesign experiments going on anywhere?

What is happening in the 13606-world regarding thoughts about
practical datatypes?

What about (optional) reusable ENTRY subtypes in the 13606 world? (see
http://www.openehr.org/mailarchives/openehr-technical/msg05285.html
under the heading 2. OBSERVATION et. al. (ISO 13606 CR))

 As you know, my opinion is that an harmonisation or at least a seamless
 transition between 13606 and openEHR is a key element to succeed.

I totally agree.

Bringing the communities tighter together is another important thing.
The way some leaders sometimes talk of the other organisation's
approaches might not be helpful in that sense. Those of you having
formal powers in each organisation please ask your leaders to speak as
honestly and nicely as possible of each others
organisations/communities/approaches, or else please change leaders.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

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

[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
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111208/77d721f6/attachment.html

Could YAML replace dADL as human readable AOM serialization format?

[Erik Sundvall]

Hi!

On Mon, Dec 5, 2011 at 00:10, Heath Frankel 
heath.frankel at oceaninformatics.com wrote:

 I think previously I had indicated I had no problem with the stringified
 interval approach in XML, but I am reverting my thinking on this and feel
 that it would be counter intuitive for those who what to use the XML
 schemas for code generation purposes.  I think in this case the computable
 requirement outweighs the human readable requirement.


You are probably right regarding XML, and maybe this is valid also for most
JSON use-cases where the desire for an as simple as possible
object-serialization-mapping outweighs human readability.

I think the openEHR community is best served by having different archetype
serialization format categories with different priorities for different
purposes. E.g.:

1a. An XML format optimized for mapping to XML-schema generated code.
1b. A JSON format optimized for mapping to AOM object models handcrafted or
generated from AOM-specifications.

2. A cADL-variant wrapped in YAML optimized for human readability. It could
be used for archetype files stored in version control systems (making
version diffs readable) and as textual format when you need textual
examples in documentation, teaching etc.

In 1a  1b easy implementation should be prioritized over readability but
in #2 human readability should be prioritized. Prioritizing both in the
same format would likely fail. Things like default ordering of nodes and
attributes could be recommended but optional for #1 but should be mandatory
for #2 (otherwise readability suffers and diffs get messed up).

I think we can come up with a much more concise representation of these
 intervals without compromising the computable requirement, something
 similar to XML schema maxOccurs/minOccurs.


Probably, but for #1 maybe being close to the AOM should be prioritized
over being concise. After all, archetypes will not be sent over the wire at
the same scale as patient data (RM instances).

By the way, is the AOM open for changes (like renaming attributes) if that
would increase clarity?

If we would change subject and discuss RM instance serialization, then
binary formats (like Protobuf and Thrift) could form a third category where
message size and speed of conversion would be prioritized over ease of
implementation or readability. XML and JSON would likely be good to have
also for interoperability and debugging purposes. YAML for the RM would not
be an obvious over the wire-format, but can be very useful for compact
human readable long term EHR archiving storage as plain text files and for
documentation examples.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733


 please everyone remember that the dADL, JSON and XML generated from AWB
 all currently use the stringified expression of cardinality / occurrences /
 existence. Now, these are usually the most numerous constraints in an
 archetype and if expressed in the orthodox way, take up 6 lines of text,
 hence the giant files (e.g. AOM 1.4 based XML we currently use) - and thus
 the much reduced files you see on Erik's page, because we are using ADL 1.5
 flavoured serialisations not the ADL 1.4 one.

 Now, I think we should probably go with the stringified form in all of
 these formalisms. The cost of doing this is a small micro-parser, but it is
 the same microparser for everyone, which seems attractive to me.

 The alternative that Erik mentioned was more native, but still efficient
 interval expressions, e.g. dADL has it built in (0..* is |=0| in dADL),
 and YAML and JSON could probably be persuaded to make some sort of array of
 integer-like things be used. XML still doesn't have any such support. In
 theory this approach would be the best if each syntax supported it
 properly, but XML doesn't at all, and the others don't support Intervals
 with unbounded upper limit (i.e. the '*' in '0..*'). *
 *
 But Erik's exercise certainly proved that efficient representation of the
 humble Interval Integer is actually worthwhile. (Once again thanks for
 that page, its quite a good way to get a good feel for these syntaxes very
 quickly).*
 *
 - thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111205/e7161629/attachment.html

Could YAML replace dADL as human readable AOM serialization format?

[Erik Sundvall]

Hi Seref!

On Mon, Dec 5, 2011 at 13:32, Seref Arikan 
serefarikan at kurumsalteknoloji.com wrote:

 I'll repeat a point I've tried to make before, since it is relevant in the
 context of binary serialization.
 I've used protocol buffers serialization of AOM in Bosphorus


Why do you use binary serialization for AOM? (Just curious, I thought text
formats would cater for most AOM use cases.)

I have not looked deeply into protobuf so I'll take your word on the lack
of OO support. Looking at http://wiki.apache.org/thrift/ThriftTypes their
Structs also seem to lack inheritance. So I'll try to keep quiet about
cross-platform binary formats at least until I have tried applying any of
them to openEHR for real.

... you'll have to find non standard ways of dealing with the simplicity of
 the formalism.


For JSON I would agree that the formalism is sometimes too simple and one
may need to make an openEHR specification for how to convey object type
when needed, perhaps inspired by something like
- http://flexjson.sourceforge.net/ that adds a class attribute or
- by exploring if introspection of the target object type like
http://code.google.com/p/google-gson/ does is enough for openEHR data.

Here is the simplest example from Bosphorus: Eiffel is an object oriented
 language, Java is also an object oriented language. openEHR specs use
 interitance, which is reflected into type hierarchies of both Eiffel and
 Java classes. You have the protocol buffers language which does not support
 inheritance. How do you represent instances of abstract types in protocol
 buffers?


Sorry if I'm dense, but when do you need to instantiate abstract types in
RM data?

In a way, it is a conceptual distance from OO. Every alternative mentioned
 here is at a particular position to a particular level of OO support (take
 it as a point in a multidimensional space). Every alternative has values
 higher than the rest in a particular dimension, but none of them is
 absolutely closer to the OO support point (represented by
 Java/Eiffel/C#/Python etc) In my opinion, without this evaluation of OO
 support, which is what we use in the actual languages of system
 development, other discussions are not really relevant. What if protocol
 buffers are fast? What if YAML, ADL, or JSON are easier to read, space
 efficient?


Do you bundle YAML and XML into that opinion (lacking of OO-support the
same way as protobuf)?

Do you think that dADL can carry everything needed for openEHR (both AM and
RM)? If so why wouldn't YAML? What in basic dADL semantics is missing in
YAML? YAML (using a !-prefixed syntax) and partly XML (using e.g. xsi:Type)
have ways of conveying object type in the case it cannot be inferred from
data.

Maybe I'm being too rigid about this particular issue, but the programming
 language, its tools and frameworks built on it is what determines industry
 adoption more than everything else today. I don't think this is being
 considered in these discussions, but that is just me.


I guess language-specific binary formats (like serialized java objects) may
be better for binary representation then. Thanks for the word of warning
regarding protobuf.

Do you think that all openEHR instance serializations really need to be
object oriented themselves or is it enough that the classes of
the receiving application are object oriented and that the deserialization
code (or the transfer format) is clever enough to put the data into the
right objects?

There are some cases where different openEHR datatypes may have the same
attribute signature and for those cases even transport formats aiming
reduce verbosity will need to explicitly declare class type since they
cannot be safely inferred.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733




 On Mon, Dec 5, 2011 at 11:36 AM, Erik Sundvall erik.sundvall at liu.sewrote:

 Hi!

 On Mon, Dec 5, 2011 at 00:10, Heath Frankel 
 heath.frankel at oceaninformatics.com wrote:

 I think previously I had indicated I had no problem with the stringified
 interval approach in XML, but I am reverting my thinking on this and feel
 that it would be counter intuitive for those who what to use the XML
 schemas for code generation purposes.  I think in this case the computable
 requirement outweighs the human readable requirement.


 You are probably right regarding XML, and maybe this is valid also for
 most JSON use-cases where the desire for an as simple as possible
 object-serialization-mapping outweighs human readability.

 I think the openEHR community is best served by having different
 archetype serialization format categories with different priorities for
 different purposes. E.g.:

 1a. An XML format optimized for mapping to XML-schema generated code.
 1b. A JSON format optimized for mapping to AOM object models handcrafted
 or generated from AOM-specifications.

 2. A cADL-variant wrapped in YAML optimized for human readability. It
 could be used

Could YAML replace dADL as human readable AOM serialization format?

[Erik Sundvall]

Hi!

Let the battle begin :-) see:
http://www.imt.liu.se/~erisu/2011/AOM-beauty-contest.html

On Tue, Nov 22, 2011 at 13:24, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:

 actually, ADL 2.0 as reported in this document is now obsolete. The ADL
 1.5 compiler already does this, and will use it as a fast save/retrieve
 format.


Will cADL become optional or go away somehow?

One area where dADL beats JSON and YAML (I think) is its better support for
 Xpath-like paths.


Why would that be different? I guess most path queries will run
on instantiated object trees rather than on documents and then there is no
difference - and if paths were run directly on documents, then please
explain why dADL would support them better.


 Plus its much more compact than JSON.


Much? Less noisy I would agree to though.


 Personally I find YAML hard to read because there are so many syntax
 elements (triple '-', triple '.' etc) but that might just be me.


Have a look at...
http://www.imt.liu.se/~erisu/2011/AOM-beauty-contest.html
...again.

The triple '-' and triple '.' are (mostly optional) start and end markers
of documents that make life easier when concatenating streams/documents,
see the YAML specification.

Am I the only one that thinks YAML is more readable than dADL?

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111201/2dfec204/attachment.html

Could YAML replace dADL as human readable AOM serialization format?

[Erik Sundvall]

Hi!

A little suggestion/thought (that might be of value also for CIMI-folks and
others looking at archetyping using ADL and AOM and wondering if a
specific language is needed).

*Limitations:*
For efficient handling of RM (Reference Model) instances (patient data)
flying back and forth between systems you'd probably want some binary
format (protobuf http://code.google.com/p/protobuf/, thrift
datatypeshttp://thrift.apache.org/, serialized Java
objects or whatever), this is NOT what this suggestion is about. For
development and debugging RM-instance exchange you may also want some
fairly human-readable serialization that is supported by many platforms
(Like JSON http://www.json.org/, YAML http://www.yaml.org/, XML or
whatever) this is NOT what the suggestion is about either. Also note that
the current suggestion only aims at looking for replacement of dADL not
cADL. Also note that the AOM and XML serialisations of the AOM are not
affected by this suggestion.

*Background:*
cADL (Constraint ADL) is a compact
DSLhttp://en.wikipedia.org/wiki/Domain-specific_language that
is aimed at defining constraints on an object model, while dADL (Data ADL)
on the other hand is mainly a general object-graph serialization format.
If I understand section 1.7.5 in the ADL 1.5
spechttp://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdfcorrectly,
ADL 2.0 will allow the option to define
*all *parts of an archetype (including what is now done in cADL) as
a dADL serialization of the
AOMhttp://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.5.pdf(Archetype
Object Model). Is that correct Tom?

*Suggestion:*
Investigate if YAML can replace or complement dADL
as object-graph serialization format for archetypes. (Perhaps there is
interest from people using an openEHR AOM implementation in a language that
already has YAML serializers to make a quick experiment?)

*Motivation:*

   - YAML parsers converting YAML documents to native object graphs already
   exist for a number of languages http://www.yaml.org/ (C/C++, Ruby,
   Python, Java, Perl, C#/.NET, PHP, OCaml, Javascript, Actionscript, Haskell)
   so there would be less work creating and maintaining archetype parsers that
   turn archetype files into in-memory object graphs. (If you write an
   archetype authoring tool an need to validate archetypes, not
   just instantiate already validated archetypes, then the Validity Rules
   (such as the ones in blue under 4.3.1.1  in the AOM spec.) will of course
   still need to be implemented in software.
   - Having an archetype specific object-serialization language like dADL
   might make archetyping look more mysterious and suspect and might hide
   the fact that the semantics expressed in the AOM is the interesting thing
   that can be serialised in many different ways.
   - And (admittedly subjective) YAML lists and objects look slightly
   better and more readable than dADL. A notable exception is probably
   intervals/ranges that have a compact representation in dADL (see
section 4.5.2
   of the ADL 1.5
spechttp://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf)
   but not natively in YAML.

*Observations:*
YAML is extensible, so data types for intervals etc can be added like in
http://yaml.org/YAML_for_ruby.html#ranges, also see discussion at
http://stackoverflow.com/questions/3337020/how-to-specify-ranges-in-yaml. A
similar approach could be taken to dADLs Plug-in Syntaxes (see
section 
4.6http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf)
using YAML. A number of language-independent extra YAML datatypes (timestamp
http://yaml.org/type/timestamp.htmlfor example) are listed at
http://yaml.org/type/index.html and you can define your own if you need
more.

It seems like specification 1.1 (http://yaml.org/spec/1.1/) is the most
implemented, so any dADL comparisons should probably be done towards that
version to be fair.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

P.s. Tom Beale and I sort of started a brief off-list discussion about
YAML, here is now an attempt to get input from more people.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2022/a48d185a/attachment.html

occurrences and cardinality in ADL, XML, JSON

[Erik Sundvall]

Hi!

Just to make things more confused, here is another option for
occurrence serialisation in JSON, YAML etc.

Use arrays/sequences with two values for things like?occurrences, that
way it's compact (same number of characters as occurrences: 0..5)
and almost as readable, but the parser/serializer does more of the job
and will even provide the programmer with data type (e.g. string or
number) or null.
In JSON...
occurrences: [0, 5]
...and YAML...
occurrences: [0, 5]

The question of how to do with unbounded * still remains of course,
one could do valid (ugly but compact) JSON like...
occurrences: [0, *]

On Fri, Nov 11, 2011 at 04:36, Andrew Patterson?andrewpatto at 
gmail.com?wrote:
 Why cant' the absence of a value mean unbounded?
 occurrences =  ?lower = 2?

 Means 2..*

Then a JSON like...
occurrences: [2]
... (assuming occurrences are never unbounded in the lower end) or...
occurrences: [2, null]
?...could mean unbounded upwards. I guess asking an API or programming
language for the second value (index 1 if starting at 0) of the array
will return null in both cases above.

Since the short form of 1..1 often is just written as 1 in UML and
ER-diagrams, the first style with occurrences: [1] meaning 1..*
should probably be avoided and instead occurrences: [1, null] should
be recommended for 1..* if humans are supposed to read. (And thus
using occurrences: [1, 1] if you mean 1..1 and occurrences: [0, 0]
if you mean 0..0)

It looks a bit scary/ugly though, but probably better than [2, *]
and to check for null is in many programming languages nicer than
having to check datatype and possibly string content.

On Fri, Nov 11, 2011 at 04:36, Andrew Patterson?andrewpatto at 
gmail.com?wrote:
 Also, what about inclusive/exclusive values at either end
 of the interval? I know that this isn't an issue for occurence and
 cardinality intervals which are always inclusive - but are we proposing that
 the representation of normal intervals will not use the same mechanisms
 are you are proposing here?

What about using?booleans in an?array/sequence?
inclusive: [true, false]
...meaning inclusive in lower but not upper end. But perhaps intervals
need a completely different approach.

Was that confusing enough?

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

P.s. Off-topic: If this discussion was rushed and had to be decided in
a time-limited face to face meeting we might already have picked the
0..*-string version and would have hesitated even to consider the
above as a possibility if it popped up a few days later. (I am just
trying to hint that slow open mail discussions allow more technical
ideas to come forward than rushed meetings. Face to face meetings have
great value too, but perhaps even more for other things than technical
design.)

Bosphorus web services beta announcement

[Erik Sundvall]

Hi!

On Tue, Nov 15, 2011 at 10:45, Seref Arikan
serefarikan at kurumsalteknoloji.com wrote:
 The web service exposes the archetype parser functionality of Thomas Beale's
 Eiffel code base with XML and JSON output.

Very nice work! Does this mean that it will be easy to keep it up to
date with the functionality of  ADL 1.5 workbench?

On Tue, Nov 15, 2011 at 20:39, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
 for those interested in JSON, I will have a JSON outputter in the ADL 1.5
 workbench in a few days
...
 I will put a small rule-base in allowing some
 variant forms to be generated. If anyone has specific requests, let me know.

Some REST/HTTP/URI related thoughts below:

On Tue, Nov 15, 2011 at 10:45, Seref Arikan
serefarikan at kurumsalteknoloji.com wrote:
 http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypeslist

You might want to swap at least the resteasy part of the URI to
something not bound to a specific product before finalizing the
interface.

 http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetype?archetypeName=openEHR-EHR-CLUSTER.case_identification.v1
 returns the XML output. Simply changing the URLS to
...
 http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypejson
 allows access to JSON output.

Having different paths in the URIs for the same resource (same
archetype in this case) actually goes against some REST principles.
XML and JSON are just different representations of the same
resource

See details regarding resource and representation in the HTTP 1.1
spec http://www.w3.org/Protocols/rfc2616/rfc2616.html or Fieldings
dissertation http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

The HTTP protocol can handle the media-type negotiation depending on
the capabilities and preferences that the client sends in the HTTP
headers. When later adding a representation with another mediatype
(e.g. YAML or protobuf) you won't need to extend the URI space (and a
lot of client code can be reused).

Of course you might want to override the HTTP negotiation in some
cases, but then I'd recommend to use a generic media URI query
parameter with values being media types
(http://en.wikipedia.org/wiki/Internet_media_type). If you also want
pretty-printing to be a selectable option (as Bosphorus seems to
provide) the resulting URI might look something like
.../getarchetype?media=application/jsonarchetypeName=openEHR-EHR-CLUSTER.case_identification.v1prettyPrint=true

Having an access route with URIs like this might also be nice in the future:
.../archetype/openEHR-EHR-CLUSTER.case_identification.v1/
(Exposes the resources nicely and gives very clean URIs in listings etc)

In LiU EEE we provide URIs to RM VERSION objects (e.g. COMPOSITIONs)
like this...
http://hostname.domain.se/ehr:example-EHR-ID/129134f5-af94-4940-bea3-ad556d0efdb8::test2.eee.mi.imt.liu.se::1
and depending on what your HTTP client asks for in the HTTP headers
different representations, like XML or HTML will be returned. If a
client wants to override e.g. preset browser settings they just append
a query string like ?media=text/html

We aim to get an updated demo server online soon too and have been
focusing more on REST for the RM side of openEHR. Source code will be
published together with a paper. Perhaps we have avoided duplication
of work if you have focused on REST for AM and we mainly for RM :-)

 In the near future, we are going to be extending the set of services, and we
 would be glad to hear about your ideas for new web services in the tooling
 space.

A web service taking a Template file (and archetypes either from
repository or uploads) as input and generating an Operational Template
(OPT) as output in JSON or XML would be very nice contribution.

There are a lot of magic output formats outlined in e.g. figure 3 of
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.5.pdf
that would be nice to be able produce online via http.

Again, nice work!

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

occurrences and cardinality in ADL, XML, JSON

[Erik Sundvall]

Hi!

On Mon, Nov 14, 2011 at 06:23, Heath Frankel 
heath.frankel at oceaninformatics.com wrote:

 However, others may not be so keen on this as those starting out with
 openEHR like to use the built-in development tools in their favourite IDE
 to generate classes that match the AM/RM and automatically serialize data.


Yes. Please do not exclude the current verbose RM-mimicking XML-formats
from a future version update since they certainly have a value too. They
are for example very nice when you want to map AQL to xPath (and xQuery)
and for generating stubs in programming languages.

Is there anything stopping us from having more than
one serialization alternative per formalism, e.g. both verbose and compact
XML?

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2014/b92687db/attachment.html

Instruction State Machine SCHEDULED - EXPIRED

[Erik Sundvall]

Hi!

I just want to check if I understand the ISM intentions correctly...

In FIGURE 24 openEHR standard Instruction State Machine in
http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf there is
no path from SCHEDULED to EXPIRED.
Of course if something is scheduled but not done, it in reality is likely
postponed or rescheduled...

...but from an EHR-algorithm's perspective, if an
action's scheduled time passes and nothing has been reported to the EHR
system yet (none of the allowed ACTIVE, POSTPONED or re-SCEDULED) what
should the algorithm then conclude?
I assume the EHR state for the action stays on SCHEDULED but having a
passed date. Is that correct? If so I guess out-of-date-finding mechanisms
need to look _both_ for EXPIRED-marked things and for SCHEDULED things past
due date. Is that correct?

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2012/c1a54e8b/attachment.html

future of CEN 13606 data types

[Erik Sundvall]

This is wonderful news! Now there is a chance to use the word
harmonization in a more productive manner :-)

Thank you to Grahame Grieve and others involved!

This is too important to leave only to time- and people-constrained
physical committee meetings, we probably all need to help out somehow
with good technical thinking and some kind of real prototype
implementation before any formal decisions are made.

- Where are the main online discussion/information hubs where key
people discuss this kind of redesign work in the different efforts
(HL7, CEN, ISO, openEHR etc)? For openEHR I'd guess this technical
mailing-list is the main hub for this (possibly complemented by a
harmonization-wiki page or two as condensed memory-notes with links
to some list messages etc).
- How do we best set up communication links between the communities?
Is it by joining each others mailing-lists/discussions? Other ways?

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733



On Sun, Sep 18, 2011 at 13:37, Thomas Beale
thomas.beale at oceaninformatics.com wrote:

 At the HL7 meeting last week in San Diego, Grahame Grieve presented
 something called Resources for Healthcare (RFH), essentially a replacement
 model for much of HL7v3, for 'practical use'. The driver was the well-known
 over-complexity of HL7v3. According to his report on the reception of RFH at
 the HL7 meeting, there appears to be a real appetite for change at HL7,
 which is good to see.

 Within RFH, Grahame has proposed a new data types model.? In practical terms
 this will presumably mean that implementations directly based on the RIM and
 21090, and particularly the creation of RIM/21090 data instances will see
 much reduced use in the future. From the point of view of openEHR and 13606
 this represents some positive possibilities for bridging implementations in
 the future, and maybe finally solving the 'logjam' in health informatics
 standards.

 Things to note about the RFH data types:

 They use orthodox object modelling rather than the subtractive modelling /
 profiling approach used to date HL7.
 They define a very lean set of semantics (so far).

 These two together mean that for the first time, HL7 data types (if that is
 what RFH data types become) can be extended in the normal OO sense, rather
 than having to be 'profiled' (creating N variants, all non-interoperable
 with each other). Interoperability can potentially now be found by
 connecting to the core definitions, even if it can't directly be found with
 more complex extensions of the core types.

 They incorporate a lot of features of the openEHR data types.

 The current openEHR data types are currently more full-featured, and in some
 cases probably more complex than they need to be - adjustments may be
 possible here (one example: the normal / reference ranges in DvQuantified
 should be pulled out into a wrapper type or else added by inheritance to
 DvQuantity and possibly DvCount, DvProportion).

 My conclusions at this point:

 building a data conversion interface between openEHR and HL7 of the future
 now has a good chance of success, if the RFH data types develop in an
 appropriate way
 CEN/ISO 13606 should move to the RFH data types, and not use 21090 - doing
 so is likely to set up a legacy in the future for 13606 users that HL7
 community is about to leave behind. It will allow 13606 to become much
 closer to openEHR, and facilitate the merging of the models into one, which
 I think is a necessary future step for both openEHR and 13606.

 If HL7 goes this way, some real convergence finally looks possible, and
 people working on openEHR and 13606 need to think about how to go about it.

 - thomas beale

Tools for collaborative working

[Erik Sundvall]

Hi!

On Sat, Sep 17, 2011 at 00:10, Bert Verhees bert.verhees at rosa.nl wrote:
 The main reason is, the Linux Kernel development must not be
 depending on a single person or company. That is too dangerous.

I think this dependency is one of the key things to consider
regarding openEHR too.

When it comes to version control of software I don't think it it would
be a _huge_ problem if we used a free commercial solution in the
cloud. If they start giving us trouble we simply move the code
elsewhere. It's still a problem though since we might lose the old
versioning history of the project. Tagged releases could be kept as
zip-files of course, but the continuous history is lost. Git is
different, everybody that wants it can have the complete digitally
signed tamper-proof versioning history. There is technically no single
central point of of control in GIT (even though you can socially set
up your project to work in a centralized manner regarding release
related branches etc if you wish). Thus if we use a commercial Git
provider like Github we could move elsewhere without losing versioning
history.

But again, regarding software up to now we have not had many
independent branches and most important design discussion and
announcements are facilitated out-of band in mailinglists rather than
via the versioning control comments etc so losing version history
might not be too disastrous.

Regarding archetypes on the other hand most discussion is nowadays
done in the combined CKM versioning  discussion tool, so losing
history from that combined repository would be a very bad thing. So if
we would be using a version control system as underpinning for a
future CKM alternative or for some kind of archetype nursery, then I
think Git would be the very best way to go. Everybody that wanted a
copy could of the complete history could have one and you could in a
controlled manner at the same time follow and reintegrate development
work from local/national efforts etc. If we at the same time could
integrate the technical backend of the clinical
discussion/communication regarding the archetype development too it
would be great. (That does not mean that clinicians would be forced to
understand GIT - a clinical frontend GUI could be similar to the CKM
or whatever.)

So some suggestions:
- Let each software project pick their own versioning mechanism, but
perhaps try to agree on hosts, e.g. use cloud-service X for SVN and
cloud-service Y for GIT so that developers involved in several openEHR
projects don't need to register accounts in too many places
- If any future functionality (like CKM++) is BASED ON a versioning
control system (rather than just using one) then make sure it is open
source and that complete history is not only kept at a single point.
Git would seem to be the obvious choice here.
- If a unified issue-tracker service could be used for all projects
then that would be preferrable. Also here it is important to use an
open or decentralized system so that the issue tracking history does
not get lost if a commercial service changes terms or goes bankrupt.
- Regarding dependency and vulnerability I also think it's important
that (as in the Apache organization) every openEHR board and
sub-project has members or committers from at least three different
economically independent organisations.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

openEHR Transition: two procedural and one licensing question

[Erik Sundvall]

Hi!

 On Thu, Sep 8, 2011 at 16:54, Sam Heard sam.heard at oceaninformatics.com 
 wrote:
 Let's stay with the issue of how we stop someone copyrighting and charging
 for a specialised archetype? Or a template that is fundamental to health
 care (like an antenatal visit)?

So, Sam have you finally dropped the thought that CC-BY-SA would
protect against patent system abuse? We have not gotten a clear answer
to this yet.

Is your only remaining concern now that you believe copyright law
might be so strong that it would stop possibilities to do
specialisations with the same main functionality as possibly
copyrighted useful specialisations? Is that your only remaining SA
motive?

Sam, since you are and have been so extremely powerful in the formal
openEHR decision process, we really need to understand your thoughts,
thus I and others have been probing to figure out your reasoning for
years.

On Fri, Sep 9, 2011 at 00:21, Timothy Cook timothywayne.cook at gmail.com 
wrote:
 Maybe that isn't such a bad thing. ?They are only roping themselves
 into their own corner.

:-)

We as a community could always provide help in highlighting those ropes via:
- Technical means: license detection upon import of archetypes and EHR
data (as described on the wiki)
- Social  political means: questioning the fairness and wisdom of
parties trying to block the common good of semantic interoperability.
Their income often somehow originates from public funding and they
should be concerned about potential badwill.

We can probably also get around the hypothetical/potential problem by
making a similar (hopefully even better) specialisation ourselves (not
an exact copy) that covers the same needs. It will be hard for the
copyrighting and charging-bad guys to claim that another
implementation of the idea is a verbatim copy (prohibited by
copyright) and that their work has enough innovation height that is
not obvious to skilled persons (and thus patentable). The same
argument goes the other way too - even ideas from a CC-BY-SA licensed
archetype from openEHR may be fairly closely re-implemented as
completely closed/copyrighted and it would be both hard and
time-consuming for the openEHR foundation to try and stop this
(anti-interoperable) approach, so let's reduce the temptation by
simply using CC-BY.

Copyright does not stop ideas the same broad way patents do. To
software people I believe it's obvious that improvement-ideas in
commercial closed source forks of e.g. apache-licensed software
projects does not prevent the open source original project to
reimplement similar ideas (as long as the closed source code is not
copied). Copyright is not nearly as harmful as patents in these cases.

On Thu, Sep 8, 2011 at 01:37, Sam Heard sam.heard at oceaninformatics.com 
wrote:
 Our advice was that having copyright simplifies the world. Having said that
 the same archetypes now exist in other repositories with copyright assigned
 to the national provider, so it is already murky.

Well, if the national providers had been encouraged to use CC-BY
instead of CC-BY-SA then it wouldn't matter at all who had the
copyright (as Tom has pointed out several times over the years)...

On Fri, Sep 9, 2011 at 05:25, Sam Heard sam.heard at oceaninformatics.com 
wrote:
 ...government agencies and companies will want to know that no one has 
 recourse to legal action if they use an archetype.

Is that a copy of the ideas behind my argument _against_ CC-BY-SA? :-)

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

openEHR Transition: Web-based tools?

[Erik Sundvall]

Hi!

I agree with Seref. Web based apps nowadays can use local storage in
modern web clients and even be run perfectly offline and sync when
they get back online.

If effort is put into new tools it might be good idea to do at least
the GUI in HTML5 etc. The server could be any technology you want,
including Eiffel ;-), as long as it speaks http, if normal users
(including ones under IT policies of the institutions) don't need to
do a server install.

Regarding editing power and repository integration have a look at some
examples like
http://c9.io/
http://ace.ajax.org/

By the way, using Git as archetype repository sync backend at least
for non-CKM work (as hinted by Shinji) seems to be a really nice idea
the nore you look at it. The Git collaboration patterns and mentality
seem to fit the use-case of distributed multi-branched archetype
development.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733



On Sun, Sep 11, 2011 at 12:21, Seref Arikan
serefarikan at kurumsalteknoloji.com wrote:
 Peter,
 The problem is not necessarily about the capability of frameworks to
 manage updates or side by side execution.
 90% of the time problem is about the IT policies of the institutions.
 If you develop with .NET 4.0, which would require a .net framework 4.0
 runtime, you assume that the people using the software would be able
 to install the runtime, and install the software.
 many corporate/institutional machines do not allow their users install
 software. Most of the corporate/institutional IT is running on
 horribly old software. IT policy is the real issue I was referring to.
 I don't want to go into a long description of things that went wrong
 for me in the past, but let me just say that I've personally had
 enough issues with both Java and .NET deployment and upgrades that
 makes web based apps a much better option when it comes to this
 particular aspect of software life cycle.

 Regards
 Seref


 On Sat, Sep 10, 2011 at 2:18 PM, Peter Gummer
 peter.gummer at oceaninformatics.com wrote:
 Seref Arikan wrote:

 ... ?Unfortunately, most modern
 software development technologies arrive with their own runtimes,
 (.net framework, jre etc) and it quickly becomes a nightmare to deploy
 and update software.

 I'm not aware of any such deployment problems with .NET. I'm sure
 there must be some, somewhere, but they must be edge cases. In ten
 years of .NET development I haven't bumped into them. Different
 versions of .NET sit side-by-side on the same machine just fine; ditto
 for DLLs targeted towards different .NET versions. My daily work
 involves a .NET 4.0 application that has dependencies on a lot of .NET
 2.0 DLLs; it just works seamlessly.

 - Peter

openEHR Transition Announcement (about regional/national openehr organizations)

[Erik Sundvall]

Hi!

On Wed, Sep 7, 2011 at 08:38, Ian McNicoll
Ian.McNicoll at oceaninformatics.com wrote:
 So, my question back, is
 What sort of support would you like to see, given that significant
 central resourcing is not likely in the short term?
[...]
 Would it be sufficient for the Foundation to give 'official status' to
 regional affiliates e.g. openEHR Japan, or are there other practical
 suggestions as to how best to support regional affiliates?

I would guess that an 'official status' recognition and thus links in
online (and some offline) information resources would be a major
thing, more imoportant than funding, especially if this also allowed
the regional organisation to arrange official openEHR
gatherings/conferences etc. It would be reasonable if the local
organisation could keep money left over from such (possibly partly
commercially sponsored) gatherings/conferences.

Of course it would be reasonable if the foundation had some
requirements on official local organisations, like having:
- open membership
- statutes matching regional democratic traditions and the openEHR
goals (internal governance rules or whatever the swedish word
stadgar should be translated to)
- proper accounting and audit
- a duty to have a dialogue with the central openEHR foundation
regarding plans involving using the openEHR tradmark for events etc
- ...probably more...

For local organisations I think bottom up comunity driven governance
with elected boards etc is the only way to go, not top-down.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

openEHR Transition: two procedural and one licensing question

[Erik Sundvall]

Hi Stef!

On Tue, Sep 6, 2011 at 22:15, Stef Verlinden stef at vivici.nl wrote:
 Good that you bring up the SA + or - discussion again.

I wish I wouldn't have to. I'd rather focus on implementation and research.

 In order to make the
 best decision can you please provide us with these arguments

The arguments AGAINST SA have been publicly available for years on the
openEHR community wikipage set up by Thomas Beale for exactly that
purpose:

http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal

Do read that wikipage and follow the links there to the mail
discussions. What is it that you think is missing or unclear in the
arguments against SA?

The arguments FOR SA have, according to me at least, not been properly
explained publicly, but some argument has obviously been strong
somehow behind the locked doors in board discussions.

Clarification from Sam and the board has been sought for several
years, e.g. in the followup questions directed to Sam since
04-Jun-2010 at 
http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal?focusedCommentId=13041696#comment-13041696

and, if possible, with the names of those companies/organisations.

No, because:
1. I don't know if it was said in confidence or not
2. It's about time they, and all other openEHR-related
companies/organisations, engage themselves in the future of openEHR
and figure out their possible positions in this ecosystem. Until now
there has not been a proper chance for them to engage on the same
premises as Ocean Informatics and UCL, but now it's about time to wake
up :-)

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

Bosphorus Web Services and an open source communication layer for openEHR implementers

[Erik Sundvall]

Wonderful news Seref!

I think we should take time to discuss some time soon in order to
match efforts and reduce overlap. :-)

I believe many things can complement each other nicely e.g. in a
partly REST-based open source framework aimed for web-based
approaches.

// Erik

On Tue, Sep 6, 2011 at 19:32, Seref Arikan
serefarikan at kurumsalteknoloji.com wrote:
 We announced Project Bosphorus from UCL, CHIME at the end of 2010 ...

openEHR Transition: two procedural and one licensing question

[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 sam.heard at oceaninformatics.com 
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 sam.heard at oceaninformatics.com 
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 save the openEHR community form patent abuse.

On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at oceaninformatics.com 
wrote:
 [Sam Heard] If this is true then the SA part of the license has no value. If
 this is true then I have not heard this before.

I am very glad if you might have started to see the lack of value in
SA for archetypes. Using pure CC-BY (for both archetypes AND
specifications) would make the first six points under Principles of
licensing unnecessary and reduce confusion.

At the same time I am very worried about the totally amazing
information blocking filter you must have built in if you have not
heard this argument before. Several people have been questioning your
reasoning on this very point for years!

On the official openEHR-wikipage set up for this particular question
when community feedback was requested...
http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal
...you have several people (including Tom Beale) in clear text saying
that CC-BY-SA will NOT protect against patent attacks. (Scroll down to
the heading Discussion summaries regarding CC-BY versus CC-BY-SA for
content models.)

How on earth could you and the entire board miss that when writing up
the draft for the transition whitepaper and when making earlier
license decisions?

One thing that however is very efficient in fighting patent trolls is
prior art. Thus one of the best protections regarding archetypes
etc. is to have as much as possible of development completely public,
indexed and archived by trusted sites (like http://www.archive.org/).
This means always making sure to allow enough search engines and not
requiring login in order to read archetype discussions and thoughts in
development repositories (things like the CKM). The earlier date the
mention of an idea can be traced back to, the more patent claims it
will protect against.

Best Regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

P.s. I agree with Pablo  Diego that we need to talk about
communication between several

openEHR Transition: two procedural and one licensing question

[Erik Sundvall]

Hi Ian!

Nice to have more than one single board member to actually discuss
with on the lists, this is already a great openEHR improvement!

On Tue, Sep 6, 2011 at 15:07, Ian McNicoll
Ian.McNicoll at oceaninformatics.com wrote:
 The issue of CC-BY vs. CC-BY-SA has, of course, been extensively
 discussed and although the previous board took a decision to adopt SA,
 this is very much up for further discussion.

Good. Don't wait too long, there are several more interesting and fun
things to discuss and work with once the licensing stupidity is
solved.

?Like many others, I did
 not get particularly involved in these discussions as it felt to me
 (perhaps incorrectly) to be a somewhat arcane and legalistic debate
 over a pretty fine point.

How can this be explained to clinicians of the board if what is
already on the wiki...
http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal
...is not enough? Just read through that page and follow the links to
the messages in the cited mail debate dating years back, then ask
again if any points are still unclear.

Analogies can be misleading, but I'll try: What danger is a pretty
fine point of a malign cancer cell cluster in a human body, why so
much fuzz when you detect that?

Whenever I talk to software people they seem to immediately understand
the issue and importance of not having licence-contagious
(GPL/SA-like) code getting into the wrong parts of closed source
systems (if you want to allow closed source business models in your
ecosystem). Software people also understand that you simply can't
claim to publish something as CC-BY at the same time as you say that
some derivative works based on it should be CC-BY-SA, that's just
incredibly misguided and any governance body letting that slip through
is not to be completely trusted regarding license competence until
further educated...

If you don't have people on the board understanding software industry
basics, then the board is missing some vital competence and you should
make sure to either get that competence into the board or take the
advice of people like Tom Beale in these questions. Just as much as
you'd probably consider it wise to consult a clinician rather than a
software specialist regarding medical issues.

The fine point of licensing is fundamental for most companies before
deciding if they want to commit commercial resources into any
software-related project. I have heard serious arguments in more than
one country where companies/organisations are not wanting to use
openEHR archetypes partly because of the SA licencing issue. They may
have adopted the technical framework (RM etc) but are using their own
set of archetypes, and as long as they don't exchange data outside
their own systems then there is no perceived interoperability
problem... *sigh*

 What might be helpful to me and others would be some clear practical
 examples of the kind of scenario for which CC-BY-SA is thought to be
 required (rightly or wrongly).

Read that wikipage and the mail links again, there are several
examples in those texts where CC-BY-SA would likely reduce trust in
openEHR as a viable business option.

One major short term risk I see currently is that the foundation will
continue to be slow in response to licensing concerns and that as a
result competitors to the openEHR-hosted CKM will pop up using better
licenses (like pure CC-BY) for their non-openEHR-derived archetypes
and that the archetyping community gets fragmented and semantic
interoperability thus is reduced.

Another short term risk is that fewer commercial entities might be
interested in openEHR if there is a perceived lack of understanding of
software industry needs in the board.

But I think you find most of these arguments already on that wikipage
and in it's linked mail discussion.
http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal

Do read it.

And the links.

Please.


// Erik

openEHR Transition: two procedural and one licensing question

[Erik Sundvall]

Hi!

Kudos for moving forward!

Plans seem to take some promising directions even though that whitepaper
at...
http://www.openehr.org:/openehr/321-OE/version/default/part/AttachmentData/data/openEHR%20Foundation%20moving%20forward.pdf
...still needs some serious editing in order to better strengthen trust in
openEHRs future.

*1. First a procedural question:*
On Mon, Sep 5, 2011 at 03:00, Sam Heard (forwarded via Thomas Beale) wrote:
 I am writing on behalf of the new Transitional Board of openEHR to share
our
 plans to take openEHR to a new level of operations...

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? I know for sure that some
people in the acknowledgements...

 Acknowledgements: Thank you to David Ingram, Dipak Kalra, Thomas Beale,
 Martin van der Meer and Tony Shannon for assisting in the planning.

...would likely object to part of it's current content.

*2. A second procedural question:*
What is the mandate period of the transitional board? When will the
suggested new structure with an elected board start? That date seems to be
missing in the mail and in the document, but having an end date is very
likely important for building trust in any kind of stated interim governance
system (ask the people in the middle east and northern Africa...).

*3. A document content change suggestion:*
Remove the CC-BY-SA part in the licencing discussion (page 5) since it makes
the document authors and anybody ratifying it look incompetent. Saying that
original things are CC-BY and that derivative models should be CC-BY-SA is
just plain stupid. Then the originals are NOT CC-BY. It's just as silly as
saying that a piece of open source code is licenced under Apache II licence
but that any derivative code must be licenced under GPL...

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 save the openEHR community form patent abuse.

A more practical way is to enforce good licencing (e.g. CC-BY) upon import
of archetypes and archetyped data in real systems and tools. That will at
the same time protect against anybody sneaking in badly licenced stuff that
is not derived from openEHR original archetypes (something that a CC-BY-SA
scheme never will be able to protect against.)

There are many other interesting things to discuss and clarify in the white
paper, but let's start here :-)

Again, thanks for working towards a more understandable openEHR foundation.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110905/bcfa284f/attachment.html

Archetype versioning on CKM

[Erik Sundvall]

Hi!

I came to think of this openEHR versioning discussion thread when I
read about the Semantic Versioning initiative at http://semver.org/

I think the reasoning there is very appropriate also for openEHR artifacts.

The problem for openEHR might be that there are so many seemingly
usable archetypes in the openEHR-hosted CKM that are neither modified
for a long time nor officially tagged as published. It is
understandable if it's tempting to start using them in real systems
already now. After all the alternative is to reinvent the wheel
locally and is that really better? Perhaps there should be a time
limit on how long artifacts in the CKM can stay at a version below
1.0.0?

Perhaps things would become easier if we break the link between an
artifact having published status (as in being CRB approved) and the
fact that an artifact has a version over 1.0.0. That way systems can
start using archetypes past 1.0.0 knowing that non-compatible changes
will have new major version numbers (irrespective of if they are
published or not).

Keeping approval badges like ARB published, NHS approved or WHO
2011 Certified separate from technical version numbers might be a
good idea anyway... (Example: the first ARB published version of
Archetype X might be 2.4.2 and the next time it's awarded an ARB
published badge again might be when the ARB has time to get around to
looking at version 2.8.4 or 7.8.9). Likely, agencies will want to
approve sets of artifacts on a regular basis like tagging a number of
mutually compatible archetypes and templates as NHS 2012-Q1
approved.

The reasoning under #3 at http://semver.org/ (regarding 1.0.0beta1 
1.0.0beta2  1.0.0.) might solve the draft problem discussed in this
openEHR thread previously. (Provided that beta versions etc. don't get
used/abused in live EHR systems.)

The Semantic Versioning specification formalism is also machine
processable in a nice way.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733



On Thu, Apr 28, 2011 at 13:41, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
 On 28/04/2011 02:07, Heather Leslie wrote:

 Hi everyone,

 I think you are missing some of the further complexity here. There is a
 definite need for differentiation between draft and published archetypes for
 which a version number alone is not enough.
 Currently we are talking only about v1 archetypes and how to manage them,
 and to a degree it makes sense. We certainly considered using v0.x for
 drafts but it doesn't solve the downstream problems - once a v1 archetype is
 published, the non-breaking revisions will become v1.1, 1.2 etc. No problem
 But when we make a breaking change it becomes v2 (or v3 or v4 or 125), but
 it needs to be clear that it is v2 *draft* initially and not v2 *published*
 until we have completed the neccessary collaborative reviews.

 There are two ways to look at this:

 A - 'draft' is only possible at the notional v0 or first version stage;
 after initial publication, it can't be used, since the archetype is now 'in
 the open'
 B - it is possible to go back to 'draft' status when the major version
 number is incremented on the basis that a new major version is a new
 archetype, and authors need to be able to go back into 'initial development'
 mode

 I can see arguments for both. What we need to decide on as a community is
 what rule we want here, and to stick to it. If we can decide that, we can
 document it and post it in a new draft of the identification specification.

 Diego's problem of knowing what archetype one is actually using is real and
 needs to be solved. CKM does track revision numbers, but they are not part
 of the version id, and you have to go into the revision history view to see
 them. However the above-mentioned identification draft spec indicates a
 system of referencing to do this such that an archetype whose id is
 currently shown as openEHR-EHR-EVALUATION.diagnosis.v1 would be referenced
 from data and / or software (i.e. in any operational context) as
 openEHR-EHR-EVALUATION.diagnosis.v1.29.0, or in the future with a namespace
 as well, i.e. org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29.0

 Note that in this system of identification, if the final part of the
 revision number is a '0', i.e. the '0' above in '1.29.0', it means that the
 archetype is published; if it is anything else it is draft or some other
 pre-release state (this corresponds with view B above). Changes in the
 lifecycle state of the archetype are assumed to always cause an increment in
 final number of the extended version id.

 A fuller idea of referencing archetypes from from data is described in this
 spec, exemplified by the following:

 se.skl.epj::openEHR-EHR-EVALUATION.genetic_diagnosis.v1.12,? -- some Swedish
 archetype
 org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29,?? -- its parent,
 the CKM diagnosis archetype
 org.openehr.ehr::openEHR-EHR-EVALUATION.problem.v2.4

Dual Model EHR implementation

[Erik Sundvall]

Hi!

When we have approached openEHR storage we have tried to keep use
cases separate and not solve everything with only one database
structure.

A simplified (perhaps naive) version of the reasoning:
1. If you want to access data as big chunks in a certain serialization
format (like openEHR COMPOSITIONs used in daily patient care), then
store them in such chunks (and index on fields relevant to your
retrieval needs).
2. If you want to access small data fields from huge amounts of EHRs
(like population wide statistics/epidemiology) then store them as such
small pieces.

OpenEHR's append-only (or never physically delete) principle
combined with it's clearly timestamped operations makes replication
between these databases easier. If the DB in use case 2 is not used
for entering data and if it can tolerate a few minutes lag-time behind
live EHRs (1.) then implementation is not that very hard.

Some more hints regarding our reasoning is available in the poster at:
http://www.imt.liu.se/~erisu/2010/EEE-Poster-multipage.pdf
A proper detailed paper is (still) in the works...

I suspect that if you would aim for a 1.5 in between 1 and 2 then
what you will get is exactly a compromise not optimal for any of the
above mentioned use cases. :-)

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733



On Mon, Jun 6, 2011 at 18:05, Ian McNicoll
Ian.McNicoll at oceaninformatics.com wrote:
 Hi Alberto,

 A few naive comments/questions from a clinical modelling perspective.

 The granularity of the archetypes is mostly determined by issues of
 clinical validity and reuseability, rather then performance. We do try
 to keep archetype tree structures as 'flat' as possible i.e remove
 unnecessary clusters, and some work needs to be done to revise some of
 the older draft CKM archetypes e.g the OBSERVATION.examination series
 in this regard. It would be interesting to know what you meant by the
 question - can you give some a couple of examples of more and less
 granular archetypes, from your perspective?

 We have recently been able to develop a high performance EHR using 80%
 CKM archetypes (or those of similar granularity/re-useability) with
 querying 100% via AQL. The key change we made to improve performance
 was to make sure that dates are well-supported by indexing e.g date
 recorded, Composition start_date, observation time etc. Most
 operational queries in a live EHR are time-based - e.g Chart of most
 recent results, Current admissions etc. OTOH many reporting style
 queries will be terminology-based i.e patients with diabetes, and I
 expect this is an area where specific indexing might help further. I
 know that UK GP systems which have traditional RDBMS type
 architectures have extensive indexing on diagnostic codes.Workflow
 indexing will also be important in other applications for tracking
 orders and resultant activities. This is a facility that Ocean is
 currently implementing in OceanEHR.

 So indexing on dates, diagnosis / procedure codes and workflow IDs is
 probably the key.

 You might find it helpful to speak to the HL7 RIMBAA community.
 Although starting from a very different RM, they are essentially
 facing a similar low-level engineering problem. (I will get killed by
 both communities for that statement!!).

 I am interested in your question re granularity - can you explain
 further what you were concerned about?

 Cheers,

 Ian


 Dr Ian McNicoll
 office +44 (0)1536 414 994
 ?? ? ? ? +44 (0)2032 392 970
 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 3 June 2011 13:27, Alberto Moreno Conde albertomorenoconde at gmail.com 
 wrote:
 Dear all,

 Within the Virgen del Rocio University Hospital we are analysing how to
 implement a EHR based on Dual Model Approach.? When we analysed direct
 implementation a database based on of either OpenEHR Reference Model? or ISO
 13606, we have detected that it could have slow performance . Given that we
 are concerned about this problem, we would like to know possible strategies
 have been identified by implementers in order to fasten the performance of
 storage and query.

 Also the granularity level is one open issue that impacts on the
 performance, I would like to know if the level of granularity of the
 archetypes contained within the OpenEHR CKM is able to satisfy the
 requirements of? an EHR with more than 1 million records.

 Kind Regards

 Alberto

 Alberto Moreno Conde
 GIT-Grupo de Innovaci?n Tecnol?gica
 Hospital Universitario Virgen del Roc?o
 Edif. Centro de Documentaci?n Cl?nica Avanzada
 Av. Manuel Siurot, s/n.
 C.P.: 41013 ???SEVILLA


 ___
 openEHR-technical mailing list
 openEHR-technical

openEHR artefact namespace identifiers

[Erik Sundvall]

Hi!

On Tue, Apr 5, 2011 at 17:51, Ian McNicoll
Ian.McNicoll at oceaninformatics.com wrote:
 artefact identification proposals
 at 
 http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf
...
 se.skl.epj::openEHR-EHR-EVALUATION.problem.v1

...Then discussions regarding UUIDs, OIDs etc followed in several messages

Is not the simplest thing to just use URIs [
http://en.wikipedia.org/wiki/Uniform_Resource_Identifier ], or even
better allowing non-latin characters by using IRIs [
http://tools.ietf.org/html/rfc3987 ]?

Then organizations can choose if they want to base IDs on
domain-names, UUIDs, OIDs or whatever that fits in a URI (which might
be a URN, see list at http://www.iana.org/assignments/urn-namespaces/
). Some archetype authoring organizations may like names with
semantics, some may not, so why enforce any of the views.

Now since metadata is going to be well defined inside the file, the
need for semantics in identifiers or file names is gone so the main
thing left is that we want a _unique_ string. URIs are supposed to be
unique.

Some URI-examples:
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
urn:oid:1.3.6.1.2.1.27
urn:lsid:chemacx.cambridgesoft.com:ACX:CAS967582:1
http://id.skl.se/openEHR/EHR-EVALUATION.problem.v1
http://schema.openehr.org/openEHR/EHR/EVALUATION/problem/v3
urn:nbn:se:liu:diva-38012

I see no point in enforcing usage of OIDs as suggested in some responses.

The idea of not changing the ID if/when transferring responsibility of
an archetype between authorities sounds very reasonable if the content
is unchanged.

When I visited Brazil, I noticed that the MLHIM project's development
version was using UUIDs for the artifacts (CCDs) that correspond to
what is called archetypes in openEHR.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

Use Archetypes and ADL file in Java

[Erik Sundvall]

Hi Alessandro!

What is it that you want to do in the thesis? If you tell us a bit
more about the goal it might be easier to give you some hints along
the way.

Is it a master thesis or some other kind of thesis? What is the time-span?

Good luck with getting into openEHR!

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

P.s. On my research page under Teaching
http://www.imt.liu.se/~erisu/#teaching you'll find links to some
master thesis projects that might have some useful introductory
chapters etc.

On Wed, Mar 30, 2011 at 11:09, Alessandro Fass
padiglionestation at gmail.com wrote:

 Pablo Pazos Gutierrez wrote:

 Hi Alessandro,

 ADL defines the structure of your clinical data, In practice, ADL defines
 an instance of the archetype object model (AOM), that instance is the one
 you can handle from java. But the clinical data values must be set on the
 reference information model (RM). So, you must have: an implementation of
 the AOM, an ADLParser that parses ADL to an instance of AOM, and an
 implementation of the RM, and processing the AOM you can create an empty
 instance of the RM (empty because you have no clinical data yet).

 Here you can find a project (my degree thesis) that implements openEHR,
 and can generate any clinical record (is Java based):
 http://code.google.com/p/open-ehr-gen-framework/downloads/list

 --
 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, 29 Mar 2011 06:24:25 -0700
 From: padiglionestation at gmail.com
 To: openehr-technical at openehr.org
 Subject: Use Archetypes and ADL file in Java


 Hi everybody I'm Alessandro OpenEhr is I'm working on for my thesis.For
 the
 moment I'm using java in the ADLParser file for the openEHR EHRS-.
 blood_pressure.-OBSERVATION v1.0 adl. I wanted to know, via java objects,
 how to handle this archetype in java and assign values, such as the
 systolic
 pressure. More generally, how can I access the OpenEhr archetypes in
 java?
 I attach the file that I have produced so far.

 ?Thank you for your attention, good job.

 Alessandro http://old.nabble.com/file/p31266646/Test_Archetype.java
 Test_Archetype.java
 --
 View this message in context:
 http://old.nabble.com/Use-Archetypes-and-ADL-file-in-Java-tp31266646p31266646.html
 Sent from the openehr-technical mailing list archive at Nabble.com.

 ___
 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


 Thanks for your reply and for the documents that I have passed.From what I
 understood ADL class represents an instance of AOM right?If you would like
 to know how I can map the archetype on an RM? Let me explain better: how ADL
 I openEHR-EHR-OBSERVATION. blood_pressure. v1. I like adl access its
 properties via the RM Observation? You can find some examples in this
 regard? I apologize but I am beginning with OpenEhr.




 --
 View this message in context: 
 http://old.nabble.com/Use-Archetypes-and-ADL-file-in-Java-tp31266646p31275301.html
 Sent from the openehr-technical mailing list archive at Nabble.com.


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

GUI stuff in AOM/ADL? (Was: future ADL-versions)

[Erik Sundvall]

Hi!

Yesterday I asked if anybody had any motivated objections to using the
openEHR template formalism as a layer to catch some GUI-hints/rules. I bring
it up again to get some response :-)

The point to have separate concerns in separate artifacts is often good.
Regarding GUI-hints it seems reasonable to not have them at the clinical
archetype level, and in some cases not at a first clinically focused
template level either. But, as we have discussed earlier, through
specialisation and/or inclusion it's possible to have several layers of
openEHR templates.

This means that ADL or some other serialisation format of the archetype
object model (that now will include templates) can be used for GUI-related
annotations and GUI-related logic in some form. Does anybody have concerns
or worries regarding this?

You could still have separate artifacts by splitting reusable clinical
modeling and use case specific GUI modeling in separate layers of
templates.

A nice thing with reusing the template formalism for catching GUI stuff is
that shared tools and understanding is already in place as opposed to
inventing some new purely GUI-related formalism. Also in some cases it's
likely that the same groups that are designing archetypes and clinically
focused templates will have knowledge of some use cases in which they know
what they'd want to happen on the GUI side. Then it would be nice to be able
to reuse people, tools, template governance repositories etc.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

P.s. (off topic)
I'm not sure it's always optimal to split everything into separate
artifacts, especially when it comes boundary problems like terminology
bindings. You could argue that the binding should be done in a separate
artifact that is neither part of archetypes nor part of terminologies, but
I'm not sure that would always make things better. Having the bindings in
the archetype forces the archetype authors to revise the bindings at the
same time as they revise an archetype and that might be good.

On the other hand you could argue that a SNOMED CT refset might be exactly
such a third artifact that can be used for managing bindings. But if you
would have three different groups maintaining archetypes, refsets and
terminology systems then you'd better keep them very well aware of each
other's actions...

On Wed, Mar 23, 2011 at 21:09, pablo pazos pazospablo at hotmail.com wrote:

  I agree with Thomas, in order to have a clean design we need to separate
 the concerns of our artifacts. If we have a solid base to our complete
 clinical data structures like Archetypes, we can define other upper layer
 artifacts to model rules, conditions, gui directives, etc.

 I like this approach because we can solve one problem at a time, instead of
 having a messy one-fits-all solution.


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110324/63e8fc42/attachment.html

future ADL-versions

[Erik Sundvall]

Hi!

On Wed, Mar 23, 2011 at 11:42, Seref Arikan 
serefarikan at kurumsalteknoloji.com wrote:

  I'll repeat it again, if someone is interested in
 developing a formalism using constraint based expressions of ADL, to
 model GUI/behaviour/etc, there is nothing wrong with that. Just do it
 out of the archetype, link that artefact to an archetype, and
 share/use it with the archetype. This way, everything stays clean, and
 everyone gets what they want


Just a clarifying double-check:
I assume you wouldn't mind GUI-hints etc in some template layer. Correct?
Since ADL can be used for both templates and archetypes it can be good to be
clarify.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110323/5cd9fe6e/attachment.html

XMI exchange of class models

[Erik Sundvall]

Hi all!

I am on a trip in Brazil to learn more about openEHR/13606/MLHIM-related
projects, actors and companies. At LNCC http://www.lncc.br/ we discussed
among other things EMF http://www.eclipse.org/modeling/emf/ versions of
openEHR models and then I realized there was an off-list discussion that
some of us had and intended to move to the tech-list but obviously forgot
to. Below you find a slightly shortened version of the discussion.

Feel free to join in.

If I understood things right LNCC has experimented with creation of EMF
models from openEHR XML schemas or something similar.

Some partly related info on the openEHR wiki:
http://www.openehr.org/wiki/display/dev/Experimental+generation+of+code+and+documentation+from+UML
( or as short URL: http://www.openehr.org/wiki/x/OwAt )

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733


Forwarded conversation
Subject: XMI exchange of class models


From: *Eric Browne* eric.bro...@montagesystems.com.au
Date: Wed, Oct 13, 2010 at 01:56
To: Erik Sundvall erisu at imt.liu.se
Cc: Thomas Beale thomas.beale at oceaninformatics.com

Hi Erik,

I don't know if you still have an interest in this, but I've just stumbled
on this recent Masters Thesis by Stefan Teijgeler that may be of use.

There's a section devoted to examining the import/export/exchange capability
of various UML modelling tools. Results are pretty depressing, and there's
not a huge amount of analysis as to the reasons for incompatibilities.

fmt.cs.utwente.nl/msc-completed/teijgeler.pdf

regards,
eric

--
From: *Erik Sundvall* erik.sundv...@liu.se
Date: Wed, Oct 13, 2010 at 07:55
To: Eric Browne Eric.Browne at montagesystems.com.au
Cc: Thomas Beale thomas.beale at oceaninformatics.com, Tim Cook 
timothywayne.cook at gmail.com

Hi!
 http://fmt.cs.utwente.nl/msc-completed/teijgeler.pdf

Thanks for the info Eric. Had a quick look and I come to the same
summary as you do.

So that probably means: if using Eclipse-based tools it's better to go
directly for an ecore model than trying to be UML/XMI-centric when
modelling.

My impression is also that generics is a lot easier in ecore than
UML/XMI (see e.g.
http://eclipse.dzone.com/articles/generics-eclipse-modelling-fra). The
quote the UML representation is verbose and intricate in comparison
to Ecore or Java. from
http://www.eclipse.org/articles/article.php?file=Article-Defining-Generics-with-UML-Templates/index.html
also indicates ecore might be easier than UML for generics modelling.

There seems to be a default ecore to XMI serialisation mechanism if we
need XMI output, but it's just one (probably incompatible) dialect of
XMI if Teijgeler's thesis is correct.

I believe it would not be too hard to convert between ecore and Tom's
DADL-formalisation of the RM. Perhaps the same thing is possible for
your formalisation Eric?

Whatever we do, one interesting question is probably who will be doing
RM modelling for specification updates and what tools will they
prefer. After answering that I believe it would be useful to create an
automated conversion path from that preferred format to at least ecore
(unless ecore is the preferred editing format of course).

Could you, Eric and Tom, bring up the issue (of determining at least
one formal machine readable RM-specification format) in the openEHR
Architecture Review Board? It might also be a good idea to bring up on
the openEHR technical list, is it OK that I forward parts of this
conversation to the list?

Link list:
EMF/ecore: http://www.eclipse.org/modeling/emf/?project=emf
Acceleo, model to Java/Python/C++/C#/php etc conversion:
http://www.acceleo.org/pages/home/en
A textual form of ecore: http://wiki.eclipse.org/Emfatic
Topcased, UML-ish graphical model editing: http://www.topcased.org/

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

--
From: *Thomas Beale* thomas.be...@oceaninformatics.com
Date: Wed, Oct 13, 2010 at 08:45
To: Erik Sundvall erik.sundvall at liu.se
Cc: Eric Browne Eric.Browne at montagesystems.com.au, Tim Cook 
timothywayne.cook at gmail.com, Seref Arikan 
serefarikan at kurumsalteknoloji.com

 All,

Seref and I have had a look at this issue, and came to exactly the same
conclusion. I even bought the EMF book. It is depressingly weak in formal
terms, and generics are dealt with in an appendix or final chapter from
memory, where a reworked EMF core model is shown. Their modelling is quite
bad, it is really amazing for me to see books promulgating such poor models,
but at least it is there, it has generics, and AFAIK, it does work, since
there are quite a lot of people using it now. In situations where I have to
recommend some tool basis for doing a 'modelling stack' for e-health, EMF
(despite the above comments) is the only thing I am able to suggest. One aim
we have is to get openEHR fully represented in EMF, and quite frankly if we
have to rewrite

Representing binary values with DV_BOOLEAN

[Erik Sundvall]

Hi!

On Wed, Feb 9, 2011 at 19:03, Ian McNicoll
Ian.McNicoll at oceaninformatics.com wrote:
 I very rarely now use DV_BOOLEAN when modelling but agree that using
 DV_TEXT/CODE_TEXT is a pain to map to a checkbox/radiobutton GUI.

Unless you reduce that mapping pain by having nice
GUI-hints/directives with documented semantics that you can use
(primarily in templates) to indicate that this DV_CODED_TEXT should be
presented as a radio-button-style group or checkbox (possibly with
default).

Good GUI-hints combined with logic machinery could also be used to
open follow-up questions if desired as previously discussed in the
thread named Re: GUI-directives/hints again (Was: Developing usable
GUIs) where on Mon, Dec 20, 2010 at 13:05, Erik Sundvall
erik.sundvall at liu.se wrote:

 Discussion examples follow (with the risk of ADL errors that Tom's
 brain-integrated ADL parser :-) will catch and he then can correct)

 In section 6.5.4 of
 http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf
 a way of defining variables is specified.
 Perhaps a (preferably Boolean) variable could be defined as an
 archetype rule like...

 $smoker:BOOLEAN ::=
 /data/items[at0003.7]/items[at0009.3]/value/defining_code matches
 local::at0013

 ...and an annotation on a tree structure that should be shown in GUIs
 only when documenting smokers could be...

 annotations = 
  [/data/items[at0003.7]/items[at0010]] = 
items = 
  [GUI-show-if] = $smoker  -- Other annotation name
 examples: GUI-hide-if ...
  [some other annotation] = whatever

 ...or perhaps...

 annotations = 
  [/data/items[at0003.7]/items[at0010]] = 
items = 
  [GUI-trigger] = $smoker
  [GUI-action] = show -- Other annotation value examples:
 hide, collapse, expand
  [some other annotation] = whatever


Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

Representing binary values with DV_BOOLEAN

[Erik Sundvall]

Hi!

Good points from both of you, I just want to add a thought.

When designing or locally adapting GUIs I think it can be valuable to
have the option to use radio-buttons (or widgets with similar
visibility and semantics) also for DV_CODED_TEXT items if you know
that the number of options are small and will suitably fit on screen.
That will increase the up-front visibility of options and save time
during data entry compared to opening and selecting from a combobox
(or some other widget with similar interaction semantics).

So having a GUI-directive/hint for suggesting radio-button interaction
style for some DV_CODED_TEXT fields might actually be a good and
useful thing.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733



On Wed, Feb 2, 2011 at 04:27, Diego Bosc? yampeku at gmail.com wrote:
 Is much different to change the field from 'test
 result:positive/negative' to 'test result positive:true/false'?
 If the semantics if not the same then the 'positive/negative' has more
 meaning that a simple boolean and I think they should be coded

 2011/2/2 Koray Atalag k.atalag at auckland.ac.nz:
 Hi All, I?d like to get feedback on this issue before we move on with
 implementing.

 In short whether we should use DV_BOOLEAN to represent the result of a Lab
 test as Positive/Negative. This particular test can have only two values
 (well plus the null case of course). I suspect this wasn?t the purpose of
 this data type in the first place and was for really no-brainer yes/no items
 as you would expect in any computer program. But, as ever, clinical medicine
 is wicked and makes me think out of the ?usual? good practice and explore
 whether this might be an option?Perhaps this discussion will provide
 guidance for others in the community as well.

 Secondly (assuming that we can use DV_BOOLEAN for such cases) in GUI not all
 occurrences of Boolean will have labels as Yes/No?It can also be True/False,
 Present/Absent, Positive/Negative etc. Moreover in difference language
 translations they will surely be different. But in ADL no at code is given
 for this data type; Yes and No is written implicitly within the definition
 section. This means that we cannot set the Text in ontology section and then
 have language translations. Has anyone come across such a requirement? If so
 what?s your solution.

 Note that I currently model all such data items with DV_CODED_TEXT and had
 no problems. But when I wanted to render radio buttons for Yes/No type items
 instead of default combobox widget I either need a GUI directive (which we
 try to avoid if possible) or set the data type to DV_BOOLEAN so that the
 default widget would be radio button and we can use accordingly.

 Cheers,



 -koray



 ___
 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

Archetype Template ANNOTATIONS - requirements?

[Erik Sundvall]

Hi!

On Tue, Jan 4, 2011 at 02:07, Heath Frankel 
heath.frankel at oceaninformatics.com wrote:

  Hi Tom and Erik,



 that's two innovative ideas in one post - you must have had a great
 christmas ;-)
 1. in the 'languages' space, allow formalisms as well - e.g. rdf
 2. the annotation structure, simple as it is, is in fact sufficient (or
 close) to support representation of RDF-like triples.

  *[HKF: ] I think we are overloading the use of the annotations for two
 different purposes and should look at the distinction made in XML Schema
 where they have documentation and appinfo, where the former is used by
 humans and the later by applications for things such as GUI directives.*


Overloading or not, the technical structure would be very similar. I don't
think the border between data for human and machine use always will be
completely clear. You might want to annotate information intended mostly for
human consumption (i.e. documentation) by using a small ontology
constraining allowed values under certain field names. Tools can in such
cases easily show localized human language labels from ontologies instead of
the URIs (owl ontologies have multilingual support).

However if there are strong reasons to split documentation and appinfo
at root level rather than with the language in the annotation section,
then of course that would be OK. The main thing is that we need a good place
to experiment with some formalized machine readable annotations (or appinfo
if you prefer to call it that).

Using RDF-ideas to make connections out from archetypes and templates to
RDF/RDFS/OWL entities might open many possibilities.

While we are at it, what bout the other way around? Is there an official
algorithm to convert an archetype/template-node to a URI (perhaps a URN)
that can be used to reference archetypes and archetype nodes in semantic web
formalisms? If not, then perhaps we should create one (in a separate
discussion thread perhaps). I think we have a lot of owl wizards reading
this, don't be afraid to dive in to the discussion.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
**
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110104/0de19c40/attachment.html

Archetype Template ANNOTATIONS - requirements?

[Erik Sundvall]

Hi!

Regarding annotations for GUI hints...

On Sun, Jan 2, 2011 at 20:41, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:
 I still think this requirement is best solved by a design pattern that is
 defined and that tools can trust - one that fits with the current
reference
 model.

What about a design pattern borrowed from RDF, where
1. the annotated archetype node has the same role as a RDF subject, and
2. URIs are used as predicate (relationship type - the left hand part of the
ADL annotation) and
3. URIs or RDF data types (including strings, numbers, booleans etc) are
used as objects (targets/values - the right hand part of the ADL
annotation).

Such annotations would be intended for (human language-independent) machine
processing, perhaps that is not really the current intention behind the
human language-dependent annotation sections in archetypes.

Using RDF-like notations would make it fairly easy to start with just plain
string matching in tools and then extend tooling support by using available
RDF or OWL toolkits to check e.g. allowed range for certain predicates
against e.g. a small GUI ontology.

Technically the approach would of course not be limited to GUI usage, but
could be used for many kinds of machine processable annotations (see example
further down).

Would it be possible to extend the language annotation group subdivisions
to not only allow language codes, but also include a set of additional codes
for machine processable formalisms where e.g. RDF could be one?

Some may argue that the Term_binding and Constraint_binding are more
appropriate places for connecting to ontologies - the difference from the
annotation approach is that the current *_binding design only allows
specification of a value not an annotation/predicate type. Using a design
pattern for annotations won't introduce changes to the underlying model.

In the thread GUI-directives/hints again we had a hypothetical example...

annotations = 
[/data/items[at0003.7]/items[at0010]] = 
  items = 
[GUI-show-if] = $smoker -- Other annotation name examples:
GUI-hide-if ...
[some other annotation] = whatever

...with RDF-like annotations, some additional examples (and a wildly guessed
language subsection syntax) it might turn out something like...

annotations = 
language = 
  [RDF] = 
[/data/items[at0003.7]/items[at0010]] = 
   items = 
 [http://schema.openehr.org/GUI-v0_1#show-if;] = $smoker
[/data/items[at0004.8]/items[at0011]] = 
   items = 
 [http://schema.openehr.org/GUI-v0_1#view;] = 
http://schema.openehr.org/GUI-v0_1#pass_through;
 [http://s.skl.se/qualreg/diab/v-3_1#q10.2;] = 
http://s.skl.se/qualreg/diab/v-3_1#daily;
...

 [en-UK] = 
   [/data/items[at0003.7]/items[at0010]] = 
   [some other annotation] = whatever

Perhaps the distributed nature of URIs (e.g. s.skl.se above) also covers the
organisation sections requirement mentioned by Sam?

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110103/84f42c85/attachment.html

GUI-directives/hints again (Was: Developing usable GUIs)

[Erik Sundvall]

Hi!

On Wed, Dec 15, 2010 at 00:30, Thomas Beale
thomas.beale at oceaninformatics.com?wrote:
 On 10/12/2010 08:49, Erik Sundvall wrote:
 If the already present annotation mechanism in templates is powerful enough 
 (Do you think it is, Koray,?Pablo and others?)

 to be clear, do you mean the annotations documented in the ADL 1.5 draft 
 document? I.e. the new annotations section?

Yes, I was then thinking of section 9.8 in
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf

When looking closer at this for GUI hint experimentation, perhaps we
could instead use a combination of annotations and the assertion/rule
mechanisms in ADL/AOM? The already present logic in the assertions
mechanism is probably enough to define e.g. Boolean trigger variables.
Annotations could then be used to let GUIs know what to do/show/hide
based on those triggers.

Discussion examples follow (with the risk of ADL errors that Tom's
brain-integrated ADL parser :-) will catch and he then can correct)

In section?6.5.4 of
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf
a way of defining variables is specified.
Perhaps a (preferably Boolean) variable could be defined as an
archetype rule like...

$smoker:BOOLEAN ::=
/data/items[at0003.7]/items[at0009.3]/value/defining_code matches
local::at0013

...and an annotation on a tree structure that should be shown in GUIs
only when documenting smokers could be...

annotations = 
 [/data/items[at0003.7]/items[at0010]] = 
items = 
  [GUI-show-if] = $smoker  -- Other annotation name
examples: GUI-hide-if ...
  [some other annotation] = whatever

...or perhaps...

annotations = 
 [/data/items[at0003.7]/items[at0010]] = 
items = 
  [GUI-trigger] = $smoker
  [GUI-action] = show -- Other annotation value examples:
hide, collapse, expand
  [some other annotation] = whatever

I guess the mess starts if such annotations are to be overridden in
yet a specialization generation of the GUI-annotated
template/archetype. That would have to be analyzed further, but maybe
some refined variant of the examples above could be a useful start in
the mean time?

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

 On Wed, Dec 8, 2010 at 15:55, Thomas Beale?thomas.beale at 
 oceaninformatics.com?wrote:
 you have two choices:

 A) mix it in with the languages  architectural layers you already have
 B) create a dedicated layer or component type, and possibly dedicated 
 formalism if needed

Erik Sundvall wrote:
 I believe there is (as usual) a context dependent gray-zone, not a clear 
 breakpoint, regarding what annotations would be most useful to have in which 
 layer. So, yes I agree layers are good for separation of concerns, but it is 
 not always (at least not at an early stage) easy to forsee exactly what best 
 fits into each layer and how many layers there should be.

Thomas Beale wrote:
 I agree - we don't yet have a clear list of the GUi semantics that would need 
 to be in a UI template...

GUI-directives/hints again (Was: Developing usable GUIs)

[Erik Sundvall]

Hi!

A very interesting discussion, thanks to everybody here! Great with all
references too!

On Wed, Dec 8, 2010 at 16:26, pablo pazos pazospablo at hotmail.com wrote:

 Maybe if we change the terminology to GUI Templates and openEHR Templates,
 we will not have these problems.


Or perhaps GUI focused templates and Structurally focused templates
(since both will be openEHR based).

Correct me if I'm wrong:
If templates can specialize templates in several generations of
inheritance/specialisation (This is the case, right?), then we could use the
same basic annotation formalism for different purposes in different layers,
only the annotation names would be different.

So an example inheritance/specialisation hierarchy in a running system could
be:

A bunch of clinical archetypes (mostly international, and some regional
ones)
...are used as building blocks in...

a structural template (maybe national/regional) often creating a composite
SECTION or COMPOSITION

[add more structural layers if useful]

...that is then annotated with GUI-hints by...
a set of GUI templates with each template fitting a different recurring
use case

...for a specific GUI, the most fitting of those GUI templates is then
picked and might be further annotated/specialized with yet another template
layer or used directly as input to GUI-generation or GUI-building tools


On Wed, Dec 8, 2010 at 15:55, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:

 you have two choices:

- A) mix it in with the languages  architectural layers you already
have
- B) create a dedicated layer or component type, and possibly dedicated
formalism if needed

 I believe there is (as usual) a context dependent gray-zone, not a clear
breakpoint, regarding what annotations would be most useful to have in which
layer. So, yes I agree layers are good for separation of concerns, but it is
not always (at least not at an early stage) easy to forsee exactly what best
fits into each layer and how many layers there should be.

If the already present annotation mechanism in templates is powerful enough
(Do you think it is, Koray, Pablo and others?) and if could be reused also
for GUI-stuff instead of creating another different formalism, then we
should take a close look at that option before thinking of specifying
another mechanism for GUI-concerns. You'd still get layers (if you sensibly
use specialisation) but more flexible boundaries during the needed upcoming
period of collaborative experimentation and real use.

On Mon, Dec 6, 2010 at 22:06, Koray Atalag k.atalag at auckland.ac.nz wrote:

 I think having these discussions is a great start. But it'd be great if
 someone from the core group 'owns' this thread and puts some pressure on us.


Koray, what makes you exclude yourself from the core group? Shouldn't
openEHR be a community with peers trying to solve common problems, where
people like you with specific implementation experience can help
collaboratively lead a specific exploration tangents at least as well as
some official core that is busy prioritizing other important explorations.
Whatever that core is I believe it will be actively involved in, and
appreciate, the discussions.

You already own the problem together with others owning the same problem.
I think openEHR should be a platform to facilitate collective ownership of
problem solving processes and solutions.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101210/9d6bfbd1/attachment.html

REST Based Services and Storage Interfaces for openEHR Implementations

[Erik Sundvall]

Hi Gavin!

Thanks for your comments!.

 On 26/11/2010 16:48, Erik Sundvall wrote:
 http://www.imt.liu.se/~erisu/2010/EEE-Poster-multipage.pdf

On Sat, Nov 27, 2010 at 17:36, gjb gjb at crs4.it wrote:
 I've been experimenting with the eXist.org DB that lets you GET and PUT
 (and version) hierarchical records (XML) RESTfully to  from the browser
 without any intervening layer (unlike PHP etc).

We have also been using eXist as one of the (so far three) tested
configurable XML databases in LiU EEE. We want to make sure that EEE
is not too tightly to any particular database solution, since the best
choice will differ depending on e.g. your major usecases, system
environment and load.

 It works well for my non EHR web-app - that uses jQuery to tame
 my in-browser code.

We assume that jQuery will be one of many options that people will use
for building GUIs connected to the Contribution builder resource
that you see in the poster. GWT with added restlet support is another
interesting option, so is Flash/Flex or any other http-speaking GUI
framework. A nice thing with the web is that you can mix and integrate
many of them in the same GUI if you want to reuse other people's
implementations. One of the intentions of having a separate
Contribution builder resource is to make it even easier.

 It probably not industrial-strength but the eXist way has plenty of
 standards based ways of getting things done
 - including xQuery pipelines incorporating user specified Java modules.

xQuery is what we currently translate AQL queries to before they are
executed in eXist or other xQuery-enabled databases (like e.g. Sedna
[1], BaseX [2] or Oracle's XML products). xQuery's semantics seems
powerful enough to cover what we need from the AQL semantics. But
again, we don't limit EEE to xQuery and XML databases, it was just a
convenient start and a reasonable option for the use case where you
from e.g. web browsers often want to access entire openEHR
COMPOSITIONS serialised as XML via http. For advanced population-wide
queries we believe other database backend solutions will be
preferable, but we have aimed for a design where the same basic REST
interface can be reused by such clients.

 could be something to consider.

See above :-)

 BTW I doubt there's much usage for HTTP DELETE for audited EHR.

 Gavin Brelstaff

I agree that DELETE will not be used on the committed Contribution
or Versioned object resources you see in the poster - if that is
tried then a http 405 Method Not Allowed [3] error will be returned.

The Contribution builder resource on the other hand _does_ allow
HTTP DELETE since it is considered a personal temporary writing space
where you might e.g. select the wrong forms/templates and want to
correct that immediately while you are documenting, before you have
committed.

Note that openEHR does allow committing unfinished work however, e.g.
when you have to rush of to another patient but what want to commit
what has been documented so far. Such commits can be flagged as
incomplete but are available as proper Versioned objects that can't
be deleted, but rather updated to new more complete versions when
there is time continue. Thus the design intention of Countribution
builder is not to store incomplete data for long periods, only to act
as a well specified interoperable writing space while actively
composing.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

References
1. http://www.modis.ispras.ru/sedna/
2. http://www.inf.uni-konstanz.de/dbis/basex/
3. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6

REST Based Services and Storage Interfaces for openEHR Implementations

[Erik Sundvall]

Hi all!

We had a poster titled REST Based Services and Storage Interfaces for
openEHR Implementations at a Swedish conference in September. I have
now finally gotten around to reformatting it to be readable when read
on screen or printed as a three-page booklet on normally sized (A4)
paper. It is available at:
http://www.imt.liu.se/~erisu/2010/EEE-Poster-multipage.pdf
Some of you have already heard these ideas at Medinfo in Capetown.

Questions and discussions are very welcome (preferably on the
technical list, not the clinical one that I am cross posting this
announcement to). We are now in the process of writing a proper paper
about this and will of course release our implementation as open
source.

The most interesting thing about all this is probably not our
particular implementation, but rather the approach of slicing the
openEHR system implementation elephant into smaller pieces so that
different people and projects can focus on smaller parts like GUI,
storage or decision support. As long as the building blocks can speak
http they can be connected no matter what language or platform they
are implemented in.

Our hope is that this could lead to interoperability _within_ openEHR
systems made by parts from different actors, in addition to the
current interoperability _between_ openEHR systems.

I also wonder if there are others that would be interested in helping
out writing an openEHR ITS (Implementation technology specification)
for openEHR service model via REST (after the proper paper is
finished... need to focus...). The ITS should preferably be tested in
several different systems before being considered finished - no good
specification without at least two independent interoperable
implementations.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

Why is OpenEHR adoption so slow?

[Erik Sundvall]

Hi!

 On 16/11/2010 12:44, Tim Cook wrote:
 Democratizing innovation / Eric von Hippel. ISBN 0-262-00274-4

On Wed, Nov 17, 2010 at 16:51, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
 this is an interesting looking book, I downloaded it.
 However, as I and I imagine others won't get through 220 pages instantly,
 do you want to summarise what you see as the lessons from it,
while this discussion is still warm?

The first chapter, 17 pages of easily-read book text, actually seems
to be a summary of the book, offered by the author.
Chapter 1 pdf: http://web.mit.edu/evhippel/www/books/DI/Chapter1.pdf

Under the title Users? Innovate-or-Buy Decisions on page 6 in the
chapter-pdf above one gets some hints regarding agent costs that
might explain why most apache-hosted project contributors are working
at real user-companies and are not agents for the end users funded
by the foundation.

Regarding the need for funded development, I think there is a
misunderstanding in this list discussion - I don't think anybody has
said that developers don't need funding for a project at the scale of
openEHR, neither has anybody said that full-time position for
developers would be bad. The underlying issue is rather
future-proofing the role of a foundation in this puzzle in order to
allow larger entities to trust it and a proper community thinking to
evolve. I won't go into details over again but you can probably get
some hints by re-reading the discussion and the links with this in
mind.

On Wed, Nov 17, 2010 at 23:19, Seref Arikan
serefarikan at kurumsalteknoloji.com wrote:
 I personally see this big bootstrapping requirement as a unique problem of
 this domain [...]

Seref, calling it a bootstrapping problem was a good way to put it,
I think it (for techies at least) describes the present openEHR
situation in an excellent way.

If e.g. IHTSDO now has seen this problem and wants to help out with
the initial bootstrapping, then perhaps they can temporarily
themselves employ people like Tom for a while to work on open source
tooling and documentation according to IHTSDOs requirements and at the
same time inspire the foundation to transition into a more open and
sustainable form in order to survive the changed requirements that
will likely become even more apparent when the bootstrapping phase is
over. I don't know if that's what the openEHR-IHTSDO talks are about,
they seem to be pretty secret and cut of from any community
discussion.

Back to the book, links to all chapters and the entire book:
http://web.mit.edu/evhippel/www/democ1.htm

What I have read so far is very interesting, and it seems to avoid
becoming yet another political pamphlet, rather it seems to be a
theoretical framework based on empirical findings, so thanks for the
book recommendation. I think the openEHR approach in the long run can
inspire and allow a lot of end user innovation (as described in the
book) without loosing interoperability and transcending into total
chaos.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

Why is OpenEHR adoption so slow?

[Erik Sundvall]

 the licence of the
archetypes to CC-BY rather than the current infectious CC-BY-SA. See:
http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal

With CC-BY the big players (NHS et al) can let their clinicians
cooperate in global archetype development on paid time, and they won't
have to even bother about the potential risk that the hard to grip
openEHR-foundation central decision process does anything stupid to
lock in their invested work. They can leave whenever they please and
take a copy of their invested work with them. That freedom then
becomes a reason to actually stay. (Even Google knows this, see
http://www.dataliberation.org/ )

I think the openEHR foundation board still has miserably failed to
communicate their reasons for stopping or delaying a licence change of
openEHR hosted archetypes from CC-BY-SA to CC-BY. Some of us have
seriously started discussing archetyping of data sent from medical
devices, including proprietary ones. Should device people come begging
the foundation to liberate certain archetypes from the SA bondage
every time they find use for one (and how long would that take) or
would they be forced to go the anti-interoperable way and start
archetyping such things from scratch in a track separate from the
openEHR CKM archetypes?

I have even heard people say that copyright issues is a potential
reason not to use international openEHR hosted archetypes as a basis
for national eHealth work. Why not simply eliminate such an argument
with CC-BY?

Couldn't somebody else than Sam from the foundation board try to
explain their reasoning this time to see if they can explain better?

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)

[Erik Sundvall]

Hi Zam! :-)

I was merely trying to keep most of the same semantic power in the
change suggestion as when the abstract ITEM_STRUCTURE (that subsumed
ITEM_SINGLE, ITEM_TREE etc) was used rather than ITEM_TREE in various
places in the RM model. But you might be completely correct that it
would be better to point to CLUSTER rather than it's abstract
superclass ITEM in some or perhaps even all places in the model where
ITEM_STRUCTURE is used today. I guess other people on the list will
have additional good ideas about this.

Did you have any more info (or link) regarding the pivot
semantics/requirements by the way?

Best regards,
Erik(!) Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

On Mon, Nov 15, 2010 at 22:29, Sam Heard sam.heard at oceaninformatics.com 
wrote:
 Hi Eric

 I would always use CLUSTER rather than ITEM for the data and other features
 in other classes. The alternative is to have far more versions of archetypes
 as if you allow element at this point you have to version when cluster is
 necessary (which you could argue it always will be at some time in the
 future).

 Cheers, Sam

openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)

[Erik Sundvall]

 the ones in
ITEM_TABLE can be moved out from the core to some optional
utility-package instead (if the need for having them standardised
remains). If looking outside the item_structure package this actually
already seems to be the case - there are pretty few methods. Good.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

P.s. Tim, I'd be interested how these changes suggestions, in your
wiew, relate to Keep everything as simple as possible; but no
simpler. that you qoute on the philosophy part of
http://www.oship.org/

On Thu, Nov 11, 2010 at 00:22, Sam Heard sam.heard at oceaninformatics.com 
wrote:
 ...
 1. Restrict a cluster to a list; and
 2. Create a consistent representation of tables which have allow pivots as
 this is the main form required for clinical data (row headings and column
 headings).

 I believe that in the interests of existing data we made DATA_STRUCTURE
 inherit from CLUSTER - maintain LIST and TABLE as openEHR classes and
 deprecate TREE and SINGLE. This would keep things moving ahead. The data
 attribute would then be a cluster rather than an item_structure.