Testimony for NCVHS; NHII Infrastructure Workgroup



National Committee on Vital and Health Statistics

Department of Health and Human Services

Meeting Location:

Crowne Plaza Hotel

1001 14th Street, N.W.

Washington, D.C. 20005

Hearing on Functional Requirements for

the Nationwide Health Information Network

July 26-27, 2006

Healthcare Information Technology Standards Panel

Elaine Blechman, PhD, co-chair, Consumer Empowerment Technical Committee

Floyd Eisenberg, MD, MPH, Co-chair, Biosurveillance Technical Committee

Jamie Ferguson, Co-chair Electronic Health Record Technical Committee

Thank you for this opportunity to discuss the core functions for the initial roll out of the Nationwide Health Information Network (NHIN), and talk about how they might fit into a NCVHS Draft NHIN Conceptual Framework. Before we engage in discussion about the work of the three Healthcare Information Technology Standards Panel (HITSP) Technical Committees, I would like to place the work of the HITSP in context with the NHIN, and then describe what is common across the HITSP committees by providing an overview of the HITSP process.

As part of the Department of Health and Human Services’ health IT strategy, the American Health Information Community (the Community) was created to advise the Secretary of Department of Health and Human Services (HHS) and recommend specific actions to achieve a common interoperability framework for health IT. The Community serves as a forum for participation from a broad range of stakeholders to provide input on achieving interoperability of health IT. “Breakthroughs” – the health IT applications that could produce a specific and tangible value for health care consumers that could be realized in two-three years - have become one of the primary products of the Community and at the second Community meeting held November 29, the Community members defined five breakthrough areas. Of these, four went forward through articulation of the long term view of the breakthrough and for three of these a “Specific Vision” of what can get done by the end of this calendar year has been identified. The specific visions are:

Biosurveillance - Transmit essential ambulatory care and emergency department visit, utilization, and lab result data from electronically enabled health care delivery and public health systems in standardized and anonymized format to authorized Public Health Agencies with less than one day lag time.

Consumer Empowerment - Allow consumers to establish and manage permissions access rights and informed consent for authorized and secure exchange, viewing, and querying of their linked patient registration summaries and medication histories between designated caregivers and other health professionals.

Electronic Health Record - Allow ordering clinicians to electronically access laboratory results, and allow non-ordering authorized clinicians to electronically access historical and other laboratory results for clinical care.

While the specific vision for each breakthrough provides a framework for achieving a general objective using health IT, more detail is needed in order to achieve the goals of the breakthrough. Accordingly, the breakthroughs were translated into what are typically referred to as “use cases.” The use cases enable health IT stakeholders to frame and focus their efforts in support of advances toward the breakthroughs.

The task of developing a process for standards harmonization to support each specific vision has been contracted to HITSP. HITSP was formed under the sponsorship of the American National Standards Institute (ANSI), coordinator of the U.S. voluntary standardization system. The Healthcare Information and Management Systems Society (HIMSS), the Advanced Technology Institute (ATI) and Booz Allen Hamilton serve as strategic partners with ANSI in this initiative to prototype and evaluate a nationwide standards harmonization process.

The HITSP brings together a wide range of stakeholders into a formal “panel” to identify, select, and harmonize standards for communicating data throughout the healthcare spectrum. Formation of the Panel was endorsed by a number of industry groups and has the oversight and backing of the Office of the National Health Information Technology Coordinator (ONC). John D. Halamka, MD, MS, chief information officer of the Harvard School of Medicine chairs the Panel.

The HITSP follows a use case driven process to develop technical specifications that inform stakeholders about how to use specific health IT standards to automate use case activities. To ensure objective and useful HITSP products, the HITSP Technical Committees were convened with outreach to stakeholders including patient advocates, providers, clinicians, vendors, standards developers and health information technology experts.

Harmonization Initiatives: Laying the Foundation for the NHIN

HITSP members and experts have committed themselves to setting and implementing standards that will ensure the integrity and interoperability of health data. A standard specifies a well defined approach that supports a business process and has been agreed upon by a group of experts, has been publicly vetted, provides rules/guidelines/characteristics, helps to ensure that materials, products, processes and services are fit for their intended purpose, is available in an accessible format and is subject to ongoing review and revision process. Harmonization is required when a proliferation of standards prevents progress rather than enables it.

