Slashdot Mirror

The solution is based on FHIR which is an open standard - as described here https://www.hl7.org/fhir/overv... "Healthcare records are increasingly becoming digitized. As patients move around the healthcare ecosystem, their electronic health records must be available, discoverable, and understandable. Further, to support automated clinical decision support and other machine-based processing, the data must also be structured and standardized. (See Coming digital challenges in healthcare) HL7 has been addressing these challenges by producing healthcare data exchange and information modeling standards for over 20 years. FHIR is a new specification based on emerging industry approaches, but informed by years of lessons around requirements, successes and challenges gained through defining and implementing HL7 v2 , HL7 v3 and the RIM, and CDA . FHIR can be used as a stand-alone data exchange standard, but can and will also be used in partnership with existing widely used standards."

There are already industry standards for EMR

Common Document Architecture (CDA) - provides formats for the interchange of data built on the OASIS schema.
Integrating Healthcare in the Enterprise - defines profiles for implementing technologies in an interoperable manner.
Open eHealth - open source baseline implementation of the above.

That's just for clinical data. There are a whole other set of standard for financial/claims records (X12) and pharmacy records/scripts (NCPDP).

The problem is that medical data is pretty complicated and often the context of the document is as important as the content. You almost always have to massage documents coming in even if they are ostensibly formatted to a standard you consume. You have to normalize units, make sure all the fields are part of the subset of the standard your system supports, etc.

And that doesn't even begin to get into tracking patient consent, tracking identity across multiple orgs, depts, and visits (MPI,PIX/PDQ), plus access restrictions and emergency access exceptions.

"HIPAA EDI" is ANSI ASC X12 (specifically committee "N") which is a collection of file formats for communicating business transactions (in this case, generally submitting charge or payment information among providers and insurers), and has very little to do with medical records.

HL7 has created the Consolidated Clinical Document Architecture which hopes and dreams to one day capture provider documentation in an electronic format. The government incentives mandate certain pieces of this document to be supported by certified software, with the pieces differing between the phase 1 (now "2011 Edition") and phase 2 ("2014 Edition") certifications.

These pieces are nowhere near enough to actually transmit something resembling a legal patient record.

Deep down, though, the problem with communication is that every provider has their own style, from the wet-behind-the-ear doc who writes out all their SOAP notes long form over two pages mentioning every little thing like they're still trying to impress their professor, to the 40 year old doc who has made up a single page template with 40 checkboxes for the most common exam findings, a few checkboxes for diagnosis, and a box to write a plan, to the 60 year old who writes "ros/pe:wnl,pt well,flu shot,rtc 1y" on the line below where the nurse wrote the vitals and calls it a day.

