Rubric Criteria for Referral Managment.xlsx

Technical Capability Criteria

2. VA Staff (Referral Coordination, Community Care) Ease of transition for existing VA staff to use the new system.

3. Providers: Ease of transition for Community Providers to use the new system. (1) VA Design Team: Rules and workflows can be created and changed by non Developers.

(2) VA Staff and Providers: The User Interface (UI) is intuitive and low learning curve.

(3) VA Staff and Providers: The UI is designed to ease users into a new system on the backend without a “rip and replace” disruptive approach. The business rules and functionality can be optimized independently of the “last mile” to the UI so that new features can be introduced gradually to users and the look and feel can be slowly transitioned.

(4) VA Staff: The UI is a web services-based unified digital experience and is designed as a common, unified front end to multiple existing VA back-end systems.

(5) VA Staff: The UI supports a multi-tenant approach so that the backend applications are modular and interchangeable.

(6) VA Staff and Providers: The UI supports a VA supplied design library with style guides for both VA staff and for Community Providers.

Service Oriented Architecture Is the design consistent with Service Oriented Architecture (SOA) such that independent services with defined interfaces can be called to perform their tasks in a standard way? Are services designed for “loose coupling?” Service-oriented architecture (SOA) is an architectural style that focuses on independent services instead of a monolithic design. A service is a unit of functionality that can be accessed remotely and acted upon and updated independently. A service logically represents a repeatable business activity with a specified outcome.

(1) Is the design according to a Service Oriented Architecture, so that modular componets are independent, loosely coupled, and can potentially be deployed independently (or grouped together as a package).

(2) System components should be loosely coupled to allow for multiple versions of an interface to be in use by dependent systems at the same time. A failure or error can then be isolated and addressed in loosely coupled systems with minimal development impact.

(3) Ability to turn off components if not needed by VA. Separation of Business Functions such that VA can select which components to use. EXAMPLE: VA can turn off a service that notifies patients of scheduled appointments and use an internal VEText or secure email application instead.

(4) Is the Design for loose coupling, such that services can be called or used by any user (via an online portal) or application (machine to machine connection)?

(4) What services are included? For example, is there a service that allows external systems to query on referrals for a given patient or for a given date range?

(5) Are service descriptions (a description of a service that explains how the service can be used by clients) published or internal? Published is defined as anyplace where microservices or web services are stored and made available to others, such as a publicly available GitHub.

Portal for Community Providers (and Alternatives like Electronic Submission) (1) In addition to a Portal for Community Providers to receive referrals, are there alternative means such as efax or letter generation?

(2) Does the Referral System allow Community Providers (e.g., Third Party Administrators, primary care physicians, specialists) to receive and submit referral requests electronically.

(3) Portal solutions are inherently manual and far less automated than electronic solutions. Multiple workflows including sending out Community Care referrals, and receiving Request for Service (RFS) are moving toward an EDI 278 implementation. The emphasis is on automated, configurable workflows and automated, configurable business rules. Note: Vendors should provide both a manual and an automated solution for referral processing, including portals for manual processing, but with a focus on a Service Oriented Architecture with modular, flexible components, APIs, and configurable workflows in support of all electronic requests and responses.

Automation First Automation through Business Rules with fallout from the Automation to Manual Workflows (1) Ability to automate and integrate aspects of the platform.

(2) Supply Platform APIs.

EXAMPLE: Invoke a platform service with an API instead of through a UI.

(3) The platform has been designed to automate referral functions and then expose any fallout from the automated process to work queues for manual resolution. Automation based on business rules should be the starting design principle and all automation is easily extendable as more business rules are defined or change over time. Manual workflows are supported to correct or handle any fallout from the automation but are not a replacement for automation.

(4) Business rules should be flexible and easy for non-programmers to create and modify (No code/Low Code).

Scalability The system components can scale for a nationwide enterprise application and can make best use of infrastructure to scale up and down appropriately. (1) Do you currently have deployments in large, nationwide enterprise deployments?

(2) Do you support on premise deployments or cloud or both? Do you support auto scaling in cloud environments?

Security and Compliance with VA ATO or FedRAMP The platform and all components are compliant with VA standards. (1) The platform can be hosted in the VA Enterprise Cloud (and managed by VA Operations Staff) and is capable of achieving VA Authority to Operate (ATO) OR if a SaaS product, is FedRAMP compliant and listed on the FedRAMP marketplace. Is either or both supported?

(2) Data Encryption: The system should use strong encryption methods (both at rest and in transit) to safeguard patient data. Security should meet or exceed the requirements of NIST FIPS 140-2/3

(3) Compliance with VA's Technical Reference Model (TRM) and Section 508 Standards

