Child pages
  • Architecture, Security, Compliance, and Distribution Requirements for Emory Mobile Apps
Skip to end of metadata
Go to start of metadata


Mobile Apps developed at Emory by Emory developers or contractors should consider the following in the development of their app.

Architecture Requirements

An architecture review should be scheduled for each mobile app project to conclude the initial design phase of the project and again prior to implementation. This review is required for projects implemented by LITS or Emory's preferred mobile app consultants. It is a valuable process that helps ensure the project is aligned with Emory standards for source code version control, software configuration management, technical documentation, authentication, authorization, etc. See the complete Architecture Review Team (ART) template for details along with background on the LITS Architecture Review Process. The following are especially important:

Source Code Repository

The source code for all Emory apps should be maintained in the LITS managed subversion repository at within an appropriate project directory. Emory is in the process of moving to an enterprise Git deployment, but at present Emory uses Subversion. Emory people and Emory's preferred mobile app consultants will all have access to Emory source code management. If source code is managed elsewhere for any part of the project, it must be done in a private repository with no public access and the source code must still be on deposit in Emory's Source Code Repository prior to completion of the engagement an mobile app distribution review.

Technical Documentation

Technical design, configuration, and operations documentation should be provided for each mobile app project in the form of wiki space or pages on the Emory wiki at

Build and Package

A documented, repeatable process for building and packaging mobile apps and back-end services must be included in the documentation and source project.

End User Authentication to the App

Emory has developed specific patterns for user authentication and authorization within mobile apps. All apps should use the approach documented in User Authentication for Emory Mobile Apps.

App Authentication to Back-end Web Services at Emory

Emory requires that its mobile apps also authenticate to back-end services with client certificate authentication in addition to end user authentication. All apps should use the approach documented in Mobile App Authentication to Emory Back-end Web Services when accessing back-end web services hosted by Emory.

Persistent Storage of Sensitive Data

Emory apps that store sensitive data or ePHI will most likely need to be hosted by Emory central IT in Emory's on-premises or approved cloud infrastructure. Typcially approved Emory databases and web service patterns for exposing that data must be used. If ePHI is involved HIPAA audit logging will need to be implemented.

HIPAA Audit Logging

Emory has implemented a common HIPAA Audit Logging Service (HALS) that is accessible as a web service and ESB service for use by any authorized Emory app. Applications can use this logging interface directly to meet Emory's HIPAA Audit Logging Requirements or they may chose to implement web services that can be proxied by Emory's HIPAA Auditing Proxy Service (HAPS).

Security Review

Most Emory mobile apps that handle sensitive data will require a security review. The Emory security review process involves submitting a request to Emory Information Security (Note: to complete this form you need an Emory NetID and password). The review will involve completing a questionnaire and discussing the responses with Emory Information Security. Mobile app defaults and mobile-app specific review questions are listed on the Information Security Public Wiki Space.

Compliance Considerations

Emory University and Emory Healthcare compliance officers review the mobile 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 mobile application 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 an application 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 applications 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.

If Emory HIPAA compliance, PCI, FERPA, or other compliance regimes apply to your app, you may need to add additional features to your app. For this reason it is best to run your app idea by Emory compliance early to make this determination or if the app is already in development, submit it for review as early as possible. As a concrete example if HIPAA compliance policies apply to your application, HIPAA audit logging will be required. This means all access to ePHI in your application must be audited in a very specific manner. For details on HIPAA audit logging see the Emory HIPAA Audit Logging Service (HALS).

Distribution Requirements

All mobile apps at Emory, whether they are bound for internal Emory users or public marketplaces, are initially distributed internally using Emory's Mobile App Catalog. Mobile developers may not distribute mobile apps beyond their initial development team by other means like TestFlight, App Store beta, or any other method. Emory policy requires that all mobile apps be distributed using the Emory Mobile App Catalog. App developers are strongly encouraged to distribute an early version of their app in the Emory mobile app catalog. If the app is ultimately bound for a public marketplace, developers should contact Office of Technology Transfer (OTT) at this early stage as well to make an invention disclosure and start the public app distribution process.

Internal distribution for testing and demo purposes to a limited group of Emory users typically takes two days from the initial request. Internal distribution for production use can take one to two weeks to get all necessary approvals. In some cases of apps subject to compliance policies, it can take longer.

Request for public distribution typically take one to six months, depending on the nature of the intellectual property involved and the nature of the app. For this reason it is advised to initiate contact with OTT at the earliest stages of the project to start the review. Many of the Emory aspects of the public distribution review can occur before the app is completed.

In the case of public distribution through the Apple App Store, Emory has little influence over the course of that process. Once the app is completed and approved by Emory for distribution, there is an Apple review process that has taken from two weeks to three months to complete, depending on the nature of the app. This process takes longer than one might expect, because Apple may reject the app for any number of reasons and the process is iterative.

Overall if an app is bound for a public marketplace, one should expect the app to spend at least several months in various internal Emory and marketplace reviews when building a project timeline. For complete details on Emory's internal and public mobile app distribution policies and practices see Mobile Application Review and Distribution Processes.


  • No labels