Inbound Admit
Discharge
Interface Scoping Questionnaire
athenahealth, Inc.
Version 15.10 Published: October 2015
Formerly Patient Rounding Lists
Inbound Admit Discharge
1 Table of Contents
1 TABLE OF CONTENTS ........................................................................................................................................................... 2
2 COMPLETING THIS DOCUMENT.......................................................................................................................................... 3
2.1 ICONS GLOSSARY..................................................................................................................................................................... 3
2.2 SCOPING OPTIONS ................................................................................................................................................................... 3
2.3 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 FORMATS & SYSTEMS ................................................................................................................................................. 6
5.3 MESSAGE SAMPLES AND SPECS ................................................................................................................................................. 6
5.4 INTERFACE WORKFLOW............................................................................................................................................................. 7
5.5 EXTERNAL ID MANAGEMENT ..................................................................................................................................................... 7
5.6 ADDITIONAL COMMENTS .......................................................................................................................................................... 8
6 OUTBOUND MESSAGE CONFIGURATION .......................................................................................................................... 9
7 INBOUND MESSAGE CONFIGURATION ........................................................................................................................... 10
7.1 PATIENT ADMIT AND DISCHARGE ............................................................................................................................................. 10
7.1.1 Minimum Required Fields.................................................................................................................................... 10
7.1.2 Matching Logic for Admission Records ............................................................................................................ 10
7.1.3 Processing Logic for Admission Records ........................................................................................................... 10
7.2 ENTERPRISE PROVIDER GROUP ROUTING .................................................................................................................................. 11
7.3 INTERFACE MAPPING REQUIREMENTS ....................................................................................................................................... 11
8 CONNECTIVITY METHOD OPTIONS .................................................................................................................................. 12
8.1 ATHENA-HOSTED SFTP ............................................................................................................................................................ 12
8.2 ATHENALIGHTNING ................................................................................................................................................................. 12
8.3 LOCALLY-HOSTED SFTP .......................................................................................................................................................... 12
8.4 HL7 MESSAGING OVER SSH ................................................................................................................................................... 12
8.5 ESTABLISHING A VPN .............................................................................................................................................................. 12
8.5.1 FTP Transfer Through VPN .................................................................................................................................... 12
8.5.2 HL7 Messaging Through VPN.............................................................................................................................. 12
9 PROJECT PLAN .................................................................................................................................................................. 13
9.1 SAMPLE INTERFACE PROJECT PLAN .......................................................................................................................................... 13
10 APPENDICES AND OTHER REFERENCES ......................................................................................................................... 14
10.1 PLANNED MAINTENANCE WINDOW....................................................................................................................................... 14
10.2 INTERFACE MESSAGE QUEUE MANAGER ................................................................................................................................ 14
10.3 MESSAGE QUEUE MAINTENANCE .......................................................................................................................................... 14
10.4 CONTINUING SERVICE AND SUPPORT ..................................................................................................................................... 14
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
2
Inbound Admit Discharge
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 Scoping Options
If you would like to proceed with athenahealth recommended settings, please review each section to get more familiar
with the features of your interface and approve the scope of the interface by typing your name below. We’ll move ahead
to the next phase with a goal of testing and deploying the interface as soon as possible.
If you would not like to proceed with athenahealth-recommended settings - please proceed with the manual scoping
process. Your interface project manager is available to meet, assist with questions, and help determine the best-fit options
for your project. With this option, additional time and cost may incur.
Do you wish to proceed with athenahealth-recommended settings? - blank If no, instructions for manual scoping are as follows:
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.
2.3 Scope Approval
I,
, agree to the interface design as described here in this document.
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
3
Inbound Admit Discharge
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 Admit Discharge
4 Product Description
This interface supports the secure and automated transfer of information between athenaNet and an external third-party
system. To ensure compatibility across a wide array of platforms and software vendors interface data is formatted
according to HL7 v2 standards and may include:
•
External Patient Identifiers (MRN or CPI assigned by an outside system)
•
Patient demographics (name, dob, address, etc.)
•
Patient hospital admission history
Common use-case scenarios are depicted below. It is important to identify and review your specific use-cases with the
Interface Project Manager.
Scenario
Event
Functionality
Admit
Patient ADMITTED to hospital (HIS)
Admission history updated in athenaNet
Discharge
Patient DISCHARGED from hospital (HIS)
Admission history updated in athenaNet
INTERFACE DEPENDENCY: It is generally recommended to combine this interface (Admit/Discharge) with an
inbound patient interface. An Admit/Discharge interface by itself is not capable of adding net new
patients in athenaNet; it simply updates the admission history for existing patients.
WORKFLOW SCENARIOS: Be sure to discuss workflow and interface use-cases with your interface project
manager until you’re absolutely comfortable with the intended functionality. Often times the introduction
of an interface will alter your end user workflow, in a good way, and it’s important to understand which
elements are automated versus requiring manual input so that information can be conveyed to practice
staff.
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
5
Inbound Admit Discharge
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 works directly with the other vendor to ensure outbound messages are generated
and delivered successfully to the receiver. For inbound message testing, athenahealth will confirm messages are 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 Formats & Systems
Does the other system adhere to HL7 standards or is there a custom specification?
- blank -
HL7 v2 is recommended
Description of custom spec:
Custom spec may incur additional cost
Is athenaNet connecting to a client operated application behind the client firewall? If not, a Third Party Agreement (TPA)
will need to be signed by the vendor and athenahealth.
- blank Is the purpose of this interface to replace an existing interface? - blank If yes, please describe existing interface:
Additional Comments:
5.3 Message Samples and Specs
For athenahealth samples and specifications, please see the Developer Toolkit.
(http://www.athenahealth.com/developer-portal/developer-toolkit/by-standard)
Are there any known custom segments or message formats required for this interface? If so, please explain:
Can you provide sample data for inbound messages to the Interface Project Manager? - blank -
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
Yes is recommended
6
Inbound Admit Discharge
5.4 Interface Workflow
Consider your workflows and use cases for this interface and outline them below. The following are some questions to get
you thinking about your workflows: Do you need to store any specific data element from the inpatient visit in athenaNet?
What kind of patient visit types will be sent to athenaNet? Is it possible for a patient to be admitted more than once a day?
With your workflows above in mind, please complete the interface message types and triggers table below:
Enable?
Action
Direction
Admit Patient
Inbound
A01
Discharge Patient
Inbound
A03
Default Message
Custom Message
Other:
Other:
Other:
5.5 External ID Management
In order to assist with patient ID management throughout an integrated health system, athenaNet can store multiple
external IDs. External IDs may be used for matching purposes or external IDs may just be interfaced and stored in athenaNet
using custom fields. All patient or visit IDs present in athenaNet, including external IDs such as those supplied by an interface
or import process, are available to be sent out over the interface.
For example, suppose the other system assigns an EMPI ID, a chart number, a hospital MRN, and a FIN number. Although
you may only intend to use one of them for matching purposes, all of the other IDs can be stored as well. Information stored
in athenaNet Custom Fields can be made searchable and appear on various patient workflow screens, including the
patient Quickview screen. In most cases an external ID may not be used as the athenaNet patient ID.
Please identify Person level Custom Fields here:
athena Custom
Field Name
athena Custom
Field ID
HL7 Field
HL7 Assigning Authority
(ex: |34567^^^CMRN^S~12345^^^EMPI^D|)
Priority for
Matching
HL7 Assigning Authority
(ex: |34567^^^CMRN^S~12345^^^EMPI^D|)
Priority for
Matching
PID.3
Please identify Admission level Custom Fields here:
athena Custom
Field Name
athena Custom
Field ID
HL7 Field
PID.18
Are any of the above external IDs formatted with leading zeros? - blank Additional comments:
By default, the information in the above tables is applied to both inbound and outbound when available.
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
7
Inbound Admit Discharge
5.6 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
8
Inbound Admit Discharge
6 Outbound Message Configuration
There are no outbound messages for this interface type. Please proceed to the next section.
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
9
Inbound Admit Discharge
7 Inbound Message Configuration
7.1 Patient Admit and Discharge
This interface is intended to record the admission and discharge data from an external system. By default, patient
demographic data received by the interface will not overwrite patient data in athenaNet. Please contact your
athenahealth Interface Project Manager for further information regarding patient demographic syncing options.
7.1.1 Minimum Required Fields
In order to process the interface message, the following data fields need to be specified. We expect data to be in the
following HL7 fields. Please indicate below if it will be different
Data Field
Default HL7 field
Visit Number
PID.18
Rounding Department
PV1.3.1
Attending Provider
PV1.7.1
Admit Date
PV1.44
HL7 Field Override
The following fields are not required for the interface to process the message, but are processed by default.
Data Field
Default HL7 field
Patient Class
PV1.2
Room Number
PV1.3.2
Bed Number
PV1.3.3
Admitting Provider
PV1.17.1
Discharge Date
PV1.45
Notes
No default, please indicate:
HL7 Field Override
Additional Comments:
7.1.2 Matching Logic for Admission Records
At least one unique, non-changing ID (ex: hospital MRN) must be present in the interface message. This ID is extracted and
used to match the interface message to a single admission record in athenaNet.
The admission matching logic will be implemented as follows:
1.
2.
3.
If the visit ID can be matched to an athenaNet admission record, update that admission 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
admission record, update that admission record (including the visit ID) and stop.
Else, the data is considered unmatchable and the message will be held in error.
7.1.3 Processing Logic for Admission Records
If no match is found for a discharge message, athenaNet will record both the admission date and discharge date in one
action from the single message.
Note, should a later message for the same Visit Number be presented without a discharge date, the discharge date will be
redacted from athenaNet making the admission appear not discharged.
Reminder, the Patient Rounding List interface on its own does not include the capacity to create, or update, patient
records in athenaNet; only create admissions (visits / encounters) on patient records present in the database.
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
10
Inbound Admit Discharge
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 new admission or discharge message, a destination provider group must be determined. The table below
outlines common approaches to determining this destination provider group.
Patients
Description
Hardcode to a billable provider group
Please specify the provider group:
Hardcode to a non-billable provider group created specifically for this interface. Patients in this provider group
will need to be CPI-copied into a billable provider group.
Please specify the provider group:
Derive from provider in message
Additional Comments:
Custom provider group routing may incur additional cost
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 be used 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 language is selected in the table below, the athenahealth Interface Project Manager is expecting a list
containing all available language codes 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
Default HL7 Field
HL7 Field Override
Department
PV1.3.1
Defined in Section 7.1.1
Provider (athenaNet Provider ID or NPI preferred)
PV1.7.1
Defined in Section 7.1.1
Patient Class
PV1.2
Defined in Section 7.1.1
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
11
Inbound Admit Discharge
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
12
Inbound Admit Discharge
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
Phase
Duration
Description
SCOPE
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
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
13
Inbound Admit Discharge
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).
Interface Admin: File Upload Interface
You want to be able to upload files via the interface.
10.3 Message Queue Maintenance
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
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
14
Inbound Admit Discharge
monitored and automatically restarted if idle. For more details please refer to Interface Down Support Document
(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
15