Transcription
Interface Scoping Questionnaire
athenahealth, Inc.
Version 15.5 Published: May 2015
Transcription
1 Table of Contents
1 TABLE OF CONTENTS ........................................................................................................................................................... 2
2 COMPLETING THIS DOCUMENT.......................................................................................................................................... 4
2.1 ICONS GLOSSARY..................................................................................................................................................................... 4
2.2 SCOPING OPTIONS ................................................................................................................................................................... 4
2.3 SCOPE APPROVAL.................................................................................................................................................................... 4
3 PROJECT INFORMATION .................................................................................................................................................... 5
4 PRODUCT DESCRIPTION...................................................................................................................................................... 6
5 GENERAL INTERFACE CONFIGURATION............................................................................................................................ 7
5.1 INTEGRATION TESTING ENVIRONMENT ......................................................................................................................................... 7
5.1.1 Testing Phases and Resource Allocation ............................................................................................................ 7
5.2 MESSAGE FORMATS & SYSTEMS ................................................................................................................................................. 7
5.3 MESSAGE SAMPLES AND SPECS ................................................................................................................................................. 7
5.4 INTERFACE WORKFLOW............................................................................................................................................................. 7
5.4.1 Workflow Outline ................................................................................................................................................... 8
5.5 DICTATION MARKERS ................................................................................................................................................................ 8
6 OUTBOUND WORKFLOW ................................................................................................................................................... 10
6.1 PATIENTS ................................................................................................................................................................................ 10
6.1.1 Minimum Required Fields for Patient Messages .............................................................................................. 10
6.2 APPOINTMENTS ....................................................................................................................................................................... 10
6.2.1 Appointment Status ............................................................................................................................................ 10
6.2.2 HL7 Mapping for Outbound S14 – Check In .................................................................................................... 11
6.2.3 Sample Outbound S14 Message ....................................................................................................................... 11
7 INBOUND MESSAGE CONFIGURATION ........................................................................................................................... 12
7.1 APPOINTMENTS (S14 – “ACK”).............................................................................................................................................. 12
7.1.1 Minimum Required Fields for Inbound S14 – “ACK” Messages ...................................................................... 12
7.1.2 Sample Inbound S14 Message .......................................................................................................................... 12
7.2 RESULTS .................................................................................................................................................................................. 12
7.2.1 Minimum Required Fields for Transcription(R01) Messages ............................................................................ 12
7.2.2 Sample Inbound R01 ........................................................................................................................................... 12
7.2.3 Minimum Requirements for Transcription (ORU) Messages ............................................................................ 13
7.2.4 Sample Inbound ORU ......................................................................................................................................... 13
8 CONNECTIVITY METHOD OPTIONS .................................................................................................................................. 14
8.1 ATHENA-HOSTED SFTP ............................................................................................................................................................ 14
8.2 ATHENALIGHTNING ................................................................................................................................................................. 14
8.3 LOCALLY-HOSTED SFTP .......................................................................................................................................................... 14
8.4 HL7 MESSAGING OVER SSH ................................................................................................................................................... 14
8.5 ESTABLISHING A VPN .............................................................................................................................................................. 14
8.5.1 FTP Transfer Through VPN .................................................................................................................................... 14
8.5.2 HL7 Messaging Through VPN.............................................................................................................................. 14
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
2
Transcription
9 PROJECT PLAN .................................................................................................................................................................. 15
9.1 SAMPLE INTERFACE PROJECT PLAN .......................................................................................................................................... 15
10 APPENDICES AND OTHER REFERENCES ......................................................................................................................... 16
10.1 PLANNED MAINTENANCE WINDOW....................................................................................................................................... 16
10.2 INTERFACE MESSAGE QUEUE MANAGER ................................................................................................................................ 16
10.3 MESSAGE QUEUE MAINTENANCE .......................................................................................................................................... 16
10.4 CONTINUING SERVICE AND SUPPORT ..................................................................................................................................... 16
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
3
Transcription
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.
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.
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
4
Transcription
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
Name:
Project Interface Contact
Interface expert,
responsible for
continuing interface
support
Networking and security
expert, responsible for
overall connectivity
Name:
Project IT Contact
Details
Name:
Phone:
Email:
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
Transcription
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 insurance (carrier, member ID, etc.)
•
Charge Data (diagnoses, cpt codes, date of service, etc.)
Common use-case scenario is depicted below. It is important to identify and review your specific use-cases with the
Interface Project Manager.
Use Case
Have dictated notes seamlessly
transcribed into your athenaClinicals
encounter
Format
Overview
HL7
Outbound: Patient Demographics and
Scheduling
Inbound: Scheduling, Results, and
Transcription
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
6
Transcription
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 -
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.
5.2 Message Formats & Systems
athena uses HL7 V2
Does the other system adhere to HL7 standards or is there a custom specification? - blank -
HL7 v2 is recommended
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
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
5.4 Interface Workflow
Consider your workflows and use cases for this interface and see the outline below.
Outbound: Patient Demographics and Scheduling Messages (ADT, SIU, MFN)
Inbound: Transcription Messages (SIU, ORU, ORU R01)
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
7
Transcription
5.4.1 Workflow Outline
When the patient arrives and the encounter begins, athena sends an S14 message to the vendor. The S14 contains the
clinical encounter id in PV1. 19.
The vendor receives the S14, and sends back an S14 (“ACK”) with the same clinical encounter id in the message in MSA.2.
This message triggers athena to keep the encounter open and prevents the provider from signing off on the encounter. The
message, “Transcription Pending” will alert the provider to expect an incoming transcription.
Once the dictation has been transcribed in the external system, the transcription is sent in an ORU^R01 message with the
transcription text in the OBX.5 segment. This transcription will be added to the designated section (marked by a “dictation
marker”) of the clinical encounter and will close the encounter.
Inbound ORU^ORU messages do not contain a dictation marker and are not placed into a clinical encounter section.
Inbound ORU^ORUs are not associated with an S14 Check – In Message. In the case that an ORU^ORU is sent into athena,
a clinical document is created and routed based on patient and provider and sent to the provider’s clinical inbox.
Action
Direction
Add Patient
Outbound
A28
Update Patient
Outbound
A31
Schedule Appointment
Outbound
S12
Update Appointment
Outbound
S14
Cancel Appointment
Outbound
S15
Check-In
Outbound
S14
Add Referring Provider
Outbound
M02
Update Referring
Provider
Outbound
M02
Delete Referring
Provider
Outbound
M02
Start Section Specific
Transcription Job
Inbound
S14
Finish Section Specific
Transcription Job
Inbound
ORU^R01
Finish Unsolicited
Transcription Job
Inbound
ORU
Default Message
Notes:
5.5 Dictation Markers
The athenaNet MX engine requires a “dictation marker”, a unique set of identifies in the inbound transaction (OBR-3 – OBR-5
segments), in order to properly parse the data into the appropriate notes fields of the encounter. Inbound ORU^R01
messages without these segments will error out and not be processed.
The dictation marker will always be in the following format –
ClinicalEncounterID|EncounterSection|Field

