Mobile Charge Capture
Interface Scoping Questionnaire
athenahealth, Inc.
Version 15.5 Published: May 2015
Mobile Charge Capture
1 Table of Contents
1 TABLE OF CONTENTS ........................................................................................................................................................... 2
2 COMPLETING THIS DOCUMENT.......................................................................................................................................... 4
ICONS GLOSSARY..................................................................................................................................................................... 4
SCOPING OPTIONS ................................................................................................................................................................... 4
SCOPE APPROVAL.................................................................................................................................................................... 4
3 PROJECT INFORMATION .................................................................................................................................................... 5
4 PRODUCT DESCRIPTION...................................................................................................................................................... 6
WORKFLOW 1 DIAGRAM (HL7) ................................................................................................................................................ 6
WORKFLOW 2 DIAGRAM (API) ................................................................................................................................................ 6
5 GENERAL INTERFACE CONFIGURATION............................................................................................................................ 8
INTEGRATION TESTING ENVIRONMENT ......................................................................................................................................... 8
5.1.1 Testing Phases and Resource Allocation ............................................................................................................ 8
MESSAGE FORMATS & SYSTEMS ................................................................................................................................................. 8
MESSAGE SAMPLES AND SPECS ................................................................................................................................................. 8
INTERFACE WORKFLOW............................................................................................................................................................. 8
5.4.1 Workflow Outline ................................................................................................................................................... 9
5.4.1.1 HL7 Workflow .............................................................................................................................................................................. 9
5.4.1.2 API Workflow .............................................................................................................................................................................. 9
5.4.1.3 Athena Patient ID Exists In Vendor System ............................................................................................................................ 9
5.4.1.4 Patient ID Does Not Exist in Vendor System .......................................................................................................................... 9
5.4.1.5 Charge Messages and Insurance .......................................................................................................................................... 9
6 OUTBOUND WORKFLOW ................................................................................................................................................... 10
MESSAGE DETAILS .................................................................................................................................................................. 10
PATIENTS ................................................................................................................................................................................ 10
6.2.1 Minimum Required Fields for Patient Messages .............................................................................................. 10
6.2.2 Sample ADT Message ......................................................................................................................................... 10
APPOINTMENTS ....................................................................................................................................................................... 11
6.3.1 Appointment Status ............................................................................................................................................ 11
6.3.2 Sample SIU Message ........................................................................................................................................... 11
API WORKFLOW .................................................................................................................................................................... 11
6.4.1 API Calls Leveraged ............................................................................................................................................ 12
7 INBOUND MESSAGE CONFIGURATION ........................................................................................................................... 13
MESSAGE DETAILS .................................................................................................................................................................. 13
7.1.1 Notes ..................................................................................................................................................................... 13
CHARGES .............................................................................................................................................................................. 13
7.2.1 Minimum Required Fields for Charge Messages ............................................................................................. 14
7.2.2 Matching Logic for Charge Messages ............................................................................................................. 14
7.2.2.1 Patient Matching for Charge Messages ............................................................................................................................. 14
7.2.3 Processing Logic for Charge Messages ............................................................................................................ 14
7.2.3.1 Claim Review Period .............................................................................................................................................................. 14
7.2.3.2 Charge Grouping.................................................................................................................................................................... 14
7.2.3.3 Claim Logic .............................................................................................................................................................................. 15
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
2
Mobile Charge Capture
7.2.4 Sample DFT ........................................................................................................................................................... 15
8 CONNECTIVITY METHOD OPTIONS .................................................................................................................................. 17
ATHENA-HOSTED SFTP ............................................................................................................................................................ 17
ATHENALIGHTNING ................................................................................................................................................................. 17
LOCALLY-HOSTED SFTP .......................................................................................................................................................... 17
HL7 MESSAGING OVER SSH ................................................................................................................................................... 17
ESTABLISHING A VPN .............................................................................................................................................................. 17
8.5.1 FTP Transfer Through VPN .................................................................................................................................... 17
8.5.2 HL7 Messaging Through VPN.............................................................................................................................. 17
9 PROJECT PLAN .................................................................................................................................................................. 18
SAMPLE INTERFACE PROJECT PLAN .......................................................................................................................................... 18
10 APPENDICES AND OTHER REFERENCES ......................................................................................................................... 19
PLANNED MAINTENANCE WINDOW....................................................................................................................................... 19
INTERFACE MESSAGE QUEUE MANAGER ................................................................................................................................ 19
MESSAGE QUEUE MAINTENANCE .......................................................................................................................................... 19
CONTINUING SERVICE AND SUPPORT ..................................................................................................................................... 19
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
3
Mobile Charge Capture
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.
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.
BEST PRACTICES: The horizontal bar is generally used to highlight additional tips, considerations, and advice.
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.
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.
Scope Approval
I,
, agree to the interface design as described here in this document.
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
4
Mobile Charge Capture
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
5
Mobile Charge Capture
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:
•
Patient demographics (name, date of birth, address, etc.)
•
Scheduling
•
Charge Data (diagnoses, cpt codes, date of service, etc.)
Common use-case scenarios are depicted below. It is important to identify and review your specific use-cases with the
Interface Project Manager.
Use Case
Format
Overview
Capture and submit inpatient and
outpatient charges quickly and
seamlessly using your mobile device
HL7 and API
Outbound: Patient Demographics and
Scheduling
Inbound: Charges
Workflow 1 Diagram (HL7)
Workflow 2 Diagram (API)
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
6
Mobile Charge Capture
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
7
Mobile Charge Capture
5 General Interface Configuration
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 -
Yes is recommended
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.
Message Formats & Systems
athena uses HL7 V2
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:
Message Samples and Specs
See athenaNet MX Native HL7 Interface Specifications for a detailed HL7 specification.
(http://www.athenahealth.com/files/interfacesupportdocs/athenaNet_MX_Native_HL7_Interface_Specifications.doc)
Can you provide sample data for inbound messages to the Interface Project Manager? - blank -
Yes is recommended
Interface Workflow
Consider your workflows and use cases for this interface and see the outline them below
Outbound: Patient Demographics and Scheduling Messages (ADT, SIU, MFN)
Inbound: Charges (DFT) Patient Demographics (API)
API Calls Leveraged: Best Match, Post Patient, Get Providers, Get Departments
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
8
Mobile Charge Capture
5.4.1 Workflow Outline
5.4.1.1 HL7 Workflow
athena sends outbound Patient Demographics and Scheduling information to Mobile Charge Capture Vendor. Charge
information is sent from Vendor to athena and a claim is created. The charge information is stored in athena
5.4.1.2 API Workflow
Patient is registered or created outside of athena and is not already registered in athena. API queries athenaNet for Patient
ID using Best Match Call (see Patient Matching Logic). API queries athena for top 100 Insurance packages. Charge
messages sent via HL7 will contain athena patient id and either a valid athena insurance package id (from API call) or a
dummy insurance.
5.4.1.3 Athena Patient ID Exists In Vendor System
Vendor sends athena patient id in inbound charge messages.
5.4.1.4 Patient ID Does Not Exist in Vendor System
Vendor queries API using Best Match, patient not found patient Posted to athena.
5.4.1.5 Charge Messages and Insurance
Option 1: If valid athena insurance package id is available it will be sent in the charge message from Vendor to athena.
Option 2: If valid insurance package is not available, the charge message will contain dummy insurance package. Charge
will be sent to Claim HOLD bucket. Billing staff at practice must resolve all HOLD and add correct insurance package.
Note: If there are any discrepancies between the insurance packages sent in message and the athena quickview
insurance; the quickview insurance will always override the incoming insurance package.
Action
Direction
Add Patient
Outbound
A28
Update Patient
Outbound
A31
Update Patient
Outbound
A08
Discharge Patient
Outbound
A03
Admit Patient
Outbound
A01
Schedule Appointment
Outbound
S12
Cancel Appointment
Outbound
S15
Check-In
Outbound
S14
Charges
Inbound
P03
www.athenahealth.com
Default Message
Notes:
athenahealth, Inc. Confidential and Proprietary
9
Mobile Charge Capture
6 Outbound Workflow
This is an outbound admit/discharge patient subscription. This data will only send to Vendor if the data exists in athenaNet
and the Patient Rounding List is enabled and being populated with data either manually or via a different inbound ADT
feed.
Message Details
Message Type
Default HL7 Field
Note
ADT/SIU
MSH.6
Send athena Context ID for Vendor
to parse the data (global)
ADT
PID.2
athena Patient ID
ADT
PID.3
athena Patient ID
ADT
PID.18
athena Patient ID
SIU
PID.18
Appointment ID
SIU
PV1.44
Appointment Date
SIU
Send AIP Segment
Patients
The following section contains configurations related only to outbound patient messages. This can be broken into two parts:
the fields necessary for the creation of a new patient and edits to existing patients.
6.2.1 Minimum Required Fields for Patient Messages
In order to create a patient, 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
Patient ID
PID.3.0
Last Name
PID.5.0
First Name
PID.5.1
Date of Birth
PID.7
In order to send a patient’s insurance, 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
Package ID
IN1.2
Name
IN1.4
Policy Number
IN1.36
Relationship to Insured
IN1.17
6.2.2 Sample ADT Message
MSH|^~\&|ATHENANET|7598^IN - CLIENTNAME Indiana|MOBILECHARGECAPTURE||201503290000||ADT^A31|99765483M7598|P|2.2||||||||
EVN|A31|201503281159||||
PID||51383087|51383087||***PHI REDACTED** |315025855|||^||||||||
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
10
Mobile Charge Capture
PV1|||^^^||||^||||||||||^|||||||||||||||||||||||||||||||||||
DG1||||no current diagnosis|||||||||||||||
GT1|||***PHI REDACTED*** |||||||
Appointments
6.3.1 Appointment Status
For outbound appointment messages the interface sends a status in field SCH.25. By default, the statuses coincide with the
event that triggered the message. Default statuses are listed below and can be customized if needed.
Trigger Event
SCH.25 Value
New Appointment
BOOKED
Appointment Check-In
ARRIVED
Appointment Check-Out
COMPLETED
Appointment Update
UPDATE
Cancel Appointment
CANCELLED
Notes
RECHEDULED APPOINTMENTS: When a user reschedules an appointment through the athenaNet
appointment workflow, it is actually cancelling the original appointment record and creating a new
appointment record with a new athenaNet appointment ID. The interface will generate an appointment
cancel message for the original appointment and an appointment create message for the new
appointment. If this functionality will be an issue for your downstream system, please discuss this workflow
with your athenahealth Project Manager.
6.3.2 Sample SIU Message
MSH|^~\&|ATHENANET|7598^IN - CONTEXT Indiana|VENDOR||201503290900||SIU^S12|99778206M7598|P|2.2||||||||
SCH|23126597|23126597||||New Patient 5|bronchitis, shoulder pain|NP5^New Patient
5|5|minutes|^^^201503290850|||||emcclain2|||||||||
PID||51383154|51383154||***PHI REDACTED*** ||||||||
PV1|||891^IND_SMG_MUC_DOC^^IND_SMG_MUC_DOC||||1079^IND_SMG_Prov_MUC||||||||||1079^IND_SMG_Pro
v_MUC|||||||||||||||||||||||||||201503290850||||||||
DG1||||no current diagnosis|||||||||||||||
RGS|||
AIG|||IND_SMG_Prov_MUC|||||201503290850|||5|minutes||
AIL|||891^IND_SMG_MUC_DOC|||201503290850|||5|minutes||
AIP|1||1079^PROVIDER^SPN MICH RD IMM CARE||||||5|minutes||
API Workflow
The athena ID is received by the vendor through an outbound ADT/SIU feed or by querying the API
(Get/patients/bestmatch).
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
11
Mobile Charge Capture
If the patient is found the athena ID of the patient is sent in the PID.3 segment of an inbound DFT^P03 message. If the
patient is not found, the vendor will add the patient to athenaNet using the API (POST/patient). After the patient has been
created, this newly created patient ID is sent in the PID.3 segment of an inbound DFT^P03 message.
6.4.1 API Calls Leveraged
•
Best Match (Outbound)
•
Post Patient (Inbound)
•
Get Providers (Outbound)
•
Get Departments (Outbound)
•
Get Custom Record Fields (Outbound)(optional)
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
12
Mobile Charge Capture
7 Inbound Message Configuration
Message Details
Message Type
Default HL7 Field
Note
DFT
MSH.6
Send athena Context ID for athena to
parse the data (global)
DFT
PID.2
Athena Patient ID
DFT
IN1
Athena Insurance Package ID or Null
PV1
NPI to automap to the correct
provider. If the practice has multiple
provider groups providers NPI +
Department ID in the message are
used to determine the correct
provider group
PV1
Vendor sends the athena
department ID this will automap
according to the athena department
ID
DFT
FT1.27
If available insurance sent in this field
as free text. Data is then added as
‘claim note’ as free text for billing to
update
DFT
FT1.20
Rendering Provider (NPI)
DFT
FT1.21
Supervising Provider (NPI)
FT1
Athena creates a claim per provider
in FT1 segment (** If 1 DFT is received
with provider A in the first FT1 and
provider B in the second FT1, two
separate claims will be created)
DFT
DFT
DFT
7.1.1 Notes
•
Insurance is always taken from the quickview if there is a discrepancy
•
If vendor sends charge and the patient is not register in the given provider group, athena automatically CPI copy
the patient into that provider group
Charges
The following sections contain configurations related only to inbound charge messages.
Only charge data is processed from inbound P03 charge messages. All other data, including any demographic
updates, are discarded.
athenaNet only handles claim creation. Edits to existing claims cannot be handled by the interface and must be done via
standard athenaNet workflow. The interface cannot void to delete charges via interface.
FINAL CHARGES ONLY: The other system should send claims only when they are ready for billing. That is,
inbound charge data should be complete, finalized, and ready for immediate billing. We do not
recommend “building up a claim” over the course of many transactions/charges/messages. Those
charges should be sent all at once, ideally contained within single DFT messages (one claim per message).
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
13
Mobile Charge Capture
7.2.1 Minimum Required Fields for Charge Messages
In order to create a claim, the following data is required. We expect data to be in the following HL7 fields. Please indicate
below if it will be different.
Data Field
Default HL7 Field
Appointment ID
PV1.19 or PV1.50
Rendering Provider (NPI)
FT1.20
Supervising Provider (NPI)
FT1.21
Department (Place of Service Code)
FT1.16
Service Date
FT1.4
Procedure Code
FT1.25
Modifier (if required for procedure
code)
FT1.26
Diagnosis Code
FT1.19
ICD code set
FT1.19.2
7.2.2 Matching Logic for Charge Messages
7.2.2.1 Patient Matching for Charge Messages
athenaNet expects the athenaNet patient ID in the inbound charge interface message; these values are used to match
the charge data to the correct patient. Note that the remote system vendor may need to be consulted before making this
selection.
The patient ID found in the inbound charge message will be used as a direct match to the athenaNet patient ID. All other
demographic data in the charge message, including insurance data, will be ignored.
Preference for Patient ID (check one):
athenaNet patient ID will be available in inbound charge message in PID.2
7.2.3 Processing Logic for Charge Messages
7.2.3.1 Claim Review Period
Claims created by the interface will be held for manual review – and are held by the kick reason PROVREVIEW. This is to
ensure some level of QA/review by the client prior to claim submission. After a minimum of 4 weeks this kick reason can be
removed at the client’s request. The removal can be done either selectively (by provider/location) or completely. Please
contact the Client Support Center after the four week time frame to adjust the PROVREVIEW settings.
BEST PRACTICES: Please ensure you have operational workflows in place for staff review of these claims.
7.2.3.2 Charge Grouping
Some systems (frequently lab systems and some HIS systems) will send charges associated with an encounter to athenaNet
in separate transactions. That is, if an encounter has multiple charges, those charges will be sent to athenaNet in separate
charge transactions. To accommodate separate transactions, charges sent to athenaNet will be grouped together onto
the same claim by default.
Charge grouping default utilizes the a) patient, b) service date, c) provider & supervising provider, d) department and e)
primary & secondary insurances when searching for an existing claim. Important note: In addition, only f) open unbilled
claims are considered for grouping new charges onto. If charge grouping is not required, or a different logic is desired,
please specify here:
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
14
Mobile Charge Capture
Charge Grouping Options
Default functionality outlined above
Hospital Grouping: The default functionality without service date. This will group claims across multiple dates of
service, however by default also cuts off claims and forces new claims if the dates span into a new calendar
month.
Custom: Please specify:
Disable: Each message will create a claim.
Custom
Mapping
Required
Data Element
Patient’s Relationship to Policy Holder
7.2.3.3
Default HL7 Field
HL7 Field Override
IN1.17
Defined in Section Error!
Reference source not found. or
Error! Reference source not
found.
Claim Logic
Scenario 1 – Patient originated in Athena