(4) Security and Privacy Demonstrate how the system ensures the security of sensitive data, including PII and PHI, through encryption, access controls, and audit logging. The platform shall comply with the Federal Information Security Management Act (FISMA).

(5) Security Documentation:

Each system shall document and maintain system security artifacts and manage system security risks, in accordance with the National Institute of Standards and Technology (NIST), Authority-to-Operate (ATO) reciprocity, interagency risk assessment processes, and applicable regulatory authorities. Include documentation or processes for maintaining: Software Bill of Materials (SBOM), Incident Reporting, Auditing, Certificates, and Authentication.

(6) Document and Control All Interfaces:

Demonstrate the ability to author or contribute to Interface Control Documents (ICD) between internal VA partners, establish Memorandum of Understanding (MOU) or Interconnection Security Agreements (ISA) with external partners.

(7) Authority to Operate (ATO): Demonstrate ability to obtain a VA ATO.

(8) Regulatory Compliance Show how the system complies with relevant regulations and standards, including HIPAA.

(2) HL7- additional versions: can be customized to accomodate VA's modernized EHRM, also via HL7 but with different version of HL7, messaging, and workflows than legacy VistA.

(3) FHIR: The platform has plug-ins and integrations to FHIR R4 standards.

(4) API Access: APIs or microservices (outbound) are exposed as RESTful APIs with JSON Payloads. Can consume inbound REST or SOAP.

(5) Third Party Integration: with other tools like scheduling platforms and analytics systems is well proven in exising implementations.

(6) UI Multi-Tenancy: Exposes APIs that can integrate to the User Interface (UI) to allow multi-tenancy on the backend, with a seamless UI that hides the underlying complexity.

(7) EDI Gateway: In the future, the Referral System will transmit referrals to a VA EDI Gateway for outbound referrals. Also, in addition to portal submissions, Request for Service (RFS) submissions may be received from the EDI Gateway via FHIR or other APIs via specifications in an Interface Control Document (ICD) to be agreed upon between VA and the Contractor.

"Nice to have", not "Must Have":

(7) TEFCA - Trusted Exchange Framework and Common Agreement (TEFCA) will outline a policy and technical approach to enable nationwide exchange of electronic health information across disparate health information networks (HINs). The development of the TEFCA is mandated by the 21st Century Cures Act. It's a way to interconnect electronic health information exchanges like Commonwell.

(8) EDI X12 278 - EDI standard for referrals and authorizations Note: The requirement is that the RAS system will interoperate with the VA’s EDI Gateway according to VA specifications as detailed in an Interface Control Document (ICD).

The requirement should be on automation to support EDI 278 transactions in real time (again: Service Oriented Architecture with modular, flexible components, APIs, and configurable workflows) but not EDI 278 per se.

(9) Direct Secure Messaging - secure message transport over the open Internet

VA Customization (1) Customization: can be customized to support an interface to VA's Data Access Service (DAS) as defined by the DAS system. The interface from the Referral System to DAS is a RESTful web services over HTTPS. All transactions will contain a JSON payload based on FHIR standards.

In the future, the Referral System will transmit referrals to a VA EDI Gateway via an Interface Control Document (ICD) to be agreed upon between VA and the Contractor.

(2) Customization: can be customized to support interfaces to other VA systems according to the VA system's published specifications (the number of interfacing systems is large, up to approximately 20 or more). For example, VA systems supply information to ingest, such as veteran identity and demographics, eligibility, referrals, clinical data, cost estimates, community provider data, and VA specific Standard Episodes of Care (bundles of care authorized by VA). Then outputs are shared with Payment and Reimbursement Systems, Data warehousing systems, and Fraud Waste and Abuse Systems, among others.

(2) VA owns any APIs developed including allowing and controlling access to those APIs.

(3) APIs must be discoverable and documented in VA’s API Catalog, CODE VA.

(4) All APIs must conform to VHA Data Governance and Community Care's API Data Governance.

(5) APIs will be managed according to SLAs.

(6) API access and usage will be logged and monitored.

(7) Specific API Requirements (minimum)

(2) Online Training Available?

(3) Sandbox environments for developers to learn and experiment.

Industry Standards Adherence to Industry Standards (1) HL7

(2) Fast Healthcare Interoperability Resources (FHIR)

(3) HIPAA compliant Analytics & Reporting Capabilities on Reporting and Dashboards. (1) Out of the box reports and dashboards built into platform.

(2) Ability to create custom reports.

(3) Audit Trails and Report: built-in audit logs that track user activity, referral actions, and data exchanges.

(4) Referral Analytics: insights into referral patterns, wait times, referral outcomes, referral volume, timeliness of care, and provider performance.

(5) Operational Insights: tools to analyze workflow efficiencies, bottlenecks, and opportunities for improvement in the referral process.

