Uniform Data Standards for Patient Medical Record Information and the
Electronic Exchange of Such Information

Testimony to the National Council on Vital and Health Statistics

8-9 December 1998

Ralph A. Korpman, M.D.

Chief Scientist, Medaphis Corporation

CEO, Health Data Sciences Corporation

Gary L. Dickinson

Manager, Healthcare Standards

Per-Se Technologies

Table of Contents

Introduction and Background 3

Sources and Terms 7

Section I: Responses to Questions 8

Section II: Electronic Health Record Impediment Issues 13

Section II: Electronic Health Record Requirement Issues 21

Exhibit A: End-to-End Data Flows -- HL7 SIG on AQP 41

Exhibit B: The Business Case for Comprehensive EHR Standards 42

[Introduction]{.underline}

I am Ralph A. Korpman, M.D., Chairman and Chief Executive Officer of
Health Data Sciences Corporation (HDS), Chief Scientist of Medaphis
Corporation and Per-Se Technologies, and Professor at the Loma Linda
University School of Medicine. I am speaking today on behalf of HDS,
Medaphis, and Per-Se. We have previously testified before this Committee
with regard to HIPAA, but we believe that the issues now under
discussion are those that are perhaps the most critical to the future of
health care in this country.

[The Testimony]{.underline}

This document is comprised of an introduction, three body sections, and
two appendices. This introductory section provides the basic background
of the speaker, the testifying organizations, and the problem space.
(Immediately following the introductory section is a listing of terms
and references used in this paper.) Section I responds to the questions
posed by the Committee. Section II delineates the impediments to
achieving success in the standards area in electronic health record
systems. Section III provides an experience-based list of the factors to
be considered for successful implementation of a standards-based
electronic health record. Appendix A shows the end-to-end data flow
diagram of HL7 that must conceptually be considered in any electronic
health record standard. Appendix B provides general information on the
business case for electronic health records and electronic health record
standards.

[Background]{.underline}

Medaphis/Per-Se/HDS serves almost 2,000 hospitals and 20,000 physicians
and groups with a broad variety of products and services. These products
and services are delivered around the world, but are predominantly
delivered in the US, where both products and services are delivered in
all 50 states.

Among our products is a comprehensive health care electronic information
tool set known as UltiCare®, also sold in a more structured form as a
comprehensive enterprise-wide electronic health record system called
Patient1™. This extensive health care information system represents one
of the few installed and fully validated operations-optimizing systems
for health care in which all care venues (inpatient, home patient,
outpatient, call center, physician office, long term care, etc.) are
integrated in a single systems domain. The UltiCare/Patient1 systems
environment constitutes the primary clinical record and operations
support mechanism for over 20,000,000 patients, for whom it maintains
lifetime medical records. Ulticare/Patient1 is the information system
for several hundred acute and long-term care facilities in the US,
including: New York City Health and Hospitals Corporation, the nation's
second largest non-Federal health care system and its largest municipal
health care system; the William Beaumont Hospitals, a major integrated
delivery system in metropolitan Detroit; Foundation Health, the
country's fourth largest for-profit HMO; and Genesis Health, one of the
country's largest eldercare providers. UltiCare/Patient1 also supports
the third largest health care call center operation in the U.S., as well
as extensive home care operations.

The first UltiCare systems were installed in the late 1980's. Although
the technology used in the system has changed radically since that time,
no patient data has ever been expunged or rendered obsolete; the
UltiCare record *is* the patient's record. With 20,000,000 such records
in use and over 200,000 health professional users, we believe we have a
unique perspective on the pros and cons of the electronic health record.

HDS has also been involved in standards efforts for over 15 years. We
have always approached our work in this area as an eleemosynary
component of our corporate responsibility, and have repeatedly (and
often unpopularly) worked to steer standards efforts towards results
that can be "done once, done right, and used internationally". Standards
efforts has often periodically trended towards expediency or have been
overtaken by small groups seeking commercial advantage; history has
shown that such efforts are doomed to deliver so much less than promised
that they are generally not worth the trouble. Efforts with broader
vision and greater reliance upon usability and field verifications have
been far more successful. In fact, the checkered history of standards
efforts is, in part, the basis of this hearing. If successes were many
and uniform, a hearing would not be necessary.

# Why is the HIPAA Clinical Standards Effort Especially Important?

HIPAA is providing a vital rallying point for U.S. standardization
efforts in the field of healthcare informatics. To date, the
administrative simplification requirements that are a major part of
HIPAA have caused substantial focus on the engagement of trusted
electronic data interchange (EDI) (and interfaces) between health care
providers, health plans and payers. Importantly for the current clinical
standards effort, from a data flow perspective the HIPAA-focused EDI is
functionally downstream from the clinical electronic health record (EHR)
it references and from which it is (or should be) derived. Indeed the
clinical EHR is the potential source for *all* of the clinical content
in the proposed HIPAA transaction set, especially the claims attachment.

This derivative nature of the HIPAA administrative transactions makes
the upstream stewardship of the clinical EHR crucial to the ultimate
viability of the HIPAA administrative simplification mandate. Without
establishing trusted data at the source, all information will continue
to be suspect, perpetuating the well-understood "garbage in, garbage
out" data situation we find today. This HIPAA clinical standards effort
is the best opportunity we have seen in quite a while that might lead to
infrastructure guidelines that could go far to achieve the necessary
level of data trust. In addition, myriad other benefits, as set forth
below, will eventuate if properly implemented.

[Invitation and Testimony Objectives]{.underline}

The Health Insurance Portability and Accountability Act (HIPAA) of 1996
(U.S. Public Law 104-191) charges the Secretary with adopting standards
for specified administrative transactions, data elements for such
transactions, and supporting standards to enable health information to
be exchanged electronically. The purpose is to improve the \"efficiency
and effectiveness of the health care system, by encouraging the
development of a health information system through the establishment of
standards and requirements for the electronic transmission of certain
health information \...\" \[HIPAA, Section 261\]

HIPAA directs the National Committee on Vital and Health Statistics
(NCVHS) to assist and advise the Secretary and to \"study the issues
related to the adoption of uniform data standards for patient medical
record information and the electronic exchange of such information\" and
to \"report to the Secretary not later than 4 years after the date of
the enactment of the Health Insurance Portability and Accountability Act
of 1996 recommendations and legislative proposals for such standards and
electronic exchange..." \[HIPAA Section 263\]

# There are four areas of interest that have been identified for the NCVHS report:

1.  Guidelines and standards for administrative and clinical messages
    that contain patient medical record information and their formats.

2.  Guidelines and standards for patient clinical information (data
    element definitions, data models, code sets).

3.  Ways to enhance the coordination and maintenance of both
    administrative and clinically-specific code sets so that they can
    support the demands of a computer environment that requires
    continuous availability, greater interoperability, more timely
    updates, greater clinical specificity and greater accountability for
    quality. These are core data-dictionary and meta-data or data-set
    registry issues.

4.  Ways to address the business case issues regarding the
    implementation of uniform data standards for patient medical record
    information.

The NCVHS committee has posed five questions:

1.  How do you interpret the Congressional instruction?

2.  What factors or issues are preventing or delaying the development
    and widespread implementation of uniform standards for patient
    medical information and its electronic transmission. Explain.

3.  Is the private sector able to address these problems satisfactorily?
    In your opinion, what is the role of government for assisting the
    private sector in the guidance, development, coordination and
    implementation of standards for the patient medical record data and
    their electronic transmission? How might the government help to
    improve the standards processes?

4.  Which standards related to patient medical record information and
    its electronic transmission would:

```{=html}
<!-- -->
```
A)  Add the most value for improving the quality and efficiency of the
    health care for the nation?

B)  Be most important to the business or goals of your organization?
    Why?

C)  What is the business case for more rapid standards development and
    implementation?

```{=html}
<!-- -->
```
5.  Do you agree with our emphasis on the four focus areas listed above?
    Explain.

# Sources and Terms

Throughout this paper, the following acronyms are used, and the
following sources are quoted:

## *Terms*

ANSI American National Standards Institute

ASTM American Society for Testing Materials, Committee E31 on Healthcare
Informatics, an ANSI accredited SDO

AWG Andover Working Group, a consortia formed by Hewlett Packard

CCOW Clinical Context Object Working Group

CORBA OMG Common Object Request Broker Architecture

DHHS U.S. Department of Health and Human Services

ECF AWG Enterprise Communications Framework

EHR Electronic Health Record (also the Computer-Based Patient Record)

HL7 Health Level Seven, an ANSI accredited SDO

HIPAA Health Insurance Portability and Accountability Act of 1996, U.S.
Public Law 104-191

IOM U.S. Institute of Medicine

IT Information technology

JCAHO Joint Commission for the Accreditation of Healthcare Organizations

LCD Lowest common denominator

OMG Object Management Group

NCQA National Council for Quality Assurance

NCVHS U.S. National Council on Vital and Health Statistics

NHS U.K. National Health Service

NIH U.S. National Institutes of Health

SDO Standards Developing Organization, typically as accredited by ANSI

UMLS NIH Unified Meta Language System

### *References*

1.  ASTM E1762, *Standard Guide for Electronic Authentication of Health
    Care Information*, 1995

2.  ASTM E1769, *Standard Guide for Electronic Health Records and Record
    Systems*, 1995

3.  Health Level Seven Data Interchange Standard, Version 2.3, 1997

4.  Health Level Seven, Special Interest Group on Accountability,
    Quality and Performance

