A. DEFINITIONS

B. INTRODUCTION

C. THE FOUR STEPS:

Definition of Telehealth

There is no single precise definition of telehealth. The Telehealth/Telemedicine Coordination Project Planning Committee adopted the following definition.

Telehealth is the use of electronic communication networks for the transmission of information and data focused on health promotion, disease prevention and the public's overall health, including patient/community education and information, population based data collection and management, as well as linkages for health care and referrals.

Definition of Telemedicine

The Committee adopted the following working definition of telemedicine.

Telemedicine is the use of electronic communication networks for the transmission of information and data related to the diagnosis and treatment of medical conditions.

Definition of Telecommunity

A telecommunity need not be limited to health care providers or users. Schools, community colleges, businesses, governmental agencies, etc., may share the resources of a telecommunity.

A telecommunity is a community created through telecommunications that becomes a "virtual community" without physical boundaries within a region, an institution, or consortia.

A telecommunity can provide desired professional and educational opportunities for all members of a community by enabling more cost-effective, integrated health and human services to the members. The development of telehealth applications can become an important part of a community's economic development and well-being.

Telecommunities foster healthy communities by providing access to electronic tools that enable personal self-health care, availability of professional health services in an extended community, professional and paraprofessional educational opportunities, and an increased health knowledge and awareness for the entire community.

Purpose of Program Development Guide

The Guide is provided to those institutions, agencies, organizations, and individuals who are interested in developing telehealth and telemedicine programs in California. It is hoped that this Guide may stimulate program developers to consider a systems approach to incorporating telehealth and telemedicine into a comprehensive plan and to recognize that successful programs will involve a collaboration of diverse organizations and technologies.

Two Primary Purposes of Guide

The Guide has been developed for two primary purposes:
(1) To provide a comprehensive overview of the activities that comprise telehealth and telemedicine program development.
(2) To present a pragmatic systems approach to implementing a needs-based, cost-effective telehealth/telemedicine program.

From this perspective, telehealth/telemedicine program development is not a stand-alone, technology-driven effort to provide medical treatment, but an integrated effort to provide system solutions within a complex and evolving health care environment.

Organization of the Guide

The Guide is organized into four steps: (See Figure 1).
Step 1: Strategic Planning
Step 2: Risk Management and Evaluation Feedback
Step 3: Program Design and Management
Step 4: Program Implementation

Systems Approach

A systems approach recognizes the need to address and incorporate three related elements: (See Figure 2).
(1) People. Decision-makers, service providers, consumers, including their values and attitudes toward change.
(2) Processes. Societal and industry issues, organizational structure and behavior, program economics, and professional work flow dynamics.
(3) Technology. Ever-changing product and service possibilities requiring dynamic and iterative assessment, as well as open and adaptive solutions to the challenges of changing service needs and integration of old and new technologies or migration to advanced technologies.

Introduction

Strategic Planning includes the participants, the mission, goals and objectives, assessment, and development and marketing and operational strategies. (See Figure 3).

Section's Topic

Sub-Topic

Participants in the Planning Process

Who Should be Involved in the Planning Process
Key Participants
Expectations
Participant Expectations

The Mission

Telehealth/Telemedicine is a Means to a Business End
Multiple Business Focus
Identify Existing Services

Goals, Objectives, Strategies

Measurable Goals
Strategies for Achieving Objectives
Primary Market and Customers

Assessment

Meeting Customer Needs
Significant Competitors
Barriers to Entry
Regulatory Barriers

Business Development/Marketing Strategy

Operational Strategy

Operational Strategy Components
Organizational Structure/Governance
Key Service/Performance Standards

Financial Performance

Introduction
Financial Projections
Partnering Strategy
Program's Fit with Core Programs

Who Should be Involved in the Planning Process?

Four major groups are encouraged to participate in the Strategic Planning Process:

• Health care institutions that will be directly affected by telehealth and telemedicine programs because of increased information/service sharing between the institutions.
• Key individuals within a health care provider organization who can identify the organizations goals and evaluate the existing level of technological and human support available for a telehealth/telemedicine system.
• Key individuals in each community who represent other communication needs within the community. Each of these community leaders can identify shared needs and the potential for shared resources, including funding, facilities, personnel, etc. The members of this group will help in the needs assessment, identify the relationships for resource sharing, and set out the strategy for pursuing a variety of applications based on their assessed priorities.
• Advisors and resource people, such as librarians and systems integrators.

Key Participants

Identify the lead representatives from the following organizations:

• Health Care Providers
• Contract Service Organizations
• Public Health
• Schools and Community Colleges
• City and County Government
• Libraries (public, academic, medical)
• Banks
• Telephone Companies
• Cable Companies
• Co-operatives
• Chamber of Commerce
• Other

Expectations

The expected outcomes of the collaborative process are:

• The formation of a group or groups that can drive the collaborative efforts at the community level and cooperation between health care institutions. These collaborative efforts will help identify referral relationships, sharing of information and facilities, and sharing of resources and expertise.
• A plan that identifies the services to be supported by the telecommunity, whether they are primarily telehealth/telemedicine applications or community-wide applications.

Participant Expectations

Each participant should develop a mission, goals and objectives for the organization's participation, e.g., what are the goals for the:

• health care provider?
• contract organizations sharing information from a telehealth/telemedicine system?
• community that might benefit from establishing common facilities and/or telecommunications?

This will help clarify expectations and roles of the participants.

Telehealth/Tele-medicine is a Means to a Business End

Telehealth/telemedicine is a means to an applied business service end. Telehealth/telemedicine is a health care program involving strategic resources, risks, and reward, rather than a type of technology. In this context, a telehealth /telemedicine program must have a defined mission and purpose within the total business effort. Once identified and articulated, the Program's mission and purpose will consistently define the scope and direction of Program development.

Multiple Business Focus

Given telehealth/telemedicine's multi-discipline aspects, the Program mission must address multiple business focus areas for all participants:

• broadly defined industry competition
• adaptive response to industry trends
• financial/economic performance
• service delivery and growth
• quality
• institutional and professional development
• impacts on the consumer's quality of life

