Hi Andrew The development of openEHR is currently seen as an engineering process similar to a software design process with full version control, issue tracking and decisions on changes confined to experts rather than committees. This has allowed the openEHR community to respond rapidly to the community of users where issues arise that directly impinge on implementation such as your example of the quoting rules for Unicode. These changes are raised as issues and then resolved by incorporatng relevant changes into the next release of the specification.
I agree with you that putting all of this under a standards body would potentially slow down necessary development at this stage, however it is certainly useful to imprimatur of a standards body with some aspects of the work. Regards Hugh __________________________________ Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI Director and Senior Clinical Consultant Ocean Informatics Pty Ltd M: 0404 033 767 E: hugh.leslie at oceaninformatics.biz Skype: hughleslie > -----Original Message----- > From: openehr-technical-bounces at openehr.org > [mailto:openehr-technical-bounces at openehr.org] On Behalf Of > Andrew Patterson > Sent: Saturday, 4 November 2006 11:13 AM > To: For openEHR technical discussions > Subject: Re: CEN 13606 > > > You have also raised a couple of technical points. Graham > has I think > > responded clearly on the data types - in an ideal world the > ISO data > > type standard would be ready to use before 13606 is > finalised, but as > > this is not the case we have on a temporary basis > referenced the CEN > > TS 14796 (and included some explicit data types as you have seen). > > These will eventually be superseded by the ISO ones). openEHR data > > types are one of the input feeds to ISO. > > yes, good. > > > extension attributes of the II data type. Ideally I should > have found > > an expert to give me more plausible values, but the main purpose of > > the example was to show how the clinical hierarchy and > revision works > > and many of the attribute values for IDs and codes are very clearly > > made up ones (such as the terminology ones). If you have > the time to > > send me some corrections (more plausible values) I can still > > incorporate them. Most readers have accepted that examples such as > > this inevitably have limitations in their completeness, but I agree > > that it's not ideal. > > Yes, I understand how difficult it is to put meaningful > examples in a spec and keep them accurate. I actually wasn't > worried about the OIDS or codes.. I had a philosophical > problem with the use of magic dates > > I would have though > > ehr_system.valid_time = 1/1/1990 - 1/1/3000 > > should be > > ehr_system.valid_time.lowClosed = false > ehr_system.valid_time.highClosed = false > > to show that where no specific values are meaningful, the > standard still has ways to represent the real intent - i.e. > that this extract has no restrictions on the time range in > which it is valid. > > I think its important that examples show best practice > wherever possible - as a programmer, there is always a > temptation on my part, whenever reading a specifcation, to go > straight to the examples section and see if there is an > example that matches what I want to do! And we'd hate lazy > programmers like me from getting the wrong ideas.. > > > Gerard has also responded to you on archetype specification > currency > > within openEHR and 13606. Standards need to be stable, and > standards > > organisations assume that this stability is reasonable and > desirable > > for the marketplace. A innovative organisation like openEHR has the > > freedom to make changes more rapidly, but it also wishes > for them to > > be validated in real implementations. The rapid turn around > that you > > describe is for a document change, not for a field-validated > > improvement! > > True, but there have been some changes e.g. the quoting rules > for unicode, that have been more than cosmetic textual > changes. I am just concerned that the freedoms that openEHR > has to change things rapidly might be lost if the spec gets > tied to the CEN/ISO process. > > Andrew > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
