Check the Status of Asynchronous Batch Processing:

Check the Status of Asynchronous Batch Processing:

GET processingStatus

Description
This API allows the practice to obtain the processing status of resources that were sent to Medfusion. Several API calls allow one or a batch of resources to be submitted for later processing (i.e. the HTTP 202 status code), and this API is how the caller determines the results of that processing. The Medfusion internal processing of an API call or individual resource within the call is called a message. The header of the response to the original POST request contains a Location URL that you can use with the GET method to check the processing status. The body of the response contains the dataJobId for the entire batch and themessageId for each message in the batch. The sample response has those values highlighted:
Message Processing
When a practice posts messages to Medfusion directly using our APIs, the request will be validated synchronously and a response message with an initial success or failure status will be returned to the sender. Success at this point only means that the resources have been accepted for later processing. The status of these synchronous messages uses the standard set of HTTP codes, including 202 for “Accepted” (but not yet processed).
The processing of each individual resource / message will then take place asynchronously. We decouple receipt of a message from its processing. This allows us to accept messages faster than we can process them, and helps to accommodate surges in demand.Response Header

202 ACCEPTED
Content-length:180
Content-type: application/xml
Location: https://integration.medfusion.net/v1/practice/935134ed-df26-4ca8-897c-b6b1da47e697/processingStatus/12fdc7c2-4a37-4178-b12a-a3fa8c6c2965

Response Body

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:ProcessingResponse xmlns:ns2="http://schema.intuit.com/health/ccd/v1">
	<dataJobId>f1ad851a-8159-4037-b3ec-e07ae3fbbf71</dataJobId>
	<messageId>12fdc7c2-4a37-4178-b12a-a3fa8c6c2965</messageId>
	<processingStatus>Successful</processingStatus>
	<ResponseMessage></ResponseMessage>
</ns2:ProcessingResponse>

URL
https://{server}/v1/practice/{PracticeID}/processingStatus/{MessageId}
HTTP Method
GET
Required URI Values
server
The domain name of the test or production system.

  • Test system: integration.demo.medfusion.net
  • Production system: integration.medfusion.net
PracticeID
The unique practice integration ID for a given practice. Medfusion will provide a practice ID that you can use during development.
MessageID
The internal Medfusion message id that was returned in the response to the API call.

Success Response
  • 200 – Success. The processing statuses are included in the body of the response. There are five processing states that can be returned to the GET processingStatus request.
    • INIT
    • INPROGRESS
    • COMPLETED
    • REPROCESSED
    • ERROR

    States COMPLETED and REPROCESSED are final and there is no need to re-query since they will not change. For INIT and INPROGRESS, the caller should re-query later in order to receive the final state of the message. The REPROCESSED state indicates that a subsequent attempt to process a message with an INIT, INPROGRESS, or (retriable) ERROR state was successful.

    ERROR will also include a node for classification of the error. Possible values are:

    • WARNING: A final status. The payload is still delivered to the patient, but a failure occurred during processing.
    • RETRIABLE: The payload failed but there were no significant errors and it can be resent.
    • FATAL: A final status. The payload fatally errored and the issue should be resolved before re-posting to the Medfusion system.

    It is recommended that the requester use the following retry logic when calling the processing status:

    • Try 10 seconds after posting.
    • Try 60 seconds after posting.
    • Try 10 minutes after posting.
    • Try 60 minutes after posting.
    • Try 90 minutes after posting.

    If the message doesn’t go to a final state within a reasonable period of time, the requester should contact Medfusion support.

Error Response
  • 400 – Bad request. The data given in the HTTP request failed validation.
  • 401 – Unauthorized request. Check the OAuth attributes.
  • 404 – Not found. The requested resource was not found in the server.
  • 415 – Unsupported media type. The server could not process the request because the content type specified in the request header is not supported.

Sample Call
GET https://integration.medfusion.net/v1/practice/eac8c4c7-3cb0-44c8-a969-0bb52c145482/processingStatus/cf9cfd7a-fd0d-4894-bcf6-d92b11094b05
Sample Response
Response Header

