Pimm – Partial immortalization

A Biotech Geek (micro)Blogger’s adventures through science, technology and the web…

  • email me

    [attilacsordas][at][gmail.com]
  • Attila on Twitter

  • Recent Comments

    Game on Systemic regmed
    Game on About
    Game on bioDIY
    games on Laboratory Website Awards
    xn--12c8d1a4fxc on Laboratory Website Awards
    game on Skills
    game on References
    game on Skills
    เรื่องเสียว on About
    สินเชื่อ on Skills
  • licence

    Creative Commons License
  • c

  •  

    May 2008
    M T W T F S S
    « Apr   Jun »
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  

Late Google Health: catching up with the past, first!

Posted by attilacsordas on May 20, 2008

People expect usually too much from Google even in the sectors, like biotechnology or medicine where Google is not native. For me the recent Google Health – which is basically an embryonic online medical health record system for users with a Gmail Account in the USA – seems to be rather about just catching up with the past than doing the future right now. That is not a criticism but rather a description. Storing/exchanging/updating individual medical records digitally is a “must-have-done-by-now” for the geeks, early technological adopters as the technology long exists, while it is still far-far away concerning current medical practices.

Google Health is really forward thinking in the way that it facilitates medical consumers/patients to upload their medical profile/conditions in the lack of institutional data thereby getting more familiar with everything health related.
But Google Health is for the more or less healthy/mainstream and not for the seriously ill: in its recent form it cannot help to find a clinical trial for a rare disease, say.

Wired’s Betsy Schiffman writes:

For the moment, Google Health looks like a charity operation. The company won’t serve ads on the site (presumably to avoid the appearance of impropriety); nor does it plan on selling data, which would likely be extremely lucrative.

Instead, the company is focused on building out the service and growing market share. That’s a good thing, say industry watchers, because it could take years before the market matures and consumers are ready for the digital health revolution.

Yep, it is still too early and building a critical mass is a crucial thing. It is so early that most of the angles remain hidden in obligatory posts on Google Health. I suggest to read the detailed & insightful comments, for instance this one at TechCrunch by Fred Neil:

Personal Health Records, PHR’s, have been getting a fair amount of attention over the past few years. There is legislation requiring physicians to have all medical records available in an electronic format, Electronic Medical Records or EMR, by 2010. The big challenge is inter-operability in which physicians will be able to exchange data with patients so that patients can maintain their own PH R PURL. This is awesome for data portability, i.e. having your medical data available on a PURL and/or handheld when traveling rather than having to fill out ridiculous medical forms. This is all great in theory, but we are years if not decades away from consumer adoption and sufficient standards for nomenclature and fields used for medical data. I have learned much about this over the past year in a stealth start up I just put on the shelf w too many landmines and resistance. It will happen some day, just not soon.

4 Responses to “Late Google Health: catching up with the past, first!”

  1. [...] Google Health: No Ads, Lots of Partners (and more to come), Matt C., MarketIntellNow, 20 may 2008 Late Google Health: catching up with the past, first!, >Pimm – Partial immortalization, 20 May [...]

  2. tar said

    электронная почта без регистрации

  3. So what can we, readers, benefit from Google Health? Will they going present more health tips?

  4. Soft-updates is an alternative to this scheme where the filesystem keeps a list of dependencies that must be satisfied before a change to the filesystem can be visible on disk. For example, you wouldn’t want to write a directory entry pointing at an inode until the inode was initialized on disk and marked allocated. Softdep handles this by rolling back changes to metadata that don’t yet have their dependencies satisfied when we try to write a block. In this way we can commit any completed ‘transactions’ while keeping the disk state consistent. Softdep also allows these dependencies to discover operations which cancel each other out and thus nothing makes it to disk. For example, let’s say you create a temporary file and then remove it after writing some blocks, which compilers often do, if it all happens within the interval of the syncer nothing will make it to disk.

Sorry, the comment form is closed at this time.

 
Follow

Get every new post delivered to your Inbox.

Join 38 other followers