Patient Access on FHIR!

The Center for Medicare and Medicaid Services (CMS) has published their final “Interoperability and Patient Access Proposed Rule” that intends to “move the health care ecosystem in the direction of interoperability” and to “signal [our] commitment to the vision set out in the 21st Century Cures Act and Executive Order 13813 to improve the quality and accessibility of information that Americans need to make informed health care decisions, including data about health care prices and outcomes, while minimizing reporting burdens on affected health care providers and payers.”

This rule comes with a pretty aggressive schedule of interoperability mandates starting this fall with the registration of digital contact information (including a FHIR API endpoint) and the implementation of a modern admit, discharge and transfer (ADT) event notification scheme as well as a comprehensive attestation to a number of Promoting Interoperability Program requirements.

Transcript

1. Interoperability and Patient Access Final Rule – Summary of Requirements 2020 Summary Presentation of the CMS Interoperability and Patient Access Final Rule Healthcare Interop Boston
2. Host: Cambridge Innovation Center CIC provides flexible office space and operational support to world-class innovators and entrepreneurs. You focus on growing your business, and we take care of the rest. We host over 50 free, public events across our Boston & Cambridge sites each month. Find out more at cic.com/boston-events Questions? Email us at events@cic.com • Founded in 1999 by MIT graduates Timothy Rowe and Andrew Olmsted • Headquartered in Kendall Square • Housed Hubspot, MassChallenge, GreatPoint Energy and Google Android. • Kendall Square space has grown from 2700 to 90,000 square feet of innovation space! • Locations in Boston, Miami, Philadelphia, St. Louis and Rotterdam About CIC  Coordinator: Kat Lazell
3. Group Organizer: David Vaccaro Veteran principal software consultant with over 20 years of professional software development experience including 16 years providing direct development consultation on a range of software development projects with a primary focus on healthcare.  dvaccaro@xinonix.com  www.linkedin.com/in/david-vaccaro  github.com/davidvaccaro • SaaS Clinical Trial Management Software • DICOM Medical Image Management Software • DICOM Teleradiology Management Software • Medical Billing Management and Interfacing Software • Anesthesia Quality Reporting (AQI – QCDR – NACOR) • Post-approval Clinical Trial Registry Infrastructure (EDC/ETL, E2B Safety Reporting) • Intellectual and Developmental Disabilities Management Platform (SIS - Public Health) Experience Availability • Consultations regarding interoperability, integration and health IT • Large team-based projects together with onesightsoftware.com
4. The Rule (CMS-9115-F) The Rule was crafted by the Centers for Medicare & Medicaid Services (CMS) as a commitment to: 1. 21st Century Cures Act (section 4003) 2. Executive Order 13813 - Promoting Healthcare Choice and Competition Across the United States (section 1 (c) (iii)) 3. Affordable Care Act (1311(e)(1)(B)) 4. Social Security Act (section 1902(a)(4), 1902(a)(19), 2101(a))
5. Goals
6. Overall Goals The Rule intends to: 1. Move the health care ecosystem in the direction of interoperability 2. Improve the quality and accessibility of the information that Americans need to make informed health care decisions 3. Minimize burdens on affected health care providers and payers
7. Goals for Patients For Patients the Rule intends to: 1. Ensure patients have access to their health information electronically, through the use of common technologies (computers, smartphones and tablets) and without special effort (apps and portals). 2. Encourage patients to take charge of and better manage their health care, thereby improving long- term health outcomes. 3. Enforce access to health information and promote healthcare app development using application programming interfaces (API).
8. Goals for Providers For Providers the Rule intends to: 1. Ensure that health care providers have ready access to health information about their patients, regardless of where the patient may have previously received care. 2. Prevent health care providers from inappropriately restricting the flow of information to other health care providers and payers. 3. Ensure that better interoperability reduces burden on health care providers.
9. Goals for Payers For Payers the Rule intends to: 1. Ensure that payers make enrollee electronic health information (held by the payer) available through an API thereby enabling third party apps to make the information both accessible to the enrollee and flow seamlessly with the enrollee as they change health care and social service providers and payers. 2. Ensure that payers clearly identify which providers are within a given plan’s network in a way that is simple and easy for enrollees to access and understand.
10. Goals of Interoperability Healthcare Interoperability should: 1. Enable the secure exchange of electronic health information with, and use of electronic health information from, other health IT without special effort on the part of the user. 2. Allow for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable state or federal law. 3. Does not constitute information blocking. As defined by section 3000 of the Public Health Service Act (PHSA)
11. Ecosystem
12. Third-Party Apps! RESTful FHIR API Healthcare Information Systems Patient Ecosystem - Simplified Provider Payer Information Systems Healthcare Information Systems Payer Information Systems Provider Payer $ Payer $ Patient Access API Provider Directory API Patient Access API Provider Directory API Payer to Payer Exchange Admit Discharge Transfer Events Patient Provider
13. Ecosystem with Relationship Complexity Complexity of Interoperability Relationships
14. Ambulatory Care Centers Surgical Centers Healthcare Information Physician Practices Pharmacies Nursing Home Rehab Centers Medical Billers Telemedicine Clinics Home Care Community Public Health Support Government Universities Disease Registries Standards Organizations Life Sciences Industry Specialist Practices Patients Ecosystem with Additional Stakeholders Diagnostic Centers Payers $ Providers Third-Party Apps
15. Vendor Neutral Archive (VNA) Electronic Medical/Health Records System (EMR/EHR) Oncology Information System (OIS) Cardiovascular Information System (CVIS) Patient Monitoring Systems (central, bedside, fetal) Hospital Management System (HMS) Pharmacy Information System Patient Administration System (PAS) Scheduling System Imaging Modalities (CT, MRI, MII,PET, Ultrasound, X-ray) Medical Imaging Workstations Enterprise Master Patient Index (EMPI) Laboratory Information Management System (LIMS) Practice Management (PM) Third Party Interfaces Radiology Information System (RIS) Picture Archiving and Communicatio n System (PACS) Ecosystem of Hospital Information Sub-Systems
16. Information
17. Information 1. Patient Related Data (United States Core Data for Interoperability) • Demographics and Smoking Status • Health Concerns, Problems and Goals • Allergies, Intolerances, Medications and Immunizations • Laboratory Tests and Results (when available) • Procedures and Vital Signs and Clinical Notes (when available) • Claims Data (approved and denied) • Formulary data including covered Part D drugs and any tiered formulary structure or utilization management procedure which pertains to those drugs. • Historical back to January 01 2016! 2. Provider Related Data (Validated Healthcare Directory IG) • Name, Address, Phone Numbers, Specialty • Pharmacy directory data, including the number, mix (type of pharmacy i.e. “retail pharmacy”), and addresses of pharmacies in the plan network. Patient, Clinical and Provider Data Requirements: (support for access to these data does NOT alter obligations under existing federal and state, local or tribal laws)
18. Claims Information Claims Data Requirements: 1. Adjudicated Claims Data (CARIN Blue Button® Framework and Common Payer Consumer Data Set (CPCDS)) • Approved and Denied Claims • Even during the period of appeal for a claim denial • Include cost, provider remittances and enrollee cost-sharing • Standardized encounter for benefits covered by the plan (Medicare Part A and Part B items and services, Part D prescription drugs and supplemental benefits) • Even applies long-term care waiver services where claims are generated weekly or even daily.
19. Requirements
20. Affected Providers and Payers Who is affected? 1. Payers (Patient Access and Provider Directory APIs and Payer- to-Payer Data Exchange) • Medicare Advantage Organizations • Medicaid State Agencies and State run Medicaid programs such as Children's Health Insurance Program (CHIP) and Fee-for-Service (FFS) Programs • Managed care plans (MCOs, PIHPs, and PAHPs) • CHIP managed care entities • Qualified Health Plan Issuers (QHP) on the Federally-facilitated Exchanges (FFEs) • Excluding from Provider Directory API • Excluding from Drug Benefit Data, including Pharmacy Directory, and Formulary Data 2. Providers (ADT Event Notifications) • Hospitals • Psychiatric Hospitals • Critical Access Hospitals (CAHs) • All Providers! (Digital Contact Information and Information Blocking)
21. Digital Contact Information (Providers) Requirements: 1. CMS will Publicly Report Providers that DO NOT Have Digital Contact Information Listed within National Plan & Provider Enumeration System (NPPES) Provider Information 2. Encourage FHIR Server and/or Other Endpoints (if available) Implementation date: Late 2020
22. Public Reporting and Information Blocking (Providers) CMS will Publicly Report Providers (within Physician Compare @ Mediicare.gov) that DO NOT Attest YES to ALL THREE (3) of the Following Questions : 1. Did not knowingly and willfully take action (such as to disable functionality) to limit or restrict the compatibility or interoperability of certified EHR technology? 2. Implemented technologies, standards, policies, practices, and agreements reasonably calculated to ensure, to the greatest extent practicable and permitted by law, that the certified EHR technology was, at all relevant times –  Connected in accordance with applicable law;  Compliant with all standards applicable to the exchange of information, including the standards, implementation specifications, and certification criteria adopted at 45 CFR part 170;  Implemented in a manner that allowed for timely access by patients to their electronic health information;  Implemented in a manner that allowed for the timely, secure, and trusted bi-directional exchange of structured electronic health information with other health care providers (as defined by 42 U.S.C. 300jj(3)), including unaffiliated providers, and with disparate certified EHR technology and health IT vendors. 3. Responded in good faith and in a timely manner to requests to retrieve or exchange electronic health information, including from patients, health care providers (as defined by 42 U.S.C. 300jj(3)), and other persons, regardless of the requestor's affiliation or technology vendor? Implementation date: Late 2020
23. Patient Access API (Payers) General Requirements: (estimated 1st year cost: $1,576,829) 1. Secured API (i.e. OAUTH2 secured for both authentication and authorization) 2. Data available no later than one (1) business day after a claim is processed or the encounter data are received. 3. United States Core Data for Interoperability (USCDI) version 1 Implementation date: January 01 2021 (6 months of enforcement discretion Due to COVID-19 ) Third-Party Apps! RESTful FHIR API Payer Information Systems Payer $ Patient Access API Patient Provider Clinical Data Claims Data Synchronous GET Asynchronous Bulk Data OAUTH2 OpenID Connect Authentication Authorization FHIR Resources  Patient  Medication  Allergy  … Many More Provider Healthcare Information Systems
24. Provider Directory API (Payers) General Requirements: 1. Public API (i.e. no authentication or authorization required) 2. New and updated information must be available through the API no less that 30 calendar days after receipt. 3. Validated Healthcare Directory Specification (VHDir IG) Implementation date: January 01 2021 (6 months of enforcement discretion Due to COVID-19 ) Third-Party Apps! RESTful FHIR API Payer Information Systems Payer $ Provider Directory API Patient Provider Pharmacy Directory Provider Directory Synchronous GET Asynchronous Bulk Data FHIR Resources  Organization  Practitioner  InsurancePlan  … Many More
25. Admission, Discharge, and Transfer (ADT) Event Notifications Requirements: 1. Only for hospital that utilizes an electronic medical records system which is conformant with the standard 2. Regulatory authority by Conditions of Participation (CoPs) 3. System notification capacity must be fully operational 4. System sends notifications that must include at least patient name, treating practitioner name, and sending institution name. 5. System sends notifications at the time of: • Registration in emergency department or Admission to inpatient services • Discharge or Transfer from emergency department or inpatient services 6. System must make reasonable effort to ensure notifications to: • All applicable post-acute care services providers • Patient’s established primary care practitioner • Patient’s established primary care practice group or entity • Other practitioner, or other practice group or entity, identified by the patient Implementation date: Spring 2021 (extended to 12 months after publication Due to COVID-19 )
26. Admission, Discharge, and Transfer (ADT) Event Notifications (Providers) Implementation date: Spring 2021 (extended to 12 months after publication Due to COVID-19 ) Healthcare Information Systems Patient Provider Healthcare Information Systems Provider Admit Discharge Transfer Events Transfer Of Care HL7 V2.5.1 Over MLLP (or other) FHIR Messaging Bundle FHIR Resources  Bundle  MessageHeader  Patient OR (possibly) Over MLLP (or other)
27. Payer-to-Payer Data Exchange (Payers) Requirements: 1. The USCDI (version 1) data set must be exchanged at the enrollee’s direction and when received by a payer, incorporated into the recipient payer’s data system. 2. Sending payer would have to provide data for up to 5 years beyond coverage and Receiving payer is required to accept. 3. Data Exchanged via Patient Access API or by other means 4. Only obligated to share data in the format originally received therefore only required to be included in Patient Access API if received in compatible format from another standards-based API Implementation date: January 01 2022
28. Payer-to-Payer Data Exchange via Patient Access API (Payers) Implementation date: January 01 2022 (NO change in schedule Due to COVID-19 ) Patient Payer To Payer Exchange Coordination Of Care Payer Information Systems Payer $ Payer Information Systems Payer $ RESTful FHIR API Patient Access API OAUTH2 OpenID Connect Authentication Authorization Synchronous Or Asynchronous Bulk Data
29. Payer-to-Payer Data Exchange via Other Means (Payers) Implementation date: January 01 2022 (NO change in schedule Due to COVID-19 ) Patient Payer To Payer Exchange Coordination Of Care Payer Information Systems Payer $ Payer Information Systems Payer $ Bulk HL7 V2.5.1 Over MLLP (or other) Medical Record (PDF) Medical Record (PDF) Medical Record (PDF) Medical Record PDFs Over SFTP (or other) OR Other!
30. Standards Primary Interoperability Standards: 1. Fast Healthcare Interoperability Resources (FHIR v4.0.1) 2. Substitutable Medical Applications, Reusable Technologies (SMART) Application Launch Implementation Guide (v1.0.0) 3. OAuth 2.0 specification and OpenID Connect Core 1.0 4. United States Core Data for Interoperability (USCDI) 5. FHIR Bulk Data Access specification 6. Logical Observation Identifiers Names and Codes (LOINC®) 7. SNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) 8. The Unified Code of Units for Measure, Revision 1.9 9. HL7 v2.5.1 (ADT and Payer-to-Payer Data Exchange)
31. Fast Healthcare Interoperability Resources (FHIR) Primary FHIR Resources 100s More!
32. Publicly Accessible API Documentation Specific business and technical documentation necessary to interact with the proposed APIs be made freely and “publicly accessible”. Publicly Accessible Any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps such as: 1. a fee for access to the documentation. 2. a requirement to receive a copy of the material via email. 3. a requirement to register or create an account to receive the documentation. 4. a requirement to read promotional material or agree to receive future communications from the organization making the documentation available.
33. Documentation Requirement for APIs At a Minimum: 1. API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns 2. The software components and configurations an application must use in order to successfully interact with the API and process its response(s) 3. All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API.
34. Routine Testing and Monitoring of APIs API must properly: 1. … and routinely be tested and monitored to ensure it is functioning properly and fully and successfully implementing privacy and security features required to comply with HIPAA Privacy and Security Rules 2. Implement, maintain, update (as appropriate), and routinely test authentication features used to verify the identity of individual enrollees who seek to access their claims and encounter data and other PHI through the API. 3. Implement, maintain, update (as appropriate), and routinely test authorization features to ensure an individual enrollee or their personal representative can only access claims and encounter data or other PHI that belongs to that enrollee through the API.
35. Denial or Discontinuation of Access to the API Payers may deny or discontinue any third-party application’s connection to their API if it is determined (objectively, fairly and consistently across all applications) that allowing the connection to the API would present an "unacceptable level of risk" to the security of protected health information on the payer’s system. Some points of note: 1. Given that the application is essentially an agent of the patient, there is no need for a Business Associate Agreement between the third-party app developer and the payer organization.
36. Payer Hosted Patient Access API?
37. Payer’s Host Patient Access API?? Why would the Payer host the Patient Access API?: 1. EHR data are frequently locked in closed, disparate health systems. 2. Care and treatment information in the form of claims and encounter data is comprehensively combined in a patient’s claims and billing history. 3. Claims and encounter data, used in conjunction with EHR data, can offer a broader and more holistic understanding of an individual’s interactions with the health care system than EHR data alone.
38. Benefits of Payer-hosted Approach What Is the benefit of Payer-hosted Patient Access API?: 1. Enables the provider to integrate claims and encounter information with EHR data gives the provider the ability to use the combined information, with relevant clinical decision support tools, as part of normal care delivery in a less burdensome way, leading to improved care. 2. Patients who have immediate electronic access to their health information are empowered to make more informed decisions when discussing their health needs with providers, or when considering changing to a different health plan. 3. Patients can easily access a comprehensive list of their adjudicated claims, ensuring that their providers know what services they have already received thereby avoiding receiving duplicate services.
39. Benefits of Payer-hosted Approach (Cont.) Why Is the benefit of Payer-hosted Patient Access API?: 4. Clinicians would be able to review, with the approval and at the direction of the patient, information on the patient’s current prescriptions and services received by the patient. 5. Patient could also allow clinicians to access such information by sharing data received through the API with the clinician’s EHR system—by forwarding the information once the patient receives it or by letting the clinician see the information on the patient’s smartphone using an app that received the data through the API. 6. Developers and providers could also explore approaches where patients can authorize release of the data through the API directly to the clinician’s EHR system.
40. Benefits of Payer-hosted Approach (Cont.) Why Is the benefit of Payer-hosted Patient Access API?: 7. Payers could use the proposed API as a means to exchange health information for other health care purposes, such as to health care providers for treatment purposes. Sharing interoperable information directly with the patient’s health care provider in advance of a patient visit would save time during appointments and ultimately improve the quality of care delivered to patients.
41. Questions?