Changing Roles

Healthcare IT is different from other IT in that our customers typically operate 24/7. Thus, our maintenance windows are usually in the wee hours of the morning. You cannot work on healthcare IT any other time.

I've been involved in these early morning sessions for eight years. In my new role as architect, I don't have any real work to do. But, old habits die hard. We performed a maintenance change to a customer's Master Patient Index (MPI) earlier this week. We were able to start that process shortly after 9pm, which is when the last clinic closed. I joined the bridge line and watched the webex as the team worked through the process. I recorded start and stop times for each of the steps in the process and produced a summary for leadership. Even though I wasn't actually at the keyboard doing the work, I felt that just being there and contributing one or two suggestions showed the team that I was part of the team.

This weekend, we are upgrading one of my sites and activating another. The window to perform this work begins at midnight on Sunday morning. I'll try to dial in and listen to progress. I work with a great team, so they will be successful.

ONC S&I Framework Face to Face Meeting in October

This arrived in my inbox yesterday.

I attended the first ONC S&I Framework Face to Face Meeting in DC back in June. I'm not sure that I will get to go to this one, but I will put in the request. I am one of the team leads for the CDA Implementation Guide Documentation Work Group.

Our next S&I Framework is just around the corner.

Make sure you mark your calendars so you don't miss these important working sessions.

See the attachment or contact us via email for more details.

We hope to see you in Arlington in October!

--
ONC October F2F Support Team

October-F2F-Support@siframework.org

S&I Framework F2F Meeting | October 18-19, 2011

Hyatt Regency Crystal City at Reagan National Airport

2799 Jefferson Davis Highway, Arlington, VA 22202

ONC S&I Framework F2F

Validating CDA Documents

I received sample CCD files from a trading partner. I ran their sample files against the NIST validator and the first file had over 50 errors against the base CDA schema. They had used the data type PQ for all results in the results section. Some of those results were not physical quantities. Like so:

<value unit="ML/MIN/1.73M2" value=">60" xsi:type="PQ"/>

<value unit="MIU/ML" value="<2" xsi:type="PQ"/>

<value unit="UNK" value="///" xsi:type="PQ"/>

<value unit="UNK" value="NOT DETECTED" xsi:type="PQ"/>

<value unit="UNK" value="Negative" xsi:type="PQ"/>

<value unit="UNK" value="neg" xsi:type="PQ"/>

There is a LOINC code for Serum Cholesterol. All of the codes were either "0" or "UNK".

I went in and manually fixed the data type errors.

This is invalid:

<value unit="UNK" value="neg" xsi:type="PQ"/>

"neg" is not a physical quantity. Send this as a code, instead.

This is correct:


<value xsi:type="CD" code="260385009" displayName="Negative" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/>

This is invalid:

<value unit="UNK" value="pos" xsi:type="PQ"/>

"pos" is not a physical quantity. Send this as a code, instead.

This is correct:

<value xsi:type="CD" code="10828004" displayName="Positive" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/>

This is invalid:

<value unit="UNK" value="NOT DETECTED" xsi:type="PQ"/>

"not detected" is not a physical quantity. Send this as a code, instead.

<value code="260415000" codeSystemName="SNOMED-CT" displayName="Not Detected" codeSystem ="2.16.840.1.113883.6.96" xsi:type="CD"/>

This is invalid:

<value unit="MIU/ML" value="<2" xsi:type="PQ"/>

"<2" is not a physical quantity. Use interval of physical quantity as the data type, instead.

This is correct:

<value xsi:type="IVL_PQ">
<high unit="MIU/ML" value="2"></high>
</value>

This is invalid:

<value unit="ML/MIN/1.73M2" value=">60" xsi:type="PQ"/>

">60" is not a physical quantity. Use interval of physical quantity as the data type, instead.

This is correct:

<value xsi:type="IVL_PQ">
<low unit="ML/MIN/1.73M2" value="60"></low>
</value>

There are many undefined codes in the document. These need to be provided.

<code code="0" codeSystem="2.16.840.1.113883.6.12" codeSystemName="CPT-4" displayName="UNK">

<code code="UNK" codeSystem="2.16.840.1.113883.5.83" displayName="HDL CHOLESTEROL"/>

I asked the HL7 Structured Documents mailing list how they would deal with this document. Some vendors got defensive. It was an interesting exchange.



RIP:Google Health

Google made an announcement last week that they are discontinuing Google Health.

As we just announced in the Official Google Blog, we will be discontinuing the Google Health service and platform over the next several months. For more context around this announcement, please check out our blog post.

Many folks in HIT have commented on this. Here is my two cents.

I created a Google Health account while taking a class in my Medical Informatics program. It seemed ok, but I was really not sure what to do with it. I am healthy and do not visit doctors unless something breaks, so I could not really find a use for it. The only data in there was information that I keyed in.

Google Health hitched their wagon to CCR and not CCD which seems to me to be a big mistake.

So, Google slinks off, tail between its legs. They thought that they could "fix" healthcare. They ended up building a product that people did not think was useful.

The most insightful comment that I read was:

... and nothing of value was lost.

Using an HIE to Stalk a Patient

One of my state-wide HIE clients asked me the following question:

A battered woman moves from CityA to CityB and she doesn’t want her husband to find her so she opts out of the exchange. The woman seeks medical attention from a doctor in CityB. The doctor sends the woman’s new address to the exchange. Can a doctor who treated the woman in CityA see her new address or will the doctor only see the CityA address they have on file for the woman?

This one initially threw me for a loop. The purpose of an exchange is to allow doctors to see updated information on their patients. This state has a strong “opt out” policy that does not allow information to be exchanged if the patient has “opted out.” In the above use case, the patient has “opted out”, so we would not share clinical information. This state does not allow a provider to “break the glass” to override the patient’s decision to not share their information.

I think that we can configure the relationship between the Master Patient Index (MPI) and Clinical front end to prohibit the updated demographics from flowing from the MPI to the clinical system when the patient has “opted out” of data sharing.

The curious case here is that the patient would have to be stalked by either a doctor that had treated her previously, or a friend of a doctor that had treated her previously that was willing to violate HIPAA and share that information with the stalker. The real world is such a complex place that I am fairly certain that this will happen.

The bottom line is that technology is not foolproof and relies on policy and the law. Technology implements policy. If a user is willing to abuse the system and/or violate the law, they can do some unpleasant things.

This is certainly a use case that I had not considered.

CDA IG Consolidation Ballot Reconciliation

The ballot for the ONC S&I Framework Consolidated CDA IGs closed earlier this month. The response was overwhelming.

There were a total of 554 comments submitted. Of these, 277 were negative.

The HL7 ballot process requires that all negative comments be addressed, resolved and withdrawn by the submitters. So, there is a lot of work to be done before the consolidated guides are approved. This is important, because the ONC would like the consolidated guides to be used for Meaningful Use Stage 2.

The HL7 Structured Documents Working Group (SDWG) resolved 56 negatives during the Orlando Working Group meeting.

A number of the negative votes are publishing related, and we will begin looking at these during today's CDA Documentation call.

Reconciliation will continue to take place on the two ONC calls on Tuesday and Wednesday and during the regular HL7 SDWG call on Thursdays.

I hope to map out a strategy for getting the final Consolidated Guides published using MDHT. We will start that work and not wait for reconciliation to be completed.

It should be a busy summer.

The ONC S&I Framework teams will meet next month in Washington, DC for two days and we hope to get more work done then.

First Week

I have had an exciting first week at my new job. It is a hectic environment, so I may be dragged into a meeting without any notice. Either someone will drop by my cube and ask me to join them, or I will receive an electronic meeting invitation ten minutes after the meeting started. It is not unusual to find that I have been "double booked." I've worked in similar environments before, and so far, I have managed to keep up.

