Re: Converting Archetype into Nosql Schemes
Hello Fadoua, Although I am not able to directly help with your request, you may be interested in a tool to view/edit operational template XML files developed under the current release (ADL1.4), such as those on the openEHR CKM site. This runs on Windows, Linux and MacOS and might help you explore some of the bundle of models that have already been developed around the world. It is based on a generic XML authoring tool XMLmind, augmented with a plugin I developed specifically for viewing openEHR Operational Templates. I've written a brief blog article at http://healthbase.info/blog/?p=390 describing how to obtain and install it. Other pointers that might be more relevant to your question:- https://openehr.atlassian.net/wiki/display/resources/Persistence+FAQs https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4636072/ http://www.ep.liu.se/ecp/070/009/ecp1270009.pdf regards, eric Eric Browne eric.bro...@montagesystems.com.au ph +61 414 925 845 skype: eric_browne > On 14 Oct 2016, at 2:59 am, Fadoua Khennou wrote: > > Hello, > > I am a Phd student, working on the implementation of OpenEhr standard with > Nosql technologies in order to study the performances for such plateformes. > > And because i have just got familiar with archetypes in the ADL workbench and > Ocean informatics, i would like to know is there an automatic way of > generating from operational template the adequate sql or nosql tables? > > If not should i integrate any other tools or modules in order to do this > conversion? > > Thanks in advance for your response. > > > My regards, > Fadoua > > > -- > Cordialement, > > KHENNOU Fadoua > __ > Phd student at USMBA-Fes, Morocco > Transmission and Processing of Information laboratory > __ > ___ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: UCUM code in body temperature archetype
Hi Silje,
‘U’ is used in the lab_test-blood_glucose archetype.
I also think that 10*12/l, 10*6/l, 10*6/mm3, 10*9/l are all valid UCUM codes.
In fact UCUM’s table 26 Example Unit Terms by Term lists 10*6/mm3 as legal with
a preferred alternative of /pL . It also lists the following alternatives:-
10*3/L = /mL
10*6/L = /uL
10*9/L = /nL
with all 6 codes being valid.
regards,
eric
> On 18 May 2016, at 11:43 pm, Bakke, Silje Ljosland
> wrote:
>
> Hah, thanks for that correction, I completely missed the '0' instead of 'O'
> and the ‘mho’. J
>
> ‘U’ is certainly wrong if used for international units, as you say, but for
> the liver tests ALP, ALT, AST, GGT and LD the test is actually measuring
> catalytic activity, so U/L should be correct. Not sure where ‘U’ by itself is
> used.
>
> Regards,
> Silje
>
> -Original Message-
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
> On Behalf Of Eric Browne
> Sent: Wednesday, May 18, 2016 3:49 PM
> To: For openEHR technical discussions
> Subject: Re: UCUM code in body temperature archetype
>
> Unfortunately Silje, not quite correct. The eye deceiveth.
>
> The construct [H20] is not valid UCUM. In none of the CKM archetypes did I
> find the correct UCUM code [H2O]. A zero has been substituted for the letter
> ‘O’.
> An easy mistake for a human to make. H20 even mistakenly appears 4 times in
> Appendix D Example Unit Terms at http://unitsofmeasure.org/ucum.html.
>
> The same is likely to occur in the case of Litre, with ‘l’ (lowercase L) vs
> ‘1’ (numeral one) vs ‘I’ (capital letter eye), depending on typefaces used.
> That’s why many health safety organisations favour ‘L’ for Litre over the
> lowercase variant. UCUM unfortunately allows either as case sensitive
> variants ( which strictly means that this particular unit is not case
> sensitive in the case sensitive case) :-(
>
> Also, despite ‘U’ being a valid UCUM unit, it is probably incorrectly used
> in the CKM archetypes. The correct UCUM unit code for international unit
> should be “[iU]” or “[IU]” - another case of case variants for supposedly
> case-sensitive units. ‘U’ is the UCUM code for catalytic activity. Same
> applies for ‘U/l’, which may be valid UCUM syntactically, but unlikely to be
> correct semantically in the liver function test archetype.
>
> Also mmho is correct UCUM. A mho is a unit of electrical conductance ( It
> comes from Ohm, the unit for resistance, spelt backwards. Ohm starts with a
> capital letter since named after a human, whereas mho does not). mho as been
> deprecated as an SI unit and renamed to siemens, but is retained and valid in
> UCUM. mmho was found in openEHR-EHR-OBSERVATION.tympanogram_hf.v1.adl
>
>
>
>
> regards,
> eric
>
>
>
> > On 18 May 2016, at 10:05 pm, Bakke, Silje Ljosland
> > wrote:
> >
> > Awesome! These can be classified into UCUM, non-UCUM and just plain wrong:
> >
> > UCUM:
> > 1/min, Hz, Hz/s, U, U/l, cm2, cm[H20], d, daPa, daPa/s, deg, h, kHz,
> > kPa, kg, kg/m2, l, l/min, l/s, m, m2, mV, mg, mg/dl, mg/l, min, ml,
> > ml/d, ml/ml, ml/s, ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg],
> > mmol/l, pg, pmol/l, s,
> >
> > Non-UCUM:
> > /d, /h, /min, /mo, /wk, Ashman units, 10*12/l, 10*6/l, 10*6/mm3,
> > 10*9/l, , IU, cc, dB, fl, , fl oz, ft, in, in2, lb, lb/in2, mIU/l,
> > millisec, oz(avdp), °, °C, °F, µmol/
> >
> > Just plain wrong:
> > gm, gm/d, gm/l, gm/wk (gm == "gram meter", not "gram") mmho (supposed
> > to be mm/h or mm.h? Does anyone know which archetype this comes from?)
> >
> > Not 100% sure:
> > {Volume/Volume}
> >
> > So quite a few units in archetypes are actually UCUM-compatible, but there
> > are plenty which aren't, and some which are wrong and can be badly
> > misinterpreted.
> >
> > Oh, and UCUM does allow non-units to be represented using curly braces,
> > like {puff} or {tablet} as symbols for the default unit '1'.
> >
> > Regards,
> > Silje
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: UCUM code in body temperature archetype
Unfortunately Silje, not quite correct. The eye deceiveth.
The construct [H20] is not valid UCUM. In none of the CKM archetypes did I
find the correct UCUM code [H2O]. A zero has been substituted for the letter
‘O’.
An easy mistake for a human to make. H20 even mistakenly appears 4 times in
Appendix D Example Unit Terms at http://unitsofmeasure.org/ucum.html.
The same is likely to occur in the case of Litre, with ‘l’ (lowercase L) vs ‘1’
(numeral one) vs ‘I’ (capital letter eye), depending on typefaces used. That’s
why many health safety organisations favour ‘L’ for Litre over the lowercase
variant. UCUM unfortunately allows either as case sensitive variants ( which
strictly means that this particular unit is not case sensitive in the case
sensitive case) :-(
Also, despite ‘U’ being a valid UCUM unit, it is probably incorrectly used in
the CKM archetypes. The correct UCUM unit code for international unit should be
“[iU]” or “[IU]” - another case of case variants for supposedly case-sensitive
units. ‘U’ is the UCUM code for catalytic activity. Same applies for ‘U/l’,
which may be valid UCUM syntactically, but unlikely to be correct semantically
in the liver function test archetype.
Also mmho is correct UCUM. A mho is a unit of electrical conductance ( It comes
from Ohm, the unit for resistance, spelt backwards. Ohm starts with a capital
letter since named after a human, whereas mho does not). mho as been deprecated
as an SI unit and renamed to siemens, but is retained and valid in UCUM. mmho
was found in openEHR-EHR-OBSERVATION.tympanogram_hf.v1.adl
regards,
eric
> On 18 May 2016, at 10:05 pm, Bakke, Silje Ljosland
> wrote:
>
> Awesome! These can be classified into UCUM, non-UCUM and just plain wrong:
>
> UCUM:
> 1/min, Hz, Hz/s, U, U/l, cm2, cm[H20], d, daPa, daPa/s, deg, h, kHz, kPa, kg,
> kg/m2, l, l/min, l/s, m, m2, mV, mg, mg/dl, mg/l, min, ml, ml/d, ml/ml, ml/s,
> ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], mmol/l, pg, pmol/l, s,
>
> Non-UCUM:
> /d, /h, /min, /mo, /wk, Ashman units, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, ,
> IU, cc, dB, fl, , fl oz, ft, in, in2, lb, lb/in2, mIU/l, millisec, oz(avdp),
> °, °C, °F, µmol/
>
> Just plain wrong:
> gm, gm/d, gm/l, gm/wk (gm == "gram meter", not "gram")
> mmho (supposed to be mm/h or mm.h? Does anyone know which archetype this
> comes from?)
>
> Not 100% sure:
> {Volume/Volume}
>
> So quite a few units in archetypes are actually UCUM-compatible, but there
> are plenty which aren't, and some which are wrong and can be badly
> misinterpreted.
>
> Oh, and UCUM does allow non-units to be represented using curly braces, like
> {puff} or {tablet} as symbols for the default unit '1'.
>
> Regards,
> Silje
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: UCUM code in body temperature archetype
Dear All, There are many, many, many archetypes in the various openEHR CKMs that DO NOT, I repeat DO NOT, I repeat DO NOT use valid UCUM codes for units in various DV_QUANTITY elements. I would guess up to 30% of Observation archetypes have some ‘invalid' UCUM unit. I spent some time trying to explain the reason for, and ramifications arising from this issue in a previous post. That post arose from Heather Leslie’s concerns about potential major changes to the coveted blood pressure archetype - see https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg09185.html. In that post I stated "Even basic archetypes like Body Temperature define units which are not UCUM-conformant. I consider this to be a more serious issue than the tilt angle of a person whose blood pressure is being recorded." At that time Thomas suggested I raise a Problem Report, but so far I have failed to do so. There are also the related PRs: https://openehr.atlassian.net/browse/SPECPR-13 https://openehr.atlassian.net/browse/SPECPR-96 regards, eric Eric Browne eric.bro...@montagesystems.com.au ph 0414 925 845 skype: eric_browne > On 18 May 2016, at 5:55 pm, Bakke, Silje Ljosland > wrote: > > Hi Daniel, > > You’re 100% correct. This error is corrected in the branch I uploaded after > the Norwegian body temp archetype was published, but this hasn’t been taken > into the trunk yet as it contains some other major changes. > > As a general observation, an issue with using UCUM units in archetype (which > is to my mind the only way to go), is that there’s as far as I know no way to > include both the code and the print symbol in the archetype. This imposes a > larger implementation burden on the systems who will have to be able to read > UCUM codes and show the corresponding symbol instead of the code, which in > many cases is not readable to clinicians. > > Kind regards, > Silje Ljosland Bakke > > Information Architect, RN > Coordinator, National Editorial Board for Archetypes > National ICT Norway > > Tel. +47 40203298 > Web: http://arketyper.no / Twitter: @arketyper_no > > From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] > On Behalf Of Daniel Karlsson > Sent: Wednesday, May 18, 2016 10:09 AM > To: openehr-technical@lists.openehr.org > Subject: UCUM code in body temperature archetype > > Dear All, > > it seems the UCUM code for the temperature units in the Body temperature > archetype is wrong. It uses the UCUM print symbol, e.g. "°C", rather than the > UCUM code "Cel". > > http://www.openehr.org/ckm/#showArchetype_1013.1.49 > > Regards, > Daniel > > -- > Daniel Karlsson, PhD, sr lecturer > Department of Biomedical Engineering/Health informatics > Linköping university > SE-58185 Linköping > Sweden > Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com > ___ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: UCUM code in body temperature archetype
I just did a bulk download of 133 Observation archetypes from ckm.openehr.org
and extracted the following list of units:-
/d, /h, /min, /mo, /wk, 1/min, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, Ashman units,
Hz, Hz/s, IU, U, U/l,
[pH], cc, cm, cm2, cm[H20], d, dB, daPa, daPa/s, deg, fl, fl oz, ft, gm, gm/d,
gm/l, gm/wk, h, in,
in2, kHz, kPa, kg, kg/m2, l, l/min, l/s, lb, lb/in2, m, m2, mIU/l, mV, mg,
mg/dl, mg/l, millisec, min,
ml, ml/d, ml/ml, ml/s, ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], mmho,
mmol/l, oz(avdp), pg,
pmol/l, s, {Volume/Volume}, °, °C, °F, µmol/
I did this with a script and have not manually validated this list visually in
the ADL.
regards,
eric
Eric Browne
eric.bro...@montagesystems.com.au
ph 0414 925 845
skype: eric_browne
> On 18 May 2016, at 8:35 pm, Thomas Beale wrote:
>
> Hi Daniel,
> the reason it is a String is because we have always treated UCUM units as
> parseable strings. E.g.
> kg.m^-2
>
> and
>
> kg/m^2
> are parseable according to UCUM's grammar into an expression that has a
> single meaning, and can also be equated to e.g. 'kPa' (which is itself
> parseable and so on).
> - thomas
> On 18/05/2016 10:05, Daniel Karlsson wrote:
>> So, right now the DV_QUANTITY.units is a String, perhaps it should be
>> DV_CODED_TEXT?
>>
>> /Daniel
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: Archetype publication question - implications for implementers [ long ]
ideal world, rather than for implementations that have to operate in the real world. My observations of how the openEHR world is evolving is that these archetype repositories do generally, and should try to set a gold standard. They should push implementations rather than retard them. That model, in turn, puts a pressure on the repositories to be of high quality, comprehensive, current. That, in turn implies publishing new versions. Implementations don’t have to adopt the new versions. But the new versions need to offer real benefits. The trouble with “fixing” the units of all currently published archetypes is that adopting them in order to really make use of the normative UCUM units would mean pain for implementers. But for what gain? Notes on current practice regarding unit usage in HL7 laboratory messages I include the following, simply because it tries to illustrate how units are currently handled in many typical data sharing environments. * Legacy, non-openEHR systems using 7-bit databases might use predefined table of units something like UCUM - more likely they would specify their own unit system - perhaps “deg” for values for "°C” in a system in a metric country or “deg” for values in “°F” in a system in the US. In many systems the units are often implicit and not stored with each value. * In Australia, diagnostic testing laboratories almost all send test result reports in HL7 v2 messages. Many of these use atomic fields for each observation. HL7 v2 uses an explicit field for transmitting a unit description. The Australian Standards specify ISO+ values to be used to name these units in messages. In practice, messages comply to various levels with these ISO standards. I think the use of these codes is similar in the US, New Zealand and a number of other countries, although I am less familiar with these. * Depending on the quantity being sent in a report, the ability to computationally deal with the unit is fraught with implementation issues. Some parameters such as temperatures or weights that have been modelled as such in archetypes can be validated. In many cases there is simply too much variability, either in the units that are allowable for a particular field, or for the variability in quality of the actual units sent. * Both of the above shortcomings lead to implementers wanting archetypes with little or no unit constraint on many fields. More often than not this is a result of lack of compliance infrastructure. * In the real world of extensive data sharing, highest common denominator ( or often lowest common denominator ) trumps standards and quality, and even safety. regards, eric Eric Browne eric.bro...@montagesystems.com.au ph 0414 925 845 skype: eric_browne > On 2 Oct 2015, at 1:41 pm, Heather Leslie > wrote: > > Hi everyone, > > I’m seeking community input around a conundrum that has arisen regarding > archetype governance or, more specifically, if we should offer a new version > of an archetype that included breaking changes/corrections according to the > openEHR specifications but which are not critical in terms of clinical safety > – a bit of a grey zone, if you like. If clinical safety were implicated, the > decision would be easy. > > The Blood Pressure archetype was published in 2009 and I believe is in fairly > wide use in systems at this point. Currently published version here, and > which has had only ‘trivial’, non-breaking changes, including addition of > translations, etc since publication. > > Recently the Norwegian community translated the archetype and then undertook > a local review of the archetype. They have suggested some modifications to > the archetype which include updating some of the data elements around > identifying the body location of the BP measurement to be in keeping with > more recent archetype patterns that we have been using, plus identified that > the representation of degrees of Tilt was not using the UCUM units, plus a > few minor additions. > > The result is that their new candidate archetype (here) which includes these > changes is regarded as a Major revision under our current CKM versioning > rules and if republished warrants becoming a version 2. That is all perfectly > OK from an academic governance point of view. > > There is no doubt that the archetype is a more accurate and enhanced > iteration but the practical implications of republishing as a v2 are not > trivial to implementers. > > So I seek your advice on whether we should proceed with further content > review with the intent of re-publishing as a new v2 archetype: > · Pros > o Archetype data is updated to include correct UCUM units > o Archetype data is updated to include more ‘modern’ modelling patterns > that are being used increasingly in more recent archetypes > o
ISO 21090 data types too complex?
Andrew, I agree that there can be value in producing lower common denominator artefacts for short term implementation gains. I don't, however, see why we can't aim to gain agreement on more specifically defined artefacts as the basis for clinical models, and then, as you suggest, provide adapters for actual implementations, particularly if the cost in doing so is minimal - it is simply a matter of automatically processing from the richer openEHR specification to the simpler ISO 13606. The difference essentially boils down to collapsing archetypes defined according to openEHR's richer ENTRY subclasses of OBSERVATION, EVALUATION, INSTRUCTION and ACTION into archetypes based on the simpler 13606 ENTRY class. As for HL7 V2, I cannot understand why the manifestation of ENTRY types is a relevant issue here. Are you suggesting that if ISO 13606 were balloted today, based on today's openEHR richer ENTRY subclasses that it would substantially change the way archetyped data could be carried in V2, to the point where you could not entertain supporting it? Or conversely that you would be happy to adopt it because it were a "standard". Or are you merely suggesting that if Australia, for example, were to develop/adopt/"compromise" on a set of archetypes based on the openEHR model rather than ISO13606 that one company - Medical Objects - might have to undertake modifications to their product suite? I have to confess that neither my technical skills, nor my clinical knowledge may be sufficient to allow me to form a strong view on the detailed merits of the attributes of openEHR's ENTRY subclasses, other than it seems patently obvious that one needs (somehow) to distinguish between INSTRUCTIONS, ACTIONS and OBSERVATIONS/EVALUATIONS in the openEHR sense of their meanings. To dismiss these differences in favour of some ISO standard, and walk away from the whole process, at least for clinical modelling purposes, seems akin to throwing the baby out with the bath water. And wouldn't that run counter to the Hippocratic oath? - eric On 2010-11-08, at 9:35 PM, Andrew McIntyre wrote: > Hello Hugh, > > As someone who believes in a level playing field I think an international > standard, even if a little flawed is better than waiting forever for > perfection which will never come. I would extend this ISO 13606-2 to enable > sharable archetypes as well. > > At least then we have a situation where everyone has a common point of > reference. I guess everyone is also a little unhappy, but that is better than > the current situation. I think the standards are virtual in any system, with > adapters to the actual implementations, and to expect anything else is > dreaming of a mono culture, usually your own variety of mono culture of > course. > > There are great ideas to be reused from all players, but to expect the world > to accept openEHR as the only standard is unreasonable. We have actually done > a lot of work to enable the use of archetypes in HL7 V2, not because we thing > V2 is the best and most efficient mechanism, but because its a standard and > it has widespread usage and we gain a backward compatible encoding, which > means we can actually use it. (And the data model is actually transformable > into another encoding if desired) > > Similarly we adapt HL7V2 data for use in the Virtual Medical Record (VMR) and > use ISO data types there, not because they are a seamless match for HL7V2, > but because the ISO data types are a standard and we would otherwise have to > ballot a whole new standard. Its planned to constrain out many, or most of > the esoteric base class methods in the ISO data types for the VMR, but they > are still a compliant subset. > > If the openEHR CKM produced ISO archetypes then it would be a lot more > acceptable to many people, as it is standards based. Currently you have to > buy into the whole game of openEHR, which is I think a problem for many. Its > not a criticism of openEHR, but a desire for a neutral agnostic model. You > may defend the Evaluation class to the hilt, but there is no reason that > every other model has to and this is the problem. We need to accept some > level of imperfect abstraction to enable inter-operability, where everyone > has to provide glue to make it concrete. Its then less than optimal for > everyone, which is I guess what "compromise" and "consensus" is all about. I > still think it provides several orders of magnitude of functionality, over > the current reality. Otherwise we are doomed to the "My Model is better than > yours" war until the last man is standing. > > I also lament the lack of real technical input into the standards, but that's > the reality, I am sure in retrospect many "standards" eg http, smtp, html > could have been designed much better, but inter-operability and pragmatism > has trumped perfection and we all live with an imperfect world. That's why I > think we should give the ISO
ISO 21090 data types too complex? - (longish / CO challenge only)
William,
I follow most of your posting, and I agree that much of the modelling of the
concepts you describe can be done independently of an implementation context.
[There is, of course, the question of tools that best help with this.] I
think, in many instances, you are seeking agreement on your
"mini-vocabularies", and help in defining them, in the first place? I've seen a
number of variants of just Barthel index from country to country. Variations
include the number of values for each component data element; the weighting
that should be applied to those values; the phrases that describe each value of
each activity of daily functions. And you would like some efficient way for
these to be edited, shared, stored and ultimately processable into systems. You
would also, I assume want an efficient way for these to be translatable from
language to language and become truly international standards?
Without going into a broader discussion on Detailed Clinical Models, I'd like
to just tease out the specific ISO21090 issue around CO (Coded Ordinal).
You imply that the enumerations can be associated with an OID, and therefore
made available to receiving systems for processing. I don't see how this is
possible, given the inheritance model for CO, which from my understanding goes
something like this:-
ANY
+ nullFlavor
+ flavorId
+ updateMode
QTY
+ expression
+ originalText
+ uncertainty
+ uncertaintyType
CO
+ code : CD [ 0..1]
+ value: Real [ 0..1]
Now are you actually implying that an OID associated with the code in the CO
not only constrains the vocabulary in the code:CD, but also constrains the
numerical value? In other words, we could have two vocabularies
[ {0, "unable"},
{5, "needs help (verbal, physical, carrying aid" },
{10, "independent"} ]
and
[ {1, "unable"},
{3, "needs help (verbal, physical, carrying aid" },
{7, "independent"} ]
and that these could be differentiated by different OIDs ?? How would that
work in practice? How would systems know that little trick? What terminology
servers know that under some circumstances they may not only have to return a
set of term descriptions, in response to an OID query, but some other
associated (numeric) data as well? Have the CTS/CTS 2 projects considered this
requirement?
Beyond this specific issue, there's a broader catch 22 here. Without doing more
clinical modelling, it is difficult to determine the implementation
requirements of datatypes and more complex data structures. Yet without
implementable datatypes and data structures and tools, it is hard to do, and
engender clinician's enthusiasm to do a great deal of clinical modelling.
That's why I think it so important to get behind and support the good work
already done with the openEHR Clinical Knowledge Manager. It seems such an
excellent vehicle for collaborative clinical modelling - irrespective of the
deployment environment. And certainly a tremendous step up from spreadsheets,
Word documents or pieces of paper! I and my colleagues wasted years in NEHTA
and in a clinical information project prior to that, trying with those archaic
tools to undertake a modest amount of modelling and share it with state
government health departments, clinical colleges etc. Not something I would
wish on anyone.
- eric
On 2010-11-08, at 5:36 PM, Williamtfgoossen at cs.com wrote:
> I see a kind of cooperation emerging here, which is fine and what I like
> most.
>
> Eric points at one are that has my particular interest since I started to
> represent such assessment scales in HL7 v3 space in 2002. We where using the
> existing HL7 R1 datatypes then and found that for the calculation of the
> sumscore the INT could do all counting, but, the specification of each single
> score needed to be done with a CO that at that time did not "allow" for the
> calculation. It dit allow Eric's example for Barthel to be expressed.
> [ { 0 , "unable"},
> { 5, "needs help (verbal, physical, carrying aid" },
> {10, "independent"}]
> However, the CO in science is a number and in statistics it is used
> differently, namely it has an order, a code and can be calculated upon.
> (Although of course there is discussion again on the yes and no's of
> calculating averages, there is no science without debate, but that is for me
> out of scope for what I am asked to discuss).
>
> Eric is very right that we do need more than just data types. We need
> vocabulary, we need units, we need relationships and we need the clinical
> knowledge around it, and proof that the persons doing the work can be trusted.
>
> How I see it from a clinical point of view with in mind the many reuses of
> clinical data is the following:
> bottom line are the atoms of data elements.
> This is the minimum level of information that can bring semantics.
> the number 38 does not say anything. However, if we define the data type as
> being a PQ, more or less equivalent wi
ISO 21090 data types too complex? - (longish)
Stef et al,
In response to Stef's plea for others' opinions, I'd like to add my voice to
Tom's concerns.
I certainly believe that the whole ISO process with respect to health
informatics standards is deeply flawed. As Grahame implies with the datatypes
standard, the process is politically driven and compromises in modelling,
engineering, safety, implementability inevitably occur. The question is how
significant are these compromises and what effect will they have on the
evolution of e-health?
It is highly unlikely that we would have an ISO standard for "Health
Informatics - Harmonized data types for information interchange" without the
monumental effort of Grahame Grieve in producing and managing the draft.
However, it is, first and foremost, an HL7 flavoured standard. The most recent
draft I have seen is, according to its forward, "a shared document between
Health Level Seven (HL7) and ISO". ISO 21090 is undoubtedly complex. One has to
question the value of an international standard, if it is so complex that it
has to be 'profiled' by different organisations before it can be used. By whom,
for what purposes, and by what processes, will such profiling be managed?
ISO 21090 suffers some of the significant flaws that permeate much of HL7
specifications. Tom has already cited the peculiar inheritance hierarchy
amongst others. Another engineering flaw is the pervasive use of cryptic, often
ad hoc enumerations. Even the names of the types wouldn't pass muster in most
quality engineering schools. Names like ENP, HXIT, CO, EN, EN.TN, CD.CV, URG
are simply inexcusable. Levels of indirection never aid readability, and lead
to difficulty in implementation and testing.
It is not necessarily sensible to compare openEHR datatypes with ISO 21090.
They are designed for different purposes. openEHR datatypes underpin openEHR's
reference implementation and archetype object models for building electronic
health record software and so can be augmented by these additional artefacts,
as described below. The ISO datatypes should be able to stand on their own in a
diverse range of implementation environments. This is a much harder task, and
bumps up against fundamental principles of information exchange, whereby the
assumptions of participating systems need to be carefully considered.
Contraints and constraint mechanisms are pivotal here.
A datatype embodies the "agreed" set of values and operations pertaining to
that type. If an item of received data "211414" has been denoted to be of type
integer, then the receiving system "knows" how to process it, and will process
it differently than if it had been denoted as a date ( AKA TS.DATE in
HL7/ISO/DIS 21090 HI-HDTII ). Healthcare includes a very rich vocabulary, and
text-based value sets are common in information exchange. A datatype for coded
text, say, needs to convey the agreed set of values of that type. Let's firstly
consider values for "severity of adverse reaction to medication". Ideally, both
a sending and a receiving system needs to agree on the set of values - and may
behave sub-optimally if one system uses the set { "undetectable", "mild",
"moderate" } and the other uses the set { "mild", "moderate", "severe",
"extreme", "almost inevitably fatal" } , even if these values all came from the
same terminology. In other words, the sending and receiving system are not
actually using the same datatypes in this case.
How do we deal with this in real systems? The United Kingdom's Connecting for
Health program has addressed this in their HL7 V3 - based models by carrying
the constraint within the datatype - in the coding scheme's identifier. So
rather than say the values come from some specific version of SNOMED CT, they
constrain the values to a specific subset using a Refset Identifier. And this
can be carried in instance data.
Now whilst ISO 21090 is capable of constraining text-based value sets, such
constraints are often done by other means - particularly through conformance
statements in non-computable documents, most notably HL7 CDA Implementation
Guides. We are seeing plenty of this in the US, as a result of their Meaningful
Use provisions. In these cases, the datatype does not necessarily carry the
constraint. It almost invariably doesn't. This means that in such transactions,
the receiving system has no way of knowing the true datatype - i.e. the set of
values - for each such data item. The only way for such constraints to be known
to the receiving system is through access to HL7 templates - thus violating THE
principal tenet of HL7's RIM-based information exchange paradigm.
This leads on to one of William Goosen's favourite topics - that of Coded
Ordinals. These have been introduced in ISO 21090 to meet the needs, often
encountered in patient assessment forms, whereby weights are given to
descriptive phrases to indicate the scope of functionality a patient has to
perform, say, activities of daily livin
IHTSDO meeting - term binding presentation available
Hi Sebastian, If I can give my own perspective on this, having been peripherally involved for some time.. 1. Unfortunately, the IHTSDO (www.ihtsdo.org), who is responsible for the ongoing management and development of SNOMED CT, is still a somewhat closed and traditional standards development organisation. It has no publicly accessible wiki of resources ? la openEHR. It does, however, have a substantial community of individuals from member countries and affiliate organisations and several collaborative websites and mailing lists where ideas, contributions, new specifications etc. are documented and evolve. I would guess that the majority of participants are either active in other standards development organisations, or staff/affiliates of member nation health informatics programs such as the UK's NHS Connecting for Health Program, Canada's Infoway, Australia's National E-Health Transition Authority, etc. 2. For many years prior to IHTSDO taking over SNOMED CT from the College of American Pathologists, SNOMED CT embraced a mechanism and format for producing "subsets" of SNOMED CT. About 18 months ago, proposals for a new SNOMED release format and a new Reference Set format (to replace the old subset mechanism) emerged and evolved. These two proposals morphed into a single umbrella specification called Release Format 2, which has now reached Draft for Trial Use status within the IHTSDO. One of the specification documents covers Reference Set formats and is available in part 2 of RF2 at: http://www.ihtsdo.org/publications/draft-for-review-and-trial-use/ . This draft specification includes support for "language refsets", which may be of particular interest to you. Access to the collaborative space where these documents are made available is described at: http://www.ihtsdo.org/about-ihtsdo/collaborative-space/ . 3. To my knowledge there is no formal IHTSDO proposal for a query language to express Refset membership specifications. However, the IHTSDO Terminology Workbench does incorporate quite a sophisticated mechanism for building refsets using an underlying ( and evolving) query-based expression language. Note: these refsets do not necessarily need to be specific to SNOMED. The refset specifications, however, are currently designed to construct static files for distribution alongside the SNOMED core and national extension files, rather than for producing dynamically evaluated termsets for local needs, as might be supported for openEHR templates, say. eric On 2010-05-06, at 5:48 PM, Sebastian Garde wrote: > Hi Thomas, > > do you know if there is a formal way of how RefSets (=the resulting Snomed CT > codes etc.) and the RefSet query (=the query on Snomed CT to get to the > RefSet) are expressed and shared? > Similar to what is described here but based on RefSets: > http://www.openehr.org/wiki/display/term/Ocean+Terminology+Query+Language+%28TQL%29 > > > I agree that RefSets are a good way forward, but they need to be available, > reusable and sharable, etc. > > Sebastian > > Thomas Beale wrote: >> >> I attended the IHTSDO meeting just finished in Copenhagen. Things look >> pretty good for where SNOMED CT is going generally - the RF2 technical >> infrastructure seems relatively well designed. There is a lot of activity in >> content modeling, the IHTSDO workbench and many other areas relevant to >> openEHR. Converely, I believe openEHR will be very important to make SNOMED >> CT work in many places, since it will be via archetypes, templates and >> associated ref sets that information systems will be able to connect to >> terminology in a disciplined way. I believe that ref sets are the future of >> SNOMED CT (and any terminology for that matter) in use in real systems. >> >> I was asked to present a view from openEHR about 'terminology binding', i.e. >> connecting terminology and information models. My presentation is on this >> page http://www.openehr.org/wiki/display/term/Terminology+Binding >> or see the following direct links: >> ? PDF - >> http://www.openehr.org/wiki/download/attachments/5997267/openEHR_term_binding_IHTSDO_april_2010.pdf >> ? PPTX - >> http://www.openehr.org/wiki/download/attachments/5997267/openEHR_term_binding_IHTSDO_april_2010.pptx >> I hope this is useful. I will continue to document IHTSDO-related thoughts >> on the openEHR wiki, and I encourage others to do the same. >> >> - thomas beale >> >> >> ___ >> openEHR-technical mailing list >> >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> > > ___ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
openEHR community on Google Wave
No problem Erik. In any case, I'm sure Google will preserve ALL versions of your emails in its open source repository for posterity. ;-) eric On 2009-12-04, at 11:10 PM, Erik Sundvall wrote: > On Fri, Dec 4, 2009 at 12:39, Diego Bosc? wrote: >> Link to the wiki page? > > Sorry about multiple versions of the mail to the lists. You can ignore > the first one. The mail sent at 13:26 is the correct one containing > more on topic text and with the off-topic stuff moved to the wiki. > > I obviously happened to unknowlinlgy send the message before I had > moved the openEHR-organisation-related content to the wiki page and > continued to edit the mail. The wiki link is in the later version: > http://www.openehr.org/wiki/display/oecom/openEHR+transparency > > // Erik > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Documentation Desparation
T[io]m, I don't think the documentation issue is as clear cut as Tim suggests. Here are my observations:- 1. The existing PDF documentation is excellent - far better than many commercial projects. This is partly due to the use of Framemaker, but mostly due to Tom's commitment, knowledge and skills. 2. In the ideal world, openEHR would have infrastructure that could readily allow for distributed documentation authoring in multiple languages with solid version management, from which PDF, XML and HTML outputs could be autogenerated, and which clearly differentiated Release vs. Draft status of both the specifications to which the documentation referred as well as the documentation versions themselves. Indexing of the documentation artefacts would be comprehensive and capable of being integrated with the HTML documentation bundle(s). 3. There is no affordable suite of products that can easily lead to such an ideal world. Any real-world solution will involve trade-offs. 4. Framemaker can, and does produce the best quality documentation in PDF format. 5. Framemaker is expensive and recent versions only run on Windows. 6. The openEHR community is still small such that few people will have the time, skills and willingness to contribute to authoring documentation. 7. Both Latex and DITA offer potential for single sourcing of documentation in PDF, XML and HTML. Both are supported by a range of cross-platform tools starting at zero cost. From a PDF quality perspective, neither matches Framemaker, particularly in the areas of UML and other diagram integration, version management through change bars or indexing. 8. DITA offers the best potential for distributed authoring, semi- automatic language translation, automated documentation builds. There is a rapidly growing array of tools supporting DITA editing and transformations. 10. DITA transformations to PDF, XML or HTML are normally done using the freely available, java-based DITA Open Toolkit. This DITA-OT is bundled with a number of XML editors, including oXygen. I've run DITA transformations in oXygen on Linux, Mac Os X, and Windows XP - from the same DITA source files on the same networked folder!! The behaviour and output is identical!! One rarely comes across such platform independence. However, tracking down errors within the DITA- OT can be time-consuming and frustrating. 11. DITA-based authoring using these modified XML editors has a long way to go to be usable by non-XML speaking authors - a parallel with the LaTex world, by the way. Framemaker 9 and Framemaker >7.1 supplemented with Leximation's DITA plugin are both potential options as a high quality authoring environment based on DITA. I've dabbled with both, and have my doubts - particularly if there's a desire to broaden the authoring base. 9. The existing Framemaker files could be converted to DITA using the low cost (Windows) tool MIF2Go. This (plus oXygen) could provide a relatively quick and painless path for Tim and others to produce XML/ HTML renditions of the current specifications for incorporation into applications. 12. My recommendation would be to consider migrating to DITA, with the proviso that:- Producing and maintaining documentation is a time consuming ( and often thankless) task. Producing and maintaining documentation of the current quality of the openEHR material will likely be an ongoing challenge to the openEHR community for years to come. eric - On 25/09/2009, at 7:18 AM, Thomas Beale wrote: > Hi Tim, > > I have said often in the past I would be happy to see the documents > move to such a format if: > a) anything remotely approaching the quality of FrameMaker can be > found (I have yet to see it; OpenOffice is not even close) > b) some is going to fund the changeover > > Others in this community may not care about visual quality - I am > interested in feedback on this point. > > I personally have no problem with PDF - it is an output format, not > an editing format, and most tools output PDF (including OpenOffice). > Personally, for readability, I think it leaves wikis and web sites > for dead, but of course the latter have a different function. > > I did have a plan for which I don't currently have enough time, > which is to get FrameMaker 9 (I have done that part of the plan) and > convert all the docs to structured DITA XML (which FM9 supports, > along with a lot of other tools I have never tried - > http://www.ditanews.com/tools/desktop_editors/ > ) from which they could potentially be converted to some other XML > for another tool. I don't have my head around all the publishing XML > formats yet, but I suspect it is possible. On the topic of help > files, it has already been done with FM9 XML output, and integrated > experimentally into a Java environment, so one thing Frame doesn't > do is lock you into anything (unless you think DITA XML i
HL7 and openEHR. was Re: Please respond by Nov. 5th: Known Free/Open Source EHR/EMR Deployment Count.
Ed, In an attempt to "close the gap", I have penned an article indicating how HL7 might make use of openEHR archetypes to overcome some of the inherent shortcomings of RIM based modelling for CDA document entries. You can read it at: http://www.openehr.org/wiki/display/stds/openEHR+Archetypes+for+HL7+CDA+Documents Interested in your thoughts about how this could be progressed. regards, Eric Browne Ed Hammond wrote: > Thanks. I agree that things are moving ahead. I wish we could remove > some > of the animosity (maybe I am reading it worng) towards HL7 (not from you), > and close the gap between the two efforts. > > best Regards. > > Ed > > > > Thomas Beale >aninformatics.com To > > For openEHR technical discussions > Sent by: > openehr-technical cc > -bounces at openehr. > org Subject >Re: Please respond by Nov. 5th: >Known Free/Open Source > 11/06/2008 01:11 EHR/EMR Deployment Count. > PM > > > Please respond to > For openEHR > technical > discussions > l at openehr.org> > > > > > > > William E Hammond wrote: >> Thomas, >> >> I am very impressed with these statistics. I was not aware of the >> penetration of openEHR into that volume of use. Congratulations for a > hugh >> success. Can you help me identify the actual systems that are in use in >> Australia, Netherlands and Brazil. I am specifically interested in the > EHR >> systems that use openEHR. We need to build on those successes. >> >> Thanks for sharing this information. >> >> Best Regards, >> >> Ed Hammond >> > *Ed, > > I should stress that these are pure openEHR systems; systems based on > archetypes of some kind include Systematic (SSE) in Aarhus, Denmark, and > Obstet in Australia. Both companies have expressed serious interest in > 'going official', and I happen to know that their architectures are > sufficiently close to the archetype / template idea that it is feasible. > I dont have any numbers on EHRs in these systems but I would expect in > the hundreds of thousands, based on the catchment areas they serve. > Although I said at the beginning that I don't think it is that useful a > statistic, it's not a bad brut measure of uptake, so let's see if we can > gather some better numbers, for interest's sake. > > One reason for success of at least our own EHR server (Ocean > Informatics) is that its performance is good - sub-0.5 second for > everything so far, with a typical concurrent load equivalent to about a > 1,000 bed hospital. I don't yet have performance numbers for harder > population queries, but mundane population queries across 10,000 - > 250,000 EHRs are fast. > > This isn't the place to advertise, but I think it is reasonable to at > least allow the community to know that real performance is indeed > possible and feasible to implement in openEHR. If others agree, it may > be the time to do a bit of a poll and start putting harder data on the > 'who is using it' webpage. > > - thomas > > * > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
Insight into the choices to be made in standards for the electronic exchange of health record information
Thomas, Strange you should malign the Russians so. In 1994 I was on a joint British-Russian expedition to investigate the mid-Atlantic ocean ridge, over 4km deep. The only submersibles to get to those depths as a pair, and photograph the "black smokers" and attendant sea creatures were Russian. The Russian video footage (along with the British Channel 4 crew), was all shot with Betamax. Quality, as you say, is paramount for this sort of work. VHS was never, considered. I'm sure the same would be true of the Russian TV studios. So too, is quality of paramount importance in health care. Let us _never_ lose sight of this requirement in the pursuit of interoperable healthcare information systems and the evaluation of the solutions that are marketed at us. eric On 08/10/2008, at 7:33 PM, Thomas Beale wrote: > Stef Verlinden wrote: >> Thomas. >> Op 7-okt-2008, om 17:10 heeft Thomas Beale het volgende geschreven: >> >>> Governments need to understand these realities, or they will >>> continue >>> to find it difficult to see how to apply any of the competing >>> standards available today. I have to say that I don't find this >>> report particularly helpful, because it gives very little in the way >>> of really solid advice on how governments should move forward. >> >> Although I agree with you, you also know where we're coming from: a >> situation where two camps dug in deep, proclaimed that their solution >> was the best and didn't want to look over the fence. This is a >> consensus document generated by all parties involved and as such a >> big >> step ahead. >> >> Another thing is that this document is about the interational EHRCOM >> standard 13606 and not about all the fantastic things we could do >> once >> openEHR derived commercial solutions finally become widely available. >> Since openEHR isn't an international standard, nor widely implemented >> as a commercially product, so that people can see it's beneifits, >> your remarks seem academic. Furthermore it's intended audience is the >> people at CEN and ISO, not governments. For that purpose we'll try to >> create a less technical document. > > well none of the standards mentioned are widely implemented. I would > be > interested to know of any commercial offerings in fact. > >> >> I completely agree with your remark that Governments need to >> understand these realities. Again I'll invite everbody to come up >> with >> clear examples, proof and/or bussiness models, which are >> understandable for decission makers (technical lay-man) so they can >> get a good understanding of these realities and the consequences of >> their choices. So far the discussion is only accesible for the happy >> few who have the time, enthousiams and (some degree of:-)) technical >> understanding to dug in deep. To convince an average decission maker >> you have a couple of minutes. If we (as the openEHR community) aren't >> capable of selling 'our' product to these decission makers in an >> understandable and concise manner, we still have the best product in >> the world but nobody will use it. So far I haven't seen any document/ >> example/ bussiness case that can convince a decission maker/ >> goverment >> why they should consider using openEHR. > > did you have a look at the PPT at the top of this page - > http://www.openehr.org/shared-resources/getting_started/government_orgs.html > >> >> As you might know this is what we call the Dutch or Philips syndrome >> over here: Back in the eighties Philips created an brillant new and >> innovative product: a videoplayer called Video 2000. Since everybody >> was convinced that such an superior system would sell itself not much >> attention was paid to marketing. >> At the same time a videoplayer which was on all fronts inferior to >> the >> Philips player was developped: the VHS player. Since it's producers >> knew that marketing was key, they promoted the product as aggresively >> as they could and with great succes. Since for the end user the VHS >> already was a big step forward (untill then there was no way to >> record >> and play video at home) and all they heard about was VHS they bought >> into that system and took over the market. Any simllarities here? > > I guess that's why some 'standards' bodies need a dedicated marketing > budget and personnel. I didn't know about Video 2000, but people > always > talk about Sony Beta losing the race. In fact they did not; betamax > has > been used in every TV studio in the world (probably not Russia I > guess) > for years - the part of the market that needed quality. There are many > myths like this about the marketplace. > > The key technical failing of many of the standards is that they are > just > not integrated; they are competing and overlapping. And yet what is > most > needed is a coherent framework, not a mish-mash of disparate standards > each designed to solve one problem in isolation. The very existence of > IHE is
Insight into the choices to be made in standards for the electronic exchange of health record information
Stef, I don't question your intentions, but I definitely question the value of such a document in helping the discussions at CEN and ISO level. I can only see it confusing the already muddied waters. You simply cannot advance the cause of harmonisation of standards, or choosing between standards, by dumbing down the issues to such an extent! I'm sorry, Stef, if my response seems brutally rude, but I'm sure that the level of debate at CEN and ISO must be more sophisticated than the simplistic suggestions embodied in your document. If not then we are centuries away from the sort of IT-enabled healthcare systems that many of us can imagine. And as for your analogy regarding the "Dutch Syndrome", we are not talking about marketing a product, we are talking about standards and specifications for e-health interoperability, decision support and much more, that affect our own health and the health of others. Please reconsider taking your document to those meetings. regards, eric browne On 08/10/2008, at 7:05 PM, Stef Verlinden wrote: > Thomas. > Op 7-okt-2008, om 17:10 heeft Thomas Beale het volgende geschreven: > >> Governments need to understand these realities, or they will >> continue to find it difficult to see how to apply any of the >> competing standards available today. I have to say that I don't >> find this report particularly helpful, because it gives very little >> in the way of really solid advice on how governments should move >> forward. > > Although I agree with you, you also know where we're coming from: a > situation where two camps dug in deep, proclaimed that their > solution was the best and didn't want to look over the fence. This > is a consensus document generated by all parties involved and as > such a big step ahead. > > Another thing is that this document is about the interational EHRCOM > standard 13606 and not about all the fantastic things we could do > once openEHR derived commercial solutions finally become widely > available. Since openEHR isn't an international standard, nor widely > implemented as a commercially product, so that people can see it's > beneifits, your remarks seem academic. Furthermore it's intended > audience is the people at CEN and ISO, not governments. For that > purpose we'll try to create a less technical document. > > I completely agree with your remark that Governments need to > understand these realities. Again I'll invite everbody to come up > with clear examples, proof and/or bussiness models, which are > understandable for decission makers (technical lay-man) so they can > get a good understanding of these realities and the consequences of > their choices. So far the discussion is only accesible for the happy > few who have the time, enthousiams and (some degree of:-)) technical > understanding to dug in deep. To convince an average decission maker > you have a couple of minutes. If we (as the openEHR community) > aren't capable of selling 'our' product to these decission makers in > an understandable and concise manner, we still have the best product > in the world but nobody will use it. So far I haven't seen any > document/ example/ bussiness case that can convince a decission > maker/ goverment why they should consider using openEHR. > > As you might know this is what we call the Dutch or Philips syndrome > over here: Back in the eighties Philips created an brillant new and > innovative product: a videoplayer called Video 2000. Since everybody > was convinced that such an superior system would sell itself not > much attention was paid to marketing. > At the same time a videoplayer which was on all fronts inferior to > the Philips player was developped: the VHS player. Since it's > producers knew that marketing was key, they promoted the product as > aggresively as they could and with great succes. Since for the end > user the VHS already was a big step forward (untill then there was > no way to record and play video at home) and all they heard about > was VHS they bought into that system and took over the market. Any > simllarities here? > > > Cheers, > > Stef > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Is there a UML class diagram for templates?
Dear list, Here are some points clarifying the status of openEHR UML2.1 model artefacts cited in Erik Sundvall's email. 1. This rendition of the model is only 95% complete and has some errors. 2. Subject to agreement and some quality review, I would be happy for the model, diagrams and XMI 2.x to be housed and managed on the openEHR site. 3. The healthbase URLs given below are only temporary and the files will disappear from here. 4. All diagrams are based on the current, published 1.0.1 Release of the openEHR specifications. 5. I also hope to produce a separate rendition to reflect the forthcoming 1.0.2 Release of the openEHR specifications. 6. Expect at least one month before finalised artefacts could be available ( unless someone else volunteers to complete the work ) 7. The models/diagrams/XMI were created with the lean, elegant, cross platform tool BOUML ( http://bouml.free.fr ), which also provides code generation support for C++, Java, Python, IDL. 8. I am amenable to the Creative Commons Licence, but would prefer to donate the work to the openEHR Foundation and let them decide the appropriate copyright, which I suspect should align with the standard openEHR Foundation copyright notice published in the specifications. 9. I would rather the work not be widely publicised until it is complete and passed at least one quality review. That said, I would be comfortable for those interested on the openehr-technical list to investigate its utility and shortcomings and let me/others know their thoughts. regards, eric On 28/08/2008, at 12:13 AM, Erik Sundvall wrote: > Hi! > > I imported an openEHR UML (XMI) file created by Eric Browne (using > BOUML) into the Eclipse-based Topcased environment a couple of minutes > ago and saw that most template related classes were implemented. Using > Topcased autolayout and some manual adjustments produced a diagram, > see http://www.imt.liu.se/~erisu/2008/08/rough-template-diagram.gif. A > nicer diagram by Eric Browne is available at > http://www.healthbase.info/openehr/UML/index.html#refpackage138545 > (The entry link to start exploring his work is at > http://www.healthbase.info/openehr/UML/index-withframe.html) > > Eric: What is the copyright status of your model files? Can I share > the source XMI file and any derived works in public? If you don't > have another license in mind I'd suggest using > http://creativecommons.org/licenses/by/3.0/ > > As written in some other threads, more info about a related experiment > (aoutoconverted from openEHRs MagicDraw files) is available at > http://www.openehr.org/wiki/display/dev/Experimental+generation+of+code+and+documentation+from+UML > Links to source files are available in a recent comment on that page. > > Thomas: What tool are you currently using to produce UML for the > template spec document? > > Best regards, > Erik Sundvall > erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 > > > > On Wed, Aug 27, 2008 at 13:49, Adam Flinton > wrote: >> Thomas Beale wrote: >>> Adam Flinton wrote: >>> >>>> Preferably in Eclipse UML2...? >>>> >>>> If so does it then include the archetypes class model as well? >>>> >>>> >>>> >>>> >>> *The UML for the forthcoming openEHR template model is online in the >>> latest AOM draft (some changes to AOM of ADL 1.4 vintage) and >>> Templates >>> draft, available at the page >>> http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes >>> >>> However, if you are after UML for the current .oet file format, I >>> don't >>> think it is published, but I would imagine it already exists - >>> publishing it should be no problem. Can you indicate which one you >>> are >>> after? >>> >>> - thomas beale >>> >>> * > >> Sorry for the delay. >> >> What I was wondering about is whether we had/could have a complete >> model >> for OpenEHR Templates + Archetypes. >> >> i.e. if one had the AOM in Eclipse XMI then one could generate Java >> classes or >> >> e.g. >> >> http://www.eclipse.org/modeling/m2t/?project=jet >> >> or if you want to go the whole hog: >> >> http://www.openarchitectureware.org/ >> >> & one could create Graphical editors via GMF, compare models, run OCL >> constraints etc.etc. >> >> What is more, maintaining the AOM /TOM via the Eclipse UML tools >> means >> that the model is machine readable/processable and the tooling is >> free/open source (though you could use tooling bas
character sets and languages in openEHR
Tom, I have pondered the same issue before. I think it unlikely that language would change inside an entry, but I did think of the possibility of medicines, e.g. chinese medicines, or part thereof, being described by specificly foreign names. cheers, eric [ btw, you may wish to check your computer's date/time. I know Queensland lags in some respects, but 3 days would make the cows very sore! :-)] On Sun, 7 Mar 2004, Thomas Beale wrote: > > A couple of technical questions prior to declaring the 0.9 baseline in > openEHR: > > One of the major openEHR implementors here in Australia has suggested > moving the attributes 'language' and 'charset' in the class DV_TEXT to > some higher level class - e.g. COMPOSITION, since almost all the time it > is the same on DV_TEXT items in a given EHR. We don't think it should be > that high, since language cannot be guaranteed the same throughout a > COMPOSITION (in their scheme, you would set the attribute on COMPOSITION > and then override it on lower nodes if they were different; however, I > am very wary of this sort of logic - HL7 uses it a lot and it really > complicates things for developers; at the moment we prefer to avoid it > completely). One possibility is to move the language attribute to the > ENTRY class, on the basis that an ENTRY is the minimium indivisible unit > of information in openEHR (this is true, even for 'large' Entries like a > microbiology test result). It was initially on DV_TEXT for safety > reasons - you would always know what language a text fragment is in > (this is important for words which are the same apearance but different > meaning in different languages); however, ENTRY is probably just as safe > from this point of view. > > Q: can anyone think of a scenario where there could be multiple > languages inside an ENTRY? > > Character set is more difficult to work out. So far, we have specified > that Unicode should be used in all strings. This means that in theory > there is no need to record the character set name (e.g. iso-latin-1, > iso-greek, etc). However, there is still a need to choose between UTF-8, > UTF-16 and so on in Unicode. And in any case, I am unsure if all > implementation technologies implement unicode in strings; is there a > legacy reason to store non-unicode character set names anyway? > > - thomas beale > > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
[Fwd: RE: Subject of care]
Sam, I take Tom's position. The issue is whether there is a one to one mapping between subject of care and an EHR. >From a health perspective, a foetus can be considered as a subject of care in its own right. A foetus is tightly coupled to a mother, but is sufficiently distinct for there to be a need for a separate EHR under certain circumstances. The question is when do we spawn a new record? Under normal circumstances, this would probably occur at birth, partly since the foetus becomes a person under law, partly because it becomes an entity predominantly independent of the mother, partly because prior to birth there is rarely a need for information specifically regarding the foetus. However, when the foetus does become a subject of care, i.e. measurements and interventions are undertaken specifically for the benefit of the foetus, there are good grounds for spawning a separate EHR. Either approach requires a more complex EHR model. But surely the raison d'etre of an EHR is to promote the care of a subject? Or is it being proposed for some other reason of which I am unaware? eric On Thu, 19 Dec 2002, Sam Heard wrote: > Tom > > This is not necessary or appropriate - as Matthew has said - placenta is > both! It is important that our solution allows information about another > person to be in an EHR - family history is a good example. We will not link > between peoples EHRs - ever in my opinion. > > Cheers, Sam > > > -Original Message- > > From: Thomas Beale [mailto:thomas at deepthought.com.au] > > Sent: Thursday, 19 December 2002 1:43 AM > > To: Sam Heard > > Cc: openehr-technical at openehr.org > > Subject: Re: [Fwd: RE: Subject of care] > > > > > > > > I think that the only systematic approach is to make a new EHR for each > > genetically distinct individual. This means making an EHR for a foetus > > as soon as anything at all is to be measured about it, and also storing > > the link of this EHR to that of the mother. If the foetus dies in utero > > or is aborted, then its EHR shows this properly as "death" jsut as it > > would be shown in a normal person's record. As for situations where the > > individual's DNA distinctness is not totally clear like the bone marro > > transplant situation, I don't think that is a problem. Observations can > > be made on genetically different material to the patient, in the > > patient's record, as long as these observations relate to the care of > > that patient. E.g. blood tests, other tests made to a sibling for the > > sole purpose of doing a transplant into the patient - should probably go > > into the patient's EHR... > > > > But I do think we need to forget the idea that because a foetus is not > > really a person, it is not a possible subject of an EHR. I think we have > > to work on genetic distinction and distinct organism (whether called > > "human" or not) instead. > > > > thoughts? > > > > - thomas > > > > Sam Heard wrote: > > > > >Matthew > > > > > >Great scenario's > > > > > >>1. If prenatal diagnosis is being done by chorionic villus sampling > > >>(CVS) in a twin pregnancy (which does happen) then it is the placenta > > >>- or rather the placentas - which are sampled. Each placenta has a > > >>DNA genotype matching that of the fetus attached to it (ie not the > > >>mother) as the placenta is an extension of the fetus. If however the > > >>fetus is an extension of the mother, then are we really saying we > > >>like the idea that the placentas may have to appear as multiple > > >>"temporary" organs of the mother, which are different in every > > >>pregnancy, and which never share her total genotype? A likely outcome > > >>would be selective termination of one twin (the affected one, on the > > >>basis of a molecular finding and either a makable or a confidently > > >>predictable clinical diagnosis) leaving the unaffected one to go to > > >>term. Thus a part of the mother is diagnosed clinically and > > >>molecularly, findings which are important for the mother later on, in > > >>that they'll trigger appropriate care next time around, but which > > >>*must not* be confused with her own clinical diagnoses or test > > >>results. > > >> > > > > > >This example is a very good one - it shows that there is a need to > > identify > > >the fetus over and above its relationship with the mother. I have > > suggested > > >that we use a local label for this - could be LOCAL:Twin1_2002. - the > > >relationship for the information is FETUS. The important thing here is > > that > > >we have the idea of subject of care - a unique identifier (or self) > > and the > > >relationship. > > > > > >The sampling is the taking of a histological sample of a body part - the > > >subject is the FETUS. There will be a procedure record, a sample and a > > >histological report - all with the fetus as the subject of care for the > > >data - in a composition that is part o
[Fwd: RE: Subject of care]
Very pragmatic, but ... If dealing with the 20% of 'abnormal' problems later, means completely redesigning and reimplementing a solution, then your pragmatic approach may not be the best. Designing and building a national or international EHR-based healthcare system is like getting someone to the moon - it is a complex and expensive exercise. Better to pre-empt the abnormal situations and build something that you hope will succeed, than to build a rocket that you know will fail. eric On Wed, 18 Dec 2002, Gerard Freriks wrote: > Hi, > > Yes nice, but ... > > Dealing with 80% of all 'normal' problems that can be encountered is > difficult enough. > 'Give me a solution and I will find the problems, the scenario's that will > brake the solution' > > The 20% of 'abnormal' problems can (and will have to be) dealt with later. > > Gerard > > > On 2002-12-17 14:24, "Sam Heard" wrote: > > > > > Matthew > > > > Great scenario's > > > >> 1. If prenatal diagnosis is being done by chorionic villus sampling > >> (CVS) in a twin pregnancy (which does happen) then it is the placenta > >> - or rather the placentas - which are sampled. Each placenta has a > >> DNA genotype matching that of the fetus attached to it (ie not the > >> mother) as the placenta is an extension of the fetus. If however the > >> fetus is an extension of the mother, then are we really saying we > >> like the idea that the placentas may have to appear as multiple > >> "temporary" organs of the mother, which are different in every > >> pregnancy, and which never share her total genotype? A likely outcome > >> would be selective termination of one twin (the affected one, on the > >> basis of a molecular finding and either a makable or a confidently > >> predictable clinical diagnosis) leaving the unaffected one to go to > >> term. Thus a part of the mother is diagnosed clinically and > >> molecularly, findings which are important for the mother later on, in > >> that they'll trigger appropriate care next time around, but which > >> *must not* be confused with her own clinical diagnoses or test > >> results. > > > > This example is a very good one - it shows that there is a need to identify > > the fetus over and above its relationship with the mother. I have suggested > > that we use a local label for this - could be LOCAL:Twin1_2002. - the > > relationship for the information is FETUS. The important thing here is that > > we have the idea of subject of care - a unique identifier (or self) and the > > relationship. > > > > The sampling is the taking of a histological sample of a body part - the > > subject is the FETUS. There will be a procedure record, a sample and a > > histological report - all with the fetus as the subject of care for the > > data - in a composition that is part of the mothers EHR. It may be copied to > > the child's EHR in the future - I have thought about the transform required > > to do this and it should be relatively easy if the relationship of the two > > records is stated first. > > > >> 2. Bone marrow transplantation, where it may be necessary to > >> distinguish that the post-transplant patient may still have a > >> haemoglobin variant, but a different one to the one they were treated > >> for, and accordingly no disorder to go with it, but will still be > >> genetically as they were before the treatment in every other organ. > >> Also the donor was most probably selected from the same family, so > >> confidentiality may be slightly different...? > > > > Interesting - who is the subject of care then? I guess this will be deduced > > from the data - I do not think that we can say the origins of all the states > > in a person that arise following a donation - at times it may be ambiguous > > (graft v host). > > > > We have considered 'donor' to be the relationship - but the person may have > > a relationship with the person apart from this? I do not think that the > > subject of care needs to be the donor then - it can be the family member as > > it is known who they are. Interesting! > > > >> It seems to me that we can either organise our concepts to make this > >> kind of record easier and more obvious, or we can begin to inbuild > >> problems for later on (eg if the fetus is part of the mother, having > >> to explain to all our knowledge agents that this might not extend to > >> genotypes, or if it does, then by chance rather than biological > >> imperative etc...). In the event of one of two fetuses being > >> affected, and one pregnancy being terminated, what is the result in > >> the record to indicate the original number of conceptions, the fact > >> that a genetic risk actually produced a fetus with a prospective > >> problem, and the DNA and other data originated in the process of the > >> testing of the CVS sample? It would be wrong, I feel, to treat the > >> fetus' diagnosis as one of the mother, as confusion here could lead > >> to all kinds of erroneous conclusions (one fetus had sickle cell -> > >> mot
Categorising EHR Content
Tom & Sam, Thanks for taking the time to explain the openEHR use of OBSERVATION, EVALUATION and INSTRUCTION and how these do not limit the ability to express state and events in a variety of clinical models. When one moves from thinking in the healthcare space to thinking in the recording space it is easy to misinterpret terminology, particularly in simplistically mapping state to OBSERVATION and healthcare actions to INSTRUCTION. I would, however, still like to crusade for the importance of the notion of non-care event, and its usefulness in future care. I appreciate it can easily be catered for in archetypes, but would like to re-stress its importance. To start with your statement, Tom, regarding the usefulness of recording the Bali-bombing in a subject's EHR: > yep. And consider: while it would in theory be possible to put something > in the EHR indicating the fact of the Bali bombing, this is in fact of > no use to patient care - we have to the know the patient's point of > view, not just the independently reported fact from the ABC reporter. > Were they in the nightclub? Around the corner? Heard the blast (ear > damage)? The very knowledge of the event totally transforms the care that is provided, as you, yourself indicate. I doubt that a person admitted to an ICU with burns to his/her foot would normally be tested for hearing loss! The normal course of healthcare is one of deducing the event. From thence forth, domain knowledge, harnessed from many similar events to other subjects, is used to guide the course of analysis and treatment. The analysis and treatment is, of course, modulated by the individual's symptoms, as you suggest. In fact, this process occurs so frequently that the first part of it is given a special name - diagnosis. It's just that diagnosis is usually limited to a subset of the event space (i.e. those change_of_state events that are taught in medical schools). Again, consider a 25 year old female who presents at a clinic having missed 2 successive periods. The GP, having considerable knowledge of a generalised pregnancy event, suspects, tests for, and diagnoses pregnancy. The event, and domain knowledge thereof, is more important than the recording of the observation "missed 2 successive periods". Now one could view pregnancy as an aggregation of observations. One could view pregnancy as an evaluation from observations. One could view pregnancy as an event, about which special data should be stored ( subject's weight, estimated date of conception, HbA1c, etc. ) I think that there is value in the last of these views, independent of the first two. >From an epidemiological point of view, it is useful to store non-care events. In their absence, one could trawl through a population's set of EHR's and discover a correlation between first degree burns, hearing loss and trauma. But I am not convinced this would lead to a clinical guideline for dealing with bomb victims. I seem to have drawn the discussion away from the topic of this list. Perhaps I should redirect further discussion to openehr-clinical instead? Thanks again for your explanations. regards, eric On Fri, 6 Dec 2002, Thomas Beale wrote: > > Sam Heard wrote: > > >Eric > > > >You are into the territory that Computing and Health care have been swimming > >in for many years - how to model health care - rather than health care > >recording. > > > exactly right. The models we have developed describe in a regular way > the concept of "recording" - whcih they have to, because there is no > other way for information to be committed to any medium. Thus, a model > of recording has to have phenomenologically primacy in any list of > models which apply to the information in question. Models of concepts > like "real world event", "accident" etc will appear as archetypes. > > > >b. bali bombing > >Observation .. was in Kuta and hit by debri ... evaluation .. Very > >distressed and requires counselling .. Instruction - referral to counsellor > >who is working with such clients. > > > yep. And consider: while it would in theory be possible to put something > in the EHR indicating the fact of the Bali bombing, this is in fact of > now use to patient care - we have to the know the patient's point of > view, not just the independently reported fact from the ABC reporter. > Were they in the nightclub? Around the corner? Heard the blast (ear > damage)? etc Again - we need the patient's account (or that of other > relevent person, e.g. patient's friend, or other bystander who knows > what happened to te patient) - and this is recorded as OBSERVATIONs > whose content include statements by the patient and/or others, and > clinical observations. > > >c. job redundancy > > > >Observation .. made redundant... evaluation ,, this is a problem that is > >worth noting in persistent data. > > > - similar argument - we need the patient's experience of this, not a > news report
Categorising EHR Content
Sam, OK. By extrapolation, then, any documentation of a healthcare event or non-healthcare event that has occurred in the past, is recorded as an observation? Any healthcare event that has not yet occurred, but envisaged, is recorded as an instruction? When a patient is discharged from hospital, all actions that were taken on the patient are recorded as observations. e.g. appendectomy ? This means the semantic knowledge of state vs. change_of_state is buried pretty deep in the record. eric On Fri, 6 Dec 2002, Sam Heard wrote: > > Eric > > You are into the territory that Computing and Health care have been swimming > in for many years - how to model health care - rather than health care > recording. > > All of these are events - but in the record they will cause recordings that > are observations, instructions and evaluations. > a. heart attack > Might start with the patient observation of chest pain...an obseravtion of > ECG... an instruction to order a blood test.. an evaluation of a > differential diagnosis.. the observation of the result of the test.. a > diagnosis. > > b. bali bombing > Observation .. was in Kuta and hit by debri ... evaluation .. Very > distressed and requires counselling .. Instruction - referral to counsellor > who is working with such clients. > > c. job redundancy > > Observation .. made redundant... evaluation ,, this is a problem that is > worth noting in persistent data. > > ETC... > > d. rape > e. snake-bite > f. car accident > g. surgical error > > We are modelling the health record not health care - attempts to model the > former have been going on for decades and their work is all over the web. > > Cheers, Sam > > > > -Original Message- > > From: Eric Browne [mailto:eric at montagesystems.com.au] > > Sent: Thursday, 5 December 2002 10:31 AM > > To: aniket Joshi > > Cc: sam.heard at bigpond.com; openehr-technical at openehr.org > > Subject: Re: Categorising EHR Content > > > > > > Aniket, > > > > I have refreshed myself on openEHR's clinical model > > terminology, but I still think you miss my point. > > openEHR has three types of EHR_Entry, namely > > OBSERVATION, EVALUATION, INSTRUCTION. > > > > I am using "event" in the natural language context, > > rather than the hijacked Event Summary context. My > > "event" refers to a non-care event ( predominantly ). > > Such "events" do not fall under any of the 3 EHR_Entry > > subclasses. Some examples: > > > > a. heart attack > > b. bali bombing > > c. job redundancy > > d. rape > > e. snake-bite > > f. car accident > > g. surgical error > > > > All of these lead to a change of state! I don't see how > > any of these could legitimately be classified as any of > > OBSERVATION, EVALUATION, INSTRUCTION. Yet, > > data describing these "events" should be captured in > > the EHR. The data could and should exist independent > > of any healthcare action. In some cases, there may not be > > any healthcare action following the event. I can conceive > > of situations where subjects might wish to record the event > > (consider rape) in their EHR, prior to any visit to a > > health provider. > > > > The only way current models appear to deal with this is > > by lumping them into either OBSERVATION, or, even as > > you suggest, INSTRUCTION (represented by ACTION_SPECIFICATION). > > > > I think the problem arises because there is no "higher" > > level representation of an event ( either definition ). > > This is my point. At the high level we should separate > > out state, activities/events that change state, risks. > > > > * state can be categorised as OBSERVATIONS or EVALUATIONS. > > * change of state can be categorised as _health_care_actions > > (openEHR's INSTRUCTIONS?) or non_health_care_events. > > * risks need their own class. > > > > Clinicians often use OBSERVATIONS and EVALUATIONS to deduce > > the event. This is often called diagnosis. A subject might > > attend a GP with severe pain and swelling in the hand. The > > GP makes some OBSERVATIONS, undertakes a test (issues > > an INSTRUCTION) and deduces that an event "funnel-web > > spider bite" has occurred. However, sometimes we ( subject, > > clinician, other person ) know the event a-priori. > > Either way, the event(my definition) is a first class > > object in its own right, and should be represented as > > such in the EHR. >
Categorising EHR Content
Aniket, I have refreshed myself on openEHR's clinical model terminology, but I still think you miss my point. openEHR has three types of EHR_Entry, namely OBSERVATION, EVALUATION, INSTRUCTION. I am using "event" in the natural language context, rather than the hijacked Event Summary context. My "event" refers to a non-care event ( predominantly ). Such "events" do not fall under any of the 3 EHR_Entry subclasses. Some examples: a. heart attack b. bali bombing c. job redundancy d. rape e. snake-bite f. car accident g. surgical error All of these lead to a change of state! I don't see how any of these could legitimately be classified as any of OBSERVATION, EVALUATION, INSTRUCTION. Yet, data describing these "events" should be captured in the EHR. The data could and should exist independent of any healthcare action. In some cases, there may not be any healthcare action following the event. I can conceive of situations where subjects might wish to record the event (consider rape) in their EHR, prior to any visit to a health provider. The only way current models appear to deal with this is by lumping them into either OBSERVATION, or, even as you suggest, INSTRUCTION (represented by ACTION_SPECIFICATION). I think the problem arises because there is no "higher" level representation of an event ( either definition ). This is my point. At the high level we should separate out state, activities/events that change state, risks. * state can be categorised as OBSERVATIONS or EVALUATIONS. * change of state can be categorised as _health_care_actions (openEHR's INSTRUCTIONS?) or non_health_care_events. * risks need their own class. Clinicians often use OBSERVATIONS and EVALUATIONS to deduce the event. This is often called diagnosis. A subject might attend a GP with severe pain and swelling in the hand. The GP makes some OBSERVATIONS, undertakes a test (issues an INSTRUCTION) and deduces that an event "funnel-web spider bite" has occurred. However, sometimes we ( subject, clinician, other person ) know the event a-priori. Either way, the event(my definition) is a first class object in its own right, and should be represented as such in the EHR. Perhaps the data pertaining to a non-care event could be recorded as "OBSERVATIONS", but some of this data, may not explicitely be OBSERVATIONS of the subject_of_care. The data qualifies the event, not the subject_of_care. I hope I have explained myself a little more clearly. eric On Wed, 4 Dec 2002, aniket Joshi wrote: > Dear Eric and Sam, > I do agree to these views.When we are trying to > capture EHR any change in the medical state needs to > be recorded and classified.But we are trying to > categorize the formats of recording these changes in > state. > A stage lower than the one described. > The level described below is comparable with Events in > the EHR and the classification. > What I meant in the earlier discussion was the > classification of the data describing the event. > Those could be classified as different observations > instructions and actions. > By your contribution we have a categorisation of the > different events. > "The "Service-Action" view of the > world portrays the burn_event as an attribute > (observation) of the emergency care act" > Yes it should and it would in the prospective view,in > the retrospective view or a guideline an emergency act > will be a part of the BURNS SERVICE ACTION. > What I Mean to say is the BURNS EMERGENCY ACTION > should comprise of X..Y...Z...a system generated > unsolicited guideline with the related fields in the > record has to entered by the HCP. > Thus the record will be part of the Burns Emergency > act. > To summarize I think the idea of categorizing the EHR > according to instructions,observations and actions and > the event wise categorization can be agreed upon and > implemented. > Comments > ANIKET > --- Eric Browne wrote: > > Sam et al, > > > > Sometimes it is beneficial to stand back and review > > the purpose > > of EHRs, when trying to categorise content. No doubt > > you have done > > this far more often than me, but for yet another > > high level perspective > > here is my current view. > > > > > > Categorising EHR Content > > > > > > [ in the following discussion, the word "subject" is > > used. This refers > > to the person who is the subject of a particular > > EHR. Information > > contained in the EHR pertains to that subject. ] > > > > In order to be as effective as possible, an EHR > > should record aspects of: > &g
Categorising EHR Content[long] was RE: Action specifications
Sam et al, Sometimes it is beneficial to stand back and review the purpose of EHRs, when trying to categorise content. No doubt you have done this far more often than me, but for yet another high level perspective here is my current view. Categorising EHR Content [ in the following discussion, the word "subject" is used. This refers to the person who is the subject of a particular EHR. Information contained in the EHR pertains to that subject. ] In order to be as effective as possible, an EHR should record aspects of: 1. the subject's past, present, expected and desirable state. 2. changes in the subject's state. 3. the events and processes that led to, or might lead to, changes in subject state. 4. risk factors that might influence subject state. In order to do this, we must define the concepts/entities that express state, processes and risks. Sometimes concepts are composed of other concepts. Sometimes concepts are specialisations or generalisations of other concepts. Sometimes concepts are relationships between two or more other concepts. Patient state can be represented by:- * a set of reported symptoms. * a set of measurements, observations, test results. * diagnoses - classification by symptoms into known diseases/conditions. * prognoses - expected symptoms or outcomes. * outcomes from some past, present of future process. * outcomes from some past event. * body parts and accessories ( e.g. pacemaker, organ transplant, walking frame). Events & Processes can be represented by:- * diagnostic tasks. * prognostic tasks. * treatment tasks. * medication prescriptions. * tests. * the relationships with participants involved in the processes. * accidents or events that sigificantly altered or might alter the subject's state. Risk factors can be:- * environmental (e.g. adjacent to lead smelter). * behavioural (e.g. smoking). * genetic (e.g. familial history of cancer). * allergic reactions that have occured to this subject. It seems to me that openEHR's view of EHR content is still biased towards the healthcare provider's view of the world, as if a person's lifelong health status can be represented soley by a linear ( in time) sequence of "actions" by healthcare providers. It should be remembered that many of the "events" that change a subject's state are independent of "intentional acts of health professionals". In twenty or thirty year's time, we may be mature enough to realize that the event "person X was made redundant from their employment today" may have significantly greater effect on X's future health ( or the health of a close friend/relative ), than "person X was diagnosed with mumps today". If this is the case, then surely such events should legitimately be recorded in an EHR? I have problems with lumping too many things under observations, without distinguishing between "state" and "changes to state". Consider the following:- A. The _observation_ "subject weighs Y kilograms" is a state recording. B. The _observation_ "subject experienced severe pain in lower left abdomen" is an event recording. An event causes a change of state. C. The _action_specification_ "appendectomy" is a process recording. It similarly causes a change of state. In the above, openEHR places A and B in the observation category. But from a healthcare perspectve, B is closer to C, than to A. Someone looking back in time through an EHR might be looking for seminal events of a certain class. Again, consider a person admitted to an Itensive Care Unit (ICU) with first degree burns. The current "Service-Action" view of the world emphasises the care provided at the ICU, thus de-emphasing the important change_of_state event, namely the burn event. The "Service-Action" view of the world portrays the burn_event as an attribute (observation) of the emergency care act. Surely a more appropriate approach should be to consider the emergency care act as a consequence of the burn event. This would also allow for subsequent trauma counselling to be related to the same event, rather than to the ICU burns treatment _action_specification_. Consequently, I believe that openEHR should include an _event_ archetype. A similar argument can be mounted for representing risks in their own right, rather than mere observations. Unfortunately, today's risks are often tomorrow's virtues and vice versa. Yet, given today's medical knowledge, the _observation_ "Person X smokes 50 cigarettes per day" carries significant value beyond the care event for which the observation is being recorded. Consequently, I believe there are good grounds for establishing a _risk_ archetype. regards, eric On Wed, 4 Dec 2002, Sam Heard wrote: > > Aniket > > Thanks for that. > Thanks for your thoughts. > > > Ther
Subject of care
Sam, I'm not sure if you are only considering familial links. If not, then organ donor/donee relationships might give rise to similar (and other) identification requirements. eric Eric Browne \ phone: +61 8 8331 3022 Montage Systems \ web:http://www.montagesystems.com.au Level 1, 145 The Parade, \ email: eric at montagesystems.com.au Norwood, SA 5067 Australia. On Mon, 2 Dec 2002, Sam Heard wrote: > Dear all > > I have been reviewing the subject of care - over family history. It is clear > that the following information is potentially useful: > > 1. The name of the person so you can refer to them as so-and-so > > 2. The relationship (father, mother) this might or might not include their > genetic relationship (adoptive) - at present I have this in the genetic > relationship boolean value of the family history problem. I think this is > the most appropriate as it is the only time when it is essential to know > it?? > > 3. The ID of the person in the demographic server - allowing contact details > etc. > > Can others think of other issues with identifying the subject of an entry in > the EHR - (not the ehr itself!) Times when this is likely are around the > birth of a child and for family history problems. > > Cheers, Sam > > Dr Sam Heard > Ocean Informatics, openEHR > Co-Chair, EHR-SIG, HL7 > Chair EHR IT-14-2, Standards Australia > Hon. Senior Research Fellow, UCL, London > > 105 Rapid Creek Rd > Rapid Creek NT 0810 > > Ph: +61 417 838 808 > > sam.heard at bigpond.com > > www.openEHR.org > www.HL7.org > __ > > > > > Dr Sam Heard > Ocean Informatics, openEHR > Co-Chair, EHR-SIG, HL7 > Chair EHR IT-14-2, Standards Australia > Hon. Senior Research Fellow, UCL, London > > 105 Rapid Creek Rd > Rapid Creek NT 0810 > > Ph: +61 417 838 808 > > sam.heard at bigpond.com > > www.openEHR.org > www.HL7.org > __ > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
