Tim Ocean Informatics is working in two key activities.
1. Tom is working on the finalisation of the V1 specification and the development of the open source Java kernel at CHIME(UCL) in London, working with a group in Sweden. The DSTC RecordPoint product (J2EE on SQL database as I understand it) announced yesterday may merge with this work in the future if appropriate - we will have to see where this goes. The DSTC are spinning off a commercial company to provide services in this area. 2. Ocean have a growing team here in Australia building a .Net proprietary openEHR EHR Service (Called EhrBank!). We are starting out at the NSW Cancer Registry working with Vince McCauley from McCauley Software as part of an ITOL grant and have some other potential customers for this product. The archetype repository is coming on - a first glimpse is available at: http://www.dualitysystems.com.au/archetypefinder/archetypefinder We and the DSTC, are ready for project based work in this area, either separately or together as suits customers, to get things moving. Happy to talk you, as I am sure are the DSTC, about any ideas that you have. Cheers, Sam Ocean Informatics > Thomas Beale wrote: > >> >> some may find this >> interesting...http://australianit.news.com.au/articles/0,7204,15675784%5E24169%5E%5Enbv%5E,00.html >> >> >> > Thomas, > > Can you tell us more about the openEHR storage and retrieval engine > being used in the Brisbane HealthConnect trials? Our situation is that > we admire the openEHR model and think that it is basically sound, and > have played with the openEHR archetype editing tools, which seem > adequate for the task. We'd like to have a go at creating some draft > archetypes for use in the public health domain, but in the absence of an > openEHR storage engine, either open source or proprietary, we don't > really see the point except as an armchair thought experiment. We don't > have the resources to build and validate a storage engine of our own > (the building doesn't look too hard; validation is the bit that looks > like it would consume a lot of resources). Any advice for us on how (or > when) we should proceed? > > Tim C > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
