Thanks a lot Helma - lots of reading material for Xmas!
Cheers,
-koray
Hi!
A very interesting discussion, thanks to everybody here! Great with all references too!
Maybe if we change the terminology to GUI Templates and openEHR Templates, we will not have these problems.
Or perhaps “GUI focused templates” and “Structurally focused templates” (since both will be openEHR based).
Correct me if I’m wrong:
If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different.So an example inheritance/specialisation hierarchy in a running system could be:
A bunch of clinical archetypes (mostly international, and some regional ones)
…are used as building blocks in…a “structural” template (maybe national/regional) often creating a composite SECTION or COMPOSITION
[add more structural layers if useful]
all correct up to here
…that is then annotated with GUI-hints by…
a set of “GUI templates” with each template fitting a different recurring use case
not forgetting that GUI is only one place to deploy a template (e.g. messages etc), so there might be some other kind of ‘deployment templates’ as well.
…for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools
you have two choices:
- A) mix it in with the languages & architectural layers you already have
- B) create a dedicated layer or component type, and possibly dedicated formalism if needed
I believe there is (as usual) a context dependent gray-zone, not a clear breakpoint, regarding what annotations would be most useful to have in which layer. So, yes I agree layers are good for separation of concerns, but it is not always (at least not at an early stage) easy to forsee exactly what best fits into each layer and how many layers there should be.
I agree - we don’t yet have a clear list of the GUi semantics that would need to be in a UI template…
If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?)
to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section?
and if could be reused also for GUI-stuff instead of creating another different formalism, then we should take a close look at that option before thinking of specifying another mechanism for GUI-concerns. You’d still get layers (if you sensibly use specialisation) but more flexible boundaries during the needed upcoming period of collaborative experimentation and real use.
I think having these discussions is a great start. But it’d be great if someone from the core group ‘owns’ this thread and puts some pressure on us.
Koray, what makes you exclude yourself from the “core group”? Shouldn’t openEHR be a community with peers trying to solve common problems, where people like you with specific implementation experience can help collaboratively lead a specific exploration tangents at least as well as some official “core” that is busy prioritizing other important explorations. Whatever that “core” is I believe it will be actively involved in, and appreciate, the discussions.
Erik, is right. There is no special ‘core group’ like in the old days - these days, it is whoever is here. In terms of ADL/AOM 1.5 specs, I will simply take into account any requirements that are clearly enough documented for me to understand…
- thomas
Hi Thomas,
Correct me if I’m wrong:
If templates can specialize templates in several generations of inheritance/specialisation (This is the case, right?), then we could use the same basic annotation formalism for different purposes in different layers, only the annotation names would be different.So an example inheritance/specialisation hierarchy in a running system could be:
A bunch of clinical archetypes (mostly international, and some regional ones)
…are used as building blocks in…a “structural” template (maybe national/regional) often creating a composite SECTION or COMPOSITION
[add more structural layers if useful]
all correct up to here
…that is then annotated with GUI-hints by…
a set of “GUI templates” with each template fitting a different recurring use casenot forgetting that GUI is only one place to deploy a template (e.g. messages etc), so there might be some other kind of ‘deployment templates’ as well.
…for a specific GUI, the most fitting of those GUI templates is then picked and might be further annotated/specialized with yet another template layer or used directly as input to GUI-generation or GUI-building tools
You describe a very big picture and sounds logic, so we’ll have:
-
Level 1: archetypes (for model complete data sets about a concept, general and specialized ones)
-
Level 2: structural templates (for localized use of archetypes, general and specialized templates)
-
Level 3: define the use of the structural templates
-
GUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data.
-
Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA …).
-
Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates.
-
Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc.
-
Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions.
-
…
If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?)
to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section?
I have a couple ideas that can improve what we’ve done on the EHR-Gen framework. If you want I can put them in the wiki.
Cheers,
-Pablo.
hi Koray
Unknown <> Indeterminate. (though they overlap)
Generally, this is not really an endoscopy requirement. I've seen it come up
in all sorts of contexts. (for instance, the Australias structured pathology
reports). Even in the case of a list of medications: you can assert
that the patient *isn't* taking any medication. Also, you can assert that you're
not sure of the entire list, but you know that the patient is *not* taking a
medication
But it doesn't apply generally - it's a pattern that varies across particular
issues. Frustratingly, there's no consistency in the way people think, as
far as I can tell, and the various coding systems are even more inconsistent
than people's thinking (mainly due to variations in total capture of woolly
thinking across issues)
With regard to the proposal to have nullFlavor on cluster, HL7 pretty much
does this in v3 - all associations have a nullFlavor. But it's a
difficult concept -
when you say the association is not a proper value - which parts of it? It's
like negation - what parts of observed as improper, and what parts properly
define the improperness? (LIke negation - what's the scope of the negation?).
I don't see why the same concern wouldn't apply to a cluster.
It seems to me that this was meant to be solved by having optional clusters
with mandatory items. Because of the variations in the pattern, you sometimes
write additional constraints - like, for instance, you can't observe
any features
of a carcinoma if the carcinoma is not present. But usually we don't bother
encoding these very obvious things in the models
I do think that you have GUI hinting requirements for the template
language here.
These are the kind of things our kind-of-like-archetype-system focuses on:
GUI hints in the templating language
Grahame
Hi Tom, I’ll try to make a few things clear. I’ll chop off parts of my original message for better readability.
…
However clinical findings, as in our case, essentially require to be depicted as unknown or absent explicitly. We have initially thought we could solve the issue by using flavours of null which is defined by openEHR RM for each ELEMENT data item (caution here it is only for ELEMENT) but the problem is that these findings are represented using CLUSTERs not ELEMENTs in our MST Archetypes. This is because we use ELEMENTs under each CLUSTER to depict properties or attributes of those findings such as size, number extent etc. And we cannot represent Absent with flavours of null either.
Koray, I don’t get this bit: you are saying you want the effect of flavours of null for whole sub-trees of information?
Yes I suggest that we have some means to indicate the presence state of a whole sub-tree with further qualifiers as to why information was not available. I am talking about present (well this is straightforward), absent (there has been an effort to find a certain lesion but it was not there) and unknown/indeterminate (which I think flavours of null can be used to further qualify). I think the absent option can simply be handled by negation of present (as Graeme mentions); but not sure how to do that in openEHR.
…
We think this might best be denoted in the RM; either at CLUSTER or ITEM classes. Something like null flavours but not quite the same. Or perhaps a dedicated new class?? That’s up to the discussions.
well moving null flavours to ITEM (meaning CLUSTER and ELEMENT both get it) would not be that hard to do - it has no negative impact on anything. But we have not done any general semantic analysis on this idea…
Happy to provide you with more information and help with that if necessary.
…
To depict standalone findings during archetype design setting the cardinality of CLUSTER to 0..* or 0..n can be used. But currently we cannot set cardinality to 0 for CLUSTER: this is not allowed according to AOM (although in openEhrV1 it’s possible to have CLUSTER’s with 0 ITEM’s as long as it isn’t validated by the RmValidator, this isn’t considered a desirable usage).
but you can’t record any data in a CLUSTER with no children. If the CLUSTER is named (i.e. has at-code) for ‘haemorrhoids’ the implication is that something is going to be said about this. The function of this name/code here is as a name, not as a value. Some ways of doing this would be:
ELEMENT [haemorrhoids]; value = present
This won’t work for us because almost all findings are qualified by attributes and associated by anatomical sites. So it has to be under a cluster as a sub-tree
or
CLUSTER [haemorrhoids];
CLUSTER – more complex description of haemorrhoids
ELEMENT
ELEMENT
etc
Well close but not exactly. Our modelling approach is:
CLUSTER occurrences {0..*} [Tumour] (note that this whole sub-tree can repeat as a whole for defining same finding with a different set of qualifiers)
ELEMENT {0..1} [Type] — values
ELEMENT {0..1} [Stage] — values
ELEMENT {0..1} [Extent] — values
ELEMENT {0..} [Sites] — values (note that this can be multiple with occurrences set to 0..)
So when we create the ‘value’ instance which is a shadow of the opt we have all parts of the model in place – i.e. all ELEMENTS have null values and obviously CLUSTERS holding them are all instantiated. When use enters data from GUI the widgets are bound to the parts of the instance and values are updated. If a multiple entry has been made then new instances of some subtrees are added to the ‘value’ instance. However when persisting this ‘value’ instance we prune all null sub-trees and then serialise and save.
So the point is we never have empty CLUSTERS which we want to store data; but what happens is initially lots of CLUSTERS holding sub-trees are instantiated with all its ELEMENTs with null/default/assumed values. As I explained in order to represent the presence of this sub-tree we insert a special ELEMENT which depicts this presence information to each and every sub-tree. And we then have to hardcode this in our application which makes me uncomfortable. I think it is not good modelling practice to do this manually. Perhaps best way would be not to touch the current data structures but introduce a custom syntax in ADL which will make things easier and more consistent among different implementations.
or
CLUSTER [features present];
ELEMENT [observed feature]; value = haemorrhoids
ELEMENT [observed feature]; value = something else
etc
Same as first one – won’t work
The real issue is a bit more tricky and has to do with core semantics: it doesn’t make sense to depict a finding as absent or unknown when qualified by certain attributes.
…
ok, so absence / negation is a common requirement in endoscopy…
That is the current requirement for us but I think this applies equally to many other domains in clinical medicine.
So it looks like some qualifiers may change the existence of core concepts – so perhaps we need some means to tag them during modelling. It looks like these are ‘physical’ properties and not ‘man-made’ concepts.
I think you mean that the possibility of reporting absence (when it can make sense) depends on the morphological feature?
Good point – have to dig further into the morphological features and check to see if there are any exceptions though.
-koray
Hi Tom, here is our response:
We have so far came across two issues which we believe should be handled at the clinical modelling levels (i.e. RM, archetypes and templates). These have to do with the structure and semantics of the clinical information and underpinned by domain knowledge.
Hi Koray
One way that we are handling this kind of issue is with a separate exclusion archetype. So for adverse reactions for instance, if you want to say that this person has no known allergies, you use a separate archetype called an exclusion archetype. For data, this has the advantage of enabling an easy query for “no allergies” rather than pulling up an adverse reaction instance and having to look inside it for “no allergies”. This works for many different types of content and means that you don’t have to hack archetypes to try to add the negative. So in your use case, you could have a specific “No polyps” exclusion archetype which models the location.
This is a common clinical pattern and problem.
regards Hugh
I think the problem here is that the need for expressing exclusion is at a fine grain level, i.e. it is not an exclusion of a whole-of-patient condition or sign or symptom, but a sign (I guess that’s what polyps etc are) or its absence within a physical examination that looks at all sorts of things. I would have guessed (I know this is naive - Koray has spent years on these models and it is some time since I saw them!) that ‘absence’, ‘indeterminate’ etc would be possible values among other sets of values indicating presence.
E.g. following your scheme Koray, I would expect to see another ELEMENT:
CLUSTER occurrences {0..*} [Tumour] (note that this whole sub-tree can repeat as a whole for defining same finding with a different set of qualifiers)
ELEMENT {0..1} [Presence] — DV_ORDINAL : present, absent, … other values?
ELEMENT {0..1} [Type] — values
ELEMENT {0..1} [Stage] — value
ELEMENT {0..1} [Extent] — values
ELEMENT {0..} [Sites] — values (note that this can be multiple with occurrences set to 0..)
This means that any feature can be recorded as absent within the same structure as the existing data. I imagine you must have thought about this and have a reason for not doing it… but I don’t know what it is at this stage…
- thomas
Hi Hugh,
The Exclusion archetype makes sense at a diagnosis or procedure level
but does not work well for detailed clinical findings. In the case of
the pathology archetypes it would result in the creation of scores of
Exclusion archetypes and umanageable templates.
The problem Koray raises is actually quite complex and difficult.
1. There is crossover with the more generic problem of questionnaire
type constructs which run counter to Clinical Statement type
expressions
e.g.
(Name) 'Polyps present" =Y/N (value)
as opposed to
(Name) 'Polyp findings' = Polyps present/ polyps absent (value)
2. The handling of indeterminate/equivocal responses which is handled
specifically in Snomed and by possibly by Null flavours in
HL7/openEHR, though this can be difficult to acheive reliably e.g Some
path models have both indeterminate AND equivocal. Others have more
nuanced values etc. My policy when constructing the path archetypes
was to model 'nulls' explicitly as Koray has done. This is frustrating
and cumbersome but does make Snomed mapping much easier.
3. Koray is also identifying a need for a conditional statement which
effectively switches on /off mandation for child elements. I
understand Graham's point that this requirement is often pretty
apparent from the model but it is an other aspect of domain clinical
knowledge which should be captured, even if the condiitonal expression
is too complex for a computable formalism and is expressed textually.
4. There is a related problem that I have identified from working with
detailed findings. Quite often the initial requirement is just for a
simple Present/Absent or Normal/Abnormal element e.g Polyps Y/N.
However from experience we know that there is a strong possibility
that this simple requirement is likely to expand to require a Cluster
with far more detail. We are faced with a dilemma as whether we model
as a simple element , which keeps the current expression clean and
simple, or whether we immediately use a cluster which adds some (for
now) unnecessary complexity.
When thinking about this , it struck me that there may be a place for
specifically supporting the detailed clinical finding to allow more
natural expansion of the content without disturbing subsequent
archetype paths. Furthermore, this seemed also to have relevance to
work on aligning with Snomed post-coordination. I wish I could have
claimed to have solved the problem but so far all that has emerged are
pages of scribbled notes.
My suggestion is that the 'Detailed Clinical finding' i.e. sub-Entry
is a challenge which perhaps needs some fresh thinking, perhaps in
combination with Snomed post-coordination work and addressing the
Questionnaire conundrum.
Ian
Dr Ian McNicoll
office / fax +44(0)1536 414994
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical analyst, Ocean Informatics
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care SG Group www.phcsg.org
Hi Tom, yes you nailed it…Actually this is exactly what we do at the moment but uncomfortable with this approach. I think it’d be great if the formalism handles this common pattern without such a workaround which is repeating all over.
Cheers,
-koray
Hi Tom, yes you nailed it…Actually this is exactly what we do at the moment but uncomfortable with this approach. I think it’d be great if the formalism handles this common pattern without such a workaround which is repeating all over.
Cheers,
Hi Tom, I agree that the this is best way how to ‘represent’ data technically. But what I suggest is, since this is a universal and repeating pattern for all clinical findings (and maybe more) can’t we have an extension in ADL such that we ‘tag’ a certain sub-tree and then this node is inserted into ADL source automatically. And the way we write queries and process that would be uniform and convenient.
Cheers,
-koray
Hi Tom, I agree that the this is best way how to ‘represent’ data technically. But what I suggest is, since this is a universal and repeating pattern for all clinical findings (and maybe more) can’t we have an extension in ADL such that we ‘tag’ a certain sub-tree and then this node is inserted into ADL source automatically. And the way we write queries and process that would be uniform and convenient.
Cheers,
Hi Tom, I agree that the this is best way how to ‘represent’ data technically. But what I suggest is, since this is a universal and repeating pattern for all clinical findings (and maybe more) can’t we have an extension in ADL such that we ‘tag’ a certain sub-tree and then this node is inserted into ADL source automatically. And the way we write queries and process that would be uniform and convenient.
Cheers,
Hi Thomas,
…
You describe a very big picture and sounds logic, so we’ll have:
Level 1: archetypes (for model complete data sets about a concept, general and specialized ones)
Level 2: structural templates (for localized use of archetypes, general and specialized templates)
Level 3: define the use of the structural templates
GUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data.
Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA …).
to do non-openEHR message syntaxes, it requires not just another ‘template’ (in fact, not much be needed here), but a transformation from the operational template (OPT) form to the target form, e.g. CCR XSD or whatever.
Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates.
Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc.
Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions.
…
I am not sure what some of these would look like, but I suspect they will come into existence one day…
If the already present annotation mechanism in templates is powerful enough (Do you think it is, Koray, Pablo and others?)
to be clear, do you mean the annotations documented in the ADL 1.5 draft document? I.e. the new annotations section?
I have a couple ideas that can improve what we’ve done on the EHR-Gen framework. If you want I can put them in the wiki.
please do that
- thomas
Hi Sam/ Thomas,
I am tending to Koray's side here.
There is a pattern which starts with a Question and leads to
increasing but unpredictable levels of detail. We can, of course
represent any pattern with clusters and elements but I have the
feeling that there are some aspects that, if supported within the RM,
might make for more consistent and more easily extended archetypes as
new use cases emerge. There is also overlap with the SNOMED findings
concept model. I come across these sort of issues fairly frequently
when modelling fairly detailed application-focused dialogs and I am
conscious that the archetypes seem more clumsy and less naturally
extensible than should be necessary.
This is probably a dumb, unworkable idea but something like a boolean
Y/N element which 'hides' its true semantics as Present/Absent, and
can conditionally become a container, would solve several problems and
considerably visually simplify a lot of archetypes.
If we can make some progress here we will make it much easier to align
with post-coordinated SNOMED terms (and make the use of archetypes to
define these patterns compelling.
I can see the argument that we can get tools to support these
identified patterns but this is tricky unless we can annotate the
models as definitely needing the pattern handling to be enabled i.e.
just because a set of nodes follows a pattern does not necessarily
mean that it should be handled in the tool as such.
As an example there is currently the typical 'pizza menu' pattern,
where the sensible view in tooling and GUI is to use a multiple
checkbox list but this may not always be the case. i.e the pattern is
accidental. The only way to control this is to annotate the ADL with
some kind of directive, as Koray has done.
Perhaps Koray and I should be funded to go and think this out for 3
months .. the Bahamas might be conducive.
Ian
Dr Ian McNicoll
office / fax +44(0)1536 414994
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical analyst, Ocean Informatics
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care SG Group www.phcsg.org
Hi, I don’t mean to be too pushy on this but I think we are not really on the same grounds at the moment. I’ll try to summarise my points:
-
Re universality I agree with you as you describe but I have indicated that this pattern is unique to certain type of observations; so perhaps I shouldn’t have used the term universal but ‘common’ in many types of clinical findings as a result of some examination. The exclusions you give by examples are very appropriate.
-
It is perfectly possible, and indeed during the diagnosis of acute appendicitis essential, to denote absence of lump or “lack of rebound reflex” is almost common expression and pathognomonic to the disease. So I don’t agree with you and my gut feeling is that all findings during physical examination may well be reported as absent.
-
Yes I’d be also very interested to identify and classify if possible which ones – but again my gut feeling is that this may not be possible and that relies on the clinical context and semantics. Therefore instead of identifying these at the outset I think giving the modellers a method to tag these will be the pragmatic solution and enable consistency among modellers and implementations.
-
Re design patterns and tooling support – I think this should be in place in any case. But as Ian has pointed out there is more to the problem than convenience for modellers. The problem is consistency among modellers and mode critically when these models need to evolve (which is almost guaranteed) then how to avoid changes in paths…i.e. many ELEMENTs will need to be converted to CLUSTERS. Conversely if you anticipate this and design accordingly you might end up having zillion of unnecessary CLUSTERS with single ELEMENTs…
Hey Ian! I liked your proposal…Never been to Bahamas
Cheers,
-koray
Hi Thomas,
…
You describe a very big picture and sounds logic, so we’ll have:
Level 1: archetypes (for model complete data sets about a concept, general and specialized ones)
Level 2: structural templates (for localized use of archetypes, general and specialized templates)
Level 3: define the use of the structural templates
GUI Templates: define directives over a couple of Structural Templates to create a graphic representations of some archetyped data.
Message Templates: define directives to structure archetyped data into messages with some syntax (HL7 v2, v3, 13606, CCR, CCD, CDA …).
to do non-openEHR message syntaxes, it requires not just another ‘template’ (in fact, not much be needed here), but a transformation from the operational template (OPT) form to the target form, e.g. CCR XSD or whatever.
Doing futurology here, we could have these mapping rules defined inside the Message Templates, or may be just referencing wich tranformation to use (the output syntax) will suffice. But I’m not sure what will be the inside of one of these templates.
Report Templates: create reports with aggregated data and graphic representations like charts. Can be used by GUI Templates.
Information Aggregation Templates: to define data aggregation rules over a set of archetyped data. Can be used by GUI Templates, Report Templates, etc.
Rule Templates: to define rules over a set of archetyped data to check validity, consistency, etc, etc. Can be used by Decision Support Modules, e.g. to check medication reactions.
…
I am not sure what some of these would look like, but I suspect they will come into existence one day…
I’m not sure neither, but I’m sure these templates will be part of any openEHR-based EHR.
-Pablo.
Hi Sam/ Thomas, I am tending to Koray's side here. There is a pattern which starts with a Question and leads to increasing but unpredictable levels of detail. We can, of course represent any pattern with clusters and elements but I have the feeling that there are some aspects that, if supported within the RM, might make for more consistent and more easily extended archetypes as new use cases emerge. There is also overlap with the SNOMED findings concept model. I come across these sort of issues fairly frequently when modelling fairly detailed application-focused dialogs and I am conscious that the archetypes seem more clumsy and less naturally extensible than should be necessary. This is probably a dumb, unworkable idea but something like a boolean Y/N element which 'hides' its true semantics as Present/Absent, and can conditionally become a container, would solve several problems and considerably visually simplify a lot of archetypes.
Technically this could be done by a special kind of CLUSTER that also acted as an ELEMENT at the same time, i.e. a CLUSTER with a value & null_flavour, just like an ELEMENT has in today’s RM. This would allow it to be treated as an ELEMENT if no children, and as a CLUSTER if there were children. This special node type really would be for this purpose, i.e. where you want to report either absent, and no further detail, or present, with further detail.
But I am still pretty sure this is not universal for al Observations, only for some kinds of physical exam and maybe some other specific finding types.
The argument against this is that it is putting a subtle new class type into the RM, that only applies to some kinds of data (ok, ..) but now needs special processing in all of the software built on openEHR. If we stick with today’s model, we have more generic software, but some tools have to work harder to recognise this (and other) patterns.
Perhaps Koray and I should be funded to go and think this out for 3 months .. the Bahamas might be conducive.;-)
I am pretty sure you can’t work it out without me there … I’ll go pack
- thomas
I can be iconoclasti here, But it seems to be it has more to do with terminology than structure…
Hi All,