Help

Dental Ark Getting Started: First Patient and Backup Acceptance Test

Do not make a real patient your first test. Start with an obviously synthetic record and treat the exercise as an acceptance test: can the clinic create a patient, carry one appointment through treatment and checkout, find the result again, and produce a backup package that passes validation?

This page is the verification path. For a shorter tour of the screens, use the Dental Ark quickstart.

Define the pass conditions

Before entering anything, write down what must be true at the end:

The synthetic patient appears once in the patient index and can be found by the details you entered.
The appointment remains attached to that patient as it moves through the daily queue.
The clinical record is saved as a draft before it is signed.
Doctor confirmation hands the visit to checkout instead of leaving it in treatment.
The bill or no-charge decision remains connected to the visit.
A backup is written outside the active Dental Ark data directory and passes Pre-Restore Check.

The application shell shows the local data directory. Record that location, then choose a different folder or removable device for the test backup. A second file inside the live data directory is not an independent recovery copy.

Prepare the minimum clinic state

Open Staff Schedule and confirm that the clinician used by the test appointment is active and bookable. If the clinic assigns chairs, check Chair Resources as well. Open Procedure Catalog and make sure the test procedure can be selected at checkout.

Use names such as TRAINING PATIENT and TEST CHECKUP. Do not enter a real name, phone number, image, diagnosis, or payment detail. Synthetic data makes it possible to repeat the test without creating a privacy or cleanup problem.

Run the first patient from intake to checkout

Open Front Desk Workbench, choose New Patient, enter the synthetic identity and save it.
Search for that patient before continuing. This proves the saved record can be retrieved and helps catch accidental duplicates.
Choose Create Appointment. Select the patient, bookable clinician, time, and test procedure, then save.
Find the appointment in Today's Flow Queue. Advance it through arrival and treatment using the available Next Step action rather than creating a second visit manually.
Open the patient record. Add a clearly synthetic chief complaint, oral examination, diagnosis, and treatment plan or treatment process.
Choose Save Draft, leave the record, and reopen it. Confirm that the draft fields are still present before using Sign & Save.
Complete doctor confirmation. The visit should become available for checkout; if the queue reports a blocker, resolve the missing record or procedure state instead of bypassing it.
Open Finance, review the visit-linked procedure, and complete a test checkout or an explicit no-charge path. Reopen the patient and confirm that the visit and financial state remain connected.
Record the intended follow-up decision so the case does not remain stranded in an unfinished queue.

The daily clinic workflow explains the normal handoffs, while the billing and payments guide covers the financial states in more detail.

Create and validate the backup package

Open Sync & Backup and note the displayed data directory and database path.
Choose Select directory & backup and select the independent destination prepared earlier.
Wait for Backup successful, then verify that Last Backup and Backup Path identify the archive you just created.
Under Pre-Restore Check, choose Select backup file & validate and open that same archive.
Require Validation Passed. Check the reported product, application/schema version, file count, and error field rather than accepting the filename alone.
Copy the accepted archive to the location assigned by the clinic's recovery plan and record who owns it.

Pre-Restore Check validates the package manifest and its expected files. It is an important gate, but it is not proof that a full recovery has been completed on another workstation. Keep that distinction in the runbook. The backup and restore guide describes the broader backup boundary.

Close the rehearsal cleanly

Capture the pass/fail result and any blocked transition. Do not leave the synthetic patient looking like a real record: archive it according to clinic policy, or repeat the exercise in a dedicated test data directory. Only begin entering live patient data after the workflow, backup destination, validation result, and responsible operator are all unambiguous.

Direct answer and acceptance boundary

For “Dental Ark Getting Started: First Patient and Backup Acceptance Test”, the short answer is: Run a safe first-patient rehearsal in Dental Ark, move the case from appointment to checkout, create a backup, and validate the recovery package. Treat that statement as a result to verify, not as a promise that every input, device, project, or environment behaves identically. A complete result records the starting state, the exact action, the visible output, and the condition that proves the task is finished in Dental Ark.