ClinicalEncounterID - A unique identifier of an athenaClinicals encounter; sent in outbound S14-Check-In
message

EncounterSection|Field - A text description of the encounter section and corresponding field. Supported
encounter sections and their field names are:
o Assessment –

DiagnosisOrders|ASSESSMENTNOTE
o Encounter Reason/Chief Complaint –

EncounterReason|FREETEXT_NOTE
o Discussion –

DiagnosisOrders|DISCUSSIONNOTE
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
8
Transcription
o
o
o
History of Present Illness (depends on client configuration in athenaNet)|

HPI|TEXT

HPI_Semistructured|OTHERNOTES

HPI_Structured|OTHERNOTES

HPI_Templated|EXAMFREETEXT
Physical Exam –

PhysicalExam|EXAMFREETEXT
Review of Systems (depends on client configuration in athenaNet)|

ReviewOfSystems|EXAMFREETEXT

WellChildROS|EXAMFREETEXT
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
9
Transcription
6 Outbound Workflow
6.1 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.1.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 Appointments
6.2.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
This S14 message contains the clinical
encounter id (PV1.19)
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
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
10
Transcription
appointment. If this functionality will be an issue for your downstream system, please discuss this workflow
with your athenahealth Project Manager.
6.2.2 HL7 Mapping for Outbound S14 – Check In
To notify the transcription vendor that a patient has been checked in and an encounter has started for a patient,
athenahealth will send a S14 message when the patient checks into their appointment. Below is an HL7 mapping table
detailing which fields will be sent to the transcription partner.
Data Field
Default HL7 field
Context ID
MSH. 4
Date/Time
MSH.7
Message Type
MSH.9
Appointment Status
SCH.25
Clinical Encounter ID
PV1.19
6.2.3 Sample Outbound S14 Message
MSH|^~\&|ATHENANET|CONTEXT ID^PRACTICE NAME|TRANSCRIPTION
VENDOR||201411051514||SIU^S14|24431698M94|P|2.2||||||||
SCH|6758002|6758002||||NEW PATIENT 20|10/31/2014@11:27-lft elbow pain/no sx,mva,xray,wc/mm;May be RTA
eligible.|NP20^NEW PATIENT 20|20|minutes|^^^201411051500|||||mmartinez163|||||||||ARRIVED
PID||347397|347397||FIRST^LAST^L^||DATE OF BIRTH|SEX||941^Patient Declined| PT ADDRESS^^PT CITY^PT STATE^PT ZIP
CODE^COUNTRY||(555)555-5555^|(555)555-5555|124^English|U||||||61^Patient Declined||||||||
PV1|||2^NORTH CENTRAL OFFICE^^NORTH CENTRAL
OFFICE||||26^arowland||||||||||26^arowland||1381042|||||||||||||||||||||||||||||||||
DG1||ICD9||no current diagnosis|||||||||||||||
RGS|||
AIG|||arowland|||||201411051500|||20|minutes||
AIL|||2^NORTH CENTRAL OFFICE|||201411051500|||20|minutes||
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
11
Transcription
7 Inbound Message Configuration
7.1 Appointments (S14 – “ACK”)
The following sections contain configurations related only to inbound appointment messages.
7.1.1 Minimum Required Fields for Inbound S14 – “ACK” Messages
In order to hold the encounter open for a pending transcription, the following data fields need to be specified. We expect
data to be in the following HL7 fields.
Data Field
Default HL7 field
Date/Time
MSH.7
Message Type
MSH.9
Clinical Encounter ID
MSA.2
7.1.2 Sample Inbound S14 Message
MSH|^~\&|TRANSCRIPTION VENDOR NAME||ATHENA|CONTEXT
ID|201411050620016||SIU^S14|14103100483460684|P|2.3
MSA|AA|1381042|26|providerID|1
7.2 Results
7.2.1 Minimum Required Fields for Transcription(R01) Messages
In order for an encounter to receive an inbound transcription inserted into the encounter, the following data fields need to
be specified. We expect data to be in the following HL7 fields.
Data Field
Default HL7 field
Context ID
MSH. 6
Date/Time
MSH.7
Message Type
MSH.9
Clinical Encounter ID
OBR.3
Encounter Section
OBR.4
Encounter Field
OBR.5
Transcription Message Count
OBR.20
Total Number of Expected Transcriptions Count
OBR.21
Transcription Text
OBX.5
7.2.2 Sample Inbound R01
MSH|^~\&|TRANSCRIPTION VENDOR|||CONTEXT
ID|20141106072947||ORU^R01|201411060729475940|P|2.3|2014110500008473|141031004834|1617879||||||
PID|||347397||LAST^FIRST^L|19501203|||||||||||||||||||||||||
OBR|||1381042|DiagnosisOrders|ASSESSMENTNOTE|||||||||||||||1|6
www.athenahealth.com
This is the first of 6 dictations.
athenahealth, Inc. Confidential and Proprietary
12
Transcription
OBX|1|TX|||~CHIEF COMPLAINT~Left elbow pain.~~HISTORY OF PRESENT ILLNESS~[DICTATION INSERTED]~~ [DICTATION
INSERTED].~~PHYSICAL EXAMINATION~[DICTATION INSERTED]~~IMAGING STUDIES~~[DICTATION
INSERTED].~~ASSESSMENT~[DICTATION INSERTED] ||||||R|||20141106072947||
7.2.3 Minimum Requirements for Transcription (ORU) Messages
If an encounter is not held open (S14 “ACK” Message Returned), and the transcription is added as a Clinical Document the
following data fields need to be specified. We expect data to be in the following HL7 fields
Data Field
Default HL7 field
Context ID
MSH. 6
Date/Time
MSH.7
Message Type
MSH.9
Transcription Text
OBX.5
7.2.4 Sample Inbound ORU
MSH|^~\&|TRANSCRIPTION
VENDOR|||94|20150102040022||ORU|201501020400225052|P|2.3|2014123100004894||||||||
PID|||347397||LAST^FIRST^L|19501203|||||||||||||||||||||||||
OBR||||||20141231^0000||||||||||providerID^providerLast^providerFirst||||||||||||||||||||||||||||
OBX|1|TX|||~CHIEF COMPLAINT~Left elbow pain.~~HISTORY OF PRESENT ILLNESS~[DICTATION INSERTED]~~ [DICTATION
INSERTED].~~PHYSICAL EXAMINATION~[DICTATION INSERTED]~~IMAGING STUDIES~~[DICTATION
INSERTED].~~ASSESSMENT~[DICTATION INSERTED] ||||||R|||20141106072947||
www.athenahealth.com
athenahealth, Inc. Confidential and Proprietary
13
Transcription
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
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
14
Transcription
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
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 end-user
acceptance testing is the client’s responsibility to plan, organize, and support.
GO LIVE
1 week
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
15
Transcription
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/files/interfacesupportdocs/athenaNet_Interface_Queue_Management_Guide.doc)
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
16
Transcription
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)
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
17