HIMSS GSA e-Authentication whitepaper June 2007

HIMSS/GSA
National e-Authentication Project Whitepaper

June, 2007 Copyright 2007 by the Healthcare Information and Management Systems
Society
1

Table of Contents
Executive Summary
Background
Problem Statement
Security and Privacy Concepts and Technologies
AAA—General Information Technology Security Framework
Trust Model
Authentication Systems
Authentication Factors
Credential Service Providers
The GSA e-Authentication Service Component
The ACES Program
ACES and Presidential Directive
IHE Interest

3
5
5
5
6
7
12
13
13
13
16
16
17

RHIO Project Overviews
Connecticut—Connecticut Regional Health Information Organization
Michigan—Michigan Data Sharing & Transaction Infrastructure Project
Minnesota—Community Health Information Collaborative (CHIC)
Nevada—Single Portal Medical Record
Ohio—Ohio Supercomputer Bioinformatics
Ohio—Virtual Medical Network
Corpus Christi—Coastal Bend Health eCities Project

18
25
37
40
41
44
48

Project Conclusions
Appendix
Acknowledgements
References

52
54
58
59

Society
2

Executive Summary
If we in the healthcare industry are to gain the public’s confidence that their personal health
information is safe, secure and confidential, especially in national or local health information
networks, we must assure them that strong security measures are in place and only authorized
personnel with a valid purpose have access to patient information. There is nothing more
important than securing personal health information. While this may seem to an easy task, we
must be vigilant that anyone attempting to access this data is authenticated in the most secure
way possible.
The Healthcare Information and Management Systems Society (HIMSS) and the General
Services Administration (GSA) of the federal government are collaborating to demonstrate how
the security and identity management infrastructure developed to support electronic government
can be applied by the healthcare industry to enable secure and appropriate access to personal
health information.
The solution offered by the GSA would enable secure and interoperable electronic healthcare
transactions locally, regionally and nationally. This level of security does not exist today at a
national level because state and federal healthcare agencies are unable to mutually authenticate
user credentials.
Healthcare facilities require every user, be it a physician, nurse, care coordinator or any other
staff member, to authenticate their identity to the information systems used to provide
administrative or clinical services. The most common authentication method in use today is a
username and password. Users have a long list of these username/password pairs for
authenticating to multiple systems, both within their institutions and between institutions. Some
care facilities are now using a single “sign on” method locally by incorporating “roles” into their
authentication and authorization systems, thus allowing access to a variety of systems (upon
presentation of credentials) based upon someone’s role in the care-giving process.
The goal of the HIMSS/GSA pilot is to demonstrate that numerous Health Information
Exchanges (HIE) and Regional Health Information Organizations (RHIO) can use a common
authentication system to facilitate the secure exchange of healthcare information. Value
propositions and a business case for using the GSA’s e-Authentication method will also be
developed.
HIMSS and the GSA developed a pilot project to demonstrate the adoption of the GSA’s secure
and interoperable technical architecture for sharing medical information among multiple
healthcare providers. The pilot utilized the GSA‘s e-Authentication Service Component program
to provide digital certificates, technical architecture development support and certificate
validation services.
Initially, seven RHIOs/HIEs volunteered to participate in the project. They included:
•
•
•
•
•
•
•

Connecticut—eHealthConnecticut
Minnesota—Community Health Information Collaborative
Ohio—eHealth Ohio-OSC Bioinformatics
Texas—Christus Health, health eCities project

Society
3

Unfortunately, the Nevada Single Portal Medical Record HIE withdrew due to a lack of
resources.
The project met its objectives of having the RHIOs and HIEs leverage the common
authentication infrastructure provided by the GSA’s E-Authentication Service Component.
•
•
•
•
•
•
•
•

Multiple RHIOs can agree and implement a common framework for the policies,
procedures and standards for federated identity authentication across multiple use cases.
The federal e-Authentication infrastructure is relevant and applicable to use-cases for
RHIOs in diverse operational environments.
PKI, as a standard for strong authentication, can be deployed uniformly across multiple
RHIOs.
The federal PKI and its trusted Federal Credential Service Providers can be leveraged for
use in multiple use-cases across multiple RHIOs.
For RHIOs, local registration authorities and local enrollment are viable for large-scale
deployments to provide for strong authentication using federal e-Authentication
components.
Hardware tokens (i.e., smart cards, flash drives) are viable for RHIO deployment of
Level 4 authentication assurance.
The service was usable, tested and implemented regardless of the RHIO or HIE use-case
realization.
The GSA’s risk-assessment process for identification of the sensitivity level for
information exchanged was learned and understood by the participants.

Background
The GSA has an interest in making sure the security infrastructure that they developed to support
the federal government’s electronic government is available to the public and other industry
sectors. The GSA approached HIMSS in 2005 to discuss partnering on a project that would show
the applicability of the federally adopted security technology and solutions for healthcare
information sharing.
HIMSS focuses exclusively on providing global leadership for the optimal use of healthcare
information technology (HIT) and management systems for the betterment of healthcare.
Founded in 1961, with offices in Chicago, Washington D.C., Brussels and other locations across
the United States and Europe, HIMSS represents more than 20,000 individual members and
more than 300 corporate members that collectively represent organizations employing millions
of people. HIMSS frames and leads healthcare public policy and industry practices through its
advocacy, educational and professional development initiatives designed to promote information
and management systems’ contributions to ensuring quality patient care.
Within HIMSS’s scope of activities are efforts to foster new and innovative solutions to current
HIT problems. One problem that continues to challenge the healthcare industry is personal health
Society
4

information security. HIMSS and the GSA sponsored this project in an effort to provide a
solution to the healthcare community related to authentication services.

Problem Statement
How do we ensure that someone accessing personal health information as part of an HIE or
RHIO is who they say they are (authentication) and/or has the right to access the data or perform
the actions for which they are requesting authorization?
The essential problem of emerging HIEs and RHIOs, and the Nationwide Health Information
Network (NHIN), is that regulatory and privacy requirements mandate the security and privacy
of health information. Infrastructure and governance rules must be enacted before HIEs can take
place. The same requirements, i.e. HIPAA and state privacy laws, also apply to individual
organizations that store personal health information.
The purpose of this pilot project was to test e-Authentication using the federal government’s
ACES e-Authentication Federal Bridge within and across organizations while ensuring the
integrity and security of personal health information in a variety of healthcare settings.

Security and Privacy Concepts and Technologies
There are multiple methods and approaches used in securing information stored in a digital
format. All methods use a common philosophical framework for authentication, authorization
and accounting (AAA). While each approach provides some measure of security, the public key
infrastructure method, which is widely used in government and banking, but less prevalent in
healthcare, provides distinct advantages. The federal government requires the use of public key
infrastructure (PKI) across all branches and for all purposes whenever certain types of electronic
data is exchanged or transferred.

AAA—General Information Technology Security Framework
Authentication. Access to a secure information system is typically enabled with an initial
authentication event. Secure systems must have the means to verify the entity-requesting login
or use of system resource. This process is known as authentication. Authentication has two
distinct components:
•
•

Identity Assertion - Users or systems asserting their identity using a credential, such as a
username or digital certificate
Identity Verification - the result of a check on the validity of the credential being asserted

For the purposes of this project the pilot focused on:
•
•
•
•
•
•

Strong authentication to securely and privately communicate and transfer data within and
between RHIOs.
Trusted federal PKI credential service provider to provide digital certificates for
authorized end-users in each RHIO.
Local registration authorities trained and certified for each RHIO.
Standard certificates used for single-factor authentication, digital signature.
Tokens (smart cards) used for security, multi-factor authentication, generate digital
signatures and secure data storage and transport.
Federal PKI architecture employing multiple certificate-validation protocols.

Society
5

Authorization. Authorization is the mechanism for granting rights to a user of a secure
information system. Once a user has been successfully authenticated, a secure system must have
the means for allowing or limiting the rights that user may have inside the system for accessing
information or performing certain functions..
Accounting. Accounting refers to mechanism for logging events and producing reports.
Typically, a secure system logs all meaningful security related events, system usage, and system
anomalies. generates log files that contain auditing information about the events that occur
within the system. These logs can be printed in the form

Trust Model
Systems supporting the accessing and exchanging of sensitive information, a determination of
“who” can be trusted must be established. To ensure interoperability and scalability, large-scale
security and privacy implementations require a “trust model.” The federal government directed
the GSA to develop a federal government “trust model” to support the President’s E-Gov
agenda, announced in 2002. In response to this directive, the government needed to develop an
internal infrastructure that could support and secure the exchange of information for a multitude
of internal federal agencies. The government adopted federated identify management which
would support the E-Gov mandates as follows:
•
•
•
•
•
•

Provide common authentication infrastructure for all federal E-Gov business applications
and e-access control.
Federation allows identity federation between multiple industry and government entities
and the Federal Government.
Technical architecture supports multiple authentication technologies, protocols and IDM
software products and components.
In 2004, GSA partnered with the healthcare industry to establish the Electronic
Authentication Partnership.
Incorporated non-profit public/private sector forum to advance and accelerate IDM
federation.
Focuses on interoperability and trust EAP Trust Framework issued December, 2004..

Society
6

Federal Trust Model for Federated Identity
1. Establish & define authentication
risk and assurance levels

• OMB M-04-04 - Established and defined 4 authentication
assurance levels as Governmentwide policy
• FBCA Certificate Policy - Established 4 authentication
assurance levels for Federal PKI domains

2. Establish technical standards &
requirements for e-Authentication
systems at each assurance level

• NIST Special Pub 800-63 Recommendation for EAuthentication – Established authentication process &
technical standards at 4 established assurance levels
• FBCA Common, Commerce Certificate Policies –
Established PKI-specific standards and requirements.

3. Establish methodology for
evaluating authentication systems
at each assurance level

• Credential Assessment Framework – Standard
methodology for assessing authentication systems of
credential service providers.
• FBCA Cross-Certification Requirements – Standard
methodology for policy mapping, audit, and testing
interoperability for cross-certification with the FBCA.

5. Perform assessments and
maintain trust list of trusted CSPs

• E-Authentication Trusted CSP List – CAF, boarding &
Interoperability testing
• FBCA Trust List --tests for policy mapping,, audit
compliance, cross-certification & directory interoperability

6. Establish common business and
operating rules for participants

• EAI Federation Business and Operating Rules and
Participant Agreements
• MOA with Federal PKI Policy Authority

Fig. 1: Standards for the Federal Trust Model.
In the realm of security, there is often contention between trustworthiness and ease-of-use. The
ultimate trust model would be to deny everyone access to everything. Of course, this would
render data and applications worthless. The ultimate ease-of-use would be to grant everyone
access to everything—obviously unacceptable in most realms, but particularly unacceptable for
health information.
This means that processes need to be established to identify the sensitivity level of information
so the right security controls can be put into place. For example, an application that allows you to
look up your child’s grades on his or her school’s Web site would probably have a different
sensitivity level than, say, an application that allows you to see the Pentagon’s war plans. In
healthcare, we expect that access to records from within an organization would have a different
sensitivity level than access from a location not under the organization’s control in order to
protect and secure patient health information.
When developing their infrastructure, the federal government understood that supporting a set of
security standards for technical, policy and process would be required to meet the needs of the
various agencies. Certain risk factors must be evaluated in the development of a security system
(policy, procedure, technology). The following subsections describe risk assessments, assurance
levels and credential types, as well as how the GSA used them to develop their security
standards.

Society
7

Risk Assessments. To properly identify the security requirements for an application or data, a
risk assessment must be performed. Just as the term implies, the goal to discover what is at risk if
access is granted to the wrong individual or system. For example, upon completing a risk
assessment, the Social Security Administration may have determined that there is little risk with
an application that shows what a citizen’s monthly benefits will be in the year 2061. There is a
requirement to be somewhat assured that people looking up this information are who they say
they are, but only minor damage would be done to the citizen and the reputation of the agency if
that information fell into the wrong hands.
On the other hand, the Department of Labor may determine from a risk assessment of their
payroll system that there is significant risk of fraud or financial loss if the wrong person accesses
their system. For health information that involves patient data, there are legal, ethical and
financial risks associated with the loss of privacy.
Assurance Levels. Once the degree of risk has been determined, an assurance level needs to be
identified that most appropriately addresses risk. Again, as the term implies, you need to identify
how “assured” you need to be of the identity of the individual or system trying get your data or
use your application. The federal government came up with four “levels” of assurance:
•
•
•
•

Level 1. Not assured that users are who they claim to be.
Level 2. Somewhat assured that users are who they claim to be.
Level 3. Very assured that users are who they claim to be.
Level 4. Absolutely assured that users are who they claim to be.

Fig. 2 shows the standard assurance levels for electronic authentication established by the Office
of Management and Budget, and supported by the GSA’s e-Authentication Service component
used in this project.

Society
8

OMB E-Authentication Guidance
Establishes
Four Assurance Levels for
Consistent Application of E-

Level
1

Level
2

Level
3

Level
4

Little or
no
confiden
ce in
asserted

Some
confiden
ce in
asserted
identity

High
confidenc
e in
asserted
identity

Very high
confiden
ce in the
asserted
identity

Fig. 21: OMB assurance level guidance.
Credential Types. A “credential” in this system is something that is asserted to represent the
identity of a user or a system. We are all familiar with usernames and passwords, ATM cards and
PINs and so on. These are examples of credentials, and figuring out which one is the right one
required for your needs is the next step in developing your security solution.
Once your organization has determined the risk associated with data or applications and have
identified the assurance level needed to address the risk, you need to determine which credential
type provides that “level” of assurance.
If the system processes patient health information, a High Confidence in the Asserted Identity is
recommended, which the Office of Management and Budget (OMB) identifies as a Level 3.
Username and password authentication requirements would not provide High Confidence.
However digital certificates issued using a strong policy probably would provide high
confidence. The OMB and the National Institute for Standards and Technology (NIST) provide
standards for pairing up certain credential types with assurance levels. Fig. 31 extends the
Assurance Level Guidance to include associated credentials.

Society
9

E-RA tool assists
agencies in
defining
authentication
requirements &
mapping them to
the appropriate
assurance level
NIST SP800-63
Electronic
Authentication
technical guidance
matches technology
to each assurance level

OMB E-Authentication Guidance
establishes
Four Assurance Levels for
Consistent Application of E-

Level
1

Level
2

Level
3

Level
4

Little or
no
confiden
ce in
asserted

Some
confiden
ce in
asserted
identity
PIN/P

High
confiden
ce in
asserted
identity
-

Very
high
confiden
ce in the
asserted
identity

Fig. 31: Assurance levels and credential types.

This system of standard approaches and methodologies is at the heart of the interoperability of
the security infrastructure. Figure 4 further illustrates the approach in the context of the
healthcare domain:

-Factor Token
Multi

Increased $ Cost

PKI/ Digital Signature
-Based
Knowledge

Very
High

Strong Password
PIN/User ID

High
Medium

Low
Access to
Protected
Web site

Applying
for a Loan
Online

Obtaining
Govt.
Benefits

Employee
Screening
for a High
Risk Job

Increased Need for Identity Assurance
Fig. 4: Risk levels, assurance levels and credential types.
Fig. 5: Risk levels, assurance levels and credential types as applied to health-related risks.

Authentication Systems
Electronic authentication systems need to be able to accept and validate an identity assertion.
The most common credential is a username and password on a personal computer. A user’s
Society
10

identity assertion is his or her claim that he or she is the person who is associated with, or owns,
the username. This is proved by supplying a secret password that only the user and the user’s
computer acknowledge. The computer validates the user’s identity by comparing the password
supplied with the expected password. If a positive match is found, the user is granted access to
the system. If not, the user is denied access.

Authentication Factors
There are three generally accepted authentication factors: single factor, two factor, and three
factor.
•
•
•

Single factor. Something you know, such as a password or the answer to a question, such
as your mother’s maiden name.
Two factor. Something you are in possession of, like a smart card, in addition to
something you know.
Three factor. Something you are, like a fingerprint, retinal scan or DNA, in addition to
something you know and something you are in possession of.

Credential Service Providers
Credentials are only as valid as the procedures used when issuing them. Examples of credentials
include a valid passport, driver’s license or a personalized, wallet-sized photo-ID issued by a
state agency or an employer. Hospitals may issue every employee a photo-ID name badge that
must be worn while on duty. However, your work ID would most likely not be acceptable by a
merchant when you are cashing a check or when you are proving your age to get into a bar.
Why? Because the merchant or bouncer has no idea what procedures were used by the card’s
issuer, such as requiring the applicant to show a birth certificate, passport or Social Security card.
They also have no idea if the work ID is real or fake. However, they do trust a state-issued
driver’s license because they trust that sound verification procedures were used when it was
issued.
Credential service providers take on the important role of issuing and managing credentials for
both people and machines. In healthcare, regulated practitioners are credentialed by the state
licensing process which is further verified and validated by provider organizations before
enabling practicing privileges at their locations.

The GSA e-Authentication Service Component
The following definition of the GSA’s e-Authentication Service Component comes from
FCW.com:
“The e-Authentication Service Component incorporates two different architectural techniques,
assertion-based authentication and certificate-based authentication, according to the General
Services Administration.
“PIN and password authentications typically use assertion-based authentication, where users
authenticate to a Credential Service Provider (CSP), which in turn asserts their identity to the
Agency Application (AA). Certificate-based authentication relies on X.509v3 digital certificates
in a Public Key Infrastructure (PKI) for authentication, and can be used at any assurance level.

Society
11

“PKI credentials offer considerable advantages for authentication. Certificates can be validated
using only public information. Standards for PKI are also more mature than other authentication
technologies and more widely used than the emerging standards for assertion-based
authentication of PIN and password credentials.
“Nevertheless, the e-Authentication Service Component incorporates both assertion-based and
certificate-based authentication to provide the broadest range of flexibility and choices for
federal agencies and end users. The agency notes that the ASC will provide the following:
•
•
•
•
•

“Credential assessments and authorizations;
“technical architecture and documents, including interface specifications for
communications within the e-Authentication Federation Network;
“interoperability testing of candidate products, schemes or protocols;
“business rules for operating within the Federation; and
“management and control of accepted federation schemes operating within the
environment.”

Society
12

The U.S. Federal PKI

Fig. 6: The U.S. Federal PKI.

The ACES Program
The Access Certificates for Electronic Services (ACES) program provides digital certificates and
PKI services to enable electronic government applications that require logical access control,
digital signature and/or electronic authentication. They also support the sharing of health
information in cross-organizational and RHIO and HIE data exchanges. GSA serves as a Policy
Authority and is responsible for organizing and administering the ACES Policy and the ACES
contract.

Society
13

ACES and Presidential Directive 12
In the past, PKI has been proposed as the solution to many security problems. The federal
government has committed to building a federal government-wide solution based on increased
post-9/11 security needs.
This effort gathered steam when President Bush issued Presidential Homeland Security
Presidential Directive/HSPD-12, Subject: “Policy for a Common Identification Standard for
Federal Employees and Contractors on August 27, 2004,” which mandates a common security
access policy and technical infrastructure across the entire federal government. To implement
this policy, GSA and NIST have worked together to develop a general-purpose PKI
infrastructure codified in Federal Standard 201. This standard requires a common access card be
developed using a federally organized PKI infrastructure, which will allow common access
control procedures to be implemented across all levels of the federal government.
With this new effort emerging at the federal level, GSA and HIMSS proposed the eAuthentication Pilots to validate, through pilot implementations, the technical concept for use in
the healthcare sector. The project chose to use the ACES credentials to demonstrate the
capabilities of using PKI within multiple healthcare settings. The purposes of using the ACES
certificates and underlying federal PKI infrastructure were:
•
•
•

To demonstrate the feasibility of using the existing federal ACES PKI infrastructure.
To prototype solutions among multiple RHIOs to see if common solutions emerge.
To introduce healthcare to PKI policies and processes.

Society
14

IHE Interest
Integrating the Healthcare Enterprise (IHE) is a multi-year initiative that creates the framework
for passing vital health information seamlessly—from application to application, system to
system, and setting to setting—across the entire healthcare enterprise. Under the leadership of
HIMSS and the Radiological Society of North America (RSNA), IHE launched in November
1998 as a collaborative effort to improve the way computer systems in healthcare share critical
information. IHE includes medical specialists and other care providers, administrators, standards
organizations, IT professionals and vendors. In 2003, the American College of Cardiology
(ACC) joined the initiative as a sponsor to advance cross-vendor integration for cardiovascular
medicine.
IHE does not create new standards. Rather, it drives the adoption of standards to address specific
clinical needs. IHE Integration Profiles specify precisely how standards are to be used to address
these needs, eliminating ambiguities, reducing configuration and interfacing costs and ensuring a
high level of practical interoperability. IHE is now truly multi-domain, with integration profiles
for radiology, cardiology, laboratory and IT infrastructure, which enable interoperability both
within and across multiple enterprises.
The IHE Interest in the GSA project is twofold. The first reason for interest is to make sure that
the IHE “Cross-Enterprise User Authentication” (XUA) profile is aligned in the best way
possible with GSA solutions to ensure that GSA-assigned identities can be used in the IHE
solution. The second reason for interest is to take away lessons learned from the GSA project so
as to make the XUA profile as complete as possible.
Two other existing IHE profiles also leverage digital certificates. The Node Authentication and
Audit Trail (ATNA) profile utilizes digital certificates to enable TLS to ensure that all nodes in
an affinity domain are trusted so as to enable secure access to shared health information
resources. IHE has also specified Document Digital Signature (DSG) which specifies the use of
ISO TS17090 Health informatics—PKI-compliant certificates to ensure document integrity and
accountability for cross-enterprise document sharing (XDS).
For more information on IHE, XUA profiles and details concerning the IHE affinity architecture,
visit the IHE’s Web site.

RHIO Project Overviews
Each of the pilot participants developed a set of use cases to document their project uses and
expected outcomes. Initially we began with seven pilot teams, with six reporting actual pilot
results. Each pilot set out to prove a different use case.

Connecticut—Connecticut Regional Health Information Organization
Background: Connecticut RHIO communities in the Middlesex, Hartford and Bridgeport areas
have come together to pilot the GSA e-Authentication technology as part of a cooperative
initiative among members of the newly formed eHealthConnecticut statewide RHIO. Local,
innovative RHIO initiatives are emerging within Connecticut while statewide RHIO efforts are
in various stages of development. In particular, initiatives in the Middlesex area overlap
significantly.
Through the eHealthConnecticut Technical Committee, members of the statewide RHIO hold
regular meetings to discuss system architecture, infrastructure and interoperability requirements
Society
15

to enable e-health initiatives for the state. The project members are testing core capabilities
provided through off-the-shelf products to demonstrate opportunities for leveraging the GSA eAuthentication technology. This group is demonstrating the use of the digital identity for
protecting access to the local RHIO systems to enable broader community sharing of the
information resources provided by the RHIO. Two of the participants, Jefferson Radiology and
ProHealth Physicians e have members who interact with numerous organizations, several of
which specifically have routine patient care business with other members of this test bed
initiative. The tools are being tested and the experiences are being shared among the
eHealthConnecticut Technical Committee members. The approach has been identified as a
solution for provider identity management as part of Connecticut’s involvement in the Office of
National Coordinator (ONC) for Health Information Technology Health Information Privacy and
Security Commission (HISPC). Demonstration of communication of a single identity for
interactions with these multiple organizations has been an important part of this initiative.
Standards: The published standards that support the trust model used by the e-Authentication
service component are shown in Fig. 1. Within the healthcare vertical, there are additional
standards that were used in this pilot that specify the healthcare-specific layer over and above the
foundation engineering standards for PKI, supporting services and services relying upon the PKI.
These health informatics standards specify requirements for use of PKI, directory services and
authorization privileges in healthcare:
•
•
•
•
•
•
•
•
•
•
•

ISO IS17090: Health informatics: PKI (Parts 1/2/3) (supersedes ISO TS17090 Health
Informatics—PKI (Parts 1/2/3).
ISO TS21091: Health informatics: Directory services for security, communications and
identification of professionals and patients.
ISO TS26000: Health informatics: Privilege management infrastructure (Parts 1/2/3).
ISO ISO DTS21298: Health informatics: Functional and Structural Roles.
ASTM E1986: Standard Guide for Information Access Privileges to Health Information.
ASTM E1762: Standard Guide for Electronic Authentication of Health Care Information.
ASTM E2084: Standard Specification for Authentication of Healthcare Information
Using Digital Signatures.
ASTM E2212-02a: Standard Practice for Healthcare Certificate Policy.
IHE Audit Trail and Node Authentication Profile (ATNA).
IHE Document Digital Signature (DSG).
IHE Cross-Enterprise User Authentication (XUA).

For the purposes of this pilot, we have asserted TS17090 in the absence of configured support for
the healthcare extension specified as optional in the technical specification and mandatory by the
International Standard revision of the specification. The extension includes a standard means by
which to assert the healthcare credentials and will be an important component to assure
extensible national and international interoperability.
Use case. In accordance with the AHIC breakthrough area for health improvement, an electronic
health record will give a clinician direct access to a person’s medical history. It would allow the
provider to electronically manage all aspects of patient care, enabling the provider to
retrieve/capture data for treatments in an effort to support provider/patient activities such as
review, encounter and follow up. In addition, electronic health records allow patient data to be
Society
16

accessible at multiple locations. Possible benefits of an electronic health record include improved
health maintenance, disease management and error reduction in clinical decision support.
Many early implementations for making the electronic health record available within a
community or RHIO are done through providing Web portal access either to the local EMR or to
a shared summary information resource. This use-case describes e-authentication to the portal as
a means by which to enable secure access to the protected health information to appropriately
credentialed clinicians in possession of a GSA Affiliation digital certificate. The affiliation
certificate has been issued in accordance with ISO TS17090 such that the regulated healthcare
professional is issued an affiliation certificate through demonstration of affiliation with the
licensing authority through vetting of individual identity and proof of an active medical license.
Supporting organization employees are similarly issued an affiliation certificate such that the
vetting attests to proof of individual identity and proof of current affiliation with the healthcare
employer.
This use-case has broad applicability, but initially will be used to enable access to medical
information from the emergency department. In the context of the pilot participants, two clinical
scenarios are considered:
•

•

A patient complaining of abdominal pain is sent for outpatient radiology services
following consultation with the primary care physician. The patient presents to the
emergency room later that evening. Rather than repeating the radiological exam in the
emergency room, the physician authenticates to the portal servicing the outpatient
radiology system and retrieves the image. This image is provided to the surgical team for
a patient that is referred for emergency surgery. This enables faster, better quality
treatment for the patient, and reduces the cost of duplicate testing.
A patient presents to the emergency department at a tertiary care hospital after
experiencing symptoms of myocardial infarction, and indicates that he has been
previously seen for cardiac services at the community hospital. The emergency room
physician authenticates to the community hospital portal to retrieve prior EKGs within
the “golden hour,” providing informed treatment for the patient.

The next use-case that will be tested is sharing of patient treatment and results between providers
using signed and encrypted communications. These data are typically communicated today via
fax or courier. This test will use signed and encrypted e-mail or other S/MIME communications
to securely deliver this information to the provider. In this test series, the physician in the
outpatient setting (primary care provider or specialist) is the recipient of the communications:
•
•

A patient is referred to out-patient radiology services. The radiology result is signed and
sent through encrypted e-mail to the primary care provider or specialist. The electronic
result is imported into the practitioner’s medical record.
A patient referred to a specialist for testing and analysis by the primary care physician.
The specialist communicates the findings through signed content sent through encrypted
e-mail.

In both of these cases, the encryption certificate is made available to the sending practitioner
through ISO 21091 compliant directory services.

Society
17

As part of this project, we have also started some early testing of authentication to a personal
health record portal using the digital identities for the patient to access their health record. This
uses the same approach as described for provider portal authentication, but is targeted toward
consumer empowerment.
As eHealthConnecticut moves toward a shared document infrastructure, we look to expand the
use-cases to include securing the RHIO affinity domain, and to enable cross-enterprise user
authentication in accordance with the XUA profile under development through IHE. The
document sharing would include digital signature on the documents made available to the
community, likely through a machine-based signature to provide assurance as to the source and
validity of the information provided to RHIO members. We envision this to be a use-case to be
pursued during the next phase of this project.
Participants: Two Connecticut regions are participating in the project—Central Connecticut and
the Bridgeport Community. Central Connecticut participation is represented by five
organizations characterizing a common health market where patients are regularly serviced by
multiple-provider entities. The participants in this region include two hospitals, three physician
networks and a two radiology groups, including:
•
•
•
•
•
•
•

Middlesex Hospital and Health System
Hartford Hospital
Middlesex Health System Managed Physicians
ProHealth Physicians (a large network of group practices)
Radiology Associates of Middlesex
Jefferson Radiology (a group of about 500 radiologists servicing Central Connecticut
locations)
Middlesex Professional Services Foundation (currently on-hold due to their portal vendor
hesitations to support the e-Authentication technology)

The Bridgeport Community has established community-wide information sharing project to
enable information sharing for those patients in that region. This region services 10 percent to 15
percent of the patients in the state. The community project includes:
•
•
•
•
•
•

St. Vincent’s Hospital
Bridgeport Hospital
SW Bridgeport Community Health Center
Bridgeport Community Health Center
Americares
Bridgeport Department of Public Health

In addition to these organizations, HIMSS staff members have been issued credentials in support
of project staff and interoperability, including Mary Griskewicz, MS, FHIMSS, Director,
Ambulatory Information Systems, and Didi Davis, Director, Integrating the Healthcare
Enterprise (IHE).
Results: Harmonization with International Health Informatics Security Standards. We have
leveraged the ACES Affiliation certificate using hardware tokens to instantiate the ISO TS17090
Health informatics-PKI technical specification. We were unable to initiate the revised IS17090
Society
18

Health informatics–PKI International Standard due to the lack of configured support in the CA
supporting the test environment for the healthcare extension defined by that standard. We
utilized the roles and codes described by ASTM E1986 Standard Guide for Information Access
Privileges to Health Information code the structural roles as described by TS17090 and ISO
TS21298 Health informatics–Functional and structural roles. The principals for privilege
management and access control defined in ISO 26000 Health informatics–Privilege management
infrastructure (Parts 1/2/3) to configure the portal environment with access privileges determined
by the structural role (functional role is presumed constant as direct care provider). This
combination of standards-based configurations has been implemented in two of the provider
portals, enabling a single-sign-on capability across provider environments based upon the ACES
certificates.
Establishing a Registrar: Connecticut is using smart to demonstrate high-assurance, portable
identity management to meet the security and privacy requirements associated with the
protection of health information and the execution of transactions and processes that may impact
patient safety. As such, a face-to-face registration requirement was met to enable the local
Registrar to issue hardware-based identities and encryption certificates in accordance with the
ACES vendor’s CPS. This face-to-face registration and training was completed on Sept. 8, 2006.
Establishing Registrar Authorization: Several considerations were in order to establish
authorization for the local Registrar for Connecticut participants. While each of the organizations
are members of the Connecticut RHIO, eHealthConnecticut, there is no service offering at this
time by the RHIO as it is in the early stages of defining what those services might be. As such,
an authorization letter from eHealthConnecticut has little meaning at the current time.
The local Registrar has met on behalf of this project and along with e-HealthConnecticut with
the Department of Public Health (DPH), who is the issuing authority of medical credentials in
the state to discuss obtaining authorization from DPH to represent the affiliation of the licensed
healthcare professionals to their licensure in accordance with the International Standards
IS17090 Health Informatics PKI. The discussion was well-received, with the only hesitation
being that for the state to provide a letter. It might be construed as an acquisition, which is highly
regulated. There was support for the principals and concepts and they encourage proceeding with
the affiliation binding and using their online-available resources for ongoing affiliation
verification. Further discussions will be pursued, and feedback will be provided regarding
obtaining a registrar letter from DPH. We also discussed a potential vision for how
eHealthConnecticut could serve as an infrastructure resource to the RHIO using this technology
should this project prove successful in the state.
Early deployments are focused around the resource providers of the project. As such, letters have
been obtained first from these organizations, and will be obtained from the organizations that are
primarily client-side subsequently. Registration letters have been obtained from Middlesex
Hospital, St. Vincent’s, Hartford Hospital, Jefferson Radiology and HIMSS.
Registration Process: In the interest of maximizing end-user support for obtaining identities, the
initial registration process included the Local Registrar requesting the identity along with the
end-user from the Registrar machine, and providing end-user training after the identity was
issued. This approach had significant limitations.
Because the registration interface required that the application be printed, signed and notarized
from the registration GUI, the local Registrar either needed to leave the organization following
Society
19

the initial key request to print the documents or needed to provide a copy of the request to the
subscriber. Scheduling two follow-up visits as part of the process was impractical, and as such,
we explored options for printing during the first session. E-mailing the request to the subscriber
was also an issue as some of the key information for the registration form was stripped by the email product. The alternative of providing the request form on a USB token was generally
selected, though this is typically against the physical control policy of many provider
organizations to accept foreign media for information transfer. This approach also required a
final visit from the local Registrar to retrieve and download the issued certificate to the
subscriber’s smart card. As the card needed to be left in the possession of the subscriber, there
were cases where the subscriber had left the key at their home office and were not able to
complete the process.
Because of the complexities and logistical issues with the above approach, we are adjusting the
process to better enable the deployment of the identity and encryption keys. The modified
process will include installation of drivers and middleware in advance (by the local IT
department) or during the registration visit by the local Registrar. The request will then be issued
from the subscriber’s machine or from the machine of the local IT or security officer. This will
enable local printing of the documents to be notarized, and will also enable the subscriber to
complete the download process from their machine once the credentials are issued. This
modified procedure reduces the local Registrar’s visits from two or three to a single visit. Enduser training will need to be done either at the time of registration through demonstration by
local staff, or upon follow-up visit from the local Registrar.
Registering Participants: At the organizational level, the deployment process begins by
registering key individuals to enable both organizational support and operational integration. The
project sponsor—typically, the CIO or CTO—provides a letter to recognize the local Registrar as
an official registrar for identities within that organization. This initial request has sparked a
number of key considerations for routine process definition. To provide such a letter which
commits the organization, the project sponsor will typically involve those persons that may have
related concerns. Usually, this is their own supervisor—the board of directors, executive
management, human resources or the organization’s HIPAA officer. The HIPAA officer and, as
appropriate, the security administrator are among the first to be issued identities, along with the
project sponsor and the IT staff responsible for the systems that will be tested. This has typically
involved the e-mail administrator and the network administrator. The regulated healthcare
professionals are selected carefully so as to assure that the user will be technically savvy and
have a real-world need for accessing or transmitting health information across organizations.
Configuration of Test Environment: E-mail testing has been conducted directly from the
operational environments. Two e-mail products are in use across the participating environments
to date. These are Microsoft Exchange, using XP clients, and Novell GroupWise 6.5, running on
an XP platform.
Web portal testing has been set up in a staged environment using the portal product used by three
of the four initial test sites, Juniper Networks. This environment has been configured with
appropriate trust and to enable role-based decisions leveraging the ASTM structural role
expressed in the digital identity in the “OU.” All identities have been configured in this manner
to emulate the requirements of the ISO TS17090/IS17090 Health Informatics PKI technical
specification and standard. Some initial testing of secondary authorization utilizing the ISO
Society
20

TS21091 Health Informatics Directory services for security, communications and identification
of professionals and patients.
Testing: There were some initial challenges in the Novell environment that were ultimately
resolved including, CSP selection and end-user e-mail profile configuration. Signed and
encrypted messages have been successfully communicated across the two products using the
ACES Vendor digital identities and encryption certificates stored on smartcard. This has been
based upon local address-book and reply-to-signed approaches. The next stage of this testing will
leverage local and regional directory services for look-up of the recipient encryption key.
Extended testing has been conducted using S/MIME enable email between participants in
Connecticut and the other HIMSS/GSA RHIO participants.
For the Web portal testing, several groups have been defined and tested based solely on the
content of the certificate. As a result, the Web portal authentication has been demonstrated as
simply requiring the token and the PIN. Several realms have been defined and successfully
tested:
•
•
•
•

All pilot participants
CIO/CTOs only
Physicians only
Hartford Hospital physicians only

These have been moved to the operational portals of two of the participants, Middlesex Hospital
and Jefferson Radiology. These portals have been successfully accessed by our physician tester,
Dr. Lincoln Abbott, an emergency department physician at Hartford Hospital.
Personal health record management is being tested using project participants as preliminary
patients. Trust for the ACES Vendor CA is pending. Once this is complete, additional patients
will be added. There is a significant naming standardization issue that will need to be addressed
to be able to broaden and scale this use-case.
Feedback: While feedback from the project participants has been generally positive, there is
concern that the penetration of the technology and user-base will need to be broadened before the
efficacy can be realized. However, the trust level associated with the identity has been well
respected, and participants from multiple sites have remarked that if this could be broadly
deployed within the state, that there would be significant opportunity to better enable health
information sharing among practitioners. Repeatedly, and independently, the provider sites
involved in the testing have remarked that if this single identity could enable high assurance
access across all of the RHIO systems, then any added burden associated with the token and
identity provision would be worthwhile.
Feedback from the state-level initiatives has also been positive. This project has been proposed
as a possible solution as part of the CT-HISPC initiative to address the problem of provider
identity management that has been identified.

Background: Southeast Michigan is a seven-county area with nearly 5 million residents—40
percent of the state’s population. The majority of the state’s 500,000 uninsured under 100
percent of the poverty level for a family of four ($19,350) live here. Forty-eight percent of the
Society
21

state’s licensed physicians (14,000) practice here and 80 percent are not automated. Three major
auto companies have world headquarters here. The economy is under siege as the manufacturing
sector declines. Unemployment and bankruptcy rates are high and continue to rise. Healthcare
costs represent one-seventh of the nation’s economy. Four of the seven major urban hospital
systems in the area are safety net providers, taking on the majority of the burden of
uncompensated care for the region. As a result, the Southeast Michigan community (citizens,
employers, purchasers, healthcare systems, providers, insurers, unions, city, state and local
government agencies, medical societies and other professional associations) is actively seeking
ways to improve healthcare access and quality while holding down costs.
In Michigan, there are many overlapping development efforts that are centered around
integration and interoperability in healthcare. HIMSS members throughout the state have been
key participants in all of these efforts. The climate is ripe in Michigan for formation of RHIOs /
HIEs. Over the past year Michigan, under the joint leadership of Teri Takai, director and CIO,
Michigan Department of Information Technology, and Janet Olszewski, director, Michigan
Department of Community Health, has put in place the framework for a statewide RHIO—
MiHIN. It also has created a health IT commission and has made $5 million in grant money
available for planning and implementation of HIEs in Michigan, arranged by Medical Trading
Areas. At this time, at least seven coalitions of stakeholders are applying for these grants, two for
implementation and five for planning. The state is currently awarding a grant for management of
a resource center to coordinate these regional efforts, record locator services and require
standards harmonization.
At the same time, in Southeast Michigan, stakeholder groups led by the auto companies and a
large IT vendor based in the region started discussions that led to formation of the Southeast
Michigan Health Information Exchange (SEMIHIE). The Michigan Chapter of HIMSS was a
leader in this effort, chairing the Governance Planning Committee and the Governance Work
Group. SEMIHIE is now an independent group working with four host organizations (Altarum
Institute, Greater Detroit Area Health Council and the medical societies of Wayne and Oakland
counties) working actively toward formation of a HIE for the community, a non-profit
organization structured as a public/private utility. SEMIHIE and hosts have submitted a proposal
response for a State of Michigan HIE planning grant proposal..
The objectives of SEMIHIE are to establish a sustainable, self-sufficient business model for the
SEMIHIE that aligns costs with benefits for the stakeholders and to provide for secure, private
and efficient cross-institutional exchange of clinical and administrative healthcare data to:
•
•
•
•
•

Enhance physicians’ and other healthcare providers’ ability to access and use electronic
health information and decision support tools to facilitate appropriate care and improve
patient safety.
Foster improvement in clinical and administrative healthcare processes through the
sharing of healthcare data.
Build the foundation to provide future support for patient education, issues affecting
personal health and public health surveillance reporting.
Create a secure, ubiquitous, interoperable HIT infrastructure consistent with state and
federal standards/guidelines, where applicable.
Implement a technology infrastructure that provides for proper security, authorization of
users and indexing of patient information from multiple sources.

Society
22

•
•
•

Drive the adoption of policies and technical standards to facilitate data gathering,
information sharing and decision-making while protecting patient privacy.
Link to national and regional efforts through use of a common trust framework, business
and operating rules, technical infrastructure and governance models for federated identity
management and interoperability.
Develop and maintain an environment of trust among the stakeholders.

In parallel with formation of SEMIHIE and MiHIN, a group of individuals including financial
institutions, large and small health systems, physician groups, insurers, unions, the autos,
employers, purchasers, public health, healthcare professional organizations, technology and
consulting firms and international standards organizations began to develop a pilot focused on
secure interchange of healthcare data across disparate stakeholders to evaluate the feasibility of
using e-Authenticationin healthcare. This pilot project, the Michigan Data Sharing Transaction
Interface (MI-DSTI), applied for and was accepted in the GSA / HIMSS e-AuthenticationPilot
Project along with the projects of six other states. [The majority of the MI-DSTI members were
also simultaneously involved in SEMIHIE and in the committees working on MiHIN.]
In July 2006, David Temoshok of the GSA and Michael Sessa of the Electronic Authentication
Partnership (EAP) spoke to the members of SEMIHIE about the importance of establishing eauthentication, federated identity management, integration and interoperability across industry
segments and of being certified to work across the Federal Bridge with agencies of the federal
government. This presentation was well-received by SEMIHIE and the requirements for linking
to national and regional efforts through use of a common trust framework, business & operating
rules, technical infrastructure, and governance models for federated identity management and
interoperability were formally incorporated in SEMIHIE’s organizational objectives in August
2006.
SEMIHIE officially adopted the MI-DSTI GSA/HIMSS e-AuthenticationPilot in late summer of
2006. Prior to that time, organizations and individuals, most of whom were SEMIHIE members,
had been working separately to develop use-cases and a technical framework for the pilot
project. This adoption improved the ability of member organizations to collaborate on the project
and access resources. This collaboration among the members in a trusted environment has been
critical to the success of the pilot project.
Toward the end of the pilot project, the original vendor of the technical infrastructure dropped
out. Two technology firms, Shinkuro and FireStar, and NextUs, a network consulting firm,
stepped up to fill the void. This technology was successfully tested by the MI-DSTI participants,
using a series of use-case scenarios (listed in the Appendix). This experimental testing was
completed Feb. 13, 2007. The group of participants has determined that the use-case and
technology are of sufficient interest and importance that they will continue to experiment with
the ACES E-Gov Certificates and the Shinkuro-FireStar technology after the official end of the
pilot program.

MI-DSTI e-AuthenticationPilot Project Participants
Project Managers
•

Helen L. Hill, Immediate Past President, Michigan Chapter of HIMSS; Chair SEMIHIE
Governance; Director IT Consulting, Covansys/Henry Ford Health System Account

Society
23

•

Michael (Mick) M. Talley, Lead Independent Director and Chair of the Audit Committee,
University Bancorp

Local Registration Authorities
•
•
•
•

Maurice Aljadah,, Program Manager, Healthcare IT, General Motors Corporation
Rebecca Dykes, Customer Service Supervisor, University Bank
Gina Cross, Customer Service Representative, University Bank
Stacy Shepanski, Vice President, Deposits and Consumer Lending, University Bank

Participants
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

Maurice Aljadah, Program Manager, Healthcare IT, General Motors Corporation
Suzanne Paranjpe, Ph.D., Executive Director, AFL-CIO Employer Purchasing Coalition
Jan Whitehouse, President, CyberMichigan, a Division of Altarum Institute; now:
Director, Save Lives Save Dollars (SLSD), Greater Detroit Area Healthcare Council
(GDAHC)
Carlotta Gabard, Vice President, IHA of Ann Arbor; now: Executive Director, Ann Arbor
Area Health Information Exchange (A3HIE)
Grace Miller, Director of Information Technology, IHA of Ann Arbor; now: Director,
Trinity Health
Sandra McKenzie, Applications Software Coordinator, IHA of Ann Arbor
Paula Smith, CIO, Oakwood Healthcare System
Barb Sabo, Director of Information Technology, Oakwood Healthcare System
Ken Garner, Manager, Information Security, Oakwood Healthcare System
Damien Payton, Lead Security Analyst, Information Security, Oakwood Healthcare
System
Vimal Chowdhry, Vice President, Business Effectiveness, IT Admin., Henry Ford Health
System
Fahd Haddad, Manager, Ambulatory Pharmacy, Henry Ford Health System
Dennis Sirosky, Senior Vice President, Product and Information Technology, Health
Alliance Plan
Mike Elinski, Associate Vice-President, Technology & eBusiness Development,
Corporate Security Officer, Health Alliance Plan
Jignesh Patel, Senior Technical Architect, Technology & eBusiness Development, Health
Alliance Plan
Craig Ireland, CIO, Botsford Healthcare Account / ACS Healthcare
Patricia Moore, IT Consultant, Botsford Healthcare Account / ACS Healthcare
Jim Holody, Director, Covansys Corporation
Charles Bracken, Managing Director, ACS Healthcare
Elaine Roach, President, Michigan Chapter of HIMSS; Vice President, ACS Healthcare
Stephen Lange Ranzini, President and Chairman, University Bank
Rebecca Dykes, Customer Service Supervisor, University Bank
Gina Cross, Customer Service Representative, University Bank

Society
24

•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

Stacy Shepanski, Vice President, Deposits and Consumer Lending, University Bank
Darnell Grant, Director of Information technology, University Bank
Janet Anderson, Executive Vice President, Internal Audit and Human Resources,
University Bank
Nick Fortson, Director and CEO, University Bank
Rick Moore, President, eHealth Ohio
Jim Lee, Michigan Health and Hospitals Association (MHA)
Mishka Bennett, Project Manager, Michigan Public Health Institute (MPHI)
Teri Takai, Director, Michigan Department of Information Technology and Chief
Information Officer for the State of Michigan
Dan Lohrmann, Chief Information Security Officer, Michigan Department of Information
Technology
Steve Crocker, Founder and CEO, Shinkuro
Mark Zalewski, Partner, Shinkuro
Mark Feldman, IT Architect, Shinkuro
Mark Eisner, Chief Technical Officer, FireStar Software
Chris Sanders, Vice President, FireStar Software
Jeffrey Dewhurst, FireStar Software
Jill Finnerty, Program Manager, FireStar Software
Robert Skinner, Partner, NextUs Incorporated

Scope: The scope of our pilot project was to identify and demonstrate a range of transactions in
healthcare that would significantly benefit from the added audit examination and security that
will derive from the use of ACES PKI certificates and services. These transactions would be
implemented in a real, operational setting, thus not just demonstrating technology, but
elucidating the issues in making that technology executable and operational.

Goals and Objectives
•
•
•

Gain experience and expertise in utilizing the ACES / E-Gov infrastructure.
Determine gaps, limitations and confusion in the distribution of certificates.
For end-users to understand that before a web-enabled, electronic transaction can occur,
the appropriate level of strength credential must first be presented, mapped to the level of
risk.

Organization: The Michigan team was initially divided into four working groups: Use-Case,
Technical, Financial and Governance. Over the course of Phase 1 of the pilot, the Use-Case and
Technical work groups became the primary focus of the participants.
Use-Case Framework: The Use-Case Framework was supplied to the members of the Michigan
Group belonging to the Use-Case Work Group (UCWG) and the Technical Work Group (TWG).
The UCWG identified three cases of interest, and the TWG established the topography for
placement of the Certificates and distribution of the tokens.
The Michigan Group had access to a total of 28 certificates, including six smart card tokens and
a “reader.”

Society
25

The Michigan Group defined the “end user” (doctor/nurse/pharmacist/payor/ambulance service
dispatcher/emergency room physician/neurologist/banker/patient/administrative staff/researcher)
and noted that the credentials, accepted as a generic term, were distributed on a personal role
basis or to an organization representing multiple persons.
The Group developed the view that it was important to use the results to provide a metric to
determine whether the data shared was an “improvement” or a quantitative advance.
Use-Case Process: The MI-DSTI pilot project use case process had three steps:
•
•
•

The vetting process and the distribution of the Credentials: Document the experience.
Share the data query initiated by the end-user from A to B: Document the methods /
results / success / problem.
Attempt some set of “interactive” experiments on the presentation format of the data for
the session with integration into existing medical protocols.

The Michigan Group intended to use the Use-Case to document the sharing of data securely
across IT systems, networks and domains to answer the following questions:
•
•
•

How do we know the person authenticated for access was the correct person?.
How do we know the data was transmitted correctly and was not tampered with by some
sort of “man in the middle” attack?
How do we know the data was shared securely, and what set of methods complied with
audit requirements for security and privacy?

The Michigan Group organized the vetting process for the credentials to begin with a physical
visitation with the designated LRA that provided for the presentation of photo identification
issued by a federal or state government agency. The goal was to use the vetting process over the
ACES E-Gov infrastructure to:
•
•
•
•
•
•

Document the experience.
Evaluate ease of access for the Lars and the end-users.
Gain expertise in the vetting process.
Document the Lars’ issues and concerns related to the outcome of the sessions.
Refine the process as gaps are discovered
LRA Certification Process.

The process for certifying selected persons and organizations as Lars had issues, difficulties and
concerns. One issue was that the original instructions from the ACES vendor to send documents
for LRA certification did not specify that the documents could not be faxed and could not be
copies. They had to be replaced with mailed, signed originals. This change or misunderstanding
added several days to the timeline.
End-User Certificate Vetting Process: The vetting process preceded the distribution of the
ACES E-Gov Certificates and required extensive coordination of timing and setting
appointments. The end-users receiving the Credentials were informed in person, by telephone or
by email that they would need to meet with an LRA and that they must provide a set of official
personal documents with photo IDs issued by a government or other appropriate administrative
body.
Society
26

The certificates were distributed to individuals and to an organization to provide for multiple use
and flexibility in the experiments.
Use Case Testimonial. Suzann Paranjpe, Executive Director, AFL-CIO Employer Purchasing
Coalition, a project team participant, submitted this statement in support of the use cases:
“We are extremely pleased with the final use-cases that were selected for the pilot, especially the
transmission of emergency department information to the patient’s primary care physician. The
current failure of this to take place has long been recognized as reducing the quality of care as
well as contributing to higher healthcare costs. As purchasers, we have pushed health plans for
years to coordinate the transfer of this information.
“We are also pleased about the pharmacy use case as this represents a significant business
transaction and will continue to, given the growth in the utilization of biotech drugs. While
referrals represent an ever declining business transaction, we agree that it will serve to provide
additional validation to the pilot’s approach to authentication.”
Use Case Scenario Testing Outcomes. The members of the MI-DSTI use case group (see
Participants, above) and Rick Moore of eHealth Ohio, with technology infrastructure and support
services provided by principals from FireStar, Shinkuro and NextUs, successfully completed the
use case scenarios developed by the group using a Ring-with-Tails architecture supplied by
FireStar on servers located at their offices in Maryland.

Society
27

Ring-With-Tails Architecture Diagram
Helen Hill
Patient
Hhill!shinkuro.com

Sandra McKenzie
Physician

EN-1

Jignesh Patel
Insurer

Sandra_mckenzie@ihacares.com

!shinkuro.com

EN-2

EN-3

Service Provider
EN-4

EN-10

EN-9

EN-5

Vimal Chowdhry
Neurology Physician
vchowdh1@hfhs.org

Rebecca Dykes
Bank
Beeka!mercurymessage.net

EN-8

Barb Sabo
Emergency Physician
Barb.sabo@oakwood.org

Fahd Haddad
Pharmacist
fhaddad1@hfhs.org

EN-7

EN-6

Patricia Moore
Ambulance Service
pmoore@acs-hcs.com

Rick Moore
Imaging Repository
rkmoore@ehealthohio.org

Test Results. The tests showed that the E-Gov technology e-Authentication service can work
successfully in healthcare. Although some issues were encountered the underlying technology
does work.
The MI-DSTI project team was able to successfully process certificates, send and receive secure,
digitally signed and encrypted data (including images) across a broad range of participants in
disparate organizations and across state boundaries.
The first scenario allowed a patient to request refills from the primary care physician, have those
refills filled by the pharmacy, notify the patient of co-pay and deductibles, and have the money
debited from the patient’s HSA by the bank following approvals. In this scenario, all parties had
appropriate credentials and were able to have their communications, digitally signed and
encrypted and sent in a secure data-sharing technology, among the parties as planned. (See
Appendix I—Detailed Use Case Scenarios and Appendix II—Samples of Use Case Forms.)
The second scenario was a variation on the first, adding pre-authorization process steps that
cause the primary care physician to send a request to the payor, HAP, before sending the
prescription to the pharmacy. [Note: in certain instances, a pharmacy such as the HFHS
Pharmacy may be pre qualified by the payor to handle pre-authorizations, thus eliminating a
process step]. (See Appendix I—Detailed Use Case Scenarios and Appendix II—Samples of Use
Case Forms.)
Society
28

The third scenario included a typical, but interesting series of exchanges among community
stakeholders: patient with credentials, ambulance company, hospital emergency department
physician, insurance company, another hospital’s pharmacy with pre-authorization capability, a
health system neurology clinic physician, an imaging center for a consortium of Children’s’
hospitals in another state, a primary care physician in another city and a financial institution.
(See Appendix I—Detailed Use Case Scenarios and Appendix II—Samples of Use Case Forms.)
Although there were a few initial setup issues, the forms the group used were actual healthcare
documents modified for use in the testing. Due to time limitations, no special applications were
created to automate the contents of the documents, so some of the forms were not polished.
Despite the fact that there were a few document naming convention questions, the process
actually worked and could, with some work on the application layer, be effectively used by the
members of this team in real life situations, quickly, effectively and securely in compliance with
HIPAA and a familiarity with ISO 17090—Part I.
One additional benefit to the project was the exceptional cooperation displayed by all members
of the project team. This will be helpful as the SEMIHIE continues to develop into a formal
organization. Throughout the project, the team members remain convinced of the importance of
this experiment and dedicated to completing the testing despite time-constraints and other
obstacles. They think that this project has potential for long-lasting benefit to the community and
will continue experiments with the GSA certificates and the Ring-with-Tails infrastructure.
Use-Case Flow Diagrams Overview: The patient, driving from her home in Ann Arbor to work
in Detroit, was hit by a truck on I-94 at Michigan Ave. in Dearborn, and suffered extensive head
injuries. Police called the nearest ambulance service. She was picked up by CEMS, the
ambulance service. CEMS notified Oakwood ER that this patient was coming in and gave a
preliminary diagnosis.
Oakwood ER assigned a room for the incoming patient; treated the patient on arrival; requested
authorization for neurology referral to HFHS Neurology from the payor, Health Alliance Plan;
requested medication authorization for the patient from the payor; requested and received
confirmation of an immediate appointment for the patient with HFHS Neurology; notified HFHS
Pharmacy of authorization of medications for the patient; called CEMS ambulance to pick up
patient; and billed the University Bank of Ann Arbor for ED services for the patient.
CEMS picked up the patient, notified HFHS Neuro that the patient was arriving; billed the
University Bank for patient pay portion. HFHS Neuro evaluated patient, requested a consult with
the Imaging Center in OHIO, received an image from Ohio from prior studies on the patient;
requested authorization from payor Health Alliance Plan for medications for the patient; notified
the primary care physician IHA in Ann Arbor of the findings; billed the University Bank of Ann
Arbor for the patient portion.
The Imaging Center in Ohio received a request for clinical information on the patient, located an
image from an earlier visit and sent that image securely and encrypted to the requesting HFHS
Neurology Clinic physician and to the primary care physician, IHA Ann Arbor; billed the
University Bank of Ann Arbor for the patient portion.
The University Bank of Ann Arbor received bills from all the parties, reviewed available funds,
notified the patient of the charges, received patient approval to pay, and paid the bills from the
patient’s demand deposit account. The primary care physician from IHA Ann Arbor received
Society
29

documentation of care provided to the patient from Oakwood ER, HFHS Neurology, HFHS
Pharmacy and the Ohio Imaging Center; reviewed and filed the documentation and arranged for
follow-up.
The patient received notifications from the University Bank for authorization of payment from
all the billing parties and approved the payments from her HSA direct deposit account. The
Patient received notification from the HFHS Pharmacy that her prescriptions were ready for
pickup and notification of the required co-pays.

Society
30

[Note: Groupwise 6.5 posed several as yet unresolved issues related to processing
certificates: recognizing valid certificates, signing and encrypting messages with the
certificate.]
Minnesota—Community Health Information Collaborative (CHIC)
Project Overview: The overall CHIC-RHIO vision is “to facilitate the sharing of health
information across all organizations, contributing to the continuum of patient care.” As
part of that vision, the Minnesota project team focused on developing a single sign-on
service, using the ACES certificates. Developing a single sign-on through a Web-based
portal will streamline access into remote systems for physicians. This project was viewed
as a proof-of-concept that federated identity management and digital certificates could be
a viable solution to the single sign-on objective.
CHIC retained a Minnesota-based company, VisionShare Inc., to develop a federated
identity management system. VisionShare, in turn, collaborated with researchers at the
University of Minnesota to build a test-bed system based on software recently developed
by the Internet2/GRID community. During the course of this project the VisionShare
principles involved in this project formed a new company, MEDNET USA, so we will be
referring to this new company in this report.
This software, called “Shibboleth”, was developed by leading researchers at The Ohio
State University and Georgetown University. Shibboleth is an initiative to develop an
open, standards-based solution to meet the needs for organizations to exchange
information about their users in a secure, and privacy-preserving manner. The initiative is
facilitated by Internet2 and a group of leading campus middleware architects from
member schools and corporate partners.
The purpose of the exchange is typically to determine if a person using a web browser
(e.g., Internet Explorer, Netscape Navigator, Mozilla) has the permissions to access a
resource at a target resource based on information such as being a member of an
institution or a particular class. The system is “privacy-preserving” in that it leads with
this information, not with an identity, and allows users to determine whether to release
additional information about themselves. An “open solution” means:
•
•

An open architecture; and
A functioning, open-source implementation.

“Standards-based” means that the information that is exchanged between organizations
can interoperate with that from other solutions.

Background on Minnesota CHIC
Description. In the eight-county region included within the CHIC RHIO, there exists two
major hospital systems and numerous smaller rural hospitals and clinics. Our overall
project strives to give physicians and other authorized providers a complete picture of
their patients’ medical record. Access to the assorted health information is designed to be
through a Web portal supported by CHIC.
Participants. Members of the team included:

Copyright 2007 by the Healthcare Information and Management Systems Society

31

Cheryl Stephens, CHIC, Executive Director, CHIC-RHIO Co-Project Lead, Local
Registration Authority for digital certificates.
Melinda Machones, St. Scholastica’s Center for Healthcare Innovation, Director of
Projects, CHIC-RHIO – Co-Project Lead, Local Registration Authority for digital
certificates.
John Fraser, CEO, MEDNET USA, Technical Project Manager, National
PKI/Infrastructure expertise
Seonho Kim, MEDNET USA, Senior Software Architect, Ph.D Candidate, University of
Minnesota Department of Computer Science. Shibboleth design and support.
Dr. Jon Weissman, University of Minnesota, Associate Professor of Computer Science.
Oversees Shibboleth planning.
Dr. Michael Slag, SMDC Health System. Pilot physician to test digital certificate.
Dr. John Van Etta, St. Luke’s. Pilot physician to test digital certificate.
Clark Averill, St. Luke’s, Director on Information Technology.
Dennis Smith, SMDC Health System, Director, Technology Systems.
Dr. Tim Arnold, Riverwood Health Care Center, Pilot physician to test digital certificate.
Mark Schmidt, SISU Medical Solutions / Systems, CIO
Interesting Facts. The use of a federated identity management system is one of the most
interesting aspects of this project. MEDNET USA recommended this solution since, with
multiple organizations involved, a centralized system was not appropriate. The
Shibboleth software used was initially developed for university environments. This is one
of the first implementation of Shibboleth in healthcare.
It is interesting to note that the CHIC community quickly understood the sharing of
identity that this model supports, and liked the overall architecture. Although quite
complex underneath, the user interface is a set of Web pages, with which users are
comfortable and can quickly master.

Business Problem
Use-Case Review: This case study for this HIMSS/GSA project was designed to allow
the CHIC RHIO to demonstrate the following capabilities:
•
•
•

Volunteer physicians and/or other authorized providers will log into a single Web
site for authentication.
This authentication will be used to authorize physician/provider access to various
Electronic Medical Record (EMR) systems.
The physician/provider will demonstrate the ability to look up patient information
on these systems without additional logins to demonstrate the capability of single
sign-on. (Phase II)


32

A diagram of the environment:

Results
Registration of Certificates. The registration process involved two phases. The first was a
test between the project’s two co-leads who had been identified and trained as Local
Registration Authorities (LRAs) by ORC. It was important to walk through and test the
process prior to engaging physicians. One of the co-leads was successful in completing
the registration process, on-line, and, ultimately, receiving her certificate and reaching the
test servers. The other co-lead, however, was unable to successfully complete the on-line
registration process and, therefore, has yet to receive her certificate. Phone and e-mail
communication with the ACES vendor reported the problem, as well as inclusion on the
Issues Log. Although she appears to have a typical Windows/IE system, the ACES
vendor has been unable to resolve the problem.
We decided there was not time to wait for resolution of this registration, since one had
worked. With the help of the IT directors at the various health systems, we identified
physicians willing to work with us through problems. Ultimately, all three physicians
successfully registered and received their digital certificates.
Although the Web application is rather straightforward, it could be streamlined to save
time and minimize points of confusion. Examples include:


33

•
•
•

Automating the installation of four certificates to trust the ORC ACES Certificate
Authorities.
Allowing special characters in the entered information for the online application
(e.g., a colon [:] is not acceptable).
Formatting or streamlining the pop-up window instructions to ensure the users
understand its purpose and follow the steps completely.

We discovered, also, that the support structure, when problems arose, was hard to reach
and resolution was slow.
Use of Certificates. The initial installation and testing were done with test certificates
issued from a test certificate authority run by MEDNET USA. This allowed the group to
focus on getting all the components quickly working. Once the ACES certificates were
received, installing and using these certificates was simply a matter of adding them to the
access control lists on the system and has not been a problem.
Secure Data Exchange. Due to existing Minnesota privacy laws, our test did not
exchange data; it was designed to test a proof-of-concept in the use of digital certificates
to authenticate a user. Both hospital systems set up test servers as part of the Shibboleth
network. When the login was successful, the user received a ‘Congratulations’ screen
upon reaching the test server.

Moving Forward
Next Steps. We have two “next steps” with this project. The first is to resolve identified
problems with the registration process so that we, and the ACES vendor, can learn for
future registrations. The second is to replace our test servers with the hospitals’ test Citrix
systems to learn to work within a Citrix environment and access the applications it
supports. All participating health systems use Citrix as their front-end interface with
different EHR systems implemented. We believe that lessons learned in the phase with
advance our vision of single sign-on capability to physicians in our RHIO environment.

A hospital emergency room desires access to patient information from patients associated
with an MSO (Managed Service Organization) associated with the hospital. The MSO
manages 21 individual physician practices. Furthermore, the MSO provides billing
services to the 21 practices and desires access to patient records in order to support the
billing efforts. The MSO provides, as an optional service, referral processing
functionality and desires to access patient information appropriate to the referral mission.
Use Case Overview. As patients of the designated clinics present to the emergency room

for treatment the ER physician will access the records of the patient directly from the
patient’s primary care and specialist records. As patients return to their primary care
physician the records of the ER visit will be electronically posted to the patient’s chart.
As patients require treatment via specialists in the form of a referral the referral
processing authority for the MSO will forward PHI to the appropriate insurance
companies in order to obtain authorization for a referral. As a patient is treated by a
primary care and specialist physicians who are both on the network the transmission of


34

the primary care physician’s patient visit records and related clinical information are
electronically posted to the patient chart at the specialist being referred to and,
subsequently, the specialist report is returned to the referring physician’s chart
electronically.
Results. Unfortunately, the Nevada project dropped out of the initiative due to lack of
resources.

Ohio—Ohio Supercomputer Bioinformatics
Project Overview. Healthcare research is increasingly incorporating individually
specific information for progress and insight into diseases and exploration of new
treatment approaches. The information that is sought includes patient histories and other
data that is part of the emerging electronic medical record. Concurrently, to remain
competitive in funding research efforts, incentives and requirements have been advanced
to encourage sharing information collaboratively among research efforts. While
infrastructure is being developed to facilitate interchange of information among the
research community (such as the NCI caBIG effort), a standard approach for individual
authentication that transcends clinical and research communities has yet to be established.
Background. Initiated by eHealth Ohio, and in conjunction with the Ohio
Supercomputer Center, this project has focused on evaluating the viability of using the
proposed national level user authentication process as a means of authenticating
individual researchers, system developers and system administrators who will be both
utilizing, creating and maintaining future health care research systems. An emerging area
of software development focus, this pilot will also identify key issues faced by resource
constrained development efforts.
Broader Impact. The broader impact of a common authentication standard that bridges
the clinical and research communities cannot be overestimated. The presence of a
national standard in this capacity will have significant implications for increased
accountability and thereby confidence in research efforts employing individually
identifiable information. A national authentication standard for healthcare researchers
will have an anticipated impact of increased uniformity among IRB (Institutional Review
Board) protocols involving patient information, while simultaneously enabling improved
adherence to regulatory requirements imposed by HIPAA.
Use-case. Authentication of researchers for research data of emerging data interchanges.
Project Approach. The approach in the pilot has been to evaluate the process for design
and logistical implications for future systems in development, intended to be compatible
with emerging data interchange requirements imposed by the research community (e.g.
caBIG). Current systems developed at OSC for the Ohio BioRepository and for the
telehealth research funded by the Department of Health and Human Services Office for
the Advancement of Telehealth provided the prototype platform technology for
evaluating the viability of the certificates, with design and procedure implications being
incorporated into development plans for target collaborative systems involving
integration of biospecimen, virtual microscopy, microarray and clinical health
information.


35

Participants
eHealth Ohio. Ohio—eHealth Ohio—OSC Bioinformaticsis a non-profit organization
formed to promote the advancement of health information technology (HIT) in the state
of Ohio via educational outreach and other services. The leadership of Ohio—eHealth
Ohio—OSC Bioinformatics include representatives from the Ohio Department of Job and
Family Services, the Ohio Hospital Association, the Ohio State Medical Association, the
Ohio Osteopathic Association and other Ohio stakeholders in HIT. Ohio—eHealth
Ohio—OSC Bioinformatics also is an active participant in the formation of the strategic
roadmap for the adoption of HIT and the Health Information Security and Privacy
Collaboration (HISPC) with the Health Policy Institute of Ohio. EHealth Ohio’s
participation in this pilot is an outreach to help promote standards in HIT security needed
for the success of the Nationwide Health Information Network and the Regional Health
Information Organizations in Ohio.

Participants from eHealth Ohio
Richard Moore
Ohio—eHealth Ohio—OSC Bioinformatics–President
Co-Project Leader and Local Registration Authority for digital certificates
Nancy P. Gillette, JD
Ohio State Medical Association, Senior Counsel
Ohio—eHealth Ohio—OSC Bioinformatics–Treasurer, Pilot Project LRA Notary Public
Ohio Supercomputer Center. OSC provides a reliable high-performance computing and
high performance communications infrastructure for a diverse statewide/regional
community including education, academic research, industry and state government.
Supporting an operational statewide fiber optic backbone network as well as production
data and computational facilities, OSC enables exploration of new computing paradigms
and approaches in such key areas as industrial computing, health information technology,
and data management, mining and visualization. Working as a collaborative partner, OSC
both promotes and leads computational research and education initiatives, enabling
progress in advanced technology, information systems and key industries.

Participants from OSC
Eric Stahlberg
OSC - Senior systems manager
Technology direction, Ohio BioRepository Initiative
David Bertram
Lead system administrator, Ohio BioRepository Initiative
Joe Miller
Lead developer, Ohio BioRepository Initiative
Columbus Children’s Research Institute. The Center for Childhood Cancer
BioInformatics Group (C3BIG) of Columbus

36

Children’s Research Institute, under the direction of Dr. Stephen J. Qualman, is a
BioInformatics application development team dedicated to increasing cure rates and
decreasing side effects in therapy through Information Technology. Development efforts
are focused on these key disciplines within the center: molecular genetics, core
morphology, histology, the biospecimen repository, functional genomics and specific
pediatric cancer research initiatives. Our development efforts also extend outside the
walls of Children’s Research Institute to those of the Cooperative Groups. These groups
are the Children’s Oncology Group (COG), the Gynecologic Oncology Group (GOG),
the Cooperative Human Tissue Network and the Childhood Cancer Survivor Study.

Participants from Columbus Children’s Research Institute
David Billiter
Manager—Center for Childhood Cancer BioInformatics Group
Tom Barr
Medical Technology Specialist—Center for Childhood Cancer Bioinformatics Group
Results and Conclusions. While original expectations of the pilot evolved over the
period, the HIMSS pilot project has proven invaluable as a means to clarify logistics and
procedures required for establishing individual authentication at local and remote
collaborating research sites.
Staff turnover and a delayed development schedule precluded fulfilling the original aims
of the pilot project within the expected timeframe. Nevertheless, procedures and details
were refined in the prospective use of the ACES vendor to prepare digital certificates for
project collaborators. Multiple individuals were registered and issued digital certificates.
Further testing of the issued certificates within the prototype architecture remains to be
done.
Summary lessons learned from the pilot include:
•
•
•
•
•
•

A clear definition of authentication process capabilities and services provided by
the central registration authority is critical in the initial phases for planning.
Accurate and complete documentation is critical for successfully completing the
authentication procedure.
Scheduling logistics for the necessary face-to-face meeting between the LRA and
individuals can be problematic when involving collaborating and remote sites.
Logistics for authenticating remote participants is increasingly difficult. Plan to
cover costs, including travel, to authenticate individuals from remote sites.
Ensure a computer security development expert is incorporated into the effort
from project inception for the duration
Use of removable USB drives provides a means to transport individual security
certificates.

Recommendations
•

Identify or qualify an onsite employee to serve as a notary public.


37

•
•
•
•

Establish and maintain a current central registry of qualified Local Registration
Authorities among the participating organizations.
Cross-certify LRA among projects to aid the registration of remote collaborators
not conveniently within driving distance.
Develop authentication instructions tailored for different individual levels of
expertise.
Consider methods for remote video registration certification.

Next steps. The individual pilot effort will next focus primarily on further validating use
of the issued certificates in the prototype and expanding the involvement of collaborators
accessing the prototype. Technical learnings from the certificate pilot will be used to
guide future technology decisions in data security.
Concurrently, steps will be taken to convene other pilot project participants to review
pilot outcomes to further refine the viable technical options for operating central,
federated or common secure authentication server resources shared among collaborating
sites.

Background. Virtual Medical Network (VMN) is a turnkey enterprise solution for
practice management, electronic health records, billing, scheduling, electronic
prescribing, and transcription (dictated files are returned as either key value paired data or
as independent documents per physician preference, and are imported directly into the
patients’ medical records). VMN’s product is a Web-based ASP model, allowing access
from virtually anywhere.
Business Problem. Because of its ASP architecture, members within VMN’s network
have no difficulty sharing information or accessing records of mutual patients while
remaining HIPAA compliant. Securely importing information from outside the VMN
network is also readily done. However, security becomes an issue when VMN clients
wish to export information outside of the VMN network. HIPAA regulations require the
creation of a positive audit trail and a documented chain of custody for transmission of
data containing personally identifiable protected health care information.
Creating a limited user role for out-of-network users does not resolve the authentication
issue. There is no reliable way to confirm that the person receiving the exported
information is in fact the actual intended recipient. This becomes a significant issue when
a physician needs to make referrals to out-of-network doctors electronically, or to export
medical histories to out-of-network facilities. Creating a means for an out-of-network
user to retrieve exported files would be fairly straightforward. However, authenticating
an out-of-network user for download permissions presented a challenge. VMN wished to
explore the feasibility of using the GSA certificates in lieu of developing a proprietary
authentication method for validating the identity of ex-network users.
Experience Using GSA Services. We selected one of our clients, Dr. James Kolp, a
physician specializing in family practice, as a candidate for our “in-network” certification
trial, and our LRA (Rick Powell) as a candidate for our “out-of-network” certification
trial. Once the certificates were obtained, Dr. Kolp would create a referral letter and an


38

exported file of a mock patient’s pertinent medical history and post the file in the
appropriate VMN location using his certificate as authorization to post. Mr. Powell would
then navigate from outside the VMN network to the site, present his GSA certificate for
authentication, and download it.
Registration of Certificates. Mr. Powell submitted his application for a certificate as
part of the training provided for LRA’s on Aug. 16, 2006. Dr. Kolp submitted his
application from his office laptop on Nov. 30, 2006.
We received and confirmed the certificate for Dr. Kolp, and were able to perform import
and export functions to confirm portability of the certificate file from one laptop to
another, as well as feasibility of maintaining a copy on Dr. Kolp’s thumb drive. In
addition, the certificate was tested against the GSA’s vendor’s web site.
Use of Certificates. Testing of the certificate against our Web server was delayed due to
the time required to troubleshoot an authentication issue. The initial client certificate
request from our web server was unsuccessful because the certificate for Dr. Kolp failed
to meet the requested parameters. This was apparently due to incompatibility issues with
Internet Interoperability Standards (IIS)5. This was resolved when we moved the VMN
authentication site to a server operating with IIS6 (special thanks to fellow pilot
participant Lori Fourquet for her generosity sharing “lessons learned,” which enabled us
to find this workaround).
VMN plans to test the certificates utilizing Dr. Kolp’s certificate as the “sending” party
and a certificate from one of the participating RHIO’s certificate holders as a “receiving”
party, thus enabling us to confirm whether communication between two discrete RHIOs
is feasible utilizing the ACES certificates. (See flowchart, below).


39

HIMSS GSA e-Authentication whitepaper June 2007

HIMSS GSA e-Authentication whitepaper June 2007

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Viewers also liked

Viewers also liked (6)

Similar to HIMSS GSA e-Authentication whitepaper June 2007

Similar to HIMSS GSA e-Authentication whitepaper June 2007 (20)

Recently uploaded

Recently uploaded (20)

HIMSS GSA e-Authentication whitepaper June 2007