FPAR 2.0 Frequently Asked Questions

OPA considers the data elements final. OMB approved FPAR 2.0 data collection under OMB control number 0990-0479.

Every encounter record MUST contain the data corresponding to data elements (1) Facility Identifier, (4) Patient Identifier, (5) Visit Date, (6) Birth Date, and (7) Sex. Files with missing values on any of these five data elements will not be accepted.

All other data elements shall be reported on each encounter when clinically appropriate. The system will accept files with missing values on these data elements and missing data will be included in data quality reviews.

Please refer to the FPAR 2.0 Data Elements with Valid Values document for additional information about expected data.

A value set is a list of codes and corresponding terms from standard vocabularies that define or represent concepts. Value sets are identified by a unique number called an OID or object identifier. For example, a value set containing codes and descriptions that can be used with Data Element #7, Sex, is identified by 2.16.840.1.113883.1.11.1 and contains codes and descriptions for male and female.

Please review the Valid Values and Sample Files document for additional guidance.

OPA encourages grantees who can report some (but not all) FPAR 2.0 data elements to submit any encounter-level FPAR 2.0 data available in 2023. Grantees will have two options for addressing incomplete data or data quality issues: 1) they can correct encounter-level data and resubmit the data, and 2) they can also edit the grantee-level tables produced by the FPAR 2.0 system to ensure totals for each table accurately represent services provided. Grantees who, for any reason, cannot submit FPAR 2.0 encounter-level data, should apply for a waiver so they can avail themselves of the alternate reporting option. Alternate reporting will consist of editing grantee-level tables to reflect aggregate data.

Grantees must report response options as described in the data elements spreadsheet. Please refer to the FPAR 2.0 Data Elements with Valid Values document for additional information about expected data.

Grantees can build their systems to collect any data elements they deem necessary and appropriate. For FPAR encounter-level reporting, grantees should submit only the data elements and associated codes posted on the FPAR 2.0 section of the OPA website.

Starting with calendar year 2022 data (2023 submission), CBE will no longer be collected in FPAR 2.0 due to changes in clinical guidance.

Grantees should provider their Type 2 National Provider Identifier (NPI2), which identifies a hospital or clinic, for this data element, when possible. Grantees can also choose to create a facility identifier. If grantees choose to create a facility identifier, grantees must ensure that the facility identifier is unique for each facility and is consistent across all records provided. OPA does not assign facility identifiers.

The Attending Physician NPI Provider should be that of the provider providing care to the client on the encounter date. The LOINC term is Attending Physician NPI Provider. OPA cannot modify this but recognizes that other providers besides physicians have NPI numbers. If the person providing family planning services has an NPI, whether they’re a physician or not, it should be reported. If the person who provided the family planning services does not have an NPI, the field should be left empty.

Grantees should report the role of the clinician providing care to the client on the encounter date. The current response options include a pre-existing list of provider roles that is also used for purposes other than FPAR reporting.

Currently, other types of providers cannot be included in the expected answer list for the Provider Role. Please submit one of the 'Expected Codes/Values' (LL4575-8) provided in the FPAR 2.0 Data Elements files. If a provider does not fit in one of the roles in the value set, please submit a response of “Other” (LA46-8). Updates to the list of allowable responses may be considered in the future.

If grantees are concerned that the patient identifiers used by subrecipients are duplicated across subrecipients, they should append a forward slash (/) and the subrecipient name to the patient identifier. This modification enables the FPAR contractor to determine whether an encounter describes the same or different patients. Grantees should use the same modified identifier each year to ensure consistency in the records across years.

There are no requirements for the format of the patient identifier. The patient identifier is a unique alphanumeric string that identifies a specific patient and is assigned by a specific organization (the assigning authority).

At this time, OPA allows for the use of a pseudo number/ID for the patient identifier. If grantees choose to use a pseudo ID for the patient identifier, they must ensure that:

1) Pseudo IDs are unique for each individual

2) They assign the same pseudo ID to the same individual across encounters each year to enable analysis of encounters over time.

