HIT Certification from a Vendor Standpoint

On March 10th, 2010, the HHS released a proposed rule on establishing certification programs for health information technology with a request for comments. The document covers a lot of ground with respect to what will be certified, how the certification process will be organized, who will be certifying HIT, etc. Below, are the main points of specific interest to HIT vendors (though you are encouraged to read the entire document at your leisure.)

1. Definitions

a. Certification criteria means criteria: (1) To establish that health information technology meets applicable standards and implementation specifications adopted by the Secretary; or (2) that are used to test and certify that health information technology includes required capabilities.
b. Certified EHR Technology means a Complete EHR or a combination of EHR Modules, each of which: (1) meets the requirements included in the definition of a Qualified EHR; and (2) has been tested and certified in accordance with the certification program established by the National Coordinator as having met all applicable certification criteria adopted by the Secretary.
c. Complete EHR means EHR technology that has been developed to meet all applicable certification criteria adopted by the Secretary.
d. EHR Module means any service, component, or combination thereof that can meet the requirements of at least one certification criterion adopted by the Secretary.
e. Disclosure means the release, transfer, provision of access to, or divulging in any other manner of information outside the entity holding the information.

f. Qualified EHR means an electronic record of health-related information on an individual that: (1) Includes patient demographic and clinical health information, such as medical history and problem lists; and (2) has the capacity: (i) To provide clinical decision support; (ii) to support physician order entry; (iii) to capture and query information relevant to health care quality; and (iv) to exchange electronic health information with, and integrate such information from other sources.

2. Start of the Medicare EHR Incentive Program

The first payment year for eligible professionals was defined as calendar year 2011 (i.e., the year beginning January 1, 2011) and the first payment year for eligible hospitals was defined as fiscal year 2011 (i.e., the year beginning October 1, 2010). Since the Meaningful Use requirements explicitly state that incentive payments are contingent on the use of certified HIT, the HHS decided on establishing both temporary and permanent certification programs. The fundamental difference between two programs in application and accreditation requirements for Certification Bodies, and it does not significantly affect the actual HIT certification process.

Under the temporary certification program, ONC-Authorized Testing and Certification Bodies will be created, whose responsibilities will comprise performing "the testing and certification of Complete EHRs and/or EHR Modules". The certification will focus on Stage 1 objectives, which include "electronically capturing health information in a coded format; using that information to track key clinical conditions and communicating that information for care coordination purposes (whether that information is structured or unstructured), but in structured format whenever feasible; consistent with other provisions of Medicare and Medicaid law, implementing clinical decision support tools to facilitate disease and medication management; and reporting clinical quality measures and public health information."

Currently, there are two versions of the temporary program sunset process. According to the first one, “the temporary program would sunset once the permanent certification program is established and at least one certification body has been authorized by the National Coordinator.” The other version sets the program sunset date on December 31, 2011.

3. Testing and Certification

The document states, that “The test tools and functional testing techniques for the certification criteria adopted by the Secretary have been or will be developed by NIST.”

Both programs require EHR modules, regardless of their function, to be certified on Privacy and Security criteria. Exceptions are made in the following cases:

• the module is an integral part of a Complete EHR being certified in its entirety, unless the module resides outside of the provider network
• when it is infeasible to apply the criteria, for instance, if the module does not stores, maintains, or transfers PHI
• the module performs a specific privacy and security capability
Testing can be done:
• at the authorized testing facility
• at the site where a Complete EHR or EHR Module is developed
• at the site where the Complete EHR or EHR Module is installed and used
• remotely using secure electronic transmissions

As far as the validity of certification is concerned, the document offers the following clarification:

“Certification represents a snapshot, a fixed point in time, where it has been confirmed that a Complete EHR or EHR Module has met all applicable certification criteria adopted by the Secretary. From that point forward, a specific Complete EHR or EHR Module version which has been certified would be forever labeled "certified." However, as the Department adopts new or modified certification criteria, previously adopted certification criteria would no longer constitute all of the applicable certification criteria to which a Complete EHR or EHR Module would need to be tested and certified. As a result, Complete EHRs and EHR Modules that had been certified to a previously adopted set of certification criteria would no longer be considered "Certified EHR Technology" for purposes of enabling an eligible professional or eligible hospital to attempt to achieve a future stage of meaningful use.”

