If I understand correctly, to put it in database terms: if the archetype element may be null, the record structure may not exist. That's not the same as the data in the record being null. If fact, Koray, I think it's it's what you are asking for. In your example, if null is allowed in the archetype, smoking could have a cigarette record with elements, or a cigarette record with no elements, or no cigarette record, It would then be up to the implementor to decide whether to capture the type of smoking at all, or for example just smoking/nonsmoking/don't know. Regards, Colin
-----Original Message----- From: [email protected] on behalf of Sam Heard Sent: Sat 17-Feb-07 11:39 PM To: For openEHR technical discussions Subject: Re: Value or Null_Flavor in CLUSTERs? Dear Koray You are taking a more organisational view of the data rather than a primarily semantic priority. It is often possible to cater for both. Sections are where we can put things without changing their meaning. So some of the levels that you describe in your example are sections - ie organising. Risk factors: Within this there may be information about smoking and substance use, drink driving, extreme sport, diagnosis such as hypertension, lipid levels and even family history. These need to be archetyped - but the important thing is that they have the same meaning. If you keep an eye on the NHS archetypes that are coming out over the next few months I think you will start to see the mixture of templates and archetypes that is required to specify information at the application level. We are working hard to keep the number of archetypes to a reasonable level....we will see if this approach is successful, but it looks promising at the moment. The ability to archetype clusters and elements greatly increases the possibility of reuse, but also the complexity. Speak to you soon, Sam Koray Atalag wrote: Hi Sam, Thanks for your (always) kind answer...My comments & reply is below Sam Heard wrote: Hi Kory You can have an empty cluster....if you want to say why it is empty then use null flavor on one or more of the possible elements. Yes this is exactly what can be done now...But when starting to think (or even implement) archetypes not merely as abstract clinical concept models but as objects or program data (as instances) then this may issue become more obvious. If these do not suffice as approaches I probably need the precise example. It suggests that your model may not be optimal. Cheers, Sam Well you are definitely right (and polite) about my models...I also suspect that they are might not only be optimal but I am trying. The previous example was meant to be the precise example but I assume did not make sense (even to me now!). Well instead of an example I will shortly summarize the issue by example: Consider instances of some archetype; let's say with 2,3 levels of nested Clusters each having many elements in leaf nodes. The archetype may describe a cardiovascular patient history and these particular clusters happen to define Risk factors. So one path might be: > Risk factors > Smoking > Cigarette > Quantity. And if a patient has no risk factors, all the entries will be null in runtime instance and eventually in the database. Think about the simplicity of putting a flag or null_flavor at the top node so that a query or a GUI generator will utilize for better performance. Is there any other way than checking each path for element value/null_flavor path? And think about this for millions of records. What disturbs me most with as is approach is that the control is transferred to implementors in deciding to either put an element under each cluster or depict presence/null_flavor on clusters. Thanks for your patience... -koray _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. Ltd. <http://www.oceaninformatics.biz/> Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Ph: +61 (0)4 1783 8808 Fx: +61 (0)8 8948 0215 #################################################################################################################### IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The CTC is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the CTC. If you receive this e-mail in error, please immediately delete it and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. ##################################################################################################################### -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 5522 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070218/9bb3d97e/attachment.dat> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
