1. Create a new Google Apps Spreadsheet.
2. In the new spreadsheet goto the Tools -> Script Editor to open the script editor.
   
3. Copy the script from here to your clipboard.
4. Paste the script into the Script Editor window.
   
5. Save the script by selecting File -> Save.
   
6. Enter CloudConnector as a name for the script.
   
7. The script needs to be authorized before it can be run.  Select and run the onOpen function from the functions dropdown.  This will activate the authorization dialog.
   
8. Click the Authorize button to authorize the script.
   
9. Rerun the onOpen function to add the CloudConnector menu to the Google spreadsheet.
   
10. Close the Script Editor window.
11. Click the Settings menu item in CloudConnector menu to activate the Settings window.
    
12. Enter your Username, Password and Security Token for the Salesforce org.
    
13. Click Login in the CloudConnector menu to login to your Salesforce org.
    
14. Click Query in the CloudConnector menu to activate the SOQL Query dialog
    
15. Enter your SOQL query and click Query to run the query.
    
16. The results should display in your spreadsheet.
17. If there are more records in the resultset, click the Query More option in the CloudConnector menu will return those results.

As I started to experiment more with node.js, I wanted to be able post data from a node.js application running on heroku to Salesforce.com via the REST API. Fortunately, Josh Birk wrote a nice article on how to use node.js with the new Apex REST (http://blogs.developerforce.com/developer-relations/2011/06/using-nodejs-with-forcecom.html). Leveraging the CRUD methods from node.js REST wrapper that Josh built for APEX REST I was able to easily create records in salesforce. I refactored this code a bit in order to take advantage of (and get more experience with) the out of the box features of express and node-oauth packages.

Using express and the jade view engine with my sample application, I was able to put together a nice little demo app of the crud operations working with SFDC.

The best part of using node.js with express was by simply constructing the name of the form elements to match the name of the fields in the object I was trying to create allowed me to pass request.body to the salesforce rest api and create the object without any object reconstruction on mapping. It is these types of things that make JSON stand out as the best message format around.

Here is a link to the sfdc-node source on github: https://github.com/gidzone/sfdc-node. Please fork away!  If you would like to get started working with this right away please use the source from github.  I had to make a couple changes to the oauth library, which are still waiting to get pulled into the main branch. I’ll post an update when the pull requests have been accepted, so you can easily run npm install sfdc-node.

The sample app can be found here: https://github.com/gidzone/nodejs-sfdc-sample

This script is currently being reviewed by google to be posted in it’s app scripts gallery for easy installation.  Stay tuned for a future post on how to use this tool.

Dave deBronkar, a kidney cancer survivor (full article), found that after data had been imported in to Google Health it said his cancer “…had spread to either his brain or spine…” which was not the truth.

As Bob Evans from Information Week (full article) explains:

Google Health users are finding stunning inaccuracies in medical records imported from primary-care physicians and hospitals because Google takes some information from insurance billing records that use broad and imprecise codes to describe patient treatment.The codes that Bob Evans is referring to are what is known as ICD-9 codes and they are used in the billing context to indicate the symptom of the diagnosis for the treatment rendered.

When coding the diagnosis for a diagnostic study, one will first code the finding and then the symptom (or complaint) from the patient. If the finding is negative, then only the symptom (or complaint) will be coded. In this case, if the data were to be imported into Google Health or any other Personal Health Record (PHR) it would show inaccurate information for this patient.

For example, a patient comes into the ER and complains of pain in the chest. A chest x-ray would be performed. If the result of the x-ray is found to be normal, the ICD-9 code for chest pain would be used for reimbursement purposes. In this case, this is a symptom not a finding. If this data was imported into a PHR it would be misleading.

The chest pain could have been caused by a case of excessive “flatulence” which would not have been captured in the PHR, if only billing data was used.

In addition, as John Chilmark points out ICD-9 is “limited” (full article).

Problem is, claims data is based on limited code sets (ICD-9) that physicians use for reimbursement. This can lead to inaccurate entries/codes as physicians struggle to fit a diagnosis to a given code or possibly prescribe a drug for off-label use, or even “game” the reimbursement system. Either way, end result is an inaccurate picture of the consumer’s health.

If claims data is bad, what is the best way to seed a PHR? In my opinion, there is no existing source we can take data from to create a baseline for a PHR. Billing data is currently being used because it is already electronic (meaning cheap), and insurance companies want to make sure they continue to wedge themselves between the doctor and the patient.

The first step in building an accurate electronic view of a person’s health is to strengthen the direct relationship between the doctor and the patient. This goal can be catalyzed through the use of Internet communication/networking tools. Simultaneously, we need to create open systems that are interoperable, which are built on existing standards. Together through direct communication and sharing the data population of PHR systems will be at the point where they only have accurate and meaningful data.

I received a tweet about this from Andre Blackman (http://www.pulseandsignal.com).
This is something that will actually turn a Wii into something more than just entertainment.

http://www.engadget.com/2009/01/27/wii-check-up-channel-will-link-you-to-health-professionals-dr/

This past October, my brother Naveen and I had the privilege of attending the Health 2.0 conference in San Francisco. For those that are unaware, Health 2.0 is essentially the use of social media in health care. One example of a Health 2.0 application is www.patientslikeme.com. At patientslikeme, users are able to share their experiences with other patients in order to “…share information that can improve the lives of patients diagnosed with life-changing diseases”.

The conference was well run, organized and informative. However, it did not seem enough to meet twice a year then come home. We really wanted to continue the conversations we began in San Francisco. In December, we reached out to some of the Chicago-area people we met at Health 2.0 to gauge interest. We met just before the holidays to discuss how to create something on a local level to discuss, exchange ideas, and network. We had a great discussion

We are trying to organize another Health 2.0 Chicago meeting this Thursday (January 15, 2009) at 5:30 PM at Matilda (3101 N. Sheffeld, Chicago, IL). If you are on twitter you can RSVP at http://twtvite.com/p61cej. We hope that if you are interested Health 2.0 you will join us.

Thanks for the memories!

For the past year or so, I have suspected that as the Dollar gets weaker and the Euro gets stronger more athletes will go and play in Europe or other parts of the world. This is because with a weak dollar other countries can now afford American talent.

The only reason that America has attracted the best athletes in the world over the past 30-40 years is because we have been able to pay them higher salaries to create the best and most competitive leagues in the world (with exception of Soccer). As the rest of the world catches up, you will see more talented Americans leave the USA and play elsewhere around the globe.

What potentially is a bad thing for American sports leagues and franchises might end up being a good thing for American sport in general. Distributing American talent around the globe will help create stronger leagues in other countries. A stronger league is a more competitive league. When people “buy” sport they are in essence consumers of competition. This consumption of a higher level of competition will inspire kids who never would have otherwise thought to play sports. In the end, these kids might end up coming to America to play or may just strengthen the newer leagues at home.

Economics is an interesting force. Let’s see how it helps the spread of American sports and talent throughout the globe.

The full details of the announcement can be read here: http://www.engadget.com/2008/03/06/live-from-apples-iphone-press-conference/

What interests me most about today’s announcement is the iFund. With the launch of this $100 million fund, it appears that Apple is now trying to build a community of developers/users around the iPhone. This is a 180 degree turn from their original stance of web apps as the only method for developing applications for the iPhone.

It is possible that Google’s Android had something to do with this change of heart. The fact that the iPhone is already in the market will give Apple a jump on Google. What will be interesting is to see if Apple decides to license the use of the iPhone OS to other hardware manufactures. This would be another huge change in Apples philosophy, but one that I think can only help them and their new commitment to building a solid user/developer community around the iPhone.