Universal API Implementation Guide - Local Development build (v1.1.20) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Home
| Official URL: https://fhir.developer.gene.com/ImplementationGuide/gene.com.fhir.uapi | Version: 1.1.20 | |||
| Draft as of 2025-06-25 | Computable Name: UniversalAPIImplementationGuide | |||
How to read this Implementation Guide
This Implementation Guide is divided into several pages which are listed at the top of each page in the menu bar.
- Home - The home page provides the introduction of the Universal API (UAPI), background on Genentech Patient Support Services, and how to get started
- Table of Contents
- Guidance - These pages provide overall guidance on how different flows work
- Artifacts Summary - These pages provide detailed descriptions on expected values/questions for each product, search parameters, bundle examples, resource profiles, extension definitions, values sets, and custom code systems
- Business Rules - These pages provide business rules for submitting data
Background
The Universal API (UAPI) Implementation Guide is based on FHIR Version R4 and defines the minimum set of constraints on the FHIR resources to create the UAPI Profiles. It also defines the minimum set of FHIR RESTful interactions for each of the UAPI Profiles.
The goal of the UAPI Implementation Guide is to describe FHIR connectivity with Genentech services. Senders of the FHIR bundles in this implementation guide include patient/financial assistance platform vendors, EHR platform vendors, practices, and hospital systems. The final receiver is the Genentech system determined by the Genentech Integration Marketplace API component.
Getting Started
-
Registration and Access to FHIR APIs
To connect to our FHIR APIs, visit the Genentech Integration Marketplace site for instructions on how to register and set up API Keys for your organization. -
FHIR Basics
For those new to FHIR, the material below describes basic FHIR principles and gives guidance for reading FHIR specifications.
Roles
Human Roles
Staff Submitting the Enrollment
Users on the Practice/Hospital side who are typically working in their EHR System and Practice Management system, may have used fax, online enrollment, or
My Patient Solutions system to submit Patient Enrollments to Genentech. Now they can have their EHR or Practice Management system directly integrated with
Genentech Patient Enrollment API.
Prescriber
Prescriber is making a prescribing decision and enters prescription details into the EHR System.
Patient
Patient is agreeing to Patient Consent terms of service. The results of requested services are communicated by the Prescriber’s Office Staff outside of the scope of Universal API functionalities.
Genentech Access Solutions Staff
Genentech users who are receiving Patient Enrollment Requests and fulfilling requested services in the internal Genentech system.
System Roles
Data Source System:
- EHR - multiple instances by different vendors like Epic, Cerner, Allscripts, etc. Each hospital can have slightly different EHR implementation even though they have the same EHR software vendor.
- Partner System - additional vendor system which is integrated with EHR. Those systems play an orchestrator role to connect with multiple different hubs and manufacturers for Patient Support Program services. Each hospital using the same Partner System vendor should have the same specification for Genentech UAPI integration.
Data Consumer System:
Genentech API - Universal API FHIR endpoint(s) which are called either from EHR or Partner System to submit data to Genentech or query for information from Genentech. The Genentech API is orchestrating requests to downstream Genentech or partner systems to fulfill requested services and make results available on Genentech FHIR Server.
Use Cases
UC1 - Enrollment into Access Solutions services
Access Solutions requires 2 main aspects to initiate their services. They are:
- Prescriber Service
- Patient Consent
The Prescriber Service includes patient, insurance and prescription information used when Genentech Access Solutions contacts a patient's health insurance plan to determine his or her coverage.
The Patient Consent is acknowledged and dated by the patient giving permission for Genentech Access Solutions to discuss his or her health information with the Doctor's office and the patient's health insurance plan. This consent is valid for 6 years from the sign date and valid for 1 year from the sign date for residents in Maryland.
Access Solutions understands that both of these requirements may not be obtained at the same time. Thus, the following scenarios are accepted in the API:
| Method | Use Case | Description | Bundle Example |
|---|---|---|---|
| POST | Prescriber Service with Patient Consent | This is the ideal package. Access Solutions will be able to immediately initiate their services if both have been submitted. | Link |
| POST | Prescriber Service Only | Sometimes the patient is not available to their Prescriber Office to provide patient consent. Thus, the Prescriber Service can be submitted by itself without the Patient Consent. However, if the patient has an existing Patient Consent on file with Access Solutions, then only the Prescriber Service is needed. | Link |
| POST | Patient Consent Only | When a patient is able to provide Patient Consent and a Prescriber Service is unneeded to be submitted, because the Prescriber Service has already been submitted prior or the Patient Consent on file with Access Solutions is close to expiring. | Link |
See details in Access Solutions & Patient Foundation Enrollment
UC2 - Enrollment into Copay services
The Copay enrollment bundle MUST inlcude all required resources - including patient demographics, organization who submits the enrollment, prescriber information, insurance coverage information, copay enrollment questionnaire answers, as well as brand and copay program identifiers.
The following Use Cases are supported by the copay enrollment API
| Method | Use Case | Description | Bundle Example |
|---|---|---|---|
| POST | Copay Enrollment | Enrolls new patient into Copay program | Link |
| POST | Verify Copay Enrollment | Verifies patient enrollment into Copay program and return current enrollment date and list of enrolled programs. | Link |
| PATCH | Update Copay Enrollment | Adds existing patient to Copay program for the requesting organization. | Link |
See details in Copay Enrollment
UC3 - Checking Status of Requested Services
See details in Query Workflow - currently only Access Solutions services enrollments are available for status updates.
Data Expectations
- The solution must ensure that patient records are separate for each vendor/hospital system even though this might be the same person. Update of enrollment information or subsequent enrollments can be only applied to existing patient records if we know that this is the same patient within a single vendor/hospital account. For this we expect to receive the “Patient Identifier” which is unique for that patient so that the system can identify if Genentech already has a patient with an identifier under vendor/hospital account for future updates.
- Validations have been implemented on the Access Solutions/Genentech Patient Foundation side to ensure that enrollments have the minimum required information to process enrollments. Please refer to Validation Rules section for details.