Results of HITS Meeting of Friday, 5/15/09

Contents

Preface....................................................................................................................................................3

Revision History...................................................................................................................................3

Abbreviations..........................................................................................................................................3

Setting The Tone for the HITS Committee...............................................................................................4

HITS Mission........................................................................................................................................4

Timing..................................................................................................................................................5

HITS Standards Includes Implementation............................................................................................5

How Do We Measure Success?............................................................................................................6

Rule Making Process & ONCHIT's Role................................................................................................6

Coordination With Other Organizations..............................................................................................6

Allowing for Innovation.......................................................................................................................7

Organizing HITS for Feedback..............................................................................................................8

Timeline Related Topics...........................................................................................................................8

Beginning HITS' Work..........................................................................................................................8

Formulating An Implementation Roadmap in Light of Other Imperatives...........................................8

Don't Forget Administrative Functions................................................................................................9

Setting Standards.....................................................................................................................................9

Defining The Process...........................................................................................................................9

Meaningful Use.................................................................................................................................10

Setting and Adjusting the Standards Bar...........................................................................................10

Standards Setting in an Asynchronous Standards World...................................................................11

Candidate Standards Areas....................................................................................................................12

Secure Messaging..............................................................................................................................12

Moving to Machine-to-Machine Data Exchange................................................................................13

Fast Path to Medical Data..................................................................................................................13

Images...............................................................................................................................................14

Implementation Standards................................................................................................................14

perretta@ix.netcom.com Page 1 of 18

Supporting A Patient-Centric Approach.............................................................................................14

Setting Up HITS Workgroups.................................................................................................................14

Communications................................................................................................................................15

HITS Project Plan & Next Steps..............................................................................................................16

Next Steps..........................................................................................................................................16

Figure 1: HITECH Timeline.....................................................................................................................17

perretta@ix.netcom.com Page 2 of 18

Preface Author's Note1: This document represents a synthesis of the proceedings of the initial HIT

Standards Committee (HITS) chaired by Jonathan Perlin and John Halamka on Friday, 5/18/09, at the US Department of Health & Human Services' Mary Switzer building in Washington, DC. I was present as a member of the public; and not as a member of HITS nor HHS. Thus, please be aware that what I have composed below include my own interpretation of the discussion. I have tried to express my notes in complete thoughts - and organize the discussion in logical categories and not specifically in the order of discussion during the meeting. In some cases, I have extended my notes to try to more accurately convey the gist of a particular HITS discussion point.

This document also includes numerous contextual hyperlinks to germane references & citations on the Web.2

Partly as a 'backgrounder' aid - Figure 1: HITECH Timeline on page 17 is a simple graphic I tried to pull together from reading the HITECH section of the American Reinvestment & Recovery Act. Such a "timeline" was NOT a discussion point in the HITS meeting - although some aspects of that schedule were alluded to.

Revision HistoryDate Version Author Comment

5/16/09 1.0 H Perretta Created primarily from handwritten notes & secondary research5/18/09 1.01 H Perretta Corrected abbreviation for Health Information Technology

Standards Panel to HITSP; Changed name of this file to HITS 05-15-2009.docx

Abbreviations Below is a simple list of abbreviations used in this synthesis - with Web references where

applicable. ARRA : American Reinvestment & Recovery Act - aka "The Stimulus Package" (click here to get

PDF of the legislation) The Committee: For purposes of this document: the HIT Standards Committee. Coordinator: is David Blumenthal, MD, National Coordinator for Health Information Technology. EHR & EMR & PHR: Perhaps unfortunate - but for purposes of this document - I used these

terms interchangeably - at least as far as this document goes - they mean the same thing. HIE: Health Information Exchange HITECH: TITLE XIII of ARRA —HEALTH INFORMATION TECHNOLOGY (page 112 of ARRA). HITP: is the HIT Policy Committee: HHS 43019. Also referred to as "the Committee" in

