The Healthcare IT Interoperability Blog

Sincerely,

David Blumenthal, M.D., M.P.P.
National Coordinator for Health Information Technology
U.S. Department of Health & Human Services

Either way, the improvements to society will be nothing short of amazing.

Remember 1999? Folks were promoting the Human Genome Project as the generational equivalent of the lunar landing and Columbus discovering America. There's no doubt that the human genome has vastly increased our understanding of disease, but we are about to undergo something seismic in the practice of medicine.

Now that ARRA/HITECH has finally answered the long big question, "Who Pays?" for much of the HIT/EHR world, the benefit we've seen from the sequencing of the human genome will pale in comparison to the immediate results that could happen with a nationally standardized model for networked medicine and electronic health records. The results we are seeing for systems that effectively adopt EHRs and physician collaboration systems indicate that even a partial success will produce stunning results.

Exhibit A: Kaiser Colorado.  Kaiser's Collaborative Cardiac Care Service (CCCS) "uses an electronic medical record and patient-tracking software to document all interactions with patients, track patient appointments, and collect data for evaluation of both short and long-term outcomes." Studying over 10,000 patients has demonstrated that their integrated CCCS system has reduced mortalities associated with Coronary Arterry Disease (CAD) by 76%. Newer data suggests EHRs systems that regularly communicate with patients are highly effective at maintaining target lipid levels. Studies such as these strongly suggests that, as part of a coordinated care program, a nationwide system of EHRs may will be as historic as the lunar landing (and certainly no less difficult), but with direct and immediate benefits of millions of lives and hundreds of billions of dollars saved. These results beg the question: "Have we been spending too much on basic research and not enough on the delivery of care?"

Other collaboration technology studies are beginning to show equally impressive results. A third party survey of Syndicom's (a client) case-based physician collaboration communities have found that 90% of spine surgeons using these case collaboration tools feel they improve their ability to practice surgery and make recommendations. Within Syndicom's community alone (over 1,000 spine surgeons), we're talking about thousands, perhaps tens of thousands of patients with improved outcomes, reduced pain, and reduced costs on our health care system. Collaboration has been a cornerstone of medicine for centuries (think grand rounds and tumor boards), yet we are just beginning to see the benefits of web-based collaboration.

If HITECH succeeds only partially in increasing medical collaboration, the $20 billion spent will be a bargain. In a nation where total medical and social costs attributed to CAD alone tops $475 Billion and affects 80 million Americans, the cost savings and life improvement potential is nothing short of spectacular for implementing a nationwide Kaiser-like CCCS system. When ten percent of patients account for 80% of all health care costs and 75% of those costs are related to chronic diseases such as CAD, the effective management of these diseases through effective health information is more beneficial than even the greatest blockbuster drug and reduced time in the hospital for high cost treatments. Savings of $50 Billion per year in CAD patients alone for a nationwide, connected EMRS is not a unrealistic.

Of course, none of this is really news to those of us in the HIT business. The promises of savings and health benefits of new technology have been made (and failed to materialize) endlessly for decades, but these the coming use of ARRA funds (which are finally answering the question of who pays?) will change the game. Never before has anyone been able to figure out who will pay for EHRs and what the incentives should be.

Now that that question has bee, to a large extent answered we're going to learn an enormous amount about best practices in HIT. As noted by David Blumenthal, the national coordinator of HIT, said earlier this week, “One thing we haven’t done is apply the scientific method in the practice of healthcare and medicine.” We as a nation have gone too long researching the mechanism of disease with far too little time spent researching the best practices in the delivery of care.

We can only hope that over the next several years we'll see as much research relating the use of information in medicine and patient outcomes. For too long, the evidence for coordinated care have been unsubstantiated by controlled studies. Just as other established practices that becomes standards of care, we need to have more research done to truly understand and quantify the benefits we are likely to see moving forward. With additional evidence-based HIT practices, we may look back on pre-unified HIT system as nothing short of barbaric, and possibly negligent, given the wide array of technologies available (and in use in other industries) for improving care. We just haven't had the research to back it up.

Studies such as this suggest that we've been thinking about HIT the wrong way. If these technologies can improve the practice of medicine and patient outcomes so dramatically, shouldn't they be considered part of the standard of care? In essence, they are a way to improve treatments and protocols across the disease spectrum. If your cardiologist found a treatment that increased survival by 76% in all CAD patients over a 2 year period, could he be found negligent for denying the use of it? Would Medicare reimburse it? Absolutely! When you think of HIT as a method for improving treatment outcomes, it really makes perfect sense that the majority of ARRA/HITECH is funded as a CMS reimbursement. The HIT portion of ARRA is a one time (hopefully) Medicare reimbursement for a treatment that's long overdue. Let's hear it for more research on the practices of medicine.

