Development of different types of standards and enabling them to become interoperable is a challenge for providers and software vendors. Getting these standards to harmonize-or complement each other with little overlap will be a major challenge.

Much of the task of harmonizing standards will fall on the newly established Health Information Technology Standards Panel (HITSP), a consortium of industry stakeholders. The federal government has contracted with the HITSP to facilitate the development of these standards according to a set of priority needs for IT, including EMRs. They wish to streamline the process, removing redundancy and unnecessary competition.

The complete medical record usually includes the following information:

• Patient demographics, which include non-medical information including identifying numbers, addresses, phone numbers, and insurance information. It may contain information about race and religion as well as workplace and type of occupational information.

• Medical history, which is a longitudinal record of what has happened to the patient since birth. It chronicles diseases and growth landmarks, giving the clinician a feel for what has happened before to the patient, and it may often give clues to current disease states.

• Surgical history, which is a chronical of surgical procedures performed on the patient. It should include dates, where it was performed, and a detailed narrative report of what was performed.

• Obstetric history, which includes prior pregnancies and their outcomes and complications.

• Immunization records should be chronicaled. Any blood, cutaneous, or radiological test should also be detailed (such as done for tuberculosis screening).

• Pediatric patient charts should include growth chart and developmental history , and compare these to children of similar age and sex. Additionally, a child's behavior (such as timing of talking, walking, etc) as it compares to other children of the same age is documented within the medical record for much the same reasons as growth.

• Medications and medical allergies.

• Family history, which is a detailed depiction of the health status of the immediate family members as well as their causes of death (if known). It may also list diseases common in the family or found only in one sex or the other. It is a valuable asset in predicting some outcomes for the patient.

• Social history describes the relationships of the patient, his/her careers and trainings, schooling and religious training. It is helpful for the physician to know what sorts of  support the patient might expect during a major illness. It may explain the behavior of the patient in relation to illness or loss. It may also give clues as to the cause of an illness (ie occupational exposure to asbestos). It usually includes the patient habits which impact the health, especially a history of smoking, excessive drinkinig, and/or drug abuse. Exercise and diet could be detailed, as well as sexual habits and performance.

• Physical examination, including the vital sign and organ system physical findings, performed and documented by a physician, a nurse practicioner, a physician assistant, or other health care provider.

Medical encounters are usually included, and are discrete summaries of a patient visit. Various different encounters exist, including the hospital admission or discharge, and the consultation. These usually are detailed informative summaries.

The progress note, or the routine patient encounter, on the other hand, may take a shorter problem-oriented record, which includes a “SOAP” note type of documentation which generally contain the aspects below:

• The chief complaint, which represents the problem that has brought the patient to see the doctor. Information on the nature and duration of the problem should be explored.

• History of the present illness, which is a detailed exploration of the symptoms that the patient is experiencing which have caused the patient to seek medical attention.

• A physical examination, which examines different organ systems, but especially the ones which might directly be responsible for the symptoms that the patient is experiencing.

• An assessment and plan which lists the active diagnoses and explains the most likely causes of the patient's current set of symptoms.

• The plan documents the expected course of action to address the symptoms (diagnosis, treatment, etc.). This often includes the dietary and medication orders as well as referals for further specialized care.

CCR

            Health I.T. interoperability will be a priority that will come in the next 2 to 5 years. The CCR is the standard promulgated by the American Society for Testing and Materials (“ASTM”) and endorsed by the Massachusetts Medical Society, the American Medical Association (“AMA”), the American College of Physicians (“ACP”) and the American Academy of Family Physicians (“AAFP”). It has also been enthusiastically endorsed by the electronic medical record (“EMR”) vendor community.

            The CCR is a modern extensible markup language (“XML”) dataset standard that represents a quick “snapshot in time” of a patient’s summary health information. This information includes the problem list, allergies, medication list, patient’s healthcare providers, plan of care and advanced directives among other inportant patient record data. The CCR is being used today to transfer summary patient information to the next healthcare provider whenever a patient is referred, transferred, or otherwise uses different clinics, hospitals, or other providers. This will bring an end to the process by which physicians and other healthcare professionals have to act “blindly”, without easy access to relevant patient information. It will provide the necessary information to support continuity of care, thus reducing medical errors, achieving higher efficiency, and creating better quality of care. It is not intended to replace or compete with the full electronic medical record.

            This CCR is a mechanism by which we could achieve interoperability of a critical component of patient information. No vendor or government entity should be entrusted with this responsibility. The AMA and/or the AAFP are the logical organizations to assume this role. The design by which this could be accomplished is fundamentally simple and sound, much like the CCR itself. A host site would maintain CCR snapshots of patient health information. Each time a patient visit occurred, a new CCR would be uploaded to the site by the ‘generating’ EHR software. This would create a history of patient treatment and health history over time. To comply with the Health Insurance Portability and Accountability Act (“HIPAA”) patient privacy standard, no patient identifying information would reside on the same server as the CCR. A separate server would house the patient identifying information. The information would be tied together with an encrypted key that could only be unlocked by the patient via a password. In the case of an emergency, if the patient password were not available, an authorized entity would be available to assist in making the CCR information available, with appropriate audit trail and notification of authorities/administrators.

            Each CCR certified EHR would, upon patient check-in and submission of a password, check the CCR server and download the latest CCR patient health record. These CCR components would be parsed into the electronic medical record for addition (or rejection of duplicate/superfluous parts) by the provider and at the conclusion of a patient visit a new CCR would be created and automatically uploaded to the CCR server. The process would initiate at patient check in and finalize at patient check out. It would occur automatically in the background – a critical requirement if CCR is to be broadly adopted and useful. The cost of maintaining a CCR per patient is probably on the order of a few cents per patient per year after the initial costs of configuring the environment. The likelihood of a security breech if patient data and identifying information are maintained on separate servers with appropriate physical barriers is remote. Ideally, one site would be used to store CCR records and this simplicity would allow vendors to quickly and easily encode this automated software functionality into their applications. The CCR server would be stored at the AMA website, the AAFP, the Centers for Disease Control (“CDC”), or alternatively the geographically defined Regional Health Information Organizations (“RHIO”) could be used to store local CCR records linked via a national entity.

            CCR is working today, but it remains largely for show. CCR has the potential to save billions of dollars in healthcare costs by eliminating duplicate tests, by allowing for less reliance on copying records, by saving on standard or express mail services to transfer medical records, and by reducing the  risk of legal exposure due to a lack of current or accurate patient information. Likewise, CCR has the potential to measurably improve patient care and eliminate certain types of patient injury. Without an active CCR with a centralized repository, the goal of reducing medical errors, achieving higher efficiency, and creating better quality of care will never be achieved. Without a plan to automate the process however, CCR will remain largely unused, eventually to become orphaned for lack of attention. A national focus on this initiative is thus not only mandatory, but resources to expedite this initiative should be allocated accordingly.

            Some points concerning the CCR initiative:

1. The main reason disease for the CCR initiative is to provide for for continuity of care or wherever the patient obtains his or her healthcare.

2. The CCR is a summary of patient's record in one point in time and is not intended to replace or compete with the full electronic medical record.

3. The CCR will allow for increased interoperability among disparate EMR systems with minimal or no custom programming required.

4. The CCR may provide a cost savings by allowing for less reliance on standard or express mail services to transfer medical records.

5. The CCR may reduce the  risk of legal exposure due to a lack of current or accurate patient information.

CCR is important not just for improving patient care, but to demonstrate to physicians the value of interoperability.

Bibliography:

1. CCR Initiative http://www.emrupdate.com/forum/topic.asp?TOPIC_ID=3476&SearchTerms=ccr

2. Massachusetts Medical Society: Medical Society Leads the Way with Easy to Share Patient Records for Practitioners http://www.microsoft.com/resources/casestudies/CaseStudy.asp?CaseStudyID=14931

3. CCR white paper written together with Dr. David Winn and Mr. Matt Chase

PHR

The Personal Health Record (PHR) is an electronic application through which individuals can access, manage and share their private health information in a secure and confidential environment. It allows people to access and coordinate their lifelong health information and make appropriate parts of it available to those who need it. 

It is similar to the CCR in that it is a private /private collaborative project with the intention of developing a standardized data set for more efficient intercommunication of patient information. Like the CCR, both the physician and the patient will be able to enter in information. Both the PHR and the CCR are in their infancies, but the PHR is represented by several different models at different levels of market acceptance while the CCR is an XML-based standard.

In September 2002 the Markle Foundation established Connecting for Health, a public-private collaborative whose purpose is to “bring greater visibility and coordination to the many government, provider and industry efforts to speed up the adoption of electronically connected health information systems.” They wish to "transform the US healthcare system into a safer, more efficient, consumer-driven healthcare system, and the PHR will be a valuable asset to individuals and families, enabling them to integrate and manage their healthcare information through secure, standardized tools."

There are several phases to this project:

·        Phase 1 of the project included a recommendation to engage the American public in this endeavor, with a more specific objective of developing personal health records. Establishing a common data set is a vital starting point. The Phase I working group has outlined seven areas to focus their energies on:

1.      Each person controls his/her own PHR. Individuals can decide which parts of their PHR can be eccessed, by whom and for how long along.

2.      PHRs contain information for one’s entire lifetime.

3.      PHRs contain information from all health-care providers. 

4.      PHRs are accessible from any place in a time.

5.      PHRs are private and secure

6.      PHRs are “transparent”.  Individuals can see who entered each piece of data, where it was transferred from and who viewed it.

7.      PHRs permit easy exchange of information with other health information systems and health professionals.

·        Phase 2 of the collaborative project included the formation of the working group on policies for electronic information sharing between doctors and patients.

The working group reported several findings, including:

·        PHR development should be accelerated.

·        PHRs will help increase consumer health awareness, activation, and safety.

·        There is no single pathway to a universal PHR.

·        A common data set is a vital starting point.

There are 6 aspects of the PHR:

(see next page)

Typical information found in PHRs who may include:

–        Date of consult, referring and referred to physicians, reason for consult.

–        Demographic information such as name DOB, address, telephone number.

–        Insurance information regarding eligibility and coverage.

–        Advance directives, DNR orders, emergency contact, s.a. next of kin.

–        Patient health status and preventive reminder information

–        Active problems

–        Social and family history (including religious affiliations)

–        Medications, immunizations, allergies, drug interaction listings and Rx refills

–        Laboratory, radiology, and other test results

–        PMH summmary (including hospitalizations and surgeries)

–        Visit summaries

–        Planned treatments, goals of therapy

–        Physician notes and other narrative information

