An Overview of ONC 's Vision and the Role of HealthIT and HITECH in Health System Change and Health Care Reform

Another one... this time from ONC

---

2010 ONC Update
December 14-15, 2010
Washington, D.C.

http://www.tvworldwide.com/events/hhs/101214/#
http://healthit.hhs.gov/portal/server.pt?open=512&mode=2&objID=3334

Tuesday, December 14, 2010
8:30 am - 5:00 pm EST

8:30 – 9:00 am Opening Remarks
Kathleen Sebelius, Secretary, U.S. Department of Health and Human Services (HHS)
Introduction by David Blumenthal, MD, MPP, National Coordinator for Health
Information Technology, Office of the National Coordinator for Health
Information Technology (ONC), HHS

9:00 – 9:45 am An Overview of ONC’s Vision and the Role of Health IT and HITECH in Health
System Change and Health Care Reform
David Blumenthal, MD, MPP, National Coordinator for Health Information
Technology, ONC
Donald Berwick, MD, Administrator, Centers for Medicare and Medicaid Services
(CMS), HHS

9:45 – 10:15 am An Overview of ONC’s Strategy and Programs
Farzad Mostashari, MD, ScM, Deputy National Coordinator for Programs and Policy,
ONC

10:15 – 11:00 am Break

11:00 – 12:15 pm Update on Privacy Regulations and Activities in the Office of the Chief Privacy
Officer
Joy Pritts, JD, HHS Chief Privacy Officer, ONC

12:15 – 12:30 pm Break

12:30 – 2:00 pm Getting to Health Information Exchange
Farzad Mostashari, MD, ScM, Deputy National Coordinator for Programs and Policy,
ONC
Doug Fridsma, MD, PhD, Director, Office of Standards and Interoperability, ONC
Claudia Williams, Acting Director, State Health Information Exchange Program,
ONC

2:00 – 2:15 pm Break

2:15 – 3:30 pm An Overview of HITECH Programs Supporting Providers in Achieving Meaningful Use
Moderator: Mat Kendall, Director, Office of Provider Adoption and Support, ONC
Panelists: Paul Kleeberg, MD, Clinical Director, REACH
Robyn Leone, Regional Extension Center Director, Colorado Regional Health
Information Organization
Norma Morganti, Executive Director, Midwest Community College Health IT
Consortium, led by Cuyahoga Community College
Rick Shoup, Director, Massachusetts eHealth Institute

3:30 – 3:45 pm Break

3:45 – 5:00 pm An Overview of Medicare and Medicaid Incentive Programs

Moderator: Michelle Mills, CMS
Panelists: Robert Anthony, CMS
Elizabeth Holland, CMS
Jessica Kahn, CMS

A do-it-yourself presentation on Health and Information Technology

A nice do-it-yourself presentation on Health and Information Technology from AHIMA developed for HI&T Week.

---

Cogitating on Standards Harmonization, S&I and Canadian Collaboratives

Just for fun, and so you can keep up, go back and read the following posts.

1. Hello again, it's me, stirring up the pot
2. A Canadian Perspective on Standards Harmonization
3. What happens to HITSP Now?
4. In which I have something positive to say about ONC

Now anybody who has been paying attention will realize the the ONC S&I Framework discussed in #4 is something that will be replacing HITSP (see #3), for which Canada has a particular solution (see #2) that I recommended we might apply south of the border in #1.

I've been thinking on this out loud for a while.  That first post is in July of 2009.  I still don't have all the answers, and I suspect I never will, and in fact, I'm still thinking...

Where I'm focused right now is trying to figure out what the governance model should be. 

I was listening to David Riley's presentation on CONNECT last week.  The idea that FHA came together as a way to represent the entire Federal government in CONNECT was interesting, because, yeah, the Feds have way to much weight for an agile organization if every agency gets involved.  And the same problem happens with SDOs, and payers, and ...

And yet the HITSP model left me wanting too, because if only X gets to elect X, then all X's will be the utmost in X and well, nobody different will ever get heard from, and the small ANYTHING will be completely drowned out.

And it shouldn't be about any one kind of anything...

So, what should happen here?

And then I think about the current election cycle here in the US, and I think about casting dice instead of votes in some races...

Which leads me to think that random chance might have some role to play...

And then there's the case where we made a leadership role in an association I'm a member of specifically to address a part of the group not usually heard from...

So, if the US were to have a new HITSP, or something like it, how should it be governed and who should do the governing?

I know one thing that desperately needs to change.  It needs to be able to say NO, and set its own schedules.  The people doing the work need to have that control.  Somebody else may be able to set priorities, but I don't care what you do, 9 men still won't be able to birth a baby in one month.

You need to have the right resources, and the right amount of time in place to make it work.

Still thinking...

Maybe if I sleep on it, I'll wake up with the answer...

It should be about Service instead of Technology

More than two decades ago I worked in the Information Services department of a small marketing and publishing company.  Simillarly named departments existed elsewhere in the industry.  Over the years the name of that department has almost universally switched over to become first Information Systems, and finally Information Technology.

At the same time, my attention shifted from the technology, to the systems to the actual services being provided.

In healthcare the focus has changed from the Hospital Information System (or HIS) to the Electronic Medical Record (EMR) or Electronic Health Record (EHR).  But again, thought leadership has been shifting from Information Systems and patient or practice medical records to the health services that the technology is providing (e.g., Health Information Exchange, lab result reporting, et cetera).

The name change does seem a little backwards, doesn't it?

Crossing the HITECH Meaningful Divide

I attended the "Crossing the Infrastructure & HITECH Meaningful Divide Symposium" today in Valley Forge PA, and will be speaking on the Meaningful Evolution of Standards tomorrow.  I spent a good portion of the day listening to speakers, except for two phone calls which meant that I missed some of the discussions.  I grew up around here, so it was nice to be speaking in an area that I know and to help providers I know to better serve my family members that still live nearby.

First up was Dr. Karen Bell, Chair of the Certification Commission on Health Information Technology.
She had some interesting things to say, and some things that people in the room needed to hear.  One of her key points was that it's not enough to have certified technology, you have to be able to use it in order to get the incentive payments.  That is pretty clearly stated in the regulations, but she was pushing in a slightly different direction.  One of Karen's main themes was that it isn't enough to have a certified suite of modules, but that they all have to work together.  For that she was pitching the CCHIT branded certification, because that was one of its differentiators.

She (and CCHIT in general) still has a number of questions about the security critieria (I know John Moehrke has been wrestling with may of the same issues).  While CCHIT is working with ONC on getting clarifications, they are still trying to address all the issues around security's role in modular certification.

Karen also talked about how they are working with hospitals seeking certification of in-house developed EHR systems.  CCHIT has a 3-step education program that is designed to help hospitals understand the certification process.

She finished her talk on this very important note.  Patient care is not just about diagnosis and treatment.  It is about caring for patients.  It is very clear that Karen is very passionate about what she and CCHIT are doing, and it was a pleasure to hear from her.
One of the interesting follow-up questions which was asked by a healthcare provider was on the topic of certification and FDA involvement.  Neither Karen nor I have a crystal ball to see where that is heading, and there doesn't seem to be much coming out of ONC and FDA on this topic.  But it was good to see the concerns being raised.

Following Karen's talk was a panel presentation titled "How C-Suite it is".  "Buddy" Gillespie led this panel and there were some interesting responses to some of the questions he posed to the panel.  On the ROI of meaningful use, one panelist pointed out that Incentive payments aren't ROI, but the process change that the resulting changes have on your business should result in ROI if you do it right.  He later points out that the penalties going into effect in 2016 are REAL MONEY, not quite like the incentives.

Another question on the cloud was asked, and one panelist made some daring predictions. In the next five years, he said, we will see heavier use of the cloud and SaaS models and lest creation of hospital data cetners.  In 10 years, the model will be very much ASP based and the clincial apps will run in the cloud.  Hospitals will focus on their core business models.
Now, HITECH/Meaningful Use isn't the only problem that providers face.  ICD-10, 5010, and others are headed their way.  What meaningful use does though, according to another panelist, is provide a proving ground for a governance process that can be reused for each of these different implementation projects. Another panelist talks about how their IT staff doesn't run Meaningful Use or ICD-10 or 5010 readiness programs, but places the responsibility for that on clinical staff working with IT.

My follow-up question on the cloud discussion had to do with provider readiness to accept the cloud, and the perceived risks.  In response to my question, one panelist talked about how their organizational policy with respect to the cloud makes it OK to deal with de-identified data in the cloud, but not personally identifiable, because the perceived risks of accidental disclosure are too great.  Another provider pointed out that for many, cloud = internet, and that SaaS may be made available through a secure link (e.g., VPN) rather than just over the web.  The value of that was because privacy from a provider or practice perspective was also important.  It was important for one hospital to ensure that their SaaS model included a neutral third party because practices were concerned about how access to usage information might now work in their favor.  Phil Magistro, Deputy Director of the PA Governor's Office for Health Care Reform talked about the PA State view of Health Information Exchange spoke next, just before lunch.  His presentation was full of great nuggets.  One of the issues that PHIX had was that ONC was slow in providing guidance, and wanted to be rather more directive about what the HIE would do.  His concern was about scope creep, but also how the State manages the scope of this program.
Some of the issues he addressed were the importance of cross-border communication.  Valley Forge where the conference was being held is in the "Delaware Valley", which is a tri-state area within about 30-60 minutes of 3 major cities in three different states (Philadelphia, Trenton, and Wilmington).  There is a hospital in PA connected today to one of the New York RHIOs.
Another challenge for PHIX is the need to address the needs of providers who aren't being supported by meaningful use.  So, they are providing a portal for LTC and other providers who aren't covered under meaningful use regulations.

PA has a pretty aggressive plan, and expects about 90% of hospitals to be fully connected to the HIE in five years.  Their RFP for a HIE provider was issued on April 1, and was recently awarded through the State department of general services to Medicity.

Of course, while tweeting all of this, John Moore at Chilmark Research (@john_chilmark) responded through twitter pointing out that the laws make it difficult. I posed John's point to Phil and he had a great response.  We ensure that we follow our State laws when we send the information, and it is up to the receiver to ensure that they follow theirs when making it available on the other end.  I thought that was a really good way to handle the situation.  I of course tweeted back the response...

Now, with regard to those policies, PA will be an opt-out state with restrictions for exchange of certain kinds of information that is more highly protected (e.g., drug and alcohol abuse treatment).  Some of the challenges are with the lawyers:  "If you have 20 lawyers in the room you get 27 opinions".

To wrap up the sessions, one of the presenters showed a picture of the World's oldest written medical records dated around 1800 BC.  He noted that some providers are not much further along.

I had to find that picture for the HL7 CDA Ambassador presentation.  The point to make is that you want a record that can last as long as necessary.   

Customer Service, a Hello, Upcoming Events and IHE Planning

SK wants to know:
Do we have any other (CDA based) templates other than CCD , which will enable us to provide discharge summary etc in cda format itself. As per your article, these kind of standards are in discussion and i would be thankful if you can advise me if there are any approved standards..


IHE Patient Care Coordination developed a discharge summary quite a number of years ago.  In fact, it was the first profiles developed by that committee, placing it in the 2005-06 season.  This post lists about 46 different CDA document implementation guides from four different sources


MO wants to know:
The NIST Test Procedure for §170.302 (v) Encryption when exchanging electronic health information and the Test Procedure for §170.302 (u) General Encryption require the tester to demonstrate that the encrypted data is unreadable.  If using a third party mechanism, say a VPN, I don't think the data is accessible.  How would NIST want this demonstrated?


I punted this one to John Moehrke, you'll have to read his answer here.

Liz, LF said to say hi.  Hi!

Upcoming Events
Tomorrow I'll be heading back to near where I grew up, in Valley Forge, PA to speak at the "Crossing the Infrastructure & HITECH Meaningful Divide Symposium" being held at the Raddison Hotel in the Valley Forge Convention Center Complex.  I'll be speaking on EHR and the Meaningful Evolution of Standards on Thursday morning.

IHE Planning Week at RSNA
Tomorrow ends the IHE PCC planning meetings to discuss our upcoming profiles.  We've heard from four different proposal teams on:

1. Nursing Admission Problem Reconciliation
2. Nursing Vocabulary Value Sets
3. Transport Workflow
4. Completion of Perinatal Profiles

We've had some great discussions, and will come to consensus tomorrow on what to move forward with to the technical committee meeting in November.  Some of my thoughts:  We may expand the reconciliation profile to problems in general, although there's some discussion about how this is an interoperability profile.  The evolution of transport workflow will likely depend on the data requirements, it could merge into ETC or stand on its own or both could be derived from a common data set.  I believe we will have some concrete requests for what to bring to the technical committee for discussion.

The teams did a great job with value statements, resourcing of the efforts, and talking about market participation that I mentioned yesterday.

We also reviewed several change proposals, including one from Andrew at NIST that I've been behind on getting done for more than a year.  Somehow I thought I'd managed to fob that off on someone else but it's back in my court.  That was, as I recall, approved to move forward so now I have to write up the changes.

My hope is that we can also review a revision of the Functional Status Assessment profile as well, and bring it in line with current HL7 Patient Care work on assessments.

Ok, back to the CDA book. Ten days and counting...

A Summary of Meaningful Use for Non-US Readers

This post comes at the request of some of my colleages from outside the US who want to understand more about what we are doing in our "National Healthcare Programme".  It might also be helpful for US readers that have been hiding under a rock for the last 12 months.

The US Federal governent allocated something like $33,000 Million to our "Ministry of Health" (called the Department of Health and Human Services, or HHS).  This is to support use of Electronic Health Records as part of our Economic Recovery.  This originated as a spending bill for economic recovery, so just about everything in it is rapidly paced because recovery $ need to be spent to be effective.

Purpose	Allocation ($M US)
Medicare/Medicaid Incentives	20,819
Broadband Access	4,700
Distance Learning, Telemedicine and Broadband	2,500
Office of the National Coordinator	2,000
Health centers	1,500
Comparative Effectiveness Research	1,100
Social Security Administration	500
Indian Health Services	85
Veteran's Administration	50