discussion below. HITS: is the HIT Standards Committee: HHS 43018 (both HITP and HITS are organized as FACA

committees (see Federal Advisory Committee Act (FACA)). The essential point is that FACA committees must be open to the public.

1 Feel free to contact author: Henry Perretta - perretta@ix.netcom.com2 Some links are to other sections in this document as well.

perretta@ix.netcom.com Page 3 of 18

HITSP: The Healthcare Information Technology Standards Panel "I": this refers to the author of this document: Henry Perretta. (I just wanted to make clear in

some cases where I was supposing the intent of various committee comments). MU: Meaningful Use (as defined in ARRA)3. ONCHIT : Office of National Coordinator of Health Information Technology - headed by the

Coordinator; and reporting directly to the Secretary of Health & Human Services. o ONCHIT supports both the HITP and HITS committees.

PHI: Protected Health Information The Statute: ARRA and HITECH. "We": this is intended to mean the HITS committee. Sorry, I was lazy and didn't want to spell

out "the Committee" each time this came up.

Setting The Tone for the HITS Committee

HITS Mission HITS needs to get the standards right - not for the sake of the standards themselves - but for "the

larger picture". This bigger picture can be framed around these two issues: Providing access to care Organizing the US health care system for efficient delivery of that care - for both individuals

and groups of individuals. So HITS needs to keep in mind: how will HITS' recommendations lead to meaningful use

(abbreviated below as 'MU') and to efficient health care delivery to both individuals and groups of individuals.

How we manage information is the single biggest consideration in addressing the above issues; and ONCHIT hopes the HITS committee ("HITS") can help lay the groundwork for that mission.

The ultimate goal of our work is to help enable health information technology (HIT) that supports the accessible, safe, efficient, effective and compassionate delivery of US healthcare.

The central requirement we face - is to make it possible for "meaningful users" to take advantage of the incentives & assistance afforded them via the HITECH legislation; beginning 1/1/2011.

HITS responsibilities include Recommendations for relevant standards Updating of existing standards Guidelines for testing of standards (through NIST)

8 Areas of Focus for HITP & HITS The "starting points" - that is: 8 areas where standards are needed - stem from HITECH (see page

117 in ARRA). 1. Privacy & Security protections & safeguards

3 See - for example - this citation from ARRA (page 356): MEANINGFUL USE OF CERTIFIED EHR TECHNOLOGY.—The eligible professional demonstrates to the satisfaction of the Secretary, in accordance with subparagraph (C)(i), that during such period the professional is using certified EHR technology in a meaningful manner, which shall include the use of electronic prescribing as determined to be appropriate by the Secretary.

perretta@ix.netcom.com Page 4 of 18

Don't shoot here (NCPDP format) Shoot here (NCPDP format PLUS meds history - for example)

2. Requisite HIT Infrastructure to allow for health information exchange3. Utilization of certified EHR systems - so that all Americans are represented in such

systems by 1/1/20144. Improve healthcare quality5. Foster public understanding of HIT6. Process to coordinate policy amongst HITP, HITS, and other health exchange bodies7. Technologies allowing authorization, authentication, and the rendering of PHI to be

unusable4.8. Support of vulnerable populations

Timing We need to figure out standards to get to true implementation of MU by 1/1/2011. If we move

backwards from that date to today - it really means we have an accelerated timeline; when we take into account HITS' work; HITS' parallel dependencies on HITP activities; the need for continual vetting and review, and the "harmonization" of HITS work with other relevant organizations: in other words - the statutory "rule making process".

Look Ahead When Setting The Standards Bar: The HITS committee (abbreviated 'HITS' throughout this document) should "skate to where the puck will be". This 'principle' of HITS' activities was implicitly mentioned throughout the day's discussions.

Example: HITS could mandate the use of prescription drug data exchange formats as NCPDP specified in HIPAA. But the "puck" is moving: as e-Prescribing gains momentum, there will be feasibility (and market impetus) to moving towards medication history checking, treatment adherence, and drug-drug interaction. HITS should be cognizant of the latter in its standards-setting activities. Conceptual graphic immediately below

HITS Standards Includes Implementation Unlike HITSP and other similar HIT initiatives, HITS has a charter to go beyond "certification

standards / specifications" - and establish implementation & testing criteria as well. In the past we have not had an alignment between standards setting - and implementation. There

wasn't a drive to "break down those silo's".

How Do We Measure Success? Success in HIT deployment is realized when we have transparency for providers (doctors, hospitals,

etc.); payers; and patients.

4 Author's Note: I believe there are several purposes for this: a) de-identification of PHI for purposes of population based health studies/uses; b) safeguards in the event of a security breach; - and probably other reasons I'm not thinking of.

perretta@ix.netcom.com Page 5 of 18

Rule Making Process & ONCHIT's Role HITS recommendations will inform the Secretary's decisions on certification and incentives. Note

that HHS must make HIT standards decisions consistent/congruent with the Federal Health Information Technology Strategic Plan. A simplistic view of this process:

HITS Recommendations HHS Reviews HHS Establishes Rules consistent with IT Plan

The Expedited Rule Process There is an expedited process to get to the 12/31/09 rule making deadline. In this process, HHS can

issue an "interim final rule". In addition, Congress allows HHS to "look to prior work" when developing the interim final rule. Click here for further description of the Federal expedited rule process5.

The Normal Rule Process To illustrate this approach: HITS would send its recommendations to the Coordinator; and then

there would be an opportunity for public comment. For an example of the "normal rule process" at work click here (example of ICD-10 rule making process).

Coordination With Other Organizations In general, "the statute" does allow HITS to hear from anyone regarding development of standards -

including certification criteria.

HITP Obviously this is the most important body for HITS to coordinate with. HITP sets the priorities for

HITS focus. ONCHIT is the "glue" coordinating activities of both committees. On 5/11/09, the HITP decided there would be 3 "working subgroups":

Meaningful Use (MU) Note that there will be recommendations from HITP - but there will be a

regulatory process around HITP MU definitions. Example MU areas (merely illustrative, although likely to be addressed by HITP):

Medications Management Care Coordination Lab workflow

Information Exchange Certification

NOTE: Privacy and Security are a common consideration for all 3 subgroups

CCHIT Question: regarding the certification criteria process: how does the CCHIT fit in? What does

HITS do about certification criteria that do not yet exist? Answer: we are looking at recommendations for a) MU, and b) development of certification

