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 3 Background 5 Problem Statement 5 Security and Privacy Concepts and Technologies 5 AAA—General Information Technology Security Framework 6 Trust Model 7 Authentication Systems 12 Authentication Factors 13 Credential Service Providers 13 The GSA e-Authentication Service Component 13 The ACES Program 16 ACES and Presidential Directive 16 IHE Interest 17

RHIO Project Overviews Connecticut—Connecticut Regional Health Information Organization 18 Michigan—Michigan Data Sharing & Transaction Infrastructure Project 25 Minnesota—Community Health Information Collaborative (CHIC) 37 Nevada—Single Portal Medical Record 40 Ohio—Ohio Supercomputer Bioinformatics 41 Ohio—Virtual Medical Network 44 Corpus Christi—Coastal Bend Health eCities Project 48 Project Conclusions 52 Appendix 54 Acknowledgements 58 References 59


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 • Michigan—Michigan Data Sharing & Transaction Infrastructure Project • Minnesota—Community Health Information Collaborative • Nevada—Single Portal Medical Record • Ohio—eHealth Ohio-OSC Bioinformatics • Ohio—Virtual Medical Network • Texas—Christus Health, health eCities project


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


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.


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..


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 E-Authentication – 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

ate ease-of-use would be to grant everyone

ent

evel than, say, an application that allows you to see the Pentagon’s war plans. In t

p their security

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 ultimaccess 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 tolook up your child’s grades on his or her school’s Web site would probably have a differsensitivity lhealthcare, we expect that access to records from within an organization would have a differensensitivity 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 develostandards.


Risk Assessments. To properly identify the security requirements for an application or datarisk assessment must be performed. Just as the term

, a implies, the goal to discover what is at risk if

gency if

ssessment of their e wrong person accesses egal, ethical and

ppropriately addresses risk. Again, as the term implies, you need to identify the individual or system trying get your data or

se your application. The federal government came up with four “levels” of assurance:

• laim to be. • Level 2. who they claim to be. • Lev ey claim to be. • L who they claim to be.

Fig the s sura for e uthentication established by the Office of Management and Budget, and supported by the GSA’s e-Authentication Service component used in this project.

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 athat information fell into the wrong hands.

On the risk a other hand, the Department of Labor may determine from apayroll system that there is significant risk of fraud or financial loss if thheir system. For health information that involves patient data, there are lt

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 ahow “assured” you need to be of the identity of u

Level 1. Not assured that users are who they cewhat assured that Som users are

el 3. Very assured that users are who thevel 4. Absolutely assured that users are

. 2 shows tandard as nce levels lectronic a


OMB E-Authentication Guidance Establishes

Four Assurance Levels for Consistent Application of E-

Level 4

Level 3

Level 2

Level 1

Little or Some High Very high no

confidence in

asserted

confidence in

asserted identity

confidence in

asserted identity

confidence in the asserted identity

ig. 21: OMB assurance level guidance.

redential Types. A “credential” in this system is something that is asserted to represent the entity of a user or a system. We are all familiar with usernames and passwords, ATM cards and INs and so on. These are examples of credentials, and figuring out which one is the right one quired for your needs is the next step in developing your security solution.

nce your organization has determined the risk associated with data or applications and have entified the assurance level needed to address the risk, you need to determine which credential pe provides that “level” of assurance.

the system processes patient health information, a High Confidence in the Asserted Identity is

e. icates issued using a strong policy probably would provide high

onfidence. The OMB and the National Institute for Standards and Technology (NIST) provide ential types with assurance levels. Fig. 31 extends the

Assurance Level Guidance to include associated credentials.

F

CidPre

Oidty

Ifrecommended, which the Office of Management and Budget (OMB) identifies as a Level 3. Username and password authentication requirements would not provide High ConfidencHowever digital certifcstandards for pairing up certain cred


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:

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

Factor Token

Very High

HighMedium

LowEmployee Screening for a High Risk Job

Obtaining Govt. Benefits

Applying for a Loan

Online Access to Protected Web site

PIN/User ID -Strong Password

Knowledge-Based PKI/ Digital Signature

Multi-Increa

sed $

Cost

Increased Need for Identity Assurance

NIST SP800-63 Electronic

Authentication c ce t ology

ac ce level

te hnical guidancma

to ehes tec nhh assuran

OMB E-Authentication Guidance establishes

ur Assurance LeveFo ls for Consistent Application of E-

Level 4

L3

evel Level 2

Level

L

co

1 ittle or

no nfidence in

asserted

Some confiden

ce in asside

erted ntity -

PIN/P

High iden

tedtity

confce in

asser iden

-

Very high

confidence in the assert d

e

identity

E-RA tooagenc

l assists ies in

defining thentication

requirements & mappin to the appropriate assurance level

au

g them


identity assertion is his or her claim that he or she is the person who is associated with, or owthe usern

ns, ame. This is proved by supplying a secret password that only the user and the user’s

le factor, two factor, and three

le factor. Something you know, such as a password or the answer to a question, such

adge that k ID would most likely not be acceptable by a

card.

tion procedures were used when it was

g credentials for state re

he GSA e-Authentication Service Component he following definition of the GSA’s e-Authentication Service Component comes from CW.com

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: singfactor.

• Singas 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 credentialsinclude 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 bmust be worn while on duty. However, your wormerchant 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 SecurityThey 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 verificaissued.

Credential service providers take on the important role of issuing and managinboth people and machines. In healthcare, regulated practitioners are credentialed by thelicensing process which is further verified and validated by provider organizations befoenabling practicing privileges at their locations.

TTF :

The e-Authentication Service Component incorporates two different architectural techniques, ssertion-based authentication and certificate-based authentication, according to the General ervices Administration.

PIN and password authentications typically use assertion-based authentication, where users uthenticate to a Credential Service Provider (CSP), which in turn asserts their identity to the gency Application (AA). Certificate-based authentication relies on X.509v3 digital certificates a Public Key Infrastructure (PKI) for authentication, and can be used at any assurance level.

“aS

“aAin


“PKI credentials offer considerable advantages for authentication. Certificates can be validated sing only public information. Standards for PKI are also more mature than other authentication chnologies and more widely used than the emerging standards for assertion-based

uthentication of PIN and password credentials.

Nevertheless, the e-Authentication Service Component incorporates both assertion-based and ertificate-based authentication to provide the broadest range of flexibility and choices for deral 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;

erating within the Federation; and • “management and control of accepted federation schemes operating within the

environment.”

utea

“cfe

• “business rules for op


The U.S. Federal PKI

provides digital certificates and t require logical access control,

igital signature and/or electronic authentication. They also support the sharing of health ation in cross-organizational and RHIO and HIE data exchanges. GSA serves as a Policy