Depending upon the participants' frame of reference, any or all of these elements can be included and prioritized within the Program's mission. Examples of possible missions follow.

• To create a new cost effective health care delivery system.
• To develop new revenue sources by using telehealth/telemedicine as an effective bridge to reach new consumer markets and community trading partners.
• To enhance competitiveness by delivering high quality service at controlled costs.
• To respond to external mandates, such as managed care and capitation, with delivery innovation and program service restructuring.
• To share the telecommunications installation costs among partners.

The Program mission statement leads to the next activity: Setting measurable goals and objectives.

Identify Existing Services

Identify the existing health care service and resource commitments that satisfy these needs. How well do the present health care services and the resources allocated to those services meet the needs? By evaluating each service, distinguish those health care services that must be addressed for further planning or resource allocation.

Measurable Goals

Once the Program's mission and purpose have been defined, it is time to create measurable goals and objectives. If telehealth/telemedicine is to be thought of as a means to a business achievement, then the goals should define that achievement. Within each goal, one or more specific objectives should quantitatively shape and clarify targets. Examples are:

• increase revenue 25% annually
• cut specific operational costs by 15% over the next two quarters
• capture 25% market share for an age/clinical needs population by the end of the century

The first acid test of strategic objectives is to determine how realistic they are and to identify inherent constraints by polling executive management and partners. If they want to pursue an ambitious goal, they must commit to taking a commensurate risk. In order for an objective to be realistic, it must have access to necessary resources.

Once the objectives have been quantified, reviewed, and deemed realistic, planners are ready for the next activity: Determining and testing Program strategies for achieving the objectives.

Strategies for Achieving Objectives

This activity identifies strategies for accomplishing the objectives of the Program. At this level, a strategy only requires a description of WHAT is to be done, not HOW it is to be accomplished. A strategy must:

• state the objective;
• determine the Program's intent by stating one or more actions (e.g., lowering costs, raising quality, expanding services) that, if satisfactorily completed, will logically accomplish the objective;
• state the assumptions as to why these actions will likely achieve the desired objectives; and
• provide a time line, including priority and order of activities, with a deadline for accomplishing the objective.

Now armed with the strategies for accomplishing our objectives, planners can move to the next activity: Defining the primary target market and customers.

Primary Market and Customers

A strategic plan must include a detailed description of the intended market and specific customers within that market. This portion of the plan should include:

• research describing the existence of the intended market
• data on the size and nature of the market
• significant trends relating to the market
• dynamic attributes or factors shaping or affecting the market's behavior
• key assumptions made regarding market analysis

With this knowledge planners can focus further on the specific customer (individual or entity) of the Program's intended services. Once the customer's identity has been established, a statement of consumer needs must be developed with as much real-world input as possible, including addressing changing needs. Now move to the next activity of the process: Stating how the Program will address the identified needs of the customer.

Meeting Customer Needs

The most critical question in Program development must be answered at this point:
Does the Program Mission, Goals and Objectives, and Strategies for achieving objectives competitively meet the needs of the identified customer(s)?

The Strategic Plan must state which of the customer's needs it will address through specific actions or service offerings. It is important to review the organization's internal objectives, so there is no conflict between loyalty to internal objectives and the objectives of the Program. All Program partners and management resources should be involved in considering the question. Some partners may leave the program at this time. After reviewing and modifying the strategy and/or customers targets, move to the next activity: Identifying and mitigating any significant challenges from competitors.

Significant Competitors

By adequately researching the target market, specific customers and their identified needs, planners should have identified any pre-existing or likely competitors that overlap or directly involve the target market. An assessment of these potential competitors must include their target market. What is their:

• mission
• services
• current presence and dynamic trends
• history
• possible defense strategies
• strengths and vulnerabilities

Specific comparisons and insights into competitors' mission, market, customers, and specific service offerings will determine if the planners want to collaborate with them or reshape the Program plan to fend off competitor encroachment.

Barriers to Entry

In addition to competitors, planners must also consider barriers to entry into the market. It is important to know if these barriers apply equally to all other potential competitors. If so, what abilities do the competitors have to clear these same barriers? Do the competitors have any other barriers that might impede their progress long enough for us to get a head start in the market? Do we have any specific advantages to overcoming these barriers? By clearing the barriers do we clear the barriers for our competitors as well? Ideally, such barriers will be significant enough to prevent competitors from easily overtaking the Program once it is underway.

Regulatory Barriers

Telemedicine is confronting emerging regulatory requirements, especially in areas of licensure and reimbursement. There are significant, dynamically changing barriers to entry that should be considered:

• legislation affecting licensure and reimbursement for telemedicine services;
• interstate licensure and trade issues when practicing telemedicine in other states;
• patient data security and confidentiality; and
• lack of accepted standards of care, method, equipment.

All of these challenges should be researched for current status and considered from an informed position.
Once the competition and barriers into the market have been assessed move to the next activity: Describing the business development and marketing strategy.

Business Development/Marketing Strategy

Building on the Program's definition of market and strategies for fulfilling customer needs, planners must prepare a plan of activities for regularly reaching this market and these customers. In today's health care and media market, the number of marketing channels is staggering. The ongoing effort and specialized resources required to promote the Program successfully must be carefully weighed. Planners must decide whether to resource the marketing function internally or out- source marketing efforts partially or totally. Competition within the health care market gives significant advantage to Programs that can more successfully reach, attract and retain customers.

A significant factor in telehealth/telemedicine business development/marketing is the need to educate Program participants and prospective market customers. This education is made necessary, at least in part, by the change in paradigm of telehealth/telemedicine services and the use of technology in ways relatively unfamiliar to health care consumers.

Operational Strategy Components

A critically important part of the Strategic Plan is the definition of an Operational Strategy, which is comprised of the following components:

• Program business structure (internal program, separate venture; corporation, partnership, etc.);
• IRS tax status (for profit, not-for-profit), if a separate program;
• Business/affiliation (subsidiary of provider/entity, new entity, etc.);
• Contractual status (member of trading partner alliance, association, group, network, etc.);
• Region(s) to be served (any unique regional attributes, e.g., geography or demographics);
• Number and type of locations;
• Service model (distributed primary care linked to specialists, rural services, etc.); and
• Payment options/plan affiliations/reimbursement assumptions.

With these operating characteristics outlined, define an overall organization structure.

Organizational Structure/Governance

The strategic plan does not detail the organization itself. It describes the structural relationship of key elements, including:

• sponsors
• administrators
• physicians
• health care personnel
• technology support
• program development personnel
• candidates for outsourcing
• partners (consider alliances and competitors as potential collaborators in addressing the range of services needed or in covering large or numerous regions)
• advisors/consultants
• evaluators

Additional detail can be overlaid regarding Program organizational leadership, decision chain and operational responsibilities.
The Program's governance should be described, including ownership interests, board of directors, and executive management. The Program structure must have clearly identified and authorized leadership to make decisions in optimizing all elements of the Strategic Plan: business, clinical, financial.

Key Service/Performance Standards

Standards of service and performance in critical operating areas must be included in the Operational Strategy:

· Clinical

Indicate priority of conducting outcomes analyses, method of analysis, customer/patient feedback methods, acceptable outcomes (90% patient approval rating, reduction of waiting times, growth of program enrollees, number of referrals/consultations, volume of patients/specific cases)

· Financial

Maximize profit margin, minimize associated costs of goods/services, accurately capture ongoing costs of operation, compete aggressively for new contracts

· Administrative

Reduce paperwork, increase compliance with regulatory mandates, reduce redundant data entry, minimize data loss, maximize transferability and usefulness of patient data, reduce labor overhead associated with scheduling Telemedicine exams, referrals, and consults; maximize EDI benefits with trading partners to reduce overall care system expense and improve care system performance

· Technical

Modernize critical health care information systems, improve access to data, make technology more user-friendly, use open systems technology to avoid obsolescence and promote interoperable health care systems, constantly test cost-benefit of newer technology through trials, pilots, and strategic alliances, promote technology as a tool to achieve target benefits, strive to integrate technologies and avoid proprietary, stand-alone solutions

Introduction

By setting standards for service and performance, the Strategic Plan spacing the guidelines for operation and can progress to forecasting critical financial performance.

Financial Projections

The Program's financial performance plan will involve projections based on market and operations assumptions. Telemedicine Programs need to operate on a profitable, cost-effective basis. The measures performance will include baselines of labor and materials costs, utilization reviews, service demographics, and an understanding of treatment strategy/disease outcomes.
Financial performance may be measured in terms of contractual performance under capitated reimbursement plans, or against competitors at negotiations for new contracts. Key financial data must be readily available about every aspect of operation in order to competitively meet new opportunities and adjust to rapidly changing service and competitive dynamics. In many cases, an ongoing review of financial performance, market dynamics, and industry competition may reveal opportunities for strategic partnering to share risk and/or reach new markets.

Partnering Strategy

Because of the complexity of the health care service environment the Strategic Plan should consider the need/advisability of strategic partnering. This partnering could take the form of:
· Key elements of the Program's own service offerings (clinical, administrative/contractual, marketing, technical support).
· The Program should decide whether or not to outsource internal elements for cooperative relationships, better internal focus, and sharing risks. The potential advantages must be balanced against possible loss of control, limited flexibility, increased coordination requirements, diffused responsibility, and potential non-aligned strategic interests.
· Extension of the Program into cooperative health care ventures, alliances, consortia, groups, or networks.

The Program must consider the advantages of:

• providing more comprehensive service
• competitive risk reduction by joining a larger, more resource-laden

• increased access to trading partner business referrals
• insight into a larger set of industry trends and concerns

These advantages are balanced by:

• need to conform to group standards and requirements
• possible initial investment expenses of achieving interoperable systems
• lack of overall control
• possible lack of flexibility due to potential impact on group
• possible risk exposure being tied to other liable entities

Program's Fit with Core Programs

As a final piece to the Strategic Plan, the Program's mission statement and operational structure should be reviewed periodically for the best fit with other core programs. Telehealth/Telemedicine Programs have inherent organizational complexity and may span traditional clinical, financial, or technical organizational boundaries. Over time, this fit with other core programs may provide opportunities to combine, consolidate, or synergize efforts and resources.

Overview

Risk Management is a commitment to identifying performance risk areas and to creating a Program environment that anticipates and overcomes problems by using evaluated feedback to adaptively ensure Program success. (See Figure 4).

Topic

Sub-Topic

Risk Mitigation

Definition of Risk Mitigation
Internal Risk Mitigation
External Risk Mitigation

Program Evaluation Feedback

Risk Measures Linked to Performance
Program Reviews and Evaluation
Specific Risk Control Actions

Definition of Risk Mitigation

Risk Mitigation describes a set of internal and external efforts to lower the risks of the Program operation. Risk management efforts impact the structure of the Program and how the Program involves and motivates its own personnel.

Internal Risk Mitigation

The following are internal Risk Mitigation actions:

• Use a systems approach (people, process, technology) for internal Program balance, perspective, and focus.
• Obtain senior management commitment to reasonable goals, resources, risk circumstances.
• Communicate and promote the Program to all personnel, not just those directly involved.
• Use a flat or inverted organizational structure and management style to empower service units; train administrators to support operation staff.
• Promote commitment to the Program through training and rewarding day-to-day Program efforts.
• Obtain management commitment to using operations feedback and providing consistent support to the Program.
• Use pilots to prove Program concepts and identify operations problems early in order to correct the course as needed.

External Risk Mitigation

The following actions can be taken to mitigate external risks:

• Recognize and build strategies to known barriers (legal, economic, security, confidentiality).
• Recognize telehealth/telemedicine as a bridge to external business relationships, trading partners, and new markets.
• Share risk among a team of strategic allies and trading partners.
• Use information systems to constantly monitor goods/services as the base line for aggressive contract negotiations and competitive marketing.
• Use a systems integrator to lower risk of runaway technology and to deal with the complex and ever-changing vendor/technology market.
• Out-source key functions to focus on internal strengths.
• Use strategic alliances to broaden perspective, to add strength/protections/resources, and to support response to a wider range of ever-changing opportunities.
• Commit the Program to keeping a global and industry view and willingness to expand and take on new partners.

Risk Measures Linked to Performance

Risk control measures should be linked to key performance areas and should employ metrics that are readily available and meaningful to operational personnel, management, and stakeholders. The process by which risk measures are determined requires that Program management work closely with operation staff and take actions that extend traditional management decision-making and responsibility boundaries. These actions include:

• Empowering staff to help set risk measures and to buy into performance goals.
• Linking performance risk measures and goals to specific operational units and people.
• Asking staff for risk reduction, savings and revenue enhancement ideas.
• Increasing performance risk measurement visibility.
• Matching a reward system with visible performance risk measurement and goal attainment.

Once performance risk measures have been set by active participation and buy-in throughout the Program, it is possible to connect the measurement process with active Program decision-making.

Program Reviews and Evaluation

The most direct way of involving Program staff in connecting performance risk management controls with active decision-making is through the use of routine Program Reviews and Evaluation. Program personnel collect, present, and participate in the analyses of the risk control metrics. Management and peer review are powerful reinforcers of the meaning, value and impact of these control measures on the Program.

Suggested risk control activities for routine Program Reviews and Evaluation include:

1. Earned Value Reporting

Progress credit is given only for the completion of incremental tasks or the attainment of performance milestones. This avoids the 90/10 rule where reporting is delayed until the last 10% of the schedule when many programs begin to report significant delays or problems. This method is effective against significant performance area failures.

2. Estimate-to-Completion (ETC)

Focus on performance risk and status reporting is shifted away from retrospective period reviews to a continual forward-looking reassessment of goal attainment. This method works well in dynamic event-driven programs, such as telehealth/telemedicine, since emphasis is placed on what must occur to meet Program objectives.

3. Risk Area Variances

Unlike traditional reviews in which adherence to meeting targets is stressed, this risk control stresses the knowledge gained from meaningful analyses of variances in performance data. The insights gained from the meaning of the variances supports a more dynamic decision-making process, which is critical to managing flexible, complex health care programs.

4. Quantifiable/Meaningful Measures of Program Performance

Such measures have the greatest risk control impact when matched to strategic objectives.

An Automated Information System is important for these Program reviews. These systems are used for gathering and presenting metrics for decision support during the reviews. Systems should be tailored to this purpose and make custom measures easy to configure and user-friendly. Poorly designed information systems may thwart a well-designed risk control program by becoming a barrier to routine use or by providing inaccurate and disassociated data.

Specific Risk Control Actions

The following are risk control actions for three major program performance Control risk areas:

1. Time/Schedules

One of the key performance risk areas is adherence to schedules, timeliness, and program component deadlines. A recommended action to guard against out of control Program implementation and operation slippage is Automated Project Management, preferably employing Critical Path Methodology (CPM). The key attributes of CPM are:

Control Action

Definition

Activities/Durations

Another risk control action to help eliminate schedule delays is creating cross-discipline problem solving teams tasked to remove obstacles and meet key deadlines. The teams should be hand-picked, representing a cross section of the Program's operational elements, and report directly to senior management for the duration of the effort.

2. Financial Control

• control areas of cost
• achieve predicted savings
• achieve projected revenues or margins
• meet return-on-investment projections
• deliver a cost-effective, competitive Program

• providing budget model guidance and management support for developing the budget, including proper allocation of fixed and variable costs;
• empowering and training operation managers to understand their business and service definitions and their corresponding cost of goods/services;
• empowering operation personnel to fine-tune useful measures of costs of their goods/services;
• encouraging operation personnel to know their customers and gauge their needs;
• training and gaining experience by using information systems to compare ongoing operational intuition with hard numbers

3. Program Quality

• Clinical services effectiveness - determination of how well the Program's clinical services meet the health care needs of its customers.
• Customer satisfaction - determination of perceived customer satisfaction. Typically, surveyed customer satisfaction has less to do with health care outcome and more to do with how well staff interact with customers.
• Regulatory requirements - determination and enforcement of standards and measures of quality prior to authorizing reimbursement, licensing operation, certifying professions and institutions, and assigning appropriate liability protection to provider programs, usually by external regulatory bodies.

Quality Category

As Measured By

Overview

Introduction

In Program Design and Management, the Guide will describe HOW the strategies of Steps 1 and 2 will be carried out through execution of Program functions and creation of an operational telehealth/telemedicine program model. (See Figure 5)

Topic

Sub-Topic

Authority and Responsibility

Program Management Authority and Responsibility

Program Model Needs Assessment

Developing the Program Model
Program Model Needs Assessment

Delivery Systems

Introduction
Delivery System Alternatives

Applications

Electronic Data Interchange
Specific Health Care Applications
Quality of Care
Public/Private Reimbursement
Liability/Confidentiality
Technologies
Prioritize Applications
Define Purpose of Application
Feasibility of Application

Clinical and Operations Protocol Design

Definition of "Protocols"
Clinical Protocols
Physician/Clinician Input
Clinical Systems Users Input
Administrative Users Input
Technical and Integration Support Input

Advanced Applied Technology

Scope of Guide
Telecommunications
Computer Hardware
Software (Database Engine)
Software (Graphical User Interface)
End-Instrument and Image Capture Integration
Videoconferencing Integration
Interface/Bridge to Existing Systems

Program Management Authority and Responsibility

Each Program's internal structure will vary, therefore the Guide will highlight critically important issues and functions to address in creating a Program management structure.
Program management must have sufficient authority and autonomy to accomplish the Program mission and to direct the Program according to the Risk Management Plan. The basic responsibilities of the Program management team are:

• Executive Program management coordination/control
• Business and technical operations
• Staffing
• Clinical/medical operations
• Finance and administration
• Quality control
• Business development/marketing
• Directive response to program feedback