standards that do not exist today.

5 From the text: A guide to federal agency rulemaking by Jeffrey S. Lubbers.

perretta@ix.netcom.com Page 6 of 18

HITSP Use Case (from a HITSP Interoperability Spec - )

HITS transforms the use case into a dictionary of sorts to help define a particular meaningful use (MU).

Leveraging HITSP's Work Question: how does HITSP DEFINITION_HITSB and that body's work with interoperability

standards play into the work HITS will take on? Answer: In HITSP's approach - interoperability standards were driven from use case scenarios.

ARRA/HITECH however, have a different construct for standards formulation. However, HITSB's interoperability standards have gone thru a harmonization process; and much of the work that HITSP has done can be of use to HITS.

Author's Note: Below I tried to depict the concept I think John Halamka was conveying:6

Allowing for Innovation HITS needs to balance standard settings:

On the one hand, the standards need to be prescriptive & constrained enough to protect the public; and to enable true health information exchange capability. For example: When setting standards, we need to balance between "leaving rural and

small provider organizations behind" - and - keeping the status quo. On the other hand, HITS does not want to stifle innovation and creativity. In other words -

by way of example: When setting standards, HITS should try to "stay ahead of the puck" - and allow EHR and HIE developers to extend functionality and performance in their products - while allowing them to deliver certifiable products.

The above consideration is one that ONCHIT deals with continuously. One of the committee participants offered an analogy - the cell phone industry: standards need to

allow for innovations such as the iPhone on one hand - but making sure innovations like the iPhone still can 'talk' to any other cell phone and cell phone network.

Bottom Line: in standards setting: allow for an evolution in the marketplace.

6 Author's note: I really only followed this discussion at a very rudimentary level. But the overall point is: HITSB interoperability specifications can be a very useful resource to inform the standards developed by HITS.

perretta@ix.netcom.com Page 7 of 18

Feedback

Organizing HITS for Feedback Committee Member Comment: In our work, HITS needs to be cognizant of the fact that a 'waterfall

approach' needs to allow for "fast feedback". Author's Note: I believe the commenter was talking about a way for HITS to quickly receive

focused and clear feedback on HITS recommendations rapidly. Probably this principle holds for a number of "cycles" - such as: feedback from HITP; from the Coordinator; from other standards bodies; from the Secretary; from the public (e.g. thru the public comments process).

Timeline Related Topics

Beginning HITS' Work From a timeline perspective, at least in theory, HITS' work is dependent on recommendations from

HITP. However, overall time constraints do not allow such a clean 'waterfall' sequence of events. HITS needs to commence work now - and this is not as bad as it sounds: reasonable assumptions can be made right now on where HITP is likely to fall where it comes to areas of MU formulation; and certification priorities.

For example, the fact that HITP is organized into 3 sub-groups is already a cue. See HITP on page 6.

Formulating An Implementation Roadmap in Light of Other Imperatives HITS (and ONCHIT and HITP) need to be cognizant of the fact that during the next few years, HIT

vendors and HIT 'meaningful users' will need to grapple with other standards mandates aside from those stemming from HITECH; in particular:

The rollout of new HIPAA Transaction & Code set standards: The X12 Version 5010 and NCPDP Version D.0 standards ICD-10 standards

We need to develop a timeline and flesh that timeline out as a "roadmap" for all stakeholders - so that all relevant parties (vendors, policy makers, standards bodies, providers, etc.) can understand their resource needs and triage appropriately. See below:

perretta@ix.netcom.com Page 8 of 18

1/2012 - 5010 & NCPDP D5 10/2013 - ICD-10 1/2014 - Nationwide EMR's

For example: the ICD-10 code set allows for ~170K diagnoses codes - orders of magnitude more than the existing ICD-9 set. Obviously EHR's and HIE facilities must allow for this to support meaningful use; and implementation specifications must take into account the impact on vendors and providers.

Don't Forget Administrative Functions As a corollary to the discussion Formulating An Implementation Roadmap (see page 8), we do not

want a failure in meeting the 1/2014 milestone because providers are more concerned about being paid than they are about implementing an EHR. At minimum, HITS needs to be cognizant of health plan <-> provider transactions when setting standards. HITECH incentives and MU are not that attractive when it comes to providers maintaining reliable cash flow.

Bottom line: the "HIT Roadmap" needs to take into account providers' needs to support "health plan administrative" transactions - particularly eligibility verification, claims submission and payment.

Setting Standards General comment made during the discussion: the statute allows that can change over time - you don't have

to just think about these standards (and Meaningful Use (MU) criteria) as "frozen for implementation" in 2011. Of course, some standards and MU criteria MUST be in place by 1/1/2011.

Defining The Process Major inputs inform HITS standards recommendations activities:

perretta@ix.netcom.com Page 9 of 18

Meaningful Use MU drives the need for standards. Although Meaningful Use (MU) is HITP's domain, the Committee

discussed likely MU areas - to start a discourse on likely standards areas that HITS will need to address.

Likely HITP Meaningful Use AreasAlthough HITP has not issued MU guidance; it is not a bad bet that MU areas will include (among other topics):

1. ePrescribing: particularly going beyond simple electronic order entry / data exchange - and moving to "where the puck will be" - meaning: medication management; applicable use information; drug-drug interaction; treatment adherence; etc.

2. Lab 3. Clinical Summary - for purposes of care coordination.

The idea here is to allow a provider to correlate patient status at (for example) the point of order entry. A "Clinical Summary" in this context would include things like a problem list; allergy list; recent treatment history; summaries where relevant for radiology / pathology / discharge summaries; etc.

Obviously "Clinical Summary" would need to be defined a bit more specifically than above.

4. Quality Measuring

Setting and Adjusting the Standards Bar The Committee discussed another "property" of standards - not just the standard itself; not just

WHEN a standard needed to be implemented -but how ambitious (or "difficult") the standard should be to reach. The moniker used here was "setting the bar".

Trading Off Bar Height If a standard's bar is too high - it may be too difficult to reach - especially in light of other mandates

such as those discussed in Formulating An Implementation Roadmap in Light of Other Imperatives on page 8.

If the bar is too low - the standard as implemented may not truly support the meaningful use - and meaningful OUTCOME - that HITP (and ultimately HHS) intends. On the other hand - we want the bar low enough (just right) so that "meaningful users" can

realistically obtain and implement a certified EMR and get support thru the HITECH statute. Particularly relevant for small provider groups and small hospitals (as alluded to during the discussion - some hospitals have 1 to 3 IT staff!).

The "bar height" all depends on the standard and how that standard supports the Meaningful Use (MU) in question. The example discussed:

If an MU is related to dramatically increasing the use of Secure Messaging (for some meaningful outcome purpose) - then the corresponding HITS standards recommendations may be relatively low in terms of "the bar". That's because HIPAA Security standards that

perretta@ix.netcom.com Page 10 of 18

went into effect in 2005 might already address/support the HITS standards composed for "Secure Messaging".

Adjusting Bar Height Over Time Call this the "Pole Vault" scenario. That is: the idea is that a standard's 'bar' can be specified by HITS

