Dear Andrew, Your e-mail, with some thoughtful questions, has generated some interesting discussion inputs already.
The relationship between 13606 and openEHR is long-standing, since a number of the openEHR family have been involved in this standard's development but 13606 does, as you have gathered, have a different and narrower scope. The openEHR Foundation is in the process of reviewing how best to reflect the relationship as it is now, and if you can wait a bit we shall be writing this up more clearly in future documents. 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. The example OIDs in the worked sample in Annex C only have placeholder illustrative attribute values for the validity, root and 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. 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! With best wishes, Dipak ________________________________________________________ Dr Dipak Kalra Clinical Senior Lecturer in Health Informatics CHIME, University College London Holborn Union Building, Highgate Hill, London N19 5LW Direct Line: +44-20-7288-3362 Fax: +44-20-7288-3322 Web site: http://www.chime.ucl.ac.uk _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
