[This Transcript is Unedited]

National Committee on Vital and Health Statistics (NCVHS)

Subcommittee on Standards

Hearing on Electronic Attachments Standards and Operating Rules

February 27, 2013

Hubert H. Humphrey Building
Room 705A
200 Independence Ave., SW
Washington, D.C. 20201

Proceedings by:
CASET Associates, Ltd.
Fairfax, Virginia 22030
caset@caset.net

TABLE OF CONTENTS

P R O C E E D I N G S (9:03 a.m.)

Agenda Item: Welcome

DR. SUAREZ: Good morning everyone. Welcome to this hearing of the National
Committee on Vital and Health Statistics Standards Subcommittee on Attachments.
My name is Walter Suarez. I am with Kaiser Permanente and I am one of the
co-Chairs of the Standards Subcommittee. On behalf of our entire crew, I want
to welcome you all and thank you, first of all, for your participation today
and for submitting your testimonies. I think this is going to be a very
exciting day, in terms of the topics that we are going to be covering.

I am going to start by asking everybody to introduce themselves. If you
could just please state your name and if you are a member of the Committee or
Subcommittee, please state if you have any conflicts.

(Introductions around table)

DR. SUAREZ: I think we are certainly live. We have a line for people to join
by phone. We will go ahead and get started. I will just make a couple of very
brief comments and let Ob also make some introductory comments.

This has been somewhat of a long time coming. It has been a while for the
industry to look into addressing the standards that are needed for the
submission of medical documentation as part of the administrative processes.
You all know about the rules that were published back in 2005, I believe it was
— the proposed rules on this topic. Of course, the Affordable Care Act
provision stated that the Secretary would need to publish final rules by
January 1st of 2014 on this topic, hence, the interest and the need
for the Standards Subcommittee of NCVHS to hold this hearing.

We have held a couple of previous hearing in the last couple of years on
this topic of attachments and just learning from the industry where things are
with respect to the standards, the coding use in the attachments, the processes
business and technical processes for putting together an attachment, and the
business needs for those attachments, the priority areas where healthcare
providers look for exchanging medical documentation.

We are here today, really, to learn and to listen, again, to the industry,
but with much more important focus and attention. We really are expected to
come out of this hearing and over the next couple of months with a series of
observations and recommendations to the Secretary with regard to several issues
around attachments, not the last of which, of course, are the standards to be
recommended to be adopted, the status and any recommendation regarding
operating rules for attachments, but then a number of other aspects around
attachments, whether they are submitted in a form of a solicited attachment or
an unsolicited attachment, whether they are submitted in a human readable
versus a computable information format, and a series of other questions that
have certainly been posed to the testifiers.

I think we are going to go ahead and move along. We have really two main
panels in the entire morning. One is regarding the attachment standards and
operating rules. The other panel is regarding industry perspectives with
respect to attachments. I am going to turn it to Ob to see if he has any
introductory comments and then we will move on to the panels.

MR. SOONTHORNSIMA: I just want to add, also, as background, obviously,
industry is going through lots and lots of changes, particularly with the
marketplace, the insurance marketplace. We want to be very, very prudent about
some of the things that we are asking the industry to do. This meeting is
extremely critical for us to learn more, as Walter said, and trying to balance
all the things that we are asking everybody to do, especially around health
insurance reform. Thank you.

Agenda Item: Panel One — Attachments Standards and
Operating Rules

DR. SUAREZ: Okay. Let’s just move along and start with the first panel. I
believe we have, first of all, HL7 is going to be presenting first. We are
going to be talking about the current state of attachment standards. I believe
each testifier will have between 10 and 15 minutes to make their remarks. We
have received more lengthy testimony.

I think what we would want to do is probably reserve some time right after
the testimony of each of the individuals to allow the Committee to ask one or
two, at the most, clarifying questions and really reserve most of the Q&A
time for after all of the testifiers go through. We will have a chance, if
anybody from the Subcommittee or the Committee wants to have a clarifying
question about a particular testimony, we will allow that in between each of
the testifiers. I believe it is Jim that is going to start?

Agenda Item: Current State of Attachment
Standards

MR. QUINN: I am actually going to start for just a minute. For the record,
my name is John Quinn. For purposes of this discussion, I am the CTO of HL7 and
have been for about six years now. I am one of the founders of HL7 going back
to 1987.

On behalf of the HL7 Attachments Workgroup, my team and I would like to
thank the Committee for the opportunity to provide comments on the current
status of standards that support attachments.

I am going to turn over — Jim McKinley, my colleague, here, will be giving
our testimony as it relates to this topic. I am here to answer questions that
are likely to occur that go beyond just the technical aspects and work of the
Attachments Workgroup. Thank you.

MR. MCKINLEY: Thanks, John. Again, I am Jim McKinley. I have been an
Attachments Workgroup co-Chair for a little over four years and actively
involved since 2005 in this effort. I would like to just jump right into the
first question, if I could.

What is an attachment? I think we will all get the answer to that in our own
way. The HL7 Workgroup defines an attachment as an electronic attachment, which
is supplemental documentation needed to support a specific health care related
event — an example of that is a health care claim, an authorization, or
referral. It could extend into other areas as the needs mature — using a
standardized format.

The primary focus for attachments should address additional information for
payer’s administrative functions to support claim processing. Although we
believe that there are other business uses for attachments to support things
like prior authorizations, referrals, notifications, and post adjudicated
needs. We further see attachments supporting other functions related to care
management, care transition, care coordination, risk adjustment, and on down
the line.

The attachment standards provide the industry with a path for growth that is
platform and transport agnostic, and can be deployed on mobile platforms as
well as mainframes and servers. These HL7 Standards can be leveraged to provide
the information and support as the industry needs advance for patient-centric
transparency and new models for health care delivery.

The second question is what are the priority business health related areas
for which attachments are necessary? What is expected to change in the next
five to ten years?

Attachments, initially, were intended in a limited capacity just to meet the
payer needs for correct benefit administration and medical policy adherence
when adjudicating a health care claim. In the near future, we believe payer
needs will also be expanded to include need for additional information of a
clinical nature, such as support for care management, care coordination,
transition of care, quality management and risk adjustment operational needs.

Migration away from the Fee for Service model to other re-imbursement models
may also alter the timing of additional information needs from a
pre-adjudication to a post-adjudication timeframe. The attachments information
may be also used in telemedicine and patient centric health care models.

Question three, what are the recommended approaches to submission of
attachments? The HL7 Clinical Document Architecture Standards support
approaches to structured and unstructured document types. Structured clinical
document architecture or CDA is designed to capture clinical information in an
organized and codified manner. CDA allows for the parsing of clinical
information specifying conformance criteria, whereas, an unstructured CDA
allows the exchange of virtually any type of information in an electronic form.

Use of external value sets for identification of valid attachment types
allow for quick addition of new types of attachments as the industry determines
their new needs. Today, payers and providers have a significant investment in
their EDI departments for the sending and receiving of the HIPAA ASC X12
transaction standards.

One of the benefits of the Health Level 7 CDA-based standard for Attachments
is it is transport agnostic and can be transported using a variety of transport
protocols. NCVHS might consider allowing the adoption of various transport
protocols either by trading partner agreement or operating rules.

Question four, what is the status of the development of attachment
standards? I am going to speak to three that are within the HL7 realm. The
first of which is the HL7 Implementation Guides for CDA Release 2: IHE Health
Story Consolidation, DSTU Release 1. This, throughout the remainder of the
document, will also be known at the C-CDA or the consolidated CDA. It is known
in the industry under numerous names. If you hear one, you know that is what we
are referring to.

This particular guide is a HL7 CDA Release 2 standard. It was balloted and
published in July 2012. The guide includes eight structured document types, and
a general unstructured document type. I will speak more to the structured
documents later.

The next is the HL7 Supplement to the Consolidated CDA Templated Guide. This
second bullet is referring back to the first standard in the first bullet,
which was balloted and approved for publication in January of this year. This
guide provides the criteria and information needed by stakeholders to utilize
the guide that we mentioned in bullet number one, the HL7 IHE Health Story
Consolidated Guide.

The final is a value set of LOINC codes, called the HIPAA Attachments, if
you will, on the Regenstrief Database. It lists the types of unstructured
documents that are available to be used for Attachment purposes.

Question five, are there other standards for clinical information exchange,
rather than in addition to HL7 Consolidated CDA that should be considered? It
is our Workgroup’s belief that beyond that of those specified from HL7 and X12
standards that we are familiar with through some collaborative efforts we had
over the years, we are unaware of any candidate standards that would be
comparable in functionality.

Question six, what metadata or pieces of information would be necessary to
include in an envelope that wrapped the contents formatted by the C-CDA? There
are quite a few. Some of them are candidate metadata for the request and some
are for the response and some can be for both.

Beginning with the first, which is the requestor, the name and identifier,
either a payer or an HMO, the identifier being plan ID, health plan ID, et
cetera, request receiver Name and ID, which could be the ETIN, the provider of
service name and ID, which would include the identified of NPI, an Attachment
Control number, which is payer or provider assigned, depending on whether it
was solicited or unsolicited in request — I will speak a little more to that
later — Attachment Information ID, what is needed, and that is defined by the
LOINC Codes that are on the Regenstrief — Daniel is going to speak a little
more to that — both in the request and response, date requested and response
due date, payer contact information, and date of service and encounter.

In addition to that, some other items are options to include as well —
Patient Control Number, which is assigned by the provider on the claim, Patient
Medical Record Number, which is assigned by the provider on the claim, then
there is Property and Casualty Claim Number, Case Reference ID, and Attachment
Request Tracking ID.

It is important to note that these are pieces of information that are
typically not a part of the clinical document either housed in the medical
system or can be assembled from the clinical medical system — the clinical
records medical system. Guidance is provided in our supplemental Attachment
guide for use of this metadata. Note, again, I said it can be assigned to the
request or the response.

Question seven, with respect to the envelope of the message, should more
than one enveloping standard be permitted to wrap the standard clinical
information? If so, what are examples of these standards that build on existing
or future infrastructure?

The HL7 Standards are agnostic to the envelope, provided it adheres to the
conformance of the metadata requirements specified in the Supplemental
Attachment Guide and previously listed on question six.

While the HL7 Standard was initially designed to work in conjunction with
the HIPAA ASC X12 transactions, HL7 CDA attachments can also be transported
using web-based transport protocols like Soap and Rest with the appropriate
metadata, again, included. Again, the X12 standards are built on a time tested
infrastructure for EDI interchange of HIPAA Transactions and Code sets. This
has been since the inception of the project in 2003.

Consideration might also be made to use different enveloping standards in
conjunction with those X12 standards through trading partner agreements and/or
operating rules. Potential use of infrastructure supported by Health
Information Exchange, such as IHE Profiles, might as well be utilized and
adapted to provide necessary enveloping features.

With respect to transport, question eight, how would you envision the
routing/transport — sending or receiving, et cetera? How could HealtheWay
and/or the ONC Direct and/or ONC Connect projects — how does it relate to
them?

Through the establishment of HIPAA, current routing/transport between HIPAA
covered entities, such as providers, clearinghouses and payers, is primarily
done through a secured FTP. Clinical/medical information could leverage those
same routing/transports for the exchange between those same covered entities.

With the addition of Health Information Exchange needs for the clinical and
medical information exchange, additional transport options for exchange could
be considered. The potential for real-time versus batch exchange should
consider appropriate transport vehicles, as well, for the exchange. Also,
portal applications may be used for direct data entry.

The HL7 Attachment standard could be adapted to be issued over the public
internet using HTTPS and the appropriate metadata and security protocols. This
would allow secure clinical data to be made available for clinicians, payers,
and patients as the standards and platforms evolve, into things such as mobile
health and beyond.

Question nine, should we consider optional or situational enveloping and/or
transport standards? The additional or attachment information exchanged using
the attachment standard is considered an electronic document. It is important
to note that additional information from a clinical record system may already
exist as a complete document or as one generated by software from information
in that clinical record system.

In either case, the electronic document should be at integrity with itself
from a clinical perspective and be comprised of clinical information
appropriate to the document type, while omitting information not a part of the
medical record, i.e., the metadata that we specified earlier. Hence, it is
creating a need for a whole new set of interfaces between the EHR System and
the AR system or Practice Management systems to request and get the attachment
so that the envelope could be properly created with correct content and then
the two later sent together.

Mixing clinical data originating in the EHR System and payment data
contained in the AR system creates a whole new set of possible use cases for
interaction between the two systems, for which they do not do this today.

In the attachments model, requests from a payer to a provider for attachment
information requires necessary re-association information, which is not
typically found within the medical document as it exists on the providers’
clinical records system. This information is unique — is used, rather, to
uniquely match the additional information with the request as triggered by a
claim, prior authorization, or the referral action.

Enveloping provides a consistent place for that necessary re-association
information from the requesting payer to be echoed back by the provider to
facilitate the accurate re-association of the attachment information with the
original claim or the original prior authorization or just a request for any
information. The Attachments Supplement identifies needed metadata for that
re-association, and enveloping methodology that conforms to those requirements
would be acceptable.

What is the set of attachment standards being recommended for adoption?
Again, this is from the HL7 perspective, consistent with the three that we
mentioned earlier. The first is, again IHE Health Story Consolidation, DSTU
Release 1, or the Consolidated CCDA, C-CDA. This standard provides guidance for
creating a compliant electronic document based on the Clinical Document
Architecture.

Compliant documents include both structured and unstructured electronic
documents. A structured document contains discrete data that’s available for
extract and parsing within the document and may be used for computer
processing. Alternatively, an unstructured document will contain information
that doesn’t contain discrete data and that doesn’t lend itself to
extract/parsing and is made up of word processing, narrative, or graphic
formats.

I wanted to depart just a moment from the testimony to add a little more
clarification to this. A clinical document formatted in the Consolidated CDA
standards is made up of two major components, a header and the body of the
data. In either the structured or the unstructured, the header will always be
parsible. It will always be formatted in a way that a computer system could
extract it.

That header is, again, metadata about what you find in the body. Even a
receiving system of an unstructured document will be able to glean some
information out of the header portion of it for the purpose of indexing it to
their repository system of images or whatever.

The second standard is the HL7 Attachment Specification, the supplement to
the Consolidated CDA. This is standard is intended to be used in conjunction
with the standard above and provides guidance and conformance requirements for
that standard implementation for attachment purposes. In addition to
conformance requirements for metadata, again, such as the re-association
information, the use of LOINC codes in structured and unstructured attachment
types, and the use of a preferred LOINC code in attachment requests and
response, the supplement also provides business cases and scenario examples,
expanded applicability of solicited and unsolicited as well as structured and
unstructured attachments, and the use of modifier LOINC, which can constrain
either a date window or an item type window for the information you are
desiring so you don’t get a full medical dump of information, if you will.

The third standard we are recommending is the Logical Observation
Identifiers Names and Codes, otherwise known as LOINC. This standard value set
segregates the subset of LOINC Codes that identify the valid attachment types
that may be exchanged using the two standards above. It also identifies
modifier codes, which can be used to constrain the time window and item
selection of that additional information that is being requested as a part of
that subset.

HL7 has worked closely with ASC X12 in their development of a set of
enveloping standards and we expect them to speak to those standards when they
testify.

The overall concept of attachments was originally tied closely to the HIPAA
transactions for claim submittal — wow, was tied closely to the X12 standards
of the HIPAA transactions and code sets. This same set of stakeholders, who
would be using attachment information, are also the ones that were receiving
and exchanging the HIPAA transactions. It would be minimal impact to simply add
an attachment standard within that infrastructure. For that reason,
consideration of the ASC X12 standards should be given to include them, at a
minimum, as a permitted option.

Are there any known limitations or gaps to the recommended standards? How
will they be addressed?

Let me see — the HL7 Standard, IHE Health Story Consolidation, DSTU,
provides guidance and conformance requirements. Structured documents lend
themselves to computer processing, and are potentially advantageous to the
consumer of attachment information.

Briefly to touch on the eight components of that in structure form, there
history and physical, CCD, Discharge Summary, Diagnostic Imaging Report,
Operative Report, Procedure Note, Progress Note, and a Consultation Note. Any
other attachment types needed but not satisfied by the eight listed above can
easily be accomplished by using the unstructured segment of that format. The
process for acquiring the attachment types is as simple as following the
recommended process found in the supplement.

HL7 standards are designed to be relevant to the stakeholders. A new
codified attachment request required by the industry, HL7 is prepared to
develop and add new content using those new industry needs in a structured
format. We will do them first in an unstructured and then progress them forward
to a structured format so that computer processing can be done.

Are there any operating rules recommended? In general, potential operating
rules would address implementation issues not already specifically addressed
within the standards proposed for adoption by our Consolidated CDA. Optionally,
some of those may also be part of the regulation.

Potential operating rules could include guidance on transport protocols, or
business rules that address the appropriate time between a request and a
response and before the requestor of attachment information can take action on
a no response.

Are there recommended standards or operating rules applicable only to claim
attachments? The type of attachments appropriate that would support a claim
benefit or medical policy adherence are very consistent, identically, with all
the other attachment purposes and needs we have listed before.

What are some of the business and technical issues surrounding attachments
for providers and health plans?

HL7 understands that an extensive architecture already exists for
information exchange based on the HIPAA transactions and code sets. The
architecture currently being used by the same stakeholders is anticipated to
participate in attachments information exchange. Adoption of this architecture
using the X12 standard could have the least impact on the payers, providers and
the clearinghouses.

I am going to skip ahead just a bit. I do want to make a point that the
Consolidated CDA is the identical standard that has been adopted under EHR
Meaningful Use. The providers and their vendors are already adapted to creating
some of that standard format outbound right now.

Since HL7 is a XML-based, the industry will require resources that are
versed in web-based services, protocols, and security. Current payer EDI
departments may not be versed in web based services and will have to leverage
resources from other areas.

What acknowledgement functions, in closing? Well, we think the
acknowledgement functions could be made available at the functional and the
content levels, but not much deeper than that.

DR. SUAREZ: Thank you very much. Are there any pressing questions from any
of the Subcommittee members before we go on to the next? I do have a few
questions, but we will reserve it until the end. We will go to attachments
coding.

MR. VREEMAN: Thank you very much for the opportunity to speak with you
today. I am going to speak about some of the questions, but not all and one
that is not on this list, which is a little bit about LOINC and why it has come
up in this context.

Regenstrief has been involved and interested in clinical data exchange
standards for a very long time, since its earliest days when Clem McDonald
arrived and was building a medical records system for a single outpatient
clinic. That work evolved into forming the basis of a regional information
network called the INPC, which is the nation’s most comprehensive and longest
tenured one.

In the course of that work, we encountered a very, very common problem. That
is local systems have totally different ways of identifying the same conflict.
At the same time, things that look alike are not always the same. For example,
when you are trying to connect two different laboratory systems, you might see
something like this.

Lyme Disease Serology in one, Lyme Disease Antibody in the other, and the
clinicians will say, oh, yes, of course, all antibody tests are serology tests
so, yes, these things on the surface look very much the same. When you look
underneath that at what actually this particular measurement is doing, one is
measuring IgM using an immune blot method and produces a qualitative result,
whereas the other is measuring IgG using ELISA method that produces a
quantitative result.

These things aren’t, from a computer perspective, directly computable or
comparable or aggregatable. Yet, from a human perspective, you would say, well,
they are kind of alike. The naming of these and the coding of these in local
systems is confusing because it doesn’t necessarily address that.

That same phenomenon happens in many, many domains, whether you are talking
about the titles that people give clinical notes, for example, these are sort
of all variations of outpatient pain clinic notes or radiology report titles
and other kinds of clinical measurements. What was needed at the time when Clem
was trying to connect up multiple hospitals was a vocabulary standard to be
sort of that Rosetta, the universal set of codes and identifiers for these test
measurements and observations.

Out of that sort of real practical desire to make this work in Indiana, he
developed the LOINC standard to solve the problem not just for Indiana, but
truly for the informatics field and the healthcare industry worldwide.

LOINC, Logical Observation Identifiers, Names, and Codes is designed to be
this coding standard for tests, measurements, and observations to facilitate
data exchange, pooling, and automatic processing of these results. It was born
in 1994 at Regenstrief. It has been distributed since the very beginning and
through today, worldwide, at no cost. I like to say it is free, but invaluable.

It is copyrighted to protect its integrity, but licensed in an open way.
Essentially, the only thing you are prohibited from doing with LOINC is using
it to make another standard, which would defeat the whole purpose of having a
standard in the first place. It is packaged up and released twice per year in a
formal release cycle.

Roughly speaking, the content in LOINC can be thought of in two main
categories — laboratory content and clinical content. Laboratory would be
stuff you would measure on a specimen. We have codes that cover all of the
usual clinical laboratory spaces — microbiology, chemistry testing,
hematology, and so forth.

The clinical side is — you can sort of think of as anything you might test,
measure, or observe about a patient not a specimen. It includes things like
basic clinical measurements, vital signs, height, weight, document titles for
the notes that a clinician might write for radiology studies, and also codes
that serve as collectors of other information. So a laboratory panel or a data
set like CMS’ minimum data set, the OASIS data set, which are large collections
of many variables, LOINC has a structure for organization that content as well.

LOINC has been around for a while, since its first release in 1995. It is
mature, but yet evolving. This graph just shows the number of codes in the
database per release, which happened, as I said, about every six months, June
and December. Overall, there are about 71,000 codes in the database. The
content, roughly two thirds of it would be laboratory tests and a third of it
would be these other kinds of clinical observations.

It is used broadly. Currently, more than 21,000 users world-wide in 150
countries. That has been growing quickly as more people are doing electronic
data exchange using standards. We add about 500 new members or users per month.
We have doubled in less than two years.