User Authentication (1) Can integrate with VA Identity and Access Management (IAM) for SSO and/or EntraID Integration, including VA SSOi and SSOe APIs (internal and external VA users).

(2) Ability to accept JWT Tokens for authorization controls.

(3) Supports SAML and OAuth.

Monitoring Integration Capabilities on Monitoring and Alerting (1) Integrate to VA Monitoring tools (Monitoring APIs). Ability to monitor the platform, and at more granular levels, such as at the service or API level.

Referral Management Repository Technology to support Referral Management (1) Database options for Patient Referral Management

(2) Can it manage updates to patient referrals, such as requests for additional services, and tracking VA approved/disapproved determination of those requests?

Business Capability Criteria

(2) Referral Tracking: Does it offer tracking and visibility into referral status.

(3) Automated Follow-Up: Does the system send automated reminders to referring and receiving providers, or task notifications to VA staff for actions that need to be taken (example: clinical review by nurse).

Decision Workflow Decision-Making Workflow: A structured workflow for evaluating and approving/denying referral requests Are any of the following provided for Decision-Making Workflows:

- Automated rules to check if the referral meets specific criteria.

- Manual review for more complex cases.

- Alerts or notifications to decision-makers (such as care managers or specialists).

- Logging reasons for approval/denial.

Communication and Collaboration Features (1) Care Coordination: What features enhance collaboration between healthcare teams, including real-time communication, shared patient notes, and case updates.

(2) Communication Channels: communication options, such as email, SMS, letter generation, or app-based notifications.

Portal for Community Providers (and Alternatives like Electronic Submission) (1) In addition to a Portal for Community Providers to receive referrals, are there alternative means such as efax or letter generation?

(2) Does the Referral System allow Community Providers (e.g., Third Party Administrators, primary care physicians, specialists) to receive and submit referral requests electronically.

(3) Portal solutions are inherently manual and far less automated than electronic solutions. Multiple workflows including sending out Community Care referrals, and receiving Request for Service (RFS) are moving toward an EDI 278 implementation. The emphasis is on automated, configurable workflows and automated, configurable business rules. Note: Vendors should provide both a manual and an automated solution for referral processing, including portals for manual processing, but with a focus on a Service Oriented Architecture with modular, flexible components, APIs, and configurable workflows in support of all electronic requests and responses.

(4) Veterans need to be notified via their preferred communication method when the VA receives an emergency care notification. Is the system flexible enough to integrate with VA systems to notify veterans (e.g., VA Notify/VEText, VA.gov, and/or myHealtheVet)?

Support myHealtheVet/VA.gov via referral API's Ties back to API Policy capability on Technical Capability Criteria tab.

(7) Specific API Requirements (minimum)

Supports ACCESS Act sections 104 and 301.

Patient Data Management (1) Data Validation: Ensuring that the referral includes necessary clinical information (e.g., diagnosis codes, insurance info) to prevent incomplete or erroneous referrals.

(2) Patient Status Tracking: Tracking the patient's progress through the referral process, including appointment scheduling, consultation, and follow-up care.

VA Referrals and Authorizations (R&A) for care in the Community are received from VA EHRMs via HL7 REF messages.

• The Referral System transmits referrals to Community Care Network (CCN) Third Party Administrators (TPAs) via a FHIR document reference over https as specified by VA's Data Access System (DAS) system, for use during adjudication of community care claims.

In the future, the Referral System will transmit referrals to a VA EDI Gateway via an Interface Control Document (ICD) to be agreed upon between VA and the Contractor.

(2) Tailored Workflow: customizable to the specific needs of VA, such as setting up workflows for different work groups.

(3) Configurable Rules: define rules for referral routing, eligibility criteria, or follow-up processes.

(4) Modular Approach: modular features that can be added or removed based on VA's needs

VA Customization- "Request for (Additional) Services (RFS)" or pre-authorization request/response (1) RFS entry from Community Providers can be via a portal, a semi- automated workflow (API call with decision/determination sent to manual work queues for clinical staff), or manual entry by staff (upon receipt of mailed or faxed requests).

In the future: In addition to portal submissions, Request for Service (RFS) submissions may be received via EDI transactions, HL7, or FHIR APIs or other APIs.

(2) Notifications to Community Providers can be via a portal, “Offline referral” (letter, email or efax to the Community Provider and TPA), or API that can be queried for approved/denied status.

(3) Administrative Portal for VA staff users: for clinical review of RFS and worklist with request details (SEOC/procedure codes, veteran and provider details), plus display medical documentation submitted for review of medical necessity

(4) Business Rules and workflow for RFS users - both VA staff and Community Providers

(5) Authoritative source: Original consult + RFS changes and status of RFS (approved, in progress, denied)

(6) Clinical documentation: Medical documentation is routed to VA specified location (e.g., S3 bucket)

