esMD+AoR+L1+SWG+2+(Identity+Proofing)+White+Paper

include component="page" wikiName="siframework" page="esMD Header"

=
All of the Use Case materials listed below have been consensus-approved and published to the [|S&I Framework Repository Browser]. For un-published, draft versions of any materials refer to the appropriate S&I Phase and/or workgroup.======

Consensus voting for the esMD AoR L1 Identity Proofing White Paper is now closed. Click here to see the votes.

Click below to download the Use Case in a MS Word document:

=0. Terms= The following are definitions of specific terms used in this document. For a full list of definitions see Appendix A: Glossary.


 * esMD** – electronic submission of Medical Documentation


 * esMD Program** – the program established by CMS for the electronic submission of Medical Documentation


 * esMD Phase 1** – the first phase of the esMD Program focused on the electronic submission of PDF(s) containing medical documentation in a C62 wrapper using the NwHIN Exchange. The primary source of the submission is through certified Health Information Handlers (HIHs). esMD Phase 1 started pilot production submission of documents in September of 2011.


 * esMD Phase 1 Transaction** – the transaction specified in the Implementation Guide for Electronic Submission of Medical Documentation Project (esMD) Version 2.9 (4/17/2012)


 * esMD Gateway** – the CMS NwHIN Connect instance that receives esMD Phase I transactions for CMS


 * esMD Initiative** – the current esMD Program effort in conjunction with the ONC S&I Framework is focused on three specific use cases: 1) Provider registration, 2) secure transmission of the electronic Medical Documentation Requests, and 3) Author of Record, digital identities and digital signatures. With this initiative, the esMD Program is soliciting participation by commercial payers and including specific support for both CMS and commercial payers.


 * esMD Initiative Transactions** – the specific transactions defined by the esMD Initiative use cases and the subsequent implementation guides


 * Individual** - Healthcare providers with patient care responsibilities including physicians, advanced practice nurses, physician assistants, nurses, psychologists, emergency care providers, home health providers, definitive care providers, pharmacists and other personnel or their delegated agents involved in patient care (for the purposes of esMD Author of Record, “individual” does not apply to the patient).

=1.0 Summary= The Author of Record (AoR) Sub Workgroup (SWG) on Identity Proofing (IdP) recognizes that healthcare payers using the esMD Initiative Implementation Guides require positive proof of the identity of providers to perform the following actions:
 * Organization or Entity** – in this document, any reference to an organization or entity is to a legal entity other than an Individual. In some cases, an Individual may also be the sole individual that is the owner/subject of a professional corporation (PC) or limited liability corporation (LLC); in which case, the Individual is the live person and PC or LLC is an organization or entity. Note: The term Organization will be used in this document.
 * 1) Establish the identity of a provider to allow the transmission of Protected Health Information (see HIPAA) as part of an electronic Medical Documentation Request (eMDR).
 * 2) Replace the “wet signature” on the Document Bundle submitted in response to an eMDR.
 * 3) Determine the authorship of medical documentation used to support claims for payment for services delivered by providers.

All providers (Individuals and Organizations), as well as their designated agents, that register for the esMD Program will be required to authenticate the above actions with digital signatures created using X.509v3 signing certificates compliant with Federal Bridge Certification Authority (FBCA) Medium Assurance and issued by Credential Service Providers (CSP) that are cross-certified with the FBCA. To meet the requirements of FBCA Medium Assurance, the individuals and organizations must present proof of their identities in person or have an acceptable antecedent event. This SWG recognizes that Individuals who deliver health care services are required to prove their identity and have their professional credentials verified in-person in a number of situations: 1) prior to the issuance of professional licenses by authorized license boards, 2) prior to being permitted to deliver health care services as part of a health care organizations such as a group practice or hospital, and 3) as part of individual verification for employment. In keeping with the standard of practice in the industry, this SWG recommends that all Individuals, including those with delegated authority meet the requirements of FBCA Medium Assurance requiring an in-person event or remote identity proofing with an acceptable antecedent event.

Further, the SWG recommends that there should be a single identity proofing process from which all digital credentials can be derived for providers of healthcare, organizations associated with healthcare, and those with delegated authority.

The immediate need to identity proof Individuals can be met by existing policies and processes for FBCA Medium Assurance as implemented by CSPs cross-certified with the FBCA. The need to identity proof Organizations that are permitted to bill CMS or commercial payers will require the adoption of policies as outlined in section 8.4 of this document. We believe such policies can be created and implemented by the existing cross-certified CSPs in time for pilot activities planned for Q2 of calendar-year 2013.

The requirement to Identity Proof all Individuals and Organizations that participate in the esMD program with CMS as well as with commercial payers that implement the esMD initiative transactions may require an identity proofing process that can be scaled to accommodate 5-7 million participants. To accomplish this, the SWG recommends: =2.0 Statement of Problem and Background= Define the required process for issuing and managing digital credentials for the electronic submission of Medical Documentation to the Centers for Medicare and Medicaid Services (CMS) and commercial payers that adopt the esMD Initiative Implementation Guides.
 * Creation of a standard policy for identity proofing Individuals and Organizations that is acceptable to CSPs cross-certified with the Federal Bridge (see Sections 8.3/8.4).
 * Federation of the identity proofing process and creation of accreditation policies to permit incorporation of identity proofing as part of Individual and Organizational credentialing or accreditation in healthcare (see Section 8.8).

On September 15, 2011, the esMD Program launched a pilot to accept electronic submissions from providers via Health Information Handlers (HIHs). The current esMD Initiative will enable Medicare Review Contractors to send electronic Medical Documentation Requests, eliminating the need to send the paper letters via mail. The next release will also implement the replacement of wet signatures with Digital Signatures on the bundle of documents requested by CMS or the appropriate commercial requestor.

There is a need on CMS’s part to: 1) verify the identification of the individual or organization receiving Protected Health Information (PHI) contained in the eMDR and 2) to ensure authenticity of the documents submitted in response to the eMDR. These are requirements for participation in the esMD Program.

Three separate work groups were assembled to address Identity Proofing, Digital Credentials, Digital Signatures, and Delegation of Rights issues associated with Digital Signatures. The Identity Proofing workgroup focused specifically on standards, policies, and operational issues related to validation of the identity of Individuals and Organizations receiving digital credentials and participating in the esMD Program.

The workgroup recommendations are constrained by two primary factors; (1) the solution must be implemented within the first two quarters of calendar-year 2013, and (2) the systems that support the esMD Initiative (including esMD Phase 1) would have to meet standards established by the Federal Information Security Management Act of 2002 (FISMA).

The workgroup identified a number of relevant standards. However, considering the FISMA requirements, special emphasis was placed on NIST SP 800-63-1 and X.509 Certificate Policy for the FBCA version 2.25 in determining the core requirements for their recommendations.

The overall recommendation is that all Individuals, Organizations, and their agents must use a digital certificate to sign esMD Initiative transactions and document bundles (as defined in the esMD Initiative Author of Record Level 1 Use Case). The certificate’s root Certificate Authority (CA) must be cross certified with the FBCA at Medium Assurance or above. Additionally, the provider should authenticate to the signing module or application with at least one additional authentication factor prior to the actual signing event. Adding the additional factor meets NIST LOA 3 and supports the non-repudiation assurances necessary for valid digital signatures. As technology options for both authentication and digital signing continue to evolve, the esMD Initiative should continue to monitor and update policies as appropriate to reflect improved technological capabilities.

The meetings to review the current standards, policies, alternatives and operational issues were conducted on the schedule outlined in the table below:

Table 1: Schedule =3.0 Requirements= The following specific requirements were provided by the esMD Initiative Author of Record Level 1 workgroup:
 * **Date** || **Topic** || **Deliverable(s)** ||
 * September 26, 2012 || Standards (NIST/FBCA) || List and review of standards ||
 * October 3, 2012 || Industry examples || List and review industry examples ||
 * October 10, 2012 || Requirements for identity || Requirements for Individuals and Organizations ||
 * October 17, 2012 || RA requirements || “Certification” process for RAs ||
 * October 24, 2012 || RA processes || Combine RA with other identity and credential verification processes ||
 * October 31, 2012 || Gaps in policy and standards || Identify gaps in standards, process and policy and make recommendations ||
 * November 7-28, 2012 || Review SWG report || SWG report ||

=4.0 Assumptions= The following assumptions were made by the IdP SWG as part of their consideration of the esMD AoR Use Case: =5.0 Review of Standards= The following standards, industry implementations, white papers, and federal requirements were reviewed by this SWG as part of their review and deliberation.
 * 1) Solution must
 * be implementable for pilot in Q1/Q2 of calendar-year 2013
 * scale to all providers (any Individual or Organization that may submit a claim to a healthcare payer), healthcare payers, and agents for either party
 * minimize the operational impact required to establish, maintain, or use a digital identity and digital signature
 * allow the relying party to verify authenticity of the signature without resorting to audit logs or validation of system configuration
 * 1) Appropriate portions of the following standards as they relate to Identity Proofing must be supported
 * NIST 800-63-1 Level 3/4 (December 2011)
 * NIST 800-57 Part 1 (Revision 3 July 2012)
 * Federal Bridge Certification Authority Medium Assurance Level
 * X.509v3+ Digital Certificates
 * All esMD Initiative transactions must be digitally signed and non-repudiable by their author.
 * Document bundles must be digitally signed and non-repudiable by the responsible provider or their designated agent as identified in the eMDR transaction.
 * All delegation of rights to an agent must be must be cryptographically verifiable and non-repudiable.
 * Must comply with US government standards and regulations.
 * All certificates must be issued to Individuals or Organizations and include their unique identification number (examples: Provider NPI, Health Plan HPID, Other Entity OEID, or EIN).
 * CMS does not plan issue credentials for digital signatures.
 * The esMD Initiative Implementation Guides require digital signatures for provider registration and the receipt of electronic Medical Documentation Requests (eMDR).

Table 2: Standards, Industry Implementations, White Papers, and Federal Requirements reviewed by the IdP SWG =6.0 Industry Examples= The SWG reviewed a number of industry examples to further inform the process of evaluating appropriate standards for identity proofing. In particular we received specific presentations or reviewed published material on the digital identity efforts initiated by the DEA, DIRECT Project, SafeBiopharma, and Federal PIV.
 * || **Standard and Document Link** || **Issued By** || **Title & Version / Notes** || **Date** ||
 * **Standards** || NIST SP 800-63-1 || National Institute of Standards and Technology || Electronic Authentication Guideline || Dec 2011 ||
 * || FBCA X.509 Certificate Policy || Federal Bridge Certification Authority || X.509 Certificate Policy for the Federal Bridge Certification Authority, Version 2.25 || Dec 9 2011 ||
 * || FPKI Certification Application Requirements || Federal Bridge Certification Authority || FPKI Certification Applicant Requirements Version v1.0.6 || May 2012 ||
 * || FBCA Cross-Certification Criteria || Federal Bridge Certification Authority || Criteria and Methodology for Cross-Certification with the U.S. Federal Bridge Certification Authority (FBCA) or Citizen and Commerce Class Common Certification Authority (C4CA) Version 3 || January 25, 2012 ||
 * || FICAM Roadmap and Implementation Guidance || Federal Chief Information Officers Council || Federal Identity, Credential, and Access Management Roadmap and Implementation Guidance, Version 2.0 || Dec 2 2011 ||
 * || IETF RFC 3647 || Internet Engineering Task Force || Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework || Nov 2003 ||
 * || FPKIPA || Federal Public Key Infrastructure Policy Authority || X.509 Certificate Policy for the U.S. Federal PKI Common Policy Framework, Version 3647 – 1.17 || Dec 9 2011 ||
 * || FIPS PUB 201-1 || Federal Information Processing Standards || Personal Identity Verification of Federal Employees and Contractors || Mar 2006 ||
 * || IETF RFC 5280 || Internet Engineering Task Force || Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile || May 2008 ||
 * || IETF RFC 6711 || Internet Engineering Task Force || An IANA Registry for Level of Assurance (LoA) Profiles || Aug 2012 ||
 * || ISO Standards Catalogue || International Standards Organization || ISO standards publications are proprietary. Subcommittee/WG structure can be found here. ||  ||
 * **Industry Implementations** || 21 CFR Part 1305 (DEA) ||  || Orders for Schedule I and II Controlled Substances || Apr 1 2012 ||
 * || 21 CFR Part 1311 Subpart B (DEA) ||  || Requirements for Electronic Orders and Prescriptions – Obtaining and Using Digital Certificates for Electronic Orders || Apr 1 2012 ||
 * || DirectTrust.org ||  || All publications appear to be proprietary ||   ||
 * || Form I-9 (OMB 1615-0047) ||  || Employment Eligibility Verification, Rev. Aug 9, 2009. ||   ||
 * || SAFE-BioPharma ||  || (see White Papers section below) ||   ||
 * || ITU Security Standards Roadmap ||  || International Telecommunication Union Security Standards Roadmap, Version 2.5. Of particular note is Part 6: Identity Management Landscape: IdM standards, organizations and gap analysis, Version 2.0 || Apr 2012 ||
 * **White Papers / Industry Reports** || Document link ||  || Research collaboration in the cloud: How NCI and Research Partners are using Interoperable Digital Identities, Digital Signatures and Cloud Computing to Accelerate Drug Development, National Cancer Institute, Federal Bridge Certification Authority, Bristol-Myers Squibb and SAFE-BioPharma ||   ||
 * **Federal Requirements** || RMH Vol III Standard 3-1 Authentication ||  || CMS Risk Management Handbook Volume III, Standard 3.1: CMS Authentication Standards, Version 1.2 || Jul 31 2012 ||

6.1. DEA - Ordering of Controlled Substances

 * Physicians have the option of e-prescribing controlled substances as of June 1, 2010, if they comply with specific requirements, as described below.
 * Physicians must first undergo a verification process (either in person or remotely) in order to receive authorization to e-prescribe controlled substances.
 * Access controls must be established prior to e-prescribing controlled substances.
 * Physicians must use a two-factor credential to e-prescribe controlled substances.
 * Physicians must comply with notification requirements if they lose their hard token or if they discover that their security controls have been compromised.
 * Physicians must use a compliant e-prescribing application in order to e-prescribe controlled substances.
 * Source: http://www.ama-assn.org/ama1/pub/upload/mm/399/dea-eprescriptions-final-rule-summary.pdf
 * Identity Proofing
 * Authentication must occur by an authorized third party (federally approved credential service provider (CSP) or CAs)
 * CSPs and CAs are required to conduct identity proofing at NIST SP 800-63-1 Assurance Level 3 (requiring either in-person or remote identity proofing)
 * Logical access controls are set after authentication credentials are issued, which verifies that the authenticated user has the authority to perform the requested operation (may be role-based).
 * Someone other than the prescriber needs to authenticate the prescriber
 * Credentialing can also be completed in-house within a hospital credential office, but two people must be responsible for this
 * **SWG Note: the requirement for an Individual (other than the provider) to authenticate the provider as part of the DEA process effectively makes the IdP requirement equivalent to FBCA Medium Assurance.**
 * Verification of identity is required via two-factor authentication
 * If a hard token is used, it must be a cryptographic device or meet the Federal Information Processing Standard 140-2 Security Level 1
 * Physicians can use their own digital certificate to sign eRxs for controlled substances, and can be used as part of the two-factor authentication as long as the certificate is from a CA cross-certified with the FBCA at the basic assurance level
 * Under the Interim Final Rule, e-prescribers must prove their identities using two of the three following factors:
 * Something you know, such as a password or response to a challenge question;
 * Something you have, such as a hard token or device separate from the computer; or
 * Something you are, such as biometric data.

