Why the buzz about CIMI?

With the recent public statement from the Clinical Information Modelling Initiative (CIMI) my cynical heart feels a little flutter of excitement. Maybe, just maybe, we are on the brink of a significant disruption in eHealth. Personally I have found that the concept of standardising clinical content to be compelling and hence my choice to become involved in development of archetypes. During my openEHR journey over the past 5 or so years it has been very interesting to watch the changing attitudes internationally - from curiosity and 'odd one out'  through to "well, maybe there's something in this after all".

And now we have the CIMI announcement...

So what has been achieved? What should we celebrate and why?

At worst, we have had a line drawn in the sand: a prominent group of thought leaders in the international health informatics domain have gathered and, through a somewhat feisty process, recognised that a collaborative approach to the development of a single logical clinical content representation (the CIMI core reference model) is a desirable basis for interoperability across formalisms. Despite most of the participants having significant investment and loyalty to their own current methodology and flavor of clinical models, they have cast aside the usual 'not invented here' shackle and identified a common approach to an initial modelling formalism from which other models will be derived or developed. Whether any common clinical content models are eventually built or not, naming of ADL 1.5 and the openEHR constraint model as the initial formalism is a significant recognition of the longstanding work of the openEHR Foundation team - the early specifications emerged nearly 20 years ago.

At its idealistic best, it potentially opens up a new chapter for health informatics, one that deviates from the relatively safe path of incremental innovation that we have followed for so many years - the reliance on messages/documents/hubs to enable us to exchange health information. There is an opportunity to take a divergent path, a potentially transformational innovation, where the focus is on the data itself, and the message/document/EHR becomes more simply just the receptacle or vehicle for the data. It could give us a very real opportunity to store lifelong health information; simplify data exchange (whether by messages or documents), aggregation, querying and analysis; and support knowledge-based activities such as decision support - all because we will (hopefully) have non-proprietary, common, agreed and fully defined models of clinical content and known transformations between each formalism.

Progress during the next few months will be telling. In January 2012, immediately before the next HL7 meeting in San Antonio, the group will gather again to discuss next steps.

There is a very real risk that despite best intentions all of this will fade away to nothing. The list of participating organisations, including high profile standards organisations and national eHealth programs, is a veritable Who's Who of international health IT royalty, so they will all come with their own (organisational and individual) work experience, existing modelling resources, hope, enthusiasm, cynicism, political agendas, bias and alliances. It could be enough to sink the work of this fledgling group.

But many are battle-weary, having been trudging down this eHealth path for a long time - some now gradually realising that the glacial incremental innovation is not delivering the long-term sustainable answers required for creating 21st Century EHRs as they had once hoped. So maybe this could be the trigger to make CIMI fly!

I think that CIMI is a very bright spark on the health IT horizon. Let's hope that with the right management and governance it can be agilely nurtured into a major positive force for change. And in the future, when its governance is mature and processes robust, we can integrate CIMI into the formal standards processes.

Best of luck, CIMI. We're watching!

CIMI - initial public statement

The following public statement has been released by the Clinical Information Modelling Initiative today:

Public release

The Clinical Information Modeling Initiative is an international collaboration that is dedicated to providing a common format for detailed specifications for the representation of health information content so that semantically interoperable information may be created and shared in health records, messages and documents. CIMI has been holding meetings in various locations around the world since July, 2011. All funding and resources for these meetings have been provided by the participants. At its most recent meeting in London, 29 November - 1 December 2011, the group agreed on the following principles and approach.

Principles

  1. CIMI specifications will be freely available to all. The initial use cases will focus on the requirements of organisations involved in providing, funding, monitoring or governing healthcare and to providers of healthcare IT and healthcare IT standards as well as to national eHealth programs, professional organisations, health providers and clinical system developers.
  2. CIMI is committed to making these specifications available in a number of formats, beginning with the Archetype Definition Language (ADL) from the openEHR Foundation (ISO 13606.2) and the Unified Modeling Language (UML) from the Object Management Group (OMG) with the intent that the users of these specifications can convert them into their local formats.
  3. CIMI is committed to transparency in its work product and process.

Approach

  • ADL 1.5 will be the initial formalism for representing clinical models in the repository.
    • CIMI will use the openEHR constraint model (Archetype Object Model:AOM).
    • Modifications will be required and will be delivered by CIMI members on a frequent basis.
  • A set of UML stereotypes, XMI specifications and transformations will be concurrently developed using UML 2.0 and OCL as the constraint language.
  • A Work Plan for how the AOM and target reference models will be maintained and updated will be developed and approved by the end of January 2012.
    •  Lessons learned from the development and implementation of the HL7 Clinical Statement Pattern and HL7 RIM as well as from the Entry models of 13606, openEHR and the SMART (Substitutable Medical Apps, Reusable Technologies) initiative will inform baseline inputs into this process.
  • A plan for establishing a repository to maintain these models will continue to be developed by the group at its meeting in January.

Representatives from the following organizations participated in the construction of this statement of principles and plan:

Further Information:

In the future CIMI will provide information publicly on the Internet. For immediate further information, contact Stan Huff (stan.huff@imail.org)

CIMI & beyond...