by Leonard Kish

PS. Thanks to The EHR Guy for this opportunity to guest blog. I hope that over the coming weeks we'll continue to explore the human, societal, scientific and economic, aspects of HIT and EHR adoption. I hope to blog on such topics as user experience, the power of open, web-based solutions and the potential of medical collaboration communities. I look forward to the conversations 

At the July 21 meeting of the HIT Standards, we approved an initial set of standards for quality, clinical operations and security/privacy. We were told to refine these initial efforts by the next meeting of the Committee, August 20, so that ONC and CMS can incorporate the work into the interim final rule. Here's an update on the deliberations of the workgroups.

Privacy and Security
We received several public comments about our selected privacy and security standards - those used for authentication, authorization, auditing, encryption, and secure transmission. It's important to note that the sending and receiving of transactions for healthcare information exchange is part of the scope of the Privacy and Security Workgroup. Clinical Operations specifies the vocabulary/codesets/value sets and the actual message or document to send. Privacy and Security ensures it is sent in a secure fashion, consistent with HIPAA and ARRA. Our recent decisions in response to comments are

*Although the IHE ATNA profile for securing transmission via TLS allows use of Null Cipher (i.e. no encryption) as an option for private networks, we will require all health information exchange transactions between organizations, even those running on private networks to be encrypted via the AES_SHA cipher by 2011.

*SOAP is an approach to data exchange that enables programmers to use the web to call remote servers using the HTTP POST syntax. POST means the URL does not contain any specific information i.e.

I use POST to talk to a server at http://mymedicalrecords.com and request information about my medical record number and the kind of information I want to retrieve using hidden exchanges between the servers, not by embedding the details of my request in the URL.

SOAP has a learning curve and generally requires a toolkit to make the implementation easier. It has been a favored approach in healthcare because it has many standardized security tools.

*REST is an approach to data exchange the enables programmers to use the web to call remote servers using the HTTP GET syntax. It's easy to use without a toolkit. For example, you could use a browser to call a URL like the following to retrieve your allergies

http://mymedicalrecords.com?myMRN=1234567&show=allergies

Although it's simple, there are fewer standardized security tools. REST is increasingly popular and Amazon, Google, and most e-commerce companies have embraced REST, creating their own unique security tools.

*The Security and Privacy Workgroup recognizes that both approaches, SOAP and REST, should be allowable for data exchange. Here's a list of the HITSP Capabilities and Services supporting these transactions

TP13 - Manage Sharing of Documents (XDS.a), SOAP and REST
TP13 - Manage Sharing of Documents (XDS.b), SOAP
TP13 - Cross-Community Access (XCA), SOAP
TP21 - Query for Existing Data, SOAP
T31 - Document Reliable Interchange, SOAP
T42 - Medication Dispensing Status, SOAP
TP49 Sharing Radiology Results, SOAP and REST
TP50 - Retrieve Form for Data Capture, REST
T63 - Emergency Message Distribution Element, SOAP
T66 - Terminology Service, SOAP and REST
T81 - Retrieval of Medical Knowledge, REST
T85 - Administrative Transport to Health Plan, SOAP
TP89 - Sharing Imaging Results, SOAP and REST

For a more detailed discussion of the pros/cons of SOAP and REST, see my blog entry on the topic.

Clinical Quality
Leveraging the completed HITEP report, the Clinical Quality Workgroup has proposed 27 initial quality measures and the data types required to capture each electronically. The challenge is that several quality measures contain exclusionary criteria i.e. when considering HbA1c levels, remove patients on comfort care measures from the denominator. When considering tobacco cessation counseling, remove patients who really like smoking and lack readiness to quit from the denominator. Such exclusionary criteria are really challenging to support with existing EHRs. It is likely that either these exclusions will have to be removed from the measures until EHRs and standards support them, or that self attestation of quality measures rather than electronic measurement be done in the short term until EHRs can capture these more esoteric data elements. The Clinical Quality workgroup is examining every data type for its readiness/adoption and will then make final recommendations on the quality measures and data types to use in 2011.

Clinical Operations
We're refining the matrix of vocabulary, messaging and document standards to respond to comments from HIT Standards Committee members and the public. We've heard such things as

*Allow HL7 2.51 messaging as well as XML-based document formats for transmission of data in HIEs, at least for the next several years

*Although care coordination and patient experience data exchanges may benefit from unstructured documents such as a PDF exchanged electronically along with metadata, quality measurement really requires codified data, even if it is just ICD9. SNOMED-CT is the preferred vocabulary for clinical observations and eventually should be used for all quality measures, but it will take several years for SNOMED-CT to be fully implemented in healthcare information exchanges, so ICD9 and ICD10 will be allowed along the way

