Privacy Policy

This policy explains how Ziurta LLC ("Ziurta", "we") handles personal information across two places: this website at ziurta.com, and the Ziurta platform at app.ziurta.com.

It does not cover third-party sites we link to, or the internal privacy practices of the organizations that use our product.

We handle personal information in two distinct capacities, and your rights differ depending on which one applies.

• As a business, for our own purposes. When you email us, create an account, or sign in, we decide how that information is used. This policy governs it, and you can exercise the rights in section 11 with us directly.
• As a service provider, on a customer’s behalf. Everything inside a customer’s account — their provider roster, applications, tasks, comments and notes — is processed only on that customer’s instructions. They decide what goes in, what it is used for and when it is deleted. Our obligations there are set out in the Data Processing Agreement, and section 12 explains where to send a request about that data.

ziurta.com sets no cookies, runs no advertising scripts and uses no tag manager. There is nothing to consent to, which is why you were not shown a banner. If you email the address on our contact page, that message reaches our business inbox and nowhere else.

We do measure how the site is used, through Vercel Web Analytics. It counts page views and records the page you came from, your browser type and your country. It sets no cookies, stores no identifier on your device, and does not follow you across sites or sessions. We cannot tell who you are from it.

If you give us your email address to receive updates, we store it with SendGrid, our email provider, and use it only to send you those updates. Every message carries an unsubscribe link, and you can also ask us to remove you at any time using the address on our contact page.

The product at app.ziurta.com does set cookies, but only the ones strictly necessary to keep you signed in and to protect the session. It carries no advertising or analytics cookies.

• Account information — name, business email address, organization and role, together with authentication data handled by our identity provider. We never see or store your password.
• Customer Data — the provider rosters and workflow records our customers put into the product. See sections 5 and 6 for what this consists of, and section 2 for who controls it.
• Correspondence — what you send us by email, and our replies.
• Technical and diagnostic data — server and request logs, and error reports generated when something goes wrong. Error reports can incidentally include identifiers present in the context of a failure.

Ziurta is a platform of modules, and each collects only the personal information its own purpose requires. We publish that scope here rather than leaving it to inference, and we publish it before a module starts accepting data — never afterwards.

One thing is true of every module, now and in future: we never collect information about a patient, and no module we release will. Section 14 explains what that means and why.

Because a module only holds what it is built to hold, our terms ask you not to submit information outside that scope — and in particular not to put sensitive identifiers into free-text fields such as comments and notes, whatever module you are using.

As we release further modules, what the platform collects will grow. Credentialing, for example, cannot work without information this list does not include today. When that happens this section changes first, and we give notice before a change materially expands what a module you already use collects.

The Revalidations module works with data about healthcare providers: National Provider Identifier, name or organization name, business mailing and practice address, taxonomy, and Medicare enrollment and revalidation status.

Most of that originates in two public federal sources — the NPPES registry and the CMS Revalidation Due Date List published on data.cms.gov — which anyone can download. A customer’s own roster upload tells us which of those providers it is responsible for. It is business and professional information, not personal or household information, but we treat it carefully regardless.

• to provide, secure, support and improve the Service;
• to match customer rosters against public CMS data and to generate the deadlines, applications and tasks that follow from it;
• to send transactional and notification email, such as an approaching revalidation deadline or a task assignment;
• to answer your questions and provide support;
• to detect and prevent abuse, fraud and security incidents, and to maintain an audit trail; and
• to comply with law and enforce our terms.

We may produce aggregated, de-identified statistics about how the Service is used. These cannot identify you, your organization or any provider.

• Subprocessors. A short list of vendors that host the Service, authenticate users, monitor errors and send email. Each is published at ziurta.com/legal/subprocessors with what it processes and where. All are located in the United States and are bound to use the data only to provide services to us.
• Professional advisers — for example accountants or lawyers, under confidentiality.
• Legal requirements. Where we are compelled by valid legal process, or where disclosure is necessary to protect rights, safety or the security of the Service. If we receive a demand for a customer’s data, we will notify that customer unless legally prohibited.
• A business transfer. If we are involved in a merger, acquisition or sale of assets, information may transfer as part of it. The acquirer remains bound by this policy for information collected before the change, or you will be told before anything different applies.

