EHRs: the means, not the end

I remember hearing a story about a software demonstration for practice management and billing - a classic where the practice principal proudly stood up and gave testimony about the merits of his new system, including the news that he had to hire extra staff in order to run it, above those who had run the practice beforehand.  Apparently the audience's collective jaws 'hit the floor'.  This is not good eHealth.  Health IT should not add overheads, but make things smarter, quicker, more efficient, and more valuable - or it's probably not worth doing. There is something weird that appears to happen around computers and all things 'e' - sometimes we just seem to lose our analytical skills, or perspective, when sitting in front of a computer. Computers are just tools to support us in our practice of healthcare.

In KevinMD's excellent guest blog in August 2009, "How a wealth of information takes attention away from the patient", Abraham Verghese discusses the tension experienced - look at the data or the patient? With more information available at our fingertips and with only a limited amount of time per patient, how do we prioritize our focus for the best outcomes?  It's not easy as you might first think. We can be torn between the need or desire for (possibly) higher quality, detailed data, rather than the conducting a thorough patient history and exam - after all, time is limited.

When I was in medical school it was always drummed into me that you couldn't compromise a thorough medical history; that a history was possibly way and above more important than even the examination and the secret to good medical practice.  I have always considered that this is a good principle to work by.

If using an electronic health record (EHR) compromises those high standards, then it is time for a re-think.  An EHR should enhance, not hinder.  If it gets in the way of you talking or touching the patient, or causes you to spend more time or effort WITHOUT providing value back then there is something wrong. Note that the value may be direct and immediate (e.g. more efficient; data available at point of care) or indirect and delayed (e.g. better quality data; ability to do query/research, support recalls etc). The benefits should be obvious. Difficulties are usually multifactorial - the clinician; the application; the inability to touch type; or other factors - but they are an important trigger for stopping and investigating the current work processes so that the problems and barriers can be identified and tackled.

Anecdotally, it has surprised me to see some clinicians assume that data displayed on a computer screen has more authority than it warrants, because it is electronic format. They change the way they practice. However, just as in a paper record, because 'nil known' is noted on a computer screen next to 'Known allergies' does not necessarily mean that they don't have any - you still have to ask as the answer may have changed since last asked.  Whether a previous clinician has written in pen or electronically, there is no difference to how we should practise.

Are we compromising our practice? The good old doctor-patient interaction vs. the EHR?

An EHR should not change the way a clinician engages with the patient.

So, it's not rocket science, but don't EHR for EHR's sake. After all, let's face it; an EHR is only useful if it supports quality health care. It is a means to an end, the journey, but not THE end.

Yes, you might arrange the office differently and there might be more opportunity for collaboration once the patient can see their record - that's all good. But if use of an EHR compromises the doctor-patient communication, the recording of data, the use of time in a consultation, or making the history-taking and examination a priority, then the issue needs identification and quick resolution.

Don't lose those first principles that you learned in medical school - they are the foundation of the doctor-patient interaction. The EHR should just be a supportive framework to enable you to do a better job.  If it doesn't, stop and re-think as the EHR should enhance, not hinder.

But you all know that already - this is just a reminder for when we lose a little focus in the excitement...

Street Art and Doors

I have loved taking photos for many years. It has just been a hobby, something to distract from the routine. But it has made me stop and view the world around me from a slightly different angle. I love the textures and small details, and it is only with a camera in hand that I slow down and look up! In early 2007 I participated in a National Gallery of Victoria guided walk around my home city of Melbourne, down into the subways and past dumpsters into stinking alleys. I saw the street art around me of which I had previously been ignorant. So now as I walk around my local inner city streets I deliberately take detours down alleys and dead ends to seek out the art works – the ‘pieces, the paste-ups, the stencils that sometimes tell a story and other times are just appealing to look at; the walls and alleys that are ‘curated’ and collaborative artworks that are appearing all over my local streets. And I've found it is a great reason to get out and explore a new city or find new aspects of an old one.