About $20,000 Million of this is allocated to "Incentive Payments" for hosptials and individual physicians and group practices to use electronic health records.  These incentive payments stretch out over four to five years, and can be as much as $44,000 to $64,000 per healthcare provider depending upon which Federal programs they provide treatment under.  Medicare is our Federally funded healthcare mostly for retirees, and Medicaid are Federal grants to the States to provide healthcare for poor and at risk populations.  The incentive payments are staged so that the biggest chunk shows up first, and then smaller and smaller chunks.  The criteria for recieving payments are also staged.  Just entering the door is probably the hardest, and also has the biggest ROI and payments.  But there will be subsequent requirements staged about 2 years apart that raise the bar incrementally, and those also have additional payments associated with them.  After 2015, instead of incentive payments (the carrot), healthcare providers that are NOT using HIT will start getting penalties which increase yearly (the stick).

As part of that law, Congress formally created the "Office of the National Coordinator of Healthcare IT".  Formerly shortend to ONCHIT, it now goes by the acronym ONC in most circles (until someone gets annoyed at them again).  This week they are ONC to me.  That office was given $2,000 million to spend on different programs. That office was originally created by a memo from the President in 2004 to our Chief Minsister of Health (the Secretary of HHS).  That office had spearheaded the development of 4 prior programs, HITSP, HISPC, CCHIT, and NHIN, and now is responsible for quite a bit more.

Allocation ($M US)	Purpose
643	Regional Extension Centers
547	State HIE Funding
265	Beacon Community Grants
118	Workforce Development
60	SHARP Grants

Regional Extension Centers are organizations designed to help educate healthcare providers about electronic health records, and to help them choose and implement them.  These are mostly organized around the states.  Besides educating doctors and helping them with implementations, these organizations are also approving and developing purchasing agreements with healthcare product vendors.

State HIE Grants to help build healthcare information exchanges.

I believe $20 Million of the ONC funds were transferred to our National Insitute of Standards and Technology (but it may simply have been a $20M appropriate, NIST has the money either way).  This is the same organization that built the reference implementation of XDS and supports a great deal of IHE Connectathon testing -- not just here in the US, but also internationally.

There are also 11 Federally funded contracts to build what is called the Standards and Interoperability framework. I don't know how this is going to turn out, but it could wind up being something like the Canadian Standards Collaborative that Mike Nusbaum wrote for me in A Canadian Perspective on Standards Harmonization. Of course, things will definately have a US rather than Canadian flavor, but we all speak the same language, Eh?

In order to recieve Incentive payments, physicians must use certified EHR technology.  That means that there has to be a certifying body.  There used to be only one under a prior federal contract, CCHIT, but now there is also the Drummond Group, and there are expected to be more.  I've heard as many as 12 have applied to be in the role.

To be a certified product, EHR Vendors must show that their EHR systems meet some or all of the criteria specified in federal regulations (see links above).  Those criteria require the use of certain standards, most notably the HL7 CCD for patient summaries (but they may also use CCR, pretty much a standard only used in the US), and HL7 V2.3.1 or V2.5.1 for labs, immunizations, and public health reporting.   Eventually, we will have an accrediting body (much like our ANSI accredits standards organinzations), certifying bodies (like CCHIT and Drummond), and testing laboratories, but for now, we just have certifying bodies and the rest of the infrastructure is expected to show up in a year or so.

Overseeing all this are two "Federal Advisory Committees", one which addresses Healthcare Policy, setting national goals, et cetera, and the other which addresses Healthcare Standards.  These bodies ADVISE our government though, and so even their recommendations can be ignored.  Our Secretary of Health and Human Services (you can think of her as our Minister of Health) is the one that has the final say on what gets done and what doesn't get done.

Now, I mentioned that Healthcare Providers have to use Certified EHR technology.  In fact, the way the regulations are written, they have to use it in certain ways prescribed by the regulation, and show that they have in order to recieve the incentive payments.  That includes using it to exchange information using standards, recieve lab results, prescribe medications, and to gather and report on a number of different quality measures considered to be national priorities.

Not quite one page, and no cartoons, but there it is.

What is the NIEM?

I spent an hour today on an NHIN Spec Factory call learning about the NIEM. The presentation appears here (Slideshare hated it at 5Mb, so its now on Google Docs). The NIEM is as you have probably heard, what ONC believes to be the framework around which their Standards Harmonization contracts that John Halamka blogged about a few months ago.  This was an effort from ONC in the socialization of the Standards framework using the NIEM that was at least partially successful and gets good (but not great) marks from me.  It was certainly better than the silence we've been hearing.

I heard a lot of familiar terms:  Use Cases, Gaps, Overlaps, Standards Evaluation ... sounded very much like HITSP.  But also many familiar processes from IHE (including testing), and the focus on model driven development makes me think that HL7 has quite a bit of expertise to offer as well

Some differences:  Pilots and Referece Implementations... The latter are something that is required by OASIS standards before they can become final.  Also, the inclusion of interim deliverables and interative ("agile") development.  The key to agile is not let it become "we don't know what we are doing so we are going to wing it" development.  That's a real danger.  You need to have documented processes.

Another big difference is all documentation in one place for an information exchange package.  That's something we all wanted out of HITSP but they didn't have the funding to implement.

According to the presenter, ONC doesn't want to write brand new specs, they want to reuse existing work.

It's all got to fit together, and apparently the communications failure out of ONC is in part a result of trying to line up 10 different ducks in a row.  Not all of the contracts have been awarded, so it's a bit difficult to communicate about everything at once.

Uhuh.  This is project management 101 guys, and you need to learn to be agile too.  Agile means being able to change your tactics when the situation changes.  If you cannot manage that, how will you manage 10 different inter-related projects.  I don't need to go back over what a disaster the communications bottleneck was for the AHIC, HITSP, HISPC, NHIN and CCHIT projects was for the first couple of years under Bush's ONC?  Surely this ONC can do better than that

All in all, I feel better today than I did on Monday, although a few slides did give me some pause.  After digging into the slide that talked about "HHS creating a Health Information Model" it was clear that as one person put it "ONC poorly worded" this slide.  I understand their intent, HHS will fund a program to do it with industry and SDO input, begging, borrowing and reusing whatever they can.

There are a lot of places that NIEM hasn't been yet.  Web Services that don't use WSDL (e.g., DICOM), dealing with an industry that has a large installed legacy base, et cetera.  This is going to be a learning process for everyone.

OK, so better marks today than previously, and we are all learning as we go.  I hope Dr. Fridsma is a quick study.

HL7 to Offer Program on Standards for MeaningfulUse of EHR Technology at Annual Meeting

This crossed my desk this morning, which was right on time since I submitted the draft yesterday ;-)

This will be a great program for those of you in the Boston/Cambridge area on October 4th.  HL7 experts will be describing the 5 HL7 Standards selected for meaningful use.  I'll be speaking on CCD and CDA as you see below, and we've lined up experts and excellent speakers on the other HL7 standards.

     Keith

---

Health Level Seven® International

For Immediate Release