The Clinical Information Modelling Initiative (#CIMI) is currently meeting in London. It comprises a significant group of healthcare IT stakeholders and was formed some months ago as an initiative by Dr Stan Huff. After a number of face to face meetings and email list exchanges, the intent is that at the end of this 3 day meeting there will be an agreed decision on a common clinical content modelling formalism/methodology for our Electronic Health Records. For background, from Sam Heard’s email to the openEHR email list on November 2, 2011:

The main topic I want to address is the international initiative to develop a standardised clinical modelling methodology. This has some IHTSDO secretarial support and is led by Dr Stan Huff of Intermountain Healthcare, a former HL7 Chairperson and co-founder of LOINC, who has been advocating a model-based approach for many years. The current approach at Intermountain has been influenced by openEHR and uses a two-level modelling approach. Stan has established a leadership group through trust and reputation, which includes a variety of agencies who have been working in the area and national eHealth programs or major initiatives who are interested in consuming the models. It has grown out of an HL7 Fresh Look initiative and is currently known as the Clinical Information Modelling Initiative (CIMI).

The group has committed to determining a single formalism for clinical modelling and ADL and openEHR are on the list of alternatives which is as follows:

  • Archetype Object Model/ADL 1.5 openEHR
  • CEN/ISO 13606 AOM ADL 1.4
  • UML 2.x + OCL + healthcare extensions
  • OWL 2.0 + healthcare profiles and extensions
  • MIF 2 + tools HL7 RIM – static model designer

Proponents of the five different approaches have been presenting to members of the group, who have a variety of experience in these matters. Fourteen organisations will cast a vote on the formalism to use including openEHR, Singapore, UK NHS, Results 4 Care, HL7, Canada Infoway, 13606 Association, Tolven, CDISC, GE/Intermountain, US Departments, CDISC, SMArt and Mitre.

At the preliminary vote, held recently on November 20, the two most popular options were openEHR ADL 1.5 and UML.

Today CIMI will vote on a proposal for either ADL 1.5 or UML to be adopted as the initial common formalism for use, and determine a road map for coordinated development of semantically interoperable clinical models into the future. The potential impact of this is huge and exciting. It could be a disruptive change in health IT.

We hold our collective breath!

Australia's PCEHR Challenge

Are you planning to participate when the Personally Controlled Health Record goes live in July 2012?

I've certainly been pondering what would make me interested to try it, in the first instance, and then to keep using it in an ongoing manner – in my roles as both a Clinician and as a Consumer.

In my previous blog post we can see the PCEHR positioned part way between a fully independent Personal Health Record and the Clinician's Electronic Health Record – a hybrid product bridging both domains and requiring an approach that cleverly manages the shared responsibility and mixed governance model.

The scope of the proposed PCEHR is outlined in the Concept of Operations document. A recent presentation [PDF] given at the HIC2011conference provides a summary of expected functionality.

Recently we've all seen many analyses about the demise of Google Health and over the past decade we've been able to see the difficulties faced by many Personal Health Records who have come and gone in the past decade or even longer. What have we learned? What are the takeaway messages? How can we leverage this momentum in a way that is positive for both consumers and clinicians and potentially transform the delivery of healthcare?

Let's make some general assumptions:

  • Core functionality is likely to remain largely as described in the ConOps document;
  • Privacy, Security and Authorisation will be dealt with appropriately; and
  • Internet skills of users will be taken into account in terms of clever and intelligent design and workflow.

In a previous post, I suggested that there are additional 3 concepts that need serious consideration if we are to be successful in the development of person-centric health records, such as the PCEHR.

  • Health is personal
  • Health is social
  • Need for liquid data

I've been pondering further and have modified these slightly. I want to explore at how we can make health data personally valuable, socially-connected and dynamic or liquid.

Adding value; making it personal

Take a look at any clinician's EHR and the actual data in itself is pretty static and uninteresting – proprietary data structures, HL7v2 messages, CDA documents; facts, evidence, assessments, plans; a sequence of temporal entries which could prove to be overwhelming when gathered over a lifetime. However it provides the necessary foundation on which innovative approaches could make that static data come become dynamic, to be re-used, leveraged for other purposes, to flow!

Data starts to come to life when we use it creatively to add value or to personalise it, rather than just presenting the raw facts and figures or the interminable lists. The key is to identify the 'hot buttons' for any and all users, clinician or consumer alike – those things that provide some value or personalisation benefit that is not otherwise available.

For the clinician to be engaged, they need to be able identify at least symmetrical, and preferably increased, value from any effort that they contribute to participating in the creation and maintenance of a shared electronic health record (EHR). This might be recognised in many ways including, but not limited to:

  • Leveraging the data itself – tools to put the data to use
    • the creation of views of the data that will better support their provision of care to their patients, such as health summaries (both automatic and curated) and up-to-date Medication, Problem and Adverse Reaction lists;
    • access to clinical decision support;
    • improved safety from generation of alerts; and
    • Secure exchange of patient information.
  • Increased opportunity for engagement
    • online consultations;
    • care coordination; and
    • answering questions via email or a shared portal.
  • Generate increased income from
    • creation of reminders for follow-up visits
    • online interactions eg repeat prescriptions, eReferrals and online consulations
  • Data available for quality improvement and clinical audit
  • Data available for research & population health

Yet this is clearly not without it's unique challenges - for example, JAHIMA's The Problems with Problem Lists! What is being proposed is not trivial at all!

Consider what will engage a patient to take more than a second look at their health record. Google Health creator, Adam Bosworth, in the short excerpt from the TechCrunch video on why Google Health failed, stated that people don't just want some place to store their health information – that they want something more. And Ross Koppel noted in his Google gave up on electronic personal health records, but we shouldn't blog post that "…while knowledge may be power, it isn't willpower." The challenge we face is how to add 'the something more'; to encourage the development of willpower.

Segmenting consumers is one approach to identifying 'hot buttons' that might trigger them to opt in and use the PCEHR:

  1. Well & Healthy – this is a tricky group to engage as they often see no reason to address any aspects of their health and are not motivated to change behaviour or seek treatment. Some may be interested in preventive health or tracking fitness or diet.;
  2. Worried Well – those who consider themselves at risk of illness and want to ensure that they are (or will be) OK, often tracking aspects of their health to be alert for issues or problems – some call them hypochondriacs;
  3. Chronically Ill – those living with an ongoing health condition or disability; and
  4. Acutely Ill – including recent life-changing diagnosis or event

Each group will have specific needs that need to be explored to ensure that despite registering, there is a persuasive reason for them to return and actively engage with the PCEHR content or value-added features.

While the 'hot buttons' for consumers might vary, there are common principles that could underpin any data made available and value-added services provided, such that consumers can use, and make sense of, their health information. Examples include:

  • Minimal data entry by the consumer – this will be a considerable barrier to entry;
  • Aggregation of information from multiple sources - creating a hub of health information in one place;
  • Information is interpreted, wherever possible to make it personal and relevant to the consumer
    • ...this is what it means for you...
    • ...this is what you should consider next...;
  • Information provided in non-medical or non-technical language, using consumer vocabulary whenever possible;
  • Provision of context for the information – for example, information about the pathology test sitting alongside the actual pathology test result; and
  • Comparison of the consumer's data alongside data from equivalent peers, for example the same age and sex, where this is safe and appropriate.
  • Consideration of the 'Games for Health' movement and the effort to leverage 'gamification' in non-game applications as a mechanism for getting users (especially Consumers) to register, participate and most importantly, support their ongoing engagement.

Socially-connected data?

Hmmm. Traditionally we tend to gravitate to the idea of privacy at all costs when it comes to health information, however what we really aspire to is making the right information available to the right person at the right time – the safe and secure facilitation of health information communication. That this might extend into the non-clinical space in some circumstances is challenging and somewhat contentious, especially in these relatively early days, but it is conceivable that our traditional, rather paternalistic health paradigm is about to undergo a considerable shakeup.

The area of Telehealth is certainly starting to gain traction between healthcare providers as an electronic proxy for transporting patients long distances for specialist care. Similarly there appears to be rising interest in online consultations and interactions between consumers and their healthcare providers including the re-ordering of prescriptions, requesting of repeat referrals and ability to ask questions via secure messaging. Clearly there are issues and constraints about these activities, but it is very likely that the incidence of consumer-clinician interactions will increase in the near future as consumers recognise the convenience and demand rises.

A person-centric health record that allows shared access from both providers and consumers can act as the hub for these communications. In addition, integration with the Clinician's information system can support the ability for notification to the consumer of availability of diagnostic test results, reminders, tests due, prescriptions due etc.

The social support imperative in health programs such as Quit Smoking and Weight loss have been well recognised for many years, and is a common strategy used in clinical practice. In recent times this is expanding beyond family and friends to the broader community via automated sharing of measurements to social networks such as Twitter. In addition we can consider some early wins in the non-medical sphere – for example, the online PatientsLikeMe community – where consumers are engaging with other consumers with similar issues and concerns. There is also some interesting research evolving about the value that is coming from consumer to consumer health advice – Managing the Personal Side of Health: How Patient Expertise Differs from Expertise of Clinicians. Contagion Health has developed the Get Up and Move program where consumers issue challenges each other to encourage increased activity and to promote exercise, facilitated by an online website, and Twitter.

A recent Pew Research Centre report, Peer-to-peer Healthcare stated: "If you enable an environment in which people can share, they will!" And Adam Bosworth made a clear statement that one reason Google Health failed was because it 'wasn't social' – that it was effectively an isolated silo of a consumer's health information. I suspect that we will see this social and connected aspect of healthcare evolving and become more prominent in coming years, as we understand the risks, benefits and potential.

Liquid or Dynamic Data?

One of the most interesting comments about the demise of Google Health was: "Google Health confronted a tower of healthcare information Babel. If health information could have been shared, Google would still be offering that service." That's a very strong statement – not only that the actual data itself was a significant issue, and more specifically, that it was not shareable.

So that requires us to ask how we can make data shareable. "Gimme my damn data" and "Let the data flow", some say - but the result is usually access to their own data in various proprietary formats but no opportunity to bring it together into one cohesive whole which can be used and leveraged to support their healthcare. I've blogged extensively already about the benefits of standardised, computable clinical content patterns known as archetypes – see What on earth is openEHR and Glide Path to Interoperability. To me this approach is simply common sense, and with the rising interest in development of Detailed Clinical Models, perhaps this view is coming closer to reality.

Until we create a lingua franca of health information we can't expect to be able to share health information accurately and unambiguously. We need agreed common clinical content definitions to support sharing of health data such that it can flow, be re-used and be used for additional purposes such as sharing information between applications – making the data dynamic.

As we work out how to approach this shared personal electronic record space, our options will be severely limited unless we have a coherent approach to the data structure and data entry. We need to:

  • Develop common data formats and rules for use that will support the flow of health information
  • Promote automatic entry and integration of data from multiple source systems – primary care EHR, Laboratory systems, government resources and, increasingly, consumer PHRs. Most will tolerate some manual entry of data if they receive some value in return, but don't underestimate the barrier to entry for both clinicians and consumers if they have to enter the same data in multiple places.

To participate, or not?

The core content of the PCEHR as per the ConOps is very clinician-oriented at present, clearly intended for the ultimate benefit of the patient, but focused on information that will be useful to share where multiple clinicians are participating in care or for use in an emergency. The nominated Primary Care clinician will be tasked with the upload and maintenance of the Shared Health Summary. Event Summaries can be uploaded (hopefully this will be automated earlier rather than later). PBS, MBS, ACIR and Organ Donor information will be integrated from Medicare sources.

All of this data will no doubt be extremely useful in some circumstances, but in itself may not be compelling enough to encourage frequent use by clinicians, nor provide them with they symmetrical value such they will need to maintain the Health Summary records. From an academic point of view the proposed ConOps is ticking all the correct boxes, however the big question is will that be enough to motivate clinicians to participate and then, more importantly, to stay involved?

Consumer engagement as described in the ConOps is fairly limited – ability to manually enter 'key information' about allergies and adverse reactions or medications; the location of an advance care directive and notes about health information that they wish to share. This is hardly enough to capture the imagination of many consumers. It is a real likelihood that those who do opt in may only use it once or twice, including manually entering some of their data, but find that there is not compelling reasons for them to return to their PCEHR record nor to encourage/demand that their Clinician participate.

We have an opportunity to turn the PCEHR into a dynamic person-centred health information hub – one that can be leveraged by clinicians and consumers, and for the benefit of the consumer's health and wellbeing in the most wholistic sense. In order to do so, the PCEHR needs to seriously consider prioritising an approach that ensures dynamic, personalised and/or value-added data; health information that can be shared and communicated clinically and socially; and dynamic data.

At all costs we must avoid:

  • a dry, impersonal tool that is ignored or infrequently used by any user, or used by only one type, rather than both consumers and clinicians in partnership;
  • barriers to entry for both consumers and clinicians;
  • a closed, inward-looking tool;
  • a silo of isolated health information operating as yet another 'tower of healthcare information Babel'.

This is our challenge!

The health information continuum

The final draft version of ISO 251's Technical Report "Personal Health Records — Definition, Scope and Context" has just been sent for formal publication. I was involved in some of the later drafting, especially proposing the notion of a spectrum, or continuum of person-centric health records was. The latest iteration, here:

Healthcare organisations and healthcare systems are accountable for the content of EHRs that they control. Individuals have autonomy over records they choose to keep. However, in between these two strict views of an EHR and a PHR is a continuum of person-centric health records which may have varying degrees of information sharing and/or shared control, access and participation by the individual and their healthcare professionals. Toward the EHR end of the spectrum, some EHRs provide viewing access or annotation by the individual to some or all of the clinician’s EHR notes. Towards the PHR end of the spectrum some PHRs enable individuals to allow varying degrees of participation by authorised clinicians to their health information – from simple viewing of data through to write access to part or all of the PHR.

In the middle of this continuum there exist a growing plethora of person-centric health records that operate under collaborative models, combining content from individuals and healthcare professionals under agreed terms and conditions depending on the purpose of the health record. Control of the record may be shared, or parts controlled primarily by either the individual or the healthcare professional with specified permissions being granted to the other party.

And the final diagram:

Australia's PCEHR is an evolving example of a person-centric health record aiming for that somewhat scary middle zone of shared responsibility and mixed governance - carrying with it enormous potential for changing the delivery of healthcare and surmounting enormous clinical, technical, cultural and social challenges.

What kind of things should we be considering?

How can we make the PCEHR a successful and vital component of modern healthcare delivery? What features and attributes will ensure that we steer clear of the approaches of previous failed projects and, instead, create some positive traction?

I've considered these issues for many years as I've watched the PHR/EHR domain wax and wane and I keep returning to 3 major factors that need to be considered from both the consumer and the clinician points of view:

  • Health is personal
  • Health is social
  • Liquid data

These are the big brush stroke items that need to be front and centre when we are designing person-centric health records.  Will post some more thoughts soon.

The DCM environment - a crowdsourcing initiative

There are a number of detailed clinical models available to choose from, from diverse backgrounds, for many differing purposes and with varying degrees of success and penetration. More are arriving on the scene as time goes on – only this week the Clinical Information Models from ONC in the US have been released for their first 2 week period of public comment, and I'd never heard of them before. I haven’t been able to find a single document pointing to an overview on available models – current or past. So, given the current activity development of a quality standard around detailed clinical models in ISO TC 215 and the number of models under development, I thought it timely to try to co-ordinate sourcing a picture of the detailed clinical model landscape.

Well aware that my understanding is limited to the openEHR archetypes I work with, I thought I’d take this opportunity to draw together some of my research and request some assistance from others to crowdsource a picture of the detailed clinical model environment that we operate within.

I have published my initial attempt as a Google doc, see below. The existing information needs to be verified; there are clearly many gaps that need to be filled in; and there are probably other DCMs to be added.

EDIT the DCM environment document...

Anyone can participate, and if you edit, please add your name/org/email to the Contributor list, so that attribution can be made.

Please feel free to edit; to add new DCMs; to correct and verify the facts. Add a column, suggest changes to structure where you see a need... Just make a comment, if you like.

You can clearly see all the gaps in our collective knowledge at present…

Let’s see if we can actually pull together a useful resource. The intent is collaboration to achieve a goal that is possibly greater than most of us can achieve by ourselves.

All contributions are gratefully received and can be freely shared with anyone who is interested.

The latest crowdsourced version of the document appears below. You will need to scroll to seen the entire content.

[googleapps domain="docs" dir="document/pub" query="id=11xGZs4drfwb7TY15Iwpk52UIxZcFhqMcMp1i3yV4To8&embedded=true" /]

________________________________________

Further Comment: 11 August 2011

I've been asked where this work is going and what is planned...

The answer is that I haven’t a specific plan.

To my knowledge there has been no environmental scan to explore what the range of models is, to my knowledge, so thought I’d try myself. I spent a day to develop the initial framework, sparse though it was. Googling was a very frustrating experience and finding out the information that we’re interested in from available websites was not easy.

Hence I thought I’d experiment with the crowd sourcing approach. I know there is a rising tide of interest in the generic concept of detailed clinical models and a lot of confusion about the work in ISO and HL7.

I hoped it might contribute to clarifying the situation and providing a concrete anchor on which to base discussions on detailed clinical models.

Worst case scenario, the final result may be little more than a brainstorming, however it will at least form the basis for anyone interested to launch a more rigorous research program, including potentially feeding into the ISO work. Best case scenario, we may have a significant resource. Final outcome will probably be somewhere in between.

I’m happy to leave it online as a general resource – it seems to have generated a lot of interest. I'm hopeful that it will keep evolving.

Photographs: Art or Technology?l

This week we had a photography- friend arrive on a flying visit from overseas - 48 hours on the ground, including the seminar in which he was participating. We took him down the Great Ocean Road - a glorious coastal road - last time we drove it was in a rented Porsche, top down, for the full experience. But that was February - there was no desire to repeat it in July! We left at 8am and arrived back at 10pm - it is a long drive... with some choice stops along the way for refreshments and to absorb the views.

Our friend had most of his camera kit with him - 2x semi-professional digital bodies and multiple lenses, including the extraordinary 14-24mm fish-eye. I had my, um, phone camera!

At the end of the day we were happy and exhausted. Our friend had over 750 shots, I had about 120 - mostly variations of Gibson's steps, the 12 Apostles and Loch Ard Gorge in the late afternoon light.

We talked at length about the camera gear, tempting me to invest in some new technology. My last significant purchases were Nikon F801 and accessories back somewhere around 1990! Film! Yet it did give me some fun playing around with black and white developing for a short window. I haven't used this camera for at least 10 years.

I've had a couple of the early digital cameras - mostly with very ho hum results in the early days.

In recent years I have been the proud owner of a very modest Panasonic Lumix point and shoot - 7MP, 10x optical zoom, super little Leica lens. It has been a brilliant camera to fling in my handbag on overseas business trips - always there to capture some little treasure to bring home as a memory of the trip.

I'd like to think that I approach my photography a little more seriously than just taking happy snaps, but I'm not too precious about it. My aesthetic has refined over time, and I particularly enjoy the experience when I venture out specifically with the aim of taking photos - it changes the way I view my world around me, and I really value that.

I was browsing through my photos this week, and uploaded of my travel-related photos to try out the photo section on Google+. My brief trip down memory lane of my travels in recent years was largely the result of my trusty Panasonic P&S. And while I didn't have the range of lenses and manual settings, I have somehow managed to capture some very pleasing shots. I guess it comes down to understanding light and composition better now, after all this time.

While I have been briefly tempted this week to get back into 'the gear', the burden of lugging it all over the world and worrying about it being stolen etc seems too onerous - just not worth the effort.

I've decided I'm going to stick with something 'middle of the road', that gives me enough manual control to make my hobby satisfying, but is easily transportable and can be with me at all times - that fits better with my priorities.

So while all the photos above have been taken on a mobile phone, maybe I'll look at updating my trusty Panasonic - it's is looking pretty battle worn now, the body showing evidence of it's adventures from many scratches and scrapes!

While the technology is necessary, for me it just a tool for me to exercise my art!

[slideshow]

Anatomy of a Procedure

ACTION archetypes are one of the harder concepts to grasp in the openEHR clinical modeling world. ACTIONs appear to be promising the world - allowing for recording all activities from planning, scheduling, postponing, cancelling, suspending, through to carrying out and completing an activity. While they may appear cumbersome at first, they are surprisingly elegant and fit for purpose... once you can twist your brain around them.

Consider ACTION archetypes as a walrus - awkward on land, but graceful in the water - well maybe the analogy is being stretched a little, but you get my drift.

Whatever you do, don't underestimate the power of these little clinical models. ACTIONs are designed to enable sophisticated tracking of activities being carried out in a distributed environment - perfect for managing care pathways between multiple providers in disparate locations - not an easy task.

Take a look at this slide show - my attempt to provide a concrete example of how a Procedure ACTION archetype will support documentation about how an INSTRUCTION or order for a Procedure (any procedure, potentially) is carried out in a shared electronic health record environment.

  • 'Pathway steps' are identified as the steps (not necessarily sequential) or clinical activities in which it makes sense to record some information in the health record.
  • The Data Elements that are identified in the 'Description' include any and all information that we may wish to record for any of the Pathway steps. For example, the data we need to record when we plan to perform a Procedure or the information required to record that the Procedure was performed or abandoned, including the reason for abandonment.

[slideshare id=8563247&doc=201107instructionsactions-110711064154-phpapp02]

 

Updated: August 17, 2011

PCEHR insights

Chris Pearce posted this to a closed email list yesterday. I think it provides a useful insight into plans for the Australian Personally Controlled Electronic Health Record (PCEHR) that is not otherwise obvious. The Documents he refers to are two NEHTA specifications that are being developed in consultation with professional bodies, related to the PCEHR Shared Health Summary and PCEHR Event Summary. With his permission:

An overview that you might find helpful in making a bit more sense of the documents. If you need more detail, you may need to go back to the concept of operations document.

The Shared Health Summary (SHS) intended to be a curated, validated record. Initially it was meant to come from general practice, but in the consultation process this has been modified - and is now the role of a 'nominated provider', who must be a health professional who is capable of understanding the continuing, comprehensive care aspect, medications and the like. It will require a mutual consent process.

The event summary was initially designed to pick up where the SHS (which is fixed at a point of time) left off - so if you had something that would alter the SHS, you could put it in the Event summary - so for example- GP loads SHS, then refers patient to specialist who diagnoses diabetes - so loads event summary with diagnosis of diabetes, Rx of metformin. The actual scope is part of the consultation process that ACHI is now involved in.

The third piece of the puzzle is a thing called the consolidated view - which is designed to bring the information together in a meaningful way - SHS, event summaries, discharge summaries, other clinical documents. Thus in the above example a third party would see a list of the current conditions that would include the ones from the SHS (clearly identified as to provenance) along with the ones from an event summary (and from consumer entered data.

But, it does mean that one can have a health summary (uncurated, or really curated at a different level) 'view' built up over time without the shared health summary.

Author: Associate Professor Christopher Pearce PhD MFM MBBS FRACGP FACRRM FAICD FACHI Director of Research, Melbourne East General Practice Network Adjunct Associate Professor in General Practice, Monash University Visiting Fellow, Australian National University Clinical Lead, National E-Health Transitional Authority

Archetype Quality II

In my previous post, I proposed a high level diagram representing the archetype development processes. Pondering on this process further, I am generally happy with the high-level steps identified although the implementation step should really outside the scope of determining quality criteria for the archetype itself; thus four identified processes remain:

  • Requirements gathering & analysis:
  • Design & build:
  • Collaboration & verification; &
  • Publication, maintenance & distribution.

The next logical steps are to:

  1. Identify all of the sub-processes involved including the full set of activities required to create, produce, maintain and distribute the final archetype, including the people, materials, tools and procedures;
  2. Identify all of the points within these sub-processes at which we can define quality criteria; and
  3. Identify the individual quality indicators with which we can measure or asses each of the quality criteria.

In addition, I'm increasingly of the opinion that we should utilise some of the ideas outlined by Kalra et al to assist us to be systematic in our identification of the quality criteria and indicators. Kalra et al proposed high level quality criteria (or statements that demonstrate ideal practice) in the following categories:

  • Business Requirements
  • Clinical Requirements
  • Technical Requirements
  • Information Governance Requirements
  • Repository Requirements

I've modified these criteria categories to:

  • Design requirements/methodology - identification of quality criteria related to the design of an archetype where it impacts on any or all of these four processes. Examples include: inclusive design (maximal data set for universal use case as the ideal, except where over-inclusiveness makes the model impractical, confusing or unsafe; minimisation of overlap with other models; minimisation of duplication of data elements in multiple archetypes; direct terminology bindings and use of terminology reference sets; precision and detail; granularity; include another archetype fragment; mandatory vs optional; metadata; authorship and references/evidence;
  • Business requirements - identification of quality criteria ensuring that the archetypes support the required activities for data storage, exchange, querying, comparative analysis, secondary use, and knowledge-based activities such as decision support for any or all of these four processes.
  • Stakeholder requirements - identification of quality criteria ensuring that stakeholder requirements are represented in the final archetypes. The term stakeholder is deliberately used here, rather than only referring to clinicians, as while the archetype methodology enables clinicians to actively participate they are not the only domain experts who should be contributing to the model. The quality criteria will possibly predominantly focused on the archetype content, but the archetypes will not only be used to support direct clinical care but also a range of other purposes. For example, to support distributed care, clinical decision support, data aggregation and reporting, comparative data analysis, population health planning etc. All potential stakeholders who will either use the data created by the archetypes or implement them should be included in the stakeholder category.
  • Technical requirements - identification of quality criteria ensuring that the archetypes are technically 'fit for purpose'. Examples include ensuring that they conform to the openEHR reference model specifications; represent existing standards specifications or data sets, as appropriate; and technical attributes such as data constraints, occurrence/cardinality and null flavors are represented accurately.
  • Information governance requirements (including repository activity) - identification of quality criteria to ensure strong governance of each archetype through it's life-cycle and maturity within a repository, and processes to support the publication and distribution of meaningful sets of archetypes. Examples include  archetype version management; identification of relationships, including dependence, to other archetypes or knowledge artifacts such as terminology subsets; currency of archetype; endorsement or certification by professional colleges or jurisdictions; implemented use in real systems; implementation guidance; identification of  gaps/overlaps of coverage in sets of archetypes; design documentation; sample data; transformations; and overall quality and safety assessment.

[Note: I have specifically excluded establishing quality criteria for the Clinical Knowledge Repository itself - this should be a separate process which determines governance policy and process for a range of clinical knowledge artifacts within a repository application - including archetypes, templates, terminology subsets, transformation to other semantically equivalent artifacts and inclusion of models from other modeling approaches.]

Each of these categories of requirements will need to be considered in each of the four processes of archetype development. A candidate framework for consideration might therefore be represented in the following table:

Design requirements/ methodology Business requirements Stakeholder requirements Technical requirements Information governance requirements
Requirements gathering & analysis  √  √  X
Design & Build  √  √  X
Collaboration & Verification  √  √   √   √   √
Publication, Maintenance & Distribution X  X   √   √    √

Quality criteria and the indicators that will be used to measure or assess them should be identified for each area in the table represented by a tick (√).

Some simple examples of criteria that can be applied to the 'Collaboration & Verification' process have been outlined in a previous post,. demonstrating practical indicators to measure and assess criteria related to the collaborative review process, evidence-basis and 'fit for purpose'.

Reference: Kalra D, Tapuria A, Freriks G, Mennerat F, Devlies J (2008). Management and maintenance policies for EHR interoperability resources [36 pages] (Q-REC Project IST 027370 3.3). The European Commission: Brussels. (Last accessed May 28, 2011))

Unambiguous data: Positive presence; positive absence

The bulk of openEHR archetype modelling is focused on how to record the positive presence of data – for example the diagnosis of diabetes or asthma, or orders for long-term beta blocker medication. When it is not possible to determine data values – the nature of clinical medicine being not so exact a science – 'null flavours' are used to mark an 'incapacity to obtain data', especially for a mandatory data point. The current openEHR null flavours are:

  • no information - "No information provided; nothing can be inferred as to the reason why, including whether there might be a possible applicable value or not";
  • unknown – "A possible value exists but is not provided";
  • masked – "The value has not been provided due to privacy settings"; and
  • not applicable – "No valid value exists for this data item".

If there is no data recorded at all, nor any null flavour, no conclusion can safely be drawn from the lack of data; there is a void in our knowledge.

And then there is the need to record things that are noticeably not present. Some approaches subscribe the notion of 'negation' – resulting in a somewhat awkward and potentially ambiguous statement that might go something along the lines of 'diagnosis of diabetes, not', potentially sitting closely alongside another selectable term of 'diagnosis of diabetes'. You can see that it is easy to get it wrong.

The openEHR preferred approach is to record the positive absence of data – an explicit and unambiguous statement of 'no history of diabetes' in an archetype with the explicit intent to record the absence of a diagnosis.

Specific absence of data needs to be recorded positively, where this is sensible:

  • To encourage unambiguous clinical records;
  • Assisting clinical decision support; and sometimes (unfortunately)
  • For medico-legal purposes.

Examples of global positive exclusion statements include:

  • No known adverse reactions
  • No surgical history
  • No significant family history
  • Not currently taking any medicines

Specific positive exclusion statements include:

  • No known allergy to penicillin (or <insert drug/plant/food/venom or other substance here>);
  • No family history of bowel cancer (or <insert diagnosis here>);
  • Not currently taking immunosuppressants (or); or
  • No pacemaker in situ.

Keep in mind that exclusion statements are only meaningful and relevant at the decision-making moment at which they are recorded. They have a fleeting temporal validity, and then the question has to be asked again – "Are you allergic to anything?"or "Have you ever had any serious illness or operations?".

Some examples:

  • Recording an absence of an adverse reaction event to penicillin becomes immediately obsolete when the patient suffers an anaphylactic reaction to the penicillin subsequently administered; or
  • The past history might reveal no previous diagnosis of asthma, yet asthma might be the cause for today's wheeze; or
  • In a Discharge Summary – 'Not currently taking any medications' is a vital piece of information for the patient's usual GP, yet that drug-free state might only be current until the first follow-up visit.

So exclusions cannot be relied upon for any future decision-making. They are just 'in the moment' statements that need to be re-asked and regularly updated in records (both paper and electronic) as part of routine clinical practise.

So while they may be valuable, does that mean we desire to model every possible negative statement positively? This is certainly not desirable, nor is it helpful. A pragmatic approach is to research those situations where explicitly modelling exclusion statements provide some obvious value; preferably those that will have consistent re-use or may be utilised in knowledge-based activities such as Clinical Decision Support (CDS) systems.

Improved outcomes may result if CDS systems prompt for the recording a positive statement of:

  • 'no known adverse reactions' prior to prescribing medicines; or
  • 'no history of asthma' prior to prescribing beta blockers.

Currently we have archetypes for recording the presence of an Adverse Reaction, a Problem/Diagnosis, Family History and Medicines. In addition we have a generic parent archetype for Exclusion (ie the positive absence) plus specialisations for Adverse Reaction, Medication, Family History and Problem/Diagnosis exclusions so far.  The generic Exclusion archetype can be used as a standardised way to record the more uncommon statements – 'Not (currently) pregnant' might be a candidate here. But if there are regular use cases identified, these too may warrant their own explicit archetypes to ensure that positive absence is recorded consistently and safely.

Modelling pregnancy

How to go about using openEHR archetypes to model a shared pregnancy record? Step 1:  Analyse the existing resources; identify each of the discrete clinical concepts that contribute to the whole record.
24 clinical concepts have been identified within this example Pregnancy Health Record.

Step 2: Map clinical concepts to archetypes

Map them to existing archetypes or determine which new ones we need. Determine the state of the existing archetypes – do we need to modify or enhance with additional requirements? Consider all possible use cases for each archetype – the end result will be better if we can be as inclusive as possible for all clinical scenarios.

The archetypes identified for this Pregnancy record are:

Clinical Concept Comment

Corresponding archetype concept name NOTE: is linked to the actual archetype in a CKM instance

Antenatal Plan An overarching plan for the patient's antenatal care Antenatal Plan <INSTRUCTION.antenatal_plan>
Information Provided Details of each piece of health education information discussed or provided to patient Information Provided <ACTION.health_education>
Social Summary Social Summary <EVALUATION.social_summary>
Adverse Reaction List Adverse Reaction list is made up of multiple Adverse Reaction entries Adverse Reaction <EVALUATION.adverse_reaction>
Family History List Family History list is made up of multiple Family History entries Family History <EVALUATION.family_history>
Diagnosis Problem lists, whether current or past are made up of multiple Problem/Diagnosis entries – the same data pattern will be used in all instances Problem/Diagnosis <EVALUATION.problem_diagnosis>
Problem/Diagnosis List
Recent Problem/Diagnosis List
Procedure list Procedure list is made up of multiple Procedure entries Procedure <ACTION.procedure>
Smoking consumption Tobacco use <OBSERVATION.substance_use-tobacco>
Alcohol consumption Alcohol consumption <OBSERVATION.substance_use-alcohol>
Obstetric Summary Obstetric summary <EVALUATION.obstetric_summary>
Pregnancy Summary An evolving summary of key data about a single pregnancy – either current or past Pregnancy summary <EVALUATION.pregnancy_summary>
Examination Findings Examination Findings <OBSERVATION.exam> Examination of the uterus <CLUSTER.exam-uterus> Examination of the fetus <CLUSTER.exam-fetus>
Current Medication List Medication list is made up of multiple Medication instruction entries Medication instruction <INSTRUCTION.medication>
Medication administered Medication action <ACTION.medication>
Height Height/Length <OBSERVATION.height>
Weight Body weight <OBSERVATION.body_weight>
Body Mass Index Body Mass Index <OBSERVATION.body_mass_index>
Blood Pressure Blood Pressure <OBSERVATION.blood_pressure>
Fetal Movements Fetal Movements <OBSERVATION.fetal_movements>
Fetal heart sounds Heart rate and rhythm <OBSERVATION.heart_rate>
Urinalysis The pattern for urinalysis is identical to the pathology test results, and in some cases will be performed in the lab, so the same pattern will be used Pathology test result <OBSERVATION.pathology_test>
Pathology Test results
Ultrasound results Imaging examination result <OBSERVATION.imaging_exam>

KEY: Pink archetype names indicate those that are early drafts. Green archetype names indicate those that are reasonably mature – through previous reviews within CKM Red archetype names indicate those yet to be developed.

Step 3: CKM Review

Within CKM each archetype will undergo review rounds by a range of clinicians, terminologists, software engineers, informaticians and other interested experts. The purpose of each review round will be to fine-tune each archetype so that it meets the requirements for each stakeholder group.

CKM Videos:

Step 4: Create an openEHR template

Once community consensus is reached within CKM, the archetypes will be aggregated and constrained in a template to accurately meet the specific use-case requirements for this particular Pregnancy Health Record. Each bold, black heading in the the following screenshot represents an archetype. The Pregnancy Summary archetype has been opened up to see the details. Black text indicates data elements that will be utilised in this use case; grey text indicates inactive data elements.

Other groups may use the same archetypes aggregated in a different order and constrained in a different way to represent their version of the Pregnancy Health Record. As the data in both Pregnancy Records is being recorded according to the same pattern, dictated by the underlying archetype, the information can be exchanged without ambiguity or loss of meaning.

Quality indicators & the wisdom of crowds

Harnessing the 'wisdom of the crowd' has potential to more powerful than traditional quality processes for a determining the quality of our clinical content in EHRs - we need to learn how best to tap into that wisdom...

Archetype quality I

Up until recently clinical content models, such as archetypes, have been regarded as a novelty; watched from the sidelines with interest from many but not regarded as mainstream. However now that they are increasingly being adopted by jurisdictions and used in real systems, modellers need to change their approach to include processes, methodologies and quality criteria that ensure that the models are robust, credible and fit for purpose. There has been some work done identifying quality criteria for clinical models but there is no doubt that establishing quality criteria for clinical content models is still very much in its infancy:

  • There has been some slowly progressing work in ISO TC 215 - ISO 13972 Health Informatics: Detailed Clinical Models. Recently it has been split into two separate components, not yet publicly available:
    • Part 1. Quality processes regarding detailed clinical model development, governance, publishing and maintenance; and
    • Part II - Quality attributes of detailed clinical models

Most of the work on quality of clinical models has been based largely on theory, with few groups having practical experience in developing and managing collections of clinical models, other than in local implementations.

In 2007, Ocean Informatics participated in a significant pilot project. The recommendations were published in the NHS CFH Pilot Study 2007 Summary Report. My own analysis, conducted in December 2007, revealed that there were 691 archetypes within the NHS repository. Of these, 570 were archetypes for unique clinical concepts, with the remainder reflecting multiple versions of the same concept. In fact, for 90 unique concepts there were 207 archetypes that needed rationalisation – most of these had only two versions however one archetype was represented in five versions! We needed better processes!

Towards the end of 2007 a small team within Ocean commenced building an online tool, the Clinical Knowledge Manager to:

  • function as a clinical knowledge repository for openEHR archetypes and templates and, later, terminology subsets;
  • manage the life-cycle of registered artefacts, especially the archetype content – from draft, through team review to published, deprecated and rejected. Also terminology binding and language translations;
  • governance of the artefacts.

In July 2008 we started uploading archetypes to the openEHR CKM, including many of the best from the NHS pilot project. Over the following months we added archetypes and templates; recruited users; and started archetype reviews. All activity was voluntary – both from reviewers and editors. Progress has thus been slower than we would have liked and somewhat episodic but provided early evidence that a transparent, crowd sourced verification of the archetypes was achievable.

In early 2010, Sweden's Clinical Knowledge Manager had its first archetypes uploaded.

In November 2010, a NEHTA instance of the CKM was launched, supporting Australia's development of Detailed Clinical Models for the national eHealth priorities. This is where most collaborative activity is occurring internationally at present.

In this context, I have pondered the issues around clinical knowledge governance now for a number of years, and gradually our team has developed considerable insight into clinical knowledge governance – the requirements, solutions and thorny issues. To be perfectly honest, the more we delve into knowledge governance, the more complicated we realise it to be – the challenge and the journey continues; a lot is yet to be solved :)

It is relatively easy to identify the high level processes in the development of clinical knowledge artifacts, each of which requires identification of quality criteria and measurable indicators to ensure that the final artifacts are fit for purpose and safe to use in our EHR systems. The process is similar for both archetypes and templates; plus the Requirements gathering and Analysis components are applicable to any single overarching project as well.

For archetypes:

The harder task is that for each of these steps, there are multiple quality criteria that need to be determined, and for each criterion it will be necessary to be able to assess and/or measure them through identifiable quality indicators.

Ideally a quality indicator is a measurement or fact about the clinical model. In some situations it will be necessary to include additional assessments manually performed by qualified experts.

If an indicator can be automatically derived from the Clinical Knowledge Manager (CKM), it ensures that up-to-date assessments of the models are instantly available as the models evolve (such as this Blood Pressure archetype example), and more importantly, without reliance on manual human intervention. However while assessments that do need to be assessed by an expert human – for example, compliance to existing specifications or standards – add valuable depth and richness to the overall quality assessment, they also add a vulnerability due to the need for skilled human resources to not only conduct the assessment, but to apply consistent methodologies during the assessment; these will be much more difficult to sustain.

Assessment of whether the indicators actually satisfy the quality criteria should also ideally be as objective as possible, however our reality is that it will probably more often be subjective and vary depending on the nature of the archetype concept itself. The process cannot be automated, nor can there be a single set of indicators or criteria that will determine the quality of every archetype. We need to ensure appropriate oversight to archetype development, ensuring that a quality process has actually been followed and utilise quality indicators to determine if the quality criteria have been met - on an archetype by archetype basis.

And it continues on...

Clinical modeling: academic vs practical

In a comment on the previous DCM post,  Gordon Tomes sent a link to an interesting 2009 academic paper by Scheuermann, Ceusters & Smith - Toward an Ontological Treatment of Disease and Diagnosis [PDF] There is a place for this 'pure', academic approach as a means to seek clarity in definitions, but a telling sentence in the paper for me is: "Thus we do not claim that ‘disease’ as here defined denotes what clinician in every case refer to when they use the term ‘disease’. Rather, our definitions are designed to make clear that such clinical use is often ambiguous."

This is totally right, but despite the apparent ambiguity this clinicians still manage :)

The approach for archetypes/DCMs is not to get tied up in these definitional knots unnecessarily but to concentrate on consensus building around the structure of the data. Use of ontologies and definitions are key elements in designing and modelling archetypes but the resulting models should not be based on academic theory but on existing clinical practice and processes. Our EHRs need to represent what clinicians actually need to do in order to provide care. Sometimes we need to be practical and pragmatic. For example, I once challenged a dissenter to build a Blood Pressure archetype based purely using SNOMED codes - the result was a nonsense, a model that he agreed was not useable by clinicians.

The approach to building the Problem/Diagnosis archetype has not been to try to differentiate these two terms pedantically. Many have tried to separate a 'Problem' from a 'Diagnosis' for years with little success - no point waiting for this to be resolved, it probably won't. And even if we did make a theoretical decision on a definition for each, the clinicians would still likely classify the way they always did, not the way the academics or standards-makers would like them to do it!

In the  collaborative CKM reviews for the NEHTA Problem/Diagnosis archetype we have been able to observe that clinicians and other stakeholders have achieved some consensus around the structured data required to represent the concepts of a problem plus the addition of some extra optional data elements to represent formal diagnoses. After completing only four review rounds, the discussion now is focused on finessing the metadata and descriptions, not on debating the structure of the model.

Clinicians may still go round in circles arguing about what constitutes an actual problem vs a diagnosis - for example, some may classify  heartburn as a problem, others as diagnosis. No matter. By using a single model to represent both we can ensure that no matter how heartburn may be labelled by any individual clinician, we can easily query and find the data in a health record, and in addition there is a single common model to be referenced by clinical decision support engines.