In January, 2005 a workgroup was formed under the auspices of the American Health Information Management Association (AHIMA), Chicago, to define the PHR. This summer, the workgroup, represented by Smith and Wolter, released the results of deliberations. The workgroup announced the PHR as an "electronic, lifelong resource of health information needed by individuals to make health decisions. Individuals own and manage the information in the PHR, which comes from healthcare providers and the individual. The PHR is maintained in a secure and private environment with the individual determining rights of access. The PHR does not replace the legal record of any provider."

Bibliography:

1. The Role of the Personal Health Record in the HER. http://library.ahima.org/xpedio/groups/public/documents/ahima/pub_bok1_027539.html
2. Attributes of the  PHR. http://library.ahima.org/xpedio/groups/public/documents/ahima/pub_bok1_027455.html
3. CONNECTING AMERICANS TO THEIR HEALTHCARE: Final Report. Working Group on Policies for Electronic Information Sharing Between Doctors and Patients, July 2004. Document URL: wg_eis_final_report_0704.pdf.
4. Marietti, C. “The PMR Defined”. Healthcare Informatics Extra. http://us.f308.mail.yahoo.com/ym/ShowLetter?MsgId=8852_3755282_197630_1653_6298_0_109241_21170_2877622579&Idx=11&YY=7964&inc=200&order=down&sort=date&pos=0&view=&head=&box=Inbox

HIPAA

The shift of medical records from paper to electronic formats has increased the potential for individuals to access, use, and disclose sensitive personal health data for malicious purposes. Medical entities have long tried to protect individual here in the United States, but it has long been felt that previous legal protections at the federal, tribal, state, and local levels were inconsistent and inadequate. EMR standards being given too little attention to the area of data security.The Health Insurance Portability and Accountability Act of 1996 (HIPAA) security and privacy rules set broad guidelines for protecting medical information, and do not provide guidance down to the granular level of data standards. So the degree of security varies depending on the work done by software vendors and I.T. staff at health organizations.

In 1996 the U.S. Department of Health and Human Services (DHHS) addressed these concerns with new privacy standards that set a national minimum of basic protections, while balancing individual needs with those of society. The HIPAA was adopted to ensure health insurance coverage after leaving an employer and also to provide standards for facilitating health-care--related electronic transactions. To improve the efficiency and effectiveness of the health-care system, HIPAA included administrative simplification provisions that required DHHS to adopt national standards for electronic health-care transactions. At the same time, Congress recognized that advances in electronic technology could erode the privacy of health information. Consequently, Congress incorporated into HIPAA provisions that mandated adoption of federal privacy protections for certain individually identifiable health information.

The HIPAA Privacy Rule (Standards for Privacy of Individually Identifiable Health Information) (3) provides the first national standards for protecting the privacy of health information. The Privacy Rule regulates how certain entities, called covered entities, use and disclose certain individually identifiable health information, called protected health information (PHI). PHI is individually identifiable health information that is transmitted or maintained in any form or medium (e.g., electronic, paper, or oral), but excludes certain educational records and employment records. Among other provisions, the Privacy Rule

• Gives patients more control over their health information;

• Sets boundaries on the use and release of health records;

• Establishes appropriate safeguards that the majority of health-care providers and others must achieve to protect the privacy of health information;

• Holds violators accountable with civil and criminal penalties that can be imposed if they violate patients' privacy rights;

• Strikes a balance when public health responsibilities support disclosure of certain forms of data;

• Enables patients to make informed choices based on how individual health information may be used;

• Enables patients to find out how their information may be used and what disclosures of their information have been made;

• Generally limits release of information to the minimum reasonably needed for the purpose of the disclosure;

• Generally gives patients the right to obtain a copy of their own health records and request corrections; and

• Empowers individuals to control certain uses and disclosures of their health information.

The deadline to comply with the Privacy Rule is April 14, 2003, for the majority of the three types of covered entities specified by the rule [45 CFR § 160.102]. The covered entities are

• health plans,

• health-care clearinghouses, and

• health-care providers who transmit health information in electronic form in connection with certain transactions.

At DHHS, the Office for Civil Rights (OCR) has oversight and enforcement responsibilities for the Privacy Rule. Comprehensive guidance and OCR answers to hundreds of questions are available at http://www.hhs.gov/ocr/hipaa (1,3).

If you go to the DHHS website URLs noted in the bibliography (1,3), you can read up on other issues, such as:

• Who is specifically is covered, and which entities aren’t.

• What constitutes “protected health information” (PHI).

• Can my PHI be disclosed without my authorization? (5)

      HIPAA is changing the way medical facilities do business, but unfortunately the federal government has mentioned the importance of privacy, but has said very little specifics about how to comply. Several EMR companies state that they have been “certified” by one group or another, but the actual meaning/value of this certification is really unknown. Certain basic ideas should be given attention in the framework of any modern EMR:

1. Under the Privacy Rule, patients have the right to adequate notice of the uses and disclosures of their private health information that may be made by “the covered entity” (s.a. the provider), as well as their rights and the covered entity's legal obligations. Notices must be in plain language and clearly posted. Certain covered entities must make a good faith effort to obtain an individual's acknowledgment of receipt of this notice. In certain cases, notice may be provided electronically… i.e. via your EMR.
2. HIPAA requires restricted access to sensitive data, including password protection. The minimal level of this protection has not yet been established, but most systems in hospitals have upped the difficulty of entering into a computer to including both password protection at the level of Windows logon and later to the software logon.
3. Encryption of emails, faxes, and other document transmissions should be considered, although difficult. If you encrypt an email, for example, how will the patient, physician, or hospital receiving entity decript the message?
4. You should add the capability to track the use or users of protected health information.
5. For billing, any electronically transmitted information should be encrypted, and if you use an intermediary, make sure that they use HIPAA-compliant ANSI format e-billing forms.
6. Should you have to provide documentation to a legal entity, s.a. during a lawsuit, you should be able to set user restrictions to only the patient data needed, making the rest of the EMR patient data locked.
7. You should make sure that users know how to report to the covered entity any use or disclosure of the information, in violation of the agreement, of which it becomes aware.