HL7 to Offer Program on Standards for Meaningful Use of EHR Technology at Annual Plenary and Working Group Meeting

          Ann Arbor, Michigan, USA – August 26, 2010 – Health Level Seven® International (HL7®), the global authority for interoperability and standards in healthcare information technology, today announced the speakers for their Ambassador program on Standards for Meaningful Use being held Monday, October 4, 2010 in Cambridge, MA.  This program qualifies for three Continuing Medical Education credits (CME) approved through the American College of Physicians and provides an overview of the HL7 standards used to achieve meaningful use under the new federal regulations.

          “As the healthcare industry is pushed forward to meet the meaningful use requirements under the ARRA-HITECH act, healthcare IT professionals and healthcare providers will have to work together to integrate computer systems and share patient data,” said Grant M. Wood, Senior IT Strategist at Intermountain Healthcare’s Clinical Genetics Institute in Salt Lake City, and host of the program.  “HL7 has solutions – from sharing lab data, to sharing summary data about a patient as they move from doctor to doctor, to even those who provide public health services like disease surveillance and immunization registries. This multi-topic session will help budding experts achieve this goal.”  

The program includes:

• HL7 and Meaningful Use by Gora Datta, Chairman and CEO, CAL2CAL Corporation.  Mr. Datta will provide an overview of what meaningful use requires, and how HL7 has been involved in the development of standards for meaningful use.
• HL7 Version 2 and Immunization by Alean Kirnak, President, Software Partners LLC; American Immunization Registry Association; Co-Chair, HL7 Public Health and Emergency Response Work Group.  Ms. Kirnak will describe the approaches to meeting Meaningful Use immunization registry reporting criteria using HL7 Version 2.  She will discuss the place of immunization registry reporting within the overall context of the meaningful use rule, as well as the potential future benefits to providers.
• HL7 Version 2 and Surveillance by Lori Reed-Fourquet, Consultant, eHealthSign, LLC and Anna Orlova, PhD, Executive Director, Public Health Data Standards Consortium Ms. Reed-Fourquet and Dr. Orlova will describe standards and approaches for meeting meaningful use requirements involving public health surveillance. They will discuss both provider and public health perspectives for bi-directional interoperable communications using multiple HL7-based messages, documents, and services.
• HL7 Version 2 and Electronic Lab Reporting by Austin Kreisler, Technical Fellow, SAIC; Co-Chair, HL7 Orders & Observations Work Group; Co-Chair, HL7 Domain Experts Steering Division; Member, HL7 Technical Steering Committee.  Mr. Kreisler will describe the relationship between meaningful use and the reporting of laboratory result data to public health agencies. This presentation will describe the various ways laboratory result data are utilized by public health agencies and show how HL7 standards are used to facilitate use of that laboratory data.
• HL7’s CDA and CCD Standards by Keith W. Boone, Standards Architect, GE Healthcare; Co-Chair, HL7 Clinical Document Architecture Work Group; Co-Chair, IHE Patient Care Coordination; past Co-Chair, ANSI/HITSP Care Management and Health Records.  Mr. Boone will describe the use of the HL7 CDA standard and CCD implementation guide to create clinical summaries and exchange health information between eligible providers and hospitals.  This session will also address the use of the HITSP C32 specification to the HL7 standards and guides.

The Ambassador Program event on HL7 and the final rule on standards for meaningful use will be held Monday afternoon immediately following the plenary meeting. For more information about this session, please visit http://www.hl7.org/events/boston102010/ambassador.asp. Additional tutorials providing more detail on HL7 standards for meaningful use, including HL7 Version 2, CDA Release 2 and CCD, are offered throughout the week.  For more information about HL7 tutorials, please visit http://www.hl7.org/events/boston102010/tutorials.asp.

          Online registration is now open. Early bird registration offers a discounted rate through September 10, 2010.  To register online, visit http://www.hl7.org/events/boston102010/.  Advance registrations will be accepted until September 24, 2010.  After September 24, 2010, registrations must be made on-site in Cambridge, MA. 

          HL7 Working Group meetings are held three times a year to provide its more than 40 work groups a chance to meet together to work on the standards and provide educational sessions for the healthcare IT community.

About Health Level Seven International (HL7)

Founded in 1987, Health Level Seven International is the global authority for healthcare Information interoperability and standards with affiliates established in more than 30 countries. HL7 is a non-profit, ANSI accredited standards development organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. HL7’s more than 2,300 members represent approximately 500 corporate members, which include more than 90 percent of the information systems vendors serving healthcare. HL7 collaborates with other standards developers and provider, payer, philanthropic and government agencies at the highest levels to ensure the development of comprehensive and reliable standards and successful interoperability efforts.

HL7’s endeavors are sponsored, in part, by the support of its benefactors: Abbott; Accenture; Booz Allen Hamilton; Centers for Disease Control and Prevention; Duke Translational Medicine Institute (DTMI); Eclipsys Corporation; Epic Systems Corporation; European Medicines Agency; the Food and Drug Administration; GE Healthcare Information Technologies; GlaxoSmithKline; Intel Corporation; InterSystems Corporation; Kaiser Permanente; Lockheed Martin; McKesson Provider Technology; Microsoft Corporation; NHS Connecting for Health; NICTIZ National Healthcare; Novartis Pharmaceuticals Corporation; Oracle Corporation; Partners HealthCare System, Inc.; Pfizer, Inc.; Philips Healthcare; Quest Diagnostics Inc.; Siemens Healthcare; St. Jude Medical; Thomson Reuters; the U.S. Department of Defense, Military Health System; and the U.S. Department of Veterans Affairs.

Numerous HL7 Affiliates have been established around the globe including Argentina, Australia, Austria, Brazil, Canada, Chile, Colombia, Croatia, Czech Republic, Finland, Germany, Greece, Hong Kong, India, Italy, Japan, Korea, The Netherlands, New Zealand, Norway, Romania, Russia, Singapore, Spain, Sweden, Switzerland, Taiwan, Turkey, United Kingdom, and Uruguay.

For more information, please visit: http://www.hl7.org/

# # #

The definition of Transparency is apparently Invisibility

Recently I ran into a friend who has some knowledge of the Standards Harmonization contract solicted under task order 10-233-SOL-00072 to HHS.  He told me that Deloitte has been awarded the contract (as of August 12th according to FedBizOps.gov).

According to the solicitation:  The purpose of this requirement is to obtain Contractor support services to harmonize standards and interoperability specifications to achieve ubiquitous implementation of standards, promote wider use of standards, and increased level of interoperability across the nation in health information technology (HIT). The overall purpose of the Office of the National Coordinator for Health Information Technology (ONC) programs is to facilitate and expand the secure, electronic movement and use of health information among organizations according to nationally recognized standards.


