[This Transcript is Unedited]

DEPARTMENT OF HEALTH AND HUMAN SERVICES

NATIONAL COMMITTEE ON VITAL AND HEALTH STATISTICS

SUBCOMMITTEE ON STANDARDS AND SECURITY

January 13, 2005

Hubert H. Humphrey Building
200 Independence Avenue, SW
Washington, D.C.

Proceedings by:
CASET Associates, Ltd.
10201 Lee Highway
Fairfax, Virginia 22030
(703)352-0091

TABLE OF CONTENTS

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

Agenda Item: Call to Order

Welcome and Introductions

DR. COHN: Good morning. I want to call this meeting to order.

This is the first day of two days of hearings of the Subcommittee on
Standards and Security of the National Committee on Vital and Health
Statistics. The committee is the main public advisory committee to the U.S.
Department of Health and Human Services on National Health Information Policy.

I am Simon Cohn, Chairman of the Subcommittee and the Associate Executive
Director for Health Information Policy for Kaiser Permanente.

I want to welcome fellow subcommittee members, HHS staff and others here in
person, and I do want to, as always, welcome those listening in on the
internet.

I obviously want to remind everyone today – and will, I’m sure, remind
everybody a number of times – to speak clearly and into the microphone, and we
have had a long history of these microphones being little finicky. So I just
warn our presenters.

Obviously, there is a lot of work over the next two days.

Today, the subcommittee continues our hearings on e-prescribing standards.

There is actually going to be a little bit of change in the agenda in the
sense that we are flipping the first two presentations. Our first presentation
today will be from the Drug Enforcement Administration, and then, from there,
we are going back and having a CMS update on e-prescribing.

Then from there we move into an overview of the DEA/VA pilot this morning.

After lunch we are going to be hearing from a number of representatives
from the industry, and then, after the afternoon break, we’ll be hearing from
NIST about their framework and standards as well as ASTM and their standards
work.

Now, at the end of the day, we are going to be having open microphone and
then going to subcommittee discussions.

As always, I want to emphasize that this is an open session. Those in
attendance are welcome to make brief remarks if you have information pertinent
to the subject being discussed.

We will also have time at the end of the afternoon for brief comments by
those in attendance.

Finally, for those on the internet, we do welcome emails and letters on any
of these issues coming before us either today or tomorrow.

Now, just to remind you, tomorrow, we do start at 9:00 a.m. We’ll be
talking primarily about HIPAA. We are starting out with, I think, a briefing
from the work group on Electronic Data Interchange and then moving from there
to an update from the NUCC and the NUBC.

We will also be discussing plans for the next hearings in February and
other issues that need to come before us in 2005.

Now, with that, let’s have introductions around the table and around the
room, and for those on the National Committee, I would ask if you have any
conflicts of interest related to any of the issues coming before us today would
you please so publicly indicate during your introduction?

Maria.

MS. FRIEDMAN: Thank you, Simon.

I am Maria Friedman from the Centers for Medicare and Medicaid Services,
and I am the lead staff to the subcommittee.

DR. WARREN: I’m Judith Warren from the University of Kansas School of
Nursing, a member of the committee, and I don’t have any conflicts that I am
aware of.

MR. REYNOLDS: Harry Reynolds, Blue Cross and Blue Shield of North Carolina,
a member of the committee and no conflicts.

MS. TRUDEL: Karen Trudel, Centers for Medicare and Medicaid Services, staff
to the subcommittee.

MS. BEBEE: Suzie Bebee, ASPE, staff to the subcommittee.

MS. AMATAYAKUL: Margret Amatayakul, contractor to the subcommittee.

MR. MAPES: Mike Mapes with Drug Enforcement Administration.

DR. LEVIN: Randy Levin, Food and Drug Administration, liaison to the
subcommittee.

DR. FERRER: Jorge Ferrer Veterans Health Administration, staff to the
subcommittee.

DR. HUFF: Stan Huff with the University of Utah and Intermountain Health
Care in Salt Lake City, a member of the committee and of the subcommittee, and
I don’t think I have any conflicts with anything that we are testifying about
today.

DR. STEINDEL: Steve Steindel, Centers for Disease Control and Prevention,
staff to the subcommittee and liaison to the full committee.

MR. BLAIR: Jeff Blair, Vice President, Medical Records Institute.

Related to any discussions on ASTM, I would be recusing myself from voting.

MS. FERIDA: Michelle Ferida(?), Drug Enforcement Administration.

MR. BRUCK: Steve Bruck(?), PEC Solutions, supporting DEA.

MR. POLLARD: Michael Pollard(?), Medco Health Solutions.

MR. SIMKO: Mike Simko, Walgreens.

MS. GILBERTSON: Lynne Gilbertson, National Council for Prescription Drug
Programs.

MR. RATHER: Phil Rather – Express Groups.

MR. DE CARLO: Michael DeCarlo, Blue Cross, Blue Shield Association.

MR. GUINAN: Jack Guinan, ProxyMed.

MR. LEVINE: Gary Levine, Senior Director of Electronic Prescribing for
Mental Health Solutions.

MS. HOFFMAN: Ruth Hoffman with Pharma.

MR. NEWMAN: Mike Newman(?), Health Resources and Services Administration.

DR. ZUCKERMAN: Alan Zuckerman, American Academy of Pediatrics,
representative to ASTM. I teach and practice at Georgetown University, School
of Medicine.

MR. WOODIMORE: Ken Woodimore(?), SureScripts.

MS. AGNASTIADES: Alania Agnastiades(?), National Association of Boards of
Pharmacy.

MS. WILLIAMSON: Michelle Williamson, National Center for Health Statistics,
CDC.

MS. FORD: Cheryl Ford, Centers for Medicare, Medicaid Services.

MS. HOWARD: Cynthia Howard, Centers for Medicare and Medicaid Services.

MR. NIAK: Rohick Niak(?), Vice President, MedPlus.

DR. COHN: Okay. Well, I want to welcome everyone.

Now, before we start our first briefing, I actually do want to just take a
moment and thank Jeff Blair, our Vice Chair, for his work sort of moving this
agenda forward, and, obviously, also Maria for tremendous efforts in terms of
putting together these and other hearings on this topic. So thank you both.

Jeff, do you have any comments to make before we launch into the first
session today?

MR. BLAIR: No, just wanted to thank our testifiers for being here, that’s
all.

DR. COHN: Yes. Yes.

Agenda Item: EPCS Program Update

DR. COHN: And I think we’ll turn to our first briefing.

Want to thank you, obviously, for your flexibility in allowing us to sort
of switch you around from second to first on today’s agenda, so thank you.

MR. MAPES: Okay. You’re welcome.

Good morning, ladies and gentlemen. Thank you for giving us the opportunity
to meet and discuss this issue that is of importance to all of us this morning.

I’m Mike Mapes. I’m the Chief of the E-Commerce Section for the Drug
Enforcement Administration, Office of Diversion Control, and we are going to
talk about where we are with what we call EPCS, our Electronic Prescriptions
for Controlled Substances Program.

As probably everybody understands, the Drug Enforcement Administration
deals just with controlled substances, and controlled substances are a small
part of the overall pharmaceutical drugs that are handled in pharmacies, maybe
5-10 percent, depending on the practice setting.

Our controlled substances, as you’ll see in the program, are divided in
five schedules, Schedules I through V.

Schedule I, obviously, those are the drugs that do not have a legitimate
medical need or use in the United States. So you won’t be seeing those in the
prescription world. Those are mostly in the research world.

But then Schedule II through V are the other controlled substances that are
handled by pharmacies and prescribed by the practitioners, with Schedule II
being those that have the highest potential for abuse and still have an
accepted medical use in the United States.

But our concern is the abuse of those drugs, and there’s a serious abuse
problem for a lot of the drugs, including the Schedule II’s, and one of the big
parts of DEA is making sure that we have a sufficient supply of those drugs
available for legitimate medical purposes while not having enough around so
they can be diverted and abused, rather than used for the intended purposes.

So, in order to help us with that, the Controlled Substances Act, the CSA,
mandates that DEA control the registration of anyone who handles controlled
substances. So whether it be a pharmacy, a doctor, a manufacturer, an importer,
exporter, any of those kind of folks, they are registered with DEA, and the
dispensing of the controlled substances, to be sure that they are done using a
legitimate medical purpose and using established standards, and that if it is
by prescription, it has to be signed by the prescriber.

DEA legal authority comes from the Controlled Substances Act, and then we
have other considerations, the Government Paperwork Elimination Act, and we
looked at our – when we looked at GPEA, we looked at that our current
requirements are that Schedule II’s must be written, with very few exceptions.
Schedule III, IV and V can be either written or oral.

And then the other project that we have that is related to this is a
project that we call CSOS, and that deals with the orders that retail
pharmacies place with their distributors or the distributors with the
manufacturers.

For Schedule II’s, right now, they use a DEA-issued paper form and that is
a project, the CSOS project, that is very similar to the EPCS in that that will
be a PKI project, and that is further along, and we have gone through the
rule-making process, and we are getting ready to have that one out in final
form in the near future and we’ll be starting that. So you’ll probably be
hearing a little bit about that at the same time, and we use the same
infrastructure for both projects.

CSOS and EPCS allow the registrants to satisfy the prescription – or the
order requirements, in the case of CSOS – electronically, rather than sending
paper back and forth, and allow DEA a means to enforce the requirements that we
have for control over the controlled substances.

All of these projects that we have are funded through a fund called the
Diversion-Control Fee Account. The Diversion-Control Fee Account is the funds
that doctors, pharmacies, hospitals, everyone pay for the registration with
DEA. So the funds that people pay to be registered with DEA is what is paying
for these projects.

When we looked at the requirements for electronic signature in the very
beginning, trying to determine what our requirements were, we had to look at
legal sufficiency. We had to look and see if the signature that would be used
would be sufficient, if the person writing the prescription, signing the order
for drugs was charged in an administrative setting, a civil setting or there
was a criminal prosecution of that person, and so we are always concerned to be
sure that the signature is sufficient legally, if we get into that kind of a
situation, and that there is authentication and a non-repudiation integrity of
the information that is used, it is accountable and it is a really strong
record of the transaction that we can go back to later.

With respect to the responsibilities of the pharmacy, DEA registrants face
significant liability associated with their responsibility to validate the
authentity(?) of a controlled-substance prescription or a supply-chain order,
and companies can face fines and be criminally prosecuted if it was done
intentionally. These relying parties currently are not well equipped to
validate the integrity nor the authentity of the transactions because they are
using paper-based systems.

DEA’s EPCS program will provide registrants with the information they need
to make accurate decisions regarding the authorization and status of the
practitioner – by status, we mean, do they have a DEA registration that is in
the appropriate schedules for the drug that is being prescribed – and the
integrity of the electronically-transmitted controlled-substance prescription.
So that information will be provided to the pharmacist to help them make their
decision.

When we look at the number of individuals that could be involved in either
of these projects, the Electronic Prescriptions for Controlled Substances,
there’s about one million DEA-registered practitioners, people authorized to
prescribe controlled substances, that is the range, from the traditional doctor
to physician’s assistants, nurse practitioners, those kind of folks, if they
have prescriptive authority in the state that they are from, and they prescribe
about 600 million controlled-substance prescriptions in a year.

The other project, the Controlled Substance Ordering System, there’s about
200,000 people who may have a digital certificate for that and there might be
about seven million transactions that they do in a year.

We are not mandating, in either case, that people adopt the electronic
system. We are offering it as an alternative. So they can still use a
paper-based system, if that is their desire.

DEA is working with GSA to design EPCS, so certificates used by DEA for the
controlled-substance prescriptions could be used for other government
transactions, at the discretion of the registrant. This could be relevant to
administrative transactions as well as Homeland Security-related systems.

To enable this, DEA plans to cross certify with the Federal Bridge
Certificate Authority. This cross certification would be performed in one
direction, thereby allowing other federal agencies to trust DEA certificates
for their transactions, but preventing other certificates from being used for
prescriptions, and the reason that we have done that, generally, is that our
certificates will provide identity as everybody’s digital certificates do, but
they’ll also provide the credentialing part of their DEA registration, and
other folks don’t have that in their certificates.

We have coordinated with many different government agencies at many levels
in many meetings and discussed these issues related to both the prescription
and the electronic orders.

With NIST, we have discussed the certificate policy and the profile,
revised architecture and discussed with them revisions to the architecture. We
have talked with the folks about FIPS and how that plays into the system.

With GSA, with the FICC and Initial Mapping to the Federal Bridge
Certificate Authority and the E–Authentication.

We have discussed, briefly, with the Department of Veterans Affairs, and
they have a – using their system, VISTA, to PK-enable it so that they can use
this.

We have discussed with SSA, very briefly, about using this to make
suitability determinations, and we have talked with HHS, the CMS folks, made a
presentation with them about where we were and where we are going and what we
are doing with the system, so that we have been trying to get everybody’s input
and take that into consideration.

We have coordinated with a number of associations and industry groups.

We have been actively piloting the EPCS program.

The VA is currently piloting digitally-signed e-prescriptions at the Hines
Illinois Medical Center. DEA operates a test system in support of the
registrants who are participating in the pilot system, the other CSOS pilot,
with HDMA and NACDS.

The success of our strategy of coordinating with, discussing with everyone
that we can these – our proposed systems has been demonstrated by the fact that
numerous EDI and EDI vendors have invested to develop DEA-compliant commercial,
off-the-shelf products, and in our supply-chain project, the CSOS project that
is coming up to start use in the next few months, there are several COTS
products that have been developed that are compliant with our requirements.

Our experience with CSOS with applying EDI and EDI 850 has been positive
and leads us to believe that the solutions to PKI-enabled prescriptions should
be within the reach of the PKI system also.

After five years of working with the industry, DEA is ready to bring in a
production in the supply-chain program that has been sought after by the
industry for a long time, and we’ll be using that same approach working with
the industry to come up with final rules in the ECPS project.

I would like to talk just a couple of minutes about the EPCS performance
standards. These are the four critical factors, the authentication, the
interoperability, the scalability and the control of the system, and it is our
belief that the integrity and non-repudiation cannot be accomplished without
digital-signature technology, and regardless whether the system is closed or
open, this technology will allow it to meet DEA’s law-enforcement requirements
and dealing with controlled-substance prescriptions.

In June of 2003, DEA issued an EPCS Request for Information, RFI, to
solicit input from the industry. The purpose of the RFI was to obtain industry
input regarding the best model for DEA’s PKI, whether that be a hierarchical or
a bridge PKI.

DEA received 10 responses to their RFI from a number of PKI and healthcare
technology companies, and based on that input and a consultation with staff
from GSA and NIST, DEA adjusted its course and it is now working to establish a
more flexible federated model based on – certification and PKI bridging. This
approach was selected to enable DEA to out source certificate management
responsibilities to the effective industry. In effect, DEA will approve
industry CA’s that meet DEA and federal requirements to issue certificates to
the over one million DEA registered practitioners.

DEA has worked closely with the U.S. Federal Identity Credentialing
Committee and the National Institutes of Standards and Technology to ensure
that the federated approach leveraged industry CA’s to the maximum extent
possible without compromising DEA’s security requirements.

DEA’s approach to implementing EPCS is founded on government and industry
standards that are mature and, equally important, commercially available. These
standards must be viewed in two areas, this trust infrastructure the DEA will
establish to issue electronic credentials or digital certificates to
registrants, and, two, the applications that are enabled to provide the
security services offered by PKI technology, namely authentication integrity
and non-repudiation services that meet DEA’s anticipated standards.

Since the supply chain and prescription applications typically EDI
technology has used are owned and operated by industry and not by DEA,
combining identity and authorization within the certificate is the only
effective method for mitigating the considerable risks faced by the companies.
Any other approach would not reduce the industry’s risk and would, therefore,
not be widely adopted. This outcome would represent the least-favorable return
on OD and the department’s IT investment.

It is important to note that DEA considered and purposely avoided
architectures that are based on identity-only digital certificates. This was
done in order to minimize government involvement in high-value healthcare
transactions since identity – all the new models of this type would require
industry to access a government-operated authorization database, a situation
where DEA downtime would be intolerable.

DEA resolves this issue in its anticipated regulations by purposely
allowing the industry to cash(?) revocation lists. This allowance is a key
element of DEA’s reliability and availability architecture.

In addition, the DEA issued digital certificate serves as a DEA issued form
which the statute mandates.

The DEA Bridge Certificate Authority is used to be sure that we are aligned
with the other federal initiatives and we establish a certificate policy that
defines the obligations and standards for all the registrants – the approved
CA’s, the practitioners, the pharmacies and the e-prescription system vendors.

The obligations of the CA are to operate in accordance with our certificate
policy, the EPCS certificate policy, issue digital certificates only to DEA
registrants, perform revocations required and publish revocation information
every four hours, undergo an annual audit for approved status and that the
audit would be performed by an outside organization.

The core policy provisions in our certificate policy deal with the
identification and authentication of the individuals that would receive the
certificate, the CRL frequency, the CRL checking requirements, physical
security, the use of biometric, the expiration date of the certificates and the
extensions within the certificates.

It is important to remember that the EPCS is application neutral and its
transmission is standard neutral. DEA is neither requiring a specific content
or message format. We do not make any stipulation regarding transport. Our
anticipated standards only address security standards that we believe are
necessary to protect these transactions. We do want to see the certificate
transmitted along with the transaction. With respect to system implementation,
COTS products that have been in support of this, whether they are email or EDI
NT(?).

The FIPS security standards, DEA has worked closely with the National
Institute of Standards and Technologies to identify and include those federal
information processing standards to ensure that DEA’s performance standards do
not introduce new vulnerabilities.

The security requirements cover areas related to security design and
implementation of cryptographic modules. The FIPS standards combined with
NIST’s Cryptographic Module Validation Program enable industry to verify that
security applications meet basic crypto and performance standards.

The goal of the Cryptographic Module Validation Program is to promote the
use of validated cryptographic modules and provide federal agencies with a
security metric to use in procuring equipment containing validated
cryptographic modules.

All this is really critical importance to us, because we have learned from
NIST a significant percentage of all the products that they evaluated are
initially found to have vulnerabilities. These tests ensure the performance
standards are met in a reliable fashion.

DEA has worked closely with state organizations to identify the security
requirements that they believe should be part of the system. At this time, DEA
expects to include biometrics in the notice of proposed rule making for
electronic prescriptions.

DEA expects that we will get a significant response on this particular
topic. It is something that we know is being watched closely by all the parties
involved, and we are interested in getting the comments from everyone so that
we can make an informed decision as the process goes along.

The required prescription content remains the same as it does for a paper
prescription – the date of the prescription, the patient name and address, the
drug name and strength and dosage form, quantity prescribed, directions for use
and the practitioner’s name, address and DEA registration number.

In the electronic world, this data needs to be archived and must be readily
retrievable in the electronic form.

Application compliance auditing. The initial compliance audit is required
for all EPCS-enabled applications and followup audits will be required upon
major application revision.

In softwares, the pharmacies will be required to ensure that their software
complies with the requirements. It is not a site-specific audit.

The pharmacy obligations, the pharmacies, the pharmacist will not require
an EPCS digital certificate for the EPCS system. They would require a CSOS
digital certificate if they were electronically ordering things from their
wholesaler.

Prescription validity is based upon the validity of the digital certificate
at the time of the signing, and refills are based upon the validity of the
original prescription.

The pharmacy software performs several checks. It checks the digital
certificate to see if it is valid. It checks the practitioner’s digital
certificate to see if it has expired. It checks the issuing CA’s digital
certificate to see if it’s expired or if either of those certificates has been
revoked, and it checks the institution’s digital certificate if the prescriber
is an agent of an institution. It checks the prescription integrity to see if
the prescription has been altered in transmission, and it leverages the trusted
digital certificate to check if the practitioner has the authority to prescribe
the schedule listed or to see if the practitioner is an agent of a specific
institution.

Related to pharmacy record keeping, the pharmacist must electronically sign
the prescription. E-signature performed as a separate act in the process. The
access code/PIN is an acceptable solution in this process, and they must
maintain an electronic archive of the prescription for two years, which is the
same retention requirement we have for paper-controlled substance prescription.

And the software audit for DEA compliance is not a site audit for each
pharmacy. It is for the software itself.

The Veterans Administration pilot test, DEA established an MOU with
Veterans Administration to allow a limited pilot in the Hines, Illinois Medical
Center. Understand that Rob Silverman from the VA will be addressing the panel
on the outcome of this pilot later today.

From the DEA’s perspective, we feel the pilot has been successful for a
number of reasons. While we did not use biometric activation, smartcards were
able to demonstrate PKI to PKI interoperability between the DEA’s CA and the
Verisign CA. So the certificates that the VA is issuing are, in fact, from an
industry CA, which is the direction that we are heading with the project. Also,
the VA was able to demonstrate essentially a smart application that could
select the appropriate certificate from a practitioner’s smartcard. This is a
solution where VA employees have their own certificate and the participating
practitioners were also issued a DEA compliance certificate. The application
was able to read the certificate on the practitioner’s smartcard and select the
appropriate certificate for use in the prescription situation.

Under these circumstances, it is unusual for a smartcard to protect all
stored credentials with the same activation password. So this is not a
situation where the doctor had to remember multiple passwords for separate
credentials.

The VA test in Hines was for a Schedule II prescription. It was using VA’s
Verisign CA as a sub CA. The VA issued practitioner test certificates, and
there were 18 or more practitioners, and, at last word, over 800 prescriptions
had been transmitted using the system at that hospital.

A little bit about the economic impact analysis that was done as part of
the rule-making process, some of the considerations that we had to look at when
we were talking about the prescription cost estimates. We are looking at the
paper prescription on the left side. The time required to sign it, fax it,
phone it, the number of call backs, the cost of prescription forms, the cost to
enter data, record keeping, storage, waiting time.

And then, on the right side, in the digital prescription, looking at that
cost, the cost to obtain/renew signatures, to acquire and install systems, the
time and effort to learn to use the systems, the time to sign and transmit and
the cost of validating and annotating records were all factors that were
considered in the overall cost.

What we found with it is that the current system comes up with about
$250,000 per pharmacy per year. In the digital system, could be as little as
$26,000 per pharmacy per year; and the cost per practitioner per year, with the
current system, about $25,000 to $69,000; and the cost for a practitioner using
the digital system, $4,000 to $12,000; and the total cost for all the
practitioners, about $4.5 billion a year, $7.3 billion if you include the
public waiting time that could be reduced using the current system or about
$773 million a year using the digital system.

We looked at the annualized cost over 10 years. In the current annualized
cost of over 10 years, about $6 billion. With digital, it could be about $2.5
billion, as adoption is phased in, with a significant cost savings and,
hopefully, reduction in the amount of diversion of controlled substances, also.

Our recommendations are that for electronic prescriptions of controlled
substances that it be a PKI-based digital signature is required for
electronically-transmitted prescriptions and orders. The biometrics could be a
part of this solution, and the third is that DEA is willing to participate with
any organizations that have an interest in this to further discuss the
situation and as we go down the road in creating the new rules and procedures
for this.

And if you have more questions after this, there’s names and phone numbers.
Give us a call.

DR. COHN: Well, Michael, thank you very much for, I think, what has been a
very useful briefing for the subcommittee and I really – appreciate your – the
amount of information you have been willing to share, knowing – as I
understand, this is obviously a direction that the DEA is proposing, but has
really not even started moving through regulatory processes or anything like
that. So –

MR. MAPES: We have started moving through the regulatory process. We have
drafted a Notice of Proposed Rule Making. That was in process at the Office of
Management and Budget. We withdrew that so that we could get some more
discussions with industry and other interested parties, so that we will meet
with more folks to get some other ideas and then, after we get those, we’ll put
that back through the process again.

DR. COHN: Okay. Well, thank you for that clarification, and, obviously, I
just want to remind both the subcommittee and others listening in to all of
this, the role of this subcommittee, now, clearly, just want to remind everyone
that we are advisory and advisory to the U.S. Department of Health and Human
Services. So we are not advisory to the Department of Justice and the Drug
Enforcement Administration, but, on the other hand, obviously, we can ask the
Secretary of HHS to talk with the Attorney General or your agency head, and,
obviously, our interest and involvement in all of this, I think, as you know,
that under the Medicare Modernization Act, e-prescribing, as part of Part D, is
intended to be a major sort of policy and interest and desire both from the
industry as well as the Centers for Medicare and Medicaid Services. So we are
trying, obviously, to advise them.

We have obviously heard a lot of testimony I think sort of asking questions
about the level of authentification and non-repudiation that is really required
for this, and we obviously are well aware that narcotics, while not the only
business case for how all this works – I mean, clearly, DEA has a major
interest, and we want to make sure that whatever we do really does link up
appropriately.

So I think, obviously, we are happy to begin this conversation, and I am
not at all certain we are going to finish it today, but I think we’ll at least
begin it.

Now, with that, I’m sure the – the subcommittee has questions. I actually
maybe would start myself with just a question or two, and I guess I was – we
have had a lot of testimony, and I did notice during your testimony that you
made a comment about open versus closed systems, and you, I think, felt that
the non-repudiation and authentication requirements for both are virtually the
same, and I wanted you just to talk about that a little bit, because I think we
have heard from some that there’s – with the amount of security that occurs
with a closed system that it may be a mitigating factor for some of these other
issues. Can you comment on that?

MR. MAPES: Yes, first, I would like to make one general comment and that is
that I’ll answer the questions the best I can. If we get in an area that may be
too technical, we would like to just give you some written comments later about
those –

DR. COHN: Please.

MR. MAPES: – but in relation to your question, in the closed system, we
still have to ensure that there is the same level of non-repudiation, the same
level of trust that there would be in an open system. We’ll say it’s a – the
VA, for example, is a closed system. They use their system, as opposed to
someone who is using the internet to send the electronic prescription. So we
have to have one set of standards that is technology neutral that applies to
all situations, and that is part of our challenge is finding a single standard
that we can stay with for a long period, because while PKI seems to be the
solution at the present time, as technology changes, there may be other
solutions out there that provide the same security and non-repudiation that PKI
now does. So we are not closing the door on any of those. We are trying to
develop our regulations and standards so that they are completely neutral as to
technology and if there is a technology that can meet those standards that we
could then allow that technology to be used.

DR. COHN: Okay. I think, Jeff, you had a question. I’m sure I have a couple
of others and are there –

MR. BLAIR: Oh, sure.

I need a little bit of help, and although this question is obviously
directed at you because you are testifying right now, if there is anyone else
in the room that could clarify this as well, I don’t want to preclude them from
also clarifying this.

The topic of non-repudiation, in my mind, seems to require two types of
security. One is that the document that is being – in this case, it would be a
prescription – that that document hasn’t been tampered with, and, number two,
that it is bound to the signature, and, then, in addition to those – that is,
you know, verifying that the document or other prescription is received without
being tampered and it’s bound to the signature – and then the second is that
the individual who is sending the prescription is authenticated or certified
that that is, in fact, the individual that they claim to be. So, in a sense,
there’s those three requirements. Is that your definition of non-repudiation?

And let me just indicate that part of the thrust, the thinking behind my
question is that I am wondering if if there’s other ways of assuring that the
document hasn’t been tampered with, I’m wondering whether we need to stay with
the definition of the word non-repudiation or can we be working with the
component pieces in order to figure out what is the appropriate level of
security that is needed.

So do we need all those three levels for non- – those three functions for
non-repudiation?

MR. MAPES: When we are discussing non-repudiation, we are talking about
that the individual who signed the document electronically cannot come back
later and successfully claim that they did not sign that document. The
non-repudiation – the other parts that you talked – that the document has not
been changed, that is the integrity of the document as opposed to the
non-repudiation, a slight difference, but we have set those out a little bit
differently. And then the certification part is that, as we talked before, our
digital certificate will offer identity of the person, so that the relying
party – the pharmacist, in this case – will be able to say, yes, this did come
from the doctor whose name we have, and the credential part of it, that that
doctor is registered with DEA to handle, prescribe this schedule of controlled
substances. So there are really three separate and distinct things. The
non-repudiation just deals with the fact that the person who wrote the
prescription in this case cannot deny it, cannot repudiate that they had done
that.

MR. BLAIR: Okay. Then given that definition of non-repudiation, where you
seem to separate off the portion of security which would deal with ensuring
that the document hasn’t been altered and that it’s bound to the signature, you
indicated that is data integrity as opposed to part of non-repudiation. Is that
correct?

MR. MAPES: Yes.

MR. BLAIR: Then my next question is if that is the case, you indicated that
if the document is sent over a secure network, what requirement do you have
when it is over a secure network? And that may be – we may have to get into a
definition of what is a secure network, but if it is in a secure network, what
requirements do you have to ensure data integrity?

MR. MAPES: Our requirements do not include the transmission requirements.
Our requirements are what is contained in the prescription and the
infrastructure that we are putting together to allow that to be transmitted,
and we have to be very consistent with our requirements in the paper world, and
we don’t have transmission requirements, a similar requirement for a paper
prescription. We say that it can be oral. It can be faxed, in some situations.
It can be written and carried by the person to the pharmacy from the
prescriber. So ours are not transmission requirements.

DR. COHN: Okay. And, Jeff, I think I was asking some of the same questions,
only I was using open versus closed, which – I mean, I guess I had presumed
closed meant secure.

MR. MAPES: Right.

DR. COHN: At least that was what I – I mean, that may be how you were
answering it also.

MR. MAPES: Yes.

DR. COHN: So just interesting terminologies.

Steve, Harry, and then I think I have another question.

DR. STEINDEL: Yes, thank you. Thank you for the interesting presentation on
the directions, and, again, like Jeff, we have been hearing a lot about this
area of electronic signature, et cetera, and a lot of terminology issues with
it over the last few weeks in hearings.

I have a couple of questions for you.

First of all, your statement was that about – I think it was about 5
percent of the prescription orders, maybe 5 to 10 percent, were for controlled
substances, and we have heard from other people that is 15 to 30 percent.

MR. MAPES: Okay. I guess it depends on the practice setting that you are
in, what kind of pharmacy you are in, whether it is the mail-order pharmacy or
a retail pharmacy, a hospital. It is a small percentage of the total volume of
prescription drugs, and whether it is 5, 10, 15 or 20 percent, it is a minority
of those prescriptions.

DR. STEINDEL: I noticed in the VA pilot you limited it to Schedule II
drugs. Are you planning on, when you release this as a full system, to just
limit it to Schedule II drugs or to extend it through Schedule V drugs?

MR. MAPES: No, we’ll allow it for all controlled substances, and if someone
wanted to use the system for other than controlled substances, they could, at
their discretion. That would be at the discretion of the holder of the digital
certificate, the prescriber.

DR. STEINDEL: So as I interpret that, if people were using the Medicare
Part D system, the electronic prescribing for Medicare Part D drugs, they would
be required to use your system to electronically prescribe Schedule II to V
drugs.

MR. MAPES: No, the requirement is only for Schedule II. There is an
allowance for others, but if – Schedule III, IV and V do not need to be handled
in the same way as Schedule II does.

DR. STEINDEL: So this PKI system that you are envisioning would be just
limited to Schedule II?

MR. MAPES: No, it would be allowed for all, but if someone was going to use
Schedule II’s, they would be using this system.

DR. STEINDEL: Could they – if we were in a total electronic prescribing
world and someone wanted to prescribe a Schedule III drug, could they use some
other type of electronic prescribing system with another form of security,
non-repudiation, et cetera, besides what you are requiring?

MR. MAPES: They may be able to. It would end up looking at what the final
standards would be in the regulations.

DR. STEINDEL: Okay. Because that issue has been raised multiple times here
–

MR. MAPES: Right.

DR. STEINDEL: – about some acceptance for limiting this to Schedule II
drugs, but would prefer, as exists now in the paper world, a little bit of
leeway for maybe the III to V drugs. So I find your answer –

MR. MAPES: We understand the differentiation between the two, and there may
be a different situation in those.

DR. STEINDEL: Yes, thank you for that clarification.

Another question I had concerned – I was a little bit confused on
certification, the issuing of the certs. You said that the DEA cert will work
over a bridge so you could use it for federal – other federal programs, but you
would not go the other way where a certificate that appeared to be issued by
another group would be accepted by the DEA, and then you talked about
private-sector certification. You know, if a private-sector cert met your
requirements, could you use it in both – internally into DEA?

MR. MAPES: We would expect that those issuing digital certificates in the
ECPS program would be other government agencies. It could be boards of pharmacy
–

DR. STEINDEL: Um-hum.

MR. MAPES: – things like that, boards of medicine. It could be
associations. It could be private companies issuing those certificates. So if
they operated a bridge or subordinate certificate authority, under our model,
yes, those would be totally acceptable, provided – they would have to follow
our certificate policy, obviously.

DR. STEINDEL: Yes, and that is actually a satisfactory answer, too, because
we have heard from I think it was SAFE(?), which is a pharmaceutical
organization that is planning a digital certificate. Right now, it is geared
towards clinical drug trials, and, obviously, this is something that might
involve controlled substances and it would be good if that cert could be used
in the DEA situation as well.

MR. MAPES: Right. Provided they followed the certificate policy.

DR. STEINDEL: That would – thank you. That was good.

The next – this gets a little bit to Jeff’s question concerning
non-repudiation, and when you talk about PKI and you are talking about things
like non-repudiation, you are starting to talk about a packaged message that
has been encrypted with a private key and then decrypted with a public key. It
is usually signed with an electronic signature and a hash is applied to it that
indicates non-repudiation. Is that total package what you are looking for or
are you just – and in your answer, you seem to indicate that you would accept
components of the package, which would not be a strict PKI.

MR. MAPES: No, it’s – those are all parts of an electronic prescription.
When I was talking about the non-repudiation, we – that is a part of the
system, but it is obviously not a part you could take out from the rest of the
system and do that separately. The system you described is the PKI system that
we are envisioning.

DR. STEINDEL: That is what you are envisioning, the total – because what we
have heard is there is a problem in the total electronic-prescribing process
with a true PKI system because in the electronic-prescribing world there are
different standards that are being used, and you indicated your solution should
be standard neutral, but, for instance, we may be in a situation where our
prescriber would be using one version of a standard and hasn’t had a chance to
upgrade, and the pharmacy is using another version of the standard and a middle
person would –

MR. BLAIR: Steve, could I just ask – be a little bit more specific, because
I am not sure that he understands what – that you are talking about the message
format standard, for example.

DR. STEINDEL: Oh, like, for instance, NCPDP script. There’s multiple
versions of NCPDP script. We may be working with a provider that is using
version two and we may be using with a dispenser that is accepting messages in
a later version, and there may be a need to translate between version two and
the later version, and a lot of times, there is a middle vendor –

MR. MAPES: Right, and –

DR. STEINDEL: – and they have to open the message which then destroys the
non-repudiation and destroys the PKI system. How do you envision that working
in your system?

MR. MAPES: We have discussed with some of the same vendors that probably
you have discussed with that same situation and we are looking at the situation
to see where those vendors could fit in. So if the prescription did not go
directly from the prescriber to the pharmacy but went to one of these third
parties that would then take it, open it and determine what standard it was
using and what needed to be for the recipient and then translate it into that
and send it off, we are taking that into consideration and trying to see if we
can account for that, adjust for that in the situation, because we understand
the traditional PKI and how we have to take that and adapt that to the real
world of electronic prescribing. So that is one of those issues that we are
trying to take a look at and resolve.

DR. STEINDEL: And one last question, Simon.

How extensively are you going to be looking at the overhead of going to a
PKI system? We have heard multiple different levels of actual overhead in terms
of message sizes, the time it takes to translate the message, et cetera. Are
you looking at that in your pilots in any great depth?

MR. MAPES: No, I don’t believe we are looking at that in the pilots,
because in the pilot that we currently have going, it is all within the same
organization, but that is an issue we can take a look at –

DR. STEINDEL: Yes, because, I mean, some people have said that the overhead
of a PKI system could be as much as 50 times what it is in a non-PKI system;
and on the other side of it we have heard, you know, relatively low like one –
you know, two to three times. So –

MR. MAPES: Right.

DR. STEINDEL: – that is an issue that is still up in the air.

MR. MAPES: Right, and –

DR. STEINDEL: And when you are talking about how many billions of
prescriptions a year, that – if we are talking 50 times, that could be a big
problem.

MR. MAPES: Right.

DR. STEINDEL: Thank you.

DR. COHN: Yes, and before we give it over to Harry, I just have one
clarification I need to make sure I understand, because it is not really
referenced anywhere in your overheads or anything else I have actually have
heard from DEA previously. The focus of all of this is really on Part II –
Schedule II medications and – which I think I heard you say unambiguously, but
then explain to me again what the proposal is for III, IV and V. Is it to be
determined? Is it something else?

MR. MAPES: No. We are developing a system that can be used for all
controlled substances.

DR. COHN: And everything else.

MR. MAPES: Right. At the discretion of the holder of the digital
certificate, the prescriber, in this case.

Because of the requirements for Schedule II prescriptions, because Schedule
II’s are much more abusable than Schedule III, IV and V and that is why they
are in Schedule II. We have to have a tighter control over Schedule II’s.
Schedule II’s cannot be, in any way – with one very minor exception – called in
from the prescriber to the pharmacy currently. They have to be written. So
Schedule II’s would have to use a system like the EPCS system. Schedule III
through V’s currently can be called in, and if people wanted to continue to
call them in, that’s fine. This is – we are developing a system to allow for
that – for electronic transmission – if they wanted to use that. It is not a
requirement that they use it, just an allowance that if they want to.

So Schedule II’s, if they are sent electronically, would have to use this
system. Schedule III, IV and V’s may not have to use this system. There are
other systems that they are using.

DR. COHN: Okay. Or other approaches for –

MR. MAPES: Right.

DR. COHN: – authentication and non-repudiation.

MR. MAPES: Yes.

DR. COHN: Okay. And would that be – was there a proposal being made on how
those were going to be handled in your vision or is that silent, at this point?

MR. MAPES: Well, the requirements will be in the – when the rule – the
proposed rule making is out, it will set out requirements for controlled
substances, and if a system meets those requirements, then they could use it. I
know that is really –

DR. COHN: Okay.

MR. MAPES: – not enough of an answer.

DR. COHN: Yes. No – let me just try to ask it again, because I feel like I
am almost understanding you, and I am very clear about what it is you are
proposing for Schedule II. I mean, I – practicing physicians, I’m well aware of
when I have to pull out my triplicates and all of this stuff, but – so I was
just trying to figure out what exactly you were proposing for III, IV and V and
whether there was a proposal or whether it was really a lack of a proposal, and
I think what I am hearing from you is that you have a well-defined proposal for
Schedule II, and for Schedule III it is likely that whatever it was you were –
I mean, you really weren’t proposing a solution for that in terms of
appropriate level of authentication and non-repudiation.

MR. MAPES: We are proposing this for all controlled substances.

DR. COHN: You are? Okay.

MR. MAPES: But there may be other solutions that can be used for Schedule
III, IV and V, because of the differences.

DR. COHN: Okay. Okay. Harry – I mean, thank you. I appreciate –

MR. MAPES: That’s fine.

MR. REYNOLDS: Steve asked a number of my questions, but I’d like to play
off of some of those a little more, and I’ll just play off of what Simon said.
You mentioned that it is only for two, but you feel comfortable that could be
used for other –

MR. MAPES: Yes.

MR. REYNOLDS: – for the other schedules.

MR. MAPES: Yes.

MR. REYNOLDS: And I know we are not committing that it couldn’t spill over
in later legislation or anything else.

The other thing, back to what Steve was talking about also, it can go
through one vendor or it can go through multiple vendors – you look at this
flow from a physician to their practice-management system to a vendor to a
switch to a – so there may be multiple stops along the way, not just one
singular –

MR. MAPES: There could be multiple stops, yes, and we have to better define
those stops and what is allowed and what can happen at those stops to be sure
that we still have the integrity of the message.

MR. REYNOLDS: And as we heard the varying testimony, that is where the rub
becomes when you get into PKI as you deal with it.

So I hear system sometimes and I hear standard sometimes. So are you
recommending standards and then certain systems would have to meet those
standards, is that correct?

MR. MAPES: Yes, our regulations will develop standards. Our PKI will be an
infrastructure that we are developing that will meet those standards. So our
regulations will be the standards for – and, again, technology neutral –
but will be the standards that have to be met in order to electronically
prescribe controlled substances.

MR. REYNOLDS: Technology neutral, but not process neutral.

MR. MAPES: Correct.

MR. REYNOLDS: Right. Okay. Thank you.

DR. COHN: Okay. Judy.

DR. WARREN: My question came early on, just because I have not heard this
or anything, but you talked about two different PKI models. One of them was
hierarchical and one was bridge. Did I understand that right?

MR. MAPES: Yes.

DR. WARREN: Can you just tell me a little bit about which ones – I don’t
understand those two models. So just a very brief –

MR. MAPES: Okay. Here we go. We’ll try this. The hierarchical model would
be the DEA certificate authority would be the top and every other certificate
authority would be subordinate to the DEA certificate authority. So they would
be underneath and subordinate to and follow our rules, our certificate policy.

The bridge certificate authority, the other certificate authorities, rather
than being underneath and subordinate to, they may have several different
purposes for the other certificate authorities, so while they would follow our
policy when they are doing transactions involving prescriptions, they may do
other transactions involving other things and would use someone else’s
certificate policy for those transactions. So they can be used for more than
one purpose.

DR. WARREN: Okay. And then – so the bridging is there is no one that
is really in charge of issuing the PKI – or not – that is the wrong word, but
no one in charge of setting the policy. You would agree to use each other’s –

MR. MAPES: Well, no, they would have to use our certificate policy in order
to issue digital certificates in our system.

DR. WARREN: Okay. That is what I was missing. Thank you.

DR. COHN: Stan.

DR. HUFF: So my understanding of PKI and basically all of the
non-repudiation issues is that it is all relative, in some sense. I mean, at
some degree of sophistication, there is a probability, even with PKI, that
somebody could successfully argue that it could be broken or it could be – and
we – I mean, we are talking about things that are so – probabilities that are
so great that it couldn’t be broken, that any reasonable person would say, no,
it wasn’t and they would convict.

But I am wondering, then – I mean, it must have been your judgment that –
you know – the other kinds of closed-system requirements that people have
talked about, you know, if you had authentication using tokens or – you know –
basically, a log in, a password and a token of some kind for authentication and
then could assure secure transmission of the prescription over a closed
network, other things, it was your judgment that those things – that there was
sufficient difference between the risk of repudiation to justify PKI versus the
other less – slightly less or a lot less secure mechanisms.

MR. MAPES: Right. In looking at the different options that are available,
it looks like PKI is the one that provides – and, as you said, there is no
absolute. There is – you know – to a mathematical certainty that the likelihood
of them successfully repudiating a transaction would be very minimal. In
others, that likelihood increases a little bit. So we have to look at them and
say what would be the best for handling these controlled substances and how
much risk is acceptable, and so, in the overall process, we determined that PKI
is the best that is currently available. Now, that doesn’t mean it will always
be, that there will be other technologies out there that will also work at some
point in time.

DR. HUFF: And I guess the – sort of the heart of the question is it is
always sort of a cost-benefit question, and do you have an – how many cases
actually come to trial where this is an issue, where – or how many cases, how
many people a year are convicted of this kind of fraud?

MR. MAPES: I don’t know what those numbers are. I could say that the
numbers are a very small percentage of the prescribers of controlled
substances, much less than one percent of the prescribers of controlled
substances. So – but I don’t really know what those numbers are.

DR. HUFF: And – I mean, you must have done some modeling to think, you
know, of the cases that are tried when – you know – when would this
non-repudiation be an issue versus other issues of evidence and other things,
and do you have any idea? I mean, if we said – did you do even modeling to say
if we do this level of security, then we think we might lose this many cases
and if we did this level, that would make – you know – a difference in five
cases or 100 cases or 1,000 cases a year, based on which level you did?

MR. MAPES: No, we didn’t look at the differences, because the
non-repudiation is one aspect of PKI and we didn’t look at that in terms of the
number of cases that we might win or lose over a period of time. That just
wasn’t a comparison that was made.

DR. HUFF: I guess along the same lines, in your Slide 33, where you did
costs and benefits, as I understand it, one set of costs are the current costs
using current paper system and other capabilities, and then you have the other
benefits where we end up with cost savings of $24.8 billion a year or $24.8
billion over 10 years. I’m not – but, anyway, a lot of money. Do you know how
much of the savings are due to use of the electronic system in general versus
an electronic system that uses PKI versus an electronic system that used some
lesser degree of validation and non-repudiation?

MR. MAPES: No, I don’t. I don’t know the difference in that –

DR. HUFF: Don’t know –

MR. MAPES: That is an issue we could look at in more detail and get back to
you in writing on that.

DR. COHN: I have a question, and I think Harry has a question and then Jeff
has a question, and maybe we’ll begin to –

DR. HUFF: Well, I guess I – I would just –

DR. COHN: Oh, you have another question. Okay. I’m sorry.

DR. HUFF: I guess it is just sort of – it would have seemed to me that the
difference in your conviction rate would have been the ultimate justification
for the increased cost between simpler methods and PKI methods, and so I am
surprised that that analysis hasn’t been done.

The factor that we were looking at is the level of control of the
controlled substances, not of the number of people who had been convicted for
violating the Controlled Substances Act. So we are looking at the level of
control that it provides.

Well, I think it is the same question, though. I mean, you know, I am part
of a medical provider group, and based on, you know, just regular kinds of key
passwords, you know, we have successfully fired and maintained in court when
those things were contested that people looked at records they shouldn’t have
looked at, and so, you know, for all of our normal business functions, which
include things probably as important as – you know – controlled substances, we
have been able to convict people with much lesser levels of security than are
being proposed here, and so I am just trying to understand the justification
for the increased cost when, you know, at least in my experience, much lesser
levels of security have been sufficient for us to conduct our business with
and, you know, up to and including convictions and other kinds of security
breaches and other things that we convict people of.

MR. MAPES: Okay. And I understand your concern about the cost of that and
the difference.

I would say that, in the paper world, when we are looking at a prescription
for a Schedule II substance, the pharmacist has to take that paper prescription
and look at it and make a decision based on what they have in front of them. So
the pharmacist looks at it and they know that this doctor normally writes for a
certain drug, which would also be available in the electronic world. They look
at it and say, yes, this doctor always uses blue paper. They usually sign their
name this way and all those kind of things that aren’t available in the
electronic world. So this is a way to try to make the paper and the electronic
similar, so that the pharmacist can rely on that as having been signed by that
physician, approved by that physician, not signed by or approved, because they
don’t have a physical signature, by an office staff member or someone else
other than the physician.

DR. HUFF: I guess in that particular case, we heard a lot of testimony that
even though those things are theoretically true in practice, the pharmacist
rarely knows actually this physician’s number or prescription pad or any of
those other things.

MR. MAPES: Okay. Well, it depends on which pharmacist –

DR. HUFF: And that is why I was wondering – I mean, there certainly could
be evidence that – those things, but I’m surprised that there isn’t science
that supports, so that you could say, this is the real difference in risk that
we are taking between these two different approaches, and this is the cost
benefit of that.

MR. MAPES: I can look more closely at the cost analysis that was completed
– ee had a contractor do the cost analysis for us – and look at it and see what
it says on those issues.

DR. HUFF: Thank you.

DR. COHN: Now, I have a question, Harry, Jeff does. Steve, do you have a –

DR. STEINDEL: I have a comment on what was just –

DR. COHN: Okay. Please, if it’s a follow on, please.

DR. STEINDEL: – just discussed.

I think what Stan is asking is let’s say there are N – in the world that we
are dealing with, it would be fraudulent prescriptions. In the world that you
are probably dealing with, it would be illegal prescriptions written. Let’s say
there are N of those, and we choose to use a PKI system, and, as was pointed
out, the PKI system could be spoofed a very small percentage of the time, but
could be spoofed. Let’s say we could get 99.99 percent of those fraudulent
prescriptions using the PKI system.

MR. MAPES: Um-hum.

DR. STEINDEL: If we chose to use a lesser system and we got 99.9 percent of
the fraudulent prescriptions, is that other one-hundredth of a percent worth
introducing a PKI system? And I think that is the kind of number that Stan is
asking about.

MR. MAPES: Okay. And that is exactly the kind of input we have to have when
we are making the decision in the process of rule making, that what is the
difference? Is this difference worth it? Where shall we go that direction? And
so that is the kind of input that we are looking for.

DR. COHN: Yes, and I would say certainly save those thoughts.

Okay. Harry, I think you have an issue on the –

MR. REYNOLDS: Yes.

DR. COHN: – a question on the same issue, and then we’ll move to a couple
of other questions –

MR. REYNOLDS: Playing off of Stan’s comment especially.

When you think of PKI with the public and private key, those can very
easily be embedded into a system to where you are basically verifying that it
came from some computer, went to the other computer and both sides of that
transmission knew the key.

Whereas, with passwords and other things that you may have people enter
each time, you may be able to capture each time, whether it’s – tokens change
regularly.

So as you think about PKI, it has tended to be a point-to-point protection,
not necessarily a singular body that has to do something every time, because a
password – I have to enter my password or I have to enter my token number,
which changes regularly, versus my PKI – my public key and private keys don’t
change, and so when you think about – so we are taking a point-to-point
capability, and, now, we are moving it into where we have individuals out
there.

So one of the key things that we all rely on – at least, what we have heard
– is that the doctor signed it. In this case, the computer can sign it from
that doctor’s office, and that doctor may, in fact, never have to be involved,
using just PKI. If you think about it, and I am just putting out a premise. I
am not –

MR. MAPES: Well, that’s why –

MR. REYNOLDS: So I think those are one of the things that, as you think
about what authentication is and what goes on in a doctor’s office and the
closed systems and the other things that were at least brought up, that whole
thing of point to point, but then once you step into the real people, we heard
that some doctors have pads that they sign a lot of them, but at least they
signed it and they took responsibility. Whereas, my – that PKI is system to
system, and you’ve got fixed numbers. You’ve got fixed numbers on both sides,
and so it is just something to add into your equation.

MR. MAPES: But in the design of our system, the digital certificate would
probably reside on a smartcard, a token of some kind, and use a biometric to
unlock that to use that, so that it could be used in multiple locations. It
wouldn’t be just a single location that the doctor could prescribe from. He
could prescribe from multiple locations; and with the biometric, that would tie
the prescriber to the digital certificate to the transaction.

MR. REYNOLDS: And the multiple locations would all require the smartcard
reader. So –

MR. MAPES: Yes.

MR. REYNOLDS: So updating a prescription from home or anything else, you
would have to have a similar device, he or she would have to have a similar
device at home to be able to do that Schedule II in the middle of the night.

MR. MAPES: Yes, they would.

MR. REYNOLDS: Okay. Fine.

DR. COHN: Michael, thank you for answering all our tough questions. We do
appreciate it.

I actually had a question that – I have two questions, and one of them sort
of, interestingly enough, begins a transition along the lines Harry was asking.
I mean, the subcommittee has been talking almost exclusively about PKI up
‘til now, and I know Jeff earlier sort of talked about this – you know –
what pieces really make for all of this working.

Now, I think we would all observe that PKI probably is only as strong as
whatever that authentication is going in, and Harry began to ask about that. I
mean, I think we are all aware that PKI, you know, if it is your computer and
it’s turned on, anybody, potentially, could use it, and PKI would just
authenticate that it goes from that computer to another one. So we really do
get back to that issue of biometrics or smartcard or whatever it is that
authenticates that Dr. Simon Cohn is actually writing that prescription, and,
then, from there, it is being non-repudiated as it goes through, and I think
that’s what I saw as you were talking in terms of your proposal.

Now, but you were mentioning here – and let me just sort of ask this
question: It appears that you are asking, or at least proposing, some sort of
biometrics to be the thing that sort of unlocks and authorizes the whole PKI to
work, and I don’t see it being much more specific than that, but what is your
sort of vision about all this? Because I think the strength of the whole
solution sort of rests on its weakest link in some ways, and I – certainly, I
have heard that – we have not heard testimony here specifically about it – that
a lot of biometrics is – at least in clinical environments – is probably not
quite ready for prime time, and, certainly, that is what I have heard as I have
talked to people about it.

I guess I would also ask the same question about your CSOS implementation
and are you going to be having biometrics for pharmacists ordering up
medications, which appears to me to be a much greater risk. If I am ordering up
10 box loads of a controlled drug, I would really want to make sure that the
pharmacist was who they said they were before they – you know – ordered up
1,000 or 2,000 OxyContin or something like that, but help me with this.

MR. MAPES: Okay. First of all, in the CSOS system, no, we are not requiring
biometrics, and you have to look at the electronic – in this case, CSOS is part
of a larger system of controls. In the CSOS world, the only ones with digital
certificates will be the registrant, the owner of the pharmacy or someone who
they have given authority to order controlled substances to, and, again, the
digital certificates in that situation will be identity and credentialing. They
will be tied to a specific DEA registration – in this case, the registration of
that specific pharmacy. So when the pharmacist orders controlled substances
from the wholesaler, they will – included in the information in the digital
certificate will be the DEA registration number, the schedules authorized and
the address of that pharmacy, so that the only place those controlled
substances could be sent would be sent to that pharmacy.

And suppliers also, as part of the control mechanisms, have to report to
DEA any suspicious or unusual transactions from a specific pharmacy. So if the
pharmacy had an ordering pattern where they ordered routinely two bottles of
something – a controlled substance – every week and all of a sudden they went
up to 20 bottles, that would probably trigger that suspicious or unusual
purchase so that the distributor would then let us know about that so we could
take a look at it.

So what I am saying here is that the CSOS system, the PKI system for
ordering is part of a larger system of controls that we have, so that we don’t
need the biometric for that, and the number of people that have those
certificates will be much smaller.

Now, the biometrics as a whole, it is a technology that is maturing. We
have seen demonstrations of several new types of biometric readers and that
kind of thing, and that is probably one of the reasons that we want to further
discuss the issue.

We know that biometrics is a key, and, as you say, it could be the weakest
point with biometrics. I don’t think it would be, but as the biometrics
industry itself is maturing and the costs come down, then we can look at the
cost benefit of using biometrics as opposed to not using it.

So we understand that some – in the past, some are expensive, large and
difficult to use and those are coming down in price and in their reliability.
So by the time this is out, two years down the road or a year, whatever it is,
what is going to be available, I don’t know, but we are going to work on
setting standards rather than, again, any specific biometric piece of hardware.

DR. COHN: Well, Mike, thank you very much for this response. I guess I am –
you know, I am not a pharmacist. I am a physician, but I found it sort of odd,
and I am just going to have to think about it and will probably ask others who
are testifying later today to comment.

I just – in some ways, it appears to be that you are – you know, if we are
talking about distribution center and mom-and-pop stores, you are sort of not
guarding the distribution center with the same rigor that you are guarding the
mom-and-pop stores, but that is just – I would have to hear others think about
this one. I just am sort of surprised about your analysis about the risk of
pharmacies versus physicians prescribing, but, as I said, I mean, I think you
are certainly allowed to have that perspective, and I would just like to get
additional input on that.

MR. MAPES: One additional comment on that and that is for all Schedule II’s
and Schedule III narcotics that a distributor sends to a pharmacy, they report
each and every one of those transactions to DEA, so that in – usually within a
month’s time frame, we know about all those transactions, look at them and
determine if some transactions appear to be out of the norm. So, again, the
CSOS is just part of a larger control mechanism for those drugs.

DR. COHN: Okay. Well, now, my final question on this one is just – I think
at the end – and I actually really appreciated your last overhead, which sort
of talked about this issue of the Part D pilot, and certain conversations we
have all been having, you know, and, obviously, part of our role is to advise
CMS on really what ought to be piloted for 2006 and maybe even a little beyond.

From your perspective, what do you think would be the appropriate role of
those pilots to potentially – I mean, now, once again, obviously, you may just
go forward with rule making, which may render Part D pilot sort of moot on
this, but assuming that this could contribute some to your decision making and
thinking, what are your thoughts about how the Part D pilot might be useful in
terms of helping mature your thinking around all of this?

MR. MAPES: I think the Part D pilot would be useful, because it could
provide us with some real-world examples of systems that worked well, systems
that need changes, systems that didn’t work well, and provide some more
discussions with industry, with the pharmaceutical industry, with the doctors,
with everybody involved, the pharmacists, so that we can get a better grasp on
what will and won’t work in those situations.

DR. COHN: Thank you.

Steve, is this a followup on this one for –

DR. STEINDEL: Yes, a followup on biometrics.

DR. COHN: Okay. Oh, okay.

DR. STEINDEL: Yes, when you are going to be asking about comments for
biometrics, are you going to specifically ask for comments concerning the
clinical environment and the use and success in that environment?

Because, first of all, biometrics, just in the general environment, as you
point out, is improving in its reliability and its success rate, but the
clinical environment, with respect to biometrics, is still a very dirty
environment. You know, physicians take off gloves. They leave particles from
the gloves on fingerprints, reduces the reliability there. If they are working
in operating theaters, you have the same glove problem. You also have problems
if you use – you know – just facial features, because they might be masked or
they might be wearing a hood. So there is a lot of reliability problems that
are different in the clinical environment than they are in just the regular
world, and so I hope when you are asking for comments that you specifically ask
for experiences within the clinical environment as well.

MR. MAPES: Absolutely. We recently had a demonstration by a company that is
in the biometrics and their emphasis is biometrics in the clinical environment,
and they told us about great successes that they have had. So we would want to
look at the success that they have had with biometrics, the error rate that
they found and those kind of things to see how good it can work in the
real-world practice settings.

DR. STEINDEL: Yes, and we do have a surgeon present. I’m sure he can
validate this. The reliability factor that he probably wants in the operating
room from a biometrics reader is 110 percent.

MR. MAPES: Yes.

DR. STEINDEL: (Laughter. Twenty, he says. (Laughter).

DR. COHN: Okay. Other questions or comments?

Jeff, do you want to – get to a microphone.

MR. BLAIR: Getting back to the question that I had asked earlier, which was
the protection of data integrity, is there any consideration that you have
given to how secure the network might be? Is there any assumptions that you had
as to whether or not the prescription is over the internet or a virtual private
network or secure network, and if you are thinking of a secure network, you
know, what assumptions did you have about what makes it secure or what
standards did you envision in terms of what is secure?

MR. MAPES: Okay. Again, ours does not deal with the transmission
requirements, but when we’re looking at our system, we were making the
assumption that it would be over the internet rather than over a VPN, so that
it would be the most open, and if the standards work for the most open system,
then, obviously, they will work in a more closed, more secured system.

MR. BLAIR: Well, if that is the case, and if the prescription is over a
network that is, to some degree, secure, does that effect, in any way, your
data integrity requirements?

MR. MAPES: No, we still have to have the requirement that we can
demonstrate that there wasn’t a change to the data in transmission, although we
are not saying what the transmission requirements are.

It may be, as we craft the regulations, that there can be some allowance
for that. Whether it is a closed or open system, I don’t know, but, right now,
we are just taking the regulations and assuming that it is the most open
transmission system, so that they would work.

DR. COHN: Well, Michael, we want to thank you, and I really appreciate your
openness in willing to have a frank discussion about all this stuff.

As you know, we are sort of really in the midst of trying to offer the best
advice we can to the Secretary. So we really want to thank you. I suspect this
will be not our last conversation about all of this, and, obviously, we’ll be
hearing from the VA about their pilot later on today as well as, I’m sure,
having conversations about a number of the issues you brought up as we go along
with the rest of the testimony.

So, really, thank you for some really great and for useful information.

MR. MAPES: Thank you for your time.

Agenda Item: CMS Update

DR. COHN: Okay. And I think we move from here to a CMS update and Karen.

Yes, and we are pleased to have Karen Trudel and Clay Ackerly present the
update.

Clay, as I understand, you are one of the Special Assistants to the
Administrator.

MR. ACKERLY: Yes.

DR. COHN: So thank you for joining us.

MR. ACKERLY: And I just wanted to say thank you to your all’s work so far.
It has been fantastic to have such high quality – I know that Dr. McLelland(?)
and the Secretary and HHS broadly a), you know, we rely on your expertise and
it has been extraordinarily helpful to have, and, you know, makes us, you know,
more confident in how we move forward with this important policy decision. So
thank you for all the hard work and it is much appreciated.

MS. TRUDEL: Morning.

A number of you have already made remarks about the fact that I obviously
have undergone an extreme makeover in terms of my presentation skills.
(Laughter).

Want to talk a little bit today about the e-prescribing process under Part
D, what we are doing in terms of the regulation, what we are doing in terms of
some of the discussions about pilots, and so I would like to just talk a little
bit about the timing and remind you of what we are looking at here.

We are still targeting publication of an NPRM for e-prescribing this month,
and we think we have workdays left in the month that we could actually manage
that. We are very, very close, and the next target after that would be a final
rule, which would need to be published by October of 2005 in order to meet our
ultimate target, which is to implement foundation standards when the Part D
benefit becomes live in January of 2006.

I wanted to provide a little bit of feedback on what I have heard in terms
of the – what I am hearing about the recommendation letter and the
recommendations. I have heard very positive feedback. What I have heard was
that the recommendations were very thoughtful. They were balanced and
comprehensive, and, of course, very timely, and I think that from two
perspectives.

One is I have heard a great deal of positive feedback by a number of
different folks in industry who felt that they really had an extraordinary
amount of ability to make their points in time for them to be heard and that
the subcommittee members and the committee members were very open and receptive
to a number of different points of view and really tried to balance them all
out.

From an internal perspective, with respect to myself and my staff, as
drafters of the regulation and the folks that we are briefing and trying to
inform through the clearance process, I think the fact that we have gone
through this hearing process gave us an enormous leg up, that we had received a
very intensive briefing. It made it a lot easier for us to develop issue papers
and briefings. We just had an extraordinary wealth of material to draw from,
and, for that, I thank you.

I would also like to talk about – to the extent that I can – what is in the
NPRM, and there are limits to how much I can say, because we are going through
the clearance process, but one of the things that we have done is to describe
the NCVHS process and the stakeholders. That adds to the credibility of our
recommendations. It gives a very good sense that we have really, really done
our homework here.

We summarized the NCVHS recommendations in the proposed rule, including
some of the ones that we are not proposing at this point. So we are trying to
give a total picture as to what we are starting with and where we expect
e-prescribing to end up.

We also explain our incremental strategy, the fact that we do want to start
out with foundation standards. We’ll lay other standards over the top, as a
result of the pilots, and that, ultimately, we are talking about a successful
integration with electronic health records, in general.

I think that what we are proposing in the regulation will not be a surprise
to any of you. We are talking about proposing foundation standards. Suffice it
to say that they are very similar to the ones that the NCVHS recommended.

We also take an opportunity to try to explain a little bit better the
concept of adequate industry experience as we heard it. So we have put out some
criteria that we think we can use as good tools to measure adequate industry
experience.

One of the things that we are doing and that you will see when the
regulation is published is that there are many places where we specifically
solicit comments on particular issues that we really, really want to hear
feedback on, and the notion of adequate industry experience, because it is so
basic to the concept of the foundation standards, is one of the places where we
are doing that.

There is also a fairly extensive discussion of state preemption raising a
number of the issues that we have heard in the hearings, and we will be
specifically, again, soliciting information and comments on that notion.

Also, we will discuss Stark and anti-kickback, but we will be making a
statement that those both will be addressed in separate regulations, so you
should not expect to see any specific Stark and anti-kickback proposals in this
NPRM.

The next thing I would like to talk about a little bit is pilots. We know
that the law says we need to announce initial standards for pilot testing by
September of 2005 and that the pilots need to be operational in 2006.

We are still working right now on the structure of the pilots. One of the
things that we are using is, obviously, the NCVHS recommendations. Margret was
able to distill a matrix or a checklist almost of things that people suggested
in the course of the hearings be pilot tested, and so we can use that as
something that we can use as a building block to develop the pilots.

We also have done our own environmental scan of existing e-prescribing
programs, and we are still in the process of evaluating those results, but
those, also, will definitely inform the structure and the nature of the pilots,
and I think you should look to see an announcement about pilots, at least at a
very high level, probably within the next month.

And I would like to remind you about the subsequent milestones that we are
looking at. After the pilot tests are finished, a report to Congress, no later
than April of 2007, and proposed and final rule, no later than April of 2009,
and, again, if previous notions hold true, we will be pressed to deliver those
things well in advance of those milestones, but that is basically where we
stand right now.

Again, I thank you for all of the support. It has made our jobs a lot
easier.

And, Clay, do you have anything you want to add?

MR. ACKERLY: No, just, again, to say thank you for moving so quickly. You
know, as you said the precedent has been set that we are trying to move ahead
of these deadlines, given what e-prescribing can mean to the quality and the
efficiency of the Part D benefit in prescribing for seniors and what it can
mean for the entire healthcare system. So this is really important and thanks
again.