In some cases, redundant or duplicative standards will be eliminated. In other cases, new standards may be established to span information gaps. In all cases, the resulting standards serve the consumer and other healthcare stakeholders by addressing issues such as data accessibility, privacy and security.

The Standards Harmonization Process

HITSP's most important work is the development of a well defined, repeatable process to identify the most appropriate standards for each AHIC use case. Our process to date is:

1) AHIC and its working groups develop Breakthroughs.

2) AHIC Working Groups or other customers prepare a HITSP Harmonization Request.

3) HITSP Technical Committees identify candidate standards which are harmonized into a final list of standards. They also identify overlaps and highlight gaps. Gaps are forwarded to Standards Development Organizations for their guidance as to emerging candidate standards or new standards requirements.

4) HITSP Coordinating Committees provide Technical Committees with important background information to support their work, such as objective criteria to evaluate the appropriateness of standards for a given purpose.

5) The final standards chosen by the Technical Committees are discussed and ratified by the HITSP panel.

6) These standards are available for public comment and feedback.

7) Technical Committees work with Standards Development Organizations and other groups to produce detailed specifications, an unambiguous “cookbook”, for the implementation of chosen standards. HITSP provides a convening and facilitation function for this activity.

8) HITSP work products are delivered to AHIC for their endorsement.

9) After AHIC endorses HITSP work, CCHIT will include functional criteria for interoperability based on HITSP specifications in its certification work. Hospitals and clinicians will be more likely to buy products which are certified as interoperable. This will lead to an increased success of vendors which embrace standards and interoperability.

[pic]

Coordination with other HHS activities

The standards harmonization activities of HITSP are well coordinated with the efforts of the other Health and Human Services Healthcare IT projects.

National Health Information Network architecture (NHIN) - Four lead contractors – Computer Sciences Corporation, Northrop Grumman, IBM, and Accenture have been given contracts to develop a nationwide architecture for the secure exchange of medical records using HITSP harmonized standards. These contractors generate requests for harmonization to HITSP and HITSP shares its work products with NHIN contractors through ongoing group forums that ensure ongoing coordination and communication.

Health Information Security and Privacy Collaboration (HISPC) – HITSP work products will be shared with the HISPC program management and harmonized privacy use cases will undoubtedly be shared with HITSP in the future to inform the selection of technical standards which enforce security

Certification Commission on Health Information Technology (CCHIT) - CCHIT has committed to include HITSP work products in its future certification criteria as described above.

Progress to date and next steps

HITSP has established an initial process for resolving gaps and overlaps in the HIT standards landscape. In June of 2006, HITSP reduced 570 candidate standards to 90 appropriate standards for secure exchange of medication, lab, and demographic data.

By September 29, 2006, HITSP will deliver unambiguous interoperability specifications which will enable vendors, hospitals and government to create software components for clinical data exchange.

Beyond 2006, HITSP will develop harmonized standards and unambiguous implementation guides which provide precise instructions for data sharing for all future requests for harmonization. Also, it will standardize the interoperability specifications for technology products, while permitting differentiation and competitive advantage in the marketplace. HITSP hopes to empower patients and care providers with Electronic Health Records (EHR) that facilitate easy access to critical health data that is accurate, private and secure.

HITSP is a key component of the Health and Human Services vision to create an interoperable healthcare system, and we look forward to our work products empowering patients, providers and government stakeholders in 2006 and beyond.

As was noted earlier in this testimony, the HITSP Technical Committees perform much of the detailed work in the process to harmonize standards, and their work is subsequently packaged for review by the full Panel. The NCVHS invitation to have the Co-Chairs of the HITSP Technical Committees to testify here today goes right to the source of the most active thinking about the current harmonization efforts which we hope will be informative and helpful to you. This does, however have the consequence that given the active stage of deliberations we are in, and the schedule of meetings for the HITSP Board and full Panel, the commentary we will offer today has not undergone that critical review by the complete membership, and therefore must be viewed as an encapsulation of the current thinking of each technical committee, not of HITSP more broadly, and is subject to our further deliberations and reviews over the coming months.

From the Consumer Empowerment Technical Committee (CE-TC)

CE Guidance: Please distinguish in your recommendations between the current NHIN use cases (registration and medications list) and broader consumer empowerment needs. Focus only on requirements for linking to the nationwide network for interconnection, not on the internal requirements of consumer empowerment systems or entities.