5.  Health Insurance Portability and Accountability Act of 1996 and
    proposed regulations related thereto

6.  HCFA Internet Security Policy, Final Version, November, 1998

7.  U.S. Institute of Medicine, *The Computer-Based Patient Record, An
    Essential Technology for Healthcare*, 1991, 1997

8.  JCAHO, *Comprehensive Accreditation Manual for Hospitals*, 1998

9.  U.K. National Health Service, "Information for Health, An
    Information Strategy for the Modern NHS", 1998

SECTION I: Responses to Questions

Question 1: How do you interpret the Congressional instruction?

1.1 Enumeration of Key Issues

The Congressional instruction requests the NCVHS to "study the issues
related to the adoption of uniform data standards for patient medical
record information and the electronic exchange of such information".
This suggests a wide-ranging discourse dealing with both requirements
and impediments. Section III of this paper offers an enumeration of key
issues in the context of requirements; Section II addresses the various
impediments and distractions that have plagued this process over the
years.

1.2 A Trusted Information Source, Downstream Data Flow

> It is clear that HIPAA EDI transaction sets set forth by Congress,
> especially in the context of clinical data in the claims attachment,
> will contain information only as good (and thus only as trustworthy)
> as its primary source -- typically the provider-based clinical EHR. It
> seems self-evident that Congress intended that HIPAA transaction sets
> downstream (in terms of data flow) from the clinical EHR should be
> able to rely on trusted information origination, stewardship and
> communication services from the point and moment of origination up to
> and including the point of triggering the transaction itself.

1.3 Applicability of Standards to the Electronic Health Record

> The Congressional instruction infers that the various "administrative
> simplification" standards mandated by HIPAA (identifiers,
> classifications, code sets, EDI transaction sets, privacy and
> confidentiality protections, security and access control, electronic
> signature) are also crucial design considerations for electronic
> health records and EHR systems.

1.4 Uniform Data Standards

Although the Congressional instruction specifies the "adoption of
uniform data standards", it is clear that the most restricted reading of
the words "data standards" will fail to provide the necessary solutions.
To solve the extant problems, applicable standards must exceed the
obvious baseline of uniform data content, extending to issues of trust,
of stewardship, of accountability, of data integrity (e.g., accuracy,
consistency, continuity, completeness, context, comparability), of
robust architectures, etc.

QUESTION 2: What factors or issues are preventing or delaying the
development and widespread implementation of uniform standards for
patient medical information and its electronic transmission. Explain.

A variety of technical and political factors have plagued the standards
efforts over the past decade and while progress has been made, it has
been slow. These issues are addressed in some detail in Section II of
this document.

QUESTION 3A: Is the private sector able to address these problems
satisfactorily?

The answer to this question is, of course, dependent on how one defines
the problems and on how one defines satisfaction. Certain constrained
areas of standards have made significant progress over the last decade.
SNOMED RT is felt by many, including us, to be on the way to becoming
the definitive vocabulary standard. HL7 has eventuated into a credible
messaging standard. DICOM 3 has addressed many of the issues specific to
image management.

However, as set forth in Section III of this paper, broad clinical
scope, validation and scalability are key factors in addressing the
larger problem. The issue is not just standards for messages,
vocabularies, or images, although those may all be components. What is
needed are the healthcare-wide models that will allow the more focused
standards (such as vocabularies) to be properly contextualized to the
care of a patient by a provider. This has always been the putative
mission of the EHR, yet lack of standards at this level has generally
hampered its adoption.

A limited number of extant architectures in the private sector do offer
the clinical scope, validation and scalability necessary to produce a
broad-based, trusted EHR. (It should be noted that for all such
compliant architectures a robust EHR was a paramount initial design
objective, not a lagging afterthought. Application components and
interfaces were specifically designed to be proper subsets of the EHR
architecture and thus are fully interoperable therein.) It is these few
architectures that, perhaps, offer the greatest immediate potential as
patterns for standardization and industry practice.

QUESTION 3B: In your opinion, what is the role of government for
assisting the private sector in the guidance, development, coordination
and implementation of standards for the patient medical record data and
their electronic transmission?

As a general rule, we are not advocates of government "meddling" with
private sector activities; often the down side outweighs the up side.
However, in this environment, we believe the government does have a
constructive role to play. This role is not to mandate standards that
the industry would likely find overly limiting or problematic. Rather,
the role should be to establish the criteria for enabling standards
frameworks that will:

1.  Identify key points of authority and reference for robust EHR
    architectures:

> .1 Statutes and regulations;
>
> .2 Accreditation standards, as applicable;
>
> .3 Professional standards, as applicable;
>
> .4 Best practice incorporation, based on national, regional and local
> guidelines.

3.2. Identify vital requirements for robust EHR architectures and
establish corresponding EHR requirements statements (leaving
implementations to the private sector). \[See Section III.\]

3.  Have a mechanism, based on EHR requirements statements developed
    under 3.2 to identify (and accredit if necessary) robust, validated
    solutions:

.1 evidencing compliance with the requirements;

.2 with broad clinical scope;

.3 with substantial validation, proof in practice;

.4 broadly scalable;

.5 in the private and public sectors;

.6 in the U.S. and internationally;

.7 from vendors and others.

3.4. Identify such validated EHR solutions as patterns for the industry
and for the government, including uniform use across government
programs.

3.5. Seek to introduce and/or promote such validated EHR solutions as
patterns for standards development in SDOs and other open venues. Seek
to fast track adoption of same.

3.6. Seek appropriate incentives and inducements for the proprietors of
such validated solutions to offer their architectures directly as open,
public standards, perhaps in some kind of public/private partnership.

QUESTION 3C: How might the government help to improve the standards
processes?

As suggested in the previous response, the government can make a
difference. It can strongly influence the direction the standards
process takes, and the quality of the end product, as well as the speed
with which such end product is reached. To date, the standards process
has focused almost entirely on loosely coupled, lowest common
denominator schemes; these have been the easiest things on which to
work, and at least a decade has been spent refining these kinds of
standards. Although these efforts have resulted in some useful
inter-system communications tools, most in the industry do not believe
that they have solved the patient data standards problem or that they
provide a comprehensive enough approach to reaching the desired
wide-ranging solution within our lifetimes.

> What the government can do is move the focus of the standards effort
> to a comprehensive EHR architecture founded on broad-based, fully
> validated solutions. This opens the substantial potential for the ever
> sought but never achieved "plug and play" interoperability that is key
> to optimal patient care and to the public health. At a minimum, the
> government should advance formal EHR requirements statements (see
> Section III) to spur attention and direct focus to the vital need for
> robust, comprehensive solutions incorporating as necessary important
> work that has gone before.

QUESTION 4A: Which standards related to patient medical record
information and its electronic transmission would add the most value for
improving the quality and efficiency of the health care for the nation?

4.1. Standards for broad-based, comprehensive, fully validated EHR
architectures as the basis for standardization of application roles,
relationships, boundaries, functions and interfaces. (Section III offers
a perspective on key requirements.)

2.  Standards for end-to-end data flows, managing information from
    source to consumer, front-end to back-end to thirty party, and
    including:

> .1 protections for individually identifiable information;
>
> .2 accountability: of individuals, of organizations, of business
> units;
>
> .3 authentication, non-repudiation;
>
> .4 assigned responsibility;
>
> .5 completeness: of record content; of the health delivery process;
>
> .6 data integrity: accuracy, consistency, completeness, context, and
> comparability;
>
> .7 non-alterability, revisions by amendment only of record content;
>
> .8 preservation of data states: initial and through each amendment;
>
> .9 chain of custody;
>
> .10 auditability, audit trails.
>
> See Appendix A for a conceptual view of end-to-end data flows. Source:
> HL7 Special Interest Group on Accountability, Quality and Performance

QUESTION 4B/C: Which standards related to patient medical record
information and its electronic transmission would be most important to
the business goals of your organization? Why?

Standards as described in response to Question 4A and based on the
requirements outlined in Section III. Standards focused in these areas
offer the greatest potential for true "plug and play" interoperability
and trusted EHR origination, stewardship and interchange that will
provide the impetus the health care industry needs for adoption of these
key technologies.

QUESTION 4D: What is the business case for more rapid standards
development and implementation?

The business case for comprehensive standards is set forth in Appendix B
\-- it is compelling. Given that fact, more rapid standards development
would, one presumes, more rapidly deliver the long list of benefits. On
the other hand, more rapid standards development of the typical lowest
common denominator kinds of interface standards stands to deliver much
less. Using today's common approach of extant limited standards,
mediated interchange, and retrospective data massing, it is increasingly
clear that a robust EHR is not the likely end result; the question then
becomes how much good money to throw after the bad.

Standards development is an arduous and time-consuming process at best.
We believe the best use of everyone's time, and the best business case
can be made for the acceleration of robust key EHR requirements
statements recommendations/standards and the examination of extant
solutions (achieving a high level of compliance therewith) as a pattern
for ensuing standards work.

QUESTION 5: Do you agree with our emphasis on the four focus areas
listed above. Explain.

The four areas of emphasis are reasonable - as far as they go. In fact
they represent the traditional focus of health informatics standards. In
Section III, a more extensive exposition of the EHR problem space, upon
which we believe future work should be based, is presented.

> After 10+ years, it has become clearly evident that narrowly focused
> campaigns emphasizing standardization primarily at the point of
> interface have produced only limited gains. More churning in these
> areas is likely to be of continued marginal benefit in the search for
> broad-based, validated, highly scalable EHR solutions. As considerable
> work continues to be done in vocabulary, classifications, and code
> sets, it becomes increasingly clear that in operation such
> standardization must occur at the point of origin of HER content, not
> via downstream translation at an interface or via a mediator, when all
> of the facts and circumstances regarding a data element are not known
> and the sourcing provider for the information no longer available.

SECTION II: Electronic Health Record Impediment Issues

[EHR Trust Factor]{.underline}

See Section III for parties to the Trust Constituency.

The Committee and others have spent endless time and effort dealing with
privacy, security, and confidentiality issues in health care records.
Although these factors are not the specific focus of this meeting, they
represent an important sub-context in any discussion of electronic
health records standards. A key success factor for any EHR standard will
be achieving the public and professional perception that safeguards are
in place and will continue to emerge to keep pace with technology. It
goes without saying that such safeguards must be robust and encompassing
enough to protect individually identifiable information and broad-based
health information sources and resources.

To the extent any national EHR standards approach is carefully devised,
prudent and measured with evidence of good practice and record
stewardship, broad acceptance should be achievable. There may be no more
singularly important strategic objective than gaining the public trust
in this regard. Although much of the unease in this area is manufactured
by small special interest groups, the potential for damage is high if
these issues are not properly resolved.

As EHR requirements that incorporate the Trust Factor are developed
pursuant to the actions of this Committee and of others, the Federal
government can serve an important role by promulgating such standards
and compliant solutions as examples of the importance of the Trust
Factor to:

> .1 the public: as evidence of trusted stewardship of their personal
> health records;
>
> .2 the assembled SDOs: as a validated example for standards
> development;
>
> .3 the legislative and administrative branches of government: as a
> model of the fulfillment of statutory, regulatory and business
> objectives;
>
> .4 the accreditation agencies: as a model for fulfillment of
> accreditation standards;
>
> .5 the professional societies: as a model for fulfillment of best
> practices;
>
> .6 the health plan: as a model for fulfillment of business objectives,
> best practices;
>
> .7 the provider organization: as a model for fulfillment of business
> objectives, best practices;
>
> .8 the individual practitioner, caregiver: as a model for best
> practices, for trusted stewardship of the individual patient/member
> health record and the practitioner service record.

Trust is a vital cornerstone that must be addressed head-on, without
equivocation. No matter how otherwise compelling, no approach will
prevail without a firm foundation of trust.

[Compartmentalized Chaos Is NOT an HER -- What Should We Be
Standardizing?]{.underline}

> Ten years ago, as large systems began to shift significantly from the
> mainframe-based model, the importance of frameworks began to be
> recognized.
>
> "Since the technology permits 'distributing' large amounts of
> computing facilities in small packages to remote locations, some kind
> of structure (or architecture) is imperative because decentralization
> without structure is chaos. Therefore, to keep the business from
> *dis*integrating, the concept of information systems architecture is
> becoming less an option and more a necessity for establishing some
> order and control in the investment of information systems resources.
> The cost involved and the success of the business depending
> increasingly on its information systems require a disciplined approach
> to the management of those systems."
>
> \-\-- John A. Zachman, Creator of the Zachman Framework
>
> IBM Systems Journal, Volume 26, Number 3, 1987

With but a handful of notable exceptions, the quest for a trusted and
complete electronic health record (EHR) has been a disappointment. Why
has the promise and appeal been so grand and the achievement so wanting?

Looking at actual implementation examples, one prime impediment is
obvious: the typical EHR systems design strategy has generally done
everything BUT design a system. Instead, multitudes of disparate
healthcare applications typically already serve niches and enclaves. The
healthcare EHR infrastructure is overlaid on these applications after
the fact: a piecemealed tapestry with many fragments, connected with odd
bits of filament, yet far from interwoven. Unfortunately, each patient
depends heavily on the connections between the fragments, and it has
been shown to be difficult if not impossible to find a patient in the
tapestry\...with this design approach there are too many holes through
which the patient might fall.

An analogy from another industry is illustrative. It would be absurd to
approach the design of the Space Shuttle in a manner similar to our
industry's tack with the electronic health record. It would be the same
as suggesting that each of several thousand teams be given an
assignment, based on some general assumptions, and then allowed to
proceed independently to design, develop and deploy each Shuttle
component independent of all other design teams and without a coherent
architecture to join them together as a unified whole. A crew cabin, a
cargo bay, a propulsion system, a wing, a rudder, a strut, etc. - each
devised in isolation from the other.

All teams may indeed produce superb components in their own right, the
"best-of-breed" solution to each designated niche and role.
Unfortunately, while viability as measured by the requirements of the
niche may be outstanding, without an encompassing integration
architecture, viability of the combined components as a unified, fully
integrated and interoperable whole is virtually certain to be impaired
beyond usefulness.

Unfortunately, this approach has been the standard in the health care
information systems arena. Harking to the Shuttle analogy, one could
never create enough standards to make the independently designed pieces
fly safely into space. The mission is not to have the best seat...the
mission is to get to space safely and back. Similarly, in health care
the mission is to care for the *patient*, not the laboratory, pharmacy,
or billing department. Until this problem is addressed on the standards
front, the standards for each component are likely to not provide the
expected value.

["Plug and Play" Interoperability]{.underline}

"Plug and play" has been a holy grail of the standards effort for years,
in the mistaken notion that without a standard framework, it should be
possible to randomly assort pieces and emerge with a result as complex
as the Space Shuttle. An early HL7 advertisement (circa 1988) comes to
mind. It showed a mosaic of puzzle pieces, each representing an
application system, precisely interlocking one with the other. The
intuitive message of this promotion was that of seamless application
unity and ubiquitous "plug and play" interoperability, all the product
of HL7 data interchange standards, of course.

Unfortunately, "plug and play" interoperability (as a function of
industry standard interface specifications) has not come to fruition
nearly as readily as the HL7 puzzle might seem to suggest. Ten years
later, it remains an elusive objective. Unfortunately, the actual
situation is we are typically taking five random pieces from a thousand
or more different puzzle boxes and, after amassing them in a single
pile, attempting to produce a cohesive and coherent whole.

[Loose Coupling and the Lowest Common Denominator Schemes]{.underline}

Much standardization activity has focused on loose coupling schemes to
effect data interchange between disparate application systems. The net
effect of these schemes is to create a common domain of functions and
data with each application engaged only to the extent allowed by its
individual architecture and addressed in its interface implementation.
The result is loosely coupled, minimally engaged applications
interconnected by lowest common denominator (LCD) interfaces. While this
approach has been perceived to bridge an immediate need, it offers
little to address the objectives of a broad-based EHR solution, or to
answer the implicit EHR Trust issues that are contained in any system
combination.

> The figure below graphically illustrates the problem.

![](media/image1.wmf)

This figure illustrates a typical interface solution, where an SDO
Standard Specification is used as a base common denominator between
disparate application architectures.. Adaptations and extensions are
then applied to form a greater common denominator given the confluence
of application architectures and local requirements.

[EHR Requisites as the Basis for the Standards Agenda]{.underline}

Long absent on the agenda of key data interchange standards developers
has been a specific focus on the requirements necessary to produce a
viable EHR. (See HL7, Version 2.3, Section 1.7, April, 1997.) This key
deficiency bears immediate attention. See Section III of this testimony
for additional detail.

[Mediator Schemes]{.underline}

Mediators (i.e., interface engines) have become a popular method of
interfacing multiple applications within an IDN or provider organization
as they allow each application to interchange data with all other
applications in that domain without the need for separate interfaces
interconnecting each on a pair-wise basis.

Unfortunately the mediator is a decidedly mixed blessing, particularly
in terms of robust EHR implementations.

> .1 Disengagement = No Tight Coupling. With the interposition of a
> mediator, transmitting and receiving applications become effectively
> disengaged one from the other. With most mediator-based broadcast
> schemes (single transmitter, many receivers) the transmitter is
> intentionally designed without programmed knowledge of the ultimate
> receiver or its role. Such schemes by their very nature embody the
> loosest possible coupling.
>
> Mediators inhibit any potential for the achievement of tightly-coupled
> interfaces between communicant applications. Blind transmission,
> disengagement of transmitter from recipient, and disengagement of
> originators/sources from stewards from ultimate recipients/consumers
> only serve to perpetuate the deficiencies inherent in loosely coupled,
> lowest common denominator approaches. Unfortunately, mediators do
> provide a low level of achievement that serves to foster minimal
> engagement when deep engagement is what is needed.
>
> .2 No Merged Lists. An immediate consequence of the lack of tight
> coupling is the inability to effectuate merged lists across
> application boundaries. Specifically, it is virtually impossible to
> implement usable two-phase database commits (with bidding and locking
> services) after inserting a mediator between communicant applications.
> Thus is precluded shared, real-time multi-application ownership of
> merged lists, including:
>
> .1 lists of patients/members (e.g., the Master Patient Index);
>
> .2 lists of practitioners/caregivers;
>
> .3 schedules for patients and practitioners;
>
> .4 schedules for deployments and allocations of resources
>
> .5 lists of patient encounters;
>
> .6 lists of patient problem-oriented episodes;
>
> .7 lists of current medications for a patient (i.e., the medication
> profile);
>
> .8 etc.
>
> Robust instantiations of merged lists are an imperative for robust,
> broad-based, highly scalable EHR solutions. Mediators from a barrier
> to this feature.
>
> .3 No End to End Acknowledgment. The transmitting application sends
> its messages only so far as, and receives an acknowledgment from, the
> mediator. By design in most implementations, these are blind
> transmissions as the transmitter has no programmed knowledge of each
> ultimate receiver. It's only known receiver is the mediator.
>
> When the ultimate receiver captures the messages and acknowledges same
> to the mediator, such affirmative response is not then communicated
> back to the original transmitter. For example, this precludes an order
> entry application from ever knowing whether an order was received by
> an ancillary application. It can only affirm acknowledgment by the
> mediator not the ultimate message destination.
>
> Although it is an anathema to mediator proponents, it is imperative
> that end to end acknowledgment be a trusted characteristic of any
> robust EHR solution.
>
> .4 No End to End Message Sequencing. In a similar instance of blind
> transmission, the message stream is sequenced between the transmitting
> application and the mediator and the message stream is also sequenced
> from the mediator to the ultimate receiver but there is no end to end
> sequencing of messages from the transmitting application to each
> ultimate receiver.
>
> Although it runs counter to the mediator culture, this discontinuity
> must also be superseded as a function of the trusted EHR.

