WARNING: This server is unstable and will be retired in the next days. If you want to keep this forum available, please request immediately a migration on the Nabble Support forum. Forums that don't receive any migration request will be deleted forever.

 « Return to Thread: RE: openEHR-technical Digest, Vol 67, Issue 34

RE: openEHR-technical Digest, Vol 67, Issue 34

by William Goossen :: Rate this Message:

| View in Thread

Ar this stage membership is open to anyone for both HL7 and OpenEHR. Hence they are both open. Difference is that HL7 is an SDO and OpenEHR a community. But yes both have their copyright approaches. I have not gone through each of them in detail. But as a user of both platforms it does not make a difference, in contrast to what Heath said.

William

Van: Seref Arikan
Verzonden: 21-2-2012 0:02
Aan: wgoossen@...; For openEHR technical discussions
Onderwerp: Re: openEHR-technical Digest, Vol 67, Issue 34

Hi William,
You've got me confused a bit.

From the http://www.hl7.org/legal/ippolicy.cfm :

"...

This authorization is provided only during the years when the appropriate HL7 Organizational Membership dues are paid, and if and only if:

  1. HL7 is clearly identified as publisher and holder of the copyright; and,...."

So if openEHR is proprietary because the foundation is holding the copyright, is not HL7 the same according to the statement above?

Kind regards
Seref



On Mon, Feb 20, 2012 at 10:34 PM, William Goossen <wgoossen@...> wrote:
Hi Heath, Thomas,

My experience is that HL7 v3 is an open standard and OpenEHR is proprietary
(as owned by the OpenEHR foundation holding the copyrights, albeit I
understand that work is underway to sort that out).

William

-----Original Message-----
From: openehr-technical-bounces@...
[mailto:openehr-technical-bounces@...] On Behalf Of
openehr-technical-request@...
Sent: maandag 20 februari 2012 23:25
To: openehr-technical@...
Subject: openEHR-technical Digest, Vol 67, Issue 34

Send openEHR-technical mailing list submissions to
       openehr-technical@...

To subscribe or unsubscribe via the World Wide Web, visit
       http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
or, via email, send a message with subject or body 'help' to
       openehr-technical-request@...

You can reach the person managing the list at
       openehr-technical-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openEHR-technical digest..."


Today's Topics:

  1. RE: Meaningful Use and Beyond - O'Reilly press - errata
     (Koray Atalag)
  2. RE: openEHR - Persistence of Data (Heath Frankel)


----------------------------------------------------------------------

Message: 1
Date: Mon, 20 Feb 2012 21:58:33 +0000
From: Koray Atalag <k.atalag@...>
Subject: RE: Meaningful Use and Beyond - O'Reilly press - errata
To: For openEHR technical discussions <openehr-technical@...>
Message-ID:

<B1CE708E5C614F4BB990E32CC5F03AD41F690A10@...>
Content-Type: text/plain; charset="us-ascii"

Hi Fred,

Apropos to Tom I'd say openEHR is also equally to do with software
maintainability; thanks to the dual or multi-level modelling and model
driven development. This is my main research area as well as open source
software. I agree with Tom's comments that being open source by itself is
not enough (for any software quality aspect I believe) and must be
accompanied with open standards. If I was asked to explain openEHR to my
mother I'd probably say: 'it is about getting information right in
healthcare'. I usually find this statement as the starting point when
talking to other audiences such as computer scientists and developers.
Perhaps you'll find useful as well.

Cheers,

-koray


From: openehr-technical-bounces@...
[mailto:openehr-technical-bounces@...] On Behalf Of fred trotter
Sent: Saturday, 18 February 2012 1:27 p.m.
To: For openEHR technical discussions
Subject: Re: Meaningful Use and Beyond - O'Reilly press - errata

Thomas,
            This is quit usable critique and I will certainly draw from it
in future revisions of the work.

You make the argument that OpenEHR is primarily for interoperability, and I
can accept that fundamental argument. It is difficult to swallow however,
when I hear the HL7 v3 wonks talking about how HL7 RIM is the solution to
semantic interoperability. Are they confused or are you confused, because
you are saying basically the same thing. From my perspective as in
implementer it looks awefully like a blueray vs HDDVD war and it looks like
OpenEHR is losing. But at the same time I keep hearing that HL7 RIM is
"compatible" with and might be "merged" with HL7 RIM.

Very confusing, and I have yet to see something compelling that can be done
in OpenEHR that cannot be done with HL7 RIM.

Having said that, HL7 RIM is a proprietary ontology/model and OpenEHR, is
not. That gives OpenEHR some usefulness even as an alternative model. Is
that where I should see the value? Here is an information model that
delivers semantic interoperability but is not proprietary?


On Fri, Feb 17, 2012 at 6:15 AM, Thomas Beale
<thomas.beale@...<mailto:thomas.beale@...>
> wrote:

Hi Fred,