The Consumer Empowerment Technical Committee for the Healthcare Information Technology Standards Panel (CE-TC) has conducted a series of open sessions to create HITSP’s work products and deliverables related to the initial AHIC Harmonized Consumer Empowerment use case. All work products are the product of lively discussion representing all sectors of health care in the US. Since completing the Tier 2 criteria analysis of projected standards and the first NHIN Forum on June 28th and 29th, the CE TC has been coordinating our considerations for standards and implementation for our use case in preparation of our Interoperability Specification documents. This testimony attempts to represent those discussions faithfully, completely, and concisely.

The current CE-TC use case allows consumers to establish and manage permissions access rights and informed consent for authorized and secure exchange, viewing, and querying of their linked patient registration summaries and medication histories between designated caregivers and other health professionals.

The Personal Health Record (PHR) plays a key role in current & future CE-TC use cases and in NHIN rollout and linkage. Operational definitions and technical standards for provider-controlled electronic health record systems (EHRs) have evolved since the early 1990s culminating in HITSP’s development of interoperability standards. However, definitions and interoperability standards for consumer-controlled personal health record systems (PHRs) are just now emerging.

A PHR must have the attributes of consumer-control and interoperability in order to meaningfully empower consumers and engage a significant number of consumers and providers in NHIN rollout and linkage. The term PHR is now applied to systems that vary in consumer-controlled access privileges and interoperability.

Via consumer-controlled PHRs, individuals establish and manage granular role- and relationship-based access privileges for exchange of their personal information with specific persons (including family caregivers and health and human service providers). Interoperable PHRs permit the exchange of consumer information with diverse EHRs and edge systems.

|[pic] |CONSUMER-CONTROLLED |

| |NO |YES |

|INTEROPER|NO |Level 1 PHR |Level 2 PHR |

|ABLE | | | |

| | |View into Provider EHR |Freestanding Device |

| |YES |Level 3 PHR |Level 4 PHR |

| | | | |

| | |View into RHIO EHR |Consumer-Controlled Interoperable |

| | | |with Multiple, Diverse Edge |

| | | |Systems |

The CE-TC use case is, arguably, the one that relies most on the establishment of yet-to-be-determined policy that governs the behavior, roles, and responsibilities of the various system- and human-actors involved. Given this current dearth in widely accepted policies, we feel for traction to be made in standards selection, the requirements for NHIN rollout must accommodate more conservative (yet reasonable) policies that may be levied in this area going forward. Without accommodation for this level of policy, there may be scenarios in which our standards would fall short when instantiated within an unanticipated level of policy stringency. The general principle at work in this regard is the pushing of responsibility toward the edge systems where policies may be applied, while sanitizing the NHIN from most contextual requirements, rendering it as close to a pure infrastructure component as possible, divorced from many business rules. Therefore, our recommendations for NHIN requirements attempt to steer it in a direction that is definitive enough to enable actual selection of standards in the absence of many policy decisions, yet robust enough to handle a spectrum of possibilities for those policies.

1. The first requirement for NHIN rollout is meaningful consumer empowerment. A Level 4, consumer-controlled, interoperable PHR is a prerequisite for current and future CE-TC use cases and for NHIN roll out and NHIN linkage. Only a Level 4, consumer-controlled, interoperable PHR can support the exchange of information across the NHIN with multiple edge systems including, perhaps, a RHIO hosted document repository.

2. The second requirement for NHIN roll out is that the NHIN functions as a trusted steward of consumer health information. The NHIN must be unquestionably serving American consumers, their health care providers, and their local RHIOs, by efficiently and effectively storing and retrieving but not transforming, processing, or replicating consumer data. NHIN repositories, when edge systems may not be able to support them, must be faithful document-in, document-out information holders, but not processors. NHIN rollout requires consumer-trusted, tamper-proof, transparent, and end-to-end transport of document content with standards in place for: security infrastructure for all nodes end-to-end; patient identification services; and document sharing including registry and repositories.

3. The third requirement for NHIN roll out is that the NHIN functions as a fully transparent information mediator. The NCVHS functional categories now identify only data push and data pull. These categories should also include document/object sharing, that is, both push and pull, where the NHIN is a fully transparent i.e., trusted steward mediator.