So is anyone else worried that we [members of healthcare SDO's and Standards Profiling organizations] haven't heard anything about this?

Final Meaningful Use Rules Published

The final rules have been published in the Federal Register (Thanks to Robin again for these links).

• Final Rule – CMS EHR Incentive Program 
• Final Rule – ONC Standards and Certification Final Rule (my commentary on this rule)

Robin's bookmarked versions will be posted as soon as I get them. 

If you are looking for my commentary on these rules, my thoughts on the Incentive Rule and my Summary of the standards and certification rule are also readily accessible.

NOTE: The commentary about support for SNOMED CT for procedures in the Standards Rule STILL doesn't match the regulatory text as I mentioned earlier.  Remember that it is the regulation that counts, not the explanatory text.

And the next Ad Hoc Motorcycle Guy Harley Award goes to...

About the award

The rules of who gets the Ad Hoc Motorcycle Guy Harley award are completely arbitrary. There is no nominating committee, although nominees are always welcome. The bar to recognition is fairly high if the first and now second recipients are any evidence.  I hope to maintain the quality of recipients in subsequent awards. I wont' award more than one a year for the same type of industry service, and I expect to award no more than five a year.

 

This next awardee must have been either a school teacher or a librarian in a former life.  She wades tirelessly through mounds of paper making sense of it in amazing infographics.  She's plowed through at least the equivalent of a carton of paper making sense of specifications from numerous SDOs, most recently turning her attention to the Meaningful Use Regulation.

 

This certifies that

Robin Raiford of Eclipsys

 

 

Has hereby been recognized for outstanding contributions to the forwarding of Healthcare Standardization

 

Robin, congratulations and thank you for all your many years of service making it easier to understand mounds of paper.  You should also get an award for paper conservation, but that's not my arena.  My thanks also goes to Robin's employer, Eclipsys, who kindly makes her time available to do this work.

 

---

 

Why is Robin getting this award? If you've seen any of her bookmarked copies of the MU rules, or any of the previously released  HITSP cross-reference matrices, you'll get it.  Here are some links to her latest work posted by John Halamka and also distributed to the EHRA today.

• Meaningful Use Core and Menu Set Objectives and Measures
• Standards cross referenced to the Code of Federal Regulations Citations

As Robin said about these in her last e-mail:

Please feel free to distribute widely on every blog, list, web whatever to get this info out there so we are all not doing the same thing – getting to the bottom of what we need in “the system shall” statements. I also redid the 2 page MU quick facts with a watermark “for informational purposes only”. Post away so some consultant does not get rich doing this.

BTW:  Given that my first post on the MU standards is still gettting about 40 hits a day even a two weeks later, I'm posting a link to this page there.

---

January 16, 2011
She's at it again. Here are the bookmarked final rules from 2010 and January 2011 which are available in Google Docs for viewing or download

• ONC Standards Final Rule
• ONC Permanent Certification Program Final Rule
• CMS Meaningful Use Incentives Final Rule

Moving from C32 Version 2.3 to 2.5

Updated 12/15/2010 to provide an example for uncoded, and added examples for value elements. 

---

Just for fun, I'm going to pretend that you have ignored my recommendation to use HITSP C32 Version 2.5, and are using an older version, like C32 Version 2.3. Maybe you had 2.3 already implemented, and were waiting to see what happened to meaningful use before you piled on more work. So, now you want to know what you need to do to make the switch?

Moving to V2.4

Fortunately, it's not really all that difficult. Between version 2.3 and version 2.4, the big change was the introduction of C83 (CDA Content Modules) and the harmonization of HITSP Section and Entry templates across HITSP Components. Some HITSP specifications (like C28, C38 and C48) used IHE Profiles, others (like C84) used Health Story/HL7 Implementation Guides, and others (like C32), just used straight CCD. Making the shift between Version 2.3 and 2.4 was basically a matter of replacing the ...88.11.32.xx template identifiers with the ...88.11.83.yy template identifiers (where xx == yy in almost all cases), and adding a few IHE template identifiers. Here are the major changes you need to make:

In the CDA Document

Where you had:

‹ClinicalDocument ...›
   ‹templateId root='2.16.840.1.113883.3.88.11.32.1 '/›
   ‹templateId root='2.16.840.1.113883.10.20.1 '/›

You would add the following:

‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.6'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.2'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.1'/›
   ‹templateId root='2.16.840.1.113883.10.20.3'/›

In the CDA Header

Where you had...

‹languageCommunication›
   ‹templateId root='2.16.840.1.113883.3.88.11.32.2'/›

Add...

‹templateId root='2.16.840.1.113883.3.88.11.83.2'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.1'/›

Note: You could remove the template 2.16.840.1.113883.3.88.11.32.2, but need not, and this pattern follows throughout for the 88.11.32.xx templates.

Where you had...

‹participant...›
   ‹templateId root='2.16.840.1.113883.3.88.11.32.3'/›

Add...

‹templateId root='2.16.840.1.113883.3.88.11.83.3'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.4'/›

Where you had...

‹performer...›
   ‹templateId root='2.16.840.1.113883.3.88.11.32.4'/›

Add...

‹templateId root='2.16.840.1.113883.3.88.11.83.4'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.3'/›

In Sections

For each of the sections below, add the specified templates to either the section or the entry

Section Name	In this CCD Section	Add these Section Templates	In this C32/CCD Entry	Add these Entry Templates
Insurance Providers	2.16.840.1.113883.10.20.1.9	2.16.840.1.113883.3.88.11.83.101.1 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.7	2.16.840.1.113883.3.88.11.32.5 2.16.840.1.113883.10.20.1.20	2.16.840.1.113883.3.88.11.83.5.1 1.3.6.1.4.1.19376.1.5.3.1.4.17
Allergies	2.16.840.1.113883.10.20.1.2	2.16.840.1.113883.3.88.11.83.102 1.3.6.1.4.1.19376.1.5.3.1.3.13	2.16.840.1.113883.3.88.11.32.6 2.16.840.1.113883.10.20.1.27	2.16.840.1.113883.3.88.11.83.6 1.3.6.1.4.1.19376.1.5.3.1.4.5.3
Problems	2.16.840.1.113883.10.20.1.11	2.16.840.1.113883.3.88.11.83.103 1.3.6.1.4.1.19376.1.5.3.1.3.6	2.16.840.1.113883.3.88.11.32.7 2.16.840.1.113883.10.20.1.27	2.16.840.1.113883.3.88.11.83.7 1.3.6.1.4.1.19376.1.5.3.1.4.5.2
Medications	2.16.840.1.113883.10.20.1.8	2.16.840.1.113883.3.88.11.83.112 1.3.6.1.4.1.19376.1.5.3.1.3.19	2.16.840.1.113883.3.88.11.32.8 2.16.840.1.113883.10.20.1.24	2.16.840.1.113883.3.88.11.83.8 1.3.6.1.4.1.19376.1.5.3.1.4.7
Product			2.16.840.1.113883.10.20.1.53	2.16.840.1.113883.3.88.11.83.8.2 1.3.6.1.4.1.19376.1.5.3.1.4.7.2
Advance Directives	2.16.840.1.113883.10.20.1.1	2.16.840.1.113883.3.88.11.83.116 1.3.6.1.4.1.19376.1.5.3.1.3.35	2.16.840.1.113883.3.88.11.32.13 2.16.840.1.113883.10.20.1.17	2.16.840.1.113883.3.88.11.83.12 1.3.6.1.4.1.19376.1.5.3.1.4.13.7
Immunization	2.16.840.1.113883.10.20.1.6	2.16.840.1.113883.3.88.11.83.117 1.3.6.1.4.1.19376.1.5.3.1.3.23	2.16.840.1.113883.3.88.11.32.14 2.16.840.1.113883.10.20.1.24	2.16.840.1.113883.3.88.11.83.13 1.3.6.1.4.1.19376.1.5.3.1.4.12
Vital Signs	2.16.840.1.113883.10.20.1.16	2.16.840.1.113883.3.88.11.83.119 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2	2.16.840.1.113883.3.88.11.32.15 2.16.840.1.113883.10.20.1.31	2.16.840.1.113883.3.88.11.83.14 1.3.6.1.4.1.19376.1.5.3.1.4.13.1
Result	2.16.840.1.113883.10.20.1.14	2.16.840.1.113883.3.88.11.83.122 1.3.6.1.4.1.19376.1.5.3.1.3.28	2.16.840.1.113883.3.88.11.32.16 2.16.840.1.113883.10.20.1.31	2.16.840.1.113883.3.88.11.83.15.1 1.3.6.1.4.1.19376.1.5.3.1.4.13
Procedures	2.16.840.1.113883.10.20.1.12	2.16.840.1.113883.3.88.11.83.108 1.3.6.1.4.1.19376.1.5.3.1.3.12	2.16.840.1.113883.10.20.1.29	2.16.840.1.113883.3.88.11.83.17 1.3.6.1.4.1.19376.1.5.3.1.4.19
Encounters	2.16.840.1.113883.10.20.1.3	2.16.840.1.113883.3.88.11.83.127 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3	2.16.840.1.113883.3.88.11.32.17 2.16.840.1.113883.10.20.1.21	2.16.840.1.113883.3.88.11.83.16 1.3.6.1.4.1.19376.1.5.3.1.4.14
Comment			2.16.840.1.113883.3.88.11.32.12 2.16.840.1.113883.10.20.1.40	2.16.840.1.113883.3.88.11.83.11 1.3.6.1.4.1.19376.1.5.3.1.4.2

Moving to V2.5

The major change affecting C32 going from version 2.4 to 2.5 were modifications supporting the meaningful use code sets. If you had already supported the HITSP code sets use in C32 Version 2.3, this didn't really effect you as a producer. As a consumer of C32 Version 2.5, there was a significant change related to coded content. For many of the C32 entries, there was one and only one allowed code system, and if you included the ‹code› element, you used the required code system. In Version 2.5 the requirements were clarified. There are two ways to use ‹code› or the CD data type in ‹value›

1. Coded data using required vocabularies.
   In this case, the code and codeSystem attributes are required on ‹code› and contain the codes in the required code set. So, for problems, if you used SNOMED-CT, you'd do something like the following:
   

   ‹code code='57054005' codeSystem='2.16.840.1.113883.6.96'/›
   ‹value xsi:type='CD' code='57054005' codeSystem='2.16.840.1.113883.6.96'/›

2. Coded using other than required vocabularies
   In this case, the nullFlavor attribute is required. If coded using other than the required vocabulary, the alternate code goes in ‹translation›, and the code and codeSystem attributes of the ‹translation› identify the code using an alternative coding scheme.  And if you used ICD-9-CM for problems, you'd do something like the following:
   

   ‹code nullFlavor='UNK'›
     ‹translation code='410.9' codeSystem='2.16.840.1.113883.6.103'/›
   ‹/code›
   ‹value xsi:type='CD' nullFlavor='UNK'›
   ‹translation code='410.9' codeSystem='2.16.840.1.113883.6.103'/›
   ‹/value› 

3. Not coded at all again requires nullFlavor:
   

   ‹code nullFlavor='UNK'/›
   ‹value xsi:type='CD' nullFlavor='UNK'/›

Which brings us to the final table of this post, which tells you what OIDS to use and where to put the codes you are using:

Coded Item	Vocabulary	OID	Code/Translation
Problems	SNOMED CT	2.16.840.1.113883.6.96	C
	ICD-9-CM	2.16.840.1.113883.6.103	T
Medications	RxNORM	2.16.840.1.113883.6.88	C
	NDC	2.16.840.1.113883.6.69	T
	MDDB (Medispan)	2.16.840.1.113883.6.162	T
	MMSL (Multum)	2.16.840.1.113883.6.175	T
	NDDF (First DataBank)	2.16.840.1.113883.6.208	T
	MMX (MicroMedex)	2.16.840.1.113883.6.176	T
	MSH (MeSH)	2.16.840.1.113883.6.177	T
	NDFRT (VHA National Drug File)	2.16.840.1.113883.6.209	T
	SNOMED CT	2.16.840.1.113883.6.96	T
Lab Tests	LOINC	2.16.840.1.113883.6.1	C
Procedures	CPT-4*	2.16.840.1.113883.6.12	C**
	ICD-9-CM	2.16.840.1.113883.6.104***	C**

Notes:
^*HCPCS is made up of CPT-4 and several other vocabularies. This is just the OID for CPT-4, I'm still digging into the remainder.
^**C32 Version 2.5 does not have a preferred vocabulary for procedures, so any code system can be used in the code element
^***ICD-9-CM Procedures uses a different OID than ICD-9-CM Diagnoses, this is NOT a mistake

Warning: These aren't necessarily all of the changes that you will need to make to your application, but it does cover the largest ones.

Another Oops in MU Rule Text?

It's a good thing the ink is still drying on the final rule text for meaningful use.  Robin Raiford is an extremetly detail oriented person who also does some of the best chartography making send of meaningful use, standards, and all the rest that I know.  Robin reports in a widely distributed e-mail that:

While gathering data for the poster and validating the dots were all correct – I have found 7 errors in Table 3 of the CMS final rule in the table layout.


If you read the text close, they kind of jump right out at you. In table 3 there are 7 items that have “unique patient” in the description of the measure and they are grouped in that portion of the table under “Measures with a Denominator of Unique Patients Regardless of Whether the Patient’s Records Are Maintained Using Certified EHR Technology”, rather than with the “unique patients” denominator items . My dots in the poster were not lining up exactly – and I discovered I had placed them using the text – not the table. So that is how I found it.

I have passed this on to the Co-chairs of HIT Policy and HIT Standards and John Halamka has passed on to Tony Trenkle at CMS for comment. So either there are two meanings for “unique” or something is in the wrong place in Table 3. So stay tuned how CMS resolves or makes it know their intent. Since one has Denominator of UNIQUE PATIENTS Regardless of Whether the Patient’s Records Are Maintained Using Certified EHR Technology and the other Measures with a Denominator of Based on Counting ACTIONS for Patients whose Records are Maintained Using Certified EHR Technology Stage 1 Objectives – this has HUGE implications for the ED and those 11 measure that include POS 23 and POS 21.

As I learn more, I'll post it here.  Thanks Robin, and keep up the goodGREAT work!

     Keith

Where is the XSD for CCD?

This is a question that shows up in various places quite a bit. People who are familiar with mainstream XML development want a schema to support conformance to all of the constraints of an XML implementation.

The CCD is a specialization of the CDA specification, for which you can find schemas. These schemas are available from HL7. If you are already an HL7 member, you can get them for free.  If not already a member, you can purchase them from the HL7 store (The CDA standard and CCD implementation guide will set you back $50.00 each).

Why isn't there a schema jsut for CCD?  The W3C Schema standard just isn't able to solve this particular problem.  To make a long story short, XML descends from SGML.  One of the requirements in SGML for DTDs which made its way into XML and subsequently the XML Schema specification was implementation simplicity in parsing tags.  This means that schemas are not permitted to use any look-ahead to determine the type of an element.  They can only look at the element name.  The problem comes into play when you need to distinguish between for example, a problem, and a result.  Both of these use the observation element of the CDA, with differing requirements on what appears inside.  But, the element has the same name, and so cannot have different requirements according to the W3C schema specification.  Another example that W3C schema doesn't support very well are co-occurence constraints.  These are constraints that say if A is X, then B must be Y.  These kinds of contraints are very difficult to model in W3C schema (yeah, I know, it can be done using certain features, but those are the very same features that often break, or aren't supported in schema driven persistence models).

