Insist on Open Source

What is the idea?Those deciding on health IT solutions should insist on Free and Open Source (FOSS) software.

When people use proprietary Health Information systems, there is always one party, the developers of the proprietary system, that has a dramatically skewed proportion of the control of the health information.

People will suggest many wonderful ideas on this board: PHR's, transparency, consumerism, Health 2.0, interoperability etc etc. But if those good ideas are implemented in proprietary systems, then the true "owners" of the health information are the vendors. They are the only ones who can change what the software needs to do.

This is important because we have no idea what a Health IT applications should be doing in two years.

Arguably (just check my comments) the best EHR in the world is VA VistA. It is the best because it was developed with the following way:

• Openly, everyone could see the code• Collaboratively, different people did different parts focusing on solving local needs. • Distributed, there was no central body who created the "specs" for VistA

That is essentially the open source development model.

Freedom is not incidental to the quality of VistA. It is the foundation of VA VistA. Without the local control and the centralized coordination that are the hallmarks of the FOSS development model, we will never realize the potential for software to improve healthcare

-Fred Trotter

Why is it important?Proprietary licenses are only good for the vendor: not the patient, not the provider, not the hospital, not the clinic.They put the vendor in control of patient data. One could argue all day about who should "own" patient data, but it should not be the software vendor.

All of the good ideas that are proposed here will be tainted by the licensing unless those who are interested in the greater good take a strong stand against those who wish to guarantee thier own profitablity.

Vista is certainly one of the most cost effective solutions out there and the VA has the highest quality outcomes of any system but that might be more a reflection of "owning" their patients versus the IT system they are using.

I am a strong proponent of patient's owning their own data if you glance at my other comments you know that vendors who fail to autormacially allow their own clients (hospitals) to exchange data with one another (ie 3 hospitals in CA in the same city with the same vendor and you have to print out paper copies since no one will pay for the IE to exhange patient files between them). The VA is also now carving up some of the Vista modules and recently gave one of the vendors the lab module

The biggest challenge with open source software isn't the implementation costs or the technology but the support down the line. There are already private firms that offer to implement the VA system but there have been very few takers so far. Why do you feel that is? Would people be comfortable with one system holding their entire record as long as we don't have guarenteed access to health care?

Sherry ReynoldsAlliance4Health

Comment from Alliance4Health at Alliance 4 Health

Would love to hear more about the relationship of privacy to open source systems. Do they provide better potential to protect patient privacy, and if so, how?

Comment from dmcgraw at Center for Democracy & Technology

responding to dmcgraw

.. more about the relationship of privacy to open source systems.

Things like privacy and security are mostly trust issues, but with Open Source trust is based on transparency where as in proprietary land, trust is based on reputation. For instance, when Microsoft HealthVault says "We will never share user data without the users permission", we have to accept that on faith based on the fact that Microsoft is a company that does what it says. Now Microsoft usually does what it says, but it also abuses its position in the operating space to perform monitoring. Is Microsoft actually worthy of trust? Who knows.

Take Dossia, however. Dossia is based on Indivo which is open source. That means that I can trust-but-verify. If I do not trust Dossia to protect me privacy I have the following options:

• Read the source code to see what Indivo does, to ensure that what I see on the front-end is what Dossia is really doing on the backend.

• Run my own instance of Indivo so that I know everything that the backend is doing

Really the questions should be "How is trust in a Health IT system possible without source code availability?" and then "How is true privacy possible without that trust?"Comment from ftrotter at Open Source Hacktivist

Agree with Fred's essay. In economic terms, Electronic Medical Record software is a 'public good' like a lighthouse, not a private good like cars or furniture yet the country still tries to ram that proprietary square peg into that round healthcare hole with predictably poor results that people somehow consider to be normal.

There is good uptake of VA VistA in the private sector. Whole states like North Carolina are adopting it. It appears to work nearly every place it has been tried with one exception that I know of and that 'failure' was largely due to massive staff turnover and loss of physician champion than the software. The naysayers are always saying prove it, then after it is proven over and over again (our

American VistA software has worked in numerous foreign countries, people!) they still say it will never work and then you find that they have a tie to a proprietary vendor.

Comment from ivaldes1

