This HBR article is spot on in regards to the CCR vs CCD question. The vendors of complexity will do what they may and create more of the same for there existing market. But, its the cheap, simple and fast that is opening up the markets. Lo-fi hitech that is accessible.... is what goes mainstream.
Flip Video vs Sony, Canon
Edmund ________________________________ Edmund Billings MD CMO & EVP Product Medsphere 1971 Palomar Oaks Way, Suite 200 Carlsbad, California 92008 edmund.billi...@medsphere.com www.medsphere.com www.medsphere.org Skype: edmundbillings 415-505-8953 c 760-692-3713 o 760-683-3701 f
edmund.billi...@medsphere.com> wrote:
> This HBR article is spot on in regards to the CCR vs CCD question. The
> vendors of complexity will do what they may and create more of the same for
> there existing market. But, its the cheap, simple and fast that is opening
> up the markets. Lo-fi hitech that is accessible.... is what goes
> mainstream.
> Flip Video vs Sony, Canon
> Edmund
> ________________________________
> Edmund Billings MD
> CMO & EVP Product
> Medsphere
> 1971 Palomar Oaks Way, Suite 200
> Carlsbad, California 92008
> edmund.billi...@medsphere.com
> www.medsphere.com > www.medsphere.org > Skype: edmundbillings
> 415-505-8953 c
> 760-692-3713 o
> 760-683-3701 f
This article was published in the September 2009 edition of Wired, not HBR.
Edmund
__________________
Edmund Billings MD
415.505.8953
On Sep 21, 2009, at 3:26 PM, "fred trotter" <fred.trot...@gmail.com<mailto:fred.trot...@gmail.com>> wrote:
If you blog it, they will link (and me too!!)
-FT
On Mon, Sep 21, 2009 at 5:05 PM, Edmund Billings <<mailto:edmund.billi...@medsphere.com>edmund.billi...@medsphere.com<mailto:edmund.billi...@medsphere.com>> wrote:
This HBR article is spot on in regards to the CCR vs CCD question. The vendors of complexity will do what they may and create more of the same for there existing market. But, its the cheap, simple and fast that is opening up the markets. Lo-fi hitech that is accessible.... is what goes mainstream.
right on! When and where is this article from? DCK
David C. Kibbe, MD MBA
Senior Advisor, American Academy of Family Physicians
Chair, ASTM International E31Technical Committee on Healthcare
Informatics
Principal, The Kibbe Group LLC
___________
913-205-7968 mobile
___________
dki...@aafp.org
kibbeda...@mac.com
CONFIDENTIALITY: This e-mail message (including attachments, if any)
is confidential and is intended only for the addressee. Any
unauthorized use or disclosure is strictly prohibited. Disclosure of
this e-mail to anyone other than the intended addressee does not
constitute waiver of privilege. If you have received this
communication in error, please notify me immediately and delete this.
Thank you for your cooperation. This message has not been encrypted. Special arrangements can be made for encryption upon request.
On Sep 21, 2009, at 6:05 PM, Edmund Billings wrote:
> This HBR article is spot on in regards to the CCR vs CCD question. > The vendors of complexity will do what they may and create more of
> the same for there existing market. But, its the cheap, simple and
> fast that is opening up the markets. Lo-fi hitech that is
> accessible.... is what goes mainstream.
> Flip Video vs Sony, Canon
> Edmund
> ________________________________
> Edmund Billings MD
> CMO & EVP Product
> Medsphere
> 1971 Palomar Oaks Way, Suite 200
> Carlsbad, California 92008
> edmund.billi...@medsphere.com
> www.medsphere.com > www.medsphere.org > Skype: edmundbillings
> 415-505-8953 c
> 760-692-3713 o
> 760-683-3701 f
My direct take-away is the importance of simplicity in the user interaction. Flips are drop-dead simple to use -- it's a big red button. Likewise, all the gizmos and features on EMRs only serve to alienate the providers who are supposed to use them.
Simplicity = Adoptability.
- Ben
From: David Kibbe Sent: Monday, September 21, 2009 4:18 PM To: open-ehealth-collaborative@googlegroups.com Subject: Re: The Good Enough Revolution
right on! When and where is this article from? DCK
David C. Kibbe, MD MBA Senior Advisor, American Academy of Family Physicians Chair, ASTM International E31Technical Committee on Healthcare Informatics Principal, The Kibbe Group LLC ___________
On Sep 21, 2009, at 6:05 PM, Edmund Billings wrote:
This HBR article is spot on in regards to the CCR vs CCD question. The vendors of complexity will do what they may and create more of the same for there existing market. But, its the cheap, simple and fast that is opening up the markets. Lo-fi hitech that is accessible.... is what goes mainstream.
I really do think the CCR to CCD comparison is warranted here. What this implies is that it is not merely enough to say that "this simple solution is good" but that more importantly "the complex solution is worse for most users most of the time"
Again, I think a full exposition of this idea warrants a good blog post from somebody.
Fred and others: I think blogging on this idea is good, but it may
also be time for action. My take on this is that ONC and HHS will do
what works for the large enterprises that they feel they must get into
the game first: Kaiser, Mayo, etc. The standards that become part of
the regulations and rule-making around Meaningful Use and HHS
Certification will be complex, de jure, and favoring large enterprises
and institutions tied to HL7.
However, that will create an opportunity to fill the gaps, so to
speak, between what is certifiable and what actually works and is
adoptable. We will need a dot-org, or perhaps several, to do the
work of creating open specifications and standards, and to create and
maintain the required ecosystem of specifications and models for e- health to grow. We could start out with a considerable body of IP,
built upon the CCR standard and its related artifacts. We could also
deal directly with ASTM in order to move its licensing to open source,
something I think they would certainly entertain.
There is no reason that the talent and good will of this and other
groups, such as the Clinical Groupware Collaborative, can't be
assembled and put to good use to do this work.
Kind regards, dCK
David C. Kibbe, MD MBA
Senior Advisor, American Academy of Family Physicians
Chair, ASTM International E31Technical Committee on Healthcare
Informatics
Principal, The Kibbe Group LLC
___________
913-205-7968 mobile
___________
dki...@aafp.org
kibbeda...@mac.com
CONFIDENTIALITY: This e-mail message (including attachments, if any)
is confidential and is intended only for the addressee. Any
unauthorized use or disclosure is strictly prohibited. Disclosure of
this e-mail to anyone other than the intended addressee does not
constitute waiver of privilege. If you have received this
communication in error, please notify me immediately and delete this.
Thank you for your cooperation. This message has not been encrypted. Special arrangements can be made for encryption upon request.
> I really do think the CCR to CCD comparison is warranted here.
> What this implies is that it is not merely enough to say that "this
> simple solution is good" but that more importantly "the complex
> solution is worse for most users most of the time"
> Again, I think a full exposition of this idea warrants a good blog
> post from somebody.
Completely agree.... Its now time to promote the applications, demonstrations and tools and knowledge. Its access to the data and utility of it that is the message.
These are ideas whose time has come: open source, good enough. If the government mandates the CDA and the CCD it will force the use of CCR to be compliant. This is exacty what the Vista CCR CCD Gateway project had to do. Use the CCR and transform to CCD.
Perfection is the enemy of GE.
________________________________
Edmund Billings MD
CMO & EVP Product
Medsphere
1971 Palomar Oaks Way, Suite 200
Carlsbad, California 92008
edmund.billi...@medsphere.com
www.medsphere.com www.medsphere.org Skype: edmundbillings
415-505-8953 c
760-692-3713 o
760-683-3701 f
________________________________
From: David Kibbe <kibbeda...@mac.com>
Reply-To: <open-ehealth-collaborative@googlegroups.com>
Date: Tue, 22 Sep 2009 04:16:41 -0700
To: <open-ehealth-collaborative@googlegroups.com>
Conversation: The Good Enough Revolution
Subject: Re: The Good Enough Revolution
Fred and others: I think blogging on this idea is good, but it may also be time for action. My take on this is that ONC and HHS will do what works for the large enterprises that they feel they must get into the game first: Kaiser, Mayo, etc. The standards that become part of the regulations and rule-making around Meaningful Use and HHS Certification will be complex, de jure, and favoring large enterprises and institutions tied to HL7.
However, that will create an opportunity to fill the gaps, so to speak, between what is certifiable and what actually works and is adoptable. We will need a dot-org, or perhaps several, to do the work of creating open specifications and standards, and to create and maintain the required ecosystem of specifications and models for e-health to grow. We could start out with a considerable body of IP, built upon the CCR standard and its related artifacts. We could also deal directly with ASTM in order to move its licensing to open source, something I think they would certainly entertain.
There is no reason that the talent and good will of this and other groups, such as the Clinical Groupware Collaborative, can't be assembled and put to good use to do this work.
Kind regards, dCK
David C. Kibbe, MD MBA
Senior Advisor, American Academy of Family Physicians
Chair, ASTM International E31Technical Committee on Healthcare Informatics
Principal, The Kibbe Group LLC
___________
913-205-7968 mobile
___________
dki...@aafp.org
kibbeda...@mac.com
CONFIDENTIALITY: This e-mail message (including attachments, if any) is confidential and is intended only for the addressee. Any unauthorized use or disclosure is strictly prohibited. Disclosure of this e-mail to anyone other than the intended addressee does not constitute waiver of privilege. If you have received this communication in error, please notify me immediately and delete this. Thank you for your cooperation. This message has not been encrypted. Special arrangements can be made for encryption upon request.
On Sep 22, 2009, at 1:10 AM, fred trotter wrote:
I really do think the CCR to CCD comparison is warranted here.
What this implies is that it is not merely enough to say that "this simple solution is good" but that more importantly "the complex solution is worse for most users most of the time"
Again, I think a full exposition of this idea warrants a good blog post from somebody.
Perhaps the best example in Healthcare is the "remote data button" in CPRS
(in the VA). They have been exchanging critical patient data all over the
country in lightning fast real time for a decade or more. They build health
summary objects are sent via HL7 messages. The critical components are MPI,
Enforced Document Hierachy, and the objects. Since they are transmitted via
HL7, theorically the idea could work in a heterogenous environment. It is
much simpler to implement and has been enormously effective. In addition,
there can be a roadmap for gradual improvement after a quick rollout of
"good enough".
I think one weakness of the "good enough" idea in Healthcare is it implies
(to me) stagnation. In fact, once in place, it needs to be subjected to the
same iterative improvement process (CQI) as anything else.
Matthew King, MD
On Tue, Sep 22, 2009 at 8:55 AM, Edmund Billings <
edmund.billi...@medsphere.com> wrote:
> Completely agree.... Its now time to promote the applications,
> demonstrations and tools and knowledge. Its access to the data and utility
> of it that is the message.
> These are ideas whose time has come: open source, good enough. If the
> government mandates the CDA and the CCD it will force the use of CCR to be
> compliant. This is exacty what the Vista CCR CCD Gateway project had to do.
> Use the CCR and transform to CCD.
> Perfection is the enemy of GE.
> ________________________________
> Edmund Billings MD
> CMO & EVP Product
> Medsphere
> 1971 Palomar Oaks Way, Suite 200
> Carlsbad, California 92008
> edmund.billi...@medsphere.com
> www.medsphere.com > www.medsphere.org > Skype: edmundbillings
> 415-505-8953 c
> 760-692-3713 o
> 760-683-3701 f
> Fred and others: I think blogging on this idea is good, but it may also
> be time for action. My take on this is that ONC and HHS will do what works
> for the large enterprises that they feel they must get into the game first:
> Kaiser, Mayo, etc. The standards that become part of the regulations and
> rule-making around Meaningful Use and HHS Certification will be complex, de
> jure, and favoring large enterprises and institutions tied to HL7.
> However, that will create an opportunity to fill the gaps, so to speak,
> between what is certifiable and what actually works and is adoptable. We
> will need a dot-org, or perhaps several, to do the work of creating open
> specifications and standards, and to create and maintain the required
> ecosystem of specifications and models for e-health to grow. We could start
> out with a considerable body of IP, built upon the CCR standard and its
> related artifacts. We could also deal directly with ASTM in order to move
> its licensing to open source, something I think they would certainly
> entertain.
> There is no reason that the talent and good will of this and other groups,
> such as the Clinical Groupware Collaborative, can't be assembled and put to
> good use to do this work.
> Kind regards, dCK
> David C. Kibbe, MD MBA
> Senior Advisor, American Academy of Family Physicians
> Chair, ASTM International E31Technical Committee on Healthcare Informatics
> Principal, The Kibbe Group LLC
> ___________
> 913-205-7968 mobile
> ___________
> dki...@aafp.org
> kibbeda...@mac.com
> CONFIDENTIALITY: This e-mail message (including attachments, if any) is
> confidential and is intended only for the addressee. Any unauthorized use or
> disclosure is strictly prohibited. Disclosure of this e-mail to anyone other
> than the intended addressee does not constitute waiver of privilege. If you
> have received this communication in error, please notify me immediately and
> delete this. Thank you for your cooperation. This message has not been
> encrypted. Special arrangements can be made for encryption upon request.
> On Sep 22, 2009, at 1:10 AM, fred trotter wrote:
> I really do think the CCR to CCD comparison is warranted here.
> What this implies is that it is not merely enough to say that "this simple
> solution is good" but that more importantly "the complex solution is worse
> for most users most of the time"
> Again, I think a full exposition of this idea warrants a good blog post
> from somebody.
I've been reading these posts with great interest but have been in customer meetings that have prohibited a direct and thoughtful response. So please accept my apologies to the group for the lateness of this response...
I am on the same page with you (almost) WRT to the 'good enough' concept. Customers need to be offered solutions that are not bloated with an accompanying bloated price tag. However, I am opposed (philosophically) to the phrase "Open source, good enough". This leaves the reader with the perception that they may be compromising if they use open source - which is incorrect. An application that meets the base requirements may be 'good enough' - no more; no less -- and, in fact, is exactly what we argued when we presented to Mark Leavitt, et al, at the CCHIT meeting at HIMSS. As you may recall, I argued that the provider should decide what the definition of 'meaningful use' should. That determination by the individual provider should define the application functionality that defines 'meaningful use' to their practice. Since then, the government, with all their 'experts' (some of which subscribe to this list) have weighed in to tell providers what is best for them. One of the positive outcomes of this debate has been the compromise recommendation by CCHIT around the CCHIT-M certification description - which I think is a good compromise. However, putting the CCHIT compromise aside, to say that 'open source' is just 'good enough' confuses the issue.
You began your posts saying that the CCD requirement over CCR was too complex and based on David's post (below), it would appear that you have strong support for your position. However, before we throw the baby out with the bath water, I ask that no one (including Medsphere) hide behind what they have today as representing the 'good enough' concept that is meant to represent the minimal requirement. The mere fact that you have created the CCR-CCD Gateway acknowledges the fact that this is a necessary path forward.
ONC has taken a position on what is needed (and what will be funded) and CCD is the path forward. And it makes sense. Why?
1. CCD harmonizes the two earlier standards for Clinical Summary - CCR and CDA. It shares patient summary in an easy-to-read format with a CCD template (provides all necessary information about a patient medical summary, separated by Sections )
2. New CCHIT certification criteria require all ambulatory and inpatient EHR systems to be CCD compatible, making CCD the most preferred standard for clinical document exchange
3. CCD recognizes the standard by HITSP (C32 and C48 Clinical Summary Document)
4. All IHE based HIEs require CCD document for XDS.b transactions
5. All NHIN transactions for Document exchange are based on CCD
6. Those systems which are in compliance with CCD will be readily compatible with new standards and systems, thereby opening doors for standards based interoperability and a better quality of care
Now, so that no one, including MOSS (Misys Open Source Solutions), hides behind any hidden agenda, MOSS has built out our HIE open source solutions to accept CCDs - in compliance with the IHE direction set by the ONC. But we have done so (and made the requisite investments) because it's the right thing to do and will move us all forward.
Let's not take a step back on what is needed to move toward true interoperability. And most of all, let's not present open source as a 'compromise'. It sends the wrong message and will not help position any of our efforts in a favorable light. Open source is just as good and in the promotion of interoperability is the best answer.
From: open-ehealth-collaborative@googlegroups.com [mailto:open-ehealth-collaborative@googlegroups.com] On Behalf Of Edmund Billings Sent: Tuesday, September 22, 2009 11:55 AM To: open-ehealth-collaborative@googlegroups.com Subject: Re: The Good Enough Revolution
Completely agree.... Its now time to promote the applications, demonstrations and tools and knowledge. Its access to the data and utility of it that is the message.
These are ideas whose time has come: open source, good enough. If the government mandates the CDA and the CCD it will force the use of CCR to be compliant. This is exacty what the Vista CCR CCD Gateway project had to do. Use the CCR and transform to CCD.
Perfection is the enemy of GE. ________________________________ Edmund Billings MD CMO & EVP Product Medsphere 1971 Palomar Oaks Way, Suite 200 Carlsbad, California 92008 edmund.billi...@medsphere.com www.medsphere.com www.medsphere.org Skype: edmundbillings 415-505-8953 c 760-692-3713 o 760-683-3701 f
________________________________
From: David Kibbe <kibbeda...@mac.com> Reply-To: <open-ehealth-collaborative@googlegroups.com> Date: Tue, 22 Sep 2009 04:16:41 -0700 To: <open-ehealth-collaborative@googlegroups.com> Conversation: The Good Enough Revolution Subject: Re: The Good Enough Revolution
Fred and others: I think blogging on this idea is good, but it may also be time for action. My take on this is that ONC and HHS will do what works for the large enterprises that they feel they must get into the game first: Kaiser, Mayo, etc. The standards that become part of the regulations and rule-making around Meaningful Use and HHS Certification will be complex, de jure, and favoring large enterprises and institutions tied to HL7.
However, that will create an opportunity to fill the gaps, so to speak, between what is certifiable and what actually works and is adoptable. We will need a dot-org, or perhaps several, to do the work of creating open specifications and standards, and to create and maintain the required ecosystem of specifications and models for e-health to grow. We could start out with a considerable body of IP, built upon the CCR standard and its related artifacts. We could also deal directly with ASTM in order to move its licensing to open source, something I think they would certainly entertain.
There is no reason that the talent and good will of this and other groups, such as the Clinical Groupware Collaborative, can't be assembled and put to good use to do this work.
Kind regards, dCK
David C. Kibbe, MD MBA Senior Advisor, American Academy of Family Physicians Chair, ASTM International E31Technical Committee on Healthcare Informatics Principal, The Kibbe Group LLC ___________
913-205-7968 mobile ___________ dki...@aafp.org kibbeda...@mac.com
"Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: One Kingdom Street, London W2 6BL, United Kingdom. For a list of Misys group operating companies please go to http://www.misys.com/corp/About_Us/misys_operating_companies.html. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing.
On Tue, Sep 22, 2009 at 1:12 PM, Matthew King <flydo...@gmail.com> wrote:
[KSB] <...snip...>
> I think one weakness of the "good enough" idea in Healthcare is it implies > (to me) stagnation. In fact, once in place, it needs to be subjected to the > same iterative improvement process (CQI) as anything else.
[KSB] Why should it imply stagnation, Matt? To me, good enough means good enough to be put to use today, but not so good that it cannot be improved for tomorrow.
I don't know, Bhaskar, but that how it could be interpreted, if that comes
into my mind. That's why I agree with Tim's comment about "Open Source, good
enough."
m
On Tue, Sep 22, 2009 at 7:00 PM, K.S. Bhaskar <ksbhas...@gmail.com> wrote:
> On Tue, Sep 22, 2009 at 1:12 PM, Matthew King <flydo...@gmail.com> wrote:
> [KSB] <...snip...>
> > I think one weakness of the "good enough" idea in Healthcare is it
> implies
> > (to me) stagnation. In fact, once in place, it needs to be subjected to
> the
> > same iterative improvement process (CQI) as anything else.
> [KSB] Why should it imply stagnation, Matt? To me, good enough means
> good enough to be put to use today, but not so good that it cannot be
> improved for tomorrow.
I would love to see this environment take hold. I would like to form an environment where many apps (mobile/otherwise) that are relatively easy to use and singularly focused can be compiled into a larger atmosphere through integration into a consortium approach so that the data from the use of these apps actually has a story to tell and does not just live on the thick client of the phone. Creating this integration is something I have wanted to do for some time.
Interesting to think about how you can create the application so that it is convenient (easy, low cost, small features) which is one way to succeed
But to then house the data from the use of these convenient solutions and sell with a feature rich dashboard (high cost, adaptable, realtime, cost saving, administration, government, etc..) with appropriate monetization for a business to be created.
Cheers, Blaine Warkentine M.D. --
On 9/22/09 7:16 AM, "David Kibbe" <kibbeda...@mac.com> wrote:
> Fred and others: I think blogging on this idea is good, but it may also be > time for action. My take on this is that ONC and HHS will do what works for > the large enterprises that they feel they must get into the game first: > Kaiser, Mayo, etc. The standards that become part of the regulations and > rule-making around Meaningful Use and HHS Certification will be complex, de > jure, and favoring large enterprises and institutions tied to HL7.
> However, that will create an opportunity to fill the gaps, so to speak, > between what is certifiable and what actually works and is adoptable. We > will need a dot-org, or perhaps several, to do the work of creating open > specifications and standards, and to create and maintain the required > ecosystem of specifications and models for e-health to grow. We could start > out with a considerable body of IP, built upon the CCR standard and its > related artifacts. We could also deal directly with ASTM in order to move > its licensing to open source, something I think they would certainly > entertain.
> There is no reason that the talent and good will of this and other groups, > such as the Clinical Groupware Collaborative, can't be assembled and put to > good use to do this work.
> Kind regards, dCK
> David C. Kibbe, MD MBA > Senior Advisor, American Academy of Family Physicians > Chair, ASTM International E31Technical Committee on Healthcare Informatics > Principal, The Kibbe Group LLC > ___________
> 913-205-7968 mobile > ___________ > dki...@aafp.org > kibbeda...@mac.com
> CONFIDENTIALITY: This e-mail message (including attachments, if any) is > confidential and is intended only for the addressee. Any unauthorized use or > disclosure is strictly prohibited. Disclosure of this e-mail to anyone other > than the intended addressee does not constitute waiver of privilege. If you > have received this communication in error, please notify me immediately and > delete this. Thank you for your cooperation. This message has not been > encrypted. Special arrangements can be made for encryption upon request.
> On Sep 22, 2009, at 1:10 AM, fred trotter wrote:
>> I really do think the CCR to CCD comparison is warranted here. >> What this implies is that it is not merely enough to say that "this simple >> solution is good" but that more importantly "the complex solution is worse >> for most users most of the time"
>> Again, I think a full exposition of this idea warrants a good blog post from >> somebody.
Dear Blaine: One such consortium is the Clinical Groupware
Collaborative. It's attracting many people who, like yourself, are
non-ideological, want to get the work done, and value collaboration as
a means of advancing health IT innovation. Give me a holler if you'd
like more information.
Kind regards, DCK
David C. Kibbe, MD MBA
Senior Advisor, American Academy of Family Physicians
Chair, ASTM International E31Technical Committee on Healthcare
Informatics
Principal, The Kibbe Group LLC
___________
913-205-7968 mobile
___________
dki...@aafp.org
kibbeda...@mac.com
CONFIDENTIALITY: This e-mail message (including attachments, if any)
is confidential and is intended only for the addressee. Any
unauthorized use or disclosure is strictly prohibited. Disclosure of
this e-mail to anyone other than the intended addressee does not
constitute waiver of privilege. If you have received this
communication in error, please notify me immediately and delete this.
Thank you for your cooperation. This message has not been encrypted. Special arrangements can be made for encryption upon request.
On Sep 23, 2009, at 11:43 AM, Blaine Warkentine wrote:
> I would love to see this environment take hold. I would like to
> form an environment where many apps (mobile/otherwise) that are
> relatively easy to use and singularly focused can be compiled into a
> larger atmosphere through integration into a consortium approach so
> that the data from the use of these apps actually has a story to
> tell and does not just live on the thick client of the phone. > Creating this integration is something I have wanted to do for some
> time.
> Interesting to think about how you can create the application so
> that it is convenient (easy, low cost, small features) which is one
> way to succeed
> But to then house the data from the use of these convenient
> solutions and sell with a feature rich dashboard (high cost,
> adaptable, realtime, cost saving, administration, government, etc..)
> with appropriate monetization for a business to be created.
> On 9/22/09 7:16 AM, "David Kibbe" <kibbeda...@mac.com> wrote:
>> Fred and others: I think blogging on this idea is good, but it
>> may also be time for action. My take on this is that ONC and HHS
>> will do what works for the large enterprises that they feel they
>> must get into the game first: Kaiser, Mayo, etc. The standards
>> that become part of the regulations and rule-making around
>> Meaningful Use and HHS Certification will be complex, de jure, and
>> favoring large enterprises and institutions tied to HL7.
>> However, that will create an opportunity to fill the gaps, so to
>> speak, between what is certifiable and what actually works and is
>> adoptable. We will need a dot-org, or perhaps several, to do the
>> work of creating open specifications and standards, and to create
>> and maintain the required ecosystem of specifications and models
>> for e-health to grow. We could start out with a considerable body
>> of IP, built upon the CCR standard and its related artifacts. We
>> could also deal directly with ASTM in order to move its licensing
>> to open source, something I think they would certainly entertain.
>> There is no reason that the talent and good will of this and other
>> groups, such as the Clinical Groupware Collaborative, can't be
>> assembled and put to good use to do this work.
>> Kind regards, dCK
>> David C. Kibbe, MD MBA
>> Senior Advisor, American Academy of Family Physicians
>> Chair, ASTM International E31Technical Committee on Healthcare
>> Informatics
>> Principal, The Kibbe Group LLC
>> ___________
>> 913-205-7968 mobile
>> ___________
>> dki...@aafp.org
>> kibbeda...@mac.com
>> CONFIDENTIALITY: This e-mail message (including attachments, if
>> any) is confidential and is intended only for the addressee. Any
>> unauthorized use or disclosure is strictly prohibited. Disclosure
>> of this e-mail to anyone other than the intended addressee does not
>> constitute waiver of privilege. If you have received this
>> communication in error, please notify me immediately and delete
>> this. Thank you for your cooperation. This message has not been
>> encrypted. Special arrangements can be made for encryption upon
>> request.
>> On Sep 22, 2009, at 1:10 AM, fred trotter wrote:
>>> I really do think the CCR to CCD comparison is warranted here.
>>> What this implies is that it is not merely enough to say that
>>> "this simple solution is good" but that more importantly "the
>>> complex solution is worse for most users most of the time"
>>> Again, I think a full exposition of this idea warrants a good blog
>>> post from somebody.
> Dear Blaine: One such consortium is the Clinical Groupware Collaborative. > It's attracting many people who, like yourself, are non-ideological, want to > get the work done, and value collaboration as a means of advancing health IT > innovation. Give me a holler if you'd like more information.
> Kind regards, DCK
> David C. Kibbe, MD MBA > Senior Advisor, American Academy of Family Physicians > Chair, ASTM International E31Technical Committee on Healthcare Informatics > Principal, The Kibbe Group LLC > ___________
> 913-205-7968 mobile > ___________ > dki...@aafp.org > kibbeda...@mac.com
> CONFIDENTIALITY: This e-mail message (including attachments, if any) is > confidential and is intended only for the addressee. Any unauthorized use or > disclosure is strictly prohibited. Disclosure of this e-mail to anyone other > than the intended addressee does not constitute waiver of privilege. If you > have received this communication in error, please notify me immediately and > delete this. Thank you for your cooperation. This message has not been > encrypted. Special arrangements can be made for encryption upon request.
> On Sep 23, 2009, at 11:43 AM, Blaine Warkentine wrote:
>> I would love to see this environment take hold. I would like to form an >> environment where many apps (mobile/otherwise) that are relatively easy to >> use and singularly focused can be compiled into a larger atmosphere through >> integration into a consortium approach so that the data from the use of these >> apps actually has a story to tell and does not just live on the thick client >> of the phone. Creating this integration is something I have wanted to do for >> some time.
>> Interesting to think about how you can create the application so that it is >> convenient (easy, low cost, small features) which is one way to succeed
>> But to then house the data from the use of these convenient solutions and >> sell with a feature rich dashboard (high cost, adaptable, realtime, cost >> saving, administration, government, etc..) with appropriate monetization for >> a business to be created.
Apologies, but when people say the CCD (and CDA and RIM) are too
complex and the CCR is simpler they jump, like you have in your email
below, to the conclusion that the CCD (and CDA and RIM) are therefore
more technically sophisticated, more inclusive, and better.
The other conclusion people jump to, and which is widely promulgated
by HL7 and HITSP, is that as you state the "CCD harmonizes the two
earlier standards for Clinical Summary – CCR and CDA."
First, the CCR is 'simpler' because it is extremely strict in its
adherence to W3C XML standards and is computable and very efficient
using all XML parsers and tools, including XPATH, XSLTs, Schematron,
XPROC, and proprietary tools from all the XML tools vendors. The CDA
and CCD do not. The CCR also does not allow any data to be placed as
tag attributes - again, this is a technical nuance and is
intentional. Keeping all data as elements generates a tree structure
and a disciplined object-attribute hierarchy. Tag attributes parse
flat - you cannot have a data attribute of a tag attribute. You
cannot build a hierarchy off tag attributes. And, yes XML tools have
been modified to find and readily parse data as tag attributes but run
a test and parsers and XPATH are significantly faster, particularly
when you get to data the size of clinical summaries, when all data are
elements. Lastly, XML is best when it contains all of its
relationships and mappings internally. In other words, it is a very
clean object description language until it has to reference outside
data or relationships to make sense of itself. CCR is very strict
about this and is 100% built on as an object-oriented data
representation. CDA and CCD, however, are based on the RIM and its
archaic (in this day and age) ER (entity relational) data model. The
CDA and CCD are referential - bad idea. This is 2009!!!!!
As for the second conclusion above that the "CCD harmonizes the two
earlier standards for Clinical Summary – CCR and CDA," it is flat-our
wrong. The CCD maps a limited subset of the CCR to CDA V2 syntax. Look at how the CCD treats medications, SIG, dates, coding, etc. and
you will see the striking difference. The CCD cannot even represent
approximate dates! What in the world? Approximate dates, pertinent
negatives, cross-coding? Are these unique to health care? No. Are
they critical to health care? Absolutely! And we have a national
standard that cannot support them natively and that cannot represent a
structured SIG? The CCR can and was built from the ground up to do
so. Apologies again, but the CCR was built by technical people who
actually also happen to practice clinical medicine!
XML is about computability. It is about packaging data so that any
system can read the XML using common (and free) tools and can compute
against it. Those of us who work technically both in health care and
outside feel strongly that:
1) Health care data are no more complex than what we deal with in the
'real' world, and this includes security.
2) The 'real' world of the Internet is leaving health care behind.
The CCR is like RESTful interfaces and JSON. No one worth there salt
technically thinks that REST is inferior to SOAP or XML RPC. It's
simpler, yes, and easier to use, and guess what, it makes the systems
that use it have to be smarter. The same with JSON. I'm an XML
person - I'm biased and I think it is very powerful, but I also have
to run really high throughput systems and JSON is faster at a lot of
things. Bottom line, everything we build nowadays is REST/JSON with
XML, HTML, and PDF payloads. We no longer restrict the payload - why
should we.
REST makes it incredibly easy to interoperate, that's why everything
in the Internet space is going there. The idea that the message
coming back has to be in the same syntax or format as the request is
old school, or that every request or payload does. XDS.b from IHE? Reinventing the wheel - and making it out of stone rather than radial
plies. It's painful. What are we doing? Making our entire industry
a dinosaur just because a few of our most powerful vendors are?
Google 'RESTful Interface' = 1,190,000 hits. Google 'XDS.b' = 57,300
hits. And here's what you get from IHE's own wiki:
"In conclusion, if XDS.b and XCA are to achieve the interoperability
what we need, the community will have to adapt to the more modern
rules of Web Services. Many of us will not want to write code to
handle all this variability. Honestly, healthcare as a community
should not be specifying low level communications interfaces like Web
Services. They have been defined by the larger computer industry and
we should accept what they have standardized. For some implementers
this means using an existing, well tested Web Services tool kit.
Others will continue to build their own. Those that build their own
accept the responsibility of conforming to the standards and norms of
the Web Services industry. The tools developed within the IHE
community will never be able to fully test the full range of options
available to us from the Web Services industry. We do not have the
resources."
> I’ve been reading these posts with great interest but have been in
> customer meetings that have prohibited a direct and thoughtful
> response. So please accept my apologies to the group for the
> lateness of this response…
> I am on the same page with you (almost) WRT to the ‘good enough’
> concept. Customers need to be offered solutions that are not bloated
> with an accompanying bloated price tag. However, I am opposed
> (philosophically) to the phrase “Open source, good enough”. This
> leaves the reader with the perception that they may be compromising
> if they use open source – which is incorrect. An application that
> meets the base requirements may be ‘good enough’ – no more; no less
> -- and, in fact, is exactly what we argued when we presented to Mark
> Leavitt, et al, at the CCHIT meeting at HIMSS. As you may recall, I
> argued that the provider should decide what the definition of
> ‘meaningful use’ should. That determination by the individual
> provider should define the application functionality that defines
> ‘meaningful use’ to their practice. Since then, the government, with
> all their ‘experts’ (some of which subscribe to this list) have
> weighed in to tell providers what is best for them. One of the
> positive outcomes of this debate has been the compromise
> recommendation by CCHIT around the CCHIT-M certification description
> – which I think is a good compromise. However, putting the CCHIT
> compromise aside, to say that ‘open source’ is just ‘good enough’
> confuses the issue.
> You began your posts saying that the CCD requirement over CCR was
> too complex and based on David’s post (below), it would appear that
> you have strong support for your position. However, before we throw
> the baby out with the bath water, I ask that no one (including
> Medsphere) hide behind what they have today as representing the
> ‘good enough’ concept that is meant to represent the minimal
> requirement. The mere fact that you have created the CCR-CCD Gateway
> acknowledges the fact that this is a necessary path forward.
> ONC has taken a position on what is needed (and what will be funded)
> and CCD is the path forward. And it makes sense. Why?
> 1. CCD harmonizes the two earlier standards for Clinical
> Summary – CCR and CDA. It shares patient summary in an easy-to-read
> format with a CCD template (provides all necessary information about
> a patient medical summary, separated by Sections )
> 2. New CCHIT certification criteria require all ambulatory and
> inpatient EHR systems to be CCD compatible, making CCD the most
> preferred standard for clinical document exchange
> 3. CCD recognizes the standard by HITSP (C32 and C48 Clinical
> Summary Document)
> 4. All IHE based HIEs require CCD document for XDS.b
> transactions
> 5. All NHIN transactions for Document exchange are based on CCD
> 6. Those systems which are in compliance with CCD will be
> readily compatible with new standards and systems, thereby opening
> doors for standards based interoperability and a better quality of
> care
> Now, so that no one, including MOSS (Misys Open Source Solutions),
> hides behind any hidden agenda, MOSS has built out our HIE open
> source solutions to accept CCDs – in compliance with the IHE
> direction set by the ONC. But we have done so (and made the
> requisite investments) because it’s the right thing to do and will
> move us all forward.
> Let’s not take a step back on what is needed to move toward true
> interoperability. And most of all, let’s not present open source as
> a ‘compromise’. It sends the wrong message and will not help
> position any of our efforts in a favorable light. Open source is
> just as good and in the promotion of interoperability is the best
> answer.
> Thanks,
> Tim
> Tim Elwell
> Vice President
> Misys Open Source Solutions ("MOSS"), LLC
> 123 Main Street, 8th Floor
> White Plains, NY 10601 USA
> T +1 914 821 2566
> F +1 914 422 3659
> M +1 914 260 4402
> E tim.elw...@misys.com
> From: open-ehealth-collaborative@googlegroups.com [mailto:open-ehealth-collaborative@googlegroups.com > ] On Behalf Of Edmund Billings
> Sent: Tuesday, September 22, 2009 11:55 AM
> To:
Let's take this up a level. This is not about open source or the standards themselves specifically. Its about what technologies will 'drive' mainstream adoption. As the article cites examples over and over again, its the good enough and not the perfect that supports the broad adoption.
The adoption of HIT by the early adopter "have alots" started in the early 1990's and these solutions have not crossed the chasm to the mainstream.... To "The Haves and The Have Nots". 1.5% EMR adoption by US hospitals in 2009 is glaring evidence.
I can't tell you have many times when asking physicians what they thought of the EMR's in the market... They say, "they are just too much". "Too expensive, too complex, more than my practice needs". The reason chasms like this occur is because as Geoffrey Moore wrote in Crossing the Chasm.... The early adopters drive technology to the 100% case and the products do not translate to the mainstream. When innovative companies apply a pareto analysis and the 80/20 rule, technologies can be dramatically simplified and they are translated for mainstream adoption.
If you have been to an HL-7 or an HITSP meeting, clearly it is early adopter driven. If you look at the CDA, its comprehensive and looks to cover the 100%. If you look at how XML is applied, it requires an understanding of XML and health informatics and ....most critically the nonstandard applications of XML within the standard. Its a science project not an innovation.
So as Clayton Christianson describes in "The Innovators Dilemma"
"A DISRUPTIVE INNOVATION IS A TECHNOLOGY THAT BRINGS A MUCH MORE AFFORDABLE PRODUCT OR SERVICE THAT IS MUCH SIMPLER TO USE IN THE MARKET."
"AND SO, IT ALLOWS A WHOLE NEW POPULATION OF CONSUMERS TO AFFORD TO OWN AND HAVE THE SKILL TO USE...., WHEREAS HISTORICALLY, THE ABILITY WAS LIMITED TO PEOPLE WHO HAD A LOT OF MONEY OR A LOT OF SKILL".
So, if we focus on adoption and take CCR as an example of a good enough innovation. It is simpler to apply or use and thus is more affordable to develop and anyone that knows XML can use straight off.. Its accessible.
So the question for the ONC to answer regarding standards is not an issue of what the "large" organizations need over the "small" organizations. The question is as it was for the CCHIT Comprehensive Certification,
"Do you want to cement-in requirements that have not been adopted by the mainstream?"
"Do you want the early adopters from "have alot" organizations defining solutions or standards that must be a adopted by the mainstream?"
"Can we ignore a standard that technology companies have found much easier to innovate with?"
If good enough does not become sanctioned and perfect does..... Innovators will use good enough to get to the same results anyway. For the VistA Gateway, George Lilly used CCR and then transformed it to a CCD.
Well, good enough then.
Edmund
________________________________
Edmund Billings MD
CMO & EVP Product
Medsphere
1971 Palomar Oaks Way, Suite 200
Carlsbad, California 92008
edmund.billi...@medsphere.com
www.medsphere.com www.medsphere.org Skype: edmundbillings
415-505-8953 c
760-692-3713 o
760-683-3701 f
________________________________
From: Richard Peters <rpet...@scarecrowfilms.com>
Reply-To: <open-ehealth-collaborative@googlegroups.com>
Date: Wed, 23 Sep 2009 11:00:38 -0700
To: <open-ehealth-collaborative@googlegroups.com>
Conversation: The Good Enough Revolution
Subject: Re: The Good Enough Revolution
Tim,
Apologies, but when people say the CCD (and CDA and RIM) are too complex and the CCR is simpler they jump, like you have in your email below, to the conclusion that the CCD (and CDA and RIM) are therefore more technically sophisticated, more inclusive, and better.
The other conclusion people jump to, and which is widely promulgated by HL7 and HITSP, is that as you state the "CCD harmonizes the two earlier standards for Clinical Summary - CCR and CDA."
First, the CCR is 'simpler' because it is extremely strict in its adherence to W3C XML standards and is computable and very efficient using all XML parsers and tools, including XPATH, XSLTs, Schematron, XPROC, and proprietary tools from all the XML tools vendors. The CDA and CCD do not. The CCR also does not allow any data to be placed as tag attributes - again, this is a technical nuance and is intentional. Keeping all data as elements generates a tree structure and a disciplined object-attribute hierarchy. Tag attributes parse flat - you cannot have a data attribute of a tag attribute. You cannot build a hierarchy off tag attributes. And, yes XML tools have been modified to find and readily parse data as tag attributes but run a test and parsers and XPATH are significantly faster, particularly when you get to data the size of clinical summaries, when all data are elements. Lastly, XML is best when it contains all of its relationships and mappings internally. In other words, it is a very clean object description language until it has to reference outside data or relationships to make sense of itself. CCR is very strict about this and is 100% built on as an object-oriented data representation. CDA and CCD, however, are based on the RIM and its archaic (in this day and age) ER (entity relational) data model. The CDA and CCD are referential - bad idea. This is 2009!!!!!
As for the second conclusion above that the "CCD harmonizes the two earlier standards for Clinical Summary - CCR and CDA," it is flat-our wrong. The CCD maps a limited subset of the CCR to CDA V2 syntax. Look at how the CCD treats medications, SIG, dates, coding, etc. and you will see the striking difference. The CCD cannot even represent approximate dates! What in the world? Approximate dates, pertinent negatives, cross-coding? Are these unique to health care? No. Are they critical to health care? Absolutely! And we have a national standard that cannot support them natively and that cannot represent a structured SIG? The CCR can and was built from the ground up to do so. Apologies again, but the CCR was built by technical people who actually also happen to practice clinical medicine!
XML is about computability. It is about packaging data so that any system can read the XML using common (and free) tools and can compute against it. Those of us who work technically both in health care and outside feel strongly that:
1) Health care data are no more complex than what we deal with in the 'real' world, and this includes security.
2) The 'real' world of the Internet is leaving health care behind.
The CCR is like RESTful interfaces and JSON. No one worth there salt technically thinks that REST is inferior to SOAP or XML RPC. It's simpler, yes, and easier to use, and guess what, it makes the systems that use it have to be smarter. The same with JSON. I'm an XML person - I'm biased and I think it is very powerful, but I also have to run really high throughput systems and JSON is faster at a lot of things. Bottom line, everything we build nowadays is REST/JSON with XML, HTML, and PDF payloads. We no longer restrict the payload - why should we.
REST makes it incredibly easy to interoperate, that's why everything in the Internet space is going there. The idea that the message coming back has to be in the same syntax or format as the request is old school, or that every request or payload does. XDS.b from IHE? Reinventing the wheel - and making it out of stone rather than radial plies. It's painful. What are we doing? Making our entire industry a dinosaur just because a few of our most powerful vendors are?
Google 'RESTful Interface' = 1,190,000 hits. Google 'XDS.b' = 57,300 hits. And here's what you get from IHE's own wiki:
"In conclusion, if XDS.b and XCA are to achieve the interoperability what we need, the community will have to adapt to the more modern rules of Web Services. Many of us will not want to write code to handle all this variability. Honestly, healthcare as a community should not be specifying low level communications interfaces like Web Services. They have been defined by the larger computer industry and we should accept what they have standardized. For some implementers this means using an existing, well tested Web Services tool kit. Others will continue to build their own. Those that build their own accept the responsibility of conforming to the standards and norms of the Web Services industry. The tools developed within the IHE community will never be able to fully test the full range of options available to us from the Web Services industry. We do not have the resources."
Sincerely,
Rick
On Sep 22, 2009, at 6:51 PM, Elwell, Tim wrote:
Edmund, et al....
I've been reading these posts with great interest but have been in customer meetings that have prohibited a direct and thoughtful response. So please accept my apologies to the group for the lateness of this response...
I am on the same page with you (almost) WRT to the 'good enough' concept. Customers need to be offered solutions that are not bloated with an accompanying bloated price tag. However, I am opposed (philosophically) to the phrase "Open source, good enough". This leaves the reader with the perception that they may be compromising if they use open source - which is incorrect. An application that meets the base requirements may be 'good enough' - no more; no less -- and, in fact, is exactly what we argued when we presented to Mark Leavitt, et al, at the CCHIT meeting at HIMSS. As you may recall, I argued that the provider should decide what the definition of 'meaningful use' should. That determination by the individual provider should define the application functionality that defines 'meaningful use' to their practice. Since then, the government, with all their 'experts' (some of which subscribe to this list) have weighed in to tell providers what is best for them. One
...
> Let’s take this up a level. This is not about open source or the
> standards themselves specifically. Its about what technologies will
> ‘drive’ mainstream adoption. As the article cites examples over and
> over again, its the good enough and not the perfect that supports
> the broad adoption.
> The adoption of HIT by the early adopter “have alots” started in the
> early 1990’s and these solutions have not crossed the chasm to the
> mainstream.... To “The Haves and The Have Nots”. 1.5% EMR adoption
> by US hospitals in 2009 is glaring evidence.
> I can’t tell you have many times when asking physicians what they
> thought of the EMR’s in the market... They say, “they are just too
> much”. “Too expensive, too complex, more than my practice needs”. > The reason chasms like this occur is because as Geoffrey Moore wrote
> in Crossing the Chasm.... The early adopters drive technology to
> the 100% case and the products do not translate to the mainstream. > When innovative companies apply a pareto analysis and the 80/20
> rule, technologies can be dramatically simplified and they are
> translated for mainstream adoption.
> If you have been to an HL-7 or an HITSP meeting, clearly it is early
> adopter driven. If you look at the CDA, its comprehensive and looks
> to cover the 100%. If you look at how XML is applied, it requires
> an understanding of XML and health informatics and ....most
> critically the nonstandard applications of XML within the standard. > Its a science project not an innovation.
> So as Clayton Christianson describes in “The Innovators Dilemma”
> “A DISRUPTIVE INNOVATION IS A TECHNOLOGY THAT BRINGS A MUCH MORE
> AFFORDABLE PRODUCT OR SERVICE THAT IS MUCH SIMPLER TO USE IN THE
> MARKET.”
> “AND SO, IT ALLOWS A WHOLE NEW POPULATION OF CONSUMERS TO AFFORD TO
> OWN AND HAVE THE SKILL TO USE...., WHEREAS HISTORICALLY, THE
> ABILITY WAS LIMITED TO PEOPLE WHO HAD A LOT OF MONEY OR A LOT OF
> SKILL”.
> So, if we focus on adoption and take CCR as an example of a good
> enough innovation. It is simpler to apply or use and thus is more
> affordable to develop and anyone that knows XML can use straight
> off.. Its accessible.
> So the question for the ONC to answer regarding standards is not an
> issue of what the “large” organizations need over the “small”
> organizations. The question is as it was for the CCHIT
> Comprehensive Certification,
> “Do you want to cement-in requirements that have not been adopted by
> the mainstream?”
> “Do you want the early adopters from “have alot” organizations
> defining solutions or standards that must be a adopted by the
> mainstream?”
> “Can we ignore a standard that technology companies have found much
> easier to innovate with?”
> If good enough does not become sanctioned and perfect does..... > Innovators will use good enough to get to the same results anyway. > For the VistA Gateway, George Lilly used CCR and then transformed
> it to a CCD.
> Well, good enough then.
> Edmund
> ________________________________
> Edmund Billings MD
> CMO & EVP Product
> Medsphere
> 1971 Palomar Oaks Way, Suite 200
> Carlsbad, California 92008
> edmund.billi...@medsphere.com
> www.medsphere.com > www.medsphere.org > Skype: edmundbillings
> 415-505-8953 c
> 760-692-3713 o
> 760-683-3701 f
> From: Richard Peters <rpet...@scarecrowfilms.com>
> Reply-To: <open-ehealth-collaborative@googlegroups.com>
> Date: Wed, 23 Sep 2009 11:00:38 -0700
> To: <open-ehealth-collaborative@googlegroups.com>
> Conversation: The Good Enough Revolution
> Subject: Re: The Good Enough Revolution
> Tim,
> Apologies, but when people say the CCD (and CDA and RIM) are too
> complex and the CCR is simpler they jump, like you have in your
> email below, to the conclusion that the CCD (and CDA and RIM) are
> therefore more technically sophisticated, more inclusive, and better.
> The other conclusion people jump to, and which is widely promulgated
> by HL7 and HITSP, is that as you state the "CCD harmonizes the two
> earlier standards for Clinical Summary – CCR and CDA."
> First, the CCR is 'simpler' because it is extremely strict in its
> adherence to W3C XML standards and is computable and very efficient
> using all XML parsers and tools, including XPATH, XSLTs, Schematron,
> XPROC, and proprietary tools from all the XML tools vendors. The
> CDA and CCD do not. The CCR also does not allow any data to be
> placed as tag attributes - again, this is a technical nuance and is
> intentional. Keeping all data as elements generates a tree
> structure and a disciplined object-attribute hierarchy. Tag
> attributes parse flat - you cannot have a data attribute of a tag
> attribute. You cannot build a hierarchy off tag attributes. And,
> yes XML tools have been modified to find and readily parse data as
> tag attributes but run a test and parsers and XPATH are
> significantly faster, particularly when you get to data the size of
> clinical summaries, when all data are elements. Lastly, XML is best
> when it contains all of its relationships and mappings internally. > In other words, it is a very clean object description language until
> it has to reference outside data or relationships to make sense of
> itself. CCR is very strict about this and is 100% built on as an
> object-oriented data representation. CDA and CCD, however, are
> based on the RIM and its archaic (in this day and age) ER (entity
> relational) data model. The CDA and CCD are referential - bad idea.
> This is 2009!!!!!
> As for the second conclusion above that the "CCD harmonizes the two
> earlier standards for Clinical Summary – CCR and CDA," it is flat- > our wrong. The CCD maps a limited subset of the CCR to CDA V2
> syntax. Look at how the CCD treats medications, SIG, dates, coding,
> etc. and you will see the striking difference. The CCD cannot even
> represent approximate dates! What in the world? Approximate dates,
> pertinent negatives, cross-coding? Are these unique to health
> care? No. Are they critical to health care? Absolutely! And we
> have a national standard that cannot support them natively and that
> cannot represent a structured SIG? The CCR can and was built from
> the ground up to do so. Apologies again, but the CCR was built by
> technical people who actually also happen to practice clinical
> medicine!
> XML is about computability. It is about packaging data so that any
> system can read the XML using common (and free) tools and can
> compute against it. Those of us who work technically both in health
> care and outside feel strongly that:
> 1) Health care data are no more complex than what we deal with in
> the 'real' world, and this includes security.
> 2) The 'real' world of the Internet is leaving health care behind.
> The CCR is like RESTful interfaces and JSON. No one worth there
> salt technically thinks that REST is inferior to SOAP or XML RPC. > It's simpler, yes, and easier to use, and guess what, it makes the
> systems that use it have to be smarter. The same with JSON. I'm an
> XML person - I'm biased and I think it is very powerful, but I also
> have to run really high throughput systems and JSON is faster at a
> lot of things. Bottom line, everything we build nowadays is REST/ > JSON with XML, HTML, and PDF payloads. We no longer restrict the
> payload - why should we.
> REST makes it incredibly easy to interoperate, that's why everything
> in the Internet space is going there. The idea that the message
> coming back has to be in the same syntax or format as the request is
> old school, or that every request or payload does. XDS.b from
> IHE? Reinventing the wheel - and making it out of stone rather than
> radial plies. It's painful. What are we doing? Making our entire
> industry a dinosaur just because a few of our most powerful vendors
> are?
> Google 'RESTful Interface' = 1,190,000 hits. Google 'XDS.b' =
> 57,300 hits. And here's what you get from IHE's own wiki:
> "In conclusion, if XDS.b and XCA are to achieve the interoperability
> what we need, the community will have to adapt to the more modern
> rules of Web Services. Many of us will not want to write code to
> handle all this variability. Honestly, healthcare as a community
> should not be specifying low level communications interfaces like
> Web Services. They have been defined by the larger computer industry
> and we should accept what they have standardized. For some
> implementers this means using an existing, well tested Web Services
> tool kit. Others will continue to build their own. Those that build
> their own accept the responsibility of conforming to the standards
> and norms of the Web Services industry. The tools developed within
> the IHE community will never be able to fully test the full range of
> options available to us from the Web Services industry. We do not
> have the resources."
> Sincerely,
> Rick
> On Sep 22, 2009, at 6:51 PM, Elwell, Tim wrote:
> Edmund, et al….
> I’ve been reading these posts with great interest but have been in
> customer meetings that have prohibited a direct and thoughtful
> response. So please accept my apologies to the group for the
> lateness of this response…
> I am on the same page with you (almost) WRT to the ‘good enough’
> concept. Customers need to be offered solutions that are not bloated
> with an
Right on target. There is no need to exclude the good enough, even
while preferring the complex of the havealots. ONC should "choose"
both the CCR and the CCD, both REST and SOAP.
It's important to both have a sense of history, and to have learned
something from it.
DCK
David C. Kibbe, MD MBA
Senior Advisor, American Academy of Family Physicians
Chair, ASTM International E31Technical Committee on Healthcare
Informatics
Principal, The Kibbe Group LLC
___________
913-205-7968 mobile
___________
dki...@aafp.org
kibbeda...@mac.com
CONFIDENTIALITY: This e-mail message (including attachments, if any)
is confidential and is intended only for the addressee. Any
unauthorized use or disclosure is strictly prohibited. Disclosure of
this e-mail to anyone other than the intended addressee does not
constitute waiver of privilege. If you have received this
communication in error, please notify me immediately and delete this.
Thank you for your cooperation. This message has not been encrypted. Special arrangements can be made for encryption upon request.
On Sep 23, 2009, at 5:02 PM, Edmund Billings wrote:
> Let’s take this up a level. This is not about open source or the
> standards themselves specifically. Its about what technologies will
> ‘drive’ mainstream adoption. As the article cites examples over and
> over again, its the good enough and not the perfect that supports
> the broad adoption.
> The adoption of HIT by the early adopter “have alots” started in the
> early 1990’s and these solutions have not crossed the chasm to the
> mainstream.... To “The Haves and The Have Nots”. 1.5% EMR adoption
> by US hospitals in 2009 is glaring evidence.
> I can’t tell you have many times when asking physicians what they
> thought of the EMR’s in the market... They say, “they are just too
> much”. “Too expensive, too complex, more than my practice needs”. > The reason chasms like this occur is because as Geoffrey Moore wrote
> in Crossing the Chasm.... The early adopters drive technology to
> the 100% case and the products do not translate to the mainstream. > When innovative companies apply a pareto analysis and the 80/20
> rule, technologies can be dramatically simplified and they are
> translated for mainstream adoption.
> If you have been to an HL-7 or an HITSP meeting, clearly it is early
> adopter driven. If you look at the CDA, its comprehensive and looks
> to cover the 100%. If you look at how XML is applied, it requires
> an understanding of XML and health informatics and ....most
> critically the nonstandard applications of XML within the standard. > Its a science project not an innovation.
> So as Clayton Christianson describes in “The Innovators Dilemma”
> “A DISRUPTIVE INNOVATION IS A TECHNOLOGY THAT BRINGS A MUCH MORE
> AFFORDABLE PRODUCT OR SERVICE THAT IS MUCH SIMPLER TO USE IN THE
> MARKET.”
> “AND SO, IT ALLOWS A WHOLE NEW POPULATION OF CONSUMERS TO AFFORD TO
> OWN AND HAVE THE SKILL TO USE...., WHEREAS HISTORICALLY, THE
> ABILITY WAS LIMITED TO PEOPLE WHO HAD A LOT OF MONEY OR A LOT OF
> SKILL”.
> So, if we focus on adoption and take CCR as an example of a good
> enough innovation. It is simpler to apply or use and thus is more
> affordable to develop and anyone that knows XML can use straight
> off.. Its accessible.
> So the question for the ONC to answer regarding standards is not an
> issue of what the “large” organizations need over the “small”
> organizations. The question is as it was for the CCHIT
> Comprehensive Certification,
> “Do you want to cement-in requirements that have not been adopted by
> the mainstream?”
> “Do you want the early adopters from “have alot” organizations
> defining solutions or standards that must be a adopted by the
> mainstream?”
> “Can we ignore a standard that technology companies have found much
> easier to innovate with?”
> If good enough does not become sanctioned and perfect does..... > Innovators will use good enough to get to the same results anyway. > For the VistA Gateway, George Lilly used CCR and then transformed
> it to a CCD.
> Well, good enough then.
> Edmund
> ________________________________
> Edmund Billings MD
> CMO & EVP Product
> Medsphere
> 1971 Palomar Oaks Way, Suite 200
> Carlsbad, California 92008
> edmund.billi...@medsphere.com
> www.medsphere.com > www.medsphere.org > Skype: edmundbillings
> 415-505-8953 c
> 760-692-3713 o
> 760-683-3701 f
> From: Richard Peters <rpet...@scarecrowfilms.com>
> Reply-To: <open-ehealth-collaborative@googlegroups.com>
> Date: Wed, 23 Sep 2009 11:00:38 -0700
> To: <open-ehealth-collaborative@googlegroups.com>
> Conversation: The Good Enough Revolution
> Subject: Re: The Good Enough Revolution
> Tim,
> Apologies, but when people say the CCD (and CDA and RIM) are too
> complex and the CCR is simpler they jump, like you have in your
> email below, to the conclusion that the CCD (and CDA and RIM) are
> therefore more technically sophisticated, more inclusive, and better.
> The other conclusion people jump to, and which is widely promulgated
> by HL7 and HITSP, is that as you state the "CCD harmonizes the two
> earlier standards for Clinical Summary – CCR and CDA."
> First, the CCR is 'simpler' because it is extremely strict in its
> adherence to W3C XML standards and is computable and very efficient
> using all XML parsers and tools, including XPATH, XSLTs, Schematron,
> XPROC, and proprietary tools from all the XML tools vendors. The
> CDA and CCD do not. The CCR also does not allow any data to be
> placed as tag attributes - again, this is a technical nuance and is
> intentional. Keeping all data as elements generates a tree
> structure and a disciplined object-attribute hierarchy. Tag
> attributes parse flat - you cannot have a data attribute of a tag
> attribute. You cannot build a hierarchy off tag attributes. And,
> yes XML tools have been modified to find and readily parse data as
> tag attributes but run a test and parsers and XPATH are
> significantly faster, particularly when you get to data the size of
> clinical summaries, when all data are elements. Lastly, XML is best
> when it contains all of its relationships and mappings internally. > In other words, it is a very clean object description language until
> it has to reference outside data or relationships to make sense of
> itself. CCR is very strict about this and is 100% built on as an
> object-oriented data representation. CDA and CCD, however, are
> based on the RIM and its archaic (in this day and age) ER (entity
> relational) data model. The CDA and CCD are referential - bad idea.
> This is 2009!!!!!
> As for the second conclusion above that the "CCD harmonizes the two
> earlier standards for Clinical Summary – CCR and CDA," it is flat- > our wrong. The CCD maps a limited subset of the CCR to CDA V2
> syntax. Look at how the CCD treats medications, SIG, dates, coding,
> etc. and you will see the striking difference. The CCD cannot even
> represent approximate dates! What in the world? Approximate dates,
> pertinent negatives, cross-coding? Are these unique to health
> care? No. Are they critical to health care? Absolutely! And we
> have a national standard that cannot support them natively and that
> cannot represent a structured SIG? The CCR can and was built from
> the ground up to do so. Apologies again, but the CCR was built by
> technical people who actually also happen to practice clinical
> medicine!
> XML is about computability. It is about packaging data so that any
> system can read the XML using common (and free) tools and can
> compute against it. Those of us who work technically both in health
> care and outside feel strongly that:
> 1) Health care data are no more complex than what we deal with in
> the 'real' world, and this includes security.
> 2) The 'real' world of the Internet is leaving health care behind.
> The CCR is like RESTful interfaces and JSON. No one worth there
> salt technically thinks that REST is inferior to SOAP or XML RPC. > It's simpler, yes, and easier to use, and guess what, it makes the
> systems that use it have to be smarter. The same with JSON. I'm an
> XML person - I'm biased and I think it is very powerful, but I also
> have to run really high throughput systems and JSON is faster at a
> lot of things. Bottom line, everything we build nowadays is REST/ > JSON with XML, HTML, and PDF payloads. We no longer restrict the
> payload - why should we.
> REST makes it incredibly easy to interoperate, that's why everything
> in the Internet space is going there. The idea that the message
> coming back has to be in the same syntax or format as the request is
> old school, or that every request or payload does. XDS.b from
> IHE? Reinventing the wheel - and making it out of stone rather than
> radial plies. It's painful. What are we doing? Making our entire
> industry a dinosaur just because a few of our most powerful vendors
> are?
> Google 'RESTful Interface' = 1,190,000 hits. Google 'XDS.b' =
> 57,300 hits. And here's what you get from IHE's own wiki:
> "In conclusion, if XDS.b and XCA are to achieve the interoperability
> what we need, the community will have to adapt to the more modern
> rules of Web Services. Many of us will not want to write code to
> handle all this variability. Honestly, healthcare as a community
> should not be specifying low level communications interfaces like
> Web Services.
I appreciate the comments Edmund as I have the same Christiansen sound
bites in my pitches too. But let's not kid ourselves. The 1.5% hospital
EMR adoption rates or the 17% (using the optimistic number) EHR adoption
rates in provider practices have nothing to do with the CCD/CCR
argument. It's much more about perceived value and return on investment
- however the customer defines it. The expectation is that ARRA
incentives will help to solve the ROI imbalance. I hope the Feds are
right.
The CCD train has left the station and with the increased EHR adoption
that will be promoted using the ARRA incentives, CCD usage will increase
as well. I'll let the techies argue what's technically best but the
directional decision has been made.
Lastly, this is about open source and standards. When it comes to
interoperability, we need to be beating the drum that this is one place
that there are no compromises. Black box solutions around
interoperability are not sustainable.
"First they ignore you, then they laugh at you, then they fight you,
then you win." Mahatma Gandhi
________________________________
From: open-ehealth-collaborative@googlegroups.com
[mailto:open-ehealth-collaborative@googlegroups.com] On Behalf Of Edmund
Billings
Sent: Wednesday, September 23, 2009 5:02 PM
To: open-ehealth-collaborative@googlegroups.com
Subject: Re: The Good Enough Revolution
Let's take this up a level. This is not about open source or the
standards themselves specifically. Its about what technologies will
'drive' mainstream adoption. As the article cites examples over and
over again, its the good enough and not the perfect that supports the
broad adoption.
The adoption of HIT by the early adopter "have alots" started in the
early 1990's and these solutions have not crossed the chasm to the
mainstream.... To "The Haves and The Have Nots". 1.5% EMR adoption by
US hospitals in 2009 is glaring evidence.
I can't tell you have many times when asking physicians what they
thought of the EMR's in the market... They say, "they are just too
much". "Too expensive, too complex, more than my practice needs". The
reason chasms like this occur is because as Geoffrey Moore wrote in
Crossing the Chasm.... The early adopters drive technology to the 100%
case and the products do not translate to the mainstream. When
innovative companies apply a pareto analysis and the 80/20 rule,
technologies can be dramatically simplified and they are translated for
mainstream adoption.
If you have been to an HL-7 or an HITSP meeting, clearly it is early
adopter driven. If you look at the CDA, its comprehensive and looks to
cover the 100%. If you look at how XML is applied, it requires an
understanding of XML and health informatics and ....most critically the
nonstandard applications of XML within the standard. Its a science
project not an innovation.
So as Clayton Christianson describes in "The Innovators Dilemma"
"A DISRUPTIVE INNOVATION IS A TECHNOLOGY THAT BRINGS A MUCH MORE
AFFORDABLE PRODUCT OR SERVICE THAT IS MUCH SIMPLER TO USE IN THE
MARKET."
"AND SO, IT ALLOWS A WHOLE NEW POPULATION OF CONSUMERS TO AFFORD TO OWN
AND HAVE THE SKILL TO USE...., WHEREAS HISTORICALLY, THE ABILITY WAS
LIMITED TO PEOPLE WHO HAD A LOT OF MONEY OR A LOT OF SKILL".
So, if we focus on adoption and take CCR as an example of a good enough
innovation. It is simpler to apply or use and thus is more affordable to
develop and anyone that knows XML can use straight off.. Its accessible.
So the question for the ONC to answer regarding standards is not an
issue of what the "large" organizations need over the "small"
organizations. The question is as it was for the CCHIT Comprehensive
Certification,
"Do you want to cement-in requirements that have not been adopted by the
mainstream?"
"Do you want the early adopters from "have alot" organizations defining
solutions or standards that must be a adopted by the mainstream?"
"Can we ignore a standard that technology companies have found much
easier to innovate with?"
If good enough does not become sanctioned and perfect does.....
Innovators will use good enough to get to the same results anyway. For
the VistA Gateway, George Lilly used CCR and then transformed it to a
CCD.
Well, good enough then.
Edmund
________________________________
Edmund Billings MD
CMO & EVP Product
Medsphere
1971 Palomar Oaks Way, Suite 200
Carlsbad, California 92008
edmund.billi...@medsphere.com
www.medsphere.com www.medsphere.org Skype: edmundbillings
415-505-8953 c
760-692-3713 o
760-683-3701 f
________________________________
From: Richard Peters <rpet...@scarecrowfilms.com>
Reply-To: <open-ehealth-collaborative@googlegroups.com>
Date: Wed, 23 Sep 2009 11:00:38 -0700
To: <open-ehealth-collaborative@googlegroups.com>
Conversation: The Good Enough Revolution
Subject: Re: The Good Enough Revolution
Tim,
Apologies, but when people say the CCD (and CDA and RIM) are too complex
and the CCR is simpler they jump, like you have in your email below, to
the conclusion that the CCD (and CDA and RIM) are therefore more
technically sophisticated, more inclusive, and better.
The other conclusion people jump to, and which is widely promulgated by
HL7 and HITSP, is that as you state the "CCD harmonizes the two earlier
standards for Clinical Summary - CCR and CDA."
First, the CCR is 'simpler' because it is extremely strict in its
adherence to W3C XML standards and is computable and very efficient
using all XML parsers and tools, including XPATH, XSLTs, Schematron,
XPROC, and proprietary tools from all the XML tools vendors. The CDA
and CCD do not. The CCR also does not allow any data to be placed as tag
attributes - again, this is a technical nuance and is intentional.
Keeping all data as elements generates a tree structure and a
disciplined object-attribute hierarchy. Tag attributes parse flat - you
cannot have a data attribute of a tag attribute. You cannot build a
hierarchy off tag attributes. And, yes XML tools have been modified to
find and readily parse data as tag attributes but run a test and parsers
and XPATH are significantly faster, particularly when you get to data
the size of clinical summaries, when all data are elements. Lastly, XML
is best when it contains all of its relationships and mappings
internally. In other words, it is a very clean object description
language until it has to reference outside data or relationships to make
sense of itself. CCR is very strict about this and is 100% built on as
an object-oriented data representation. CDA and CCD, however, are based
on the RIM and its archaic (in this day and age) ER (entity relational)
data model. The CDA and CCD are referential - bad idea. This is
2009!!!!!
As for the second conclusion above that the "CCD harmonizes the two
earlier standards for Clinical Summary - CCR and CDA," it is flat-our
wrong. The CCD maps a limited subset of the CCR to CDA V2 syntax. Look
at how the CCD treats medications, SIG, dates, coding, etc. and you will
see the striking difference. The CCD cannot even represent approximate
dates! What in the world? Approximate dates, pertinent negatives,
cross-coding? Are these unique to health care? No. Are they critical
to health care? Absolutely! And we have a national standard that cannot
support them natively and that cannot represent a structured SIG? The
CCR can and was built from the ground up to do so. Apologies again, but
the CCR was built by technical people who actually also happen to
practice clinical medicine!
XML is about computability. It is about packaging data so that any
system can read the XML using common (and free) tools and can compute
against it. Those of us who work technically both in health care and
outside feel strongly that:
1) Health care data are no more complex than what we deal with in the
'real' world, and this includes security.
2) The 'real' world of the Internet is leaving health care behind.
The CCR is like RESTful interfaces and JSON. No one worth there salt
technically thinks that REST is inferior to SOAP or XML RPC. It's
simpler, yes, and easier to use, and guess what, it makes the systems
that use it have to be smarter. The same with JSON. I'm an XML person
- I'm biased and I think it is very powerful, but I also have to run
really high throughput systems and JSON is faster at a lot of things.
Bottom line, everything we build nowadays is REST/JSON with XML, HTML,
and PDF payloads. We no longer restrict the payload - why should we.
REST makes it incredibly easy to interoperate, that's why everything in
the Internet space is going there. The idea that the message coming
back has to be in the same syntax or format as the request is old
school, or that every request or payload does. XDS.b from IHE?
Reinventing the wheel - and making it out of stone rather than radial
plies. It's painful. What are we doing? Making our entire industry a
dinosaur just because a few of our most powerful vendors are?
Google 'RESTful Interface' = 1,190,000 hits. Google 'XDS.b' = 57,300
hits. And here's what you get from IHE's own wiki:
"In conclusion, if XDS.b and XCA are to achieve the interoperability
what we need, the community will have to adapt to the more modern rules
of Web Services. Many of us will not want to write code to handle all
this variability. Honestly, healthcare as a community should not be
specifying low level communications interfaces like Web
...
At least at the primary care level, we need to look at the EMR deployment problem differently. We who are technologically savvy, think of electronic medical records as information technology. But your typical doctor doesn't want to think of IT (all my physician friends outside the VistA world are more interested thinking of patient care than about IT).
Practices can deal with EMRs if they are treated like appliances with a service plan, like a copier, a sterilizer or a building alarm system. A vendor ships a preconfigured EMR appliance. The practice plugs it into power outlet and the network. It's an EMR appliance that they can connect to from any PC. The vendor remotely administers the appliance as part of a service that is priced like a utility (e.g., $x per provider per month, $y per patient visit, etc.) and *zero* administration for the practice.
The appliance is actually a commodity PC (maybe with the vendor's sticker on it, or even painted lilac & taupe in the vendor's corporate colors). It's inexpensive. The disks/databases are encrypted so that if it is stolen, nobody is out much money and patient data is still secure.
The benefits of having an appliance in the practice are (a) lightning fast LAN response times even for a practice in the boonies and (b) something that people can touch and feel (the EMR system is a thing rather than an abstraction and the people in the practice know that their patient data is inside the appliance, just as it is today inside their filing racks).
As part of the service, the appliance has a low bandwidth real time streaming backup to an environment in the vendor's data center (or to a server rented by the vendor somewhere). This backup is only milliseconds behind the appliance. In the event of a failure in the local appliance, the practice can switch within a couple of minutes to the VIstA in the data center, and all their latest patient data is right there. The vendor ships a replacement, the practice ships the failing appliance, the new appliance catches up with work done against VistA in the data center and switches back to the local appliance.
The practice has no access to the server except from their PCs, but there is a "break the glass" way that they can access all the data in it if the vendor goes out of business or if there is a dispute. By using a "break the glass" approach, the vendor is protected.
*All* of this is technologically feasible *today*. The disruptive technology is here. But it needs to be productized, packaged and presented differently.
<edmund.billi...@medsphere.com> wrote: > Let’s take this up a level. This is not about open source or the standards > themselves specifically. Its about what technologies will ‘drive’ > mainstream adoption. As the article cites examples over and over again, its > the good enough and not the perfect that supports the broad adoption.
> The adoption of HIT by the early adopter “have alots” started in the early > 1990’s and these solutions have not crossed the chasm to the mainstream.... > To “The Haves and The Have Nots”. 1.5% EMR adoption by US hospitals in > 2009 is glaring evidence.
> I can’t tell you have many times when asking physicians what they thought of > the EMR’s in the market... They say, “they are just too much”. “Too > expensive, too complex, more than my practice needs”. The reason chasms > like this occur is because as Geoffrey Moore wrote in Crossing the Chasm.... > The early adopters drive technology to the 100% case and the products do > not translate to the mainstream. When innovative companies apply a pareto > analysis and the 80/20 rule, technologies can be dramatically simplified and > they are translated for mainstream adoption.
> If you have been to an HL-7 or an HITSP meeting, clearly it is early adopter > driven. If you look at the CDA, its comprehensive and looks to cover the > 100%. If you look at how XML is applied, it requires an understanding of > XML and health informatics and ....most critically the nonstandard > applications of XML within the standard. Its a science project not an > innovation.
> So as Clayton Christianson describes in “The Innovators Dilemma”
> “A DISRUPTIVE INNOVATION IS A TECHNOLOGY THAT BRINGS A MUCH MORE AFFORDABLE > PRODUCT OR SERVICE THAT IS MUCH SIMPLER TO USE IN THE MARKET.”
> “AND SO, IT ALLOWS A WHOLE NEW POPULATION OF CONSUMERS TO AFFORD TO OWN AND > HAVE THE SKILL TO USE...., WHEREAS HISTORICALLY, THE ABILITY WAS LIMITED TO > PEOPLE WHO HAD A LOT OF MONEY OR A LOT OF SKILL”.
> So, if we focus on adoption and take CCR as an example of a good enough > innovation. It is simpler to apply or use and thus is more affordable to > develop and anyone that knows XML can use straight off.. Its accessible.
> So the question for the ONC to answer regarding standards is not an issue of > what the “large” organizations need over the “small” organizations. The > question is as it was for the CCHIT Comprehensive Certification,
> “Do you want to cement-in requirements that have not been adopted by the > mainstream?”
> “Do you want the early adopters from “have alot” organizations defining > solutions or standards that must be a adopted by the mainstream?”
> “Can we ignore a standard that technology companies have found much easier > to innovate with?”
> If good enough does not become sanctioned and perfect does..... Innovators > will use good enough to get to the same results anyway. For the VistA > Gateway, George Lilly used CCR and then transformed it to a CCD.
> Well, good enough then.
> Edmund
> ________________________________ > Edmund Billings MD > CMO & EVP Product > Medsphere > 1971 Palomar Oaks Way, Suite 200 > Carlsbad, California 92008 > edmund.billi...@medsphere.com > www.medsphere.com > www.medsphere.org > Skype: edmundbillings > 415-505-8953 c > 760-692-3713 o > 760-683-3701 f
Exactly, its the complexity and cost of the products that continue to block adoption. The CCD is just a proxy for the same 100% rule complexity that has blocks adoption. Its the chasm and crossing it will require innovation, not just more of the same now that docs have 40k dollars. What small businesses in other industries with 3 employees have to spend $400-500/month or on mission critical software.
As far as proxies go, it would be most telling to correlate the rate of HL-7 3.0 and CDA adoption to that of mainstream EHR adoption. And then to look at the rate of CCR adoption.... It might help us project how good enough applications and services might be adopted.
For anyone who has not read Crossing the Chasm, do it and follow it with the Tipping Point. The mainstream adopts not based on a ROI assessment or due dilligence or a lengthy product selection, they adopt because its a no-brainer and they feel the me-too pressure. The mainstream do not relate to the early adopters. They relate to the practical early majority who they look up to. If they now have one, I better get one too.
Edmund
________________________________
Edmund Billings MD
CMO & EVP Product
Medsphere
1971 Palomar Oaks Way, Suite 200
Carlsbad, California 92008
edmund.billi...@medsphere.com
www.medsphere.com www.medsphere.org Skype: edmundbillings
415-505-8953 c
760-692-3713 o
760-683-3701 f
________________________________
From: "Elwell, Tim" <Tim.Elw...@misys.com>
Reply-To: <open-ehealth-collaborative@googlegroups.com>
Date: Wed, 23 Sep 2009 15:45:19 -0700
To: <open-ehealth-collaborative@googlegroups.com>
Conversation: The Good Enough Revolution
Subject: RE: The Good Enough Revolution
I appreciate the comments Edmund as I have the same Christiansen sound bites in my pitches too. But let's not kid ourselves. The 1.5% hospital EMR adoption rates or the 17% (using the optimistic number) EHR adoption rates in provider practices have nothing to do with the CCD/CCR argument. It's much more about perceived value and return on investment - however the customer defines it. The expectation is that ARRA incentives will help to solve the ROI imbalance. I hope the Feds are right.
The CCD train has left the station and with the increased EHR adoption that will be promoted using the ARRA incentives, CCD usage will increase as well. I'll let the techies argue what's technically best but the directional decision has been made.
Lastly, this is about open source and standards. When it comes to interoperability, we need to be beating the drum that this is one place that there are no compromises. Black box solutions around interoperability are not sustainable.
Tim
Tim Elwell
Vice President
Misys Open Source Solutions ("MOSS"), LLC
123 Main Street, 8th Floor
White Plains, NY 10601 USA
T +1 914 821 2566
F +1 914 422 3659
M +1 914 260 4402
E tim.elw...@misys.com
"First they ignore you, then they laugh at you, then they fight you, then you win." Mahatma Gandhi
________________________________
From: open-ehealth-collaborative@googlegroups.com [mailto:open-ehealth-collaborative@googlegroups.com] On Behalf Of Edmund Billings
Sent: Wednesday, September 23, 2009 5:02 PM
To: open-ehealth-collaborative@googlegroups.com
Subject: Re: The Good Enough Revolution
Let's take this up a level. This is not about open source or the standards themselves specifically. Its about what technologies will 'drive' mainstream adoption. As the article cites examples over and over again, its the good enough and not the perfect that supports the broad adoption.
The adoption of HIT by the early adopter "have alots" started in the early 1990's and these solutions have not crossed the chasm to the mainstream.... To "The Haves and The Have Nots". 1.5% EMR adoption by US hospitals in 2009 is glaring evidence.
I can't tell you have many times when asking physicians what they thought of the EMR's in the market... They say, "they are just too much". "Too expensive, too complex, more than my practice needs". The reason chasms like this occur is because as Geoffrey Moore wrote in Crossing the Chasm.... The early adopters drive technology to the 100% case and the products do not translate to the mainstream. When innovative companies apply a pareto analysis and the 80/20 rule, technologies can be dramatically simplified and they are translated for mainstream adoption.
If you have been to an HL-7 or an HITSP meeting, clearly it is early adopter driven. If you look at the CDA, its comprehensive and looks to cover the 100%. If you look at how XML is applied, it requires an understanding of XML and health informatics and ....most critically the nonstandard applications of XML within the standard. Its a science project not an innovation.
So as Clayton Christianson describes in "The Innovators Dilemma"
"A DISRUPTIVE INNOVATION IS A TECHNOLOGY THAT BRINGS A MUCH MORE AFFORDABLE PRODUCT OR SERVICE THAT IS MUCH SIMPLER TO USE IN THE MARKET."
"AND SO, IT ALLOWS A WHOLE NEW POPULATION OF CONSUMERS TO AFFORD TO OWN AND HAVE THE SKILL TO USE...., WHEREAS HISTORICALLY, THE ABILITY WAS LIMITED TO PEOPLE WHO HAD A LOT OF MONEY OR A LOT OF SKILL".
So, if we focus on adoption and take CCR as an example of a good enough innovation. It is simpler to apply or use and thus is more affordable to develop and anyone that knows XML can use straight off.. Its accessible.
So the question for the ONC to answer regarding standards is not an issue of what the "large" organizations need over the "small" organizations. The question is as it was for the CCHIT Comprehensive Certification,
"Do you want to cement-in requirements that have not been adopted by the mainstream?"
"Do you want the early adopters from "have alot" organizations defining solutions or standards that must be a adopted by the mainstream?"
"Can we ignore a standard that technology companies have found much easier to innovate with?"
If good enough does not become sanctioned and perfect does..... Innovators will use good enough to get to the same results anyway. For the VistA Gateway, George Lilly used CCR and then transformed it to a CCD.
Well, good enough then.
Edmund
________________________________
Edmund Billings MD
CMO & EVP Product
Medsphere
1971 Palomar Oaks Way, Suite 200
Carlsbad, California 92008
edmund.billi...@medsphere.com
www.medsphere.com www.medsphere.org Skype: edmundbillings
415-505-8953 c
760-692-3713 o
760-683-3701 f
________________________________
From: Richard Peters <rpet...@scarecrowfilms.com>
Reply-To: <open-ehealth-collaborative@googlegroups.com>
Date: Wed, 23 Sep 2009 11:00:38 -0700
To: <open-ehealth-collaborative@googlegroups.com>
Conversation: The Good Enough Revolution
Subject: Re: The Good Enough Revolution
Tim,
Apologies, but when people say the CCD (and CDA and RIM) are too complex and the CCR is simpler they jump, like you have in your email below, to the conclusion that the CCD (and CDA and RIM) are therefore more technically sophisticated, more inclusive, and better.
The other conclusion people jump to, and which is widely promulgated by HL7 and HITSP, is that as you state the "CCD harmonizes the two earlier standards for Clinical Summary - CCR and CDA."
First, the CCR is 'simpler' because it is extremely strict in its adherence to W3C XML standards and is computable and very efficient using all XML parsers and tools, including XPATH, XSLTs, Schematron, XPROC, and proprietary tools from all the XML tools vendors. The CDA and CCD do not. The CCR also does not allow any data to be placed as tag attributes - again, this is a technical nuance and is intentional. Keeping all data as elements generates a tree structure and a disciplined object-attribute hierarchy. Tag attributes parse flat - you cannot have a data attribute of a tag attribute. You cannot build a hierarchy off tag attributes. And, yes XML tools have been modified to find and readily parse data as tag attributes but run a test and parsers and XPATH are significantly faster, particularly when you get to data the size of clinical summaries, when all data are elements. Lastly, XML is best when it contains all of its relationships and mappings internally. In other words, it is a very clean object description language until it has to reference outside data or relationships to make sense of itself. CCR is very strict about this and is 100% built on as an object-oriented data representation. CDA and CCD, however, are based on the RIM and its archaic (in this day and age) ER (entity relational) data model. The CDA and CCD are referential - bad idea. This is 2009!!!!!
As for the second conclusion above that the "CCD harmonizes the two earlier standards for Clinical Summary - CCR and CDA," it is flat-our wrong. The CCD maps a limited subset of the CCR to CDA V2 syntax. Look at how the CCD treats medications, SIG, dates, coding, etc. and you will see the striking difference. The CCD cannot even represent approximate dates! What in the world? Approximate dates, pertinent negatives, cross-coding? Are these unique to health care? No. Are they critical to health care? Absolutely! And we have a national standard that cannot support them natively and that cannot represent a structured SIG? The CCR can and was built from the ground up to do so. Apologies again, but the CCR was built by technical people who actually also happen to practice clinical medicine!
XML is about computability. It is about packaging data so that any system can read the XML using common (and free) tools and can compute against it. Those of us who work technically both in health care and outside feel strongly that:
1) Health care data are no more complex than what we deal with in the 'real' world, and this includes security.
I agree with Bhaskar - 'good enough' is a compromise. It ranks somewhere below the bottom on the good-better-best scale. Like the baseball glove my mother bought me when I was a kid, 'good enough' never meant good. Open source, the CCR, these are not 'good enough'. They are simple and in their simplicity is their value.
Kevin
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Matthew King <flydo...@gmail.com>
Date: Tue, 22 Sep 2009 21:23:33 To: <open-ehealth-collaborative@googlegroups.com>
Subject: Re: The Good Enough Revolution
I don't know, Bhaskar, but that how it could be interpreted, if that comes
into my mind. That's why I agree with Tim's comment about "Open Source, good
enough."
m
On Tue, Sep 22, 2009 at 7:00 PM, K.S. Bhaskar <ksbhas...@gmail.com> wrote:
> On Tue, Sep 22, 2009 at 1:12 PM, Matthew King <flydo...@gmail.com> wrote:
> [KSB] <...snip...>
> > I think one weakness of the "good enough" idea in Healthcare is it
> implies
> > (to me) stagnation. In fact, once in place, it needs to be subjected to
> the
> > same iterative improvement process (CQI) as anything else.
> [KSB] Why should it imply stagnation, Matt? To me, good enough means
> good enough to be put to use today, but not so good that it cannot be
> improved for tomorrow.
> Dear Blaine: One such consortium is the Clinical Groupware Collaborative. > It's attracting many people who, like yourself, are non-ideological, want to > get the work done, and value collaboration as a means of advancing health IT > innovation. Give me a holler if you'd like more information.
> Kind regards, DCK
> David C. Kibbe, MD MBA > Senior Advisor, American Academy of Family Physicians > Chair, ASTM International E31Technical Committee on Healthcare Informatics > Principal, The Kibbe Group LLC > ___________
> 913-205-7968 mobile > ___________ > dki...@aafp.org > kibbeda...@mac.com
> CONFIDENTIALITY: This e-mail message (including attachments, if any) is > confidential and is intended only for the addressee. Any unauthorized use or > disclosure is strictly prohibited. Disclosure of this e-mail to anyone other > than the intended addressee does not constitute waiver of privilege. If you > have received this communication in error, please notify me immediately and > delete this. Thank you for your cooperation. This message has not been > encrypted. Special arrangements can be made for encryption upon request.
> On Sep 23, 2009, at 11:43 AM, Blaine Warkentine wrote:
>> I would love to see this environment take hold. I would like to form an >> environment where many apps (mobile/otherwise) that are relatively easy to >> use and singularly focused can be compiled into a larger atmosphere through >> integration into a consortium approach so that the data from the use of these >> apps actually has a story to tell and does not just live on the thick client >> of the phone. Creating this integration is something I have wanted to do for >> some time.
>> Interesting to think about how you can create the application so that it is >> convenient (easy, low cost, small features) which is one way to succeed
>> But to then house the data from the use of these convenient solutions and >> sell with a feature rich dashboard (high cost, adaptable, realtime, cost >> saving, administration, government, etc..) with appropriate monetization for >> a business to be created.