Evidence-first operating procedure

Work from a small, repeatable case before changing a full project. Record the application version, operating system, input or device identity, relevant settings, and the expected result. Perform one deliberate action, preserve the first unexpected transition, and compare it with a known-good run whenever one is available. Changing several controls at once may hide which condition fixed or created the problem.

Checkpoint 1: Dental Ark Getting Started: First Patient and Backup Acceptance Test

Treat “Dental Ark Getting Started: First Patient and Backup Acceptance Test” as a separate acceptance gate for “Dental Ark Getting Started: First Patient and Backup Acceptance Test”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 2: Run a safe first-patient rehearsal in Dental Ark, move the case from appointment to checko

Verify “Run a safe first-patient rehearsal in Dental Ark, move the case from appointment to checkout, create a backup, and validate the recovery package.” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 3: Define the pass conditions

For “Define the pass conditions”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 4: Prepare the minimum clinic state

Use “Prepare the minimum clinic state” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Checkpoint 5: Run the first patient from intake to checkout

When “Run the first patient from intake to checkout” is ambiguous, compare one known-good case with one failing case under matching conditions. Mark the first meaningful difference rather than listing every later symptom. That first boundary usually produces a clearer support request and a safer next experiment.

Checkpoint 6: Create and validate the backup package

Close “Create and validate the backup package” only after the saved, exported, or reopened result still matches the observed state. Temporary UI feedback is useful, but durable evidence is stronger. Record any limitation that remains so the next reader does not interpret an incomplete path as a successful one.

Checkpoint 7: Close the rehearsal cleanly

Treat “Close the rehearsal cleanly” as a separate acceptance gate for “Dental Ark Getting Started: First Patient and Backup Acceptance Test”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 8: The synthetic patient appears once in the patient index and can be found by the details yo

Verify “The synthetic patient appears once in the patient index and can be found by the details you entered.” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 9: The appointment remains attached to that patient as it moves through the daily queue.

For “The appointment remains attached to that patient as it moves through the daily queue.”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 10: The clinical record is saved as a draft before it is signed.

Use “The clinical record is saved as a draft before it is signed.” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Acceptance matrix

Checkpoint	Evidence to retain	Pass condition
Dental Ark Getting Started: First Patient and Backup Acceptance Test	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Run a safe first-patient rehearsal in Dental Ark, move the case from appointment to checkout, create a backup, and valid	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Define the pass conditions	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Prepare the minimum clinic state	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Run the first patient from intake to checkout	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Create and validate the backup package	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome

Failure isolation, recovery, and handoff

If a check fails, stop at the first failed boundary. Preserve the source, project, session, or capture; duplicate it before destructive editing; and change one variable per experiment. Repeating a broad workflow after several simultaneous changes may produce a different result without explaining why.

Separate absence of evidence from evidence of absence. A blank view may mean the wrong input, scope, filter, permission, device, time range, or project state rather than “nothing happened.” Verify the acquisition or import path before interpreting a decoder, editor, report, or export.

Before handoff, reopen the durable artifact and inspect its beginning, the decision point, and its end. Record version, platform, relevant configuration, expected behavior, observed behavior, and the smallest reproduction. Remove or redact sensitive material and confirm the recipient is authorized to receive it.

Questions and answers

What is the fastest reliable way to start?

Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.

What evidence should be saved?

Keep the input identity, application version, platform, relevant settings, exact action, first unexpected transition, and final output. If the workflow creates a project, session, report, or export, close and reopen it before treating it as durable evidence.

When should the procedure be repeated?

Repeat it after an application, operating-system, driver, firmware, model, source, or workflow change that can alter the result. Preserve the earlier accepted case so the comparison uses the same acceptance boundary rather than memory.

When is the task ready for handoff?

It is ready when another authorized person can identify the input, repeat the action, see the same result, understand any remaining limitation, and open the saved artifact without relying on undocumented local state.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: