Transcript of Paper wsl format
- 1. Developing future-proof open source information systems for
healthcare Abstract. Healthcare information is full of context. The
current design approach to healthcare information systems (HIS)
doesn't provide a facility to transfer that context when the data
is exchanged with other systems. This paper aims to review the
scientific literature regarding success and failures in HIS
implementation and integration projects and to present the
fundamentals of the development of a future-proof HIS, the Open
Source Health Information Platform (OSHIP). 1. Introduction It has
long been recognized that there is an inherent need for full
semantic interoperability between information systems that are used
to manage healthcare information [Lopez and Blobel 2009], [Hovenga
2008], [Ma et al. 2007], [Engel et al. 2006], [Nykanen and Karimaa
2006], [Rossi Mori and Consorti 1998]. Thus, in the broadest sense,
a Healthcare Information System (HIS) is any information system
that maintains and manages information affecting the health of a
person or population [Wikimedia Foundation, Inc. 2009]. Healthcare
information has many complex temporal and spatial components and
then mix in the fact that medical and healthcare knowledge changes
rapidly. It is widely accepted that not only the medical condition
of a person is significant to their health but a host of social,
economic and environmental conditions place direct and indirect
effects on personal and population health [Ghosh 2007], [Norgall et
al. 2006], [Ruland and Bakken 2001], [Starr and Starr 1995]. This
is the crux of why HIS re so complex and typically 'purpose-built'
without any real interoperability built into them. While the
science of information design encompasses much more than
computerized information systems, the aim of this paper is
discussing the computerization of healthcare information. Expressed
in its simplest terms, the current approach to developing an
information system follows these steps: (a) requirements gathering,
using one or more of the many standard methodologies; (b) systems
analysis, in order to determine from the requirements the systems
involved to meet the needs of the requirements; (c) data modeling,
which means building a model of the data elements available from
the information sources (systems) to meet the needs of the
requirements; (d) implementation of the data model in some
persistent storage facility; (e) implementation of the software
required to add, edit and manage the storage and use of the data
elements defined in the model; and (f) maintenance of the system
then entails modifying the data model and the software as the
requirements change. This process has proven robust and reliable
over many years and millions of software applications being
deployed when sound software engineering principles are adhered to
in the entire process [Covitz et al. 2003], [Xu et al. 2001],
[Kanoui et al. 2000]. Looking into how typical applications handle
the information management aspect a bit more, we see how an
application like this actually manages information. We see that the
data elements are discretely persisted and the software and/or data
management layer manages the relationships between these data
elements.
- 2. Data elements are simply data elements. It is their
relationship to each other and their relationship to the user, via
input and output design in each application, which gives them their
semantic context in order to create information from their
existence [Schuurman and Leszczynski 2008], [Rector et al. 2002],
[Degoulet et al. 1998]. As an example of the data versus
information conundrum, let us say that we have a data element of
the integer 102. That integer can represent a systolic blood
pressure measurement, a heart rate, a body temperature, and so on.
The validity, reliability and clinical significance of this data
element necessarily depends upon the context (that includes, e.g.,
units of measurement, patient position, point of measurement,
device used, demographic data from the patient, etc.). There are
certain elements of a database management system that lend to this
context, but this feature is a part of the software layer, not the
actual persistence of the data. While it is often conceived that
table names and column names in, for example, SQL databases,
provide this functionality, it is important to consider situations
when the data needs to be exchanged with an application that uses a
hierarchical or object or XML database. In this case, there is no
standard way to do this translation. In fact, even between
applications based on SQL databases, the migration of data must be
performed on a case-by-case basis where the table and column names
are not the same and a custom translation must be built for every
case [Huang et al. 2005], [Stitt 1995]. Certainly the development
of standardized HL7 messages was a big leap forward in information
exchange in healthcare [Tracy and Dougherty 2002], [Hettinger and
Brazile 1994]. Two big drawbacks to this approach are that the
message formats had to be made very generic in order to accommodate
systems that may or may not have all of the data elements in a
specific message and this exchange process requires a manual
mapping on both the sending and receiving ends for each message to
their local database. An entire industry developed around providing
these mapping engines and the expertise to setup the complex
mapping routines. Even if the development of the message formats
were defined by domain experts, the mapping is typically performed
by software experts, not clinicians [Hiroi et al. 2007], [Lin et
al. 2006], [Ma et al. 2005], [McDonald et al. 2003], [Kinsey et al.
2000], [Ma 1995]. It is important to highlight that information
should be universally available inside the healthcare sector, from
professionals at the point of care up to epidemiologists, policy
makers and economists [Hartz and John 2009], [Iglehart 2004].
Nevertheless, the immense amount of standardized data sets built
into applications published on literature are almost entirely made
based on the interests of specific research projects [Elisa and
Heimar 2006], [Tierney et al. 2006], [Innes et al. 2001],
[Studnicki et al. 2001]. It is not possible for every healthcare
application to incorporate all the minimum data sets being
requested by these competing interests. Even if it happened, the
real semantic context of collected data that results in information
is in the software of the original application, not in the data
itself [Mead, 2006]. Completely controlled environments like the
U.S. Veterans Administration and Kaiser-Permanente have
demonstrated that a centrally controlled approach to HIS
development and management using current approaches does work and
does reduce adverse events as well as improve access to patient
information at the point of care [Protti and Groen 2008], [Raymond
2005]. The evidence exists that interoperable HIS are a benefit to
those organizations as well as to their patient population [Brennan
et al. 2008]. However, even in countries with nationalized
healthcare services it is still a challenge to mandate a common
data set for all HIS that meets the needs of all
- 3. healthcare information users [Halamka et al. 2005], [Suselj
and Cuber 1998]. So, we believe that what is needed is a new way of
thinking about complex information systems. The objective of this
paper is to present an implementation of an information model that
addresses those challenges in healthcare information. 2. Method As
an analogy, the idea of Lego blocks is suggested. A box of these
blocks contains various sizes and shapes of components designed to
work together to form objects. The kit comes with instructions so
that a certain sub-group of the blocks can be used to build a
specific object (e.g., a truck). Some of those same blocks can be
used in combination with additional ones, to build another specific
object (e.g., a helicopter) according to a different set of
instructions. There are other instructions to build various other
objects all based on the same set of common blocks, all according
to the restrictions described in the instructions. In healthcare
information, we define a Common Reference Model (CRM) as the common
set of healthcare information blocks implemented in software that
represent clinical concepts as an information instance, and the
instructions about the representation of each clinical concept, as
Clinical Knowledge Model (CKM). If the CRM is abstract enough then
it could be implemented in any object- oriented language on any
hardware platform. It therefore provides the freedom of use and
creativity to meet the needs and desires of application developers.
The CKM units (instructions) can be described by the domain experts
for each concept because they exist as constraint descriptions of
the very broad based CRM, not existing in software themselves, but
simply informing the software about what they are representing. In
fact, the CKM units describe themselves completely with their
entire semantic context. Since they exist as data instances and not
lines of software code, they can be exchanged with other
applications based on the CRM without any loss of semantics, and be
persisted in any type of data management system. CKM units can also
be queried with a standardized query language so that even the
queries only have to be built one time, since the data structure is
standardized. Additionally, for every change either of the
healthcare science or management, a new version of a specific CKM
unit can be adapted from the existing version, with no need to
change the software nor is there any loss to the semantic integrity
of the existing data. The openEHR specifications are designed
following those principles, and it has been proven in multiple
programming languages using multiple persistence layers and
hardware platforms, and also provides definitions for service and
support layers in order to allow the development of real healthcare
applications [Beale and Heard 2007]. The Open Source Health
Information Platform (OSHIP) is the reference implementation of the
openEHR specifications release 1.0.2 in Python language, heavily
dependent on the Zope Component Architecture (ZCA) version 3.4.x.
It is a library combined with other open source components designed
to facilitate the creation of interoperable healthcare
applications. The persistence (storage) layer is completely
independent of the reference model and component libraries. Any
type of database can be used, such as object database or any SQL
databases, but a native Python object database such as the Zope
Object Database (ZODB) provides transparent object persistence,
which eliminates the issues of mapping objects to SQL tables. OSHIP
itself
- 4. uses the ZODB for the Archetype Server and Terminology
Server. The current status of development of the project can be
found on http://launchpad.net/oship. 3. Conclusions The approach
for designing HIS here presented requires the adoption of a new way
of thinking, but not letting go of sound software engineering
principles. In fact, this approach enforces the sound principles of
separation of software and data. Of course high quality, rapidly
delivered information is needed by healthcare decision makers; but
the mainstream approach on this matter leads to wasted time and
effort and even poor quality results due to a lack of
interoperability across applications causing misinterpretation of
existing data. The context currently lies in the software, where it
cant be exchanged. There is a need to return it to the data, where
it belongs. References Beale T, Heard S (eds.). openEHR
Architecture Overview Revision 1.1. London, 2007; openEHR
Foundation. Brennan DM, Holtz BE, Chumbler NR, Kobb R, Rabinowitz
T. Visioning technology for the future of telehealth. Telemed J E
Health 2008; 14: 982-5. Covitz PA, Hartel F, Schaefer C, De
Coronado S, Fragoso G, Sahni H, Gustafson S, Buetow KH. caCORE: a
common infrastructure for cancer informatics. Bioinformatics 2003;
19: 2404-12. Degoulet P, Sauquet D, Jaulent MC, Zapletal E, Lavril
M. Rationale and design considerations for a semantic mediator in
health information systems. Methods Inf Med 1998; 37: 518-26. Elisa
R, Heimar M. Nursing minimum data set: A literature review. Stud
Health Technol Inform 2006; 122: 734-7. Engel K, Blobel B, Pharow
P. Standards for enabling health informatics interoperability. Stud
Health Technol Inform 2006; 124: 145-50. Ghosh T. Structuration and
sensemaking: frameworks for understanding the management of health
information systems in the ICU. Stud Health Technol Inform 2007;
130: 45-57. Halamka J, Aranow M, Ascenzo C, Bates D, Debor G,
Glaser J, Goroll A, Stowe J, Tripathi M, Vineyard G. Health care IT
collaboration in Massachusetts: the experience of creating regional
connectivity. J Am Med Inform Assoc 2005; 12: 596-601. Hartz S,
John J. Public health policy decisions on medical innovations: What
role can early economic evaluation play? Health Policy 2009; 89:
184-92. Hettinger BJ, Brazile RP. Health Level Seven (HL7):
standard for healthcare electronic data transmissions. Comput Nurs
1994; 12: 13-6. Hiroi K, Ido K, Yang W, Nakaya J. Interface
analysis between GSVML and HL7 version 3. J Biomed Inform 2007; 40:
527-38. Hovenga EJS. Importance of achieving semantic
interoperability for national health information systems. Texto
& contexto enferm 2008; 17: 158-167.
- 5. Huang EW, Wang DW, Liou DM. Development of a deterministic
XML schema by resolving structure ambiguity of HL7 messages. Comput
Methods Programs Biomed 2005; 80: 1-15. Iglehart JK. Global health
policy and free access to information. Health Aff (Millwood) 2004;
23: 7-8. Innes G, Murray M, Grafstein E. A consensus-based process
to define standard national data elements for a Canadian emergency
department information system. CJEM 2001; 3: 277-84. Kanoui H,
Joubert M, Maury G. A semantic-based kernel for advanced health
information systems. Med Inform Internet Med 2000; 25: 19-43.
Kinsey TV, Horton MC, Lewis TE. Interfacing the PACS and the HIS:
results of a 5- year implementation. Radiographics 2000; 20:
883-91. Lin IC, Hsu HM, Liu CT. A HL7 transformer application for
vaccination data report. Int J Electron Healthc 2006; 2: 117-31.
Lopez DM, Blobel BG. A development framework for semantically
interoperable health information systems. Int J Med Inform 2009;
78: 83-103. Ma C, Frankel H, Beale T, Heard S. EHR query language
(EQL) - a query language for archetype-based health records. Stud
Health Technol Inform 2007; 129(Pt 1): 397-401. Ma H, Rolka H,
Mandl K, Buckeridge D, Fleischauer A, Pavlin J. Implementation of
laboratory order data in BioSense Early Event Detection and
Situation Awareness System. MMWR 2005; 54(Suppl): 27-30. Ma H.
Mapping clause of Arden Syntax with HL7 and ASTM E 1238-88
standard. Int J Biomed Comput 1995; 38: 9-21. McDonald CJ, Huff SM,
Suico JG, Hill G, Leavelle D, Aller R, Forrey A, Mercer K, DeMoor
G, Hook J, Williams W, Case J, Maloney P. LOINC, a universal
standard for identifying laboratory observations: a 5-year update.
Clin Chem 2003; 49: 624-33. Mead CN. Data interchange standards in
healthcare IT - computable semantic interoperability: now possible
but still difficult, do we really need a better mousetrap? J
Healthc Inf Manag 2006; 20: 71-8. Norgall T, Blobel B, Pharow P.
Personal health - the future care paradigm. Stud Health Technol
Inform 2006; 121: 299-306. Nykanen P, Karimaa E. Success and
failure factors in the regional health information system design
process - results from a constructive evaluation study. Methods Inf
Med 2006; 45: 85-9. Protti D, Groen P. Implementation of the
Veterans Health Administration VistA clinical information system
around the world. Healthc Q 2008; 11: 83-9. Raymond B. The Kaiser
Permanente IT transformation. Healthc Financ Manage 2005; 59: 62-6.
Rector AL, Rogers J, Roberts A, Wroe C. Scale and context: issues
in ontologies to link health- and bio-informatics. Proc AMIA Symp
2002; 642-6.
- 6. Rossi Mori A, Consorti F. Exploiting the terminological
approach from CEN/TC251 and GALEN to support semantic
interoperability of healthcare record systems. Int J Med Inform
1998; 48: 111-24. Ruland CM, Bakken S. Representing patient
preference-related concepts for inclusion in electronic health
records. J Biomed Inform 2001; 34: 415-22. Schuurman N, Leszczynski
A. A method to map heterogeneity between near but non- equivalent
semantic attributes in multiple health data registries. Health
Informatics J 2008; 14: 39-57. Starr P, Starr S. Reinventing vital
statistics. The impact of changes in information technology,
welfare policy, and health care. Public Health Rep 1995; 110:
534-44. Stitt FW. A standards-based clinical information system for
HIV/AIDS. Medinfo; 8(Pt 1): 402, 1995. Studnicki J, Luther SL,
Kromrey J, Myers B. A minimum data set and empirical model for
population health status assessment. Am J Prev Med 2001; 20: 40-9.
Suselj M, Cuber S. Smartcard - a vehicle of access to the health
care services. Stud Health Technol Inform 1998; 52(Pt 1): 31-5.
Tierney WM, Beck EJ, Gardner RM, Musick B, Shields M, Shiyonga NM,
Spohr MH. Viewpoint: a pragmatic approach to constructing a minimum
data set for care of patients with HIV in developing countries. J
Am Med Inform Assoc 2006; 13: 253-60. Tracy WR, Dougherty M. HL7
standard shapes content, exchange of patient information. J AHIMA
2002; 73: 48-51. Wikimedia Foundation, Inc, 2009. Health
informatics. In: Wikipedia, the free encyclopedia. Available on:
http://en.wikipedia.org/wiki/Medical_informatics. Accessed in Jan
14, 2009. Xu Y, D'Alessio L, Jaulent MC, Sauquet D, Spahni S,
Degoulet P. Integrating medical applications in an open
architecture through generic and reusable components. Stud Health
Technol Inform 2001; 84(Pt 1): 63-7.