On April 18, 2005, the Department published a Notice of Proposed Rulemaking which proposes the bases and procedures for imposinlg civil money penalties on covered entities that violate any of the HIPAA Administrative Simplification Rules. (4)

HIPAA Regulation Status As of October 1, 2004

HIPAA Regulation	Proposed Rule Publication	Final Rule Publication	Expected Compliance Date
Privacy and Patient Confidentiality	November 3, 1999	December 28, 2000	April 14, 2003*
Standards for Electronic Transactions	May 7, 1998	August 17, 2000 (addenda published February 20, 2003)	October 16, 2003 (for those filing an extension)
Medicare Billing	N/A	August 15, 2003	October 16, 2003
National Standard Employer Identifier	June 16 , 1998	May 31, 2002	July 30, 2004*
Security Standards	August 12, 1998	February 20, 2003	April 21, 2005*
National Standard Provider Identifier	May 7, 1998	January 23, 2004	May 23, 2007*
Standards for Electronic Claims Attachments	Expected 2005	Expected 2006-2007	2008-2009*
National Standard Health Plan Identifier	Expected 2005	Expected 2006-2007	2008-2009*
Enforcement			To be effective with each final rule
National Individual Health Identifier	On Hold
Patient Medical Record Information	2005-2006?

*Small health plans have an additional year to comply.

Bibliography:

1. HIPAA Privacy Rule and Public Health Guidance from CDC and the U.S. Department of Health and Human Services* http://www.cdc.gov/mmwr/preview/mmwrhtml/m2e411a1.htm
2. Department of Health and Human Services, Office of the Assistant Secretary for Planning and Evaluation Administrative Simplification in the Health Care Industry http://aspe.os.dhhs.gov/admnsimp/index.shtml
3. Office for Civil Rights – HIPAA Medical Privacy - National Standards to Protect the Privacy of Personal Health Information FAQ Page http://www.hhs.gov/ocr/hipaa/
4. HIPAA Administrative Simplification – Enforcement (HIPAA Enforcement NPRM published ) http://www.cms.hhs.gov/hipaa/hipaa2/enforcement/default.asp
5. HIPAA Basics: Medical Privacy in the Electronic Age http://www.privacyrights.org/fs/fs8a-hipaa.htm#3
6. HIMSS Advocacy News http://www.himss.org/advocacy/news_tracker.asp

HL7

Health Level Seven is both an American National Standards Institute (ANSI)-accredited standards organization and a standard. The organization, founded in 1987 with a mission “to provide standards for the exchange, management and integration of data that support clinical patient care, and the management and delivery of healthcare services by defining the protocol for exchanging clinical data between diverse healthcare information systems. The HL7 organization works through volunteer efforts to create flexible, cost-effective approaches, standards, guidelines, methodologies and related services for interoperability between healthcare information systems.”

As a standard, HL7 is widely accepted and used by many institutions. Since its creation, this standard has grown from a user-based consensus standard to an international standard with affiliate groups in Australia, Canada, Finland, Germany, India, The Netherlands, New Zealand, South Africa and the United Kingdom. Named as the most widely used standard among healthcare providers in a 1998 survey of 153 CIOs sponsored by the College of Healthcare Information Management Executives (CHIME) and HCIA Inc., HL7 has cut costs and facilitated interconnectivity.

Currently Microsoft seems to be very interested in HL7, offering its BizTalk Accelerator for HL7 and eventually will be extending this functionality to its Office 2003 System via InfoPath’s XML capabilities. There are numerous companies that offer HL7 custom made solutions, all of which are somewhat pricy, costing anywhere from $5000.00 to over $30000.00.

The HL7 can be similar to the CCR in that it represents a transferable health record remains more theory than reality due to the unsuitability of the HL7 as a  reliable standard that can be used as an inexpensive, quick and easy health record by various disparate electronic health record (“EHR”) softwares.  The HL7 is an internationally acknowledged specification that is both complex and flexible, making it an inherently a poor CCR-like health record standard. If another vendor wishes to import a CCR-like health record using HL7’s clinical document architecture (“CDA”), they require a costly, proprietary interface or bridge which often requires a great deal of programming “tweaking” to make the connection work. Hospitals and large medical groups can afford this added programming cost, but that is not the case in the typical small to medium sized physician office, where interoperability is most desperately needed.  The CCR, on the other hand, is a tight, well defined, easily applied standard that allows sharing of patient information ubiquitously among CCR certified EHRs. This makes the standard not only reliable, but inexpensive, or even free.

Bibliography:

1. HL7.org http://www.hl7.org/ehr/
2. Microsoft Biztalk Accelerator for HL7 http://www.microsoft.com/biztalk/evaluation/hl7/default.mspx
3. Microsoft InfoPath 2003: Health Level Seven Clinical Document Architecture http://www.microsoft.com/technet/itsolutions/cits/iwp/cda/hl7cda06.mspx
4. Healthcare Informatics Online: HL7 in the 21^st Century. http://www.healthcare-informatics.com/issues/2000/04_00/hl7.htm