I don't have my work email and calendar sync'd up to my Blackberry, yet, so I occasionally miss a meeting. I've submitted a request to have that done, so that should be taken care of in a few days.

I'm reviewing project proposals prior to our submitting a response. These are all for technologies that I have worked with, so I know what to look for. I've read proposals for three state-wide HIEs, and at least one for a regional HIE. It looks like I should be a part of the project teams for most of those.

I am being asked to consult existing project teams to explain technical options to them.

I've written use case narratives that will be handed off to developers.

I am getting better at finding my car in the parking structure after work. The first couple of days, I wandered around for five minutes or so before locating my car. I think that I have that figured out, now.

It has been a good week. I am looking forward to my second week.

What is a Null Flavor and How is it Used?

I wrote this for the ONC CDA IG Consolidation project. Well, actually Keith Boone rewrote the first paragraph.

IT solutions are designed to store and manage data, but sometime we do not have the data for various reasons. Typically, in these cases, a special value, known as NULL is stored. There may be several reasons why the data isn’t available. In some cases, it may not be available or known, in others, it is not relevant, and in others it may not be computable or measurable. In HL7, these different reasons for why the data isn’t available are described as the flavor of NULL. This supports the management of the missing data. Let’s look an example.

If a patient arrives at an Emergency Department unconscious and with no identification, the system would represent the lack of information by use of a null flavor. The patient’s birth date would be unknown and would be represented using a null flavor. In this case, the appropriate null flavor would be “NAV” which is the code for “temporarily unavailable”. This information is not available, but is expected to be available later. In this example, when the patient regains consciousness or a relative arrives in the ER, we expect to know the patient’s birth date.

<birthTime nullFlavor=”NAV”/> /* coding an unknown birthdate */

Here is another example of using a null flavor for a patient who does not have a home phone.

<telecom nullFlavor=”NI” use="HP"/> /* coding a patient who does not have a home phone */

For those constraints that require the presence of an attribute that is unknown (SHALL be present with a cardinality of at least one (1..)), use a null flavor.

• NI = No Information. This is the most general and default null flavor.
• NA = Not Applicable. Known to have no proper value (e.g., last menstrual period for a male).
• UNK = Unknown. A proper value is applicable, but is not known.
• ASKU = asked, but not known. Information was sought, but not found (e.g., the patient was asked but did not know).
• NAV = temporarily unavailable. The information is not available, but is expected to be available later.
• NASK = Not Asked. The patient was not asked.

There are a handful of other codes. See the null flavor vocabulary table for the complete list.

A Document Interface

One of our trading partners is sending us clinical documents from their EHR system. These are plain text documents. The documents are being sent in HL7 v2.3 ORU^R01 messages.

They are sending us the document in a single OBX segment with line breaks in the OBX-5 field. I have seen other systems send each line in a separate OBX segment. I call that the "card punch" format, because each line of the report is on its own data card, just like the old days.

This is what one of the messages looks like:

MSH|^~\\&|DOC|K|DOC|WSUPG1|20110328082244||ORU^R01|Q1484927743T1489224997||2.3|||AL
PID|1|...
PV1|1|CD:123456||CD:9999|||0000000000^SMITH^ZACHARY|||...
ORC|RE||...
OBR|1||999999999|PROGN^Progress Note^^^xxx SICU Progress Note|||...
OBX|1|TX|PROGN^Progress Note||...NOTE GOES HERE~New Line~Another New Line||||||F|||20110328082242||

They are sending us the following document types (the left value is the code that I recieve, and the right side is the corresponding LOINC code):

DISCH^Discharge Summary ==> code="18842-5" displayName="DISCHARGE SUMMARIZATION NOTE"
PROGN^Progress Note ==> code="11506-3" displayName="Subsequent evaluation note"
HP^History and Physical ==> code="34117-2" displayName="History and Physical Note"
CONS^Consultation ==> code="11488-4" displayName="CONSULTATION NOTE"
OPRPT^Operative Report ==> code="11504-8" displayName="Surgical operation note"
ADMN^Admission Note ==> code="34862-9" displayName="Admission Evaluation Note"

The document type code appears in the OBR-4 field and the OBX-3 field. The project manager has me filtering out the H&P documents because they are not in scope for the first phase of the project. I added a filter to discard the H&P documents, and I will get to remove that later.

The only other interesting thing is that I have to look up the National Provider Identifier (NPI) for the providers in the PV1 segment. The remote system is sending us their provider ID, and we need the NPI to match on. So, I have a database look-up that retrieves the NPI and places that in the message. I am performing the look-up on the PV1-7 Attending Doctor, PV1-8 Referring Doctor and the PV1-9 Consulting Doctor fields. I then take whichever of these three fields has an NPI (and is therefore, one of our doctors) and place that value into PV1-7.

NextGen will match on PV1-7 and will place the document into the doctor's PAQ (Provider Approval Queue). The document was already signed by a doctor at the sending facility (unless it is a Progress Note, in which case it may be signed by a non-doctor), so our Doctor's are not really "approving" the document. This is just a way to ensure that our doctor's see the document.

NextGen will also add the document to the appropriate patient's chart.

We are doing some final testing on this interface before moving it into production.

PHI, HIPAA and Why Patients Should Worry

Sometimes, I despair.

People are worried that when we put their health information into EHR systems, it will be vulnerable to hackers. They worry that anybody will be able to see their medical records. The large hospital systems that I work with are fairly well protected. Their security personnel are well trained professionals who take their jobs seriously. They ensure that technical controls and process controls are in place to secure their systems and the data that is contained in them.

But a system is only as secure as its weakest link.

Today, I got an email asking me to set up an interface with an external trading partner. It's a simple, file based interface. I just need to go out to an external ftp site, pick up a file and deliver a copy to an internal system for them to process.

I told the Project Manager that if the file contained Protected Health Information (PHI) we would need to use sftp instead of ftp for the transfer to protect the information.

He asked me what data elements would be considered PHI.

This is a project manager at a medical school. We learn what PHI is and why it needs to be protected whenever we take HIPAA refresher training.

I gave him a short list and sent him a link to a faq.

http://www.hipaa.com/2009/09/hipaa-protected-health-information-what-does-phi-include/

The file that they are proposing to send contains names, addresses and phone numbers of patients. It is most definitely PHI, and I will not build an interface that does not protect it adequately when it is flowing over the wire.

If I had not asked, this data would have been transmitted in the clear, over the wire and been vulnerable to interception.

The level of competence found in IT staff at smaller provider organizations concerns me. That's where we are vulnerable. Hackers will not waste their time attacking the well defended, hard targets. They will steal your data from the poorly defended, soft targets. I fear that there are too many easy targets out there.

PCAST - Documents vs Atoms

In December, the President's Council of Advisors on Science and Technology (PCAST) released a report on HIT. We've been referring to this as "the PCAST Report"

Wes Rishel recently blogged on one of the more contentious issues contained in the report.

http://blogs.gartner.com/wes_rishel/2011/02/13/pcast-documents-vs-atomic-data-elements/

Basically, the report calls for a move away from the "record-centric notion that data elements should 'live' inside documents."

Now, I am all for "re-using" information. I expect that we will extract information from these documents and will repurpose that data in ways that none of us can fully understand, today. Indeed, we will extract a Patient's Medication History, Problem List and Allergies from a clinical document and import that into a recieving EHR system to feed into its Clinical Decision Support logic. However, I do see the danger of "taking things out of context" (pun intended).

If we extract "atomic" data from clinical documents and feed this data into other systems and processes, we may end up with GIGO (Garbage In, Garbage Out). The likelihood that the downstream systems may not fully understand the meaning of the "atomic" data and will mis-use it is great.