Don’t misunderstand me, to those who tag my house periodically... pox on you! That’s just plain vandalism and it costs me a sweet fortune to get it cleaned off. But to those who pursue their craft with the right permissions, I think I envy you a little – your art enables me to feel a little anarchic and a little rebellious, but vicariously and without the heights!

Other objects I like are doors & gates. As eyes are like windows on the soul, doors are the 'windows' (oops, sorry) of the city... they tell you a little something about those who live there. Well, it’s a nice thought, and I have a few photos of doors. Well, it's also a bit of an obsession really. No-one else gets it! You will also likely see some textured and abstract photos.

Anyway, as an exercise to nurture my soul a little, I decided to post a photo on Flickr each day this year - my #365photo challenge to myself. Will I succeed or not? No idea, but so far, so good - up to D13! My intention is to focus on finding some new street art and posting it, but the pressure of finding new stuff everyday is probably unsustainable, so will mix with a few photos that I have gathered over the last few years, mainly from time spent trawling East London in 2007 looking for the elusive artwork of Banksy, plus a few doors from my travels.

So, the Flickr photostream itself will hopefully evolve throughout the year and today I have added a few photos from it to this blog (in the right column) - each day they should change as I add another to my #365photo challenge.

Enjoy, or not – as you please. It just is.

Standardized, data-driven eHealth

What is an EHR? Most currently working within eHealth circles will have a ready answer, and the classic response will be something like "an EHR is a software application that is used by clinicians for provision of patient care". But think about it for a second...

What do we want from an electronic health record? It's not actually the application or the user interface or the workflow, but a record of health information in an electronic format.

And so what of the health information itself? What is it? What do we want? What should we want?

Let's work with these definitions: Data are the computable facts; while health information is the data after it is processed, organized, structured or presented in a given context so as to make it useful.

We definitely want health information that...

  • Is available at the right time and the right place to the right person.
  • Is accurate, detailed and of high quality.

I don't think there is much disagreement on these two points. How about these next suggestions?

We should also want health information that...

  • Is a lifetime health record - cradle to grave. Health information that can be accumulated over time, aggregated from many sources to inform better care for ourselves, our patients and loved ones.
  • Can be created in one place or by one provider and shared with others so that the meaning of the data is preserved and accurate.
  • Can be dynamically and actively used - consisting of structured, atomized data that we can re-use and combine in different ways to improve our health and wellness. Documents or PDF's of our health information are useful as part of a passive record, but they are effectively a dead end - we can't do anything useful with big blobs of text except read them.
  • Is not locked in to a proprietary vendor database; data should be in an open, non-proprietary format.
  • Is a continuum of our health information across all aspects of healthcare and related activities, not fragmented silos of data artificially segmented for personal, clinical or secondary use purposes.
  • Can be accessed via an EHR, EMR or PHR, SEHR or ICEHR - pick an acronym, any acronym!
  • Can be accessed independent of any specific organizations, providers and geographical locations.
  • Has had minimal transformation or manipulation. Keep in mind the Chinese Whispers effect! There is significant risk that important data can be lost or lose integrity with each data migration to a new software application or transformation between disparate systems.

It is a commercial reality that we continue to develop EHR applications in the traditional manner, building the greatest and 'best of breed' clinical software applications, with each EHR vendor doing it in their own proprietary way, as 'rugged individuals'! The resulting software usually has a rich functionality and a great user interface. It is likely that it does a fine job locally in the clinic, hospital or network on which it is installed. But what about regionally, nationally, internationally? Is it still working well if we take the big picture view? Sure, our EHR applications are full of data, but the data is isolated, fragmented, and limited in its use.

