CORE+Phase+II+Current+Profile+Documentation

=**Issue:** **CMS esMD Security Guidance**=


 * Sponsor(s):** The CMS

**Problem Statement**
CMS receives requests for reimbursements. This results in a CMS request for supporting documentation from the providers. Today, this is a bi-directional dialog largely accommodated via FAX and mail (paper based). The CMS plans to leverage the Nationwide Health Information Network in support of this workflow for the provider-to-CMS evidence submission transaction. (The initial request for evidence transaction will remain paper/FAX based for now.). The CMS is now seeking implementation guidance from the Nationwide Health Information Network Security and Privacy workgroup on the appropriate way to use the Nationwide Health Information Network security model. Specifically, the method of determining trust between the entities. They've asked that we work with them each week in their esMD Wed meeting and in separate Sec and Priv Workgroup meetings as deemed appropriate.

In Process (90% complete)
 * Status:**

**Proposed Solution**
The Nationwide Health Information Network Security and Privacy Workgroup suggests**:**
 * 1) Using the same OID for both the organizational ID and home community ID.
 * 2) Use FIPS approved TLS with x.509 certificate based mutual authentication as per CAQH Core II and the Nationwide Health Information Network 2010 Messaging Platform specification. Note that it is essential that both client and servers be configured properly in order to achieve FIPS compliance. Please see NIST SP800-52 (or it's successor) for guidance on best practices related to TLS usage. Note that no versions of SSL are currently approved for FIPS compliance. Also note that as of this writing, SP800-52 references and recommends TLS version 1.0. However this version of TLS is depreciated, and the Nationwide Health Information Network Security and Privacy Workgroup recommend TLS version 1.2 which is the currently approved latest version of the TLS family of protocols. The new proposed text may be found at: TLS Encryption Clarification

From SP800-52 Executive Summary: "While SSL 3.0 is the most secure of the SSL protocol versions, it is not approved for use in the protection of Federal information because it relies in part on the use of cryptographic algorithms that are not FIPS-Approved. TLS, when properly configured, is approved for the protection of Federal information."

From SP800-52 Section 2.1: "However, because SSL 3.0 is not approved for use in the protection of Federal information, (Section 7.1 of [FIPS140Impl]), TLS must be properly configured to ensure that the negotiation and use of SSL 3.0 never occurs when Federal information is to be protected. "

**Outstanding Issues**

 * 1) Is there a legal requirement for the CMS to log the user or system sending the evidence documents?
 * 2) Melanie Combs-Dyer confirmed that the CMS trusts the HIH at they gateway level, they will log NPI that will probably be in the SAML header. This is phase 1a. They still need to complete the CMS onboardig process. The trust will be via standard 2-way-SSL. In phase 1, where they are receiving PHI, not sending PHI, they don't need to log additional details. They plan to decide soon.
 * 3) What Nationwide Health Information Network profile will be used to submit the data?
 * 4) esMD
 * 5) What is the payload of the submission?
 * 6) bin64 encoded x.12 messages
 * 7) Can/should we remove the requirement to use SAML since it may provide little to no value in this exchange?
 * 8) Will be addressed next by the CAQH and esMD workgroups.
 * 9) What are the compatibility goals? Will the CMS be using the existing CONNECT gateway or is this fresh development (or something else entirely)?
 * 10) Both ends of the exchange will likely use the CONNECT gateway, but the HIH is allowed to use non-CONNECT software. The CMS intends to use CONNECT.
 * 11) The CAQH Core II documentation appears to be contradictory internally and may conflict with FIPS compliance.

Research
From the CAQH Core II Connectivity Rule:

__Section 3.1__ The following is a list of standards and their versions that this Rule is based on: ... SSL Version 3.0

__Section 4.3.2 Submitter Authentication and Authorization Handling__ ... 2. X.509 Certificate based authentication over SSL (Submitter Authentication Standard D in the Conformance Requirements, §4.1), using the Secure Sockets Layer (SSLv3.0) open standard for client certificate based authentication.

__In table 4.4.2 (normative)__

Required for both if X.509 Client-certificate authentication over SSL/TLS is not used.

__Foot note 19 states:__ 19 This type of authentication is consistent with the IHE’s Audit Trail and Node Authentication (ATNA) profile.

__6.2 References__ Note: These were used for Rule creation as well as to create the analysis artifacts as part of CORE Phase II Connectivity. ... Internet Engineering Task Force (IETF) TLS 1.1 Specification http://tools.ietf.org/html/rfc4346.txt

__http://wiki.ihe.net/index.php?title=ATNA_FAQ__ States: The IHE ATNA and XDS Integration profiles require the use of the Transport Layer Security Protocol, or TLS. TLS was originally defined by [|RFC 2246] and updated by [|RFC 3546].

Below is a list of vendors that have been identified as in-use by the Nationwide Health Information Network and CMS participants, along with statement of compliance by those vendors. To do: Need to pull NIST FIPS 140-2 validated vendor pages and insert a link.
 * Vendor Support:**

Sun Metro: Supports various security standards: Single Socket Layer (SSL)v2, SSLv3, Transport Layer Security (TLS) 1.0, X.509 certificates, PKCS #11, FIPS-140, and 168-bit step-up certificates. []

Microsoft: Appears to have only recently added support for TLS 1.2 TBD

IBM: TBD

Others: TBD

For CAQH Phase III, we have an opportunity to converge. We'd ideally want to use the same profile for other payers, and others, such as those using CAQH software. They key point of contention is SAML support. The CMS may want to push all information into the XDR metadata rather than in the SAML header. This would make support for other profiles easier and more consistent since the CMS would always use the payload for this information. For those using CONNECT, this would require the policy enforcement to move from the CONNECT internal policy engine to the CMS business logic components. If we remove SAML from the profile for CAQH or others, then what changes would need to made to CONNECT? It has been suggested that CONNECT will have to be modified since it requires SAML now. Need to validate this with the CONNECT team.
 * Brainstorming:**

TBD: Will the Provider NPI will be a SAML attribute?

1) Eric Heflin: will reach out to the CONNECT team to confirm that SAML is required, and what the impact would be to them of removing it. Done. 2010-09 EJH confirmed with the CONNECT team that SAML is assumed to be present and that the effort of removing it would be non-trivial. 2) Discuss the CAQH team's ability to support SAML with their workgroup. 3) Determine if the CAQH Core II allows for the same "2-way-SLL" implementation as does the Nationwide Health Information Network's 2010 Authorization Framework Production Specification.
 * Next steps:**

1) EJH confirmed on 2010-09-30 that the current version of TLS is 1.2 as per the Internet Engineering Task Force's list of current official standards: http://www.rfc-editor.org/rfcxx00.html 2) EJH confirmed that the common use of 2-way-SSL is technically implemented as TLS version 1.2. SSL and prior versions of TLS are officially depreciated by the IETF due to vulnerabilities. Also confirmed that TLS 1.2 supports what is commonly known as 1-way authentication (where, for example, a web browser is uses an anonlymous certificate to communicate with a server containing a certificate issued by a trusted Certification Authority such as Entrust), and what is commonly known as 2-way-SSL whereby both the client and server endpoints have an x.509 certificate installed that was issued by a mutually trusted Certification Authority.
 * Research:**

Support the full range of healthcare administrative transactions.
 * Related Goals:**

The CMS will use the Nationwide Health Information Network CONNECT .3.1 gateway. The HIHs are not federal contractors, and so will currently not be able to join the Nationwide Health Information Network Exchange formally.

FIPS 140-2 CAQH Core II and the pending Core III connectivity rules Nationwide Health Information Network 2010 Production Specs Current CONNECT implementation
 * Dependencies and Constraints:**


 * Requirements:**
 * 1) The CMS states that they trust the gateways, and that trust of users or systems behind the gateway is implied.
 * 2) The CMS case number must be specified in the evidence submission to allow the case worker to associate the evidence with a case.


 * Out of Scope:**
 * 1) Since the CMS trusts gateways, there is no CMS requirement to log the individual system or user placing the request.
 * 2) The initial request for the evidence documents will remain out of band (paper, FAX) for now.
 * 3) There will be no routing or relay of the evidence document message at this time.

HIH = Health Information Handler
 * Definitions:**


 * Other Related Issues:**
 * 1) The CAQG Core II communications rule has two methods for authentication 1) username/password; or 2) x.509 on the channel.
 * 2) Today: They use X12, EDI using delimited text (HL7 2x like).
 * 3) CAQH: Has developed specifications for delivering these X12 payloads using web services. CORE Phase II 270 "connectivity rule" defines this. A "claims attachment" X12-275 for the medical evidence would come from providers to justify reimbursement for procedures. They are seeking to use Nationwide Health Information Network messaging platform and the CAQH platform to converge. Using SOAP 1.2 over HTTP(S). Using TLS. Outstanding issue: How should the info be encoded, acknowledgment of the submission, and authentication (our work). Section 4.3.2. Using username/password and x.509 certificate over 2-way-SSL.
 * 4) CAQH is working on Phase III. We have a chance to converge and influence more.


 * Approach Number (in no particular order)**
 * || ===**Brief Description**=== || ===**Detailed Description**=== || ===**Pros**=== || ===**Cons**=== || ===**Ranking**=== ||
 * 1 || TBD || TBD || TBD || TBD || TBD ||

__2010-10-19__ Eric H contacted Gavin O'Brien, and he redirected me to Matthew Scholl at the NIST regarding these issue. I emailed Matthew, who was on vacation, the following questions and discussion topics:
 * Updates:**

The specific issues are: 1. What are the precise, approved, version or versions of TLS and/or SSL that can be used for federal agencies for the purpose of national healthcare information exchange? 2. I find that the FIPS 140-2 seems to be the latest guidance document, but it doesn’t specifically mention any version of TLS or SSL. It seems though SP 800-52 that does mention specific versions (see below for text from it) may be growing out of date since SSL 3.1 IS the same as TLS version 1.0 to my knowledge. Also SP 800-52 doesn’t mention which versions of TLS are approved (1.0, 1.1, or 1.2) that I see. Is this because it is implied that TLS 1.0 is the exact, and only FIPS “approved” version? Or is the entire TLS family approved? 3. SP 800-52 mentions that TLS must be properly configured. Is there more detailed guidance? For example, auto re-negotiation settings? Crypto families? 4. Are FIPS 140-2 and SP 800-52 the appropriate guidance documents? Will they be updated in the near future? Will the update also be a 140* series document, or a Special Publication, or something else? 5. We want to have a reference in our text to the appropriate current and any anticipated future NIST FIPS document or documents. Our text may read something like: Normative: Organizations utilizing this specification MUST use TLS 1.0, 1.1, 1.2, or the latest guidelines as issued by the NIST in their 140-2/SP 800-52 publication family. In the event the NIST provides TLS version requirements in a publication other than 140-2 or 800-52, that supersedes these documents, then that publication's guidance MUST be used instead of FIPS 140-2 and SP 800-52. Non-normative: Federal agencies are currently required to comply with the latest security rules issued by the NIST under their FIPS guidelines. Specifically, that for confidential data, federal agencies MUST use TLS 1.0 as per FIPS SP 800-52. Since security is a very dynamic area of the industry, we anticipate that the FIPS guidelines will change while this specification is still current and implementers are cautioned to create their implementations in such a way that the version of TLS, and it’s associated configuration, can be changed to reflect NIST / FIPS security requirements and best practices. I’d like to discuss with you the proper way to accommodate these issues and a reference to the NIST FIPS publications in an appropriate manner that you approve of. Reference text: From the SP 800-52 Executive Summary: "While SSL 3.0 is the most secure of the SSL protocol versions, it is not approved for use in the protection of Federal information because it relies in part on the use of cryptographic algorithms that are not FIPS-Approved. TLS, when properly configured, is approved for the protection of Federal information." From SP 800-52 Section 2.1: "However, because SSL 3.0 is not approved for use in the protection of Federal information, (Section 7.1 of [FIPS140Impl]), TLS must be properly configured to ensure that the negotiation and use of SSL 3.0 never occurs when Federal information is to be protected. "

