Something called the “Yosemite manifesto on RDF as a Universal Healthcare Exchange Language” was published in 2013 as the Group position statement of the Workshop on RDF as a Universal Healthcare Exchange Language held at the 2013 Semantic Technology and Business Conference, San Francisco. Can such grand claims be true?
A strange thing happens in health IT solution procurement, and by extension government initiatives that seek to influence it. See if you can disagree with the following characterisation of health provider organisations as solution purchasers.
CIOs and CMOs have known for years if not decades that:
The word ‘platform’ is starting to reach the same status as the word ‘internet’ – part of the bedrock, but many have no idea what it really is. In e-health particularly, ‘platform’ is often mixed up with ‘open source’, ‘APIs’ and ‘standards’ in ways that don’t always make sense. Regardless, public policy in the NHS, US ONC and in other countries is being formulated without necessarily a clear common understanding. I’m going to try to address some of the ambiguities here.
The key thing to understand about a platform is that it represents progress away from being locked-in to a monolith of fixed commitments, toward an open ecosystem. This is true both technologically and economically. Any platform operates in two environments: development, and deployment, and these need to be understood distinctly to understand how to use the platform concept properly.
I attended HIMSS 2014 in the mammoth convention centre in Orlando 10 days ago, and went to a session on ‘Clinical Decision Support – is progress being made?’. Despite this being the dead Thursday of HIMSS, around 50 people showed up.
The presentation was done by Cory Tate (sen research dir. KLAS) and Adam Cherrington (research dir. KLAS). KLAS is the organisation that performs research into the shape of the health IT industry and publishes the results. So when they say something, it usually means that it’s actually statistically true across the US at least, rather than just a supposition of one person.
What they said was, in a nutshell was: progress is being made, there are Order set products (Elsevier, ProVation etc) and some surveillance products, e.g. infection control rule sets and so on. These have some nice features. Etc Etc. A discussion developed with the audience in which it became clear that both the presenters and others present identified the main blocker as the inability to connect the order sets and other CDS or analytics modules to the EMR products in use. Continue reading
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 😉
I have been working in the last few months to produce a final version of ADL/AOM 1.5, based on:
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:
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 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.
In CIMI, we mostly seem to assume two pathways:
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
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’.
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.
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).
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 🙂
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’?
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.
