Value or Null_Flavor in CLUSTERs?

[Colin Sutton]

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: openehr-technical-boun...@openehr.org 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 
levelwe 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 clusterif 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

Value or Null_Flavor in CLUSTERs?

[Sam Heard]

An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Value or Null_Flavor in CLUSTERs?

[Koray Atalag]

Hi Sam,

Thanks for your (always) kind answer...My comments & reply is below

Sam Heard wrote:
> Hi Kory
>
> You can have an empty clusterif 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

Value or Null_Flavor in CLUSTERs?

[Sam Heard]

An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Value or Null_Flavor in CLUSTERs?

[Koray Atalag]

Hi,

I know that this is probably something very inappropriate but I happened 
to need such a solution. An example:

CLUSTER []
CLUSTER []   Some type of finding (a lesion: ulcers)
  ELEMENT []   A Feature of the finding (i.e. bleeding)
v: some value
  ELEMENT []  Another Feature of the finding (area)
v: some value
ELEMENT []   Another type of finding   (a lesion: atrophy)
v: some value  OR null_flavor

My problem is I want to be able to state whether CLUSTER[] is 
observed (True) or not (False) when both features (ELEMENTs  and 
) are not present (NULL). I am perfectly able to state it when the 
data structure is an ELEMENT.

Problem arises when none of the features (attributes) of CLUSTER [] 
is observed and that two things can happen:
1) None of the features could really not be assessed, but there is 
definitely an ulcer (presence=TRUE)
2) The lesion in CLUSTER [] is not visualized at all 
(Presence=FALSE). But then we need to know why (classical flavors of null)?

Of course a straightforward solution is putting under each CLUSTER with 
child nodes, a new ELEMENT describing its "presence" with Boolean type 
and with null_flavor.

However if it will not break very badly current semantics and other 
strategies, the advantages of such approach might be:
1) Reducing size, manageability and understandability of (big) archetypes
2) During querying of leaf-nodes in a huge repository, the search 
algorithm can first check parent nodes' presence and then further go 
down to leaf-nodes. If a whole branch is not valid/null from the top, 
then there is no need to look for lower levels and the performance might 
be enhanced.

I might be making a horrible proposal here technically or even there 
exists another solution already, but this is what I need.

Best regards,

Koray Atala, M.D.
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical