Hi Heather et al, Whilst I have followed this thread and agree with many of the observations and conclusions reached so far, I would like to make the following observations, which are restricted to the aspect of the “non-UCUM" unit described in Heather’s original posting. They have more serious and broader implications than this one iconic Blood Pressure Archetype.
Notes on UCUM According to the UCUM specification at http://unitsofmeasure.org :- "The Unified Code for Units of Measure provides a single coding system for units that is complete, free of all ambiguities, and that assigns to each defined unit a concise semantics. In communication it is not only important that all communicating parties have the same repertoir of symbols, but also that all attach the same meaning to the symbols they exchange. The common meaning must be computationally verifiable. The Unified Code for Units of Measure assumes a semantics for units based on dimensional analysis.” * UCUM introduces ambiguity, despite the above claim. * UCUM is complex and comprehensive. It brings together units from various other standards into a single framework. It is designed to support computability and communications interoperability, and hence adopts a highest common denominator 7-bit represention of unit codes as normative for sharing. * UCUM does not provide a single code for each unit - it provides 2 normative codes, as well as a non-normative display/print rendition and an ad-hoc name. For each unit, UCUM defines a case-sensitive version, a case-insensitive version, and a version intended for display or printing. * Some units have no display/print variant defined. * UCUM defines every unit in terms of 7 metric base units and does so in a coherent and consistent fashion. This can support conforming systems to perform conversions from one unit to another. * UCUM does not supply normative names of units. * Some similar units have quite dissimilar UCUM variants. e.g. °C Cel for temperature print and case-sensitive variants respectively. °F [degF] for temperature print and case-sensitive variants respectively. ° deg for plane angle print and case-sensitive variants respectively. * Some of UCUM’s names have been US-ised. E.g. litre has been changed to liter, metre to meter, deca to deka. * UCUM’s names don’t follow the 7-bit rule. Some names like Ampère and Ångström use 8-bit character representation. * UCUM uses [qualifier]s to indicate where a base unit is changed, e.g. mm is a unit for length property whereas mm[Hg] is a unit for pressure property. The [] syntax is unnecessary and complicates implementations. * UCUM provides no simple guide for use, particularly regarding normative components such as c/s, c/i and print. * UCUM inconsistently defines print representations of some units as normative and others as non-normative depending on the table. * UCUM’s print codes are often 8-bit. UCUM is premised on providing support for the highest common denominator across information systems, by constraining its normative unit strings to 7-bit values. However, unit print and unit name will not work in 7-bit environments. * UCUM releases are clearly supported and versioned, although differences between versions are hard to determine. * The contents of all UCUM specification tables are published as a single XML file for download. * Implementers of UCUM must choose between case insensitive and case-sensitive versions. The two cannot co-exist in the same channel of communication without special additional processing. * Even using UCUM, some units are difficult to represent and agree upon e.g. the unit for measuring estimated Glomerular Filtration Rate, quite common in healthcare - see http://unitsofmeasure.org/trac/ticket/98 * Further useful information: http://motorcycleguy.blogspot.com.au/2009/11/iso-to-ucum-mapping-table.html Notes on openEHR’s implementation of UCUM within the AOM. * openEHR is a standard primarily for building software components for electronic health records. openEHR Archetypes are being created and adopted by national bodies in many countries as canonical models for supporting interoperability of data shared between systems. Whilst these two goals are not mutually exclusive, they do present challenges and compromises for openEHR. EHR systems do need to care about supporting the entering and representation of data to users. * openEHR’s implementation of units is a compromise between these to goals that imposes minimal implementation overhead. * openEHR is designed to work in an 8-bit unicode/UTF-8 world. All openEHR-based applications are likely to support unicode characters and clearly ‘°’ would be part of that world. There are interesting examples such as the Observation Archetype "Fundoscopic examination of eyes” that constrains Field Angle values to “30º", “45º", etc.. as Coded Text. * The openEHR DataTypes specification defines properties, including units for DV_QUANTITY types. The specification is a little vague on adherance to UCUM for units, stating that unit strings are to be expressed in UCUM unit syntax. This allows for support of units beyond those defined in UCUM. * The current openEHR BNF for parsing units appears to have some errors if it were to be considered UCUM-conforming - e.g. presence of ‘μ’ symbol; absence of ‘[‘ and ‘]’ symbols. * openEHR is unclear on which variant(s) of UCUM ( case-sensitive, case-insensitive, print ) should be supported or mandated. The current openEHR BNF for parsing units cannot support 8-bit UCUM units such as ‘°’ i.e. degree symbol in values conforming to type DV_QUANTITY. Tooling implementations for openEHR units ( I have only looked briefly at these ) * ADL Workbench - appears to have support for UCUM beyond the openEHR spec. - e.g. all 7 electronically published fields can be stored within the Workbench. Units appear to be fully parsed against the UCUM spec. * Ocean Archetype Editor - constrains creation of archetyped units to the set defined in a units and properties XML file distributed with the AE. This set does not match the UCUM units. Current implementation allows only ‘°’ for degree symbol. Recent versions support UCUM ‘overrides’ for each unit. Where UCUM values have been explictly entered, they have been entered inconsistently - some are case-sensitive, some are case-insensitive. Processing of UCUM overides does not appear to have been implemented yet. See http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2014-February/003102.html . * Clinical Knowledge Manager - Many archetypes on the international CKM use non-valid UCUM units. I have not examined archetype processing, but assume from the archetypes in the international repository that existing archetypes are not validated against UCUM. 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. Implications for Archetypes, Archetype repositories and Archetype Governance * The CKM Body Temperature archetype constrains values of quantities to have units of “°C” or “°F”. Most archetype tools I suspect, display the value of the units from the ADL verbatim. WYSISYG. This works well in the user interface world. “°C” and“°F” are both valid UCUM print rendition of units (they just happen to be invalid for sharing). Most EHR applications probably behave similarly - units would be displayed directly as stored in data sources. * Given openEHR proclaims to support UCUM as the standard for units in DV_QUANTITY, it would seem sensible to constrain to UCUM values in ADL. Most tools don’t do this currently. Most archetypes have invalid values for UCUM. Most tools don’t support both display/print as well as case-sensitive normative UCUM values. * Some unit issues, such as the Blood Pressure tilt angle could be “fixed” simply by adding the normative UCUM unit and flagging the deprecated unit as such. However, tools would need to be updated to allow these new, “fixed” units to be entered where they previously could not. Only some of the existing openEHR units could be “fixed” this way. * I think units are somewhat akin to terminology systems like SNOMED. There are significant implementation complexities. The main value in standardising units is to ensure safety and quality of data from disparate sources. The main additional value in adopting UCUM more fully is to support unit conversion. * Ideally, in order just to support UCUM well, openEHR implementations should support the case-sensitive UCUM value, the print value and the unit definitions, all supplied by UCUM via the published XML file. This does not mean that the DV_QUANTITY type needs to change, but it would mean updating existing archetypes to replace the current archetype units with the correct UCUM case-sensitive one. Let’s call this the UCUM code. openEHR archetype editors would then map these UCUM codes to unit displaynames ( i.e. the UCUM print value ). openEHR applications would also ideally map the UCUM code to unit displaynames. i.e. Applications and archetypes use UCUM codes internally, but those codes aren’t displayed to humans. * If there are grounds for changing the Blood Pressure Archetype to “fix” the Tile Angle, then those same grounds dictate that many more Archetypes be changed. This should be undertaken as a major versioning exercise, probably with 6 months warning and with as many ducks lined up before the new archetypes are published. Many deployments will need to change. Testing of those deployments will need to be undertaken. Consideration will need to be given to how to support existing data in live applications. * There will always be tension between national and international archetype repositories trying to produce models for an 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 > <heather.les...@oceaninformatics.com> 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 New implementers will be able to use the most up-to-date version of the > archetype, rather than using an archetype that has been identified as having > flaws. Otherwise new implementers will continue to implement a known, flawed > archetype into their new systems > o Further content review will expose the archetype to a broader range of > clinicians and their input will potentially further enhance, or at least > endorse the current, quality. > > · Cons > o Further content review will possibly introduce further changes – maybe > breaking, maybe not. > o Existing implementers will need to decide whether it is worthwhile to > update to v2. The alternative is to stay with the v1 published archetype as > is and consider updating at some future time. > o The update of the UCUM unit and body location pattern does not have major > safety implications or significantly impact the modelling quality, yet will > have internal implications in existing clinical systems. > o Two versions of the archetype will be in circulation, and implementers > will need to manage the interoperability issues that will arise. > o Norway will likely use the new archetype as their national standard, > diverging from the openEHR CKM content, which is not desired by either party. > > A portion of the diff is attached, which demonstrates the major breaking > changes. There are many other changes that only refer to translations and are > non-breaking in the rest of the diff > > Major changes are: > · Changing ‘Tilt’ units – ‘°’ to ‘deg’ – at1005 – this is the > critical and breaking correction that has triggered considering these > additional changes: > o Making Measurement Location a choice of coded text and text – at0014 > o Removal the redundant ‘Location’ cluster heading > > This is the first time we have had to update a published archetype and it > certainly won’t be the last. If there were breaking changes that needed to be > made for clinical safety reasons or similar critical reasons I would have no > hesitation in proceeding to v2. If there were non-breaking changes we would > manage the progression with additional minor revisions or patches – not a > problem. This one has breaking changes but no clinical safety issues, so a > bit of a grey zone because of the possible implementation implications. > > I have no doubt that many implementers are already grappling with these > issues if they have implemented draft archetypes, so perhaps you all have > established systems and approaches for this. > > I have had some advice suggesting we should leave the archetype as is, rather > than ‘rock the implementation boat’ for little semantic value, yet I’m not > sure that it is our role to be paternalistic. My own inclinations are that we > should govern the archetypes from a pure point of view, updating and creating > new versions if we have to, and allowing CKM to provide the transparency that > will support implementers to make informed choices. > > So: > Option 1: Do nothing. The current flawed archetype will be the only one > available on the openEHR CKM > Option 2: Promote the new candidate archetype to the public trunk as a > potential new iteration – so available for viewing and download, but with no > official status, effectively in limbo until a further review round is carried > out and it is republished. > Option 3: Promote the new candidate archetype to the public trunk, run formal > content reviews on it and plan to re-publish as v2 > > Please, your thoughts? > > Regards > > Heather > > Dr Heather Leslie MBBS FRACGP FACHI > Consulting Lead, Ocean Informatics > Clinical Programme Lead, openEHR Foundation > p: +61 418 966 670 skype: heatherleslie twitter: @omowizard > > _______________________________________________ > openEHR-clinical mailing list > openehr-clini...@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