In the contest between the information modeling perspective which says that these two things carry many of the same semantics, and the business viewpoint which says that there are different rules that apply, something has to give.  The HL7 XML ITS says that the information model, which ensures semantic interoperability, is paramount, not the business viewpoint which imposes these different constraints.  After all, semantic interoperability has been the Holy Grail that we've all been persuing, right?

All is not lost (especially if you code in Java).  The Model Driven Healthcare Tools project (MDHT) from Open Health Tools has a great deal of support for CDA, the CCD, IHE XPHR and the HITSP C32 specifications.  Those of you using .Net might be a bit stuck.  I encourage you to participate in the MDHT work, because there is a definite need for EMF driven .Net code generation tools here.

HL7 Responds to Meaningful Use

Health Level Seven® International
For Immediate Release       
Contact: Andrea Ribick
+1 (734) 677-7777
andrea@HL7.org

Meaningful Use Standards Final Rule Names Five HL7 Standards and Implementation Guides

Version 2.5.1 Implementation Guide for Electronic Laboratory Reporting to Public Health Now among HL7 Publications Needed for Meaningful Use

          Ann Arbor, Michigan, USA – July 19, 2010 – Health Level Seven® International (HL7®), the global authority for interoperability and standards in healthcare information technology, today announced that five of its standards and guides will be used in the U.S. final rule on standards and certification criteria for meaningful use.