We have had a long-standing relationship and close collaboration with HL7
and other standards organizations, but our work with HL7 goes actually back to
the beginning of both organizations, not surprising given that Clem played a
major role in both of these. We have work closely with the Attachments Group
since the beginning as well and, actually, last year signed an official
agreement between the two organizations just sort of solidifying our commitment
to work together to develop complementary standards that work well together to
solve important problems.

LOINC has been adopted as a national standard in a variety of different
contexts in at least 15 different countries, including here in the U.S. I will
just mention a couple of those contexts.

Today, all of the big labs, the large referral commercial laboratories have
adopted LOINC. Most provide either the codes in their messages outbound or
tables that allow you to map their internal codes to LOINC codes. In a variety
of efforts, such as the Consolidated Health Informatics Initiative, the
health-related federal agencies have adopted LOINC in a variety of different
ways.

Lots of care organizations that want to standardize data are using LOINC.
All of the health information exchanges like the Indiana Network for Patient
Care have grown up by using LOINC in one capacity or another. Insurance
companies for both internal aggregation of data, but also for things like
quality measures/specifications are using LOINC, HR vendors. I am particularly
excited about the growing interest I am seeing from instrument manufacturers
who are coming to us asking for codes for their instruments so that all of
their customers know exactly what the code is.

Of course, a lot of interest and activity recently in the U.S. has come from
the Meaningful Use program. In that context, LOINC has been adopted in a
variety of different ways. One of them is in the use of electronic quality
measures for quality measure reporting.

The HIT Standards Committee adopted vocabulary recommendations across a
variety of different domains or contexts. LOINC was adopted in that context for
essentially anything that had to do with a test, measurement, observation, or
something like that.

In the most recent iteration, Stage II iterations, LOINC was adopted in the
context of messaging centers like HL7 for a variety of different purposes, such
as care summaries for reporting cancer cases to state registries, submitting
lab results to public health, or sending/receiving electronic lab results in
ambulatory settings as well.

My recommendations around the standards for attachments are actually
identical to the ones put forward by my colleagues from HL7, which is this
combination of the Consolidated CDA guide, which is used widely in other
contexts outside of just attachments, combined with the Attachment
Specification and, inside of that, LOINC codes to identify the clinical
content.

In the context of attachments, whether for claims purposes or other
purposes, LOINC codes sort of serve three main goals. The first is identifying
the specific kind of information being communicated in both a request and
response. Just like you order a single laboratory test, the same LOINC code
could be used for placing the order and when you receive back that test, as
performed, as a result. LOINC codes can serve both for requesting information
and the response saying here is what I have.

What kind of information? Is this a discharge summary? Is this a radiology
report, a chest CT, a consent form? What is this kind of information? That is
what the LOINC code provides. In addition, the LOINC database has a field that
we have added for the purpose of flagging each record that is allowed for use
in an attachment as either structured or unstructured. It is easy to find how
that information should be communicated. That is one goal.

The other use of LOINC is to specify these variables that modify different
parameters used in fulfilling the request for information. We call them
modifier codes, but they are codes that would indicate a modification, for
example, to the default time period. Say give me all the data 30 days prior to
the service, rather than everything you have ever seen. There are codes that
indicate those modification parameters.

Lastly, in attachment responses that would be coming back using Consolidated
CDA or other types of messaging. LOINC codes identify that content in a variety
of ways. For structured attachments using Consolidated CDA, LOINC codes would
identify the attachment type, the sections that are within that, some of the
sub-structure, and potentially individual entries within those sections.

For example, in a continuity of care document, a summary document, there
would be a LOINC code that says this is a CCD. This is a summary of an episode
note. There might be a section inside there for vital signs. There would be a
code that indicates this is a collection of vital signs. In that section, there
would be an entry, say, for respiratory rate and a LOINC code to identify that
measurement as well. The codes identify the specific kind of content being
communicated.

I wanted to briefly share some of the tools that are available today as part
of sort of the normal LOINC distribution for implementers and their relevance
in this context. One of them is a page where we sort of have pointed to some
additional information that cross-references what is contained in the HL7
Attachment Supplement. Much of what I am saying today is sort of on the web
page for LOINC users.

We have a generally available online lookup tool, search.LOINC.org, where
you can basically go to type in words and find out what is in the latest
version. This works across the entire database. With some keys, you can, for
example, find and filter on that attachments structured or unstructured field
that I mentioned earlier to sort of figure out, okay, what are all of the codes
I could use for unstructured attachments and see some examples of that.

Since the beginning, LOINC has always been distributed with some software
tools to help people map their local codes to it. This program we call RELMA,
the Regenstrief LOINC Mapping Assistant. It works — it has some features just
for searching the database like that online lookup tool. It is a Windows-only
program so you have to download it and install it on your machine.

There are some search functions where you could find the codes using the
fields that I indicated earlier. There is also a special sort of attachment
viewer that makes it easier to directly get to that content. Here, I show a
screen shot of that attachments window that has three tabs, one for structured,
one for unstructured, and one for these modifier codes.

In the context of Consolidated CDA, you can browse down and say, okay, what
are the codes I can use at the document type level or the attachment type
level. Here, I have indicated the discharge summaries. If you click on the
discharge summary code over on the right hand side, you will see the allowed
section headers from the consolidated guide, the list of those LOINC codes
there, and entry codes that might be applicable, too. Mostly, these are sort of
the section level codes so finding all the codes you need for each one of those
in one place.

There is also a tab that would list every code that has been flagged in the
database for use as an unstructured attachment. This would be things
potentially like consent forms, DME things, and so forth. The third tab is
these request modifier codes, these time window parameter modification codes,
and so forth, to find those. You can see each of the individual ones that might
be used in a particular request to alter the default specification there.

There is sort of a brief introduction to LOINC and attachments. I would be
happy to take questions. Thank you.

DR. SUAREZ: Thank you so much. This has been terrific. Any pressing
questions from the members of the Committee? Okay. Please save your questions
for the end then, too. We are going to move to X12. I believe Margaret will be
speaking.

MS. WEIKER: I am Margaret Weiker, Chair of the ASC X12N, which is insurance
subcommittee within X12. I want to thank you all for inviting me today to
speak.

A little bit about ASC X12, we were chartered by ANSI in 1979 to develop EDI
standards for national and global markets. We have more than 315 X12 EDI
standards and increasing X12 XML schemas. ASC X12 enhances business processes,
reduces cost, and expands organizational reach.

ASC X12 standards are used to electronically conduct nearly every facet of
business to business operations today. We also have members that include health
care, insurance, transportation, finance, government, supply chain, as well as
other industries.

A brief history, a very brief history, ASC X12 supports the definition of an
attachment given by HL7, as well as WEDI. We all three agree that an attachment
is electronic attachment is supplemental documentation needed to support a
specific health care related event using a standardized format.

Since 1997, X12 and HL7 have been working together to develop attachments,
as well as pilots were conducted initially to test the implementation of the
standards and to measure ROI. As part of those pilots, there was significant
return on investment for those that participated.

The NPRM for attachments was published in September 2005. The standards have
been updated since 2005 based upon the pilots and recommendations they made as
well as on business requirements that our users that were part of the pilot,
but maintained still sending the attachments via that mechanism, as well as,
recently, we made some changes to support the ESMD Project.

There are two models in regard to attachment data that can be exchanged.
There is the solicited model, which defines a process where — and I am going
to use this as a claim example — where an original claim is sent without
additional supporting documentation. The payer then subsequently identifies an
additional data need and requests that additional data using the ASC X12 277
Request for Additional Information Transaction.

The provider, in turn, responds with the ASC X12 275 Additional Information
in support of the health care claim or encounter transaction. The 275 contains
the embedded HL7 attachment data. The TRN segment or the Trace segment in the
277 is defined by the payer. The TRN segment values are returned in the
appropriate X12 275 Trace Segment information and that is how a payer ties the
attachment to the original claim. There is a flow chart it includes, as well as
the acknowledgements for the transactions.

In the unsolicited model, the attachment is sent electronically with the
original claim. This particular data flow has the potential to significantly
diminish the effort needed by payers to adjudicate and pay the claims as well
as the time involved with resubmitting claims with additional supporting
information.

In this model, the provider knows the payer needs the additional information
and submits the 837 health care claim and the ASC X12 275 transaction with the
appropriate HL7 information embedded in the 275. These specifications can occur
within the same data interchange envelope. In other words, both the claim and
attachment data are sent at the same time within the same transmission. They
can be in different interchanges; however, they are done in the same
transmission.

There is a segment called the Paperwork segment that exists in the 837,
which is defined by the provider. The TRN segment or the Trace segment in the
275 has the same value that is contained in the Paperwork segment in the 837.
That allows the healthcare payer to tie the claim to the attachment.

In regard to some of the questions that were posed, in regard to what
standard should be adopted, ASC X12 recommends that Version 6020 be adopted for
the 275 for the healthcare claim or encounter. There is also a separate guide,
the 275 Guide for Health Care Services and Review and then there is the 277
transaction, which is the Health Care Claim Request for Additional Information.

The standards development organizations have not come to a consensus on how
to acknowledge the combined standard transaction of the 275 and the HL7 at the
application level. We are recommending at this time that the TA1 and the 999
transaction acknowledgements should be included as part of the first level of
acknowledgements.

What other type — what are the business priorities attachments? Claims and
Post Payment, which includes clinical reports, labs, rehabilitation, consent
forms, Durable Medical Equipment, prior authorizations and referrals. There is
also care management and quality care measurements, as well as pre and post
audits.

In addition, workers comp and the property and casualty industry has been
using electronic attachments for over eight years. Some of these are required
by state laws to be submitted with the claim as part of — based on their bill
type. The IAIABC Jurisdictional Model Rule, based in 2009 adopted the 275
transaction. The states of California, Texas, Minnesota, Louisiana, and Georgia
have adopted this as well as 12 other states are considering adopting it in
their legislative session this year.

What are the recommended approaches to the submission of attachments? The
administration of an event of an existing infrastructure within the X12
transaction links the individual to the events. The administrative envelope
layer is necessary to maintain the original claim data along with the
administrative and functional separation that happens through the life of the
event. Trading partner relationships establish how to maintain and control
these electronic interchanges. They are managed through existing EDI gateways
today.

The X12 infrastructure represents a considerable investment over many years
throughout the industry. Implementing a new protocol/standard would require
substantial new investment. We recommend utilizing the current standards and
structures to reduce the financial impact and speed adoption of the time frame.

The X12 standard also supports the unsolicited as well as the solicited
exchange of attachment information as conveyed within the HL7 documents of
structured or unstructured data.

The next question has to do with operating rules — or questions have to do
with operating rules. Some of the operating rules that X12 sees as potential
are defining and publishing the attachment requirements to leverage the
unsolicited business flow, information on MIME packaging and Base64 encoding
for unstructured clinical content, timeliness of a submission of an attachment,
and, of course, we recommend that both ASC X12 and HL7 subject matter experts
be involved in the development of the operating rules for attachments.

ASC X12 supports the HL7 standards as well as any HL7 proposals under
development for attachments.

The metadata pieces that would be necessary to include in the envelope —
these are included in the ASC X12 275 transaction. I am not going to read them,
but they are listed here.

With respect to the envelope and the message and should there be more
examples, as I stated earlier, we recommend using the existing EDI gateways
that support the ASC X12 transactions today since this is a proven standard
between providers, payers and clearinghouses.

The next question has to do with the transport and the routing. Again, the
EDI architecture provided in the standards is an administrative method of
exchanging, which already has established security, routing, and privacy
elements that have already been included in established payer/provider
relationships.

Should we consider optional or situational enveloping? We do not recommend
situational or optional enveloping. Enveloping allows the linkage, the
authorization, the authentication, audit trails, traceability that is needed.
We recommend not making envelopes optional or situational.

In regard to the gaps and limitations, so far to date we don’t believe there
have been any gaps identified. The ASC X12 version cycle will keep up-to-date
with the needs that may arise in the industry. For example, we recently added
requests made by the esMD group. The HL7 Standards will evolve independently of
the X12 Standards.

X12 recommends the attachment rule not be limited to just claim attachments,
but allow other standards to be used for purposes such as authorizations,
referrals, post payment, and audits. We are also recommending a staggered
implementation timeframe to address the concern that a mandate which includes
attachments other than claims with the same implementation timeframe may impact
the implementation of all attachments. Of course, the standards must be aligned
with other attachment standards being used for Meaningful Use and exchanged
between providers.

What are some of the most important business and technical issues
surrounding attachments for providers, health plans, and vendors? Incorporation
into existing workflows. Any time you make changes to a standard or add
standards, providers, vendors, et cetera, have to incorporate this into their
workflow. Education will be a big must. There is a lack of a knowledge base, I
think. Of course, the implementation costs are always a concern.

That concludes my testimony. Thank you very much.

DR. SUAREZ: Thank you, Margaret. Thank you very much. Again, any questions?

DR. FITZMAURICE: Maybe just one. I noticed that there are some differences
between HL7 and X12. One may be more flexible. The other would be more rigid.
Rigidity can help reduce costs in many cases. Are HL7 and X12 trying to work
out these differences? Am I just perceiving something that may not be there?

MS. WEIKER: I am not sure what differences. HL7 develops the actual
attachment. X12 is not developing the actual attachment. They are basically two
separate things that come together.

MR. QUINN: I think it just reflects two organizations that have worked on
essentially different things, but at this point, have a common purpose of
Meaningful Use. X12 and their architecture pre-dates HL7. HL7 has — as long as
we have been active, since 1996, this has gone through several evolutions. If
the Department of Health and Human Services in say 1998 was prepared to go
forward with attachments, what would have been published in 1997 would be quite
a bit different than what would be published today.

MS. WEIKER: And we do have joint groups that meet. We do keep abreast of
what each other’s organization is doing. We have liaisons and that kind of
thing. I think it is more of a complement.

MS. KLOSS: Margaret, thank you so much for your enlightening comments. The
pilot you referred to, is that a recent pilot? Is it based on the configuration
of standards that we are hearing about now? Is this earlier?

MS. WEIKER: The pilot is earlier. This was like the first round of the
attachments that HL7 developed.

MS. KLOSS: So the conclusions from that aren’t particularly enlightening to
what the implementation challenges are?

MS. WEIKER: I think some of the conclusions are enlightening in regard to
there was considerable return on investment. I know WellPoint was one of the
people that piloted and they have considerable return on their investment. In
fact, there are entities that participated in the pilot and today continue with
exchanging attachments, et cetera, using them. Going forward, they would have
to change the attachment piece of it to meet the HL7 CDA model, but I think
there are some lessons learned that are still valuable.

Mary Lynn Bushman, who is actually in the back row back there, her
organization participated in those original pilots.

MS. KLOSS: Thank you. I know we will want to talk about implications of
implementation after.

MR. QUINN: I wanted to add just a tiny bit. When we did those pilots we were
using the then existing today’s technology. It is not that we didn’t use CDA.
We didn’t have Meaningful Use with all of the document types that they have
defined since then. By aligning attachments more with the Meaningful Use piece,
we have made, actually, the job a heck of a lot easier for the vendors and the
providers. I am not going to speak for the payers, but certainly for the
providers and their vendors.

DR. SUAREZ: Okay. Thank you. We are going to move on to Lynn from NCPDP.
While she is setting up, I wanted to acknowledge, also, written testimony that
we received from the American Dental Association and a few others that will be
also considered. Certainly, the applicability of attachments to the dental
transaction is a very critical one.

MS. GILBERTSON: Thank you. My name is Lynn Gilbertson from the National
Council for Prescription Drug Programs. The presentation that has been prepared
for you I am going to go through quite quickly with the intent that you can
read some of the slides and the pictures at your leisure.

The first slide is about NCPDP. We are an ANSI-accredited standards
development organization. I am not going to go into the detail, but we service
the pharmacy services sector industry in the e-prescribing environments.

The first topic I was asked to present about is the status of electronic
prior authorizations. This slide is just showing the impact of where some of
the paying points are in prior authorization that you can review at your
leisure. The part of the focus that we are going to give you some updates on is
what is in red in the very center, which is the prior authorization exchanges
that take place between the prescriber and the payer or the health plan.

Since 2005, there has been a lot of industry work on electronic prior
authorization, specifically in the pharmacy benefit, the drug environment.
NCPDP has facilitated an industry task group all of these years. They have gone
on hiatus once or twice. We did have industry participation in 2006 of an AHRQ
and CMS sponsored pilot on EPA. What has now transpired over the years in there
is a renewed vigor for the electronic prior authorization process as part of
the prescribing workflow in the prescriber benefit, sending information in the
prior authorization as part of the pharmacy benefit for the patient — so the
drug prior authorization.

What the industry facilitated task group has done is take the lessons
learned over the past pilot from years ago, the draft standard that was brought
forward after that original pilot was tested, and now has come together with a
standard structure that allows the exchange of the prior authorization
questions and the answer choices between the prescribers and the payers.

It also supports the ability to pull from the electronic health record if
the entities are able to support, for example, pulling LOINC information out of
the electronic health record using SNOMED codes if appropriate. These
transactions that have been brought forward also use the CDA attachment
environment.

The electronic prior auth supports both the solicited and an unsolicited
model very similar to what Margaret described where the prescriber doesn’t know
whether a PA will be required for this drug and doesn’t know what the criteria
might be versus a vendor who might have a relationship with a given payer or
health plan that has already set up what the criteria is for a particular drug,
for a particular PA, and can send in the answers in the first transaction
exchange.

This is all built on the NCPDP script transaction set, which is used in
electronic prescribing today. It uses, obviously, reuse of the elements and the
segments and the functions, as well as the reuse of attachments.

Over the next slides, I provide some detail about the transactions that have
come forward in the PA. They are being used today — the transactions that have
come forward obviously are not being piloted today as exactly because they have
just been enhanced, but there are pilots going on using the draft that was
recommended a couple of years ago by the expert panel that was put together as
part of looking at the pilots from the 2006 timeframe.

The transactions, very basically, are a PA Initiation Request and Response.
Is this drug covered? Does it need a PA? What is the information required to
satisfy a PA? And then there is the response between the prescriber and the
payer. Then the transaction of the PA Request and Response, which is the
ability for the prescriber system to then send the answers to the questions,
the attachments to the questions, whatever is needed to help fulfill the prior
authorization with a response coming back from the payer.

This particular drawing is too hard to see unless you are up close. This
shows the solicited and the unsolicited on a pictorial representation for those
who like pictures.

Other transactions that are included in this set besides the PA Initiation
Request and Response and the PA Request and Response are the ability to follow
through on an appeal process. If there is a requested appeal, the payer can
respond back whether they support electronic appeal process and what their
criteria for the appeal is or how to perform a manual. There is also, in every
exchange, the ability to cancel that a prior authorization is not needed
anymore. These are all real-time transactions between these two entities.

The update, as of now, is that the industry facilitated task group did bring
forward all of these transactions as part of the script standard in the
February NCPDP meeting that was approved. It will go to ballot in March and
April — all of these transactions that I have been explaining.

Best guesses for publication is we will adjudicate the comments that come
from the ballot in our May meeting. If there are no substantive comments, it
could be the script standard with the EPA transactions could be published as
soon as August. If there is a need for recirculation of a ballot because of
substantial comments, which is just fine, the estimated publication would then
be November.

The other topic is the other attachments that are used in the pharmacy
industry that you may or may not be aware of. We are kind of quietly on the
outskirts sometimes. The framework of the Script Standard has a peer called the
Specialized Standard, which is used for transactions that are not specifically
in e-prescribing.

Some of these transactions include query transactions, which are between
entities involved in the healthcare, such as the pharmacy and the prescriber.
If the pharmacy needs to follow up with the prescriber about allergies or
conditions or obtain a medical history, for example, they send a real-time
query transaction to the prescriber system asking for one of these pieces of
information.

The standard was built so that, at that time, it could support what we knew
of as the attachments that were in use, which is the CCR and the CDA. It is a
reuse of what is existing in the industry today wrapped around this query where
I am asking for a specific kind of information.

The other transactions that are included are medication therapy management,
referred to as MTM. One of the models that, for example, is a payer, asks
pharmacy or a provider to accept a patient and perform some type of medication
therapy management service. The request — we will request for this patient —
for this pharmacy this type of service, a targeted type of service that may
need to be applied for this patient. It uses standard terminologies, for
example, SNOMED codes, for these types of services.

It may include an attachment, once again, does the CDA, for if the payer has
information that they need to send to the pharmacy as follow up. It may not be
used in this case, but that is one of the business examples that were brought
forward. It could be in the MTM transactions, there is also the ability for the
pharmacy to follow up with the service documentation. What services did they
perform? What information does the payer need to know? That can come back in a
service documentation transaction with CDA as the attachment providing the
information of what was performed.

One of the things that is important about this is that billing for services
is outside this picture. The billing for the actual service takes place using
the NCPDP telecommunications standard if it is a pharmacy based bill or the X12
837 TR3 if it is the medical because that is already named in HIPAA.

The other activity that has been going on is a joint project between NCPDP
and HL7, which NCPDP has facilitated. This is based on a Medicare Part D
requirement that a patient should have a takeaway document after an annual
comprehensive medication review. There is a statutory requirement to create
this. What this join group has done was actually create an implementation guide
of the use of the Consolidated CDA for this particular purpose.

I have included some links there. You can look at the project summary if you
are interested. There is also some — a use case was brought forward to ONC on
the Blue Button Initiative from this task group as well.

Just some final thoughts from the pharmacy industry, I think from what we
have heard this morning, NCPDP is in agreement in how the attachments are
defined by our colleagues here. It must be clear to the industry, though, what
types of business functions are going to be done to exchange attachments.
Whether it is claim attachment, whether it is attachment, the terminology and
the definition has to be very clear for the industry, whether it is part of the
adjudication of a claim or bill, whether it is post adjudication of the claim.

We wanted to make sure you were aware that so far in the pharmacy industry,
there have been no new requests for attachment functions in the billing
functions. In the use of the telecommunication real-time transactions, there
hasn’t been any new cases brought forward for any kind of attachment in that
real-time transaction.