I cannot explain this any better than Wes does. Please read his analysis.

ONC CDA IG Consolidation Project Publishing

I volunteered to work on what is now called the Documentation workgroup of this project. Keith Boone of GE Healthcare and I are leading the workgroup.

Basically, what we are doing is deciding what content should go into the Implementation Guides (IGs), and the contractors that the ONC has working on the project will make it happen. I may end up writing some content.

The content needs to be finalized and sent to HL7 for the ballot by March 30.

The issues so far include:

Format for the Conformance Statements. Today, they read like one of those 1970s user manuals that has been translated from Japanese to English by either a machine, or by someone that does not really understand English or the application. Here is an example.

[IHE] SHALL contain [1..1] statusCode, which SHALL be selected from ValueSet ConcernEntryStatus STATIC

OK. This says that this conformance requirement comes from IHE. The section is required to contain a single statusCode which must be from the ConcernEntryStatus value set, which is a static value set.

We'll have a computable version of the conformance statements, so there is little reason for the statement in the IG to read so formally. We'd like the statements to still be precise, but not as clunky. We're going to come up with some examples of what we think the verbage should look like and then present the top 3 or 4 to the larger group. If we get fifty or more people arguing over where a comma should be, it will not be productive.

Format for the graphical representation of the model fragments. We think that each section and entry should have a graphical representation (some people understand pictures better than words). If we use standard UML, our wider audience will understand it, but the HL7 folks will expect the HL7 version of the UML diagram to be present in an HL7 publication. If we use UML only, we will get negative votes from HL7 members who expect the HL7 style graphics to be used in an HL7 publication. If we include both, the document will be much bigger, but that may be our best option. I think that we will make a decision and report that back to the full work group.

A format for the "table view" of the Header, Section and Entries need to be decided on. The HL7 Heirarchical Message Description (HMD) or the HITSP style tables are under consideration. We could possibly come up with a hybrid of the two. I think that we will make a decision on this and then report back to the full work group in the next couple of weeks.

This IG will be viewed and voted on by many people who are not normally voting on HL7 standards. We will need to explain a lot of this to them. Some years ago, when the EHR Functional Model was ballotted, the EHR Work Group faced a similar issue. They put together a separate document that explained the process to newbies. I will find a copy of that and use it as the basis for a document that we will include in the ballot package.

The Header and each section and entry will have a fully populated XML example. The trick will be to have a meaningful example that doesn't obscure the important stuff. We should probably use the HL7 Cast of Characters from the Publishing Facilitator's Guide for our examples.

http://www.hl7.org/v3ballot/html/help/pfg/pfg.html#storyboardnames

There will also be a complete example of each document type containing annotations indicating the conformance statement that the data satisfies.

The Documentation Workgroup meets on Wednesdays at noon eastern!

Every Wednesday from 12-1pm EST | Dial-in: 1-888-998-2663 | Pass-code: 9065865
Webinar: https://www.livemeeting.com/cc/dt/join?id=docWG&role=attend
Sign-up for this workgroup by e-mailing admin@siframework.org

http://jira.siframework.org/wiki/display/SIF/CDA+Consolidation+Project

ONC Standards and Interoperability Framework CDA Implementation Guide Consolidation Project

I blogged about this project earlier.

http://jira.siframework.org/wiki/display/SIF/CDA+Consolidation+Project

Basically, this is a project that is sponsored by the Office of National Coordinator for Health Care IT (ONC) to consolidate and harmonize eight of the CDA IGs that are required for Meaningful Use. I am participatign in my role as the Publishing Facilitator for the HL7 Structured Documents Work Group, which owns the IGs and will be the sponsoring committee when the documents are ballotted in HL7.

Some very smart people have developed tools that will enable us to create a single library of CDA Templates and constraints and publish the IGs

