How to Write an athenahealth Calendar Integration RFP: A Requirements-to-Evidence Workbook
For practice managers asking how to write an athenahealth calendar integration RFP, the starting point is practice-defined scheduling scenarios, not a vendor feature list. The RFP should make every bidder respond to the same scope, priorities, evidence requests, responsibility boundaries, pricing assumptions, and future acceptance tests. That structure gives medical-group buyers, healthcare IT reviewers, practice privacy reviewers, and procurement leads comparable proposals and clear stop conditions.
What should an athenahealth calendar integration RFP produce?
It should produce a comparable requirements-to-evidence workbook, not a collection of vendor narratives. Every response should connect a real scheduling risk to a prioritized requirement, a fixed vendor response state, requested proof, a witnessed scenario, a future acceptance test, and an accountable practice owner.
The final package should contain six linked artifacts:
- A scope register defining included providers, calendars, departments, locations, platforms, and transactions.
- A requirements-traceability matrix with mandatory, conditional, preferred, and out-of-scope labels.
- A scenario-and-evidence library covering normal work, exceptions, failures, recovery, and lifecycle changes.
- A responsibility map spanning the practice, vendor, athenahealth administration, Google Workspace, and Microsoft 365.
- A normalized response and pricing worksheet.
- A decision record with clarification, shortlist, conditional-shortlist, and reject outcomes.
What belongs in the scope inventory?
Inventory each provider-calendar pair and every operational boundary that could change a vendor’s answer. Do this before writing requirements so bidders do not silently assume different providers, calendar containers, locations, transactions, or administrative duties.
| Scope field | Questions the practice must answer |
|---|---|
| People and locations | Which providers, departments, clinic locations, time zones, and pilot cohorts are included? |
| Calendar topology | Google Calendar or Outlook; primary, secondary, shared, delegated, group, or resource calendar; managed or personal account? |
| Transactions | Creation, rescheduling, cancellation, blocks, recurring exceptions, competing edits, recovery, onboarding, and offboarding? |
| Authority | Which system and role may create, change, approve, verify, or reverse each schedule state? |
| Data and support | Which fields, permissions, retention rules, support owners, fallback paths, and exclusions apply? |
athenahealth’s event-notification topic guide distinguishes appointment schedule, update, reschedule, and cancel events, reinforcing the need to specify lifecycle transactions rather than ask whether appointments are merely supported. Use a minimum necessary calendar data governance worksheet to define field-level data, visibility, permission, and lifecycle boundaries before vendors respond.
How should requirements be prioritized and traced?
Assign every requirement a priority, consequence, owner, proof request, and acceptance method. Mandatory means the proposal cannot advance without current support or an explicitly acceptable resolution; conditional applies only to identified scope; preferred improves fit; out of scope receives no evaluation credit.
| Operational risk | Priority and requirement | Vendor response | Required proof | Demo or acceptance | Owner |
|---|---|---|---|---|---|
| A cancellation leaves calendar residue | Mandatory: reconcile the canceled appointment in both systems | Fixed response state | Current documentation and demonstration | Cancel, inspect both systems, retain evidence | Practice operations |
| Both systems are edited | Mandatory: disclose precedence and conflict handling | State dependencies and exclusions | Configuration evidence | Competing-edit scenario | Integration owner |
| A connection is lost | Conditional: detect, contain, recover, and reconcile | State monitoring and support boundaries | Sample alert and recovery record | Disconnect-and-recovery test | Healthcare IT |
| A provider leaves | Mandatory: revoke access without leaving schedule residue | State every responsible party | Lifecycle documentation | Offboarding negative test | Lifecycle owner |
This matrix prevents a feature score from hiding the operational reason a requirement exists.
Which scenarios and evidence should vendors provide?
Require scenario-level responses for routine transactions, exceptions, failures, recovery, and provider lifecycle changes. A generic feature checklist cannot show whether a proposal handles the practice’s actual combinations of authority, recurrence, calendar container, and failure state.
- Appointment creation, rescheduling, cancellation, and source-system reversal.
- One recurring occurrence versus an entire recurring series.
- Provider availability blocks, competing edits, and unauthorized edits.
- Notification loss, connection loss, retry, reconciliation, and recovery.
- Provider onboarding, account change, leave, and offboarding.
- Negative tests for excluded calendars, denied permissions, unsupported states, and revoked access.
Google’s Calendar Events reference and Microsoft’s event resource documentation describe different event properties, recurrence behavior, identifiers, and container models. Ask for current documentation, witnessed demonstrations, configuration evidence, sample operational reports, contractual language, or pilot evidence appropriate to each claim. A roadmap statement is not proof of current support. After proposals arrive, apply proof-based athenahealth calendar integration vendor due diligence to the shortlisted responses.
How should responsibility boundaries be mapped?
Assign configuration, permission, monitoring, reconciliation, support, and revocation duties to named organizations and roles. Do not accept shared responsibility unless the proposal identifies who acts first, who supplies evidence, who approves the result, and who owns unresolved work.
| Duty | Practice | Vendor | athenahealth admin | Google admin | Microsoft 365 admin |
|---|---|---|---|---|---|
| Approve scope and authority | Accountable | Consulted | Consulted | Consulted | Consulted |
| Configure mappings and rules | Approve and verify | State and perform vendor duties | Configure assigned athenahealth controls | Configure Google controls if applicable | Configure Microsoft controls if applicable |
| Monitor and reconcile | Own schedule impact | Provide product evidence and escalation | Support athenahealth investigation | Support Google investigation | Support Microsoft investigation |
| Revoke and offboard | Authorize and close | Remove vendor connection | Remove athenahealth access or mapping | Revoke Google authorization | Revoke Microsoft authorization |
An unowned monitoring, reconciliation, escalation, or revocation duty is a boundary defect, not a minor documentation gap.
How should proposals be normalized?
Make vendors classify every requirement using the same five response states. Then require dependencies, exclusions, assumptions, responsible parties, and costs whenever the answer is not standard current support.
| Response state | Required disclosure |
|---|---|
| Supported now | Current version, standard configuration, documentation, and evidence method. |
| Supported with configuration | Exact configuration, prerequisite, administrator, and recurring operating duty. |
| Requires custom work | Defined deliverable, dependency, quoted cost, ownership, maintenance, and acceptance path. |
| Planned | Roadmap status and dependency; no current-support credit for mandatory requirements. |
| Unsupported | Operational consequence, workaround if any, and affected requirement. |
Give all bidders the same pricing assumptions: provider-calendar pairs, departments, locations, platforms, environments, contract term, support model, custom work, internal administration, lifecycle changes, and exit obligations. Use a total-cost worksheet for calendar integration proposals after equivalent scope has been established.
Why should Google Calendar and Outlook use separate platform appendices?
Keep practice-level workflow requirements common, but document platform-specific authorization, containers, event states, notifications, and administration separately. Cross-platform feature parity should be demonstrated, not assumed.
| Appendix topic | Google Calendar questions | Outlook questions |
|---|---|---|
| Authorization | Which OAuth scopes, users, calendars, and consent path? | Which delegated or application permissions, tenant consent, and mailbox boundary? |
| Containers | Which primary, secondary, shared, or subscribed calendars are read or written? | Which user, additional, shared, group, or resource calendars are read or written? |
| Event states | How are status, visibility, free/busy, recurrence, and exceptions interpreted? | How are show-as, sensitivity, response, recurrence, exceptions, and cancellation interpreted? |
| Change detection | How are per-calendar channels renewed and missed notifications reconciled? | Which subscription resource and permission model applies, and how are expirations recovered? |
Google advises choosing narrowly focused Calendar API scopes and states that push-notification channels are created per watched resource and may occasionally miss messages. Microsoft distinguishes granular delegated and application permissions, while its Outlook change-notification guidance describes different permission considerations for mailbox and shared-resource scenarios. Require the vendor to identify the exact model proposed for the practice.
How should acceptance criteria be written during the RFP?
Write each criterion as a future test card with an initial state, action, expected state in both systems, evidence, and owner. The RFP defines the test; a later demonstration or pilot executes it.
- Initial state: appointment and calendar event agree at the original time.
- Action: an authorized role reschedules the appointment in the approved source.
- Expected athenahealth state: the appointment shows the approved new interval.
- Expected calendar state: the matching event shows the new interval without an active duplicate.
- Evidence: identifiers, timestamps, screenshots or exports, and observed exceptions.
- Owner: the person who decides pass, condition, retest, or fail.
Convert selected criteria into a pilot acceptance matrix for athenahealth calendar sync only after the RFP identifies a viable proposal.
What should the proposal gate decide?
The gate should produce clarification, shortlist, conditional-shortlist, or reject—not merely a total score. A high weighted score must not override an unsupported mandatory workflow, unresolved data boundary, unowned operational duty, or untestable claim.
| Outcome | Use it when |
|---|---|
| Clarification | The answer is incomplete but potentially resolvable before scoring. |
| Shortlist | Mandatory requirements and responsibility boundaries are supported by adequate evidence. |
| Conditional-shortlist | Named conditions, owners, evidence, and deadlines must be resolved before a pilot. |
| Reject | A mandatory workflow is unsupported or a consequential boundary remains unresolved. |
If a pilot follows, use an operational outcome scorecard for a calendar sync pilot rather than treating functional acceptance alone as evidence of broader operational value.
How do you write an athenahealth calendar integration RFP workbook?
Build the workbook in the same order a practice will use it to make the procurement decision. Keep requirement IDs consistent across the scope register, vendor response sheet, evidence library, demonstration agenda, acceptance cards, pricing schedule, and final decision record.
- Name the decision owner and authorized operations, IT, privacy, and procurement reviewers.
- Freeze the provider, location, platform, transaction, data, and support scope.
- Translate operational risks into prioritized requirements.
- Attach scenarios and evidence requests to each consequential requirement.
- Assign every cross-organization duty.
- Issue fixed response states, pricing assumptions, and separate platform appendices.
- Define clarification and mandatory-requirement gates before responses arrive.
- Record the final shortlist, conditions, rejections, and next-step tests.
Where do current Sporo options fit?
Review current products only after the practice-owned workbook is ready, and evaluate them under the same evidence rules as every other option. Commercial destinations include the Sporo Health homepage, the current athenahealth and Google Calendar product page, the athenahealth and Microsoft Outlook product page, and the Sporo athenaConnect Marketplace listing. This is how to write an athenahealth calendar integration RFP that remains vendor-neutral while still supporting a practical next-step comparison.
Frequently asked questions
Use these answers as minimum procurement rules, then adapt the workbook to the practice’s authorized operating, technical, contractual, and privacy review.
Does a small practice need a formal RFP document?
No. A small practice may use a concise RFP workbook, but it should still define scope, mandatory scenarios, evidence requests, responsibility boundaries, pricing assumptions, and a decision record.
How many requirements should be mandatory?
Only requirements whose failure would make the proposed workflow unacceptable should be mandatory. Each one needs a stated operational consequence, owner, evidence request, and acceptance method.
Should vendors answer requirements with yes or no?
No. Require supported now, supported with configuration, requires custom work, planned, or unsupported, plus dependencies, exclusions, costs, assumptions, and the responsible party.
Is a yes-or-no HIPAA compliance question enough?
No. Request concrete information about data flows, permissions, contracts, incident responsibilities, retention, and administrative controls for review by the practice’s authorized privacy, security, and legal experts. HHS’s business associate contract guidance shows why contract duties and safeguards need specific terms.
When should acceptance criteria be executed?
Write them during the RFP stage, then execute them during a later witnessed demonstration or bounded pilot using the agreed initial state, action, expected states, evidence, and owner.
Can Google Calendar and Outlook use the same RFP appendix?
No. They may share practice-level workflow requirements, but permissions, calendar containers, event states, notifications, and administration should be documented in separate platform appendices.
Sources
- athenahealth event-notification subscription topics
- Google Calendar Events API reference
- Google Calendar API scope guidance
- Google Calendar push-notification guidance
- Microsoft Graph event resource
- Microsoft Graph Outlook change notifications
- Microsoft Graph permissions overview
- HHS business associate contract guidance