[The Great Divide: Front and Back-end Applications]{.underline}

A prevalent industry approach employs separate front and back-end
applications. The back-end acts as a repository for data massing,
collecting data forwarded by multiple front-end applications, typically
via mediators. The front-ends serve particular niches, departments
and/or functions. The back-end repository claims to offer an IDN or
provider organization a functional EHR.

Even if a mediator is not in play and the front and back-end
applications are directly connected, few implementations employ tight
coupling sufficient to support two phase database commits (with bidding
and locking services) and thus shared, real-time multi-application
ownership of merged lists is infeasible.

To fully support a robust EHR, it is imperative that front and back-end
applications engage tight coupling sufficient to ensure two phase
database commits and key prospective views of information (see next
section).

[Back-end Retrospective Data Massing Repository Schemes]{.underline}

As described in the previous section, a trend has emerged to house the
EHR in back-end data massing repositories. As a function of the relative
disengagement (lack of tight coupling) of the front and back-end
applications, these repositories typically capture the health delivery
process in a retrospective mode (what has occurred).

Inherently lacking in these schemes is a real-time, enterprise-wide
scheduling function that encompasses a prospective and concurrent
aspect, in addition to the retrospective view. A true real-time
prospective view is imperative to:

> .1 actively engage immediate patient care events;
>
> .2 proactively engage wellness and preventative care events;
>
> .3 ensure assigned responsibility (of practitioners/caregivers) for
> immediate or upcoming health service events;
>
> .4 optimally allocate and deploy critical organizational resources
> (i.e., practitioners/caregivers, facilities, locations, equipment,
> supplies, time).
>
> Imagine successfully navigating a vehicle while strapped into a
> rear-facing seat. Imagine successfully navigating a provider
> organization, health plan, or IDN similarly encumbered.

[Measurable Points of Completeness]{.underline}

Another critical requirement is the ability to ensure completeness of
the health delivery process and correlative EHR content. Without knowing
what is to be done (i.e., the prospective aspect) it is impossible to
measure completeness. Specifically: Does the currently amassed data in
the repository represent a complete record, a complete set of health
delivery services? For a patient/member, for a problem oriented episode,
for an encounter, for a health service event? Where are the gaps? Who is
responsible for their completion?

[Transliteration Schemes]{.underline}

Much recent attention has focused on transliteration schemes, which
purport to automatically translate record content, attribute by
attribute, from its original encoding to a common or standard encoding.
Mediators are routinely promoted for their transliteration capabilities,
transposing data encodings "in transit" from one application to another.

> The NIH UMLS Meta Thesaurus is often cited as an authoritative
> cross-mapping of content encodings, from one standard
> classification/coding scheme to another. Unfortunately, this approach
> may not be as useful as it might first appear.
>
> .1 The Repudiation Dilemma. If EHR content is transliterated after the
> point of origination and the new encoding does not produce a precisely
> identical term or phrase, the EHR is immediately (and correctly)
> subject to repudiation by its author, scribe or verifier.
>
> .2 Change of Meaning. Transliteration that changes the encoding to
> produce a term that is presumably equivalent but not precisely
> identical to the original carries the imminent potential of change of
> meaning which may in some cases be crucial to decisions regarding
> patient care or treatment.
>
> .3 Change of Specificity, Granularity of Content. Transliteration that
> increases or decreases clinical specificity also carries substantial
> risk factors in its subsequent use in patient care or treatment.
>
> .4 Accountability. Accountability for EHR content is ascribed to
> individuals acting as practitioners, caregivers, authors, scribes
> and/or verifiers. When data is transliterated as an "automatic"
> function of interfacing schemes, including mediators, the
> accountability factor is lost. Who becomes the accountable party for
> the new encoding?

The integrity of EHR content is seriously jeopardized by transliteration
schemes that purport to arbitrarily change information from its original
encoding to something else. At minimum, the original encoding should be
conveyed undisturbed with any transliteration attached as an addendum.

[The Guile of Technology]{.underline}

For a number of years, standardization activities have been flummoxed by
the latest whiz-bang technologies. Proponents come forth with claims of
transcendent solutions that seem irresistible but in almost all cases
turn out too good to be true. Many of these have suggested seamless
integration and "plug and play" interoperability, including mediators,
back-end retrospective data massing repositories, ActiveX/DCOM, OMG
CORBA, AWG ECF, CCOW, SGML/XML, etc. This is not to deny some inherent
usefulness in each of these technologies; many of these are not only
useful but have great potential. The plea here is for the clear up-front
identification of the actual useful role each product plays.

In many cases, the industry has witnessed hordes of advocates stampeding
off claiming victory only to produce constructs that offered marginal
substance when compared to core EHR requirements. Unfortunately, this
action-response sequence has repeatedly caused enough distraction to
disrupt ongoing work.

Technologies alone will not achieve a robust EHR solution. The EHR
problem space will not yield to the assertion of technologies ahead of
core requirements and prudent design. Instead, fulfillment of EHR
requirements must remain the primary design objective for
standardization with technologies then applied as appropriate therefrom.

SECTION III: Electronic Health Record Requirement Issues

EHR data standards should be defined within a framework that is explicit
in the following:

1.  Medical, Legal Record. Services to ensure a targeted level of
    confidence (trust) with regard to the EHR as a full medical/legal
    record for an individual patient or health plan member, to:

> .1 Chronicle the health delivery process;
>
> .2 Evidence the provision and performance of health services; and
> correlatively
>
> .3 Evidence the origination, stewardship and use of EHR content;
>
> .4 Document key demographic and identification traits;
>
> .5 Document the course of the patient's illness or health status;
>
> .6 Furnish documentary evidence of the course of an individual's
> health evaluation, treatment and change in condition;
>
> .7 Document an individual's health status;
>
> .8 Provide data for preventive care;
>
> .9 Document communication between the practitioner responsible for the
> patient's care and any other health care practitioner who contributes
> to the patient's care;
>
> .10 Assist in protecting the legal interest of the patient, the health
> care provider(s) and the responsible practitioner(s);
>
> .11 Provide continuity of care;
>
> .12 Provide data to substantiate insurance claims;
>
> .13 Provide a basis for evaluating the adequacy and appropriateness of
> care;
>
> .14 Document the operational and work performance of the health care
> provider and practitioner; and
>
> .15 Provide data for use in continuing education and research.

[Points of Authority and Reference]{.underline}

2.  EHR Requirements Statements. Services to fulfill key requirements
    both de facto and de jure as set forth by national, regional and
    local authorities:

> .1 Statute and regulation;
>
> .2 Accreditation standards;
>
> .3 Professional standards;
>
> .4 Health informatics standards;
>
> .5 Local policies and conventions.
>
> Including:
>
> .6 Privacy and confidentiality standards;
>
> .7 Security, access control standards;
>
> .8 Record stewardship standards;
>
> .9 Business and clinical practice rules;
>
> .10 Clinical and operational decision/action rules;
>
> .11 Standards of practice;
>
> .12 Standards for performance measures and quality indicators;
>
> .13 Identifier standards;
>
> .14 Vocabulary, classification and code set standards;
>
> .15 Minimum/reference data set standards;
>
> .16 Transaction set standards;
>
> .17 Data interchange standards;
>
> .18 Imaging standards;
>
> .19 Automated device standards;
>
> .20 Application component standards.

[Trust]{.underline}

3\. EHR Trust Constituency. Individuals, organizations and business
units with an immediate stake in the veracity, stewardship and use of
the EHR.