Another great benefit of this idea is he security of the systems. Open systems have proven to be quite secure due to the openness and exposure. This is critical for ensuring privacy of medical records and generating enough confidence for healthcare providers and consumers to feel comfortable trusting their information to these systems.

Comment from GadgetComa

I agree with the Fred's piece. Vista is a great EMR. The only issue with it that I can see is it is extremely hard to implement and it is not a web based product. I have heard that a company has developed a web based front end to OpenVista but am not sure.

Comment from reddsman

There are many good reasons to consider free open source software (FOSS), although, when in terms of privacy, there’s nothing inherent in FOSS that makes it superior to all proprietary products.

I’d also add that it’s unwise to limit oneself only to FOSS because there are many truly useful, uniquely creative products that are not licensed as FOSS.

Furthermore, there are non-FOSS vendors who do operate for the greater good, and who do give consumers/ patients complete control of their own personal health information, even though their businesses require modest profit to survive.

So, it's important to keep one’s eyes and mind open.

Comment from SteveBeller at National Health Data Systems, Inc.

Regarding Open Source and Privacy:

Open source allows for third-party auditing of the source code for security flaws, either that be programming bugs or bad practices.

Comment from swaldren at American Academy of Family Physicians

Steven wrote

in terms of privacy, there’s nothing inherent in FOSS that makes it superior to all proprietary products. Yes there is. With FOSS you can trust-but-verify that the software respects privacy. With proprietary software you can just trust. Arguing that some proprietary vendors are trustworthy does not negate the fact that you have to trust their claims about privacy.

They rely on "trust" rather than "trust-but-verify".

I have taken this argument one step further in my blog post trust but verify and trust but fork.

Comment from ftrotter at Open Source Hacktivist

I agree with Fred comments on FOSS with two caveats:

1. Proprietary does not equal commercial. There is commercial value to services that can be provided. OSS allows for the incentive to the vendor to be tied to the service they provide. It also

allows for substitution in the market place, e.g. I don't like the service I am getting from WorldVista I can switch to Medsphere - just an example)

2. Open Source does not equal Vista. What I mean here is not the issue of FIOA vs. open source license. What I mean here is that there is a series of open source health-IT solutions out there to consider. For small ambulatory practices, I have not been convinced that VA Vista (or any of its OSS flavors) is a good choice for an EHR.

* Disclaimer: I have a start up OSS healthcare project *

Comment from swaldren at American Academy of Family Physicians

Regarding I’d also add that it’s unwise to limit oneself only to FOSS because there are many truly useful, uniquely creative products that are not licensed as FOSS.This is the useful vs. freedom argument that is typical of proprietary vendors. They try to get users to pay attention to how useful the software is, rather than focus on the fact that they have given up their autonomy by using it.

For people like me, freedom is more important than convenience. Thankfully, there enough people like me who are also working on making useful software that respects freedom by using a FOSS license, that soon there will be very little useful-but-proprietary software that does not have a useful-and-FOSS alternative.

Comment from ftrotter at Open Source Hacktivist

Regarding: Furthermore, there are non-FOSS vendors who do operate for the greater good, and who do give consumers/ patients complete control of their own personal health information, even though their businesses require modest profit to survive. The question is not whether proprietary vendors "support the greater good". The question is if the "greater good" would be better served with the same software under a FOSS license.

Proprietary vendors, by definition, are the only ones who have access to the source code of their Health IT software. Therefore their patients/consumers/users can only use the software in the way that the vendor programs the software. When a user wants to do something that the software does not do, they cannot change the program to do that. Your idea of "complete control" is like saying "I give my children the freedom to run where ever they want, as long as they stay in the park"

All companies, FOSS and proprietary alike, require profit to survive, but that profit should not be ensured by trapping users of Health IT software.

Comment from ftrotter at Open Source Hacktivist

Although is good, this discussion needs balance since few things are black & white.

Fred wrote: With FOSS you can trust-but-verify that the software respects privacy. With proprietary software you can just trust.I like your argument, although it is limited to products in which the vendor stores (or at least has access to) a person’s health data. This is not the case with standalone software or other types of products that a vendor sells and then no longer has direct access to them.

