Custom app development follows a lifecyle from concept through application deployment. Read on to learn about what to expect and review useful tips. You will be on your way to a successful app development project at Duke!
DESIGN AND PLAN
The Design phase includes both user design as well as technology design. This is the time when you explore, discuss, and decide on required features, technology integrations, and the audience for your app. Visual design is iterative, starting with low-fidelity wire frames and eventually becoming robust, beautiful screen design.
A consultation with the Mobile App Gateway team can help you to refine your concept, engage with DHTS, and start the project approval processes during this phase. You are laying the groundwork for success.
A few questions to consider:
Planning to use Duke Health branding? Get it right by following these guidelines.
Push notifications are a great way to engage or annoy users. Take a look at how to use them to enhance the user experience with this piece.
Don't forget about collecting data on your user's app engagement. Take a look at Google Analytics.
Do you want to work with an outside software developer? Contact us for vendors and information about contract approval processes at Duke.
Note: Contracts cannot be signed by individual PIs or Duke staff and must be executed by the Procurement office or the Office of Research Contracts.
Once you have identified a Duke- approved development partner, signed a contract, and determined any technical integrations you may need with Duke's data or software, you are ready to build or develop!
Projects vary in timelines based upon complexity, but you should plan between 3-12 months, and your software development partner can estimate this for you. When considering timelines for your overall project, add in time for DHTS and IRB reviews before you can start distributing your app.
Building a content focused mobile app? Talk to us about the Duke Health Mobile Content Manager tool.
If you are creating a website, refer to the Duke IT Security Office Web Hosting Policy.
Are you creating a patient facing app that pulls data from the EHR to populate the app? Go to open.epic for FHIR API endpoints and access to a development sandbox. Duke Health employees can also find over 400 APIs on the Epic App Orchard. Outside vendors can join the App Orchard for a fee to access APIs, publish apps, and receive technical support from Epic.
Interested in using Duke's single sign on (SSO) so users don't have to create a new name and password? The documentation is available here.
It's crucial to do multiple rounds of testing of your application prior to release to ensure that the functionality works and the application is secure.
Plan for a combination of developer testing, user testing, and security testing in your timeline. Developer testing is done by the vendor. DHTS recommends that vendors use Veracode to scan for security vulnerabilities. User testing is a great way to ensure that your application meets your engagement goals and delights your audience. Talk to the MAG team about how to run effective user testing sessions.
We also suggest the following user testing tools:
When you are comfortable with your app performance, request a consult to set up a security review with the Duke Health Information Security Office.
Finished with testing? You are ready to release!
Congrats! You've made it! Your app has been approved, designed, tested, and built. You are ready to release it to your users.
Consider also how you are going to publicize your public app to attract users. Some tools you can use are:
You've come a long way, and everything works perfectly. Unfortunately it won't stay that way forever. Browsers update, Apple and Android release new phones, and code becomes stale. Plan for maintenance fees (around 15-20% of the initial build cost) from the beginning to support your app through it's lifetime.
Discuss a maintenance approach with your contract developer or DHTS when you are negotiating your contract.
We recommend discussing these topics when negotiating a maintenance agreement: