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

Status of this Document

Process Goals

The goals of this process are to implement Emory's policy for internal-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

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

In order to review 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.

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).

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