The MassHealth connectivity method provides a secure, system-to-system connection between MassHealth and its trading partners to send and receive HIPAA transactions. Submitters may also upload files through the Provider Online Service Center (POSC) .
It is an automated process and is ideal for trading partners that transmit a large volume of HIPAA transactions. It was implemented in accordance with the Affordable Care Act (ACA) Operating Rules.
The new MassHealth connectivity method does not replace the existing Healthcare Transaction Services (HTS) submission method—it is different from HTS. Trading partners that currently use the HTS service may continue to use that service until they determine the appropriate time to transition to the new MassHealth Connectivity method. However, all newly identified submitters should adopt the new method where possible.
MassHealth supports the following transaction types:
- Batch Processing: 270/271, 276/277, 835, 837I, 837P, 820, 834, 999/TA1
- Real-Time Processing: 270/271, 276/277, 999/TA1
A trading partner may choose between two different envelope standards, transmitted via the following internet protocols:
- HTTP MIME Multipart (Hypertext Transfer Protocol/Multipurpose Internet Mail Extensions)
- SOAP+WSDL (Simple Object Access Protocol/Web Services Description Language)
Both options for the new connectivity method utilize a set of standards for interoperable communication. Both envelope methods utilize web services and HTTP Headers to transmit data. The main difference is the technology.
SOAP is a standard, Extensible Markup Language (XML) based communications protocol. Based on a contract between a client and a server, SOAP uses specific tags in a Web Service Description Language (WSDL), an XML technology, for transporting data. SOAP is the advanced version of HTS.
HTTP is an application layer protocol for transmitting messages. The HTTP Multipart MIME envelope method invokes a Java servlet to transport HTTP requests and responses (data) through a web service. It is a layer within a web service.
In other words, the HTTP Multipart MIME utilizes servlets in a Java web server. SOAP utilizes web services. For example, SOAP is a standard web service for interoperability. Java implemented the interoperability communication standards through servlets.
The changes are federally mandated for payors. MassHealth must provide this connectivity method option to all of its trading partners. However, the changes are not federally mandated for MassHealth trading partners. Trading partners may choose to adopt this method or leverage other transaction submission options available through MassHealth (i.e. POSC DDE, POSC batch upload).
Yes. The new MassHealth connectivity method is compliant with the EOHHS Virtual Gateway security standards.
If you are currently sending and receiving HIPAA transactions with MassHealth through the existing Healthcare Transaction Service (HTS) connectivity method, it is not required that you switch to the new connectivity method option. MassHealth will continue to support existing HTS users.
However, it would be ideal for all trading partners to transition to the new MassHealth connectivity method when it is technically feasible. All newly identified (system-to-system) submitters should adopt the new MassHealth connectivity method.
Yes. The MassHealth EDI Department will assist you throughout the entire process to ensure a successful implementation. Contact the MassHealth EDI Department at EDI@MAhealth.net or 800-841-2900 to coordinate testing.
The testing timeframe may vary, depending upon if you have implemented either MIME or SOAP with other payors. If you are not already sending batch files for HIPAA transactions, testing may take longer.
You will need to use the appropriate URL below to ensure that you connect to the proper environment when sending a test message envelope (with payload) to the MassHealth test environment.
- SOAP: https://wsgw.mass.gov/HHS/mmisExtInterfaces/CoreServiceTPT
- MIME: https://wsgw.mass.gov/HHS/mmisExtInterfaces/CoreMimeServiceTPT
No. You can use the same credentials in your message envelope that you use to access the POSC test environment. The credentials are the user name and password that you use for production. The credentials must be included in the security section of your message envelope.
MassHealth recommends that you first decide which technology submission option you want: SOAP or MIME. Then you will need to test the HIPAA transaction that you intend to use as the “payload” before testing the message envelope.
If you are not already submitting electronic batch HIPAA transactions, you will need to upload a HIPAA compliant test file to the POSC test environment before submitting a test message envelope with the payload. To upload a test file to the POSC test environment, click on the following link to log on to the POSC and upload the file in the usual manner: https://mmis-portal-tptest.ehs.state.ma.us/EHSProviderPortal.
At a high-level, the batch process is as follows.
- A trading partner generates an X12 transaction (payload), packages it within either SOAP or an HTTP MIME Multipart message, and sends the message envelope to MassHealth.
- MassHealth receives the request, and immediately issues a batch receipt confirmation for the trading partner to retrieve. Note: The batch receipt confirmation is not an ASC X12-acknowledgment transaction. The message will indicate that the Batch was received and the envelope processed and indicate if there were errors. It will contain status and error codes for both HTTP and envelope processing.
- Trading partner retrieves the batch receipt confirmation and sends a request to obtain an X12 acknowledgment.
- MassHealth processes the batch request, issues a response specific to the payload type for the trading partner to retrieve. Note: After the Batch is processed, the trading partner will be able to request a Batch Retrieval to retrieve the ASC X12 Acknowledgment transactions, such as a 999 or TA1. They may also request a response for that payload type, such as 271 or 276.
- The trading partner retrieves the X12 response, loads the message envelope into their system, and reviews the HIPAA transaction set response.
At a high-level, the real-time process is as follows.
- A trading partner generates a single X12 transaction (payload), packages it within either SOAP or an HTTP MIME Multipart message, and sends the message envelope to MassHealth.
- MassHealth receives and processes the request, immediately issues a response with an X12 transaction set for 271, 277 or 999/TA1, available for the trading partner to retrieve.
- There is no batch receipt confirmation for real-time transactions.
- MassHealth only accepts 270 and 276 real-time transactions.
No. HTS uses SOAP v1.0, and the new CORE connectivity method uses SOAP v1.2. Where technically feasible, MassHealth recommends that trading partners upgrade to the new MassHealth Connectivity method.
Please refer to the schema and definitions specified in the Phase II CORE Connectivity Rule 270 specification available on the www.caqh.org website.
Click on the following links for the XSD and WSDL file specifications:
Note: Open in notepad or an XML editor tool.
You may also refer to the MassHealth Connectivity Companion Guide.
18. If I upgrade to the new connectivity method from HTS, has the Batch Retrieval functionality changed?
Yes. Trading partners can now use the “Batch Response Pick Up” feature to retrieve a list of files that are ready to be downloaded then download each file using the “Batch Retrieval” transaction. This replaces the “Get All” function offered in the current HTS system.
- A successful file submission will usually return a status code of “200 OK” or “202 Accepted.”
- An unsuccessful file submission will usually return an error code of “400 Bad Request.”
- If MassHealth was unable authenticate the sender, usually an error code of “403 Forbidden” or “401 Unauthorized” is returned.
- If MassHealth was unable to receive your file or the message could not be processed, usually an error code of “500 Internal Error” is returned.
- A successfully processed envelope will usually return a status code of “Success.”
- An unsuccessfully processed envelope will usually return the name of the field causing the error and will indicate one of three types of errors. If an illegal value was provided, or a required field was missing, or if a field was sent that was not understood, the trading partner will usually receive one of the following error codes: <FieldName>Illegal, <FieldName>Required, <FieldName>NotUnderstood.
- A “VersionMismatch” error code will usually be returned if there is an issue with CORERuleVersion being sent
- If there are security issues such as the user name/password, an ““UnAuthorized”” error code is usually returned.
- If the batch file checksum value computed on the recipient did not match the value that was sent in the envelope, a “ChecksumMismatched” error code is usually returned.
- If there is a formatting issue with the envelope, a “Sender” error code is usually returned.
- If the message could not be processed, a “Receiver” error code is usually returned.
A “payload” contains the X12 transaction content encoded in a standard messaging envelope.
It contains the payload and is inside of the transport protocol envelope that is sent over the public internet.
Please contact the EDI Department at MassHealth Customer Service Center. The production environment will be made available only to trading partners that successfully pass testing.
If you have any questions, please contact the EDI Department at the MassHealth Customer Service Center by sending an email to EDI@MAHealth.net or by calling 800-841-2900.