Dear Dipak there were many questions concerning 13606 on this mailing list so I will also post my questions here. YET wouldn?t it be possible to host an own mailinglist via openEHR for CEN 13606. (compared to technical/implementers). It doesn?t feel right to bother you and the openEHR community with every small question concerning CEN 13606. It would be great to share Information with the CEN community without feeling guilty when posting at the wrong place.
looking at the example in Annex C of prEN13606-1 some questions arouse. ENTRY rc_id.extension = 0251: this ENTRY has attributes based on committal. Shouldn?t these attributes be based on the feeder_audit? Shouldn?t "committal.ehr_sytem.extension" be named feeder_audit.ehr_system.extension? Nearly all the elements of the revision (second part of the example) are copied from another part of the EHR. Why do only some have the original_parent_ref attribute? (prEN13606-1 p.39). Why does for example the ELEMENT rc_id.extension= 0251 not contain an original_parent_ref? Is it a restriction of the (imaginary) information model, that created the ehr_extract or of the 13606-1 standard to update the COMPOSITION (rc_id = 213) and ENTRY (rc_id=251)? Or would it also be allowed to update ONLY the ELEMENT (rc_id=258) where the actual change took place?? ELEMENT (rc_id=258): why does this element not have the attribute previous_version from the AUDIT_INFO (13606-1 p.46)? This element is a revision of rc_id=158. It is the only element where change took place. Why is it not indicated directly in this element? Thanks for you answer Christoph Rinner On Fri, 03 Nov 2006 19:26:27 +0100, Dipak Kalra <d.kalra at chime.ucl.ac.uk> wrote: > 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 > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
