> 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