MS. TRUDEL: Any questions?

DR. COHN: I know Jeff has a question and Steve has a question or a comment.

I just want to, first of all, thank you for the compliment. I mean, we –
obviously, we worked hard, but I think we are very proud of the work that we
have done so far and, obviously, look forward to continue the close
collaboration. So thank you.

Jeff, you have a comment, and then Steve.

MR. BLAIR: Yes. Clearly, the schedule to move forward to get ready for the
pilot tests is limiting a lot of things that we might like to do. Right now,
NCVHS is working on trying to come up with recommendations for the e-signature
portion of e-prescribing.

Could you maybe give us some feeling for either whether that will
eventually be included in the NPRM or will it be handled separately or how will
this fold into – or is that not known yet?

MS. TRUDEL: The quick answer is there’s a lot about the pilots that we
don’t know yet, but just kind of doing the math in my head, I think we are
talking about the next set of standards coming from the subcommittee in March,
and I think if there are clear paths that we might want to test, even if they
may be multiple paths that we might want to test, you know, differentially, it
would seem to me that there would be adequate time to work them into the
pilots.

The other thing is that from my perspective, at least, I don’t expect that
every pilot is going to test every single potential standard. I think what we
need to do is to have enough experience that we can put things together, but I
would think it would be very, very difficult for any pilot to get up and
running if it were testing every potential possible standard that we could be
considering, and so there’s – I think we have some latitude there in
determining how exactly we distribute the testing load.

DR. COHN: Okay. Steve.

DR. STEINDEL: Karen, I won’t comment on the extreme makeover.

MS. TRUDEL: Thank you.

DR. STEINDEL: But I do have a question. You mentioned that – when you were
talking about the incremental steps, that is just kind of preamble material
about where you are going –

MS. TRUDEL: Yes.

DR. STEINDEL: – because I am concerned about the implications with the
electronic health record. You know, obviously, this is going to be a direction
towards it, but I don’t know if we know enough to say anything more except in
preamble material.

MS. TRUDEL: And we don’t, but what we need to do is to signal to the
industry that the department recognizes that these things all have to come
together in the final analysis.

DR. STEINDEL: Yes, I am very comfortable with that statement.

MS. TRUDEL: Yes. Exactly. That is the point.

DR. COHN: After our DEA conversation, this has been very – appears to
be very quiet. (Laughter).

DR. STEINDEL: Can we ask what the iconology means?

(Laughter).

DR. COHN: I guess I would ask – obviously, we have just been talking and
having conversations with the DEA. I presume that their participation would be
potentially welcomed in pilots in 2006 if they felt it was important to test
various approaches to areas that they are concerned about.

MS. TRUDEL: Oh, I think we are very open to discussions with our colleagues
at the DEA.

DR. COHN: Okay. Good. Good.

Well, okay. Well, I think we’re done. Thank you very much. We look forward
to the NPRM. I presume we have 60 days to respond to it, once it hits the
street.

MS. TRUDEL: Yes.

DR. COHN: Is that a reasonable assumption?

MS. TRUDEL: That is correct. Yes.

DR. COHN: And we’ll look forward to seeing it. Thank you.

MS. TRUDEL: And, hopefully, we’ll be back with another presentation in more
detail very shortly.

DR. COHN: In February. Okay. Obviously, we appreciate the opportunity to
provide meaningful input to it. So thank you.

MS. TRUDEL: Um-hum. Thanks.

DR. COHN: Bye-bye.

Now, we will take a 15-minute break, and then we will start off on our next
session.

(Break)

Agenda Item: Overview of DEA/VA
Pilot

DR. COHN: Okay. Our next session focuses on the Veterans
Administration/Drug Enforcement Agency PKI pilot. We are pleased and delighted,
actually, to have Robert Silverman from the VA coming to brief us about the
pilot. So please. Welcome.

MR. SILVERMAN: Thank you. I really appreciate the opportunity to talk about
the DEA PKI pilot.

To frame my involvement – Able to hear me there?

DR. COHN: Now we can hear.

MR. SILVERMAN: Okay.

DR. COHN: We’re sorry, but these microphones are temperamental and you need
to get close to them.

MR. SILVERMAN: Very good.

To frame my involvement, my background training is as a pharmacist and my
day-to-day responsibilities are as a coordinator of CPRS, which is VA’s
electronic healthcare record.

In terms of this pilot, I have been Hines VA Hospital’s site primary point
of contact for about 2-1/2 years – to DEA, to the prescribers, to the various
contractors we’ll talk about. So that’s the framework where I am coming from.

Today, I’ll focus on five areas. Briefly, I’ll get back on to e-prescribing
in general at VA.

If I understand, not everybody here may or may not have had opportunity to
see CPRS in action. I have some static slides to show what our daily routine of
electronic prescribing is like. We’ll talk about the pilot. I will go through
some of the steps that our practitioners face to – what I would call – enroll
in the pilot. So you can see step by step where does the information flow, and
you’ll also be able to get a sense of the security that is inherent in the
process we use within VA, some static screen shots of DEA e-prescribing
directly off of our system, both at Hines and off of one of the test databases,
and then summarize our findings over the 2-1/2 years that the pilot has been
operational.

First part to that is that e-prescribing is a day-to-day occurrence at any
VA medical center. At Hines, the CPR system has been operational since late
October 1998. So the idea of entering a prescription electronically, having it
transmitted to the pharmacy, having it received and filled by the pharmacy – in
some cases, before the patient can make the walk from clinic to pharmacy pickup
– is very commonplace, and that is, I feel, an important background towards the
changes in controlled and secure prescribing, such as the PKI pilot provides,
because that is a level of security on top of an existing e-prescribing
environment. It is not adding, oh, now, we have to prescribe electronically and
enforce the security system to it. The electronic prescribing exists, and we
are adding the security as another layer to it.

Prescriptions are transmitted whether they are controlled substances,
legend prescription drugs, over-the-counter items, and at VA, effective about
six or seven months ago, our medical-record system now also allows
documentation of any over-the-counters that a patient might be taking from
outside VA sources. So if we have a patient who is being treated in a
primary-care clinic and is also receiving their opthalmologist care outside, we
can document a complete profile, not just what is a VA pharmacy providing and
dispensing.

So we have the compete history, allergy and adverse-reaction checks against
both VA-prescribed and non-VA-provided medications, and through today’s
technologies, such as VPN, that is available routinely outside of the facility.

At Hines –

MR. BLAIR: Could I just ask a brief question?

MR. SILVERMAN: Sure.

MR. BLAIR: Because it is effecting my ability to absorb all of your other
comments here.

When you are sending this to a pharmacy, is that a commercial or retail
pharmacy or is that an in-house pharmacy?

MR. SILVERMAN: Everything I am talking about is in-house VA pharmacy. This
is a closed system. I think that has incredible bearing on how the system
functions, and, to some of the questions you were asking earlier about open
transmission of the prescriptions, this is VA clinic to VA pharmacy.

Anyway, to finish on that point, remote can mean at university medical
center, our affiliated hospital across the street, or it could be at home of
the provider using secure VPN.

What I have here are just a couple of shots to frame what it is that the
prescriber is seeing. See if that pointer works here.

This is our – cover sheet, a single-screen overview of patient care. Across
the top, patient demographics, current activity, postings allowing access to
allergy information, a current medication profile, our clinical reminders,
which is our guideline support system, and even just from this cover sheet, you
have access to what I call more detail than you ever want to know about a given
prescription – who wrote for it, when it was prescribed, when it was signed, if
it was written in – awaited an electronic signature for a little while, when it
was filled, by what route it was filled. All that information is available
readily in real time.

Across the bottom of our chart, we have these tabs, presumably designed to
mimic the tabs of a paper hard chart, and so this is a screen shot of the
medications tab, more detail of that same section you saw in our cover sheet, a
given prescription with instructions, quantity, relevant dates.

It is not just a look-up system. It is an order entry or e-prescribing
system. So the order builder takes care of the typical components that are
going to be required. Let me see where the mouse is here. Drug name, dosage,
route, schedule, whether it’s a PR in order, and, in the case of a
prescription, a day’s supply, a quantity, refills, when allowable, method of
pickup and the order to be sent.

So everything that I am showing here is what I have called the day-to-day
prescribing. This is all without PKI. These prescriptions are transmitted VA
clinic to VA pharmacy.

And then the method of transmission here is an electronic signature code.
That is a – I don’t really know all of the right security words to use for it,
but that is a single or simple signature code like a password. It is not the
systems access password, but same idea. It is a simple unidirectional code that
isn’t shared on two sides. It’s a password.

And so what we are faced with for the DEA pilot with VA is – here is this
regulation. We’ve got – regulation states Schedule II’s may only be prescribed
with authority of a written prescription, and so for everything you have seen,
we’ve got an environment where over-the-counters, legend drugs and Schedules
III through V are prescribed electronically, and one remaining pocket of
prescriptions that must be written, whether you call it grey form or purple
form or whatever color you perceive the VA prescription pad to be, ink-signed
and delivered to the pharmacy by some method. That could be foot traffic by the
provider or it could be foot traffic by the patient, but there is an inherent
delay in that transmission because the prescription has to get there somehow,
and so that is a notable pocket to an otherwise all-electronic prescribing
environment.

And I’m sure that this slide is no surprise. It is the exact letter of the
regulation that defines written prescription requirements for Schedule II.

I believe that a copy of this presentation is being made available for
everybody on paper as we speak.

With the changes to our CPRS medical-record system that are a part of the
pilot, the system is now smart enough to recognize that there is a possibility
for PKI digital signature, and since it knows that there is a possibility, it
is able to effectively block attempted entries of Schedule II medications
without that digital signature. So the screen I am showing here is an attempt
to write a morphine prescription without using smartcard and without using PKI
signature for it, and the system responds, I’m sorry, but that may not be
transmitted.

And so the first advantage that we achieved by participating in the pilot
is that there is no longer an attempt to transmit these prescriptions. The
prescribers around the room may be familiar with what drugs or what schedules
found that that is not uniformly the case and a frequent question is, Is
such-and-such drug Schedule II? or, more commonly, I entered Tylenol with
Codeine and it didn’t prompt me for my card. What’s wrong? And I have to remind
them that that is Schedule III and not subject to this.

So this was an early advantage, before we even get into PKI and secure
signature, is that the system is now smart enough to block prescriptions
appropriately that require that level of security.

I’ll talk a little bit about the pilot itself. I call it an ongoing pilot.
There was a formal review period that has ended. Gap analysis papers were
written to define all of the issues identified during that time, but the system
is still in use at Hines. We still are learning each week of new issues about
PKI certificates, what happens when you renew those certificates, and, to the
best of our ability, with the resources available, we try and continue to fix
them, and, if not, document them. So any copies of the official gap-analysis
paper at the close of the pilot won’t necessarily include everything that we
have learned to date within VA about how our system works, and the scope of the
project was to demonstrate the application of digital signature in place of
written signature when we are transmitting electronic prescriptions.

I have borrowed this from DEA’s website and the middle part here.

During the PKI test period, DEA is exempting participating pharmacies. In
this case, it is the Hines Veterans Hospital pharmacy specifically by street
address that is exempted. The little grey box there is just my reminder, I
think, that it is Chapter 1306 and not 1304, but – (laughter) – that is not
relevant to this. It’s – whatever the table is, there is a regulation that says
and there is a waiver from DEA for our participation. So that is the specific
method by which Hines is participating in a system where we do not have written
signature on these prescriptions, and I have provided the reference for that
site.

As the pilot began in October of 2002, we identified 50 physicians, based
on a report from our prescribing system of who wrote the most Schedule II’s. In
order to get the highest potential volume of prescriptions transmitted, we
wanted to find out who was most likely to prescribe those drugs anyway through
normal course of their practice.

We have selected 50, and since then, we have had some attrition. New
prescribers have asked to participate and prescribers identified in that 50
have asked to return to written prescription writing, and so, right now, we are
at about two dozen, approaching 30, active physicians using the system, again,
each day or each week.

Every time I have checked recently, there has not been a day to go by
during the week without at least one PKI-enabled prescription transmitted.

What I wanted to do here is identify the different roles that have been
involved in DEA’s pilot with VA or VA’s pilot with DEA. DEA is obviously a big
part of it, and PEC, who is DEA’s contractor, has been involved. I will
describe some of the specific roles that PEC has performed and worked with us
on that.

VA’s Office of Information, that is our software and technology department,
has had several roles in this. An office called Emerging Technologies, which is
the housing area for PKI and the infrastructure of security things. There is an
infrastructure group itself. That is our programming office that deals with
things like passwords and system access, and then, obviously, the CPRS and
pharmacy programs themselves have been modified to understand and accept
digital prescribing.

VA is separated into VISN’s. Essentially, these are regions. There are 21
regions, and each region has an information security officer. That person and
each station’s – again, in this case, just Hines right now – information
security officer are involved in the process, CPR’s coordinators, the role that
I play, and then IRM – that is our Information Resources Management Department
– has a role in the entire cycle of this, both from setting up work stations
and setting up the central server.

One of the questions I heard earlier was there would have to be a card
reader at each location where this is to be used, and that is exactly the case.
Over the 2-1/2-year course of the pilot, we have gone from zero readers at the
beginning to probably about 300 to 400 card readers available in our facility,
and I am guessing about 60 of them have been enabled specifically for the
software support necessary to utilize the DEA PKI functionality.

To get a little bit more specific about the goals, we wanted to create the
infrastructure necessary to transmit a digitally-signed prescription. Again,
that takes our kernel program – that is the medical records operating system,
if you’ll allow the analogy – the medical-record software itself, the pharmacy
software, and it takes certificates.

I call it kind of for show-and-tell, but I have a total of seven smartcards
here each of which has been a different stage in the pilot. Some of them are
inactive now. Some of them were good long enough to find a single bug and then
replaced and two of these I use on a day-to-day basis.

And we also wanted to compare existing electronic signature. What does VA
do for every other prescription on the books to a PKI-enabled digital
signature?

I would like to frame my idea of the continuum of signature methods. This
does not come from a specific security background. These are loose terms that I
use to describe the system frequently when I am trying to describe it for a
prescriber that would like to participate.

At one end of the spectrum, you have the written signature of ink and
paper. We have other systems of e-signature that are used in performing a
captured signature. Think of the credit-card machine you would use at the
store. In those cases, you are capturing an image of the person’s hand
movements. We have the electronic signature, the slide that I showed earlier,
and then the digital signature or one example of that is PKI where a provider
knows both an electronic code and has possession of a card to match the token
of that code.

Somebody asked when I was providing this before where do ATM machines get
into that level, and in terms of the amount of security, I think an ATM
machine, although it is not a chip-based technology, is approximately
equivalent to that highest level of the digital signature. You have possession
of a card and knowledge of a number to that card. In other words, two parts
necessary to execute the transaction, and that two part is going to become
important when I go through the security process that is unique to VA’s closed
system.

As I know that the hearings today have already discussed, there are three
parts that make up the security of a digital signature – the integrity of the
prescription in transmission, the non-repudiation of the author and the
authentication of the identity to that author – and the pilot system is able to
address all three of them by identifying that the prescription is not altered
when it is received by the pharmacy. The prescriber cannot deny that they are
responsible for the signature that caused that transmission to take place, and
that person is the only person who could have initiated that transmission of
the prescription.

So what I’ll go through is the process from a provider’s interest in
participation through to the transmission of a prescription.

Typically, in today’s pilot environment, a provider will contact me and
tell me that they have heard about the pilot and they would like to be issued a
card so that they can digitally prescribe and – you know – they want to ditch
their prescription pad.

So my first responsibility there is to contact PEC, and PEC locates the
provider’s DEA registration among a table they get from DEA weekly, and that
table contains, I believe, every DEA registrant in DEA’s system. So PEC is
looking, do I have a match for the provider to validly identify that we have a
name and a DEA number that match? And if they find that, they are currently
transferring it to a small database of VA participants.

When they transmit that information, they are also confirming back to me
that the record has been added, and so if I know the record has been added, I
will provide the physician with an application or a registration form. This is
a paper form at present.

The act of filling out that form verifies the identity of the prescriber. I
am asked to check a photo ID, in fact, and make sure that I know that the
person signing the form is the DEA number and the personal identity of the
named signer, and I transmit that over to our VISN information security
officer.

Their role in this process is that they have the only secure access to
generate an enrollment code. So by validly identifying that I have a known
person signing for this, the VISN security officer will return back to us an
eight-digit enrollment code that is to be delivered securely to that provider.
I try and stay out of that process, even during a pilot where a lot of things
are dealt with hands on. I try and stay out of at least one of the loops to
enforce the integrity of our system.

So I have – take Dr. Ferrer, for example. I have personally met with and
identified that he is who he states he is. He has a photo ID that states who he
is, and his DEA number is what he states it is, and, in return, he gets,
independently, an enrollment number that is unique to him.

He can then go to a website and that website will deliver the electronic
certificate to the smartcard, and that circuit is the first part of the
security. Only he is able to get his certificate on his card, and that
certificate contains essentially his DEA number.

For any of the process here, happy to address questions when we get to the
end of that. Is there one currently?

DR. STEINDEL: Yes, I have a clarification question on the one – said
resident physicians without individual DEA numbers also require pharmacy
authorization. Could you explain what you mean by that?

MR. SILVERMAN: Right. Sure.

DR. STEINDEL: Seems like a weak link in the system.

MR. SILVERMAN: In the VA, a practitioner may have their own DEA
registration or they may be prescribing under the authority of the facility. At
a certain point during the process, they are not yet eligible for their state
licensure, and, therefore, not eligible for their own DEA number. So we use a
facility-specific number and a resident physician’s specific suffix, AB
1234567-X 9876.

DR. FERRER: Under those circumstances, the resident physician is
prescribing on behalf of the attending –

MR. SILVERMAN: On behalf of the attending and under the auspices of,
essentially, the chief of staff. So you have two lines of authority that
control that.

Make sure I go the correct direction on this. There we go.

So at the website, the provider will register for a certificate using that
enrollment code, and that certificate is delivered directly to the smartcard.
That is another one of the unique aspects of it.

Earlier, we were talking about PKI being an aspect of something that is on
a computer. In this case, the certificate resides on the smartcard, so it
travels with the physician and it also isn’t left at the computer to be used by
any subsequent users of that specific workstation.

Some of the other tasks that are in our current process are for the
physician to select a PIN number to the card, and, in this case, that can be a
PIN number or biometrics – we’ll talk about that a little bit – and in the
example of this particular, out of my seven cards, get the photograph printed
on there, too.

I don’t expect you to be able to read all the fine print on there.

This is an example of one of the things we have done for the pilot. During
the transition from one brand of smartcard-specific vendor to another vendor,
providers had to re-enroll, and so this is the level of detail – whether you
consider that a lot of detail or a little detail – I was able to boil down to a
single page – and that prints a little bit nicer on 8-1/2 by 11 – what it takes
for a provider to get everything that they need onto the new card, and so that
is ane example of what type of information we are giving our prescribers to
independently be able to continue their use of the system.

And so after all of those steps have been completed – the request to
participate, the entry of the physician’s name into the database, the retrieval
of the certificate – the last step is basically for me to acknowledge in the
system that the provider has done all of that, and that is me flipping an
electronic switch to say, okay, computer, it is now appropriate for you to
accept a digital signature prescription from that given provider.

And so my opinion of what makes that a secure system is first of all that
the certificate that they have obtained on the website matches their DEA
number. The account that they use when they sign on to the electronic medical
record system matches their DEA number, and so if they are able to sign the
prescription, it is more than just a two-part circuit of completion. It is
actually five parts. They knew their access code – basically, their user name
and password – to sign onto the medical record. They knew their signature code,
the old-style one. They possess the card. They possess the PIN number or
whatever is – you know, whatever is used to unlock the card, and the
certificate on that card has not yet been revoked. So all of those things are
assured and guaranteed by a prescription that gets transmitted. If any of those
break, the prescription just doesn’t transmit in our system and it won’t go
through.

I’ll quickly run through a second set of those slides about some of the
things that might change if we were to scale this nationally among VA. Again,
it is important to note that this is still a closed system within VA. These are
not ideas of scaling nationally to private pharmacies and physician offices,
but this is scaling from single VA to all VA’s potentially using the system.

First of all, we wouldn’t need to individually identify somebody asking to
participate. All prescribers would have to be eligible by virtue of having a
DEA registration.

Secondly, they would be able to obtain the registration form directly off
of a website, not specifically that it is a DEA website, but it is some
publicly-available website, and probably appropriate that they should still
sign it in the presence of somebody who is validating their identity. I think
it is useful to have one human factor in the issuance process.

I see a question there.

SPEAKER: Could that be a notary?

MR. SILVERMAN: Could it be a notary? I would say perfectly so. Within VA,
our ISO’s effectively act in that same role.

The application form would be transmitted to the local registration
authority. That is LRA. That might still, within VA’s case, be the regional
information security officer. We still need to generate an enrollment number. I
am not tied to the specific security of it being eight digits long. Seven or
nine probably have their own validity themselves, but it is an enrollment
number that is used, delivered back securely to the participant, and the
participant would use that to get their digital certificates on the smartcard.

Another goal of this course is to consolidate this smartcard activity with
other smartcard activities, and these are all things that VA has in mind with a
project called the One VA Card – access to the grounds of the facility, access
to the parking lot, access to the buildings, access to other things that PKI is
used for, for example, secure email, in which a card should be large enough in
terms of the virtual memory to hold certificate for DEA and certificates for
secure signature and encryption of their email, and that is one of our goals is
to continue the pilot and know that we have cards that are up to that task of
having those three certificates on them and function correctly for all three
purposes.

We would still have a step required for the electronic medical record to
have – as I described it – have the switch turned on for a given prescriber. It
is important that if you are not participating in this, there is no sense for
the computer to run all of the checks necessary to see if you are going to give
it a digital signature or if you are just not going to, and that goes back to
the slide I showed. If you don’t have the switch turned on, the computer will
respond, I’m sorry. That is a Schedule II and you need to provide a written
prescription.

And this is a duplicate of the same slide. I think whether or not we have
some of the personal transmission, physicians being identified individually
– it matches on the card, it matches in our electronic medical record and
the provider has the smartcard and the token appropriate to unlock that.

So this time, these screen samples are what you would see if utilizing
smartcard and prescribing morphine prescription. This is – it is off of a
different system. I don’t remember if I duplicated the prescription exactly,
but I think it is the same prescription that I showed before. Morphine, 30
milligrams, twice daily. Same screen. You know, same entry process. Drug, dose,
schedule, route. Same electronic signature codes processed to go. That is the
simple password used for Schedule II, Schedule III through V’s, legend drugs,
and then if the system recognizes that there is a Schedule II in the batch, it
will prompt for the smartcard’s PIN number and use that to query the card and
affix digital signature when appropriate.

The system responds back to the prescriber with a statement that the
prescription is digitally signed, that is – some prescribers want to go back
and see that it worked, and this differentiates digital signature from
electronic signature. There is a certain comfort level – the provider that once
they know it works, they stop checking this each time and they know that if the
system asked for the PIN number, it worked fine.

This is a static screen shot of what the pharmacist will see on the reverse
end. They will see two lines, Processing a Digitally-Signed Order and
Digitally-Signed Order.

This is their indication that they do not need to wait for a paper copy to
come through and they do not need to expect to file a paper copy in the record
keeping. If these things appear, that is that the software has validated that
there was a digital signature on the order and that the contents of the order
now match what they were at the time it was signed. I don’t know that I could
really describe how it works internally, other than to know that there is a
hash created, and if the hash that would be checked now matches what was
created back then, the prescription has not been altered. So this tells you
that that prescription is – it has integrity, compared to when it was written.

This is more for the take-home part of the handouts. I have tried to boil
down the hardware installation to the simple steps necessary, so that we can,
within our own hardware support staff, role out more computers and enable more
physical workstations as rapidly as possible, and, essentially, it takes about
six steps – six different pieces that get installed above and beyond our
standard workstation to enable the DEA PKI functionality.

This one is, for your records, a copy of that provider’s written
application to participate in the project, and I perceive that, for the short
term, something similar to this would still continue to be used, a written and
personally-validated application to the DEA of, yes, I want to have an
electronic copy of my DEA registration on a smartcard.

So what are the findings that we have had so far? First and foremost, it
works. I have been told that that is a grand understatement by the
practitioners actually using this. They love it. They love not having to carry
their prescription pad with them. They love not having to figure out a way to
transmit the prescription to the pharmacy, either walking it themselves or give
it to the prescription (sic).

And it is not just the delivery that is received favorably. Electronic
prescribing in our medical record ensures a complete prescription. You cannot
transmit a prescription unless it has a quantity on there. You cannot transmit
a prescription without a schedule or, effectively, a set of instructions, and
so, whereas, you had the III through V’s and non-controlled substances all
being checked by the system, now, we have Schedule II’s being checked by the
same thing and you can’t write out a half-complete prescription and try and
transmit it. So you have that.

You end up with one-stop shopping for handling all prescriptions in the
same manner, and there is an economy of scale to the pharmacy as well. There is
reduced storage of the paper prescriptions necessary because you have the
electronic copy. Our files are backed up through the regular routine backup of
every other prescription file. You don’t have to keep the boxes of – in this
case, it would be the prescription stamped with the red letter C and all the
things that are traditional to Schedule II controlled substances.

Some of the things that we have solved during the pilot, we have had a
transition in smartcard type. Again, that’s my pile of seven here. We
completely changed vendors of smartcard and have successfully navigated through
that transition and the issues that it raised.

We have had a change in the CA. There was a new sub-CA that came on board
during the pilot and we had a successful transition through that where the CA’s
might be entities that you recognize. There was an EPC SCA, the e-prescribing
for controlled substances certificate authority, and that has been superceded
by a CA called the E-Commerce. It is essentially two computer systems
performing the same role, but we have navigated through that transition.

We have had two changes in the software used to read the cards. Those have
been navigated successfully, and one of the components that is used on our
workstations is called the COM object. Effectively, that is the little bit of
software that tells our medical-record system to look for a smartcard, and I
think we have gone through 10, if not more, updates through that, as we find
issues, and that is now stable since last September. We haven’t had need to
change or other changes from external sources on that particular piece of
software, and we use one that was created in September ‘04.

We had issues that we faced where if I went to a clinic office and I
activated a workstation it would work for that prescriber who was in that
clinic on that day of the week, and we have now successfully made it so that it
can work for anybody using that room.

We have worked through an issue called PIN caching, which goes back, a
second time, to the topic of is PKI something that is a token present on a
computer and there for the next person to access, and, in this case, the system
we are using allows PIN caching. If you put in your PIN number once, it can
save it for a specified period of time. We have gone on the level of what I’ll
call extreme security. We have lowered that to one minute. What that does for
you is that if you are writing two or three prescriptions on the same patient,
you can authenticate the card a single time and you don’t have to authenticate,
okay, here is the morphine for PR and Breakthrough. Here’s the Fentanyl patch.
Here’s the other prescription. You don’t have to enter a PIN code for each of
those, but in the time it would take to get to a next patient, it will ask
again. So the card and the authentication to the card are continually
challenged.

And working through the process even forced the VA to reevaluate our own
drug file in the computer system of what defines a Schedule II drug. We
uncovered a need for clarification to that, and this project has helped us fix
that up, so that Schedule II really defines Schedule II and not inappropriately
defines narcotics. I heard one of the practitioners talking about the
non-narcotic C2’s, and we kind of got that in line as a result of the pilot.

We have had some experience testing biometrics. There’s a particular
vendor. I am not endorsing nor criticizing any specific vendor by this. These
are just examples of pieces of equipment available in the industry.

We used one smartcard reader that is the precise MC 100 model. It’s got a
little glass chip that is a fingerprint reader in there, and there is something
unique about me. I was the only person in a room of 20 people who had trouble
getting a fingerprint to take on there, but since I was the site point of
contact for this, that was enough to effectively put a halt to that.
(Laughter).

We did some testing at the medical center, and we found that the longer a
provider had been at the hospital, the better their chance was that they would
get a good fingerprint take, and we wondered if – you know – enough hand
washing over a career had something to do with it. (Laughter). Whatever it was,
that particular model didn’t work.

There’s another example. I saw it at a VA conference, effectively the
trade-show side of the conference, a brand name called Identex Biotouch(?). I
am in no position to endorse it. All I know is that I walked up to the vendor
demonstrating that model of fingerprint reader. First time, worked for me. So
there is either something unique about me or there is something unique about
that reader that in the year-and-a-half between the initial pilot and when I
saw that, fingerprint readers have improved in technology. I think the latter
is probably the case.

We’ve got some gotchas where the level of access to VA computing systems
necessary to participate is a little bit higher than what Office of Cyber and
Information Security would really like the everyday practitioner to have. It is
a level called PowerUser, and that is a level of computer access that we are
not really comfortable with handing out to all practitioners and all
prescribers, but the current infrastructure requires it, and so it is a lesson
learned and a lesson that can probably be solved between now and national –

And, right now, we are tied to a specific smartcard vendor. We have already
learned this once, that if you change smartcards, you have to change a lot of
the guts that work on the way through. We know what those are, because we have
gone through it once, but if, for whatever reason, we were to move to a third
smartcard vendor, we would have to move to a third iteration of all those other
things. Those are just some examples of things we have learned about the pilot,
that you can’t deny it works right now, but it works because we have a fixed
set of equipment and circumstances put together.

The security needs for a certificate that is used in a DEA prescribing are
a little bit different than the needs of a VA email certificate. My email
certificates can sit on my computer workstation in the office just fine, and
when I want to sign and encrypt an email, it asks me for my PIN number and I
put it in, and I can set it up so that if my card is there or not there, it
still works. It is not a smartcard-dependent process.

The DEA pilot has been set up specifically to be a smartcard-dependent
process, so that you carry the one copy of the certificate with you. You don’t
leave it on computers all around, and that is a situation where the software
used to operate these systems is much more commonly designed. Its defaults are
based on, I work at a desk in an office, and so we have to change some of those
defaults away from standard to, I work in a clinic where I might be in Room A
or Room B or Room C at any given time, and I want my card to work effectively
in all three of them.

We tried a little bit with card-based log-on to the network. There might be
some time savings there. I think the bigger savings is that it is easier to
remember your PIN number to the card than it is to remember your password to
the system, and the savings are probably more so from that than anything
claiming to be a time savings of using the card to access the computer systems.

I am accused sometimes of living in an idealistic world. One possible
future model – and this is Rob’s words only – is an idea where a DEA
registration website would be a place where you would renew your DEA
registration, and if you had a smartcard reader capable of doing so, right when
you are doing that, you could get your certificate at the same time. I don’t
think that is out of the bounds of possibility. It is just out of the scope of
what we are dealing with right now, and a possible goal to aim for that DEA
registration renewal and certificate provision are one and the same.

And I see a couple of copies of the handout. So you have my phone number
and email for followup and questions after today’s session.

That is the conclusion of what I have formally.

DR. COHN: Okay. Well, Robert, thank you very much for, I think, a very
interesting session. I can see – I think, everybody has their hands up here and
we’ll sort of go around here.

I guess I just wanted to start out with just a question and just sort of a
clarification from my view.

I noticed that you had been testing PKI with a smartcard, and I think what
I heard from you was, I think, sort of a frank admission that biometrics are
going to be extremely user-dependent, and, like many things in the world are,
maybe not quite there yet – this realm, and I do remember – at least my
understanding of Peter’s testimony by the DEA was they appeared to be
suggesting some sort of a combination of biometrics plus PKI. So I guess – am I
right that I am sort of hearing from you that smartcard plus PKI appears to
have been tested in the VA? I don’t think you make any statement that the
biometrics had really been tested or were ready to go.

MR. SILVERMAN: Sure. And I don’t deny that having me be the particular
person who had trouble with a fingerprint may have had an impact, but it had an
impact nonetheless.

The software that we used at the beginning of the pilot was a program
called Passage. It is an RSA security program, and RSA is one of the standards
out there, and Passage had a setting for smartcard authentication that you
could authenticate with your PIN number or you could authenticate with a
biometric fingerprint or a combination of the two. It was intended for the
pilot that we would actually test all three of those scenarios – PIN number
only, fingerprint only or both – and as soon as the fingerprint became a
non-issue, all subsequent testing at VA has been card plus PIN number.

DR. COHN: Okay. Thank you for the clarification.

So Judy, Harry, Steve. Jeff, you had your hand up, too, didn’t you?