to be raised over time. For example - perhaps a meaningful use (MU) is concerned with coordination of care. Perhaps one

of the applicable supporting standards is for secure messaging. The bar might be set low initially - to allow person-to-person messaging (e.g. for secure e-mail); but might be "raised" for a later date - to allow for machine-to-machine transmissions.

Standards Setting in an Asynchronous Standards World The gist of this discussion was allowing for the fact when setting standards in HIT; we must allow for

the fact that "other things are changing with respect to providers' use of technology - and these are happening independently of each other - and happening at different times relative to standard implementation deadlines".

Thus, HITS needs to factor in the following when setting standards: The existing investment in IT - particularly at providers. To the fullest extent possible,

standards must be able to be "retro fitted" to existing systems and applications. The other consideration here is the need to allow for the learning curve of provider users;

from several angles: Some providers may be using applications today - but we need to consider their

learning curve as they begin implementing and using certified EMR systems. Some providers may be using few or no applications - and may have an even steeper

learning curve than those above. We need to avoid the "frozen interface syndrome".

For example: the Open Systems Interconnect (OSI) data communications standards became obsolete - because they were stagnant and did not move ahead. Result: TCP/IP quickly replaced OSI as the de facto data networking standard.

The other (perhaps more relevant) example cited: is the situation with HL/7 Version 2.21. 7 We must allow for standards to be "upgraded" and updated over time. HITS' standards' philosophy needs to

accommodate the differing rates & timings of changes in application, system, sub-system, hardware and networking technologies.

7 Author's Note: I think the Committee person who cited this example was alluding to the fact that perhaps interoperability standards were proposed around HL/7 2.21 - however in the meantime HL/7 moved on to versions 2.3, 2.4, 2.5 and 3.0.

perretta@ix.netcom.com Page 11 of 18

Below is a conceptual graphic. Think of several layers of standards supporting certified HIT applications. Each layer "moves forward" to the respective next levels (depicted as black diamonds) at different rates and at different times.

The point is: the HIT standards from HITS - needs to be relevant and support multiple levels of standards "below" this top level.

HIT Standards

Sub System Software and Transaction Standards (e.g. HL/7, HIPAA, CORBA)

Data Communication Standards (TCP/IP, PKI, etc.)

Candidate Standards Areas

Secure Messaging One other MU possibility: how about an area centered on Secure Messaging?

In other words: an area that deals with: what do we replace FAX of 'free text information' with?

The concept here is start with an MU area where we can set the bar relatively low initially. Secure Messaging would need a relatively low level of technical effort in terms of formatted/codified data specification. We'd basically be trying to at least enable further "digitization" & supported electronic communications management capability to deal with free text communications - between and amongst providers, patients, pharmacies, payers, etc.

Secure Messaging would naturally lead to HITS standards for authentication, data integrity, and confidentiality. Overall, this sets the stage for further standards setting for Machine-to-Machine Data Exchange.

Note that HITSB developed use cases for Secure Messaging - helping HITS efforts in this "MU area".

perretta@ix.netcom.com Page 12 of 18

Other Sources / Uses

Moving to Machine-to-Machine Data Exchange In the context of standards setting - the Committee talked about an evolution in standards - that is:

going from "human to human via machine" standards (example: secure messaging in support of person to person communications of free text) --- to --- machine to machine data exchange.8

The ultimate goal are standards to enable machine interoperability and data exchange. Here again, the Committee needs to shoot to where the puck will be:

Semantic and SyntacticNote: for both the discussion of Secure Messaging and Moving to Machine-to-Machine Data Exchange the concept of semantic and syntactic data exchange was discussed.

Author's Note: I believe the concept here is that "syntactic" data specifications stipulate the allowable format of data (allowable values; length; allowable character sets; etc.); and a semantic specification spells out the meaning of that data. Click here for further information. I would guess that one must have agreement on SYNTACTIC spec's before one can impose SEMANTIC spec's on a given standard.

Fast Path to Medical Data The Committee talked about another HIT need: a "fast path" to Medical Data. The problem today is

that many HIT / EMR systems will support a valuable function - but GETTING to that data varies enormously - and becomes a hindrance to provider staff trying to care for a patient.

So the "candidate standard" here would be a standard presentation format (perhaps with some guidelines for standard user navigation to data as well).

There is an analogy to this problem & solution today: For healthcare eligibility inquiry & response, the HIPAA TCS rule mandates the use of the

270/271 transaction. This only specifies a machine - to - machine format. However CAQH's CORE project extends that standard and attempts to specify the presentation of that information in provider applications.

8 By way of illustration: "EDI" (electronic document interchange) is/are standards for this purpose expressly; as are HL/7 standards.

perretta@ix.netcom.com Page 13 of 18

Images Inclusion of Image data is important for EMR systems - and for HIE exchange functionality. Most

likely, image information can play a part in a MU scenario.

Implementation Standards The Committee needs to consider that implementing an EMR application(s) can take a lot longer than

originally anticipated - especially since you have to deploy extremely carefully to maintain patient safety9 - in other words: "do no harm" while implementing.

James Walker cited an example from Geisinger; where they implemented an EMR application after 50 THOUSAND hours of testing. In spite of that exhaustive testing effort, the Geisinger team still had to address 4,192 issues AFTER deployment!

Bottom Line: implementation timelines need

Supporting A Patient-Centric Approach Here the discussion revolved around information capture standards in support of 4 general areas:

1. Healthy behaviors2. Management of patient conditions (in other words: treatment)3. Outcomes - beyond mortality and broad morbidity measures4. Patient engagement in health care decision making

Setting Up HITS Workgroups Like HITP; HITS figures the best way to focus on the task at hand would be to organize into sub-

groups - with each sub-group (aka "workgroup") focused on one aspect of HITS activities. The first idea proposed: why not organize HITS along the same lines as HITP's subgroups

('meaningful use' (MU), information exchange, and certification/adoption)? One disadvantage of that approach discussed by the group: HITP's subgroups do not have

an explicit privacy & security workgroup. Going back to the "8 areas" of focus - note that 2 of these areas are explicitly related to privacy / security (Privacy & Security itself; and 'technologies related to PHI protection & rendering PHI unusable when needed).

Another workgroup "set" proposal was discussed: Administrative Transactions Clinical Care Security constructs Quality measurements (for patient status, and outcomes)

A final workgroup "set" was discussed and decided: Clinical Operations (including e-Prescribing and Clinical Summary)

Here we talked about standards that go beyond the current state - example: "Ok, you have implemented e-Prescribing with NCPDP formats --- now here are standards to support a Meaningful Use (MU) of checking for drug-drug interaction".

In other words: are we managing the patient - as opposed to simply collecting and moving data around electronically?

Clinical Quality

9 And, in fact, hopefully improve patient safety.

perretta@ix.netcom.com Page 14 of 18

HITECH

ARRA

Other Standards bodies - NCVHS, NHIN, etc.

Providers & Industry Stakeholders

The Public at Large

HITS

In the "quality" area we talked about going beyond what data needs to be collected - and including WHO collects it and WHEN they collect it.

We had a little sidebar discussion here as well - HITECH in this area should be informed by NQF (the National Quality Forum); evidence based medicine; and desirable practice outcomes.

We also have to allow for the impact of ICD-10 and how that meshes with quality standards from HITS.10 The same is true for SNOMED.

Privacy and Security Covering at least data transport - and user authentication.

For all 3, we do need to keep an eye on the HIT administrative transaction standards (meaning HIPAA 5010).

Communications We considered a fourth group - focused on communications: in other words; how are we going to

communicate with all groups in near real time? By "groups" - we meant stakeholders like providers and the public. HITSB, by way of example, formed a communication committee early on for exactly this function.

The general concept is reflected below conceptually - from 2 perspectives: What is "informing" the work of HIT What stakeholders exist for communications for a variety of purposes.

10 Another example of "shooting where the puck will be".

perretta@ix.netcom.com Page 15 of 18

HITS Project Plan & Next Steps HITS committed to a '90 day turnaround' to provide recommendations. In other words:

Next Steps The next items for HITS:

The HITS co/chairs will work with committee on who will lead each sub-group and what each subgroup will do.

ONCHIT will give date guidance to HITS for deliverables.

perretta@ix.netcom.com Page 16 of 18

HITS gets MU and/or standard guidance from HITP

Applicable HITS workgroup(s) formulates standard(s) for MU

60 days

Full HITS committee vets - and forwards to Coordinator as

recommendation.

30 days

Coordinator approves and forwards to Secretary

Figure 1: HITECH Timeline

perretta@ix.netcom.com Page 17 of 18

perretta@ix.netcom.com Page 18 of 18