We wanted to make sure you were aware from our testimony that attachments
may stand alone as being shipped around, but they also must be allowed to be in
context-specific transactions, as we have shown with the electronic prior auth,
with the MTM, with the query, and those types of transactions. We need the
ability to put a context around it.

To echo what Margaret has mentioned, as well, about education, there is
still a lot that needs to be done in the industry with getting comfort level on
using attachments. It is growing. It just is the experience. You just have to
get in there and start using it. There are functions about sending attachments
around that the industry is still wrestling with. How do you update incorrect
information? How do you retract information? How do you send corrections? Just
those kind of administrative things that we kind of take for granted.

The other is the use of industry vocabularies. There are still more
experiences needed. More education is needed. Sometimes the volume of code
values in a particular vocabulary is very overwhelming, but I think we can help
the industry realize that in their environment, they are only going to be using
a subset based on their business needs anyway. The education of just starting
to get used to it, getting comfortable, and starting to consume this
information will be very helpful. Thank you.

DR. SUAREZ: Thank you so much, Lynn. I really appreciate the incredible
perspective from the pharmacy industry. I think one of the interesting things
that I heard through this presentation is the relationship, but, at the same
time, the distinction between the purpose and use of an attachment.

You clearly lay out some of the prior authorization transaction type
attachments that are exchange of information, which are very much
administrative type processes between a pharmacy and a payer. Then the next
sequence of examples, the query transaction, the medication therapy, those
clearly got into a lot more of the treatment of the patient and the exchange of
information between the pharmacy and the prescriber and the provider to
provider exchange, in terms of pharmacy being a provider and the physician
being also a provider.

Those types of applications, you know, draw this important convergence that
we have been talking about of the world of attachments applied to
administrative transactions and also then to clinical-related transactions.
Excellent job. Thank you.

We are going to go to — unless there are any other comments, we are going
to go to Gwen from CORE.

MS. COMBS-DYER: While Gwen is bringing up her slides, I wondered if I could
just add to a question that was asked a few minutes ago. Linda, I think it was
you that was asking Margaret about the pilot that they ran. Margaret was
talking about the pilot with Marilyn Bushman. That was between her organization
and CMS because they were a Medicare claims processing contractor.

I just wanted to let you know that we found that pilot very helpful. It
really helped to advance my thinking at CMS about how this electronic exchange
could really work. It sort of drove me to ONC where I began to learn about the
standards and interoperability framework and was really able to kick off the
whole concept of electronic submission of medical documentation, ESMD, which I
will be talking about with my slides.

I just wanted to make sure you knew the other end of that pilot was CMS. We
found it very helpful.

DR. SUAREZ: Thank you. I think we are ready.

Agenda Item: Current state of Attachment Operating
Rules

MS. LOHSE: Great. Thank you. Good morning. Thank you for inviting us to
testify. We are going to share the perspective from the operating rule author
and go through where we are in the status of identifying options for operating
rules. We are very excited about this. I think across the board there is a lot
of opportunity here. There are lots of good pieces that we can put it together
and make some progress.

With that said, I will go through some of the questions that you had posed.
We did put a lot of information in here. I am not going to go over all the
details. I do hope we respond to your questions. At the end, we are going to
actually summarize some of the options that had been identified for operating
rules, as well as hear the perspective about where the industry is adopting the
standards that we have heard about today.

For those of you that are new, just a little bit of background about CAQH
CORE. It was established in 2005, solely focused on drafting operating rules,
driving their adoption, tracking their progress, tracking their impact,
certifying voluntarily, building awareness, identifying early adopters. This is
an integrated model before the reform bill to support the standards.

One thing to note, we have had quite a lot of activity over the last few
months about the other parts of the model that aren’t developing the operating
rules. We put on over four education sessions per month, many of them in
collaborations with the SDOs. We have had a number of good ones with ANSI, X12,
with NACHA, the other standard setting bodies, and a number of partners have
also put out an update on the CARCs and the RARCs, which I am going to go over
in a minute, but it is in the second set of operating rules.

We have had a lot of entities that are voluntarily certified like Kaiser of
Colorado. BlueCross BlueShield of Nebraska just pledged — GE Centricity. A lot
of operators really showing they are doing the adoption.

What is the relationship to standards and operating rules? Obviously, this
is pretty critical as we look at attachments because it is both standards and
operating rules. Since the inception of CORE, CORE has always built upon and
supported the existing standards. It really is an integrated process between
the operating rules and standards.

It is an iterative process, too. We have already seen what some of the
current operating rules that you can have an operating rule support the future
version of the standard and then once the future version of the standard comes
out, remove those items for the operating rules. We are seeing an iterative
process where they really work off one another to push the industry forward.

The operating rules are always built on a number of criteria. I am laying
these out here. I am not going to go into detail of them, but we are focused on
administrative simplification and working in unison with the financial
transactions to move those transactions forward. It is vendor neutral. You
don’t repeat or contradict the standards.

You had asked a little bit about what the process was and the timeline for
the operating rules. This slide is just to highlight that. Every set of CORE
rules goes through a similar process. With the ACA mandated rules, it obviously
starts out when we had been recommended to be the authoring entity and then we
begin the other pieces.

One of the first steps is research, assessment, and analysis so we can have
references and available information for all of the participants around the
table, building out awareness for the industry and for those that are not
necessarily at the table and there are a lot of those, and then moving forward.
You will see the CORE participants in the coming months and the coming quarters
will be meeting, debating, and they will be seeking a lot of steps for public
input. We will be updating you with the goal to meet the ACA deadline
delivering a set of operating rules to CMS/OESS per the timeframe.

This is a significant step to really involve everyone. I think John already
noted and Margaret — we are all working together behind the scenes and
involved.

What is the research that we have done to date? Just as a highlight here,
again, gathering best practices, identifying out of scope items. Those things
have been done through a number of steps. One is participation in other
national initiatives like the Blue Button and the S&I initiatives,
dialoguing with the SDOs, outlining alignment with Meaningful Use, and also
large scale adoption programs like the esMD. We have been working with them
since their inception.

We have been conducting interviews to do a white paper. We have conducted
over 40 interviews to look at a host of different uses and also contacting a
lot of entities that typically would not be contacted. A public survey, we had
over 150 unique companies that registered for that and 80 that finished. Some
are in the process. We put it out for two months. Some people want some more
time. We are getting a lot of feedback from that public survey. We are also
analyzing codes that are in the second set of operating rules around
attachments and claims. We not have that data so why not take advantage of it?

So what is the definition? You had asked what the definition is of
attachments. I would say it is very much aligned with what you have heard from
the other testifiers today. People are looking for a broad definition of
attachments. This is especially true given the increasing audit request,
Meaningful Use, and health reform. It is a broad definition. I think if we had
asked years ago, it might have been a more specific definition. Now, we are
looking at a broader one.

For business needs, there is a host of them that we had found during the
research that I mentioned. They are listed on the top of this slide, really, in
order of what we heard the frequency was. There is no doubt a lot of these are
administrative, but some of them are clinical. You are going to see — you
asked what are the next ten years going to bring us? Probably an increase in
the size, the physical size of the transaction and the physical size of the
attachments along with the transaction as well as the frequency. That is going
to impact processing and cost. We are going to be seeing that as we are moving
forward.

I wanted to note when I talked about the analysis with the codes, the CARCs
and the RARCs, those are in the remittance advice that go along with the claim.
They communicate rejections, denials, and also pends. We aggregated some data
and there is over — as we did that aggregation, the CORE participants and the
public asked for 300 new codes to describe attachments related to claims. We do
this process three times a year. In one step, 300 new codes.

We did put an example of the codes on this slide. This is — the CORE roles
have business scenarios. One of the business scenarios is
missing/invalid/incomplete documentation, so the request for additional
documentation, which is almost an attachment. Three hundred new codes in one
request. These are just examples. There are hundreds more. Many of them, you
will see, relate back to clinical information. There is no doubt of that
linkage.

Now, I am going to go into some of the questions that you had asked
regarding the formats and what we are seeing with the formats. First of all,
U.S. Postal Service. It is a key piece. This is a migration path. U.S. Post
Service is still one of the formats. Second is electronic transmission of
paper. Using fax, e-mail, portals to send web, PDF, scanned documents like TIF
and other items.

I think you can see from the esMD Initiative, they actually have recognized
the same migration path. You will hear that from Melanie later. We have been
looking at what are the ROI within each of these steps. What amount of staff is
used at the hospitals? What is the cost? We have checked some information on
that. Clearly, the health plans, the providers, the vendors want to get to
auto-adjudication, but because of the lack of structured data and the exchange
that is not happening as much.

The third step in the migration path is the structured content and then,
really, data exchange that is interoperable. There is not many instances where
we saw that additional information collected for one purpose is used for
another. If you think of those CARCs and RARCs that we saw, if they could
access that other information, it might reduce a lot of the back and forth.
That is not happening very often because there is not structured data and the
data exchange is not happening as much.

There is a growing use of the C-CDA, HL7, and, no doubt, that is going to be
happening more, especially in the clinical arena. The SSA has used it. It
resulted in a full time really reduction by half of their cost. There is a lot
of benefit with the C-CDA. You are starting to see with the exchange of the
data because of the federal mandates around the operating rules, more use of
the CAQH CORE connectivity rule, which supports a whole host of industry
neutral standards like web services that we have been hearing about today.
There is some use of XML, but it is not very frequent yet. I think we already
heard that.

As we go on here, just to get to the last piece of this, what is currently
used? At a very basic level, we are in the early stage of adoption and
understanding. I think you have already heard that about education and some of
the other items that the implementation talked. Structured content needs —
jpeg basic imaging formats, those are being used. There is more sending of the
C-CDA. It can provide that linkage between admin and clinical. Now, with
Meaningful Use supporting it, we are going to be able to see that.

You had asked if there are other standards related to content. We had heard
from our interviews that a lot of the folks feel like if we improved what we
had already had, added to the claim — we are going to have ICD 10 coming out.
Some of the pieces of attachments relate to codes that now will come in ICD 10.
We also could connect things within the claim to improve the process. There are
places like Trace Numbers to use with what we have to improve the process
beyond the C-CDA piece for content.

On the infrastructure and communication, you asked a number of questions
about messaging, transport, enveloping, and security. I am not going to go into
great detail of that. It would probably take another 30 minutes, but there is
no one standard. Given the market maturity and where we are to meet the needs
of the current migration path, there is no one standard in this area that is
going to meet our needs.

We have provided some information here about what is being used, mentioning
LOINC is starting to be used a lot more, obviously, the C-CDA, some of the
pieces with the CORE pieces. Direct and CONNECT are getting more use. The CORE
Connectivity is supporting the features that are in the CONNECT. There is that
alignment. There is minimal use of the X12 transactions that you have been
hearing about today — growing, but minimal, and some thoughts about continuing
to improve those. Again, acknowledgements are not something that there was
consensus on. I think you have already heard that today.

With current uses, what are going to be the things that are recommended as
we are moving forward? The standards and the operating rules really need to
focus on a migration path that addresses both the move from electronically
sending paper — so that first step — to then the second step and the ultimate
goal of sending structured data in a very interoperable data exchange way.

We are going to need to do that in a migration path based on a number of
criteria. We consider things like what level of privacy and security do we need
to have based on the data? Given the growing size of attachments, what are
going to be the standards you need to exchange the data? Operating rules, no
doubt, can help drive that adoption path.

There is a recommendation I think you are hearing across the board for the
HL7 C-CDA, then optional use of the X21 standards and the supplement as we are
moving forward to get more experience. It might be useful to use things like
NPRM to continue to get feedback from the industry. Then, no doubt, the CORE
operating rules to date since its inception has looked at a whole range of
communication standards. Since they are industry neutral, that needs to
continue.

I am going to just talk a little bit about what some of the recommendations
could be for the operating rules moving forward. There are just two slides on
this. I am not going to go through the detail. This highlights — you asked,
what are the options? We are looking at step two of the migration path and the
ultimate step, step three, focusing on both of them as we are doing this first
set of operating rules and doing that again with the standards and the
operating rules.

The CORE participants, with a number of places for public input, will be the
ones that end up making the recommendations. These are preliminary options
identified through the research to date.

We need to address a basic standard for electronic exchange of paper.
Looking at an agreement about PDF or TIF or JPEG, there was a lot of demand for
that as we were out talking to people. Similarly, with other operating rules,
require that additional information request be transmitted electronically. We
have a very broad definition of electronic. We could take better advantage of
using that broad definition and then building on interdependencies and aligning
with the clinical pieces.

For the second piece, supporting the C-CDA and making sure that we are also
encouraging common data models and beginning stages of support for LOINC and
really working to do that and then a targeted set of these communication and
data exchanges, these options for transport, the CORE Connectivity, CONNECT,
and Direct.

As we wrap up here, I don’t want to go over, we are really focusing on a
lessons learned from what we have already done to date. We are making sure we
address things like specialty areas, property and casualty, dental, pharmacy,
aligning with what already exists and building on that and working in
milestones and then really harmonizing across and taking advantage of that
harmonization.

There needs to be an ongoing focus on that integrated model that I talked
about before so there is equal focus on education, outreach, tracking results
so then the maintenance and the improvement can move forward. Thank you very
much. Hopefully, this was useful.

DR. SUAREZ: Indeed. Thank you. Thank you very much for your testimony. Any
pressing questions? We are going to go to Melanie now for an overview of the
esMD Initiative.

Agenda Item: Medicare — esMDInitiative

MS. COMBS-DYER: Thank you very much for inviting me. I have brought along
Bob Dieterle, who is the esMD Initiative Coordinator for us. He is under
contract to CMS, working now for a signature consulting group. He is going to
be running our slides.

Thank you for the opportunity to testify today about electronic submission
of medical documentation or the esMD program, as well as our Electronic
Determination of Coverage or eDoC initiative at the Centers for Medicare and
Medicaid Services.

I am Melanie Combs-Dyer, the Deputy Director of the Provider Compliance
Group in the Office of Financial Management at CMS. My responsibilities include
overseeing the Medicare Recovery Audit Contractors — we sometimes call them
the RACs — as well as the medical review units of our Medicare Administrative
Contractors, usually called our MACs. Collectively, I will refer to all of
those contractors as Review Contractors.

It is important for you to recognize that I am from the part of CMS that
oversees all of these medical review and audit initiatives. I am not from the
part that writes the rules. You will be hearing later from Kari, who is
responsible for writing our rules.

Medicare and Medicaid issue billions of dollars in improper payments every
year, but most of those improper payments cannot be detected just by looking at
the claim. It takes a human being, usually a coding expert or a clinician to
compare a claim to the medical documentation that was written in the patient’s
medical record at the time of service.

The primary job of the review contractors that I oversee is to find and stop
those improper payments in the most cost efficient manner with the last amount
of provider burden. Each year, MACs send about a million requests for medical
documentation to providers like physicians, hospitals, and medical equipment
suppliers. RACs send over a million requests for medical records each year.

Before esMD existed, providers responded to those medical documentation
requests by mailing or by faxing paper medical records to the requesting review
contractor, but, starting 17 months ago, we started the esMD system, giving
providers a new mechanism to respond to those medical documentation requests.

Today, we are in Phase I of esMD. The review contractor still sends the
medical documentation request letter through the U.S. postal service. Outbound
is still paper. But we give the provider the opportunity to respond either by
mail, by fax, or by esMD. It is always paper going out. It can either be paper,
fax, or esMD coming back in to the review contractor.

Someday, Phase II of esMD will allow two way electronic exchange of
protected health information between the review contractors and the providers.
When we get to Phase II, you can see from the slide that providers will be able
to register to receive those outbound electronic medical documentation
requests. They will still respond to those documentation requests using Phase I
of esMD.

Let’s talk about the attachment standards for just a minute. One question
you ask is whether there are multiple definitions of attachments and, if so,
which one do I recommended? Yes. There are multiple definitions of attachments.
I used to call them claim attachments, but I don’t anymore. Now, I just call
them attachments. There are three reasons for this.

First is Prior Authorization. Just a few months ago, Medicare began a Prior
Authorization program in seven states for Power Mobility Devices, those
scooters that you sometimes see advertised on TV. In those seven states, the
requester submits progress notes, an order, and other relevant documentation to
the review contractor before the item is even delivered to the patient’s home
and before a claim is submitted.

Just last month, we opened up the esMD system to allow providers to submit
those Prior Authorization requests electronically to the review contractors.
Even though this medical documentation is not attached to a claim, in fact, a
claim hasn’t even been generated yet, I still consider those documents to be
attachments.

Second is pre-payment review. During a pre-payment review, a review
contractor stops the claim that has been submitted before it is paid and sends
a medical documentation request. When a provider sends the requested
documentation, whether it is by mail or by fax or by esMD, it isn’t attached to
the claim. The claim was already submitted. The medical documentation is being
sent days or weeks after the claim was submitted, yet, I still consider this
documentation to be an attachment.

Third is post payment review. During post payment review, a review
contractor identifies a claim that has already been paid by the MAC and sends a
medical documentation request to the provider. When the provider sends the
requested documentation, whether by mail, by fax, or by esMD, the documents
aren’t attached to the claim. In fact, the review contractor that is requesting
the documentation may be a RAC, a completely different company than the one to
which the provider sent the claim. Still, I consider that documentation to be
an attachment.

Therefore, the CMS esMD team recommends a regulatory definition of
attachment that is not based on what the medical documentation is being
attached to or to whom the medical documentation is being sent or even via what
mechanism the medical documentation is being sent. We further believe that the
definition should be broad enough to include structured data in a standard
exchange format like the C-CDA, unstructured data in PDF format that is
contained in a C-CDA envelope, and the metadata required to establish
authorship such as a digital signature.

You also ask what the priority business areas are for attachments and how
this is expected to change over the next five to ten years. My group’s priority
is to prevent improper payments from the Medicare trust fund through post
payment review, pre-payment review, and prior authorization. I predict that
over the next five to ten years, we will see a shift to less post payment
review and more pre-payment review and prior authorization.

At this time, I would like to turn things over to Bob Dieterle of Signature
Consulting Group, our esMD Initiative Coordinator.

MR. DIETERLE: Thank you very much. I am Bob Dieterle, esMD
Initiative Coordinator. My responsibilities include working with the Office of
the National Coordinator’s Standards and Interoperability Framework and the
stakeholder community of providers, payers, suppliers, HIT vendors, and
standards organizations to define use cases, information requirements, and
standards for the next generation of attachments and transactions that enable
them.

This slide summarizes our recommended standards regarding content, format,
envelopes, messaging standards, and transport. There is an error here and also
elsewhere in the presentation. ASC 277 should be ASC 275. I apologize for that.

To answer the question regarding the status of attachment standards, allow
me to briefly describe our joint effort with the ONC S&I Framework Program.
We have developed a specific use case that addresses a number of security and
operational technical issues related to the determination of coverage.

All documents are signed digitally by the authors or their agents as our
transactions to register for payer services receive electronic requests for
documentation and submit information required for determination of coverage as
part of prior authorization, pre-payment, or post payment reviews.

The eDoC workgroup focuses on providing structured standards for
documentation. Our first use case was for Power Mobility Devices, which are a
significant example of inappropriate payment. Three sub-workgroups will focus
on reusing the efforts of other S&I initiatives. The first sub-workgroup
will focus on structured and unstructured data required to rapidly and reliably
assess the need for these services and transmit it using the Consolidated CDA.
The other sub-workgroup efforts are described in the accompanying material.

This slide depicts the current payload, metadata, and envelopes by esMD
Phase I to transport PDFs over CONNECT or the CAQH Connectivity. This slide
shows a number of viable options to transmit the same PDF or it could be a
structured CDA payload using Direct. As you can see, we have a relatively
complex environment here that gets simplified through the use of implementation
guides.

With regard to recommended standards, the Electronic Determination of
Coverage workgroup is actively developing structured documentation requirements
for its initial use case. We encourage all interested parties to participate.
While we believe a significant part of the data should be in highly structured
format, a portion or, depending upon the provider, all of the data will be
unstructured and, therefore, must be supported in a CDA wrapped PDF format.

Metadata required to appropriately describe various artifacts necessary for
the exchange of attachments is required. While some of these elements may be
eventually incorporated in the Consolidated CDA, for the foreseeable future,
the industry will need to support metadata to describe digital signatures,
delegation of rights, actions taken on documents, relationships to other
information, such as a claim, routing and final destination for appropriate
delivery of the attachment, and intended use, such as for prior authorization
determination of coverage.

The esMD team recognizes that multiple envelope standards are currently
required to support the content format, digital signatures, and other metadata,
and work with the three transport standards, for which we have developed
implementation guides. For transport standards, we support CAQH CORE operating
rules for SOAP-based ASC X12, supported by most payer and provider
administrative systems. eHealthExchange is utilized by federal agencies, large
providers, and many of the health information exchanges. Finally, Direct is
required by Stage II EHR Certification.

We are recommending that the Committee consider adoption of the current esMD
Phase I standard for unstructured documentation using PDF format and the
structured data templates for the Consolidated-CDA that emerged from the
Electronic Determination of Coverage workgroup.

There are known limitations to the recommended attachment standards. The
gaps are primarily related to detailed structured content specifications, use
of specific clinical vocabularies, and, finally, proof of authorship. The esMD
Initiative is working to identify solutions to each of these limitations in the
Author of Record and eDoC Workgroups.

In our opinion, the same attachments are appropriate for determination of
coverage regardless of whether it is for prior authorization, pre-payment
review, or post payment audit. With appropriate harmonization, the attachment
standards can be used not only for coverage determination, but also for
provision of care, in particular, for transitions of care and longitudinal
coordination of care.

Finally, the Committee has requested comment on business and technical
issues and how to address them. In the esMD initiative, we have identified a
number of process and technical challenges. Specifically, we have identified
issues related to the long-term validation of digital signatures, delegation of
rights artifacts, documentation modification and addenda, structured
documentation, standards for orders and results, as well as standardization of
clinical data elements and their associated clinical vocabularies.