*The HIT Standards Committee focuses on healthcare information exchange - from the edge of one organization to another organization. All the vocabularies we are discussing - LOINC, RxNorm, SNOMED-CT and UNII (for allergies) are for exchange, not necessarily required within internal systems of organizations. This is the realistic approach that is needed to give organizations the time they need to implement controlled vocabularies for data exchange.

We'll continue our work for the next two weeks and then present it publicly on August 20. Thanks to all the Committee, Workgroup, and HITSP volunteers who have spent many hours on this effort.

From my perspective it is the renaming of a traditional role.  It attempts to embellish what we used to denominate as a "Software Design Engineer" due to a fad or trend that is occurring.

I already believe that we have so many roles and titles that it's becoming a little ludicrous.

I am sure we will outgrow it when the industry follows a new trend with some fancy name such as: "Virtual Creator" now that virtualization is a fad.  Yes, I remember when software developers would consider themselves "creators".  Writing a program was defined as a "software creation process".  If a farmer creates crops, eggs, and milk then why can't we create?

I still believe that in practice this could be a role, maybe a title, but definitely it is not yet a profession. 

Anyways, we have enough titles already.  We have literally stolen titles from every industry I can think of. Well, we haven't seized the medical field titles yet but I can predict that soon we will.  Maybe I will become a network neurologist or a core cardiologist, or an infrastructure traumatologist, hmmm, what else?

The term is definitely useful to get the attention of recruiters who use it as a keyword to search for potential candidates.  It is "commercially" appealing at the least.

Albeit IBM used the term for its key engineers during the eighties after the term "scientist" didn't fit very well in the mainstream business world, it had started to fade away with the massive outburst of new information technologies in every sector, thereafter the terms "software engineer" or "computer systems engineer" became more popular in accordance with a conservative corporate world.

Bill Gates made the "architect" term popular once again when he stepped down from his executive position and was self-proclaimed as chief software architect.  He was careful of not losing his "C" title.  Many followed.  But he could have proclaimed himself anything and he would have had followers.  As it happens with every hype, this one faded away.

Until now! It has been relived due to another fad:  Service Oriented Architecture (SOA).  A few years ago folks would rather call themselves:  team leaders, project leaders, development managers, directors of development and the sorts.  Leader was the best component of a title even if you were the last one in the organizational chart with no followers to lead.  If this latter was the case you were a leader by persuasion, or influence.

Don't we adjust things easily when the round pig doesn't fit in the square peg.  Or is it the other way around?

How many universities out there offer a Software Architect curriculum?  I was unable to find courses that would even cover the subject, maybe "Software Paradigms"?  I visited both Stanford's and Berkeley's websites.

Another question is:  Can it be considered a profession if it hasn't been formally embraced by the academia world?  Not really.  But it can still be a job title and certainly a role.  I couldn't find the title in Salary.com where architect is mainly for landscapers and database builders.

The fact is that the activity that a software architect should perform is that of a designer and not of an implementer.  Implementing has a granularity mindset and not a big picture one.

To perform the role of software designer (or software architect for those of you with a freemason complex:. :) you have to possess certain traits, among them:

1. Vision,

2. Big picture mindset,

3. Knowledge of the technologies you are using and/or integrating with,

4. People skills,

5. Project management skills,

6. Strong leadership,

7. Self-constrained (Getting away from the low-level details like: "programming or coding!")

Should a software architect perform low-level activities?  In my opinion, definitely not.  If you architect and implement I can foresee a project without an end.  The same reason technical project managers have been substituted by non-technical ones has been for almost the same reason.  When the project manager got involved in technical details the scope of the project became a "moving target".  And by the way, a "moving target" is not a positive connotation for an executive team.  Non technical project managers limit all activities within the scope and only change them when it is meant to mitigate an unforeseen risk that popped up.

In conclusion and in one sentence: "A software designer (or software architect) is a professional that performs the activities of forethought and calculated analysis, creative design, and mindful projection of that which will result in the materialization of a service, product, or solution that fulfills the requirements of a specific business need within the margins of a well defined scope and that can be clearly understood by all the stakeholders involved."

The EHR Guy

I have nothing against open source software and I use many applications developed under this paradigm for my daily activities, I even enjoy them as weekend projects (e.g. ClearCanvas, PatientOS, Mirth Project, OpenDICOM, etcetera), but I just don't see them fit for the demanding and critical healthcare IT domain. 

VistA is not an example of the typical open source application so let's not bring it to the table for this discussion.

