Andrew Ho wrote:

As you imply above, the only way public specifications like HL7,
openEHR, etc can become truly ubiquitous and fully respected is if there
are high-quality open source implementations out there,



Right, I am hoping to motivate you and your team to help OIO and other "willing" free software projects implement OpenEHR. I think that's the only way openEHR will ever see the light of day.

there are projects already happening - one under consideration is an Australian government funded one which could lead to a national EHR infrastructure - so I don't think nothing at all will happen, but overall I agree - the OS community is very important. The timetable (see http://www.openehr.org/active.htm) is this: we want to get a 0.9 release out the door in the next 8 weeks. I am presently in Europe to push this along. The 0.9 release will be solid enough for widespread implementation (the current release is actually, but there are various small things we need to change - see the change request page http://www.openehr.org/Change/product/CRs/CR_summary.html; there are more I have to add yet as well). We have been a bit slow due to syncing in with the standards community and making sure that we are compatible with everything as long as we stay inside the "best-of-breed" approach (if we do not like something on a technical basis, it stops at the door and does not get into openEHR...).Another thing which has to be done is that the DSTC will (I hope!) contribute an XML implementation spec to help people use openEHR in XML, schema etc. Lastly, ADL will be released in a 1.0 form at about the same time.

at least of the interoperability layer,



Based on my experience with OIO, offering an "interoperability layer" is not sufficient. Imaging the "VHS interoperability layer" being released as a "free spec" - would it have any chance replacing Sony's BetaMax video recording format?

The only way to establish and protect any standard, IMHO, is to have a
useful product that implements the "standard". "Open" standards are no
different, except we need at least one (preferrably more than one)  free
and useful implementations.

sure - and as I said in the previous post - I agree with this.

to prevent corporations from using the vendor-lock-in strategy to
segment the market.



Yes, that is sure to happen. Even before any standard is finalized, proprietary "enhancements" are typically planned or even ready-to-ship.

the way to do this is with pay-for compliance - you pay a bit and some testing is done on the product, then you get the right to use the "openEHR 1.0-compliant" sticker...

I realize that the openEHR team is currently following a different
roadmap. Maybe you would reconsider and put achieving at least one free
implementation earlier on the roadmap?



some OS components will appear by end of this year, going into next year. I will release the Eiffel source of v0.9 when it is cleaned up, and it can be either wrapped or rewritten in Java (for those who like wheel-reinvention;-). But there is nothing to stop you or anyone else writing code right now. If you are interested in doing this, I suggest the openEHR demographic model is a god place to start experimenting.

- thomas





Reply via email to