MR. BLAIR: No.

DR. COHN: What? (Laughter).

We’ll go with Judy.

DR. WARREN: I am concerned that, initially, you had 50 physicians in this
pilot. When it was over, more than half of them dropped out and asked to return
to paper, and, currently, you only have two dozen with some new people coming
in. So my question is why did 25-plus physicians request to go back to paper,
and then what was the motivation of new physicians asking to join in this?

MR. SILVERMAN: Of the 50, there is a portion of that, I will guess about 15
– I know I have access to look up the exact numbers. There are 15 that never
got off the ground, never got started with it at all. So they were out by
virtue of – in one case, a prescriber that just declined participating from the
start. A couple of them were hematology/oncology fellows who were identified
among the 50 and we got everything set up for them, and before they did the
first certificate issuance, concluded their rotation and resumed service at
Loyola University Medical Center instead of at Hines. So the number of dropouts
is not the 25 to 30, but I would say we probably had five to seven actual,
thank you for letting me try this. I am not going to use it anymore, and that
is uniformly a factor of the physician’s level of comfortability with
computers. This is by no means the world’s easiest thing to just get a card and
dip it in, and it is much easier now. Some of them would probably start now and
have better success than with the system as it existed in October of ‘02.
We have come a long way.

The people that want to join are the supervising attendings who have large
resident clinics where they are supervising pharmacists, PA’s, nurse
practitioners, where they have a lot of prescriptions that they are supervising
for the PA, pharmacist, NP, where in the paper system, somebody would be
recommending, okay, I have just seen – and the same is true for resident
physicians – I have just seen such-and-such patient in clinic. I believe they
need these prescriptions. One of them is Schedule II. You are going to have to
write that one and I can put the rest of them in the computer for your review
and signature. So they like it because they want to do the one-stop shopping as
well –

DR. WARREN: Okay.

MR. SILVERMAN: – and that is what prompts somebody to join.

DR. WARREN: Okay. And, then, did I hear you right that not every terminal
could accommodate the smartcard –

MR. SILVERMAN: Yes.

DR. WARREN: – and that was a terminal specific? So if I am a prescriber and
I am writing a bunch of prescriptions and I suddenly get this message, and I
have to go find an appropriate terminal that I can do that in if I am going to
do it electronically?

MR. SILVERMAN: As it stands today, exactly correct.

DR. WARREN: Okay. And then just – if you can give us a ballpark about how
much extra time does it take you to set up that terminal.

MR. SILVERMAN: I’ve gotten it down now to – if I am going to do it, and,
again, I have a familiarity with it that is not uniform.

DR. WARREN: Right. A knowledgeable installer of a terminal.

MR. SILVERMAN: A knowledgeable installer of a terminal can do it in under
15 minutes.

DR. WARREN: Okay. And then this whole process you had for registering the
people seemed to be pretty ornate to me. How much time did that take, and
resources?

MR. SILVERMAN: Originally, the process was probably – let’s see, what are
we dealing with? I would say in October ‘02, you’d be looking at about a
one-week turnaround. What we have got it down to now is that there is still a
one-week turnaround, but there is some lag time in there, and the lag time
comes from the fact that within 20 minutes, I can get a provider, confirm their
DEA number, get the thing signed, check their photo ID, all of that goes,
acknowledge to PEC that we’ve got a prescriber that wishes to participate. They
can confirm back, but they are only providing that database update to VA once a
week right now. So if you asked me on a Friday, I would like to participate, by
Friday, before we leave work, you are ready to go, and I’ll give you your card
next Thursday on the same day that the database comes updated.

DR. WARREN: Okay. And you were talking about scalability, which I thought
was a wonderful thing to add at the end. You know, you were basically dealing
with only 50 physicians here, and you start talking about some of them never
got off the ground, some of them didn’t make it through rotation, and
especially in an academic medical center, what kind of support do you think you
are going to need if everybody who has the ability to do Schedule II
prescriptions is going to be needing these kinds of smartcards?

MR. SILVERMAN: The one thing that would address that the best is, right
now, there’s the process on the website where you go and enroll for your
certificate, and that could be done at any of the enabled workstations.

I didn’t go into each of the specific issues and bugs and gotchas, but one
of the issues is that if you do the enrollment at a workstation, there is some
extra cleanup that may occur about a year later that needs to be done, and so
an ideal situation would be where you go to pick up your enrollment number and
pick up your card and get that physical stuff would be a bank of computers
right there for you to do your registration, and you do your registration right
there, and all you are walking away with is your card that’s got your
certificate on it, and you know the PIN number to it because you just set it
up, and in your pocket, your envelope with your enrollment number, in case you
have to do it again, and you do that in a controlled area, and that would
resolve a lot of the problems we had in the early going is if setting up the
card was something you did, you know, kind of in the room next to where you
turned in your credentials.

DR. WARREN: Okay.

DR. COHN: Okay. Harry.

MR. REYNOLDS: You didn’t mention how doctors do refills.

MR. SILVERMAN: Schedule II’s don’t have refills, so we have not addressed
that at all.

MR. REYNOLDS: I am not a pharmacist, so I didn’t understand –

MR. SILVERMAN: Okay. Yes, that is a requirement of Schedule II
prescriptions that they are non-refillable.

MR. REYNOLDS: Okay. If you step back from your – what you call PKI and
everything, you are really talking about a certification process, a clear and
precise certification process. You know who the person is and you have all
agreed that they can do it.

MR. SILVERMAN: Right.

MR. REYNOLDS: And then you are talking about two-tiered authentication.

MR. SILVERMAN: Card and possession of it to open the card.

MR. REYNOLDS: Yes, or – yes, which could be a token, which could be
whatever you want it to be.

In other words, once you set it up as a two-tiered, philosophically, you
are talking about two tiers. You are using a smartcard or some people could use
biometrics or others could use – so it is basically that whole idea of a clear
and precise certification and a two-tiered authentication.

MR. SILVERMAN: Right.

MR. REYNOLDS: Which is the same thing on an ATM or anything else – So since
you are a closed system, which you were talking about you like to live in a
happy place. That is a happy place.

MR. SILVERMAN: Yes. (Laughter).

MR. REYNOLDS: Closed systems are happy places.

MR. SILVERMAN: Right.

MR. REYNOLDS: Get real ugly when you get – So you have heard us discuss – I
think – Were you here earlier this morning?

MR. SILVERMAN: I came in during the – about the midpoint of Mr. Mapes’
presentation.

MR. REYNOLDS: Okay. You heard us discussing the whole process of it goes
from the physician through a vendor to, possibly, another vendor, then to a
switch and then to the pharmacy.

MR. SILVERMAN: I did.

MR. REYNOLDS: And you have – obviously, with a closed system, you have a
single format.

MR. SILVERMAN: Um-hum.

MR. REYNOLDS: You don’t do any translations.

So since you do have experience and since you have been on the ground with
this in reality, how do you see even your process – if you stepped outside a
closed system and you had multiple players, how do you see your process working
and how do you see the integrity from start to end staying in place?

MR. SILVERMAN: Okay. I don’t think I understand the question –

MR. REYNOLDS: Because it works great in a direct transaction.

MR. SILVERMAN: Um-hum.

MR. REYNOLDS: As soon as you get middle players, that is where it kind of
starts coming apart.

MR. SILVERMAN: My security background has all been gained as a result of
this process.

One of the things that – even in the closed system – is useful to us –
Let’s see if this will get me to the right place. This slide here is where I
described our closed system. We are getting an integrity check that is the
process that creates a digitally-signed order to appear on the screen. That
integrity check is what I see as the important part of transmission in an open
system that, in some way, not only is there a prescription being transmitted,
but something checkable. We’ll use like the phrase check digit or check sum,
probably more complex to that, in terms of all the fields of a prescription,
but two things going on their way through, and any alteration to one would show
up in the other.

So what I see for that – and I am addressing the question you are asking –
is that the pharmacy and the standard – the standards designed to facilitate
this electronic transmission would have to settle on what is our – first of
all, what is the format of allowable transmission, and then each pharmacy
system looking to accept it in would adopt that format in terms of, I know,
according to the standard, how to verify the integrity of the prescription on
the way in, because there is potential for those packets to be intercepted over
whatever these open transmissions are – call it the internet, per se – and as
long as they can be validated against what it was at the time of transmission,
that is what I see to be the case is that the receiving pharmacy will have to
adopt a set of standards of how do I know what to check.

MR. REYNOLDS: So, using your screen there, it could – philosophically, when
that screen came up, it could show four digital certifications, if it went
through four other people, or somebody could own that and you could audit them
knowing that they would have – other words, somebody got it from the doctor. So
that is your original start. Then that vendor sent it on – okay – and at some
point they have to say it was okay and now I got it. I’m in charge.

MR. SILVERMAN: Um-hum.

MR. REYNOLDS: And then it goes to the next one and they translate it. They
said, I’m in charge. So, at some point, the pharmacy has to decide who is in
charge, because the whole point of this thing is that it used to walk in with a
signature.

So I am not asking you to design it. I’m just trying to understand any
non-closed system. If there is a succession of I got it. I’m verifying it, and
the original thing from the doctor still comes through, but everybody else kind
of checks it – I got it. I got it. I got it – and that pharmacy – I don’t know
how that works, but that whole digitally-signed says somebody owned it. They
owned it under your certification, because you are the keeper of the
certification, and it got to you and that wasn’t tampered with. That is what we
are – right? That is kind of the process.

MR. SILVERMAN: Part of the – even in the closed system that provides this
statement, digitally-signed order – is the prescription came through with the
digital signature affixed to it. That is just a string of characters and codes
and stuff that come through. It also has to go out and check against what is
called a revocation list or a revocation authority. Is the certificate used to
sign that still valid? So, for example, if you ordered a prescription yesterday
– yesterday morning – and yesterday afternoon you were found convicted of fraud
in prescribing from a case that has just completed and your certificate gets
revoked, the system is going to check that and it is going to say, there is no
valid certificate behind what signed this thing, and that is actually a
failure, even though it was validly signed, it was signed by something that
wasn’t valid anymore.

MR. REYNOLDS: So that speaks a little bit towards if you had a DEA number
or something else focused on it, then you have a national place to check –

MR. SILVERMAN: You have a national –

MR. REYNOLDS: – regardless of where you are and how many steps it goes
through.

MR. SILVERMAN: You have a single standard to check, and I think the other
part to that is we are a closed system. Point A to Point B, that is all you
get. It probably is appropriate to say if the pharmacy system is checking its
immediate predecessor – that is a vendor in one of these cases – that is what
it is responsible to check. Check that last part. Everything else is chain of
succession –

MR. REYNOLDS: That is where I was going. So if there is an audit trail
through the succession –

MR. SILVERMAN: The last one becomes sufficient.

MR. REYNOLDS: Okay. So that digital signature may be from RX Hub –

MR. SILVERMAN: Um-hum.

MR. REYNOLDS: – or may be from somebody – not necessarily the physician,
which is different than now, because you have to have the signature for that.

Okay. Thank you. That’s helpful.

And, again, we are not – I am not asking you –

MR. SILVERMAN: Yes, I can’t design it.

MR. REYNOLDS: I’m not asking you to commit to it. I’m trying to understand
–

MR. SILVERMAN: No.

DR. COHN: Okay.

MR. REYNOLDS: Since you are alive and well and have done it.

MR. SILVERMAN: Right. All you need to do is ask me to test it.

DR. COHN: Okay. Well, I think we have Steve as the final, and then we’ll
break for lunch after that.

DR. STEINDEL: Yes, Simon, I’m standing between us and lunch and I’m hungry,
so I am going to turn this more into a comment than I will a question.

But what I have observed during your presentation is, first of all, there
is a rather limited number of physicians who are involved with this, and I
assume there are much more than that at Hines who do prescribe controlled II
substances.

I would also assume – I think you made the comment that you see – and not
one week goes by without seeing a controlled substance ordered using this
system. So I assume there’s a lot of controlled substances still ordered by
paper at Hines.

Then I also observed, like Judy commented on, a really rather elaborate
certification and maintenance system on this – card readers that need to be
swapped out, changed, changes in software, et cetera – and this is in a closed
system at one VA, and then I am trying to project this as it goes out to 172
VA’s, thinking about the problems that we may be seeing – you know – passing
this through 172 VA’s.

And then getting into Harry’s question, where we don’t have a closed
system, and we are introducing whole new –

As to what – and I am trying to picture what could be the cost benefit of
going to this type of system over something that is going to be less elaborate.

The comments have been made in the past – and I have been one of them that
makes it, because CDC runs a closed PKI system – is that, in a small
circumscribed environment like you are working in, you can operate a PKI
system. It takes some overhead – sometimes, some substantial overhead – but the
extrapolation to a non-circumscribed system is very difficult, and that is just
my observation.

And, Simon, if we could have just a comment back, but, you know, as Simon
indicated, we would like to be brief.

MR. SILVERMAN: I’ll be extremely brief about that.

In your final comment of that, you described the term overhead, and that is
how I perceive the progression from late 2002 to where we are now. Initially,
it was an hour setup or we found a bug or it didn’t work, and all of that has
gotten down.

Each of these are effectively one-time things. There has been a turning
point at which the system became stable and we can add practitioners and add
workstations ad lib, and so, for that one facility, a huge learning curve, per
se, to get to that point. The second facility won’t have to go through that.
Still closed 140-170 VA’s depending on how you like to count us. Second system
can go straight on from there. Third system can learn from there that by the
time you really are scaling it is a single day or a single week or however you
want to manage your hardware rollout. Roll it out, get everybody authorized and
then you are stable for a year or the expected validity of a certificate, which
is a year or until your DEA registration expires, whichever comes first.

DR. COHN: Which is three years, as I understand.

MR. SILVERMAN: Correct. It’s three years, but it might come up on – you
know – within the one year.

DR. COHN: That’s right. Okay. We will continue this conversation.

Now, I am going to suggest we break for lunch. I am going to try to get us
back on schedule by starting at one o’clock. So it will be a slightly
abbreviated lunch, but Steve knew his last question was between us and lunch.
So – Anyway, we’ll be back at one o’clock.

MR. SILVERMAN: Thank you for the chance to speak.

(Luncheon recess at 12:15 p.m.)

A F T E R N O O N S E S S I O N (1:25 p.m.)

Agenda Item: E-Signature:
Authentication and Non-Repudiation

DR. COHN: Our first afternoon session is really, I think, a chance to talk
to the industry again around all of the issues related to authentication and
non-repudiation, and we are obviously delighted to have you joining us to talk
some more about it. I think we have all really had a chance to – hopefully –
get a little smarter and learn a lot, both in previous hearings as well as in
the sessions this morning. So we are obviously delighted to hear more about
your thoughts as they have progressed.

Now, I think we are going to be – are we going to be going per the listing
here? Yes, I think, right now, we have David –

MR. MEDVEDEFF: Medvedeff.

DR. COHN: Thank you. Florida Medicaid start leading off then, and then
we’ll go from there to – and then Jack Guinan, Mike Simko and David Kilgo.
Okay. Well, thank you. Please.

MR. MEDVEDEFF: I’m David Smith. (Laughter). My name is David Medvedeff, and
I am Vice President of Clinical Programs for Goldstandard.

Again, thank you for the opportunity to present.

A few months ago, at one of the committee meetings, we gave you an update
on what was happening in Florida Medicaid, and, specifically, what the program
looked like and how it rolled out.

So, today, what I was asked to do is provide a high-level update on where
we are at in Florida Medicaid and then speak to the fraud-and-abuse
authentication and non-repudiation issues.

First, I would like to speak on the update on Florida Medicaid and where
that program is at.

If you recall, at the first meeting that I testified, this program started
in the summer of 2003. It was targeting 1,000 of the highest Medicaid
prescribers. It provided Medicaid’s preferred list, a clinical-drug database
and a 60-day prescription history at the point of care for high-volume Medicaid
prescribers in an effort to enable that doctor to make better decisions having
good, sound clinical data specific to that patient, and, more importantly,
irrespective of the other prescribers caring for that patient, driving better
continuity of care.

Because of the results we had in the first phase of this program, from 2003
to 2004, and the return on investment, both clinically and financially, that
the state recognized, the program was expanded in late 2004 to include 3,000 of
Medicaid’s highest prescribers. It was also expanded to give that
prescription-history view from 60 days to 100 days, and this was done to give
the doctor a seamless clinical view of that patient’s drug therapy from visit
to visit if that patient had a chronic need. So the doctors – Medicaid were
telling Medicaid and telling Goldstandard that they see their patients every 90
to 100 days, and if they could see a seamless view of that drug history, then
this would be helpful, and the program was also enabled to include electronic
prescribing.

So what is the status of the program in Florida? We currently have 1,500
doctors registered to participate. We have 1,300 active users, 1,300 PDA’s out
in the community being used every single day, and we are adding about 200 to
300 doctors every month through the balance of the spring to bring this number
up to 3,000 total providers in Florida using electronic prescribing and
technology at the point of care.

All of the prescriptions that are being routed today electronically are
going through SureScripts, and we have also enabled this to include a
multi-payer source. So, now, the doctor sees not only Medicaid fee-for-service
patient data, they also see Humana patients, Staywell(?) patients and other
payers that we are working with, so, essentially, taking all that data from
multiple sources and pushing it down to the point of care.

Some of the other developments – just giving you a high-level background on
what is happening in Florida – about six weeks ago, Florida announced a new
collaborative that has been developed. It is known as the Florida Behavioral
Healthcare Collaborative. This is focused on educating prescribers,
particularly in the mental-health arena, on the appropriate use of medications
in trying to drive better continuity of care between the general practitioner
and the specialist. Goldstandard has been brought in to be part of this with
Florida Medicaid leveraging technology to do this through electronic
prescribing.

Everything I have just described to you, as far as the rollout of this and
how this is being implemented in Florida, will also take place now in
Mississippi beginning next month, and we are in further discussions to
incorporate all the lab data around Florida Medicaid and potentially in
Mississippi, to start pushing out labs along with electronic prescribing.

So that is the update, and what I would like to do is take a few minutes to
speak to the issues of fraud and abuse, authentication and non-repudiation.

When I was asked to testify, I really wanted to set the scope, because
fraud and abuse, in particular, in the Medicaid world, takes on a totally
different scenario than fraud and abuse in the technology world. So fraud and
abuse can be viewed either at a patient level, at a prescriber level, at a
pharmacy level or it can go as far as identity theft, which are some of the
issues around authentication; and the non-repudiation is really focused on the
integrity of the data and the confidence that when the data leaves the doctor’s
hands it is the same data that gets to the pharmacist’s eyes in the pharmacy.

So let’s talk about patient-level fraud and abuse. This is your traditional
view of patient-level fraud and abuse, and what we have on this slide is one
patient who received about 15 or 16 narcotics in the span of about 60 days, and
before technology, this was very easy to do, to gain the system – in a Medicaid
program, in particular – and, now, using technology, doctors at the point of
care can identify fraud and abuse at the patient level.

This is a slightly different view, and this is an HIV patient who, again,
on 30 different medications, but what you don’t see in this is that, now, a
doctor at the point of care can identify that the patient is receiving a
therapy they did not prescribe, has a very severe drug interaction with their
current therapy. It is coming from a different doctor, and what it turns out,
in this case, is that this was the partner of an HIV patient who was using,
fraudulently, their Medicaid plan to pay for their partner’s HIV medication.
So, again, defrauding the system, and technology now can enable that.

And then we get to the issue of identity theft, and this is actually an
email that was sent to me by a pharmacist that works for Medicaid out in the
community, and what this email basically is describing is that, now, using
technology at the point of care, this doctor identified that a patient stole a
prescription pad and started writing themselves and their friends
prescriptions, and the doctor was receiving this data on their PDA.

So when you get to the issue of fraud and abuse, I think, technology almost
enables kind of a check and balance in a system which may be more useful than
worrying about the authentication aspect on the front end, and I’ll speak to
that in a couple of minutes.

So addressing authentication – and what I would like to do is just really
shed light on how we address that in Florida.

The user-name and password issue is only handled by the end user. So only
the prescriber that is using the application can change or manage their
password. The way that happens, all of our provisioning and training of the
device and training on the application is done face to face. All of the data
entry, as far as user name and password, is done electronically only by the
prescriber, and none of that data is stored on any server that we have access
to, that the state has access to, and the only way that user name and password
can be identified is using our partner, Verisign, through one of their hosted
facilities.

We go as far as if that doctor calls our help desk, the help desk can
identify the doctor through demographics, can ask a challenge question and
challenge answer. The doctor has to first choose the right question and then
the right answer, and then we can provide hints around that password, but only
that provider can select that password, and if we come to a point where they
cannot remember their password, we start all over again, and the doctor has to
reissue a new user name and password. It is the only way that we are
comfortable, kind of in an ivory-tower sense, that that doctor is the only one
who knows what that user name and password is.

Now, let’s get to the reality. We get PDA’s returned that have a cracked
LCD screen, and you flip the PDA over, and, literally, scratched in the plastic
is the doctor’s password.

You walk into a doctor’s office, and the doctor signed all the
documentation saying they understand how important securing this password is,
and they actually have thumb-tacked on the poster board behind their
receptionist their user name and password and the application.

So, the industry, as a whole, takes user name and password very seriously
and the authentication issue very seriously, but it has bene our experience,
working with, now, almost 3,000 doctors, that some take it very serious. Some
have their entire system and operations in their practice setup, so that all of
their peripheral support is using the application.

Now, to the issue of non-repudiation – and I am not going to belabor this
point, but, really, this is taking the data that is within a secure
transmission and further encrypting that, and so what we have done in Florida
is we have actually implemented a PKI solution. Now, this is only carrying the
water part of the way, and what I mean by that is to have true end-to-end PKI,
you have to have PKI from the vendor perspective, so when that data gets
transmitted from the doctor’s hands to our server, we have to be able to read
that and authenticate that message. From the vendor to then the gateway, you
have to have a PKI in place, and then from the gateway to the pharmacy, you
have to have PKI in place.

Today, I would argue that the vendors are probably the most nimble in being
able to implement this as we have, but I could tell you that the reality is I
don’t know that the Titanic is going to move that quickly. So probably a bad
ship to use there. (Laughter).

So, you know, the reality is the end-to-end adoption, as I said. I believe
if we come to – as an industry – we come to the conclusion that PKI is the only
way this message can be taken from the doctor to the pharmacist, it is going to
slow this uptake that we are starting to see across the industry with
electronic prescribing, the use of VHR’s and EMR’s, and there are other
solutions out there, and what I mean by that is, now, the doctor has new data
in their hand, and that is claims data. So I am a prescriber and I write a
prescription for Drug A, I get feedback that Prescription Drug A was the one
received at the pharmacy and it was received for this patient. You could argue
that is almost non-repudiation. You didn’t necessarily have to have a very
robust technology to non-repudiate that the message that was sent was the same
one delivered, but when you send the message back to the doctor that says, we
received Drug A and we filled it for Mrs. Smith and it was exactly the way you
prescribed it, the doctor knows that – in real time – that message was there
and it was exactly what that doctor intended to write.

So I think the use of SSL, the use of the secure transmission ports and
also the use of this new feedback data that otherwise wasn’t available before
technology is one way that we could allow this industry to mature before we put
in these guidelines that are very restrictive.

And that is my presentation. Thank you.

DR. COHN: Thank you, David. Thank you very much.

Jack.

MR. GUINAN: Yes. My name is Jack Guinan. I am the CTO of ProxyMed. Thank
you all for having me again.

For those that don’t know me from previous times here – we have about 4,000
physicians doing e-prescribing on our network – I am going to speak to, again,
authentication, non-repudiation and give you all a sense of what we are doing
along those lines from a very pragmatic approach.

As far as authentication goes, the way we look at it, how do we know the
person sending the transaction is, in fact, the person that we think that they
are?

We do this through a set of business processes and then common access
controlled methods.

I am going to go through – I have passed out – I’m sorry I don’t have a
Power Point Presentation, but I have – I believe they passed out a written copy
of the testimony.

The steps that we go through to allow folks to use our network are as
follows: When someone – a physician’s office and a prescriber wants to use our
network for e-prescribing, they are required to fill out a registration form
and send it in to us, a physical form, with their practice information,
physician information, and this includes DEA numbers for physicians that want
to be registered on the network.

When we get this information from the practice, we bounce the information
against the DEA database. As someone mentioned earlier today, we also get this
on a very frequent periodic basis, being updated. We match all the information
we get from it. As well, then, we call the practice, and we also verify the
rest of the information. So there needs to be a physician’s office that truly
exists like on the piece of paper at that phone number answering the questions,
and we have a script that the folks in our office use to figure out that, in
fact, it is the physician’s office.

Once this is complete, we assign our own unique identifier to both the
practice and the prescribers at the practice, and these are given out to the
end users. These ID’s are entered into the software that is going to be
creating and sending the e-prescribing messages.

So, then, as this practice who has been – I’ll call it certified or
credentialed by us and given access to the network, when they send their
messages with those ID’s, we look at these messages and make sure that the ID’s
do match up in our database, that they are registered and that the information
in the message matches the information to those ID’s. I’ll get into the fact
about opening the messages in a minute with the non-repudiation, but we do open
the message, look, and the name of the clinic and the address inside the
message needs to match what was in the registration information.

We have, in the past, implemented various tokens and other ways to know
that the computer that was sending the message was, in fact, a computer that
was registered, but I’ll address that in a second as well. Those didn’t fare
too well, as computers changed quite often. So we rely on the fact that we
getting a message with ID’s that we know are valid ID’s and were given to an
entity that we manually and over the phone and spoke to people recognized as a
person that was okay to send prescriptions to the network.

If we are sending these prescriptions on, then, to another network, this
does not follow through to the next network, but we are then authenticated by
that next network in line. So the onus is on the first network in the line
really to authenticate who the practice is and the physician.

When we send the message on to the pharmacy directly and not through
another network, like to Walgreens, who is present here, Walgreens relies on
ProxyMed that we have done this authentication. They’ll speak to their own
authentication, but, basically, we have a system in place with log-ins and
passwords that they know that it is us, and, in effect, are trusting us that we
are fulfilling our obligation to make sure we are only accepting prescriptions
from someone that we are supposed to be. So there is this concept of trusted
entities that I’ll get into as well. So that is how we perform authentication,
how we certify folks to use our network.

Once we do get prescriptions, then, how do we know that – or there is a
question raised, how does the pharmacy know that the prescription has not been
altered once it is sent by one of these entities?

Well, the reality is is that – and, as we have told this group in the past,
we actually do alter just about every one of the messages that comes through.
NCPDP script is a young standard and not everyone is on the same version, and
there are slight differences in implementation. So I would say that probably
100 percent of the time, when a message comes in, we open the message. We look
who’s sending it, where is it going, what format are they both on and what were
the predetermined business rules that we established with our trading partners
and agreed to up front to say we are allowed to do this sort of mapping between
the various formats.

We do sometimes – besides reformat, there is a requirement to, in fact,
change content of messages. Not everyone has implemented the same code sets on
both sides, and so not for things like drug – we never change the drug that is
being sent, the sig, but there are certain qualifiers in the NCPDP script
message where people are using a one to stand for something instead of a two,
and we have agreed, well, we’ll change it later, but just map – everyone who
sends a one in this field, map it to two for us, and so besides just the format
of the message – not on every message, but on a good portion of them – there is
some amount of the content that’s changed. So, in fact, we wouldn’t pass that
test, and so that is one of our big concerns is that whatever is adopted here
recognize the fact that today – and I believe this is the case with other
players in the industry – but, today, for ourselves, to operate our business,
we are required to actually modify the messages as they go through. So we would
really like to see the – whatever is implemented here not restrict us from
doing that. I don’t know how we would operate if we were not allowed to
actually act upon the messages that came through the network.

And so I believe the way that we are getting around this and the way that
the trading partners in the chain are okay with this is that we have contracts
in place between us, trading partner agreements, that set forth what our
various service levels are, what our warranties are, what our liabilities are,
and we have established operating procedures, interface specifications, again,
what we are allowed to map and not, what we are required to actually reject at
our network. So, sometimes, we might get a message into the network and when we
open it up it doesn’t comply with what one of our partners want, and they say,
don’t send me a message that doesn’t comply with what I want. Sometimes, at the
clearinghouse, we actually reject messages back to the sender, because we
weren’t able to map them to where they went, and we do this under contract with
our trading partners.

And so if you – for those of you who have this on page three of the
document, maybe to follow easier, there is a little picture, but, as an example
of how complicated this gets, there is a situation where you might have a
medical-manager physician using a handheld in their office and they are writing
the prescription. Well, that prescription is traveling from the handheld, first
of all, to a centralized computer in their office. So it doesn’t go
straightaway out of the office. That computer is hooked up to the Web MD
Network. So there’s an interface there. The Web MD Network, in turn, passes
that prescription along to our network. Now, I am not going to speak to what
they do, whether or not they open or modify the messages, but when it gets to
us, like I just said, we do that. Well, if this prescription is going to
Publix, for instance, it goes from our network to eRx’s network. They are an
aggregator, a network provider, the same that we are, more so on the pharmacy
side. The eRx network does open, and, again, modify again the message to what
they have to with their trading partner, Publix, and so then eRx sends the
message on to the Publix central host system, which, in turn, then, passes the
message along to the in-store systems at the end of the chain.

So you can see in this one example – and there’s many more examples like
this – that there are five entities involved, but, actually, seven different
steps along the way that the message had to be passed along.

If there was to be implemented a PKI implementation that required an
authentication of the certificates and the kinds of real-time validation of
certificates at each one of these steps, we are talking about creating a huge
amount of traffic in transactions that need to happen as overhead on top of
getting this prescription along, because to make sure that – you know – we are
allowed to deal with this – let’s say that we have the private key and we are
going to decrypt this message. Well, entailed in this technology is hitting
some CA system or somewhere to make sure that the certificate is valid and that
it is following the rules.

So there are literally dozens and dozens of these kinds of situations with
this complex web of participants, and so to implement a technology like PKI
that was talked about this morning would add a huge amount of complexity. I
know that we are not there. It would be very hard for us to implement that
technology in this picture with our partners, and I know that most of our
partners would also find it difficult. So I don’t have an answer, but what I
came to say really is that we would like to make sure that whatever solution is
proposed allows this kind of traffic, because this is where the industry is.
Maybe it shouldn’t be this complicated and maybe it won’t be this complicated
in the future, but if this is where it is today and we are going to use this as
the foothold to get the initiative going, we need to make sure that the
business players that are in it can keep doing business the way we are and we
will evolve with whatever comes along, but this is a very real situation.

My next point that has to with authentication, non-repudiation technology,
it has to do with the cost in the physician’s office and sort of the intrinsic
burden of security in that – and my point is that e-prescribing is just one of
many, many functions that will go on in a physician’s office, and many computer
applications that are in a physician’s office, and physicians’ offices, like
many other mostly small businesses, can’t afford to do things six different
ways. They need to do things one way. HIPAA was quite a burden already imposed,
and most people are still struggling in small physician’s offices to meet what
will be the security regulations coming this year to implement just log-ins and
passwords for every individual and not share log-ins and passwords. This is a
big burden already.

So to have e-prescribing come in and say, I know that for all the rest of
your systems, you are using log-ins and passwords and your own internal
security policies, and that is good enough for all of the rest of your
HIPAA-covered transactions, but to do e-prescribing, you have to now learn what
a digital certificate is and know how to implement it and get it registered and
when they expire to renew them and when it doesn’t work to add the support.

I would say that most likely they’ll say, well, then I’ll pass on that for
now, because I have enough on my plate, and it is going to have to fit in with
the level of security technology that is present in the general systems in the
physician’s office. So I think – especially, you know, at these hearings we are
talking about e-prescribing particularly, but in talking at a number of other
organizations and other initiatives going on, we are all just struggling with
getting basic access control put into physicians’ offices under HIPAA, and that
is to have everyone get a log-in and a password that changes periodically, to
have lock-out involved, all of the things that are inherent in the HIPAA
security regulations.

So our recommendation for this is that we look to the HIPAA security
regulations and the way that the vendors in the community are implementing
HIPAA security regs into physicians’ offices and try to make whatever is
recommended here go along with what is happening with that initiative, because
there is a huge amount of effort there, and I am just afraid that since
e-prescribing, again, is a small initiative compared to getting paid in a
physician’s office that this will get put on the side if it seems to be too
much of a hassle when they have these other efforts to worry about.

So, then, a little more specifically with – oh, I’m sorry. I also wanted to
say that, in the past, we have tried to distribute client-specific digital
certificates and so that at least at each office they had their own digital
certificate and that was a way, again, to authenticate who they were.

