Project 4 will focus on taking the common solution (in Filelocker titled PHA4v4.zip) and using this as a basis to make a number of changes and enhancements including:

  1. Update Prescription Screen with OpenEMR Integration and FDA Daily Meds Access: This enhancement involves changes to the current prescription screen and the introduction of a new screen that summarizes the medication interactions (see enhancement two below). In the process, you will need to gather information from both MSHV and OpenEMR, and provide a link to FDA Daily Meds for each prescription drug.
  2. New Medication Reconciliation and Interaction Checking Screen and Algorithms:Design, develop, implement, and test medicationinteractions for PHAwhich includes access remote repositories and putting together the resulting interactions on one or more screens that summarize the interactions for the patient. This that will pull medications from both MSHV and OpenEMR.

TEAMS:Students must work in teams of three individuals in order to partition the work among team members. Please send email to and with your team names, emails, and netIDs. Solomon will finalize teams in the CSE2102 labs on Wednesday. Please note that you can work across labs with any student in the class. Since there are 53 students in the class, we will have 17 teams of 3 and 1 team of 2.

Update Prescription Screen with OpenEMR Integration and FDA Daily Meds Access

In Figure 1, both the current medication screen (left side) and Medications screen (right side) for prescriptions is shown. Note that in the figure, non-prescription meds were shown since the test account used for the screenshots did not have any prescription drugs.

Figure 1. Current Medication Summary Screen and Prescription Drug Screen.

The screen on the right needs to be modified to have two categories under My Prescription Drugs – Microsoft HealthVault and OpenEMR. Then, under those two categories there needs to be the medications that are found in MSHV and OpenEMR for the patient listed in the same format as they are currently shown.

An enumeration of changes for this first enhancement are:

  • Integrate OpenEMR using the new REST API for getting medications to make those medications accessible for a patient and listed in read-only manner on the new medication screen. This will require you to retrieve the medications from OpenEMR. To accomplish this,please see the course web page for the file: Note that you will be using a shared version of OpenEMR running on cicats9. This is due to the fact that the REST API needs an IIS server to be running would be difficult for you to set up on your own computing environment. The instructions in the PDF contain the reference to the REST API for OpenEMR at ciciats9.
  • Create a revised Medications Screen to include the HealthVault and OpenEMR categories.
  • For each medication, currently clicking on the medication brings up the screen for the medication itself. You need to have two options available for each medication: 1. Pull up the medication as current working; and 2. Pull up a new screen that links a medication to FDA Daily meds so that for each medication the patient can see detailed drug information. Note that for OpenEMR meds, there are not allowed to make any modifications to the medications, since these are never stored back.
  • Add a button somewhereon the revised medication screen for “Check Interactions” which upon selection does a number of actions (see enhancement 2 below) that results in a new screen with a colored code list medication interactions.

Note that the DailyMed RESTful API is a web service for accessing current Structured Product Labeling (SPL) information. It is implemented using HTTP and can be thought of as a collection of resources with the web services listed at the site: For example,you can search for AMOXICILLIN a common antibiotic at: and get back a list of meds from which you can select one from that list, say: . For the project you want to programmatically display this information on the PHA app when the patient does a search.

New Medication Reconciliation and Interaction Checking Screen

Design, develop, implement, and test medication interactions for PHA which includes access remote repositories and putting together the resulting interactions on one or more screens that summarize the interactions for the patient. This enhancement has two main parts:

  1. Design and implement a new screen to show the medication interaction results.
  2. Working with varied REST APIs in order to pull information about medications and their interactions from external sources.

Figure 2 illustrates both of these parts.

Figure 2. Expanding PHA Architecture for Project 4.

In terms of the new screen for medication interactions, consider the example shown in Figure 3, which is designed provide the alert information to the user in a quick and easily recognizable fashion, geared towards simplicity in order to serve a wide range of patients and to be easily portable to mobile devices. The main application screen, is currently divided in two tabs, visualizing MSHV and the OpenEMR. Patients can switch between the tabs to see the list of medications stored in each record. The Reconcile Medications and the Find Medication Interactions buttons perform on-demand reconciliation and interaction searches. If any of the entries interact, the severity of interaction is indicated by a yellow (significant interaction) or red (critical interaction) background. Entries for which no interactions are found are displayed with a neutral background color. There are up to three buttons located next to each of the medications: ViewInteractions, Details, and Remove. Since a patient cannot modify the information located in the provider’s EMR, the only button visible in this tab is Details. View Interactions presents the user with a listing of cross-interactions between the specified medication and any other reconciled entry. Details presents information of the medication ingredients, generic names, and the dates when the user started and stopped taking the medication. Note that this was designed for a web-based setting which may not be suitable for a mobile platform.