(7) Interoperability: Communicate to downstream VA systems- Referral ID & RFS changes

(2) Is it possible to "turn off" included scheduling modules?

(2) Submit to a specified workflow for clinical decisions/patient record

(3) Support automated data capture to utilize solutions that extract relevant information from submitted documents

(4) Utilize AI with machine learning to analyze medical records and flag cases for review Emergency Care Emergent Health Care- No referral needed, but veterans have 72 hours to submit the notification in the Portal or via EDI 278 to be adjudicated as VA authorized emergency care. (1) Business Rules and workflow for users

(2) Authoritative source: Emergent Care Notification ID stored

(3) Administrative Portal for VA staff users: for adjudication of emergent care notifications and worklist with request details (procedure codes, veteran and provider details)

(4) Display Medical documentation submitted by Community Providers for review

(5) Interoperability

- Communicate to downstream VA systems- Referral ID & Referral type data Including Program Authority

- Medical documentation is routed to VA specified location or workflow VA Precertification Generate VA Precertification ID for Community Providers (a tracking number to verify the Providers followed the VA precertification notification process) (1) Business Rules and workflow for VA staff users: for precertification review of veterans with Other Health Insurance

(2) Authoritative source:

- Precertification ID and associated Referral

- Authoritative source of billing codes (CPT codes) requiring VA precertification

(3) Administrative Portal for VA staff users: Generate worklist of referrals requiring precert with request details (diagnosis, procedure codes, veteran and provider details)

(4) Display Medical documentation submitted by Community Providers for review

(5) Interoperability

- Communicate to downstream VA systems- Referral ID & Referral type data Including Precertification ID.

- Medical documentation is routed to VA specified location or workflow

(2) Send Status updates to the EHRs including: 1st appointment scheduled, cancelled, clinical notes….

(3) Receive medical records from the EHRs and associate to the Consult/Referral

(4) Disseminate Consults with associate medical records via various forms of communication: portal, electronic transfer, text, fax, letters, printed forms, direct secure messaging, and email (automatically generate email and letter templates and send notifications to Veterans and Providers)

(5) Automated workflows and business rules to include case management of high-complexity patients

(6) Manage worklists, assign tasks, filter and sort worklists based on criteria. Display referral status and history.

(7) Dental: View the following dental plan information in a RAS for an initial dental referral: Tooth, Area of mouth or surface, American Dental Association (ADA) code or code sets, Related treatment plan guidelines

(8) Clinical View: The system shall receive and display care coordination plans, associated care plan documents, clinical notes, and a comprehensive view of a Veteran’s medical documentation history from the electronic health record system.

(9) Precertification: Route RFS requests with services (e.g., CPT codes) that require precertification to a work queue (e.g., Revenue Operations)

(10) AI - incorporate AI to optimize workflows related to the tracking and documentation of care coordination activities, supporting timely decision making and improved care delivery

(11) Advanced analytics that allow viewing claims data, medical documentation, care complexity, and risk factors

(12) Integration with VA direct care systems and other data capabilities/services to assist in transitioning care between VA direct and non-VA community settings

Utilization Management 1. Support prospective outpatient, inpatient and retrospective UM with the ability to evaluate and audit services that were performed and whether they were medically necessary – at both the micro and macro level, including advanced analytic capabilities

2. Document the clinical decision (approve, deny) for a Request for Service. Include a reason for denial to ensure all authorized users understand the justification for the RFS denial and can take appropriate follow up actions.

3. Implement payer specific and clinical guidelines to support decision making

4. Demonstrate automated utilization review capabilities, including the ability to apply clinical guidelines and criteria to determine the medical necessity of services

5. Show how the system manages authorizations, incluing initial requests, renewals, and modifications.

6. Provide examples of reporting and analytics capabilities, including utilization trends, compliance with guidelines, and performance metrics.

Clinical Review Tool System shall supports clinical review (and utilization management) through close integration with clinical review tools (EHR agnostic) for direct and community care (or at least aligns with direct care clinical review processes). Which Clinical Review Tools are currently supported?

Show how the system supports peer review processes, include case assignment, review workflows, and documentation.

Analytics (1) System shall provide a view a history of changes or updates made to a referral in a RAS illustrating the full lifecycle of a Veteran's referral.

(2) System shall provide the following advanced analytic information related to care coordination in a RAS: Medical Documentation, Care Complexity, Risk Factors

Emergency Care and Precertification - Interoperability The system shall be able to receive emergency care or precertification notifications via electronic data interchange (EDI), Health Level 7 (HL7), or Fast Health Interoperability Resource (FHIR) Application Programming Interface (API). Can the emergency care application and/or precertification application serve as an endpoint for an EDI X12 278 transaction used to notify VA of an emergent/urgent care event?

If not, what formats are available (JSON, XML….)