Interoperability and Patient Access Rule
Frequently Asked Questions
Learn more below about how we enable payers to be operationally compliant with this new mandate by July 1st, 2021.
×
- Should the payer provide real time updates to the provider directory?
No. Payer should make the updates available within 30 days after the change has been captured within the payer system. - What is the minimum information that the provider directory API should support?
The minimum information should include name, addresses, phone numbers, and specialties. For MA organizations that offer Part D prescription drug benefits, a pharmacy director must include name, address, phone number, number of pharmacies in the network, and mix of pharmacies (e.g. retail). - Should there be a user authentication for accessing the provider directory API?
No authentication or protocol restriction should be used in accessing the provider directory information. - Where should the FHIR endpoints be made available?
It must be accessible though a public-facing endpoint on the payer’s website. - Which entities are exempted from this requirement?
QHPs in FFEs are exempt from this requirement because current regulations already require them to make provider directory information available in machine-readable format.
- Why do we need to test the FHIR infrastructure?
CMS & ONC rules require testing in all phases of product development and implementation. - How would a payer know if the vendor product is conformant to FHIR specification?
Payer should expect a conformance report from a vendor that they conform to the FHIR specification resources and profiles. - What should be tested?
• Validate individual resources and profiles
• Validate the use of standard and extended RESTful API operations
• Validate “must support” elements
• Validate the FHIR-Client - What should a payer look for in a vendor’s FHIR conformant report?
Standard FHIR 4.0.1 scope broadly covers the interactions like create, delete, history-instance, read, search-type, update, and more on the following categories of resources:
• Base
• Clinical
• Financial
• Foundation
• Specialized - What tools can be used for testing?
Tools like Inferno from healthIT.gov can be used for testing FHIR servers. HL7 workgroups like DaVinci and PDEX have test scripts that can be used to test conformance to FHIR specifications.
- What are the data sets that are in scope for patient access API?
a. Member claims comprising of inpatient, outpatient, professional, and pharmacy type of claims.
b. Clinical data sets comprising of allergies and intolerances, assessment and plan of treatment, care team members, clinical notes, laboratory, medications, patient demographics, smoking status, implantable device, vital signs, goals, health concerns, immunizations, problems, procedures, and provenance. - What are the different types of standards used in mapping of these data sets?
a. The member claims need to be mapped from the source system to CPCDS (Common Payer Consumer Data Set that meets CMS BB 2.0 API content) based FHIR resources.
b. The clinical data sets need to be mapped from the source system to USCDI v1.0 (it leverages US Core 3.1.1).
c. For a payer-to-payer data exchange encounters and clinical data can be mapped directly to US Core 3.1.1.
In instances where source system supports HIPAA X12 transactions sets, there is also a practice to map from HIPAA X12 to CPCDS. E.g. 837s from an EMR. - Who manages the member consent?
Payers who maintains the member health data are the ones who need to manage the member consent declaration and tracking. It is during the patient registration's user flow, the consent scope aligning with the intent of the information usage by the third-party app is presented to the member for granting or denying authorization. At this point it becomes member responsibility to periodically review the consent based on the third-party app's information usage policy revisions. - What to look for in a third-party app evaluation?
a. The third-party apps are evaluated to ensure member health data is not handled or exposed in unauthorized or impermissible ways. Review of app’s privacy policies for transparency around data collection, use and disclosure, this can help determine the level of consent required to support member’s health data transfer to a third-party app.
b. Technical controls. Under ONC final rule, the third-party app may be verified for controls related to transmission encryption, authentication, and authorization. - What to look for when monitoring the usage of APIs by third-party apps?
Payers need to have a policy and process for monitoring and review of API usage by the third-party apps. Key elements to be address are:
a. Periodic review of usage for security compliance, this could be detecting unusual patterns of access like frequency and operations performed.
b. Violation of privacy policies in terms of requesting access to FHIR resources that member has not provided consent for.
c. Have a periodic review cycle for third party apps re-validation.
Founded in 2004, Sagitec has focused on Public Sector and Healthcare industries. Today, Sagitec solutions are used by over 800k+ contributing employers and 5 million+ members. Sagitec’s HealConnect is an enterprise SaaS platform for Medicaid member engagement, deployed on HITRUST certified Microsoft’s Azure cloud.
Contact Us
- 422 County Road D East
Saint Paul, MN 55117
- 612-284-7130
