salesforce
+
+

Lab 5: Submitting Medical Inquiries and Adverse Events

Overview

In lab 4 you were introduced to a sample set of APIs that were created to demonstrate how the Anypoint Platform may be used to efficiently process Medical Inquiry Requests (MIRs) and Adverse Event Reports (AERs). In this lab you will practice submitting an MIR and an AER in order to observe the behavior of this workshop’s Application Network.

Learning Objectives

  • Gain experience working with APIs hosted in the Anypoint Platform.

  • Observe the processing of requests through the Application Network.

Step 1: Prepare to Test the Case Intake Experience API

In order to observe the behavior of the APIs in this workshop’s Application Network you will need to be able to submit test messages to the Case Intake Experience API. Tools such as Postman and cURL are commonly used for testing APIs. However, recall that in lab 3 you were introduced to the api-console, which is included in APIs that are generated through the scaffolding process. You will use the api-console during this lab.

Complete the following steps to open the api-console

  1. Navigate to Runtime Manager in the Anypoint Platform, select the Sandbox environment, then click on the lsw-eapi-case-intake API. (Remember, APIs may have a 4 digit suffix specific to this workshop instance.)

    lab5 runtime manager 1

  2. Copy the URL for the API.

    lab5 runtime manager 2

  3. Open a new browser tab, paste the URL of the API in the address bar and ensure that you are using https://, then append /console/ to the address and press the enter key. The API console will be displayed.

    lab5 api console 1

  4. Click on the POST button. Details related to testing this API method will be displayed.

    lab5 api console 2 1

  5. Testing of your API will consist of setting any query parameters that may be needed, then editing the message payload and clicking on the Send button.

    At this point, you will have to update the Request Url field with the domain name you copied before. It should look similar to this https://lsw-eapi-case-intake-bmygf7.5sc6y6-4.usa-e2.cloudhub.io/api/case

    You will be running your tests against the same set of APIs that the other workshop participants will be using. In order to see the results of your testing, you should edit the contactName and inquiryId properties to unique values in order to be able to locate your messages when you review the API logs.

    You should see a 200 OK response and a sample payload returned.

    lab5 api console 2 2

Step 2: Overview of Submitting MIRs and AERs

As mentioned in Lab 4, a single Experience API is used to accept MIRs and AERs. The Case Intake Experience API has been designed to accept data in JSON format.

The data that makes up the content of the message is also customized for this workshop. That is to say, it is not a standard HL7 or FHIR message payload. As the message is processed through the Application network the message format, data elements and transport protocol can all be tailored to the requirements of the calling application as well as the systems that are accessed via the System APIs.

With those concepts in mind, complete the following tasks to see how a MIR is processed.

  1. Edit the sample message to set the requestType to Medical Inquiry, the contactName and value fields as desired, and then click on the Send button.

    lab5 api console 3

  2. The message will be submitted for processing. Scroll the browser window down to see the 200 OK return code and the message that was returned.

    lab5 api console 4

Step 3: MIR Processing Steps

Note:

Use the following diagram as a reference as you proceed through this lab step.
lab5 post test 1

So, what happened after you clicked on the Send button at the end of Step 2?

  1. The Case Intake Experience API will inspect the message payload and convert it to the proper format required for submitting either a MIR or an AER. It will then invoke the Inquiry and Report Routing Process API in order to determine where to route the request to.

  2. The Inquiry and Report Routing API will inspect the value of the requestType element and route it either to the Medical Inquiry System System API or to the AE Processor System API.

  3. Since the request was for a Medical Inquiry, the Medical Inquiry System System API will be invoked. This System API will complete the appropriate interactions with the back end system and then return the response from the back end system to the Inquiry and Report Routing Process API, which will return that response back to the Case Intake Experience API.

Step 4: Demonstration of Connecting to Veeva Vault

Click on the image below to view a demonstration of the steps required to search for and download a document from Veeva Vault.

Step 5: AER Processing Steps

Note:

Use the following diagram as a reference as you proceed through this lab step.
lab5 post test 2

So, what happened after you clicked on the Send button at the end of Step 2? Several of the same steps that were performed for the MIRs will be performed.

  1. The Case Intake Experience API will inspect the message payload and convert it to the proper format required for submitting either a MIR or an AER. It will then invoke the Inquiry and Report Routing Process API in order to determine where to route the request to.

  2. The Inquiry and Report Routing API will inspect the value of the requestType element and route it either to the Medical Inquiry System System API or to the AE Safety Report System System API.

  3. If the request was for a Adverse Event Report, the AE Safety Report System System API will be invoked. This System API will complete the appropriate steps to format an AER for submission to the FDA, then send the AER to an Anypoint MQ queue for later processing. Lastly, it will return a response to the Inquiry and Report Routing Process API, which will return that response back to the Case Intake Experience API.

    Note:

    The FDA prefers that smaller AERs be submitted in batches rather than in individual transmissions. Larger AERs (Greater than 1GB) are to be sent individually. Using Anypoint MQ to batch up smaller AERs, yet still providing a mechanism to submit larger reports immediately, accomodates this requirement.

  4. As mentioned in Lab 4, the Process AE Queue to FAERS ICSR Process API runs as a daemon process to send AERs to the FDA on either a scheduled or an on-demand basis.

    • By default, this daemon will run from a scheduler to "GET" messages from an Anypoint MQ queue, then call the ICSR Submission to FAERS System System API to submit the AER batch in the FDA’s system.

    • Although not illustrated, this daemon process also exposes a REST API method that enables an application to request immediate processing of the AERs that have been enqueued. This capability enables urgent AERs to be submitted outside of the scheduled polling interval.

  5. The ICSR Submission to FAERS System system API will perform the appropriate interactions with the FAERS system to complete the submission of the AERs.

Step 6: Demonstration of Connecting to FDA’s Electronic Submission Gateway

Click on the image below to view a demonstration of the steps required to submit an Adverse Event Report to the FDA’s Electronic Submission Gateway via an AS2 connection.

Step 7: Observing the Results

There’s a lot that happens with each call to the Case Intake Experience API. For this workshop each of the APIs have included Logger components that will write out the values of either contactName or value from the messages that are submitted. In Lab 6: Monitoring the Application Network you will learn how to access the output from the Logger components in order to verify that your messages are being processed by the apporpriate APIs.

Summary

In this lab exercise you have seen how the various APIs that were created for this workshop operate. Now go to Lab 6: Implementing APIs in Anypoint Studio to experience building your own API.

Submit your feedback!
Share your thoughts to help us build the best workshop experience for you!
Take our latest survey!