CCHIT's step to support the FOSS realm is indeed laudable, Mark Leavitt has proven to be a nice guy, this is a genuine gesture which gives you (the open source guys) the opportunity to certify your Electronic Health Record (EHR) products.  But this isn't the gateway to success since you may still have a long stretch to go. 

Let me explain why:

Healthcare IT is extremely demanding and it requires discipline a discipline which can only be delivered by highly organized and structured entities.

Companies such as: GE Healthcare, HP, McKesson, MEDITECH, Philips, SIEMENS, and similar others have for many years devoted themselves to the development of highly reliable clinical applications and medical devices.  Most of these aforementioned companies have strict product development methodologies and strategies that they have had to implement in order to meet with the ever increasing and strict requirements of the FDA for the verification and validation  (V and V) of medical devices and related software.

Many may argue that for the software product development process they don't use the same guidelines as they do for the manufacturing of their medical devices, but knowing how these companies operate, and I have worked closely for and with them for many years, I am absolutely sure that they do.

Maybe the adventurism into the healthcare IT domain taking place by Google, Novell, and Sun Microsystems (soon to be part of Oracle), among many, and albeit this latter one at one point in time built very sophisticated medical image viewing workstations based on their SPARC technology, are probably giving you an over optimistic perception. 

In my opinion these companies currently just don't have the culture to fit into this rigorous process.  Undoubtedly, they are extremely successful organizations in their activities but just not in this one.  You see, this is a different beast. 

And maybe you do a great job at creating software, perfect software.  But this is not the only piece of the puzzle since there is the rigid documentation process required for clinical product development.  Only the documentation process will overwhelm your budget if not drain it completely.

The very laid back and lax nature of open source development is the antithesis of what is required to develop critical clinical applications.

The FDA has formed a working group to determine whether or not Electronic Health Records should be regulated and to what extent if such is the case.  Let's say that they do decide to regulate them, and then this would be your demise in healthcare IT.  The costs involved in meeting FDA requirements go beyond those that the most daring venture capitalists are willing to risk.  Only companies with an infrastructure and logistics similar to those of GE Healthcare and SIEMENS can actually survive and strive in a scenario described here.

My recommendation to you, open source developers, is that along with the FOSS community members, you continue pouring your energies into your projects but don't expect to take the industry by storm.  It just won't happen, sorry.

Stick with trying to overcome Microsoft Office some day in the remote future, maybe by 2021, or by creating a user friendly operating system that is not tailored "only for geeks", like Linux is.  Did you know that almost 90% of the workstations currently used by clinicians are Microsoft technologies based?  You see, open source is "only for geeks" and not for the real world, the real users. 

And I am not referring to geeks in a derogatory way since I consider myself one as well.  But I do have a professional maturity level to understand that I have to create solutions for real world users and not savvy information technology experts.

Once you break out of your silicon shell then let's sit down and talk seriously.

Thanks for reading!

The EHR Guy

Hi Followers,

For many years, ever since I knew about blogs, I always thought of writing my own weblog.

I’m not much of a writer so I really never expected to actually launch a serious one but I did want to give it a shot.

As a matter of fact, I didn’t even know what to name it so I decided to use my old worn out moniker as the moderator’s name and give it the flamboyant title of “The Healthcare IT Interoperability Blog”.

Getting started was difficult, somewhat like jumping in freezing water.  But after taking the first steps things just started getting easier and unfolding all by themselves.

For many months I had to push my friends and colleagues to read my blogs and many times they agreed to it but I doubt they ever read them since I would ask for feedback and they would just answer: “cool”.  It would take me a month to write one and still I considered it a bit on the mediocre side but I would post it anyways.  It was like throwing a sibling into the pool so that he/she could learn how to swim.

Anyways, everything was cool while things remained in a closed circle.  Like some have mentioned before, I do admit to have a sort of mildly-geekY-paranoia of going public.

But then, suddenly, I find myself with a surprisingly unexpected popularity, in small proportions, of course.  Some notorious Healthcare IT folks were actually reading my blogs and they would recognize me at some of the meetings.  For Pete’s sake I was using an avatar! How could they recognize me?  I guess because the avatar has a striking resemblance to me.  I don’t think they found my blogs interesting since they never commented about them.  I think they just liked the style for some reason.  Who knows?

Well, the fact is that I am enjoying this new hobby that I have.  I feel that I can share my experience in the healthcare information technology domain with many out there.  I will try to provide as much value as I can.

The Healthcare IT Interoperability Blog now has 2 bloggers and both act as moderators as well.

I, The EHR Guy, will focus on, well, EHRs. The EMR Gal will focus on EMRs, no brainer, huh?

You are probably asking what is the difference between an EHR and an EMR and I’ll answer this question in the next blog that I will be publishing very soon!  So please come back frequently!

Thanks for reading!

The EHR Guy