We are planning to test proposed solutions to the author of record issues
and the emerging solutions to the structured data issues as part of the pilots
of the Electronic Determination of Coverage for Power Mobility Devices. At this
time, I would like to turn the testimony back over to Melanie.

MS. COMBS-DYER: The committee asks about the current state of the industry.
I would like to tell you about the current state of the esMD system.

In fiscal year 2012, 1,778 providers sent over 85,000 medical records in PDF
format through 16 health information handlers, or HIHs, to 21 CMS review
contractors. That is 85,000 medical records in a year. In the first four months
of fiscal year 2013, providers have sent over 90,000 medical records. You can
see that we are seeing exponential growth in the provider adoption of the esMD
system.

The Committee asks if there are any problems with the current state. There
are. First, although the esMD system is well liked by facilities and other
large providers, esMD remains an expensive option for small providers. Second,
although, the esMD system helps to reduce the print/mail costs of both
providers and review contractors, PDF formats must be reviewed by humans
at the review contractors. We look forward to the structured documents that may
emerge from our eDoC initiative as they may allow for more automated review.

Finally, the current esMD system does nothing to help a provider send a
referral or an order to another provider. You heard from the NCPDP folks
earlier about how things work so well in the drug area. It does not work so
well in DME or physical therapy or other places where a physician needs to get
an order to somebody across town.

Again, I remain hopeful that the eDoC Initiative will result in pilots that
promote electronic exchange between providers that meet both the information
requirements for patient care as well as the information requirements for our
determination of coverage.

In the interest of time, let me just say that the final two slides show some
of the costs and benefits that we can expect to see in the future. In closing,
thank you for inviting Bob and me to testify before you today. We really
believe that the esMD system and the eDoC initiative hold tremendous promise. I
hope that the Committee will consider the recommendations of the CMS esMD team.
We welcome your feedback and suggestions. We are happy to take your questions
at this time.

DR. SUAREZ: Thank you, Melanie and Bob for the testimony. We are going to go
to the last testifier, Kari, from OESS, and then we will open up for questions
from the Committee.

Agenda Item: Regulation Development

MS. GAARE: Good morning. My name is Kari Gaare. I work in the Office of
eHealth Standards and Services. Thank you for the opportunity to speak before
the Committee today.

As you have heard so far this morning, this is an exciting and dynamic time
as health information technology is transforming the delivery of healthcare.
The attachment regulation is unique in that it is one of the first steps
towards combining and merging the clinical and administrative sides of
healthcare through standards. The regulation provides the opportunity to build
on existing infrastructure in both the clinical and administrative spheres
while allowing for future innovation.

The end goal for the attachments is the seamless exchange of machine
readable clinical information among providers and payers to support the payment
of healthcare services. The reality today, though, is that it is primarily a
manual paper process. Obviously, there is a significant gap between the end
goal and where we are today. It is clearly not realistic or feasible that
industry could immediately jump from a largely manual paper process to the
electronic exchange of machine readable clinical information.

Over time, we certainly will reach our end goal, especially given all of the
health information technology initiatives. The key is how do we address the gap
in a way that does not disrupt the system and that instead ensures continual
good functioning and smooth transitions. Some thoughts for consideration to
help in the transition — first, we can ensure consistency with upcoming
initiatives like Meaningful Use Stage III so that the standards and the
versions of the standards adopted are consistent.

Second, we can focus on leveraging existing infrastructure so we are
creating enterprise solutions. Some examples of existing infrastructure include
the Stage II Meaningful Use EHR requirements that support CDA for the standard
format of the clinical information and Direct for the transport, Direct being
the low-cost e-mail based secure exchange, which industry is currently learning
how to integrate into the exchange of information for administrative use.

The NHIN Exchange with CONNECT, another transport standards, is currently
the standard for government agencies’ secure messaging. It is extending to the
commercial sector. The administrative transactions are also well established.
We have accumulated many lessons learned, for instance, how to create, deploy,
and support high volume standard transactions in understanding business rule
requirements.

We need to ensure that as we move forward to new technologies, we do not
forget these lessons. esMD has established standards for electronic exchange of
documentation, authentication of transactions, and authorship of documents.

Third, we can allow for innovation. For example, we might ask what will be
in use in 2016 that isn’t now? Fourth, we can use an incremental approach to
standardization. As they say, you must crawl before you can run. It would be
difficult to make such a large change overnight.

Finally, we want to apply lessons learned from pilot projects. As Melanie
and Bob just spoke about, the esMD and the eDoC initiatives provide a very
unique opportunity to operationalize standards and processes so we can learn
what works and what doesn’t prior to larger adoption.

There are many different pieces to the puzzle to achieve our goal that must
be taken into consideration and were touched on in the previous slide. We are
looking forward to the recommendations from this committee to help us put the
puzzle pieces together. The components of the attachment standard need to be
addressed to achieve the clinical and administrative goals.

First, we must consider the definition. Could this be broadened to ensure
that there is real standardization in the exchange of clinical information
across all transactions? Second, we might focus on the format for the clinical
information. Finally, there are the envelope, the transport, and the business
rules around the exchange.

This is a very transformative time in the standardization of health
information technology. We have the opportunity to bring together the clinical
and the administrative standards. As we move forward with this regulation, we
are really looking forward to the Committee’s recommendations on ways to,
first, close the gap to achieve seamless exchange of machine readable clinical
information. Second, we want to ensure coordination with existing and future
initiatives. Finally, we want to define an incremental approach for adoption.

With that, I want to thank you for the opportunity to speak today. I will
open it up for questions.

Agenda Item: Questions from Subcommittee

DR. SUAREZ: Great. Thank you very much. That is a great segue, really, to
opening up for questions from the Subcommittee and member of the Committee.
Before we start, I really want to thank everyone for their testimonies. This
has been just an incredible display of the progress and evolution that this
topic has had over the last four, five, six years since the regulations were
originally published. It is a wonderful overview. Thank you for your feedback
in terms of recommendations.

I want to acknowledge the arrival of our Chair of the National Committee, if
you want to introduce yourself, Larry.

DR. GREEN: I want to get in line for questions. I am Larry Green from the
University of Colorado. I have actually been hiding in the back corner. I have
been here for almost the whole thing. I am not a member of the Subcommittee,
but I chair the full Committee. I want to add my thanks to yours, Walter. These
folks really prepared. These were really good. Thank you very much for drowning
us in another fire hydrant.

DR. SUAREZ: All right. Let’s open it up for questions from the Committee and
Subcommittee members. If you could lift your cards, we will start from that
end.

DR. CHANDERRAJ: I will start my question with Gwen. You said there were no
particular, at this time, standard approach — standards developed for claims
attachment and other things, but we heard reports from HL7 and Margaret from
X12 saying that there are already. Can you try to bridge that gap?

MS. LOHSE: Absolutely. Hopefully, this will help explain the comments. There
are two ways to look at the standards needed for attachments: what relates to
the content — so that would be, for instance, the HL7 C-CDA, and then also
what you need to exchange all the attachments, especially for administrative
attachments, given the point to point exchanges they go through through the
health plans, through multiple potential vendors, and maybe now HIEs back to
the provider and through that. So there are then the communication standards.

For the communication standards, what we have seen, based on our research to
date, is there should not be one communication standard picked, but it should
be a list of options, for instance, the CAQH CORE Connectivity Rule supports
SOAP and web services’ set of standards, which also aligns with CONNECT. There
is Direct. Then there are a number of proprietary approaches that, I think,
Kari probably highlighted that if we stopped that immediately, we have to
consider how it is going to impact day to day business.

Hopefully, that answers your question. I think with the communication
standards, there is no one way, though it is going to meet our business needs
given where we are in the migration path. Does that clarify?

DR. CHANDERRAJ: Yes. I just wanted to have their responses to your
statement.

MS. WEIKER: I think what Gwen is referring to is she is talking about the
transmission because that is different. What transmission protocol, you might
want to say, is used to send a CDA, to send an X12, to even send an NCPDP
transaction? There are the transmission protocols, which are SOAP, web
services, HTTPS, ITS, TDL, on and on. There are providers that do continue to
use those. I think what Gwen was referring to was the transmission, not so much
of the data content that is contained within the transmission.

MS. LOHSE: I am going to go down to a slide that was in our appendix that
might help with this. The payload in the middle, we heard HL7 CCD Plus is the
way the industry is going to connect clinical and admin. I think we also heard
from Melanie and also from the research that CAQH CORE has done that there are
a number of things like PDFs that fit into that.

Then the outer rims are how is that passed among all of the different hubs?
That is the area where there needs to be flexibility given where the market is
today, and also given that the size of these attachments is going to
significantly change, the technology is going to change. We have to take into
consideration cost. If the size of these change and the processing needs of the
health plans, the vendors, and the providers, we can’t just present something
that might cost too much to send.

That is that outside rim where there needs to be flexibility. Then a really
specific, very structured recommendation about what the content standards are
going to be. I hope that helped.

DR. CHANDERRAJ: I have question for Melanie and Bob. The
esMD — since we are developing a standard for all of the attachments and
communications, do you see a need for an expensive software that physicians
need to acquire to communicate with CMS?

MS. COMBS-DYER: I will start and then I will let Bob help me out with the
answer. No. We don’t. However, providers do need to either have a gateway,
which is unrealistic for most providers, although, we do expect some large
facilities to build their own exchange gateway, but, more commonly, a provider
needs to find a health information handler that has an exchange gateway, much
the way they look for a claim clearinghouse today to submit their claims.

They have to find a CMS Certified health information handler. Once they do,
then that health information handler helps them figure out how to move the
information. Some of them — some HIHs have a web portal that the provider goes
to. They fill out some metadata and attach, attach, attach, and submit. That
information then moves securely through the esMD system to my review
contractors.

Other health information handlers physically go onsite to the providers’
shop and scan their paper records into the right formats and put the right
wrappers around them and send them through the esMD system. Different health
information handlers have helped create different solutions for providers. Do
you want to add to that?

MR. DIETERLE: We recognize the problem that we are currently experiencing
and that is the CONNECT software is both sophisticated and requires certain
experience to implement and support. In the process of looking at the future of
what we need to do within CMS regarding receipt of attachments, we are
exploring and will explore over the next year to expanding this from not just
supporting CONNECT, but also supporting ASC X12 or CAQH CORE Operating Rules
and incorporating, starting this year with a pilot, support for Direct.

What we are doing is recognizing the fact that the industry does have
specific standards either mandated by law or Meaningful Use or by convention
that wind up with a particular either content based or content neutral
transport that is optimal for particular environments. We start to look at
attachments, we walk across from the administrative systems into the clinical
system.

The clinical system, traditionally, has not supported X12. What they have
supported is some form of SOAP-based transaction. CONNECT, for the larger
providers, does make sense and many of them are implementing it. For the
smaller providers, Direct, because it is now part of the Stage II certification
requirements for EHRs. We are going to see more and more support for that from
the EHRs that are playing broadly in the field. It is our goal to take
advantage of all of this.

DR. SUAREZ: I am going to go to Larry and then we will come back to Linda.

DR. GREEN: I have three very specific questions. I will go fast. My first
one is probably for some combination of Bob, Gwen, and Dan. There are a lot of
players in this space. Can you hand us a prioritized list of the top three big
conflicts between the players around establishment of these standards? Where
does trouble lie?

MS. LOHSE: I will start with one thought. What is the migration path? We
talked a lot about what the migration path is. I think — it is not just the
discussion here. It is more importantly discussion out in the industry about
the people who have to actually adopt these — so the health plans that are
both public health plans, the Medicaids, and also all of the commercials
because the regulation applies to them, all the HIPAA covered entities.

The big debate, I think, is how far do we go within a federal regulation to
adopt some of the standards and, therefore, which of the operating rules
support the standards? That, I think, is the biggest thing. People have
different opinions about that. We are going to really need to work to make sure
that we hear the opinions of the people around this table, but, as importantly,
and, I think, even more importantly, we hear the opinions of those that aren’t
at this table that need to adopt and what is feasible for them. That would be
one of my number one things.

MR. VREEMAN: So I can speak a little bit to the vocabulary standards base. I
think the biggest competitor is local codes. That is, the momentum — the
entropy that exists in the world of getting from what we have today, lots of
independent ways of identifying this, to something else is the biggest barrier.

You have heard comments about — there is still some discussion or confusion
around what vocabulary for what purpose? I think, as I tried to indicate,
LOINC’s view of the world carves out a particular niche in that. It is not the
only vocabulary standard needed for all health information. It is for test
measurements and observations, document titles and so forth.

Other standards are needed for other kinds of information, such as
communicating allergies for drugs, for problems in a problem list. That kind of
information is important, but it is not LOINC’s focus.

There is also probably a tension between vocabulary standards for
identifying clinical content for use in EHRs, for decision rules, and at the
level of clinical detail needed, and billing codes that exist. In some
purposes, some services may be attached a billing code, such as a CBT code or
another code that has a relationship to the clinical content, but is not the
same as what exists in the EHR for a particular service.

DR. SUAREZ: Anyone else?

MR. DIETERLE: Let me respond just a little bit differently here. We have
recognized from the beginning that we have conflict in the industry in trying
to look how we take what is currently in use and move the ball forward. Move
the ball forward in the case of CMS meaning go from post payment audit and some
portion of pre-payment review to prior authorization so that we can start to
influence the decisions that are made by providers based on what they know will
or will not be covered. Not make it guessing game, but give them the
information right up front.

As we start to do this, we start to see the merging of what was normally
considered administrative information and what is clinical information. We have
to start thinking in terms of how we bring these things together so that one
set of documentation serves both purposes. One set of structured information
serves both purposes.

Part of what we are doing with the S&I Framework is to use an open
community where everyone is invited to participate and bring to the table their
experience and their vision for the future and create a set of use cases that
describe the problem, harmonize it against existing standards, look for the
gaps that exists, and work with the standards organizations to go and fill
those gaps.

Truly, there are gaps. There are gaps related to province of information.
How do we verify who actually was the author of a particular document or a
piece of data? We built the Author of Record Workgroup to do exactly that. We
are at a point where we have completed all of the work for digital signatures
on document bundles. We are working on digital signatures on individual
documents. Next, we will work on digital signatures on individual contributions
so that they can be used both for clinical purposes and administrative
purposes.

We have the technical issues related to transport. We just can’t pick one.
We do realize that we have the three different paths. We have the
administrative investment already in X12 and the CAQH CORE Operating Rules. We
have the investment the federal agencies have made in CONNECT or Exchange. We
have the emerging investment that is being made by all of the HR vendors in
Direct. All of them have use, some based on volume or enterprise level support,
others just for the fact that they connect to various symptoms, whether it is
EHRs or the administrative side of the house.

Finally, we have the content standards. While we have seen tremendous
progress with HL7 and the Consolidated CDA, we still have things that have to
be defined better. We need more clinical elements for specific purposes. We
need to be very specific about what clinical vocabularies are used to describe
them so that we can reliably use those to go and process, on the administrative
side, the request for coverage for particular services.

DR. GREEN: Bob just answered my second question. You will be glad to hear
that. I was seeking reassurance that actions toward achieving what I heard so
subtlety from Melanie, which was find and stop improper Medicare payments, that
we are also heading down — I am looking for reassurance that we are heading
down a pathway that will support the full NCVHS Committee’s charge and
interest, which is we would like to measure and improve health and healthcare,
the health of populations, and the health care that individuals get.

I am seeking reassurance that what we are hearing here today that is really
designed to manage the money is also going to be competent and capable of
managing the care. You spoke right to it. Thank you very much.

My third question is — Walter, you are going to have to help me deal with
— is I want someone to tell me what you need from NCVHS.

DR. SUAREZ: Is that a question for me?

DR. GREEN: No. We need to hear from these folks what NCVHS can do to help.

DR. SUAREZ: Sure. Part of the questions, actually, that we asked them was —
we need to come out of this hearing with a clear sense of issues of
recommendations and observations, certainly, around those issues that actually,
Kari, at the very end, mentioned that CMS is going to look for and HHS.

DR. GREEN: I just want to give them an opportunity to prioritize what they
would like to get out of this.

DR. SUAREZ: Sure. That is a great point. Anybody and everyone, if you would
like to respond to that, what do you expect or hope that you will see coming
out from NCVHS? I know we asked you that. You provide us with recommendations.
We appreciate that.

MS. GILBERTSON: This is Lynn. I will stick on the pharmacy side. The
recognition that the attachments can be part of other context-specific
transactions, the support of the electronic prior authorization transactions,
which should be coming forward, and I think those are the two main asks.

MR. QUINN: I work in an environment where, you know, my meetings have 500
people and 37 different countries. The U.S. is one country, but I have to admit
that I would be somewhat less than honest if I wouldn’t say over the last
several years that ONC has carried the largest bullhorn in the room.

Somebody had a slide up that talked about, essentially, the S&I
Framework process. You realize that there is a selection of standards. There is
identification of gaps. Then there is this issue of harmonization and closing
the gaps — harmonization between other standards, which is what we are talking
about here, and then this closing of the requirements gaps.

From my perspective, the most frustrating thing of all is to hear that we
need all of these things and then nobody show up — you don’t have to show up
in person. I even mean showing up virtually — to a ballot of a bunch of things
that ONC has put on the table of things they want added. Is that complete? It
is complete from ONC’s perspective, but what else? ONC has one voice in the
ballot process, but so does everybody else. The ballots take place and what, to
me, is the most frustrating thing would be for me to get a phone call from one
of you later one saying, hey, what is the matter? You guys didn’t do this.

With the public process, we had meetings. We had conference calls. The stuff
is out on the web. You can participate. If we weren’t doing something that you
knew we weren’t doing and didn’t tell us, then, excuse me, this is not a game.
That is probably issue number one.

Second, what has become more and more popular in the standards environment
— this doesn’t mean I am talking about for those of us that create, generally,
content standards like HL7, is that more and more, a lot of this in
collaboration with HIE, the implementation guides have become balloted. We
have, now, specific environments for the implementation guides.

People say to me what is the difference between an implementation guide and
a standard? A standard is basically a banquet table of things you can select
and are encouraged to do so. An implementation guide is something I can give a
programmer and get an exact byte for byte representation on a wire of exactly
what it is we all agree our computer systems will be able to process.

There is — we tend to refer to this as the wire format. What goes over the
wire, whether it is any one of the things we have talked about — you are
right. HL7 doesn’t, quote, unquote, really care. In the world of CDA, the more
flexible and sophisticated you can get in the wire, the more you will be able
to see the connections of the schema definitions coming across. XML, as a
future direction, are certainly things that are more concurrent with the other
level of sophistication of electronic interchange that takes place within
commerce in general in this country or around this planet and less and less
doing it like we used to do 30 years ago because we got it working 30 years
ago. I realize everybody has their push and their shove of what is important
and what is not important.

I think that when ONC issues Meaningful Use and implementation guides, the
combined — and, actually, to this case here, when we are talking about
attachments, when you issue the final rules on this topic, it is important that
you actually cover the breadth of everything. What you are uncomfortable about
is, gee, content standard everybody says use HL7 C-CDA. Okay. That is good.
Then everybody gets kind of fuzzy when we start talking about the wire. We are
all getting fuzzy about, well, we can do this and we can do this and we can do
this.

You have to decide — it is very important that when you, in effect, put
down the parameters for that implementation guide, that it be pretty darn
bullet proof so we don’t end up with a bunch of different implementers going
off in different directions and when they try to make it all work together —
guess what? — it doesn’t work. It doesn’t even begin to work because the wire
formats don’t match. Those are my pieces of advice.

MS. WEIKER: From an X12 perspective, we would recommend that you not limit
the definition of attachment to just a claim, that it be broad like the
definition that has been given earlier. We also recommend that you adopt
version 6020 of the 275 for both the claim as well as the health care services
review, which is the prior auth and referral, as well as the 277 for the claim
request for additional information. I also would ask the Committee to consider
adopting the TA1 in the 999 acknowledgement for the first level of
acknowledgements for the interchange as well.

DR. SUAREZ: Just a quick clarification, Margaret. When you say the first
level of acknowledgement, just for the members here, would you expand a little
bit on that?

MS. WEIKER: Typically, when an X12 transaction is sent, there is a first
level of validation of that. The first level would be in the actual
interchange. Is the sender, the receiver — that type of thing — valid? If
not, then you get back a TA1.

The 999 transaction validates syntax. Is it structurally correct? Is the
transaction structurally correct? As well as, then it can be applied against an
implementation guide or a TA3. The rules in that guide can also be applied. If
there is something that was not used in the implementation guide, but was sent,
or if there was something required that was missing, then you would use the 999
to say you are missing this data element or you sent us more than you should of
or something. That is the 999.

It doesn’t get into the application layer to validate that the attachment is
what we asked for. It is just at the high level to say, yes, this transaction
passes both syntax and semantics.

MS. GAARE: I was only going to say from a CMS OESS perspective, we actually
have to adopt specific versions of these different pieces of the puzzle. We
have, obviously, the clinical information. We have the envelope, the transport,
and then we have the business rules around the exchange. What we really look
for from the Committee is really recommendations around those different pieces
and how to start to put them together in a way that is going to work for
industry.

DR. SUAREZ: Thanks for making our job easier. Gwen, I think you wanted to
respond, too. Before you do, I want to give a quick note for people. I know we
are behind schedule by about 15 minutes. We are going to allow another 15
minutes of Q&A. That will push our agenda about 30 minutes down — just for
everyone to be aware of.

MS. LOHSE: I want to echo what Kari said. There are obviously a number of
standards in versions that need to serve as a baseline for making the
administrative simplification — Larry had pointed out, obviously, the impact
on quality and making the patient case easier on the physicians that are
involved in this process.

