Child pages
  • Emory Review Process for External-facing ESB, Web, and FHIR Services
Skip to end of metadata
Go to start of metadata

Status of this Document

This is the draft description of the Emory Review Process for public-facing ESB, Web, and FHIR Services and Use for services bound for public consumption by Emory vendors, partners, or the general public. If these services will only be accessed from Emory networks, you may use the Emory Review Process for Internal-facing ESB, Web, and FHIR services. This document describes a proposed process that is not presently in use. Comments and suggestions are welcomed as comments on this page or you may send feedback to Steve Wheat at <>.

Process Goals

The goals of this process are to implement Emory's policy for public-facing ESB, web, and FHIR services by:

  1. Obtaining and recording approval of appropriate data custodians for release of data and logic
  2. Implementing applicable compliance and security requirements
  3. Tracking and recording services and their use in Emory's service registry and dashboard
  4. Assessing additional risk of exposing services to clients on the internet or the general public at large
  5. Implementing appropriate public service security, auditing, and countermeasures

Step 1: Request a New Service Deployment or Proposed Use of an Existing Service

In order to review a new service or proposed use of an existing service, complete the New ESB or Web Service Deployment Request Form or Request to Use and Existing ESB Service, Web Service, or Event Form to start the process. The appropriate LITS integration team for University or Healthcare IT will receive the request to deploy the new service or use and existing service, enter the service into the Emory ESB/Web Service Dashboard, initiate the review, and make contact with the requestor to start the review and prepare to implement the request if approved.

Note that LITS may not publicly expose the new service or publicly expose and existing service for a new use without completing this process. For many projects there is a desire to expose a development, test, and/or demo environment to faciliate proofs-of-concept or demos with vendors or public apps. This too may only be done with certification from the data custodian in Step 2 that no sensitive data or processes can possibly be exposes in these non-production environments.

Step 2: Data Custodian Review

LITS identifies the data custodian for the data the ESB or web service exposes from the Emory ESB/Web Service Dashboard and forwards the request to the data custodian for approval. Data custodians are determined by the business owners of the data as part of the SOA governance process. LITS identifies the specified owners by using the dashboard list. If upon review by the data custodian it is unclear whether the request should be approved or denied, a meeting of the SOA governance team (all reviewers in this process) may be called by the data custodian or the requestor to discuss the request.

Step 3: Compliance and Regulatory Review

Emory University and Emory Healthcare compliance officers review the ESB service, web service, or service consuming application to determine whether or not Emory's HIPAA compliance or other appropriate compliance policies apply. Emory's compliance officers provide the following general guidance in determining whether or not HIPAA applies to a mobile application:

  1. If the service collects, stores, or transmits personal health information for the personal use of the consumer and not for Emory people in their role as researcher, clinician, or support role, then HIPAA does not apply to the application.
  2. If such a service provides Emory researchers or clinicians access to the personal health information for the purposes of research or patient care, then HIPAA does apply to the application.
  3. All such services that collect, store, or transmit personal health information must implement appropriate information security measures to protect personal health information, regardless of whether or not Emory's HIPAA compliance policies apply. 

Step 4: Technical & Information Security Reviews

Emory LITS performs a high-level technical review of the ESB service, web service, or integration to determine if there is a need for any detailed security and compliance reviews of the service or consuming application. For example, if the service collects and stores ePHI, credit card information, or other compliance related data, Emory LITS will inform the owners of the service or consuming application of relevant policies and any practices required by those policies. Once this cursory template is completed a technical review will be scheduled by the appropriate LITS technical review team for University of Healthcare IT, depending on whether the application is considered an Emory University or Emory Healthcare application. Additional materials may be required, depending on the type of review specified. The organizer of the technical review team will contact application developers and help them prepare any additional materials.

If a security review is required, a meeting is scheduled with representatives of Emory Information Security to walk through a mobile app security checklist based on the security, compliance, and regulatory requirements that are relevant to the particular service and consuming application(s).

Note that all publicly exposed ESB, Web, and FHIR services are potentially subject to additional security and auditing measures beyond internally distributed services. Projects should allow additional time for the implementation of any additional measures specified in the review of a publicly-exposed ESB, web, or FHIR service.

Subsequent Service Update Submissions

For subsequent service or service consumption updates, application owners should request another review if the answers to the review questions would change. For example, if the nature of the data being collected or stored by the service has changed and now ePHI is being collected when it was not before, then a new review should be scheduled. Service owners and service consumers should also update the internal submission forms relevant to their applications for each subsequent submission.

  • No labels