Child pages
  • Massive Transfusion Protocol Native Mobile Application(s)
Skip to end of metadata
Go to start of metadata


The Massive Transfusion Protocol (MTP) Mobile application is a mobile application designed to accept input from trauma physicians and provide an assessment of the probability the patient will benefit from MTP. The application stores the input and the assessment, called a case record, in a research database. The application is presently used by Emory physicians at Grady Hospital.

The application is currently in production and was initially developed as a "mobile web application" which means, it's a web application that runs in a native browser on any device/platform (iPhone, Android, desktop) and conforms to whatever form factor is associated to that device/platform.  To review the features of the app and learn a little more about the history of this project, visit this page.


The application was originally developed as a mobile web application because it was thought it would not need any features typically associated with native mobile applications.  That is, it's a relatively simple app that doesn't have any overly complex user interface requirements that would have made a native mobile app necessary.  Additionally, the app does not store any data locally.  By building it as a mobile web application, we were also able to re-use user interface and back-end logic across all devices/platforms.  Once the application was deployed, it could be "hybridized" by our internal app catalog and be made available to any Emory person that needed it via that platform.

Recent issues have forced us to re-think this approach because as operating system versions change, it often requires that the application be "re-hybridized" and there currently isn't a good way to get the new version of the application to the users without them having to delete and re-install the app on their devices.  This is not sustainable long-term.  Additionally, the physicians at Grady Hospital would like the option to distribute the app to a much broader audience than just Emory.  For these reasons, we've been asked to provide estimates covering the re-implementation of this application as a native iOS and Android application so we can eliminate the issues we've experienced with hybridized apps as well as provide a path to public distribution via the Apple app store and Google Play.

New Development: On March 22, 2016 LITS met with Apperian representatives who are actively working on a solution to these problems we've seen with hybrid apps. It may be possible to stabilize the current mobile web app as a hybrid app very soon. There are still legitimate long-term reasons to consider moving to a native app architecture if public distribution of the MTP app is still desired. We just wanted to make sure you are aware of this new development.

Statement of Work

There are 6 high-level categories of work necessary to re-implement the app as a native app for iOS and Android.  Those are:

  • Engineer an approach to effectively integrate a native Android app with our back-end ESB services similar to the way we do it for iOS apps.  We've engineered an approach that works for iOS but have not done that yet for native Android apps.  This work would not be specifically related to this project as the methods created to accomplish this goal would apply to all native Android apps going forward just like the approach we've engineered for iOS apps can be applied to any future iOS app (including this one).
  • Engineer an approach to effectively authenticate and authorize users of the application.  Currently, this is done via Shibboleth and our internal Authorization ESB Service because it's an internal app and it's being run as a mobile web application which inherits all the infrastructure associated to Emory's web and application servers, single-signon via Shibboleth being one of those services it inherits because of how/where the web application runs.  In order to make this app available to the general public, there will need to be a new authentication/authorization approach taken that does not involve our internal single-signon services and will involve a new, MTP specific registration and identity vetting process.
  • Develop an ESB service to generate the probability that an MTP would be beneficial/necessary.  Currently, this is performed in the service layer of the web application so in order to re-use this logic across devices, the most likely approach will be to externalize that logic as an ESB service and expose it to the mobile devices via a web service facade which is our standard approach.  The remaining server-side logic already exists in the MTP ESB/Web Service (creating a CaseRecord, retrieving all CaseRecords for a surgeon etc.).  This work is specifically related to this app and only applicable to this app.
  • Re-work the web application to use the new ESB service so we can still offer the ability to upload test data since that function can only be performed via the web app (desktop form factor).  If that function is to remain, we'll need to keep the web app live so test data can be submitted and ran through the algorithm.
  • Develop the Android version of the app, which means re-implement the current set of screens, flows and user interface logic as a native Android application.  This work is specifically related to this app and only applicable to this app.
  • Develop the iOS version of the app, which means re-implement the current set of screens, flows and user interface logic as a native iOS application.  This work is specifically related to this app and only applicable to this app.

Native Android Mobile App Development Work Estimate

Engineer approach to integrate native Android app with the MTP back-end ESB services~120This work will apply to other, future applications and therefore would not be included in the overall cost of this effort as it relates specifically to MTP.  Since this is an engineering effort, the estimate is a high-level estimate which is likely low.  It's just hard to provide an estimate for this kind of work at this point until we've done more research as to the potential approaches for this.  From past experience, on the iOS platform, we can assume work like this will take several months to complete.  However, since the iOS and Android platforms are so different, it's difficult to provide many specifics for this work at this time.
Engineer registration, authentication and authorization approach60This will be new work that we haven't done before on this platform so it will likely take longer to complete than the iOS effort
Re-implement current set of screens, flows and user interface logic as a native iOS application75 
Total for project:135135 hours @ $95.00 per hour or $12,825

Native iOS Mobile App Development Work Estimate

Develop/test ESB service that encapsulates the MTP probability calculation logic and expose it to the iOS and Android apps via a web service facade12The logic already exists inside the service layer of the web application, so this effort is simply moving the logic from that component to a more centralized component (the ESB) and testing that new service.  Note, this work will apply to both platforms (iOS and Andoid) but it is listed here because iOS is the more prevalent platform
Engineer registration, authorization and authorization approach20We should be able to leverage techniques and even some code that we've already used in other iOS apps for this
Re-implement current set of screens, flows and user interface logic as a native iOS application60


Total for project:92112 hours @ $95.00 per hour or $10,640


Web Application Estimate

Re-work web app to use the new ESB service for MTP probability generation and test8This work is necessary to maintain the ability to submit test data in mass to test the probability calculation algorithm with a large set of data
Total for project:88 hours @ $95.00 per hour or $760
  • No labels