Allowing for that recognition of what those baseline standards are, but
thinking about what is the regulatory options to assume this is going to have
to be an ongoing maintenance process. I don’t think we want to get involved in
another place where we try to pick all the standards and then we don’t have an
update over a long period of time.

That is one of the things that we are really focused on with the operating
rules. We want to work with those around the table to figure out what are the
baseline standards in the versions? How will those need to be updated as we
learn which business areas are going to drive adoption? Is it going to be
audits? If we have a broad definition, will it be audits? Will it be prior
auth? Every two to three years, we actually have the flexibility to continue to
expand.

If this is locked down to a place we can’t do that, we either start with way
too much without the knowledge to drive it or we start with too little without
making the changes. It is that flexibility and adaptability that is so
essential. This is not just one regulation coming out at one time. This is an
ongoing piece. I hope NCVHS will support that.

DR. SUAREZ: Thank you. Thank you for that. We are going to go to Linda and
Ob, Michael, and then Jim.

MS. KLOSS: Thank you. Thank you all. I want to kind of go back up to a
little higher level, here, a little more strategic. You have all said that we
— it is time to move from the concept of claims attachment to a broader
concept of attachment. Then you recommended that we think broadly about this
and, certainly, bridge clinical, administrative, and think about care
management, care transition, care coordination, post payment review.

My anxiety is that more of those really important use cases that get piled
onto this, the less we may be able to be precise, specific, practical, and
pragmatic. I guess I would just like your thoughts about how do you kind of
roadmap those use cases in a logical way. That just all seems too big to me. I
don’t know if that makes sense. How do we get from — we jettison the word
claims, but to really think about this as supporting care management and care
transition, just wow.

MS. COMBS-DYER: This is Melanie. I will at least start the answer. Others
can join in. What we have decided to do in the eDoC initiative is to start with
trying to identify the specific data elements that need to be documented in a
progress note or in an order to support the coverage of a Power Mobility
Device. Now, we have put out all kinds of educational articles and checklists
that physicians can hang on the wall and help remind them what to document in
the progress note or in the order, but we now have an opportunity with all the
EHRs that providers are beginning to adopt to take those lists of data elements
and take them down off the wall and build them into the EHR.

Through the eDoC Initiative, we will identify those specific data elements,
starting with the policy, starting with what is it that needs to be documented
— How far can the patient walk unassisted? How far can the patient walk with
assistance? — all of those little data elements and build them into what are
the right vocabularies to use for this? What are the right words to use to
describe the question and the answer?

Once we lay that all out, we believe that the industry will pick up on that
and build that into the EHR. Whether it is in a template sort of question and
answer for the provider or little pop up boxes that come up on the screen or
lord knows where we are going to end up in mobile health, but once you identify
the data elements that are needed for coverage and patient care that can be
built into the actual EHR. Did you want to add to that, Bob?

MR. DIETERLE: I think the complexity is in recognizing that we are moving
two parts of the industry forward at the same time. We are moving the clinical
care side forward by structuring more and more of the information using
clinical vocabulary, using standard data elements, capturing the information,
the structured information, rather than just dictating reports.

We are also trying to use the same information on the administrative side to
make decisions related to coverage. I don’t think these are incompatible moves.
I think it is important, as long as we adopt the same standard, that we
recognize that we can start to create, for these high priority areas,
implementation guides that point to what is important, both clinically and
administratively since we are going to try to put it back through the same core
structures anyway.

I do not see this as taking on too much. I think if we do not take it on, we
run the risk of creating an administrative requirement that is not supported by
the clinical activity and that would be the worst of all cases.

MS. COMBS-DYER: I will just add one more piece. When we were first talking
about this we knew that we wanted Power Mobility Devices to be our first use
case, but we very intentionally did not call this workgroup the Power Mobility
Device Progress Note Workgroup. We are trying to put together a framework that
will help us to pull the right people to the table to identify the data
elements first for PMD, but I am sure there will be a second use case and a
third use case and a fourth use case. Hopefully, this framework that we design
will be flexible enough to handle any kind of clinical care coverage that we
decide we would like to have these data element standards for.

MS. GAARE: I would just add I think it is also how do you approach the
adoption as well? Is it that incremental approach to start to get everybody off
of paper? I think there is a lot of leeway, too, in the way that you are
approaching adoption. I think Gwen mentioned that a lot, in terms of the
operating rules. Maybe start with one use case and build from there.

MS. LOHSE: I would hope the point being going from paper to electronic, we
have to address that in this first set of regulations. The second — that
ultimate stage we want to get to with the structured data interoperability,
then we need to let the industry, as they debated over the next 12 months, to
say what are the major use cases?

If they have the flexibility to pick audits and prior auth and that is going
to drive the audits because of adoption initiatives that are outside of admin
and prior auth because of the needs in the market, then those two get that
moving. The industry needs to have that type of flexibility to say what will
drive. Having recommendations from you about the underlying standards, it is
essential to the larger vision.

DR. SUAREZ: Anyone else?

MR. MCKINLEY: From a development standpoint, through my affiliation with HL7
and the Workgroup that I am participating in, it seems like we may have some
duplicative efforts going on in trying to identify the data elements that esMD
is doing. At the standards organization that I support, as I mentioned, we had
eight structured content pieces that were there. Previously, you asked, what
could NCVHS do for us? One of the things you could do is to help us bring
people to the table in the standards organization so that we can leverage all
of the standards tools at HL7 to build the best standard for that.

I guess what I am suggesting is we might — in implementing this, we might
choose to arrive at a more streamlined path if we can, to some extent, where it
is going to cover the entire industry’s needs. We can certainly work with the
efforts that are being done through the esMD project to find the best mix for
that and how that best fits into their needs and the needs of HL7.

DR. SUAREZ: If there are no more responses, Ob?

MR. SOONTHORNSIMA: Linda asked an excellent question. She took my question
so what I am going to do is follow up with a complementary question. What I
heard from Bob and others is that, you know, if we are going to do this, let’s
make sure that we have both administrative and clinical value in getting the
data. That is priority. What Gwen said — what I heard is let’s really
prioritize based on some use cases that the industry feels is going to be most
critical. Marry those two together.

Now, going back to Bob’s point, too, we need to move this ball forward. I
look at all of the balls that we have to juggle today. What would be your
advice, in terms of over the next 12-18 months, because we will be in the
middle of — actually, post implementation of the marketplace, for example, and
there will be lots of data exchanges going on at that point? What do you see
over the next 12-18 months in terms of the number of use cases and those key
obstacles — more importantly, obstacles?

What will different stakeholders have to overcome? Let’s assume we have the
right use cases. Let’s assume that we have the right clinical and
administrative context. What will be those hurdles that the industry has to
overcome in order to implement? Does that make sense?

MS. LOHSE: One I can immediately think of is education. You all had a
hearing I think back about six or seven months ago about the learning network.
I am not talking about the physical network. I am talking about a learning
network within the clinical world, for instance, High Tech did allow for
funding for a number of education sessions, also, obviously, free sessions from
the government.

Education is going to be critical. A lot of these are very new requirements
for those that need to adopt them, whether it is the providers, the health
plans, or those that support them. Education will be a piece. There is not
enough of that right now. It will be an obstacle unless we all address it
together.

A second thing is we all seem to be coalescing around a migration path —
around that concept. The only way a migration path is going to be able to work
is if people commit to tracking and really saying that certain volumes are
driving my attachments. Comparing apples to oranges doesn’t work when you are
tracking because the data is no good. How do we get the industry into a process
that they are tracking? We are dealing with that right now with the CARC and
the RARC codes. It is going to be a really big lift, but it will need to happen
and need to feed into here, as well as other codes that are essential that we
heard about today.

I would say education will be a big challenge. Tracking will be a big
challenge. Those are two of the immediate. I have others, but I want the
opportunity for others to speak.

MR. DIETERLE: Let me try to focus on what we have decided to do. It has many
of the elements of the answer to your question in it. Working with the S&I
effort, we are trying to create a reproducible process where we can take these
specific use cases, for example, Power Mobility Device, and put it within a
framework that addresses what are the clinical data elements that need to be
documented? What are the vocabularies that have to be used to document? What
things can’t be documented?

In addition to that, we are trying to use these other emerging initiatives
within S&I, such as structured data capture, which I assume Dr. Fridsma
will talk about later, and healthy decision support, clinical decision support
to go an allow us to create something that can be accessed remotely by an EHR
when the provider is in the process of documenting a patient’s condition where
it will have implications not just clinically, but administratively. We can
start getting out of this process where we create something on paper. We give
it to the HIT industry. Somewhere over the next five to seven years, they
incorporate it into their templates. Then we do it all over again.

What we are trying to do, if you will, is move to a real-time process where
once we decide what needs to be done clinically and its administrative
implications, we can implement it in a way that all certified EHRs can have it
available to them tomorrow. This is a vision for a couple of years down the
road, but the work that we are doing this year and next year will give us the
technical foundation for that and allow us to start to conduct pilots to see
if, indeed, this will work because we are moving the ball very far forward. On
the other hand, it is one of those things that we need to move.

We have a problem right now in trying to get these guides and get these
standards that were created into the industry broadly. The timeframe for it is
so extended that we see these unnatural approaches, either highly constrained
guides and no movement, for a period of time or open ended environments where
we have many competing standards.

DR. SUAREZ: Thank you. We really need to move on, I think. We are going to
have two last very quick questions.

DR. FITZMAURICE: First of all, let me say that I am very pleased at the
cogent testimony of all testifiers and the collaboration among the SDOs, CMS,
and others, who are improving our chances of having an interoperability of much
clinical and claims data in my lifetime. You have really stepped up. I have
seen an awful lot happen in the past ten years. For these ten years, we have
been in an early stage of adoption of attachment standards. Early stage for ten
years? I guess so.

I have a couple of specific questions. I will say them and then stop. The
first is is HL7’s vocabulary consistent, identical, or mappable to X12
vocabulary choices for attachments and claims data elements? I have heard that
there is FHIR and there is CIMI. These are two initiatives. Will they be used
in HL7 attachment standards to promote future vocabulary control and reference,
say in C-CDA documents or other forms of attachment? That is one question.

My second question is I guess of Bob and Melanie. What methods are used for
authentication of physicians and the receivers of their esMDs, the medical
documents? Is it possession and use of digital certificates? Is it simply there
is a signature on a paper or a PDF copy of that written signature and that
allows things to progress?

My third question is that all SDOs seem to be working together to improve
the relative strengths and to share those strengths. Vocabulary control and
common data model are terms that I have heard more than once this morning. This
is difficult since much of your respective vocabularies are embedded in your
legacy implementations of your standards. I would ask how can NCVHS help with
vocabulary consistency, but I have heard some of the answers. One is by raising
the issue. Another one is by helping bring people to the table. If there are
other ways, please let us know.

MR. QUINN: As far as HL7 vocabulary goes, as you well know, Mike, our
vocabulary at this point is basically stuff that is peculiar to the
representation of the standard, itself. It is not the content of, for instance,
patient or provider information — things like the code for a message header or
a trigger event.

We have become more and more — not agnostic, but collaborative and
supportive with every — whether it is LOINC or SNOMED or NLM, in general, we
have gone to probably the opposite extreme, doing things like spending our
efforts on defining things like CTS2, Common Terminology Services II, as
opposed to trying to expand HL7 terminology.

As far as CIMI and FHIR, let me deal with the one that is probably closer to
reality, which is FHIR. FHIR, Fast Healthcare Interoperability Resources is the
acronym. It doesn’t really spell the word fire. It just gets pronounced that
way. FHIR is an initiative that has been going on for about two years inside of
HL7. It is basically creating a plethora of very finely granular web services
that could be used for reaching out and grabbing specific information about a
patient as opposed to saying give me a CDA of X that is populated with 200
elements.

Something that actually also speaks well to the way web architectures are
implemented today in other industries where you end up with a lot of — you
click on CNN. If you look at what is going on in the URL, it is going crazy
because it is going out and grabbing stuff from here, here, here, and here and
composing this thing on your screen on the fly. It is good to have good
bandwidth on your internet line for that reason.

As far as CIMI goes, HL7 is participating pretty strongly with CMI at this
point. That doesn’t mean that all the meetings take place at HL7 meetings.
There is one that is coming up that is going to be in Baltimore and Leeds
simultaneously next month, I think. This is the Clinical Information Modeling
Initiative, in case you are mystified by the acronym.

I have sat on the sideline. I have advised clients, including NHS at one
time, and said, you know, the one thing that the industry — and I am not
talking about the U.S. industry. I am talking about the IT and healthcare
industry together, globally — has not been able to manage is to figure out a
way of being able to information model clinical processes and map them to
information models.

Let me put it this way. We are still talking about it in CIMI. We still have
people I should say beating their head against the wall on it. I am not — I
haven’t seen the glow at the other end of the tunnel that is not a train coming
at us that is going to, in fact, say yes, we finally have conquered what may be
the most intractable conundrum within health information technology.

I will say I am much further along the way to having an OWL(?)
representation than I ever thought possible before, however, all 300 pages of
it on my laptop are not readable by me. I am assuming there is software out
there that will be able to read it and tell me that it really is a valid
representation. There is progress being made in a lot of areas. I am not
bringing any of them to the table here. This is for a future discussion after
some demonstration of value and implementability by something other than the
best informaticians on the planet.

MR. MCKINLEY: Can I add two seconds? To the extent that your question is
speaking to the speed to market that is standard and can respond to the
industry need, it is important to know that Consolidate CDA is built on a
template based model, which means that your document is a template. Within
there are sections, in each are templates. The sections can all be extracted,
plugged, and placed to build a new standard rapidly to the extent that those
are already defined. This is a very good piece that I wanted to share.

MR. QUINN: There is no hard limit to the number eight when it comes to
C-CDA. I am sure with my major stakeholders’ help, I will — that number will
be much larger soon.

MS. LOHSE: With respect to the question about authentication or signatures,
CMS really cares about that a lot. We don’t pay for a lot of things unless
there is a physician’s signature. When we receive a PDF of a handwritten
medical record we have pages and pages of instructions on what to do if it is
illegible or what if it is illegible, but there is a types name underneath. We
are golden in that department.

When it is a PDF of a printout of an EHR we have no rules. We leave it up to
our contractors to decide whether or not they will accept those little numbers
and those little words that come at the bottom of, for example, a progress note
or an order. We really need to get better about that.

For structured documents, for those signatures, we have developed the Author
of Record Workgroup. I am going to turn it to Bob to tell you what is happening
there.

MR. DIETERLE: Thank you. We have done a lot of work to try to move from wet
signatures and then electronic signatures and the need to validate specific EHR
implementations and their audit logs to prove, indeed, that those are valid
signatures to digital signatures.

What we have tried to do it come up with one standard for the industry,
under which identity proofing an individual or an organization at a level that
can be used for singing certificates for Author of Record. It can be used for
digital certificates for Direct. It can be used for any number of other
certificates or credentials that are necessary for authentication.

One would hope over time it could be used by the DEA for ordering controlled
substances. We are not trying to speak for them. The idea is one identity
proofing, one in-person process that can be used as the basis for then identity
proofing on a recurring basis that doesn’t require in-person identity proofing
because you can use the antecedent process.

We have written guides that are consistent with the Federal Bridge Authority
Medium Assurance using X509 signing certificates. They respect FIPS 186, which
is a requirement of DMSA for digital signatures. We use the Oasis SAML
Assertion to do delegation of rights. For example, a provider may assign the
right to sign on their behalf to another person who holds the certificate. We
can prove that cryptographically. We have adopted the IHE DGS standard for
storing digital signatures on individual documents and ensuring that they have
not been modified, data integrity.

Broadly, what we have done is over the last year we have developed the
guides for all of these. We are in the process now of piloting this or at least
getting this ready for pilot. We will be doing that over this current calendar
year. We are moving that effort from bundles of documents down to individual
documents. I think that — does that answer your question?

DR. SUAREZ: I think we are going to go to Jim.

DR. SORACE: Real quickly, it is very interesting because we have
administrative data, we have clinical data, we have practice management
systems, we have EHRs, we have pharmacy systems. It is a wide scope of use
case.

Moving this forward, I just want reassurance on one thing. If you look at
that diagram, the blue message envelope box — do we have, in existence today,
a necessary and sufficient, but minimally burdensome set of message envelopes
that these various developers and users can implement that will fulfill the
mission?

MS. LOHSE: I would say yes. I think there is probably more than one. You
heard about the CORE Connectivity, the SOAP, web services that allow the web
certificate. Then you also have Direct. You have CONNECT. There are a lot of
similarities with the CONNECT and the CORE. I think you do have that
capability. The world will change over the next ten years. I don’t know if
others have comments about that.

MR. DIETERLE: There are three broad classes of metadata that is part of the
envelopes. We have the metadata that has been traditionally associated with
specific standards, such as CAQH CORE for identification of source and
destination and routing an attachment to specific claims. We have the metadata
that is associated with specific transport, such as CONNECT, and the SAML
assertions that are necessary. We have some of the emerging metadata that is
associated with Author of Record and proving province of information as part of
the transactions.

Can we see all of those coming together? Yes for a particular transport
envelope/message combination, but as long as we are going to use multiple
transports, there will be some variability in what we need to support as far as
metadata. I think the number is very small. I think it is on the order of five
or six different things that we need to do. I am not sure it is outside of the
reach of the industry to support them, but it won’t be identical for every
message.

DR. SUAREZ: I think we are going to end. I wanted to really allow this
because I think this is really the most important part of our meeting. We are
about 45 minutes off the schedule. We are going to take a 15 minute break.

(Break)

Agenda Item: Big Picture Perspective of
Technology

DR. SUAREZ: Thank you very much. We are going to restart the hearing. We are
very pleased to have Doug Fridsma from, ONC. Again I express my apologies for
the delay and the pushing down on the schedule. We really appreciate your
coming and joining us. I know you have a lot of comments about a lot of the
questions that you heard in the back here during the exchange in the first
panel. So I will turn it over to you, Doug.

DR. FRIDSMA: Thank you. I am delighted to be here. The good news is that
much of what I am going to say has already been said among the colleagues we
work with ESMD and some of the other projects here as well.

My hope is to give you a little bit broader perspective, give you a sense of
the direction and sort of the strategy that we are doing at ONC to try to get
to this interoperable health care system that we would like to see.

Just by way of background, we have now gone through stage one and stage two
in terms of the certification criteria for health information exchange.

I think it is important, when we think about interoperability, that I
separate that into two functions. We have talked a little bit about that but I
just want to make it very explicit. Interoperability is defined as the ability
to exchange information and then to use the information that has been
exchanged. So there are two parts of it. There is one about getting the
information to move, and the other is having that information in a format that
allows you to use it for other purposes.

If it is a PDF you might be able to read it and you might be able go through
it and glean from that information. There is some degree of interoperability
there but we are really thinking about having those data elements that can be
used for clinical decisions, support, we used across other activities.

Much of what we try to do in our office is to identify what are the building
blocks that are necessary that span different kind of use cases and allow us to
assemble things together. We will go through that a little bit. And we use what
we call our Standards of Interoperability Framework, which is our way of
bringing together the communities that have problems that they are trying to
solve and giving them a format and a process, if you will, to come to shared
solutions about that.

One of the things that we did was when we created the consolidated CDA or
the consolidated clinical document architecture, we brought together IHE,
Health Bridge, and HL7. We took a look at the CCR, which was a standard which
was in Meaningful Use stage one. The CCD, that was also in Meaningful Use stage
one, and said listen, we are not going to have two different standards for
describing transitions of care. You guys get together and figure out how you
can simplify the implementation and merge those two things together. That is
really what the consolidated CDA is.

We have done that across a lot of different initiatives as well, and we will
talk a little bit more about some of those.

When I talk about standards – in fact there are three other layers and
I won’t go there, but there are five standards that we care about right now.
The first thing that we standardize is we standardize meaning. By standardizing
meaning we do that with vocabulary and code sets, so that when I say congestive
heart failure and you say dropsy, we actually mean the same thing because the
underlying codes are equivalent and computers can understand that.

I can look at those and I know that they are the same but a computer is not
going to be able to understand that congestive heart failure and dropsy are in
fact similar things. So we standardize meaning through vocabulary and code
sets.

That is why one of the things that is really important for claims
attachments is that we have shared vocabulary so that we have shared meaning.

The second thing that we standardized is structure. The reason we do that is
is the message formatted so that it is computable so that a computer can start
at the beginning of the content and go to the end of the content and be able to
break it up into its chunks and know what sections are what so there is the
ability to break that content apart and understand what to do with it.

So we standardized structure that helps computers have predictable ways of
looking at how the information is organized.

The third thing that we standardized is transport. That answers the question
of how do I move information from point A to point B? As you have heard, we
don’t believe necessarily that there is a single one size fits all for
transport. I like to use the analogy, how many of you keep in touch with your
families? How many of you use email? How many of you use the phone? How many of
you use your cell phone? How many of you have got Facebook going? Any of you
with twitter?

So if the relationships that we have with our family have multiple ways that
we communicate – healthcare has a big industry with lots of complexity. We
are not going to be able to distill it down into one way. Can you imagine if
the only way you were able to talk to your family was through 140 characters on
a little twitter feeds. That would be crazy.

We know that there has to be different ways to transport things because we
need a portfolio that fits into the work process.

Two other things that are important; we standardize security so that people
can encrypt and decrypt on both ends, and we standardize what I call
“services”. So services to me are the verbs, if the content is the
nouns. So a service says what can you do with the information? Like I can save
it or I can send it. Those are kind of examples of services. We haven’t done a
whole lot with services but with this Structure Data Capture Initiative we are
actually going to start exploring how we can standardize services.

So, we standardize meaning, structure, transport, security and services.
Those are our fundamental building blocks that we have tried to build into
Meaningful Use stage one and stage two.

We have talked about some other things. If you really want to get to
interoperability there are three other things to think about and you can write
these in the margin because I don’t have building blocks here but you guys
talked about them so you can.