6.2. DIRECT Project

 * Trust relationships are expressed using digital certificates. A party may choose to trust a specific certificate, as well as any certificate that cryptographically chains to a trust anchor.
 * Certificates are issued only to parties that agree to abide by specified trust policies. These policies often cover:
 * Certificate applicability (i.e., purposes for which certificates are issued)
 * Identity verification of parties
 * Security requirements of parties
 * Setting trust policy is __outside__the domain of the DIRECT Project.
 * For health information exchange, policy originates with the HITPC and ONC
 * Communities may further build upon those policies
 * DIRECT Project does not require particular policies or processes for identity proofing but is recommending compliance with FBCA Medium Assurance
 * The same X509v3 certificate issued for DIRECT Project participants is used for both signing and encryption
 * All states, implementing communities, and national HISPs do require Individuals and Organizations seeking to enroll to provide identifying information. Information required is based on:
 * What is needed to obtain a certificate
 * What is needed to establish a foundation of trust between exchange participants
 * SWG Comments:**
 * Using the same digital credential to both encrypt and sign violates the X.509v3 standard. To be compliant with standards and federal requirements, esMD Initiative transactions and esMD Author of Record require a separate private key for signing only. Federal PKI does not recognize anything called an “organizational certificate,” but it does recognize group certificates—the distinction is mostly academic. Group certificates are issued at an LOA comparable to individual certificates, but carry additional requirements, such as:
 * Defining control over the access to a private key
 * Ensuring that individuals authorized to use a group certificate have their own digital certificates at the same LOA or higher
 * Full accountability via logging.
 * **Individual** || **Organization** ||
 * * In-person proofing before a Registration Authority, trusted agent, or an entity such as a notary public
 * Requires one of: Federal Government-issued ID, READ ID Act compliant photo ID, or two non-federal IDs (one of which must be a photo ID) || * Requires organization name, postal address, documentation proving existence of the organization
 * Organization must be HIPAA covered or a BA, or a healthcare-related organization that protects PHI with HIPAA-equivalent protections
 * Also requires identity validation of the requesting organizational representative
 * Organizations further identity proof their agents ||

6.3. Safe-BioPharma

 * The SAFE-BioPharma process asserts LOA 3 identity proofing, and provides an alternative to the remote identity proofing method found in NIST SP 800-63-1 (LOA 3).
 * Conceivably, the SAFE-BioPharma process could achieve a separation of the identity proofing process from the credentialing process by using an outsourced RA. NIST SP 800-63-1 allows for this type of modular approach.
 * Additionally, it is conceivable to write a 3rd party certification policy that is also acceptable to FBCA and meets NIST SP 800-63-1 Level 4 assurance.

6.4. Personal Identity Verification (PIV) (FIPS 201-1)
=7.0 Alternative Solutions= This section lists alterative solutions that were considered and provide an evaluation of the merits of each. (Review FBCA Medium Assurance, NIST LOA 3 and NIST LOA 4)
 * For compliance with the PIV-I control objectives, departments and agencies shall follow an identity proofing and registration process that meets the requirements defined below when issuing identity credentials.
 * The organization shall adopt and use an approved identity proofing and registration process.
 * The process shall begin with initiation of a National Agency Check with Written Inquiries (NACI) or other Office of Personnel Management (OPM) or National Security community investigation required for Federal employment. This requirement may also be satisfied by locating and referencing a completed and successfully adjudicated NACI. At a minimum, the FBI National Criminal History Check (fingerprint check) shall be completed before credential issuance. Beginning with Part 2, identity credentials issued to individuals without a completed NACI or equivalent must be electronically distinguishable from identity credentials issued to individuals who have a completed investigation. Appendix C, Background Check Descriptions, provides further details on NAC and NACI.
 * The applicant must appear in-person at least once before the issuance of a PIV credential.
 * During identity proofing, the applicant shall be required to provide two forms of identity source documents in original form. The identity source documents must come from the list of acceptable documents included in Form I-9, OMB No. 1115-0136, and Employment Eligibility Verification. At least one document shall be a valid State or Federal government-issued picture identification (ID).
 * The PIV identity proofing, registration and issuance process adheres to the principle of separation of duties to ensure that no single individual has the capability to issue a PIV credential without the cooperation of another authorized person.
 * The PIV identity proofing and registration process used when verifying the identity of the applicant is accredited by the department or agency as satisfying the requirements above and approved in writing by the head of the Federal department or agency.

Table 3: FBCA Assurance Medium Level Requirements Clarification on the trust relationship between the Trusted Agent and the applicant, which is based on an in-person antecedent identity proofing event, can be found in the “FBCA Supplementary Antecedent, In-Person Definition” document. For PIV-I, credentials required are two identity source documents in original form. The identity source documents must come from the list of acceptable documents included in Form I-9, OMB No. 1115-0136, Employment Eligibility Verification. At least one document shall be a valid State or Federal Government-issued picture identification (ID). For PIV-I, the use of an in-person antecedent is not applicable. ||
 * **Level** || **Identification Requirements** ||
 * Medium (all policies) || Identity shall be established by in-person proofing before the Registration Authority, Trusted Agent or an entity certified by a State or Federal Entity as being authorized to confirm identities; information provided shall be verified to ensure legitimacy. A trust relationship between the Trusted Agent and the applicant which is based on an in-person antecedent may suffice as meeting the in-person identity proofing requirement. Credentials required are one Federal Government-issued Picture I.D., one REAL ID Act compliant picture ID1, or two Non-Federal Government I.D.s, one of which shall be a photo I.D. (e.g., Non-REAL ID Act compliant Driver’s License). Any credentials presented must be unexpired.

Table 4: NIST 800-63-1 LOA 3
 * || **In Person** || **Remote** ||
 * Basis for issuing credentials || Possession of a verified current primary government picture ID that contains Applicant’s picture, and either address of record or nationality of record (e.g., driver’s license or Passport) || Possession of a valid Government ID (e.g., a driver’s license or Passport) number and a financial or utility account number (e.g., checking account, savings account, utility account, loan or credit card) confirmed via records of both numbers. Note that confirmation of the financial or utility account may require supplemental information from the applicant. ||
 * RA and CSP actions || RA inspects photo-ID and verifies via the issuing government agency or through credit bureaus or similar databases. Confirms that: name, DoB, address and other personal information in record are consistent with the application. Compares picture to Applicant and records ID number.

