salesforce
+
+

Lab 4: Use Case Overview

Overview

During and after clinicial trials of new drugs the pharmaceutical industry must track any Adverse Event Reports (AERs) that are reported to them and submit them to the FDA. The use case for this workshop is centered around improving the process of capturing Adverse Event Reports (AERs), which are then submitted to the FDA. Processing of Medical Inquiry Requests (MIRs) will also be reviewed.

Capturing of AERs is typically a very disjointed and unstructured process. Adverse Event Reports may come from any number of sources, and the channels that they support may be equally diverse as well.

lab4 use case overview 1

The Anypoint Platform can act as a bridge between the Health Care Providers (HCPs) that need to submit an AER to the FDA. Processing of AERs requires strict adherence to the security and message format standards that the FDA has in place. The Anypoint Platform may be used to ensure compliance with all of the requirements the FDA has in place, and at the same time may also be used send AERs and MIRs to additional endpoints for internal reporting requirements.

lab4 use case overview 2

Learning Objectives

  • Locate and review existing APIs in Anypoint Exchange that may be used to integrate Adverse Event Reporting as well as process Medical Inquiry Requests.

Step 1: Access the Anypoint Platform

  1. After you had registered for this workshop you should have received an email that contained instructions on creating an Anypoint Platform account. Open a web browser and navigate to the following URL: https://anypoint.mulesoft.com/. The following page will appear.

    lab4 anypoint login 1

  2. Enter the credentials that you used when you registered via the email link and then click on the Sign in button. The Anypoint Platform home page should appear.

    Note:

    Ensure that you use the credentials that you used from the email link. Otherwise, you will not have access to the Business Group that contains all of the assets used in this workshop.
    lab4 anypoint login 2

  3. The home page for the Anypoint Platform will appear.

    lab4 anypoint platform home 1

  4. Most of the assets that we will review in this lab exercise will be found in Anypoint Exchange. Click on the Discover & share button under Exchange in order to show a list of all assets that are available in the Business Group for this workshop.

    lab4 anypoint platform home 2

  5. In order to review only those assets that are a part of this workshop click on the link immediately below the All assets link in the left side of the page. Note that the name listed below will vary, depending on how your Anypoint Platform instance is configured.

    lab4 anypoint exchange 1
Note:

This workshop uses the following naming convention for APIs:

  • eAPI: prefix for Experience layer APIs

  • pAPI: prefix for Process layer APIs

  • sAPI: prefix for System layer APIs

  • -W4367 (or similar suffix): Suffix for all APIs (Naming convention used by Workshop authors.)

Also, note that any hyperlinked text in the Anypoint Exchange entries may not be active in the workshop environment you’re working in.

Step 2: Review the Case Intake Experience API

Experience APIs provide a business context for the data and processes that are unlocked and established with System and Process APIs. Experience APIs expose the data to be consumed by its intended audience — such as mobile applications, internal portals for customer data, etc.

For this workshop, a single Experience API is used to accept Medical Inquiry Requests and Adverse Event Reports. You can configure any number of additional Experience APIs to accomodate variations in security requirements, message formats or transfer protocols.

lab4 eapi case intake diagram

Complete the following steps to review the key properties of the Case Intake Experience API.

  1. Click on the eAPI - Case Intake tile and then expand the /case resource.

    Note:

    An updated user interface for Anypoint Exchange was just introduced prior to this workshop. If you are presented with the newer version of the user interface simply click on the back to previous UI button in the upper right corner to have all remaining screen match the layouts in this student guide.

    lab4 anypoint exchange 2 1

    This is the layout of the previous user interface.

    lab4 anypoint exchange 2 2

  2. This API exposes one resource: /case, and two methods on this resource: GET and POST. For this workshop each MIR and AER that is submitted will be assigned a unique caseType and caseId.

    Click on the GET method.

    lab4 case intake 1

  3. The GET method will retrieve data regarding a specific case, based on the type of case (MIR or AER). The caseId and caseType values are passed as Query parameters to this API. These values will simply be passed to the Inquiry and Report Routing API. To test the GET method using the mocking service enter "Medical Inquiry" in the caseType field and "1352335" in the caseId field, then click on the Send button.

    lab4 case intake 2

  4. Scroll the page down to see a sample response that is returned from the mocking service.

    lab4 case intake 3

  5. Next, click on the POST method to review how this API supports publishing of case information.

    lab4 case intake 4

  6. As with any POST method, data that needs to be submitted must be included in the body of the request. A couple of points to note with this API:

    • This method does not expect any URI or query parameters.

    • This API will accept JSON payloads.

    • Although it is not apparent from the documentation, this method will call the Inquiry and Report Routing API passing a JSON payload.

    • The request type is identified within the message payload, using the requestType key (JSON).

    • An example message payload is included in the API description, however there isn’t a complete description of the message format requirements for this method.

      This illustrates one of the key values of API led architecture. It isn’t necessary to modify source or target applications to accomodate differences in formats or protocols. Accomodation of the differences can be made within the Application Network.

      In this workshop, the input message is not a standard FHIR or HL7 message. This is a good example of why it is important to include complete documentation for your APIs, and why Anypoint Exchange provides tools to enable thorough documentation of APIs, either in the Exchange asset itself, or via a hyperlink in the documentation.