<table style="width:100%;">
<colgroup>
<col style="width: 29%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 10%" />
</colgroup>
<tbody>
<tr class="odd">
<td><p>Trust Constituents:</p>
<p>Individuals</p>
<p>Organizations</p>
<p>Business Units</p>
<p>Role</p></td>
<td><blockquote>
<p>Individual</p>
</blockquote></td>
<td><blockquote>
<p>Organization</p>
</blockquote></td>
<td><blockquote>
<p>Business Unit</p>
</blockquote></td>
<td><blockquote>
<p>Subject of Record</p>
</blockquote></td>
<td><blockquote>
<p>Source, Author of Record Content</p>
</blockquote></td>
<td><blockquote>
<p>Verifier of<br />
Record Content</p>
</blockquote></td>
<td><blockquote>
<p>Scribe of<br />
Record Content</p>
</blockquote></td>
<td><blockquote>
<p>User of<br />
Record Content</p>
</blockquote></td>
<td><blockquote>
<p>Record Steward</p>
</blockquote></td>
<td><blockquote>
<p>Provider/Performer of Health Services as Documented in Record</p>
</blockquote></td>
</tr>
<tr class="even">
<td>Patient, Health Plan Member</td>
<td>X</td>
<td></td>
<td></td>
<td>Yes</td>
<td>Yes</td>
<td>A/A</td>
<td>N/A</td>
<td>A/A</td>
<td>No</td>
<td>No</td>
</tr>
<tr class="odd">
<td>Next of Kin, Emergency Contact, Guarantor</td>
<td>X</td>
<td></td>
<td></td>
<td>Yes</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
</tr>
<tr class="even">
<td>Practitioner, Caregiver</td>
<td>X</td>
<td></td>
<td></td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr class="odd">
<td>Transcriptionist</td>
<td>X</td>
<td></td>
<td></td>
<td>Yes</td>
<td>No</td>
<td>A/A</td>
<td>Yes</td>
<td>No</td>
<td>Yes</td>
<td>No</td>
</tr>
<tr class="even">
<td>Department, Service, Specialty</td>
<td></td>
<td></td>
<td>X</td>
<td>Yes</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr class="odd">
<td>Provider</td>
<td>X</td>
<td>X</td>
<td></td>
<td>Yes</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr class="even">
<td>Integrated Delivery Network (IDN)</td>
<td></td>
<td>X</td>
<td></td>
<td>Yes</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr class="odd">
<td>Payer, Health Plan, HMO</td>
<td></td>
<td>X</td>
<td></td>
<td>A/A</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
</tr>
<tr class="even">
<td>Value Added Network (VAN)</td>
<td></td>
<td>X</td>
<td></td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
</tr>
<tr class="odd">
<td>Employer</td>
<td>X</td>
<td>X</td>
<td></td>
<td>A/A</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>A/A</td>
<td>No</td>
</tr>
<tr class="even">
<td>Public Health Agency</td>
<td></td>
<td>X</td>
<td></td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>A/A</td>
<td>No</td>
</tr>
<tr class="odd">
<td>Regulatory Agency</td>
<td></td>
<td>X</td>
<td></td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>A/A</td>
<td>No</td>
</tr>
<tr class="even">
<td>Accreditation Agency</td>
<td></td>
<td>X</td>
<td></td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>A/A</td>
<td>No</td>
</tr>
<tr class="odd">
<td>Research</td>
<td>X</td>
<td>X</td>
<td></td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>A/A</td>
<td>No</td>
</tr>
<tr class="even">
<td>Clinical Education</td>
<td>X</td>
<td>X</td>
<td></td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>A/A</td>
<td>No</td>
</tr>
<tr class="odd">
<td>Others</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>

N/A = Not applicable

A/A = As applicable

4\. Rights, Privileges and Responsibilities. Incumbent rights,
privileges and responsibilities of each Trust Constituent with regard to
the EHR, its origination, stewardship and use.

5\. Privacy and Confidentiality Protections. Services to ensure targeted
level of trust regarding privacy and confidentiality protections
afforded EHR record subjects. \[See preceding matrix.\]

6\. Individual Identifiers. Services to ensure targeted level of trust
regarding assignment, stewardship and use of individual identifiers,
for: patient/members, providers, and practitioners/caregivers.

7\. Individually Identifiable Information. Services to ensure targeted
level of trust regarding origination, stewardship and use of
individually identifiable EHR information.

8\. Organizational Identifiers. Services to ensure targeted level of
trust regarding assignment, stewardship and use of identifiers for
organizations and business units: providers, payers, health plans,
employers.

[Stewardship]{.underline}

9\. EHR Stewards. Individuals and organizations who act as stewards for
the EHR. \[See preceding matrix.\]

10. EHR Stewardship Chronicle. Services to chronicle EHR stewardship:

> .1 Origination of record content: by author, scribe, or automated
> device;
>
> .2 Verification of record content (e.g., of automated device input);
>
> .3 Attestation, electronic signature of record content;
>
> .4 Access or view of record content;
>
> .5 Copying or duplication of record content;
>
> .6 Disclosure or transmittal of record content;
>
> .7 Receipt of record content from another party.

[Wholeness and Integration -- The EHR Continuum]{.underline}

11. EHR Health Delivery Chronicle. Services designed to chronicle the
    health delivery process, its correlative work flow, information flow
    and recording processes:

> .1 As an immediate and concurrent function of health delivery;
>
> .2 Once, at the point of service or care;
>
> .3 Concurrent with the clinical service event.

12\. EHR Care Continuum. Services to engage the EHR and chronicle care
delivery in multiple venues: acute, emergent, ambulatory, long-term,
home health.

13\. EHR Business Continuum. Services to engage the EHR and chronicle
care delivery across the health business continuum: health plans, IDNs,
provider organizations, business units, small group and solo
practitioners.

14. EHR Application System Continuum. Services to engage a robust EHR
    across the continuum of health application systems, including
    originators and non-originators of EHR content:

> .1 Front-end: medical device applications (e.g., instruments,
> monitors);
>
> .2 Front-end business unit: department, service, specialty or
> function-oriented application;
>
> .3 Back-end enterprise: repository application;
>
> .4 Integrated business unit and enterprise application;
>
> .5 Mediators: (i.e., interface engines, hubs, store and forward,
> translators);
>
> .6 Value-added network (VAN) applications;
>
> .7 Third party applications.

15\. EHR Individual Lifetime Health Record. Services to chronicle an
individual's health status and history, a "womb to tomb" health
chronology. \[See Appendix A for further detail.\]

16\. EHR Episode/Problem Record. Services to chronicle patient
problem-oriented episodes of care:

> .1 For a lifetime continuum;
>
> .2 Across one or more encounters;
>
> .3 With related diagnosis;
>
> .4 With protocol and status: critical path, care plan;
>
> .5 With milestones, resolutions and outcomes.

17. EHR Encounter Record. Services to chronicle patient encounters:

> .1 With each health care provider;
>
> .2 With each health practitioner, caregiver;
>
> .3 At each of multiple points (locations) of service;
>
> .4 For each encounter type: acute, emergent, ambulatory, long-term
> care, home health.
>
> .5 For a lifetime continuum

18. EHR Timeline Record. Services to chronicle the health time
    continuum:

> .1 Prospective (future): Upcoming health service events and wellness
> checks - scheduled but not yet underway.
>
> .2 Concurrent (present): Current, immediate health status, health
> service events and wellness checks -- active (in progress) but not yet
> complete.
>
> .3 Retrospective (past): Historical health status, service and
> wellness events -- completed, resolved or canceled.
>
> .4 For individual patients/members;
>
> .5 For individual practitioners, caregivers;
>
> .6 For critical resources: facilities, locations, equipment;
>
> .7 For organizations, business units.

19. Companion EHR Records. Services to define and manage interrelated,
    companion records as discrete EHR strata:

> .1 Master person index;
>
> .2 Patient/member health record: individual;
>
> .3 Provider operations (business) record: organization, business unit;
>
> .4 Practitioner/caregiver service record: individual;
>
> .5 Population health records: with and without individually
> identifiable record content.

20\. Logical Wholeness. Services to ensure a logically integrated
record, even if physically distributed.

[Accountability]{.underline}

21\. EHR Accountable Parties. Individuals, organizations and business
units accountable for:

> .1 EHR content origination: authors, scribes, verifiers;
>
> .2 EHR access and use;
>
> .3 EHR stewardship;
>
> .4 Health services as documented in the EHR.
>
> \[See preceding Trust Constituency matrix.\]

22. EHR Accountable Actions. Services to record accountable actions
    relative to the EHR, its content, its origination, stewardship and
    use:

> .1 Access or view record content;
>
> .2 Create or amend record content: as author or scribe;
>
> .3 Validate record content (e.g., automated device input);
>
> .4 Copy or duplicate record content;
>
> .5 Disclose or transmit record content;
>
> .6 To be in receipt of record content from another party;
>
> .7 Provide health services or perform other actions as documented in
> the EHR.

23. EHR Authentication. Services to authenticate individuals and
    actions:

> .1 User authentication: proof of user identity;
>
> .2 Data source authentication: proof of authorship or origin;
>
> .3 Data verification authentication: proof of data validation;
>
> .4 Data interchange authentication: proof of transmittal, proof of
> receipt.

24\. Non-repudiation. Services to ensure non-repudiation of authorship
or origin of EHR content.

25\. EHR Attestation, Electronic Signature. Services to bind the
identity of an accountable party to specific content of the health
record, including to:

> .1 Affix attestation/signature to record content;
>
> .2 Validate attestation/signatures and corresponding record content,
> including downstream from the point of origination;
>
> .3 Form encrypted encapsulations of content and identifier(s) of
> source individual(s) using public/private key schemes or other robust
> solutions.

26. EHR Attestation Context. Services which record the essential context
    of attested content and/or the provision or performance of health
    services or other actions, including:

> .1 Who -- subject: patient/member;
>
> .2 Who -- provider/performer: organization, business unit, individual;
>
> .3 Who -- source individual (if different): author, scribe;
>
> .4 Who -- verifier individual (if different);
>
> .5 Who -- attesting/signing individual (if different);
>
> .6 Who -- source application system;
>
> .7 Who -- disclosed to, if applicable;
>
> .8 What -- provided or performed: procedure, work flow event,
> sequence, stage;
>
> .9 What -- action: provide, perform, create/amend/verify record
> content;
>
> .10 When -- occurrence: event start date/time and duration;
>
> .11 When -- recorded: recording date/time;
>
> .12 Where -- physical location: e.g., physical point of
> service/access;
>
> .13 Where -- device ID, network address.

