Tim

We would be very happy to provide the Ocean product, EhrBank, to you for you to test and work with. We are hoping to open source this work - as I have said previously - but have to get sufficient service contracts in place before we can afford to do so. At present you will need to use our .Net kernel - is that OK? In future we hope our EhrBank back end will work with any validated kernel using webservices.

Cheers, Sam

Tim Churches wrote:
Hugh Leslie wrote:
  
Hi Tim

The commercial Kernel is owned by DSTC(Extensia) in QLD and has been in use
in QLD Health for at least 18 months.  I am sure you can purchase a licence
(from the new company that DTSCs health arm has morphed into called
Extensia)  - see their web site at www.extensia.com.au. 
    

Extensia appears to offer a complete openEHR-based EHR solution called
RecordPoint. But that's not what I want. I want an openEHR
storage/retreieval engine/kernel to experiment with and, if the results
are promising, build some special purpose applications on top of.

  
But why don't you
have a look at the open source components first? The java kernel is
available for download from the openEHR website.
    

Yeah, but have a look at the things it can't do yet:
(the following from the download page at
http://svn.openehr.org/ref_kernel_java/TRUNK/project_page.htm )

<quote>
Job: Create archetypes for a person
Description: We need to create an archeypte to represent one person. The
most basic set of archetypes are optional at this stage. 5 archetypes
would be ideal to represent the different objects within demographic
package, initially without using any archetype slots functionality.
Further examples expanding on the initial 5 archetype models can then be
considered using archetype slots and other options. Input from Dipak
Kalra and/or Sam Heard would be optimal.
Who: YLim, NLea

Job: Create archeyptes for 10 people
Description: As above, only 10 variants for 10 different people. This
could be interpreted as 10 instances of the PERSON object and their
respective relationships as defined by PARTY_RELATIONSHIP instances.
Who: YLim, NLea

Job: Get kernel working
Description: Try and bind archetype objects to relevant reference model
objects with different archetypes and functions (i.e. with archetype
slots and without)
Who: YLim, NLea

Job: Get persistence package working
Description: To reduce table numbers in a database, it is advantegeous
to group certain reference model classes into single object for direct
object relational mapping. This package will serialise the objects into
specific formalism such as XML and dADL which will be persisted,
retrieved and de-serialised when required.
Who: YLim, NLea
</quote>

After reading that, especially "Job: get kernel working", I am more than
a little disinclined to invest time and effort in this code, as it stands.

Note that I am not whingeing, I am just pointing out that it is
unrealistically confident for people to say "openEHR is the future"
when, at this juncture, you can't a) buy a commercial openEHR
engine/kernel or b) download a working open source openEHR engine/kernel.

Am I being too nasty in pointing out these inconvenient facts? Or just
plain wrong? Or is the above information, verbatim from the openEHR Web
site, incorrect? Or am I misinterpreting it?

Tim C

  
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Tim Churches
Sent: Monday, 2 January 2006 7:06 PM
To: General Practice Computing Group Talk
Subject: Re: GP Requirements - was [GPCG_TALK] Re: The Dreaming

Hugh Leslie wrote:

    
There are a number of projects around the world that have built 
systems that utilise this structure and in Australia there are at 
least three working examples of openEHR kernels including a commercial 
offering that is being used by QLD Health.
      
Hugh,

Where can I obtain information on this commercial openEHR kernel? I'd like
to purchase one.

Tim C
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

    

_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

  
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

Reply via email to