I think you are missing the point. The key thing we are working on in
openEHR is interoperability, not open source. Open source health
applications have historically not made any difference to interoperability,
intelligent computing or anything else - they are the same as closed source
systems that don't do any of these things. This is not to say that they
aren't better quality software / solutions in other ways - some are very
nice. But in general they have the same proprietary data formats and service
interfaces as commercial solutions (making such definitions openly available
doesn't change anything).

Solving interoperability and intelligence in e-health (as for other domains)
is very hard indeed, and solutions based on simple approaches only have
marginal benefit. What matters to clinical people and actual health delivery
is interoperability, regardless of closed or open source: open standardised
(= widely agreed) information models, service interfaces and knowledge
formalisms. Of course open source, done the right way does have a lot to
offer, and can make the economics better, but it doesn't specifically
address the interoperability problem.

What I think you will see in the future is intelligent health computing
platforms based on openEHR, or something like it (as you noted, Tolven also
does not have much penetration today, but it also is a sophisticated
solution that takes semantic interoperability seriously). See the CIMI
forum<http://informatics.mayo.edu/CIMI/index.php/London_2011> to get some
idea of the international backing for knowledge-driven architecture. Without
these kind of model-driven architectures, semantic interoperability will
remain a dream, as will any serious industry around decision support,
business intelligence and data-based medical research, and any other
application wanting to use computable patient-centred health data. Because
of the time it has taken to mature the openEHR - and other related, and even
competing - health computing platforms, solutions based on these platforms
are only just starting to make serious inroads.

I have no problem with your view of openEHR in terms of limited penetration
(today), but what I think would be a little more positive would be for the
open source sector to actually take part in solving interoperability, rather
than continuing to add to the problem. There are real synergies to be
explored. Much of the new work in openEHR and related architectures is
coming out open source. It would be great if existing open source health
application developers were to get involved - e.g. by working with us and
others (e.g. HL7 HSSP, IHE etc) on e-health service
models<http://www.openehr.org/wiki/display/spec/openEHR+Service+Model>. We
on the other hand have a lot to learn about e-health applications.

Finally, I would guess that e-health is about 10% of the way to a truly
useful full-featured intelligent and open e-health platform of the future.
That means that books like yours should potentially be educating readers on
the likely future, not the status quo.

- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.chime.ucl.ac.uk/mailman/private/openehr-technical/attachments/2
0120220/a393d2ed/attachment-0001.html


------------------------------

Message: 2
Date: Tue, 21 Feb 2012 08:49:34 +1030
From: Heath Frankel <heath.frankel@...>
Subject: RE: openEHR - Persistence of Data
To: For openEHR technical discussions <openehr-technical@...>
Message-ID:
       <CACOAxbA7mRUQf5Qk1xgoEY4g-v+=RUEE42J%2B-FECeFOZjjxDQA@...>
Content-Type: text/plain; charset="windows-1252"

Hi Koray,
Yes there was a honours thesis done on using an object database to store
and query openEHR data. It was intended to compare our indexed XML blob
approach but from memory it ended up comparing two commercial object
databases.
I will have to ask Chunlan if the paper is publicly available.

Heath.
On 20/02/2012 8:54 PM, "Koray Atalag" <k.atalag@...> wrote:

>  I remember a Honours or Master?s thesis on openEHR persistence...I think
> Heath was involved. Heath is that publicly available?****
>
> ** **
>
> Cheers,****
>
> ** **
>
> -koray****
>
> ** **
>
> *From:* openehr-technical-bounces@... [mailto:
> openehr-technical-bounces@...] *On Behalf Of *M?rcio Costa
> *Sent:* Saturday, 18 February 2012 10:36 a.m.
> *To:* For openEHR technical discussions
> *Subject:* Re: openEHR - Persistence of Data****
>
> ** **
>
> Do Anyone knows about some papers of persistent storing? ****
>
> ** **
>
> att,****
>
>
> *M?rcio Costa*
> B.Sc. in Computer Science @ Cin/UFPE
> M.Sc. Candidate in Computer Science @ CIn/UFPE
> MSN: mdckoury@...
>
>
> ****
>
> Em 17 de fevereiro de 2012 17:59, M?rcio Costa <mdckoury@...>
> escreveu:****
>
> i would like to thank everyone for the information and attention. ****
>
> ** **
>
> i'm trying to do a review about this subject to start my research, but i
> will do something to analyse the best way to model and persist this kind
of
> data.****
>
> ** **
>
> Best Regards,****
>
> ** **
>
> *M?rcio Costa*
> B.Sc. in Computer Science @ Cin/UFPE
> M.Sc. Candidate in Computer Science @ CIn/UFPE
> MSN: mdckoury@...
>
>
> ****
>
> 2012/2/17 pablo pazos <pazospablo@...>****
>
> Hi Erik, you are right, the uglyness depends on 1. the queries you want to
> execute and 2. the programmer background.****
>
> ** **
>
> For 1. the "common" queries like get all records for this patient in this
> time window, are not that ugly, but more complex queries could be.****
>
> For 2. for a XML guy, writing xPath based queries is ok, but for a SQL is
> a pain in the a55.
>
> :D
>
> I'm hoping to see that paper on AQL->xQuery soon!****
>
> ** **
>
> I totally agree that inside the system maybe you don't need a complete RM
> structure to handle data instances, but for the service layer (sharing
> information with other systems) this is a must.****
>
>
>
> --
> 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: Fri, 17 Feb 2012 16:21:29 +0100
> > Subject: Re: openEHR - Persistence of Data
> > From: erik.sundvall@...
> > To: openehr-technical@...****
>
>
> >
> > Hi!
> >
> > On Thu, Feb 16, 2012 at 23:26, pablo pazos <pazospablo@...>
> 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@... http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
> >
> > _______________________________________________
> > openEHR-technical mailing list
> > openEHR-technical@...
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical****
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@...
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical****
>
> ** **
>
> ** **
>
> ** **
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 6898 (20120220) __________****
>
> ** **
>
> The message was checked by ESET NOD32 Antivirus.****
>
> ** **
>
> http://www.eset.com****
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 6898 (20120220) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@...
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.chime.ucl.ac.uk/mailman/private/openehr-technical/attachments/2
0120221/10b0ee3a/attachment.html


------------------------------

_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


End of openEHR-technical Digest, Vol 67, Issue 34
*************************************************

_______________________________________________
openEHR-technical mailing list
openEHR-technical@...

[Het originele bericht is niet volledig opgenomen.]

_______________________________________________
openEHR-technical mailing list
openEHR-technical@...
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

 « Return to Thread: RE: openEHR-technical Digest, Vol 67, Issue 34