I met with some people from the team to discuss some of the particulars that I mentioned in my last blog post.
First off, although Apple is apparently providing a centralized space for developers to talk to each other, they are not really providing a set infrastructure for the data to be set to "talk" to each other.
While some tools are being provided, such as tools that can convert metric units into english, so for example someone's height can be given in inches or centimeters using Apple's tools, apparently there is no set rules or conventions for any fields.
My concern is that this could just lead to a big giant mess of data that is inefficient and will lead to programming redundancy in labor.
For example let us suppose that patient data is stored in the following spreadsheet
First off, although Apple is apparently providing a centralized space for developers to talk to each other, they are not really providing a set infrastructure for the data to be set to "talk" to each other.
While some tools are being provided, such as tools that can convert metric units into english, so for example someone's height can be given in inches or centimeters using Apple's tools, apparently there is no set rules or conventions for any fields.
My concern is that this could just lead to a big giant mess of data that is inefficient and will lead to programming redundancy in labor.
For example let us suppose that patient data is stored in the following spreadsheet
The A column could represent the patient's first name, the B column could represent the patients last name C could represent the birth date, D could represent their age, E could represent their height and so on.
I believed that this new system of integrating health records would mean that information would now exist in one central easy to access spreadsheet. However this does not seem to be the case.
After speaking with Misael it is apparently the case that each app will be collecting their own data, and then programmers will have to tie in data from other apps via either data mining of some sort using search queries, or through paid access done through apple or google servers.
This does not seem efficient. Furthermore access to the database can cause different input errors as for example 5'0" may read as 5 feet 0 inches by one program, but 50 inches by another program. When we're talking about health the results can be disasterous! Even deadly!
I think it would be a great thing if programmers could get together and agree on some kind of unified coding scheme and database standards. This would also save a lot of redundancy as in terms of staff work as code would not have to be developed to mine for information but could just be programmed to go to a certain location in the database for info. Operational server side costs of time and electrical energy would also be saved as additional search operations running acrost the whole database could be avoided. As time goes on the amount of data will surely just grow and grow and grow, and it is important to build an efficient and expandable system to address these issues.
I'm excited that I've just started seeing a computer programmer, whom I'll call, "L" and our discussions on this topic should be pretty lively. We've already discussed the need for such a project, so it's interesting to continue discussion on this topic with a professional in the field of computing. She probably has much more experience with database management.
The coolest thing is that we are one of the pioneers in this field and have a chance to really set the bar and determine the standards in this newly developing field!
BUT returning to the original point of this post, I was exploring this topic originally to compare the feature set of Apple Healthkit vs. Google Fit. It seems that there is no limit to the number of fields that a programmer can utilize to interact with Healthkit.
It's generally agreed between people that I speak to that these apps will be speaking to each other and that developers are already planning on building cross platform. Due to the sensitivity of patient data, the data will have to be stored on secured servers, and the cost of maintaining this security is supposed to be a hugely profitable field.
Honestly I'm a big fan of open source in it's spirit and execution, and I'd love to see this problem addressed with as little cost as possible for the end users. While I understand the need for proprietary databases to keep venture capital around to fund these projects, I'd really like to find a way to make things more efficient and to bring costs down.
REVIEWING THE APP
On the initial screen I see the face.
The nose is HUGE. aesthetically a large nose is comical... clown like. Perhaps a smaller pie chart with a larger 2 of 4 completed underneath?
Now I'll cover each individual application piece from the top to the bottom... left to right.
QUALITY OF LIFE
The first box labeled Quality of Life (3 months) is confusing because I see 5 circles although it says three months. If the line between two circles represents a month then there is either an extra month or the data is being divided in some unintuitive way. If data is being mapped to 5 measurements taken over 3 months, then this is just confusing.
When I open up the Quality of Life box I see a graph with many lines all over the place. I find the graph confusing and if I was really sick I would feel anxious.
Here are the issues that I felt were of the most concern:
1. On the graph I see a lot of vertical lines. This means that on a given date my quality of life was at once good and bad. I'd rather just see a single line that I could understand. I'd rather have simplified information that I can understand, then a wealth of information that is confusing.
2. The graph is filled with specific dates. Rather then labeling each individual date it would be good to choose a less cluttered view.
3. Quite a few questions (out of the 10 questions given questions 1, 5, 8, and 10) are, "state of mind" questions. Or questions that ask a patient to identify their mood. However psychology studies show that when someone is currently feeling happy or sad it can affect their ability to accurately access their overall mood over a previous time period. On the other hand I liked questions 2,3,4,6,7, and 9 because I felt that these questions were much more specific and able to answered in a more accurate way.
I was unable to get the following questions to correctly record a response. 1,2,6,9,10.
After finishing the questions I received a score of 35 which is, "Fair." I was then prompted that if my score was 50 or above or increased by 5 or more that I should notify my health provider.
I think it would be a good thing for the health provider to be automatically notified. I'm not sure if this is able to be done due to patient privacy rights, but if this is the case then I feel like we should inform the patient of this phenomenon so that they are not thinking that the program is forcing them into an unnecessary sequence of actions. Also once patients realize that by modifying the answers to their "state of mind" questions can alter their final score, they may start to answer questions in a way not to achieve the goals of the application but to achieve a desired score.
On the Symptoms screen which is the "Left eye" of the application, there is a sequence of questions that are to be answered. The frequency of BM's is obviously bowel movements, but should be clarified as this abbreviation may not be readily apparent for users.
The Checklist of Care once again arbitrarily seems to mention 3 months. This is good because it's a quarter, but it would be nice to be able to visit past quarters.
Also the answer choices of Unmet, met, N/a, and Don't know aren't very clear. Measuring bone density doesn't seem like something that will happen very often and filling out n/a as the first choice again and again seems like it will lead towards patients eventually just skipping the whole section. It also seems inappropriate to constantly prod the patient for something that happens like a YEARLY colonoscopy, or to address HPV if they are innoculated. If certain things have been addressed, then these pieces should be disabled (yet the patient should still see that they are getting credit for these activities and see that it is positively impacting their score)
Getting down to the smile section of the health promise application once again we have a (3 months) informational prompt which seems redundant.
I know we are going off the idea of a gas gauge which is easy to read, however the red is scary. I'm assuming that less hospital and ER visits is good, so we could perhaps label the gauge with a *good* on the red side and a *bad* on the green side if this is what that means to make things crystal clear. If "bad" is something we are trying to avoid (because do we really want to tell patients that they are "bad?") then we could say more visits (better) or less visits (needs attention.) I would include the better and needs attention pieces just to make things very clear as to which side is good or bad.
In the app part that opens when they click on this button the patient is asked to make calls such as whether or not their hospital visit was related to their Crohn's disease. Is the patient qualified to make this decision? I'm also thinking that it would be nice if the patient could store photos of their hospital documentation and doctor's notes at this point. Perhaps we can add this functionality.
Also I noticed that there is a spelling mistake in the "Have you recently experienced" part of the app. In the Hospitalized section the word "Admitted" is misspelled as "Adimitted" and the word "Released date" is grammatically incorrect and should be switched out to the word, "Release date"
MEETING ANOTHER MEMBER OF THE TEAM and VIDEO MEETING UPDATE
I did not know this but Sameer who is our advisor is a graduate of Hunter College! Our lineup is very heavy with Hunter College students. I find this pretty cool. During our meeting we discussed some of the upcoming instructional videos that would be made for users. This means instructional videos and an explanatory video. I had some ideas about pitching the product which members of the team found helpful and I look forward to contributing towards this part of the project with my sales experience. At this meeting I got to meet Flo, and work with Pascal in a more professional setting as we got to wrap our heads around some actual production work. Thank goodness! I can't wait to start producing some real product!
We've got a target production date of July 20 something... I'd like to make sure that I'm finished contributing whatever I need for the product by the 20th to give Pascal time to piece whatever he needs together. I'll ask him as the project progresses if he needs an extra hand.
Thanks to Jason I was pointed out to a couple of different already existing GI apps such as GI Buddy which can be downloaded and previewed here.. Next week I plan on examining these apps further in depth as well as to examine their instructional video pieces to get better ideas on how to proceed with this project so I am not working in a vacuum, but rather standing on the shoulders of others efforts. Jason also recommended 22 otters as an example of other videos and Patients like me which has been referenced in Jeremy's blog from last year. I'll be sure to check those out as well.
I believed that this new system of integrating health records would mean that information would now exist in one central easy to access spreadsheet. However this does not seem to be the case.
After speaking with Misael it is apparently the case that each app will be collecting their own data, and then programmers will have to tie in data from other apps via either data mining of some sort using search queries, or through paid access done through apple or google servers.
This does not seem efficient. Furthermore access to the database can cause different input errors as for example 5'0" may read as 5 feet 0 inches by one program, but 50 inches by another program. When we're talking about health the results can be disasterous! Even deadly!
I think it would be a great thing if programmers could get together and agree on some kind of unified coding scheme and database standards. This would also save a lot of redundancy as in terms of staff work as code would not have to be developed to mine for information but could just be programmed to go to a certain location in the database for info. Operational server side costs of time and electrical energy would also be saved as additional search operations running acrost the whole database could be avoided. As time goes on the amount of data will surely just grow and grow and grow, and it is important to build an efficient and expandable system to address these issues.
I'm excited that I've just started seeing a computer programmer, whom I'll call, "L" and our discussions on this topic should be pretty lively. We've already discussed the need for such a project, so it's interesting to continue discussion on this topic with a professional in the field of computing. She probably has much more experience with database management.
The coolest thing is that we are one of the pioneers in this field and have a chance to really set the bar and determine the standards in this newly developing field!
BUT returning to the original point of this post, I was exploring this topic originally to compare the feature set of Apple Healthkit vs. Google Fit. It seems that there is no limit to the number of fields that a programmer can utilize to interact with Healthkit.
It's generally agreed between people that I speak to that these apps will be speaking to each other and that developers are already planning on building cross platform. Due to the sensitivity of patient data, the data will have to be stored on secured servers, and the cost of maintaining this security is supposed to be a hugely profitable field.
Honestly I'm a big fan of open source in it's spirit and execution, and I'd love to see this problem addressed with as little cost as possible for the end users. While I understand the need for proprietary databases to keep venture capital around to fund these projects, I'd really like to find a way to make things more efficient and to bring costs down.
REVIEWING THE APP
On the initial screen I see the face.
The nose is HUGE. aesthetically a large nose is comical... clown like. Perhaps a smaller pie chart with a larger 2 of 4 completed underneath?
Now I'll cover each individual application piece from the top to the bottom... left to right.
QUALITY OF LIFE
The first box labeled Quality of Life (3 months) is confusing because I see 5 circles although it says three months. If the line between two circles represents a month then there is either an extra month or the data is being divided in some unintuitive way. If data is being mapped to 5 measurements taken over 3 months, then this is just confusing.
When I open up the Quality of Life box I see a graph with many lines all over the place. I find the graph confusing and if I was really sick I would feel anxious.
Here are the issues that I felt were of the most concern:
1. On the graph I see a lot of vertical lines. This means that on a given date my quality of life was at once good and bad. I'd rather just see a single line that I could understand. I'd rather have simplified information that I can understand, then a wealth of information that is confusing.
2. The graph is filled with specific dates. Rather then labeling each individual date it would be good to choose a less cluttered view.
3. Quite a few questions (out of the 10 questions given questions 1, 5, 8, and 10) are, "state of mind" questions. Or questions that ask a patient to identify their mood. However psychology studies show that when someone is currently feeling happy or sad it can affect their ability to accurately access their overall mood over a previous time period. On the other hand I liked questions 2,3,4,6,7, and 9 because I felt that these questions were much more specific and able to answered in a more accurate way.
I was unable to get the following questions to correctly record a response. 1,2,6,9,10.
After finishing the questions I received a score of 35 which is, "Fair." I was then prompted that if my score was 50 or above or increased by 5 or more that I should notify my health provider.
I think it would be a good thing for the health provider to be automatically notified. I'm not sure if this is able to be done due to patient privacy rights, but if this is the case then I feel like we should inform the patient of this phenomenon so that they are not thinking that the program is forcing them into an unnecessary sequence of actions. Also once patients realize that by modifying the answers to their "state of mind" questions can alter their final score, they may start to answer questions in a way not to achieve the goals of the application but to achieve a desired score.
On the Symptoms screen which is the "Left eye" of the application, there is a sequence of questions that are to be answered. The frequency of BM's is obviously bowel movements, but should be clarified as this abbreviation may not be readily apparent for users.
The Checklist of Care once again arbitrarily seems to mention 3 months. This is good because it's a quarter, but it would be nice to be able to visit past quarters.
Also the answer choices of Unmet, met, N/a, and Don't know aren't very clear. Measuring bone density doesn't seem like something that will happen very often and filling out n/a as the first choice again and again seems like it will lead towards patients eventually just skipping the whole section. It also seems inappropriate to constantly prod the patient for something that happens like a YEARLY colonoscopy, or to address HPV if they are innoculated. If certain things have been addressed, then these pieces should be disabled (yet the patient should still see that they are getting credit for these activities and see that it is positively impacting their score)
Getting down to the smile section of the health promise application once again we have a (3 months) informational prompt which seems redundant.
I know we are going off the idea of a gas gauge which is easy to read, however the red is scary. I'm assuming that less hospital and ER visits is good, so we could perhaps label the gauge with a *good* on the red side and a *bad* on the green side if this is what that means to make things crystal clear. If "bad" is something we are trying to avoid (because do we really want to tell patients that they are "bad?") then we could say more visits (better) or less visits (needs attention.) I would include the better and needs attention pieces just to make things very clear as to which side is good or bad.
In the app part that opens when they click on this button the patient is asked to make calls such as whether or not their hospital visit was related to their Crohn's disease. Is the patient qualified to make this decision? I'm also thinking that it would be nice if the patient could store photos of their hospital documentation and doctor's notes at this point. Perhaps we can add this functionality.
Also I noticed that there is a spelling mistake in the "Have you recently experienced" part of the app. In the Hospitalized section the word "Admitted" is misspelled as "Adimitted" and the word "Released date" is grammatically incorrect and should be switched out to the word, "Release date"
MEETING ANOTHER MEMBER OF THE TEAM and VIDEO MEETING UPDATE
I did not know this but Sameer who is our advisor is a graduate of Hunter College! Our lineup is very heavy with Hunter College students. I find this pretty cool. During our meeting we discussed some of the upcoming instructional videos that would be made for users. This means instructional videos and an explanatory video. I had some ideas about pitching the product which members of the team found helpful and I look forward to contributing towards this part of the project with my sales experience. At this meeting I got to meet Flo, and work with Pascal in a more professional setting as we got to wrap our heads around some actual production work. Thank goodness! I can't wait to start producing some real product!
We've got a target production date of July 20 something... I'd like to make sure that I'm finished contributing whatever I need for the product by the 20th to give Pascal time to piece whatever he needs together. I'll ask him as the project progresses if he needs an extra hand.
Thanks to Jason I was pointed out to a couple of different already existing GI apps such as GI Buddy which can be downloaded and previewed here.. Next week I plan on examining these apps further in depth as well as to examine their instructional video pieces to get better ideas on how to proceed with this project so I am not working in a vacuum, but rather standing on the shoulders of others efforts. Jason also recommended 22 otters as an example of other videos and Patients like me which has been referenced in Jeremy's blog from last year. I'll be sure to check those out as well.
Social media research!
I've also been asked to do a short research piece on the top 10 social media companies. I want to coordinate this with Yathin whom I'll have to catch up with. Hopefully we don't retread the same ground, but can perhaps coordinate an examination from different angles to provide more depth in our coverage.
RSS Feed