There is no doubt that all over the world, the health IT community are finding it unexpectedly hard to exchange health information between different applications - the effort and resources that are being poured into policy, research and pilots for health information exchange is enormous. Progress is glacially slow. If we want to exchange PDFs and documents, then we are doing well, but if we want our software to be able to do more than display text, to do clever things with our health information, then our data requirements are much more complex. If we want that data to be able to be shared, used in multiple applications then the current approach requiring data transformations and messaging paradigms won't be sustainable

Interestingly, the further we go down these paths many are realizing the need to change our emphasis away from the EHR application and towards the data. Back in November 2009, Clay Shirky wrote:

"This ability to separate data from transport and applications from data is the essential pre-condition for innovation — a group that has a valuable new idea for presentation of data for clinical use should not also be forced to think about the data encoding or the way the data are transported. Groups working on new data encodings should not be tied to a pre-existing suite of potential applications, nor should they have to change anything in the transport layer to send the new data out, and so on."

The bolded text, above, reflects my emphasis on an important statement. Confirming this approach, as recently as this week, Kibbe & Klepper also called for separation of the data from the applications and from the transport layer.

Change the focus to standardized, data-driven eHealth

So, innovation requires a new approach to data; a changing emphasis from application- or message-driven to data-driven eHealth. If we also insist on an open and standardized approach to health data specifications then we will be able to realize many additional advantages:

  • A strong foundation of shareable and re-usable computable clinical content definitions on which to build coordinated and cohesive applications, messages, clinical decision support programs, and research activities. If we use common, standardized data definitions then the tasks of eHealth become orders of magnitude easier. Content definitions are created and agreed as the content is already specified and the processes become more generic
  • An unambiguous and detailed understanding of what each piece of data means so we can do 'stuff' with it - a tight semantic 'handle'.
  • A powerful enabler for managing the complex requirements involved in health data capture, integration, aggregation, inferencing and sharing.
  • A continuum of our health information, independent of vendor, provider or organization - the real potential for lifelong health records, for the first time.

There is no doubt that this approach is orthogonal to the status quo and it will be challenging to many for logistical, financial and political reasons, but can we really afford to ignore this?

According to the European Commission's seminal 2009 report entitled "Semantic Interoperability for Better Health and Safer Healthcare: Research and Deployment Roadmap For Europe" (PDF, p16), standardizing the capture, representation and communication of clinical data requires three components to represent meaning: a generic reference model for representing clinical data, agreed clinical data structure definitions and clinical terminology systems. Potential standardized data definitions proposed are openEHR archetypes, ISO/EN 13606 Part 2 (which are simpler archetype structures), HL7 templates, generic templates and data sets.  Standardization of data is not 'pie in the sky' but an approach that has had significant research and implementation experience, particularly in Europe.

So, to consumers, clinicians, organizations, researchers and governments, the call should not only be "Gimme my damn data!" but give me standardized data that is application- and message-independent. Then we can actually start to use and re-use our data, not only as a detailed record of current and past health conditions, events and activities, but dynamically and pro-actively to inform and promote our future health and well-being.

PHRs: still a powerful grassroots approach to eHealth

In 1999 four clinicians and an ex-CIO gathered around my kitchen table and week by week we hatched a plan for a Personal Health Record (PHR) which we hoped could revolutionise healthcare. At that time a PHR was not at all mainstream. Very few clinicians we spoke to thought it was a good idea at all. Many held a very paternalistic view that patients were not capable to handle their health information, and that a PHR would not ever be trusted as a useful resource (- for some reason a verbal a history was acceptable but a patient entered record of some sort was not)! Patients were also pretty passive and had to be convinced that they could be supported to manage their health information in a similar way that they managed their finances! In January 2000, those last heady days of the dot-com era we started development in earnest, then rode the rollercoaster and navigated the fallout of the dot-com crash. HotHealth was launched in November 2000. My clinical colleagues were still not very enthusiastic about the concept. The business model was not easy. Large companies, health insurers, hospitals, pharmaceutical companies - everyone could see how a PHR would be 'useful', but none would commit. The funding dried up and it/we were acquired by listed company in 2002.

