Comments

LarryOsterman wrote:

But you didn't ask about VB for the mac.  What's with that?

Or MS Bob.NET

(ooooh, we don't joke about Bob)

scobleizer wrote:

Better security.

IMO, better security should never be a reason to PAY for an upgrade. I'm more interested in the other reasons, my security is fine. Hardware firewall, software firewall, A/V, A/S, etc...

When's PDC? Two more weeks? Three weeks? I'm not going, but it'll be interesting to see what you've been "anti-hyping" for months now.

Beer28 wrote:

That's actually not true. BSD and Linux actually keep the config files in folders prefixed with a . in the user's local dir ~/.config

The registry was first used to point to specific dll's, eventually people started storing application specific data in it. Which is when the problems started. IMO. Linux/Unix and OS X (I think, I 'm not sure about OS X) require your shared libs to be in the path. Which is a little easier (e.g. no real DLL hell) but you have to hope that an application you want to use was compiled against the version of the lib you have.

That being said, it's nice to have everything in your /home/~user dir. When I upgraded to OS X 10.4, I just zipped up my home dir and copied over to a network drive.

Beer28 wrote:

As is the case with the .so's not facing dll hell due to the version being in the file name. The low tech solution on unix systems is actually much more elegant.

As someone who spent two days hunting down dependancy issues when trying to install the Ruby on Rails framework under Ubuntu Linux, I'd respectfully disagree with you on this point. A lot of time the archive file containing the source for a lib will contain a version # in it's name, but the binary ends up being called the same name as any other version and there isn't any easy way to determine which version you've got. If there is, tell me about it.

mswanson wrote:

We worked a bit with Bill Crounse while architecting and building the NxOpinion diagnostic software. We also worked with Microsoft Research on Bayesian inference techniques to perform very fast and memory efficient diagnostics. If you'd like to see some cool technology and an inspirational video, check out the Technology Case study video in the upper-right corner of the PressPass article.

I haven't watched the video yet, but I'm going to. I just wanted to comment on this.

This is the scariest f'ing thing to do when you are developing a medical record/research system. I'm creating a cancer research system for UW/SCCA now and my biggest fear is that a doc will try to use our system to treat patients. We want them to use our system for quality of care research (e.g. how are my patients that are taking drug x doing? How efficient is this diagnostic technique at detecting this type of cancer) and analytical research ( e.g. what type of people are more likely to get this type of cancer, what types of treatments are more effective with this type of cancer). But I'm not sure we want to try and replace the electronic medical record system. We sure as heck don't want to try and suggest diagnoses to the docs. We are planning on using Baysean inferences, with a little bit of genetic programming, to increase the quality of the queries the docs want to run. Classifying the results into "good data", "Ok data", and "you should review this before you use it data.".

I can't believe the docs would go for letting a computer make a diagnosis for them. Is the system just suggesting possible diagnoses or is it making the diagnosis for the docs?

edit: I wanted to add that the reason we hope the docs aren't making a diagnosis from our application is that we don't think we can gather as much data as the patients paper chart has in it. We don't want the docs to make treatment decisions based on incomplete data. Trying to get data out of decades old, proprietary systems is ...hard.

'nother edit: One question. How is the tablet program at Swedish MC doing? I remember reading a case study on their EMR at the MS site a while back. Somebody from MS approached the SCCA about doing a Tablet pilot project. But their proposal was pretty lame, they didn't really want to push the envelope and we needed them too.  I'm not sure if we took them up on their offer or not. The last time we talked to someone about Tablet PC data entry for our app was in NYC, and it wasn't an MS presentation. It was a lame partner who showed us a lame ink text box. That was about 2 years ago though.

Jeremy W. wrote:

Exposed through managed code?

It's exposed through a documented set of API's. It shouldn't matter if it's managed or not.

I think there's a difference, from a security standpoint, between calling code via interop and calling managed API's to the .NET Framework. I *KNOW* there's a big difference between the two methods from the PITA standpoint.