Developing the Program Model

The design of the Program Model begins with a multiple needs assessment and the selection of an appropriate Delivery System Alternative. Within the design, consider linkages to trading partners, specific application, clinical and operational protocols, applied technology, and interfaces to existing systems.

Program Model Needs Assessment

Since the needs assessments will define the context boundary of the Program, the developer should obtain input from constituents. Recommended need perspectives are:

Perspective

Constituent Groups

Each of these perspectives should be formally reviewed using systems methodology, such as Business Process Analysis. The business or clinical needs of each group or entity is defined and re-engineered as an optimized relationship with the new Program. This analysis and definition should include:

• Definitions of respective missions and objectives
• Search for goal and objective overlap/synergy
• Conflict identification and resolution/compromise
• Search for mutual "win" strategies and defined buy-ins
• Concrete expectations
• Realistic evaluation criteria
• Model of baseline and re-engineered work flows (participants, trading events, cycle time and values)

Following the needs assessment process and the construction of relationship models, the Program can use the information to select a proper Health Care Delivery System.

Introduction

Each Program is a health care delivery system. As such, the Program may choose from several well-studied delivery system models. The choice of an appropriate delivery will depend on the Program's strategic definition of the service point of need. Because of current competition among health care programs, it is necessary to select the most cost-effective services closest to the physical and temporal point of need. Following is a discussion of current delivery system alternatives.

Delivery System Alternatives

Delivery System

Definition

Distributed primary clinic(s) or provider(s) linked to regional tertiary facility specialists

Used for referrals, consultations, case management, and continuing education. This delivery system can be either a privately owned/managed intra-net (open only to affiliated or group members) or an open consortia operating under a contracted or voluntary Community Healthcare Network (CAN) to serve community or regional needs

Peer-to-peer entity relationship

Providers/entities trade complementary services and eliminate redundancies and costly duplication and competition of services

Private/public sector outsource relationships

Specialist providers/entities contract with larger commercial employers, health services plans, institutions (e.g., prison system, schools) or agencies to establish telemedically linked facilities in which the provider/entity service the examination and consultation needs of the customer at the local site and makes care triage decisions and local referrals. This model is increasingly attractive to local site entities who wish to focus on early health care intervention and avoid lost productively and costs involved in seeking off-site health care and patient transport.

Case utilization review

The Program operates as a linked consultant to help review case treatment decisions as a critically important component of cost control within managed care and capitated care systems. This relationship may exist within any of the above models.

Advanced consumer based models

Privately or publicly accessible health care Value Added Networks (VANS) are established (telephone hot lines, electronic bulletin boards, Internet and World Wide Web, interactive kiosks, interactive television and satellite broadcast, CD-ROM packages) that provide consumer education and triage instructions.

Home-based health care

Providers/entities are linked to private homes via telephone, data line, satellite dish, or cable television modem for services and information. While still largely experimental, these home health care models can compete with or augment the current extensive and labor-intensive home health care industry.

Electronic Data Interchange