Unfortunately, this effort failed. We tried this with our entire customer
base with our own software project of about 1,500 physicians. I guess it was
about 500 practices. We distributed the digital certificates. We went through
the whole effort of helping them to get installed on the PC’s and get
registered. Primarily, this was a Windows environment. That was a lot of cost
to us to both distribute and then support the effort.

Well, started immediately. They got a new computer system in their office
the next day. How do I get the digital certificate on the new computer system?

The computer system breaks. The vendor comes in, wipes out the system,
reinstalls the software. The digital certificate is not there anymore.

We had a flood of support calls, and we had many, many of our customers not
able to use the service because the security was stopping them from using it,
all inherent in the fact that there is some amount of skill involved and
training involved to be able to install, administer digital certificates in a
Windows environment, and, again, I am speaking to the small physician practice
and maybe group practice that has offices with 5-10 physicians in each office.
They just don’t have the staff there to administer this type of technology on
an ongoing basis.

So we did try this on more than one occasion, and we went back to log-ins
and passwords and trying to force people to change their passwords as they are
supposed to do.

So if – again, if this kind of technology came back around, it was
mandated, well, we wouldn’t like that very much, because history has a way to
repeat itself. I don’t think much has changed in the marketplace since we tried
it last time.

So, then, just a few recommendations. We recommend that the goal of
authenticating the parties involved in electronic prescriptions be accomplished
through a combination of business processes, as I discussed, as well as some
basic access control in the form of log-ins and passwords that we spoke about.

We also recommend that, as opposed to encrypting and putting a hardened
package around – message, that we work on securing the communication channels.
That is much easier. We have no problem in putting whatever sort of security
technology is required to secure the communication channel. Most of us in the
business are already doing this, and, under HIPAA, any of us that are covered
entities are already doing this.

We specifically, as I said, would not like to see a PKI implementation,
because we believe that it would pose too much cost and burden and probably be
a real stumbling block to getting started.

We do support the NCPDP’s stated definition of electronic signature which
has an electronic signature being any electronic sound, symbol, data string or
process attached to or logically associated with a record that goes along with
what I have been saying on our practices, and, as I said, we propose that you
make sure that the HIPAA security regulation dovetail into whatever it is that
is being proposed for the implementation for this.

Thank you very much.

DR. COHN: Okay. Jack, thanks very much.

The next presenter is Mike Simko, Walgreens. Oh, David.

MR. KILGO: Good afternoon. Mike and I are going to work together –

DR. COHN: Oh.

MR. KILGO: – we face some of the similar issues in the retail industry.

And, again, I am David Kilgo. I am Director of Third-Party Operations with
Walmart. I have been a pharmacist for 25 years and almost 20 years with
Walmart.

MR. SIMKO: Mike Simko with Walgreens, Manager of Pharmacy Systems.

MR. KILGO: And we were asked to come and talk about the current position of
pharmacy today with non-repudiation, e-signature, and in terms of how we manage
that, and what we would like to talk about first is kind of the present state
of the industry, the present state of what our pharmacists face on a day-to-day
basis in our current paper environment and how e-prescribing is such a leap
forward in that environment.

And, today, in our pharmacies, we have a paper-based system, and you think
in terms of validation of the prescription. How do I know this is a valid
prescription for a valid patient? You deal with written prescriptions that come
in fax prescriptions and telephone prescriptions. The fact that a written
prescription can be difficult to read, authentication can be difficult. A
popular trade journal routinely has difficult-to-read prescriptions, the
purpose being to encourage validation through telephone calls and confirmation,
but they are very difficult to read.

If you practice around a teaching institution where you have one
prescription blank that maybe many different parts of the institution use,
validation after hours is very difficult. Very difficult to find the part of
the institution that the prescriber came from. Many times, it’s a little
difficult to identify exactly who the prescriber is.

Phone prescriptions, you deal with look-like, sound-alike drugs, and also
elaborate schemes that you see that many times people will do to divert drugs.

And I may recognize an office person as belonging to a physician that I
have a good relationship with, that I commonly see prescriptions from, but yet
I still do not have a verification that that prescription was, in fact, ordered
by the prescriber.

A fax prescription, again, takes all the issues above and just adds another
complexity to it.

The prescription itself, critical information may be missing. It is routine
to see prescriptions missing quantities, directions, signatures.

Patient identification is difficult. Very important to match the patient
that you receive the prescription from to a profile in your practice management
systems in a written environment because of the information that may be
lacking. Compromises your DUR efforts and also is very frustrating to your
staff in terms of getting claims submitted properly.

Very important that minimal information be included – the name, the
address, birth date, sex of the patient.

And, also, many times, you must rely on the person that is not the patient
delivering the prescription. I think in terms we have a very ill customer, a
very ill patient who is – have a care giver that would be delivering the
prescription to the pharmacy.

All of these present challenges for our pharmacy staff and for our
pharmacists to deal with.

And think about in terms of how the electronic process addresses those. We
look at every one of these steps along the way where there is a critical
opportunity, e-prescribing deals with that through the written prescription,
the phone or the fax. The e-prescription consolidates into one method, so that
you have confidence in the message you received.

I spoke to one of our pharmacists this week who is actually leading our
group in terms of having electronic prescriptions or receiving it and said, Has
there ever been a time when you had any concern or any problems with knowing
that that prescription was valid? And her answer was, absolutely not, that she
had extreme confidence in the system, that she loved it and her practice peers
on the other end – were sending the messages equally loved it as well, but
there was absolutely no opportunity for any integrity issues with those
messages.

The patient ID, again –

MR. BLAIR: Those messages resulting in a fax –

MR. KILGO: No, they were actually flowing into our practice management
system electronically. They were – never used a paper until the very end of the
process. So an electronic message comes directly into our practice, our
pharmacy-management system as an electronic message, right into our workflow,
so that there is never anything put to paper until the very end.

So, at that point, Jeff, all our pharmacist has to do is make sure that the
patient that they are adding it to their profile matches the demographics that
they have on record for that patient, and if there’s differences they can
readily update it, and the same with the prescriber.

But, again, e-prescribing deals with all these, and it is inherent in the
design of the process dealing with all these, so that the demographics of the
patient is copied into the message and sent along.

Authentication of the prescriber, again, issues for pharmacy. In today’s
environment, customers travel great distances. It is not uncommon even to see
customers maintain a relationship with a prescriber that was in their favorite
town maybe hours away. It is also not uncommon in a rural environment that a
customer may travel a few hours to go to a specialty that they need care, and
familiarity with that prescriber is an issue. How do I know – do I get enough
contact with this prescriber to have confidence that the prescriptions I am
receiving on paper are, in fact, legitimate and from that prescriber, and, yes,
it is the pharmacist’s responsibility to make those validations, but, yet, I’m
sure any pharmacist in the room, you have been duped a few times over something
that you thought was very valid, but yet it turned out not to be.

Preprinted prescription blanks, stamped signatures all are challenges for
us. Again, touching the large clinics – and I don’t mean to beat up on the
large clinics, but, yet, it is a unique opportunity in the metro areas,
especially where that you have a large proliferation of customers, especially
if you practice in an area that need the care offered in those environments.

You deal many times with stolen and forged prescriptions, and, also, again,
with the content.

Registration of new prescribers in an area is another big challenge of how
do I know that the doctor or the nurse practitioner that I have just received a
prescription from – maybe across town, maybe in the same neighborhood – is, in
fact, a legitimate prescription, and, again, e-prescribing deals with all of
those.

And if you look at the next slide – I’m sorry I didn’t let my Power Point
keep up, but e-prescribing deals with each one of those through inherent
designs of the system. The network is secure and gives confidence to our
pharmacist. The SureScripts, SPI or SureScripts provider ID provides the
validation on the front end to ensure that the authentication of the prescriber
is valid. He is who he says – he or she is who they say they are and they have
their credentials supporting their action there.

MR. SIMKO: More thoughts on the security side. It is true that pharmacies,
at least chain pharmacies, they generally connect through a central server, and
that gateway goes out to an aggregate or, in this case, such as ProxyMed or
SureScripts, and we rely that the physicians that – or the prescribers that
they are registering on their system that they are registering an actual
prescriber and that that connection is secure between the prescriber and the
aggregator.

The pharmacy is still wholly responsible that that physician and that
prescription is valid. We are relying on them maintaining the secure connection
and assuring us that that connection is – what is sent by the prescriber is
what is received by them and what is received by them is what is sent to us;
but, nevertheless, the validity of the patient, the relationship that a true
doctor-patient relationship exists and that that prescriber is able to write
prescriptions for that particular medication still are relying on our
pharmacies and our pharmacy host systems.

Physician registrations are assigned a unique identification number. We
track prescribers based on those unique numbers with our host-pharmacy system,
and, again, there is an electronic log of all transactions that take place.

Just to mention a few things on the security side, we have had very suspect
prescribers that would never write a prescription, and we noticed that the only
prescriptions we would get would be phone-in prescriptions. They are only given
orally, and when, you know, it was offered to them that, you know, why are you
not writing prescriptions? they would say, well, you know, they just don’t want
their patients to have to wait, that they can just phone the prescription ahead
of time, their patients can get the medication quickly. We suggested
e-prescribing, and, in many cases, a lot of them didn’t want to participate. So
there is just – you know – no trail for the pharmacies at all to authenticate
an oral prescription, outside of knowing the prescriber and maybe knowing who
works in the office, but you have no authentication of any particular
prescription that was transmitted to the pharmacy.

Electronically, we have logs, and we have used those logs in the past for
an authentication purpose.

The other important piece is the integration of e-prescribing and the
host-pharmacy system, and, again, the pharmacy system validates prescriber
registrations. We know who a valid prescriber is. We have them registered in
our system and we know who a valid e-prescriber is, and those people are
registered in our system. Again, we assign unique ID numbers to those physician
registrations.

Firewalls are built around our host-pharmacy system, so no one but who we
approve can transmit anything to us, and so in the case of aggregators, such as
ProxyMed or SureScripts, those messages have to come from them. No one else can
send us medication orders.

Variety of ways. You can use VPN or SSL lines, and then, again, the
pharmacist is ultimately responsible for proving the validity of that
particular drug is appropriate for that patient, and, again, we use our
host-pharmacy system in connection with our relationships that even after a
message is received that patient, that physician and that prescription are all
validated.

As far as pharmacy and aggregators, our recommendations are that, again,
secure connections are used, direct lines, SSL and VPN, private-data circuits,
encrypted messaging. Jack Guinan mentioned, you know, the HIPAA standards, and
then standards that prevent altering prescription transactions, which is like
NCPDP script.

The pharmacy side, existing firewalls that are in place are working very
well. Unique pharmacy identifiers with NCPDP numbers, prescriber ID numbers,
the elimination of any authorized access and the keeping of log files for all
transactions.

Again, you know, the blend of all this technology has really shown to be
beneficial as far as not only the timely receiving of medication orders for
patients, but – and, as mentioned before, you know, the critical pieces of all
the prescription is in place. We don’t get prescriptions that have incomplete
information, and any prescription we get electronically, you know, we have full
confidence that our trading partners, such as ProxyMed or SureScripts, are
protecting the integrity of the system up until when they get that medication
order from a particular prescriber, and, in turn, our connection with them has
that same kind of confidence built into it, so that when we get medication or
electronic prescriptions transmitted from the aggregators to our gateway to our
pharmacy network we know that that is a secure connection and we know where it
is coming from, and, again, as far as the host-pharmacy side, we have processes
in place to know that that particular prescriber, that particular patient,
then, for that medication is valid, and it is still incumbent on the pharmacy
and the pharmacist that they do that validation process.

So, you know, parts are all in place that ensure the security of the
message, and the process is in place in the practice of pharmacy that that is
the appropriate therapy and that is a valid prescription, and I know, you know,
we have heard a lot of testimony today about authentication and
non-repudiation. We trust the electronic network far more than what we are
dealing with with oral prescriptions today, and especially the case of
controlled substances. They can – you know , Schedule III through V’s can be
phoned in to a pharmacy and we have no method of proving where those came from,
and especially in today’s pharmacy-practice world that many patients no longer
just go to their corner drugstore. Oftentimes, they’ll drop a prescription off
near where they work or near where they saw their physician, but not
necessarily near their home. So, often, in today’s society, pharmacists are
losing the very personal contact with a particular physician, and, no, we don’t
know that a certain doctor uses blue prescription blanks or some other color.
We are relying on the fact of technology and secure connections, and it is that
interplay between that technology leading from the physician’s office, those
secure connections and our relationship with those trading partners that make
electronic prescribing so far superior to the processes that exist today, and
while PKI may, at some point of time, for some very small segment of
prescriptions – i.e., Schedule II drugs – we think that – you know – Schedule
III, IV’s and V’s, if they are allowed to be transmitted orally today, this is
a much more secure method of doing it, and we feel highly confident that those
would be valid prescriptions and anything that would be unauthorized, invalid –
and, again, those have all the procedures to be checked by both a physician’s
office and the pharmacy – would not be utilizing that system for it.

MR. KILGO: Some thoughts and conclusion. The paper-based prescription
today, as we see it, poses many problems. I think we all agree with that.

The security intrinsic in the SureScripts system has been adequate to
ensure authentication, non-repudiation.

Again, back to my pharmacist who said, yes, I know where this came from,
and the good news is that that physician also knows that we receive it. So
there is a variety of handshakes along the way as the data passes from location
to location.

There is no immediate need for digital signatures beyond the current
validation process. The security built into the system and used by retail today
ensures that these signature requirements are less urgent, and the requiring
digital signature, at this time, could potentially slow the progress that we
are making, and we are making progress. I look at the number of prescriptions
that we are receiving electronically week to week, week on week, as we add new
states, and it is quite impressive.

Pharmacy-practice systems. We maintain and recognize valid prescriber
registration information, recognize that it maintains accurate patient
information, and with the e-message, that information is compared, so that
there is a valid authentication there.

Integration of the e-prescription within the practice-management system
many times just flows right into the work processes, so that it becomes a step
of efficiency for the pharmacists and their staff.

The security of the firewalls, secure networks, restricted access and HIPAA
compliance as well, and, then, looking at April when we have another layer of
HIPAA security coming in place adds more security into that environment.

Important things to keep in mind is there is no substitute for the
pharmacist’s professional judgment. Talking about some of the things our
friends at Goldstandard were addressing earlier where the passwords and such
were taped to the PC’s or on the back of the PDA’s, that is real world,
unfortunately, and even at that point, the pharmacist is still the gatekeeper
of that prescription getting to the public and the use of their information,
the use of their skills in relating to the patient, reviewing profiles and
counseling patients and knowing their patients.

And, lastly, there is no perfect system. If we wait for the perfect system
we’ll be waiting a long, long time.

MR. SIMKO: Any questions?

DR. COHN: Oh, I suspect there will be some questions.

Actually, I want to thank you all, I think, for what has been some very
useful presentations, and I suspect that there’ll be questions from the
subcommittee.

I actually have one just to ask David Medvedeff.

MS. FRIEDMAN: David Smith.

DR. COHN: David Smith, okay. (Laughter).

I apologize. You’re going to have to get a new chair, since I can’t seem to
pronounce anybody’s name.

But, David, you alone of all the testifiers appear to be using –
successfully using – maybe using PKI in your application. Help me with this one
a little bit, because I think what you described is is that you only use it
between the provider and your server, and, after that, you make no pretense. So
I guess that was question number one, did I understand that right?

And, number two, is if, indeed, you are using that, what sort of
controlled-drug-substance policies and use do you have in Florida in
relationship to your systems.

MR. MEDVEDEFF: Sure. First, we are using PKI. We are using it, again, only
from the provider to our server before it gets to the gateway.

Now, it is in a place where we could take it end to end, but the industry
is not ready to receive that end to end. So in order to keep that data so that
it is in a useable format when it gets to the pharmacy through the gateway, we
have to remove that electronic signature, so it does not corrupt that data
transmission when it goes from our server and beyond.

Now, we instituted the PKI for one main reason and that was the amount of
misinformation that was circulating about electronic prescribing and where the
regs were going to end up, and we view ourselves as a fairly innovative
company. We weren’t necessarily pushing for PKI, but if it happened, we wanted
to be prepared, and we did not want to be left out in the cold, and so we went
ahead and we are proactive in implementing that, but, again, it stops short
where it is not end to end. It goes from the doctor to our server and then it
goes through an SSL connection, a secure-layer connection, from that point
forward.

Around controlled substances, because the DEA has not given guidance on
that, all controlled substances are actually faxed back directly to the doctor,
and the doctor then faxes the controlled substance into the pharmacy. So we
have not instituted PKI, because it is not end to end, to enable us to do
controlled-substance electronic-prescription transmission.

DR. COHN: Okay. And that applies to, of course, to II, but also to III, IV
and V?

MR. MEDVEDEFF: Correct.

DR. COHN: Okay. Other questions?

Harry.

MR. REYNOLDS: Yes, I’ll go with David first. I’ve got one for each, if I
could. Is that all right?

DR. COHN: Go ahead.

MR. REYNOLDS: Yes, okay.

I really like the idea of the communication back to the physician. I think
that is a strong comment about the closed loop.

Jack, I had a couple of questions. I struggle with mapping versus – in the
record, because, as you think about non-repudiation and you think about truly
receiving in a pharmacy what was sent, format mapping is one thing, content
mapping to the end is another, and so if you could give me anymore words on
that. That –

MR. GUINAN: I would say that the reformatting of the messages is by far the
majority of the changes that take place, and I am trying to think of an example
where we change the actual content for code sets.

For things like on refills, the way that PRN is handled on a refill, as
opposed to a specific number, or, actually, some pharmacies – Okay. So when you
send a refill request to a physician’s office and they say, We are looking for
three more refills, and then when they respond, some of the systems take the
message going back itself as a fill of one with two additional refills where
some of the systems will send back a message that actually says three refills.

Some of the pharmacy systems, when they are requesting three additional
refills, want you to send back three. Others want you to send back actually the
prescription plus two more refills. So we have business rules in place that
actually map out, well, how many refills are the people really looking for, and
those are the types of content changes that go on.

I do believe that a more fine-tuned implementation guide of the script
standard could probably get rid of these content changes. I don’t think it
would be all that hard to have people agree on – There’s not 100 of these
points. I think there might be less than a dozen. NCPDP does a good job of
pushing these kinds of things through. So I think that we could probably get
away from having to change the content.

I think one of the concepts that is thrown out there is what is the intent
of the prescriber, as opposed to exactly what did the prescriber send in the
electronic message.

MR. SIMKO: And I think the other part to that is we have to do a better job
of getting people nearer the same version release –

MR. GUINAN: Yes.

MR. SIMKO: – of NCPDP script, because it is anywhere from one to five.

MR. GUINAN: Yes, and some of the older versions don’t support all of the
values for the code sets, and so there has to be a translation of, I know that
you sent a zero in that field, but, on the new version, you are supposed to
send a one. So we’ll go ahead and change it for you.

But I believe that this can be handled through having NCPDP put out a more
fine-tuned implementation guide.

MR. REYNOLDS: And for David and Mike, I have a problem with your comment on
Slide 11, second comment. If I listened to your SureScripts discussion of
authentication, you have – is it not true that you have assured non-repudiation
that it came from a doctor’s office, not that it came from that doctor?

MR. KILGO: True.

MR. REYNOLDS: Okay. That’s – I thought it was a little stronger than what
the true definition of non-repudiation would be. It says, I did it, or, They
did it, or, Somebody else did it for me, or something. So –

And the other thing, you mentioned one – that you have a SureScripts
provider number, and so does a physician have to have multiple provider numbers
depending upon all the different systems?

MR. GUINAN: At the moment, a physician is registered on one or the other of
the networks out there. A physician doesn’t participate on more than one
e-prescribing network.

MR. REYNOLDS: But if the patient – and back to the idea earlier. If a
patient drove two hours and then was going back home and that physician had to
order that drug and the patient wanted it sent to a pharmacy at home, which is
on a different network, that network doesn’t know that doctor. That doctor is
not signed up on that network, so how do you, as the industry, see – because –
I mean, living in an area where Duke is, there’s a lot of people that join us
at Duke and then go home.

MR. GUINAN: I guess when the patient was at that physician’s office the few
hours away, the decision to send the prescription electronically really has to
be made at that time, because if they are not going to, then they have to hand
the patient the prescription, and so – I mean, that physician that is writing
the prescription is either on a network or he’s not.

MR. REYNOLDS: And, also, I am talking not just a physician’s office, but
out of a hospital. So somebody gets discharged out of a hospital and then they
go home, and, you know – again, in the hospital pharmacy, they are hooked up
through HL-7, and then it goes out to the – you know, we have all talked about
– then it would go out to NCPDP and go to a local pharmacy.

So this idea of whether a doctor can have one ID and it works throughout
the process or it is one ID as long as they stay within their little network.
Little not being a negative term. (Laughter). The network they have signed up
to.

MR. GUINAN: It is possible that a physician, as he is practicing in a
hospital, that hospital could be hooked up to one network, but his office is
hooked up to a different network, and so that same physician could have two
different ID’s.

MR. REYNOLDS: Okay. That’s –

MR. GUINAN: That is correct.

MR. REYNOLDS: Thank you.

MR. MEDVEDEFF: Mr. Reynolds, it has been our experience – This is Dave
Medvedeff. We have run across that a number of times now where we have tried –
we have actually assigned the doctor, through SureScripts, a SureScripts
provider ID, but the doctor is using a medical manager as well in their office
and has a ProxyMed ID, and that creates a tremendous amount of confusion in the
retail pharmacy, because which doctor’s name do you select off of the system.
So they force him into one ID, and that does create some issues, and I know
that SureScripts has been fairly diligent at trying to come up with a solution.

MR. REYNOLDS: And, again, I wasn’t picking out specific vendors as an
issue. I was talking about the flow in the process.

MR. SIMKO: And, ultimately, you are right, but, as David described, in
today’s world, we have that physician registered with two different software
registrations because of that, because they have actually two different
systems.

MR. REYNOLDS: But, again, when you get into PKI and you get into other
things and you start talking about – we heard the discussion today that you
have one number and everything else. I am hearing that the industry may have
situations where they don’t just have one number and they wouldn’t have just
one PKI and they wouldn’t look like – That is all I was trying to clear up –

MR. GUINAN: Yes, it is a very real scenario.

MR. REYNOLDS: Okay. Thank you.

DR. COHN: Okay. Steve.

DR. STEINDEL: I have two questions, one for you, David, and the other in
general.

When you were talking about your PKI system, PKI systems are associated
with certificates. Where is your certificate?

MR. MEDVEDEFF: We actually have implemented a roaming certificate through
Verisign. They call it their managed PKI. So the certificate is stored on a
server, and, when the doctor logs in, it authenticates the doctor to the server
–

DR. STEINDEL: Any cases where a prescription may be questioned, et cetera?

MR. GUINAN: We have been requested to provide records pursuant to a few
Medicaid-fraud cases, and we have supplied the records, but I am not aware of
what – you know – weight where it is given to them or not. So I guess the short
answer is no, and, just speaking for ProxyMed, we haven’t been involved
directly in a litigation. I know that we have been requested to provide these
type of records, and having them has been a very good thing for the
prosecutors, but I don’t know what weight they are given. Mike, do you know?

MR. SIMKO: We have been – as part of investigations on some practices for
Medicaid fraud and other state medical societies about prescription abuse of
controlled substances and that, and Medicaid fraud, in that regard, transaction
logs that we have had through ProxyMed that we have asked that those be
provided to prove that transmission did come from a particular physician’s
practice.

MR. GUINAN: No, but I don’t think it’s been tested yet to have a physician
say, No, I didn’t write that prescription, and then for us or someone like us
to present, Well, it says here you did, and so I am not aware of anything like
that.

MR. SIMKO: Yes, we don’t know if that’s been held up in any –

DR. COHN: Okay. Jeff and then Stan.

MR. BLAIR: David, do you have any statistics from Florida with respect to
the incidence of fraud in prescribing? And let me kind of give you all of the
layers of my question. In particular, if you do have any data on that, what
portion of the fraud is – could be captured by better authentication and what
portion of it could be then captured – authentication with PKI?

MR. MEDVEDEFF: I do have numbers as far as fraud in a general sense, in
Florida Medicaid specifically. A grand jury convened late 2003 – in the winter
of 2003 – and their rough estimate was that there is $1.5 billion in Florida
Medicaid that is funding fraud and $300 million of a $200-billion budget was
directly attributed to prescription-drug fraud. So $300 million out of $200
billion spent was prescription-drug fraud.

Now, the caveat there is that prescription-drug fraud is not necessarily
patients writing themselves prescriptions or doctors abusing the system and
writing patients prescriptions that are not appropriate. There are a number of
layers – if you want to get into layers of fraud – such as doctors providing
prescriptions that get fed into black-market wholesaling rings, and it is a
very complicated, very lucrative businesses. You can imagine $300 million in
just Florida.

As far as what portion of that could have been captured using
authentication and maybe tighter security, you know, I had the one slide. It
was one testimonial from one doctor who said he identified a patient who stole
a prescription pad and wrote numbers of prescriptions. I am sure that story
happens more than most doctors know.

And then the other response to that is, if technology is allowed to be
planted in the community, you now have sentinels all around. So you have other
providers, other prescribers that can see what else is going on with that
patient, and maybe you can identify provider fraud, pharmacy fraud and
patient-level fraud, because I think what is happening is more and more
pharmacy fraud. No offense to our partners here, but pharmacy fraud is starting
to be identified by doctors who are seeing patient prescription data come to
them saying, I have never written a prescription for this patient. Why is this
patient on these five medications? And when you start to drill down and you
start to go through if there was a paper trail that maybe there is some fraud
there.

So I don’t know that I necessarily answered your question exact, but that
is all the information I have.

DR. COHN: Okay. Stan, I think last question for this panel.

DR. HUFF: Just make sure I understand, in your use of certificates, the
certificates were on your server.

MR. MEDVEDEFF: Posted by Verisign. They are not –

DR. HUFF: Not your server, that is correct. Verisign. And so you didn’t
have the same problems in maintaining the certificates that were described by
Jack –

MR. MEDVEDEFF: Well, we went that route first.

DR. HUFF: Oh. Tell us about that. Tell us that story.

MR. MEDVEDEFF: He is very eloquent. It was the exact same scenario, and it
was probably taken to another level when you are dealing with battery life on a
PDA, and when you completely drain your battery and then you drain your backup
battery, the PDA will do a hard reset when you turn on the PDA the next time,
and it wipes out all the software on there, and you are basically starting from
a blank operating system, and we had issues around loading new certificates and
authentication, and he described everything that we had experienced, which is
why we went out to the industry and said, What are the options available?

And another thing we liked about the roaming PKI – the managed PKI, as
Verisign calls it – is it enables that provider to use a PKI certificate
regardless of how they are entering the system, whether it is on their PDA.

We also have everything available on a website. So they can go in – user
name and password, build a cert as they need it, use a certificate, and then,
as soon as they log out, it flushes the certificate off of the hard drive and
they can then log into their PDA again. So it creates some options and they
don’t have to have plug-ins and that kind of thing.

DR. HUFF: But, again, just – the potential Achilles’ Heel of that is that,
now, if you don’t have a very strong authentication to the roving server, then
you really haven’t – I mean, you know it’s coming from somebody in a secure
package, but you are not sure who.

MR. MEDVEDEFF: The only thing you are doing with that is you are ensuring
that the data was not corrupted when it was in that secure transmission.

DR. HUFF: Right.

MR. MEDVEDEFF: So it’s in a secure pipe and the data inside the pipe is
secure and nobody has hacked in and changed it.

DR. HUFF: Right.

And then my other question is just make sure – this is just sort of general
education for anybody who wants to tell me. So is the typical – is that the
typical scenario that we heard about faxing of prescriptions for controlled
substances that is sort of the norm with – how are people handling, typically,
now, controlled-substance prescriptions, and especially Schedule II?

MR. KILGO: Schedule II is no different. Still requires a signed hard copy,
and, in our environment, the pharmacist leaves a message that they received a
message for a controlled substance, called and receive a fax.

MR. GUINAN: And we don’t allow the sending of Schedule II’s at all on the
network. For a while, we did the call-back methodology, but it wasn’t clear
that that is completely in line with what the DEA was looking for. So we don’t
– we just steer clear of it at the moment. So Schedule II’s, we don’t send over
our network.

DR. COHN: What about III, IV’s and V’s?

MR. GUINAN: III’s, IV’s and V’s, at the moment, we do, although this is an
open question on whether or not that is – we should be or not, and our pharmacy
partner and ourselves, we are all struggling with this, looking for some more
direction.

DR. COHN: Steve, you have a final comment as we transition?

DR. STEINDEL: Just as a very quick comment. People have heard that CDC runs
a PKI system, and we actually use the roaming certificate as well, for the
exact same reasons that were outlined. You know, we had the same problems with
computers crashing, et cetera.

DR. COHN: Want to thank you all for some very interesting testimony.

Agenda Item: NIST Standards

DR. COHN: Now, I believe we actually have NIST on the line calling in. We
have Power Points we are going to put up, relatively high tech, and we’ll just
allow, I think, Maria, I guess, to get up there and get on it, but we want to
thank the testifiers what has been some very interesting testimony.

Also, to warn people, we’ll obviously take a break after the NIST
presentation and discussion.

MR. POLK: Good afternoon. Are we on at this point?

DR. COHN: Yes, you are live. Can you hear us?

MR. POLK: Yes, I can. I just switched to holding the phone, so I have a
little better sound, so I wasn’t sure that you were waiting for me. My
apologies for that.

DR. COHN: No –

MR. POLK: Good afternoon, and I am Tim Polk from NIST. I will actually be
the only NIST speaker. Unfortunately, because of other duties involving FIPS
201(?), Curt Barker has asked me to cover the FIPS 201 topic for him, and I
want to say I really appreciate your accommodating me by letting me call in,
rather than appear in person. I would have liked to have been there, but we
have – this has been a very – it is a very busy time this week, and I do
appreciate your accommodating me in this manner.

I have submitted a presentation, an Introduction to Public Key
Infrastructure, which is what I was understanding was needed as a background,
although, I realize that the previous session spent a lot of time talking about
PKI. So I will probably move through that fairly quickly.

I do not – unfortunately, I don’t believe Curt sent a FIPS 201
presentation. Is that correct?

MS. FRIEDMAN: No, he didn’t.

MR. POLK: Okay. I’m sorry about that. I think that he and I had some
miscommunication, but I am prepared to cover FIPS 201.

I am also one of the authors of NIST 863, the authentication guidance
document. So I would be happy to handle questions on any of those three issues
as we move forward.

I think that probably the best thing to do, since you do have the slides on
public key infrastructure, is I am going to move kind of quickly through them,
and then I’ll have sort of some free-form comments about the federal PKI and
how it relates to this introductory material. Does that sound good?

MS. FRIEDMAN: Sounds good.

Tim, this is Maria Friedman, and thank you for sending the stuff in. I’ve
got your slides up on the screen for the group to see, and there’s also hard
copies. So ready when you are.

MR. POLK: Great. Oh, I am hoping that this is – that this presentation is
tailored somewhat towards your needs. I certainly, though, am happy to take
questions afterwards if there are specific issues that I missed in all of this.

MS. FRIEDMAN: I think, particularly, the group had some questions –
residual questions about the levels of authentication that were in your
document and also on FIPS.

MR. POLK: Yes. Okay. Well, I kind of thought that, while you were looking
for PKI, that, in the end, we would end up talking about 863. I am not terribly
familiar with HIPAA, just enough to be rather dangerous, but I certainly can
try to help interpret 863 and what it may mean for those of you who are trying
to implement that.

MS. FRIEDMAN: Well, this particular discussion is – while this is the
standards and securities subcommittee and we deal with HIPAA, this particular
discussion is on standards as they relate to e-prescribing.

MR. POLK: Okay. Great. Good. I thought I had seen something about HIPAA in
one of the earlier mails and I was worried about that. This is much better.
Okay.

MS. FRIEDMAN: Okay. Sorry about the confusion.

MR. POLK: All right. Well, then, why don’t I go ahead and go through the
set of slides.

I guess a quick overview. When I do an introduction to PKI, there’s really
four basic topics that I like to be sure that I cover, and the first one is
always, well, why, in fact, are we doing this?

The next one is what are these components? Because some of them you will
have heard of, but maybe they are different names that get used at times to
talk about PKI.