So one of them is context – like where did you get the information so
that you know where to use it. You need to know context sometimes for
interoperability and reusing that information.

The second is workflow. I know where it came from and where it needs to go
to so I can integrate it dynamically into a work process. The third is policy.
And policy is probably the hardest degree of interoperability. If you have the
same policies then you are able to actually use the information for similar
things. We don’t have those just yet but the five things that we are focused on
are right here.

Our approach to standards development across ONC is that we believe that
interoperability is not one size fits all. So we believe that there needs to be
different transport standards that fit into different work processes. But we
also want to have series of building blocks that are reusable so that we don’t
have multiple vocabularies. We have SNOMED, ICD-9, ICD-10, RxNorm, and we want
to make sure that those building blocks can be reused.

We don’t want to have a thousand different standards out there. We want to
pick a parsimonious set that has some reusability to it, and take standardized
meaning, standardized structure, standardized transport, and assemble those
things together to solve problems.

Substitutability is a term that I like to use as opposed to modularity,
because substitutability suggests that I can take one transport mechanism and I
can substitute another one, and all the other pieces continue to work the way
you would like them to do.

We need to have some degree of optionality but optionality increases
complexity and we always have to be very parsimonious when we think about that.
But we do need to get to this notion of substitutability that I can use say,
web services as my transport and use multiple different kinds of content and it
doesn’t affect the way in which the transport works.

The same thing, I could take a single kind of transport and I could send it
with direct or I could send it with web services or I could use a restful
approach, and it doesn’t affect the way the content is structured or the way
the content is described.

So creating those levels like that allows us to have a portfolio that we can
assemble together to solve problems, it reduces the complexity because we have
the reusability, and it actually gets us closer to interoperability because we
have commonality across different use cases in different things that we do.

So one of the things when we think about the attachments, there is an
opportunity I think, to leverage the transitions of care work for some of the
clinical attachments that are there. So I would implore that rather than create
a one-off around claims attachments, to help us identify what is a common way
to do things that serves both clinical care needs as well as for the claims
attachment work.

We need to create a community and engage so that we have some commonality
with what we do. It is probably an appropriate part to start with consolidated
CDA, and a good metric or a good way to look at the problem is if there is an
existing standard we should use it. If there is an existing standard that
doesn’t quite fit our use case, let’s see if we can tweak it. And if there
isn’t a standard that needs to be there then what we should do is we should
build it in a community that allows us to actually create usability so that we
don’t have different communities developing different standards, but are all
doing essentially the same kinds of functions.

I know that you have already taken a look at this, the Consolidated CDA
Document Level Template, and the things that are there. That is a starting
point. It is not an ending point. I know there are eight templates, but in fact
maybe we need to add new segments, maybe we need to add new kinds of elements,
maybe we need to add new sections to try to make a way for these things to be
reusable.

We want to reduce the complexity of formats. We want high quality data that
is highly cost effective and we want to reduce the documentation burden through
alignment with the resources that are going on. We, at ONC, have chosen not to
hire a bunch of contractors to develop a bunch of standards and to give that to
the community. We have instead invested our resources into creating a convening
role, to bring communities together to come up with those problems so that the
problems and the solutions are already sort of identified with the communities.

The work that has gone on with DSMD and with Melanie’s group, is an example
of CMS and ONC and the community coming together. Let me just things like
author of record – maybe that is something we can use in other situations
in which you need a signature for whatever that work process is. So Melanie has
been working very hard to make that a modular and substitutable piece.

We are also working with them to sort of continue in this SNI framework. The
claims community is important and we have chosen in large part, to focus on the
clinical work because we believe NCVHS under the HIPAA transactions, has
purview to make sure that that is important.

But we have got to work together with you because as we look ahead to
healthcare reform and we look at cost effectiveness and reimbursement for
quality, we are going to need the same sort of substitutability and high
quality claims information that allows us to link the quality of activities
with the claims information and be able to make some sense of that that says,
what is cost effective, what is working, what is not, and the like.

A lot of the transactions are in fact transaction based, but we need to
start thinking about what are those data elements that are in there that need
to be extractable so that we can do big data analytics and other things like
that to the data that gets exchanged.

So with that I will stop and open it up if there are particular questions.
But I think there are a tremendous number of opportunities for us to begin
thinking about layering out our standards, finding out where there are
commonalities across the various building blocks.

One of the things I think Melanie’s team talked about was this notion of
structured data capture. What this really is if you think about the standards
that we have in Meaningful Use stage one and stage two, most of them are
document centric. Say here is a document with sections and you can extract a
section and reuse it for clinical decision support or the like.

But as you start to think about pre-authorization, there is a bunch of data
that you need to have for that. If you think about safety reporting, there is a
bunch of data that you need for that. If you think about clinical research and
the learning healthcare system, there is a bunch of data that you need to
collect there.

It will not be scalable for us to certify an electronic health record to
capture that whole range of possible clinical, adverse event, pre-authorization
data elements. But if we have a common way of describing those atomic data
elements then we actually empower the electronic health record to do all of
those things and we allow the domain experts in CMS and the folks that are at
AHRQ and the folks that are at the NIH, to really focus on the definitions and
what the data looks like. Because they focus on meaning in those common data
elements because they all have a common structure that we can then have EHRs
interact with. It is a really important part of our layering strategy.

With that I will stop and see if there are any questions.

DR. SUAREZ: Thank you. This was a great overview of the concept that we have
talked about in the past with within NCVHS, of the convergence which is really
now happening between the clinical and the administrative world.

Let me see if there are any questions?

DR. FITZMAURICE: Doug, that was a very cogent presentation and I liked how
everything fit together. One of the things that you mentioned was building
block components and combination of the building blocks. As you look across the
standards and interoperability initiatives, have you thought about the use case
components and maybe looking at use case components by initiative to see what
their decisions have been so that new use cases can look at those same
components and reuse them as you build towards standards that are reusable?

DR. FRIDSMA: So we do have some activities in the standards and
interoperability framework. It is much easier for us to create compelling
justifications for investments when there is a tangible return that says we are
going to develop a standard for example, for laboratory reporting, HL7251 or
whatever it is, or we are going to create convergence between CCR and CCD.

But you are absolutely right, if we wait until we have developed what the
standard is and then try to identify is it the same use case, it creates a lot
more work. But if what you do it is at the use case, and say you know what, the
kinds of things that we are trying to solve in this initiative are very similar
to the kinds of things that you are trying to solve in this other initiative.
That is something that we are able to do.

Now there is work that we have with NIST on use case simplification,
creating some tools that make it easier for us to have consistent ways of
describing those use cases. If you get agreement up front that the problem that
you are trying to solve is the same as another problem that somebody else has
already solved, getting to that solution becomes much, much faster. So we are
working on that but that is a hard kind of SNI framework initiative that we are
still working on.

DR. CHANDERRAJ: One thing I see as a practical problem in trying to
structure the clinical document is because physicians have not been trained or
educated from the medical school days to relate a particular disease or
substance in a particular format or particular name.

Has ONC considered introducing this as part of the curricula to develop a
unique standard because that is where I think you will develop a uniform way of
communicating, because physicians today, use the same, like you said, for
congestive heart failure, they use dropsy, they use different elements, ankle
edema, they use different sets of naming the same thing. So I think education
should begin with the physicians at the medical school days and try to
incorporate this at a later time, maybe once the present batch of graduates
come out.

DR. FRIDSMA: I have just sort of two comments to that. First, as a
physician, I certainly understand the tension between structured and
unstructured information. I think that it is important to realize that, from my
own personal experience, I had someone who was an paranoid schizophrenic. She
was an older lady and just delightful. She truly was. One of my favorite
patients. But I could tell if her meds needed adjusting by how she dressed. She
would dress to the nines. She had the hats and the gloves and everything. She
came in dressed to the nines. But if she didn’t match I knew I had to check her
levels.

Now how do you capture that in electronic health records? Right?

(Laughter)

The thing is we have to be very sensitive to that and I think what we have
to do is we have to figure out what needs to be structured? And the things that
need to be structured are the things that need to be re-used in some sense. SO
if you take a look at meaningful use stage 2, the things that we really try to
move the bar in terms of structuring was medications, problem lists, allergies
and lab tests. Because what we heard from physicians was if I am on call and I
get a phone call from somebody and I don’t know the patient terribly well, if I
know their problems, their medications, their lab tests and any allergies, I
can get about seventy percent of what I need done in that kind of conversation.

It is also something that can be used for clinical decision support. It can
help us with some other things. So we have to make sure that we structure the
things that are necessary and not structure everything, because I think that is
a dangerous path to go down.

So your point about education – when I was at the University of Arizona
and Arizona State University we actually did some early curriculum work with
physicians who were in training, to help them understand how to structure
information. But it is a complicated thing to talk about how you deal with
information. What is the basic science of that? We didn’t wait until they got
to the EHRs and h ad that be their training. We said how you structure
information is based on the kinds of questions that you need to ask.

So we did some decision analysis, because that is an important piece of it,
and we talked about how you structure information and gave them a bunch of
exercises and other studies to take a look at. The thing that you are saying,
and I think it is really important, is that it is not about teaching people jut
to use a stethoscope. It is about being able to use the stethoscope as a tool
to help them with being a better doctor, to being a better
diagnostician.

We need to make sure that students who are studying to be doctors, and any
providers, see information as a tool in their armamentarium that, if they
collect it and use it in effective ways, can make them better at taking care of
patients.

DR. SUAREZ: So I do have a quick question. You had a chance to listen to the
testimony through the first panel. In the recommendations that we heard
basically, we heard the kinds of points that you made – build from the
structure of HL7 using LOINC codes.

Throughout those recommendations did you see or did you hear anything that
is inconsistent that meaningful use is going? Particularly thinking that by the
time that this is to be implemented, January 1, 2016, that is when covered
entities will be required to comply with the standard, we will be well on the
way to meaningful use stage 2, and probably getting ready for stage 3. Did you
identify any areas where things need to be considered differently?

DR. FRIDSMA: I think there are a couple of things. In general I thought the
testimony was really sort of heartwarming in the sense that people are
beginning to think about separating out transport from content from meaning. I
think there are still – we’ve said this before – there are a lot of
standards out there and a lot of people already have a way of doing these sorts
of things. We have to recognize where people are and we have to try to help
move to a new place in some sense. So there is going to be a little bit of pain
with that as we go, and we have to think about how we can provide – we,
the government and the community – tools and resources that will aid in
that migration. It has to be part of our conversation.

I also think that we have to be looking ahead. I think this is true of
meaningful use. I think it is true of many standards that are out there. They
tend to be reflective of the way healthcare is organized now. So it tend sot be
transaction-based; it tends to be I have the information and I send it to
someone else.

I think when you think about some of the pioneer ACOs and you think about
accountable care organizations, it is going to require maybe different models
about how we exchange information. It may not be that I send it to people. How
many of you have tried to write a document with 10or 15 other people using
e-mail and putting that attachment on and sending it around. It is a really
challenging thing to do. And Google Docs allows you to get everybody in there
and everybody edits and you can actually do it a lot faster. But that is a
different way to think about information than to say I am going to send it to
you and you are going to send it to someone else, and we’re all at some point
going to try to merge everything together.

I have said this before. Part of what we are trying to do is take what I
call a path of least regret in the standards that we adopt, so that we don’t
preclude policy changes or other technology because, well, we’d love to get to
that more collaborative place, but all of our standards are based on
transactions and we don’t have a good way of sort of extracting that and
aggregating that.

So big data analytics, making sure that we understand how cost effectiveness
works, which means you have to marry quality with the economics of things. It
means that there are use cases out there that are not transaction-based that
are going to require sort of integration and collaboration, and may require
different ways of putting meta data and more granular data that can be then
aggregatable, if you will.

So I think we need to start dipping out toe into that water and start trying
to find where the low-hanging fruit it for us to start on that process. Maybe
we are not going to change everything, but let’s identify some places where
that would be a valuable place to go. Take some of the transactions, take some
of the HL7 stuff and see how we can create more granular representations and
more ability to have that big data analytics and aggregation.

Agenda Item: Panel 2: Industry Perspectives

DR. SUAREZ: Great. Any other questions? Thank you again for your flexibility
with your schedule. We are going to go right into Panel two. I understand there
are a couple of changes in the order of the agenda. Are we still going with
Gail first? We are ready for Panel 2. We are going to start with the Plan
Perspective and go to the Provider Perspective.

Agenda Item: Plan Perspective

MS. KOCHER: Good afternoon. My name is Gail Kocher and I am director of
industry standards and e-health through Blue Cross and Blue Shield Association.
BCBSA is a national federation of 38 independent community-based and
locally-operated Blue Cross and Blue Shield companies or plan, that
collectively provide healthcare coverage for 100 million members, one in three
Americans.

On behalf of BCBSA and its member plans, I would like to thank you for the
opportunity to respond to the subcommittee’s questions and provide our
perspective on healthcare attachments.

While current operations for attachments vary somewhat from plan to plan,
our comments provided in response to your questions do reflect a representative
review of all Blue plans. We do have just some initial points before we go
specifically to the questions.

First and foremost, we believe strongly in the value of standardization.
Rules for attachment that automate today’s largely manual processes have the
potential to generate significant savings. Further we believe that the rule
should not only to claims transactions, but also to referral and prior
authorization, but through staggered implementation approach.

To realize this potential, we recommend building in flexibility to allow
trading partners to mutually agree to alternative methods to exchange
healthcare attachments, putting limits on unsolicited attachments to avoid
unnecessary work to manage and control unwanted and unnecessary documents.

Planning extensive outreach to providers to encourage participation that
will enable the realization of the full potential value, sequencing the
implementation of operating rules, so the finalization of operating rules is
sequential to and after finalization of the transactions standards, staggering
the implementation of the attachments for the referral and prior-auth, and
other business purposes after claims to limit operational overload.

These last two recommendations are emblematic of the larger issue; the huge
volume of systems related mandates bearing down on plans, as well as providers
and other covered entities, not only through HIPAA but the provision of other
requirements related to the Affordable Care Act. Therefore we see the need for
strategic roadmap to balance these mandates that are coming and ensure a smooth
and successful implementation.

Now let us address the specific questions. The current methods of requesting
additional information are predominately by letter or some by email or
facsimile. The most common format that plans receive today are hard copy
reports or images such as x-rays. In some instances plans do receive those
reports via facsimile, but we all know what that does to the quality of the
document.

There are a few plans that can accept attachments through internet portals
as PDF documents, and there is a limited use today of the electronic
transactions, such as CX12-275.

To some degree we do know that current standards and infrastructure will
support electronic exchange of clinical information between payers and
providers. What we know of less certainty however, are alternatives that may be
in place, but just as easily adopted with respect to the exchange in 2016 and
future years.

Technology and standards are rapidly changing and any rules promulgated
should allow for flexibility in the use of new transport methods in document
types.

As long as trading partners mutually agree to the alternative methods and
remain compliant with base standards, those alternatives should be permissible
under the rules.

Operating rules should also promote wider adoption through greater
uniformity across all trading partners and greater consistency in the
operations once they are implemented.

While certain rules can be based on those adopted for other transactions
such as the baseline Safe Harbor connectivity system availability, response
time and performance in general, other rules may need to be specific to the
transaction, such as unique requirements for unsolicited attachments.

We support the development of a unique set of healthcare attachment
operating rules through industry wide collaborative processes. In our view, in
order to avoid potential conflicts, a final set of standards needs to be
adopted prior to completion of the complete set of operating rules for the
attachments.

We believe that benefits can be identified through tracking things such as
success metrics. Which can be based on elimination or reduction of known issues
or improvement in existing performance measures.

If for example, a certain percentage of attachment types require more than
one request, we would expect that percentage to go down with greater
automation. This is something that can be measured.

The length of time to complete or finalize claims that require additional
information would be another meaningful measure of that success. Accuracy based
on statistical sampling could also be used to monitor progress.

While we do not have specific, absolute, or unit cost of the current state
that we can report to you, we do know that plans realize significant cost in
several areas. Labor costs associated with manual requests and document
handling for both request and receipt of attachments, generates a high
percentage of current operational costs. Other than labor, costs are incurred
for things such as postage or courier services.

Cost savings can be achieved through greater automation and standardization
through either cost reduction or cost avoidance. The level of such savings for
the payers will be largely dependent on the level of participation by the
provider community.

We would expect that cost reductions for labor and postage and cost
avoidance through the reduction of service calls and redundant work due to lost
or misplaced documents. We would also anticipate improved customer relations,
whether provider or member, due to the timelier processing, which would be a
valuable consequence of greater automation based on standard document types.

We would categorize the use of existing infrastructure as cost avoidance, as
opposed to cost savings. If providers and payers could use the same basic
infrastructure to exchange healthcare attachments as they use for claims and
other mandated transactions, there would be no need to expend additional
resources to implement a new infrastructure for the attachments.

Whatever combination of standards are adopted they should be implementable
within our current infrastructure but should not preclude the other alternative
methods for trading partners that wish to mutually agree to develop and
implement those methods.

Operating rules can address important issues such connectivity, system
availability, and performance measures such as timing responses from request to
delivery. The need for other rules specific to the transaction type, such as
unsolicited attachments, items that may require more than one request and
others, should become more evident once final standards have been specified for
adoption.

An operating rule for document quality and readability for unstructured
documents is also something that might prove valuable.

Healthcare attachment standards that either currently exist or close to SDO
approval, could be used for additional requirements other than claims. Within
the current suite of transactions required under admin sym provisions,
additional information required in order to respond to a prior authorization
request would seem to be supported by a combination of ASCX12 and HL7
standards.

While we support the development and use of such standards for multiple
purposes, we will caution against having use of these standards mandated at the
same time as claims attachments. The ACA mandates that plans implement claim
attachments by January 1, 2016, any requirement to implement attachments for
other transactions should be staggered one or more years later.

Some of the most important business and technical issues with the attachment
standards and operating rules are the introduction of additional clinical
document formats and code sets that are new to most of the payers. They are
introducing concepts such as the clinical and administrative data, structured
and unstructured data multiple uses for clinical information, and transport and
delivery options, as well as greater automation surrounding the clinical
attachments.

The last issue, these unsolicited attachments, warrants particular attention
because allowing unsolicited attachments outside of trading partner agreements
would unnecessarily impose additional administrative burden on payers, as well
as the providers. Payers would need to develop new administrative procedures to
receive, store, protect, or dispose of these potentially large volumes of PHI
and PII, for which they have no need.

Payers would face challenges in marrying the unsolicited attachment, which
is a separate transaction to the appropriate claim in the adjudication system.
There are additional concerns that must be addressed in any implementation of
unsolicited attachments and are unique to that arrangement.

Providers who send the unsolicited attachments outside of the trading
partner agreement, would bear a greater burden to document compliance with
minimum necessary standards than if they sent unsolicited attachments as part
of a defined trading partner agreement. These agreements could outline when the
unsolicited attachments are appropriate, and would give providers guidelines to
justify disclosing the PHI to a health plan for payment.

Getting started with basic requirements that show immediate positive
results, we see as a key first step. As evidenced by the 2005 CMS Electronic
Claims Attachment Pilot, immediate cost and performance improvements were
realized using a very basic approach for requesting and receiving claims
attachments.

Once there is wide adoption of the basic standards within the industry we
will be better positioned to take greater advantage of the standards through
enhanced automation made possible by structured documents.

This should not preclude immediate adoption and implementation of greater
adoption for those that are willing and capable to do so. As we have previously
stated in prior comment letters and testimony, we believe the use of
unsolicited attachments should be based on mutual trading partner agreement and
not mandated by rule.

In conclusion, BCBSA does support the adoption of standards and operating
rules for healthcare attachments. We recognize the potential value of their use
with respect to reduced cost, greater quality and improved customer
satisfaction. We caution against rulemaking that would require the adoption of
more than claims attachments, as specified in the ACA.

We see the need for a basic set of requirements that will promote adoption,
but at the same time permit other uses and more sophisticated automation. While
some concurrent development of standards and operating rules seems reasonable,
we would recommend the finalization of operating rules that they should be
sequential to, and after finalization of transaction standards, and that
implementation times be adjusted accordingly.

We recommend that the implementation of all federal mandates, including
claim attachments, be encroached in phases to address these aspects. Given the
number of mandates with an implementation date of 2016, we encourage CMS to
consult NCVHS to develop a strategic roadmap for administrative simplification
provision implementations.

This roadmap should balance all mandates from the ACA, not just the admin
sym provisions, along with the other error in HITECH mandates to work towards
avoiding bottlenecks and overlapping resource commitments.

We would request that NCVHS work with industry stakeholders in developing
this roadmap. We appreciate the opportunity to testify and I would be happy to
answer any questions. Thank you.

DR. SUAREZ: Thank you. Any pressing questions from anyone, at this point?
Let’s move on to George.

Agenda Item: Provider Perspective

MR. ARGES: Members of the subcommittee, I want to thank you for the
opportunity to be here today. I am George Arges, senior director of the Health
Data Management Group at the American Hospital Association. On behalf of our
members I want to again, thank you for the opportunity to present our views on
the electronic attachment standard and operating rules.

Over the past several years the major capital investment that our members
have been pursuing has been information technology and in particular, the
adoption of electronic health record systems.

Another of these initiatives is the investment needed to transition to ICD
10. This effort seeks to adopt a more robust clinical code set to improve the
understanding of the disease and illness rendered to the patient. Both of these
efforts are at the top of our member’s information technology initiative and
require considerable resource commitment.

Today’s hearing are about electronic attachments and standard and operating
rules. The attachment standards are of a concern to hospitals because there is
a lack of a well defined business model that can be applied to the attachment
standard. It is our view that the use of attachment standards should be rare
and only used, in particular with building information, when it is insufficient
to convey an understanding of the information reported on the claim.

It should never be used as a mechanism that seeks to build a database of
tests or lab results or for the receiver of this information to conduct data
research.

