Sam Heard wrote:
Dear William
Thank you for the succint description of all that you are up to. The real issue here is that if there is a score, it must be the total of all the ordinal values...I think this is correct. So we can say, if there is a Total, that this total value must be the sum of all the elements, each of which must be present.
I believe that an invariant is the way to do this.....Thomas Beale might help us with the invariant statement that we can put into the archetype. Is this sufficient for you to accept this specification?
yes, this is easy. In the invariants section, you just have a statement like:
invariant
Total_valid: /path/to/total.magnitude = /path/to/item1.magnitude + /path/to/item2.magnitude ....etc
We are improving the way we do invariants, so that symbols will be able to be used instead of those long paths. But the basic idea won't change.
We know from experience here that you have to be prepared to receive data from legacy systems, and it is not always what you and I would want.
I believe the way to do this is with a CEN EN13606 style of openEHR ENTRY, with "legacy" archetypes designed for that, and a conversion facility inside the system between openEHR EN13606 data, and proper opeNEHR ENTRYs, using archetype / archetype conversion. We are workinng
In een bericht met de datum 30-5-2005 23:21:26 West-Europa (zomertijd), schrijft sam.heard@oceaninformatics.biz:
Dear Sam, Evelyn, Others,
This becomes an interesting discussion. I want to go back to the original purpose of our Barthel document to answer, a copy is attached.
The purpose is to bring together clinical knowledge, terminology / codes, an object oriented specialized model, and technical requirements.
These models are the technical specification for development of an electronic health record (EHR) for stroke patients. This record system must also be able to send HL7 v3 messages for continuity of care.
>From the clinical point of view the Barthel index must be valid and reliable, which is substantiated by a wealth of evidence free available in the research literature. Key for the index is that it consists of 10 variables each of them gets a score (0-3 in Dutch version). Preferably the score is done in one and the same session.
Here I agree with Evelyn's assessment that clinicians might get interupted and have to complete the Barthel later. However, I said that maybe measuring part on day one and onother part of day 2 would probably be the maximum time lag. I prefer a complete score in the 1 - 3 minutes that it takes.
there is no reason not to allow a time lag: the total will still be correct - i.e. it will be the sum of those items scored so far. With an openEHR (versioning) system, you just go an modify the Observation the next day.
The way I worked out cardinalities have in fact nothing to do with the technical implementation in either message or EHR, it describes the relationship between the total score and the 10 variables. To be reliable and valid, al 10 MUST be present, otherwise it is not a Barthel.
A partially scored Barthel will still be valid, if the archetype was used. Your application software just needs to set the lifecycle state of the relevant Composition containing the Observation, to "draft" or "incomplete" or whatever.
I assume that the time lag Evelyn suggests is acceptable, but would need clinicians and researchers input to confirm that hypothesis.
The practical need that a system remembers part of the score and the status as 'being carried out but not finished' (Active) and allows a clinician to Complete it after a while, yes I agree to that.
Built-in to openEHR. See Figure 9 in http://www.openehr.org/repositories/spec-dev/latest/publishing/architecture/rm/common_im.pdf; you will see the lifecycle state attribute in the VERSION<T> class. This can be set by the application, and the whole system will know that something is unfinished.
But to my opinion, that cannot be seen as optional relationship between the variables and total score. That relationship must be mandatory a 1..1 relationship
as modeled in the document.
The archetype will ensure this; it will force the software to record something for all 10 items, but assuming '0' is a valid value for them, then the ones you didn't score will just have a 0. Of course, you will need to remember which ones were not scored the next day when you come back!
Reasonable size is interesting, but For stroke only we have identified about a 100 and new groups coming up with their addition set of clinimetrics. A lot can be reused, and stroke is potentially one of the largest scales and indexes users, but any specialty can have up to this number of archetypes. I could live with the 10 Barthel observations being archetypes and Barthel a template. The matter would be to define an ontology / hierarchy, since I too see the
At the moment it is a single archetype, is this not preferable?
problem of massive maintenance on single observations that vary only slightly, e.g. just another valueset.
On the other hand: purposful development e.g. specialty for specialty is a feasable approach.
On your semantic interoperability: for me the use of OO classes, attributes, codes, relationships and cardinalities are exactly the ICT tools that help me as a clinician to express the content and constraints that is necessary for accurate clinical application of the required information / observation. If archetypes cannot accommodate a cardinality of 1..1 between clinically inseparatable items, they potentially create dangerous information. I mean if information is not entered or stored or exchanged correctly, clinicians might make wrong decisions based on such information.
well, archetypes can certainly handle cardinality (actually called 'existence') of items; even better, using invariants, you can state contingent cardinalities/existences e.g. like:
invariant
exists /path/to/bp/diastolic implies exists /path/to/bp/systolic
- thomas beale