athenahealth Response: athenaNet® provides for role-based user access control which grants varying degrees of access to users with different levels of authority within a medical group or other organization.

Benefit to You: This provides the practice with the ability to control what level of information each user has the ability to access. Your practice can decide not to allow receptionists to have access to schedule creation or billing admin for example. The added benefit is that each transaction is tagged with the user's name for monitoring and training purposes.

athenahealth Response: All athenahealth systems are monitored for interruptions and security protocols 24 hours a day.

Benefit to You: athenahealth has planned for redundancy with multiple, geographically diverse hosting facilities to minimize the impact of system or network interruptions. In addition, there are mirrored copies of the data within each hosting facility, and the full system is backed up each night to multiple, offsite locations.

athenahealth Response: Yes, this level of security is available.

Benefit to You: The benefit is that no other group can accidentally change or delete your templates. You are given the flexibility, however, to have one central group create all templates if you so desire.

athenahealth Response: A void audit trail is currently in place.

Benefit to You: This provides the practice with the ability to view voided transactions and the user who completed the transaction for monitoring purposes.

athenahealth Response: All passwords in athenaNet are carefully protected using generally accepted security protocols. Like all data in athenaNet, they are only transmitted over cryptographically secured channels via the HTTPS protocol. User passwords are also never stored within our databases; instead a cryptographic hash function (DES) is used, which allows us to confirm a user’s password without persisting it in our system.

Allowed passwords can be configured by practice security administrators, but we discourage changing parameters from the defaults. These parameters include the minimum password length, the minimum password complexity, the number of inactive minutes before session timeout, the number of failed login attempts before the account is blocked, and the number of unique passwords which must be used before a password can be reused.

athenahealth response: athenahealth does not create patches to be installed by customers. It is purely a browser based application and the only tool that must be installed at user locations to support athenaClinicals^SM is ActiveX Controls which support tablet based annotation functions. Hot-fixes and patches made to the application are administered centrally by athenahealth to our servers in our data center as described above. Customers are responsible for maintaining any technology infrastructure they use to connect to athenahealth using a browser. athenahealth can detect whether certain requirements are in place, such as browser version.

For patches to athenaNet:

• There’s no need for customers to locate approved patches or verify the version of the software it’s applied to; both of these functions are managed locally, since athenaNet runs on a single, unified codebase. This also applies to coordinating patches with respect to which functions or settings must be on or off for the patch to work, and to testing procedures to identify that the patch was correctly applied.
• The impact of patches is communicated with release notes.

For patches to the operating system, athenaClinicals has never either required or contraindicated the application of any Windows hotfixes or upgrades. However, if such a situation arose, it would be communicated in the same manner as patches to Internet Explorer.

athenahealth doesn’t provide a software system which resides on the user’s computer or installation media; our product is delivered over the web. Regarding patches or updates to our servers, we install patches from a small number of software sources we trust (SuSe, IBM, and Oracle). We verify these patches using MD5 checksums. We then roll them out in several stages: first they are applied to a development server which is regression tested; then they are loaded onto a single, less used production server for a period; then to a small set of fully utilized production servers for a period; then into production generally. If problems appear in any of these stages, we pause the rollout and investigate/solve the problem before continuing.

athenahealth Response: athenahealth tracks product performance by looking at Target Average Render Time (TART). A page-by-page target is maintained for how quickly the application returns a page, and performance is tracked against this. The TART for most pages is one second, but certain critical workflow pages have lower TARTs, and certain resource intensive pages (e.g., reports) have higher TARTs. In 2007, this metric was changed to track the 90th percentile time of pages, and the per page metrics were adjusted to 1.15s target.

Using a system with a Windows XP system with a 2.40 GHz Intel CeleronProcessor, 256 MB RAM, and a 80Gb hard drive, and a network connection to athenaNet with less than a 100ms consistent average ping roundtrip time and less than 3% sustained packet loss, users can expect pages to render in 1.15 seconds with 10 concurrent users.

athenahealth Response: While athenaClinicals is centrally-hosted, athenahealth takes preventive measures against malware affecting our centrally-controlled code base. Our servers are patched and updated according to the following process: we install patches from a small number of software sources we trust (SuSe, IBM and Oracle). We verify these patches using MD5 checksums. We then roll them out in several stages: first they are applied to a development server which is regression tested; then they are loaded onto a single, less used production server for a period; then to a small set of fully utilized production servers for a period; then into production generally. If problems appear in any of these stages, we pause the rollout and investigate/solve the problem before continuing.

athenahealth Response: The athenaNet application uses NTP time synchronization. Time stamps are recorded for any user actions within the EHR, and are generated by our computer systems.

The athenahealth database and web servers synchronize their clocks with a central server in athena’s datacenter via NTP version 4.2.0. That server is an NIST (National Institute of Standards and Technology) stratum 2 server, which receives its time via NTP (same version) from three statum 1 servers:

time-a.nist.gov
time-a.timefreq.bldrdoc.gov
nist1-ny.WiTime.net

All timestamps in the application (including security timestamps) are generated in the database, which in turn receives its time from the operating system, which is kept synchronized via NTP as described above.

athenahealth Response: The athenaClinicals application always assumes that it is being run over an open network (even though some of our clients have private connections to the application). Therefore, all communication between users and the application takes place using HTTP over SSL (HTTPS), using AES-256 256 bit encryption. This communication protocol, coupled with the use of site certificates, provides a high level of protection of data (such as any PHI communicated) against confidentiality failure, integrity failure, and false remote nodes.