In the US, there were a fair number of PHRs in 2000, maybe even as many as 50. DrKoop.com (now apparently HealthCentral) was the clear leader at the time; WebMD is probably the only significant one remaining. Our annual market research for competitors showed a huge turnover - PHRs were appearing and disappearing at a great rate!

But the evidence was starting to come in and support the concept - Kate Lorig's work at Stanford on supported self-management in arthritis was working well on paper and face-to-face. We applied some of these principles to HotHealth plus health summaries, prevention plans, wellness promotion, quality health information etc - the kinds of features we are used to seeing in PHRs now.

Well, HotHealth still exists and has had some modest success, mostly in the spin off of a PHR for older children and teenagers with insulin dependent diabetes which ran between 2003 and 2005 - Betterdiabetes - but it never blossomed as I had hoped. Was it the timing? Was it the business model? Was Australia too small a market. Yes to all of these, and much more - it was harder than we anticipated.

In 2005 I was asked to write a commentary in Australian Health Review - "The patient’s memory stick may complement electronic health records"(PDF of full text). Re-reading it now, I can't help but be disappointed that not a lot has really changed in terms of integration and data exchange between clinicians and patients. We have made some small progress, but I thought the revolution would have happened by now.

Amusingly I think that my final paragraph in that commentary, written back in September 2005, still stands true.

"A grassroots push by consumers wishing to hold, own and manage their own health information has the potential to make relatively quick, inexpensive and significant changes to the way healthcare is delivered, to support and encourage consumer input to their own health information record, and kick-start electronic health record development in Australia. And eventually when our individual PHRs evolve to amalgamate and integrate with the HealthConnect* implementation, we will all be beneficiaries of an integrated and interoperable health system, meeting the needs of all participants in a timely manner, and most importantly enhancing health outcomes, and minimising risk."

It's just been a longer journey that I first thought!

Reflecting today, I think that those four words in bold - "grassroots push by consumers" - are important. Health care consumers are now better educated and equipped than ever before to decide what it is that they want from eHealth. Let's complement the top-down national program approach with a powerful, bottom-up, consumer-driven kickstart to eHealth!

More than just requesting our data in a readable format, more than collecting a heap of printed pages or folders of pdfs, we should be requesting our data be in a format that we can do something with, data that we can actually re-use. Think of all the little bits of health information that have been created and left behind after each consultation with your family doctor and at each hospital visit. And of course don't forget your dentist and physio, your naturopath who also prescribes for you nor the doctor you saw only once while on holiday in some far off place. Think of what we could do with all that data; if we could only aggregate all of these snippets of information together. The PHR is the most likely place for our fragmented data to come together; the result being a broader, deeper and richer record than could be achieved by any one provider!

I still firmly believe that Personal Health Records have the potential to transform the way we deliver health care. It may take longer than we all anticipate but the PHR is a very powerful grassroots approach to eHealth. Be patient;-)

*HealthConnect was Australia's eHealth program at the time - now totally MIA and no evidence of it exists online!

Why Is The Shared EHR So Hard?

'Provision of the right data to the right provider at the right time' is the mantra we commonly hear in eHealth. It sounds deceptively simple! Some promise it; some hope for it; but pretty much no-one has it. The collective desire for a seamless and efficient shared electronic health record (EHR) which actually provides that data to the provider at a particular time is widespread and yet the EHR remains elusive. If we know what we want, why is the shared EHR so hard to achieve? Why is it taking so long? And what's more, if the financial sector can do it, why not health?

The progress that we have made in the past 10-20 years of eHealth development has been glacially slow compared to other industries and domains. The approach to health IT, and in particular the shared EHR, has been primarily linear in nature with modest incremental successes achieved. Sure, progress has definitely been made, but despite investing enormous amounts of money and resources, the solution has been more difficult than most ever anticipated. Healthcare doesn't appear to fit the same data interoperability model that has been successful in other domains such as banking or financial services. In a world where connectivity reigns and personal data can flow freely, it is not yet the norm for our health information to be connected nor to flow!

