Archetype unification proposal – node identifiers

 

 

happy new year and best wishes for 2014. I hope your new year’s day is a bright one (unless you live in the UK, in which case it’s a lost cause here today 😉

adl15_new_ids

I have been working in the last few months to produce a final version of ADL/AOM 1.5, based on:

  • existing requirements,
  • emerging requirements – Intermountain, CIMI,
  • Harold Solbrig’s proposals for terms-as-URIs,
  • Dave Carlson’s MDHT / AML work at OMG led by Robert lario,
  • general feedback on the openehr-technical list, particularly from David Moner’s group at UPV, where they have implemented different rules
  • implementer feedback

So here’s the new idea. To date, We have been trying to keep ADL/AOM 1.5 backwardly compatible at the syntax level for ADL 1.4. However, I think this keeps too many old problems unsolved. I propose a new approach:

  • make the central ADL/AOM 1.5 specifications as clean as possible
  • provide a series of updates to ADL 1.4, coming from the 1.5 specs, that are carefully designed to be applied to 1.4 tools, to bring them up to date
    • e.g. things like how to post-fit the new identifiers, tuple support, annotations, to DAL 1.4 archetype tools
  • provide rules and tooling to deal with differences between archetype paths, upon which querying is based
  • provide a 1.4 => 1.5 upgrade tool to completely convert existing ADL 1.4 archetypes to the new format

The latest changes I propose (and have in fact implemented) are primarily about dealing properly with the long-running problem(s) of archetype node ids, i.e.:

  • the quirky 4-character top-level codes like at0001, at0003 etc, also lower level codes like at0001.0.1, at0.0.2
  • the root node code at0000, which really should be ‘1’ not ‘0’
  • the question of whether all nodes should have codes or not (in openEHR we have not done this; the 13606ers have)
  • the lack of separation between node id codes and value codes
  • sibling alternate C_OBJECTs under a single-valued C_ATTRIBUTE were not properly distinguished by their paths

The proposal is documented here on the wiki.

All comments and criticism welcome. If you think the proposal is broken in some way, or could be done better, don’t be afraid to say so. Please comment on the openehr-technical list, or for substantive comments, the wiki page above.

Let’s try and get to a final proposal that works for all ADL/AOM users – not just openEHR. I think that would be a real achievement.

Posted in Computing, Health Informatics | Tagged , , , , , | Leave a comment

CIMI – time for clinician collaboration?

How can CIMI ‘standard’ clinical models be created?

In CIMI, we mostly seem to assume two pathways:

  • de novo authoring, e.g. with an archetype tool that consumes the CIMI RM
  • accession and conversion of external models, e.g. CEMs, openEHR, 13606, R4C, VA, etc

Neither of these is as simple as it sounds, and they are likely to have different outcomes. Below I have tried to tease out some issues in order to think about CIMI’s approach from here on in. Continue reading

Posted in Health Informatics, openehr | Tagged , , , , | Leave a comment

The real reason most software fails

To my mind there is a problem in academia to do with where disciplines like ‘computer science’ (CS) and applications of computing sit.  Pure computer science is the study of computational theory and applications. It develops things like data structures, algorithms, models of parallel computing and much else relating to computation as an object of study. Things like bio-informatics, financial computing and avionics, just to name a few, aren’t usually thought of as proper ‘science’, but as some sort of ‘applied’ form of pure CS. Somewhere in the middle is ‘software engineering’.

mmser-complete

However, in my view, the offspring of CS were never properly conceived as disciplines, but rather artisanal pursuits.  In this post I have a look at a few domains and try to show how disciplines derived from computing should be understood as both proper science and engineering. In doing so, I came up with the schema above, as a way of establishing the key concepts. There’s nothing on this diagram that can’t be found in a dozen books on philosophy of science. But … I like diagrams.

Continue reading

Posted in Computing, Culture, Health Informatics, Philosophy | 8 Comments

ADL/AOM 1.5 (major) progress update

I have been working for some years on the side on the long overdue Archetype Definition Language (ADL) 1.5 and Archetype Object Model (AOM) 1.5 specifications (dev page). I have made some major progress just recently, of the ‘nice’ kind, where the specification simplifies, becomes more generic, and the formalism becomes more powerful (you know it’s the right change when you think, ‘ah if only I had done it this way years ago’. Such is the nature of R&D).

AOM_front_page

Continue reading

Posted in Health Informatics, openehr | Tagged , , , , | Leave a comment

What is a ‘clinical statement’?

In the CIMI forum, a debate is raging about this question. It might partly be my fault for daring to question some things in the reference model, but having done that, various participants are indeed arguing. So that’s a vindication 🙂

socrates

These kinds of terms are bandied about all the time in health, but it appears that few people agree on what they mean. And that means we can’t have meaningful conversations. We need some common definitions in CIMI, because otherwise the names of things in our models don’t have a common meaning. And if we don’t know what anything means, we are probably mad. Well, you probably are. I’m not, obviously.

So what is a ‘clinical statement’?

Continue reading

Posted in Health Informatics | Tagged , , | Leave a comment

A real world CIMI archetype analysis based on Intermountain CEMs

I have been meaning to blog the recent CIMI meeting (already 10 days ago 😉 but have been buried in ‘work’. So in lieu of that, I’ll put up an analysis of a real use case from Intermountain Health that Stan introduced on the call last night. Don’t expect to get all the details, but it will give you some feel for what CIMI is doing.

The analysis started with the question “should we allow ENTRY to contain ENTRY in the CIMI reference model”? Obviously my response to that was one of horror, since a ‘clinical statement’ can’t contain a c’linical statement’ …

But that’s just me. Let’s backtrack and get the real reason from Stan as to why this might seem necessary. It’s to do with the need to replicate the typical Intermountain lab panel item CEMs and also construct a ‘panel’ CEM, whose contents would be one or more analyte CEMs. At Intermountain, with their different RM, this is understood colloquially as something like an ‘entry’ (the panel) containing ‘entries’ (the items).

The CIMI (and for that matter 13606 and openEHR) Reference Models are not constructed like this. In these RMs, an ‘Entry’ means a clinical statement (which might contain numerous data points).

Here is my analysis. If this could be perfected, it could help us transform the 6,000 or so Intermountain CEMs into ADL 1.5 archetypes based on the CIMI reference model, thereby making a hugely valuable resource more visible to the outside world.

Continue reading

Posted in Health Informatics, standards | Tagged , , | Leave a comment

What is a standard?

On the left  is the VMEbus, a  hardware bus specification created by Motorola at the time of the 68000 CPU. It uses the Eurocard physical card, connectors and mechanicals (DIN 41612), and adds an electrical/signalling specification (i.e. what do all those connectors do?). The overall specification was standardised as IEC 821 ‘ VMEbus’ (VME = ‘VersaModule Eurocard’). This is a standard. I’ll tell you why in a moment.

VME_XMI

On the right is XMI, the OMG’s XML meta-data interchange standard (ISO/IEC 19503:2005). This should be a standard, but isn’t. What’s the difference?

Continue reading

Posted in Health Informatics | Tagged | Leave a comment

OMG e-health platform summit Berlin 2013

I attended the OMG e-health summit this week, devised and facilitated by Ken Rubin (HP health vertical). The session drew participants from various countries and programmes, including Finland, Germany, UK NHS, Australia, Italy, US and others.

ehealth_summit_berlin_2013 Continue reading

Posted in Health Informatics, openehr | Leave a comment

The openEHR platform live in Norway

I had the pleasure of being invited to the annual DIPS Forum Tromsø, Norway 2-5 June 2013, to present on openEHR. DIPS is the main Norwegian hospital information system supplier, and the DIPS forum is its annual user/vendor meet-up. (Presentation – YouTube; 32 mins).

Tromso 2013

Something possibly unique is going on in Norway. DIPS is a vendor that originated in hospital IT, and morphed into something like a normal company. Abnormally, it remains very close to its users in the clinical community, under a visionary clinical and engineering leadership that has its eyes firmly on the long term, while never forgetting its audience.

The DIPS Forum is evidence of this relationship: 24 years long, with 650 or so attendees in 2013, it’s larger than an HL7 meeting, and yet consists almost 100% of users from only one country, and only one vendor (plus the odd foreigner;-). My impression is that what the user community really appreciates is the relationship and engagement. It’s the kind of thing bureaucrats dream of creating by ‘programmes’ or ‘reorganisation’ but in fact it can only ever really be ‘grown’ into place. It’s what ensures the product, while probably not perfect on any given day, keeps up with (and sometimes probably overtakes) user needs and aspirations. Continue reading

Posted in Health Informatics, openehr | 2 Comments

Identifying complex knowledge artefacts

Based on a lot of experience, thinking and gnashing of teeth of colleagues Ian McNicoll, Heather Leslie, Sebastian Garde who work on the Ocean Clinical Knowledge Manager (CKM) product, as well as many others using archetypes and archetype tools more generally, I have produced a major update to the openEHR Knowledge Artefact Identification specification draft, here.

Lifecycle management with semver.org versioning.

This specification is designed to answer the following needs for complex, designed artefacts like archetypes, templates and terminology subsets:

  • ‘ontological’ (human readable) archetype, template and subset identifiers
  • machine identifiers
  • references to identified artefacts from other artefacts
  • recording knowledge artefact ids in data
  • lifecycle management and states;
  • dealing with transfer and forking;
  • supporting integrity and non-repudiation.

It combines the concept of lifecycle management for knowledge artefacts with a solid versioning model, mostly lifted from the excellent specification at semver.org.

I have taken a lot of care to ensure this specification works equally well with artefacts produced by other organisations, particular non-openEHR archetypes and similar models. It now needs community input and feedback… i.e. feel free to pull it to pieces.

Posted in Computing, Health Informatics, openehr | Tagged , , , , | 1 Comment