"The planned two-year schedule for updates to meaningful use objectives and measures and correlated certification criteria creates a natural expiration for the "certified status" of Complete EHRs and EHR Modules. Accordingly, after the Secretary has adopted new or modified certification criteria, the validity of the certification associated with previously certified Complete EHRs and EHR Modules will expire and those Complete EHRs and EHR Modules would need to be re-certified in order for eligible professionals and eligible hospitals to continue to possess HIT that meets "all applicable certification criteria adopted by the Secretary" and consequently also meets the definition of Certified EHR Technology.

Stated another way, regardless of the year and meaningful use stage at which an eligible professional or eligible hospital enters the Medicare or Medicaid EHR Incentive Program, the Certified EHR Technology that would be used would have to include the capabilities necessary to meet the most current certification criteria adopted by the Secretary... in order to meet the definition of Certified EHR Technology."

The rule makes clear distinction between Meaningful Use requirements for the users of HIT and HIT certification. For example, eligible providers and hospitals, whose first payment year is 2013, will have to meet Stage 1 requirements. At the same time, the HIT they use must be certified on Stage 2 criteria.

The document introduces the notion of differential certification, when a previously certified Complete EHR or EHR Module will have only to be certified on a set of new or substantially amended criteria.

The cost of certification is estimated to be in the range of $30,000-50,000 for a Complete EHR, and $5,000-35,000 for a Module.

HIT: Challenges from the Data Perspective

Patient health and medical information generated in a healthcare organization can be categorized by various features. For example, it can be

• Transactional, related to a separate event, such as an ADT, exam, order, procedure and so on
• Summary, describing the development and status of a condition, family and social history, providing a problem and medication list, etc.

From the vocabulary interoperability standpoint, each piece of information is either coded or uncoded. Coded entries, e.g., diagnoses, always contain the code value from a coding system and the name of the system, as in the following excerpt from a CCD:

<observation classCode="COND" moodCode="EVN">
  <id root="abbbdd09-ae9f-4879-aa80-3893736973d1" />
  <code code="346.2" displayName="Migraine Headache, Variant" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD9CM" />
</observation>

Uncoded data is usually a narrative in a free text form, for instance:

DISCHARGE DIAGNOSES
Extruded disk, L4-5, with right L4 and L5 radiculopathy.

From the semantic interoperability and automatic processing point of view, each record can be structured or unstructured. HL7, CCR and CCD-formatted data are good examples of structured records. Images, scanned and text documents represent unstructured ones. Be aware, though, that structured records may, and often do include unstructured pieces. For instance, an HL7 message can contain a free-text report or note.

The rationale behind the HITECH Act and Meaningful Use was not as much about lack of patient information, as about its availability (with privacy and security protection, of course) and usability. Computer programs are very good at categorizing, grouping and sorting electronic records as long as the logical model of the data includes standard codes for diagnoses, medications, problems, etc., and links labs, reports and clinical documents to respective encounters. The challenge though, is to get all these attributes populated.

The Stage 1 Criteria for Meaningful Use make a serious effort towards improved usability by requiring recording patient demographics, problem lists, current and active diagnoses, medications and medication allergy lists and lab test results as structured and largely coded entries. It seems relatively straightforward with regard to patient demographics, diagnoses, problems lists and electronic prescriptions, even though, for example, very few if any EHR systems use the CDC Race and Ethnicity Code Set. The HIT Certification programs together with the Meaningful Use Criteria will eventually encourage EHR system vendors and users to implement standard vocabularies, especially, since the Unified Medical Language System (UMLS) is now available at no charge in the U.S. Interestingly enough, there are no similar requirements for lab systems. The hope is that healthcare providers trying to become meaningful users will gradually steer clinical labs in the same direction. But for now we can expect a lot of activity building and customizing integration interfaces to get lab test results structured, UCUM-normalized and standardized.

The move towards structured and coded EHR will be a huge deal even just going forward. There is an enormous volume of historic data, some of which has not yet been digitized at all. It has to be dealt with in a smart fashion, based on record holders priorities and resources. But this topic deserves a separate discussion.

HEALTH IT: GOALS, CONCERNS AND CHOICES

Health information technology, if properly implemented, can move us closer toward two fundamental goals of healthcare reform:

• Improved quality of care, through:
  * Making comprehensive patient information (clinical history, medications, test results, etc.) available at the point of care
  * Better decision support
  * Patient involvement
• Cost containment, through:
  * Prevention of errors; elimination of duplicate tests and treatment procedures
  * Faster dissemination of research results and best practices

From the provider standpoint, there are three logical levels of information aggregation. First, all pieces of medical data for the current encounter (complaint, diagnosis, tests, reports, notes, medications, treatment procedures) are combined with relatively static patient’s personal information (demographic, family history, social history), into a visit summary. At the next level, the entire visit history for that patient at this point of care is incorporated. Finally, all patient records from all source EHR systems are added together to form PHR.

In fact, the first and second levels of aggregation can be found in most EHR applications. There is still work ahead of us to simplify and automate communication between them and, for example, lab or bedside monitoring systems. Eventually, that will depend on the architecture of each EHR system, and is not going to be covered by interoperability standards. This means that the internal representation of patient data, the way it is stored, delivered and presented to the user, is up to the system vendor. Luckily, that is largely a technical task of establishing necessary protocols and data exchange formats.

It gets more complicated when we need to retrieve patient records created by another EHR system outside of our network. Basically, it does not matter if it is two blocks away or across the country, from a birds’-eye perspective, the process will look the same: to locate those records; send a request; get results. At a closer look, though, each of those steps has a number of actions involved, and architectural decisions have far-reaching implications.

For an EHR system, the capability to find external health records for a patient depends on access to a registry that links an identifier, which must be unique for each person, with all repositories where those records are stored. It either has to know that identifier, or should be able to get it based on the patient data it has. Basically, there are two choices: a nationwide patient number, which will be assigned at birth or on arrival to the U.S. with a proof of residence, or a Record Locator Service (RLS), that is to create a unique master index for every person and to tag all records for that person with it. The main objective against the nationwide identifier is that without proper identity verification process, it may be abused, much like SSN is, to gain access to somebody else’s medical records. As for RLS, it brings a few mostly technical issues. In general terms, it uses record matching techniques based on demographic information available in EHR. If certain fields are empty or contain incorrect values, they may return false positives or negatives.

The record retrieval process can also differ depending where the data is stored. If there is a centralized repository, containing copies of all medical records, it is relatively straightforward. The data management application

1. Authenticates the user (checks his credentials)
2. Authorizes him (grants access rights) based on his profile
3. Applies privacy protection rules (laws, regulations, patient consent instructions)
4. Formats results and sends them back to the requester
5. Creates audit records (who, what, when)

The most complex part of the workflow logic corresponds to steps 2 and 3. For example, an ED doctor requests health records on the out-of-state patient he currently cares for. If the state of residence has different disclosure rules than the one the patient is being treated in, which of them should apply? Should the doctor be allowed to see psychiatric records if the patient has apparent congestive heart failure?

Maintaining profiles of external users and implementing all that logic may prove too overwhelming for an individual EHR system in a pure P2P world. It makes a lot of sense to set up an intermediary that will handle most of that process. Each connected EHR system will only need to know a limited number of user categories, and what information has to be provided depending on which category the requesting user belongs to. In this framework, though, the big unknown is availability of source EHR systems, especially, in small hospitals and practices. Storing a copy of patient records at a local RHIO, much like in the centralized repository, will insulate the source EHR system from external requests, but the need for a record linking mechanism will still remain.

As far as clinical research and public health activities are concerned, where data mining and statistical analysis are applied against large volumes of data, a centralized repository of personal health records is the most efficient and, perhaps, secure option. Traditionally, researches receive anonymized, or de-identified, patient data directly from healthcare institutions. HIPAA allows for disclosure of de-identified records, but in a recently published paper, Paul Ohm of the University of Colorado Law School states that release of raw data does not guarantee necessary privacy protection, especially, if the data enters the public domain. In many cases, though, the end result of interest is computed statistics, bearing no links whatsoever with any personal information. By keeping data inside the repository, controlling and monitoring access to it, we have a better chance to avoid unintended consequences.

I tend to believe that there is no ideal architecture or technology that could perfectly meet all our needs, and personal health records are no exception. The law, policies and standards will continue developing, hopefully, with the goals, that I mentioned earlier, in sight.