The Model Driven Health Tools (MDHT) from the Open Health Tools (OHT) project will be used to generate the IGS. MDHT is based on the Eclipse workbench. The actual prose for the IGs will be created using the Darwin Information Typing Architecture (DITA). The tools will transform the models and DITA into a variety of output formats.

https://www.projects.openhealthtools.org/sf/projects/mdht/

http://docs.oasis-open.org/dita/v1.2/os/spec/DITA1.2-spec.html#ditaspec

I've seen Eclipse before, but this is my first exposure to MDHT and DITA. I think that I understand how the tool integrates the modelling and vocabulary information with the publishing aspect, but I am still learning.

The main group has been meeting since the first week of January. The publishing sub-group will begin meeting next week.

The intent is to ballot these IGs in the May HL7 ballot cycle, so we have a lot to accomplish in a very short period of time. We will also explore how we can better integrate the IG generation and publication process into the HL7 Publishing process. It would be good if all of the CDA IGs can be generated using these tools. This would enable consistent formatting.

There are two other S&I Framework projects that will kickoff next week. These are the Transition of Care (TOC) Initiative and and the Laboratory Interface Initiative. I do not have time to participate in either of those. I'll be busy enough with my day job and the CDA IG Consolidation project.

Scheduling Interface and the Big Picture

I've been working on a project to replace existing interfaces to our old practice management system and redirect them to the replacement PM system. We're also adding new functionality and interfaces, too. Sometimes, it's important to think about what the business use of the messages is. Many times, the old system did things the way that it does because it made sense to do it that way ten or fifteen years ago. Simply replicating that process with the new system may not be the best way to go.

Here is an example.

Our doctors practice in several local hospitals. Our agreement with the hospitals is that we will bill for the procedures that our doctors perform there. We will bill for the professional charges, and the hospital will bill for the administrative charges. The trick is to figure out what we should bill for.

Our doctors use the hospital's computer systems when they deliver care there.

This hopital sends us a stream of scheduling messages. We do not get a stream of ADT messages from this hospital. That would be too easy.

The current system looks through the scheduling messages to see if there were appointments today that we do not have encounters in the practice management system. If not, it creates one. This will create an empty encounter that someone in the billing office will notice. They will follow up with the doctor to see what procedures were performed so that we can figure out what to bill.

Now, the scheduling stream is every appointment at the hospital clinics. Some patients will schedule a procedure up to a year in the future. This could be an annual mammogram, for example. Now, that appointment can, and probably will, change many times before the patient actually has that encounter. Keeping track of this in an interface engine will be very difficult.

I decided that I would save all of the messages and would have another process that would look at messages for encounters that are scheduled for today and check those against existing encounters in the practice management system. This would involve a database lookup. If there was no encounter, I would translate the scheduling message into a registration message and send that to the practice management system to create the encounter.

As I was trying to decide how I would replicate the existing logic, I realized that it would be very error prone. I could have the original appointment message for an encounter today, but if there is a later message that rescheduled or cancelled that appointment, this logic would create an encounter that never happened.

So, as I thought about how I would implement a system that would manage the appointments, I wondered if there might be a better way. Why should I have to create a logic in the interface engine to manage appointments and schedules? Could I find a system that would do that for me?

Then, it hit me. What if I simply sent the scheduling messages to the Practice Management system and let it manage the appointments? After all, that is one of the functions of a PM system.

Hmmmm.... I thought about it for a few moments.

Then, I asked Pam, our PM expert, how the PM system would handle an appointment without an encounter. She said that it would show up as a "no show" in an audit report. So, the business owners could use this "no show" report to follow up with the doctors to determine the billable procedures that occurred in this encounter.

This has the advantage of also having the schedule for these locations in our PM system.

We still need to follow up with the business owners to see if getting the information in this way would meet their needs.

We are building a mock-up of the new system to see what it might look in a test environment. I will create this schedling interface and we can see if this will work.