CCHIT

From the CCHIT website homepage:

“The mission of CCHIT is to accelerate the adoption of robust, interoperable HIT throughout the US healthcare system, by creating an efficient, credible, sustainable mechanism for the certification of HIT products.”

In an Executive Order issued April 27, 2004, President George W. Bush called for widespread deployment of health information technology within 10 years, and shortly afterward appointed David J. Brailer, MD, PhD, as National Coordinator for Health Information Technology. On July 21, Dr. Brailer released a landmark report: The Decade of Health Information Technology: Delivering Consumer-centric and Information-rich Health Care (accessible at: http://www.hhs.gov/onchit/framework/) setting forth twelve strategies for improving healthcare, organized around four broad goals. One of the key actions listed to support those goals was the private sector certification of health information technology products.

In response to this clear opportunity, recently brought into sharp focus by federal and private sector healthcare leaders, three leading industry associations in healthcare information management and technology - AHIMA, HIMSS, and The Alliance (formerly NAHIT) - have joined forces to launch The Certification Commission for Healthcare Information Technology. The three associations have committed funding and staff to support the Commission during its organizational phase.

The purpose of The Commission is to create an efficient, credible, sustainable mechanism for the certification of healthcare information technology products. The goals of product certification are:

1. To reduce the risk of HIT investment by providers.

2. To ensure interoperability of HIT products with emerging local and national health information infrastructures.

3. To enhance the availability of HIT incentives from public and private purchasers/payers.

4. To accelerate the adoption of robust, interoperable HIT throughout the US healthcare system.

Significant controversies have surfaced:

1. This is going to add to the overall cost of developing an EMR. Discussion at CCHIT is to try and keep the certification cost at or below $25,000. Ultimately the cost of doing businees is borne by the end-user. To survive, vendors will have to either raise price or increase sales volume. All EHR manufacturers will have to start imbedding additional knowledge bases that will add an estimated additional $5000, to $20,000 per doc annually to all EHRs. See http://healthdatamanagement.com/html/news/NewsStory.cfm?DID=12734

2. Physician participation is limited. The committees are dominated by entities other than clinicians who understand the real word of health care in the trenches.

3. CCHIT will unecessarily restrict the use of electronic technology while adding another level of complexity to the average EMR product.

4. The committee members who are insisting on a very rich feature set for certification are physicians using high end EHRs like NextGen and PMSI. This could be a move to lock out the smaller, less expensive EMR companies who represent economical competitors who offer less functionality for a lower cost. Of interest, the chair woman of one workgroup (an internist) was subsequently accepted a paid position with NextGen.

5. Just how can they "accelerate the adoption of robust, interoperable HIT throughout the US healthcare system," when major impediments to getting any HIT in place include: 1) cost; and 2) our inability to gain consensus about optimal data stuctures.

6. We already have numerous methods / regulations including HIPAA, CCR, and HL7 that were adopted for improved “interoperability” that still need to be adopted more fully by the medical community. Why add another layer?

7. Some have mentioned that EHRVA (a powerful group of high end vendors) and CCHIT may be trying to kill CCR (AAFPs/AMAs version of how to implement interoperability).How will CCHIT impact on your ability to write/use your own application as your office EMR or to use paper or a hybrid system? I personally believe that CCHIT will fail once physicians realize that expensive CCHIT-certified EHR systems will only be helpful to third parties, s.a. CMS or HMOs/PPOs. Pay for Performance schemes are unpopular and frequently fail to pay or when they do pay, the amount is small.

21 CFR Part 11, Electronic Records, Electronic Signature

In March 1997, FDA published final Part 11 regulations on electronic records and electronic signatures. Part 11 applies to all FDA program areas (including medical devices, drugs, biologics, active pharmaceutical ingredients, foods, cosmetics, and veterinary medicines sold in the United States or available here during clinical trials). The original intent of the rule was to permit the widest possible use of electronic technology while still protecting public health. The rule became effective August 20, 1997.

In February 2003, FDA withdrew five draft guidance documents on Part 11, as well as its compliance policy guide on the rule (CPG 7153.17). At the same time it issued a new draft guidance narrowing the scope of the regulation. (The withdrawn guidances included ones on validation, glossary of terms, time stamps, maintenance of electronic records, and electronic copies of electronic records.) FDA states that it does not intend to reissue any of the withdrawn guidances or the CPG; its August 2003 scope and application—guidances discussed in this article—provides its current Part 11 enforcement policy.

Part 11 applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted to meet records requirements in FDA regulations. Part 11 also applies to electronic records submitted to FDA, even if those records are not specifically identified in FDA regulations. Thus, if companies choose to keep any required records electronically or to submit records electronically to FDA, they must comply with Part 11. The underlying (or base) regulations are called the predicate rules. These rules cover good manufacturing practices (GMPs), good laboratory practices (GLPs), good clinical practices (GCPs), marketing and labeling requirements, and so on.

One of the major changes in the new guidance is that Part 11 applies to the records and electronic signatures, not to the computer systems themselves. Under this narrower interpretation, FDA considers Part 11 to apply only to the following:

• Records required to be kept per predicate rules and kept in electronic form rather than in paper. Records not required by predicate rules but kept electronically are not Part 11 records. FDA recommends that manufacturers determine and document which records are Part 11 records. The starting place of a Part 11 assessment should be determining and documenting which electronic records are maintained for GxP GMP, GLP, or GCP purposes.