4. The fourth requirement for NHIN roll out is that edge systems control data. We believe that a trusted steward of consumer information must avoid certain functions that NCVHS has delineated for the NHIN. The following functions should reside with edge systems: data rendering, data usage, data filtering of document content, data mapping and translation, and data content (except of setting standards for normalizing information and terminologies).

5. The fifth requirement for NHIN linkage is that personal health records control permissions. Successful NHIN linkage requires a robust infrastructure which guarantees that patient permissions are imposed and maintained. The PHR, as an edge system, must function to establish the source, manage and maintain the individual’s role- and relationship-based permission controls – what we are calling “granular consumer consent” at this point in our deliberations. The PHR system must control the promulgation and perpetuation of consent to all edge systems attached to the NHIN.

5. The sixth requirement for NHIN linkage is that edge systems communicate over the NHIN. The NHIN, by definition, must act as a trusted, transparent, unobtrusive information steward. Individual Americans must perceive the NHIN as an effective means to better health care, but not as an intrusive government agency. The NCVHS discussion template positions the NHIN as an all-powerful force in which communication of edge systems goes through (and is controlled by) the NHIN. We recommend an alternative discussion template that positions the NHIN as an infrastructure in which communication of edge systems moves over (and is facilitated by) the NHIN.

The Consumer Empowerment Technical Committee would like to thank you for the opportunity to comment.

From the Electronic Health Records Technical Committee (EHR TC)

EHR Guidance: Please distinguish in your recommendations between the current NHIN use case (laboratory results) and broader electronic health record needs. Focus only on requirements for linking to the nationwide network for interconnection, not on the internal requirements of EHR systems or clinical entities.

The Electronic Health Records Technical Committee of the Healthcare Information Technology Standards Panel (EHR TC) has conducted a series of open sessions to create HITSP’s work products and deliverables related to the initial AHIC EHR use case. The committee currently has 89 organizational members representing all sectors of health care in the U.S., and our committee meetings typically include lively debate on a wide variety of related issues. Since the first NHIN Forum on June 28th and 29th, the NHIN functional requirements and the relationship of the NHIN framework and NHIN concepts to the standards and implementation considerations for our use case have occupied some of our time in these open sessions, although it should be mentioned that those discussions have not been the main body of work for the committee. This testimony attempts to represent those discussions faithfully, completely, and concisely.

As context for the following points, I would like to refer to the three slides on pages 24 through 26 of the attached presentation. These slides represent the functional flow diagram for the EHR Laboratory Results use case that was published by HITSP in the Technical Committee presentation to the Panel (HITSP 06 N 95) on June 14th. They also represent an example of the adaptation of these functional elements into interoperability specifications for the scenario of sending an electronic lab result to authorized providers of care for use in clinical care. HITSP 06 N 95 is an Appendix attachment. I will now explain those diagrams in the slides.

As described in the slides, the EHR Lab use case can be viewed in two primary scenarios. In the first scenario, a releasable electronic laboratory result is sent to the ordering clinician, to specified authorized providers of care, and to a data repository. For interoperability in this scenario, a set of functional interactions must occur that require standard laboratory terminologies and message formats and that communicate characteristic message content.

In the second scenario, authorized providers of care may query either a data repository or a record locator service to retrieve lab results or result summaries. It should be possible to enter the queries from within an existing EHR system, or through an independent web application without an EHR system. For interoperability in this scenario a further set of functional interactions are performed, such as those to create and retrieve a structured document containing the lab results. All of these interactions involve multiple actors, and all of the actors described in this work generally are agreed to be edge systems for purposes of the NHIN. If these actors are unspecified edge systems, then a wide variety of implementation architectures is enabled in which any of these actors may be combined in edge system entities in practically limitless ways.

From the perspective of the HITSP standards specification for linking to the NHIN in the current EHR use case, functional services of the NHIN core should be restricted to a minimal set of transport services. In a manner in the electronic realm that is analogous to a commercial package delivery service in the paper realm, the core of the NHIN should deliver electronic “packages” to authorized receivers in a reliable and secure manner. And this should be done without opening the “packages” or performing any additional services related to their contents or their “containers.” Again using this analogy, the set of NHIN core functional services related to transport might include verification of the address of the recipient, authentication of the identity of the recipient, while giving the sender an acknowledgement of receipt. Related security policies and security profiles may require specification by the NHIN. Specific standards for these NHIN transport-related services should be determined by HITSP in consultation with appropriate designated parties.