Step 3: Review the Inquiry and Report Routing Process API

In the previous step you saw that the Case Intake Experience API would accept POST requests in JSON format. You also saw that the API would accept messages where the requestType determined whether the message was related to either an MIR or an AER. It is up to this Process API to route the GET or POST request to the appropriate system of record and return the results back to the Experience API that called it.

lab4 papi case routing diagram

Complete the following steps to review the key properties of the Inquiry and Report Routing Process API.

  1. Return to Anypoint Exchange and then click on the pAPI - Inquiry and Report Routing tile.

    lab4 inquiry and reporting 1

  2. Click on the /request resource to view the methods that are exposed from this API.

    lab4 inquiry and reporting 2

  3. Click on the GET method. Similar to the Case Intake Experience API, this API expects two query parameters: requestId and requestType. In this API, the requestType value will be used to determine whether to call the GET method in either the Medical Inquiry System or AE Processor System APIs.

    Note:

    The RAML specification for the GET method did not include a sample response body. THus, if you click on the Send button you will get an empty response. This is normal behavior.
    lab4 inquiry and reporting 3

  4. Click on the POST method. This API requires a message body that is formatted in JSON. It will route the request to the appropriate System API based on the value of the requestType key. Transformation of the message payload to accomodate any difference in message format requirements may also be done within this API.

    lab4 inquiry and reporting 4

Step 4: Review the Process AE Queue to FAERS Process API

For any number of reasons it may be necessary to delay processing of documents until a later time. Batching of documents is a common example. Waiting until a specific date or time to submit a document may also require a delay in the processing of documents.

For this workshop, it is assumed that submission of AERs to the FDA must be delayed, rather than immediately processed. Anypoint MQ is used to queue AER submissions from the AE Safety Report System System API (described in a later step). The Process AE Queue to FAERS Process API runs as a daemon process to submit AERs to the FDA on a scheduled basis. This API also exposes a REST endpoint to enable manual submission of AERs, when necessary.

lab4 papi faers submission diagram

Complete the following steps to review the key properties of the pAPI Process AE Queue to FAERS Process API.

  1. Return to Anypoint Exchange and then click on the Process AE Queue to FAERS tile.

    lab4 process ae queue 1

  2. Click on the /queue-processor resource to view the methods that are exposed from this API, then click on the POST method.

    lab4 process ae queue 2

  3. Note that this API uses a Scheduler to periodically poll for AERs that may have been enqueued. This will enable normal priority AERs to be submitted in a batch to the FDA. This API also exposes a REST endpoint to enable triggering a manual submission of any AERs that have been enqueued. This action will enable immediate transmission of high priority AERs.

    Also, note in the flow illustration above that there is an Error handling flow that contains an ANYPOINT_MQ:TIMEOUT message processor. There may be times when the scheduler looks for documents to process, but doesn’t find any ready. This may throw an exception if it isn’t accomodated. This API was designed with a custom error handler that will simply disregard any exceptions where messages are not available.

    The MuleSoft runtime allows API designers to include any number of exception processing routines to handle conditions that would otherwise throw errors in the application.

Step 5: Review the System APIs

System APIs provide the connection to the various applications and data sources that need to be included in an Application Network. A System API may utilize a MuleSoft Connector to connect to an application, or it may make direct SOAP or REST API calls if a Connector is not available.

System APIs provide a layer of abstraction for Process APIs, such that the Process API does not need to know any details regarding connectivity or security requirements. In many cases, the back end application may be swapped out for a newer version, or completely replaced without having to reconfigure any of the other APIs in the Application Network.

For this workshop, there are 3 System APIs that are used:

  1. The Medical Inquiry System API is used to add or retrieve inquiries related to MIRs. The backend system could be an application such as Cerner or Veeva, or it could even be a relational database.

  2. The AE Safety Report System API is used to capture AERs and prepare them for submission to the FDA. As mentioned earlier, this workshop assumes that AER submissions are batched and scheduled. An Anypoint MQ queue is used as the queuing system to store AERs until a submission to the FDA is needed.

  3. The ICSR Submission to FAERS API invoked by the Process AE Queue to FAERS ICSR daemon to take the AERs that have been processed and transfer them to the FDA.

    lab4 system apis
    Note:

    A live connection to the FDA Adverse Event Reporting System (FAERS) was not available at the time this workshop was developed. Thus, interactions with the FDA are simulated by this System API.

    Review the ICSR Submission to FAERS entry in Exchange for a visual depiction of how the automated submission of AERs will be implemented.

Summary

You now have a more in depth understanding of the various APIs that are a part of this workshop. Some of the key points to remember are:

  • By adhering to an API Led approach to building out your Application Network you can foster reuse of existing assets, which will in turn improve the speed of delivering new features and enhancements to your organization.

  • By using REST interfaces and MuleSoft Connectors you can easily upgrade or replace back end systems without having to revisit all of the APIs that are in your Application Network.

Now go to Lab 5: Submitting Medical Inquiries and Adverse Events to practice invoking the APIs you’ve explored.

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