The interim final rule published in January of this year included:

• HL7 Version 2.5.1 for the submission of lab results to public health agencies.
• HL7 Version 2.3.1 or Version 2.5.1 for submitting information to public health agencies for surveillance or reporting (excluding adverse event reporting).
• HL7 Version 2.3.1 or Version 2.5.1 for submitting information to immunization registries as the content exchange standard and the CDC maintained HL7 standard code CVX—Vaccines Administered as the vocabulary standard.
• HL7 Clinical Document Architecture, Release 2 (CDA) Continuity of Care Document (CCD), a Version 3 standard based on the HL7 Reference Information Model, as one of two options for content exchange standards for the receipt of a patient summary record.

In addition, the final rule now includes the HL7 Version 2.5.1 Implementation Guide for Electronic Laboratory Reporting to Public Health when HL7 Version 2.5.1 is used for reporting lab results to public health agencies.

HL7 Members are Heard by ONC
In March, HL7 published comments on the Interim Final Rule on Standards.  As a result of feedback from HL7, its members and others in the healthcare industry, a number of changes important to HL7 members were made to that rule.

Overlaps and Inconsistencies with Previously Selected Standards Are Reduced
HL7 recommended that ONC provide clarification on overlaps and inconsistencies between standards required for use in Federal Agencies under Executive Order 13410 and standards that had been previously recognized under this order.  The final rule incorporates many more of the implementation guides that had been previously recognized by HHS as requirements, including the ANSI/HITSP C32 Version 2.5 implementation guide.  These changes greatly reduce the number of inconsistencies and overlaps between the final rule and Executive Order 13410.

Implementation Guidance Has Been Added
HL7 recommended that the Final Rule provide more implementation guidance.  The new rule incorporates implementation guidance for Immunizations using HL7 2.3.1 or HL7 2.5.1, use of the Continuity of Care Document using the HITSP C32 Version 2.5 specification, guidance for public health reporting using HL7 2.5.1 developed by the Public Health Information Network, and for laboratory to public health using the recently approved HL7 Version 2.5.1 Implementation Guide for Electronic Laboratory Reporting.

Transport Standards Inconsistencies Eliminated
HL7 recommended that the transport standards section be altered to accommodate the use of the selected HL7 standards.  The final rule does not make any recommendations for transport.

Description of CCD Improved
HL7 observed that the description of CCD in the Interim Final Rule was inaccurate.  The interim final rule described CCD as being a Level 2 implementation guide of CDA.  CCD supports both structured narrative (Level 2) and coded data (Level 3).  ONC corrected these errors.  Furthermore the selection of the HITSP C32 Version 2.5 Specification for implementation guidance means that CCD documents exchanged for meaningful use will contain coded data (Level 3).

Use of Appropriate Standards for Discharge Summaries
HL7 pointed out that Discharge Summaries require content that is not described or supported in the CCD.  ONC acknowledged that Discharge Summary documentation can be separated from the content of the CCD, but did not select an alternative standard for them.

Use EHRs for Clinical Purposes
HL7 recommended that the text in the Interim Final rule which required use of the EHR to perform eligibility and claims transactions be removed, as this is inconsistent with EHR systems as described by the HL7 EHR Functional Model.  The final rule removes the requirement for the EHR to perform claims or eligibility transactions.

“The final rule on standards for meaningful use will improve the potential for interoperable exchange between healthcare providers.  HL7 and its members are proud to have been a contributor to this historic regulation,” said HL7 CEO Charles Jaffe, MD, PhD. “The HIT Standards Committee deserves our gratitude for this significant achievement. We must continue to advance the vision of the committee if we hope to reach the goal of improving the care of our patients.”
          For more information, please visit the HL7 website at http://www.hl7.org/. HL7 International members may download copies of the standards and implementation guides for free. Nonmembers may purchase them at http://www.hl7.org/.

About Health Level Seven International (HL7)
Founded in 1987, Health Level Seven International is the global authority for healthcare Information interoperability and standards with affiliates established in more than 30 countries.  HL7 is a non-profit, ANSI accredited standards development organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. HL7’s more than 2,300 members represent approximately 500 corporate members, which include more than 90 percent of the information systems vendors serving healthcare. HL7 collaborates with other standards developers and provider, payer, philanthropic and government agencies at the highest levels to ensure the development of comprehensive and reliable standards and successful interoperability efforts.
HL7’s endeavors are sponsored, in part, by the support of its benefactors: Abbott; Accenture; Booz Allen Hamilton; Centers for Disease Control and Prevention; Duke Translational Medicine Institute (DTMI); Eclipsys Corporation; Epic Systems Corporation; European Medicines Agency; the Food and Drug Administration; GE Healthcare Information Technologies; GlaxoSmithKline; Intel Corporation; InterSystems Corporation; Kaiser Permanente; Lockheed Martin; McKesson Provider Technology; Microsoft Corporation; NHS Connecting for Health; NICTIZ National Healthcare; Novartis Pharmaceuticals Corporation; Oracle Corporation; Partners HealthCare System, Inc.; Pfizer, Inc.; Philips Healthcare; QuadraMed Corporation; Quest Diagnostics Inc.; Siemens Healthcare; St. Jude Medical; Thomson Reuters; the U.S. Department of Defense, Military Health System; and the U.S. Department of Veterans Affairs.
Numerous HL7 Affiliates have been established around the globe including Argentina, Australia, Austria, Brazil, Canada, Chile, China, Colombia, Croatia, Czech Republic, Finland, France, Germany, Greece, Hong Kong, India, Italy, Japan, Korea, The Netherlands, New Zealand, Romania, Russia, Singapore, Spain, Sweden, Switzerland, Taiwan, Turkey, United Kingdom, and Uruguay.