Action  Claim Created (use quickview insurance data)
Scenario 2 – Patient was added to athena via the API
•
Action  DFT sends valid insurance package id in message  Claim Created
•
Action  DFT sends dummy insurance package in message  Claim goes to HOLD
o
Claims in HOLD will need to be resolved by billing staff by adding in the correct insurance package to the
claim
Note: If there is a quickview insurance listed, the insurance sent in the message will NEVER update the patient’s quickview
insurance
7.2.4 Sample DFT
MSH|^~\&|VENDOR|MORRISTOWN||2983|20140707220545||DFT^P03|201407070000|P|2.3||||||||
EVN|P03|20140707220545|||||
PID|1|4747481|A01553425||***PHI REDACTED*** ||||||||||||
PD1||||^SACHS^R|||||||||
PV1|1|I|^AH3 H30601^^127^^21||||6036^ALLEGRA^JOHN|||||||||||AAM||MEDICARE||||||||||||||||||||||||20140619||||
|||||
FT1|1|F62651362CE8||20140701||CG|99233^F/U: INPT CONSULT-3|||1||||||^^AH3 H30601^127^^21|||428.33^HEART FAILURE, DIASTOLIC, ACUTE ON CHRONIC^I9~402.91^HYPERTENSIVE HEART DISEASE WITH
CONGESTIVE HEART FAILURE^I9~425.18^HYPERTROPHIC CARDIOMYOPATHY^I9~424.1^AORTIC VALVE
DISORDER^I9|1558333112^SCHWARTZ^MD|1558333112^SCHWARTZ^MD||||99233^F/U: INPT CONSULT-3|||
FT1|2|5A221F5A88DE||20140702||CG|99233^F/U: INPT CONSULT-3|||1||||||^^AH3 H30601^127^^21|||428.33^HEART FAILURE, DIASTOLIC, ACUTE ON CHRONIC^I9~402.91^HYPERTENSIVE HEART DISEASE WITH
CONGESTIVE HEART FAILURE^I9~425.18^HYPERTROPHIC CARDIOMYOPATHY^I9~424.1^AORTIC VALVE
DISORDER^I9|1114192101^JULIANO^MD|1114192101^JULIANO^MD||||99233^F/U: INPT CONSULT-3|||
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
15
Mobile Charge Capture
FT1|3|C8C5615FD1D1||20140703||CG|92986^PERCUTANEOUS BALLOON VALVULOPLASTY; AORTIC
VALVE|||1||||||^^AH3 H306-01^127^^21|||424.1^AORTIC VALVE DISORDER^I9~402.91^HYPERTENSIVE HEART DISEASE
WITH CONGESTIVE HEART FAILURE^I9~425.18^HYPERTROPHIC CARDIOMYOPATHY^I9~428.33^HEART FAILURE, DIASTOLIC,
ACUTE ON CHRONIC^I9|1114192101^JULIANO^MD|1114192101^JULIANO^MD||||92986^PERCUTANEOUS BALLOON
VALVULOPLASTY; AORTIC VALVE|||
FT1|4|E21479D672B4||20140703||CG|99233^F/U: INPT CONSULT-3|||1||||||^^AH3 H30601^127^^21|||428.33^HEART FAILURE, DIASTOLIC, ACUTE ON CHRONIC^I9~402.91^HYPERTENSIVE HEART DISEASE WITH
CONGESTIVE HEART FAILURE^I9~425.18^HYPERTROPHIC CARDIOMYOPATHY^I9~424.1^AORTIC VALVE
DISORDER^I9|1114192101^JULIANO^MD|1114192101^JULIANO^MD||||99233^F/U: INPT CONSULT-3|||
GT1|1||***PHI REDACTED***
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
16
Mobile Charge Capture
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.
Connectivity method choice and details will be collected in the Connectivity Worksheet:
http://www.athenahealth.com/_doc/interfaces/Standardized_Connectivity_Worksheet.pdf
http://www.athenahealth.com/_doc/interfaces/Interface_Connectivity_Worksheet.pdf
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.
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.
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.
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.
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
17
Mobile Charge Capture
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.
Sample Interface Project Plan
Duration
Description
3 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) if applicable,
detailing the cost of the interface, are completed and signed in this stage. Client completes a
connectivity worksheet.
2 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
1 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
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
18
Mobile Charge Capture
10 Appendices and Other References
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.
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.
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/files/interfacesupportdocs/athenaNet_Interface_Queue_Management_Guide.doc)
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
(http://www.athenahealth.com/_doc/interfaces/Interface_Down_Support_Document.pdf)
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
19
Mobile Charge Capture
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
20