Integrating Complementary Tools
with PopMedNetTM
27 July 2015
Rich Schaaf
rschaaf@commoninf.com

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
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
Code Lookup Tool (CLT)

 Browse different types
of hierarchically
organized medical
terminology data
(drug/event/procedure
codes) for the MiniSentinel project
 Allows users to group
codes into multiple
sets in order to identify
therapies, diagnoses,
procedures, etc. for use
in studies
Slide 4
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
Algorithm Lookup Tool (ALT)

 Provide a
searchable catalog
of algorithm
definitions used to
define outcomes,
cohorts,
confounders,
therapies, etc.
Slide 6
Task Order Matrix (TOM)

 Keep track of
Mini-Sentinel
task orders along
with their
associated
activities and
subactivities
Slide 7

Application Integration
Slide 8
Motivation for improved integration

 The Mini-Sentinel Distributed Query Tool is based
on the PopMedNetTM 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
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
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

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 MiniSentinel 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
PopMedNet API documentation

 Extensive API
documentation
is available
within
PopMedNet
Slide 13
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
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 endpoint
The corresponding URI is:
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

Integrate the API request into the
application
Example implementation in Java
•
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
Slide 16
initClient(user, password)

Slide 17
getActiveRequests(client, baseURI)

Slide 18
printRequestsFromJSON(json)

Slide 19
Output from the RestClientDemo

Slide 20

Questions / Discussion
Slide 21