2010-09-29 tcon with the esMD Workgroup
 * Meeting notes:**

Craig Miller was absent for most of the call, so some of these issues will probably need to be revisited and confirmed with him.

Eric Heflin informed the esMD that the Nationwide Health Information Network Sec and Priv Workgroup had meet and discussed two of their requests:

1) That we feel using the same OID for the home community ID and the organization ID is the recommended best practice for their profile. The key factors leading to this recommendation are: a) The CMS is seeking to establish a trust relationship with the HIH at the gateway level only (no trust is needed for any entity behind the HIH gateway currently). b) In the future the CMS / HIH relationship may evolve to the point where the HIH is a gateway to a more complex federation of HIH's behind the gateway HIH. At that point, one of the two OIDs can be changed in the profile so that the CMS can identify the entity behind the HIH gateway responsible for the data exchange. c) The SSA and others currently us the two different OIDs to represent information specific to their profiled used of the Nationwide Health Information Network gateways. So there is precedent for the exact OID meaning to be specific to a profile.

2) That we recommend the use mutually authenticated TLS version 1.2 as the mechanism for establishing the trust relationship between the CMS and their associated HIH gateways. Reasons: a) This is compatible with the existing Nationwide Health Information Network Authorization Framework. b) It appears to be compatible with one of the CAQH Core II communications options.

In addition the CMS has asked for recommendations on requiring SAML for their HIH providers (as opposed to asking the Nationwide Health Information Network to create a profile whereby which SAML was not used). They have also asked for a precise written statement of SSL vs TLS, taking into account the constraints imposed by CAQH Core II, FIPS 140-2, the Nationwide Health Information Network 2010 production specifications, and the current industry best practices. (EJH agreed to own both of these tasks.)

Tom Davidson suggested that CMS may want to ask for CONNECT (and other implementations) to provide a transcoding adapter that supports the SAML-less version of the evidence documentation push form the HIH, and then the gateway would add the SAML prior to sending it to the CMS.

Other considerations: The CAQH Core II and Core III communications rules will be broad reaching, and broad in scope: applying to other administrative transactions. So the fact the SAML is arguably not essential for the current CMS/HIH work flow should not unduly influence this decision. EJH working recommendation on the call was to keep SAML; as it provided for more flexible, robust, and secure options that will likely be of value for the broader scope of CMS and CAQH activities over time. This was only an initial recommendation; EJH asked for an appropriate amount of time to review this issue with the Sec and Priv WG before making a final recommendation.

Change Nationwide Health Information Network to not require SAML - Not a viable option at this time Change the CAQH to require SAML in phase II as a profile or constraint - Currently selected solution Change CAQH core phase III to require SAML - Not possible to impose this constraint at this time Provide a trans-coding adapter from core-connectivity compliant transactions to Nationwide Health Information Network Exchange compliant messages (adding SAML) - Would provide for behind-the-scenes compatibility with existing CMS core-connectivity and the Nationwide Health Information Network Exchange

Other: For 277 use the CMS would act as the initiating gateway.

SAML attributes of interest - Case or person ID - PurposeOfUse - Access control attribute

Next: EJH will research the TLS/SSL versioning issues and propose written text to the Sec and Priv WG members for review, and EJH will broach the topic of a SAML-less Nationwide Health Information Network profile with the next Sec and Priv WG meeting this week.

<< end of tcon meeting notes>>

Validate this page, esp. the problem statement and outstanding issues, with the esMD Workgroup. - done - Discuss with the Sec and Priv Workgroup. - done -
 * Next Steps**

The official CORE II documentation: [| http://www.caqh.org/pdf/270.pdf]
 * Annotated References**:

NIST FIPS 140-2 (with eratta): []

NIST FIPS Special Publication SP800-52 Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations []

IETF Current Standards: []

IETF TLS 1.2 Standard: []

WikiPedia Overview Page: []

SANS article of SSL and TLS FIPS compliance: []

Eric Heflin, Nationwide Health Information Network Spec Factory, Security and Privacy Workgroup Chair Thomas Davidson Raja Kailar
 * Contributors To This Page:**