A small success, maybe.

openEHR: interoperability or systems?

Thomas Beale (CTO of Ocean Informatics and chair of the Architecture Review Board of the openEHR Foundation) posted these two paragraphs as part of the background for his recent Woland's Cat post - The Null Flavour debate - part I. It is an important statement that I don't want to get lost amongst other discussion, so I've reposted it here:

An initial comment I will make is that there is a notion that openEHR is ‘about defining systems’ whereas HL7 ‘is about interoperability’. This is incorrect. openEHR is primarily about solving the information interoperability problem in health, and it addresses all information, regardless of whether it is inside a system or in a message. (It does define some reference model semantics specific to the notion of ‘storing information’, mainly around versioning and auditing, but this has nothing to do with the main interoperability emphasis.)

To see that openEHR is about generalised interoperability, all that is needed is to consider a lab archetype such as Lipid studies in the Clinical Knowledge Manager. This archetype defines a possible structure of a Lipids lab test result, in terms of basic information model primitives (Entry, History, Cluster, Element etc). In the openEHR approach, we use this same model as the formal definition of this kind of information is in a message travelling ‘between systems’, in a database or on the screen within a ‘system’. This is one of the great benefits of openEHR: messages are not done differently from everything else. Neither is interoperability of data in messages between systems different from that of data between applications or other parts of a ‘system’.

