Health, Education & Government
›
Government & Public Sector
›
Public Health & Human Services
Public Health Surveillance
Multi-agency, multi-stakeholder programs where procurement, compliance, and mission alignment determine success.
Example organizations in this space:
Palantir
Oracle Health
Tyler Technologies
Conduent
This interactive experience is the shipped product itself — the same application code customers run in production, mounted read-only in your browser over a real sample journey. Not a video, not a mockup: because the demo and the product are one codebase, it can never drift from the real thing.
Inside this journey
-
Pre-Sales
Qualify and diagnose before investing in a full evaluation cycle.
-
Qualification
Confirm funding source, data-sharing authority, procurement constraints, and timeline before investing in full discovery.
Qualification Questions
Funding source and budget
- To make the best use of your time, is there allocated funding for this surveillance platform effort?
- If funding is allocated or expected, which budget range should we assume for the platform and first-year services?
Data-sharing authority and compliance
- Will the data you plan to share include individually identifiable health information or other sensitive personal data?
- Do you already have a legal authority or agreement in place that allows sharing these data with an external vendor (for example statute, MOU, or BAA)?
- If agreement is in progress or required, what is the expected approver or timeline for finalizing data-sharing authority?
Procurement route and decision authority
- Which procurement route will you use for this purchase?
- Who is the primary signatory for contracts and which stakeholders must approve (procurement, legal, IT, program leadership)?
Timeline and go/no-go drivers
- What is your target go-live or reporting deadline that would make a discovery urgent?
- Are there specific dates, grant expirations, or federal reporting windows driving that timeline? If so, please specify.
-
Outcome Discovery
Map surveillance objectives, current data flows, stakeholders, and success metrics needed for rapid detection and federal reporting.
Discovery Questions
Quick situational snapshot
- Tell me briefly which surveillance programs your team is responsible for and which one is the immediate priority right now
- Which data streams feed those priority programs today
- How frequently do those feeds arrive into your primary analytic system
- Who on your team owns ingesting and validating each feed, title or role only
- Describe the federal reporting obligations you must meet, including cadence or triggers that drive immediate notifications
- If a new detection tool needed a 3-month pilot to prove value, what specific condition would make you greenlight that pilot this quarter
When signals become chores, not insights
- When a signal appears that looks meaningful, how often does it lead to investigation rather than being dismissed as noise
- Walk me through the most recent false alert that tied up multiple people, what exactly happened and why it consumed time
- How many staff-hours per week are typically spent investigating alerts and reconciling case counts
- What breaks downstream when hospitals send delayed, duplicate, or inconsistent reports
- What single data quality issue would make you stop a live deployment immediately
Who would realistically need to change their habits
- Who would have to change workflow or priorities for a new platform to actually reduce alert fatigue rather than add one more inbox
- Which of your current thresholds or case definitions are adjusted manually and why
- Tell me about any recent reporting rule changes that are still not reflected in your analytics or dashboards
- Are there policies, legal reviews, or approvals that could prevent sharing lab-level or patient-level feeds with an external partner
- If internal policy blocked sharing raw lab feeds, could you still meet the pilot success criteria using deidentified or aggregated data
If detection worked like clockwork, what would change
- Imagine detection improved so investigations start two days earlier on average, how would day-to-day operations feel different for your surveillance team
- List the measurable outcomes you would use to prove that improvement, for example timeliness, positive predictive value, or reduction in manual reviews
- To whom would you present pilot results to secure funding or approval for a broader rollout, title or committee
- What single organizational step would block converting a successful pilot into procurement if it is not addressed
Real access, constraints, and the things that stop us
- Name the specific systems we must integrate with in the first 90 days and indicate whether they expose an API
- Please identify the team or title that owns those connectors and whether they can assign time to a pilot within 30 days
- Rate the maturity of your patient identity and record linking on a scale of 1 to 5 and note any frequent mismatches
- Are there active legal, privacy, or institutional reviews that will delay data access, and what is the expected timeline
- Name the one technical blocker, for example no API access or no test environment, that would prevent the pilot from starting on your target date
Which other paths are on your table
- List the external vendors, incumbent products, and internal projects you are actively evaluating for improving detection and reporting, and mark which seems most likely to be chosen
- What would have to be true about your incumbent system for you to keep it rather than replace or augment it
- Is there an internal proposal to build or extend capability without an outside vendor, and who is championing that option
- Describe the costs or operational risks in the alternatives that make you hesitant to change today
- Point to the single alternative you would prioritize if budget forces you to pick just one this year, and explain why
If this lands, what happens next
- Pinpoint the timeline constraint that, if tightened, would make you prioritize a pilot this quarter rather than next year
- Identify the budget owner and the tentative amount available for analytic tools this fiscal year
- Quantify the savings or avoided costs the pilot must demonstrate to justify purchase, or describe the non-financial threshold that matters
- Point to any procurement vehicles available, for example state contracts or federal grants, that could accelerate signing
- State the exact next step that would convert a successful pilot into a signed agreement within 30 days
-
-
Solution Experience
Translate the buyer's surveillance use cases into platform workflows, alerting logic, and operational impact using realistic scenarios.
Solution Experience
- Solution Experience Session
- Confirm the current state and its cost
- You confirm the demonstrated workflow reduces analyst triage and false alerts to an acceptable level for a prioritized use case.
- Provide prioritized surveillance use cases and sample data feeds for the scenario runs, including required reporting fields and current weekly volume estimates.
- You confirm the demonstrated reporting output meets your federal reporting completeness and timeline requirements.
- Run a prioritized surveillance use case end-to-end
- Deliver two recorded scenario runs with measured detection latency, alert volume before/after calibration, and reporting completeness metrics before the follow-up session.
- You agree on the remaining technical evidence and data access needed to validate production readiness.
- Demonstrate alert calibration and triage impact
- Identify and confirm named data owners and access windows required for a technical pilot.
- Confirm reporting completeness and timelines
- Define acceptance criteria for detection and reporting that will be used to evaluate pilot success.
- Validate that this matches your need
- Solution Experience Session
- Solution Experience Deck
- Solution Brief
- meeting
- slides
- document
-
Solution Scope
Define integrations, analytics modules, alerting and reporting responsibilities, calibration services, training, and measurable deliverables.
Scope Configuration
- Ingest EHR Data Feed
- Ingest Laboratory Information Systems
- Ingest Emergency Department Syndromic Feed
- Ingest Vital Statistics Registry
- Map and Normalize Clinical Data
- Migrate Historical Case Records
- Configure Disease Detection Algorithms
- Calibrate Alert Thresholds with Epidemiologists
- Deploy Geographic Cluster Analysis
- Configure Automated Case Notification
- Activate Trend Forecasting Models
- Generate Federal- and State-Format Reports
- Train Users on Platform Workflows
- Provide Ongoing Analytics Tuning
Scope Questions
Ingest EHR Data Feed
- Do you receive streaming HL7 v2 ADT or ORU feeds, FHIR APIs, or batched file drops from your hospitals' EHRs?
- List the primary EHR vendor names or 'unknown' for each hospital/clinic that will be in scope for initial ingest.
- Enter the number of hospital and clinic sites to include in initial EHR onboarding and the expected monthly message volume range.
- Specify the transport protocol(s) used by each EHR feed you control (MLLP, SFTP, HTTPS FHIR, other).
- Provide the technical contact role and email for the team who can grant access to the EHR feed and test messages.
Ingest Laboratory Information Systems
- Identify the laboratory information systems (LIS) or reporting services that send ELR into your environment.
- Indicate the ELR message formats you receive (HL7 v2 ELR, CSV lab batches, FHIR DiagnosticReport, other).
- Estimate the typical latency from specimen result to ELR arrival (minutes/hours/days).
- Specify whether your lab feeds use standard test codes (LOINC) or local test codes that require mapping.
- Name the role that can provide the LIS schema, sample ELR messages, and test-code crosswalks during onboarding.
Ingest Emergency Department Syndromic Feed
- Confirm whether your syndromic surveillance feed provides HL7 v2 messages compatible with ESSENCE-style ingestion or a different schema.
- State the percent coverage of emergency departments in your jurisdiction that currently submit syndromic data.
- List the chief complaint, triage, and visit-level fields present in your syndromic messages (free-text chief complaint, coded problem list, triage acuity, disposition).
- Provide the contact role responsible for syndromic feed ingestion and data quality at the health department.
- Indicate whether you have historical syndromic data available for baseline modeling and roughly how many months/years are accessible.
Ingest Vital Statistics Registry
- Indicate whether death certificates and vital records are available electronically and by which method (SFTP extracts, API, portal export).
- State the average lag time from event occurrence (death/birth) to record availability in the registry.
- Describe the coding and structure present on death records (ICD-10 cause of death, free-text cause, race/ethnicity fields, geo identifiers).
- Identify who holds the data use agreement (DUA) signature authority and whether an existing DUA covers analytics use.
- Specify any redaction or privacy rules that must be applied to vital records outputs (minimum cell counts, no point-level maps).
Map and Normalize Clinical Data
- Select the standard terminologies you require for normalization (LOINC for labs, SNOMED CT for clinical findings, ICD-10 for diagnoses).
- Confirm whether you maintain a canonical patient identifier or whether we must perform deterministic/probabilistic matching across sources.
- Enter the estimated count of unique local test codes or local diagnosis codes that will require mapping in the initial normalization pass.
- Upload or point to a sample mapping file, value set, or example rows illustrating lab value normalization (e.g., 'POS' -> 'Positive').
- Clarify whether any jurisdictional reportable-condition code lists must be applied during normalization and whether those lists are maintained centrally.
Migrate Historical Case Records
- Enter the total count and date-range of historical case records to migrate into the platform.
- Select the source formats for historical records you will provide (CSV exports, HL7 archives, database dumps, PDF attachments).
- What migration completeness percentage will constitute acceptance for historical case migration (for example, percent of required fields populated)?
- Identify the role or team that will validate migrated records against your authoritative case registry and approve migration sign-off.
- Describe whether attachments (scanned lab reports, clinician notes) must be migrated and in which formats (PDF preferred, TIFF, other).
Configure Disease Detection Algorithms
- Choose which detection algorithms to configure for go-live (syndromic spike detection, CUSUM aberration, Poisson regression outbreak detection, spatial cluster scan).
- How should notifiable-condition case definitions be encoded (lists of ICD-10 codes, lab-confirmation rules, symptom-based logic tied to chief complaint phrases)?
- Indicate your preference for algorithm sensitivity versus specificity for early warning use cases.
- List any statutory or local case definitions that differ materially from CDC standards and require custom logic.
- Name the single role responsible for approving algorithm logic changes and the escalation path for clinical questions.
Calibrate Alert Thresholds with Epidemiologists
- When should the first multi-day calibration workshop with your epidemiology team occur (after data access, after 2 weeks of data, after 30 days)?
- Choose the surveillance metrics to include in calibration sessions (ED visits per 100k, positive lab test percent, cluster growth rate).
- What acceptance criteria will you use to confirm that calibrated thresholds are adequate (for example, target positive predictive value or acceptable weekly false alert rate)?
- Enter the titles of epidemiologists who will participate in iterative tuning (e.g., surveillance branch chief, state epidemiologist).
- Specify any recurring events or seasonal periods (influenza season start/end, mass gatherings) that should be encoded into threshold schedules.
Deploy Geographic Cluster Analysis
- Indicate the geographic resolution required for cluster alerts (zip code, census tract, county, or custom shapefiles).
- State whether case and lab records include geocoded coordinates or whether we must geocode free-text addresses as part of onboarding.
- Describe the spatial privacy constraints we must enforce in maps and cluster outputs (geomasking radius, minimum cell count like 5, aggregate to county).
- Identify the authoritative jurisdictional shapefiles or base maps to use (state-provided shapefiles, CDC boundaries, or agency GIS exports).
- Estimate the acceptable geographic false-discovery rate or other tolerance for cluster alerts during pilot monitoring.
Configure Automated Case Notification
- Select the automated notification workflows required (automatic lab-positive notifications to reporters, clinician outreach, critical result paging).
- Specify the delivery channels for notifications (secure email, HL7 back-channel, SMS to on-call roster, EHR inbox) and any encryption requirements.
- Provide the case attributes that must appear in automated notifications (patient age, specimen date, LOINC/test code, jurisdiction case ID).
- Name the on-call roster owner and indicate whether on-call contacts will be provided as a static list or via an API.
- Clarify any reporting cadence or throttling rules for notifications (e.g., one notification per cluster per 24 hours).
Activate Trend Forecasting Models
- Select which forecasting horizons you need (1 week, 4 weeks, 12 weeks) for target syndromic indicators.
- Specify which indicators should be forecasted (ED visits for influenza-like illness, positive SARS-CoV-2 tests per 100k, hospitalization counts).
- Estimate the minimum historical data window required for reliable forecasting for your priority indicators (months/years).
- Identify whether you require probabilistic forecast intervals (e.g., 95% prediction intervals) or single-point forecasts.
- Describe any external covariates to include in models (weather, school calendar, special events) and whether feeds for these are available.
Generate Federal- and State-Format Reports
- List the specific federal and state report formats you must generate (CDC ILINet weekly, NNDSS electronic lab reporting format, state CSV schema).
- State the cadence required for each report (daily, weekly, monthly) and whether automated submission to federal systems is required.
- What acceptance evidence will validate that generated reports meet federal and state schema requirements (schema validation pass, sample submission acceptance by CDC/state)?
- Provide any state-specific field mappings or column headers that differ from national templates and a contact who owns the state schema.
- Clarify whether the pipeline must support automated secure submission (SFTP to state/CDC endpoints, API push) or manual export only.
-
Mutual Commit
Finalize commercial and data-sharing terms, responsibilities, SLAs, and acceptance criteria required for go/no-go.
Agreement Modules
- Master Services Agreement (MSA)
- Statement of Work (SOW)
- Subscription Order Form
- Service Level Agreement (SLA)
- Data Sharing Agreement
- HIPAA Business Associate Addendum (BAA)
- Acceptance Criteria & Go/No-Go Signoff
- Change Order Agreement
- Termination, Data Return & Exit Plan
-
Deployment
Lock readiness facts and configuration values before execution begins.
-
Pre-Deployment Readiness
Capture concrete readiness facts the deployment depends on — data access, named owners, test environments, and go-live windows.
Pre-Deployment Questions
Environment and access
- Which environments will the deployment touch? (select all that apply — helps us plan access and test sequencing)
- For each environment selected above, provide the environment name and the named technical owner (name, role, email). This is used to request accounts and schedule access windows.
- Are integration endpoints and service accounts already provisioned for the environments selected? (so we know if credential creation is a pre-step)
Data and configuration
- Which data sources will be included in the initial onboarding? (select all that apply)
- For the sources you selected, who is the authoritative data owner for each (name, role, email) and which source should be prioritized for the pilot? (this sets ingestion order and SLAs)
- Has the buyer agreed on the field-mapping approach and the source-of-truth for core case fields (e.g., unique patient ID, onset date, specimen result flag)?
People and ownership
- Please confirm the named owner for each deployment workstream: data ingestion, integrations, analytics calibration, and user training. List as 'workstream: name, role, email'.
- Is a formal internal approval group required for go/no-go (e.g., IT security, legal/data governance, surveillance leadership)?
- If you selected one or more approvers above, list the approver names, roles, and the minimum approval each must provide for go-live (so we can sequence sign-offs).
Timing and constraints
- What is the target go-live window or pilot start date? If date is flexible, provide earliest and latest acceptable dates. (we use this to book staff and reserve cutover windows)
- Are there blackout windows or reporting freeze periods to avoid during deployment (e.g., federal reporting deadlines, known surge periods)?
- If you answered 'Yes' above, provide the blackout dates or recurring blackout windows and a brief reason (so we can plan around them).
-
Configuration Details
Lock exact configuration values the deployment team will use — integration endpoints, API credentials, field mappings, alert thresholds, and case-definition parameters.
Configuration Details
Environments & Endpoints
- Enter the production integration endpoint URL the platform will pull/push data from (format: https://... — enter exact URL for the production ingestion endpoint).
- Select the deployment region for the production instance (Default is 'US-East (Virginia)' — choose one).
Authentication & Credential Handoff (non-secret values only)
- Select the integration authentication method you will use for the ingestion endpoint (Default is 'OAuth2 client ID; secret exchanged via your secrets manager'). Do NOT paste secrets here.
- Enter the non-secret identifier for the chosen authentication method (client ID, certificate CN, API key name, or SAML entity ID). Example: 'ingest-client-01'.
- Enter the credential owner and the secure channel you will use to exchange the secret (format: 'Full name, role — secrets manager name or secure email'). Example: 'Alice Smith, IT Security — agency-vault'.
Data Field Mappings & Case Status
- Enter the exact source field name that contains the primary patient identifier as it appears in the feed (example: 'patient_id' or 'mrn').
- Select the source field to map to the platform's 'case_status' field (if 'Other', provide exact source field name in the next question).
Alerting, Detection Variant & Case Definitions
- Enter the county-level alert threshold (numeric: cases per 100,000 population measured over a 7-day window). Default is 10 (enter a whole number).
- Select which anomaly detection variant the deployment should enable for initial tuning (Default is 'Statistical control charts').
- Enter the primary case-definition name or identifier the buyer will use for automated case classification and reporting (enter exact name/version as used by the agency). Example: 'NotifiableDisease_X v1'.
- Should the platform send automated federal reporting for accepted cases? (Default: Yes)
-
Deployment
Execute integrations, data onboarding, threshold calibration, training, and pilot monitoring with clear owners, schedule, and escalation paths.
-
-
Success
Monitor detection accuracy and reporting outcomes, capture learnings, and maintain a shared channel for issues and enhancement requests.
Success Reviews
- Go-live Health Check (weeks 1-4)
- First Measurement Review (weeks 4-10)
- Acceptance Gate Review (around day 90)
- Quarterly Success Review (ongoing)
Issues & Enhancements
- Plan targeted refresher training for user cohorts showing low proficiency or adoption within the quarter.
- Run a threshold calibration exercise and publish expected impact on alert volume and PPV within two weeks.
- Deliver a data-quality remediation plan addressing missing or late hospital reports with completion dates.
- Prepare the evidence package to present at the acceptance gate, including the metric extraction queries and raw sample alerts.
- Restate acceptance criteria and numeric targets
- A formal acceptance decision is recorded for the deliverable, with pass/fail documented per criterion recorded in Mutual Commit.
- All remediation items for conditional or failed criteria are scheduled with target dates and verification steps.
- Incumbent system decommission or retention plan is documented and scheduled if applicable.
- Publish the acceptance decision record including metric evidence and the named signatory's confirmation.
- Create remediation work items for any conditional or failed criteria with deadlines and verification tests.
- Execute the incumbent transition steps agreed in the meeting, including data archival or migration verification.
- Trend review for detection accuracy
- Confirm detection positive predictive value and reporting completeness are within acceptable bounds or agree corrective actions if not.
- Prioritize and schedule resolution windows for the top enhancement requests from the shared channel.
- Agree any required training or operational changes to reduce alert fatigue and improve data quality.
- Triage the enhancement backlog and publish prioritized items with target delivery quarters.
- Schedule calibration runs or analytics tuning to address any downward trend in detection PPV.
- Re-confirm success criteria and named owners
- Confirm production data flows from each integration endpoint are active and within expected throughput ranges.
- All critical blockers identified with remediation tasks and target dates.
- Named owners confirmed for each success criterion recorded in Mutual Commit.
- Publish deployment health checklist and send to all named owners for acknowledgement.
- Open incident tickets for any ingestion errors above threshold and record target resolution dates.
- Provision missing user accounts and confirm training completion for core users.
- Present first measurement data
- Determine whether median time-to-detection and reporting completeness are moving toward the targets recorded in Mutual Commit or require remediation.
- Agree a concrete set of calibration and data-quality actions with target dates to close gaps before the acceptance gate.
- Confirm the acceptance gate date and required evidence package scope as referenced in Mutual Commit.
- Present outcome data against each criterion
- Reporting timeliness and completeness
- Validate integrations and ingestion health
- Diagnose root causes for gaps
- Document pass/fail per criterion and decision
- Deployment and configuration verification
- Open issues and shared channel queue
- Calibration actions and short-term monitoring
- Agree remediation plan for any failing or conditional criteria
- User onboarding and access
- Confirm timeline to acceptance gate
- Operational tweaks and training needs
- Document blockers and owners
- Confirm next quarter objectives and checkpoints
- Early signals and usage patterns
- Incumbent system transition check
- Open issues, blockers, and immediate remediation