27. Public Key Certificate Authorities. Robust services to register and
    manage public and private key pairs:

> .1 To support strong authentication, non-repudiation, attestation,
> electronic signature;
>
> .2 Issued to individuals: as originators, stewards or users of the
> EHR;
>
> .3 Issued to organizations, business units: as originators, stewards
> or users of the EHR;
>
> .4 Issued to application systems: as originators or stewards of the
> EHR.

[EHR Clinical Service Event Record]{.underline}

28. Event Detail.. Services to ensure the capture and documentation of
    clinical service events, as detailed previously under Electronic
    Signature and also including:

> .1 Rationale, if applicable;
>
> .2 Context and condition related parameters;
>
> .3 Event or process specific parameters;
>
> .4 Relevant clinical parameters;
>
> .5 Relevant operational and performance parameters: performance
> measures, quality indicators, resource utilization, cost parameters.

[Security, Access Control]{.underline}

29\. Security Policy Domain(s). Services to configure and manage
security policy domains each designed to administer sets of security
policies and procedures relative to EHR content origination access and
use. Domains are typically established for IDNs, organizations, and
business units.

30\. Orange Book C2 Level of Trust. Services to ensure security and
access safeguards and functions conformant to the U.S. Department of
Defense Trusted System Criteria (the "Orange Book"), Level C2 (or
better).

31. Data Classifications. Services to configure and manage security
    classifications for EHR content (data), establishing controls for:

> .1 Access to record content;
>
> .2 Creation or amendment of record content;
>
> .3 Verification of record content;
>
> .4 Copying or duplication of record content;
>
> .5 Disclosure or transmission of record content;
>
> .6 Receipt of record content from another party.

32. Function Classifications. Services to configure and manage security
    classifications for EHR functions, establishing access controls for
    EHR:

> .1 Networks;
>
> .2 Application systems;
>
> .3 Discrete application functions.

33. User Clearances. Services to configure and manage security
    clearances, which map to data and function classifications, for
    individuals with access to EHR data and functions, including:

> .1 Discrete individual clearances;
>
> .2 Role-based clearances.

34. User Access Control. Services and mechanisms to ensure EHR access
    only to authorized individuals using, for example:

> .1 ID tokens: physical cards, buttons, keys;
>
> .2 Password assignment and renewal rules;
>
> .3 Limited signon retries;
>
> .4 Secure intranets;
>
> .5 Dial-back modems.

35. Master User Index. Services to configure and manage a registry of
    individuals with authorization to access EHR data and functions,
    including:

> .1 Identifier(s), identification traits;
>
> .2 Demographics;
>
> .3 Roles;
>
> .4 Clearances to EHR data and functions: individual or role-based;
>
> .5 Access parameters: identifiers, tokens, passwords.

36\. Encrypted data transmission. Services to ensure secured data
transmission, including encryption.

[Auditability]{.underline}

37\. Audit trails. Services to ensure audit trails sufficient track
actions of accountable parties relative to the provision and performance
of health services, to the origination, stewardship and communication of
EHR content.

38\. Audit review. Services to manage and review audit trails.

[Roles, Relationships]{.underline}

39\. Roles. Services to establish and manage roles of individual
practitioners/caregivers and authors, scribes and verifiers of EHR
content.

40. Relationships. Services to establish and manage relationships of
    individual practitioners/caregivers:

> .1 As responsible/accountable parties: to patients, members;
>
> .2 As employees or agents: to organizations, business units.

[Availability, Reliability]{.underline}

41\. Availability. Services to ensure EHR availability, 24 hours x 7
days x 366 days/year.

42\. Fault Tolerance. Fault tolerance services to ensure continuous
availability of the EHR computing base: hardware, software, databases,
networks.

43\. Post Year 2000. Services to ensure availability and reliability
beyond the dawn of the new millennium.

[Scalability]{.underline}

44. Scalability. Services and facilities to ensure scalability and
    extensibility of the EHR domain, including:

> .1 EHR data store;
>
> .2 Additional business units, facilities, locations;
>
> .3 Additional practitioners, caregivers;
>
> .4 Additional encounter types;
>
> .5 Additional types of service.

[Performance]{.underline}

45\. Rapid User Response Time. Services to ensure rapid response to user
actions relative to the EHR.

46\. Minimal Data Latency. Services to ensure timeliness of EHR
information transmission from source to consumer.

47\. Optimal Processing Throughput. Services to ensure the optimal
processing throughput of the EHR computing base.

[Paper Reduction]{.underline}

48\. Permanent Record. Services to reduce and supplant paper usage and
retention with regard to the permanent EHR.

49\. Transitive Record. Services to reduce and supplant paper usage and
retention with regard to transitive and temporal records.

[Data Integrity]{.underline}

50. Data Registry, Data Definitions. Services to create and manage a
    data registry, including uniform specifications for:

> .1 Attributes (data elements);
>
> .2 Naming;
>
> .3 Identifiers;
>
> .4 Data types, formats;
>
> .5 Definition of usage;
>
> .6 Grouping of attributes into minimum and reference datasets.

51\. Standards. Data definitions should allow designation of national,
regional and local standards, where applicable.

52\. Accuracy. Services designed to ensure accuracy of EHR content,
including:

> .1 In the data registry: input accuracy and validity checks and rules;
>
> .2 At EHR content origination: rules for input accuracy and validity
> checks;
>
> .3 With authentication, non-repudiation services;
>
> .4 With attestation/electronic signature.

53. Context. Services to create and manage logical contextual data
    relationships within the EHR:

> .1 In the data registry: contextual data relationships, rules for
> context checks;
>
> .2 At EHR content origination: rules for context checks;
>
> .3 In logical database structures;
>
> .4 In logical EHR views;
>
> .5 In relationships of information to work flow and clinical events;
>
> .6 In relationships of information to EHR timeline;
>
> .7 In relationships of information to accountable parties:
> individuals, organizations, business units.

54. Consistency, Structure and Comparability. Services designed to
    ensure data consistency, structure and comparability:

> .1 In the data registry: consistency checks and rules;
>
> .2 At EHR content origination: rules for consistency checks;
>
> .3 Of information across patients, members and populations;
>
> .4 Of information across health plans, provider organizations,
> practitioners/caregivers;
>
> .5 Of information across sites (locations) of service, at different
> points in time;

55. Continuity, Completeness. Services designed to ensure the continuity
    and completeness of information content:

> .1 In the data registry: continuity and completeness checks and rules;
>
> .2 At EHR content origination: rules for continuity and completeness
> checks;
>
> .3 Of information completeness as a function of the completeness of
> corresponding health services and work flow events.

56\. Gap Analysis. Services to probe the EHR for gaps in continuity and
completeness in record content and to identify corresponding assigned
responsible(s).

57\. Uniform Capture. Services designed to ensure systematic, uniform
capture of EHR content.

58\. Data Verification. Services designed to ensure routine verification
of specific EHR inputs, particularly that of automated devices, prior to
formal EHR inclusion.

59\. Vocabulary, Classification and Coding. Services designed to ensure
consistent vocabulary, classification and coding of EHR content.

[Time Integrity]{.underline}

60\. Clock Synchrony. Services to ensure clock synchrony across all
application systems which act as EHR originators or stewards.

61\. Year 2000 Compliance. Services to ensure correct EHR date and time
keeping with regard to Y2K.

[Persistence, Permanence]{.underline}

62\. Permanence. Services to ensure the persistence and permanence of
the EHR.

63\. Non-Alterability. Services to ensure non-alterability of EHR
content.

64\. Revision by Amendment Only. In conjunction with the preceding
points, services to ensure that EHR content revisions are in the form of
amendments only.

65\. Formal Amendment Process. Services to engage a formal amendment
process for error correction and EHR content revision.

66\. Data State Preservation. Services to ensure data state
preservation, initially and through each amendment.

67\. Historical Snapshot. Services to reconstruct EHR content for a
given historical date/time.

[Process Integrity]{.underline}

68. Work Flow, Procedure Definition. Services to create and manage work
    flow and health service procedure definitions and to thereby engage
    business and clinical practice rules:

> .1 Security, access classifications;
>
> .2 Clinical pathway and variance rules: protocols, care plans;
>
> .3 Scheduling rules;
>
> .4 Rules for orders and results;
>
> .5 Sequencing, staging rules;
>
> .6 Rules for assigned responsibility;
>
> .7 Rules for resource allocation and deployment:
> practitioners/caregivers, facilities, locations, equipment, supplies,
> time;
>
> .8 Rules to measure continuity, completeness of workflow (and thus the
> correlative EHR content);
>
> .9 Decision support rules.

69. Integrated Scheduler. Services to manage a comprehensive and
    immediate schedule of upcoming clinical service events:

> .1 Fully integrated between and across business units within a health
> delivery setting: a health plan, a provider organization, an IDN;
>
> .2 Integrated with EHR timeline: prospective, concurrent aspects;
>
> .3 Initiated by explicit practitioner orders for clinical services;
>
> .4 Initiated by appointments for ambulatory services;
>
> .5 Initiated by resource-based schedules: exam rooms, operating
> suites, etc.;
>
> .6 Initiated by clinical pathways: protocols, care plans;
>
> .7 Oriented to individual patients, members;
>
> .8 Oriented to individual practitioners, caregivers;
>
> .9 Oriented by resource: facility, location, equipment.

70\. Assigned Responsibility. Services to assign, manage and verify
assigned responsibility for clinical service events: of practitioners,
caregivers.

71\. Event Initiation. Services to initiate health service events based
from:

> .1 Spontaneous orders;
>
> .2 Pre-defined orders, order sets: by individual practitioner,
> organization, business unit;
>
> .3 Clinical pathways: protocols, care plans.

72\. Clinical Pathways. Services to ensure optimal care progression
along designated clinical pathways and to ensure notation of variances
and related authorization, where applicable.

73\. Resource Projection. Services to project resource requirements:
personnel, facilities, locations, equipment, supplies, time.

74\. Cost Projection. Facilities to project costs associated with
planned clinical services.

75\. Resource Allocation, Deployment. Services to ensure optimal
allocation and deployment of critical resources.

76\. Process (Work Flow) Continuity, Completeness. Services to verify
the continuity and completeness of the health delivery process and
clinical service events, along with correlative EHR documentation.

77\. Process Gap Analysis. Services to probe the EHR for gaps in
continuity and completeness in the health delivery process (work flow)
and to identify assigned responsible(s).

[Decision Support]{.underline}

78\. Definition. Services to create and manage definitions for decision
support logic, based on and to engage business and clinical practice
rules;

> .1 For relevant operational (business) conditions;
>
> .2 For relevant clinical conditions;
>
> .3 For clinical pathways: protocols, care plans;
>
> .4 For clinical service event initiation;
>
> .5 For initiation of prompts, alerts, notifications, reminders;
>
> .6 To establish assigned responsibility.

79. Real-time Rules Engine. Services to detect and evaluate decision
    support rules in real-time:

> .1 As a concurrent, proactive function of the health delivery process;
>
> .2 To engage business and clinical practice rules;
>
> .3 To trigger appropriate follow-up actions;
>
> .4 To initiate condition-predicated notifications: prompts, alerts,
> notifications, reminders;
>
> .5 To initiate condition-predicated actions, e.g., to
> initiate/modify/cancel:
>
> .1 assigned responsibility;
>
> .2 clinical pathways;
>
> .3 orders;
>
> .4 clinical service events.
>
> .6 To detect duplicate/redundant services;
>
> .7 To detect conflicts and undesirable interactions;
>
> .8 To detect potential allergic reactions.

80\. Record Linkage. Services to denote actions as the result of
decision support triggers in the EHR.

[Knowledge Bases]{.underline}

81\. References. Services to ensure real-time support for clinical
decision making, including references to:

> .1 Current medical literature and bibliographies;
>
> .2 Current diagnostic, treatment and medication guidelines;
>
> .3 Applicable statutes and regulations;
>
> .4 Applicable accreditation and professional standards of
> practice/care;
>
> .5 Available facilities, resources and services;
>
> .6 Local business and clinical practice rules.

82\. Record Linkage. Services to denote actions pursuant to knowledge
base references in the EHR.

[Surveillance, Metrics and Analysis]{.underline}

83. Definition. Services to create and manage definitions for key
    surveillance, metrics and analysis, based on business and clinical
    practice rules:

> .1 Performance, compliance measures;
>
> .2 Quality assurance indicators;
>
> .3 Allocations and deployments;
>
> .4 Costs: projected and actual;
>
> .5 Utilization: projected and actual;
>
> .6 Productivity and work load;
>
> .7 Clinical pathway variances;
>
> .8 Outcomes.

84\. Real-Time, Concurrent. Services to engage real-time measurement and
assessment: performance, compliance, quality assurance, allocations and
deployments, costs, utilization, work load, variances, etc.

85\. Retrospective. Services to engage retrospective measurement and
assessment: performance, productivity, compliance, quality assurance,
costs, utilization, variances, outcomes, etc.

86. Epidemiological Surveillance. Services to engage epidemiological
    surveillance of:

> .1 Patient diagnostics, treatment and care;
>
> .2 Organizational and business unit practices;
>
> .3 Environmental conditions.

87. Ad Hoc Query, Analysis and Reporting. Services to provide ad hoc
    query, analysis and reporting within:

> .1 Real-time, OLTP operational data store;
>
> .2 Retrospective, OLAP analytical data store.

[Communications Infrastructure]{.underline}

88\. Immediate Conveyance. Services to ensure immediate information
conveyance from source to consumer, within an provider organization or
business unit.

89\. Messaging. Services to initiate and manage electronic message
communication, including:

> .1 Interpersonal messages;
>
> .2 Rules-based prompts, alerts, notifications, reminders.

90\. Receipt. Services to ensure affirmative acknowledgment of message
receipt.

[Real-Time, Immediate]{.underline}

91\. Concurrent with Service Performance. Services to record clinical
service events, once, at the point of service/care, concurrent with the
event.

92\. Current status. Services to review current, immediate status of
health service events, work flow:

> .1 For patients, members;
>
> .2 For practitioners, caregivers;
>
> .3 For critical resources: facilities, locations, equipment;
>
> .4 For organizations, business units.

93\. Integrated Schedule. Services to manage and review the current
integrated schedule and EHR timeline: prospective, concurrent,
retrospective.

94\. Problem-Oriented Episodes. Services to manage and review current
patient problem-oriented episodes.

95\. Clinical Pathways, Variances. Services to manage and review current
clinical pathways and variances.

[Personalized Practitioner, Caregiver Functions]{.underline}

96\. Personal Data Views. Services to define, maintain and access
personalized views of EHR content.

97\. Personal Order Sets, Clinical Pathways. Services to define,
maintain and access personal order sets and clinical pathways (e.g.,
protocols, care plans).

98\. Assigned Responsibility. Services to assign and verify personal and
group assignments for clinical service events.

99\. Personal Work Assignments. Services to create and manage personal
work lists and action items.

100\. Notifications, Alerts, Reminders. Services to create, manage and
access notifications, alerts and reminders, based on personal criteria.

101\. Unreviewed Information. Services to provide notification of
current, yet unreviewed, EHR information, based on personal criteria.
(e.g., What has changed since I last accessed the EHR?)

[User Interface]{.underline}

102\. Consistency. Services to ensure consistency of user interface
experience across applications.

[On-Line Transaction Processing (OLTP)]{.underline}

103\. Real-time, Immediate. Database services to support the real-time,
immediate health delivery process and the EHR.

104\. Transactions. Services to support two phase database commits
(including bidding and locking), tightly coupled across multiple
applications to implement shared, multi-application ownership of EHR and
related records, including merged lists:

> .1 Patients/members (e.g., the Master Patient Index);
>
> .2 Practitioners/caregivers;
>
> .3 Schedules for patients, practitioners and resources;
>
> .4 Lists of patient encounters;
>
> .5 Lists of patient problem-oriented episodes;
>
> .6 Lists of current medications for a patient (i.e., the medication
> profile);
>
> .7 etc.

[On-Line Analytical Processing (OLAP)]{.underline}

105\. Retrospective. Database services to support retrospective
analytical functions relative to the EHR and its derivative subsets.

[Data Store Management]{.underline}

106. Database Synchrony, Replication. Services to ensure database
     synchrony and replication management across multiple applications:

> .1 At initial application binding;
>
> .2 Continuously during routine operation;
>
> .3 After application downtime.

107\. Retention. Services to ensure proper database retention
characteristics, including services for creating and retrieving archival
records.

108\. Not Size Restricted. Facilities to ensure that the EHR content is
not constrained by database maximum size restrictions.

[Consents, Authorizations]{.underline}

109\. Health Services. Services to track patient consents for
procedures, diagnostics, therapeutics and other care.

110\. Disclosure. Services to track patient consents for disclosure of
their personal EHR and its subsets, including specific scope of
disclosure.

[Data Export, Disclosure.]{.underline}

111. EHR Derivatives. Services to export EHR derivatives and subsets to
     third parties and secondary users:

> .1 while ensuring privacy and confidentiality protections for record
> subjects;
>
> .2 within the scope of applicable consents/authorizations for
> disclosure, as applicable.

112\. Disidentification. Services to ensure EHR derivatives and subsets
have identifying individual and organizational traits excised prior to
disclosure, as applicable.

113\. Audit trails. Services to maintain audit trails of controlled
disclosures of EHR derivatives and subsets.

114\. Protection Labeling. Services to label disclosed EHR derivatives
and subsets as protected, as applicable.

115. Requests for Amendment. Services to track patient requests for
     amendment of EHR content, including actions taken:

> .1 Amendment made per request;
>
> .2 Amendment refused.

[Data Display]{.underline}

116\. Equivalent Presentation. Services to ensure equivalent data
presentation and display, across all applications within an organization
or business unit.

117\. Simultaneous Access. Services to ensure multiple simultaneous
access to view EHR content.

118\. Record Index, Table of Contents. Services to provide an index or
table of contents to EHR content.

119\. Drill Down. Services to provide discrete levels of EHR display
detail, with drill down capability.

120\. Customized Displays. Services to provide customized displays and
views of EHR content: by organization, business unit, individual
practitioner.

[Master Definitions]{.underline}

121. Master Definition Tables. Services to create and manage master
     definition tables, based on business and clinical practice rules.
     For example:

