1. Integrating Complementary Tools with PopMedNet TM 27 July 2015 Rich Schaaf rschaaf@commoninf.com

2.  Introduction Commonwealth Informatics  Implements and supports innovative systems for medical product safety and public health surveillance  Mix of academic, government, and commercial projects  Deep experience with data from  Healthcare records (both EMR and claims)  Single case adverse event reports (ICSRs) and product complaints  Clinical trials data sets Slide 2

3.  Commonwealth Informatics  Participates in Mini-Sentinel as a subcontractor to the Mini-Sentinel Operations Center (MSOC)  Responsible for developing and enhancing several of the MSOC’s software applications  Code Lookup Tool  Medical Code Management  Algorithm Lookup Tool  Task Order Matrix Slide 3

4.  Code Lookup Tool (CLT)  Browse different types of hierarchically organized medical terminology data (drug/event/procedure codes) for the Mini- Sentinel project  Allows users to group codes into multiple sets in order to identify therapies, diagnoses, procedures, etc. for use in studies Slide 4

5.  Medical Code Management (MCM)  Maintain a versioned and timestamped repository of medical terminologies for use by:  Code Lookup Tool  MSOC SAS programmer community  PopMedNet Query Tool Slide 5

6.  Algorithm Lookup Tool (ALT)  Provide a searchable catalog of algorithm definitions used to define outcomes, cohorts, confounders, therapies, etc. Slide 6

7.  Task Order Matrix (TOM)  Keep track of Mini-Sentinel task orders along with their associated activities and subactivities Slide 7

8.  Application Integration Slide 8

9.  Motivation for improved integration  The Mini-Sentinel Distributed Query Tool is based on the PopMedNet TM software application  Several complementary software applications support the activities of the MSOC  MSOC processes and workflows can be improved through better integration among the set of applications in the Mini-Sentinel “ecosystem”  The current version of PopMedNet enables integration by providing APIs that allow access to a rich set of services Slide 9

10.  PopMedNet API  Allows programmatic access to an extensive set of PopMedNet resources  Entirely REST based  Follows the OData (Open Data Protocol) standard that defines the best practices for building and consuming RESTful APIs http://www.odata.org Slide 10

11.  What is REST?  REST stands for Representational State Transfer. It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.  REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines..  RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.  REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.)  Despite being simple, REST is fully-featured; there's basically nothing you can do in Web Services that can't be done with a RESTful architecture. http://rest.elkstein.org/2008/02/what-is-rest.html Slide 11

12.  Example: Retrieve information for all “active” Mini-Sentinel requests  Goal  Facilitate associating sets of codes produced in the Code Lookup Tool (CLT) with the corresponding Mini- Sentinel request  Enhance the CLT application to query PopMedNet to determine the set of “active” (not yet finalized) requests  Implementation steps  Determine the relevant API endpoint  Formulate the API request  Integrate the API request into the application Slide 12

13.  PopMedNet API documentation  Extensive API documentation is available within PopMedNet Slide 13

14.  Determine the relevant API endpoint  Active requests are retrieved using the “requests/list” endpoint  Use the API documentation to determine the fields that are available for requests Slide 14

15.  Formulate the API request The API request identifies the:  API endpoint  Fields of interest  Filtered set of rows to return  Sort order for the returned results For this example the client application needs the:  ID, Identifier, Name, Description, Status and StatusText fields  Where Status = 250  Sorted by Identifier  From the https://qa4api.lincolnpeak.com/requests/list endpointhttps://qa4api.lincolnpeak.com/requests/list The corresponding URI is: https://qa4api.lincolnpeak.com/requests/list https://qa4api.lincolnpeak.com/requests/list ?$select=ID,Identifier,Name,Description,Status,StatusText &$filter=Status%20eq%20Lpp.Dns.DTO.Enums.RequestStatuses'250‘ &$orderby=Identifier Note: Spaces in the URI need to be replaced with a URL encoded equivalent (“%20” or “+”) Slide 15

16.  Integrate the API request into the application Example implementation in Java Slide 16 initClient() Initialize the REST client object getActiveRequests() Obtain the list of active PopMedNet requests printRequestsFromJSON() Extract the request information from the JSON returned by the API request This example uses the Apache Wink REST framework

17.  initClient(user, password) Slide 17

18.  getActiveRequests(client, baseURI) Slide 18

19.  printRequestsFromJSON(json) Slide 19

20.  Output from the RestClientDemo Slide 20

21.  Questions / Discussion Slide 21