In trying to understand the problem more fully, there are 3 broad headings we need to explore:

  1. Technical
  2. Human interaction and activities
  3. Information exchange

Let's explore some of these issues:

1. Technical

There is little doubt that traditional EHR development has been driven by technology requirements and engineering processes, so many of the typical aspects we consider when thinking of the EHR are actually quite manageable, if not solved - consider storage and retrieval of data, security, role-based access, audit trails, repository storage etc. It is not the technology holding us back here. Some even suggest that the technical aspects of the standalone EHR are the (relatively) easy part, and they may well be right!

With over 7000 EHR vendors in the United States alone, we have proof that building a standalone EHR is undoubtedly achievable. Our EHRs that are in use are traditionally rugged individuals, each created in splendid isolation with the finest data structure, processes and user interfaces! Unfortunately, building proprietary silos of health information is the almost universal approach to EHR development adopted by vendors and does not make it easy for health data to be shared.

I have seen and heard some say that we already have all the standards that we need for eHealth. This is still somewhat controversial and perhaps depends on what part of eHealth that you are trying to make work. For a coordinated eHealth system the desire is for each standards to not only achieve its purpose and goal, but to harmonize with all the others in existence to create a unified whole. Can this vision be achieved? There are certainly some examples of very successful standards.  There are also some examples of tweaking of standards for local use... which makes them non-standard again. There are also some examples of standards that have never yet been implemented... what? Let me refer you to the blog post from my colleague - The Crisis in eHealth Standards, by software engineer, Thomas Beale - for an erudite discourse on the strengths and weakness of standards and the standards processes.

2. Human interaction and activities

There is no doubt that some EHR technological achievements have been delayed or even diverted by the human, political and regulatory issues arising from practical implementation - and in most instances, rightly so.  We can develop a technological solution, the 'what', but in many jurisdictions the 'how' still has everyone tied up in knots.  For example we have technical solutions for unique patient identifiers, data security, and role-based access to data - but 'how' to apply these in practice is more elusive, often crossing into moral and ethical arguments (including confidentiality and privacy), requiring broad social and political agreement and sometimes supportive legislation. These issues have received a disproportionate amount of attention, particularly in the media, and perhaps at the expense of issues that follow which are not so well understood, yet!

Healthcare is not primarily a technical business - it is about people. Yet in our rush towards EHR development we seem to have focused on the EHR being a technical solution rather than merely a tool or medium to support the practical application of health knowledge and provision of healthcare to real people.  Some of the most underestimated and misunderstood problems in EHR development are related to:

  • the scope and dynamic nature of our health knowledge domain;
  • the nature of the human-human interaction that underpins quality health care;
  • the approach to capturing and storing the essence of a clinical encounter; and
  • the changing clinical requirements, processes and approaches to healthcare provision.

None of these are trivial concepts.  They are in the metaphorical 'EHR too hard basket', but we need to address them...

Health is possibly (more likely, probably) the most complex knowledge domain.  The extent and scope of health-related knowledge that needs to be represented in an EHR is enormous - it has huge breadth and depth, plus a fine web of complex relationships.  Most commonly underestimated is that health knowledge is dynamic - requirements distilled from a clinician and built into an EHR application by a software engineer today can be out-of-date by the time the product is launched.

An encounter between a clinician and a patient is a very complex pas de deux, an intricate communication dance between two parties.  Interestingly we clinicians have developed surprisingly effective written methods to capture the information exchange from these encounters, with all the required subtleties and nuances. Capturing the essence of this encounter into a format that can be stored, re-used, queried and shared on a computer is a daunting task and more complex than first appears. Attempting to represent both the data and our clinical processes via the user interface on a computer screen is definitely also an advanced task.

