Sprint 5 was a continuation of sprint 4. Again, we started sprint 5 by reviewing what was done in the sprint 4, particularly our achievements and failures. As a matter of fact, we revisited pouchdb to make sure that we have it installed and running in everybody PC. This success in Sprint 4 has helped us very much in continuing to explore ways of capturing the offline data. In Sprint 5, there were no any interruptions and the team was able to do our regular team meetings without any interference. I will say Sprint 5nwas very effective in terms of meetings and discussions. We were able to hold effective discussions, coming up with some ideas and also explaining to each other what we meant by the ideas we came up with. I will personally give credit to Rick Phillips for offering those pieces of advice. His advice has been very informative and that has helped the team a lot in doing and understanding our work. Jason has also been doing well in integrating those ideas we came up with and the advice offered by Rick Phillips into code.

Again, for our offline data capture task, even though, the idea of using local storage system was established in the previous sprint, the team was still unsure of if the pouchdb I have been preaching on since day one will work for us. But now, I can authoritatively say that the team is confidence that we could capture the data remotely using pouchdb based on our further experiments. As usual, we continue to and will still do more research on pouchdb to gain insight of how we can possibly capture the data; we continued to dig deeper into pouchdb by learning more tutorials of how to synchronize data between two servers. One of the major problems we were facing in our data capturing task was getting the data. We could initially write a dummy data into the pouchdb but we wanted to capture the data from the AMPATH database. By Rick advice, we were able to search for data through the patient database of the AMPATH and store it into an array which we could iterate through to store each into separate files in pouchdb.

Besides, at this point, we look close to getting the task done but still face some problems. We are not completely sure of what need to be sync back. I personally suggested to the team that I think the ideal way is to synchronize just the differences. I will prefer we are able to add a function that checks for difference and synchronize that to the database than synchronizing the whole data captured remotely including the old that was retried while going offline. I also think it will not be useful for the doctor to have a whole bunch of data that he/she doesn’t need and I think we should be able to come up with away that the doctor could filter the data down to just what he/she need at the time when he/she is going offline. This also led us to haven to design a GUI for the doctor. With regard, I created an abstract ER Diagram with three entities; thus the Doctor, Appointment and Patient, showing how the relationships and cardinalities. Rick and I are now waiting to kickoff with design for the GUI when we are clear of the filed they want us to include.

In summary, I would say this Sprint has been very interesting due to the enthusiasm and passion that we put into work. I believed if the team keeps up with this enthusiasm, we would definitely get the work done. I also think the work sharing that has been listed on trello board will also help keeps everyone busy.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

This sprint we finished our prototype API and had it approved by Ampath.  We also started working through the implementation details for our service as a group.  Finally, we figured out how to repair our local versions of the app and get our group repository in synch with Ampath’s master branch so that we can implement our API over the next sprint.  I learned how to coordinate with other teams to build an API, and how to implement password hashing and data encryption.

I think the biggest takeaway for me this sprint was how to coordinate with other teams on a project to write an API for them to use, and how to integrate details of their implementations into my team’s work.  Because we’re providing a “background” service for the other teams, they can work for now assuming that our service will do what it’s supposed to.  However, this means that we need to understand some details of their implementations so that we can provide them with what they need.  Given the speed with which the semester is coming to a close, the encryption service may not be integrated into other services or components this year.  However, we hope to have something that’s usable for Ampath or another group working on this project to take over in the future.

Our biggest job this sprint was to work on our service’s public API.  We did this primarily through team work periods in class.  This followed a roughly three-step process, which we repeated until we believed our API was in a state where we could send it to Ampath for approval.  First, we spoke with another team to get a handle on their requirements for our service.  Second, we wrote a set of function signatures that we believe filled those requirements.  Third, we discussed implementation of those functions and what other private functions we might need to implement them, as well as which parts of the Crypto-JS API we want to use.

One of the biggest parts of this discussion was to figure out how we want to derive private keys and store hashes in order to provide the best compromise between security and usability.  For password hashing, we decided to store a hash derived from the password with salt derived from the username and timestamp of the offline session creation.  This will be stored with the username in-browser, by the offline login team’s code.  For private key derivation and storage, we spoke with Ampath and agreed on temporary private key storage for the duration of a login session (the key will be generated from the password using a password-to-private-key function and stored in a file that is deleted on logout).  While not optimally secure, this allows encryption/decryption of data without requiring password entry for each data operation.

We followed Jason Knowles’ intructions to rebuild our apps, and used git to update our team repo with Ampath’s latest changes.  For next sprint, our job is to implement and test as much code as we can manage.

I think our team coordination could have been better this week.  It felt like a lot of what we were doing didn’t engage the entire team, although I’m not sure how to manage that better.  Not everyone was present for each work day for varying reasons, although we did keep in touch on Slack we could also probably have kept better notes to send to absent team members.  I think dividing up labor will be easier next sprint since we have actual code to work on.  We will have to make sure we keep our repositories synched, as we don’t have a ton of practice with that.

From the blog CS@Worcester – orscsblog by orscsblog and used with permission of the author. All other rights reserved by the author.

This sprint was not a complete success. We wanted to have some code pushed and maybe make a pull request to AMpath. However, our progress was delayed due to our inexperience in writing angular 2 methods and testing them effectively. I learned that testing code in a language you haven’t studied can be exceptionally difficult to grasp. I am still trying to work out the uses for toBe(), toThrowError(), toEqual(), and how the expect works in the test suite. Writing the method for the code seemed easy enough and I think I have the correct code, however it is hard to confirm when testing isn’t going smoothly. I understand that writing tests first would have been the correct way to do this, but I can’t write tests for code that I don’t know how to write. Therefore, I had to learn how the code worked and look at the API for pouchDB (which you can find here https://pouchdb.com/api.html) to ensure that I was using the correct calls and what-not. If I could restart this sprint, I would spend much more time on learning how to test in angular (sense that is the most frustrating part to me) rather than writing the code. At first, I was coding a method that was too complex, with the help of google I was able to finish my updateDoc method (as far as I know).

Our team is working well together, I think we could do a little bit better helping each other remember to do our standups and evaluations. Besides that we work really well together. I think we are all contributing equally to the project, so there is no problem there. As a team we feel as though we could have gotten this sprint completely finished in the allotted time if we had prior knowledge of testing in angular. However, it is what it is. Our next sprint will most likely focus around testing the methods we have created and tweak them to try to perfect them.

Our sprint plan was to finish this module, obviously that didn’t happen. Each of us was responsible for writing a method and Connor was responsible for testing. I wouldn’t blame Connor for the tests not being done because he still has to learn the testing procedures for angular as well and if he has to write a test for each of our methods, that is bound to take some time. So each of us has been pitching in and trying to debug together. This means that our sprint goal will most likely be extended to next sprint as this really is the last step to finishing off the Offline Storage Module.

I am interested to see what will happen when we (our entire class) conglomerates the code and tries to piece it together. I can imagine that some snags will occur and it won’t be very smooth at all. We will have to assign different people to test different parts of the entire offline module to ensure that everything is compatible with each other.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

As Sprint 5 comes to a close, I believe we are making great progress. Our team’s primary goal is to have a completely functional data capturing service for offline purposes. With the achievements made during this sprint, it seems very realistic that we will have a working module by the end of this semester.

Our main objectives for Sprint 5 were the following:

1.  Decide what would be the most useful data to capture.
2.  Capture raw data to be stored into PouchDB.
3.  Construct ideas presenting captured data in a meaningful way.
4.  Improve cross-team communication.

Deciding what would be the most useful data to capture:
We all agreed that we should begin to focus on storing detailed patient data. Internet connectivity is often unreliable where the AMPATH app is intended on being used. We want to allow medical providers to have offline access to patient data when a given patient is expected to be seen.

Capturing raw data to be stored into PouchDB:
I believe we have made substantial progress concerning this task. We were able to use OpenMRS services (located in the ./src/app/openmrs-api folder) to help us achieve our intended goals.

Originally, we were able to capture data of some 200 patients having the word “test” in their names. This was a great starting point, but we knew we needed to improve upon our results. First, the data was being captured and stored into one large file. This contrasted with our intended capability of having each patient object being stored in its own file. Second, the data being captured was only basic patient information, such as name and address. We wanted to also include more detailed criteria, such as upcoming appointments and other patient encounters.

Initially we were using the PatientResourceService.searchPatient('test') function to capture a given array of patients. We were taking the results from the returned Observable and storing it into PouchDB. The problem we were having was figuring out a way to iterate through these results so we could store each patient in an individual file. Ultimately, we were able to achieve this by using the JavaScript lodash ability. By importing lodash in our component, we were able to use _.each to iterate through the subscribed results from the returned Observable in an array-like fashion. 

Our next step was to try to figure out a way to store patients other than those with “test” in their name. Further, we wanted to capture more meaningful information about the patient (appointments, encounters, etc).

Ultimately, we were able to manipulate an existing component, located in ./src/app/patient-dashboard/common/patient-encounters/patient-encounters.component.ts, to store a patient’s detailed data in PouchDB when it is searched for.

Presenting the captured data in a meaningful way:
This is a topic discussed in great detail during our last working class during Sprint 5. Ultimately we need to decide how we are going to present this to the user. We anticipate the user will be a provider, such as a doctor looking for information about patients to be seen. We are in the process of constructing a mock diagram for a GUI to view and manipulate the captured data.

Improving cross-team communication:
I feel we have made some progress in this area. We seem to have a general idea what everyone is working on. But at the same time, there is definitely room for improvement regarding our communication with other teams. We anticipate a lot of cross-team collaboration in the upcoming sprint. Since all teams are finishing up their work, we need to make sure all implementations are compatible with each other. For this reason, I am confident our cross-team communication will continue to improve during our next sprint.

Overall:
I believe this was an effective sprint. We’ve all done a good job letting each other know what we’re currently working on. I had a lot to do with implementing the offline capturing abilities, but this was only possible due to the support and input from all of my teammates. Regarding participation during this sprint, I think we’ve all done our fair share.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.