If you are about to socialize your app and you’re wondering which API to use and which network to connect, you’re not alone. Facebook’s API alone has grown into a behemoth and now MySpace is on the verge of making their API public. Throw Twitter’s API, Ning and any one of 20 plus other sites and the combinations make any developer want to curl up into a fetal position and start weeping. What to do??
Well, start slim. When OnlyMusicVideos.tv approached us to help them connect their site into Facebook, the only option was a full on application that appeared on the Facebook Canvas. Now there are much easier and cleaner options. Introducing Facebook Connect, a much cleaner way to integrate the power of Facebook without the user ever leaving your site.
What Can It Do?
Several things. The most important of which, is allowing your app to authenticate a user via their Facebook credentials. This allows users the ability to log into your application via Facebook and pull their information from their FB profile into your application (according to FB rules, obviously). So what exactly does this mean? Simple. Every Facebook user now has an account with your app. If a user can login to FB, then they can login to your application and take advantage of your features. Plus, you can now update the user’s profiles (via news feeds, stories, status updates, etc) with information from your application/business.
How Do You Do It?
- Add some JS and a single HTML file (xd_connect.html) to your website. This JS will connect to FB and allow you to parse out FB’s custom HTML tags (called FBML) and pull down and session information that is pertinent to the current user (like whether they are logged in or not)
- If they are logged in redirect them to the normal logged-in version of your site and add a new Account/User to your app with the Facebook Id that is passed to you. This will allow you to connect a FB user into your system. You may need to alter your DB slightly to hold the facebook id. Then your done.
- If they are not logged in you should display the FB login button that will trigger a popup and allows the user to login through FB. Once they login, FB will redirect them back to your site will updated session details. At this point you can just follow through step 2.
That’s it, your connected to the web 2.0 world.
Well, that’s up to you. Just because you connected to a social network doesnt mean all of the Internet are going to come running to your site. It does make it much easier, but you still need to get out there and promote. Utilize the services that you are connected to. Create groups and invite all your employees and fans of your products to help generate traffic and awareness. Even your offline marketing needs to show that you are connected through the particular networks that you are integrated with. Send an email blast to your current customers that they can now connect with their FB profile (you might want to make an easy way for them to connect their current account with their FB account). The power of a social network isnt that there are a lot of people on there, it’s the speed at which information can zip through the network and generate instantaneous traffic and feedback.
Being the Chief Architect here are Flvorful and heading up several IT teams throughout my career I am pretty keen to the technology that is available for computing and the problems that can be solved with them. So you can imagine how annoyed I get when I go to my doctor's office and have to fill out those forms every single time, for every single doctor I go to.
I look around and know we have the technology to fix this highly inefficient process, all we have to do is put it together.
I think this technology should be an open standard (OPENHealth) that is centrally managed by a non-profit group. The group would be tasked with centralizing and securing the medical data for all patients. This group will be completely independent from government so that politics never come into play. They will be sustained by small subscription fees that they charge hospitals based on their size ($40-$70 per month). This money will be used to pay for the groups staff and the technology and bandwidth that will be required.
Of course, we will have to add some checks to this group so that they dont become corrupt and the easiest step is transparency. Everything that the group spends money on should be made available online ( i think non-profits have to do this anyway, but i'm not too sure).
The standard should be simple XML utitlizing REST calls. You can secure it behind HTTPS (if it's good enough for the banks to secure your transactions, it's good enough for medical data). Every accredited hospital will get a key and a passphrase that changes daily and is emailed to the hospital admin and IT staff (their software should allow for easy input of daily keys). This would prevent old employees who dont work for hospitals from memorizing the key (if they had some sort of super memorization power and can remember a 32-bit SHA1 hash key). Realistically, only the hospitals IT admin staff will know the hospital's key because it will probably be buried within the hospital's particular admin software so the daily key may not be necessary and it would be transmitted via HTTPS thereby bypassing any sort of network-sniffing-type hacks, but it's nice to err on the side of caution.
The XML should be simple so that it can be quickly and accurately parsed by any programming language as well as making it far easier to maintain. XML schema that utilize excessive attributes are not only confusing, but lead to excessive overhead when parsing the XML nodes because of the need to add an extra node for attributes and values inside the tags. The XML should be just tags and values. Nesting tags help clarify groupings as well as properly naming the tags.
Here is an example of a simple XML Dataset for a particular patient.
<record> <record_id>123456789</record_id> <first_name>John</first_name> <last_name>Doe</last_name> <allergies> <allergy>Dust</allergy> <allergy>Pollen</allergy> <allergy>Mold</allergy> </allergies> <hospital_visits> <visit> <visit_date>Jan 3, 2007</visit_date> <hospital>HOSPCODE123</hospital> <reasons_for_visit> <reason>Had a headache</reason> <reason>Runny Nose</reason> <reason>Puffy Eyes</reason> </reasons_for_visit> <diagnosises> <item>Has the flu</item> <item>Also had high blood pressure</item> </diagnosises> <remedies> <remedy>Prescribe Anitibiotics</remedy> <remedy>Get sleep</remedy> </remedies> <prescriptions> <prescription>Penecillin</prescription> <prescription>Advil</prescription> </prescriptions> </visit> </hospital_visits> </record>
This would obviously continue for as many visits as necessary. This schema should be derived from Mayo Clinic's Universal Medical Record. This particular type of record was developed by Mayo Clinic over 100 years ago and has since been implemented in several not for profit health centers around the world.
All Health software companies would utilize this new standard when creating software for Hospital Administration.
It wouldn't really require that much money to operate, $400,000 - $800,000 per year would be a rough estimate (based on number of servers necessary to house data and provide enough connections and bandwidth for the API calls plus the labor required to maintain the servers and support), although the initial investment may be closer to $2 million for the cost of getting the hardware necessary to build this network all over the country in different data-centers. Putting servers in different data-centers is necessary to ensure the integrity of the information. There will be a master database (or master cluster of databases depending on you choose to setup the schema) and this database (cluster) is the source for all writes and is replicated to all other database servers (clusters) all over the country to increase concurrency and add redundancy.
The shear cost of paper-based administration and incorrect medical documentation will all but disappear and drive down costs if we can just harness technology and build the tools we need.