Following the choice of Delivery System, the Program can identify key Interchange-business or clinical entities to bring in as trading partners. A trading partner is a service or goods provider or recipient participating in a formal agreement in which the respective partners work closely together to align procedures, practices, and, ideally, information system components to meet common goals.
In advanced cases, trading partners can optimize information flow through the use of Electronic Data Interchange (EDI) in which subsystem modules or entire information systems are directly linked with common on-line telecommunication and database systems or indirectly interfaced via efficient data transfer based on commonly defined files and readable data formats.
In may cases, business and clinical decision support data (sales and inventory orders, case referral, clinical examination and lab results, physician's order, etc.) can be input directly from service site network terminals or pulled from digitally-adapted clinical examination room instruments. Considerations of EDI are:

• system compatibility;
• data security;
• procedural reconciliation balanced against cost-benefits derived from the common system elimination of work flow redundancy;
• reduced data storage;
• labor savings associated with streamlined procedures;
• faster and more accurate exchange of decision-making information to competitively speed the flow of goods and services closest to the point and time of need.

Specific Health Care Applications

Any specific service or application candidates should fit closely with the requirements of these Program development activities. (See Figures 1 and 2) Candidates might be included within the following areas:

Candidate

Activity

Quality of Care

• Specification of professional standards for practicing a particular telemedicine environment
• Specification of practice protocols for providing telemedicine services
• Specification of system compatibility standards for quality and accuracy of information transferred among various types of systems
• Minimum standards for effective diagnosis and treatment using telemedicine equipment

Review the specific types of telehealth/telemedicine technologies for patient services identified by local health care providers and institutions, including:

• Patient care eligibility policies and procedures for patients meeting the clinical and regulatory criteria for service by the technology
• Procedures for patient consent, provider consent and payer consent
• Staff training and education regarding the use of telehealth/telemedicine technology

Review the evaluation system, established by health care providers, that includes criteria to evaluate the performance outcomes related to the telemedicine activities, including:

• collection of provider, patient and payer process information about the events;
• identification of successes and failures of the technology to meet the identified needs of the provider, patient and payer involved in the process;
• analysis of the factors that contributed to the positive or negative outcome of the telemedicine events;
• identification of feasible interventions to improve outcomes;
• identification of diagnostic categories, specific medical conditions or specific procedures identified in provided policy manual.

Review telemedicine patient care protocols, established by health care providers, that identify types of services provided, necessary referral information, diagnostics, necessary monitoring assessments, documentation criteria, and scope of the consultation modality.

Public/Private Reimbursement

Review the reimbursement program established by third party payers, both public and private, for "value added" services provided in a telemedicine environment.

Identify telemedicine applications that satisfy the following criteria for reimbursement:

• safety of the patient is not compromised;
• consultation is medically necessary and is required by an attending provider;
• the consultation is assisted by the locally qualified presenter;
• the situation is outside the normal circumstances handled by the remote site;
• the consultation results in a written report to be included in the patient's medical record.

Liability/Confidentiality

Verify that the liability insurance policy protects against the consequences of data processing, telecommunication or other disasters.

Review state licensure statutes if the identified applications are for inter-state telemedicine consultations, and review the procedures for the necessity of having a health care practitioner present at the originating site and when the attending physician or other health care provider is not present for the consultation.
Review policies and procedures established by regulators and institutions, including:

• Rules and regulations at each institution;
• Situations in which licensing is required; and
• Practice parameters between providing consultative services and participating in a patient's care.

Review policies and procedures established by state licensing authorities, including situations in which licensure of individuals is required.

Technologies

Review known health care and technology standards.

Prioritize Applications

Prioritize and plan future telemedicine systems to fully support the mission and goals. When setting priorities, make sure that problems and opportunities (health care services) are addressed before setting the corresponding technologies (telemedicine applications).

Define Purpose of Application

Define the reason for considering the telemedicine application. For instance, a statement of opportunity for teleradiology might be:

To enable remote delivery and enhance diagnosis of radiological images to reduce the costs associated with transporting images, reduce the delays in the reading of images, increase the retention of local patients and improve the response of health care delivery.

A clear definition of the purpose of the application serves to focus the remaining activities and can be used in resolving differences of opinion and evaluating the effectiveness of the application.

Feasibility of the Application

This process addresses the feasibility of the application in great detail for technical, economic, and legal considerations. Consider also the political and human feasibility of the application. How accepted is the application among the organization, medical staff, medical community, and the general community? Assess the impact of the potential shifting of responsibilities and the redeployment of human resources to match those responsibilities. Also, consider the long term commitment required to insure effective use of the application and the expansion of the application.

Definition of "Protocols"

Each application requires a specific set of Clinical and Operations Protocols. This Guide defines such protocols as:

Pre-formatted instructions or templates that streamline and guide critical decision-making in the use and application of clinical and administrative services.

Clinical Protocols

Because telemedicine involves personnel communicating over extended media, such guidelines permit consistently safe and efficient use of equipment, material, and other scarce resources, timely and correct triage of patient condition to the most appropriate care, and productive use of expensive and valuable provider personnel time.

Typically, clinical protocols would be developed primarily by attending physicians and nursing staff, but telemedicine clinical systems will involve a cross-discipline team of physicians, system users, and system technician/integrators. Each clinical specialty (cardiology, dermatology, ophthalmology, etc.) to be involved in the Program will need to develop a consistent set of standard intake, examination, referral and treatment guidelines for all clinical personnel. Clinical protocols are defined as:
The instruction guides that allow well-trained personnel to quickly and accurately access each treatment situation and correctly use the resources of the telemedicine application and equipment to effect the highest quality care.

Physician/Clinician Input

The chief designer of the clinical protocol is the physician who details the correct and most efficient set of instructions to guide himself, his colleagues, and other health care personnel in the consistent application of care. These instructions will help initial examination and triage personnel in determining life-threatening or emergency conditions, appropriate referral and scheduling for non-emergency conditions, and the most critical/required intake data. The protocol should be thorough and clear enough to guide health care service with little or no direct supervision or consultation from the physician.

Clinical Systems Users Input

Telemedical systems extend clinical care and involve a growing number and type of support personnel. With the assurance of expert supervision only a telephone or data connection away, the role of primary care personnel broaden to include a wider range of nursing and paraprofessional staff.
These system users must contribute to the development of consistent, effective, and easy to use clinical protocols that guide them in the conduct of traditional or new roles. In many cases, physicians will not always understand the needs of this growing, diverse support staff. The majority of physicians may be new to their own roles within a telemedicine program.
Clinical protocols must include user-friendly computer software, adaptive interfaces with context-sensitive help, and operational features re-engineered to optimize the user's work flow. With tool-based protocols that streamline and drive procedures, the end-user can concentrate on higher order decision-making and quality care issues.

Administrative Users Input

Telemedicine systems usually extend the logistics of administration. New systems have relatively new guidelines for administrative procedure authorization, payor plan requirements, and complex utilization review. Telemedicine systems promote and accelerate the replication, update, and transfer of clinical information, including medical records, examination data, and financial information. As a result, administrative personnel must have input to be properly guided by clinical protocols that direct them to best support the case-by-case provision of telemedical care.

Technical and Integration Support Input

Telemedicine also involves the installation, operation, support, and evolution Integration Support of complex technology, including:

• computers
• telecommunications
• software
• digitally-interfaced clinical equipment

Clinical protocol development must include expert health care technology personnel to develop, install, and maintain software and computer-based protocols shared over complex telecommunications and data networks. The ultimate challenge for these technology professionals is to understand and integrate ever-changing technologies and tools while making their existence and use relatively transparent to users of the systems. Protocol-assisted decision support must not be constrained by after-the-fact technical complexity. Therefore, protocol development must involve these support personnel.

Scope of Guide

This Guide will not attempt to address specific products or vendors. However, there are definite categories of technology which provide the typical building blocks of telemedicine. Similar to basic construction materials, these technology components must be systematically and expertly integrated to fit-to-need, end performance and ongoing flexibility.

Telecommunications

Telecommunications is a very complex and rapidly changing environment ofissues, technological changes, and business competition. As a fundamental component of telehealth and/or telemedicine, it enables distant health care locations, various provider personnel, and consumers to communicate. The variable matrix services that can be offered are determined by:

• the nature of the communication (voice, video, data, analog, digital);
• the speed (bandwidth) at which it occurs;
• cost of transmission; and
• the locations it can be accessed from.

Telecommunication possibilities grow almost daily with a trend toward wider accessibility to higher speed digital lines at lower costs.

Computer Hardware

The hardware component primarily involves the workstation, display, and server computer platforms required to provide processing power, inter-operability, and clinical display resolution. A turnkey system includes the subcomponents in the following chart:

Subcomponent

Purpose

Central Processing Unit (CPU) capacity

transistor density to support increasingly complex embedded instruction sets

Chip set architecture

transfer word and memory update speed

Data and Input/Output bus architecture

Internal bus slot type and availability

Disk and memory capacity and access speed

Image capture and videoconferencing board integration

size, pixel depth, lines of resolution, color balance, refresh rate, aspect ratio, etc.

Image processing/display board capabilities

Screen and presentation display characteristics

Electro-mechanical input device

keyboard, mouse, touch screen, voice activation

Each of these subcomponents will have a direct impact on end-workstation design and performance and require the integration of distinct and rapidly changing vendors and emerging standards. Issues also exist at the server hardware level, but involve different processing requirements to support larger data storage, multiple user access and network operating system support, extensive system security, advanced systems administration utilities, and multi-media record storage and retrieval engineering.

Software (Database Engine)

The connected clinical systems of the Program will involve some type of electronic examination/patient record management system, which requires an automated database engine to provide relational storage and retrieval of information. This engine may also be tasked with management of compound documents (voice, video images, data, graphics) representing the medical record. The preferred requirements of such an engine are:

• distributed relational capabilities
• data awareness properties
• extensibility of data structure
• interoperability with other competing vendor products
• scalability to different processors
• platforms
• user volume loads
• performance in industry standard transaction and I/O benchmarks
• flexibility within different operating systems

Software (Graphical User Interface)

The graphical interface (screen) has emerged as a key component in providing users with intelligently designed, data aware, icon driven interfaces. Touch screen interactivity and simpler, more powerful screen interfaces are in demand. Applications making such demands include:

• multi-media data input and presentation
• interactive software training requirements

Graphical User Interfaces must be developed using vendor toolkits that provide customized and very powerful interfaces with both middleware (software libraries, utilities for specialized performance, and structured query language or SQL algorithms for reading and updating databases) and database engines. The choice of development toolkit and integration with middleware and database engine will have a direct impact on Program application capabilities, user-friendliness, and performance.

End-Instrument and Image Capture Integration

Telemedicine requires that remote examination take place using instruments that have been designed or retrofitted with sensor devices, typically cameras. These cameras range from digital to video and span a wide range of image resolution power and expense. Regardless of the sensor device, the image output must be transmitted to the telehealth/telemedicine computer workstation via cable or direct digital interface and be captured there for storage, processing, retrieval, and/or transmission. The capture can occur as a static high-resolution still image or a compressed multi-frame video clip. The quality, clinical validity, and cost of image sensing represents a dynamic and hotly debated issue.
It usually requires considerable clinical and Program management time to evaluate vendors to find the appropriate balance of clinical quality performance and cost benefit for the product. An alternative is to hire a systems integrator who can bridge the highly specific medical instrument vendor community, computer hardware industry, and the Program's clinical and business staff.

Videoconferencing Integration

The needs of the Program applications will determine the extent to which clinical interaction between sites and providers/patients will need to be accomplished via interactive videoconferencing. To address the Program needs that will require interactive videoconferencing, it is necessary to understand the component value of videoconferencing in telemedicine.
A common mistaken assumption is that telemedicine videoconferencing systems interfaced with clinical instruments provide a turnkey solution for telemedicine programs. Videoconferencing represents a solid, but separate, technology component that can combine conferencing with collaborative computing (simultaneously sharing software programs and files). Users can create environments wherein clinical imaging systems capture and transmit high resolution, data dense files, including examination video and patient records. While these systems solutions exist, the videoconferencing vendor community has generally stayed away from developing integrated software applications. The Program will need to develop or purchase its own applications and be responsible for custom software code integration (vendor supplied developer's kits) with the videoconferencing system.

Interface/Bridge to Existing Systems

A final Program Model consideration is interfacing or bridging new Program applications with existing information systems. Typically, existing systems have not been designed using open systems technologies, are often proprietary, and difficult to interface. It is important to carefully analyze the cost benefit and quality of outcome of directly interfacing old and new software applications and data structure. Often, it is easier and more cost effective to off-load data from the old system or both systems and manipulate it with customized programs to get the desired results. If this cannot be done, the Program may have to resource the reverse engineering required to get the existing systems in order to be able to proceed with new system development or the Program may have to purchase new systems. Now move to the Program Implementation.

Overview

Introduction

Program Implementation and Feedback will use a systems approach involving key leadership, process, change management, and technology teams. These teams will prepare the program for Pilot activities and cutover to full production.

(See Figure 6)

Topic

Sub-Topic

Pilot Program

Purpose of Pilot Program
Pilot Program Design Model
Pilot Program Activities
Pilot Sites
Pilot Site Facilities Preparation
Pilot Program Staff Training
Pilot Program Partners
Conducting Pilot

Production Cutover

Production Cutover Goal
Systems Approach to Production Cutover
Interface External Business Partners

Continuous Review

Continuous Review

Purpose of Pilot Program

Program Pilot Activities should be of sufficient scope and duration to obtain adequate Program concept feedback and to gain operations experience for Program management and staff. This experience will also better define, redefine or clarify goals and expectations, structure more meaningful outcomes evaluations, permit evaluation of Risk controls and contingency plan investments and examine risk mitigation strategies such as partnering and alliances.

Pilot Program Design Model

Once designed, the Program model can now be implemented on a trial basis as a Pilot Program. The objectives of a Pilot Program are:

• a limited-risk demonstration and trial of the Program concept and practical application;
• testing and modification of the activities and verification of assumptions;
• an opportunity to gain experience for Program personnel and management in determining real-world training needs and technical support levels; and
• a trial run for the combined clinical, administrative, and financial operations, using the systems approach (people, processes, technology) as a yardstick to measure impact and Program progress.

Pilot Program Activities

The Program Pilot activities begin with the design and structure of the effort. The design must encompass all the Steps:
Step 1: Strategic Planning
Step 2: Risk Management and Feedback
Step 3: Program Design and Management
Step 4: Program Implementation

Pilot Program activities should replicate production program model activities, including:

· Clinical, administrative, and technical operations

· Market, customer, and patient base

· Technology infrastructure and equipment

· Personnel

· Economics

· Risk area constraints (schedule, finance quality)

· Outcomes expectations

· Program management review and decision-making

Pilot Sites

Determine Pilot sites by the systems approach: preparation and the potential of people, processes and technology. Ideal sites will combine exemplary needs and realistic resources to support the Pilot, combined with representative personnel, existing program processes, and technical expertise.

Pilot Site Facilities Preparation

The Pilot site technical and equipment infrastructure should be reviewed for required upgrades, modifications, or installations. Site facilities personnel should be fully involved and buy into the facilities plan. Time should be allocated for ordering and installing equipment and telecommunications, infrastructure testing, and configuration management registration (site inventory of components and software versions). The facility's clinical floor space must be reviewed as part of facility design to optimize placement and work flow of the equipment.

Pilot Program Staff Training

Staffing and Personnel training requirements should be reviewed as part of the preparation. Program Model requirements for Program functions and services should be compared to site staffing and skill levels to determine any additional staffing or training requirements. Site staff must be involved in the training as detailed in Step 3 on Clinical and Operational Protocols. Once developed, these protocols form the basis for ongoing training for site staff on the nature and correct use and application of all Program equipment and operations procedures. Training should be conducted on-site, if possible, to better acquaint staff with changes to their environment. Ongoing site training and support can be supplied with refresher visits, videoconferencing, and/or interactive computer-based training modules. Training should simulate operational use, be personalized and closely related to specific responsibilities. The duration and frequency of training will vary by site, but should give adequate time for staff to feel comfortable with performing operations and pursuing Program objectives.

Pilot Program Partners

Communicating with alliance and trading partners should be part of the Program Pilot preparation activities. These organizations or individuals may have direct involvement in Clinical and Operations development (see Step 3 on Protocol development) and must be integrated into Pilot activities.

Conducting Pilot

Once Pilot site preparation and training have taken place, begin a limited schedule of service and operation, concluding with a Program management review. Following this internal review and corresponding adjustments, start a second period of service and operation, concluding with a Program Development Review.
This review will determine the extent of any further Pilot activities based on the perceived and measured value of the Pilot operations. When the Pilot has generated Program concept-proof and adequate operation time for two rounds of operations feedback and staff training/learning experience, a final Pilot Activities Summary Report containing edits and adjustments to the plan should be prepared for production planning, with a recommended Production Cutover schedule.

Production Cutover Goal

Once the Pilot Summary Activities Report, with plan adjustments and Production Cutover recommendations have been completed, the Production Cutover activities can begin. The immediate goal of these cutover activities is to build on Pilot feedback to prepare a plan for scaling the Pilot to Production levels. The Production Cutover Plan must address the Program's impact on people, processes, and technology and involve a methodology for production transition.

Systems Approach to Production Cutover

A recommended approach to implementing the Production Cutover involves the formation of transition and leadership support teams in five areas:

1. Leadership Team
The function of the Leadership Team, comprised of executive and program management, is to support production program kickoff efforts by communicating Pilot results, lessons learned, and current production expectations. The Leadership Team should provide an overview of the Strategic and Risk Management Plans as well as the Program Design and Management Model. The Leadership Team should demonstrate its commitment to the effort through ongoing support and participation in regular Program Reviews and by endorsing the Telehealth/Telemedicine Program Management Team.

2. Change Management Team

As the Program is cutover to production status, the Change Management team must help the entire organization understand Program activities and begin to understand and personalize their meaning and impact. This perception change across the organization is the beginning of the cultural and personnel change management process.
The Change Management team should communicate planned Program efforts and events internally to build understanding, gain buy-in, and foster motivation for the Program. The team can also sponsor briefings for familiarization with new procedures to help people overcome anxiety and concern over new programs. The Change Management Team is particularly visible during site preparation activities, working closely with local program personnel. Finally, the Change Management team is responsible for gaining buy-in and providing motivation through ongoing support and encouragement of staff in the Program.

3. Clinical and Operational Processes Team

This team of process experts chosen from within the organization is critical to defining standards and maintaining responsibility for clinical and operational protocols. As the Pilot activities end, this team captures significant lessons learned from operations and clinical summary reports to establish baseline processes for production cutover. As production implementation of the Program proceeds, this team plays an active role within training and site preparation to help set up and familiarize site staff with Program protocols. During implementation this team also monitors process compliance and progress as part of the regular Program Reviews.

4. Information System Transition and Support Team

In Programs involving necessary interaction with older clinical or administrative information systems, this Information System Transition and Support Team provides continuity and assurance of smooth interaction of the new Program. This team must gain the trust and confidence of the personnel responsible for the older system who may feel threatened by the Program implementation and seek early guidance from the Strategic Plan to know of any intended phase down, transition, or replacement of the older system.

If these events are planned, then the Transition and Support team must help plan a migration strategy that is effective for every systems element (people, processes, technology). If coexistence of old and new systems is intended, then this team will help build interfaces or bridges between the systems to optimize total Program functionality.

5. Advanced Technology Implementation Team

Depending on the choice of Health Care Delivery System (see Step 3 Delivery Systems), the Program may choose to support its requirements with advanced technology. The Advanced Technology Implementation team coordinates planned technology infrastructure investments and activities, balancing impact on people, processes, and the technical environment. This team is also responsible for working with a systems integrator to evaluate off-the-shelf technology to recommend new systems purchases, old and new systems integration, or new systems development to meet unique Program requirements. Finally, this team plays a lead role in interacting with any technology partners or strategic allies.

Interface External Business Partners

As a final step for full production cutover, all significant external business partners must be kept involved in the planning and implementation process. If these external entities are participants in the Program, then they must have equivalent production cutover schedules and activities carefully coordinated with Program management. A failure in a key supplier, referral source, or trading partner to come on-line at the required time, could be disastrous to an otherwise carefully planned production cutover.

Continuous Review

The systems approach is successful because of continuous feedback, review and course correction. It is important that not only Program staff, but all stakeholders are involved in the feedback and review process. If a telehealth and/or telemedicine program is part of a larger telecommunity, the Program should actively participate and provide feedback to the telecommunity Program. Periodically, all aspects, starting with Step 1, should be reviewed to ensure that the Program is still needed and on target.