Standards and related specifications determined by HITSP for most or all of the other functions required by the use case generally are used in functional interactions between health care systems and entities. The inclusion of standards for these additional functional services in the core of the NHIN would limit architectural choices; would have the effect of dictating selected implementation options in some cases; and could limit commercial variation by requiring the bundling of some optional functional services with mandatory functional services in EHR systems. An example of these effects is found in terminology services as described in the HITSP standards solutions to the EHR use case. For interoperability to be achieved a standardized set of terminologies must be used. There are many ways of achieving this end and a wide variety of solutions can be found in commercial systems marketed to edge systems. In this example, inclusion of standards for functional terminology services in the core functions of the NHIN could severely limit market choices and limit related implementation alternatives.

As in the functional diagrams, HITSP interoperability specifications for this use case will cover a variety of functional services in addition to those related to transport. Among others, some functional services for electronic clinical messages and clinical documents are ones to create, address, send and receive them, and to execute rules which perform operations on their contents and formats. Without favoring any architectural choices for edge systems, it still can be stated that multiple hierarchical tiers or layers of edge systems should be agreed to contain and perform these additional functional services. Specifying a multiple number of edge system tiers or layers would enable a wide variety of architectural approaches to be implemented because these additional services could potentially be placed in any tier or layer, in any configuration, and they could enable architectural variation to coexist more peacefully. This would be true particularly if their definition promotes a common set of interoperable interaction specifications between edge layers for the additional functional services. HITSP should select relevant standards and develop interoperability specifications for these interactions when the core services are defined.

Architectural neutrality would be promoted further if it were clear that any edge tier or layer could interact with the core NHIN transport services under specified conditions. An example of these edge system layers can be found in large states in which a state Regional Health Information Organization (RHIO) operates in conjunction with both regional and local RHIOs as well as multi-state delivery systems and networked communities of interest. In this example it would be helpful to have a set of conditions and specifications for interactions of these tiers or layers of edge systems with the NHIN core functional services. A categorization of such specifications for geographic and non-geographic edge systems could simultaneously allow for states to oversee health information exchange programs within their state, and for non-geographic networks or communities of interest to have common specifications for interactions with NHIN core services. It should be reemphasized that any such definitions of multiple tiers or layers of edge systems need not place any limit or constraint on architectural options. To enable standardized interactions of edge systems with the NHIN core, HITSP should be engaged to determine the standards and interoperability specifications as soon as policies are proposed that specify any conditions or boundaries for edge system interactions with the NHIN.

In summary, the HITSP EHR TC believes that functional services of the NHIN core should be limited to reliable and secure transport of unaltered electronic messages and electronic documents.

The Electronic Health Records Technical Committee would like to thank you for the opportunity to comment.

From the Biosurveillance Technical Committee (BIO TC)

BIO Guidance: Please distinguish in your recommendations between the current NHIN use case (clinical care –public health linkage) and broader biosurveillance needs. Focus only on requirements for linking to the nationwide network for interconnection, not on the internal requirements of biosurveillance systems or entities.

The Biosurveillance Technical Committee of the Healthcare Information Technology Standards Panel (BIO TC) has conducted a series of open sessions to create HITSP’s work products and deliverables related to the initial AHIC Harmonized Biosurveillance use case. All work products are the product of lively discussion representing all sectors of health care in the U.S. Since completing the Tier 2 criteria analysis of projected standards and the first NHIN Forum on June 28th and 29th, the BIO TC has been coordinating our considerations for standards and implementation for our use case in preparation of our Interoperability Specification documents. This testimony attempts to represent those discussions faithfully, completely, and concisely.

As reference for the following points, I will refer to the eight slides on pages 28 through 34 of the attached presentation. These slides represent the functional flow diagram for the Biosurveillance use case that was published by HITSP. They also represent an example of the adaptation of these functional elements into interoperability specifications for the scenario of sending anonymized or pseudonymized data from clinical care settings authorized public health agency Biosurveillance Information Systems to use in trend analysis for event identification, and situational awareness with respect to patterns of disease incidence and resource utilization. I will now explain the diagrams in the slides.

