INetCore Software Solution Inc

IcrApp-HealthCare Web Services Information

Web Service API support data exchange via Web Services (WS) as described in this guide. The standardized ePCR Web Service API provides the following advantages:

Fully automated electronic data exchange (including submission and retrieval) between agency, regional, state, and national systems.
Better transaction management: The data exchange can be easily monitored without risk of time outs by using an asynchronous transaction model. In Health Care systems, XML and business validation reports can be available in real time from the same communication channel.
Possibility to move to real-time data exchange supporting public health surveillance.
Vendor independence, scalability, and wide acceptance/adoption.
Web Service supporting data payload XML and non-XML standards like HL7, NEMSIS v3.5.0/v3.5.1, NTDS v2024/2025, ITDX 2024/2025, and other custom formats based on client requirements.

Web Service WSDL: https://inetcoress.com/icrapp-webservices/NemsisWs?wsdl

Purpose of Web Services API

The ePCR Web Service API is a unified interface that supports data exchange between distributed systems. In a typical scenario, a client can interact with a Web Service at a given URL by using the HTTPS protocol. Web Services are based on SOAP/Restful.

Major Design Goals:

Flexibility: Allows applications to communicate over the Web in a platform-neutral, language-independent environment.
Efficiency: Instant response and quick turn-around.
Unity: Minimize confusion over information exchange by standardizing the information exchange interface.

Security

Hyper Text Transport Protocol Secure (HTTPS) is the required communication channel. HTTPS is used for secure communication over public networks. In HTTPS, the transmission of information is encrypted using Transport Layer Security (TLS). Systems support TLS version 1.2 and higher versions.
Web Service messages might include sensitive information such as login credentials and protected health information (PHI/PII). These types of data must be protected at the transport level.

Web Service Descriptive Language (WSDL)

Web services are defined using Web Services Description Language (WSDL).

The WSDL specifies the operations:

This Web Service provides “RetrieveStatus”, “SubmitData” and “QueryLimit” operations

Status Codes

All responses from the Web Service must have a Status Code to communicate to a client what happened with a request. All Status Codes are defined in the WSDL, and listed at the end of this document.

Common errors (defined by the WSDL standard) should be included in the Response Data and use the appropriate Status Code as indicators.
The WSDL defines a set of standard response codes. All WS response messages must include a status code.

a.All error codes are negative integers.
b.All success codes are positive integers.
c.Integer “0” means that the requested action is not completed yet. The client should query the server later to retrieve final processing status.
d.Systems may define custom error codes, with integers smaller than -100. Similarly,custom success codes should use integers greater than 100.

Systems must adopt the definitions from the WSDL for codes between -100 and 100.For example, it is non-compliant to use “-1” as a status code for “Failed import of a file, because of the [FATAL] level Schematron rule violation” since “-1” has been defined in the WSDL as “Invalid username and/or password”.

The following is a summary of all status codes used in the WSDL.

PrivilegeErrorCodes:
Error codes of authenticaition/authorization for an attempted web service operation

-1	Invalid username and/or password
-2	Permission denied to the client for the operation
-3	Permission denied to the client for that organization

ParameterErrorCodes:
Generic error codes fan an attempted web service operation

-4	Invalid parameter value
-5	Invalid parameter combination

ServerErrorCodes:
Error codes for web service server

-20	Generic server error
-21	Server error, because of database connection/operation issue
-22	Server error, because of file system/network/IO issue

SubmitDataProcessCodes:
Codes to describe return codes for an attempted data submission web service operation

-11	Failed import of a file, because the same file is already on the server
-12	Failed import of a file, because of failing XML validation
-13	Failed import of a file, because of [FATAL] level Schematron rule violation
-14	Failed Import of a file, because of [ERROR] level Schematron rule violation
-15	Failed Import of a file, because of critical ETL rule violation
-16	Failed import of a file, because of critical Business Intelligence rule violation
-30	Failed import of a file, because the size of SOAP message exceeds the limit
1	Successful import of a file
2	Successful import of a file, with [ERROR] level Schematron rule violation reported
3	Successful import of a file, with [WARNING] level Schematron rule violation reported
4	Successful import of a file, with ETL rule warning
5	Successful import of a file, with Business Intelligence warning
6	Partially successful import of a file, with [ERROR] level Schematron rule violation reported
10	File has passed validation, processing is not yet complete

ResultPendingCode:
Code to indicate the process is not finished on the server for an attempted web service operation

0	The expected data processing is not yet complete

RetrieveErrorCode:
Code to indicate the error status for RetrieveStatus operation

-40	Status for the requested requestHandle is not available: it could be expired, or not in the correct format, or never exist, or for any other whatever reason.
-41	Status for the requested requestHandle is not available since it expires already
-42	Invalid value of requestHandle (for example, not formatted properly)
-43	Never-used value of requestHandle

QueryLimitCodes:
Code to indicate the status for QueryLimit operation

51	Successful operation of QueryLimit
-50	Server is too busy. The client should query later
-51	Failed operation of QueryLimit