The moral to this story is that implementing a new system is an opportunity to do things better. If you keep your head down and simply replicate existing functions, you lose an opportunity to improve things. Of course, this requires that you actually understand what the old system does at an operational level, and not simply at a tactical level.

Patient List Interface

Here is a cute, little interface project that I knocked out in a couple of days.

One of our business partners is sending us what they call "patient list" data. This is information on patient groupings. For example, a patient could be on the "Gastroenterology Consults" list. This is information that does not come across in the organizations ADT stream, and the likelihood of getting it added to that was pretty low. Instead, they send us a patient list file which would contain a record for each patient and the patient list that they are on. They generate this as a Comma Separated Value (CSV) file and would send that to us as a flat file. I built a route and a mapping in the engine to take the flat file, generate an HL7 A08 (patient udate) message for each patient and place the Patient List information into the PV2-23 field (ClinicOrganizationName). The route then places each ADT message into the ADT stream for the appropriate system.

The A08 updates the basic patient demographic information by only adding the patient list information to the PV2-23 field ClinicOrganizationName. They can then select all patients that are currently in the Neurology list, for example. The receiving system gets the Patient List information with no changes required.

We already had a mechanism in place to exchange flat files, so they added this file to the stream. On the receiving end I have a script that looks at each file, identifies which one it is and routes it for processing. I added the new file to the script and built a new route to process the patient list file.

I then had to build a data structure for the CSV, which was pretty straightforward. I then built a special ADT structure that contained multiple A08 messages, and then a Map (that is the Rhapsody term, in Cloverleaf, this would be a Translate) to map the data from the CSV file to the ADT Message. After this, I added a DeBatch filter to the route to split each of the A08s into a separate message.

I had not built this sort of interface before, so I learned a little bit doing it. The trickiest part was getting the file structure definitions set up correctly. The actual mapping took about an hour to build and test.

More on Meaningful Use

I wrote earlier about what Meaningful Use is and why it is important. Recall that providers will be reimbursed for purchases of certified HIT products and that they will then recieve financial incentive for the "meaningful use" of that technololgy, but all that the legislation says is that meaningful use is:

1. ePrescribing
2. participation in an HIE
3. submission of quality measures

The importance of the definition is that it is the first step in a process that involves many others.

1. The HIT Standards committee will need to select the standards and implementation guides that support meaningful use
2. The certification body (which may be CCHIT, but HHS has not confirmed this) will need to align its certification criteria with these
3. Vendors may need to adjust their EHR Systems to ensure that it meets the criteria. This may require recertification.
4. HealthCare Organizations (HCOs) that already have technology in place may need to upgrade or adjust their systems so that they can meet the meaningful use criteria. Those organizations that do not have EHRs in place will likely wait until the vendors have caught up with the certification criteria before they begin implementing.

Until the definition is published, we can guess at what they mean, and try to be ready for it.

Money becomes available for the purchase of "certified" EHR systems in October, 2010. So, the timing is extremely tight.

These dates are from the recovery.gov website:

http://www.recovery.gov/?q=content/program-plan&program_id=5299

Standards Rulemaking: Recovery Act §3004 (B) (1) - No later than December 31, 2009, HHS shall adopt and publish an initial set of standards, implementation specifications, and certification criteria. The rulemaking for this initial set of standards, implementation specifications, and certification criteria may be issued on an interim, final basis. Fully competitive contract awards will be utilized to support the impact analysis.

Milestones:

Complete Draft Rule/ Regulatory Impact Analysis. Start: 05/01/2009 End: 08/26/2009

Submit for HHS Clearance. Start: 08/26/2009 end: 09/25/2009

Clear OMB (up to 90 day process) Start: 09/25/2009 End: 12/24/2009

Publish in Federal Register. Start: 12/24/2009 End: 12/31/2009


So, if the HIT Standards Committee is to meet the deadline of submitting the list of standards that are required to support “meaningful use” (August 26), the definition has to be published very, very soon.