Fred also wrote: Proprietary vendors, by definition, are the only ones who have access to the source code of their Health IT software. Therefore their patients/consumers/users can only use the software in the way that the vendor programs the software.Three things: (1) There’s nothing I know that prevents a proprietary vendor from opening up to source code to a customer, (2) I’d bet that few customers have the ability to make enough sense of

any source code (FOSS and proprietary) to build in their own routines, and (3) the vendor can always enhance the software to accommodate different customer requests.

And Fred wrote: Your idea of "complete control" is like saying "I give my children the freedom to run where ever they want, as long as they stay in the park."I was referring to ways in which patients/consumers/users have control of their data at an “atomic level” such that only they can dictate what data is shared and with whom.

Comment from SteveBeller at National Health Data Systems, Inc.

I agree with the principles of open source, and always prefer transparency over obscurity. To Deven's point though, simply building an open source system does not guarantee privacy and confidentiality protections for consumers and other actors participating in the system. An additional layer of supporting, enforceable policies (governing the actions of participants) is necessary. From a consumer perspective, I also think it's highly unlikely (nor is it desireable) that the lay public could perform audits on the code to ensure appropriate safeguards, etc... I agree that someone should do it, but that raises the question of governance.

Open Source in Public Healthhttp://www.csinitiative.com/publichealth.php

There is a very interesting public health open source project in Utah <blockquote>The TriSano project, launched Sept. 16 under the auspices of the Collaborative Software Initiative, is initially working with Utah state officials to develop a system for monitoring and managing disease outbreaks.</blockquote>

According to an article recently in Govenment Health IT there are already a number of other States interested in the project.

One advantage of having public health drive the process is that there is already more of a collaboartive model in that sector and a shared mission. I am following the APHA meeting in San Diego this week so I will send some tweets via "twitter" and see if we can get more of them over here.

Sherry (A4H)

Comment from Alliance4Health at Alliance 4 Health

There is an intriguing set of comments here. But can someone who is not technologically savvy really look into the back end of a system to figure out what's going on? I don't think I'd know the first thing to look for, and if I can't figure it out, I can promise you my grandmother can't. Or are you promoting open source because someone will be able to monitor this (government, nonprofit watchdogs, etc.), which will help improve privacy protections? Just want to understand better.

Comment from dmcgraw at Center for Democracy & Technology

Regarding But can someone who is not technologically savvy really look into the back end of a system to figure out what's going on?The question is best met with an analogy.

Probably, you are not qualified to service your car, your home air-conditioning system, or your plumbing. However, there is a whole market of people that can help you with projects surrounding your car and home. What you, the novice have is ownership, you hire expertise. Suppose you thought it was a good idea to have a toilet on the roof (scrubs), since you own the house, you only need to convince one plumber that this is a good idea. Since you are paying customer you will have no trouble doing this.

A proprietary Health IT system is more like living in an apartment complex or hotel. All changes to the plumbing must go through the management. That does not mean that the will not change the plumbing. It means they will change the plumbing *when it becomes profitable to do so*. Generally that means you get a toilet on the roof only when 1000 other people think its a really good idea.

The problem is that in healthcare, the strange, one-off feature request is the norm. That makes proprietary solutions ill-suited.

Again, the basic answer to your question is "You need ownership, not expertise" FOSS gives you ownership which changes your relationship with expertise in a positive way.

Comment from ftrotter at Open Source Hacktivist

This all depends on (a) the kind of relationship a customer has with a proprietary vendor; (b) the dedication, competence and responsiveness of the FOSS development team; and (c) the benefits derived from their respective IT products. Thus, lumping all proprietary solutions into one basket and all FOSS into another, simply isn't justified, imo.

Comment from SteveBeller at National Health Data Systems, Inc.

But "(a) the kind of relationship a customer has with a proprietary vendor" is always exclusive. It might be good, it might be bad, but whatever it is, there is little a customer can do about it.

Whereas "(b) the dedication, competence and responsiveness of the FOSS development team" can vary wildly, but because it is not exclusive it does not matter. If your FOSS support organization sucks, you just fire them, and get someone else.

Comment from ftrotter at Open Source Hacktivist

Fact: HIT is highly biased towards proprietary solutions. Fact: FOSS in health care is nascent at best. Fact: the cost to develop enterprise IT is huge, and is a significant barrier to the creation of FOS.

