goal and objectives that software products must comply with. Initially these are
necessary but as is often the case they are used defensively to ward-off competition,
improvements and new developments.
Similarities exist with the development environments within especially large IT corporations
where competition, improvements and new developments put at risk established
products and services. An example would be attempts to develop a product that
in some way compets with an existing product.
Having participated in such a development, even a successful one, the conclusion was
quickly reached that the subsequent conflict was due mostly to friction within the
internal structure and technical obsolescence.
It appears that organizations such as the NHS can be subject to internal forces that
would create barriers that would disguise internal events. My guess is that the conflict
over the paper: /Open Source Software and the NHS /has been elevated to the
barrier level.
The success of OSS and related efforts within any organization depends upon the
internal organization and the /relevant players/ plus external pressure from appropriate
sources. External pressure receives support from /acceptable alternatives/.
Acceptable alternatives include availabale fully supported and functional products and
services that endorse and integrate OSS. Favorable Cost-Performance evaluations
often substantially impact the acceptance of OSS.
Viewed through a prism that separates groups within the NHS, there appear to be a:
1)Patient group
2)Practitioner group
3)Services group
4)Administration group
5)Executive group
Each group can have multiple /Support Groups/.
My guess is that the conflict here is primarily between the /Services /and /Administration/
groups; all too common a location.
What does OSS offer each group?
To get a group involved in the resolution of issues there has to be a '/stake/', or reason,
for the group to give up its /closet /position and enter the fray.
_Patient Group_:
Generally even superficial knowledge of OSS is missing. However, OSS enabled
products and services can be impressive and quickly build support. My suggestion,
and interest, is to build these and solve Patient-related problems.
_Practitioner Group_:
The Healthcare work-horses need help and OSS enabled products and services can
turn a benefit to the individual, sub-groups and the community. In a /top-down/
organization members may be faced with difficult struggles to achive integration.
Developing OSS products and services for this group and linking them to those
developed for Patients has a major bonus, i.e., the enhancement of the
Patient-Practitioner interface, or in other words, expanding Patient-Practitioner
communications.
Since the NHS exists (theoretically) to service this communications environment,
getting the Patient and practitioner on the same side and supporting OSS is a good
thing.
Services Group:
Most services groups are attached to organizations to provide a well-defined service
and no more. As an example, there has been relatively little advancement in
Automatic Tellar Machines, other than security, for some time. They perform a
well-defined service reliably.
A Services Group may be a strong supporter of OSS for an obvious set of reasons,
but improvements and modifications suggested by this group alone have a slim
change of succeeding unless the existing service is totally unusable.
_Administration Group_:
A smoothly operating, manageable organization is a common goal of this group.
Modifications and changes, even those that would present substantial benefits, may
be unacceptable since actual and potential impacts on the current operation can be
adverse.
As an example, foundation hospitals may appear to be a good idea at some levels
in the NHS, but certain factors and events, whether or not anticipated, may prove
them undesireable.
Advocates of OSS must understand and work with this group to mitigate adsverse
impacts and produce successful integrations.
_Executive Group_:
Decisions here can take any project into the sea or over a cliff. My impression is they are
very sensitive to the Patient group and somewhat sensitive to the Practitioner group.
This brings me back to these two groups. OSS enabled products and services have to
be accepted, effective, efficient, meaningful, productive and usable. Throwing OSS
at any group along with verbal justifications does not convince many people of its
inherent current and future advantages.
A good paper!
Colin Smith's paper is a good one and reflects what appears to be a reasonable position
by the NHS. I would like to add the following:
-OSS enable Healthcare products and sesrvices do not necessarily have to conform to the
NHS environment (the world market is personable acceptable)
-Within the NHS there should be OSS speciality-focused products and services
-/One-size-fits-all/ usually doesn't and may result in serious conflicts in some areas
-Select companies that develop OSS enabled products and services is acceptable, but
personal preference, especially in Healthcare, is specialty-focus and small community
development using available OSS products and services.
_NOTE:_
If 30 Patients or 30 Practitioners gather in a room to design a web-based product or
services, what would the various graphical presentations look like? Would there be
complete agreement? How many changes would occur within the first six months?
What are the Information flow?
Substitute software developers for the Patients and Practitioners and re-run the
questions.
My guess is that templates and custom design might be significantly more successful.
Bottom Line:
1)The NHS is an organization organized to produce Healthcare products and services
2)The NHS is similar to many other organizations/companies, especially those that
support complex products and services
3)People administer the NHS and can justify prior decisions
4)The ultimate beneficiaries significantly impact NHS decisions
5)OSS enabled products and services need to be developed in a competitive environment
6)OSS developers need to understand the organizations involved in any undertaking
and adapt products and services
7)Pulling the paper is a classical response to an organizational threat and may be justifiable
8)The ultimate impact on OSS enable products and services is most likely ZERO.
Regards!
-Thomas Clark
Adrian Midgley wrote:
http://www.theregister.co.uk/2004/10/25/nhsia_vapes_oss_paper/
The archive version is here, and in various places such as a Spanish health IT site where it is, as one would expect, taken seriously. Unlike its reauthors.
http://web.archive.org/web/20040204194259/http://www.nhsia.nhs.uk/text/pages/features/i_250202.asp