And, then, PKI architectures. You’ll find that PKI’s are somewhat like my
son’s tinker toys. You can assemble them in all sorts of interesting ways, and
then they will have different properties.

And, then, finally, there is a specific topic called Path Validation in PKI
that I just want to be sure people have a little introduction to and understand
how this may impact your ability to build applications that use PKI.

Now, I’ve moved on to the slide, “Why PKI?” –

MS. FRIEDMAN: Um-hum.

MR. POLK: – and, as much as I have been doing this for more years than I
care to admit, but PKI itself, while it is a lovely technical mechanism, it is
really not the goal. The goal is to be able to get security services, and PKI
is just one of many mechanisms that you can use to do this.

There are some nice things about PKI, and it is one of the reasons that
cryptographers and a lot of security people are very fascinated – myself
included – with PKI as being such a great mechanism, and one of them is that
they are – that there’s possibilities for scaling.

Public key infrastructure – if you have a half-a-dozen people that are
working on an application, public key infrastructure is probably not something
that you want to deal with, but if you are trying to roll out an application
that is going to have a very large and perhaps very diverse community of users,
PKI may very well be a good choice.

So one of the other things that is nice about PKI, on the next slide, is
that you can do pretty much anything, in terms of provisioning security with
PKI.

The one thing you really don’t do with PKI is you don’t address denial of
service, but PKI – a good PKI should let you authenticate who your users are,
establish confidentiality. You should be able to use those keys to set up a
secure pipe. You should be able to protect the integrity of your data in
transit, and you actually have at least the technical mechanisms in place to be
able to say, after the fact, who did what. That is the technical
non-repudiation.

There’s lots of ways to get around some of the – I say technical
non-repudiation, because while the mechanism will show what keys were used,
there’s lots of ways that users, by not following the rules, can disclose
information or let someone else use it, and so you may still have to go to
court to discuss who really did what, but the keys are pretty much irrefutable.

Now, on to the next slide. Most people are familiar with cryptography, but
they usually are thinking of secret-key cryptography, which is where if Bob and
Alice want to exchange information, they both need to have the same key.
Cryptography, in one form or another, has been used since the time of Caesar,
with the secret keys.

There’s a lot of – when you hear people talk about the DEZ(?) or the triple
DEZ or the advanced encryption standard or AES that NIST has done, all of those
are what we call secret-key cryptography, and there is one sort of Achilles’
Heel for secret-key cryptography and that is that Bob and Alice have to share a
key. They have to share a secret, and as soon as more than one person knows the
secret, it is really not much of a secret. So it undermines an awful lot of
things, and some of those services that we were talking about before, like
non-repudiation, very difficult to do with secret-key cryptography.

Now, in the early ‘70s, a new kind of cryptography was invented called
Public Key Cryptography, and in Public Key Cryptography Bob and Alice actually
have two different keys that are mathematically related, only one of which
needs to be kept a secret. There’s a lot of neat things about this, which is
that you can use the same set of keys for multiple users. Everyone can share
the one key that is public, and only the user that needs to hold the secret has
to keep the one secret, and it really is secret, because only one person has to
have it.

There are a number of issues with this. It is a much slower type of
cryptography than secret key, but it is very – people are very interested in
doing this, because it solves that major problem of Bob and Alice having to
have the same key with secret-key cryptography.

But the biggest weakness – the keys are all so much longer. You’ll hear
people discussing how large key sizes should be, and sometimes people will get
mixed up with this. A secret-key algorithm like AES, which has a 128-bit key,
is as strong as a public-key algorithm, a lot of times, that might have a much
larger key. So there are issues that have to do with the sizes of keys and
being able to transmit information back and forth with public key, but the
really big problem with public key is being able to figure out who is the
person that a public key should be associated with.

So we can move to the Choosing Cryptographic Tools slide.

There really is no one-size fits all solution when it comes to
cryptography. You really need to be able to combine these different kinds to
build any kind of an efficient system.

If you have a document that you are wanting to encrypt, so – you know, a
large Microsoft Word document or a PDF document – you would never want to use
public-key cryptography. It is very, very slow to encrypt that kind of data,
but secret-key cryptography works very well, but, on the other hand, if you
want to know who sent you that Microsoft Word document, what you want to do is
something called a digital signature, which is something you do with public
keys.

If you wanted to find a way to be able to encrypt that document and then
get that key passed to another person, you use public key to transmit short
pieces of highly-secret information, where secret key is good for bulk
encryption.

So you can see there is a need to be able to combine these tools in almost
any system. In large systems, you really want to be able to build them using
the best of both of these kinds of cryptographic mechanisms.

So, as I said, the one big problem with public key is – public-key
encryption or public-key cryptography is how do you get the key that is not
secret – how do you know that you can trust it for any particular user, and
that is actually what PKI is all about is solving the problem of whose public
key is it and what is it good for.

So if we could move to the one that says Credit Card.

There is an analogy that I like to use that it really holds pretty well for
public-key certificates and for PKI. Everybody is familiar with a credit card.
It has some information on it. It is basically that credit-card number and the
name, things that are in there on the mag stripe. It’s got an expiration date.
Everything you need to know to be able to find out if you can – everything you
need to know – What is the number? Who is it associated with? It is all on that
credit card, and, to the first order of magnitude, you trust it, because it
says it is from – it says it is a Visa card or it says it is a Master card.

Well, a digital public-key certificate is sort of like that. It is the way
that instead of the credit-card number, you get my public key and you can
determine that it is associated with Tim Polk. So it is a little bit different
in that it is not all that hard to forge a credit card, and, actually, it is
fairly difficult if you follow the rules to forge a public-key certificate.

If you could move to the slide that says, Using Public Key Certificates.

The way you would use a public-key certificate, if Bob has signed a
document – say an email – and sent it off to Alice, Alice needs to find Bob’s
public-key certificate, and she uses the key in that certificate to be able to
verify the signature on the document sent to her. If she can do that, well,
that is the first step.

The second step is she has to check and make sure that she can trust this
certificate. You do all of this through digital signatures. Basically, she has
to find two digital signatures in this picture and show that both of these
digital signatures verify against the public key, one in the certificate and
one that she already had, and she builds sort of a chain that says, Well, I can
trust the email from Bob, because I can trust his certificate, and each of
these signatures verify.

So this is conceptually how you use public-key certificates to establish
authentication services, to check a digital signature, find out what the origin
of a message is.

So there is one other – there’s really two data objects for public-key
infrastructure. There’s the certificate, and then there is something called a
CRL.

CRL’s are one of the ways that we do what we call status checking. Just
like if I am issued a credit card, if I quit paying, even though the credit
card hasn’t expired, the credit card is no good anymore. Public-key
certificates may be revoked, too. Maybe I have left the company. Maybe I lost
the crypto module or it was stolen from me. One way or another, there may be
reasons that even though Bob has a certificate that Bob’s certificate isn’t
trustworthy anymore.

If you think about credit cards again, there are two mechanisms that I know
of for handling credit-card revocation. Years ago, when I used to work retail,
we had a paper booklet that I would flip through to look for cards that had
been stolen. We called it the Hot List.

The second way, which is what people tend to do now, is they swipe your
card through a machine. It contacts the credit-card company or the credit-card
issuer and finds out whether or not I am under my credit limit and whether or
not they can handle the transaction.

The Hot List, the paper booklet for hot cards, is a lot like what we call a
CRL. It is – once again, it is like a certificate and then it’s a
digitally-signed object and you can figure out whether or not you trust the
signature on the CRL, and then if my card number, or, in this case, my
certificate number, is listed, you know it is not a good certificate anymore.

There are some protocols and some systems that can be used to do status
checking on line, where you contact a trusted server and you find out whether
or not that certificate is good.

So both of those analogies have – both of them have a corollary in PKI.

So if I could move into the slide that says, Certification Authority, I am
not going to go through – just in the interest of time, I am not going through
all the different components, but I would like to talk about the three most
important components for a PKI.

The key component of a PKI is a certification authority. It is the system
that digitally signs certificates. It is the system that is making an assertion
that this is Bob’s public key. That is a trusted system that – but you may only
have one system for a very large organization. You don’t need to have lots of
them, because they scale rather nicely.

You usually put it inside a security facility. You have lots of very tight
controls on how it is operated. Users don’t come in and ever touch the
certification authority. That is not that kind of a machine.

The next component is the one that deals with users, for user enrollment
and registration, the registration authority. This system is the one that does
the identity proofing and determines whether or not – it is the system that
decides that Bob should have a certificate and that Bob is the correct name to
put into the certificate.

This is a system that is trusted, but only by the CA. Really, it only
exists to do operationally one operational control of does someone need to get
a certificate, is this the right person, does that certificate need to be
revoked. They handle passing that kind of information to the CA.

And, then, there is a component that is actually not a trusted component.
The repository is usually an LDAP directory, but a lot of times now people do
it with web servers, but it is just basically a database that is online. You
send a query to it – I am looking for a certificate for Bob – and you get an
answer back. I am looking for a CRL issued by a particular CA, and you get an
answer back.

Because all the data in PKI is digitally signed, usually, you just don’t
really have to protect a repository other than making sure – you usually – you
are protected in terms of the integrity of the information that is sitting on
it, but you don’t have to worry about who accesses the information and you
don’t – and, in fact, if there is ever a problem of data being replaced by an
attacker, users will be able to figure this out, because the digital signatures
will no longer work. If data is replaced or modified, this will be self evident
to the users of your PKI.

Now, PKI architectures. There are five architectures I would like to
mention. I’ll try to go through them pretty quickly so that we have time to
move on to some other issues, but the simplest way to do a PKI is to build – is
to have one really big CA. All the users that are going to use your application
all get their certificates from the same CA.

For large applications, this may – and ones with particular security
sensitivities, this is something that you can do and justify, although you are
not probably taking the full advantage of the whole world of PKI, but, then
again, your application doesn’t demand it.

It is easy, in fact, to get a PKI to work and to work very well with a
single CA model, and if you really have control of the application and the user
community, this is a great way to do things.

More commonly, perhaps the most common PKI that an organization or an
enterprise – most common architecture is the hierarchical PKI, which is on the
next slide.

In this, you have a superior subordinate relationship. Usually, what you do
is the superior CA out of the PKI we would call the root. It’s the one at the
top of the screen, and subordinate CA’s would then issue certificates to users.
You could make this more complicated by having CA’s that have more CA’s beneath
them, but this is the basics of hierarchical PKI, and you can build very large
PKI’s using this model.

For example, the Department of Defense uses this model and they have
three-million users, I believe, at the last count, in their PKI.

The next architecture is what is called a Mesh, and in a mesh you have a
number of CA’s that really are basically all peers. None is the most important
or the least important. There’s just several CA’s, but each have a community of
users that they issue certificates to, and these CA’s have to have some kind of
trust relationships between them.

Now, all of this is normally hidden from users, because what you are most
familiar with, if you have ever kind of looked under the covers of your
browser, the PKI that you really have that you would use at home or that you
are most likely to use for things, like when you are doing secure web browsing,
is based on the trust list, and the idea here is that there are many, many
small PKI’s. They may be a little mesh of three or four CA’s. They could be a
hierarchy. It could be a single CA, but rather than having to list all of the
CA’s – it is just a list of different starting points for you to be able to
find a way to trust the certificate, and that is what is commonly done in the
browsers.

These days, browsers ship with a list of about 130 CA’s that you are
expected to trust or that you may wish to trust.

Now, you can think, if we are up to – we haven’t been doing PKI that long,
and we are already up to 130 certificates in the browser, at some point, we
need to move beyond these small enterprise PKI’s of three or four CA’s and
start to tie them altogether into a – hopefully, someday – a global PKI.

Now, we have been working in the federal government for a while to try and
construct such a PKI that covers all of the U.S. federal government, and the
tack that we have been taking, we invented something called a Bridge CA, and
the idea is that we are going to take a whole bunch of different PKI’s that
were built for their own reasons, tie them altogether, and, now, that CA that
you deployed to support one particular application, now, it will let you do
other applications with other users, and that is the goal of the Bridge CA.

If we could flip to the second of the Bridge CA slides, the Bridge CA
example, you can see that it can quickly – taking a CA and dropping it in
between, suddenly, we have a much larger PKI. Imagine that instead of two PKI’s
like that, there are nine, as there are, I believe, currently in the federal
PKI, and you can see that, very quickly, the size and the number of users that
might be available to do an application with can become very large.

However, I glossed over something that is a very key point here. One of the
reasons that much larger PKI’s have not been created up until this time is what
we call the Path Development, the Path Discovery and Validation Problem.

If you recall, at the very beginning, Alice had – to find out if she could
trust Bob’s certificate, Alice needed to use a key that she had stored on her
system to validate a certificate for Bob, and then she used the key from that
certificate to validate Bob’s message.

Well, that works fine when Alice and Bob are just both working from the
same CA. Imagine that Alice wants to validate a message from Gwen all the way
on the right hand side of the screen. The way that she actually has to do this
is that she needs to use the key to verify one certificate and then another and
then another, until she finally gets to Gwen’s certificate – each of those
certificates actually representing a relationship between two CA’s – until she
finally gets to Gwen’s certificate, and she has Gwen’s public key, and then she
can actually validate a message that she got from Gwen.

Now, that is the last slide that I have on PKI, Pass Validation. Of course,
I did Bob, which wouldn’t have – the point here is, though, that there can be
this cascade of certificates. You need to go through this whole path, because
PKI is sort of a derived trust model. I trust one CA. It trusts another CA.
That CA issued a credential to Gwen. Well, at that point, you are able to say,
I can trust the message from Gwen.

So this all sounds fairly complicated, and it can be difficult to retrieve
the right certificates, because the standards are really not as solidly in
place in that area as they should be.

Validating that path of certificates is very straightforward. We have good
standards on how to do that and determine whether or not a particular sequence
of certificates is any good, but the problem of finding them is still a
challenge, and that is actually the biggest challenge we face in the federal
PKI today is that while we are constructing a very strong federal PKI, a lot of
the commercial off-the-shelf software is still struggling to make proper use of
that.

So that is the – everything I had on PKI.

My comments that I would say is that in the federal PKI that is really
growing, and we have a lot of momentum and a lot more agencies are joining, but
we are still struggling with some of the software functionality problems in
that a lot of times, people who have implemented PKI in applications have
implemented it with one of the much simpler PKI architectures in mind,
something like a small hierarchy or even just a single CA, and when you move
into an architecture like the federal PKI has now deployed, those
implementations do not necessarily work.

So should I take comments, questions about PKI at this point or would you
like me to give an overview of FIPS 201?

MR. BLAIR: Could we go into the authentication levels?

DR. COHN: Yes. Yes, we would like for you to continue on, because I think –
this stuff, I think, you have told us so far, I think we are pretty familiar
with, but obviously like to hear the other part.

MR. POLK: I was afraid of that. Okay.

DR. COHN: We would like to understand this other piece.

MR. POLK: Okay. FIPS 201. I am sorry that you don’t have slides. I will
send you a set that can be distributed later, if that is useful.

MS. FRIEDMAN: Yes, thank you, Tim. This is Maria. Send them to me.

MR. POLK: I will do that.

Let me go over FIPS 201 real quickly. I think most people have probably
heard that this project is ongoing.

Last August, the President signed Homeland Security Presidential Directive
No. 12, Policy for a Common Identification Standard for Federal Employees and
Contractors.

The general objectives of this standard were that we be able to have
reliable identification verification on a government-wide basis for government
employees and contractors. This needed to be interoperable, and it needed to be
strong enough that we had a real basis for reciprocity. We felt that agencies
were not comfortable accepting credentials issued by other agencies. They felt
uncertain of what standards had been implemented in doing this.

MS. FRIEDMAN: Hey, Tim, this is Maria.

MR. POLK: So –

MS. FRIEDMAN: Hey, Tim, can I interrupt you for just a second? I think –
you know, we are – in the interest of time, I think what we are really
interested in is your other document.

MR. POLK: 863?

MS. FRIEDMAN: Yes.

MR. BLAIR: The authentication levels.

MS. FRIEDMAN: The authentication levels.

MR. POLK: Yes.

MS. FRIEDMAN: One of the things we had discussion on last time was the
authentication levels, and our cochair, Jeff Blair, had some – Jeff, you want
to kick off this discussion real quick with him and –

MR. BLAIR: Oh, sure. Sure.

MS. FRIEDMAN: – tee this issue up?

MR. BLAIR: Yes. We are really hoping that you may be able to help us
understand what would be the appropriate authentication levels that would
relate to e-prescribing.

MR. POLK: Excuse me, would relate what?

MS. FRIEDMAN: To electronic prescribing.

MR. BLAIR: To electronic prescribing.

MR. POLK: Okay.

MS. FRIEDMAN: We looked at – just to back you up a little bit, the document
was intended for a much wider and deeper use –

MR. POLK: Absolutely.

MS. FRIEDMAN: – and so what we are trying to do here is figure out if any
of those levels actually can be related to electronic prescribing, which is the
charge of this group, electronic prescribing for the Medicare Part D benefit.
So it is a federal program. So we gotta take this stuff into account.

MR. POLK: Absolutely. Okay. Well, the place that we really need to start is
not in this document. It is OMB Memorandum 0404.

MS. FRIEDMAN: Yes, OMB was here and they had a similar kind of hierarchical
set of levels and we weren’t sure how theirs fit together with yours.

MR. POLK: Okay. The set of four levels that are specified in 863 and the
set of 400 levels for OMB 0404 are exactly the same. The document was designed
to align precisely with Memorandum 0404. In fact, we wrote that document
because OMB came to us and said, We have written this memo. We need NIST to
write the technical guidance on how to implement it.

Now, let me say, now that I have said that, 863 applies to a very specific
environment. The assumptions of NIST 863 are that we are communicating over an
open network, that the person that we are attempting to authenticate and the
server that is attempting to authenticate their identity are not co-located,
and we don’t make any assumptions about their being a secure network in
between.

So the first step would be to say, if that is the environment that your
electronic prescribing network works in and – then we would need to look at 04
– the OMB memorandum and determine where you believe you fall on that list of
four levels. That would be our first step.

If you feel that you have a significantly different environment, but say
you own the network and – you know, so no information ever goes across the
internet or the system it is authenticating the identity, you are there
physically present at that server, then you would have – then 863 might, in
fact, be overkill for your environment.

What 863 prescribes for that level – prescribes is probably the wrong word
here, but what it specifies for that OMB level would be stronger, perhaps, than
you needed because your environment had additional protections that we could
not take into account.

DR. STEINDEL: What if you have a virtual private network that is running
over the open internet?

MR. POLK: If you have a virtual private network, then it depends on – if
the virtual private network provides – you may improve things because the
virtual private network may, in fact, preclude some of the man-in-the-middle
attacks and that sort of thing that we worry about in 863.

However, that would also be that you would have to be making an assumption
that all of the systems on your virtual private network are then trusted. If
you are worried about internal attacks from other people who are, perhaps,
permitted to be on the virtual private network, but that are – that you still
have to worry about them mounting an attack on some other user, then you would
not be able to claim that the virtual private network overtook – you know –
over – provided those extra controls. So it depends on your community. Okay.
You are not going over the internet, but are these all fully-trusted people is
– you have to decide what your threats are.

Our assumption is that other people that are on the network are, in fact, a
threat. As long as that is still true, having a virtual private network is
probably not going to change your situation appreciably.

MS. FRIEDMAN: What if you have secure private networks and you have a whole
system of contracts and trading-partner agreements in place to help not only
make it all work on a business level, but also make it work on a trust level?
Is that what you are looking for as well? I mean, those kind of things that add
to the trust levels, I guess, is –

MR. POLK: Sure. I mean, you can always take those things into account. You
now have a virtual private network. You have some other set of agreements that
go with this that compensate for some of those – they compensate for some of
the threats that we list in 863. We would not claim that you shouldn’t take
those into account. I think you should, but it is still the – you have to
decide how much faith you really have in those mechanisms, and you have to
recognize that those are a risk that you are accepting that, you know, how much
are you – are you willing to rely on the trading-party agreement to say I am
not worried about an insider attack, so I don’t have to worry about the
man-in-the-middle attack, then you can do that, but you have to consider
whether or not you believe you can accept that risk.

MS. FRIEDMAN: And just let me – this is Maria again. Let me clarify one
thing I thought you said. Where you guys were really coming from in designing
these risk levels was the insider attack, the man-in-the-middle attack. Did I
hear that correctly?

MR. POLK: Well, there are a list of things that we worry about. At the
highest end, we worry about things like session highjacking, where Alice is
connected to a server and she is authenticated, and then someone else is able
to highjack the session and continue to communicate as if she was Alice, even
though someone else has stepped in. That is something we worry about only at
Level 4.

At Level 3, we had decided that to meet the OMB requirements, you had to
worry about a man-in-the-middle attack. You had to worry about verifier
impersonation.

At Level 2, we worry about things like eavesdroppers. I don’t think you
have issues with eavesdroppers if you have a virtual private network, unless
you have decided that even within your virtual private network eavesdropping is
something that you have to worry about from your community of users.

You might reasonably be able to say, I don’t worry about eavesdropping. I
have the virtual private network, but you still might have to worry, for
example, about the man-in-the-middle attack or maybe about session highjacking.
We would have to look at the actual mechanism that you are using.

But we came through and set up a table. There is a Table No. 3 in our
document, on page 40, that says what the required protections are at each of
the four levels.

If I was looking at a network like yours where I think I could claim it is
appreciably different than the authors were – you were not getting any extra
points for having a VPN in the way we set up 863. I think you would have to
come back and look at the mechanism and say, Does the VPN protect me against
eavesdropper attacks?

MR. BLAIR: Can I –

MR. POLK: – protect against? Well it protects against people –

MR. BLAIR: Can I interject?

MR. POLK: – who are not part of the virtual private network. Then you might
go through different levels, and you may be able to say, I can check off the
boxes that are required at my level to meet the OMB guidance. So even though I
am not using one of the NIST-prescribed mechanisms, my environment gives me all
of those check boxes, and that is what I would key on if I was trying to
demonstrate that my architecture gave me the right requirements.

MS. FRIEDMAN: I think our co-chair had a question. He is going to jump in
here.

MR. BLAIR: Let me try to ask a question that I think might be
representative of the question that many of us may have.

The area where we need help is trying to determine whether typical
environment for e-prescribing should be a Level 1, Level 2, Level 3, Level 4,
and if it is going over a private network, which seems to be that most of the
e-prescribing environments are, to commercial and retail pharmacies, the major
concern, I think, that many of us have is trying to validate that the
prescriber is who they say they are.

MR. POLK: Right. Okay.

MR. BLAIR: And so would that – where does that bring us in terms of Level
1, 2, 3 or 4?

MR. POLK: Unfortunately, 2, 3 or 4 does not have to do with what – what you
have said is that you have one particular threat out of the threats that we
worried about. Really, the remaining threat that you are worried about is
whether or not it is really Bob or Alice.

MR. BLAIR: Yes, I won’t say that we have only one threat. I’ll just simply
say that is the primary threat.

MR. POLK: You know what, I feel like I am overstating that.

MR. BLAIR: Yes, that is the primary threat.

MR. POLK: That is the primary threat. So – but the problem is that OMB 0404
is based on what is the risk for your data if it is disclosed, if it is
compromised, and so it has to do – I mean, so, for example, even though you
only have one aspect you need to worry about, which is what is the identity of
the person – authenticating the identity of the person doing the transaction,
you still could end up at Level 3 or 4 based on the importance of your data,
and I think that people would make a claim that you are probably at Level 3 or
4, because if – for example, I personally am allergic to penicillin. If someone
could change the prescription as it was being sent, that would be – that could
be very dangerous for me in terms of if I am being prescribed an antibiotic.

On the other hand, there are also strong privacy-related things. If you are
prescribing someone a drug that is primarily used to combat HIV, there are
privacy issues that they would probably say rank up fairly high as well. So I
don’t think that we can look at your environment and claim that that reduces
your OMB authentication level. We would do the reverse. We gotta look at your
data and say what the OMB level is, and then we say, But your environment
addresses four out of the six check boxes and we can address the last one in
this manner.

DR. COHN: Tim, just ask a question. I mean, it sounds to me like we are
both – all sort of looking at the OMB document and we are sort of reflecting
that some of this sounds a lot like the HIPAA security regulation in the sense
that what you are talking about – and, actually, what you are saying is being
very useful, because you are sort of a) talking about this issue of being on
the wide-open internet, but you are sort of speaking of – you know, this is
where we would like to get, but there are a range of mitigating or compensating
factors that need to be taken care of – taken into account as one makes a final
determination on exactly what one is doing about this one. That is sort of what
you are saying.

MR. POLK: Yes. What I am saying is that the technical requirements to meet
your – whatever – the OMB authentication level, may, in fact, be reduced by
your environment because it is not something we thought about with 863.

I would also say that I suspect that you are exactly right that the sort of
way they think about your requirements for HIPAA are probably closely related
to the same way that they have laid out the requirements here. It has to do
with what are the consequences of compromise or modification of data when you
set those levels.

So when you determine your OMB level, it has a lot to do with – it has more
to do with what are the consequences, basically, under HIPAA? What are the same
kind of consequences that you have to worry about if this data gets changed or
if the data gets disclosed when it should have been confidential? So you have
to think about that, and then you get to factor in all of the mechanisms that
you use, including things like your VPN’s and your trading agreements. You can
factor all of those in to am I really meeting that level.

DR. COHN: Very appreciative of your conversation here. I am actually also
reminded that – I am hoping in February we are going to hear back from NCPDP
and the industry around what are, effectively, I think, we are describing as
best practices around some of this, which, I think, in your context are now
sort of compensating or mitigating factors around all of this.

MR. POLK: Well, yes, I mean, I wouldn’t – normally, I wouldn’t say that
they are mitigating factors, because they are all technical controls that help
you achieve your requirements. I just keep saying that they are sort of
mitigating factors because if you looked at 863 in a vacuum and said, Oh, we
have to do all of these things to meet either Level 3 or Level 4, that that –
you really don’t have to do all of those things because you have all of these
other technical controls in place that we couldn’t assume.

For 863, our model was much more my mother contacting Social Security over
the internet. That was the kind of environment that we had to assume – It is
sort of the worst case, and it is the one that we had to assume that we were
addressing with 863, but, again, that isn’t the world you live in, and so if
you did the same controls that we would have prescribed for that kind of
environment, you probably will have overkill.

DR. COHN: Okay. Do other people have questions or comments?

Yes, this is being very helpful.

Now, do you have any – we are really sort of asking our questions at this
point. We really appreciate it.

Did you have any other perspectives on this particular piece that you want
to share with us? Because I think you are sort of answering many of our
questions here.

MR. POLK: I think that what I would say – you know, this is the sort of
thing that has always kind of worried us with 863. It has been very difficult –
It was a pretty difficult document to write, and we had to make a lot of
assumptions in the beginning, and I would really encourage you to take the
approach of going through and saying, Here are the controls that we already
have, and what this adds to the environment that NIST had considered were these
features, because computer security should always be cost effective. It should
always be in line with your needs, and we certainly don’t want you to go beyond
that just because when you pull the document off the shelf, don’t just flip to
that level.

The one other piece – the piece that I think you will find perhaps the most
difficult to meet in your environment will, in fact, be the identity-proofing
sections, because one thing that – we have been talking all about the
mechanical mechanisms, but if, in fact, I issue a certificate and I put Bob’s
name on it and I gave it to Alice in the first place, you really don’t know who
that person is. The very first step – the identity-proofing step is key to any
kind of authentication mechanism. Whether it is passwords or PKI, knowing who
that person is when you issue them the original credential is a key step.

You have an advantage in that you are working with people who know their –
I mean, if it’s – you are sort of working with people that know their customer
or who know their internal structure, I think, a lot of times, but I would say
that that is probably going to be the trickiest piece, because I think you have
enough technical mechanisms in place to help you come up with something cost
effective, but that that is the place that I would worry and go back and look.

DR. COHN: Well, that is very well said. I think we all are well aware that
PKI doesn’t really solve that problem –

MR. POLK: Right.

DR. COHN: – and it is really that main input, and we have talked about
biometrics and smartcards and everything else, which I think are the pieces of
technology that you are referencing –

MR. POLK: Um-hum.

DR. COHN: – in terms of all of that, but I think it does give us some
thought. Though, of course, some of that may be as simple as – you know –
really just identifying that that person is who they say they are and getting
all the proof, the notarization, et cetera, et cetera.

Well, I don’t have any more – I mean –

MR. POLK: Getting those key steps – those initial steps right is very
tricky, and, of course, is the – it is the piece where – it is the foundation
for everything else. So it is the one where I think most systems, no matter how
good the technical mechanism is, if they are going to fail, that is where they
fail.

DR. COHN: Okay. Well, Tim, thank you very much. I think you have addressed
our questions and more, so we really appreciate it.

MR. POLK: Well, I’m glad to hear that. I was a little worried. I’m afraid
that the original presentation wasn’t quite on the mark, but I am glad to hear
that I have at least made some progress here.

DR. COHN: Yes.

MR. POLK: And I do appreciate your letting me work remotely. I know that
doesn’t usually make things quite as efficient, but it was very important for
us and we do appreciate it.

MS. FRIEDMAN: Thanks, Tim – it’s Maria – and thank Joan also for me.

MR. POLK: I will do so.

DR. COHN: Okay. And why don’t we give everybody a well-deserved break, say,
15 minutes –

MS. FRIEDMAN: Okay. You’re done. Thanks.

DR. COHN: – and we’ll get together at 20 to four.

MR. POLK: Okay. Thank you all. Goodbye.

(Break)

Agenda Item: ASTM Standards

DR. COHN: Okay. Our next presentation or set of discussions, really, it
really relates to ASTM standards, and we are obviously happy to have Alan
Zuckerman and Lori Forquet – hopefully, I have said your last name – what? Oh,
and Dan Smith. Okay. Thank you. Third one here – joining us for the discussion.

Now, I think before we start, Lori, are you going first?

MS. FORQUET: I will start first, and I will cue in the folks. I’ll give you
an overview of what we are covering.

DR. COHN: Okay. Great.

Okay. I know Jeff has a comment he needs to make before you jump in.

MR. BLAIR: Yes. I will be recusing myself from any votes or decisions
related to ASTM, and the reason is because my employer is chair of ASTM, but I
wanted to go on record that no case and no time and in no way has my employer,
nor has ASTM, ever made any attempts to influence my decisions or the role that
I play as vice chair of ASTM, at this time, or ever in the past. So that should
be on the record that there’s been never any attempt to influence my decision.

Now, in interest of full disclosure, I also want it to be on the record
that there’s been times when we have had folks who are testifying to us where
they have either asked for guidance on how they prepare their testimony or I
have volunteered to assist them so that they understand the questions, the
issues, the focus of the committee, and I volunteered to do that to provide
some guidance as ASTM prepared its testimony. That was not because I was asked.
That something I volunteered to try to assist them and to assist us as I have
done with other testifiers in order to make their testimony more relevant.

Thank you.

DR. COHN: Lori, why don’t we let you lead off, please?

MS. FORQUET: Is the mike on? Because I know I have a hard time speaking up.
So –

DR. COHN: Doesn’t sound like it’s on.

MS. FORQUET: It doesn’t sound like it. Let me try this one.

DR. COHN: Yes.

MS. FORQUET: This one is working. Okay. Make sure I don’t have a problem.

Okay. Lori Forquet. I would like to thank you, once again, for having us
back here to discuss, in a little more detail, some of the ASTM security
standards that would be applicable for the e-prescribing discussions that we
have heard today and, actually, in the December hearings as well.

I did describe my positions prior, but the ones I would like to mention
once again, Chair of E 3120, Health Information Security; and Vice Convener of
ISO TC 215, Health Informatics, Working Group 4 on Security; and I am a member
of IHEIT Infrastructure Committee, and I only mention that because I will be
discussing some of those activities throughout the presentation.

Just an overview of what we’ll cover today: ASTM standards for health
information security and privacy. Dan Smith will give an overview of ASTM, and
then I will describe a little bit of ISO TC 215 activities that have been
conducted through ASTM. ASTM involvement in IHE, and then we’ll move on to just
a little overview of the other possible e-prescribing information workflow
models. ASTM framework starting to go through the ASTM standards that we
referenced last time and believe to be applicable in this space. ASTM
framework, E 20-85. ASTM Internet and Intranet Security, E 20-86. ASTM Security
Standards for Electronic Signature, including E 17-62, which is electronic
authentication of health information; E 20-84, which is authentication of
health information using digital signatures; and E 21-22, which I will actually
be discussing in the context of the ISO uptake of that standard.