If ID is valid and photo matches Applicant, then: Address confirmation:
 * If personal information in records includes a telephone number, the CSP issues credentials in a manner that confirms the ability of the Applicant to receive telephone communications at a number associated with the Applicant in records, while recording the Applicant’s voice or using alternative means that establish an equivalent level of non-repudiation; or
 * If ID confirms address of record, RA authorizes or CSP issues credentials. Notice is sent to address of record, or;
 * c)If ID does not confirm address of record, CSP issues credentials in a manner that confirms the claimed address. || RA verifies information provided by Applicant including ID number AND account number through record checks either with the applicable agency or institution or through credit bureaus or similar databases, and confirms that: name, DoB, address and other personal information in records are consistent with the application and sufficient to identify a unique individual. For utility account numbers, confirmation shall be performed by verifying knowledge of recent account activity. (This technique may also be applied to some financial accounts.)
 * CSP issues credentials in a manner that confirms the ability of the applicant to receive mail at a physical address associated with the Applicant in records; or
 * If personal information in records includes a telephone number, the CSP issues credentials in a manner that confirms the ability of the Applicant to receive telephone communications at a number associated with the Applicant in records. CSP records the Applicant’s voice or using alternative means that establish an equivalent level of non-repudiation. ||

Table 5: NIST 800-63-1 LOA 4 RA inspects photo-ID and verifies via the issuing government agency or through credit bureaus or similar databases. Confirms that: name, DoB, address, and other personal information in record are consistent with the application. Compares picture to Applicant and records ID number. //Secondary Government ID or financial account// //Current Biometric// RA records a current biometric (e.g., photograph or fingerprints) to ensure that Applicant cannot repudiate application. //Credential Issuance// CSP issues credentials in a manner that confirms address of record. ||
 * || **In Person** ||
 * Basis for issuing credentials || In-person appearance and verification of:
 * a current primary Government Picture ID that contains Applicant’s picture, and either address of record or nationality of record (e.g., driver’s license or passport), and;
 * either a second, independent Government ID document that contains current corroborating information (e.g., either address of record or nationality of record), OR verification of a financial account number (e.g., checking account, savings account, loan or credit card) confirmed via records. ||
 * RA and CSP actions || //Primary Photo ID://
 * RA inspects secondary Government ID and if apparently valid, confirms that the identifying information is consistent with the primary Photo-ID, or
 * RA verifies financial account number supplied by Applicant through record checks or through credit bureaus or similar databases, and confirms that: name, DoB, address, and other personal information in records are on balance consistent with the application and sufficient to identify a unique individual.
 * [Note: Address of record shall be confirmed through validation of either the primary or secondary ID.]**

=8.0 Recommended Solution= This SWG recommends that a process compliant with current requirements for the FBCA Medium Assurance requiring an in-person event or remote identity proofing with an acceptable antecedent event as defined below to form the basis for IdP of Individuals and Organizations for the esMD Program. The IdP process must require additional specific information for Individuals and Organizations that will bill CMS and commercial payers (see Section 8.5). The resulting Identity Proofed Individuals and Organizations may be issued digital credentials by any of the FBCA cross-certified CSPs/CAs at the same or a reduced level of assurance based on the single Identity Proofing event (along with any required repeat IdP process due to expiration or revocation). To improve access and lower cost of IdP of Individuals and Organizations, the SWG also recommends establishing policies and standards to create a federated RA process that can take advantage of current in-person HR and credentialing process that are part of the delivery of healthcare services.

8.1. Recommended Standards
After an extensive review of the various standards, white papers, and industry examples cited in sections 5 and 6 of this white paper, the SWG recommends adoption of the relevant portion of the following specific standards.

Table 6: Recommended Standards for Adoption
 * **Standard and Document Link** || **Issued By** || **Title & Version / Notes** || **Date** ||
 * NIST SP 800-63-1 || National Institute of Standards and Technology || Electronic Authentication Guideline || Dec 2011 ||
 * FBCA X.509 Certificate Policy || Federal Bridge Certification Authority || X.509 Certificate Policy for the Federal Bridge Certification Authority, Version 2.25 || Dec 9 2011 ||
 * FPKI Certification Application Requirements || Federal Bridge Certification Authority || FPKI Certification Applicant Requirements Version v1.0.6 || May 2012 ||
 * FBCA Cross-Certification Criteria || Federal Bridge Certification Authority || Criteria and Methodology for Cross-Certification with the U.S. Federal Bridge Certification Authority (FBCA) or Citizen and Commerce Class Common Certification Authority (C4CA) Version 2.2 || October 22, 2008 ||
 * FICAM Roadmap and Implementation Guidance || Federal Chief Information Officers Council || Federal Identity, Credential, and Access Management Roadmap and Implementation Guidance, Version 2.0 || Dec 2 2011 ||

8.2. RA Functions
The Registration Authority (RA) is the organization that collects and verifies each Individual’s and Organization’s identity and information to be entered into the corresponding public key certificate. The RA performs its function in accordance with the Federal Common Policy or the approved CSP, and any other relevant agreements or policy documents. Areas and activities overseen by the RA include, but are not limited to:
 * In person proofing
 * Verification and validation of identity documents
 * Enrollment and registration
 * Oversee identity issues related to
 * Credential issuance
 * Credential usage
 * Credential revocation
 * Post issuance updates and additions
 * Credential re-issuance