responsible for organizing and administering the ACES Policy and the ACES

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

The ACES Program The Access Certificates for Electronic Services (ACES) program

KI services to enable electronic government applications thaPdinformAuthority and iscontract.


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.

rd 201. This standard requires a common access card be

ES credentials to demonstrate the

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 Standadeveloped 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 e-Authentication Pilots to validate, through pilot implementations, the technical concept for use in the healthcare sector. The project chose to use the ACcapabilities 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.


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 critinformation. IHE includes medical specialists and other care providers, administrators, stan

ical dards

lar

s ducing configuration and interfacing costs and ensuring a

s IT infrastructure, which enable interoperability both

first reason for interest is to make sure that

the IHE

nd digital certificates to enable TLS to ensure that all nodes in

rmation ) which specifies the use of

t certificates to ensure document integrity and .

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 cardiovascumedicine.

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 addresthese needs, eliminating ambiguities, rehigh level of practical interoperability. IHE is now truly multi-domain, with integration profilefor radiology, cardiology, laboratory andwithin and across multiple enterprises.

The IHE Interest in the GSA project is twofold. Thethe 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 insolution. 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 aAudit Trail (ATNA) profile utilizesan affinity domain are trusted so as to enable secure access to shared health inforesources. IHE has also specified Document Digital Signature (DSGISO TS17090 Health informatics—PKI-complianaccountability 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

n

s are

s

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 OrganizatioBackground: Connecticut RHIO communities in the Middlesex, Hartford and Bridgeport areashave 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 effortin various stages of development. In particular, initiatives in the Middlesex area overlapsignificantly.

Through the eHealthConnecticut Technical Committee, members of the statewide RHIO hold regular meetings to discuss system architecture, infrastructure and interoperability requirement


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 e-Authentication 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 andProHealth Physicians e have members who interact with numerous organizations, several of which spec

ifically have routine patient care business with other members of this test bed

C) for Health Information Technology Health Information Privacy and

e PKI. ces and

, communications and identification of professionals and patients.

ation.

).

or the purposes of this pilot, we have asserted TS17090 in the absence of configured support for the

. The extension includes a standard means by

ic inician direct access to a person’s medical history. It would allow the

e

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 (ONSecurity 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 thThese health informatics standards specify requirements for use of PKI, directory serviauthorization 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

• 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 Inform• 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).

Fthe healthcare extension specified as optional in the technical specification and mandatory by International Standard revision of the specificationwhich 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 electronhealth record will give a clprovider 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 b


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

opriately

ugh demonstration of affiliation with the identity and proof of an active medical license. y issued an affiliation certificate such that the

current affiliation with the healthcare

itially will be used to enable access to medical al

The patient presents to the emergency room later that evening. Rather than repeating the radiological exam in the

aster, better quality t, and reduces the cost of duplicate testing. e emergency department at a tertiary care hospital after

ommunity hospital. The emergency room ty hospital portal to retrieve prior EKGs within

eatment for the patient.

tions e

primary care provider or specialist) is the recipient of the communications:

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 apprcredentialed 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 throlicensing authority through vetting of individual

mployees are similarlSupporting organization evetting attests to proof of individual identity and proof ofemployer.

This use-case has broad applicability, but ininformation from the emergency department. In the context of the pilot participants, two clinicscenarios are considered:

• A patient complaining of abdominal pain is sent for outpatient radiology services following consultation with the primary care physician.

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 ftreatment for the patien

th• A patient presents toexperiencing symptoms of myocardial infarction, and indicates that he has been