I’ll describe, just briefly, some of the industry uptake of the ASTM
standards, and that will be followed by Dr. Zuckerman, who will demonstrate a
product which has had some standards uptake.

Dan.

MR. SMITH: Good afternoon and thank you.

I’ll just have two slides that will provide you a little bit of an overview
of ASTM, and I know – I don’t want to take up more than a minute here.

ASTM is one of the largest standards organizations in the world, and we are
different from most standards organizations in that we don’t specialize in any
one industry. ASTM writes standards in virtually every industry. We have a
membership base of approximately 30,000, and we have about 11,000 standards,
again, that cover almost every industry you can think of.

ASTM is ANCI accredited, meaning that our standards development process has
met the ANCI requirements, and we have had a very strong relationship with many
federal agencies, evidenced by several thousand ASTM standards that are
referenced and used in the Code of Federal Regulations.

Specifically, ASTM E 31 on Healthcare Informatics is responsible and has
jurisdiction of the standards that Lori will be introducing and covering today.

E 31 was formed in 1970, and, today, they have over 30 standards.

The committee is comprised of approximately 320 or so members that
basically cover or basically have membership of all the major stakeholder
groups in the healthcare industry.

So unless there’s any questions about ASTM, I’ll turn it back over to Lori.

MS. FORQUET: Thank you, Dan.

And to lead off from that, ASTM E 31-20 addresses the health informatics
security and privacy standards. These address areas of confidentiality,
authentication, integrity, non-repudiation, access control, audit logging,
privilege management, identity management, secure archive, availability,
including emergency access issues, reliability of data, authorization,
accountability, amendments to health information.

The privacy-standards space tends to address the issues of consent, in the
international space, sudanimization(?), disclosure, trust agreements, training
of individuals with access to health information, and things such as anonymous
care.

The ASTM security-and-privacy standards that I will not be highlighting
today – I did want to provide you a list of the other security-and-privacy
standards, should it come up that you are interested in pursuing any of the
others in more detail. They have to do with unique health identifiers, active
work on defining this security for the continuity-of-care record, which you see
a lot of uptake in the health-information-system-vendors industry for
communication of health information and potentially even communication of
e-prescribing information.

The 1869 Standard Guide for Confidentiality Privacy Access,
state-of-security principles for health information, including computer-based
records. 1985, which is a standard guide for user authentication and
authorization. 1986, which is a standard guide for information-access
privileges to health information. E 21-47, which is a standard specification
for audit and disclosure logs for use in health-information systems, and we
also have an active work item on privilege-management infrastructure.

Those that I will be covering today are ASTM E 20-86, which is a standard
guide for internet and intranet healthcare security; E 20-85, which is a
standard guide on security framework for healthcare information; E 17-62, which
is a standard guide for electronic authentication of healthcare information;
and E 20-84, which is a standard specification for authentication of healthcare
information using digital signatures.

There is also the E 22-12, which is the standard practice for healthcare
certificate policy.

ASTM involvement in ISO health informatic security standards, ASTM was one
of the lead organizations involved in establishing the ISO Technical Committee
215 on Health Informatics several years back, and I want to – I believe it was
1998.

ASTM managed the U.S. Technical Advisory Group, provided the TC Secretary,
during the startup years of that initiative, and ASTM has contributed,
completed an in-progress standards work as a U.S. contribution to the
development of the International Health Informatics Security Standards.

The ISO TC 215 Security Standards, we have a new work. I had a proposal on
sudanimization. We have health informatics guidelines on data protection to
facilitate trans-border flows of personal health information, a technical
report on trusted end-to-end information flows, active work on security
management using International Standard 17799 for health care, and directory
standard, TS 21091, for directory services for security, communications and
identifications of professionals and patients.

Integrating the Healthcare Enterprise, I believe you would be familiar with
it, but IHE is a multi-year initiative that creates a framework for passing
vital health information seamlessly from application to application, system to
system, setting to setting across the entire healthcare enterprise. This is a
vendor forum, whereby specific implementation profiles for the uptake of
underlying standards are defined, tested and demonstrated by the industry
vendors, and this organization is sponsored by HIMS(?).

The IT Infrastructure Committee is working on a proposed profile for
digital signatures and attestation and authorization where the implementation
profiles to electronic signature standards I am describing today will be
addressed. The work is expected to be addressed this year for demonstrations
early in 2006.

We have seen a lot in the information flow from – going from the
prescribers of the drugs that were in question from hospitals or community
physicians through the value-added networks and off to the pharmacy, but we
have not really heard about the other potential pathways that e-prescribing
might be able to take. Perhaps unlikely, but technically feasible, email, EDI,
whether it be via script, HL-7 or the continuity-of-care record, and those
transactions could go from the prescriber directly to a pharmacy, depending on
the networking and the level of integrations within that community.

There is also movement toward patient portable health records on
smartcards, and so that prescription could feasibly be a continuity-of-care
record, for instance, that is put on the patient’s smartcard and carried by the
patient to the pharmacy.

There is also the other integration factor that we need to consider, which
is for the physician and the clinician. It is part of the longitudinal health
record. It is part of the patient record and part of their day-to-day clinical
activities.

The ASTM E 20-85, the scope of that document, as a framework for healthcare
information, is to provide the framework for the protection of the healthcare
information, addresses the storage, transmission of health information. It is
designed to accommodate very large – whether it be national or international –
distributed user bases. It is intended to be spread across many organizations,
and it – in light of that – recommends the use of certain scalable technologies
over others, but note that it recommends and does not prescribe.

The specific existing standards are identified which accommodate many
cases, including those from ISO, ITU, IETF, and our discussions last month,
there was some question as to what underlying security standards might be
utilized in looking at some of the security behind the network security that
has been described here, and so this guide would be suitable for taking a look
at whatever the architecture is and looking at the underlying engineering
standards and recommending the appropriate use of those standards, where
possible.

This document also discusses the high-level requirements for healthcare. It
details the requirements in other documents. So this is only addressing the
high-level requirements. Details would be spelled out in other documents, such
as the E 17-62 that we’ll be discussing.

Where the healthcare-specific requirements may be met by extending an
existing standard, we would also prepare a new document, and that would be the
case with E 20-84 that I’ll discuss.

E-threats. The 20-85 document provides a security overview of the potential
threats that the security services may detect or prevent attacks from. This
would include Masquerade, which is successfully pretending to be another
entity. This would include impersonation of users or system components. It
would include falsely claiming origination or acknowledging the receipt of a
message or a transaction. An example of this might be an individual
masquerading as a physician in order to attempt to write a prescription for a
narcotic or other controlled substance.

Other threats would be the potential for modification of information,
modifying a message or data content, destruction of messages or data. An
example of this threat would be an attempt to change the prescription quantity
or dose in an attempt to divert drugs.

Message sequencing. Orders of message would be altered, and this would
include replay, preplay, delay, reordering of messages, and an example of where
this might be used would be to capture a password message when a legitimate
user logs on and later replay it to masquerade as that user.

Repudiation as a threat, as opposed to non-repudiation. Repudiation,
whereby the user or the system denies having performed some action, and that
might be in the origination of a message. It might be in the receipt of a
message, and the example of that would be a physician who might be accused of
over prescribing. They may deny having written a prescription.

Then there are other – threats described that are perhaps a little less
pertinent to this discussion: Unauthorized disclosure, revealing message
contents or other data, but very important for HIPAA, and denial of service,
which would prevent the system from performing its functions.

The next document I would like to discuss is E 20-86, which is a standard
guide for internet and intranet healthcare security. This covers mechanisms to
protect healthcare information transmitted over internets and intranets. The
guide covers relevant standards and recommends, where needed, the particular
options to be used within those standards.

The significance in use is that the guide recommends security mechanisms
for the protection of health information transmitted using internet protocol
suite. This includes an overview of security threats, which is actually the
same overview, but in order to keep the documents whole and not relying on one
another, they are repeated in 20-86 as they were listed in 20-85.

It also provides a relevant overview of cryptography as that is the
fundamental technology that is used in a protection scheme. It distinguishes
between network and application-level security. It discusses when each level of
security for network versus application might be useful, and it makes
recommendations for security protocols – specific security protocols and
mechanisms, both for network and application security needs.

At the network security level, the network security services protect the
data in transit between systems, and this is appropriate where the end system
is not trusted by the underlying – the end system is trusted, but the
underlying network is not. This is appropriate where the protection is required
for all or most of the traffic between systems.

Application security measures are built into a particular application and
are independent of the network layer.

It describes where pros and cons of various approaches, considerations are
described for efficiency. Considerations are described for making choices
relative to cost. Those services which associate data with an originator or
recipient, it states, are best at the application layer, and this would be for
things such as authentication and non-repudiation. It would not do that at the
network layer.

Cryptographic protection across the network is useless without the proper
security mechanisms on the other end system, and as we start reaching these
networks into organizations and individuals over whom you have no control, they
need to be assured that they are providing appropriate access control at the
other end of the wire, that their local systems are providing user
authentication at that end, that they have proper configuration management,
that they are patching and their security updates are all done and not
threatening your system via their network, and they must have robust audit
procedures in order to capture mischief behavior.

Moving on to the next standards I’m going to discuss 1762, the Standard
Guide for Electronic Authentication of Healthcare Information. This defines the
document structure associated with a document that must be signed. It describes
the characteristics of the process in applying a signature, the minimum
requirements for different mechanisms and technologies, and I spelled many of
them out last time, so I won’t repeat them. The minimum requirements for user
identification and access control. It outlines technical details for all of the
electronic signature mechanisms in sufficient detail to allow interoperability.

The objective is to create guidelines for entering information into a
computer system where the assurance that the information conforms with the
principles of accountability, data integrity and non-repudiation are assured.
User authentication is used to identify an entity and verify the identity of
that entity.

Data origin authentication binds the entity and verification to a piece of
information, and the signatures have been a part of the documentation process
of healthcare have traditionally been the indicators of accountability, and as
we moved into the electronics space, we need to assure that accountability is
propagated.

The requirements for E 17-62 include non-repudiation, integrity,
secure-user authentication, multiple signatures, signature attributes,
counter-signatures, transportability, interoperability, independent
verifiability and continuity of that signature capability.

Currently, there are no recognized security techniques that provide
non-repudiation in an open network environment in the absence of trusted third
parties, other than digital-signature-based techniques.

The generation of electronic signatures requires the successful
identification and authentication of the signer at the time of the signature.
The standard acknowledges the efforts of the industry and system integrators to
achieve authentication with other methods and is, therefore, not restricted to
a single technology.

Data and information for which authentication is required, the system needs
to provide the signer an accurate representation of that information that they
are about to sign. They need to be able to append one or more signatures,
particularly in healthcare. They need to include information associated with
the assigner, and this may include appending zero or more document identifiers
as attributes.

The internal structures of the health-information content are recognized to
be defined through other standards. We are not looking to define the message
content here, only wrap it.

Mandatory attributes include signature and time. Other attributes for
signatures, optionally, would be location, things such as the signer’s role,
the signer’s organization, document links, biometric information, annotation
and other optional attributes.

The electronic-signature technology discussed user authentication using
passwords. It lists requirements for the communication of passwords when
passwords are used. It lists requirements for generation of passwords when
passwords are used. It references standards for sound practices of password
utilization.

Generally, the common practice of simple user entry of passwords is
inadequate to meet the intent of the electronic signature, but recognizing that
that is active and in place, we have denied some standards surrounding that.

It also describes the use of secret-key cryptography for user
authentication, public-key cryptography, biometric and token-based.

The data-authentication component defines technologies of digital
signatures, approaches of private-key protection using password-protected
encrypted approaches, public-key authentication, digital-signature
representation and secret-key-based data authentication.

Other items that are addressed are time stamps, and there is an informative
appendix, including information on digital-signature technology, biometric
authentication, time-stamp technologies and organizational policy issues that
might be relative to signatures in healthcare.

The next document is E 20-84. The scope of this document is a standard
specification for authentication of healthcare information using digital
signature. So, whereas, 17-62 is not specific to digital signature technology
and is permissive, if you are to use digital-signature technology, this is the
standard that has been written to support that.

It covers the uses of digital signatures to provide authentication of
healthcare information as described in the guide, E 17-62. It describes how the
components of the digital signature systems meet those requirements and
includes the specification of allowable algorithms, key management and key
formats.

The specification describes one implementation that meets all of the
requirements of 17-62. It does not purport to be the only approach.

An overview of the document, the digital signatures are cryptographic
technique in which each user is associated with a pair of keys. There is a
piece of data associated with a document which allows the recipient to prove
the origin of the document and to protect against forgery. The overview
describes the concepts of the signing and verification process.

The contents specifies mapping algorithms, procedures and data formats to
the electronic-signature requirements from E 17-62. It recommends specific
algorithms for the various approaches, public-key management requirements, such
as the user shall obtain the signer’s public key from a source that he or she
trusts, and that is going to be very dependent on the domain in which you are
implementing. The specification does not impose any structures on CA’s.

The private-key management, the user’s private key is intended to be
protected from disclosure to others. It recommends to use a tamper-proof
cryptographic module, such as a smartcard. However, it also recognizes that it
is an acceptable approach to encrypt a secret-key computer from a password
entered by the user and stored on removable media, such as a floppy disk – or
USB’s. The technology moves forward.

Specification for data structures – ASM 1 specifications for the data
structures are also defined.

We get now into the PKI security documents.

E 21-22, all of that information was contributed to the ISO TC 215
technical specification for healthcare PKI. So I am actually describing
consensus work between the two.

The risk for PKI security – and we heard that loud and clear, particularly
from NIST today – would be identity fraud, the ability to trick the CA into
issuing a certificate to the wrong person, and this might happen at the time of
registration, if you are able to misrepresent yourself to the CA; within the CA
management itself, such as the ability to bribe the staff; within the CA
hardware or software, if you hack into that machine or physically access the
machine and cause it to sign where it wasn’t intended; to forge a CA signature,
perhaps steal the certification authority’s signing key and use it without it
knowing it. Credential fraud. Can you trick the registration authority into
attesting to the wrong credentials? And the risk of stolen identity. We need to
be able to protect the private key, and the users do need to be educated as to
their responsibility with that key and that it would be holding their
signature.

The requirements for PKI in a healthcare context that we were addressing
through the standards objectives are the reliable and secure binding of the
unique and distinguished names to the subject, their professional roles in the
healthcare space to the subject, and attributes, when they are used, that may
be used to secure the communication, such as identifiers. Where do we represent
the health identifiers in the standard? And we need a high level of assurance
for this infrastructure, infrastructure availability, trust and internet
compatibility. We need to facilitate the evaluation and comparison of
certificate policies.

The technical specification. Defined essential elements of the healthcare
PKI that would support secure movement of information across national
boundaries. This includes the authentication of healthcare providers and their
roles, the identity of extensions to X 509 certificates to represent the
additional information that we are attesting to, such as their healthcare
license, to get an agreed set of policies and procedures for authentication and
verification of healthcare provider accreditation.

We defined within 17090 a healthcare role extension. This is intended to
define minimum policy requirements for the secure binding of the identity to
the person and that extension can then represent the healthcare profession. It
can represent regulatory identifiers. It can represent professional
identifiers, consumer identifiers, health insurance claim numbers, employee
roles. We made it general to be able to support any of the healthcare
identifier needs.

The document is split into three parts. Part one is a framework and
overview. It defines PKI concepts, components and interoperability issues with
respect to healthcare. It is much more of an administrative overview in how and
where you should use PKI for healthcare.

Part two is a certificate profile. It discusses the detailed ASN 1
specifications and what those – in every single field of the X 509 certificate
and the custom extensions that we added.

And part three is the policy management of the certification authority, and
this defines the minimal requirements for certificate policies and
certification practices for managing a CA.

There are 15 scenarios in part one that include scenarios for
authentication, confidentiality, integrity, digital signature, including a
scenario for electronic prescribing.

The identities that we discuss at that level are the healthcare
professional, whether you are a doctor or a nurse; a healthcare employee, such
as medical-records clerks; non-regulated professionals on some locations –
midwives or social workers may not be actually regulated healthcare workers, so
we need a binding to the healthcare space – supporting organization employees,
such as your insurance-claim clerk; and consumers, be they anonymous or
identified consumers.

The regulated healthcare organization, such as a pharmacy, if you are going
to issue a certificate to a note on the network or to the pharmacy, rather than
the pharmacist; supporting healthcare organizations, their billing services.

The authentication of the individual’s identity, to get that strong
binding. We have defined an in-person registration, a face-to-face within the
process, and they must, at that time, demonstrate a government-issued photo ID.

Regulated health professionals shall also present proof of their
professional credentials established by the professional regulatory or
accrediting body in their jurisdiction. So, in our case, it would be at the
state level. In other countries, it may be national.

Non-regulated healthcare employees and sponsored health professionals shall
present proof of sponsorship or other binding to the healthcare organization
saying that they are either an employee of the healthcare institution or a
practitioner. Supporting organizations shall present proof of employment by
their supporting health organization as well.

The types of security controls are in accordance with ISO 17799 or other
approved accreditation. This addresses the physical controls, procedural
controls, personnel controls, network controls, cryptographic module
engineering controls, repository management, security audit and records
archival associated with the infrastructure.

IHE has a proposed profile that we’ll be addressing this year, digital
signatures for attestation and authorization. The overview of this is that
signatures have been part of the documentation process and the healthcare and
traditionally been indicators of accountability.

For electronic-health-record systems to be accepted, they must provide an
equivalent or greater level of accurate data entry, accountability and
appropriate quality-improvement mechanisms.

In this context, a standard is needed that does not allow a party to
successfully deny authorship and reject responsibility through non-repudiation.

Reliance upon the electronic health records and other forms of electronic
health information requires an electronic-signature process that provides
satisfactory evidence of information’s authorship, approval, review or other
ownership. In particular, acts of attestation and authorization require a high
degree of assurance for accountability and data integrity. As electronic health
records are shared across healthcare enterprises, digital signatures can be
used to provide such accountability and non-repudiation of signatures used both
for attestation and for authorization.

Attestation and authorization require all the security services that
digital signatures can offer to check that the prescription is verified as
having originated from a particular health professional with appropriate
credentials. Ensuring there are no errors in the transmission requires the
integrity, service, and accountability requires the service of non-repudiation.

The types of standards that we’ll be addressing at this stage through IAT –
although we will probably bring in more – are the E 1985 Guide for User
Authentication Authorization, the Technical Specification 17090 of healthcare
PKI that I just described, the IETFRC’s on X 509 P KIX(?), the IETFRC’s on
S-MIME(?), ASTM 1762, 2084 and 2212 that I have described.

The digital-signature profile will cover the supporting services that may
be and that must be invoked as part of the signing processes, the supporting
services that may be and that must be invoked as part of the
signature-verification processes, the signature attributes for use with
digital-signature mechanisms, minimum requirements for user identification,
access control and other security requirements that must be in place to ensure
the integrity of the signature, types and characteristics of health information
requiring signature and associated constraints, requirements and approaches for
multiple signatures, requirements and approaches for nested and embedded
signatures, requirements for preserving signature integrity and intermediary
processing and information forwarding.

The legal environment is determined to be out of scope. Legal constraints
surrounding digital-signature constraints are by law.

Separating the signing from the document-signing mechanism and signing
generically by format, each having their own mechanisms. The counter-signature
and attestation part. The authorization would be linked to workflow, breaking
that into a separate part, and the structured documents.

We have a few examples of implementation of the standards. The VHA,
Veterans electronic-signature requirements for that project, the requirements
that they are adopting are the Government Paperwork Elimination Act, ASTM
17-62, ASTM 20-84 and 21 CFR Part 11.

Kaiser Permanente had also done some activities in deploying a PKI in
compliance with the ISO specification.

The Australian HIC is already deploying PKI, although not yet for
e-prescribing, and it is under planning in other countries, and Med Plexus(?),
formerly I-Trust(?), through AAFP, the EHR pilot study, which Dr. Zuckerman
will be demonstrating.

DR. ZUCKERMAN: Okay. Thank you.

I am Alan Zuckerman. I represent the American Academy of Pediatrics to
ASTM, and I am also speaking on behalf of Rick Peters, who represents the
American Academy of Family Physicians, and I am also beginning work on the
certification of interoperability with EHR, including digital signature.

What I would like to take a few minutes to do today is to bring a physician
perspective to the everyday use of these standards and try to demonstrate that
we can use digital signature today, that it is being used to sign prescriptions
in physician offices, and it doesn’t have to change workflow or change the
appearance of the applications.

It is important, of course, to think of prescriptions as clinical documents
and not just messages on the internet. The software which is running in this
computer here – but, to save time, I have captured screen shots so we can move
a little bit more quickly – is built largely using open-source libraries to
implement the standards and modeled in compliance with these standards.

One particular feature that it uses that is a little bit different from the
VA demonstration you saw is the concept of creating keys and putting them –
when you create the user account – putting them in a lockbox. This, of course,
doesn’t measure up to the registration standards we would want to go to in the
future, but it certainly makes the system very transparent to the user.

The Med Plexus EHR is a commercial product. It has been in use since 1999.
It has been the product used in the American Academy of Family Physicians EHR
pilot project, also often misnamed an open-source project, which it is not.

There is a CMS-funded evaluation of the implementation in the offices that
doesn’t deal specifically with digital signature that’s nearing completion, but
the important message is although the pilot is just in five practices
distributed around the country, about 25 physicians or over 40 practices using
this – well over 100 physicians – digitally signing prescriptions every day
with this software, and it is a full PKI digital signature, but it is
completely transparent to the user.

Part of the reason for that is that they have turned off the smartcards,
but, in fact, smartcard readers have gotten smaller, and I did want to make the
committee aware that these USB devices are full-fledged smartcards, as is this
PCMIA card. So we should get away from a pure credit-card model, plugging in
these devices, which have both a card and reader function, together show what
is happening.

Well, what did I do this morning? I opened a security middleware. I logged
on to the EHR, got my cockpit which lists appointments, selected a patient, was
able to view the existing prescriptions on file, which included one for
Amoxicillin written two days ago, and what I am going to do now is create a new
encounter, and, for that encounter, start a new document representing a new
prescription, and I need to link that to the encounter because of the way this
EHR is structured, and then I select the medication.

What I am doing is going through a common scenario, where if the first
antibiotic fails, we are moving to an alternate here, Seftin(?). So the EHR
does an alphabetic search, brings me to an e-prescribing screen. I think you
have probably seen many of these, and they could also be copying from a
template. What is a little bit different here is there a signature button at
the bottom of the screen which is asking me to get ready to sign.

When I do get ready to sign, alerts will come up. The prescription is now
converted to a document and it is ready to sign, and when I click the sign
button it asks if I want to send this by fax, by paper, and, today, this has
been expanded to SureScripts as well, but I don’t have the SureScripts software
here with me today, and when you sign, you reenter the PIN.

So, in effect, if you are configured to require the smartcard, we have the
smartcard as one factor, and we have the user’s PIN that is entered just in
time to complete the transaction, and the prescription is now sitting there in
EHR on the printer or as a PDF that we can email is the prescription.

But, now, let’s bail out of the EHR application, take a look at the
internals to show you that while this conventional process has gone on, we have
also generated the PKI.

Here, in a particular directory, residing on my hard disk is a print file
which is the XML prescription, and here you can see the prescription itself.
Medication is Seftin. It has quantity, frequency, all the usual fields. This is
very similar to the SureScripts XML prescription structure. In fact, the
translation is now being done.

What happens next is we have a signature section, as prescribed in the ASTM
standards that have been followed, which includes this string of characters
here which is that encrypted message digest encrypted with the private key of
the user, as we have had presented previously, and it also has the information
about the prescriber, and ID link is encrypted, the time of the signature, all
the other types of fields as prescribed by the standard, and it just is
generated as part of clicking on the signature, and the method of storing the
keys is a very important part of that. These are residing on this computer in a
keys directory and for each of the users there is a subdirectory which has four
files in it. One is that triple-DES key for symmetric encryption, so that we
can store data and transmit it. There is a user-password file. There is a
private key and there is a public key. Well, these are sitting here right out
in the open, so something seems wrong, but when you open them up – and I am
opening it just in Notepad and we can do it later – they have been encrypted,
and so they are not useable, because they have been encrypted by the security
middleware. It works pretty much like a safe-deposit box in a bank. To actually
use this key, you need to have the user’s PIN to unlock the box, but you also
have to have the bank’s key to open up this lockbox, which is holding the
private-key credentials.

Also, if you look out, we have properties here, and we have these various
software JAVA jar files, which are themselves digitally signed. Instead of
using a virus checker to see that no one has tampered with the cryptographic
module or with EHR application, they are digitally signed, so that you can tell
if the software has in any way been modified, and if we open the property’s
file, you can see there are just a few lines of code to convert from this
lockbox folder, which can be on the client or on the server, to a smartcard,
and we could enable a particular smartcard and link to the appropriate
cryptographic library with 60 seconds of editing a configuration file.

If we now move over to the sequel server and open up the actual data
objects and you look inside the database record, this prescription for Seftin
has the generic and brand name, and it has all the specifics and details in XML
stored within the database to hold all of the XML prescription.

We also have a separate object for the document itself, which actually has
the complete XML of the entire document from start to finish, whether it is a
clinical note or a prescription, and in that document we have a series of
fields for the name of the signer and the type of the signature, the time it
was signed, and all of the other signature fields are stored here in the
database, all this happening multiple times a day without the physicians even
being aware that a signature has been placed on record, and when the
prescriptions are sent outside, we simply leave the prescriptions behind.

And in terms of registering the user, these keys, and the whole process, is
just a consequence of creating a new-user account with administrator
credentials, but what would be necessary to take an application like this to
the next level would be to involve a third party, at this point, to bring in
the certification from someone such as the DEA or their sub-CA authorities.

And the points I’m trying to make is just that PKI digital signature
actually is in use. It can be totally user friendly and transparent. The
standards – we protect the keys. We have a lot of different ways of protecting
them, such as this lockbox approach or simple smartcards that can be made not
too intrusive. They require that we use specific cryptographic modules, and in
the appendix of all the standards, there is an exact list, and those plug-in
module jar files that I showed you implement the particular SHA 1 and DSA
signature algorithms that are used by this application, and they also require
that we capture and save some fields on the signature and attach that to the
record of the document. You saw both in the database representation and in the
XML document that it is not overly difficult to comply with the standards and
put in the relevant parameters, including the algorithms used, into the
document record.

And the conclusion that I hope you will share with me, that is, if we
simply the registration process and we don’t require extremely expensive
add-ons, such as biometrics, this type of activity is feasible, and if we
actually encrypt keys and consider leaving them on servers under appropriate
protection of smartcards and other tokens that we can have applications that
function totally without the knowledge or interference of the physician’s
normal workflow, and the experience of the past year in this EHR project, which
has this buried within the software, has pretty much shown that. Most of the
physicians totally unaware that digital signatures are there along with their
name on every document that they have signed.

Thank you.

DR. COHN: Okay. Thank you all very much for some very interesting
presentations.

Questions from the subcommittee? Stan, you had a question, please.

DR. HUFF: The one thing – I think the one question, even since the previous
presentation, that I had was when do we really need this? And what I mean by
that is, I mean, within our institution, at least, you know, regular log-in and
password and other things have seemed to be sufficient for all of our business
needs, and why – granted, it is feasible, but why would we go – I think
everybody would grant that it is at least extra work and extra software, even
if you can make it invisible in the application. So what are the use cases when
you see that this extra level of non-repudiation and security are needed?

MS. FORQUET: When you are outside of the control of the other entity in
that organization to whom you are communicating with, you can no longer apply
sanctions and some of the other security processes and mechanisms that we do to
assure a secure system.

DR. HUFF: But in – I mean, both in the – that is typically not the
situation I ever deal with.

MS. FORQUET: Um-hum –

DR. HUFF: And in the e-prescribing networks that we are conjecturing, that
is not the situation either.

MS. FORQUET: As you start moving into an electronic-health environment
where you are not necessarily dealing with clinicians and providers that are a
part of your controlled network, that is when you start needing to cross the
control boundaries of domain and have interoperability issues. So –

DR. HUFF: So it’s the environment where we conjecture that, for instance,
the patient is holding their record, which is an aggregation of many records
that were generated by authoritative physicians or providers or others who
contributed information to that record where you see the greatest utility?

MS. FORQUET: That is one scenario. The other would be the local
health-information infrastructures where you are trying to build a longitudinal
record within a community, within a region and try to better service the
quality and cost of health care.

DR. HUFF: But that would then seem to be problematic in terms – if I am
dealing either in an LHII or in a personal record that was held with these,
now, I am not trying to decrypt one signature. I’ve got, potentially, hundreds
or thousands of documents, all of which have certificates and private keys, and
I am going to have to have access, then, to some directory of public keys in
order to decrypt or to verify the validity of that information. Is that true –

MS. FORQUET: Let me distinguish it is not the encryption. The encryption is
–

DR. HUFF: Yes, I said that wrong, but in order to verify that that data is
accurate, I am going to have to have access to potentially hundreds or
thousands of public keys.

MS. FORQUET: Key directories is one approach, and, as I indicated, we do
have an ISO standard to address that kind of a community directory, but, also,
what is typical when you sign a document is to send your certificate along with
the document, so it can be verified, so, in most cases, you are not even
needing to look it up in the directory.

DR. ZUCKERMAN: That was what the DEA told us this morning they want to
happen. They want the public key to travel with the prescriptions. When a
physician releases that prescription, whether an LHII or a pharmacy, a public
key is there to verify it, and that was what the VA was doing that the VA
didn’t have to have directories, that the prescriptions, as sent by the people
who are writing them, could be verified from internal information in the
document.

MR. GLICKMAN: Can I say something? I mean, am I allowed to say something?
To answer –

DR. COHN: Sure. We are going to be transitioning to open mike anyway soon.
So I want you to come to a microphone, introduce yourself and make a comment.

MR. GLICKMAN: Well, I just – Are you going to still have the open mike –

DR. COHN: No, we will –

MR. GLICKMAN: Okay.

DR. COHN: We were transitioning to that in minutes anyway.

MR. GLICKMAN: This is Mike Glickman. I’ll make some comments when the
open-mike session comes, but in terms of the user name and password, that
really works best in a closed system, and the issue is if you looked this
morning at what was working for the gateway-oriented network environments that
the e-prescribing vendors were using, it is a simpler problem.

So the idea is that the only really established way to have non-repudiation
is through some form of PKI. It is not going to be user name and password. You
know, that isn’t really a digital signature.

So if you were able to have a two-step process, for example, where all you
had to do was authenticate that I knew I had a public key once before and
stored that away, even if I am doing a personal health record, I am the one
that dealt with the doctor in the first place. I will have one instance of his
public key, and then when another one comes along, it is not that I am going to
have to look at thousands of other people, I’ll take the public key. It’ll be a
second instance. I’ll run it through the algorithm and it’ll work.

So I just see that, in a closed system, it is a simpler problem. In an open
system – in the open internet, it is a much more complex problem, and we don’t
want to do it twice.

DR. COHN: Harry had a question.

MR. REYNOLDS: Yes. Dr. Zuckerman, take me through, with the digital
signature and everything – and the PKI you had in there, take me through that
if it leaves your office and goes through four or five other points and is
translated and has the other things happen to it that we all talked about today
and can happen, help me with how that stays intact.

DR. ZUCKERMAN: Well, if we are going to be compliant with our signature
standards, and if we are going to be interoperable, the only thing we can sign
is what leaves the office, and so the original document probably has to travel
from that point end to end. Whatever other translations, whatever other events
are done, they will be a second document that might be signed or counter signed
by another intermediary, but the essence of the standards, the essence of the
method is that the signature is totally dependent upon the document which is
being signed.

Now, on the other hand, much of the information in electronic prescriptions
really aren’t being translated. They are being reformatted, and the only thing
that is changing is the punctuation and the labels that surround data which
itself is constant, and if we develop very good translators and we have certain
XSLT, XML translator programs we could move from one format to another without
touching the internal content, and if someone would certify interoperability of
two different formats, you could never move the signature, but you could at
least verify that the data, as it originally left the office, hasn’t been
changed in any of the key fields of content when it arrives at its final
destination in a slightly different-appearing way, but if you change the drug
name, if you re-code it, if you substitute different names – but as long as you
have all of the content remain constant, then there is not a problem.

MR. REYNOLDS: I’m still not comfortable I got an answer. I mean –