Engaging Clinicians in Clinical Content (in Sarajevo)

Just browsing and found the link to our presentation for a paper the CKM team gave at the Medical Informatics Europe conference in Bosnia, 2009. Thought I'd share it here, in memory of an amazing conference and location:

MIE09: Engaging Clinicians in Clinical Content [PDF]

Our presentation:

[slideshare id=1958920&doc=engagingcliniciansinclinicalcontent-090906091020-phpapp02]

And the reference to Herding Cats is explained (a little) in the embedded video - actually an advertisement for EDS:

[youtube http://www.youtube.com/watch?v=Pk7yqlTMvp8&w=425&h=349]

I arrived after a 37 hour flight - Melbourne - London - Vienna - Sarajevo to join my Ocean CKM team - Ian McNicoll and Sebastian Garde. We presented our paper and also ran an openEHR workshop.

The conference was held at the Holiday Inn in Sarajevo - the hotel in which all the international journalists were holed up during the war, on 'Sniper Alley'.

Despite it being 14 years after the war had ended, raw emotions were palpable many times during the conference. That a pan-European conference was being held in his beloved Sarajevo under his auspice was a very overwhelming event for the Professor of Informatics and he was often seen in tears!

From my hotel room window in the centre of the city I could see 6 cemeteries.

Walking through the inner city we came across many cemeteries, thousands of marble gravestones with the majority representing the young men aged between 18 & 26.

Bullet holes were still very obvious on the walls of buildings.

Yet the city was vibrant, alive and welcoming.

I won't ever forget this visit.

Some photos of the experience:

DCMs – clarifying the confusion

Detailed clinical models are certainly a buzz term in the health IT community in recent years, commonly abbreviated to DCMs. Many people are talking about them but unfortunately, often they are referring to different things. The level of confusion is at least as large as the hype.I sincerely hope that this post helps to lift the veil of confusion just a little...

Anatomy of a Problem... a Diagnosis...

Problem or Diagnosis? Does it really matter?

Representation of the concept of a Problem or Diagnosis is a cornerstone of an electronic health record. Yet to date it seems to have been harder than expected to achieve consensus. Why is this so?

Games for Life?

"Anyone who sees a hurricane coming should warn others. I see a hurricane coming.

Over the next generation or two, ever larger numbers of people, hundreds of millions, will become immersed in virtual worlds and online games. While we are playing, things we used to do on the outside, in "reality," won't be happening anymore, or won't be happening in the same way. You can't pull millions of person-hours out of a society without creating an atmospheric-level event.

If it happens in a generation, I think the twenty-first century will see a social cataclysm larger than that caused by cars, radios, and TV, combined... The exodus of these people from the real world, from our normal daily life, will create a change in social climate that makes global warming look like a tempest in a teacup."

EDWARD CASTRONOVA, Exodus to the Virtual World (paraphrased in "Reality is Broken")

How do games work? Why are humans so drawn to games? What can they do for us in our real lives?

These are questions posed in just the first chapter of Janet McGonigal's recently published 'Reality Is Broken: Why Games Make Us Better and How They Can Change the World'.

On page 3...

"Games developers know better than anyone else how to inspire extreme effort and reward hard work. They know how to facilitate cooperation and collaboration at previously unimaginable scales. And they are continuously innovating new ways to motivate players to stick with harder challenges, for longer, and in much bigger groups. These crucial twenty-first-century skills can help all of us find new ways to make a deep and lasting impact on the world around us.

Game design isn't just a technological craft. It's a twenty-first-century way or thinking and leading, and gameplay isn't just a pastime. It's a twenty-first-century way of working together to accomplish real change."

And

"If we take everything game developers have learned about optimising human experience and organizing collaborative communities and apply it to real life... I foresee games that reduce our stress at work and dramatically increase our career satisfaction. I foresee games that fix our educational systems. I foresee games that treat depression, obesity, anxiety, and attention deficit disorder. I foresee games that help the elderly feel engaged and socially connected. I foresee games that raise rates of democratic participation. I foresee games that tackle global-scale problems like climate change and poverty. In short, I foresee games that augment our most essential human capabilities - to be happy, resilient, creative - and empower us to change the world in meaningful ways... Such games are already coming into existence."

"We need to build hybrid industries and unconventional partnerships, so that game researchers and game designers and game developers can work with engineers and architects and policy makers and executives of all kinds to harness the power of games.

Finally but most importantly, we all need to develop our core game competencies so we can take an active role in changing our lives and enabling the future."

I've observed family and friends of all ages engrossed (?obsessed) with game playing for as long as I can remember. I've even experienced it myself. Confession time: I was so engrossed in playing a game that I forgot to pick my kids up from school - they've never let me forget and that was over 15 years ago! However, it was a very powerful experience - absorption in a strategy game removing all sense of time or responsibility from my mind, complete focus on an alternate reality. I don't doubt the potential power of games...

For some time I've been pondering how to harness the gaming phenomenon to create positive outcomes and, in particular, its potential to improve health. I have been observing efforts such as Games for Health with interest. Now this book raises the possibility of the application of gaming to any/all facets of our lives. Where will it end? Is this a good direction?

Amusingly, my youngest son has proposed a new method to promote a fairer distribution of chores in our house - using Chore Wars to gain experience points, treasure etc as rewards for competing 'adventures' (aka chores). That's a great idea if all siblings are prepared to compete to win, but unfortunately for him his brothers quietly smile and are very happy to lose this particular game:) Close, but no cigar!