the cpreviously seen for cardiac services at physician authenticates to the communithe “golden hour,” providing informed tr

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 communicato securely deliver this information to the provider. In this test series, the physician in thoutpatient setting (

• 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.


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

nd the

o be

d

iced by

ut

rt

ave 090 0

consumer empowerment.

As eHealthConnecticut moves toward a shared document infrastructure, we look to expause-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 tpursued during the next phase of this project.

Participants: Two Connecticut regions are participating in the project—Central Connecticut anthe Bridgeport Community. Central Connecticut participation is represented by five organizations characterizing a common health market where patients are regularly servmultiple-provider entities. The participants in this region include two hospitals, three physiciannetworks 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 Connectic

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 suppoof 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 hleveraged the ACES Affiliation certificate using hardware tokens to instantiate the ISO TS17Health informatics-PKI technical specification. We were unable to initiate the revised IS1709


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

ment

ES

e ments associated with the

mpact

t this

d

ding and using their online-available resources for ongoing affiliation

logy

ave t are

rd Hospital, Jefferson Radiology and HIMSS.

, the the

ing

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 manageinfrastructure (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 ACcertificates.

Establishing a Registrar: Connecticut is using smart to demonstrate high-assurance, portablidentity management to meet the security and privacy requireprotection of health information and the execution of transactions and processes that may ipatient 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 atime 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 inthe state to discuss obtaining authorization from DPH to represent the affiliation of the licensehealthcare professionals to their licensure in accordance with the International Standards IS17090 Health Informatics PKI. The discussion was well-received, with the only hesitationbeing that for the state to provide a letter. It might be construed as an acquisition, which is highlyregulated. There was support for the principals and concepts and they encourage proceeding with the affiliation binverification. 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 technoshould this project prove successful in the state.

Early deployments are focused around the resource providers of the project. As such, letters hbeen obtained first from these organizations, and will be obtained from the organizations thaprimarily client-side subsequently. Registration letters have been obtained from Middlesex Hospital, St. Vincent’s, Hartfo

Registration Process: In the interest of maximizing end-user support for obtaining identitiesinitial registration process included the Local Registrar requesting the identity along withend-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 follow


the initial key request to print the documents or needed to provide a copy of the request to tsubscriber. Scheduling two follow-up visits as part of the pro

he cess was impractical, and as such,

ber e-

ations to accept foreign media for information transfer. This approach also required a strar to retrieve and download the issued certificate to the

s the card needed to be left in the possession of the subscriber, there left the key at their home office and were not able to

ill then be issued ill

r’s visits from two or three to a single visit. End-

n. The ar as

ave n supervisor—the board of directors, executive

ally ork administrator. The regulated healthcare

ee

role r

we explored options for printing during the first session. E-mailing the request to the subscriwas also an issue as some of the key information for the registration form was stripped by the mail 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 organizfinal visit from the local Regisubscriber’s smart card. Awere cases where the subscriber hadcomplete 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 wfrom the subscriber’s machine or from the machine of the local IT or security officer. This wenable 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 Registrauser 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 integratioproject sponsor—typically, the CIO or CTO—provides a letter to recognize the local Registran 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 hrelated concerns. Usually, this is their owmanagement, human resources or the organization’s HIPAA officer. The HIPAA officer and, asappropriate, 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 typicinvolved the e-mail administrator and the netwprofessionals are selected carefully so as to assure that the user will be technically savvy andhave 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 environmentsto 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 throf 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 expressed in the digital identity in the “OU.” All identities have been configured in this manneto emulate the requirements of the ISO TS17090/IS17090 Health Informatics PKI technical specification and standard. Some initial testing of secondary authorization utilizing the ISO


TS21091 Health Informatics Directory services for security, communications and identiof 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 theACES Vendor digital identities and encryption certificates stored on smartcard. This has beenbased upon local address-book and reply-to-signed approaches. The next stage of this testing wleverage 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

fication

ill

, several groups have been defined and tested based solely on the

articipants, Middlesex Hospital

s technology and user-base will need to be broadened before the

t if this could be broadly

d independently, the provider sites

with the token and

n proposed

Project ackground: Southeast Michigan is a seven-county area with nearly 5 million residents—40

e

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 pand 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 preliminarypatients. 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 addressedto be able to broaden and scale this use-case.

Feedback: While feedback from the project participants has been generally positive, there iconcern that the penetration of the efficacy can be realized. However, the trust level associated with the identity has been well respected, and participants from multiple sites have remarked thadeployed within the state, that there would be significant opportunity to better enable health information sharing among practitioners. Repeatedly, aninvolved 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 identity provision would be worthwhile.

Feedback from the state-level initiatives has also been positive. This project has beeas a possible solution as part of the CT-HISPC initiative to address the problem of provider identity management that has been identified.

Michigan—Michigan Data Sharing & Transaction InfrastructureBpercent 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 th


state’s licensed physicians (14,000) practice here and 80 percent are not automated. Three majoauto companies have world headquarters here. The economy is under siege as the manufacturingsector 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 (citi

r

zens,

ment of Community Health, has put in place the framework for a statewide RHIO—

m

l tate of Michigan HIE planning grant proposal..

nt business model for the SEMIHIE that aligns costs with benefits for the stakeholders and to provide for secure, private

utional exchange of clinical and administrative healthcare data to:

ve

in clinical and administrative healthcare processes through the sharing of healthcare data.

uture support for patient education, issues affecting surveillance reporting.

d

curity, authorization of

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 DepartMiHIN. 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 forimplementation 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 (AltaruInstitute, Greater Detroit Area Health Council and the medical societies of Wayne and Oaklandcounties) 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 proposaresponse for a S

The objectives of SEMIHIE are to establish a sustainable, self-sufficie

and efficient cross-instit

• Enhance physicians’ and other healthcare providers’ ability to access and use electronic health information and decision support tools to facilitate appropriate care and impropatient safety.

• Foster improvement

• Build the foundation to provide fpersonal health and public health

• Create a secure, ubiquitous, interoperable HIT infrastructure consistent with state anfederal standards/guidelines, where applicable.

• Implement a technology infrastructure that provides for proper seusers and indexing of patient information from multiple sources.


• Drive the adoption of policies and technical standards to facilitate data gathering, information sharing and decision-making while protecting patient privacy.

ational and regional efforts through use of a common trust framework, business dentity

ation of SEMIHIE and MiHIN, a group of individuals including financial

ssional organizations, technology and

Transaction icationPilot

ers were

on embers of SEMIHIE about the importance of establishing e-

ork across the Federal Bridge with agencies of the federal for linking

ng

ugust

e, organizations and individuals, most of whom were SEMIHIE members, for the pilot

e project embers in a trusted environment has been

consulting firm, e MI-DSTI participants, mental testing was

experiment with f the

Governance; Director IT Consulting, Covansys/Henry Ford Health System Account

• Link to nand operating rules, technical infrastructure and governance models for federated imanagement and interoperability.

• Develop and maintain an environment of trust among the stakeholders. In parallel with forminstitutions, large and small health systems, physician groups, insurers, unions, the autos, employers, purchasers, public health, healthcare profeconsulting firms and international standards organizations began to develop a pilot focused on secure interchange of healthcare data across disparate stakeholders to evaluate the feasibility ofusing e-Authenticationin healthcare. This pilot project, the Michigan Data Sharing

GSA / HIMSS e-AuthentInterface (MI-DSTI), applied for and was accepted in theProject along with the projects of six other states. [The majority of the MI-DSTI memb

IN.] also simultaneously involved in SEMIHIE and in the committees working on MiH

In July 2006, David Temoshok of the GSA and Michael Sessa of the Electronic AuthenticatiPartnership (EAP) spoke to the mauthentication, federated identity management, integration and interoperability across industry segments and of being certified to wgovernment. This presentation was well-received by SEMIHIE and the requirementsto national and regional efforts through use of a common trust framework, business & operatirules, technical infrastructure, and governance models for federated identity management and interoperability were formally incorporated in SEMIHIE’s organizational objectives in A2006.

SEMIHIE officially adopted the MI-DSTI GSA/HIMSS e-AuthenticationPilot in late summer of 2006. Prior to that timhad been working separately to develop use-cases and a technical frameworkproject. This adoption improved the ability of member organizations to collaborate on thand access resources. This collaboration among the mcritical 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 stepped up to fill the void. This technology was successfully tested by thusing a series of use-case scenarios (listed in the Appendix). This expericompleted 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 tothe ACES E-Gov Certificates and the Shinkuro-FireStar technology after the official end opilot program.

MI-DSTI e-AuthenticationPilot Project Participants

Project Managers • Helen L. Hill, Immediate Past President, Michigan Chapter of HIMSS; Chair SEMIHIE


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

mittee,

r, Healthcare IT, General Motors Corporation visor, University Bank

Bank nsumer Lending, University Bank

• Maurice Aljadah, Program Manager, Healthcare IT, General Motors Corporation

f Information Technology, IHA of Ann Arbor; now: Director,

arner, Manager, Information Security, Oakwood Healthcare System • Damien Payton, Lead Security Analyst, Information Security, Oakwood Healthcare

& eBusiness Development,

e Plan

are re

Local Registration Authorities • Maurice Aljadah,, Program Manage• Rebecca Dykes, Customer Service Super• Gina Cross, Customer Service Representative, University• Stacy Shepanski, Vice President, Deposits and Co

Participants

• 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 oTrinity 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 G

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

Corporate Security Officer, Health Alliance Plan • Jignesh Patel, Senior Technical Architect, Technology & eBusiness Development, Health

Allianc• 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 Healthc• Elaine Roach, President, Michigan Chapter of HIMSS; Vice President, ACS Healthca• Stephen Lange Ranzini, President and Chairman, University Bank • Rebecca Dykes, Customer Service Supervisor, University Bank • Gina Cross, Customer Service Representative, University Bank


• Stacy Shepanski, Vice President, Deposits and Consumer Lending, University Bank • Darnell Grant, Director of Information technology, University Bank

• Nick Fortson, Director and CEO, University Bank

ichigan n

• Steve Crocker, Founder and CEO, Shinkuro

ident, FireStar Software Software

examination and security that I certificates and services. These transactions would be

se in utilizing the ACES / E-Gov infrastructure.

r,

al, Financial and Governance. Over the course of Phase 1 of the pilot, the Use-Case and

ase Framework was supplied to the members of the Michigan ).

• Janet Anderson, Executive Vice President, Internal Audit and Human Resources, 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 M• Dan Lohrmann, Chief Information Security Officer, Michigan Department of Informatio

Technology

• Mark Zalewski, Partner, Shinkuro • Mark Feldman, IT Architect, Shinkuro • Mark Eisner, Chief Technical Officer, FireStar Software • Chris Sanders, Vice Pres• Jeffrey Dewhurst, FireStar • Jill Finnerty, Program Manager, FireStar Software

porated • Robert Skinner, Partner, NextUs Incor

fScope: The scope of our pilot project was to identibenefit from the added audit

y and demonstrate a range of transactions in healthcare that would significantly

ill derive from the use of ACES PKwimplemented 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 experti• Determine gaps, limitations and confusion in the distribution of certificates. • For end-users to understand that before a web-enabled, electronic transaction can occu

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, TechnicTechnical work groups became the primary focus of the participants.

Use-Case Framework: The Use-CGroup belonging to the Use-Case Work Group (UCWG) and the Technical Work Group (TWGThe UCWG identified three cases of interest, and the TWG established the topography forplacement 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.”


The Michigan Group defined the “end user” (doctor/nurse/pharmacist/payor/ambulance service dispatcher/emergency room physician/neurologist/banker/patient/administrative staff/researcher)

e

uantitative advance.

the session with integration into existing medical protocols.

he Michigan Group intended to use the Use-Case to document the sharing of data securely cross 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?

he Michigan Group organized the vetting process for the credentials to begin with a physical isitation with the designated LRA that provided for the presentation of photo identification sued by a federal or state government agency. The goal was to use the vetting process over the CES 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.

and noted that the credentials, accepted as a generic term, were distributed on a personal rolbasis 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 q

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

Ta

TvisA


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.


Ring-With-Tails Architecture Diagram

Jignesh PatelInsurer

!shinkuro.com

Sandra McKenziePhysician

[email protected]

Helen HillPatient

Hhill!shinkuro.com

EN-1

EN-10

EN-2

Patricia MooreAmbulance Service

[email protected]

Service Provider

Vimal ChowdhryNeurology [email protected]

Barb SaboEmergency Physician

[email protected]

Rick MooreImaging [email protected]

Rebecca DykesBank

Beeka!mercurymessage.net

Fahd HaddadPharmacist

[email protected]

EN-3

EN-9

EN-8 EN-7 EN-6

EN-5

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 secudigitally signed and encrypted data (including images) across a broad range of particip

re, ants in

y

data-sharing technology, among the parties as planned. (See

s, a pharmacy such as the HFHS

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 monedebited 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 secureAppendix 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 instancePharmacy 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 UseCase Forms.)


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

s.)

e forms the group used were actual healthcare ocuments modified for use in the testing. Due to time limitations, no special applications were reated 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

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 Form

Although there were a few initial setup issues, thdc



doc FHS Pha ed for foll

The patient received notifications from the University Bank for authorization of payment from all t account. The Patpick

umentation of care provided to the patient from Oakwood ER, HFHS Neurology, Hrmacy and the Ohio Imaging Center; reviewed and filed the documentation and arrangow-up.

he billing parties and approved the payments from her HSA direct depositient received notification from the HFHS Pharmacy that her prescriptions were ready for up and notification of the required co-pays.

[Note: Groupwise 6.5 posed several as yet unresolved issues related to processing certificates: recognizing valid certificates, signing and encrypting messages with the

Community Health Information Collaborative (CHIC) health

ations, contributing to the continuum of patient care.” As

as viewed

n-on objective.

ed earchers at the

ject the VisionShare SA, so we will be

ding researchers at The Ohio is an initiative to develop an

m

a person using a web browser

ith and allows users to determine whether to release

additional information about themselves. An “open solution” means:

e; and

authorized providers a complete picture of eir 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:

certificate.]

Minnesota—Project Overview: The overall CHIC-RHIO vision is “to facilitate the sharing ofinformation across all organizpart 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 a proof-of-concept that federated identity management and digital certificates could bea viable solution to the single sig

CHIC retained a Minnesota-based company, VisionShare Inc., to develop a federatidentity management system. VisionShare, in turn, collaborated with resUniversity of Minnesota to build a test-bed system based on software recently developed by the Internet2/GRID community. During the course of this proprinciples involved in this project formed a new company, MEDNET Ureferring to this new company in this report.

This software, called “Shibboleth”, was developed by leaState University and Georgetown University. Shibbolethopen, 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 fromember schools and corporate partners.

The purpose of the exchange is typically to determine if(e.g., Internet Explorer, Netscape Navigator, Mozilla) has the permissions to access aresource 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 wthis information, not with an identity,

• An open architectur• 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 th

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

hibboleth software used was initially developed for university environments. This is one of the first implementation of Shibboleth in healthcare.

ing to note that the CHIC community quickly understood the sharing of

Web

s

on le

S

It is interestidentity 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 singlesite for authentication.

• This authentication will be used to authorize physician/provider access to variouElectronic Medical Record (EMR) systems.

• The physician/provider will demonstrate the ability to look up patient information these systems without additional logins to demonstrate the capability of singsign-on. (Phase II)


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

portant to walk through and test the

e

save

Registration Authorities (LRAs) by ORC. It was improcess 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-linregistration 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 theIssues 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 totime and minimize points of confusion. Examples include:


• Automating the installation of four certificates to trust the ORC ACES CertificAuthorities.

• Allowing special characters in the entered information for the online app(e.g., a c

ate

lication olon [:] is not acceptable).

erstand its purpose and follow the steps completely.

blems arose, was hard to reach

tes

ere

ns’ screen

to replace our test servers with the hospitals’ test Citrix

h with ment.

ith the hospital. The MSO

rder 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

• Formatting or streamlining the pop-up window instructions to ensure the users und

We discovered, also, that the support structure, when proand resolution was slow.

Use of Certificates. The initial installation and testing were done with test certificaissued 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 wreceived, 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 ‘Congratulatioupon 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 issystems 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 witdifferent EHR systems implemented. We believe that lessons learned in the phaseadvance our vision of single sign-on capability to physicians in our RHIO environ

Nevada—Single Portal Medical Record A hospital emergency room desires access to patient information from patients associated with an MSO (Managed Service Organization) associated wmanages 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 insurancecompanies in o


the primary care physician’s patient visit records and related clinical information are

rts, incentives and requirements have been advanced ong research efforts. While

interchange of information among the nity (such as the NCI caBIG effort), a standard approach for individual

munities has yet to be established.

, this project has focused on evaluating the viability of using the s as a means of authenticating

ges

view ling improved

adherence to regulatory requirements imposed by HIPAA.

archers for research data of emerging data interchanges.

in the pilot has been to evaluate the process for design opment, intended to be compatible by the research community (e.g.

systems developed at OSC for the Ohio BioRepository and for the Human Services Office for

tform technology for e viability of the certificates, with design and procedure implications being

ollaborative systems involving microarray and clinical health

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 newtreatment 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 effoto encourage sharing information collaboratively aminfrastructure is being developed to facilitateresearch commuauthentication that transcends clinical and research com

Background. Initiated by eHealth Ohio, and in conjunction with the Ohio Supercomputer Centerproposed national level user authentication procesindividual 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 bridthe 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 ReBoard) protocols involving patient information, while simultaneously enab

Use-case. Authentication of rese

Project Approach. The approachand logistical implications for future systems in devel

ith emerging data interchange requirements imposedwcaBIG). Current telehealth research funded by the Department of Health andhe Advancement of Telehealth provided the prototype plat

evaluating thincorporated into development plans for target cntegration of biospecimen, virtual microscopy,i

information.


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—eHealthOhio—OSC Bioinformatics include representatives from the Ohio Department of Job aFamily 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 strategicroadmap for the adoption of HIT and the Health Information Security and Privacy

nd

needed of the Nationwide Health Information Network and the Regional Health

ants from eHealth Ohio

n, Senior Counsel

ting an operational statewide fiber optic backbone network as well as production loration of new computing paradigms

information technology,

e Miller Lead developer, Ohio BioRepository Initiative

cer BioInformatics Group (C3BIG) of Columbus

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 securityfor the success Information Organizations in Ohio.

ParticipRichard Moore Ohio—eHealth Ohio—OSC Bioinformatics–President Co-Project Leader and Local Registration Authority for digital certificates Nancy P. Gillette, JD Ohio State Medical AssociatioOhio—eHealth Ohio—OSC Bioinformatics–Treasurer, Pilot Project LRA Notary Public Ohio Supercomputer Center. OSC provides a reliable high-performance computing andhigh performance communications infrastructure for a diverse statewide/regional community including education, academic research, industry and state government. Suppordata and computational facilities, OSC enables expand approaches in such key areas as industrial computing, healthand data management, mining and visualization. Working as a collaborative partner, OSCboth 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 Jo

Columbus Children’s Research Institute. The Center for Childhood Can


Children’s Research Institute, under the direction of Dr. Stephen J. Qualman, is a BioInformatics application development team dedicated to increasing cure rates and

nter: molecular genetics, core

development efforts also extend outside the ups. These groups

al Technology Specialist—Center for Childhood Cancer Bioinformatics Group

l expectations of the pilot evolved over the en invaluable as a means to clarify logistics and

ompleting the

RA and

decreasing side effects in therapy through Information Technology. Development efforts are focused on these key disciplines within the cemorphology, histology, the biospecimen repository, functional genomics and specificpediatric cancer research initiatives. Our walls of Children’s Research Institute to those of the Cooperative Grore the Children’s Oncology Group (COG), the Gynecologic Oncology Group (GOG), a

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

Medic

Results and Conclusions. While originaperiod, the HIMSS pilot project has provprocedures 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 cauthentication procedure.

• Scheduling logistics for the necessary face-to-face meeting between the Lindividuals 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.


• Establish and maintain a current central registry of qualified Local RegistraAuthorities among the participating organizations.

• Cross-certify LRA among projects to aid the registration of remote collaborators not conveniently within dr

tion

iving distance.

n certification.

ators o

tronic health records, billing, scheduling, electronic r

usiness 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

• Develop authentication instructions tailored for different individual levels of expertise.

• Consider methods for remote video registratio 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 collaboraccessing the prototype. Technical learnings from the certificate pilot will be used tguide 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.

Ohio—Virtual Medical Network Background. Virtual Medical Network (VMN) is a turnkey enterprise solution for practice management, elecprescribing, and transcription (dictated files are returned as either key value paired data oas 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.

B


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).

MN plans to test the certificates utilizing Dr. Kolp’s certificate as the “sending” party

Vand 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).