Table 7: Functional Areas Supported by RAs and CSPs/CAs
 * = **Functional Area** ||= **Credential Service Provider** ||= **Registration Authority** ||
 * Key management functions, such as the generation of CA key pairs, the secure management of CA private keys, and the distribution of CA public keys ||= YES ||= NO ||
 * Establishing an environment and procedure for certificate applicants to submit their certificate applications (e.g., creating a web-based enrollment page) ||= YES ||= YES ||
 * The identification and authentication of individuals or organizations applying for a certificate ||= YES ||= YES ||
 * The approval or rejection of certificate applications ||= YES ||= YES ||
 * The signing and issuance of certificates ||= YES ||= NO ||
 * The publication of certificates in a repository, where certificates are made available for potential relying parties ||= YES ||= NO ||
 * The initiation of certificate revocations, either at the subscriber’s request or upon the entity’s own initiative ||= YES ||= YES ||
 * The revocation of certificates, including by such means as issuing and publishing Certificate Revocation Lists (CRL) or providing revocation information via Online Certificate Status Protocol (OCSP) or other online methods ||= YES ||= NO ||
 * The identification and authentication of individuals or organizations submitting requests to renew certificates or seeking a new certificate following a re-keying process, and processes set forth above for certificates issued in response to approved renewal or re-keying requests ||= YES ||= YES ||
 * A common reason for breaking up the registration process as described above is to allow the subscriber to register or obtain tokens for use in two or more environments. This is permissible as long as the tokens individually meet the appropriate assurance level.
 * If a valid credential has already been issued, the CSP may issue another credential of equivalent or lower assurance. In this case, proof of possession and control of the original token may be substituted for repeating the identity proofing steps (this is a special case of a derived credential). Any requirements for credential delivery at the appropriate LoA shall still be satisfied.

8.3. Identity Proofing of Individuals
The process that the RA follows to IdP Individuals is well understood and clearly defined in the references cited in section 8.2 and below. The following is a general summary of an expanded process that utilizes an **Accredited** RA that is not necessarily associated with a single CSP.
 * 1) Individual fills out application for Identity Proofing with Accredited RA
 * 2) Individual assembles required documents and picture IDs
 * 3) Verification of identity proofing process compliant with FBCA Medium Assurance requiring an in-person event or remote identity proofing with an acceptable antecedent event as part of:
 * 4) Dedicated RA current process
 * 5) Provider organization in-person verification process:
 * 6) Credentialing (e.g. for delivery of services in a hospital)
 * 7) HR process (e.g. for employment)
 * 8) In-Person license process (State, DEA, FDA, other)
 * 9) Public Notary (limitations may be required as part of certificate policy)
 * 10) RA minimum process
 * 11) Records documents and biometric (such as picture or fingerprint)
 * 12) Validates documents to primary source
 * 13) Compares and verifies demographic information (e.g. name, age, gender, DoB, address, contact number(s))
 * 14) Verifies NPI or other Payer Identification (e.g. verify name, address and other demographic information associated with NPI or other Payer Identification) (Note: demographics / address must be maintained/updated by individual prior to identity proofing)
 * 15) Issues confirmation or rejection to address of record
 * 16) Issues Proof of Identity to specified CA if successful

Table 8: FBCA Medium Assurance Requirements Clarification on the trust relationship between the Trusted Agent and the applicant, which is based on an in-person antecedent identity proofing event, can be found in the “FBCA Supplementary Antecedent, In-Person Definition” document. For PIV-I, credentials required are two identity source documents in original form. The identity source documents must come from the list of acceptable documents included in Form I-9, OMB No. 1115-0136, Employment Eligibility Verification. At least one document shall be a valid State or Federal Government-issued picture identification (ID). For PIV-I, the use of an in-person antecedent is not applicable. || Note: An Accredited RA may use an antecedent in-person process as long as it meets the requirement found in the “FBCA Supplementary Antecedent, In-Person Definition” document.
 * **Level** || **Identification Requirements** ||
 * Medium (all policies) || Identity shall be established by in-person proofing before the Registration Authority, Trusted Agent or an entity certified by a State or Federal Entity as being authorized to confirm identities; information provided shall be verified to ensure legitimacy. A trust relationship between the Trusted Agent and the applicant which is based on an in-person antecedent may suffice as meeting the in-person identity proofing requirement. Credentials required are one Federal Government-issued Picture I.D., one REAL ID Act compliant picture ID1, or two Non-Federal Government I.D.s, one of which shall be a photo I.D. (e.g., Non-REAL ID Act compliant Driver’s License). Any credentials presented must be unexpired.

8.4. Identity Proofing of Organizations
The process that the RA follows to IdP Organizations is not currently defined in the references cited in section 8.2. The following is a general summary of a recommended process that relies on an IdP individual and attested relationship with the Organization to be IdP.
 * Authorized representative fills out application for Identity Proofing with Accredited RA
 * Authorized representative assembles required documents
 * Papers of incorporation
 * State license
 * Federal tax ID
 * Motion by board of directors for representative to act on organizations behalf
 * Authorized representative with prior identity proofing and valid digital credentials submits documents and personal ID as part of identity process:
 * Records documents and biometric of representative (such as picture or fingerprint)
 * Validates document to primary source and verifies and compares demographic information
 * Verification of NPI or other Payer Identification (e.g. verify name, address and other demographic information associated with NPI or other Payer Identification) (Note: demographics / address must be maintained/updated prior to identity proofing as part of this process)
 * Issues verification to address of record for Organization
 * Issues Proof of Identity to CA

8.5. Identity Proofing Policy specifics
While the industry currently has policies for identity proofing individuals as part of the work done by the federal government (see standards for FBCA, NIST, FICAM, PIV), the specifics of identity proofing Individuals and Organizations for healthcare delivery and administrative purposes need be considered when developing new IdP policies. When defining specific healthcare IdP policies for RAs, the following specifics must be considered in addition to those required by FBCA Medium Assurance:
 * Individuals
 * Validation of currently valid NPI or alternate payer ID number
 * Organizational
 * Validation of currently valid NPI or alternate payer ID number
 * Proof of existence (e.g. licensed in state)
 * Proof individual has right to represent the organization
 * Proof individual has previously been IdP at same or greater Level of Assurance

8.6. Recognition of Existing Identity Proofing
The SWG recommends that existing identity proofing processes associated with the issuances of Digital Credentials that meet or exceed the requirements for FBCA Medium Assurance should be considered valid for esMD until such time as specific policies are developed, approved, and adopted by esMD. Examples of acceptable current identity proofing processes include those that meet or exceed:
 * FIPS 201-1 for PIV
 * FBCA X.509 Certificate Policy Medium Assurance
 * NIST 800-63-1 LOA 4

8.7. Revocation Process
A certificate shall be revoked when the binding between the subject and the subject’s public key defined within a certificate is no longer considered valid. Examples of circumstances that invalidate the binding are: Whenever any of the above circumstances occur, the associated certificate shall be revoked and placed on the CRL.
 * Identifying information or affiliation components of any names in the certificate become invalid.
 * Privilege attributes asserted in the subscriber’s certificate are reduced.
 * The stipulations of the subscriber agreement have been violated.
 * There is reason to believe the private key has been compromised.
 * The subscriber or other authorized party (as defined in the CSP) asks for his/her certificate to be revoked.

Who may revoke a certificate?
 * CSP/CA may summarily revoke certificates it issued to maintain the integrity of the system. A written notice and brief explanation for the revocation shall subsequently be provided to the subscriber and responsible RA.
 * The CSP/CA can request the revocation of a subscriber’s certificate on behalf of any authorized party as specified in the CSP. A human sponsor may request that the certificate he represents be revoked. Other authorized agency officials may request revocation as described in the CSP.
 * A request to revoke a certificate shall identify the certificate to be revoked, explain the reason for revocation, and allow the request to be authenticated (e.g., digitally signed). The steps involved in the process of requesting a certification revocation are detailed in the CSP.

Issues that need to be addressed in the CSP:
 * Death of an Individual or discontinuation of an Organization and the impact on transactions in process.
 * Implications for claim/documentation submission post-revocation.
 * Legal issues with delegation for rights to corporations that must survive death and potentially termination of the relationship.

8.8. Requirements for and Certification of Federated RAs
To accommodate the anticipated growth in demand for Individual and Organizational identity proofing, federation of the RA process is desired. The recommendation from this SWG is to use existing healthcare settings where the personal, professional, or legal status of Individuals and Organizations are currently reviewed and verified. Specific examples where this is done include:
 * Credentialing of licensed individual providers by hospitals and physician groups or their delegated agent.
 * Enrollment of licensed individual providers with payers.
 * Licensing of healthcare professionals by state license boards.
 * Accreditation of Organizations by entities such as The Joint Commissions, College of American Pathologists (CAP), COLA, etc.
 * Commercial Health Insurers
 * Updated registration process for national insurance (e.g. expanded PECOS)

This SWG recommends that esMD work with the FPKIPA and existing cross certified CSPs/CAs to establish a federated RA infrastructure. This will entail the following: Note: May be able to use existing Cross Certified CA (FBCAxCA) process/methods as a starting point and create agreement among FBCAxCAs.
 * Creation of policies acceptable to FBCA and the cross-certified CSPs/CAs for:
 * Identity proofing Individuals
 * Identity proofing Organizations
 * Requirements for federated RAs
 * Requirements for accreditation of RAs
 * Accreditation process for RAs to be administered by cross-certified CSPs/CAs or an accredited third party (e.g. current organization that licenses, reviews or accredits existing health care organizations)
 * Certification process for third party RA accreditation organizations

The information collected by Accredited RAs for identity proofing should allow any FBCA cross-certified CA to issue credentials (this is not the case as of the time of this writing). Every cross-certified CA has been vetted so that its policies and practices are deemed compliant (but not necessarily comparable to) the Federal PKI Policy. The latest language in the X.509 Certificate Policy should be applicable to establishing a process where proofing done by RAs is accepted by cross-certified CAs and implementable by third party organizations.

RA requirements are spelled out in the CSP policies. The RA has to itself be credentialed at the same LOA, or higher, that it is credentialing. The policy OID is in every X.509v3 certificate. Accreditation Entities could not only identity proof organizations, but also certify that the organizations’ identity proofing processes meet requirements. Thus, hospitals and similar entities could act as RAs for the sake of identity proofing individuals.

The SWG recommends a single identity proofing process conducted by one RA. One or more CSPs/CAs may issue specific certificates or credentials based on that identity proofing at the same LOA or below.

8.9. Process Flow and RA Communication with CSPs
The various entities and interactions that comprise the e-authentication model used here are illustrated below. The shaded box on the left shows the registration, credential issuance, maintenance activities, and the interactions between the Subscriber/Claimant, the RA and the CSP. The usual sequence of interactions is as follows: Figure 1: Entities and Interactions within the e-authentication Model

The CSP maintains the credential, its status, and the registration data collected for the lifetime of the credential (at a minimum).
 * 1) An individual Applicant applies to an RA through a registration process.
 * 2) The RA identity proofs that Applicant.
 * 3) On successful identity proofing, the RA sends the CSP a registration confirmation message including all of the registration information in secure manner (all defined in the CSP)
 * 4) A secret token and a corresponding credential are established between the CSP and the new Subscriber.

