Download HITSP Testimony for NCVHS 072606 FINAL

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
2006 Healthcare Information Technology Standards Panel
2
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.
2006 Healthcare Information Technology Standards Panel
3
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.
Harmonization Process
Steps taken by industry within the context
HITSP
ive
ce t
Re ques
Re
I
II
Harmonization
Request
III
IV
Standards
Identification
Requirements
Analysis
V
VI
Standards
Selection
Gaps/
Overlaps
Resolution
VII
VIII
Inspection
Test
Interoperability
Specification
Construction
n
gi rt
Be po
p
Su
IX
Harmonization Process Management
Interoperability
Specification
Dissemination
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.
2006 Healthcare Information Technology Standards Panel
4
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.
2006 Healthcare Information Technology Standards Panel
5
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 providercontrolled 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 consumercontrolled 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.
Four Types of
Personal Health
Record Systems
PHRs
CONSUMER-CONTROLLED
NO
2006 Healthcare Information Technology Standards Panel
YES
6
INTEROPERABLE
NO
YES
Level 1 PHR
Level 2 PHR
View into Provider
EHR
Freestanding Device
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-bedetermined policy that governs the behavior, roles, and responsibilities of the various systemand 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, documentout information holders, but not processors. NHIN rollout requires consumer-trusted, tamperproof, 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.
2006 Healthcare Information Technology Standards Panel
7
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
2006 Healthcare Information Technology Standards Panel
8
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
2006 Healthcare Information Technology Standards Panel
9
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 nongeographic 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)
2006 Healthcare Information Technology Standards Panel
10
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
2006 Healthcare Information Technology Standards Panel
11
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
2006 Healthcare Information Technology Standards Panel
12
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.
2006 Healthcare Information Technology Standards Panel
13