HIMSS GSA e-Authentication whitepaper June 2007
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

HIMSS GSA e-Authentication whitepaper June 2007

on

  • 511 views

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 across multiple healthcare ...

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

Seven RHIOs/Health Information Exchanges initially volunteered to participate in the project. One participant the Nevada Single Portal Medical Record HIE had to withdraw from the project due to a lack of resources.

Central Ohio HIE - Initiated by eHealth Ohio, and in conjunction with the Ohio Supercomputer Center, this project has focused on evaluating the viability of using the proposed national level user authentication process as a means of authenticating individual researchers, system developers and system administrators who will be both utilizing, creating and maintaining future health care research systems. An emerging area of software development focus, this pilot will also identify key issues faced by resource constrained development efforts.

Statistics

Views

Total Views
511
Views on SlideShare
511
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

HIMSS GSA e-Authentication whitepaper June 2007 Document Transcript

  • 1. HIMSS/GSA National e-Authentication Project Whitepaper June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 1
  • 2. Table of Contents Executive Summary Background Problem Statement Security and Privacy Concepts and Technologies AAA—General Information Technology Security Framework Trust Model Authentication Systems Authentication Factors Credential Service Providers The GSA e-Authentication Service Component The ACES Program ACES and Presidential Directive IHE Interest 3 5 5 5 6 7 12 13 13 13 16 16 17 RHIO Project Overviews Connecticut—Connecticut Regional Health Information Organization Michigan—Michigan Data Sharing & Transaction Infrastructure Project Minnesota—Community Health Information Collaborative (CHIC) Nevada—Single Portal Medical Record Ohio—Ohio Supercomputer Bioinformatics Ohio—Virtual Medical Network Corpus Christi—Coastal Bend Health eCities Project 18 25 37 40 41 44 48 Project Conclusions Appendix Acknowledgements References 52 54 58 59 June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 2
  • 3. 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 June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 3
  • 4. 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 June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 4
  • 5. 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. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 5
  • 6. 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.. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 6
  • 7. Federal Trust Model for Federated Identity 1. Establish & define authentication risk and assurance levels • OMB M-04-04 - Established and defined 4 authentication assurance levels as Governmentwide policy • FBCA Certificate Policy - Established 4 authentication assurance levels for Federal PKI domains 2. Establish technical standards & requirements for e-Authentication systems at each assurance level • NIST Special Pub 800-63 Recommendation for EAuthentication – Established authentication process & technical standards at 4 established assurance levels • FBCA Common, Commerce Certificate Policies – Established PKI-specific standards and requirements. 3. Establish methodology for evaluating authentication systems at each assurance level • Credential Assessment Framework – Standard methodology for assessing authentication systems of credential service providers. • FBCA Cross-Certification Requirements – Standard methodology for policy mapping, audit, and testing interoperability for cross-certification with the FBCA. 5. Perform assessments and maintain trust list of trusted CSPs • E-Authentication Trusted CSP List – CAF, boarding & Interoperability testing • FBCA Trust List --tests for policy mapping,, audit compliance, cross-certification & directory interoperability 6. Establish common business and operating rules for participants • EAI Federation Business and Operating Rules and Participant Agreements • MOA with Federal PKI Policy Authority Fig. 1: Standards for the Federal Trust Model. In the realm of security, there is often contention between trustworthiness and ease-of-use. The ultimate trust model would be to deny everyone access to everything. Of course, this would render data and applications worthless. The ultimate ease-of-use would be to grant everyone access to everything—obviously unacceptable in most realms, but particularly unacceptable for health information. This means that processes need to be established to identify the sensitivity level of information so the right security controls can be put into place. For example, an application that allows you to look up your child’s grades on his or her school’s Web site would probably have a different sensitivity level than, say, an application that allows you to see the Pentagon’s war plans. In healthcare, we expect that access to records from within an organization would have a different sensitivity level than access from a location not under the organization’s control in order to protect and secure patient health information. When developing their infrastructure, the federal government understood that supporting a set of security standards for technical, policy and process would be required to meet the needs of the various agencies. Certain risk factors must be evaluated in the development of a security system (policy, procedure, technology). The following subsections describe risk assessments, assurance levels and credential types, as well as how the GSA used them to develop their security standards. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 7
  • 8. Risk Assessments. To properly identify the security requirements for an application or data, a risk assessment must be performed. Just as the term implies, the goal to discover what is at risk if access is granted to the wrong individual or system. For example, upon completing a risk assessment, the Social Security Administration may have determined that there is little risk with an application that shows what a citizen’s monthly benefits will be in the year 2061. There is a requirement to be somewhat assured that people looking up this information are who they say they are, but only minor damage would be done to the citizen and the reputation of the agency if that information fell into the wrong hands. On the other hand, the Department of Labor may determine from a risk assessment of their payroll system that there is significant risk of fraud or financial loss if the wrong person accesses their system. For health information that involves patient data, there are legal, ethical and financial risks associated with the loss of privacy. Assurance Levels. Once the degree of risk has been determined, an assurance level needs to be identified that most appropriately addresses risk. Again, as the term implies, you need to identify how “assured” you need to be of the identity of the individual or system trying get your data or use your application. The federal government came up with four “levels” of assurance: • • • • Level 1. Not assured that users are who they claim to be. Level 2. Somewhat assured that users are who they claim to be. Level 3. Very assured that users are who they claim to be. Level 4. Absolutely assured that users are who they claim to be. Fig. 2 shows the standard assurance levels for electronic authentication established by the Office of Management and Budget, and supported by the GSA’s e-Authentication Service component used in this project. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 8
  • 9. OMB E-Authentication Guidance Establishes Four Assurance Levels for Consistent Application of E- Level 1 Level 2 Level 3 Level 4 Little or no confiden ce in asserted Some confiden ce in asserted identity High confidenc e in asserted identity Very high confiden ce in the asserted identity Fig. 21: OMB assurance level guidance. Credential Types. A “credential” in this system is something that is asserted to represent the identity of a user or a system. We are all familiar with usernames and passwords, ATM cards and PINs and so on. These are examples of credentials, and figuring out which one is the right one required for your needs is the next step in developing your security solution. Once your organization has determined the risk associated with data or applications and have identified the assurance level needed to address the risk, you need to determine which credential type provides that “level” of assurance. If the system processes patient health information, a High Confidence in the Asserted Identity is recommended, which the Office of Management and Budget (OMB) identifies as a Level 3. Username and password authentication requirements would not provide High Confidence. However digital certificates issued using a strong policy probably would provide high confidence. The OMB and the National Institute for Standards and Technology (NIST) provide standards for pairing up certain credential types with assurance levels. Fig. 31 extends the Assurance Level Guidance to include associated credentials. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 9
  • 10. E-RA tool assists agencies in defining authentication requirements & mapping them to the appropriate assurance level NIST SP800-63 Electronic Authentication technical guidance matches technology to each assurance level OMB E-Authentication Guidance establishes Four Assurance Levels for Consistent Application of E- Level 1 Level 2 Level 3 Level 4 Little or no confiden ce in asserted Some confiden ce in asserted identity PIN/P High confiden ce in asserted identity - Very high confiden ce in the asserted identity Fig. 31: Assurance levels and credential types. This system of standard approaches and methodologies is at the heart of the interoperability of the security infrastructure. Figure 4 further illustrates the approach in the context of the healthcare domain: -Factor Token Multi Increased $ Cost PKI/ Digital Signature -Based Knowledge Very High Strong Password PIN/User ID High Medium Low Access to Protected Web site Applying for a Loan Online Obtaining Govt. Benefits Employee Screening for a High Risk Job Increased Need for Identity Assurance Fig. 4: Risk levels, assurance levels and credential types. Fig. 5: Risk levels, assurance levels and credential types as applied to health-related risks. Authentication Systems Electronic authentication systems need to be able to accept and validate an identity assertion. The most common credential is a username and password on a personal computer. A user’s June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 10
  • 11. identity assertion is his or her claim that he or she is the person who is associated with, or owns, the username. This is proved by supplying a secret password that only the user and the user’s computer acknowledge. The computer validates the user’s identity by comparing the password supplied with the expected password. If a positive match is found, the user is granted access to the system. If not, the user is denied access. Authentication Factors There are three generally accepted authentication factors: single factor, two factor, and three factor. • • • Single factor. Something you know, such as a password or the answer to a question, such as your mother’s maiden name. Two factor. Something you are in possession of, like a smart card, in addition to something you know. Three factor. Something you are, like a fingerprint, retinal scan or DNA, in addition to something you know and something you are in possession of. Credential Service Providers Credentials are only as valid as the procedures used when issuing them. Examples of credentials include a valid passport, driver’s license or a personalized, wallet-sized photo-ID issued by a state agency or an employer. Hospitals may issue every employee a photo-ID name badge that must be worn while on duty. However, your work ID would most likely not be acceptable by a merchant when you are cashing a check or when you are proving your age to get into a bar. Why? Because the merchant or bouncer has no idea what procedures were used by the card’s issuer, such as requiring the applicant to show a birth certificate, passport or Social Security card. They also have no idea if the work ID is real or fake. However, they do trust a state-issued driver’s license because they trust that sound verification procedures were used when it was issued. Credential service providers take on the important role of issuing and managing credentials for both people and machines. In healthcare, regulated practitioners are credentialed by the state licensing process which is further verified and validated by provider organizations before enabling practicing privileges at their locations. The GSA e-Authentication Service Component The following definition of the GSA’s e-Authentication Service Component comes from FCW.com: “The e-Authentication Service Component incorporates two different architectural techniques, assertion-based authentication and certificate-based authentication, according to the General Services Administration. “PIN and password authentications typically use assertion-based authentication, where users authenticate to a Credential Service Provider (CSP), which in turn asserts their identity to the Agency Application (AA). Certificate-based authentication relies on X.509v3 digital certificates in a Public Key Infrastructure (PKI) for authentication, and can be used at any assurance level. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 11
  • 12. “PKI credentials offer considerable advantages for authentication. Certificates can be validated using only public information. Standards for PKI are also more mature than other authentication technologies and more widely used than the emerging standards for assertion-based authentication of PIN and password credentials. “Nevertheless, the e-Authentication Service Component incorporates both assertion-based and certificate-based authentication to provide the broadest range of flexibility and choices for federal agencies and end users. The agency notes that the ASC will provide the following: • • • • • “Credential assessments and authorizations; “technical architecture and documents, including interface specifications for communications within the e-Authentication Federation Network; “interoperability testing of candidate products, schemes or protocols; “business rules for operating within the Federation; and “management and control of accepted federation schemes operating within the environment.” June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 12
  • 13. The U.S. Federal PKI Fig. 6: The U.S. Federal PKI. The ACES Program The Access Certificates for Electronic Services (ACES) program provides digital certificates and PKI services to enable electronic government applications that require logical access control, digital signature and/or electronic authentication. They also support the sharing of health information in cross-organizational and RHIO and HIE data exchanges. GSA serves as a Policy Authority and is responsible for organizing and administering the ACES Policy and the ACES contract. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 13
  • 14. ACES and Presidential Directive 12 In the past, PKI has been proposed as the solution to many security problems. The federal government has committed to building a federal government-wide solution based on increased post-9/11 security needs. This effort gathered steam when President Bush issued Presidential Homeland Security Presidential Directive/HSPD-12, Subject: “Policy for a Common Identification Standard for Federal Employees and Contractors on August 27, 2004,” which mandates a common security access policy and technical infrastructure across the entire federal government. To implement this policy, GSA and NIST have worked together to develop a general-purpose PKI infrastructure codified in Federal Standard 201. This standard requires a common access card be developed using a federally organized PKI infrastructure, which will allow common access control procedures to be implemented across all levels of the federal government. With this new effort emerging at the federal level, GSA and HIMSS proposed the eAuthentication Pilots to validate, through pilot implementations, the technical concept for use in the healthcare sector. The project chose to use the ACES credentials to demonstrate the capabilities of using PKI within multiple healthcare settings. The purposes of using the ACES certificates and underlying federal PKI infrastructure were: • • • To demonstrate the feasibility of using the existing federal ACES PKI infrastructure. To prototype solutions among multiple RHIOs to see if common solutions emerge. To introduce healthcare to PKI policies and processes. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 14
  • 15. IHE Interest Integrating the Healthcare Enterprise (IHE) is a multi-year initiative that creates the framework for passing vital health information seamlessly—from application to application, system to system, and setting to setting—across the entire healthcare enterprise. Under the leadership of HIMSS and the Radiological Society of North America (RSNA), IHE launched in November 1998 as a collaborative effort to improve the way computer systems in healthcare share critical information. IHE includes medical specialists and other care providers, administrators, standards organizations, IT professionals and vendors. In 2003, the American College of Cardiology (ACC) joined the initiative as a sponsor to advance cross-vendor integration for cardiovascular medicine. IHE does not create new standards. Rather, it drives the adoption of standards to address specific clinical needs. IHE Integration Profiles specify precisely how standards are to be used to address these needs, eliminating ambiguities, reducing configuration and interfacing costs and ensuring a high level of practical interoperability. IHE is now truly multi-domain, with integration profiles for radiology, cardiology, laboratory and IT infrastructure, which enable interoperability both within and across multiple enterprises. The IHE Interest in the GSA project is twofold. The first reason for interest is to make sure that the IHE “Cross-Enterprise User Authentication” (XUA) profile is aligned in the best way possible with GSA solutions to ensure that GSA-assigned identities can be used in the IHE solution. The second reason for interest is to take away lessons learned from the GSA project so as to make the XUA profile as complete as possible. Two other existing IHE profiles also leverage digital certificates. The Node Authentication and Audit Trail (ATNA) profile utilizes digital certificates to enable TLS to ensure that all nodes in an affinity domain are trusted so as to enable secure access to shared health information resources. IHE has also specified Document Digital Signature (DSG) which specifies the use of ISO TS17090 Health informatics—PKI-compliant certificates to ensure document integrity and accountability for cross-enterprise document sharing (XDS). For more information on IHE, XUA profiles and details concerning the IHE affinity architecture, visit the IHE’s Web site. RHIO Project Overviews Each of the pilot participants developed a set of use cases to document their project uses and expected outcomes. Initially we began with seven pilot teams, with six reporting actual pilot results. Each pilot set out to prove a different use case. Connecticut—Connecticut Regional Health Information Organization Background: Connecticut RHIO communities in the Middlesex, Hartford and Bridgeport areas have come together to pilot the GSA e-Authentication technology as part of a cooperative initiative among members of the newly formed eHealthConnecticut statewide RHIO. Local, innovative RHIO initiatives are emerging within Connecticut while statewide RHIO efforts are in various stages of development. In particular, initiatives in the Middlesex area overlap significantly. Through the eHealthConnecticut Technical Committee, members of the statewide RHIO hold regular meetings to discuss system architecture, infrastructure and interoperability requirements June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 15
  • 16. to enable e-health initiatives for the state. The project members are testing core capabilities provided through off-the-shelf products to demonstrate opportunities for leveraging the GSA eAuthentication technology. This group is demonstrating the use of the digital identity for protecting access to the local RHIO systems to enable broader community sharing of the information resources provided by the RHIO. Two of the participants, Jefferson Radiology and ProHealth Physicians e have members who interact with numerous organizations, several of which specifically have routine patient care business with other members of this test bed initiative. The tools are being tested and the experiences are being shared among the eHealthConnecticut Technical Committee members. The approach has been identified as a solution for provider identity management as part of Connecticut’s involvement in the Office of National Coordinator (ONC) for Health Information Technology Health Information Privacy and Security Commission (HISPC). Demonstration of communication of a single identity for interactions with these multiple organizations has been an important part of this initiative. Standards: The published standards that support the trust model used by the e-Authentication service component are shown in Fig. 1. Within the healthcare vertical, there are additional standards that were used in this pilot that specify the healthcare-specific layer over and above the foundation engineering standards for PKI, supporting services and services relying upon the PKI. These health informatics standards specify requirements for use of PKI, directory services and authorization privileges in healthcare: • • • • • • • • • • • ISO IS17090: Health informatics: PKI (Parts 1/2/3) (supersedes ISO TS17090 Health Informatics—PKI (Parts 1/2/3). ISO TS21091: Health informatics: Directory services for security, communications and identification of professionals and patients. ISO TS26000: Health informatics: Privilege management infrastructure (Parts 1/2/3). ISO ISO DTS21298: Health informatics: Functional and Structural Roles. ASTM E1986: Standard Guide for Information Access Privileges to Health Information. ASTM E1762: Standard Guide for Electronic Authentication of Health Care Information. ASTM E2084: Standard Specification for Authentication of Healthcare Information Using Digital Signatures. ASTM E2212-02a: Standard Practice for Healthcare Certificate Policy. IHE Audit Trail and Node Authentication Profile (ATNA). IHE Document Digital Signature (DSG). IHE Cross-Enterprise User Authentication (XUA). For the purposes of this pilot, we have asserted TS17090 in the absence of configured support for the healthcare extension specified as optional in the technical specification and mandatory by the International Standard revision of the specification. The extension includes a standard means by which to assert the healthcare credentials and will be an important component to assure extensible national and international interoperability. Use case. In accordance with the AHIC breakthrough area for health improvement, an electronic health record will give a clinician direct access to a person’s medical history. It would allow the provider to electronically manage all aspects of patient care, enabling the provider to retrieve/capture data for treatments in an effort to support provider/patient activities such as review, encounter and follow up. In addition, electronic health records allow patient data to be June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 16
  • 17. accessible at multiple locations. Possible benefits of an electronic health record include improved health maintenance, disease management and error reduction in clinical decision support. Many early implementations for making the electronic health record available within a community or RHIO are done through providing Web portal access either to the local EMR or to a shared summary information resource. This use-case describes e-authentication to the portal as a means by which to enable secure access to the protected health information to appropriately credentialed clinicians in possession of a GSA Affiliation digital certificate. The affiliation certificate has been issued in accordance with ISO TS17090 such that the regulated healthcare professional is issued an affiliation certificate through demonstration of affiliation with the licensing authority through vetting of individual identity and proof of an active medical license. Supporting organization employees are similarly issued an affiliation certificate such that the vetting attests to proof of individual identity and proof of current affiliation with the healthcare employer. This use-case has broad applicability, but initially will be used to enable access to medical information from the emergency department. In the context of the pilot participants, two clinical scenarios are considered: • • A patient complaining of abdominal pain is sent for outpatient radiology services following consultation with the primary care physician. The patient presents to the emergency room later that evening. Rather than repeating the radiological exam in the emergency room, the physician authenticates to the portal servicing the outpatient radiology system and retrieves the image. This image is provided to the surgical team for a patient that is referred for emergency surgery. This enables faster, better quality treatment for the patient, and reduces the cost of duplicate testing. A patient presents to the emergency department at a tertiary care hospital after experiencing symptoms of myocardial infarction, and indicates that he has been previously seen for cardiac services at the community hospital. The emergency room physician authenticates to the community hospital portal to retrieve prior EKGs within the “golden hour,” providing informed treatment for the patient. The next use-case that will be tested is sharing of patient treatment and results between providers using signed and encrypted communications. These data are typically communicated today via fax or courier. This test will use signed and encrypted e-mail or other S/MIME communications to securely deliver this information to the provider. In this test series, the physician in the outpatient setting (primary care provider or specialist) is the recipient of the communications: • • A patient is referred to out-patient radiology services. The radiology result is signed and sent through encrypted e-mail to the primary care provider or specialist. The electronic result is imported into the practitioner’s medical record. A patient referred to a specialist for testing and analysis by the primary care physician. The specialist communicates the findings through signed content sent through encrypted e-mail. In both of these cases, the encryption certificate is made available to the sending practitioner through ISO 21091 compliant directory services. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 17
  • 18. As part of this project, we have also started some early testing of authentication to a personal health record portal using the digital identities for the patient to access their health record. This uses the same approach as described for provider portal authentication, but is targeted toward consumer empowerment. As eHealthConnecticut moves toward a shared document infrastructure, we look to expand the use-cases to include securing the RHIO affinity domain, and to enable cross-enterprise user authentication in accordance with the XUA profile under development through IHE. The document sharing would include digital signature on the documents made available to the community, likely through a machine-based signature to provide assurance as to the source and validity of the information provided to RHIO members. We envision this to be a use-case to be pursued during the next phase of this project. Participants: Two Connecticut regions are participating in the project—Central Connecticut and the Bridgeport Community. Central Connecticut participation is represented by five organizations characterizing a common health market where patients are regularly serviced by multiple-provider entities. The participants in this region include two hospitals, three physician networks and a two radiology groups, including: • • • • • • • Middlesex Hospital and Health System Hartford Hospital Middlesex Health System Managed Physicians ProHealth Physicians (a large network of group practices) Radiology Associates of Middlesex Jefferson Radiology (a group of about 500 radiologists servicing Central Connecticut locations) Middlesex Professional Services Foundation (currently on-hold due to their portal vendor hesitations to support the e-Authentication technology) The Bridgeport Community has established community-wide information sharing project to enable information sharing for those patients in that region. This region services 10 percent to 15 percent of the patients in the state. The community project includes: • • • • • • St. Vincent’s Hospital Bridgeport Hospital SW Bridgeport Community Health Center Bridgeport Community Health Center Americares Bridgeport Department of Public Health In addition to these organizations, HIMSS staff members have been issued credentials in support of project staff and interoperability, including Mary Griskewicz, MS, FHIMSS, Director, Ambulatory Information Systems, and Didi Davis, Director, Integrating the Healthcare Enterprise (IHE). Results: Harmonization with International Health Informatics Security Standards. We have leveraged the ACES Affiliation certificate using hardware tokens to instantiate the ISO TS17090 Health informatics-PKI technical specification. We were unable to initiate the revised IS17090 June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 18
  • 19. Health informatics–PKI International Standard due to the lack of configured support in the CA supporting the test environment for the healthcare extension defined by that standard. We utilized the roles and codes described by ASTM E1986 Standard Guide for Information Access Privileges to Health Information code the structural roles as described by TS17090 and ISO TS21298 Health informatics–Functional and structural roles. The principals for privilege management and access control defined in ISO 26000 Health informatics–Privilege management infrastructure (Parts 1/2/3) to configure the portal environment with access privileges determined by the structural role (functional role is presumed constant as direct care provider). This combination of standards-based configurations has been implemented in two of the provider portals, enabling a single-sign-on capability across provider environments based upon the ACES certificates. Establishing a Registrar: Connecticut is using smart to demonstrate high-assurance, portable identity management to meet the security and privacy requirements associated with the protection of health information and the execution of transactions and processes that may impact patient safety. As such, a face-to-face registration requirement was met to enable the local Registrar to issue hardware-based identities and encryption certificates in accordance with the ACES vendor’s CPS. This face-to-face registration and training was completed on Sept. 8, 2006. Establishing Registrar Authorization: Several considerations were in order to establish authorization for the local Registrar for Connecticut participants. While each of the organizations are members of the Connecticut RHIO, eHealthConnecticut, there is no service offering at this time by the RHIO as it is in the early stages of defining what those services might be. As such, an authorization letter from eHealthConnecticut has little meaning at the current time. The local Registrar has met on behalf of this project and along with e-HealthConnecticut with the Department of Public Health (DPH), who is the issuing authority of medical credentials in the state to discuss obtaining authorization from DPH to represent the affiliation of the licensed healthcare professionals to their licensure in accordance with the International Standards IS17090 Health Informatics PKI. The discussion was well-received, with the only hesitation being that for the state to provide a letter. It might be construed as an acquisition, which is highly regulated. There was support for the principals and concepts and they encourage proceeding with the affiliation binding and using their online-available resources for ongoing affiliation verification. Further discussions will be pursued, and feedback will be provided regarding obtaining a registrar letter from DPH. We also discussed a potential vision for how eHealthConnecticut could serve as an infrastructure resource to the RHIO using this technology should this project prove successful in the state. Early deployments are focused around the resource providers of the project. As such, letters have been obtained first from these organizations, and will be obtained from the organizations that are primarily client-side subsequently. Registration letters have been obtained from Middlesex Hospital, St. Vincent’s, Hartford Hospital, Jefferson Radiology and HIMSS. Registration Process: In the interest of maximizing end-user support for obtaining identities, the initial registration process included the Local Registrar requesting the identity along with the end-user from the Registrar machine, and providing end-user training after the identity was issued. This approach had significant limitations. Because the registration interface required that the application be printed, signed and notarized from the registration GUI, the local Registrar either needed to leave the organization following June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 19
  • 20. the initial key request to print the documents or needed to provide a copy of the request to the subscriber. Scheduling two follow-up visits as part of the process was impractical, and as such, we explored options for printing during the first session. E-mailing the request to the subscriber was also an issue as some of the key information for the registration form was stripped by the email product. The alternative of providing the request form on a USB token was generally selected, though this is typically against the physical control policy of many provider organizations to accept foreign media for information transfer. This approach also required a final visit from the local Registrar to retrieve and download the issued certificate to the subscriber’s smart card. As the card needed to be left in the possession of the subscriber, there were cases where the subscriber had left the key at their home office and were not able to complete the process. Because of the complexities and logistical issues with the above approach, we are adjusting the process to better enable the deployment of the identity and encryption keys. The modified process will include installation of drivers and middleware in advance (by the local IT department) or during the registration visit by the local Registrar. The request will then be issued from the subscriber’s machine or from the machine of the local IT or security officer. This will enable local printing of the documents to be notarized, and will also enable the subscriber to complete the download process from their machine once the credentials are issued. This modified procedure reduces the local Registrar’s visits from two or three to a single visit. Enduser training will need to be done either at the time of registration through demonstration by local staff, or upon follow-up visit from the local Registrar. Registering Participants: At the organizational level, the deployment process begins by registering key individuals to enable both organizational support and operational integration. The project sponsor—typically, the CIO or CTO—provides a letter to recognize the local Registrar as an official registrar for identities within that organization. This initial request has sparked a number of key considerations for routine process definition. To provide such a letter which commits the organization, the project sponsor will typically involve those persons that may have related concerns. Usually, this is their own supervisor—the board of directors, executive management, human resources or the organization’s HIPAA officer. The HIPAA officer and, as appropriate, the security administrator are among the first to be issued identities, along with the project sponsor and the IT staff responsible for the systems that will be tested. This has typically involved the e-mail administrator and the network administrator. The regulated healthcare professionals are selected carefully so as to assure that the user will be technically savvy and have a real-world need for accessing or transmitting health information across organizations. Configuration of Test Environment: E-mail testing has been conducted directly from the operational environments. Two e-mail products are in use across the participating environments to date. These are Microsoft Exchange, using XP clients, and Novell GroupWise 6.5, running on an XP platform. Web portal testing has been set up in a staged environment using the portal product used by three of the four initial test sites, Juniper Networks. This environment has been configured with appropriate trust and to enable role-based decisions leveraging the ASTM structural role expressed in the digital identity in the “OU.” All identities have been configured in this manner to emulate the requirements of the ISO TS17090/IS17090 Health Informatics PKI technical specification and standard. Some initial testing of secondary authorization utilizing the ISO June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 20
  • 21. TS21091 Health Informatics Directory services for security, communications and identification of professionals and patients. Testing: There were some initial challenges in the Novell environment that were ultimately resolved including, CSP selection and end-user e-mail profile configuration. Signed and encrypted messages have been successfully communicated across the two products using the ACES Vendor digital identities and encryption certificates stored on smartcard. This has been based upon local address-book and reply-to-signed approaches. The next stage of this testing will leverage local and regional directory services for look-up of the recipient encryption key. Extended testing has been conducted using S/MIME enable email between participants in Connecticut and the other HIMSS/GSA RHIO participants. For the Web portal testing, several groups have been defined and tested based solely on the content of the certificate. As a result, the Web portal authentication has been demonstrated as simply requiring the token and the PIN. Several realms have been defined and successfully tested: • • • • All pilot participants CIO/CTOs only Physicians only Hartford Hospital physicians only These have been moved to the operational portals of two of the participants, Middlesex Hospital and Jefferson Radiology. These portals have been successfully accessed by our physician tester, Dr. Lincoln Abbott, an emergency department physician at Hartford Hospital. Personal health record management is being tested using project participants as preliminary patients. Trust for the ACES Vendor CA is pending. Once this is complete, additional patients will be added. There is a significant naming standardization issue that will need to be addressed to be able to broaden and scale this use-case. Feedback: While feedback from the project participants has been generally positive, there is concern that the penetration of the technology and user-base will need to be broadened before the efficacy can be realized. However, the trust level associated with the identity has been well respected, and participants from multiple sites have remarked that if this could be broadly deployed within the state, that there would be significant opportunity to better enable health information sharing among practitioners. Repeatedly, and independently, the provider sites involved in the testing have remarked that if this single identity could enable high assurance access across all of the RHIO systems, then any added burden associated with the token and identity provision would be worthwhile. Feedback from the state-level initiatives has also been positive. This project has been proposed as a possible solution as part of the CT-HISPC initiative to address the problem of provider identity management that has been identified. Michigan—Michigan Data Sharing & Transaction Infrastructure Project Background: Southeast Michigan is a seven-county area with nearly 5 million residents—40 percent of the state’s population. The majority of the state’s 500,000 uninsured under 100 percent of the poverty level for a family of four ($19,350) live here. Forty-eight percent of the June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 21
  • 22. state’s licensed physicians (14,000) practice here and 80 percent are not automated. Three major auto companies have world headquarters here. The economy is under siege as the manufacturing sector declines. Unemployment and bankruptcy rates are high and continue to rise. Healthcare costs represent one-seventh of the nation’s economy. Four of the seven major urban hospital systems in the area are safety net providers, taking on the majority of the burden of uncompensated care for the region. As a result, the Southeast Michigan community (citizens, employers, purchasers, healthcare systems, providers, insurers, unions, city, state and local government agencies, medical societies and other professional associations) is actively seeking ways to improve healthcare access and quality while holding down costs. In Michigan, there are many overlapping development efforts that are centered around integration and interoperability in healthcare. HIMSS members throughout the state have been key participants in all of these efforts. The climate is ripe in Michigan for formation of RHIOs / HIEs. Over the past year Michigan, under the joint leadership of Teri Takai, director and CIO, Michigan Department of Information Technology, and Janet Olszewski, director, Michigan Department of Community Health, has put in place the framework for a statewide RHIO— MiHIN. It also has created a health IT commission and has made $5 million in grant money available for planning and implementation of HIEs in Michigan, arranged by Medical Trading Areas. At this time, at least seven coalitions of stakeholders are applying for these grants, two for implementation and five for planning. The state is currently awarding a grant for management of a resource center to coordinate these regional efforts, record locator services and require standards harmonization. At the same time, in Southeast Michigan, stakeholder groups led by the auto companies and a large IT vendor based in the region started discussions that led to formation of the Southeast Michigan Health Information Exchange (SEMIHIE). The Michigan Chapter of HIMSS was a leader in this effort, chairing the Governance Planning Committee and the Governance Work Group. SEMIHIE is now an independent group working with four host organizations (Altarum Institute, Greater Detroit Area Health Council and the medical societies of Wayne and Oakland counties) working actively toward formation of a HIE for the community, a non-profit organization structured as a public/private utility. SEMIHIE and hosts have submitted a proposal response for a State of Michigan HIE planning grant proposal.. The objectives of SEMIHIE are to establish a sustainable, self-sufficient business model for the SEMIHIE that aligns costs with benefits for the stakeholders and to provide for secure, private and efficient cross-institutional exchange of clinical and administrative healthcare data to: • • • • • Enhance physicians’ and other healthcare providers’ ability to access and use electronic health information and decision support tools to facilitate appropriate care and improve patient safety. Foster improvement in clinical and administrative healthcare processes through the sharing of healthcare data. Build the foundation to provide future support for patient education, issues affecting personal health and public health surveillance reporting. Create a secure, ubiquitous, interoperable HIT infrastructure consistent with state and federal standards/guidelines, where applicable. Implement a technology infrastructure that provides for proper security, authorization of users and indexing of patient information from multiple sources. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 22
  • 23. • • • Drive the adoption of policies and technical standards to facilitate data gathering, information sharing and decision-making while protecting patient privacy. Link to national and regional efforts through use of a common trust framework, business and operating rules, technical infrastructure and governance models for federated identity management and interoperability. Develop and maintain an environment of trust among the stakeholders. In parallel with formation of SEMIHIE and MiHIN, a group of individuals including financial institutions, large and small health systems, physician groups, insurers, unions, the autos, employers, purchasers, public health, healthcare professional organizations, technology and consulting firms and international standards organizations began to develop a pilot focused on secure interchange of healthcare data across disparate stakeholders to evaluate the feasibility of using e-Authenticationin healthcare. This pilot project, the Michigan Data Sharing Transaction Interface (MI-DSTI), applied for and was accepted in the GSA / HIMSS e-AuthenticationPilot Project along with the projects of six other states. [The majority of the MI-DSTI members were also simultaneously involved in SEMIHIE and in the committees working on MiHIN.] In July 2006, David Temoshok of the GSA and Michael Sessa of the Electronic Authentication Partnership (EAP) spoke to the members of SEMIHIE about the importance of establishing eauthentication, federated identity management, integration and interoperability across industry segments and of being certified to work across the Federal Bridge with agencies of the federal government. This presentation was well-received by SEMIHIE and the requirements for linking to national and regional efforts through use of a common trust framework, business & operating rules, technical infrastructure, and governance models for federated identity management and interoperability were formally incorporated in SEMIHIE’s organizational objectives in August 2006. SEMIHIE officially adopted the MI-DSTI GSA/HIMSS e-AuthenticationPilot in late summer of 2006. Prior to that time, organizations and individuals, most of whom were SEMIHIE members, had been working separately to develop use-cases and a technical framework for the pilot project. This adoption improved the ability of member organizations to collaborate on the project and access resources. This collaboration among the members in a trusted environment has been critical to the success of the pilot project. Toward the end of the pilot project, the original vendor of the technical infrastructure dropped out. Two technology firms, Shinkuro and FireStar, and NextUs, a network consulting firm, stepped up to fill the void. This technology was successfully tested by the MI-DSTI participants, using a series of use-case scenarios (listed in the Appendix). This experimental testing was completed Feb. 13, 2007. The group of participants has determined that the use-case and technology are of sufficient interest and importance that they will continue to experiment with the ACES E-Gov Certificates and the Shinkuro-FireStar technology after the official end of the pilot program. MI-DSTI e-AuthenticationPilot Project Participants Project Managers • Helen L. Hill, Immediate Past President, Michigan Chapter of HIMSS; Chair SEMIHIE Governance; Director IT Consulting, Covansys/Henry Ford Health System Account June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 23
  • 24. • Michael (Mick) M. Talley, Lead Independent Director and Chair of the Audit Committee, University Bancorp Local Registration Authorities • • • • Maurice Aljadah,, Program Manager, Healthcare IT, General Motors Corporation Rebecca Dykes, Customer Service Supervisor, University Bank Gina Cross, Customer Service Representative, University Bank Stacy Shepanski, Vice President, Deposits and Consumer Lending, University Bank Participants • • • • • • • • • • • • • • • • • • • • • • • Maurice Aljadah, Program Manager, Healthcare IT, General Motors Corporation Suzanne Paranjpe, Ph.D., Executive Director, AFL-CIO Employer Purchasing Coalition Jan Whitehouse, President, CyberMichigan, a Division of Altarum Institute; now: Director, Save Lives Save Dollars (SLSD), Greater Detroit Area Healthcare Council (GDAHC) Carlotta Gabard, Vice President, IHA of Ann Arbor; now: Executive Director, Ann Arbor Area Health Information Exchange (A3HIE) Grace Miller, Director of Information Technology, IHA of Ann Arbor; now: Director, Trinity Health Sandra McKenzie, Applications Software Coordinator, IHA of Ann Arbor Paula Smith, CIO, Oakwood Healthcare System Barb Sabo, Director of Information Technology, Oakwood Healthcare System Ken Garner, Manager, Information Security, Oakwood Healthcare System Damien Payton, Lead Security Analyst, Information Security, Oakwood Healthcare System Vimal Chowdhry, Vice President, Business Effectiveness, IT Admin., Henry Ford Health System Fahd Haddad, Manager, Ambulatory Pharmacy, Henry Ford Health System Dennis Sirosky, Senior Vice President, Product and Information Technology, Health Alliance Plan Mike Elinski, Associate Vice-President, Technology & eBusiness Development, Corporate Security Officer, Health Alliance Plan Jignesh Patel, Senior Technical Architect, Technology & eBusiness Development, Health Alliance Plan Craig Ireland, CIO, Botsford Healthcare Account / ACS Healthcare Patricia Moore, IT Consultant, Botsford Healthcare Account / ACS Healthcare Jim Holody, Director, Covansys Corporation Charles Bracken, Managing Director, ACS Healthcare Elaine Roach, President, Michigan Chapter of HIMSS; Vice President, ACS Healthcare Stephen Lange Ranzini, President and Chairman, University Bank Rebecca Dykes, Customer Service Supervisor, University Bank Gina Cross, Customer Service Representative, University Bank June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 24
  • 25. • • • • • • • • • • • • • • • • • Stacy Shepanski, Vice President, Deposits and Consumer Lending, University Bank Darnell Grant, Director of Information technology, University Bank Janet Anderson, Executive Vice President, Internal Audit and Human Resources, University Bank Nick Fortson, Director and CEO, University Bank Rick Moore, President, eHealth Ohio Jim Lee, Michigan Health and Hospitals Association (MHA) Mishka Bennett, Project Manager, Michigan Public Health Institute (MPHI) Teri Takai, Director, Michigan Department of Information Technology and Chief Information Officer for the State of Michigan Dan Lohrmann, Chief Information Security Officer, Michigan Department of Information Technology Steve Crocker, Founder and CEO, Shinkuro Mark Zalewski, Partner, Shinkuro Mark Feldman, IT Architect, Shinkuro Mark Eisner, Chief Technical Officer, FireStar Software Chris Sanders, Vice President, FireStar Software Jeffrey Dewhurst, FireStar Software Jill Finnerty, Program Manager, FireStar Software Robert Skinner, Partner, NextUs Incorporated Scope: The scope of our pilot project was to identify and demonstrate a range of transactions in healthcare that would significantly benefit from the added audit examination and security that will derive from the use of ACES PKI certificates and services. These transactions would be implemented in a real, operational setting, thus not just demonstrating technology, but elucidating the issues in making that technology executable and operational. Goals and Objectives • • • Gain experience and expertise in utilizing the ACES / E-Gov infrastructure. Determine gaps, limitations and confusion in the distribution of certificates. For end-users to understand that before a web-enabled, electronic transaction can occur, the appropriate level of strength credential must first be presented, mapped to the level of risk. Organization: The Michigan team was initially divided into four working groups: Use-Case, Technical, Financial and Governance. Over the course of Phase 1 of the pilot, the Use-Case and Technical work groups became the primary focus of the participants. Use-Case Framework: The Use-Case Framework was supplied to the members of the Michigan Group belonging to the Use-Case Work Group (UCWG) and the Technical Work Group (TWG). The UCWG identified three cases of interest, and the TWG established the topography for placement of the Certificates and distribution of the tokens. The Michigan Group had access to a total of 28 certificates, including six smart card tokens and a “reader.” June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 25
  • 26. The Michigan Group defined the “end user” (doctor/nurse/pharmacist/payor/ambulance service dispatcher/emergency room physician/neurologist/banker/patient/administrative staff/researcher) and noted that the credentials, accepted as a generic term, were distributed on a personal role basis or to an organization representing multiple persons. The Group developed the view that it was important to use the results to provide a metric to determine whether the data shared was an “improvement” or a quantitative advance. Use-Case Process: The MI-DSTI pilot project use case process had three steps: • • • The vetting process and the distribution of the Credentials: Document the experience. Share the data query initiated by the end-user from A to B: Document the methods / results / success / problem. Attempt some set of “interactive” experiments on the presentation format of the data for the session with integration into existing medical protocols. The Michigan Group intended to use the Use-Case to document the sharing of data securely across IT systems, networks and domains to answer the following questions: • • • How do we know the person authenticated for access was the correct person?. How do we know the data was transmitted correctly and was not tampered with by some sort of “man in the middle” attack? How do we know the data was shared securely, and what set of methods complied with audit requirements for security and privacy? The Michigan Group organized the vetting process for the credentials to begin with a physical visitation with the designated LRA that provided for the presentation of photo identification issued by a federal or state government agency. The goal was to use the vetting process over the ACES E-Gov infrastructure to: • • • • • • Document the experience. Evaluate ease of access for the Lars and the end-users. Gain expertise in the vetting process. Document the Lars’ issues and concerns related to the outcome of the sessions. Refine the process as gaps are discovered LRA Certification Process. The process for certifying selected persons and organizations as Lars had issues, difficulties and concerns. One issue was that the original instructions from the ACES vendor to send documents for LRA certification did not specify that the documents could not be faxed and could not be copies. They had to be replaced with mailed, signed originals. This change or misunderstanding added several days to the timeline. End-User Certificate Vetting Process: The vetting process preceded the distribution of the ACES E-Gov Certificates and required extensive coordination of timing and setting appointments. The end-users receiving the Credentials were informed in person, by telephone or by email that they would need to meet with an LRA and that they must provide a set of official personal documents with photo IDs issued by a government or other appropriate administrative body. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 26
  • 27. 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. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 27
  • 28. Ring-With-Tails Architecture Diagram Helen Hill Patient Hhill!shinkuro.com Sandra McKenzie Physician EN-1 Jignesh Patel Insurer Sandra_mckenzie@ihacares.com !shinkuro.com EN-2 EN-3 Service Provider EN-4 EN-10 EN-9 EN-5 Vimal Chowdhry Neurology Physician vchowdh1@hfhs.org Rebecca Dykes Bank Beeka!mercurymessage.net EN-8 Barb Sabo Emergency Physician Barb.sabo@oakwood.org Fahd Haddad Pharmacist fhaddad1@hfhs.org EN-7 EN-6 Patricia Moore Ambulance Service pmoore@acs-hcs.com Rick Moore Imaging Repository rkmoore@ehealthohio.org Test Results. The tests showed that the E-Gov technology e-Authentication service can work successfully in healthcare. Although some issues were encountered the underlying technology does work. The MI-DSTI project team was able to successfully process certificates, send and receive secure, digitally signed and encrypted data (including images) across a broad range of participants in disparate organizations and across state boundaries. The first scenario allowed a patient to request refills from the primary care physician, have those refills filled by the pharmacy, notify the patient of co-pay and deductibles, and have the money debited from the patient’s HSA by the bank following approvals. In this scenario, all parties had appropriate credentials and were able to have their communications, digitally signed and encrypted and sent in a secure data-sharing technology, among the parties as planned. (See Appendix I—Detailed Use Case Scenarios and Appendix II—Samples of Use Case Forms.) The second scenario was a variation on the first, adding pre-authorization process steps that cause the primary care physician to send a request to the payor, HAP, before sending the prescription to the pharmacy. [Note: in certain instances, a pharmacy such as the HFHS Pharmacy may be pre qualified by the payor to handle pre-authorizations, thus eliminating a process step]. (See Appendix I—Detailed Use Case Scenarios and Appendix II—Samples of Use Case Forms.) June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 28
  • 29. The third scenario included a typical, but interesting series of exchanges among community stakeholders: patient with credentials, ambulance company, hospital emergency department physician, insurance company, another hospital’s pharmacy with pre-authorization capability, a health system neurology clinic physician, an imaging center for a consortium of Children’s’ hospitals in another state, a primary care physician in another city and a financial institution. (See Appendix I—Detailed Use Case Scenarios and Appendix II—Samples of Use Case Forms.) Although there were a few initial setup issues, the forms the group used were actual healthcare documents modified for use in the testing. Due to time limitations, no special applications were created to automate the contents of the documents, so some of the forms were not polished. Despite the fact that there were a few document naming convention questions, the process actually worked and could, with some work on the application layer, be effectively used by the members of this team in real life situations, quickly, effectively and securely in compliance with HIPAA and a familiarity with ISO 17090—Part I. One additional benefit to the project was the exceptional cooperation displayed by all members of the project team. This will be helpful as the SEMIHIE continues to develop into a formal organization. Throughout the project, the team members remain convinced of the importance of this experiment and dedicated to completing the testing despite time-constraints and other obstacles. They think that this project has potential for long-lasting benefit to the community and will continue experiments with the GSA certificates and the Ring-with-Tails infrastructure. Use-Case Flow Diagrams Overview: The patient, driving from her home in Ann Arbor to work in Detroit, was hit by a truck on I-94 at Michigan Ave. in Dearborn, and suffered extensive head injuries. Police called the nearest ambulance service. She was picked up by CEMS, the ambulance service. CEMS notified Oakwood ER that this patient was coming in and gave a preliminary diagnosis. Oakwood ER assigned a room for the incoming patient; treated the patient on arrival; requested authorization for neurology referral to HFHS Neurology from the payor, Health Alliance Plan; requested medication authorization for the patient from the payor; requested and received confirmation of an immediate appointment for the patient with HFHS Neurology; notified HFHS Pharmacy of authorization of medications for the patient; called CEMS ambulance to pick up patient; and billed the University Bank of Ann Arbor for ED services for the patient. CEMS picked up the patient, notified HFHS Neuro that the patient was arriving; billed the University Bank for patient pay portion. HFHS Neuro evaluated patient, requested a consult with the Imaging Center in OHIO, received an image from Ohio from prior studies on the patient; requested authorization from payor Health Alliance Plan for medications for the patient; notified the primary care physician IHA in Ann Arbor of the findings; billed the University Bank of Ann Arbor for the patient portion. The Imaging Center in Ohio received a request for clinical information on the patient, located an image from an earlier visit and sent that image securely and encrypted to the requesting HFHS Neurology Clinic physician and to the primary care physician, IHA Ann Arbor; billed the University Bank of Ann Arbor for the patient portion. The University Bank of Ann Arbor received bills from all the parties, reviewed available funds, notified the patient of the charges, received patient approval to pay, and paid the bills from the patient’s demand deposit account. The primary care physician from IHA Ann Arbor received June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 29
  • 30. documentation of care provided to the patient from Oakwood ER, HFHS Neurology, HFHS Pharmacy and the Ohio Imaging Center; reviewed and filed the documentation and arranged for follow-up. The patient received notifications from the University Bank for authorization of payment from all the billing parties and approved the payments from her HSA direct deposit account. The Patient received notification from the HFHS Pharmacy that her prescriptions were ready for pickup and notification of the required co-pays. June, 2007 Copyright 2007 by the Healthcare Information and Management Systems Society 30
  • 31. [Note: Groupwise 6.5 posed several as yet unresolved issues related to processing certificates: recognizing valid certificates, signing and encrypting messages with the certificate.] Minnesota—Community Health Information Collaborative (CHIC) Project Overview: The overall CHIC-RHIO vision is “to facilitate the sharing of health information across all organizations, contributing to the continuum of patient care.” As part of that vision, the Minnesota project team focused on developing a single sign-on service, using the ACES certificates. Developing a single sign-on through a Web-based portal will streamline access into remote systems for physicians. This project was viewed as a proof-of-concept that federated identity management and digital certificates could be a viable solution to the single sign-on objective. CHIC retained a Minnesota-based company, VisionShare Inc., to develop a federated identity management system. VisionShare, in turn, collaborated with researchers at the University of Minnesota to build a test-bed system based on software recently developed by the Internet2/GRID community. During the course of this project the VisionShare principles involved in this project formed a new company, MEDNET USA, so we will be referring to this new company in this report. This software, called “Shibboleth”, was developed by leading researchers at The Ohio State University and Georgetown University. Shibboleth is an initiative to develop an open, standards-based solution to meet the needs for organizations to exchange information about their users in a secure, and privacy-preserving manner. The initiative is facilitated by Internet2 and a group of leading campus middleware architects from member schools and corporate partners. The purpose of the exchange is typically to determine if a person using a web browser (e.g., Internet Explorer, Netscape Navigator, Mozilla) has the permissions to access a resource at a target resource based on information such as being a member of an institution or a particular class. The system is “privacy-preserving” in that it leads with this information, not with an identity, and allows users to determine whether to release additional information about themselves. An “open solution” means: • • An open architecture; and A functioning, open-source implementation. “Standards-based” means that the information that is exchanged between organizations can interoperate with that from other solutions. Background on Minnesota CHIC Description. In the eight-county region included within the CHIC RHIO, there exists two major hospital systems and numerous smaller rural hospitals and clinics. Our overall project strives to give physicians and other authorized providers a complete picture of their patients’ medical record. Access to the assorted health information is designed to be through a Web portal supported by CHIC. Participants. Members of the team included: Copyright 2007 by the Healthcare Information and Management Systems Society 31
  • 32. Cheryl Stephens, CHIC, Executive Director, CHIC-RHIO Co-Project Lead, Local Registration Authority for digital certificates. Melinda Machones, St. Scholastica’s Center for Healthcare Innovation, Director of Projects, CHIC-RHIO – Co-Project Lead, Local Registration Authority for digital certificates. John Fraser, CEO, MEDNET USA, Technical Project Manager, National PKI/Infrastructure expertise Seonho Kim, MEDNET USA, Senior Software Architect, Ph.D Candidate, University of Minnesota Department of Computer Science. Shibboleth design and support. Dr. Jon Weissman, University of Minnesota, Associate Professor of Computer Science. Oversees Shibboleth planning. Dr. Michael Slag, SMDC Health System. Pilot physician to test digital certificate. Dr. John Van Etta, St. Luke’s. Pilot physician to test digital certificate. Clark Averill, St. Luke’s, Director on Information Technology. Dennis Smith, SMDC Health System, Director, Technology Systems. Dr. Tim Arnold, Riverwood Health Care Center, Pilot physician to test digital certificate. Mark Schmidt, SISU Medical Solutions / Systems, CIO Interesting Facts. The use of a federated identity management system is one of the most interesting aspects of this project. MEDNET USA recommended this solution since, with multiple organizations involved, a centralized system was not appropriate. The Shibboleth software used was initially developed for university environments. This is one of the first implementation of Shibboleth in healthcare. It is interesting to note that the CHIC community quickly understood the sharing of identity that this model supports, and liked the overall architecture. Although quite complex underneath, the user interface is a set of Web pages, with which users are comfortable and can quickly master. Business Problem Use-Case Review: This case study for this HIMSS/GSA project was designed to allow the CHIC RHIO to demonstrate the following capabilities: • • • Volunteer physicians and/or other authorized providers will log into a single Web site for authentication. This authentication will be used to authorize physician/provider access to various Electronic Medical Record (EMR) systems. The physician/provider will demonstrate the ability to look up patient information on these systems without additional logins to demonstrate the capability of single sign-on. (Phase II) Copyright 2007 by the Healthcare Information and Management Systems Society 32
  • 33. A diagram of the environment: Results Registration of Certificates. The registration process involved two phases. The first was a test between the project’s two co-leads who had been identified and trained as Local Registration Authorities (LRAs) by ORC. It was important to walk through and test the process prior to engaging physicians. One of the co-leads was successful in completing the registration process, on-line, and, ultimately, receiving her certificate and reaching the test servers. The other co-lead, however, was unable to successfully complete the on-line registration process and, therefore, has yet to receive her certificate. Phone and e-mail communication with the ACES vendor reported the problem, as well as inclusion on the Issues Log. Although she appears to have a typical Windows/IE system, the ACES vendor has been unable to resolve the problem. We decided there was not time to wait for resolution of this registration, since one had worked. With the help of the IT directors at the various health systems, we identified physicians willing to work with us through problems. Ultimately, all three physicians successfully registered and received their digital certificates. Although the Web application is rather straightforward, it could be streamlined to save time and minimize points of confusion. Examples include: Copyright 2007 by the Healthcare Information and Management Systems Society 33
  • 34. • • • Automating the installation of four certificates to trust the ORC ACES Certificate Authorities. Allowing special characters in the entered information for the online application (e.g., a colon [:] is not acceptable). Formatting or streamlining the pop-up window instructions to ensure the users understand its purpose and follow the steps completely. We discovered, also, that the support structure, when problems arose, was hard to reach and resolution was slow. Use of Certificates. The initial installation and testing were done with test certificates issued from a test certificate authority run by MEDNET USA. This allowed the group to focus on getting all the components quickly working. Once the ACES certificates were received, installing and using these certificates was simply a matter of adding them to the access control lists on the system and has not been a problem. Secure Data Exchange. Due to existing Minnesota privacy laws, our test did not exchange data; it was designed to test a proof-of-concept in the use of digital certificates to authenticate a user. Both hospital systems set up test servers as part of the Shibboleth network. When the login was successful, the user received a ‘Congratulations’ screen upon reaching the test server. Moving Forward Next Steps. We have two “next steps” with this project. The first is to resolve identified problems with the registration process so that we, and the ACES vendor, can learn for future registrations. The second is to replace our test servers with the hospitals’ test Citrix systems to learn to work within a Citrix environment and access the applications it supports. All participating health systems use Citrix as their front-end interface with different EHR systems implemented. We believe that lessons learned in the phase with advance our vision of single sign-on capability to physicians in our RHIO environment. Nevada—Single Portal Medical Record A hospital emergency room desires access to patient information from patients associated with an MSO (Managed Service Organization) associated with the hospital. The MSO manages 21 individual physician practices. Furthermore, the MSO provides billing services to the 21 practices and desires access to patient records in order to support the billing efforts. The MSO provides, as an optional service, referral processing functionality and desires to access patient information appropriate to the referral mission. Use Case Overview. As patients of the designated clinics present to the emergency room for treatment the ER physician will access the records of the patient directly from the patient’s primary care and specialist records. As patients return to their primary care physician the records of the ER visit will be electronically posted to the patient’s chart. As patients require treatment via specialists in the form of a referral the referral processing authority for the MSO will forward PHI to the appropriate insurance companies in order to obtain authorization for a referral. As a patient is treated by a primary care and specialist physicians who are both on the network the transmission of Copyright 2007 by the Healthcare Information and Management Systems Society 34
  • 35. the primary care physician’s patient visit records and related clinical information are electronically posted to the patient chart at the specialist being referred to and, subsequently, the specialist report is returned to the referring physician’s chart electronically. Results. Unfortunately, the Nevada project dropped out of the initiative due to lack of resources. Ohio—Ohio Supercomputer Bioinformatics Project Overview. Healthcare research is increasingly incorporating individually specific information for progress and insight into diseases and exploration of new treatment approaches. The information that is sought includes patient histories and other data that is part of the emerging electronic medical record. Concurrently, to remain competitive in funding research efforts, incentives and requirements have been advanced to encourage sharing information collaboratively among research efforts. While infrastructure is being developed to facilitate interchange of information among the research community (such as the NCI caBIG effort), a standard approach for individual authentication that transcends clinical and research communities has yet to be established. Background. Initiated by eHealth Ohio, and in conjunction with the Ohio Supercomputer Center, this project has focused on evaluating the viability of using the proposed national level user authentication process as a means of authenticating individual researchers, system developers and system administrators who will be both utilizing, creating and maintaining future health care research systems. An emerging area of software development focus, this pilot will also identify key issues faced by resource constrained development efforts. Broader Impact. The broader impact of a common authentication standard that bridges the clinical and research communities cannot be overestimated. The presence of a national standard in this capacity will have significant implications for increased accountability and thereby confidence in research efforts employing individually identifiable information. A national authentication standard for healthcare researchers will have an anticipated impact of increased uniformity among IRB (Institutional Review Board) protocols involving patient information, while simultaneously enabling improved adherence to regulatory requirements imposed by HIPAA. Use-case. Authentication of researchers for research data of emerging data interchanges. Project Approach. The approach in the pilot has been to evaluate the process for design and logistical implications for future systems in development, intended to be compatible with emerging data interchange requirements imposed by the research community (e.g. caBIG). Current systems developed at OSC for the Ohio BioRepository and for the telehealth research funded by the Department of Health and Human Services Office for the Advancement of Telehealth provided the prototype platform technology for evaluating the viability of the certificates, with design and procedure implications being incorporated into development plans for target collaborative systems involving integration of biospecimen, virtual microscopy, microarray and clinical health information. Copyright 2007 by the Healthcare Information and Management Systems Society 35
  • 36. Participants eHealth Ohio. Ohio—eHealth Ohio—OSC Bioinformaticsis a non-profit organization formed to promote the advancement of health information technology (HIT) in the state of Ohio via educational outreach and other services. The leadership of Ohio—eHealth Ohio—OSC Bioinformatics include representatives from the Ohio Department of Job and Family Services, the Ohio Hospital Association, the Ohio State Medical Association, the Ohio Osteopathic Association and other Ohio stakeholders in HIT. Ohio—eHealth Ohio—OSC Bioinformatics also is an active participant in the formation of the strategic roadmap for the adoption of HIT and the Health Information Security and Privacy Collaboration (HISPC) with the Health Policy Institute of Ohio. EHealth Ohio’s participation in this pilot is an outreach to help promote standards in HIT security needed for the success of the Nationwide Health Information Network and the Regional Health Information Organizations in Ohio. Participants from eHealth Ohio Richard Moore Ohio—eHealth Ohio—OSC Bioinformatics–President Co-Project Leader and Local Registration Authority for digital certificates Nancy P. Gillette, JD Ohio State Medical Association, Senior Counsel Ohio—eHealth Ohio—OSC Bioinformatics–Treasurer, Pilot Project LRA Notary Public Ohio Supercomputer Center. OSC provides a reliable high-performance computing and high performance communications infrastructure for a diverse statewide/regional community including education, academic research, industry and state government. Supporting an operational statewide fiber optic backbone network as well as production data and computational facilities, OSC enables exploration of new computing paradigms and approaches in such key areas as industrial computing, health information technology, and data management, mining and visualization. Working as a collaborative partner, OSC both promotes and leads computational research and education initiatives, enabling progress in advanced technology, information systems and key industries. Participants from OSC Eric Stahlberg OSC - Senior systems manager Technology direction, Ohio BioRepository Initiative David Bertram Lead system administrator, Ohio BioRepository Initiative Joe Miller Lead developer, Ohio BioRepository Initiative Columbus Children’s Research Institute. The Center for Childhood Cancer BioInformatics Group (C3BIG) of Columbus Copyright 2007 by the Healthcare Information and Management Systems Society 36
  • 37. Children’s Research Institute, under the direction of Dr. Stephen J. Qualman, is a BioInformatics application development team dedicated to increasing cure rates and decreasing side effects in therapy through Information Technology. Development efforts are focused on these key disciplines within the center: molecular genetics, core morphology, histology, the biospecimen repository, functional genomics and specific pediatric cancer research initiatives. Our development efforts also extend outside the walls of Children’s Research Institute to those of the Cooperative Groups. These groups are the Children’s Oncology Group (COG), the Gynecologic Oncology Group (GOG), the Cooperative Human Tissue Network and the Childhood Cancer Survivor Study. Participants from Columbus Children’s Research Institute David Billiter Manager—Center for Childhood Cancer BioInformatics Group Tom Barr Medical Technology Specialist—Center for Childhood Cancer Bioinformatics Group Results and Conclusions. While original expectations of the pilot evolved over the period, the HIMSS pilot project has proven invaluable as a means to clarify logistics and procedures required for establishing individual authentication at local and remote collaborating research sites. Staff turnover and a delayed development schedule precluded fulfilling the original aims of the pilot project within the expected timeframe. Nevertheless, procedures and details were refined in the prospective use of the ACES vendor to prepare digital certificates for project collaborators. Multiple individuals were registered and issued digital certificates. Further testing of the issued certificates within the prototype architecture remains to be done. Summary lessons learned from the pilot include: • • • • • • A clear definition of authentication process capabilities and services provided by the central registration authority is critical in the initial phases for planning. Accurate and complete documentation is critical for successfully completing the authentication procedure. Scheduling logistics for the necessary face-to-face meeting between the LRA and individuals can be problematic when involving collaborating and remote sites. Logistics for authenticating remote participants is increasingly difficult. Plan to cover costs, including travel, to authenticate individuals from remote sites. Ensure a computer security development expert is incorporated into the effort from project inception for the duration Use of removable USB drives provides a means to transport individual security certificates. Recommendations • Identify or qualify an onsite employee to serve as a notary public. Copyright 2007 by the Healthcare Information and Management Systems Society 37
  • 38. • • • • Establish and maintain a current central registry of qualified Local Registration Authorities among the participating organizations. Cross-certify LRA among projects to aid the registration of remote collaborators not conveniently within driving distance. Develop authentication instructions tailored for different individual levels of expertise. Consider methods for remote video registration certification. Next steps. The individual pilot effort will next focus primarily on further validating use of the issued certificates in the prototype and expanding the involvement of collaborators accessing the prototype. Technical learnings from the certificate pilot will be used to guide future technology decisions in data security. Concurrently, steps will be taken to convene other pilot project participants to review pilot outcomes to further refine the viable technical options for operating central, federated or common secure authentication server resources shared among collaborating sites. Ohio—Virtual Medical Network Background. Virtual Medical Network (VMN) is a turnkey enterprise solution for practice management, electronic health records, billing, scheduling, electronic prescribing, and transcription (dictated files are returned as either key value paired data or as independent documents per physician preference, and are imported directly into the patients’ medical records). VMN’s product is a Web-based ASP model, allowing access from virtually anywhere. Business Problem. Because of its ASP architecture, members within VMN’s network have no difficulty sharing information or accessing records of mutual patients while remaining HIPAA compliant. Securely importing information from outside the VMN network is also readily done. However, security becomes an issue when VMN clients wish to export information outside of the VMN network. HIPAA regulations require the creation of a positive audit trail and a documented chain of custody for transmission of data containing personally identifiable protected health care information. Creating a limited user role for out-of-network users does not resolve the authentication issue. There is no reliable way to confirm that the person receiving the exported information is in fact the actual intended recipient. This becomes a significant issue when a physician needs to make referrals to out-of-network doctors electronically, or to export medical histories to out-of-network facilities. Creating a means for an out-of-network user to retrieve exported files would be fairly straightforward. However, authenticating an out-of-network user for download permissions presented a challenge. VMN wished to explore the feasibility of using the GSA certificates in lieu of developing a proprietary authentication method for validating the identity of ex-network users. Experience Using GSA Services. We selected one of our clients, Dr. James Kolp, a physician specializing in family practice, as a candidate for our “in-network” certification trial, and our LRA (Rick Powell) as a candidate for our “out-of-network” certification trial. Once the certificates were obtained, Dr. Kolp would create a referral letter and an Copyright 2007 by the Healthcare Information and Management Systems Society 38
  • 39. exported file of a mock patient’s pertinent medical history and post the file in the appropriate VMN location using his certificate as authorization to post. Mr. Powell would then navigate from outside the VMN network to the site, present his GSA certificate for authentication, and download it. Registration of Certificates. Mr. Powell submitted his application for a certificate as part of the training provided for LRA’s on Aug. 16, 2006. Dr. Kolp submitted his application from his office laptop on Nov. 30, 2006. We received and confirmed the certificate for Dr. Kolp, and were able to perform import and export functions to confirm portability of the certificate file from one laptop to another, as well as feasibility of maintaining a copy on Dr. Kolp’s thumb drive. In addition, the certificate was tested against the GSA’s vendor’s web site. Use of Certificates. Testing of the certificate against our Web server was delayed due to the time required to troubleshoot an authentication issue. The initial client certificate request from our web server was unsuccessful because the certificate for Dr. Kolp failed to meet the requested parameters. This was apparently due to incompatibility issues with Internet Interoperability Standards (IIS)5. This was resolved when we moved the VMN authentication site to a server operating with IIS6 (special thanks to fellow pilot participant Lori Fourquet for her generosity sharing “lessons learned,” which enabled us to find this workaround). VMN plans to test the certificates utilizing Dr. Kolp’s certificate as the “sending” party and a certificate from one of the participating RHIO’s certificate holders as a “receiving” party, thus enabling us to confirm whether communication between two discrete RHIOs is feasible utilizing the ACES certificates. (See flowchart, below). Copyright 2007 by the Healthcare Information and Management Systems Society 39
  • 40. Due to the schedule delay resulting from IIS5 incompatibility, the scope for the purpose of this white paper was contracted, but still encompasses authentication of the recipient’s 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 Network Solutions 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 discussion, the following diagram shows the flow of data with certificate use as we understand it. Copyright 2007 by the Healthcare Information and Management Systems Society 40
  • 41. 4 1 2 9 6 VMN In-Network Physician 7 Other Web Server 3 8 5 ACES Certificate Server ` Ex-Network Physician The critical drawback to this schema is that the certificates are resident files on a specific piece 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 same physical piece of equipment or the physician must carry the certificate file in some manner as to make it portable (e.g., CD, flash drive) and compatible with all types of PCs or 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 becomes a significant 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. Copyright 2007 by the Healthcare Information and Management Systems Society 41
  • 42. VMN’s position is that this anticipated methodology is dependent on the development of a robust, standardized directory schema for use by the Shibboleth club members. Corpus Christi—Coastal Bend Health eCities Project Project Overview. In 2005, The City of Corpus Christi, Texas and CHRISTUS Spohn discussed ways to improve emergency treatment by first responders. The city operates the ambulance service through its fire department and CHRISTUS Spohn Memorial Hospital is the regional trauma center. Corpus Christi had just completed installing a wireless infrastructure in the first neighborhood for what is now a 150-square-mile, municipalwide wireless mesh. The initial solution was to allow the paramedics to access CHRISTUS Spohn’s MEDITECH electronic medical record while they were in the field. With national and state efforts for regional health information organizations gaining momentum, an alternate approach was deployed. A new healthcare database would be created that would connect to the City’s 911 emergency dispatch system. The paramedics would access the health data in the field, once they identified the individual. The paramedics then send their data to the hospital via the wireless network, including 12 lead EKG readings. This results in improved care safety, quality and outcomes. All health care providers in the region were invited to participate including city and county health departments. Copyright 2007 by the Healthcare Information and Management Systems Society 42
  • 43. 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 ambulance for accessing personal health information. The health eCities project desired to explore the GSA e-Authentication method to determine if it could successful provide a trusted, 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 Copyright 2007 by the Healthcare Information and Management Systems Society 43
  • 44. Corpus Christi Health eCity Project Step 1: Health Record Summary (PHR) 1 - Person registers (self or Community Health Worker (CHW) - PHR created (CCR) - PHR distributed to key locations “Vial of Life” Repository 2 PHR PHR Firewall Fir ew all Private, Structured, and Secure If PHR is updated at any location… All copies are automatically synchronized Fir ew all all ew Fir 3 Physician Offices - View - Insert into EHR - Use for referrals PHR 3 Meditech PHR Hospital EHR - ED, - Registration, - Pre-surgical, etc. Corpus Christi Health eCity Project Step 2: Paramedic Receives Call and Searches Repository for PHR “Vial o f Life” Repository Authentication - User name / password - ACES certificate w/ card 1 Paramedic logs in and searches “Vial of Life” Repository for PHR 2 If found, data pushed into SafetyPad device. Firewall If not found, data entered into SafetyPad device. Copyright 2007 by the Healthcare Information and Management Systems Society 44
  • 45. Corpus Christi Health eCITY Project Step 3: EMS Report Completion, Upload, and Distribution EMS Report completed and uploaded to Safety Pad server Firewall EMS Report SafetyPad DB all ew Fir Fir ew all EMS Report pushed to Novo EMS Report pushed to PCP and/or other physicians EMS Report EMS Report EMS Report available in hospital Experience Using GSA Services Registration of Certificates. Three persons were identified who were willing to act as Local Registration Authorities (LRAs). One individual successfully completed the registration process. The LRA would be the agent for registering the paramedics. The commander and co-commander agreed to be the pilot subjects to test the registration process and to test the system. These registrations have yet to occur. Use of Certificates. During the registration process we learned that the City installed the software the paramedics use on a server being used by the FBI. FBI protocol prohibits the addition of any other applications to the server. This situation required a workaround that prohibited the use of certificates 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 exchange occurring once certificates are issued. 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 paramedics at the scene will have rights to the same machine at the same time. We need to differentiate the user from the machine and assure that audit trails by users are occurring. We will evaluate methods to accomplish this including the use of tokens. Copyright 2007 by the Healthcare Information and Management Systems Society 45
  • 46. Project Conclusions Overall Summary. The project met its objectives of having the RHIOs and HIEs leverage the common authentication infrastructure provided by the GSAs eAuthentication 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 larger scale deployments to provide for strong authentication using federal eAuthentication 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. Overall 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. Overall Recommendations. We recommend that RHIOs and HIEs consider leveraging the 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. Copyright 2007 by the Healthcare Information and Management Systems Society 46
  • 47. • • • • • • 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. An expanded RHIO demonstration project population should be supported to implement a common framework for the policies, procedures and standards for identity 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. Federally approved service providers are available on GSA schedules. New providers need to be added to contract on GSA IT Schedule 70. 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. Copyright 2007 by the Healthcare Information and Management Systems Society 47
  • 48. Appendix PKI There are many ways to protect confidential information; Public Key Cryptography is one of these ways. Public Key Cryptography uses a key pair to encipher and decipher information. To code or encrypt the information, the owner of a key pair makes one of the keys public. This way, anyone wanting to communicate securely with the key pair owner can encode the information with the public key. Only the corresponding key can decipher or decrypt the data. It’s important that this key be kept private and secret. What is a PKI? A PKI, is the combination of policies, practices, and procedures that formalize the use of public key cryptography to bind people or devices to a trustworthy online identity. This binding 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). The RA is tasked with properly identifying the holder of the public key and making sure that the person or device presenting the public 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. The 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 procedures that control the trusted third-party actions in binding a key pair to a trustworthy online identity. 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 organization employee Organizations: • Healthcare organization Copyright 2007 by the Healthcare Information and Management Systems Society 48
  • 49. • 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 can decrypt the message; Authentication. A public key properly bound to an online identity makes it 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 the state that it was in at the moment that it was signed, or the validation system will indicate that the digital signature is invalid because the underlying 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 based health professionals for patient information in remote clinical information systems. Access requests by applications used within provider information systems such as 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, which require a reliable binding between an image and a patient identity, as well as authentication of the health professional. Verification of authenticity, confidentiality and integrity for remote access control applications. Electronic prescription, and other clinical orders verified as having originated 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. Copyright 2007 by the Healthcare Information and Management Systems Society 49
  • 50. • Transcription validation. Using digital certificates? Certificates and keys can be used to keep personal health information in many formats i.e., e-mail messages, documents and files confidential. Privacy and security regulations, such as HIPAA and Gramm-Leach-Bliley, have made it desirable for system users to use 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 up language (XML) it will become possible to digitally sign electronic consent forms, health record 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. Bridge CA Model1. Most PKI sales have been to individual enterprises; thus, each organization can end up with a separate Certification Authority (CA). To enable a community of interest to protect shared data, however, in order to meet new federal government requirements for data security and privacy in healthcare and finance, PKI can be leveraged across organizational boundaries. This raises the issue of crosscertification—i.e., how different CAs relate to each other. Three Methods The Hierarchy Model. There are three possible ways in which CAs can be cross-certified: the hierarchy approach, the mesh approach and the bridge approach. In a hierarchical pattern, trust cascades downward from the highest CA. But it’s not always easy to decide on which CA deserves to be at the top. For example, how secure is the CA? How up-todate are its Certificate Revocation Lists (CRLs)? In other words, why does one particular CA deserve to be the source of trust? The Mesh Model. The second approach, the mesh model, is a peering arrangement; each pair of CAs establishes a cross-certification. This works fine, as long as the number of CAs is limited—somewhere around six. But, as the number of CAs grows, the number of required cross-certifications also grows, and exponentially. For example, three CAs need 1 Excerpt from an article written for Business Communications Review, 12/2002, by Project Leader Pete Palmer. Copyright 2007 by the Healthcare Information and Management Systems Society 50
  • 51. only three cross-certs, but eight CAs require 56, and 12 CAs need 132 cross-certs. Oh, and 300 CAs need 44,850. In short, scaling is a non-trivial issue. The Bridge Model. The bridge model comes out of work done to cross-certify government organizations, Half a dozen federal agencies, two states and the Canadian government were among the early participants in the Federal Bridge Certification Authority (FBCA), a project in which a number of PKI vendors and MitreTek, a systems integrator, played key roles. The FBCA was conceptualized as a PKI hub that would provide an efficient way to link agencies’ CAs, which were originally designed for intra-agency applications. By crosscertifying CAs through the FBCA, which acts as a trusted third party, an agency that needs to accept a certificate from another federal, state or local agency to conduct an electronic transaction will know that the certificate can be trusted. In one test, as shown in Fig. 6: The U.S. Federal PKI, different PKI domains, using different CA products and different X.500 directories, were successfully cross-certified. The FBCA uses an X.500 directory framework with chaining between directories and client access using LDAP (Lightweight Directory Access Protocol). For more information on the FBCA, visit www.cio.gov/fpkisc or www.csrc.nist.gov/pki. The FBCA model holds the promise of overcoming the technical problems inherent in the other two methods when it comes to securing communications beyond one organization. The FBCA framework also includes guidelines for resolving issues of policy compatibility, e.g., on how participating CAs should keep their directories secure and up to date. In short, the bridge CA approach has been proven, which should help give PKI a better reputation going forward. Copyright 2007 by the Healthcare Information and Management Systems Society 51
  • 52. Acknowledgements Project Lead: Pete Palmer, HIMSS Minnesota Chapter GSA Director, Identity Policy and Management, David Temoshok, GSA Program Analyst, USA Services, Intergovernmental Solutions Office of Citizens Services and Communications Office, Marc Wine HIMSS Staff: Mary Griskewicz MS, FHIMSS, Director, Ambulatory Information Systems HIMSS Liaison: Jill Redenius, Coordinator Regional Managers: Connecticut Lori Fourquet Michigan Helen Hill Mick 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 Copyright 2007 by the Healthcare Information and Management Systems Society 52
  • 53. Vendor Contributions NOVELL AET Europe: Reinoud Weijman, Mira van Houten, and Ben Jiang Juniper Networks: Michael Bowles, Jay Maciorowski, and William Huckman. References ISO TS21091 Health informatics—Directory services for security, communications and identification of professionals and patients ISO IS17090 part1,2,3 Health informatics—Public key infrastructure ISO TS26000 part1,2 Health informatics - Privilege management and Access Control ISO DTS21298 Health informatics: Functional and Structural Roles ASTM E1986 Standard Guide for Information Access Privileges to Health Information ASTM E1762 Standard Guide for Electronic Authentication of Health Care Information ASTM E2084 Standard Specification for Authentication of Healthcare Information Using Digital Signatures ASTM E2212-02a Standard Practice for Healthcare Certificate Policy FIPS 201: Personal ID Verification of Federal Employees & Contractors SP 800-63 Recommendation for E-Authentication SP 800-73: Interfaces for PIV (including Smart Cards) Card Edge PIV OMB M-04-04 FBCA Certificate Policy 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 Audit Trail and Node Authentication Profile (ATNA) Copyright 2007 by the Healthcare Information and Management Systems Society 53
  • 54. IHE Document Digital Signature (DSG) IHE Cross-Enterprise User Authentication (XUA) Liberty Alliance ID-FF 1.2 The Identity Federation Framework Liberty Alliance ID-WSF 2.0 Web Services Framework 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 Infrastructure Certificate and CRL Profile RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP RFC 3377 Lightweight Directory Access Protocol (v3): Technical Specification RFC 2259 Internet X.509 Public Key Infrastructure Operational Protocols— LDAPv2 RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework RFC 3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling. RFC 3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. RFC 2634 Enhanced Security Services for S/MIME ISO/IEC 9594-8 Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks ANSI X9.30 Part 1: Public Key Cryptography for the Financial Services Industry - Part 1: The Digital Signature Algorithm (DSA) (technically aligned with NIST FIPS PUB 186) ANSI X9.30 Part 2: Public Key Cryptography for the Financial Services Industry - Part 2: The Secure Hash Algorithm (SHA-1) ANSI X9.30 Part 3: Certificate Management for DSA ANSI X9.31 Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA) (technically aligned with ISO/IEC 9796) ANSI X9.45: Enhanced Management Controls Using Digital Signatures and Attribute Certificates ANSI X9.52: Triple Data Encryption Algorithm Modes of Operation Copyright 2007 by the Healthcare Information and Management Systems Society 54
  • 55. FIPS 140–2 Security Requirements for Cryptographic Modules. FIPS 140 (Federal Information Processing Standards Publication 140) is a United States federal standard that specifies security requirements for cryptography modules FIPS PUB 112 Password Usage FIPS PUB 180–2 Secure Hash Standard (SHS) FIPS 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 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 david.temoshok@gsa.gov Pete Palmer HIMSS Special Project Work Group Lead 612-598-4444 pete.palmer@wellsfargo.com Copyright 2007 by the Healthcare Information and Management Systems Society 55
  • 56. Mary Griskewicz 32B Director, Ambulatory Information Systems 7B HU 203-421-8317 mgriskewicz@himss.org UH Copyright 2007 by the Healthcare Information and Management Systems Society 56