The nature of healthcare provision is also in flux. Consumers/patients/clients/citizens/individuals are increasingly mobile, more now than ever before, demanding healthcare from a range of providers in varying geographical locations.  Gone is the old-fashioned notion of the local family physician providing all our needs for all generations of the family; the local physicians are morphing into our health coordinators and facilitators in a world of collaborative and distributed models of care. Our ability to diagnose, treat and prevent conditions are moving with the assistance of new technological advances - in particular, watch out for the potential tsunami-like impact of personalized medicine/genomics on healthcare in the next few years.

3. Information exchange

There are many differing approaches to sharing health information. Why? The plain answer is that it is hard and there is no clear way forward; there are also many differing requirements and starting points:

  • Logically, the technical task of sharing health information would be easier if the data was in a common format. Conversely sharing seems to become more difficult by orders of magnitude if our collective data structure is in chaos.
  • Practically, some require only the simple exchange of a readable document such as a PDF or semi-structured documents. At the opposite end of the scale, there is need for EHR systems to share detailed and structured health information, so that not only can clinicians and patients read it but the meaning of each piece of data is clearly understood and it can be directly integrated into the computer and utilized in clinical decision-making - this is known as semantic interoperability.

In many places, national eHealth programs and the myriad of 'ruggedly individual' EHR vendors are pursuing technical approaches to data exchange through the set-up of information exchange hubs, message mapping and data transformations.  In this instance the focus is on exchange of complete or semi-structured documents as readable health information. Europe and some other parts of the world are taking a different approach, focusing on the exchange of standardized, atomic data  and reflected in the European decision to adopt ISO/EN 13606 as its standard for EHR extract exchange.

Exchange of unstructured health-related documents as 'blobs' of data is a great starting point, but in the long term it is a dead end. In reality it is not a sound basis for a shared EHR, nor interoperability, as we can only read them and then store them passively within the EHR. Personally, I want a dynamic, lifelong EHR for myself and my patients - one that can actively create, receive, integrate and re-use my atomic health information and put it to work for me to improve my current health and to provide the basis for future health decisions.

'Provision of the right data to the right provider at the right time' - can this actually be achieved? Clearly the relatively safe, comfortable and incremental technical innovation that has underpinned our EHR development to date hasn't provided the shared EHR solution we hoped for. So at this point let us draw from the wisdom of Einstein: “We can't solve problems by using the same kind of thinking we used when we created them." Indeed, perhaps it is time for a different approach to the shared EHR; one in which we divert our focus and are encouraged to push boundaries; to seek transformational change in our approach to eHealth.

In future posts, I hope to explore some of these issues in more depth and, in turn, some opportunities that arise...

Acknowledgments: Dr Sam Heard and Dr Hugh Leslie

Waving in eHealth

I’m excited and optimistic about Google Wave. In my mind, its key strength is as a brilliant hybrid medium for complex, small group conversations:

  • allowing tightly focused, tree-like threads, through contextual inline replies;
  • synchronous & asynchronous collaboration, wherever useful or most appropriate; and
  • inclusion of shared resource files.

So, Google Wave in eHealth - how could it be used?

A few thoughts...

1. Health Conversations

  • For private use...

For Patient to Patient or Clinician to Clinician conversations, Wave is a great way for individuals to share thoughts and information on any topic, health included, and no matter what the personal or professional purpose. However if the topic IS health, then there also should be a caveat that the Wave doesn’t contain any private health information. It is not unreasonable to assume that sharing health information in Wave is similar to that of using insecure emails – so just don’t do it!

  • For use in healthcare provision...

As a vehicle for a dialogue between Clinician and Patient, Wave is great but it is important to keep in mind that this is not just your average chat, but another format of an online consultation, and all the complications that this brings. If Wave is embedded in an appropriately secure environment, such as an existing EHR/PHR platform with appropriate privacy provisions/authorizations etc. and where versioning of the Wave could be recorded to support the medico-legal record, then Wave could be a great tool in eHealth.  Remember that this is a preview and it is a new technology, so there will be hiccups as we all learn to use Wave - there is a significant overhead to using Wave effectively.

