You are on page 1of 12

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 Reynolds
Alliance4Health
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 Health
http://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 control
Wrong. 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

You might also like