Figure 3. Sample Interactions Checking.

The second part of the project as indicated in Figure 2 (right hand side) has to do with accessing varied database and web repositories. The process for interaction checking begins with a retrieval of the sets of medications from MSHV and OpenEMR. Remember that the Patient class in Project 3 final design had a protected variable for keeping OpenEMR medications that wasn’t used in Project 3 but will be in this project.

Once all of the medications have been loaded in PHA from MSHV and OpenEMR, the next step involves iterating through those medications in order to identify each of them. There are three webs sites of note to assist in this process for RxNorm (“RxNorm provides normalized names for clinical drugs and links its names to many of the drug vocabularies commonly used in pharmacy management and drug interaction software”), RxTerms (“RxTerms is a drug interface terminology derived from RxNorm for prescription writing or medication history recording”), and NDF-RT (“NDF-RT is a concept-oriented terminology, a collection of concepts, each of which represents a single, unique meaning”):

Note that each medication has a unique alphanumeric identifier called NUI that is a identifier for the drug in the NDF reference terminology ( The NUI can be found by doing a concept search using the NDF-RT RESTful API Alternatively, you can use RxNorm and RxTerm to make sure you have a proper name/search criteria, get the RxCUI (an identifier from RxNorm and RxTerm), and then do a search over that specific identifier: Note that two significant objectives of this project are: one, working with a teammate and dividing your responsibilities; and, two, learning to work with external databases and services where you have limited support in house (e.g., from Solomon).

For experimental purposes, the following list of medications would be as below; we will be entering these meds into OpenEMR. You can enter other medications in MSHV that will be utilized to search for interactions.

  1. Zithromax (Azithromicin)
  2. Angiozem (Diltiazem)
  3. Azilect (Rasgaline)
  4. DayQuil (Acetamiophen)
  5. Avinza (Morphine)
  6. Rifadin (Rifampin)

Note that we may provide you with additional medications for you for testing.

For those of you interested in an entire article on our medication interaction checking and reconciliation, please see: if you copy and paste the link into a browser, you will be asked to log on via your netID and then it will access the PDF of the paper.

Helpful Suggestions:

  • Java Test Program for APIs: In order to learn about and use the various APIs (RxNorm, RxTerms, NDF-RT, FDA) programmatically, we suggest that you consider writing a straight Java-based program (non-Android) that will allow you to get experience with using the API outside of the overhead of having it work in the Android environment. The key issue is to understand what the calls expect (parameters) and what they return (data format – XML vs. JSON). By doing so, you can get all of the calls to the APIs that you need working correctly, tested and debugged prior to incorporating the code into PHA.
  • Distribution of Work: The use of a test program for the APIs also gives each team the opportunity to partition the work. You could have one teammate do the RxNorm, RxTerms, NDF-RT APIs in preparation for their use in identifying drugs and interaction checking. You can have another teammate work on the changes to the medication screen and perhaps adding in the FDA Daily Meds link. You can have a third teammate work on the new checking interactions screens that the displaying of the results which shows the level of severity of the interactions. These are essentially three different components that a team can plan around rather than trying to put everything into PHA at once.

Remember, one objective of the project is for your team to experiment and learn the new technologies by leaning on each other, the other is to get used to working in a team and work somewhat on learning the different ways you can partition the project into components.

Document Version and Source Code Control: github ( will be used for the final project to allow all of the code to be shared and reliably backed up for each Team. You need to log on to github with your NetID to become a user of the system. Once this is done, one of the team members can create a project (that both of you can write) and share using the NetIDs of all members. Each team should share also with Solomon (sob05001) and Prof. Demurjian (sad02010). Please make sure you keep local copies of documents and code on your own computers for backup purposes. For using git with Eclipse, please see the following link:

Project 4 Final Requirements

  • December 5th, 2013, 12 midnight: All students mail their teams to and . Remaining students will be assigned partners.
  • Revisions to Medication Screen: Changes to medication screen in order to organize drugs according to MSHV and OpenEMR.
  • Additions to Medication Screen: For each medication, still allow a display of its data, but in the case of OpenEMR, this must be read-only since they cannot be changed (not written back).
  • FDA Daily Meds: Each medication on the new screen should also have the ability to call the web services for FDA Daily meds and show the resulting information in a new screen.
  • New Medication Checking Screen: This can be initiated off of the revised medication screen and will take the combined list of meds (from MSHV and OpenEMR) and return a list of meds and their interactions.
  • Usage of External Web Services: Utilize web services for FDA Daily Meds, RxNorm, RxTerms, and/or NDF-RT as relevant to your specific needs and approach.

Note: Expect emails and information in both the lab and the lecture over the remainder of the semester.

1