--- title: Healthcare - Progressive Verification during Authentication - Main Flow description: Learn about the Healthcare - Progressive Verification during Authentication - Main Flow flow, including its purpose, structure, inputs, outputs, and variables. component: pingone-solutions page_id: pingone-solutions:healthcare:flow-reference/healthcare-authentication-with-username-and-password-main-flow canonical_url: https://docs.pingidentity.com/pingone-solutions/healthcare/flow-reference/healthcare-authentication-with-username-and-password-main-flow.html revdate: September 1, 2025 section_ids: purpose: Purpose structure: Structure input-schema: Input schema output-schema: Output schema variables-and-parameters: Variables and parameters --- # Healthcare - Progressive Verification during Authentication - Main Flow The **Healthcare - Progressive Verification during Authentication - Main Flow** lets users sign on. It can be launched through the widget or through PingOne. ## Purpose The **Healthcare - Progressive Verification during Authentication - Main Flow** is one of the initial flows in the Healthcare flow pack solution. It enables existing users to sign on using a password and uses the **Healthcare - Progressive Verification during Authentication - Device Authentication - Subflow** flow to let existing users sign on using a known device. ## Structure This flow is divided into sections using teleport nodes: * **Flow Configuration** Uses multiple function nodes to save the variable and parameter values so that the correct values are available in the flow and in subflows. The flow then progresses to the **Check Session, Call To Protect Analysis & MFA Step-Up** section. * **Check Session, Call To Protect Analysis & MFA Step-Up** Uses a PingOne node to determine whether the user has an existing session: * If the user has a session, a hidden HTML node captures risk information, and a PingOne node fetches additional user information, then the flow progresses to the **Threat Detection and Mitigation** section. When this section completes, a function node checks if the user's account is enabled, and if the user's account is enabled, the flow progresses to the **Return Success** section. * If the user doesn't have a session, the flow checks for any existing session tokens and uses a PingOne node to delete the prior session before invoking the **Healthcare - Progressive Verification during Authentication - SignOn - Subflow** subflow. When the subflow completes, a function node updates the risk level, and a PingOne Authentication node creates a user session. A loading page displays, and a PingOne node retrieves user information. Function nodes then evaluate the number of times the user has logged in. If the count is 2, 4, or 6 logins, the flow progresses to the **Progressive profiling during authentication** section. If the login count is less than 10, a PingOne node updates the login count. The flow then progresses to the **Return Success** section. * **Threat Detection and Mitigation** Uses a function node to check if PingOne Protect analysis is required: * If PingOne Protect analysis is not required, the flow returns to the previous section. * If PingOne Protect analysis is required, the flow invokes the **Healthcare - Progressive Verification during Authentication - Threat Detection - Subflow**. If the **Healthcare - Progressive Verification during Authentication - Threat Detection - Subflow** completes successfully, a function node stores the risk evaluation as a variable, then a second function node branches the flow based on the risk level: * If the risk level is low, the flow returns to the previous section. * If the risk level is medium, the flow progresses to the **MFA Authentication** section. When this section completes, the flow returns to the previous section. * If the risk level is high, a function node checks if the high risk was the result of a new device. If not, a PingOne node notifies the user. A PingOne node deletes the existing session, and a loading page displays. The flow then progresses to the **Check Session, Call To Protect Analysis & MFA Step-Up** section. If the **Healthcare - Progressive Verification during Authentication - Threat Detection - Subflow** completes unsuccessfully, a function node stores the risk evaluation as a variable and the flow progresses to the **Return Error** section. - **MFA Authentication** Uses a PingOne node to look up the user's existing devices. An HTML node then checks the user's current device for WebAuthn support, and comparison nodes filter for unusable devices and check if at least one device is configured. If the user has no active devices or the user's device information could not be found, the flow progresses to the **Step up to register Email MFA device if no MFA devices found during authentication** section. If the user has active devices, the flow invokes the **Healthcare - Progressive Verification during Authentication - Device Authentication - Subflow**. If the subflow completes successfully, a function node saves the user's authentication method as a variable, and the flow returns to the previous section. * **Step up to register Email MFA device if no MFA devices found during authentication** A comparison node checks whether email verification is required. If email verification isn't required, the flow invokes the **Healthcare - Progressive Verification during Authentication - Device Registration - Subflow**. The section then branches based on the device registration result: * If the result is **Complete**, the user's authentication method is stored as a variable and the flow returns to the previous section. * If the result is **Skip**, the flow returns to the previous section. * If the result is **Cancel**, the flow returns to the **Return Error** section if an existing session was found, and to the **Offer Sign On Page** section if no session was found. If email verification is required, the flow invokes the **Healthcare - Progressive Verification during Authentication - Verify Email - Subflow**, then uses PingOne nodes to enroll email as an MFA device and enable MFA for the user. The user's authentication method is stored as a variable, and the flow then returns to the previous section. * **Progressive profiling during authentication** Uses a function node to branch the flow based on the number of successful logins: * If the user has had two successful logins, an HTML node gathers emergency details. * If the user has had four successful logins, an HTML node gathers insurance details. * If the user has had six successful logins, an HTML node gathers information about medical conditions. * If the user has any other number of successful logins, the flow progresses to the **Return Success** section. The flow then branches based on the user's selection: * If the user clicked **Save**, a PingOne node saves the provided information and a success message displays. The flow then progresses to the **Return Success** section. * If the user clicked **Cancel**, the flow progresses to the **Return Success** section. - **Return Success** Sends a JSON Success Response, indicating that the flow completed successfully. Simultaneously, the flow uses function nodes to check for a PingOne Protect risk evaluation ID and verify that the user did not cancel. If a PingOne Protect risk evaluation ID is found and the user did not cancel, the flow uses a PingOne node to update the evaluation status with a success. - **Return Error** Uses a function node to enrich the error details, then displays an error message. The flow checks the flow invocation method, then sends an error JSON response with the appropriate parameters indicating tha the flow completed unsuccessfully. The flow also simultaneously uses a function node to check for a PingOne Protect risk evaluation ID, and if a PingOne Protect risk evaluation ID is found, uses a PingOne node to update the evaluation status with a failure. ## Input schema This flow has the following inputs: | Input name | Required | Description | | ---------------- | -------- | ----------------------------------------------------------------------------------- | | `flowParameters` | No | An object containing parameters passed in if the flow was launched with the widget. | ## Output schema This flow has the following outputs: | Output name | Description | | ---------------- | ---------------------------------------------------------- | | `p1UserId` | The user's PingOne user ID. | | `p1Username` | The user's PingOne username. | | `authMethod` | The authentication method that was configured by the flow. | | `successMessage` | The success message to display. | | `errorMessage` | The error message to display. | ## Variables and parameters This flow uses the following variable or parameter values: | Variable name | Description | | -------------------- | --------------------------------------------------------------------------- | | `canEnrollOnlyEmail` | A Boolean indicating whether email should be the only permitted MFA device. | | `resendOtpAttempts` | The number of times the user has resent the OTP. | | `p1MFADeviceId` | The device ID for the device being registered. |