DR. ZUCKERMAN: Again –

MR. REYNOLDS: No, no, no, the reason I am saying it is I think I heard you
initially start off and say there might be two documents, one that goes
straight to the pharmacy that says, Hey, I have signed this and I am sending it
to you, and, oh, by the way, it may come through another path, but when it gets
there, I did it.

DR. ZUCKERMAN: The only way you could verify that you did it is verify the
signature on the first document and then field by field match the content.

MR. REYNOLDS: Okay. Okay. Thank you.

DR. COHN: Steve, I think the last question and then we’ll move into open
mike.

DR. STEINDEL: Yes, I have, first a comment and then a question.

It sounds like one of the deliberations that we have to reach is –
prescribing world what constitutes a closed system, because that seems to be
somewhat of the key of how much risk is involved with this and whether or not
we consider the e-prescribing system is defined to us sufficiently closed
because of the agreements. That is what I heard somewhat from NIST and what I
even just heard right now. You know, that if we could define it as some type of
closed system, then what we need to do with it is less.

Now, I have a question concerning the application that you showed. Where is
the certificate? How is the certificate generated?

DR. ZUCKERMAN: Unfortunately, in this application, which was written
earlier, they are not using typical certificates. Instead, the fields that
would create a certificate are generated during the user-account creation and
they are working, now, to package them as a certificate. This is not up to the
standards of certificates. To use this in a full certificate-based,
third-party-authenticated world, you have to bring the certificate in or
actually obtain it during your user-enrollment process within the application,
because it is a closed system, and they are generating their own certificates.
They are self-signing their certificates; that is, in effect, there is a
certificate, but it is self-signed by the same vendor that is providing the
application.

DR. STEINDEL: Yes, and from what I – my understanding of a PKI that is
being used outside of a closed system, I mean, where your biggest problem comes
about is with the cert –

DR. ZUCKERMAN: Absolutely.

DR. STEINDEL: And I think anyone would agree that what you were showing
with your application, while it was very similar to what Stan is doing with his
application – it may have little twists and turns that are different – but the
big problem is when we are looking at the cert itself and how it is verified as
being correct and still in effect, et cetera, especially when we have to go
through 15 bridging authorities to try to trace it back, and that is a
real-world situation.

Thank you.

DR. COHN: Thank you all very much. Really appreciate it, and I think we are
just going to have to mull over how this applies to everything else, I guess,
is really going to be part of the question, but thank you. Very useful.

Agenda Item: Open Microphone

DR. COHN: Okay. Why don’t we move to open microphone? Do we have anybody
who would like to make any comments?

Ross, would you like to introduce yourself and make a comment?

MR. MARTIN: Ross Martin from Pfizer.

Actually, I have a question for Dr. Zuckerman, before he leaves.

Based on the DEA presentation from this morning, it doesn’t sound as though
– even though you are using PKI in this situation – that it would pass muster
with what they are sort of proposing for Schedule II medications. Would you
agree with that?

DR. ZUCKERMAN: Yes, but it is not a major process to adapt it to
certificates that they issued, place them into the smartcards and tweak the
software so that it will work with it, because we are working with the same
standards.

The key is the DEA, in their documents, have said they are going to use
specific certified algorithms. These are the same ones that exist in this
library. Just tweaking the configuration to point to a smartcard that they have
generated. Once you get past the registration – It takes me a long time to
register with the DEA for a paper certificate. Once you get past that hurdle,
then you just plug your certificate in. You can use an application exactly like
this, as long as they don’t require the biometrics, and if they do, there are
ways to work around that, but it is a little more obvious to the physician.

So everything you have seen today could work with a DEA-issued certificate,
but you have to go through that process first.

MR. MARTIN: Yes, I guess my point in that is I am just concerned that the
very parts that you have to add back in are the ones that are the most
cumbersome, and I think you guys all see that, too.

I wanted to just ask if – as we move toward the timing of when PKI would be
required, and if there are interim steps, and if you are going to make any
recommendations about the other things that could pass muster – For example,
within the e-prescribing environment, if we could test against Medicare Part D
provisions along with – and try to get this tested with the DEA – whether or
not the model of sending the electronic prescription for Schedule II just as a
normal prescription, printing off a copy of it, having a wet signature on that
with a printed script, so that – because the DEA language isn’t clear to me
whether or not the entire prescription has to be handwritten or a wet signature
is required or a handwritten signature is required on a printed script, and I
think it is the former, but if you could have a printed script with a wet
signature on it that accompanies the patient, so that when they pick up the
prescription that was delivered electronically, you’ve got the best of both
worlds, if you will. You’ve got this thing that is required today of the
validated signature, but you’ve got all the checks and balances and audit-trail
capabilities of the electronic process going in conjunction, and you have
something that is not very different from what you do for everything else. The
only additional step is printing out, or, in the case of what Goldstandard was
doing, faxing back a copy for the doctor to sign and hand to the patient.

MS. FRIEDMAN: Why would you want to do that? It seems like double work.

MR. MARTIN: The only double work is for Schedule II controlled substances.

MS. FRIEDMAN: I know, but I’m saying that why would you want to do that,
because you are dropping back to paper anyway, so why bother? Why bother with
the electronic portion when you are just dropping back to paper –

MR. MARTIN: Because you get the drug checks. You get the opportunity for
the fill notification that says, yes, this written prescription that otherwise
would have no other connection to everything else that you are doing
electronically with electronic medical record, with all these other
opportunities that e-prescribing provides, and you are also not having to write
out the entire prescription. All you are doing is signing it.

So there is very little double work, I would contend, with doing it that
way. You are just validating it through another channel, which is kind of what
you need – that extra assurance that you need, and it seems that that could,
potentially, fulfill the DEA requirement, but I would like to test that.

DR. ZUCKERMAN: Can I just mention that that is normative practice, but
depends on the exact local regions, because some states are requiring special
paper, other copies, but, at least in this region, this is what many of the
physicians do, we do write our controlled-substance prescriptions using
e-prescribing, hand sign them on paper, hand them to the patient. Still means
the patient has to come into the office, because there are no refills and –

MR. MARTIN: Do you electronically sign – I mean, do you electronically
deliver a copy of the prescription –

DR. ZUCKERMAN: You are not allowed to.

MR. MARTIN: That is my point is that you also want that part of it to
happen as well.

DR. COHN: I hear where you are going, Ross, but I am not sure that that is
a critical piece, since, if you think about it, if you do it electronically,
locally, you are doing all the drug checks, and, at the pharmacy, they still
have to enter it into their database, and then they are, once again, doing the
drug check. So I think you are sort of getting both of those, I think, if you
think about it. I mean, you are getting sort of both. So, I mean, you know –
what I am saying is that your solution isn’t the only one to get the drug
checks involved. So – but it is a reasonable thing to think about.

Any other comments or – Okay. Thanks.

Please.

MR. GLICKMAN: Well, good afternoon. I thank you for the opportunity for the
open mike and a chance to address this group.

My name is Michael Glickman. I am with Computer Network Architects. I am
one of the original 12 members of the HL-7 Working Group, involved since about
March of 1987.

I am also the First Chair of the HIMS EHR Steering Committee. I am involved
with TC 215, Working Group Two, on messaging and communications, and our group
is currently coordinating and serving as a liaison on an international scale
with the IEEE with medical devices, HL-7, and, recently – though it has taken
about 4-1/2 years, when I say recently – the Dicom(?) community has been
involved in liaisoning with the ISO world as well.

One point I wanted to make to the group – and I am sure you all know it,
but kind of for the record, if you will – that it is exponentially easier to
coordinate standards up front than it is to try to harmonize them after the
fact.

So one thing that I wanted to say is that a digital signature must provide
not just – to be truly a signature in the original sense of the world, it must
provide not just authentication – and audit, but it also has to provide
non-repudiation.

I have heard the phrase non-repudiation used a lot of ways today, and the
one that comes out of the standards and the one that was mentioned by the NIST
people is the prevention of an entity from denying previous actions. That is a
very important point.

PKI, I think, is recognized as truly a highly scalable and well-established
method to establish and maintain security between trusted parties, but there
are a lot of other ways to do it.

I think the e-prescribing group that testified earlier was solving a
simpler problem, if you will. It is kind of like – you know, a lot of us are
scientists in the room, but solving mechanics and thermodynamics and you avoid
friction. You know, it makes the mathematics a lot easier.

The notion is when you have gateways and a closed system and centralized
processing, I mean, that is what it takes to deliver a product today, and these
groups have delivered successful products, but they have, to a certain extent,
ignored the kind of problem that you all are – the daunting test that you all
have to face, and that is how does it work in a larger environment and how will
it work effectively in an open environment.

So – the groups that also testified earlier, and all of the local and – you
know – enterprise-specific implementations have implemented policies and
procedures, and they have implemented service levels and trading-partner
agreements. So that it is not just the PKI infrastructure. If you would just
say, let’s mandate PKI, that wouldn’t get us any closer to non-repudiation, you
know, at the end of the day – that would be a lot of days – than it would
today.

The notion is that we also – you know, I am sure in those service-level
agreements that wasn’t mentioned today there’s probably remedies and liquidated
damages and other sanctions that are associated with disclosing that
information. So it is not so much – you know – PKI, per se. It is the fact that
we want to have a method, if we are going to do a digital signature, if we are
going to follow the paradigm that I can sign it and only I can sign it. Others
can verify that it’s me and that I can’t deny it after the fact. Those are
three very important attributes of a digital signature, no matter how it is
implemented and how it is communicated.

So I guess what I ask the group, you know, having been involved in all the
coordinating efforts – realize we have had – the ANSI HISBY(?) was preceded by
the ANSI HISPP, which was preceded by HIS SEESAY(?), and I am talking about 16
years ago, and Dicom, when they started was in 1982, when the ASTM – when the –
I’m sorry. That’s the other guy – when the ACR, American College of
Radiologists and National Electrical Manufacturers Association got together and
decided that having to buy all of your radiology material from one vendor is
not necessarily the way the future is headed. It has just taken 23 years to
have implementable systems.

So I guess one last parting comment that I wanted to make to the group is
that there is an awful lot of existing infrastructure in place and you are
asking for many of those groups to present to you. Clearly, NCPDP is going to
be the subject-matter expert for the prescription information, the pharmacy
information, all of that.

You know, there is also, of course, ANSI through the HISB, which represents
a lot of efforts in healthcare. It is the only remaining information standards
board. There was the Information Systems Standards Board, and that was the one
that ended about a year-and-a-half ago. There is also HL-7, and, of course, the
ISO TC 215 efforts that are available to you, and then the HIMS IHE, which is
really serving as an implementation guide in kind of a live demo year after
year, and they have added, over the years. You know, realize it started about
15 or maybe 11 years ago with just Dicom. Then it was Dicom with HL-7. Then it
was Dicom, HL-7 and HIMS, and, this year, in February, in Dallas, it is going
to also involve the government in what is called an Interoperability Showcase.
So those are all existing methods, and I encourage you to consider some form of
what HL-7 and other groups have called in various phrases some kind of draft
standard for technical use or trial use. I’m sorry, draft standard for trial
use, but the notion of either using IHE profiles or using an HL-7 draft
standard for technical use, but coming up with some way where we try it out
first and try to avoid this one-size-fits-all approach that is never going to
fit everybody.

And those are my comments. I appreciate the opportunity.

I can answer any questions, if you have any.

DR. COHN: I’m not sure I have a question, but it’s great to hear from you,
and I guess listening to what you have been doing, I can understand why I
haven’t seen you for years. You have been in Europe – (laughter) – and other
parts of the world, sounds like –

MR. GLICKMAN: Many of our meetings are here, but, yes.

DR. COHN: Yes, exactly. So – Are there other comments from – I mean, thank
you for your comments. I think they are timely. Other comments from the
subcommittee? Steve.

DR. STEINDEL: The NIST publication, non-repudiation was referred to in the
comments that were just made, and what I was impressed with was how he
introduced that, because he introduced it with the term technical
non-repudiation, and that was a little twist, because there are many, many ways
to do non-repudiation, and, you know, some of the technical methods, like a
hash method or something like that, we have had comments about the
appropriateness of it in this environment and the audit trails, et cetera, and
we have heard some instances today about how that was used successfully for
non-repudiation.

So there’s many ways you can do non-repudiation. I think we need to
remember the difference that NIST talked about about technical non-repudiation
and non-repudiation in general in our deliberations.

MR. GLICKMAN: I think a lot of people are using non-repudiation and are
really talking about data integrity. You know, the idea that data gets there –
arrive intact. Whether it gets translated or not, as long as it is translated
one to one – according to the rules, it’s fine.

DR. COHN: Thank you.

Other comments, statements from the –

DR. HUFF: I just –

DR. COHN: Oh, please.

DR. HUFF: I think I heard everything you said, and I – but if you were to
summarize – I mean, if you wanted to say very specifically what you would like
this committee to do, what is it you would like this committee to do?

MR. GLICKMAN: Me personally?

DR. HUFF: Yes.

MR. GLICKMAN: Tread lightly on PKI – using PKI, so that all of the rest is
worked out, and recognize that the issue is to have what we consider today a
digital signature, that a user name and password, per se, isn’t going to pass
muster in the long run, and the way to get there is going to be to try it, test
it, do some prototyping first, so that we only have to do it once and we avoid
the harmonization downstream.

DR. COHN: Okay.

MR. GLICKMAN: And there’s lots of resources available already and
infrastructure in place to try that out, not just HIMS and a lot of standards
development groups as well.

Whether you agree or not, have I communicated what I –

DR. HUFF: Yes, I understand.

DR. STEINDEL: I wasn’t sure if you were here before lunch. I don’t
remember, but when Karen Trudel was giving the CMS update, and, basically, what
they are – CMS – is thinking about is extensive pilots to test this before it
does go into place. So we already are thinking about exactly what you are
proposing.

MR. GLICKMAN: And I guess so I’m adding, but there are some already – you
know, infrastructure well represented by industry and users that could help in
that process.

DR. COHN: Thank you.

Other comments, statements from the turn for our open mike?

Agenda Item: Subcommittee
Discussion

DR. COHN: Okay. Well, let’s move into subcommittee discussions, and sort of
– sort of looking around at everybody here.

Oh, I – Okay. I think we are going to move, now, into sort of a little
session talking about sort of what we heard and sort of next steps, and I
certainly do want to remind everyone that – I mean, we’ll have some time I
think tonight to reflect on things, and if there’s time tomorrow, we can sort
of do a final sort of summation of all of this, but, of course, we do have
hearings and meetings scheduled for February 1st and 2nd
to sort of try to come to, hopefully, whatever final agreement, or at least
next-step agreement in terms of what it is that we may want to be recommending
to the full committee, knowing that – I think our plan had been to come with
recommendations relating to this, updates on the other recommendations we made
in our first letter, as well as, I think, a letter that also includes privacy
and confidentiality recommendations from the Subcommittee on Privacy and
Confidentiality from the hearings that they have already had.

So I guess I am just sort of curious about what others think at this point.
What sort of frames or learnings you have had from today that we need to have
Margret try to capture while things are still fresh.

I think my own view, at this point – unless I hear otherwise from you – is
that probably we will limit our session in February to two days.

I would imagine that likely, just knowing our drafting approach, that,
hopefully, by February, and maybe a little before, we’ll begin to have things
sketched out – at least some of the aspects – but then there’ll be, probably, a
series of conference calls in February, hopefully, none of which will last
eight hours again, but that will be cause to allow us to sort of refine the
letter prior to the March schedule, and I am just sort of speaking right now of
process. Hopefully, people are comfortable with that process, but, once again,
no eight-hour conference calls. We’ll try to be respectful of everyone’s time.

MS. GILBERTSON: Are you looking at two full days, February 1st
and 2nd?

DR. COHN: Okay. There was a question about whether we are looking at two
full days, February 1st and 2nd.

I think we are going to have to let the agenda and schedule – I mean, sort
of help us schedule. I guess I am hoping not, but I have no idea at this point.

MS. GILBERTSON: Oh, okay.

DR. COHN: I think we’ll have a better idea maybe tomorrow, if that is at
all helpful. I am sure a lot of people would prefer it not to be two full days,
if that helps you at all, and – what?

DR. WARREN: It can go to three.

DR. COHN: Okay. Okay. So, anyway, do people have thoughts, comments? I
mean, I think we have heard today, among other things, about – and just things
to reflect on – that there may be a role for the pilots in 2006 to help clarify
some issues.

I would also, I think, at least from my perspective, suggest that probably
there is very little black or white in the subject matter, and that probably
there’s recommendations that will likely be somewhere in the middle, at least
from my sense of things, and I guess I am hearing – and I guess I need to go
back and re-review things from previous testimony, but I think, at least from
my perspective, I am hearing that there is a world of routine e-prescribing.
There is something that we are going to have to think about that relates to
controlled substances that relate to Schedule V, IV and III, and then there
seems to be maybe a very different world that is Schedule II, and so, once
again, nothing is black and white in all of this stuff, and I would just
suggest that we sort of think about them, and, potentially, those buckets,
knowing that – we may decide that two of the buckets may be really one bucket
or whatever, but I think they are useful constructs to consider, certainly,
based on some of the DEA testimony and others, and, obviously, I do want to
thank the DEA for coming and talking with us.

So I’ll stop there. That’s just sort of some constructs.

Jeff, Steve, do you have some comments at this point?

DR. STEINDEL: No, I think, Simon, you have summed it up very well.

DR. COHN: God, I meant to start the conversation. I didn’t mean to sum it
up.

DR. STEINDEL: I think we have heard a lot and I think we are thinking –
starting to see a lot of clarity.

DR. COHN: Okay.

DR. STEINDEL: Just a matter of putting it together, which we’ll let Margret
do. (Laughter).

DR. COHN: That is well said.

Harry, do you have any comments at this point?

MR. REYNOLDS: Yes, a little bit like Steve, I feel that it is coming
clearer, and, at least, I am starting to get a sense of what I would feel
comfortable recommending as far as to start the pilots versus later on in the
pilot, you know, the Schedule II we heard today and other things, whether or
not that ought to be in the pilots or whether we exclude things like that,
because, obviously, you know, the DEA put down a rather firm stance about how
they are going to want that authenticated and if the industry can’t get there
by that time to do good pilots or get going on the pilots or if it causes a
complete overhaul of the current things that are in place, then you might not
get as thorough a look at the other things going on in e-prescribing as we
might have, if we started out a little slower, which I think – what we heard.

The other thing I still struggle with, which I – we talked a lot about
smartcards and we talked a lot about – you know – the other things that we can
use, the USB’s and everything else. Problem is, I always keep standing in my
doctor’s office looking at his PDA, and those things don’t quite work the same
way as some of the others.

So, again, if one of our focuses is to truly get to the individual
practitioner and truly make it useable to them, and we talk about being
somewhat technology independent, I am not sure that some of these, at the
present time, may or may not almost force a technology focus where you have –
and I’m giving – You asked for our thoughts.

DR. COHN: Sure –

MR. REYNOLDS: I am trying to formulate some things.

The other thing is I really like the idea of the pharmacy sending a message
back to the doctor’s office or to whoever sent it, because I think that – any
time you look at some kind of an audit process or – that is a closed loop.

DR. COHN: Yes. Harry, am I wrong or is that the fill notification –

MR. REYNOLDS: Yes, it is. It is, but I am saying I’m – yes, but what I am
saying is I’m saying that maybe that ought to absolutely be – Before, we got
into the privacy side of that and we started talking about a lot of other
things, whether that would be an issue.

I think from a standpoint of auditing and everything else, now, and further
certification that this happened and the right people were involved, I think
that it has taken on a much – maybe even more of a position for me than it did
before.

DR. COHN: Okay. So what I am hearing for you, you are saying that it
actually may be a tool for non-repudiation.

MR. REYNOLDS: Yes, because, again, if you listened to all the – I think we
are still looking into this whole tiered thing, and we’ve still got this
struggle of this whole transmission of the prescription, you know, going
through all the entities, and how do you really get some kind of a tiered –

You know, non-repudiation takes on a lot of forms. Sometimes, it takes a
closed loop. Sometimes, it takes lots of other things. You know, some people
want it to be a closed system. Other times, it might be a closed loop. Might be
other ways of doing it. I’m not designing it now, but I am just trying to come
up with ways that would allow it to truly get back and truly close it, so that
somebody could pull the plug right away if they saw an issue, because I think –
one thing I heard I didn’t agree with today necessarily in the discussion, this
– the reason I think this is different than HIPAA, I think it’s standards, and
that’s fine, but I think the difference – most of the HIPAA transactions are
after the fact and they are actually not administering patient care. You know,
they are kind of the claim comes in after it happened, and that’s fine. You are
documenting patient care. That is a fact. You are paying for patient care. You
are talking about eligibility. You are talking about claim status. You are
talking about the other transactions that are out there. You are sending
something from one entity to another. Somebody gets it. They get treated. So we
are in a little different part of the game. So that is why – so, as you think
about it, I think it is a little different than some of the – you know, people
were mentioning you don’t have to – maybe you can look at it like HIPAA. It’s a
little different. Might be under the same kind of philosophy and jurisdiction,
but it is a little different as far as what it is actually delivering, and that
is – I don’t want to be too callous about saying it is just like HIPAA.

DR. COHN: Okay. And I think, Margret, did you have a comment or a question?

MS. AMATAYAKUL: I had a question about the fill status notification versus
the acknowledgment of receipt, and maybe the NCPDP – okay. Great. Does the
acknowledgment of receipt of the new prescription describe the content of the
prescription that would close the loop for Harry or is it, in fact, the fill
status that does that?

MS. GILBERTSON: Remember, these are all real-time transactions. So for
every real-time transaction, there can be a real-time response, and there are
tie-back fields that say, This is the message you sent me. This is what I am
responding to, and this is what I am telling you. So I can either tell you I am
sending you a status back with all your trace specs, you know which message I
am talking about and who I am, and here is the status of the message received.
Thank you very much, whatever, or there was an error somewhere, and this is who
generated the error and what it is about. So you have the real-time request
response situation going on.

After that – after the prescription has actually been dispensed to the
patient and they walk out or whatever the situation is, then the fill status
would occur. That, once again, is a real-time request and response. Sent you
the fill status. You acknowledge that you got it back.

MR. REYNOLDS: But is it – like if you think of HIPAA, there’s a – you know,
on the transactions there is a TA-1 that says, I got it and everything is okay
and we’re fine or 997 that says. Other portions of it, you have the original
transaction that you sent also. With what you are talking about, do they
actually contain the drug and the other things coming back or are these
acknowledgments, Hey, I got it. Thank you. Hey, I am working on it –

MS. GILBERTSON: These are not axe and axe(?). No, these are not just
thanks. This is enough – You cannot construct the entire new fill request – the
new request. You could, but we don’t – you don’t have to send the drug segment.
You don’t have to send the patient segment. You can send some of those, if you
want to, but it is enough to say, This is who I am. This is when you sent it.
This is your trace-back that you sent me to acknowledge that we are talking
about the same transaction. So it is not at the level of a 997. It is deeper
than that.

DR. COHN: Margret probably – a little more clarification that she needs.
Please go ahead.

MS. AMATAYAKUL: Well, no, it led to another question –

DR. COHN: Oh, please.

MS. AMATAYAKUL: – in followup to that.

So a trading-partner agreement would be needed to determine the content of
the tie-back message. So if, in fact, you wanted to be able to detect fraud and
abuse in ordering a narcotic, let’s say, then you would need either more than
what is coming in the tie-back normally or you would have to have a trading
partner-agreement that says, I want more than what you normally send as an
acknowledgment of the receipt.

MS. GILBERTSON: Not quite sure I am following. Me, as the originator,
determines this is what I want, and when you send me a response back, you must
echo what I put in that information. You can’t monkey with it, whatever. That
is my tie-back that you received and sent back.

MS. AMATAYAKUL: I got it.

MR. REYNOLDS: But I’m not sure that the committee – I guess – I’m not sure
– maybe it would be worthwhile for the committee to make sure that enough
information goes back in a way that the doctor’s office would at least know
what – not just that a transaction occurred, but the basics of that transaction
that are easily identifiable back to the – easily identifiable as to, Hey, who
is this person and this drug –

MR. GLICKMAN: (Off mike).

MR. REYNOLDS: Yes. Yes, see, that – I think those kind of things, since the
data is available and since there is stuff going back and forth. The same thing
we have all messed with on the HIPAA transactions. So you are not asking for
new data –

DR. COHN: Okay. Well, I was just going to ask Lynne again, and I apologize
for making you come back to the microphone, and I think I hear where Harry is
going. I just couldn’t tell quite from what you were saying what that is
exactly and what that means in terms of your world, which is NCPDP script. I
mean, does that – you know, saying that something like that should happen, is
that something that is easily implemented by everybody or does that require
specific business practices on the part of the originator or what are we
talking about here? Is that a change to your standard? Is that making something
that has been optional now required? I mean, what are we talking about here?

MS. GILBERTSON: I can’t answer fully. I don’t have the status message in my
head as to exactly which segments are all mandatory, optional or not used. I
would have to look it up tonight and let you know.

DR. COHN: Okay. That’s fine. I just – I’m hearing – I just don’t know what
it means in terms of – I mean, if one were to pursue a recommendation like
that, I was looking for what exactly it means and what it would have to look
like to become actionable in terms of your view, as opposed to something that
you would scratch your head about and go, That was sort of interesting. I
wonder what they are talking about.

So, obviously, this would be something helpful to sort of understand where
you are, you know, what’s – I mean, how that all works there. So if you can
look – and you don’t have to do it tonight. You can send a note, if you want
to, over the next week or two, if that would be better.

MS. GILBERTSON: Okay. No problem.

DR. COHN: Okay. Thanks.

Steve.

Lynne, please stay.

DR. STEINDEL: No, you can’t sneak away. You brought up –

MS. GILBERTSON: No, I just want to write myself a note.

Okay.

DR. STEINDEL: The fill-status notification, that would be sent if the
prescription – when the prescription was picked up. So if a prescription – Ross
is shaking his head.

MR. MARTIN: – when it was taken out of the bottle and put into the –

MS. GILBERTSON: No.

DR. STEINDEL: No.

MS. GILBERTSON: No, no, no.

MR. MARTIN: Well, we are talking about – we are changing that. I mean,
that’s the whole thing –

MS. GILBERTSON: Well, we are clarifying that when it’s used – that’s right.
It is when it is dispensed or returned to stock.

DR. STEINDEL: So it could be like days or something –

MS. GILBERTSON: Yes.

DR. STEINDEL: So from a non-repudiation point of view, there may be a
temporal lag that could cause some problems. If we are talking about the
acknowledgment message, whatever you call it, within NCPDP, is this something
that the clinician would normally receive and store in their record? That is
question one.

And question two, do we have any issues concerning the different versions
of the standard, so, you know, right now, we have heard a lot about talking –
translating it one way. Are we going to have to worry about translating it
going back?

MS. GILBERTSON: I mean, if we are – different versions of the script
standard, no. Those are all foundation messages that have been in there since
time began and are usable.

We are talking about HL-7 to NCPDP mapping the project. Those transactions
are considered – not only the request, but also the responses and we are
mapping those as well.

Yes, there could be a temporal lag on the kill-status notification. That
part, yes, that’s true. The other ones are real time, so you are hanging on the
line and within 55 seconds you are getting a response back, so there is not a
temporal lag –

DR. COHN: Yes, and I guess I would have to remind Lynne Gilbertson we need
to – since we are on the internet, you need to – your identity, yes.

And the other speaker was Ross Martin, who had not been identified. So –

Are there other comments? Stan, did you have anything you wanted to share?

DR. HUFF: Well, you know, I just pulled out the letter to remember what was
on our we-might-do-in-the-future list, and e-prescribing was there, and looking
at the other things on there, the things that – the most important to me after
a couple of months perspective were whether we wanted to ever tackle any more
about non-drug allergens, a code system for non-drug allergens, you know,
things that are pertinent to e-prescribing, but aren’t drugs, like, you know,
latex and egg yolk and – So that was one thing.

And the other one was the whole issue of medical-history sharing, and I
don’t know if we want to take those up or not, but those look like probably the
most important things on there that we hadn’t really addressed.

DR. COHN: Steve, and then I’ll make a comment.

DR. STEINDEL: Yes, just a comment on allergens. CHI has kicked off a work
group on that, so we would probably be asked sometime in the near future in our
previous role of reviewing CHI standards to make comments on an allergen list
at that point. So that is actually in the works at this point in time.

DR. HUFF: Okay. That’s good to know.

DR. COHN: Yes, and I believe that medical history, which is, I think, what
you were talking about, as I remembered – I am having to think back to the
actual MMA, which I am getting pretty good at – but I believe that that was
potentially a different time schedule than the rest of these things.

DR. HUFF: Heads nodding behind you.

DR. COHN: Am I correct on that? I said it was on a different time schedule,
that there was not the same requirements for timing or implementation as the
rest of these things. So all I am suggesting is it gives us a little more time.

I guess I would – I may be wrong, and we can certainly decide – we can put
this on as an issue for us to discuss either tomorrow or in February, but it is
hard for me to imagine that we’ll be able to solve the whole medical history
issue in – adding one day in February for the March – Now, if you disagree or
you think –

DR. HUFF: No, I think so. Yes.

DR. COHN: But we should put it on for – I mean, let’s hold that as an issue
about what we want to do with that this year.

DR. HUFF: Yes.

DR. COHN: Judy.

DR. WARREN: So are you suggesting that to get ready for tomorrow’s
discussion that we go back and review what we had in the recommendation letter
and what is in the – that little blurb that we got that Karen gave us of the
law?

DR. COHN: Actually, no, I wasn’t. Stan just brought it up.

DR. WARREN: (Laughter). I know that, but you made comments after that.

DR. COHN: Only because my observation is is that unless you all have a lot
more time than I think you do, we are running out of time for the March letter,
and so what I am saying, literally, is is that as we begin to finish off a
letter that we intend to bring forward in March, we can sort of look at other
important areas that we may want to deal with.

DR. WARREN: What I was thinking of is for the letter in March, we may want
to address those issues as being future work like we did the last time.

DR. COHN: Okay. That is a reasonable – and that may be a very reasonable
thing for us to frame, and I think your just saying that may have put it into
something draft that Margret can remind us about. So is that – and that will at
least remind us as we begin to look at letter about how we may and when we may
want to handle those things.

DR. WARREN: Because the other thing is there was medication history in
there as well as medical history, and I don’t think we have touched that one
either, have we?

MR. BLAIR: We touched medication history only from the standpoint of
communicating it from PBM’s to prescribers. There could be medication history
from other sources, and we just didn’t have time to go into all of those.

DR. COHN: You can take that as another possible area that we may want to
further investigate.

I would suggest, though, that those other areas may be things that we may
want to investigate, maybe not separately from medical history, because that
stuff tends to overlap a bit.

Now, obviously, we have moved into next steps. I am concerned we actually
haven’t gotten this one handled – this step as opposed to the next steps.

Do others have other thoughts about what we have heard? I mean, certainly,
I think the – I guess I would throw in the – which I know we were sort of
taking notes on – what I thought were some very valuable conversations from
NIST in terms of their reflections.

I mean, I think their model is an important model, personally. Others can
reflect on whether they think it is an important model, but, once again, having
– you know, the sense I think we all had looking at it initially was is that it
was unclear the environments they were describing, where this applied, and I
think hearing from NIST that there are – I mean, I use the term mitigating.
They had different terms that they use to describe the environment and how it
may be a factor in how one meets those various levels, I think, is an important
thing for us to mull over or ponder over on how it may impact all of this.

While the NIST work is not really exactly a standard, certainly is a very
useful framework for us to think about things, and, once again, may also relate
to those buckets that we had talked about in terms of the types of data that
get sent for e-prescribing. So just a thought there.

Other comments as we begin to wind down for the day?

Okay. What we’ll try to do is tomorrow we are obviously going to be talking
about HIPAA. I’m sure we’ll spend the first part of the morning talking about
HIPAA. We’ll be having some subcommittee discussion in planning for next
meetings. We are clearly on for February. I am sure some of that conversation
tomorrow will be related to actually HIPAA and other administrative
transaction, next steps for 2005, but we will, I think, come back and reflect
on it, if there’s other thoughts that you all have as you sleep on the
information for today in terms of next steps.

Okay. Any final comments, questions?

Okay. With that, the meeting is adjourned, and we’ll start up tomorrow
morning at nine o’clock.

(Whereupon, the meeting adjourned at 5:21 p.m., to reconvene the following
day.)