# # #

Robin's Eggs

Easter eggs are those little nuggets in software applications the provide a cool little extra to the user. Robin Rainford provides her little nuggets as bookmarked editions of the PDF versions of the final rules.

 

Thanks to John Halamka for making them available on the web:

• Incentives
• Standards

How to use HITSP C32 Version 2.5 for Meaningful Use

David Tao asks an excellent question:

---

Keith, re C32 v2.5, it points to HITSP C83 and C80. I THINK that v2.0 of those documents (published January 2010) is appropriate to use, but the FR is not specific about that, and I know that some people assume that C83/C80 v1.1 (published July 2009) are the appropriate versions. I hope NIST will clarify this soon, but do you have a recommendation and have you had any conversations with ONC or NIST about that?



Thanks,


David

---

David,

I KNOW that those are the appropriate documents to use.  Those are the specifications that support meaningful use with C32.  If you tried to use the meaningful use vocabularies with earlier versions, you'd be in trouble because those versions don't support it.  The C83 Version 2.0 specification was written after the interim final rule was published and modified accordingly to support it. 

     Keith

Race and Ethnicity in Meaningful Use

Today a question crossed my desk about the vocabulary terms to support Race and Ethnicity specified in the Meaningful Use Standards rule and in the Incentives rule.  In short, the question was, what are the code values that I need to use to specify race and ethnicity.

The rules didn't say.  Instead, they reference an OMB directive that tells you the high level concepts that your terminology has to roll up to.

If you are looking for a terminology that works, look at the CDC Race and Ethnicity vocabulary.  This is THE vocabulary that is specified in the HITSP C32 Version 2.5 specification for how to use the CCD, and is the common vocabulary that appears in many other HITSP specifications.  You can utilize a value set just supporting the short list of OMB mandated categories, or you can drill down into more details.

Some states (such as Massachusetts), have mandated a deeper level of reporting for these concepts.  The CDC vocabulary supports that level of detail and yet remains consistent with the OMB guidelines.

     Keith

BTW:  I made comments on these rules that they should be consistent with OMB guidelines.  I'm pleased to see those comments adopted in the final rules.

Summary of Meaningful Use Incentives Changes

I finished my review of the Meaningful Use Incentives rule. My review was focused specifically on how the measures in that rule are tied to the standards rule (which I reviewed yesterday here), and so I only had to read about 250 of the 864 pages. I specifically did not cover quality measures, or many of the administrative details.  I also do not go into detail on the percentage measure revisions, or into the quality measures.  If you are looking for other details such as these, I recommend that you read the article in the New England Journal of Medicine, John Halamka's summary, Inga (HISTalk's) summary, or many of the other summaries available on the web.

Note that page numbers in the text below are from the PDF on display and will not correspond to the page numbers when these are finally published in the Federal Register:

• Definitions of Certified EHR Technology and Qualified Electronic Health Record in this rule are the same as, and therefore reference the definitions of those terms in the Standards Rule (see Page 22).
• You can stop being a meaningful user in the middle, and resume where you left off (see page 24 through 26), up until 2015. After that, all bets are off.
• Your first reporting period is 90 days long in your first reporting year (page 28), and you start at the Stage 1 criteria for two years, then move to Stage 2 criteria (page 39). After 2014, it isn’t indicated what will be done about getting everyone to the same level of meaningful use, but that is the stated goal.
• States are not allowed to request more stringent criteria than what can be certified in Stage 1. If you are a vender of an EHR product, you should consider certifying for optional criteria, because states would be allowed to require it for Medicaid users (page 50). Even so, if a hospital is eligible under Medicare, then it is deemed to be Medicaid eligible, even if its EHR technology does not support additional state requirements (also page 50).
• The rule takes the approach that there are core measures which must be implemented by all, some core measures which must be implemented by all EPs, others which must be implemented by all Hospitals, and then a menu of other requirements of which some number are required to be implemented. Therefore, the incentives are no longer a set of all-or-nothing requirements. From an EHR product perspective, products will probably need to support more of the “menu” requirements because different users of those products will want to select different requirements from the “menu”.
• Some requirements may not be applicable to a provider. Failure to meet these requirements will not go against the providers eligibility for incentive payments. However, note that the Incentives rule indicates which requirements are permitted to be treated this way (page 61 to 62).
• The incentive eligibility has been linked to the standards rule in many places. The phrase “We further specify that in order to meet this objective and measure, [EP/Hospital/CAH] must use the capabilities Certified EHR Technology includes as specified and standards at 45 CFR 170.3XX(x).” Basically, this phrase says that to be eligible, you must use the Certified EHR Technology to meet the objective and not some other technology, and that you must do so in the way specified by the standards identified in the certification criteria.
• Because eligibility and claims are no longer certification criteria in the Standards Final Rule, they are also no longer required to be used to obtain incentive payments.
• The NPRM required tracking of “Insurance Type”. However, given that there are no established standards to identify types of insurance, the requirement to track this information for patients was removed from the Incentives rule.
• The NPRM required tracking of Race and Ethnicity. The final incentives rule clarifies that this tracking should be consistent with OMB guidance for gathering information about race and ethnicity. See yesterday’s post in the Standards rule for a link to those guidelines.
• Hospitals must capture whether or not an advance directive is available for patients over 65. This is a new requirement for the Incentives rule.
• The use of Clinical Decision Support in the NPRM required implementation of 5 rules. This was reduced to 1 rule so that implementations could focus on good implementation of clinical decision support. The description of clinical decision support has been modified to avoid bad examples.
• In cases where providers are required to either give patients data, or make it accessible online, the time frames have been altered. Instead of 2 or 4 days, they have been changed to business days (Monday through Friday excluding Federal and State holidays), and in one case, increased from 2 to 3 days (See page 161 and 175). In addition, it was indicated that it is not appropriate to charge patients for clinical summary provided for an office visit (Page 179) since that would be enabled by the Certified EHR Technology and should be of minimal expense to the provider (Hit the print button…)
• Some measures included a required test (e.g., for reporting information to public health for surveillance, immunizations or lab results; or electronic exchange of data with other providers). For these measures, the test need not include actual patient data, but could use test data. Also, the test need not be “successful”. On this, my advice would be to show appropriate due diligence in your attempts to ensure that the test passes.

Finally, my last comment is simply to reiterate in my own words what I found on page 219.

Meaningful Use will not be cancelled. It is law. The regulation implements what is already required under law. For this, I’m not sorry!

Having plowed through the regulations in two days, I have to say that the final results are much improved over the original regulation text delivered earlier this year. I am pleased with the final results, and proud to have been a participant in this regulatory process. The rules are not perfect, but they are certainly good enough to provide for dramatic improvements in healthcare.