• Records required by predicate rules and kept electronically as well as in paper, and which are relied on to perform regulated tasks.

• Records sent to FDA in electronic format to meet predicate rules (even if those records are not identified in the predicate rules). If a record is not submitted but is used to generate the submission, it is not a Part 11 record unless the manufacturer must keep it per a predicate rule and it is being kept in an electronic form.

• Electronic signatures intended to be the equivalent of handwritten signatures, initials, and other signings required by predicate rules. So, if a company is using electronic signatures, it must comply with Part 11. The FDA guidance adds that Part 11 signatures include electronic signatures that the company uses to document certain events required by predicate rules (such as approval, review, verification, etc.) FDA adds that “actual business practices may dictate whether you are using electronic records instead of paper records.” It also adds that “when persons use computers to generate paper printouts of electronic records, and those paper records meet all the requirements of the applicable predicate rules and persons rely on the paper records to perform its regulated activities, FDA would generally not consider persons to be ‘using electronic records in lieu of paper records’” under 11.2(a) and 11.2(b). Per FDA, in these instances, the use of computer systems to generate paper records would not invoke Part 11.

However, if a device manufacturer or its employees rely on the electronic record to perform regulated activities, FDA may consider the manufacturer to be using the electronic record instead of the paper record. FDA recommends that for each record kept to meet predicate rules, the manufacturer determine in advance whether it plans to rely on either the electronic or the paper record to perform regulated tasks. It recommends that the manufacturer document its decision in a standard operating procedure or a specification.

It is advisable that the company implement a thorough training program: The company should audit and monitor to make sure that everyone is not only using the current version of the record, but also the version that the company wants used (i.e., electronic or paper).

An interesting note is that even though FDA recently withdrew its previous guidance on time stamps, the agency still believes one of the key points presented in that guidance: that when a manufacturer uses time stamps for systems spanning different time zones, it does not have to record the signer’s local time. Instead, FDA recommends that the company implement time stamps with a clear understanding of the time zone used. Systems documentation should explain the time zone references as well as the acronyms or other naming conventions.

FDA has narrowed its current approach down to three main points:

• Part 11 will be interpreted narrowly. FDA is now clarifying that fewer records will be considered subject to Part 11.

• For those records subject to Part 11, FDA intends to exercise enforcement discretion regarding Part 11 requirements for validation, audit trails, record retention, and record copying, and with regard to all Part 11 requirements for systems operational before the effective date of Part 11 (also known as legacy systems).

• FDA will continue to enforce all predicate rule requirements, including predicate rule record and recordkeeping requirements. As far as I am aware, no EHRs today have 21 CFR Part 11 certification.  Proposed CCHIT security requirements in the 2007-2008 time frame may make it possible for EHRs to be used for electronic maintenance of research data. However, even then, FDA certification may be cost prohibitive.

    Bibliography:

1. EMRUpdate.com: Part 11 Compliance http://www.emrupdate.com/forum/topic.asp TOPIC_ID=3533&SearchTerms=part,11

2. Main page at 21 CFR Part 11 http://www.21cfrpart11.com/

3. Medical DeviceLink: Regulatory Outlook Part 11: New Guidance Provides Little Guidance http://www.devicelink.com/mddi/archive/04/01/001.html

4. US Food and Drug Administration http://www.fda.gov/ora/compliance_ref/part11/
    

Electronic Medical Information Databases

The following is a showcase of medical information databases are used by many EMRs to add medical content to help in patient care. As a physician still in practice seeing patients, I personally feel that most basic EMRs that allow for freehand inking and text placement are what most physicians prefer to use.  

The granular databases do have their role, though, in making the exchange of discreet clinical data easier and with practice management software used to bill insurance companies. Incorporating granular data to make clinical decisions is costly, and unless subsidized by the government will never see widespread adoption. For clinical information, most physicians still prefer to use inexpensive PDAs, desktop or laptop computer software. In this manner, the data is cheaper to purchase, frequently easier to use, and, as in the case of PDAs, more accessible.

• ICD-10

The International Classification of Diseases, 10th Edition code set (ICD-10) is slowly becoming adopted by the insurance industry and the federal government for use in delineating diagnosis and procedural codes. It is  has far more detailed coding elements than the currently used and older ICD-9 codeset that now is nearly 3 decades old. Its use in EMRs can make data mining more productive for research and analysis of patient care data, and it is felt that now is the time to adopt ICD-10 as data standards for EMRs are being developed. ICD-9 has 11,000 diagnosis codes compared with ICD-10's 120,000; and 13,000 procedure codes compared with 87,000 in the new set. The larger code set gives far more data specificity for treatment, research and reimbursement purposes, but may make the documentation and eventual payment by a medical practice cumbersome, slow, and could dramatically increase the cost of billing and collections.

The National Committee on Vital and Health Statistics, an advisory body to the Department of Health and Human Services (NCVHS) commissioned a study that showed adopting ICD-10 would cost $425 million to $1.15 billion, with 10-year benefits of $700 million to $7.7 billion. One way or another, HHS has not taken action on ICD-10. Now, legislation before Congress, H.R. 4157, would mandate adoption of ICD-10 by October 2009, although there is a good chance the legislation will be enacted by 2007. The Blue Cross and Blue Shield Association wants to delay the adoption of the ICD-10 codes to October, 2012.

URL: http://www.healthdatamanagement.com/html/current/CurrentIssueStory.cfm?articleId=13354

• SNOMED

The U.S. government has made SNOMED-CT clinical vocabulary available free to clinicians in an effort to encourage it as a standard for recording a large portion of clinical information. The SNOMED CT Core terminology contains over 366,170 health care concepts with unique meanings and formal logic-based definitions organized into hierarchies. As of July 2005, the fully populated table with unique descriptions for each concept contains more than 993,420 descriptions. Approximately 1.46 million semantic relationships exist to enable reliability and consistency of data retrieval. It is  designed for highly trained clinicians and medical libraries, not consumers as are the PHR and CCR initiatives.

SNOMED International is a division of the College of American Pathologists (CAP) who wishes to focus on advancing excellence in patient care through the delivery of a “Systemized Nomenclature of Medicine”. Among the applications for SNOMED CT are electronic medical records, ICU monitoring, clinical decision support, medical research studies, clinical trials, computerized physician order entry, disease surveillance, image indexing and consumer health information services.

One recent study published in the Mayo Clinic Proceedings looked at the ability of SNOMED clinical terms to correctly represent clinical problem lists. THey found that of the 4996 problems in the test set, the overall sensitivity was 92.3% with a specificity of 80%. They suggested that health care organizations be encouraged and be provided incentives to begin adopting SNOMED CT to drive their decision-support applications.

URL: 

1. http://www.snomed.org/snomedct/index.html
2. Elkin PL et al. “Evaluation of the Content Coverage of SNOMED CT: Ability of SNOMED Clinical Terms to Represent Clinical Problem Lists”, Mayo Clin Proc. 2006;81:741-748. URL:  http://www.mayoclinicproceedings.com/Abstract.asp?AID=2481&Abst=Abstract&UID

• LOINC

LOINC is a medical database developed by the Regenstreif Institute for Health Care ("RI") in an effort to facilitate the exchange and pooling of data such as laboratory results and vital signs for use in clinical care, outcomes management, and research. Although they perform many of the activities of the HL7 initiative, the developers state that the LOINC codes are more universal in scope.

Of interest, the RI has been developing the Regenstrief Medical Records System for the past 30 years which represents one of the nation's first EMRs and serves as a keystone of EMR-related activities.

Dr. David Winn, CEO of e-MD’s has been trying to begin a movement to make the LOINC 30,000 + codes database a standard on which to map a lab interchange onto a common subset (representing 99.5%) of labs that we commonly order in the outpatient, ambulatory setting. The task is daunting, though, and its ability to succeed universally in the clinical outpatient setting is low.

URL: http://www.regenstrief.org/loinc

• RXNORM

RxNorm was developed in 2001 by the United States National Library of Medicine to provide a database of standard names for clinical drugs (active ingredient + strength + dose form) and for dose forms as administered to a patient. RxNorm is one of a suite of designated standards and is part of the Unified Medical Language System for use in U.S. Federal Government systems for the electronic exchange of clinical health information.

RxNav is a sister product developed in Java to function as a standalone application to connect the RxNorm server at the National Library of Medicine.

URL: http://www.nlm.nih.gov/research/umls/rxnorm_main.html

• PIER

Physicians' Information and Education Resource (PIER): is an electronic medical resource from the American College of Physicians designed for rapid electronic access to clinical information at the point of care. It is written in XML and is available as a free-standing resource on the Web and on PDAs. It is designed to integrate with electronic medical records, order entry systems, hospital information systems, practice management systems.  Although it can be integrated and used as medical content in any EMR, its primary purpose seems more to be for teaching and “lifelong learning”  rather than for help in documenting patient care. There are several module types:

• Disease

• Screening and Prevention

• Complementary and Alternative Medicine

• Ethical and Legal Issues

• Procedures

• Drug Resource

• Clinical Presentations: Flow-diagram approaches to diagnosing undifferentiated symptoms, signs, and laboratory abnormalities (not yet available)

URL: http://pier.acponline.org/info/pierinf_integration.html

• CPOE

CPOE is a database system designed by the Physician Order Entry Team (POET) at Oregon Health & Science University, funded by a grant from the National Library of Medicine to study success factors for implementing Physician Order Entry (POE). Two initial trials, one at Los Angeles-based Cedar Sinai and the other at Children’s Hospital in Pittsburgh have unfortunately demonstrated that CPOE can be an onerous system not particularly liked by its physician users. In the case of the Cedars-Sinai Hospital, it demonstrates the "worst case scenario" where an institution paid upwards of $34 million dollars to use a system for only 3 months. There were many implimentation errors that occurred, including the nightmare of having to put up with an inflexible "medication error" checking software.

Thus the use of CPOE is far from becoming a widespread tool due to this reputation for being difficult to implement successfully. The use of computerized physician/provider order entry (CPOE) continues to be increasingly encouraged in an effort to decrease medical errors and to many seems the next logical step in terms of widening the value of information system technology..  Certainly the industry has learned that patience has to be part of the implementation process, and that the goal shouldn’t be to be 100 percent CPOE in some pre-determined timeframe.

URL:  http://www.ohsu.edu/dmice/research/cpoe/index.shtml
URL: http://www.washingtonpost.com/wp-dyn/articles/A52384-2005Mar20.html?sub=AR

• DOQ-IT