Yes. Grantees must report Facility Identifier (Data Element #1), Patient Identifier (Data Element #4), Visit Date (Data Element #5), Birth Date (Data Element #6), and Sex (Data Element #7) for every family planning encounter. If an encounter-level file does not include any of these five data elements, the FPAR 2.0 system will reject the submission.

OPA will not have access to birthdates. The contractor developing the FPAR 2.0 system will retain date of birth and other elements for one year after submission before they are destroyed. The FPAR 2.0 system will convert dates of birth to an age. It will also assign age 50 to all clients 50 years and older. OPA will only have access to summarized, de-identified data (such as age instead of date of birth).

The FPAR data elements and response options were designed to align with Interoperability Standards and EHR Certification requirements (United States Core Data for Interoperability (USCDI) standards; ISA Standard Terminology). Currently FPAR 2.0 is accepting only male and female as responses for Data Element #7 (“Sex”), using LOINC answer codes (ex. ‘LA2-8’ for male and ‘LA3-6’ for female). At this time, OPA’s annual FPAR analyzes certain family planning care variables based on sex. OPA will review the response options, value sets, and interoperability standards on an ongoing basis to identify future opportunities to correct or enhance the allowable reporting options.

Grantees can report options other than male and female using Data Element #43 (Gender Identity) to represent the client's gender identity. For FPAR reporting, please map all data to the response options currently published in the FPAR 2.0 Data Elements as well as the Valid Values and Sample Files.

If it is unclear whether the person is proficient in English and “Other” is listed as the primary language, grantees should not report a value for Data Element #8 (Limited English Proficiency). An individual may have a primary language other than English and may also be proficient in English. If it is known that the individual is not proficient in English, grantees should report “Not proficient in English” (LOINC LA28229-5) for Data Element #8 (Limited English Proficiency).

Response options for this data element are “Hispanic or Latino” or “Not Hispanic or Latino”. This term is used for reporting the ethnicity based on classifications provided by the Office of Management and Budget (OMB), Revisions to the Standards for the Classification of Federal Data on Race and Ethnicity.

Race is the only multi-select data element. The CSV file should contain one column for each of the Race categories, which can each take a value of LA33-6 (for yes) and LA32-8 (for no). Please review the FPAR 2.0 Implementation Guide and Valid Values and Sample Files for additional guidance on reporting.

Grantees can leave the field blank for all clients who do not know or who are unwilling to report their income. However, grantees should report a non-negative integer if they are able to report annual household income for the client.

When reporting household size, grantees should ask clients to include themselves in the total number of people living in their household.

Please report only one insurance coverage type per encounter. The Insurance Coverage Type element is intended to determine clients’ access to comprehensive primary medical care. If a client has access to comprehensive primary medical care, please report one option that is most applicable to the clients’ insurance from the list of response options provided. For further guidance on reporting Insurance Coverage Type, please reference the Insurance Coverage Mapping Guidance document.

Grantees do not need to offer all response options as a selection option for subrecipients if response options are not applicable.

Grantees should report the more specific valid values detailed in the FPAR 2.0 Data Elements with Valid Values file for each client in their encounter-level data. If a client is uninsured, select the response option that best applies to the client (e.g., pay, health spending account). If the insurance coverage type of the client is unknown, then leave the data element blank for the client.

When grantees submit their encounter-level data, the FPAR 2.0 system will automatically categorize the response options for Insurance Coverage Type under four categories (public, private, uninsured, or unknown/not reported) to populate Table 5 (Unduplicated Number of Family Planning Users by Principal Health Insurance Coverage Status). Further information on how response options are categorized can be found in the Insurance Coverage Mapping Guidance.

If a client has more than one form of insurance listed, grantees should report the insurance used to cover family planning-related activities. If both are used, grantees should report the primary insurance.

For all clients who are uninsured, grantees should report “pay” for data element#13 (Insurance coverage type). However, if clients are being subsidized through a government program, then report “SAFNET” (safety net clinic program).

For more information on each of the response options for data element #13 (Insurance coverage type), refer to the coverage type value set.

Grantees should determine the response option that best fits the client’s insurance. Definitions for each response option can be found on the HL7 website. For example, if a client has a Medicaid MCO, please code it as SUBSIDMC, as it best matches with the definition of a subsidized managed care program.

MCPOL should only be used for private managed care plans.

If Medicare is considered the client’s principal insurance, whether they attained Medicare due to a disability or not, SUBSIDMC should be reported as their insurance coverage type.

The purpose of the Insurance Coverage Type data element is to capture a high-level description of a patient’s access to broad primary medical care health coverage type, including various categories of insurance (public, private, etc.) and self-pay. For Insurance Coverage Type codes, please report the response most applicable to the family planning client. The codes are located in column D in the FPAR 2.0 Data Elements with Valid Values File, or column H in the FPAR 2.0 Data Elements file.

For the Payer for Visit data element, the payer source charged by the organization for Title X services should be reported. If this information cannot be determined, the Payer for Visit data element contains a response option of 'None (no charge for current services)’ and ‘Other (specify)’. For Payer for Visit, grantees should report the LOINC codes listed as valid values in column D in the Valid Values file or column H in the FPAR 2.0 Data Elements file.

Grantees' electronic health record (EHR) should include a distinct question to capture pregnancy status. Pregnancy Status is a separate data element and should be reported as a separate field. Please refer to the response options for the pregnancy status data element in the FPAR 2.0 Data Elements with Valid Values file.

Grantees may leave this field blank for family planning clients who are male at birth.

The purpose of the pregnancy intention data element is to capture a client’s intention in the next year to either become pregnant or prevent a future pregnancy. This includes male clients seeking pregnancy with a female partner. However, grantees may leave this field blank for family planning clients who are male at birth. Pregnancy intention may be used to help improve preconception health screenings and decisions based on client needs, such as determining an appropriate contraceptive method, taking folic acid, or avoiding toxic exposures such as alcohol, tobacco, and certain medications.

Grantees' EHR should include a distinct question to capture Contraception At Intake and Reason for No Contraceptive Method at Intake. Contraceptive Method at Intake shall be reported as a separate field from Reason for No Contraceptive Method at Intake since each field is mapped to different LOINC codes.

Grantees should only report the most effective contraceptive method used by the client and how the most effective contraceptive method was provided: https://www.cdc.gov/reproductivehealth/contraception.

Grantees should report the most effective method reported by the client at the time of each family planning encounter.

Contraceptive Method at Exit shall be reported as a separate field from Reason for No Contraceptive Method Use Reported at Exit since each field is mapped to different LOINC codes.

Contraceptive counseling is an interaction in which a provider spends time (5-10 minutes) during an encounter discussing the patient's choice of contraceptive method and available options (LOINC: 86654-1).

Counseling to achieve pregnancy is an interaction in which a provider spends time during an encounter discussing any services and/or provides counseling related to achieving pregnancy or addressing infertility (LOINC: 86655-8).

For telehealth, it is up to the reporting organization and clinical judgment of their providers to determine when self-reported values are acceptable.

Grantees can report body height in either inches (in) or centimeters (cm). Please see the FPAR 2.0 Data Elements with Valid Values to reference acceptable response options.

Grantees should report body weight as pounds (lb), grams (g), or kilograms (kg). Please see the FPAR 2.0 Data Elements with Valid Values to reference acceptable response options.

According to the Centers for Disease Control and Prevention’s Tobacco Glossary, a current every day smoker is someone who smokes daily, specifically “an adult who has smoked 100 cigarettes in his or her lifetime and who currently smokes cigarettes.” Further refinement specific to what constitutes a current every day smoker comes from the National Cancer Institute (NCI). Specifically, a current every day smoker may be designated as either a heavy tobacco smoker – “a smoker who smokes more than 10 cigarettes per day, or an equivalent quantity of cigar or pipe smoke” or a light tobacco smoker – “a smoker who smokes less than 10 cigarettes per day, or an equivalent quantity of cigar or pipe smoke”.

Conversely, a current some day smoker refers to an occasional smoker, or “a person who has smoked at least 100 cigarettes in his or her lifetime, who smokes now, but does not smoke every day”.

For data elements 29 (Pap test), 31 (HPV test), 33 (Chlamydia test), 35 (Neisseria gonorrhoeae test), 37 (HIV test), and 39 (Syphilis test), grantees should report whether the respective tests were performed during the visit, rather than the actual result of the lab test. The Sexually Transmitted Infection (STI) and lab panels include codes for tests performed as well as the actual results. Please review the FPAR 2.0 Data Elements, as well as the Valid Values and Sample Files.

The panels contain a set of lab terms that may be used to gather test results for each data element’s associated test. The panels include codes for tests performed as well as the actual test results.

Grantees submitting a CSV file should submit all data elements (such as multiple tests ordered or performed during the encounter) on the same row if the provider administered the tests during the same encounter. For examples on how to report multiple tests in one encounter, please refer to the encounter-level CSV sample file.

Self-Identified Need for Contraception (SINC) is an electronic clinical quality measure (eCQM) under development at the University of California San Francisco (UCSF). Reporting this data element is optional. If a grantee does not currently collect it, SINC does not need to be reported.

Data element #41 is the self-identified need for contraception, part of the eCQM under development at UCSF under grant funding from OPA. Because it is not yet an endorsed measure, it’s only to be reported if (a) it’s already included in the grantees’ EHR and (b) if it’s part of the clinical visit.

For Data Elements 42 and 43, “Unknown” would be reported if the family planning client was not asked about their sexual orientation or gender identity, respectively, while “Asked, but unknown” would be used if the family planning client was asked about their sexual orientation or gender identity but the family planning client declined to answer.

The FPAR data elements and response options were designed to align with Interoperability Standards and EHR Certification requirements (United States Core Data for Interoperability (USCDI) standards; ISA Standard Terminology). As such, the verbiage in the descriptions of codes used in FPAR reporting is not determined by OPA. The descriptions are chosen by the standards body creating the codes. Additional updates to the response options may be considered in the future.

The panels have been created to provide a comprehensive list of screening methods and results. Grantees are not required to submit the full suite of panel questions listed in the FPAR 2.0 Data Element file. Grantees should report an applicable code to indicate whether a test was performed (LA33-6 = Yes) or not performed (LA32-8 = No). Grantees should select data element codes available in their systems for the tests and results applicable to the family planning encounter. Please refer to the FPAR 2.0 Data Elements file.

Grantees should report the result that aligns with the provider’s clinical care decision. For example, if the clinician decides to treat for the STI, then report the positive result. Grantees can find further instructions on how to report lab results in the Valid Values and Sample Files – PDF document. A sample lab result file is also available on the website.

Grantees can apply for a waiver if grantees are unable to submit encounter-level data. Meanwhile, grantees should implement plans to adopt or upgrade EHRs to submit encounter-level lab data for future submissions. Grantees should map tests and results available in their EHR to the most appropriate tests and valid value responses published in the FPAR 2.0 Data Elements with Valid Values – XLSX file.

OPA expects grantees following the preferred approach to provide both encounter-level and lab results data. There are two options for submitting lab results. In the first option, grantees can submit the encounter-level data and lab results data in one file. In the second option, grantees can submit their lab results data and encounter-level data separately. For further guidance on these options, please reference the Valid Values and Sample Files document.

If a grantee is prohibited from sharing an exact date of birth, please submit the actual birth year and June 30th, for example 2000-06-30 or 1992-06-30. The FPAR 2.0 system will convert dates of birth to an age. It will also assign age 50 to all clients 50 years and older.

Additionally, OPA will only have access to summarized, de-identified data (such as age instead of date of birth). OPA will not have access to birthdates. The contractor developing the FPAR 2.0 system will retain date of birth and other elements for one year after submission before they are destroyed.

Data will be anonymized and all raw data, including PII, will be destroyed within a year of submission. For details on the data anonymization process for FPAR, please refer to the IHE IT Infrastructure White Paper, “Analysis of Optimal De-Identification Algorithms for Family Planning Data Elements” published in December 2016. Appendix A of the white paper shows how specific data elements are de-identified from the original file submitted by grantees.

The FPAR 2.0 system will comply with applicable HHS and federal regulations through completion of the HHS Enterprise Performance Life Cycle Framework, including the Authority to Operate (ATO) process with cybersecurity and privacy review controls.

OPA does not have a recommendation for how often grantees should review the encounter-level data from direct service sites and/or subrecipients. OPA strongly encourages grantees develop a process based upon the grantee's organizational capacity and need for assessing the data from direct service sites and/or subrecipients prior to submission.

No, there is not a designated FPAR 2.0 EHR vendor. OPA is working to gather information from some of the largest vendors nationwide to inform implementation planning and TA development. OPA encourages all grantees and subrecipients to work directly with their EHR partners.

Data can be submitted in CSV (Flat-file) format. An encounter-level sample file is available on the FPAR 2.0 section of the OPA website. The file provides an example of how to format a CSV file of Title X encounter and lab result data for submission to the FPAR 2.0 system.

A flat file is a simple data file that typically has one row per record, and each row follows a uniform format. One of the most common flat file examples is a comma-separated values (CSV) file.

Grantees should submit a file containing all relevant encounters for the 12-month reporting period. Each encounter (that is, each row in the file) should contain encounter-level FPAR 2.0 data elements. Submissions will be due annually each February. An encounter-level CSV sample file is available on the FPAR 2.0 section of the OPA website.

Grantees are responsible for submitting encounter-level data to the FPAR 2.0 system after collecting the data from their subrecipients.

Grantees are responsible for submitting encounter-level data to the FPAR 2.0 system. As such, grantees are encouraged to assess data quality from subrecipients prior to submission. Grantees may need to work with subrecipients to resolve data quality issues identified by OPA after data is submitted to the FPAR 2.0 system. Please review the FPAR 2.0 Implementation Guide as well as the, Valid Values and Sample Files.

Grantees will continue to submit FPAR data annually, in February. Grantees will collect FPAR data from January 2022 through December 2022 to be submitted in 2023.

No, grantees should report using a single approach for a reporting cycle. Grantees who, for any reason, cannot submit FPAR 2.0 encounter-level data, should apply for a waiver so they can avail themselves of the alternate reporting option. Alternate reporting will consist of grantee-level aggregate level reporting. For grantees starting out on the alternate approach, they should move to the preferred approach for the next reporting cycle as soon as they are in a position to provide FPAR 2.0 encounter-level data.

Grantees should submit a file containing all relevant encounters for the 12-month reporting period. Each encounter (that is, each row in the file) should contain encounter-level FPAR 2.0 data elements. An encounter-level CSV sample file is on the FPAR 2.0 section of the OPA website.

OPA is exploring opportunities to reduce reporting burden, including providing a crosswalk for FPAR 2.0 and UDS data elements. We will explore opportunities to align FPAR reporting requirements with other reporting systems in the future.

The FPAR 2.0 system will allow grantees to submit their data electronically. The FPAR 2.0 system will automate some procedures that are currently done manually, such as tabulating and checking basic counts of the number of clients served and types of services provided. Grantees will also be able to review and edit the aggregate level data tables produced for them by the FPAR 2.0 system, before they are considered final. Please review the FPAR 2.0 Implementation Guide.

OPA and the development contractor will take this suggestion into consideration as design work continues.

OPA is exploring opportunities to reduce reporting burden, including providing a crosswalk for FPAR 2.0 and UDS data elements. We will explore opportunities to align FPAR reporting requirements with other reporting systems in the future.

A Data Quality Checklist can be found on the FPAR 2.0 section of the OPA website. The document describes the automatic checks conducted by the system.

We have published sample CSV file-layouts and other supplementary TA materials on the FPAR 2.0 section of the OPA website.

OPA is planning a webinar for grantees about the file upload process in November and December 2022. These webinars will be recorded and shared with grantees.

Grantees should continue to use FPAR numbers used in the past. New grantees should have been assigned new FPAR numbers. Grantees should check with their Project Officers if they do not know the FPAR number associated with their grant.

The FPAR 2.0 data collection builds on data already reported in FPAR 1.0 and adds additional detail that will allow OPA to report to HHS leadership and Congress more completely on the services provided by Title X grantees in their communities. Grantees and OPA will have the ability to use dashboards and performance metrics for quality improvement projects, conduct data validation, produce custom analyses, and improve engagement and collaboration with OPA.

The “Other (specify)” fields included in Table 14 (Revenue Report), under the “Other Revenue” section do not have a character limit and all character types are accepted.

OPA will compare reporting rates for FPAR 2.0 data elements to FPAR 1.0 reporting rates at a grantee level, as well as historical trends across all grantees, to help assess data quality and data validity. Grantees will also be able to review and edit the aggregate level data tables produced for them by the FPAR 2.0 system, before they are considered final.

The FPAR 2.0 system will be hosted in a secure, cloud-computing environment with robust capacity.

For the 2022 FPAR submission, all grantees are responsible for submitting sufficient data to produce the 14 FPAR tables (except for Table 10 that is discontinued). For grantees who are submitting encounter-level data, the FPAR 2.0 system will aggregate the encounter-level data and use that to automatically populate the FPAR tables. Please note that grantees must manually enter data for Table 13 (Number of Full-Time Equivalent Clinical Services Providers and Family Planning Encounters by Type of Provider) and Table 14 (Revenue Report).

After all encounters have been submitted, grantees may review the pre-populated tables. If the encounter-level data are complete, then grantees will move directly into the data quality review step of the submission. Historically, these are the data quality checks that OPA performed after grantees provided the initial submission. For example, on Table 2, the FPAR 2.0 system will note a data quality issue if race is unknown or not reported for 10% or more of female users.

In the first few years we realize that the encounter-level data may not be totally complete. For example, some of the grantees submitting encounter-level data may not be able to provide all data elements and/or may be missing encounter-level data from some of their service sites. In these cases, the pre-populated tables would not be complete and accurately reflect all services provided. Therefore, grantees can edit the pre-populated tables to fully reflect all services before moving on to the data quality review step of the submission.

A general comment feature was added to FPAR 2.0 on March 15, 2023. The general comment feature appears below the list of fourteen tables. Grantees can use it to provide additional context about their annual submission. Use of the general comment feature is optional. To provide notes about data quality issues, grantees should use the comment section that appears after the data quality issue within each table.

To resolve this issue, grantees will have to explicitly set the formatting of the date columns. When viewing the file in Excel, highlight all values in the two date columns. On the Home menu at the top, there is a submenu related to formatting. Look for the icons with the dollar sign, percent sign, and comma. At the bottom right of that submenu, there is a small button with an arrow. Select that button to expand the formatting menu.

Grantees should see a title that says "Category". In the box underneath, select "Date". In the menu that appears, select the example date value that is formatted as YYYY-MM-DD.

Select OK. The date values should be updated to the correct format. Then, select save.

To confirm that the format of the dates is correct, grantees should open the file in Notepad instead.

Grantees may also see similar issues with long numbers. For example, Excel will automatically convert some of the valid values for Data Element #43 (Gender Identity) into scientific notation. Grantees must convert these values into text, or the file will trigger a data validation warning in the system. To convert these values into text, follow the steps noted above, and instead of selecting “Date” in the formatting menu, select “Text.”

These re-formatting steps need to be performed and grantees must save the file, whether changes were made to the file or not, every time.

A video demonstrating how to perform the steps for reformatting the dates is available on MAX.gov, along with the transcript for the video.

For grantees uploading encounter-level data that include Data Element 43 – Gender Identity, CSV files may convert some of the valid LOINC values into scientific notation and create validation errors in FPAR 2.0. To avoid this validation error, we ask that you convert values to a text format and then save the file prior to uploading the data in the portal.

Follow these steps in your CSV file to format the values correctly:

1. Select the entire column containing Data Element 43 – Gender Identity
2. Right-click once the column is selected, and select “Format Cells”
3. Select “Text” from the options listed under “Category”
4. Click “OK” and save your file

The FPAR 2.0 system can be accessed through https://fpar.opa.hhs.gov/.

A Grant Admin account will be created for the project director of your grant. The project director will then create additional Grant Admin or Grant User accounts. If an account has been created for you, you will receive an email with instructions on how to activate your account. If you have not received that email, please contact your project officer.

Grant Admins and Grant Users can view data upload and status, enter FPAR and grant data, run data quality checks, and access the reporting dashboard and Table Archive. Grant Admin can also create a new Grant Admin or Grant User account for others, remove an existing account, and submit data for OPA review.

All passwords must contain at least eight characters, one number, one capital letter, and one special character—for example, a dollar sign ($), an exclamation point (!), or an ampersand (&). A green check mark appears to next to each criterion that the password meets. The system may also reject a password if the reentered password does not match the first password entry. Please ensure that there are no extra spaces for both password entries. A green check mark will indicate when the reentered password matches the first password entry.

Please make sure that the password was entered correctly. Capitalization and spaces matter, so please ensure that all the capitalization is correct and that there are no extra spaces. If that still does not work, you can reset your password by selecting “Forgot your password?” on the login page.

First, log into FPAR 2.0. In the left navigation menu, select “Users.” Then, select “Add user” on the page. Fill out the information requested in the pop-up that appears, then select “Save.” If you are a Grant Admin for multiple grants, please ensure that you are adding accounts in the right grant. The grant is displayed in the static banner at the top of the page.

First, navigate to the “Users” menu tab in the left navigation menu of FPAR 2.0. To remove a user account, select the “Remove” button next to the user’s name and confirm removal of the user. If you are a Grant Admin for multiple grants, please ensure that you are adding accounts in the right grant. The grant is displayed in the static banner at the top of the page.

If you receive verification codes through text message (SMS) and your mobile phone number has not changed, there is nothing you need to do.

If you receive verification codes through text message (SMS) and your mobile phone number has changed OR receive verification codes through Google Authenticator, you will need to update your MFA method.

First, log in to the FPAR 2.0 system. Then, select your profile icon at the top right corner of the static banner and select “My Account.” Once you are on the User Profile page, select “Change MFA.” Finally, select the MFA method you prefer. If you select the text message method, you will be prompted to enter the new mobile phone number. If you select the Google Authenticator method, you must first download the Google Authenticator app on your new device and follow the steps outlined in the system.

The Dashboard will be available once all FPAR data has been approved and reviewed. Once the Dashboard is available, Grant Admins and Grant Users will be notified through email and will be able to view the Dashboard.