What all of the above doctors have in common is that they do NOT want to deal in "structured data". They do not want to deal with SNOMED (or ICD-10, or hell, most of them don't even use ICD-9 that's what they hire billers for). Nobody deals with LOINC (good luck finding out the process used for your urinalysis dipstick so you can code the results correctly. I've got two major national labs that use LOINC for their test results, zero local labs, and zero labs that use LOINC order codes at all. For vitals at least someone in the government bothered to arbitrarily pick codes for height, weight, blood pressure and a few others out of the list of different ways of measuring each of them).

HL7, CDA, and a national private network. Problem solved. Yes, it'll be expensive - but you don't need to "define" anything because everything you need is defined already.

I was just thinking the same thing, particularly in response to the posters writing that GPs and hospitals have gone forward with their own computerized system that are now not interoperable.

For those who don't know, HL7 includes, among other things, an XML schema for health care information. Let each office or organization build their own system--with a list of 'best practices' from the NHS to reduce reinventing the wheel--and use the existing standard for inter-org communications.

Nope. The current Electronic Medical Record systems are not capable of exchanging information freely. There is no standard data format that everyone can exchange.
There are a few standards that can package data, but they are not adequately specified for seamless interoperability.
If you request records, they can print them out quickly for you though.

Such as HL7 which, from the reading I've been doing is actually quite thorough. And if both sides are using HL7 v3, which is XML-based, you can overcome formatting issues between software packages through the use of XSL stylesheets.

Apparently, despite writing for a site dealing with medical technology, and ranting on about the lack of openness in EMR, the author of the article has never heard of HL7. That is, an open ANSI-standard EMR platform that has been around since 2003. Oh, but I'm sure that doesn't relate to the article.

Or would the fact that most medical records HAVE to be in a non-proprietary format since they must be passed between so many systems that are operating in a Hospital. Do you think one single proprietary software application handles all of the different departments, plus billing, plus insurance, plus pharmacy, plus the lab tests and results, etc? Most hospitals use different software to cover each phase and shift data between each application's database, or use HL7 to pass them as messages.
Even the large software applications which handle everything pass data through HL7. I know.. I've worked with many of the top ones.

A standard isn't software; it's how to exchange information. That includes data formats, but also includes protocols and an awful lot of context. The standards work is a big job, and people have been working on it for years (see HL7). As eln points out below, it's boring as hell, but that doesn't make it unimportant. The industry has been in the process of moving from HL7 v.2 to v.3 for about a decade now.

If you want to get into the software part of the solution, have a look at the OHF Project. There are others, but that's a starting place.

I agree with tnk on the benign reason; the system as a whole will save money, but which individual players will save how much? Hospitals already spend very little on IT compared with other businesses, so spending a big whack that may end saving money for some insurance company isn't going to happen.

You want one big reason for doing this? If it can free up nurses from doing secretarial work chasing down documents in the mail and phoning around, it just might keep enough staff at the hospitals to serve the public. The U.S. department of health and human services prepared this report on the subject. It's worth reading.

http://www.hl7.org/ Major medical records systems are pretty universally HL7 compliant. That means medical providers can uniformly interchange your charts without the help of Google. It has been around for a decade.

We already have HL7. Providers have the ability to exchange and consolidate your medical records directly and to provide electronic copies for the patient to physically retain to personally bring by sneakernet between their providers without the need for a proxy. The vast majority of people don't have that many medical providers, nor do they change them very often. It is neither necessary nor desirable to have a company like Google aggregate the records. Its only strength is in being the *only* repository, which is its greatest weakness as a single point of failure. If there are multiple companies like Google providing the service, how is that terribly different than polling the providers directly? Central clearinghouses might be useful, a la the credit reporting agencies. When someone has records on you, they publish that fact without publishing the actual records. So, in an emergency situation, a provider could ask the question "where does this person have records" and then proceed to retrieve them with proper clinical discretion on both ends.

How is sheets of paper being faxed/mailed between docs the best possible standard? The whole system is jive, adding storing it with Google might make it slightly less jive, actually fixing it would, well, fix it.

Give people their medical records. Digitally signed by the docs that made them so they're authentic if the medical system must.

See HL7. You can have a clusterf**k at the individual level or at the standards level - but it will still be one.

HL7 is a "standard" for moving patient information from system to system. I call it a "standard" because the 1.x and 2.x versions were largely "advisory", with more MAY than MUST, with a huge amount of wiggle room... I've worked on 4 information exchange projects now, and all of them started from scratch because none of their HL7 "specs" are compatible.

Supposedly the new version 3 standard (which uses the "modeling approach") will be much more firm with the implementors, which will hopefully mean that every now and then one implementation will actually be compatible with another implementation. I've looked over their "models" and they've modelled a lot of the business use-case stuff for patient data, but not a lot of the actual data itself. Hopefully when it's done, it'll come out a bit better baked than previous versions.

I read several of the responses to this posting and, true to Slashdot form, even though some /.ers knew about the software, most did not, and yet everyone had an opinion.... Democracy at its finest!

Seriously, though, I'd like to add some light. I've seen Vista in use at VA in MD/DC area; this is a wicked piece of software. IMO, if all hospitals used this software to its potential, patient care in the US would benefit greatly. Basically Vista puts all the records for a patient at the fingertips of hospital staff. And I mean ALL -- hematology, cardiology, radiology, oncology, any bloody -ology you can think of.

Which is pretty impressive, especially given that this started in VA hospitals. Any MD who has worked both public and gov't will tell you that typical VA patients usually have a greater incidence of multiple illnesses or concomitant disorders than patients in public hospitals -- or more specifically, the incidence of pts with concomitant illnesses is greater at VA hospitals than in the commercial hospitals within the immediate area surrounding the VA hospital. Vets are often just "more sick," for a variety of socioeconomic, medico-financial, age-related, and incidence-of-exposure reasons. And VA patients are often long-term, multiple-report patients -- meaning the typical patient has had several visits to the VA hospital versus his/her non-VA counterpart.

So in such an environment, there is a great driver for good patient recordkeeping (knowing what this patient's drug and treatment profile looks like over a long period of time) and clinical access (getting that information quickly and knowing it is accurate). And Vista (or "VistA") fills the bill. It does an extraordinary job in capturing patient information and making it available to a physician in a logical, well-thought-out manner. Sure, it may require some expert help to implement -- but show me any solution with the same broad med system involvement and impact that doesn't require paying for implementation expertise. I mean, some vendors may *say* their solution is OTS and can be implemented by any hospital IT group, but when it comes down to their software doing everything that a full Vista implementation can do, I bet the salesperson's story changes to "well, you will need to use our services group to implement across all those divisions...."

Now, Vista may be based on an old language, but that's the nature of some long-term projects. Hate to sound like an old guy at 38, but you young programmers wouldn't *believe* how much financial information in the US is still processed via COBOL in MVS.... Anyway, I'm sure most /.ers would agree that it ain't the language so much as the *result* that's important, and Vista is one well-tested, well-done, usable piece of software. And the developers of Vista and its proponents at the VA and within HHS have really gone out of their way to keep the software compatible with open tech standards -- not just the overarching ones like those the W3C police, but also open standards that are more medically specific like those created through Health Level 7 (http://www.hl7.org/).

The intersection of computer nerd and med-tech geek is sparsely populated, so I hope that all /.ers can understand that Vista really is a rare thing -- a government-initiated software product that adheres to open standards, is moderately user-friendly, actually improves the environment in which it is implemented, and provides significant benefit to its target (and at-risk) population.

***After reading my posting, I felt I needed to add that I have absolutely no connection with Vista or WorldVista. I've worked within HL7 on some standards and was introduced to the Vista system by a VA doc who was also presenting at a conference with me. In other words, this ain't been paid programming!

unless it does hl7 it's junk.

I don't understand why there is such a need to make a new protocol...

The article didn't mention a new protocol. And the HHS Department is pushing HL7 heavily, so if the companies are working with HHS then I'm sure the "nonproprietary technology standards" the article talks about includes HL7.

But there are lots of gaps in HL7 that need to be filled, and it's only the medical message transmission protocol anyway.

For those curious, check it out.

So how will the work of this consortium integrate with that being done by the HL7 organization? And if there's a disagreement between standards bodies about how best to comply with HIPAA regulations, how does it get worked out?

It's hard enough to reach a consensus on DVD formats -- imagine trying to get every doctor's office,

The standard is pretty well established, the HL7 Clinical Document Architecture. Adoption will take time as systems are upgraded.

Also, take into consideration that the incorporation of these standards into vendors' products is excruciatingly slow at best. Several years ago, vendors had the idea that we can take care of all of your healthcare information systems needs -- "Our system does it all!". Well, they soon learned that healthcare information systems were extremely complex and they couldn't manage/keep resources to maintain/produce such huge systems and still make a profit. Enter the age of the "Best of Breed" system. "Our system just does these few things, but it does 'em really well! You just need to buy/build an interface to get it talking to your other systems!" Many of us that work in healthcare IT cringe whenever someone mentions an interface. The results you get from stringing together lots of interfaces can often be like playing the telephone game - send a piece of information from one system through one or more interfaces, to another system and hope like hell it makes sense on the other end.

You guys are on the right track when you talk about security. I worked at one hospital that was in the "Top 10" hospitals in US News and World Report a couple of years ago and some of the stuff I saw floating across the network was scary. We had some clinical systems that sent their userid/pw across as plain text. Packets floating across the network often contained patients names, clinic notes, diagnoses, lab test results, etc., all in PLAIN TEXT! It was amazing how much information I could obtain by using an evaluation copy of a packet analyzer on an unsecured network port at this institution.

One scary trend I've noticed lately is all of the people/vendors that want to download patient information to PDA's without having adequate security on the PDA. I'm just waiting for some doc to lose his Palm and have some kind soul find it and turn it over to the local media. :)

There are lots of other issues that futher complicate the whole healthcare information system issue such as institutional politics, workflow/usability issues, etc., but I don't have time to get into them right now.

Personally, it sounds to me like these guys need a serious whack with a clue-by-4... that or they need to get out and do a bit more research on the subject at hand..

Also, take into consideration that the incorporation of these standards into vendors' products is excruciatingly slow at best. Several years ago, vendors had the idea that we can take care of all of your healthcare information systems needs -- "Our system does it all!". Well, they soon learned that healthcare information systems were extremely complex and they couldn't manage/keep resources to maintain/produce such huge systems and still make a profit. Enter the age of the "Best of Breed" system. "Our system just does these few things, but it does 'em really well! You just need to buy/build an interface to get it talking to your other systems!" Many of us that work in healthcare IT cringe whenever someone mentions an interface. The results you get from stringing together lots of interfaces can often be like playing the telephone game - send a piece of information from one system through one or more interfaces, to another system and hope like hell it makes sense on the other end.

You guys are on the right track when you talk about security. I worked at one hospital that was in the "Top 10" hospitals in US News and World Report a couple of years ago and some of the stuff I saw floating across the network was scary. We had some clinical systems that sent their userid/pw across as plain text. Packets floating across the network often contained patients names, clinic notes, diagnoses, lab test results, etc., all in PLAIN TEXT! It was amazing how much information I could obtain by using an evaluation copy of a packet analyzer on an unsecured network port at this institution.

One scary trend I've noticed lately is all of the people/vendors that want to download patient information to PDA's without having adequate security on the PDA. I'm just waiting for some doc to lose his Palm and have some kind soul find it and turn it over to the local media. :)

There are lots of other issues that futher complicate the whole healthcare information system issue such as institutional politics, workflow/usability issues, etc., but I don't have time to get into them right now.

Personally, it sounds to me like these guys need a serious whack with a clue-by-4... that or they need to get out and do a bit more research on the subject at hand..

Also, take into consideration that the incorporation of these standards into vendors' products is excruciatingly slow at best. Several years ago, vendors had the idea that we can take care of all of your healthcare information systems needs -- "Our system does it all!". Well, they soon learned that healthcare information systems were extremely complex and they couldn't manage/keep resources to maintain/produce such huge systems and still make a profit. Enter the age of the "Best of Breed" system. "Our system just does these few things, but it does 'em really well! You just need to buy/build an interface to get it talking to your other systems!" Many of us that work in healthcare IT cringe whenever someone mentions an interface. The results you get from stringing together lots of interfaces can often be like playing the telephone game - send a piece of information from one system through one or more interfaces, to another system and hope like hell it makes sense on the other end.

You guys are on the right track when you talk about security. I worked at one hospital that was in the "Top 10" hospitals in US News and World Report a couple of years ago and some of the stuff I saw floating across the network was scary. We had some clinical systems that sent their userid/pw across as plain text. Packets floating across the network often contained patients names, clinic notes, diagnoses, lab test results, etc., all in PLAIN TEXT! It was amazing how much information I could obtain by using an evaluation copy of a packet analyzer on an unsecured network port at this institution.

One scary trend I've noticed lately is all of the people/vendors that want to download patient information to PDA's without having adequate security on the PDA. I'm just waiting for some doc to lose his Palm and have some kind soul find it and turn it over to the local media. :)

There are lots of other issues that futher complicate the whole healthcare information system issue such as institutional politics, workflow/usability issues, etc., but I don't have time to get into them right now.

Personally, it sounds to me like these guys need a serious whack with a clue-by-4... that or they need to get out and do a bit more research on the subject at hand..

Also, take into consideration that the incorporation of these standards into vendors' products is excruciatingly slow at best. Several years ago, vendors had the idea that we can take care of all of your healthcare information systems needs -- "Our system does it all!". Well, they soon learned that healthcare information systems were extremely complex and they couldn't manage/keep resources to maintain/produce such huge systems and still make a profit. Enter the age of the "Best of Breed" system. "Our system just does these few things, but it does 'em really well! You just need to buy/build an interface to get it talking to your other systems!" Many of us that work in healthcare IT cringe whenever someone mentions an interface. The results you get from stringing together lots of interfaces can often be like playing the telephone game - send a piece of information from one system through one or more interfaces, to another system and hope like hell it makes sense on the other end.

You guys are on the right track when you talk about security. I worked at one hospital that was in the "Top 10" hospitals in US News and World Report a couple of years ago and some of the stuff I saw floating across the network was scary. We had some clinical systems that sent their userid/pw across as plain text. Packets floating across the network often contained patients names, clinic notes, diagnoses, lab test results, etc., all in PLAIN TEXT! It was amazing how much information I could obtain by using an evaluation copy of a packet analyzer on an unsecured network port at this institution.

One scary trend I've noticed lately is all of the people/vendors that want to download patient information to PDA's without having adequate security on the PDA. I'm just waiting for some doc to lose his Palm and have some kind soul find it and turn it over to the local media. :)

There are lots of other issues that futher complicate the whole healthcare information system issue such as institutional politics, workflow/usability issues, etc., but I don't have time to get into them right now.

Personally, it sounds to me like these guys need a serious whack with a clue-by-4... that or they need to get out and do a bit more research on the subject at hand..

Also, take into consideration that the incorporation of these standards into vendors' products is excruciatingly slow at best. Several years ago, vendors had the idea that we can take care of all of your healthcare information systems needs -- "Our system does it all!". Well, they soon learned that healthcare information systems were extremely complex and they couldn't manage/keep resources to maintain/produce such huge systems and still make a profit. Enter the age of the "Best of Breed" system. "Our system just does these few things, but it does 'em really well! You just need to buy/build an interface to get it talking to your other systems!" Many of us that work in healthcare IT cringe whenever someone mentions an interface. The results you get from stringing together lots of interfaces can often be like playing the telephone game - send a piece of information from one system through one or more interfaces, to another system and hope like hell it makes sense on the other end.

You guys are on the right track when you talk about security. I worked at one hospital that was in the "Top 10" hospitals in US News and World Report a couple of years ago and some of the stuff I saw floating across the network was scary. We had some clinical systems that sent their userid/pw across as plain text. Packets floating across the network often contained patients names, clinic notes, diagnoses, lab test results, etc., all in PLAIN TEXT! It was amazing how much information I could obtain by using an evaluation copy of a packet analyzer on an unsecured network port at this institution.

One scary trend I've noticed lately is all of the people/vendors that want to download patient information to PDA's without having adequate security on the PDA. I'm just waiting for some doc to lose his Palm and have some kind soul find it and turn it over to the local media. :)

There are lots of other issues that futher complicate the whole healthcare information system issue such as institutional politics, workflow/usability issues, etc., but I don't have time to get into them right now.

Personally, it sounds to me like these guys need a serious whack with a clue-by-4... that or they need to get out and do a bit more research on the subject at hand..

Also, take into consideration that the incorporation of these standards into vendors' products is excruciatingly slow at best. Several years ago, vendors had the idea that we can take care of all of your healthcare information systems needs -- "Our system does it all!". Well, they soon learned that healthcare information systems were extremely complex and they couldn't manage/keep resources to maintain/produce such huge systems and still make a profit. Enter the age of the "Best of Breed" system. "Our system just does these few things, but it does 'em really well! You just need to buy/build an interface to get it talking to your other systems!" Many of us that work in healthcare IT cringe whenever someone mentions an interface. The results you get from stringing together lots of interfaces can often be like playing the telephone game - send a piece of information from one system through one or more interfaces, to another system and hope like hell it makes sense on the other end.

You guys are on the right track when you talk about security. I worked at one hospital that was in the "Top 10" hospitals in US News and World Report a couple of years ago and some of the stuff I saw floating across the network was scary. We had some clinical systems that sent their userid/pw across as plain text. Packets floating across the network often contained patients names, clinic notes, diagnoses, lab test results, etc., all in PLAIN TEXT! It was amazing how much information I could obtain by using an evaluation copy of a packet analyzer on an unsecured network port at this institution.

One scary trend I've noticed lately is all of the people/vendors that want to download patient information to PDA's without having adequate security on the PDA. I'm just waiting for some doc to lose his Palm and have some kind soul find it and turn it over to the local media. :)

There are lots of other issues that futher complicate the whole healthcare information system issue such as institutional politics, workflow/usability issues, etc., but I don't have time to get into them right now.

Personally, it sounds to me like these guys need a serious whack with a clue-by-4... that or they need to get out and do a bit more research on the subject at hand..

Also, take into consideration that the incorporation of these standards into vendors' products is excruciatingly slow at best. Several years ago, vendors had the idea that we can take care of all of your healthcare information systems needs -- "Our system does it all!". Well, they soon learned that healthcare information systems were extremely complex and they couldn't manage/keep resources to maintain/produce such huge systems and still make a profit. Enter the age of the "Best of Breed" system. "Our system just does these few things, but it does 'em really well! You just need to buy/build an interface to get it talking to your other systems!" Many of us that work in healthcare IT cringe whenever someone mentions an interface. The results you get from stringing together lots of interfaces can often be like playing the telephone game - send a piece of information from one system through one or more interfaces, to another system and hope like hell it makes sense on the other end.

You guys are on the right track when you talk about security. I worked at one hospital that was in the "Top 10" hospitals in US News and World Report a couple of years ago and some of the stuff I saw floating across the network was scary. We had some clinical systems that sent their userid/pw across as plain text. Packets floating across the network often contained patients names, clinic notes, diagnoses, lab test results, etc., all in PLAIN TEXT! It was amazing how much information I could obtain by using an evaluation copy of a packet analyzer on an unsecured network port at this institution.

One scary trend I've noticed lately is all of the people/vendors that want to download patient information to PDA's without having adequate security on the PDA. I'm just waiting for some doc to lose his Palm and have some kind soul find it and turn it over to the local media. :)

There are lots of other issues that futher complicate the whole healthcare information system issue such as institutional politics, workflow/usability issues, etc., but I don't have time to get into them right now.

Personally, it sounds to me like these guys need a serious whack with a clue-by-4... that or they need to get out and do a bit more research on the subject at hand..

Also, take into consideration that the incorporation of these standards into vendors' products is excruciatingly slow at best. Several years ago, vendors had the idea that we can take care of all of your healthcare information systems needs -- "Our system does it all!". Well, they soon learned that healthcare information systems were extremely complex and they couldn't manage/keep resources to maintain/produce such huge systems and still make a profit. Enter the age of the "Best of Breed" system. "Our system just does these few things, but it does 'em really well! You just need to buy/build an interface to get it talking to your other systems!" Many of us that work in healthcare IT cringe whenever someone mentions an interface. The results you get from stringing together lots of interfaces can often be like playing the telephone game - send a piece of information from one system through one or more interfaces, to another system and hope like hell it makes sense on the other end.

You guys are on the right track when you talk about security. I worked at one hospital that was in the "Top 10" hospitals in US News and World Report a couple of years ago and some of the stuff I saw floating across the network was scary. We had some clinical systems that sent their userid/pw across as plain text. Packets floating across the network often contained patients names, clinic notes, diagnoses, lab test results, etc., all in PLAIN TEXT! It was amazing how much information I could obtain by using an evaluation copy of a packet analyzer on an unsecured network port at this institution.

One scary trend I've noticed lately is all of the people/vendors that want to download patient information to PDA's without having adequate security on the PDA. I'm just waiting for some doc to lose his Palm and have some kind soul find it and turn it over to the local media. :)

There are lots of other issues that futher complicate the whole healthcare information system issue such as institutional politics, workflow/usability issues, etc., but I don't have time to get into them right now.

Personally, it sounds to me like these guys need a serious whack with a clue-by-4... that or they need to get out and do a bit more research on the subject at hand..

I was thinking there would be some benefits of creating an open source interface engine (a program which translates and routes HL7 messages) The current ones are not the best technology, but most of all when you buy them you get stuck with a single vendor's support argeements (and excessive rates), you have to pay for any extra functionality, and all the usual disadvantages of closed source software (which need not be repeated here). This sounds like it might even be feasible considering if the software was good enough, a vendor (or vendors) could still sell support.

I have heard that Microsoft is beginning to show a lot more interest in this field lately. The next version of HL7 is going to be XML based, and what is BizTalk server but an XML translator/router.

This comment is not the opinion of my employer.

There is a lot of activity in the area of open source electronic medical record (EMR) software. As some of the posters have mentioned clinical information systems are highly complex, and this has led to many idiosyncratic open source projects that cannot be integrated easily. (The open source EMR world is still in an early stage of its development.) Current efforts are now focusing on larger, integrated approaches to open source healthcare computing.

There are two good web sites that are like clearinghouses for open source in healthcare:

1. The Minoru Development site is loaded with resources for open source healthcare developers, including a list of open souce projects. Minoru-Development hosts an email list that is energetic and wide-ranging.

2. Another good general site for open source in healthcare is LinuxMedNews, a Slashdot-like news and discussion site.

There are other large healthcare projects that are use some proprietary development tools, but which are developing open standards for healthcare computing. These include HL7 and GEHR (the Good Electronic Health Record project).

If you're interested in getting involved open source devolopment in healthcare, check out the Openhealth mailing list.

In the health care industry there is a loose (i.e. loosely followed) message standard called HL7 (health level 7) which is a delimited format. However they have been working on 3.0 which is based on XML. I have heard that Microsoft is very much interested and involved in this new standard. Also I went to an XML seminar (read: marketing) where they described the BizTalk (business world XML messaging) XML standard as well as their (vaporware as of yet?) XML message server. I get the feeling MS sees XML being an important standard across all industries.