TL;DR
Before adding a tracking tool, document what runs on each page, what information it can receive and where that information goes. Give that record to the practice's privacy, legal and technical reviewers. A marketing checklist cannot determine compliance by itself.
Start with the actual website
List the public site, appointment destination, contact forms, embedded videos, chat tools and analytics or advertising scripts. Include tools installed through a tag manager and tools supplied by the website platform.
For each one, identify the responsible vendor and practice owner. Do not assume that an old installation is still approved because no one remembers adding it. Likewise, do not remove systems impulsively before understanding operational dependencies and the authorized change process.
The purpose of this inventory is to give reviewers facts. It is not to classify every page visit as protected information or declare every public page harmless.
Use a data-flow worksheet
| Field | Question to answer |
|---|---|
| Page or component | Where does the tool run? |
| Trigger | Does it run on page load, a click or form submission? |
| Data | What fields, URLs or identifiers are actually transmitted? |
| Destination | Which system or vendor receives them? |
| Purpose | What approved business task requires the data? |
| Access and retention | Who can access it, and what documented retention applies? |
| Review status | Who reviewed this specific configuration? |
Ask the technical reviewer to verify behavior using an approved method. Marketing staff should not paste real patient submissions into a shared document to illustrate a problem. Use synthetic examples and appropriately limited technical evidence.
Separate the legal question from the implementation question
The NIST Privacy Framework, Version 1.0 includes selective collection and disclosure of data among its privacy-management outcomes. Use that principle to ask whether each proposed transmission is necessary for the stated task. The framework does not determine the practice's legal obligations or certify a tracking configuration.
Have qualified reviewers evaluate the actual data, recipients, contracts and applicable jurisdiction before changing tracking. The worksheet supplies facts for that review; it does not label every public-page visit as protected health information or declare it exempt.
A vendor's general statement that its product supports healthcare use does not establish that your configuration, contracts and data flows are appropriate. Have the responsible reviewers evaluate the actual use case and applicable obligations.
The technical question is narrower: does the deployed system behave as described? An approved design still needs verification after implementation.
Review a proposed change before release
For a proposed event measuring clicks from a service page to an outside scheduler, the change request should identify the event name, destination, data fields and purpose. It should also explain whether any page or query-string information could reveal more than intended.
The practice's reviewers can then decide what is appropriate. Do not treat a desire for better attribution as automatic permission to collect additional data. First define the event the report needs to measure, then assess the data needed for that purpose.
Keep the inventory current
Reopen the review when the site adds a form, changes a scheduler, installs a marketing tool or alters event parameters. Store the approved configuration and its owner with the change record.
Frequently asked questions
Can a privacy policy alone approve a tracking setup?
No single document establishes that the implementation is appropriate. The practice needs a review of its actual tools, data flows and obligations.
Should the marketing report contain patient-level examples?
Use aggregate, non-sensitive information when it can answer the business question. Any proposed use of identifiable information needs explicit review through the practice's approved process.