One of my first thoughts re the potential clinical use of Wave was how it could have enhanced a Personal Health Record (PHR) that was developed for use by older children and teenagers with Insulin Dependent Diabetes at Royal Children’s Hospital, Melbourne – BetterDiabetes. There is a component within this PHR where the teens can request online assistance and advice from their Diabetes Nurse Educators (DNEs) for management of their diabetes. Armed with appropriate authorization and access permissions, the DNEs can view selected parts of the BetterDiabetes record, including glucose measurements uploaded only minutes beforehand, making informed and making real-time responses back to the teens regarding proposed changes to their care. In the online version of BetterDiabetes the secure messages flowing back and forth are similar to email, but embedded in the PHR – asynchronous, fragmented and clunky. If this was able to be transcended by a Wave-like tool for communication it could be a very useful vehicle for collaborative healthcare provision. The provision of timely information flow in both directions, and including addition of external files to the ‘Wave’ could be extremely valuable.

2. EHRs & EMRs

Wave is NOT appropriate for an EHR/EMR platform. Formal health records should be based on standards such as ISO 18308 – ‘Requirements for an Electronic Health Record Reference Architecture’ and ISO/DTR 20514 – ‘Electronic Health Record Definition, Scope and Context’. Now Wave may be very useful as an interface for communications within that EHR framework, form or structure, but it is definitely not the basis for "…a set of clinical and technical requirements for a record architecture that supports using, sharing, and exchanging electronic health records across different health sectors, different countries, and different models of healthcare delivery." Of some concern, there are some public Waves that are promoting Google Wave as the newest medium for EMRs. One public Wave as an example is: Electronic Medical Records (EMR) and Medical Information Systems: Is Wave the future of electronic medical records? which includes an EMR example.

By all means let's embed the innovative Wave interface for use within a formal EHR/EMR but we need to be careful if we are expecting more from it.

3. Clinical Decision Support

Phil Baumann’s ‘A Clinical Infusion of Google Wave’ blog, featuring Clinybot, is a fascinating, futuristic view of Clinical Decision Support provided for clinicians. Phil states that he assumes all privacy and security aspects are OK when proposing Clinybot - agreed. However, the missing ingredient in Phil’s proposal is not unique to Clinybot but the reason why we have so little Clinical Decision Support in practice. In order for Clinybot to function as described it would have to have a clear semantic handle on the data structure underlying it. Clinical Decision Support can be and is developed on a per EHR/EMR basis, however standardization of clinical content would enable universal applicability of Clinybot across all EHRs and EMRs. The combination of Clinybot and standardised content could be a very powerful potential partnership.

_____

I’m a pragmatist; definitely not a futurist. I’ve seen some predictions and anticipated uses for Wave that I think are very optimistic, maybe even a little far-fetched. Perhaps these things might happen... probably not.

And of course there are issues and drawbacks to Wave. Tech Crunch's Why Google Wave Sucks, And Why You Will Use It Anyway is a pretty good heads up to the reality of Wave at present.

For the moment I'm more than happy to explore how the benefits of the complex, small group conversations can be leveraged in healthcare, and particularly my clinical modeling work with openEHR. I will keep an open mind to see how Waving in health develops.

Riding the Google Wave

This morning I posted two tweets: "I'm having some great 'robust' discussions on #GoogleWave. I'm now able to finish @ianmcnicoll's sentences for him... in person & online;-)"

and

"I have a love/hate relationship with #GoogleWave. Getting sick of the "Everything's shiny, Cap'n." message, when clearly everything is NOT".

These two statements posted about an hour apart reflect some of my journey into the world of Google Wave.

My day-to-day work is all about collaboration - relying heavily on Skype and GoToMeeting as online tools to communicate with colleagues and clients distributed around Australia, and overseas; and working with groups of clinicians who are using an online application, the openEHR Clinical Knowledge Manager (CKM) for designing, reviewing and agreeing computable clinical content definitions, known as archetypes, for use in Electronic Health Records.

CKM is a relatively new and unique online application. Powered only by volunteers, it is harnessing the "collective intelligence" of clinicians and informaticians from all over the world to create open source archetypes, which underpin the European and international EHR standard, ISO13606.  Since its April launch, CKM is gaining momentum and has attracted 388 registered users from 49 countries, with 130 individuals actively involved in reviewing and agreeing the current 200+ archetypes - some modest success methinks.

The biggest challenge for me this year has been exploring how to productively engage with these busy clinicians and informaticians who are volunteering their time and expertise.  As a result, it was only early this year that I opened a Facebook account (after swearing I would never do it), and only this week I passed my 1000 tweet mark!  Learning to engage with these social networking tools and communities has certainly given me enormous insight re how we might be able to take CKM forward.

The core CKM team comprises Ian McNicoll (@ianmcnicoll) in Glasgow, Sebastian Garde (@gardes) in Dusseldorf and myself in Melbourne and we meet formally using Skype and GoToMeeting twice a week, which is not always the easiest way to collaborate.  One of the next challenges for CKM  is to nurture the design and initial creation of the archetypes collaboratively - effectively a sandpit or archetype 'nursery'.  Our main question is how to provide an online environment where interested international clinicians could share their time and resources effectively... and then we heard that Google Wave was coming!

Receiving that invitation was very exciting.  This was immediately followed by the let-down phase because, of course, you have to wave with someone!  And then the dilemma of "What to do with it?" I found a number of public waves where there were multitudes of people joining and then... well, nothing.  No-one seemed to have a clue what to do with it!  And the few Waves that were very active seemed to become quite chaotic very quickly, resulting in confusion rather than collaboration.

Once Ian, Sebastian and I all had our Wave accounts, we had an opportunity to play - sending asynchronous messages, using the Piratify and Flippy bots to do silly things to the blips and co-writing in real-time - hence my ability to finish off Ian's sentences for him;-).  More recently, we started to find some real uses for Wave which our usual email, Skype and GoToMeeting couldn't do.  We created a number of separate Waves, each related to a particular CKM requirement that we were trying to thrash out.  In fact, only this morning we managed to come to an agreement on a particularly curly one - an issue that we hadn't been able to resolve through a number of verbal discussions.  The ability to focus on one comment (blip) to get a common understanding has been very useful.

And then there was a recent twitter discussion that I had with @psweetman and @JFahrni about allergies - 3 strangers from UK, US & Australia using Twitter to try to come to a common understanding!  Jerry took the initial tweets (-what is the collective noun for a group of tweets?) and combined them in his blog.  While we could now see them all together, instead of fragmented 140 character snippets, it was still difficult to engage with each other.  So I took the blog and 'Waved' it - created a private Wave in which all 3 of us could participate.  The discussion that ensued was much more effective, building on previous comments and thrashing out specific points. It worked pretty well, including some bonus tips on where to visit next time I go to Las Vegas!

It is this collaborative aspect of Google Wave I'm beginning to love - it is really quite compelling.  Other tools, even used in combination don't cut it. Yet the down side is that Wave is still pretty clunky and I feel that I have seen more than my fair share of the "Everything's Shiny Cap'n" messages as the Wave crashes - hence the frustration evident in my second tweet.

The reality is that you just can't collaborate like this in other media.  Google Wave has enormous potential as it is refined and is extended. I look forward to exploring if and how we can incorporate Wave into our archetype development, especially now with the opportunity to federate Wave servers.  Perhaps it will work, perhaps not - but I have a glass half full kind of view at present.  Will keep you posted...