Thursday, February 5, 2009

Following PHIN 2008 there was a discussion about the need to bring the service to the data. This is something I've been thinking a lot about and trying to plan accordingly for. Especially since the need to bring the service to the data keeps popping up again and again. Last week I called Wayne to discuss my work with the cloud/Nimbus and how Johns Hopkins and Utah might collaborate on a project that brings the service to the data. The document at the link below is an overview of one architecture that Wayne and I discussed.

http://sites.google.com/site/phgrid/Home/resource-documents/ConceptualOverviewofaPotentialArchitecturetoBringtheServicetotheData.doc?attredirects=0

Spatial Networking.com

Imagine using a tool such as this for social network analysis in support of outbreak response: (also has a catchy soundtrack)

SPATIAL NETWORKING
http://www.spatialnetworking.com/

This link is similar, and allows opportunities for travel teams to have situational awareness of opportunities where
There travel may intersect: http://www.whereyougonnabe.com/

A picture of what to do...

I apologize for the cliche, but I want to draw out a picture with my words...

I see the efforts of the NCPHI Grid lab progressing towards sort of a city map of options and interests, and being that I live in Atlanta, it's (naturally) playing out as a wagon wheel with a big network of semi-clogged roads surrounded by a ring bypass with a light rail system that is trying it's best.

The way I see it, the suburbs and exurbs are like the user interfaces, and the downtown areas are the land of data.

The exurbs are like the user interfaces for people who don't really need all the data, just a summary... It would represent things like the "health channel" or widgets on the front page of "health.gov": Things that turn red if something bad is happening... or things that will send out an email if you need to be extra careful about washing your hands at a particular football stadium. The inner-city suburbs are more like maintenance interfaces where really hard-core statisticians go to conduct some hard-core informatics and data mining.

Right now, my impression of this city is that there are two or three really big skyscrapers (like Biosense databases) and a bunch of little warehouses (hospitals). But the problem is that all the roads between these things are gravel and the parking at the big skyscrapers is expensive. In the meantime all the secure trucks keep sinking and get stuck on rainy days, and no-one has really build up sets of nice subdivisions anywhere.

In the meantime, NCPHI is sort of building model homes in certain spots, paving over a few of the roads to make reach out on a few points (AMDS-GMAP/Rodsadai and NPDS-GMAPS/poicondai being suburbs on the north end) and building a train station at either end...

I feel like the end point we are trying to get to is filling in the map.

On the outside, lots of new UI's need to be developed, some really complex ones with lots of analysts, some very simple ones so that people can essentially Google their neighborhood to see if anything is amiss, lots of support to make such things automatically set up and install instead of being a 17 step rollout.

In the city, a lot of virtual and physical infrastructure needs to be set into place: connecting all the data silos and little warehouses together. Even having little services run around indexing and enriching (instead of this data point only having a zip code and an address, it now has a zip code, address, county, census track...) and backing up the data (so now if one service goes down it can be modified by other services), and also lots of different pathways to share the data, with large pipes for big file transfers and secure networks for identified patient data, and all the connections to get the data out to the UI suburbs.

That is sort of where I see thing should be, and I also don't think NCPHI can really build all of this, but can really just plot out the map and tell people "it would be really cool if you turned this field of nothing into a really cool alert application using this tech connecting to these services..." or going "make this but for this style of data coming from this aggregator".

So yeah, a little thought on how all this is set up.

Wednesday, February 4, 2009

Unified Medical Language System (UMLS) Basics - Online Tutorial

If you are not familiar with the Unified Medical Language System (UMLS) - please read through the tutorial.

http://www.nlm.nih.gov/research/umls/online%20learning/index.htm



Tuesday, February 3, 2009

Well, we know it works in tomcat.

I have confirmed that the old version of poicondai (the CO centric version that you can see on the demo server now) will run in tomcat. Also, the lab engineer, Dale, has already whipped up a VM with SQL Server for testing, so that is awesome, and I should be able to test on it tomorrow.

Meanwhile, I have finished testing and creating an interface on top of the NPDS Axis service I had created, and now I have created a new project called npdsgmaps to essentially act as the mediator between the webapp, the gmap-polygon libraries, and the npds service. Thus it will make sure the time series of the polygons get populated appropriately, and that all the extra data for the web services gets passed in without the polygons having to worry about it. I am tentatively hoping I will get basic data in a rudimentary poicendai-map program (IE, a state and/or some zipcodes showing data) by tomorrow evening... but that is a lot of tentative and hope, I'll let you know where I am :D.

Cheers.

DRN Demo preparation

Dan and I tested the manual steps for the DRN demo with Joel Spangler from Geisinger. We transferred up the user SAS program using Ross' naming conventions, Joel combined the user SAS program with the Geisinger template, Joel ran the SAS program, I copied down the output file and displayed it using Open Office's spreadsheet program. Then Dan and I ran through the same steps using the NCPHI node.

I also wrote a few simple bash shell scripts that will help the demo go faster when we're running within WebEx. These bash scripts will be replaced by Don Brown's perl scripts once they are ready.

Curiously, the SSTS client runs a lot more slowly from Linux nodes than from Dan's windows client setup. It's a significant time difference (60 seconds on Linux vs. 5 seconds on Windows) and we'll be investigating to determine what the difference is.

Monday, February 2, 2009

Poicendai, AXIS, CXF, and Service Mishaps. Oh My

Sorry if I have been a bit mum over the past couple of days, but I
have had my head buried on trying to get the NPDS Service to return
data, and after discovering some of the issues that were
(embarassingly) problems on my end... I got data back... so now I am
trying to parse it into objects that would be easy for GMAP Polygons
to understand... and I'm trying to leave wiggle room for Dr. Espino
who is working on a really net Mvn fueled CXF version of the parser,
which will be better than the AXIS version I have because it won't
conflict with globus.

That, and I have just had a bunch of fun new requirements: Poicendai
(and therefore gmap-polygon) will now need to run based on a different
SQL platform, so I get to migrate test that, and I need to make sure
it will run on standalone tomcat (I am pretty sure it will but I still
have to test it), and start researching authentication schemes.

That, and we need to find better ways to handle Friday deploys to make
sure everything works after deployment, and that people can test
deployments in case the code originator isn't present and able to run
the test.

So, it's going to be very busy here over the next week, because I was
planning/hoping to get an unembarassingly demonstrable version of
PoiCenDai out this week.

Google, Microsoft PHRs sign health plan partners

http://www.fiercehealthit.com/story/google-health-phr-signs-first-health-plan-partner/2008-06-12?utm_medium=nl&utm_source=internal&cmp-id=EMC-NL-FHI&dest=FHI

The adventure continues...

Defense Department sets up its own SourceForge

DoD has set up their own open source portal. This seems similar to what the biosurveillance folks have been thinking of configuring.

http://news.cnet.com/8301-13505_3-10154053-16.html

From the article linked above...
"Despite being based on SourceForge's technology, Forge.mil has one significant difference: security. As David Mihelcic, chief technology officer for the Defense Information Systems Agency, told Federal Computer Week, the Department of Defense's code repository has been 'upgraded to meet DOD security requirements,' with smart cards used to provide log-in credentials."

(comically forgemil is down right now so I can't verify with my own eyes)

NIH to Provide $4 Million for Pilot Projects

http://www.healthcare-informatics.com/ME2/dirmod.asp?sid=&nm=&type=news&mod=News&mid=9A02E3B96F2A415ABC72CB5F516B4C10&tier=3&nid=48F3DE9C05AE43249BC284B3A692B24A


Interesting....