Account and Customer Data is retained for as long as the account is active. After termination, a customer has 30 days to export, and we then delete Customer Data within 30 days. Copies inside routine encrypted backups persist until they age out on our provider's rolling schedule.

Correspondence is kept as long as needed to handle the matter and for our records. Diagnostic and error data is kept on a short rolling window. Audit log entries are retained for the life of the account, because their value is precisely that they cannot be edited or selectively removed. Records we must keep by law are kept for the required period.

Depending on where you live, you may have the right to know what personal information we hold about you, to obtain a copy, to correct it, to delete it, to limit our use of sensitive information, and not to be discriminated against for exercising these rights. California residents have these rights under the CCPA as amended by the CPRA, and residents of a number of other states have comparable rights under their own laws.

To make a request, email privacy@ziurta.com. We will verify your identity before acting, usually by confirming control of the email address associated with the information, and we will respond within the time your state’s law allows. An authorized agent may act for you with proof of authorization. We do not charge for this, and using these rights will not affect your service.

We do not sell or share personal information, so there is no opt-out to exercise. We also honor a browser Global Privacy Control signal where one is sent.

If you are a healthcare practitioner and your information appears in the Service, it is almost certainly there because an organization you work with — a practice, health system, billing company or credentialing vendor — uploaded its roster, or because it appears in the public NPPES and CMS registries.

We process that information only on that organization’s instructions and cannot decide on our own to change or delete it. Please send your request to that organization directly; it is the one that can act on it. If you contact us instead, we will pass the request to the relevant customer and tell you we have done so. Where we can identify the customer without further information, we will.

Information that comes from NPPES or the CMS Revalidation Due Date List is published by the federal government and remains publicly available at source regardless of what we do, so corrections to it need to be made with those registries.

No system is perfectly secure, but the following measures are in place today:

• Tenant isolation at the database layer — Every table holding Customer Data is scoped to a tenant and additionally protected by PostgreSQL Row-Level Security policies. The application connects as a restricted role without the ability to bypass those policies, so a missed filter in application code cannot expose one customer's data to another.
• Encryption — Data is encrypted in transit using TLS, and encrypted at rest by our hosting and database providers.
• Access control — Access to the Service is authenticated through a dedicated identity provider, with role-based permissions enforced centrally rather than per route. Administrative access to production infrastructure is limited to personnel who require it.
• Audit logging — An append-only audit log records roster changes, application and task activity, status changes, role changes and configuration changes, with the acting user and timestamp.
• Data residency — Hosting, database and authentication providers are configured to United States regions.
• Secrets handling — Service credentials are held in encrypted environment configuration. API keys and webhook secrets are stored hashed and shown only once at creation.
• Backups — The database provider maintains automated backups with point-in-time recovery. Backups are encrypted and purge on the provider's rolling schedule.
• Minimization by design — Each module collects only the personal information it needs for its own purpose, and that scope is published rather than left to inference. No module processes patient information. The modules generally available today collect no Social Security numbers, government identification numbers, dates of birth or financial details, and provide no document or attachment storage.

If you believe you have found a vulnerability, please tell us at privacy@ziurta.com before disclosing it publicly. We will not pursue good-faith security research that respects customer data and does not degrade the Service.

The Service is not built to receive protected health information, and our terms prohibit customers from submitting it. Ziurta is not a HIPAA Business Associate and does not offer a Business Associate Agreement.

This is a permanent commitment, not a description of the current product. Ziurta works with information about healthcare providers — who they are, and where they stand with Medicare and, in future, with other payers and credentialing bodies. That is professional information about a practitioner, not information about a patient, and the distinction is deliberate: no module we release will collect patient data.

If you believe patient information has reached the Service, tell us at privacy@ziurta.com and we will work to remove it.

The Service is offered to organizations in the United States, and all information is stored and processed there. We do not offer the Service in the European Economic Area, the United Kingdom or Switzerland, and this policy does not attempt to describe rights under those regimes. If you are located outside the United States, do not use the Service.

The Service is a business tool and is not directed to children. We do not knowingly collect personal information from anyone under 16, and will delete it if we learn we have.

We will update this policy when our practices change. The date at the top of this page always reflects the current version. If a change materially affects how we handle information about you, we will give notice by email to account administrators or in the Service before it takes effect.

Privacy questions and requests: privacy@ziurta.com. Anything else: info@ziurta.com.

Ziurta LLC