As described in the slides, the BIO use case can be viewed in two primary functional scenarios. In the first scenario, required data elements (patient demographics, laboratory orders and results, radiology orders and results, and encounter summaries) are sent in message format to the Biosurveillance Information System at the health department (local, regional, state or CDC). For interoperability in this scenario, messaging standards are used in point-to-point data submission based on a set of functional interactions. Only the first, message-based, functional scenario is provided for view in detail in the slides. In the second functional scenario, the same data elements are sent in document format to the Biosurveillance Information System at the respective health department(s). The BIO TC has reviewed the functional scenarios in context of several Clinical Exemplar Scenarios to maintain the context of the effort. The primary Clinical Exemplar Scenarios used for clinical context have been pandemic influenza, a bioterrorism event caused by anthrax, and a usual event requiring surveillance (for example sexually transmitted disease due to Chlamydia). The functional scenario components have now been addressed as constructs, which are transactions, transaction packages or components. BIO TC-specific constructs are shown as an example in the slides. Additional constructs that are common to more than one Technical Committee have also been assigned and are in process; these are not shown on the slides. All these interactions involve multiple actors, and all of the actors described in this work generally are agreed to be edge systems for purposes of the NHIN.

From the perspective of the HITSP standards specification for linking to the NHIN in the current BIO use case, functional services of the NHIN core should be restricted to a minimal set of transport services. Four requirements are specifically of concern from the Biosurveillance perspective. The NHIN must provide a secure communication channel and node identification for appropriate management of machine credentials. Credential management requires a policy for issuing such credentials in the edge system. The second core system requirement is a method for edge system actors (sending and receiving healthcare organizations) to request high-level filtering at the other edge. Filtering requires that data contained within a document are codified at the granularity needed for clinical care (i.e. diagnoses, symptoms, etc.). Rules for filtering can then be predicated on this concept level detail. Filtering is basically an edge system requirement, but a public health authority requires the ability to notify other edge systems to modify the filtering criteria for transmission of information. Third, the core system should provide a methodology and/or process for edge systems managing functions in related networks. For example, public health authorities as an edge system require hospital bed availability information. The same information is a component of the data set used by Emergency Management Service (EMS) organizations regarding hospital and emergency department utilization. Fourth, the core system must support a communication environment for secondary users of data and data sources. Public health and others will require additional security and privacy risk assessment. Policy for authorization will also need to be addressed.

From the perspective of the HITSP standards specification for linking edge systems to the NHIN for the current BIO use case, four high-level requirements are also identified. First, interoperability requires the edge system to send and/or receive message and document-based secure point-to-point communication; document-based communication will also require a shared document resource. Associated services include management of security, terminology services and pseudonymization capability to enable case investigation by authorized health department actors as appropriate within HIPAA guidelines. High-level filtering of data elements is a requirement to determine essential data at the sending and receiving systems. A second requirement for edge systems is anonymization for aggregation of data for trending analysis. Third, timely data flow management is a requirement of the edge systems. For the purpose of situational awareness of high-volume, high-impact illness (e.g., influenza pandemic), data has been requested by edge systems in real time, or near real time. Specifically, hospital bed availability at midnight on a daily basis is potentially less useful than a more frequently updated utilization report. The edge systems will require analysis to most effectively identify, provide and use such information. Fourth, edge systems will need to evaluate and manage the workflow associated with potentially large volumes of data sent and/or received.

Our committee also appreciates the opportunity to make some general comments. Syndromic surveillance and situational awareness are two key drivers of the Biosurveillance use case. Aggregate monitoring is managed successfully in a number of locations today. Bed utilization and conditions for which patients are seen in emergency departments are monitored actively using existing standards. HITSP can help significantly to enhance the process and enable greater participation. It is also important to note that Public Health is more similar to clinical healthcare delivery than it is different. The Biosurveillance use case provides an initial inroad to the interface between clinical care and Public Health. Hopefully it will create an infrastructure for a more collaborative care approach. Public Health, as with clinical care, requires as much data as possible for individual case follow up and contact evaluation. It is also important the note that requirements for core systems and edge systems are informed by architecture which are, in turn, informed by requirements. All should be considered in the effort to enable concordance of efforts. Lastly, standard development organizations (SDOs) have ongoing efforts towards harmonization and standard enhancement. Concurrent with the HITSP effort, many SDOs are quite near completion of some of these efforts that can significantly enhance the HITSP process. By coordinating efforts on harmonization, HITSP can more effectively evolve to accommodate an evolutionary approach.

The Biosurveillance Technical Committee would like to thank you for the opportunity to comment.

-----------------------

Four Types of Personal Health Record Systems

PHRs

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download