> .1 Data registry, data definition;
>
> .2 Master user index;
>
> .3 Security classifications for functions and data;
>
> .4 Security clearances for users, roles;
>
> .5 Facilities, locations;
>
> .6 Resources;
>
> .7 Procedures;
>
> .8 Work flow;
>
> .9 Clinical pathways: protocols, care plans;
>
> .10 Decision support: initiators, rules, triggered actions;
>
> .11 Medication formulary;
>
> .12 etc.

[Multi-Media]{.underline}

122\. Multi-Media Record. Services and facilities to support multi-media
EHR content, including: text, audio, video, images, graphics, waveforms,
etc.

[Personal Linkages]{.underline}

123\. Persons. Services to support the linkage of individual EHR
subjects, including:

> .1 Mother/child, multiple birth, birth order;
>
> .2 Next of kin, family groups;
>
> .3 Guarantor;
>
> .4 Insured, subscriber, health plan member;
>
> .5 Emergency contact.

124\. Populations. Services to support grouping of individual EHR
subjects into designated groups, e.g., for clinical studies.

[Localization, Local Authority]{.underline}

125. Localization. Services to support the parameters of local
     organizations and business units, including:

> .1 Business and clinical practice rules;
>
> .2 Security, access control, administration of security policy
> domains;
>
> .3 Decision support rules;
>
> .4 Practice guidelines, standards of care
>
> .5 Surveillance, measurement and analysis rules;
>
> .6 Procedures, work flow;
>
> .7 Master table definitions;
>
> .8 Data registry, definitions;
>
> .9 Vocabulary;
>
> .10 Classifications, code sets;
>
> .11 Naming and identifiers;
>
> .12 Data export, disclosure.

[User Environments]{.underline}

126. User Environments. Services and facilities to support separate EHR
     user environments, including:

> .1 Production, operational EHR;
>
> .2 Test, development;
>
> .3 Education, training.

[Version Control]{.underline}

127. Versioning. Services and facilities to support and manage multiple
     versions, including:

> .1 Hardware, firmware;
>
> .2 Networks, communications;
>
> .3 Application software;
>
> .4 Master table definitions;
>
> .5 Vocabulary;
>
> .6 Classification, code sets;
>
> .7 SDO data interchange standards;
>
> .8 Mediator software.

128\. Controlled Roll Forward. Services and facilities to support
controlled version roll forward (e.g., from test/development to
production environment).

[Mediators (Interface Engines)]{.underline}

129\. Synchrony. With mediator in place, services to ensure synchrony of
application data stores: at initial application binding, during
continuous operation, after application downtime.

130\. End to End Acknowledgment. With mediator in place, services to
ensure end to end (source transmitter to ultimate recipient) message
acknowledgment, from source application to ultimate recipient.

131\. End to End Sequencing. With mediator in place, services to ensure
end to end sequencing of messages, from source application to ultimate
recipient.

[Application Inter-dependencies]{.underline}

132\. Applications. Identification of application inter-dependencies
(where an application cannot fully perform its function without
essential precedent data from, or function by, another application).

[EHR Core Architecture]{.underline}

133. Information Model. Services and facilities to support the core EHR
     information architecture, including:

> .1 Data Registry: attributes (data elements), data groups and
> datasets;
>
> .2 Data Model: object classes, relationships, attributes, and
> identifiers;
>
> .3 Process Model: object states, state transitions, use cases and
> scenarios, workflow, data flow;
>
> .4 Vocabulary, classifications, code sets;

134\. Accountability Model. Services and facilities to support the
accountability of individuals, organizations and business units. \[See
preceding sections on accountability.\]

135\. Data Integrity Model. Services and facilities to support the
integrity of data origination, stewardship and communication. \[See
preceding section on data integrity.\]

136\. Process Integrity Model. Services and facilities to support the
integrity of the health delivery process. \[See preceding section on
process integrity.\]

137. Application Interoperability and Component Model. Services and
     facilities to support the full interoperability of application
     components, including roles, relationships, boundaries and
     functions.

Exhibit A

Exhibit B [The Business Case for Comprehensive EHR
Standards]{.underline}

[Background and Support]{.underline}

The HIPAA-inspired investigation being performed by NCVHS is timely and
reflects similar processes going on around the world. For example, the
National Health Service in the United Kingdom has recently published a
manifesto detailing a comprehensive informatics approach for the next
decade that deals with many of the same issues:

"Better care for patients, and improved health for everyone depend on
the availability of good information, accessible, when and where it is
needed."

"To provide... the most modern tools to improve the treatment and care
of patients and to be able to narrow inequalities in health by
identifying individuals, groups and neighborhoods whose health care
needs particular attentions."

"To ensure that patients can be confident that ... professionals caring
for them have reliable and rapid access, 24 hours a day, to the relevant
personal information necessary to support their care."

"To provide every ... professional with on-line access to the latest
local guidance and national evidence on treatment, and the information
they need to evaluate the effectiveness of their work and to support
their professional development."

> \-\-- "Information for Health -- An Information Strategy for the
> Modern NHS", U.K. National Health Service, September 1998

Similarly, the Joint Commission on the Accreditation of Health Care
Organizations has increasingly identified information as a key tool:

Information as a Key Resource

"\[A provider\] organization's provision of health care is a complex
endeavor that is highly dependent on information. This includes
information about the science of care, the individual patient, the care
provided, the results of care, and the performance of the organization
itself. Because many individuals and departments within the organization
provide care, their work must be coordinated and integrated. Because of
this dependence on information and the need to coordinate and integrate
services, health care organizations must treat information as in
important resource to be managed effectively and efficiently. Managing
information is an active, planned activity.

"Information management is a function - a set of processes and
activities - focused on meeting the organization's information needs.
Its goal is to obtain, manage, and use information to enhance and
improve individual and organization performance in patient care,
governance, management, and support processes.

"Information management processes \[are the focus\] of organization-wide
planning to meet internal and external information needs."

\-\-- JCAHO

# The Business Case

There is a strong independent business case for establishing "uniform
data standards for medical record information and the electronic
exchange of such information". Properly executed, such standards could
be expected:

-   To provide a trusted information source and resource. This is
    particularly important from the perspective of key stakeholders:
    patients, health plan members, providers, practitioners/caregivers,
    payers, accreditation and oversight agencies, public health
    agencies, researchers, and others.

-   To facilitate the right information to the right people, when and
    where needed. Timely, accurate information serves as the basis for
    the best possible care.

-   To ensure standards of clinical practice, service and performance.

-   To ensure trusted record stewardship, for health records and their
    companion records:

```{=html}
<!-- -->
```
-   Master patient/member registry/index;

-   Patient (member) health record: individual; family; group

-   Provider operations (business) record: organization, business unit;

-   Practitioner service record: individual; group.

```{=html}
<!-- -->
```
-   To ensure trusted health record stewardship, for:

```{=html}
<!-- -->
```
-   Data at rest (data stores);

-   Data in transit (communication);

-   End to end data flows: source to consumer, longitudinal chain of
    custody, front-end (point of service) to back-end (e.g., repository)
    to third party.

-   To ensure privacy and confidentiality protections for subjects of
    health records, both individual and organizational.

-   To ensure the rights, privileges and responsibility
    (accountabilities) of health record subjects.

-   To ensure health record access is limited to authorized individuals
    with a "need to know".

-   To ensure access is granted according to the security and access
    control policies and procedures of the controlling health record
    steward.

-   To ensure disclosure of health record content is according to
    permissions granted by applicable patients, health plan members,
    individual and organizational providers, practitioners, caregivers
    and others in accordance with controlling legal and regulatory
    requirements.

-   To provide lifelong, longitudinal, individual electronic health
    records. Properly constructed, such records will be patient
    centered, designed to be responsive to patient needs, and not
    constrained by/to organizational and business unit boundaries.

```{=html}
<!-- -->
```
-   To promote optimum care delivery, both reactive (to existing health
    conditions) and proactive (preventative, wellness).

```{=html}
<!-- -->
```
-   To provide population based health record derivatives for clinical
    research.

-   To ensure on-line immediate, secure access to health records. 24 x 7
    x 366 (and post Y2K) availability.

-   To integrate information seamlessly across the clinical continuum:
    preventative/wellness, home health, ambulatory, acute, emergent, and
    long-term.

-   To ensure information clarity and integrity: legibility, accuracy,
    consistency, continuity, completeness, context, and comparability.

-   To ensure accountability:

```{=html}
<!-- -->
```
-   Of individual persons, of business units, of organizations;

-   For provision of health (care) services;

-   For access to, or duplication of, health record content;

> \- For authorship, transcription and/or verification of health record
> content;

-   For disclosure of individually identifiable health record content;

-   For transmission and/or receipt of health record content;

-   For translation of health record content (e.g., linguistic
    translation, coding scheme translation).

-   To coordinate the expertise of multiple clinicians, sometimes over
    great distances.

-   To enable best business and clinical practices based on national,
    regional and local guidelines.

-   To provide decision support tools, both clinical and operational.

```{=html}
<!-- -->
```
-   To ensure immediate access to clinical guidelines, best practices,
    medical literature and other information resources

```{=html}
<!-- -->
```
-   To improve the effectiveness of clinical care.

-   To optimize operations and efficiencies in the health delivery
    process.

```{=html}
<!-- -->
```
-   To reduce redundancies and duplications.

The industry had been slowly awakening to the opportunities represented
by the accomplishment of this important task. Thus both the mission and
the timing of the NCVHS Sub-Committee in this area is particularly
auspicious.