Open source offers advantages over proprietary software like facilitating interoperability. FOSS will play a growing role in HIT but a better solution would provide the means to include conventional software business models in a broader industry solution, not exclude them. Comment from TimGee at Medical Connectivity Consulting

I agree with Tim. We can even take interoperability as a case in point: A socially compassionate vendor offering an innovative proprietary solution for data exchange between disparate systems, which is more cost-efficient than existing FOSS (or other proprietary) solutions, is actually better for the country (humanity). So, enabling FOSS and proprietary software to live together cooperatively makes more sense to me than excluding either.

Comment from SteveBeller at National Health Data Systems, Inc.

I am a doctor and have an EHR (electronic health record). All I know is that the hospital system, the 3 different labs I work with, the radiology dept, etc all use a different system that will not "talk" with by system unless I get a bridge and pay extra for the uplink to be maintained. WHY can't it all talk together? Why am I charged extra if I want it to? I can go anywhere on the internet and it understands it all.

Comment from stargirl65

Open source was a key factor in the VA's transformation into the best hospital system. This model is being replicated in the private sector. Midland Memorial hospital in Texas implemented VistA over

the past three years. It became one of only 14 HIMSS Stage 6 hospitals in a fraction of the time, and for a fraction of the cost. As for VistA support, there is now an entire industry behind it. More details in my newsletter, VistA & Open Healthcare News <http://tinyurl.com/6ae8y9>.

Comment from ramaduro

regarding stargirls comments>

You probably bought a proprietary EHR system. That means that, for the most part your vendor dictates the cost of "bridges" and everything else.

But thankfully you do not have to "buy the bridge", you can use Mirth, an open source bridge, and it will probably do what you need. If not, it will soon.... IT may be expensive, but if it is it will be a reflection of the work involved rather than an arbitrary price.

Comment from ftrotter at Open Source Hacktivist

RE: A socially compassionate vendor offering an innovative proprietary solution for data exchange Until that company goes out of business, and its software becomes abandon ware. Or the company is bought, and the software is subject to forced upgrade. Your idea fails the seven generation test. Because it focuses on the symptom of the problem, rather than the root cause.

Comment from ftrotter at Open Source Hacktivist

regarding ftrotter

you are right. my system does talk to my lab with HL7 protocols. I suppose the MIRTH would help if I even knew where to start. I have another lab to hook up to, want to do patient portals, and also e prescribing but these all add monthly fees to my base monthly support fee. The base covers the program and annual updates (diagnosis codes, drug names, charges etc) plus program improvements and is already expensive. EHR's do NOT save money.

Comment from stargirl65

In response to stargirls comment about interoperability, an alternative to all this confusion is to use a decentralized node-to-node (peer-to-peer) architecture for exchanging data between disparate systems. The problem is that our healthcare system is locked into a complex, costly, conventional, centralized paradigm.

Comment from SteveBeller at National Health Data Systems, Inc

In response to Fred’s last comment, a socially compassionate vendor with an proprietary solution should open the source code if going out of business and should make sure the company purchaser would maintain its virtues. Likewise, a reputable FOSS vendor should guarantee that there will always be developers willing to support their product. In other words, don’t simply damn all proprietary nor embrace all FOSS products; determine which ones are best and insist on a responsible license.

Comment from SteveBeller at National Health Data Systems, Inc.

Past experience proves vendors can't give what clinicians need. We simply reject most tools they've created. As a RN and EMR Analyst, I submit to you that software development is like Science by nature because it's collaborative. Medicine and Science are symbiotic. Likewise, IT will be too if it is kept open. VA VistA has many modules created by medical personnel scratching their own itch.

Support for open standards is key.

Comment from jesran at CHLUG

While the Federal government has not taken a definitive stance on Open Source in Health IT, it has taken the role of setting interoperability standards for Health IT software. (ONC's CCHIT body) Even if the software is not open source - if certified by CCHIT, data would be interoperable with other certified systems.

Regarding the question as to why there are fewer takers of VistA - VistA was built in the 90s using an old language - MUMPS.

Comment from rleung at CGI

I agree that interoperability standards are important, for both FOSS and proprietary software, although it’s a far more complex issue than most realize (see a series starting at this link). And standards ought to evolve continually by seeking and adopting more cost-effective alternatives. This means we need very flexible software systems that can readily adapt to changing standards.

And about VistA, I know a company that ported it to a Windows version.

Comment from SteveBeller at National Health Data Systems, Inc

The key drawback to VA VistA, and almost all EMRs in general, is that they are not web-based. If clinicians could log in from any thin browser they might uptake EMR more enthusiastically. Look to web-based open source projects like OpenEMR (http://www.oemr.org) for traction. Alternatively, VistA may bloom a web-client in the future. As for proprietary vendors the web-based clients still seems like vaporware, i.e. GE Centricity and Eclipsys Sunrise.

Comment from jesran at CHLUG

Regarding rleung's comment about CCHIT and Interoperability:

I would recommend looking at the actual interoperability requirements for CCHIT. There are not very many and they are the standard forms that are widely available ( Lab and eRx). Also the software on the other side of the connection (e.g. laboratory and pharamcy) are not covered by CCHIT.

Comment from swaldren at American Academy of Family Physicians

Re EMRs not being web-enabled ...

Web-based/thin client vs. desktop/rich client: Different benefits in different situations. As with OS and proprietary applications, one shoe does not fit all. And note that certain application server technologies actually enables someone using a browser on the web control to control a desktop application residing a web server.

Comment from SteveBeller at National Health Data Systems, Inc.

Great idea, great comments,

In the open-source debate I would put more stress on:

userfriendelyness (+removing bloat) and freedom of flexibility and connectivity, which lead to more employee efficiency and thus better customer-service

Some usefull links:

Open Source Healthcare (zorgbeheer)

Statement of Matthew King (House of Representatives)

Benefits and Limitations of FOSS EHR (CHCF - .pdf)

Web2.0 and Social Networking come to Healthcare (Newsweek)

Open source versus commercial web software (isite design - on a light note)

Comment from bartcollet at zorgbeheer

FOSS isn't the core issue. I support the FOSS direction but wish to acknowledge that the issue is support for enterprise applications as much as it is holding an open source license. The ownership of data in today's hospital lies with the hospital even though they use a vendor's system to capture and manage patient data.

We need laws that protect patient privacy by making transparent any agreement a vendor seeks to arranage with a health care organization for the purchase or use of the personal health data held by the institution. I think HIPAA provides some protection against the abuses of the past. There probably needs to be more explicit legislation addressing the sale of data, whether it is de-identified or not.

The issue of selling data has nothing to do with open source. As a former employee of a major HIT vendor, I would argue that vendors are not in control of patient data. Successful vendors make money by getting the client to assume ownership for the system, to rely on themselves to support it. Yes, vendors maintain backdoors into clinical systems to make sure they can support it when called to and/or to shut if off if the client is in default of the contract, but that access does not represent data control. Clinical information systems have made large advances because there was a profit to be made by building a better mouse trap. If FOSS systems do evolve to eventually match the power of today's HIT systems they will win out in the market place. Brazil is implementing a FOSS health information system that apprears to be brilliantly executed, built around modern tools, able to use industrial strength database products and even includes population health in its overall design. If systems like this continue to emerge their power will be felt in the US.

Comment from daross at Public Health Informatics Institute

Clearly open source would be more efficient than closed source, if programmers have good motivation and enough time. To achieve this, an unbureaucratic framework seems necessary which makes it financially attractive to create open source code according to the needs of the community, because today usually money seems to be attractive.

Comment from wolfgang at UKSH

I am not familiar with the details of the various software programs which will link various parts of the medical system and provide interoperability. I do understand the value of this for physicians, hospitals, laboratories, etc.

However, I don't think patients want to be the 'owner' of all this data, responsible for sending it to the parties who need it and determining who these are. This is part of the flaw in thinking that patients should become the owner, and discloser, of all their medical information.

When it comes to mental health information, there are special problems. HIPAA has an exception about information being shared with patients if the clinician thinks it might cause harm. This is a significant concern for mental health clinicians when the patient is not ready to heat the specifics of how the clinician has diagnosed them. Patients maybe aware that they feel understood by the clinician without knowing the way the clinician understands their problems for quite awhile.

Another concern I have about making the patient the owner of his/her records is how this will be implemented by people who may be homeless, incarcerated, unable to understand the disclosure

process, or otherwise off the grid of being able to keep track of their own information.

Laura Groshong, LICSW, Director, Government Relations, Clinical Social Work Association

Comment from lwgroshong

Open source is essential. I have worked in proprietary systems and it is to restricting to be helpful to all the parties that need to be involved.;and there are many parties that need to be involved in this health care coordination of information.

Comment from gerrigray at NAMI

Laura makes good points. But I don't think anyone is making the case that consumers should control every piece of data used by their healthcare providers. In fact, as things now stand, many states (including mine, NY) don’t even allow consumers get their own blood test results; they must obtain it through a physician. Any way, it would be foolish for a consumer to dictate whether or not their primary care doctor or appropriate specialist should be allowed to view their lab results, imaging studies, etc. as it may be life threatening decision for which consumers are ill-prepared to make. However, they should have control over whether their employer (or others) gets to see this type of health information.

Most mental health information, on the other hand, is not life threatening, except, perhaps, suicidal and homicidal ideation/tendencies, knowledge of which providers are already required to report to authorities (along with and sex and physical abuse). But no one is forcing a consumer to reveal such ideation/tendencies if he or she is unwilling to do so.

For all other mental health information--including one’s cognitions (thoughts, perceptions), emotions, behavioral tendencies, psychosocial history and relationships, etc.,--I suggest that consumers should have full ownership/control over whom, if anyone, gets to learn about it.

And if someone doesn't have the capacity to make determinations about sharing the health information, a health proxy (or other “trusted partner”) could assist them.

So, to me, it’s not about having a consumer track and control all one’s health information by disallowing one’s healthcare provider from accessing essential information needed to make life-saving and wellness decisions. Instead, it’s about having control over who gets to see one's mental health information, and who, other than the physician(s) involved in one's care, is authorized to view one's biomedical information.

Comment from SteveBeller at National Health Data Systems, Inc.

Regarding Yes, vendors maintain backdoors into clinical systems to make sure they can support it when called to and/or to shut if off if the client is in default of the contract, but that access does not represent data controlWrong. It obviously does mean data control, what you mean is that this data control is typically not abused. But that is just what your proprietary company did. Its great that your company did not abuse its position of power and control. But that does not mean that it is not a position of power and control. Just because one master was good to one slave does counter the argument that the master/slave relationship is fundamentally immoral.

Dr. Notes is a perfect example of the "bad master" that demonstrates that the whole type of relationship is not equitable.

Comment from ftrotter at Open Source Hacktivist

In response to gerrigray's comments, I agree that open source is essential. But not all proprietary systems are too restricting to be helpful to all the parties that need to involved in the coordination of

health information. I offer as evidence a system I've been working on for many years that is specifically designed to forever evolve through collaboration with all stakeholders--see a series of blog posts starting at http://curinghealthcare.blogspot.com/2008/04/personal-health-profiler-part-1.html

Comment from SteveBeller at National Health Data Systems, Inc

I think Fred and other supporters of FOSS in health care are making unfounded assumptions about the history and market dynamics of software in health care. Health care software vendors have always been held to a higher standard. Health care institutions, for the most part, adhere to the “first, do no harm” mantra (which is not part of the Hippocratic Oath, by the way.) They are extremely risk averse. Since we are all consumers of health care services at one point or another, we rely on this being true. It’s inherent in the psyche of most health care professionals. No one wants to be responsible for making a decision that puts patient safety at risk. They, in turn, demand that their vendors show the same commitment towards minimizing risk in the products and services that they provide. The only “right” that they demand is the right to have a system that works and is error free.

Many health care institutions have been using automated systems for over 4 decades. The institutions are quite sophisticated and where they lack sophistication, they hire consultants. This is a very competitive industry and smart negotiators will usually get what they want, e.g. putting source code into escrow has become standard procedure. Over the years, many of the traditional, mainstream vendors have allowed access to the internals of their system, admittedly, often with great reluctance, but they do it. They are reluctant not because of fear that someone will steal their code but because they feel that unqualified users can break the integrity of the system and put patient safety at risk.

FOSS software in health care has yet to establish a successful track record, and no, VistA is not FOSS even though its development history looks very similar. If one “insists” on FOSS in healthcare their choices become very limited indeed and they lose the “right” to choose a solution that they feel satisfies their business needs.

Comment from MikeGinsburg at DSS, Inc.

Earlier in this discussion I read:

Fact: HIT is highly biased towards proprietary solutions. I don't know that this is true, since HIT (Health Information Technology) is defined by each individual. What some people call HIT would be totally unacceptable to other people. So the term is vague and only means what you think it means. Regardless of this, most Information Technology is biased towards proprietary solutions, because just using a computer isn't generally Information Technology. In many people's minds, just running a website or doing business using a computer isn't generally IT, as IT is defined to include a group of people either as a separate business or a separate department who are dedicated to making sure that using the computer is easy for everyone else in that company. Many people equate proprietary software with control, and feel they can't make money as a business, or can't get allocations as a department, if they don't maintain control. So the above fact is true because the more general statement is also true i.e. that all IT is highly biased towards proprietary solutions, not just HIT.Fact: FOSS in health care is nascent at best. according to one defintion: nascent is 1. [a] coming into existence. I am confused by this statement, and perhaps a little frustrated by it. Source code availability has been a strong aspect of health care computing at least as far back as the 1970s. It is true that the term "Free and Open Source Software" is a new term, but the concept that health organizations shared code with each other, legally and legitimately, has been around a very long time. One of the social factors that

pushed the ANSI standard for MUMPS is that people wanted to share code, and couldn't do it because the various vendors were creating implementations that were incompatible. Also, the idea of "public domain" work by the government, again allowing easy access to source code, and other publications of the government is old enough that it is written into copyright law as a specific detail. I would hope that those sharing the idea of "nascent HIT" just are talking about the idea as only just coming into existence within their own experience, not within the industry as a whole.

Fact: the cost to develop enterprise IT is huge, and is a significant barrier to the creation of FOS.I agree that enterprise IT is a huge cost. However, I would expect rather than a barrier, that it would actually be an incentive to the creation of FOSS. Basing your solution on a shared model may be the only way you can get a dependable, reliable, and broad coverage of the field of medicine. Elevating code from locally useful with one or two users, to being used by a large group of people takes time and money. When the large group of people is actually a large number of small groups of people, the only solution might be FOSS, as a proprietary solution can only be advanced by a single entity that has to bear the cost of making the software available to each one of them. This can only happen when the profit/cash-flow of gaining each adopter allow the process to be self-sustaining. If the cost of delivery to one possible adopter is greater than the funds coming back from that delivery, how can you sustain the process? With FOSS, you have multiple delivery agents, but a single expense of development that is shared among all the agents.

With the additional comment :

Open source offers advantages over proprietary software like facilitating interoperability. FOSS will play a growing role in HIT but a better solution would provide the means to include conventional software business models in a broader industry solution, not exclude them.I generally agree that FOSS makes interoperability easier, but the interoperability problem is actually one of information flow and knowledge representation. It does no one any good if you have a well defined transport mechanism, but you have no way to guarantee that the information you are sending is accepted and interpreted in the way that you meant on your system. The hard part of interoperability is determining where the payoff is for the effort to describe what you are doing completely enough so that you have a good hope that this can happen. There are multiple proprietary and FOSS technologies availabe to allow someone to describe the meaning. The ISO Common Logic standard, CycL (at www.cyc.com), and OWL-Full are good beginnings. Augmenting CCR/CCD with these description technologies to say what the sending system "meant" by the CCR/CCD terms goes a long way. The interoperability issue, as was stated earlier, boils down to cost as much as technology. I'll leave the social and privacy costs to a later posting, and to the other esteemed collegues on this site.

Comment from whitten

Twenty-six years ago I was introduced to what was then DHCP from the Veterans' Administration. Because is was both free and open we were able to implement it in the Family Practice clinic at UC, Davis and modify it to meet our needs. I'm currently involved in doing the same with VistA at a large Mental Health facility in Washington state. In neither place could we have begun to afford the functionality and flexibility of the VA solution if we had been obliged to use commercial, closed source software. Indeed, in all these years I've seen precious few industry applications that even came close despite sky-high prices for installation, maintenance and customizing. Health care cannot afford to continue paying large sums for marginal applications that we cannot modify and adapt as we need..

Comment from mmendelson