Healthcare

CRS supports healthcare workflows where a patient is applying for a financing product to pay for elective or non-insurance covered care. That includes patient financing applications, point-of-service prequalification for installment plans, and routing patients to lending partners that fund their care. The common thread is that the patient is initiating a credit transaction and has consented to the credit pull as part of that application.

CRS does not support credit pulls outside of a permissible purpose under the Fair Credit Reporting Act. Pulling consumer credit data for general billing decisions, scheduling decisions, or clinical decisions is not a permissible purpose and is not a supported use case. Workflows must be tied to a patient-initiated credit transaction or to the patient's written instruction.

The most common permissible purposes in healthcare workflows are the patient's written instruction (the patient signs a consent for the credit pull as part of a financing application) and a credit transaction initiated by the consumer (the patient is applying for a loan, payment plan, or installment product offered by the provider or a third-party lender). CRS works with clients to confirm the permissible purpose framework before any credit pull is enabled.

No. CRS data is not designed for and should not be used for clinical decisions, scheduling decisions, or any decision about whether to provide care. CRS supports financing decisions for patients who have chosen to apply for a financing product, not provider-side decisions about care delivery.

No. A soft inquiry does not affect a consumer's credit score and is not visible to other lenders. Soft inquiries are typically used for prequalification, where the patient is exploring financing options before formally applying for credit.

A soft pull is used at the prequalification stage to give the patient a sense of which financing offers they may be eligible for, without affecting their credit score. A hard pull happens when the patient formally applies for a specific financing product and a lender makes a credit decision. Both require permissible purpose under the FCRA, but the hard pull is the one tied to the actual extension of credit.

Yes. CRS supports patient financing marketplaces that match applicants to financing partners. The marketplace must have permissible purpose at the point of the pull (typically through the patient's written instruction or as part of a credit transaction the patient has initiated) and must comply with adverse action and other FCRA requirements when an applicant is declined or routed away from a particular partner.

When a patient applies for credit and is declined, the lender that made the credit decision is responsible for delivering the adverse action notice required under the FCRA and ECOA. CRS supports compliant workflows by providing the data and infrastructure that lenders use to make these decisions and to generate the required notices.

Yes. CRS offers credit monitoring products that a declined applicant can opt into separately, on their own initiative and with their own consent. These products give the consumer visibility into their credit profile and tools to work toward eligibility. Enrollment in these products is consumer-initiated and separate from the original financing application.

CRS provides the underlying credit data infrastructure. Patient consent, disclosure, and the language used to obtain written instruction are the responsibility of the provider or lender operating the financing workflow, and should be drafted with FCRA and applicable state law in mind. CRS works with clients to ensure their integration is structured around a valid permissible purpose, but the client owns the consent surface.

Is CRS data used to make clinical or eligibility-for-care decisions?

Clients operating patient financing workflows are responsible for maintaining permissible purpose for each credit pull, providing required disclosures to consumers, delivering adverse action notices when applicable, complying with the duty to investigate disputes, and adhering to data security and dispute resolution requirements under the FCRA. CRS provides the data infrastructure and supports compliant workflows, but the regulated party for most FCRA obligations is the user of the consumer report (typically the lender or the provider running the financing program).

CRS data is consumer credit data, not protected health information, and is governed primarily by the FCRA rather than HIPAA. However, providers integrating CRS into healthcare workflows are responsible for ensuring that their own systems and processes comply with both regulatory frameworks where they intersect, particularly when credit data and patient health information are stored or processed in the same environment.

CRS treats all consumer credit data as protected under the FCRA and applicable state privacy laws. Data is transmitted and stored using industry standard security controls, and access is restricted to the workflows and personnel that have been authorized as part of a client's integration. Clients are responsible for ensuring their own systems and personnel meet the requirements of the FCRA, applicable state privacy laws, and any healthcare-specific obligations that apply to their business.

CRS data is consumer credit data, not protected health information, and is governed primarily by the FCRA rather than HIPAA. However, providers integrating CRS into healthcare workflows are responsible for ensuring that their own systems and processes comply with both regulatory frameworks where they intersect, particularly when credit data and patient health information are stored or processed in the same environment.

No. CRS does not support and does not enable the use of credit data to vary the price of medical care to a specific patient. CRS supports financing workflows where the patient is choosing among credit products offered by lenders, not provider-side pricing decisions for the underlying care itself.

CRS maintains records of credit pulls and the permissible purpose attested to at the time of each pull, and can support client audits and regulatory inquiries with appropriate records. Clients should retain their own records of consumer consent, disclosure delivery, and any adverse actions taken, since those records are typically held by the regulated party operating the workflow.