Due to the schedule delay resulting from IIS5 incompatibility, the scope for the purpose

encompasses authentication of the recipient’s

,

of this white paper was contracted, but still certificate (endpoint at completion of Step 12). Verification of download (Steps 13-16) will be performed post-publication of this white paper.

VMN was able to successfully complete Steps 1-12.

Secure Data Exchange. Ultimately, it may be prudent to use a server SSL certificate provided by the same CA that provided the user certificates. For the purpose of our pilot, however, VMN is utilizing our existing server SSL certificates provided by NetworkSolutions in conjunction with the user certificates provided by the GSA vendor.

Moving Forward. VMN’s first priority is to complete the original test scope outlined above and confirm interoperability between RHIOs. As background to further discussionthe following diagram shows the flow of data with certificate use as we understand it.


In-NetworkPhysician

`

VMN

Ex-NetworkPhysician

Other Web Server

ACES Certificate Server

1 2

3

4

5

6

7

9

8

The critical drawback to this schema is that the certificates are resident files on a specific

iece of equipment or hardware-based storage device. That means that in order for an authenticating server to process the certificate, the request must either be made from the

tificate file in some s

a

p

same physical piece of equipment or the physician must carry the cermanner as to make it portable (e.g., CD, flash drive) and compatible with all types of PCor laptops that might be used for the access request. While perfectly acceptable for physicians operating in a single-location family practice, it becomes somewhat cumbersome for physicians with multiple office sites and/or multiple hospital privileges, let alone hospital ER, surgical settings or disaster relief sites. Standardization becomessignificant issue. For instance, do the doctors use flash drives? What if the hospital PCs don’t have USB ports? Should they use pocket PCs? What if there’s no cable available? Or, no IR port? Is there a risk that the file could be inadvertently copied onto a borrowed hard drive, thus compromising the security of the certificate? This is a significant risk, since the certificates must be imported into the client machine’s operating system to be used.

Moving forward, our plans are to refine internal protocols and standards for data transmission between RHIOs, potentially utilizing Shibboleth. The schema below depicts the proposed “to be” process.


VMN’s position is that this anticipated methodology is dependent on the development of robust, standardized directory schema for use by the Shibboleth club members.

orpus Christi—Coastal Bend Health eCities Project roject Overview. In 2005, The City of Corpus Christi, Texas and CHRISTUS Spohn iscussed ways to improve emergency treatment by first responders. The city operates the mbulance service through its fire department and CHRISTUS Spohn Memorial Hospital the regional trauma center. Corpus Christi had just completed installing a wireless frastructure in the first neighborhood for what is now a 150-square-mile, municipal-ide wireless mesh. The initial solution was to allow the paramedics to access HRISTUS Spohn’s MEDITECH electronic medical record while they were in the field.

ith national and state efforts for regional health information organizations gaining omentum, an alternate approach was deployed. A new healthcare database would be

reated that would connect to the City’s 911 emergency dispatch system. The paramedics ould access the health data in the field, once they identified the individual. The aramedics then send their data to the hospital via the wireless network, including 12 lead KG readings. This results in improved care safety, quality and outcomes.

ted to participate including city and ounty health departments.

a

CPdaisinwC

WmcwpE

All health care providers in the region were invic


Individual participation in the health eCities data bank is voluntary. The result is a community sponsored personal health record maintained by the individual and accessible for first responders to use when emergency care is required.

Background on RHIO/HIE. The Health eCities initiative began with the very practical focus of getting health information into the hands of the first responders for use in medical emergencies. While the initial proof of concept was limited to one hospital it was designed to be all inclusive. All providers including solo physicians, all the hospitals, the public health clinic, the family medicine residency program, mental health providers and more were included in discussions on.

Business Problem. Phase I of the digital cities project requires the paramedics to gain access to a secure database that houses personal health information. The database is populated by multiple sources using a private grid and node system that is not detectable by the Internet unless one is a participating node.

Phase II of the project expands the access to the database to any health care provider participating in the Corpus Christi—Coastal Bend Health Alliance, a coalition that provides care to the uninsured.

While the paramedics are a limited entity (79) a secure method for authenticating each paramedic to the system is required. The paramedics will use laptops mounted in the mbulance for accessing personal health information. The health eCities project desired explore the GSA e-Authentication method to determine if it could successful provide a usted, strong authentication method for use by the paramedics. Once proven, this

method could also be used for authentication for phase II.

Visualization of Phase I of the Project

atotr


Corpus Christi Health eCity ProjectStep 1: Health Record Summary (PHR)

Meditech

“Vial of Life”Repository

EHR

PHR

- Person registers (self or Community Health Worker (CHW)- PHR created (CCR)- PHR distributed to key locations

12

Physician Offices- View - Insert into EHR- Use for referrals

3

- Registration, - Pre-surgical, etc.

Hospital - ED,

3

If PHR is updated at any location…All copies are automatically synchronized

Private, Structured, andSecure

Firewall

Firewall Fire

wall

Fire

wall

PHR

PHR PHR

Corpus Christi Health eCity ProjectStep 2: Paramedic Receives Call and Searches Repository for PHR

“Vial o f Life”Repository

Paramedic logs in and searches “Vial of Life”Repository for PHR If found, data pushed

into SafetyPad device.

12

FirewallIf not found, data entered into SafetyPaddevice.

Authentication - User name / password- ACES certificate w/ card


Corpus Christi Health eCITY ProjectStep 3: EMS Report Completion, Upload, and Distribution

EMS Report completed and uploaded to Safety Pad server

SafetyPadDB

EMS Report pushed to Novo

EMSReport

EMSReport

Firewall

Firewall

EMS Report available in hospital

Fire

wall

EMS Report pushed to PCP and/or other physicians

EMSReport

xE perience Using GSA Services Registration of Certificates. Three persons were identified who wereLocal Registration Authorities (LRAs). One individual successfully c

willing to act as ompleted the

ring the paramedics. The

occur.

led the bits the d that

nge occurring once certificates are issued.

s at the scene ser

it trails by users are occurring. We will evaluate methods to accomplish this including the use of tokens.

registration process. The LRA would be the agent for registecommander and co-commander agreed to be the pilot subjects to test the registration process and to test the system. These registrations have yet to

Use of Certificates. During the registration process we learned that the City instalare the paramedics use on a server being used by the FBI. FBI prosoftw tocol prohi

addition of any other applications to the server. This situation required a workarounr h ited the use of certifp o ib icates until this issue could be resolved. A workaround has

been identified and is being implemented.

Secure Data Exchange. Due to the above mentioned reasons data exchange has yet to occur as related to the original intent of this pilot project.

Moving Forward. With the application issue resolved all certificates were issued with testing of both certificate use and data excha

One issue to be addressed is that a limited number of laptops will be used by the paramedics and due to their shifts and staffing of each ambulance, more than one paramedic will need to use the laptop. During an emergency all paramedicwill have rights to the same machine at the same time. We need to differentiate the ufrom the machine and assure that aud


Project Conclusions Overall Summary. The project met its objectives of having the RHIOs and HIEleverage the common authentication infrastru

s cture provided by the GSAs e-

iple

ent are viable for larger

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.

verall Lessons Learned. There were quite a few lessons learned:

• Enrollment is the most difficult part of deployment. • The biggest challenge is to ensure a smooth and manageable enrollment process is

applicable for the healthcare setting and practitioner. • Policies and procedures need to be streamlined for the healthcare setting

regarding the enrollment process using the ACES certificates. • Once certificate enrollment is completed and issued they functioned in the

expected manner. • Establishing an overall enrollment strategy and process took considerable time to

formulate and implement thus pushing out the project time line. • Each RHIO and IHE must identify a risk assessment process for the sensitivity of

the data being exchanged. • A trusted authentication process can be established across multiple RHIOs and

HIEs using the ACES Bridge.

verall Recommendations. We recommend that RHIOs and HIEs consider leveraging e GSAs e-Authentication service as the participants did in this project.

• The technical solution is available to ensure strong authentication to protect personal health information.

Authentication Service Component.

• Multiple RHIOs can agree and implement a common framework for the policies, procedures, and standards for federated identity authentication across multuse-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 enrollmscale deployments to provide for strong authentication using federal e-

O

Oth


• Additional pilot projects testing this technology should continue and should be permitted by the GSA using the ACES Federal Bridge eAuthentication technology with RHIO’s and HIE’s.

• Federally approved service providers are available on GSA schedules. New to be added to contract on GSA IT Schedule 70.

• An expanded RHIO demonstration project population should be supported to implement a common framework for the policies, procedures and standards foridentity authentication across multiple use-cases.

• The development and standardization of local enrollment procedures and development of a standard scheduling tool are critical for large-scale project deployment.

providers need• Expand functionality and scope to include first responders and emergency

response providers in coordination with the U.S. Department of Homeland Security.

• Establish a governance structure for decision-making.


Appendix

PKI to protect confidential information; Public Key Cryptography is

s. Public Key Cryptography uses a key pair to encipher and decipher mation, the owner of a key pair makes one of

way, anyone wanting to communicate securely with the key pair wner can encode the information with the public key. Only the corresponding key can

What is a PKI? that formalize the use of

to bind people or devices to a trustworthy online identity. This

e RA is tasked with properly identifying e

The

s that ontrol the trusted third-party actions in binding a key pair to a trustworthy online

ganization employee

There are many waysone of these wayinformation. To code or encrypt the inforthe keys public. This odecipher or decrypt the data. It’s important that this key be kept private and secret.

A PKI, is the combination of policies, practices, and procedurespublic key cryptographybinding is done through an artifact product known as a digital certificate.

Once the key pair is generated, the public key is submitted to a Certificate Authority (CA) through a Registration Authority (RA). Ththe holder of the public key and making sure that the person or device presenting thpublic key is also the holder of the private key. Once that can be positively determined, the RA tells the CA to issue a digital certificate for the party presenting the key pair. CA then issues a digital certificate to the holder of the private key. A digital certificate is a small file containing the public key and other identifying information about the holder, such as the actual name and email address for personal certificates, or the hostname for SSL certificates for servers. The CA then digitally signs the file with its private key to give the digital certificate data integrity or appropriate authority.

All of these tasks are controlled by the PKI—the policies, practices, and procedurecidentity.

Healthcare PKI In accordance with International Health Informatics Security Standards, a healthcare PKI not only attests to the binding of the individual identity with the digital certificate, it also asserts the healthcare regulator credentials associated with that individual’s healthcare identity. The ISO standard asserts the following identity types:

Persons: • Regulated health professional • Non-regulated health professional • Patient/consumer • Sponsored healthcare provider • Supporting or

Organizations: • Healthcare organization


• Supporting organization

Other Entities: • Devices • Regulated medical devices • Applications

Each of these identities may require a digital certificate issued by the PKI to enable secure health related communications.

What applications/services does PKI enable? Key features of a PKI:

• Confidentiality of Personal Health Information. It is possible to encrypt files/messages with a public key such that only the associated private key candecrypt the message;

• Au

thentication. A public key properly bound to an online identity makes it

state that it was in at the moment that it was signed, or the

based health professionals for mote clinical information systems.

s by applications used within provider information systems such as

ich require a reliable binding between an image and

ol

from a particular health professional (origin authentication), is being filled for the correct patient., and ensuring there are no errors in transmission.

• Digitally signed patient consents.

possible for that online identity to access secure sites; • Nonrepudiation. By digitally signing, based on a valid digital certificate and

corresponding private key, nonrepudiation asserts that the “signer cannot deny having signed”; and

• Data Integrity. A digitally signed document/object/etc. cannot be altered in any way from thevalidation system will indicate that the digital signature is invalid because theunderlying document has been altered and it cannot reasonably be trusted.

Within healthcare, these capabilities enable such applications as:

• Secure e-mail. • Access requests by applications used by community

patient information in re• Access request

patient administration, clinical management, pathology, radiology, dietary and other related clinical support system systems.

• Billing applications, which require non-repudiation, message integrity, confidentiality and authentication of patients, health service providers and health insurers, and support for fraud prevention.

• Telemedicine applications, wha patient identity, as well as authentication of the health professional.

• Verification of authenticity, confidentiality and integrity for remote access contrapplications.

• Electronic prescription, and other clinical orders verified as having originated


• Transcription validation.

Using digital certificates? Certificates and keys can be used to keep personal health information in many formi.e., e-mail messages, documents and files confidential. Privacy and security regulations, such as HIPAA and Gramm-L

ats

each-Bliley, have made it desirable for system users to use

consent forms, health

ridge CA Model1. Most PKI sales have been to individual enterprises; thus, each rganization can end up with a separate Certification Authority (CA). To enable a mmunity of interest to protect shared data, however, in order to meet new federal

overnment requirements for data security and privacy in healthcare and finance, PKI can e leveraged across organizational boundaries. This raises the issue of cross-rtification—i.e., how different CAs relate to each other.

hree Methods he Hierarchy Model. There are three possible ways in which CAs can be cross-certified: e hierarchy approach, the mesh approach and the bridge approach. In a hierarchical ttern, trust cascades downward from the highest CA. But it’s not always easy to decide

n which CA deserves to be at the top. For example, how secure is the CA? How up-to-ate are its Certificate Revocation Lists (CRLs)? In other words, why does one particular A deserve to be the source of trust?

he Mesh Model. The second approach, the mesh model, is a peering arrangement; each ir of CAs establishes a cross-certification. This works fine, as long as the number of

As is limited—somewhere around six. But, as the number of CAs grows, the number of quired cross-certifications also grows, and exponentially. For example, three CAs need

encryption to securely store and to securely transmit health information across the Internet. Certificates and keys facilitate encryption and therefore compliance with rules regarding the non-disclosure of confidential data.

Certificates and keys can be used to digitally sign emails, and with xtendable mark uplanguage (XML) it will become possible to digitally sign electronicrecord transfers, and a host of other frequently recurring transactions that require authorization. Interconnecting the Healthcare Enterprise (IHE), also co-sponsored by HIMSS, to enable accountability and data integrity in shared document systems has developed suggested standards for digitally signed consent forms for the healthcare industry.

Because identity and regulatory healthcare affiliation can be verified through digital certificates, it is also possible to secure Web sites for certificate-based access. A visitor to the site presents his or her certificate and, if a seamless technical handshake reveals that this person/device also holds the private key associated with the public key in the certificate presented, and assuming the person has rights to access the site, they then gain entry in to the site.

Bocogbce

TTthpaodC

TpaCre

an article written for Business Communications Review, 12/2002, by Project Leader Pete Palmer. 1 Excerpt from


only three cross-certs, but eight CAs require 56, and 12 CAs need 132 cross-certs. Oh, l issue.

Canadian among the early participants in the Federal Bridge Certification

stems

link

a trusted third party, an agency that ral, state or local agency to conduct an

now that the certificate can be trusted.

KI, different PKI domains, using cts and different X.500 directories, were successfully cross-certified.

n X.500 directory framework with chaining between directories and ing LDAP (Lightweight Directory Access Protocol). For more the FBCA, visit www.cio.gov/fpkisc

and 300 CAs need 44,850. In short, scaling is a non-trivia

The Bridge Model. The bridge model comes out of work done to cross-certify government organizations, Half a dozen federal agencies, two states and thegovernment wereAuthority (FBCA), a project in which a number of PKI vendors and MitreTek, a syintegrator, played key roles.

The FBCA was conceptualized as a PKI hub that would provide an efficient way to agencies’ CAs, which were originally designed for intra-agency applications. By cross-certifying CAs through the FBCA, which acts asneeds to accept a certificate from another fedeelectronic transaction will k

In one test, as shown in Fig. 6: The U.S. Federal Pdifferent CA produ

s aThe FBCA useclient access usinformation on or www.csrc.nist.gov/pki.

model holds the promise of overcoming the technical problems inherent in the thods when it comes to securing communications beyond one organization. amework also includes guidelines for resolving issues of policy

patibility, e.g., on how participating CAs should keep their directories secure and up , the bridge CA approach has been proven, which should help give PKI a

oing forward.

The FBCA other two me

he FBCA frTcomto date. In shortbetter reputation g


Acknowledgements Project Lead: Pete Palmer, HIMSS Minnesota Chapter

emoshok, SA Program Analyst, USA Services, Intergovernmental Solutions Office of itizens Services and Communications Office, Marc Wine IMSS Staff: Mary Griskewicz MS, FHIMSS, Director, Ambulatory Information ystems

HIMSS Liaison: Jill Redenius, Coordinator

elen Hill

GSA Director, Identity Policy and Management, David TGCHS

Regional Managers:

onnecticut CLori Fourquet

Michigan HMick Talley

Minnesota Cheryl Stephens Melinda Machones John Fraser

Southern Ohio Chuck Hutzky Bridgette Hackman Rick Powell

Central Ohio Richard Moore Eric Stahlberg

Texas Hank Fanberg

Nevada Donald Young


Vendor Contributions NOVELL AET Europe: Reinoud Weijman, Mira van Houten, and Ben JianJuniper Networks: Michael Bowles, Jay Maciorowski, and Willi

g am Huckman.

ns and

ISO IS17090 part1,2,3 Health informatics—Public key infrastructure

ISO TS26000 part1,2 Health informatics - Privilege management and Access Control

1298 Health informatics: Functional and Structural Roles

ation

d Specification for Authentication of Healthcare Information Using

ard Practice for Healthcare Certificate Policy

Contractors

Edge PIV

Certificate Policy

IHE Audit Trail and Node Authentication Profile (ATNA)

References ISO TS21091 Health informatics—Directory services for security, communicatioidentification of professionals and patients

ISO DTS2 ASTM E1986 Standard Guide for Information Access Privileges to Health Information

ASTM E1762 Standard Guide for Electronic Authentication of Health Care Inform

ASTM E2084 StandarDigital Signatures

ASTM E2212-02a Stand

FIPS 201: Personal ID Verification of Federal Employees &

SP 800-63 Recommendation for E-Authentication

SP 800-73: Interfaces for PIV (including Smart Cards) Card

OMB M-04-04 FBCA

FBCA Common Commerce Certificate Policy

FBCA Cross-Certification Requirements

FBCA Trust List

Credential Assessment Framework

e-AuthenticationTrusted CSP List

EAI Federation Business and Operating Rules and Participant Agreement


IHE Document Digital Signature (DSG)

IHE Cross-Enterprise User Authentication (XUA)

Liberty Alliance ID-FF 1.2 The Identity Federation Framework

ework

astructure Certificate and CRL Profile

RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol –

ctory Access Protocol (v3): Technical Specification

X.509 Public Key Infrastructure Operational Protocols—

Public Key Infrastructure Certificate Policy and Certification ractices Framework

FC 3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 ertificate Handling.

FC 3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 essage Specification.

FC 2634 Enhanced Security Services for S/MIME O/IEC 9594-8 Information technology - Open Systems Interconnection - The irectory: Public-key and attribute certificate frameworks

ANSI X9.30 Part 1: Public Key Cryptography for the Financial Services Industry - Part (DSA) (technically aligned with NIST FIPS PUB

186)

ic Key Cryptography for the Financial Services Industry - Part

nt for DSA ures Using Reversible Public Key Cryptography for the

Industry (rDSA) (technically aligned with ISO/IEC 9796)

ANSI X9.45: Enhanced Management Controls Using Digital Signatures and Attribute

ncryption Algorithm Modes of Operation

Liberty Alliance ID-WSF 2.0 Web Services Fram

Liberty Alliance ID-WSF ID-SIS A collection of Identity Services Interface Specifications

XaDES XML Advanced Electronic Signatures

XML-Dsig Signature Syntax and Processing

X.500 The CCITT and ISO standard for electronic directory services

RFC 3280 Internet X.509 Public Key Infr

OCSP

RFC 3377 Lightweight Dire

RFC 2259 Internet LDAPv2 RFC 3647 Internet X.509P

RC

RM

RISD

1: The Digital Signature Algorithm

ANSI X9.30 Part 2: Publ2: The Secure Hash Algorithm (SHA-1)

ANSI X9.30 Part 3: Certificate ManagemeANSI X9.31 Digital SignatFinancial Services

Certificates

ANSI X9.52: Triple Data E


FIPS 140–2 Security ReInformation Processing Standards P

quirements for Cryptographic Modules. FIPS 140 (Federal ublication 140) is a United States federal standard

hy modules

Password Usage

ash Standard (SHS)

IPS PUB 181: Secure Hash Standard, 1994 (technically aligned with ANSI X9.30–1)

FIPS PUB 186-2: Digital Signature Standard (technically aligned with ANSI X9.30–1)

FIPS PUB 190: Guideline for Use of Advanced Authentication Technology Alternatives

FIPS PUB 74: Guidelines for Implementing and Using the NBS Data Encryption Standard

FIPS PUB 81: DES Modes of Operation

Web site References http://idmanagement.gov

that specifies security requirements for cryptograp

FIPS PUB 112

FIPS PUB 180–2 Secure H

F

http://cio.gov/eauthentication http://.cio.gov/ficc http://cio.gov/fpkipa http://csrc.nist.gov/piv-project/ http://eapartnership.org

For Additional Information

David Temoshok

Director, Identity Policy and Management 202-208-7655 [email protected]

Pete Palmer

HIMSS Special Project Work Group Lead 612-598-4444 [email protected]



32BMary Griskewicz

77BDirector, Ambulatory Information Systems 203-421-8317 [email protected]

Health & Medicine

HIMSS GSA e-Authentication whitepaper June 2007