The Doctors' Office Quality Information Technology (DOQ-IT) is an effort designed to improve quality of care, patient safety, and efficiency for services provided to Medicare beneficiaries by promoting the adoption of Electronic Medical Records (EMR)/Electronic Health Records (EHR) and Information Technology (IT) in primary care physician offices. The importance of this is geared more towards the EHR and to those physicians wishing to augment their incomes by providing a certain predetermined standard of care.

The objectives of this project are to work with small to medium sized primary care offices providing them with assisatnce using the EHR to pull out health data that can be used to improve the health of their patient populations. The project has a set of healthcare quality measures that will be tracked. There are quality measure for diabetes, coronary heart disease, hypertension and preventive care items like vaccination status, colorectal screening, tobacco usage,and cancer screening.

Quality measures developed in the Doctors' Office Quality (DOQ) project will be reported by participating practices in DOQ-IT via standardized EHR platform to the QIO Clinical Warehouse. The QIO Clinical Warehouse will receive, review and validate electronically transmitted information regarding practitioner performance and identify opportunities for improvement. The data will be aggregated under the practice, and then, based on your score against quality of care standards, a lump sum sent on a periodic basis. Sort of like capitation checks, or IPA witholds.

Naturally, there is a lot of resistance to this type of government intrusion by the general physician community. Whether or not Medicare and HMOs can make this a pervasive safety and cost saving initiative will be determined in part by how much the insurance industry will be willing to fund this costly measure, offsetting the initial losses incurred by the physician community. On the whole though, this can be a really exciting initiative with the potential of benefiting both physicians and patients.

Other Issues: Protecting Against a Lawsuit

            Many professionally made EMRs fail to take into consideration the possibility of  a lawsuit. There are certain requirements or standards for a “legal record”. These rules are actually quite straightforward.  They are:

• It has to meet the well-established requirements of a medical record.

• It has to meet the well-established requirement of a computerized business record.

        A good reference about these requirements can be found at: "Maintaining a Legally Sound Health Record", a Practice Brief from the professional association of health information managers (medical records professionals) AHIMA, http://library.ahima.org/xpedio/groups/public/documents/ahima/pub_bok1_014041.html

                Their current practice briefs, like the one linked above, are in their public section and you will find a lot there about implementations and what to do when you have some parts electronic in one system, others in another system, and some on paper (as most of us will for some time yet.).

                The electronic medical record needs to follow certain business rules to decrease their risk of legal problems:

• One major issue overlooked frequently is the matter of when a bill is sent off, the patient workup needs to have been completed, not when it is ordered. Not only is this go against many private and Medicare rules, but if the test is not done at all (patient forgets and leaves, cannot urinate, etc.) and the test is dutifully billed, it would be difficult to explain to an auditor.

• Another issue concerns the EMR “evaluation and management” (EM) encounter forms. They need to be made to conform to the appropriate CPT code billing level. They need to also comply with AHIMA standards. The Medicare general and specialty score sheets on EM coding can be found at http://www.hgsa.com/professionals/emcd/ss_overview.htm .

• Reports ideally should be made retrospectively unchangable once signed. If a change is made, there should be the capability to date and sign the changes. Ideally, archiving the reports off-site at a neutral site (s.a. at the office of a lawyer) should be performed.

Last Thoughts: Snomed vs. Medcin

            These 2 are the most popular medical information databases, so they deserve further comparison. Their differences are subtle, except for cost, which may make the far less expenseve SnoMed more popular.

Comparison Element	SNOMED	MEDCIN
Original Design	Is designed for use by pathologists and epidemiologists as a classification system, as a reference terminology; very few SNOMED® terms are clinically meaningful by themselves, they have to be combined with other terms to give meaning.	This database is a clinical data index designed as a structured data entry at the point-of-care; it’s a nomenclature designed for direct use by physicians as an interface technology.
Years in Existence	25 years	25 years
Cost	$	$$$$ For a 2 physician, 2 year costm the total currently comes out to $49,760.00
Authors	The College of American Pathologists (CAP)	Medicomp Systems
Example References	"arm" and "pain"; “chest” and “pain”	"arm pain"; “chest pain”
Navigation	Navigation in SNOMED® can be very difficult unless all terms are pre-built for the user.	A word can be found by simply drilling "down the tree" of clinical propositions.
Mapping	Because SNOMED® builds clinical propositions out of smaller units it cannot map directly to other terminologies, such as CPT, nor can it generate E&M codes or address billing issues.	MEDCIN® is composed of clinical propositions which map very clearly to both CPT and E&M code4 bullets such as those in the CMS 1997 guidelines.
Native Tools	SNOMED® has no native tools.	MEDCIN® provides tools for building forms, narrative generation, and intelligent prompting.  It has over 270,000 terms is a clinically meaningful data concept, and all of them are linked to a diagnosis index containing more than 72 million clinically relevant associations.
Famous Companies Using Product	The government funds an EMR – VistA, which runs a codified language – SNOMED.  Other users include eMDs, HoltSystems EMR,	US Dept of Defense, Kaiser, WebMD,  Electronic Healthcare Systems, Allscripts, IMPAC, as well as several others (see http://www.medicomp.com/index_html.htm)
Summary	SnoMed is the leading candidate to become the standard vocabulary for EMRs for use in HMO data mining and for interoperability purposes.	MEDCIN is comprehensive SDK/Toolkit that will allow a reasonably good programming firm to incorporate Decision , at Support and extremely good codified data from a standardized data set of rules, but at a very expensive price.

        Generally, most of these differences are minor and can be rectified by good EMR programming with seamless integration of either program with the benefit of SNOMED being less added cost.