200 OK
Content-length:180
Content-type: application/xml
Location:http://integration.medfusion.net:8080/v1/practice/7f20527e-52f7-475a-98f6-571b6898369d/processingStatus/db32d632-b1f6-408c-99c6-1b5c7c6a5a9b

Response Body – Successful Completion (Defined in ProcessingStatus.xsd)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3::ProcessingStatus xmlns:ns2="http://schema.intuit.com/health/events/v1"
xmlns:ns3="http://schema.intuit.com/health/v1">
    <DataJobId>bec02040-f23b-11e1-aff1-0800200c9a66</DataJobId>
    <Message>
        <MessageId>681fe5f1-133a-4d47-98bb-2e1f7f0d9521</MessageId>
        <PracticeResourceId>8aa5d265-6875-44e7-b3f1-084b71d22a4e</PracticeResourceId>
        Note: The PracticeResourceId corresponds to the unique Message ID supplied when posting
         the original message to Medfusion.
        <Status>
            <State>COMPLETED</State>
        </Status>
    </Message>
</ns3:ProcessingStatus>

Response Body – In Progress

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3::ProcessingStatus xmlns:ns2="http://schema.intuit.com/health/events/v1"
xmlns:ns3="http://schema.intuit.com/health/v1">
    <DataJobId>bec02040-f23b-11e1-aff1-0800200c9a66</DataJobId>
    <Message>
        <MessageId>681fe5f1-133a-4d47-98bb-2e1f7f0d9521</MessageId>
        <PracticeResourceId>12332</PracticeResourceId>
        <Status>
            <State>INPROGRESS</State>
        </Status>
    </Message>
</ns3:ProcessingStatus>

Response Body – Error

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2::ProcessingStatus xmlns:ns2="http://schema.intuit.com/health/events/v1"
xmlns:ns3="http://schema.intuit.com/health/v1">
    <DataJobId>bec02040-f23b-11e1-aff1-0800200c9a66</DataJobId>
    <Message>
        <MessageId>681fe5f1-133a-4d47-98bb-2e1f7f0d9521</MessageId>
        <PracticeResourceId>20121121044949342719</PracticeResourceId>
        <Status>
            <State>ERROR</State>
            <Error>
                <Code>EHDC_CCD_IN_002</Code>
                <Description>BusinessException at ActorIdValidation, Validating the 
                authenticity of the CCD</Description>
                <Severity>FATAL</Severity>
            </Error>
        </Status>
    </Message>
</ns2:ProcessingStatus>
Errors
There will be unique error codes and descriptions per API call. As new errors are encountered, new codes will be created. The State will be ERROR and there will be an error code and description included in the Response Body.
Remediation Actions
For all Error response messages received by the practice, the practice must review and determine how to resolve the error, fix it and then re-post the message to Medfusion.Response Body – Batch of requests with various statuses

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:ProcessingStatus xmlns:ns2="http://schema.intuit.com/health/v1"
    xmlns:ns3="http://schema.intuit.com/health/events/v1">
    <DataJobId>90d1789e-e56e-4692-a08a-a449185521f6</DataJobId>
    <Message>
        <MessageId>3941e706-5a00-445b-bc42-749e1ef95cc3</MessageId>
        <PracticeResourceId>475324</PracticeResourceId>
        <Status>
            <State>COMPLETED</State>
        </Status>
    </Message>
    <Message>
        <MessageId>65393518-58e7-44ce-8bbc-67cb97f9fd87</MessageId>
        <PracticeResourceId>dev3062101</PracticeResourceId>
        <Status>
            <State>REPROCESSED</State>
        </Status>
    </Message>
    <Message>
        <MessageId>a7b8ee43-1dc9-4034-8941-d6226f9ebe13</MessageId>
        <PracticeResourceId>dev3062102</PracticeResourceId>
        <Status>
            <State>ERROR</State>
            <Error>
                <Code>DC_CORE_004</Code>
                <Description>Exception while publishing Canonicals to the Hub</Description>
                <Severity>FATAL</Severity>
            </Error>
        </Status>
    </Message>
</ns2:ProcessingStatus>