CSPs will generally assign a finite lifetime when issuing credentials to limit the maintenance period. When the status changes, or when the credentials near expiration, credentials may be renewed or re-issued; or, the credential may be revoked and/or destroyed. Typically, the Subscriber authenticates to the CSP using his or her existing, unexpired token and credential in order to request re-issuance of a new token and credential. If the Subscriber fails to request token and credential re-issuance prior to their expiration or revocation, he or she may be required to repeat the registration process to obtain a new token and credential. The CSP may choose to accept a request during a grace period after expiration. =9.0 Gaps= Significant gaps exist in current standards, policies and operational processes that must be addressed to implement the recommendations from this SWG. Satisfying these gaps is work that should be undertaken during calendar-year 2013 to support the Individual and Organizational Identity Proofing required for expansion of the esMD Program and users of Author of Record implementation guides. These gaps include: =10.0 Risks, Issues, and Obstacles= The following are potential risks, issues, and obstacles with regard to the recommended IdP that were identified by this SWG. =Appendices=
 * Specific requirements for identity proofing health care individuals at FBCA Medium Assurance requiring an in-person event or remote identity proofing with an acceptable antecedent event for esMD (e.g. validation of NPI or other Payer ID)
 * Standards and policy for identity proofing health care organizations at FBCA Medium Assurance for esMD (e.g. for group certificate)
 * Solicit additional criteria for organizational IdP as part of policy creation
 * Method for updating policy as environmental conditions change
 * May have specific requirements based on type of organization (e.g. DME)
 * Policy and process for federating RA activities
 * Common policies and process across FBCA cross-certified CSPs to support federated RAs
 * Policy for accreditation of organizations to certify federated RAs
 * Specific policy items for consideration
 * Impact of “identity revocation” (e.g. person dies, organization no longer does business) –implications for claim/documentation submission post “revocation”
 * Individuals with multiple identities (multiple RAs IdP and multiple CSPs issue)
 * Process to make all of this operational
 * Role of CMS
 * Role of ONC
 * Role of FBCA, NIST, and FICAM
 * The burden to individual providers to undergo in-person ID-proofing
 * Risk to organizations to identity proof individuals or entities
 * Time and cost to create and implement all required policy
 * Issues when individuals move from one organization to another that is/was acting as an Accredited RA
 * Unable to make the expanded process operational

Appendix A: Glossary
A. **Authentication** (NIST) - Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information. [NS4009] B. **Author (of Record)** - The individual that creates a record. C. **Certificate Authority** (NIST) - An authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CARLs or CRLs. D. **Credential** (NIST) - An object or data structure that authoritatively binds an identity (and optionally, additional attributes) to a token possessed and controlled by a Subscriber. E. **Credentialing** – the process by which personal or professional information about an Individual or Organization is verified by a third party. F. **Data Integrity** (NIST) - A property whereby data has not been altered in an unauthorized manner since it was created, transmitted or stored. Alteration includes the insertion, deletion and substitution of data. G. **Decryption** - The reverse process of encryption, i.e., to make the encrypted information readable again. H. **Delegation of Rights** - The ability to delegate rights or authority to another to act in a specific capacity on behalf of the grantor of the right. I. **Digital Certificate** (NIST) - A digital representation of information which at least (1) identifies the certification authority issuing it, (2) names or identifies its subscriber, (3) contains the subscriber's public key, (4) identifies its operational period, and (5) is digitally signed by the certification authority issuing it. J. **Digital Id Management** - A trusted authority is responsible for creating the key pair, distributing the private key, publishing the public key and revoking the keys as necessary. The “Passport Office” of the Digital World. The keys and their associated information (e.g. Digital Certificate) are typically stored as software tokens, browser certificate stores, and hardware tokens (Smart Cards, USB Tokens). K. **Digital Signatures** - An artifact appended to a record as a result of a user’s intended action wherein that memorializes a signing event by a process that digitally signs a document or transaction using the private key component of his certificate. (From NIST - The result of a transformation of a message by means of a cryptographic system using keys such that a Relying Party can determine: (1) whether the transformation was created using the private key that corresponds to the public key in the signer’s digital certificate; and (2) whether the message has been altered since the transformation was made.) (From 800-63-1 an asymmetric key operation where the private key is used to digitally sign data and the public key is used to verify the signature. Digital signatures provide authenticity protection, integrity protection, and non-repudiation). L. **Encryption** - In cryptography, encryption is the process of transforming information (referred to as plaintext) using an algorithm (called a cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key. M. **Identity** - A unique name of an Individual or Organization. Since the legal names of an Individual or Organization are not necessarily unique, the ID must include sufficient additional information (for example an address and NPI number) to make the complete name unique. N. **Identity Proofing** - The process by which the credential issuer validates sufficient information to uniquely identify an Individual or Organization applying for the credential. It proves that the ID exists, proves the applicant is entitled to that ID, and addresses the potential for fraudulent issuance of credentials based on collusion. O. **Non-repudiation** (NIST) - A service that is used to provide assurance of the integrity and origin of data in such a way that the integrity and origin can be verified by a third party. This service prevents an Individual or Organization from successfully denying involvement in a previous action. P. **Policy OID** – The OID (Object Identifier) is a specialized formatted number that is registered with an internationally recognized standards organization. The unique alphanumeric/numeric identifier registered under the ISO registration standard to reference a specific object or object class. In the federal government PKI they are used to uniquely identify each of the seven policies and cryptographic algorithms supported. Q. **Public Key Infrastructure** - A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates. R. **Registration Authority** (NIST) - An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates. S. **X.509v3+** - Includes X.509 version 3 and all subsequent versions [RFC 5280 and its predecessors]

Appendix B: References
• CMS Internet Only Manuals (IOM)

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"