Hi Paul, Data integrity is surely a critical issue when developing health software, and for sure the case in which a user submit wrong details is a problem. Still, I believe different approach other than limiting the permissions should be deployed.
One example, if I may, can be taken from HealthVault. While their solution is not 100% as well, the way of saving full history of changes in every detail, including who changes what and when (as if it was health "version control" with revisions, etc.) can be more useful, from my point of view. The current situation of different permissions of clientLogin vs. OAuth or AuthSub is something I don't understand as well. Nowadays, when everybody wants SAAS, it sounds strange that desktop applications can do things that web applications can't. Any special reason for that limitation ? All in all Google Health is good and with big potential service, but if I compare it to other Google services, it seems to lack many critical things to make it ahead of other similar services. I would love to see Google Health as good as Google Calendar or GMail in their region. Regards, Shushu On 24 מאי, 21:33, "Paul (Google)" <[email protected]> wrote: > Hi Shushu, > > The rationale for why Health doesn't allow users to modify provided > information is that it's critical to retain the integrity of the data > source attribution. When data is entered into a user's profile by a > third party (e.g. by a pharmacy or health care provider), their > profile will show the name of the data provider under the "Received > from" header. In addition, this attribution is included in exported > CCR records as Actor elements included with the provided information. > If it were possible for a user to modify provided information, it > would not be appropriate to maintain the attribution. For example, if > a pharmacist reported that a patient was prescribed a particular > medication, and the user changed the dosage or frequency in their > profile, Health could no longer attribute the pharmacist as the data > provider for the prescription. > > I hope this clarifies Health's current model for maintaining > attribution. We absolutely love to hear about alternate uses for > Health from a "data integrator" standpoint. Please don't hesitate to > let us know what your intended use is, and how Health might evolve to > support it! > > Paul (Google) > > On May 23, 1:52 am, shushu <[email protected]> wrote: > > > > > > > Clarify this helps, but it is a bad situation for my development. > > There are many logical scenarios where the user should be able to > > update the information, and I can't understand why those limitations > > were defined as they are. > > > On 8 מאי, 01:11, "Paul (Google)" <[email protected]> wrote: > > > > One more note, Shushu! If you're sending the data to Health using > > > AuthSub or OAuth, the user will not be able to change the information > > > sent, they will only be able to delete the medication or add notes. > > > If you've requested read/write access for your application, however, > > > you will be able to retrieve/sync user-entered medications. I hope > > > this helps! > > > > Paul (Google) > > > > On May 7, 2:16 pm, "Paul (Google)" <[email protected]> wrote: > > > > > That's perfectly correct; thanks for pointing this out, Gilad! Health > > > > does allow free-text data to go into Direction/Frequency/Value; > > > > however, it would be more appropriate, according to the CCR spec., to > > > > put free-text frequency information into Direction/Frequency/ > > > > Description/Text. > > > > > So the three options are as follows: > > > > > Direction/Description//Text: not currently shown in UI, but ideal for > > > > prescription directions (sig) > > > > Direction/Frequency/Value: can be free text, shows in the UI, but a > > > > controlled term (e.g. "1 dose per day") would be preferred > > > > Direction/Frequency/Description/Text: is free text, shows in the UI; > > > > however, is only visible if Frequency/Value is not set > > > > > So for maximum CCR portability, using the first two of the above would > > > > be the best choice. However, if you need the user to see the > > > > frequency and direction information now, using the third option would > > > > likely be best. > > > > > Paul (Google) > > > > > On May 5, 3:22 pm, gilad <[email protected]> wrote: > > > > > > Direction/Frequency/Value is just a string. it is not restricted to > > > > > the suggested values > > > > > fromhttp://code.google.com/intl/iw/apis/health/ccrg_reference.html#frequency > > > > > > You can put there any string and it will show as the frequency value > > > > > in the Google Health UI. > > > > > > Gilad > > > > > > On May 3, 11:08 pm, Shushu Inbar שושו ענבר <[email protected]> wrote: > > > > > > > Hello Paul, > > > > > > Thanks for the suggestion. > > > > > > This gives a solution for keeping values in Google Health, but > > > > > > won't be > > > > > > useful for allowing users to set the values by themselves in Google > > > > > > Health. > > > > > > Our goal is to keep the sync between our system and Google Health > > > > > > 100% > > > > > > accurate all the time, and to make irrelevant which tool was used > > > > > > to set the > > > > > > information. > > > > > > > I will implement your solution. > > > > > > Any ideas on how to solve this problem, or how to workaround it ? > > > > > > > Regards, > > > > > > Shushu > > > > > > > On Tue, May 4, 2010 at 04:09, Paul (Google) <[email protected]> wrote: > > > > > > > Hello Shushu, > > > > > > > > Thanks for the questions; they're good ones! The "notes" section > > > > > > > in the UI > > > > > > > is meant for users to add personal notes to their profile about > > > > > > > an entry > > > > > > > (e.g. "this med made me drowsy, don't take before driving"), and > > > > > > > it is > > > > > > > therefore not available for external systems to use. Presently, > > > > > > > the best > > > > > > > approach to entering medication frequency and additional notes > > > > > > > (prescription > > > > > > > SIG) is to pass the frequency into Direction/Frequency/Value, and > > > > > > > the notes > > > > > > > in as Direction/Description/Text. These notes presently won't be > > > > > > > visible to > > > > > > > the user; however, they will be stored with the user's profile > > > > > > > and can be > > > > > > > retrieved. The Health team is aware that this information is > > > > > > > potentially > > > > > > > useful to the user and would be good for them to see it in the UI. > > > > > > > > Thanks again! > > > > > > > > p...@google > > > > > > > > On Mon, May 3, 2010 at 2:26 AM, shushu <[email protected]> wrote: > > > > > > > >> Hello, > > > > > > > >> The application I am working on syncs between medications in > > > > > > >> different > > > > > > >> systems and Google Health. > > > > > > > >> In the "How Often" field > > > > > > >> (Medication/Directions/Direction/Frequency/ > > > > > > >> Value) the relevant values I need are "1 time per day in the X". > > > > > > > >> According to > > > > > > >>http://code.google.com/intl/iw/apis/health/ccrg_reference.html#frequency, > > > > > > >> the possible values are defined by SNOMED, which doesn't cover > > > > > > >> all of > > > > > > >> the options I need. > > > > > > > >> The solution I thought about is to select "1 time per day", and > > > > > > >> to use > > > > > > >> the "notes" field with proper formatting to cover the values I > > > > > > >> don't > > > > > > >> have. > > > > > > > >> Unfurtunately, it seems that there is no way via the existing > > > > > > >> API to > > > > > > >> get/set the notes field. > > > > > > > >> Is this correct ? > > > > > > >> Are there any other solutions ? > > > > > > >> Do you plan to enable get/set of notes in the upcoming future ? > > > > > > > >> Regards, > > > > > > >> Shushu > > > > > > > >> -- > > > > > > >> You received this message because you are subscribed to the > > > > > > >> Google Groups > > > > > > >> "Google Health Developers" group. > > > > > > >> To post to this group, send email to > > > > > > >> [email protected]. > > > > > > >> To unsubscribe from this group, send email to > > > > > > >> [email protected]<googlehealthdevelopers% > > > > > > >> [email protected]> > > > > > > >> . > > > > > > >> For more options, visit this group at > > > > > > >>http://groups.google.com/group/googlehealthdevelopers?hl=en. > > > > > > > > -- > > > > > > > You received this message because you are subscribed to the > > > > > > > Google Groups > > > > > > > "Google Health Developers" group. > > > > > > > To post to this group, send email to > > > > > > > [email protected]. > > > > > > > To unsubscribe from this group, send email to > > > > > > > [email protected]<googlehealthdevelopers% > > > > > > > [email protected]> > > > > > > > . > > > > > > > For more options, visit this group at > > > > > > >http://groups.google.com/group/googlehealthdevelopers?hl=en. > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > > > Groups "Google Health Developers" group. > > > > > > To post to this group, send email to > > > > > > [email protected]. > > > > > > To unsubscribe from this group, send email to > > > > > > [email protected]. > > > > > > For more options, visit this group > > > > > > athttp://groups.google.com/group/googlehealthdevelopers?hl=en. > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "Google Health Developers" group. > > > > > To post to this group, send email to > > > > > [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]. > > > > > For more options, visit this group > > > > > athttp://groups.google.com/group/googlehealthdevelopers?hl=en. > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Google Health Developers" group. > > > > To post to this group, send email to > > > > [email protected]. > > > > To unsubscribe from this group, send email to > > > > [email protected]. > > > > For more options, visit this group > > > > athttp://groups.google.com/group/googlehealthdevelopers?hl=en. > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Google Health Developers" group. > > > To post to this group, send email to > > > [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]. > > > For more options, visit this group > > > athttp://groups.google.com/group/googlehealthdevelopers?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Health Developers" group. > > To post to this group, send email to > > [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/googlehealthdevelopers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Google Health Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at... > > קרא עוד » -- You received this message because you are subscribed to the Google Groups "Google Health Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/googlehealthdevelopers?hl=en.