If the claim attachments standard is needed for certain types of rare
situations or occurrences, it should require reporting guidelines on the use
and handling of this information.

Much of the data contained on the claim comes from information contained in
the EHR. The same can be said for the attachment standard in that the
information being requested, often looks to the EHR to obtain additional
information and therefore becomes a secondary use of the EHR.

If more specific and detailed information is being requested via the
attachment request, it must only occur because there is some uncertainty about
the information reported on the claim in relationship to the reported diagnosis
codes.

A current ICD 9 diagnosis coding system often lacks the specificity needed
for users to fully understand information reported on the claim. We believe
that once the transition to ICD 10 is complete, we envision less of a need to
request additional information via the attachment, since the specificity of ICD
10 will provide the detail user some of the needed understanding to basically
process the claim.

Our first recommendation is that the NCVHS oversee development of specific
guidelines that describe the appropriate application of the attachment
transaction standard and the associated purpose for requesting additional
information.

I say this particularly since the first panel talked about a number of other
uses for the attachment standard; for prior authorization, for
post-adjudication review, for communicating information that a clinician may
want to share with another clinician, as part of this.

This is even more imperative as you like at it from these other purposes as
well. So guidelines are needed to basically describe how and when the
information should be provided and for whom. What application and for what
purpose. We need this information because we did not hear anybody talk today
about the patient and about the privacy of that patient and what the potential
might be for misuse of data contained in the attachment standard.

I think that it is important that these be considered as part of the
guidelines as you move forward.

The recommendation about protection on access should be also applied
throughout the transaction standards as you look towards this. In particular
since one of the methods of conveying information might be an image of the
electronic health record page that contains the information requested. The
question then becomes should protections basically be included, such as digital
right management that restricts the ability to view or open the attachment
document. To only authorize individuals or specifically designed email
recipients.

Additionally, if a DRM is established, should there be a reasonable amount
of time for the receiver to review the attachment data, then to make a decision
about the claim.

Then after this period has expired, the attachment document cannot be
reopened. So in essence, it becomes unable to be transported or misused for
another purpose.

The DRM should limit the ability to print the attachment document as well.
This is especially important because the design of the attachment standard
allows a portion of the hospital medical record document to be scanned and
placed digitally within the attachment standard.

Since there are a number of entities handling the transmission of the
document, it becomes even more important to provide some sort of protection to
limit access and allow review to only those authorized representatives, as well
as printing of any long term storage of that document. Such actions would be in
keeping with the minimum necessary provisions of the HIPAA Privacy Rule
Electronic Records.

Establishing DRM processes also requires providers and health plans to
utilize a common DRM system application. It would require someone to manage
this process, someone to register those requesting authorization to review the
attachment, log them into the DRM system. The DRM maintainer would then receive
the attachment, they would allow the DRM rights to be applied to that document,
basically allowing a certain number of days or months to view that document and
perhaps put in no printing requirements. Then the information should be routed
to the requester who has been preregistered as part of this process.

The DRM system maintainer would then be able to track whether the attachment
was opened by the authorized receiver, how often they opened the document
during the specified period. In addition, the DRM system maintainer can issue
an annual report on the frequency of use of attachments by health plans and
others.

Without these safeguards we would be increasingly concerned about HIPAA
privacy violations. It is our hope that as our nation moves more towards to the
use of ICD 10 clinical coding and its greater specificity, the need for
additional attachment information will be eliminated.

I wanted to remind the users of the HIPAA transactions, that there are
processes in place today to embellish and add new information to the claim if
needed, to establish greater accountability around the bill charges.

I know that I serve on the National Uniform Billing Committee and I know our
committee stands ready to entertain any new coding requests that are needed for
inclusion to the UB-04 dataset to further eliminate the use of attachments. We
have done this in the past, when we looked at the UB-92 revisions that were
incorporated. We surveyed users, determined the type of attachment information
that was provided as distinct documents. And based on this information we
embarked on a process to basically improve the UB-04 dataset, adding a number
of new codes and data elements that were designed to eliminate attachments.

But it is important that the 837 institutional claim that incorporates the
UB-04 dataset, also have users program their systems with the necessary edit
logic to understand all of the UB-04 codes and their meaning.

So any request for attachment information that is already codified on the
claim, should be prohibited. It is just busy work.

When it comes to operating rules, the AHA is supportive of operating rules.
But in the case of attachments, I would urge that a model framework that
includes guidelines and DRM managements, be examined first. This is
particularly important since operating rules generally seek to adopt best
practices associated with a particular transaction.

In this case, the attachment as a HIPAA standard, has not been in use for a
significant period of time, nor does it have the type of protections that I
mentioned earlier. And most importantly, we do not have operating rules for the
claims standard at the present time.

So the AHA would that operating rules for the claims standard be issued
first to demonstrate adherence and functional capability of users to handle the
full array of codified information on the claim. Additionally, with the
implementation of ICD 10 coding systems, we may see a significant decline in
the need for more information since greater specificity about disease, illness,
or procedures are part of the new clinical coding system.

I want to thank the NCVHS for the opportunity to present and I would be
happy to take comments later on.

DR. SUAREZ: Thanks, George. We will go to Mary.

MS. SAVICKIS: Thanks very much. On behalf of the American Medical
Association and the Medical Group Management Association, we appreciate the
opportunity to comment today and I am joined by my esteemed colleague, Rob
Tennant, in the audience.

I thought as I was preparing for this hearing that I would bring a little
levity to it. I am the mother of twins and I am potty training them. I presume
some of you have potty trained kids before – new mother, don’t know what I
am doing. Let’s just say it is messy, diapers are costly, and I am looking for
a standard in efficiency. What can we say, all right. I have a daughter and a
son and I need patience. I see the standardization on the horizon. I know it is
coming. I can’t speak for Rob on that front.

The AMA and the MGMA are very supportive of the X12 275 and the existing 277
standard. We would like to focus on some of the recommendations that we have
made to this committee in the past. I know you have probably heard some of
these things this morning and probably bear repeating, at least in our opinion,
but we like to take this opportunity to emphasize some of our previous
recommendations and emphasize the importance of adopting the 275 as a uniform
standard.

I would like to preface my statements by saying that it is not that
physicians and physician practices are opposed to change, we look forward to
that day when true interoperability is at the point of care and you will have
the information that will move seamlessly among and between providers, but
let’s be honest, we are not there today. So we are looking for a solution that
can be adopted more immediately, as other solutions percolate up.

Again, we would like to focus on adopting the 275, I will talk about ESMD
shortly. We also recommend the adoption of the supporting operating rules for
X12 277. We recommend the business use for the 277 and 275, be the request for
additional documentation sent to the provider and the corresponding response
received by the provider from the payer, referencing the documentation.

Furthermore, we think business rules should be applied in a consistent
manner across all providers and payers, for both unsolicited and solicited
responses.

We have heard a lot about prior authorization. It is an increasing practice
among payers and we are looking for efficiencies. That is the bottom line. The
current prior authorization process for medical, pharmacy, laboratory and
radiology and DME services is manual. It is costly. We want to get rid of it.
SO we would like to see some standardization.

Uniform standard and operating rules for attachments would bring significant
cost savings and efficiencies to this process. If it must be used it should be
streamlined.

An automated workflow should be integrated within practice management within
EHRs and the best solution we think would be a single electronic end work flow
for prior authorization that utilizes the 270, 271, 278, 275, 837 and 835
transactions. We have heard also a lot today about where administrative and
clinical data is colliding, and we are in that – I don’t know if you want
to call it the “sweet spot,”, but it is a transition. The health care
industry is in enormous transition right now and physicians are at the
forefront of this and there is a lot of change. I heard the mention about the
framework, the need for kind of mapping a way for us to adopt and get to the
place where we need to be. There is a lot on the horizon, so we need to be
thinking strategically about how we can make sure that physicians, in our case
physicians, and physician practices, are able to get there. So we are drinking
from the fire hose.

The X12 centers are the ones that are already built into the systems, they
know how to use them. There are some other solutions. As I said, ESMD, which
are percolating up, but we like to think that as we start shifting into an era
where administrative and clinical data are coming together we still would like
to use the existing efficiency that we think is right there.

We think the 275 can accommodate both structured and unstructured
attachments when they can be sent from the PM or EHR. The 278 transaction,
while not the most efficient, also has the capability to convey a payer’s web
address to link physicians to required forms and questionnaires that we have
heard about also. So our recommendations are that it is critical for the
attachments that are to meet the varying stages of industry readiness. The vast
majority cares, so practice in small practices today – maybe the large
providers are going to be able to accommodate some of the costs of some of
these newer models, but we would like to see the X12 centers adopted.

We think that will deliver the efficiencies with prior authorization. It is
going to accommodate some of the meaningful use. But keep in mind that
meaningful use is also a challenge for many physicians. The centers that are
baked into that will become a de facto center for physicians, even if they are
not actually going to go through that program. That is another challenge and a
conversation for a separate day, but not every physician may necessarily be
able to meet all the meaningful use standards. But the ones that are baked in
do become a de facto standard for the industry.

So what we would like to see – the reality is we would like to get to
this true level of interoperability, but we are not there. We are on the
pathway there but the reality is it is going to take several years. The HIPAA
standards still, the entire set that are adopted today, are not in full use,
and that is another issue we are grappling with. SO the reality is it is going
to take some time and we still are going to be relying – I mean it is
unfortunate, but it is the case that we are still going to be relying on
unstructured data. I think it would be a mistake to say no to the X12 standards
and leapfrog over and require the use of only some of these other new
technologies, when we could implement something today that could help move that
dial forward, while again not precluding the use of these other new systems
that have been mentioned.

SO our recommendation is implement the 275 structured payload envelope and
the 277 request transaction will quickly reduce significant burdens on
physician practices, and streamline much of the payer processing required to
support the payer needs for prior authorization and other purposes. It will
also leverage existing investments of the healthcare community that have
resulted in the HIPAA –mandated transactions to date.

I will talk a second about the operating rules. I don’t need to go through
this list. You can all see it on there. WE think they should include a number
of things ranging from guidance for unsolicited attachments all the way down
the list through standards, legal agreement, and there was also lots of
discussion around the LOINC codes. We agree with HL& that the attachment
rule should not name the specific external LOINC codes used to identify types
of unstructured attachments. The industry should continue to request and use
LOINC codes for attachments that are needed to meet their business needs.

We recommend external LOINC codes be referenced in the rules. SO that is a
specific recommendation we make to NCVHS to meet the CMS. And the rule should
also include terminology centers that are consistent with meaningful use, as
there are a number of ways that the certified EHR technology identifies medical
elements, such as problem lists and conditions, allergies, adverse reactions
and medications.

So this brings us to the conversations that you were having this morning
about the lack of a standard has brought other solutions. This seems like a
natural thing. Melanie and her staff have done an excellent job of trying to
figure out a way to automate the process that they need for the PMD.

I can only speak on behalf of the AMA but we have been deeply engaged in
those discussions, and in fact we have joined the SNI framework on Melanie’s
group to try and become as involved as we can and learn as much as we can about
the ESMD process. From the looks of it right now I do see the numbers are
growing, but they are still very low.

It is, as Melanie mentioned, a costly solution for the average practicing
physician or small practice. Right now it looks to be somewhat cost
prohibitive. Nonetheless we think it is important to remain engaged and we
would recommend that if CMS is going to go down this road, which we hope they
will do, of adopting the 275, that they still also leave open the option for
use of the ESMD should the provider and payer agree to that.

I have already mentioned we would like to see use of the existing standards.
That would help bring efficiencies to the existing system. There is a lot of
talk in this town about administrative simplification and reg relief and we
think that this is completely consistent with our efforts to move the dial
forward on existing X12 centers that are already baked into everybody’s system,
and we think if you can use these now, while still exploring other options,
those again flexibility, what works for my son and potty training may not work
for my daughter – nonetheless we would like to see them both use the
bathroom at some point.

Please do adopt the X12 centers, but still nonetheless leave open the option
for maybe larger practices in the future – it will be a small practice but
right now it looks like it is going to be the bigger providers using these
other solutions. We would recommend also that we need industry guidance on
securing PHI, in particular the smaller practices and providers. They need as
much help as they can making sure that as they start moving data in this new
electronic world that it is done in a safe and secure manner. They are not
experts on all things technology.

So ESMD – I like to refer to it as the secure electronic tunnel when I
talk about it and break it down into the fifth grade English sometimes that I
have to do at work. Again they are looking for that day, that sweet spot when
there is going to be bidirectional information exchange. SO again we think this
is great. It should be left as an option. We do want to see the 275 adopted. I
would also add that as new versions of HIPAA are considered, such as the 6020,
which includes ESMD, care should be taken to insure that there is ample
opportunity to figure out how attachments will be handled.

I am not the expert here on worker’s compensation, pinch hitting a little
bit for one of my colleagues, but this is something that we have raised in the
past. There is a lot of use and need for attachments in worker’s compensation,
and bringing the 275 to the forefront is going to be very helpful. We strongly
support expanding the applicability of the HIPAA attachment, electronic health
care transactions, to all lines of insurance as applicable, including worker’s
compensation.

In summary what I would say, and I think I have said this a few times, the
attachment center and operating rules will greatly improve administrative
simplification. They are right there on the horizon. Centers should be
flexible, not stifle innovation, and permit additional industry approaches.
Rules should leverage existing HIPAA transactions and prior authorization, and
worker’s comp approaches should be incorporated.

I guess we will take questions at the end of the panel. Also we are
submitting written comments for the record, too.

DR. SUAREZ: Thank you

Agenda Item: Multi-stakeholder Perspective

MR. DAY: Good afternoon, members of the subcommittee. My name is Durwin Day.
I am legal and regulatory implementation strategist with Health Care Service
Corporation, and a member of the Workgroup for Electronic Data Interchange, or
WEDI. I would like to thank you for the opportunity to present testimony today
on behalf of WEDI concerning the matter of attachment standards and operating
rules.

WEDI represents a broad industry perspective of providers, clearinghouses,
payers, vendors and other public and private organizations that partner
together to collaborate on industry issues. WEDI is names as an advisor to
Health and Human Services under the HIOPAA legislation and we take an objective
approach to resolving issues.

I did provide some background information in the written testimony, but I am
going to skip that because it really references WEDI’s involvement in the 2004
Medicare pilot. You heard about that in the X12 testimony this morning. But
more recently the WEDI attachment workgroup is focused on gathering industry
perspectives and developing comments in anticipation of this NCVHS testimony.

Although it was not an official policy advisory group, sop formal votes and
recommendations were not taken, but WEDI has actually nine findings I would
like to present to you right now. One of them is concerning the standard
transaction. WEDI agrees with the X12 recommendation to name to 277 health care
claim request for additional information, and the 275 additional information to
support health claim or encounter.

The version selection we felt may need some more industry comment due to
various business needs. As an example you heard Margaret talk about recent
changes and updates they made to the 6020 version to support the ESMD project.
So the choice of version would be up to probably X12 and the industry.

To be cost effective the exchange of clinical information should build on
the established electronic exchange of data between a provider and a payer. So
established trading partner agreements exist to manage the exchange of those
X12 transactions. We recognize that there are other methods to the enveloping
and transport for attachment information, but we believe that should be
identified as a trading partner option for now, and left for consideration for
future regulation, with the emergence, of course, of meaningful use health
records and the use of health information exchanges. Other options may prove
even more viable alternatives for transport.

WEDI also agrees with HL7’s recommendation to name the HL7 implementation
guide for CDA release 2, called the IHE Health Story Consolidation Guide. And
the HL7 supplement to the consolidated CDA template guide. Both of those guides
are Clinical Document Architecture release 2 standards, and to emphasize
together they give stakeholders guidance to implement attachments at various
levels of technical readiness. In other words, it gives them the ability to
understand how to implement unstructured and structured attachment types.

You might recognize that Daniel had a slide up there with the covers of both
of those things and he had a big plus sign in between. SO that was very good.

HL7, again you heard that the IHE Health Story Consolidation Guide, known
commonly as the Consolidated CVA Guide, was also named as a standard for
meaningful use 2. What this means that it is transparent for providers. SO when
they are sending a discharge summary document they can send the same document
either to another provider or to a payer.

WEDI also agrees with HL7’s use of LOINC to identify the type of attachment
document. LOINC should be referenced as an external code set to allow industry
to continue to name attachment types to meet their business needs. A good
example of that is the IAIABC, which is the International Association of
Industrial Accident Boards and Commissions. They recently are in the process of
defining nine new attachment types to meet the business needs of worker’s
compensation as to definition of attachments. You have heard it earlier in both
X12 and HL7 – we believe definition is a supplemental documentation to
support health care related events using standard formats.

Originally attachments were focused on supporting claim payment, but now
attachments should focus not so narrowly on claims but because they are the
same attachment types in the standards, they can also be used for other
functions in businesses such as you heard, prior authorizations, referrals,
post-payment, workers comp.

In speaking to other uses, WEDI believes that the attachment rule should be
limited to the claims. Though we recognize that they should be allowed to use
these same standards for other purposes, such as the authorizations and
post-paid audits, additionally, the attachment rule should be aligned with
other attachment standards being used such as meaningful use of electronic
health records, and HIEs.

The attachment rule may need to recognize the other X12 transactions that
are related to this. There is a 275, 278, for healthcare services review. There
was also concern about if we do include these other uses that we may be
broadening the scope of the implementation for these attachments too much.
Therefore, we see that maybe mandating these other uses further down the road.
WEDI is prepared to assist the industry with implementation of any mandated
attachment types.

Concerning the approach of solicited and unsolicited, the rule should
mandate solicited approach solicited model, but the unsolicited approach should
be implemented based on a trading partner agreements. Where trading partner
agreements will define the criteria for specific conditions, when the
attachment is needed.

Benefits can be realized by both parties by reducing the processing time for
the payment of the claim and the resources needed to respond to request of
transaction.

Rule types. WEDI believes that the attachment rule types should be published
as an NPRM. It has been eight years time span since the previous NPRM on
attachments, so the industry may need to have the opportunity to identify any
concerns or gain clarifications if they need to. We would be willing to conduct
a policy advisory group to gather industry input on the topic.

Speaking on education and outreach, WEDI looks forward to working with the
Department of Health and Human Services to promote education outreach to
facilitate industry implementation.

Lastly, you heard about transaction acknowledgements. WEDI supports the
acknowledgements to be named as a regulation, however the attachment rule
should not address the application acknowledgements, that you heard earlier.
SDOs are continuing to work on the acknowledgement solutions for the
combination of the X12, HL7 application level.

Now I am going to quickly, I wanted to address eight of your questions that
were proposed. Number one was talking about the current state of the exchange
of clinical information. As you heard, we believe that most of the industry is
still using paper and postage to send the attachment information. Few use some
electronic solutions and they are usually based on the NPRM from 2005. There
are some other initiatives going on, like the ESMD initiative as well, using
some other transport methods.

Number two, was a question about predicting the technical state of industry.
Here is where HL7 CDA Clinical Document Architecture is really designed to
allow for the industry to grow. HL7 provides for the unstructured document to
have a PDF or JPEG put in the exchange and be human readable. HL7 CDA structure
documents, can also be rendered as human readable, but also can be processed by
computer. This allows the industry to develop as the technology grows. HL7 CD
Standard is transport agnostic.

Number three, what is the role of the operating rules? We see that it can
provide the industry with guidance on enveloping and transport options, as you
have heard, and you are hearing it again a couple more time.

Number four was, what is the significant benefits that we should expect?
Both providers and payers will realize dollar savings by eliminating the
postage and handling. It also could prevent the loss of documents, better
control of PHI, and the request and response for a specified document types.

Number five, infrastructure, in 2016, with the development of electronic
health record technologies it is becoming more commonplace to be exchanging the
records through HIEs or even web portals.

Number six was talking about the most important parts of operating rules.
WEDI would be willing to conduct a PAC, Policy Advisory Group, to help address
this issue, as well, talking about what would be the best for operating rules.

Number seven, should it be only claim attachments or should there be other
types of attachments? Since the same attachment types are used not just for
claims but for all the other uses that were mentioned, post-pay, audits, it is
the same types of documents that are named in the consolidated CDA guide. It is
not inclusive of everything, they will be building more and creating more
attachment types, but for now from a WEDI survey that we did, those were the
top hitters 80/20 rule that brings most of them in. Those that were not there
could always utilize the unstructured CDA part.

Last one, number eight, what are the important businesses and technical
issues? Again, somebody said earlier, education, and we believe that is true.
Education will be a key part to prepare our stakeholders.

So in conclusion, WEDI supports the need to assure attachments standards and
associated operating rules are implemented in a timely and effective manner, to
enhance the use of EDI in healthcare. While the use of electronic attachments
would be beneficial, it is important to consider the return on investment and
to devise a process that minimizing cost and maximizes benefits.

The process must add value, be easy to understand, and easy to follow. It
must consider not just the impact of providers and health plans, but the cost
to trading partners and software vendors. We want to emphasize the need for all
entities to work together in close collaboration to avoid conflicts and ensure
successful implementations and more industry consistency both now and in future
implementations.

Moving forward, the industry should carefully consider how best to ensure at
the initiative process between operating rules and standards, provides the most
ROI, and the industry structures speak to the evolving landscape.

WEDI, in its advisory role, offers our support to NCVHS and HHS in helping
to achieve these goals and stand ready to assist as needed.

Members of the subcommittee, thank you for the opportunity to testify. That
concludes my remarks.

DR. SUAREZ: Thank you so much, Durwin. We are going to go to our last
testimony from MEAN/NEA.

Agenda Item: Vendor

MS. BENTON: Thank you. We appreciate the invitation to participate in this
dialogue today. I am Lindy Benton, by way of introduction, the CEO for MEA/NEA,
that used to, two years ago, stood for Medical and Electronic Attachments. We
have not gone through the rebranding process, but we have dropped the tagline
of attachments because there is a much broader definition of what we send and
what we do today.

