Inbound Anesthesia
Time Sheets
Interface Scoping Questionnaire
athenahealth, Inc.
Version 15.10 Published: October 2015
Inbound Anesthesia Time Sheets
1 Table of Contents
1 TABLE OF CONTENTS ........................................................................................................................................................... 2
2 COMPLETING THIS DOCUMENT.......................................................................................................................................... 3
2.1 ICONS GLOSSARY..................................................................................................................................................................... 3
2.2 SCOPE APPROVAL.................................................................................................................................................................... 3
3 PROJECT INFORMATION .................................................................................................................................................... 4
4 PRODUCT DESCRIPTION...................................................................................................................................................... 5
5 GENERAL INTERFACE CONFIGURATION............................................................................................................................ 6
5.1 INTEGRATION TESTING ENVIRONMENT ......................................................................................................................................... 6
5.1.1 Testing Phases and Resource Allocation ............................................................................................................ 6
5.2 MESSAGE SAMPLES AND SPECS ................................................................................................................................................. 6
5.3 INTERFACE WORKFLOW............................................................................................................................................................. 6
5.4 ADDITIONAL COMMENTS .......................................................................................................................................................... 6
6 OUTBOUND MESSAGE CONFIGURATION .......................................................................................................................... 7
7 INBOUND MESSAGE CONFIGURATION ............................................................................................................................. 8
7.1 ANESTHESIA TIME SHEETS ........................................................................................................................................................... 8
7.1.1 Matching Logic for Patients ................................................................................................................................. 8
7.2 ENTERPRISE PROVIDER GROUP ROUTING .................................................................................................................................... 8
7.3 INTERFACE MAPPING REQUIREMENTS ......................................................................................................................................... 9
8 CONNECTIVITY METHOD OPTIONS .................................................................................................................................. 10
8.1 ATHENA-HOSTED SFTP ............................................................................................................................................................ 10
8.2 ATHENALIGHTNING ................................................................................................................................................................. 10
8.3 LOCALLY-HOSTED SFTP .......................................................................................................................................................... 10
8.4 HL7 MESSAGING OVER SSH ................................................................................................................................................... 10
8.5 ESTABLISHING A VPN .............................................................................................................................................................. 10
8.5.1 FTP Transfer Through VPN .................................................................................................................................... 10
8.5.2 HL7 Messaging Through VPN.............................................................................................................................. 10
9 PROJECT PLAN .................................................................................................................................................................. 11
9.1 SAMPLE INTERFACE PROJECT PLAN .......................................................................................................................................... 11
10 APPENDICES AND OTHER REFERENCES ......................................................................................................................... 12
10.1 PLANNED MAINTENANCE WINDOW....................................................................................................................................... 12
10.2 INTERFACE MESSAGE QUEUE MANAGER ................................................................................................................................ 12
10.3 MESSAGE QUEUE MAINTENANCE .......................................................................................................................................... 12
10.4 CONTINUING SERVICE AND SUPPORT ..................................................................................................................................... 12
APPENDIX A: INBOUND ANESTHESIA TIME SHEETS SPECIFICATION ................................................................................. 14
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
2
Inbound Anesthesia Time Sheets
2 Completing This Document
The integration process can be complicated at times and it’s important to recognize that a number of configuration
options will be presented to you along the way. They are documented here in the Interface Scope Questionnaire (ISQ) as
interface settings. To help you navigate the scoping process, we provide a recommendation for each of the available
settings.
2.1 Icons Glossary
Throughout the ISQ you'll find various icons to highlight athenahealth recommended settings and best practices.
The olive branch icon indicates athenahealth recommended settings.
The money icon indicates options that may incur additional costs.
BEST PRACTICES: The horizontal bar is generally used to highlight additional tips, considerations, and advice.
2.2 Scope Approval
The instructions for scope review are outlined below. Your interface project manager is available to meet, assist with
questions, and help determine the best-fit options for your project.
1.
Review:
Please read the entire Interface Scoping Questionnaire (ISQ) and complete all form fields and check-boxes to the best of
your ability. Should you have questions about the configuration options presented in this document please do not hesitate
to discuss with your interface project manager.
2.
Approve:
When this document is completed to your satisfaction, please approve the scope of the interface by typing your name
below.
I,
, agree to the interface design as described here in this document.
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
3
Inbound Anesthesia Time Sheets
3 Project Information
Please fill the following to the best of your ability. While not all contacts are required, you should be able to submit at least
two contacts at the onset of a new interface project.
General Information
System’s Marketing Name (if applicable)
Company Name:
(ex. athenahealth, Inc.)
Vendor
(If applicable, third party
data exchange vendor)
Software Product Name:
(ex. athenaNet)
Version:
(ex. 14.9)
Interface Engine:
(ex. athenaNet MX Engine)
Trading Partner Name
Trading Partner Type (ex. Health Information System, EHR, etc.)
athenahealth Practice Context ID
athenahealth Interface Project Manager (PM)
Interface PM Contact Information
Event Number (provided by Interface PM, for internal
athenahealth tracking)
Contact
Role
Project Business Contact
Responsible for overall
success of the project
Project Interface Contact
Project IT Contact
Details
Name:
Phone:
Email:
Interface expert,
responsible for continuing
interface support
Name:
Networking and security
expert, responsible for
overall connectivity
Name:
Phone:
Email:
Phone:
Email:
Name:
Vendor Contact #1
Role:
Phone:
Email:
Name:
Vendor Contact #2
Role:
Phone:
Email:
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
4
Inbound Anesthesia Time Sheets
4 Product Description
This interface supports the secure and automated transfer of information from an external third-party system to athenaNet.
It is a one-directional interface inbound to athenaNet. In most cases the third-party is a Surgical Information System (SIS)
that provides the necessary data to populate Anesthesia Time Sheet Batches in athenaNet.
The anesthesia billing workflow in athenaNet is generally a multi-step process, summarized below. This interface automates
the first three steps. The 4th step involves manual review within athenaNet and will continue to follow the standard workflow
for reviewing time sheet batches and generating claims.
1)
2)
3)
4)
Practice creates a "time sheet batch" in athenaNet, via the Manage Anesthesia Time Sheet Batches page. A time
sheet batch corresponds to a daily shift schedule for the anesthesiologists who are directing providers.
Within the batch, practice completes a time sheet for each directing provider in the time sheet batch (via the Time
Sheet Batch and Time Sheet pages). Typically, this is done using the paper time sheets from each directing provider
as a reference.
After all the time sheets for that batch are completed, the system creates a Worklist. (Create Anesthesia Claims
Worklist page)
The potential claims appear in the Create Anesthesia Claims Batch page, where the practice staff member must
review the results, approve the charge-level information, and create the claims.
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
5
Inbound Anesthesia Time Sheets
5 General Interface Configuration
5.1 Integration Testing Environment
A non-live, athena-hosted preview environment is provided to facilitate integration testing prior to moving the interface to
production. It is expected that the other vendor system provides a similar non-live environment for testing on their side as
well.
Will a vendor test environment be made available for this project? - blank If no, please tell us what will be done for testing:
Yes is recommended
No separate testing site may incur additional cost
5.1.1 Testing Phases and Resource Allocation
Interface testing is generally broken up into two phases, unit testing and end-user testing.
In the unit testing phase, athenahealth will confirm interface data is received and processed.
Upon completion of unit testing, end-user testing phase begins. athenahealth may provide guidance when appropriate,
but ultimately it is client responsibility to plan, organize, and carry out testing of their interface in relation to practice
workflows.
TEST PLANS: Plans should be aligned with the supported use cases. In addition to test plans offered by the
Interface Project Manager we encourage you to come up with your own test scenarios as appropriate.
5.2 Message Samples and Specs
See Appendix A: Inbound Anesthesia Time Sheets Specification for details on the athenahealth specifications for this
interface.
Does the other system adhere to athenahealth’s inbound time sheet flat file specification?
- blank -
Yes: Adheres to Standard Spec is recommended
Description of custom spec:
Custom spec may incur additional cost
Can you provide sample data for inbound messages to the Interface Project Manager? - blank -
Yes is recommended
5.3 Interface Workflow
Please complete the interface message types and triggers table below:
Enable?
Action
Direction
Anesthesia Time Sheet
Inbound
5.4 Additional Comments
Through completion of this document, if there are general interface comments, not already covered by the questions and
sections below, please enter them here:
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
6
Inbound Anesthesia Time Sheets
6 Outbound Message Configuration
This section does not apply to this interface type. Please move to the next section.
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
7
Inbound Anesthesia Time Sheets
7 Inbound Message Configuration
7.1 Anesthesia Time Sheets
7.1.1 Matching Logic for Patients
At least one unique, non-changing ID (ex: hospital MRN) must be present in the data file. This ID is extracted and used to
match the incoming record to a single patient record in athenaNet.
The default patient matching logic will be implemented as follows:
1.
2.
3.
If the external ID can be matched to an athenaNet patient record, update that patient record and stop.
If the first four letters of the last name (Last Name Fragment) and the first four letters of the first name (First Name
Fragment) and either a valid social security number (SSN) or valid date of birth (DOB) matches an athenaNet
patient record, update that patient record (including the external ID) and stop.
Else, the data is considered unmatchable and the record will move to the interface ERROR queue for manual
review.
For customizations to default matching logic, please describe here:
Custom patient matching may incur additional cost
The goal of the algorithm is an accurate match of data contained in incoming interface messages with existing athenaNet
patients, as appropriate. Matching requirements that are too restrictive can result in the creation of duplicate patient
records in athenaNet.
EXTERNAL ID MATCHING: It is important to note that number 1 above assumes the external ID provided by
the other system is correct. If the integrity of external IDs is questionable in any way, even in the most
extreme edge-cases, athenahealth recommends checking some other data elements (such as name and
DOB) in addition to the external ID. In other words, the interface could be customized to match on
[external ID and Name Fragment rather than [external ID or Name Fragment]. This is just an example.
Please describe anticipated customizations above and be sure to consult with your Interface Project
Manager. Charges
7.2 Enterprise Provider Group Routing
The following section is related to clients who utilize the athenaNet Provider Group Enterprise functionality. If you are not
using this functionality, skip to the next section. Please check with your athenaNet Account Manager for clarification if you
are unsure.
athenaNet separates patient, appointment, and charge information into provider groups within an enterprise practice.
Each patient record is assigned to a single provider group, and a copy of the patient record (actually a subset of the
original data) is recorded in the Common Patient Index (CPI).
When processing inbound data to an enterprise practice, a destination provider group must be determined. The table
below outlines common approaches to determining this destination provider group.
Patient Provider Group Routing Options
Derive from provider in message
Hardcode to a billable provider group (PHI exposure must be considered)
Additional Comments:
www.athenahealth.com
Custom provider group routing may incur additional cost
athenahealth, Inc. Confidential and Proprietary
8
Inbound Anesthesia Time Sheets
7.3 Interface Mapping Requirements
It is expected that the client system sends data elements as outlined in the athenaNet global tables.
(http://www.athenahealth.com/_doc/interfaces/athenaNet_Global_Tables.xls)
Will data sent to athenaNet use athenaNet’s global values? - blank -
Yes is recommended
However, it may be not be possible for some clients to send athenaNet’s global values. In these cases, the client must
manually create and permanently maintain interface mappings that link their foreign codes to the ones that exist in
athenaNet.
Custom mappings may incur additional cost
For each item in the table below, you are stating that the selected data element requires a custom, non-standard
mapping.
To complete scoping, the client or vendor is required to create in Excel a list of custom values to be mapped during
implementation and provide it to your Interface Project Manager for verification and review. During the build phase of the
project, the client will create these mappings based on this list provided.
For example, if ‘Provider’ is selected in the table below, the athenahealth Interface Project Manager is expecting a list
containing all available provider codes or IDs and descriptions in the external system for review. In the build phase, the
client will map each of these external codes to the corresponding athenaNet codes.
Custom
Mapping
Required
Data Element
Notes
Department
Provider (athenaNet Provider ID or NPI preferred)
Other
Other
MINIMIZE CUSTOM MAPS: Sending standard codes that are already recognized by athenaNet reduces the
level of continuing maintenance in creating and maintaining mappings.
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
9
Inbound Anesthesia Time Sheets
8 Connectivity Method Options
As part of interface implementation, athenahealth will need to establish a secure method of transfer for electronic data to
and from a third party system. The most common options are described in this section. Not all options will be available for all
interface types. For questions, please contact your Interface Project Manager.
For more details about athenahealth connectivity options, please see the Developer Toolkit.
(http://www.athenahealth.com/developer-portal/developer-toolkit/connectivity)
8.1 athena-Hosted SFTP
These connections are initiated externally by the client or third-party system to a SSH-FTP server in athenahealth’s data
center. The client or third-party system is provided with an athena-issued DNS name, username, and password. Once the
client-initiated SSH tunnel is established, the client is able to securely transfer files to or from athenahealth.
8.2 athenaLightning
athenaLightning is a program that can be downloaded and installed inside of a third-party network. It opens an SSL tunnel
out to athenahealth and supports file-based data transfers to and from other applications running inside the client-network.
8.3 Locally-Hosted SFTP
athenahealth can initiate outbound connections to a third-party or client-hosted SSH2 server. The client provides an IP (or
DNS name), username, and password for athenahealth to initiate an outbound SSH connection. Once the SSH tunnel is
established we can exchange files locally using SFTP.
8.4 HL7 Messaging over SSH
athenahealth can initiate outbound connections to a third-party or client-hosted SSH2 server. Once the SSH tunnel is
established athenaNet can run an HL7-receiver and HL7-sender (MLLP TCP/IP socket based transfers) on the client-hosted
SSH server in real time.
8.5 Establishing a VPN
VPN connections may incur additional cost
athenahealth network operations staff can work to establish a point-to-point VPN tunnel (sometimes referred to as site-tosite) between two networks as needed. Once the VPN is in place we can perform file based transfers through plain FTP or
run an HL7-receiver / HL7-sender (MLLP TCP/IP socket based transfers). Coordination of VPN staff on both the athenahealth
and remote side will add additional time to the project.
8.5.1 FTP Transfer Through VPN
This option requires an established VPN and client-hosted FTP server. The client provides an IP (or DNS name), username,
and password for athenahealth to initiate an outbound FTP connection. Once the connection is in place we can securely
and automatically transfer files to and from the client-hosted FTP server.
8.5.2 HL7 Messaging Through VPN
Another way of sending or receiving data through a VPN is via MLLP TCP/IP socket based connections. This is accomplished
by running an HL7-sender on one end of the tunnel and an HL7-listener on the other end. The source system always runs the
“sender” while the receiving (consuming) system always runs the “listener.”
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
10
Inbound Anesthesia Time Sheets
9 Project Plan
New athenaNet interfaces are worked as separate projects alongside the athenaNet implementation. These projects are
designed and adapted to fit within the same timeline as the primary implementation window.
9.1 Sample Interface Project Plan
Duration
Description
4 weeks
Client and athena review and scope project. Interface Scoping Questionnaire (ISQ), detailing the
options and extras required for the interface, and the Interface Proposal (IP), detailing the cost of
the interface, are completed and signed in this stage. Client completes a connectivity
worksheet.
4 weeks
Client and athena work together to establish a secure communications connection between
athena and the practice. Athena creates necessary code for the interface, and tests it internally
given whatever samples the client has supplied. At the end of this period, interface is released on
PREVIEW test server.
TEST
4 weeks
Client tests interface for correctness and workflow impact. Any interface modifications are done
in this stage. At the end of this period, when satisfied, client signs the Go Live Agreement (GLA).
athena will participate in unit testing to verify functionality from a technical perspective. Full enduser acceptance testing is the client’s responsibility to plan, organize, and support.
GO LIVE
2 weeks
Athena brings the interface live on the agreed date. Athena must have at least 2 days advanced
notice on the go-live date. Post Go-Live, the interface maintenance is transitioned to a dedicated
team
Phase
SCOPE
BUILD
Shortening project duration may incur additional cost
athenahealth Interface Implementation
athenahealth
Client
athenahealth
Interface Team
Trading Partner/Vendor
Scope
Project Request
Complete Interface Scoping Questionnaire (ISQ) and Provide Sample Messages
Complete Interface Proposal (IP)
Build
Complete Connectivity Worksheet
Establish Connectivity
Code Interface
Test
Test Interface
Code Interface Modifications
Go-Live
Complete Go-Live Authorization (GLA)
www.athenahealth.com
Interface Go Live
Interface Transition to Post-Go Live Support
athenahealth, Inc. Confidential and Proprietary
11
Inbound Anesthesia Time Sheets
10 Appendices and Other References
10.1 Planned Maintenance Window
The athenaNet MX Engine is subject to the same maintenance windows as the general athenaNet application. Currently, 1
A.M. to 3 A.M. Eastern Time is reserved every morning for maintenance. By default, all interfaces are shut-off during this time
window, and also remain disabled until 4 A.M. Eastern Time. For changes to this time window, please contact
athenahealth.
10.2 Interface Message Queue Manager
The athenaNet Interface Message Queue Manager (IMQM) is an interactive repository for all interface messages that pass
through the athenaNet MX Engine. Please note that messages in a final state (processed or deleted) will only remain in the
queue for 90 days.
The IMQM is especially useful in allowing clients to manually resolve common errors, such as missing providers, invalid
procedure codes, or unknown departments. In order to access the IMQM page in athenaNet the following user permissions
must be granted by the local system administrator:
Permission
Use Case
Interface Admin: View Message Queue
You want to be able to view the IMQM.
Interface Admin: Map Insurance Messages
You need to map insurance messages.
Interface Admin: Map Messages (except Insurances)
You need to map all messages excluding insurance messages
(e.g. provider and department mappings).
10.3 Message Queue Maintenance
Interface messages delivered by athenaNet can be categorized into several processing states.
Message State
Explanation
SCHEDULED
Scheduled to be sent at a later time
NEW
Placeholder for a new message and ready to be sent or received
PENDING
Delivery or acknowledgement is pending
PROCESSED
Processed normally; remains in queue for only 90 days
ERROR
Generic error encountered; routed to client
CBOERROR
Billing related error encountered; routed to client
ATHENAERROR
Internal error encountered; routed to athenahealth Client Support Center
DELETED
Messages that have been deleted; remains in queue for only 90 days
See athenaNet Interface Queue Management Guide for more information on the functionality of the IMQM and on clientside cleanup for ERRORs and CBOERRORs.
(http://www.athenahealth.com/~/media/athenaweb/files/developerportal/interface_message_queue_management_guide.docx?la=en)
10.4 Continuing Service and Support
Two weeks after go-live your interface will be transitioned into our daily service and support structure.
As a standard practice, athenahealth continuously monitors all client connections to the cloud server and will notify the
appropriate contact if an error occurs. All global distributions are monitored for missing subscriptions. All job statuses are
monitored and automatically restarted if idle. For more details please refer to Interface Down Support Document
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
12
Inbound Anesthesia Time Sheets
(http://www.athenahealth.com/~/media/athenaweb/files/developerportal/interface_down_support_document.pdf?la=en)
Should you need to contact athenahealth for, questions or modifications to the interface, live support can be accessed
directly in athenaNet:
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
13
Inbound Anesthesia Time Sheets
Appendix A: Inbound Anesthesia Time Sheets Specification
Flat File Specified Fields:
Fields
Required
Yes/No
Notes
Context ID
Yes
Client-specific athena ID
Batch Name
No
A unique ID or string generated by the other/source system. If not
specified, athenaNet treats everything with the same date of
service as one batch.
Batch Notes
No
Notes about the group of services to which this item belongs.
Date of Service
Yes
Required format is YYYYMMDD
Patient ID Number
Yes
athenaNet patient ID, a unique identifier
Surgical Procedure Code (CPT)
Yes
CPT code; modifiers are accommodated
Flag to indicate time-based service
Yes
Y or N
Anesthesia Procedure Code (ASA
Code)
Conditional
Required for time-based services
Number of units
No
Optional for non-time based services, defaults to 1; not used for
time-based services
Department ID
Yes
A unique ID or string generated by the other/source system. Will
be MAPPED to athena departments.
Anesthesia Type
No
1 = General
2 = MAC
3 = Regional
4 = Epidural
5= Local
6 = Spinal
7= Combined Spinal Epidural
Only 1 can be specified
Physical Status Indicator P1 to P6
Extenuating Circumstances
No
No
P1 – P6 modifier; only one can be specified
1 = Extreme Age (99100)
2 = Emergency (99140)
3 = Hypotension (99135)
4 = Hypothermia (99116)
More than 1 can be specified
Diagnoses
No
ICD-9, can send up to 4 codes; multiple codes separated by
comma; diagnosis codes are not required within the anesthesia
data entry, but will be required for claim creation.
Referring Provider NPI
No
Referring Physician’s NPI number
Surgeon name
No
For reporting purposes only
Hospitalization Dates / DOS From
No
Required format is YYYYMMDD
Operating Room Identifier
No
For reporting purposes only
C = complete
I = incomplete
Flag indicating whether the
requirements for medical direction
have been met
No
Case Notes
No
Notes about the patient’s case
Directing Provider / Supervising
Anesthetist ID (NPI)
Yes
The provider ultimately responsible for the service. This is
generally an anesthesiologist, but could be a CRNA performing
services without direction.
www.athenahealth.com
Can be left blank to use the practice’s default (determined prego-live)
athenahealth, Inc. Confidential and Proprietary
14
Inbound Anesthesia Time Sheets
Directed Provider ID (NPI)
Yes
The provider performing the service during that time period. This
could be the same as the Directing Provider specified on the time
sheet if the service is self-performed, or another anesthesia
provider working under his/her direction.
Start Time
Conditional
Required for time-based services
End time
Conditional
Required for time-based services
Flag indicating whether the service
should be included in concurrency
calculations.
No
We default this based on values in the practice fee schedule.
Example Message:
195940 AN92793 PROGRAM='Clinical Anesthesiology' 20140528 1975709 AS01173 Y 01173
IP P1 732.1
20140528
411^Ross^Patrick 411^Ross^Patrick 07:28 12:45
www.athenahealth.com
26^CHLA
athenahealth, Inc. Confidential and Proprietary
15