Health IT: A look at what can be done

Posted by admin 23/07/2008 at 08h24

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.


SuperInPlaceControls: A new rails plugin from Flvorful

Posted by admin 10/12/2007 at 17h12

We just finished up our newest plugin: SuperInPlaceControls.

This is meant as a drop in replacement for the current in_place_edit_for method that was recently moved into a plugin. SuperInPlaceControls works with Rails 2.0, validations, and empty fields.

Check out the SuperInPlaceControls page for more info, demos, examples and docs.

Have fun.

—jake


New Open Source site launched

Posted by admin 10/12/2007 at 17h09

We have just launched our new Open Source project site. We will centralize all of our OS projects into this site.

Check it out


When we first created our software we had this great idea. Wouldn’t it be cool if we could let our users change their skins out. We looked everywhere for an example, the closest thing we found was Youtube’s custom color control, nothing on the order of being able to create their own buttons and background. So then we started looking deeper into the FLVPlayback component and saw that there was already a way to swap out skins. So, stupidly, we started coding, wondering why in the world anyone else hadn’t tried this technique before. Lo and behold, we found our answer. If the skin had more buttons and graphics than what was provided by Adobe, you couldn’t easily swap it out because of how the object got named. Most of you have probably seen this problem: You create an object (either via actionscript or dropping it on the stage) and when you trace the object name you get something useless like “instance129”. When this happens, you are not able to easily swap out the clips (or buttons) dynamically because you dont always know what the objects name is going to be. We tried everything, needless to say, nothing worked, so we started from scratch.

Introducing BetterFLV

We figured, if Adobe wasnt going to give us the control we were going to have to create a new Skin class and FLVPlayback Class, and that’s exactly what we did.

BetterFLV extends the FLVPlayback component and has a companion class called Skin that controls the skin for the BetterFLV object. This allows you to create sites that allow your users to create their own skin buttons and backgrounds.

We didnt stop there. You would think that a video player class would come with a built-in timer object, as most of you already know it doesnt, but BetterFLV does. It also contains the code for an “Embed Code” button so that you can share the video and it has a “Click-To-Seek” buffer so that you dont have to drag the handle to seek thru the video.

Best of all: It’s free.

We are releasing BetterFLV as open source (GPL)

How to use

We tried to make it as easy as possible.

  1. Download the code and copy Skin.as and BetterFLV.as to you project directory.
  2. import the classes into your flash app via import BetterFLV
  3. Create an object from BetterFLV: main_player = new BetterFLV()
  4. Tell the player what skin to use: main_player.set_skin("http://www.somedomain.com/some_skin.swf")
  5. Tell the player the source for the video: main_player.source = "http://www.somedomain.com/some_flv.flv"

Done

Check out the sample folder for a sample app and sample skin.

Future Versions

  • Add Volume Slider
  • Anything else we can think of

UPDATE (11/5/2013)
Code now move to github

Check out the code and let us know what you think.

—jake


The most hilarious Rails post ever

Posted by admin 27/09/2007 at 08h52

I was browsing around DZone and found a post by Alex Bunardzic satirizing the now common “Why I switched from Rails to WHATEVER” posts that have been flying around the net. His language of choice: Assembler. Take a read and dont blame me if you fall out of your chair.

PS You must be a nerd to understand :)

—jake