We recognize this issue is another in a long list of challenges, to address
in this larger context of developing and transitioning to a more connected and
effective industry. Our goal in presenting today is to provide a high level
perspective as experienced industry leader, who is active in the field of ideas
in attempting to drive meaningful and valuable change in the area of clinical
information exchange.

This is going to be an overview. We provided details in your package. You
can read through the questions. We have also provided a study that we
commissioned that just looked at a 500-bed community hospital, that is when we
realized the problem when far beyond attachments for these community hospital
struggling to rid themselves of the paper communication process.

Our company has been processing claims attachments and documents for over 16
years in the industry. We have an information exchange engine. We store over
100 million documents and images currently today. We exchange more than 2
– and actually that has gone up to almost 2.5 million per month, over 500
health and dental plan and payers, and 50,000 providers. We have been doing
this for a very long time and we have been doing it successfully. To your
point, we have had no security breaches and no lost documents in that entire 16
years.

Managed Care organizations and vendors to those organizations, use the
MEA/NEA information exchange engine to help address logistical challenges of
medical record requests, reviews for risk adjustment, quality measures, medical
management and payment integrity processes, including claims attachments, as
well as credentialing and other provider communication exchanges.

As we consider the objective of developing operating guidelines to ensure
the effective exchange of clinical information we found that there are three
areas of significance. One is the current state of the clinical information
exchange. The second being the formats and use cases, and the third being the
significance and attainable benefits of comprehensive exchange.

The first challenge facing us as we pursue the definition of standards and
operating rules, is that the managed care industry does not generally exchange
clinical information electronically today. While significant strides are being
made in the adoption and meaningful use of electronic health records, the
industry is not generally advancing towards sharing clinical information, such
as needed between the point of care and the managed care organizations who are
responsible for payment and outcomes, measures, resulting in disintegrative
processes and systems today.

Standards and operating rules can help provide guidance, but the different
systems and nomenclature predominant among the stakeholder groups, will hinder
our connectivity.

Another industry challenge for lack of connectivity, is that many manage
care business processes, like risk adjustment and quality measures, for
example, require the exchange of clinical information which no standards or
operating rules exist. Our experience is that more than 95 percent of these
exchanges are accomplished at least in part, by mail, fax, and on-site
extractions.

The electronic exchanges that do exist often occur in one-off custom file
exchanges between managed care organizations and there BPL vendors for services
such as lab, dental, pharmacy and behavioral health.

The primary reason that our company exists today is to solve for the current
state of obstacles that faces industry today. Our company has developed a
simple technology agnostic end to end electronic solution for the exchange of
secure clinical information that is time tested over 16 years, and produces the
desired savings and efficiencies. The potential for savings notwithstanding the
current complexities of data collection produced missed opportunities for
medical management, which potentially affects our care outcomes.

In a study we commission in 2012, the extent of efficiencies found and
inefficiencies found, just the claims denial process, confirmed that despite
all of the efforts underway to optimize the electronic medical records,
back-office processes remain heavily manual and inefficient.

For example, greater than 90 percent of the processes involved in addressing
denials are paper based, fax, and mail supported steps which require human and
time intervention. Thirteen percent or an estimated 185 million of annual
revenue for this mid-sized community hospital, is tied up in a complex manual
and often unsuccessful claims denial management process.

Due to the high resource requirements of the status quo managed care
organizations must make choices as to how much clinical information can be
reviewed. There is simply not enough capacity to review all the medical records
to identify medical risk. Even if the capacity were to exist, the time and cost
to accomplish these would be prohibitive.

CMS, STARS, and bonuses, and optimized risk adjusted capitation, are two
examples that depend on efficient and effective clinical information between
stakeholders.

Now that we have explored the challenges we face due to the lack of
meaningful clinical information exchange, I want to defer to my colleague, Mr.
Don Gerdts, who not only has extensive experience in the managed care industry,
but Don has worked with MEA/NEA on developing our methodology over the last
couple of years in secure information exchange.

MR. GERDTS: First I just want to recognize that the work of the committee is
hard work but certainly important, and we think the benefits will pay off. To
Lindy’s comments in context of the discussion already, we really work in the
migration path that Lin talked about earlier, as we move from current state to
the idea of structured clinical data exchange. The solutions that we provide
are in the middle and do represent that migration path.

As much as been addressed already, we believe that the definition of claim
attachments when applied to standards and operating rules, should be much
broader than just claim attachments. They are one practical piece of needed
information sharing, but broader medical record information requested by
broader medical needs, drive higher value processes, as we have discussed, like
medical management, risk adjustment, quality measurement and payment integrity.

In the millions of transactions that we process, we see nearly as much
volume of longitudinal medical record information requested by payers from
providers, as we do claim attachments. So to omit these use cases from
consideration we believe would be to solve only part of the problem.

In addition to broadening the definition of attachments, I would like to
suggest that unstructured human readable documentation is necessary as we
transition to comprehensive exchange of structured clinical data. Which is a
desirable idea that we fully support.

Human readable medical documentation will continue to be exchanged for the
foreseeable future, even with the advent of standards and operating rules for
structured data. This is true both for the request of the information in
addition to the attachment response.

MEA/NEA connects hundreds of trading partners to exchange the types of
information that we are discussing today. Just to give you a status of where
things are in our connections, many of those trading partners do have plans to
adopt standard transactions, but only one uses X12 transactions for clinical
documentation requests and responses, and none yet exchanges HL7 clinical
document architecture for attachments. Instead, all of our trading partners
exchange electronic requests and responses with human-readable documents
indexed with structured meta data similar to the XDR specifications that ESMD
uses.

Approximately 40 percent of our clinical information exchange occurs via PDF
documents, with the other 60 percent being TIF and JPEG payloads.

As one of the highest volume health information handlers for CMS’s success
from growing ESMD project, we would also like to highlight that PDF is the
document exchange standard for the millions of pages of documentation exchanged
between providers and review contractors through the Connect gateway.

With a broad definition of formats and use cases in mind, I would like to
take a moment to highlight the significant and specific economic, quality and
efficiency benefits that can be realized by advancing comprehensive clinical
information exchange.

Electronic exchange of medical documentation measurably reduces hard costs
associated with the request and collection of the information. Using current
predominant methods of request, collection and processing, the average cost of
medical record extraction is approximately $30 per chart, and the cost of claim
attachments nears – depending on which study you look at — $4 to $5 per
attachment.

Transitioning from current methods to electronic requests, acquisition and
response to the clinical documentation can remove $4 to $7 per transaction of
the administrative healthcare costs. Given the hundreds of millions of claim
attachment transactions and tens of millions of medical record review, for all
of the purposes that we have discussed, the economic impact is significant and
measureable.

As you know, managed care organizations employ a number of strategies to
address the health care needs of their covered members, including case
management, disease state management, and also quality measurement. The last of
these strategies highlights a need within the industry for better information
to reflect the actual effectiveness of care delivery. Years of producing HEDIS
measures, for example, show that deficiencies in care quality are often a
deficiency in accessible and complete clinical information, and not actually an
issue of the effectiveness of the care delivery.

In addition to the financial efficiencies our experience in a number of use
cases of clinical information exchange shows that significant improvements are
achievable in time and human resource efficiency. One example is the use case
of electronic exchange for payment integrity purposes. The drive-by CMS and
commercial payers both, to insure payment accuracy and appropriateness, leaves
providers to deal with time sensitive audit demands, often 30 to 45 days
turnaround, where the mandate is to respond effectively or lose revenue.

Since 2010 CMS has recovered over $3 billion in overpayments through the RAC
program, with approximately $2.2 billion of that coming in just 2012. We
believe that the acceleration will continue driving even more need for us to
end the paper chase.

The growing adoption by providers and vendors of RES MD services and similar
interest shown by commercials plans and vendors, supports this premise. Even
without mandates providers are using and paying for these services because they
help to achieve improvements in the efficiency and effectiveness of their audit
response efforts.

So as we consider the objective of developing operating guidelines to insure
the effective exchange of clinical information, we explored the challenges and
the current state of clinical information exchange, proposed additional formats
and use cases for exchange, and highlighted the significant and obtainable
benefits of comprehensive exchange.

Claim attachments are just one of several business process use cases that
exist in parallel and we believe that each one can and should be addressed at
the same time. As such, we encourage abroad definition and context for
attachment standards and operating rules. We sincerely believe that the
opportunity lies in front of us to make more incremental improvement to the
state of connectivity and information portability in the United States health
care enterprise.

I would like to thank the committee again for inviting us to present on this
important topic. As Lindy mentioned, for your information we provided each of
you with a supplemental document – it looks like this. I hope everyone got
one. It contains not only our remarks, but answers to your technical questions
and a copy of the case study that Lindy mentioned early in her remarks. Thank
you.

Agenda Item: Questions from Sub-Committee

DR. SUAREZ: Thank you very much for that statement. So we are now ready for
questions from the committee. I see Larry’s card up.

DR. GREEN: My question is to George and the Hospital Association statement,
paragraph three in your written testimony, about half way through it. I just
want you to contextualize the sentence. I want to make sure we really
understand what the Hospital Association’s position is. That sentence that the
standard should never be used as a mechanism that seeks to build a data base or
for the receiver to conduct data research. Do you really mean that?

MR. ARGES: I mean it from a claim processing perspective. There are
different roles that different organizations play obviously. Public health
obviously may6 need attachment information for their purposes, for building a
database. But the claims data, we believe, is something that identifies the
core variables that should be used to basically process the claim. If there is
some ambiguity about a test result or whatever, you should be able to look at
it and say, okay, it met the end, I will process the claim. But you shouldn’t
be building a database of the lab results for a patient who has their HDL or
LDL levels composed based on age or sex or whatever. That, to me, is a
different purpose, and I am not sure that should be the role of a health plan,
to be doing that.

DR. GREEN: So the answer is yes. You actually do mean that.

MR. ARGES: Yes.

DR. CHANDERRAJ: Can I add to that? I don’t remember which study – I am
getting old and I can’t remember a lot of things, but I think there was a study
showing the data that has accumulated from the EHR cannot be used to justify
any kind of medical research because most of the providers are gaming the
system. The data that is entered there is always either not appropriate and it
has to be re-entered by another researcher. So what they7 are saying is you
cannot do adequate research analysis by7 this kind of data, unless the process
of standardization has taken place – which may be years from now.

DR. SUAREZ: Mike, then Bruce.

DR. FITZMAURICE: This is for Mari Savickis. You note – the slide is not
numbered – that the current prior authorization is manual, time expensive,
very costly for payers. I had two daughters who worked in a physician’s office
and one of the things that drove them crazy was calling up the payer and
saying, under what conditions can my doctor give this particular drug?

Is there a list of prior authorization requirements available from each
payer that physicians could access ahead of time and know the rules for what is
covered and what is not? Does such a list not exist? You have to do trial and
error?

MS. SAVICKIS: The lists exist. I don’t know if the providers, or in that
case the physicians, always have access to them. I probably have to get back to
you for a more complete answer. I think the answer is broadly they probably
have some ideas what the parameters are, but the reality is they don’t always
know what the specifics are. What is the basis of your question? I feel like
you are getting to something.

DR. FITZMAURICE: After I come back from an NCVHS meeting and they tell me
this I start smiling. They don’t like the smile because it is a lot of hard
work for them. It is a big problem in the physician’s office.

MS. SAVICKIS: It is not like they have it there at their fingertips.

DR. FITZMAURICE: It’s not like you can query and get it back without a phone
call.

MS. SAVICKIS: No. In fact there are some ways that we have been trying to
explore. We haven’t gotten too far down this road. There is a flag – well,
the 278 is already standard and you can use that for prior authorization. I
think with more robustness around 5010 you can use these in a better manner,
although I don’t know that the industry necessarily has that. As I understand
it there is a flag in the 270-271. I am going off memory right now. Nancy is
shaking her head like you would think I would know this bible and verse after
all the time I spent on it. But it is a way for the physician provider to ask
whether or not prior authorization is needed. You could query the payer saying
is it needed? So the flag is turned on. Then the yes or no comes back and I
guess there is also a U or M for undecided, maybe. So you could kind of like do
a preemptive strike and say, like, is it needed? Ah, yes, it is. Then you could
use the 278, the 278 is not quite robust enough, so then you would use the 275,
which isn’t an adopted standard.

So there is a way to do this now. It just isn’t being done. Do they just
have this vision in the top of their head when they are not using the X12
standards? I think it depends on the provider, and probably, no, not always.

MR. FITZMAURICE: So it is like playing the game of Battleship before we had
sonar.

MS. SAVICKIS: It is. Hello, is prior authorization needed? Oh, it is, okay,
and start fax.

DR. CHANDERRAJ: Michael, can I respond to that?

DR. SUAREZ: You want to follow up on this, Raj. Go ahead.

DR. CHANDERRAJ: There are formulas from each insurer that tells you what
drugs you can use and what you cannot use but each company has so many formulas
that no physician can keep track of this formulas. I think most of the time the
database that you are using for ER prescription would kind of give you that but
many physicians don’t use that filter.

MS. SAVICKIS: Drugs are just one thing, too, there is prior authorization
for any number of products. That is why Melanie’s invention is that – it
works well for when you have got a discreet item and they are not even there
with a clinical template. She is trying to get – I don’t want to speak for
CMS – and she can correct me if I am wrong, but they are trying to get to
a standard clinical template. But that would just be used specifically for
Medicare, specifically for the power mobility device. That question that is not
going to be relevant for any number of any other services that a doctor is
trying to provide so those forms or checklist or whatever they are, vary by
payer. Right?

I think Lynn wants to weigh in on this.

MS. GILBERTSON: This is Lynn Gilbertson with NCPDP. While the system is not
complete and there are still gaps, the industry is working on the prescribing
system can perform the X12 270-271, which is the eligibility request, and
obtain information back about the formularies that this patient is under. Which
as you recall the committee recommended the Scripps Standards used for the
prescribing functions, the X12 270-271 for the eligibility function, and then
the Formulary and Benefit Standard, which is sent down to the vendor systems to
allow them to hit based on the pointers they get back and the eligibility that
say what is the formulary identifiers for this patient. They can dig down into
the benefit information for the patient.

It is not drug and patient specific at this point, it is way too much data,
but it gets the foundations. Then you follow up now with in this case, the new
e-prescribing prior auth transactions I mentioned, that allow you to say is
this drug requiring a PA real time, and if so, send me what the parameters are
for the PA determination. How do I fulfill the PA?

DR. SUAREZ: We are going to just to two more quick questions. Bruce and then
Lynda, and Marjorie you will have the last word.

DR. COHEN: So I just needed to follow up with George to clarify what he said
to Larry so I understand. Is it your position that the attachments that are
used to adjudicate claims should not be used for research or that the
underlying claims themselves should not be used for research?

MR. ARGES: The claim attachment should not be used as just a mechanism to do
research that has not been agreed to by the provider. It is not to say a health
plan who uses claims data and abstracts it, and organizes it, and publishes it,
that is one thing. There are other mechanisms, there are cancer registries,
there are other methods by which specific focus is done and you look at data
that is separate and apart from the claim.

But I don’t want somebody just to arbitrarily come in and say I want to do a
specific research and I am asking for all these pieces of information because I
just want to do this research. There is a cost to me for having to provide that
information and unless it somehow impacts the claim, I don’t see the need for
me to necessarily provide that unless somehow I have agreed to do so ahead of
time.

DR. COHEN: So administrative databases that emerge based on the electronic
health records, which is where claims are generated from, should not be used
for research or are they appropriate for approved research?

MR. ARGES: You are adding another element here. You are basically saying can
you use the electronic health record to basically conduct research. Obviously
you go to the electronic health record to basically pull information out. You
use it as part of the claim. The claim has a well defined set of criteria in
terms of what you report, what should be necessary to adjudicate that claim.

You have a specific business purpose and that is to basically review that
claim information and process it. But you are not there to basically conduct
separate research for just adjudicating that claim. If your role is to
adjudicate a claim that is what you need to do.

DR. SUAREZ: I think this gets o the heart of the question of what is the
primary purpose and then what might be secondary uses of data. Today we collect
claims because payers require providers the same thing. Then the payers take
the claim, processes that, and pays the claim. But then they also use the
claims data for their internal quality analysis and other purposes, as well as
there is collection of claims for other purposes – claims that have been
already processed.

We will get to the discussion, I think, during the afternoon on the purpose
for which the claim attachment should be requested and those kinds of issues.
That is part of the question that you are asking.

DR. COHEN: I guess I know many states now are beginning to develop in the
federal government all payer claims databases that are essentially focused on
aggregating claims from commercial insurers to use for a variety of purposes,
including research. You see that as legitimate use of claims?

MR. ARGES: Sure. As chair of the National Uniform Billing Committee, get
request from Public Health to add data elements that aren’t necessarily always
part of the claim. We do that on occasion so you have to make the case, but we
need to understand it ahead of time so that weigh the balance in terms of the
cost in collecting it, reporting it, and the benefit derived from it. But it is
not just to be used as an arbitrary means of I want to independently conduct a
piece of research.

DR. SUAREZ: Linda.

MS. KLOSS: Thank you all and thank you for your references to both criteria
for determining how we move forward and measures, and for the data you gave us
on cost. My question is does anyone have, does industry have any information on
what the savings might be if we moved from our current largely paper world to
the step one of having the baseline be electronic bare bones, as it was
described for us before? What is the opportunity?

MR. GERDTS: As I indicated in my remarks, our estimate is $4 to $7 per
transaction can be removed from the system. Based on, we will just term it
hundreds of millions of claim attachment transactions and tens of millions of
medical record reviews for a lot of the purposes that we discussed, one can do
the math to see that. Compared to a sixth of the nation’s economy that is not a
large number but it is a lot of money.

MS. KLOSS: Even for that first step, moving from paper fax world –

MR. GERDTS: Those are the savings that we see.

MS. SAVICKIS: While I have a bad memory too, I call it having a junior
moment, while I would like to say that this is maybe a big dollar figure in
D.C., these days, what is another $728 million, but that is the figure we have
that would save –

DR. SUAREZ: What was the figure?

MS. SAVICKIS: The burdensome and despair prior authorization policies are
estimated to cost $728 million in unnecessary administrative cost to the
healthcare system in 2012. That is our figure. If you need more wrap-up –

MS. KLOSS: That is prior authorization.

MS. SAVICKIS: That is prior authorization. We may have more disaggregated
data, I would have to go back and check.

DR. SUAREZ: Anyone else? All right, Marjorie

MS. GREENBERG: I want to join the committee memes in thanking everybody.
This has been a really long but fascinating morning. I don’t know if you
consider two o’clock in the afternoon still the morning, but we will. I now I
am just standing between you and lunch.

In defense of George and he doesn’t need me to defend him, but I will say as
the chair, and he referred to this, the National Uniform Billing Committee, he
has definitely been supportive of uses of let’s say the transaction — let’s
not call it the claim so much – ’04, and going back before then to the
UB92. I’ve been involved in all those years – for research purposes,
whether it be injury control – for reporting purposes, let’s put it that
way. Not just claiming, but reporting to public health and states and, you
know, supporting the hospital discharge data bases, and now we are moving more,
as you said, Bruce, towards the all-payer claims databases and so on.

I think maybe what people heard was you shouldn’t use the claim or the claim
information for research, and of course that is not what you said. Medicare
data has proven to be probably our best source of research data on health care
utilization, et cetera. And even quality for Medicare beneficiaries for all
these years.

I think the problem is, you know, we have a vision and I think the committee
supports this vision. It is one of its three main themes, since last August, of
convergence. I heard a really eloquent, I thought, in the previous panel,
argument for convergence and that we need to get away from the siloed thinking.
WE have this data to pay the claims, this data to do this, this data for risk
management – and try towards this convergence.

At the same time we have the reality, whereas I was hearing that still,
other than the claim, most data, other information, is being exchanged by paper
or unstructured electronic exchange. Then I heard what we heard so much at the
stakeholder meeting in the roundtable in December, that we really need a
roadmap. Given that we have this vision, which I am assuming most people
subscribe to, even the American Hospital Association, of collect once, use
multiple times.

Yet we have this reality of being very far from that. So it is getting from
here to there, because even tough accountable care organizations are the
vision, and we hear that they are growing, there is still a lot of fee for
service out there and there is still a lot of exchanging of information in
paper.

So what I heard is that some of the provider organizations at least feel
– I heard some people saying let’s make this very broad, but this roadmap
can’t start with just the broad. You have to start with where really people are
having to exchange information for adjudicating claims. This is going on right
now. And it is not going to end next week or next month.

So we want to take that need, and maybe that is a more narrow need – I
heard that as your position, but I won’t try to speak for you – and then
see how we can get from there to this much broader vision of exchanging
information that is needed to improve our health care system. I think it is a
series of steps that really have to be thought through. We have got to quit
talking roadmap and we relay have to start working roadmap.

Although we may have felt certain things, particularly with the last panel
and this panel, are inconsistent, I don’t actually think they are. I think it
is a question of staging. I think it is a question of facing the reality today
of trying to do some things that will cut costs in a efficient way, but moving
hopefully towards that convergence vision.

That is just my little summary of what I heard.

DR. SUAREZ: I want to say that is a perfect segue for lunch, but what I
would say that that was a perfect segue for what happens after lunch, which is
going to be this discussion. I think you framed a lot of the key elements very
nicely. I have been taking notes as you were highlighting some of those things.
SO I think a lot of the elements you described are relay critical of what we
need to talk about after lunch.

Again, on behalf of the subcommittee, and you heard it several times, thank
you so much for preparing this incredible testimony. Everybody was just
incredible in terms of the content that showed where we are today and what are
your recommendations with respect to this important issue.

We are going to take a full hour for lunch and we will be coming back and we
will have a good two hours of discussion for the subcommittee. You are all
welcome to stay in the afternoon, and as we have the discussion we will
certainly be inviting you all to participate. Thank you.

(Whereupon, the hearing adjourned.)