1. HyperEPJ
Towards Hypermedia in the Electronic Patient Journal
Master Thesis in Information Technology
Søren Mygind Spangsberg – 20043455
Supervisor: Niels Olof Bouvin 20. December 2006
Department of Computer Science
Department of Information and Media Studies
Aarhus Universitet
4. Chapter 1
Foreword
1.1 Structure of this Thesis
The thesis starts with an introduction to the preliminary work in chapter 4 In-
troduction and Motivation. This chapter describes the vision for the thesis, a
scenario concreting the vision, the motivation for doing the thesis, goals for it,
its delimitations and the method applied.
The report continues in chapter 5 Hypermedia concepts describing background
knowledge in the field of hypermedia. The chapter both follows a historic time
line, from the start of the field and its progression, including concrete systems
developed, and the transformation of the field from being monolithic and closed
to open. The background knowledge is completed in section 5.4 Structural Com-
puting describing the reorientation of the field of hypermedia.
The thesis then progresses with chapter 6 Domain Analysis. Firstly, it analyzes
the health sector focusing on electronic patient journals and secondly it describes
the communication and intervention work between the author and people in re-
lation to the health sector.
In chapter 7 System Design the system is designed and implemented on basis
of the results in chapter 6 Domain Analysis.
Finally, in chapter 8 Conclusion, the work is summarized including future thoughts
and reflections.
1.2 About the Author
The author of this master thesis is Søren Mygind Spangsberg, who is a master
student of information technology. Furthermore, Søren holds a bachelors degree
in computer science.
3
5. Acknowledgments
1.3 Acknowledgments
Several people should receive special thanks for their work in relation to this
thesis:
Niels Olof Bouvin, Supervisor, Associate Professor, University of Aarhus
Kenneth M. Anderson, Associate Professor, University of Colorado
Jan Mark, Chief Architect, CSC Scandihealth
Inge Spangsberg, MD, Radiologist, Randers Centralsygehus
Poul Thorsen, MD, PhD, North Atlantic Neuro Epidemiology Alliances (NANEA)
Anna Hapunik, English Teacher, Master student of English Philology
4
6. Chapter 2
Abstract
This master thesis is devoted to the challenge of integrating hypermedia technol-
ogy in the electronic patient journal (EPJ). The EPJ is a large collection of in-
formation concerning a patient available when-ever and where-ever in the health
sector to the staff. The development and integration of the EPJ in Denmark has
in recent years come closer to the awareness of many due to delays and troubles
of communicating across EPJ systems. Furthermore, it is complicated to bring
new IT-systems into the health sector because the present procedures in the ex-
isting systems/structures are established and worked through.
The vision for the thesis is that hypermedia technology may be utilized to aug-
ment the EPJ in order to enable quick exchange of informations between the
health sector staff, by creating links between vital information regarding a pa-
tient etc.
Through open hypermedia technology and structural computing, a prototype has
been developed that support the use of hypermedia functionality in an EPJ con-
text, however in smaller scale. The basis is a cooperation with the IT company
CSC Scandihealth, who develops EPJ systems in Denmark and worldwide.
To cope with the challenge of integrating IT-systems in the health sector,
participatory design is used in the development. Users related to the health
sector and CSC Scandihealth are involved during the design process in order to
bring their ideas and demands to the prototype.
5
7. Chapter 3
Danish Summary
Denne kandidatafhandling beskæftiger sig med hypermedieudvikling og inte-
gration i den elektroniske patient journal (EPJ). EPJ´en er en stor samling af
information omkring en patient, som er tilgængelig for sundhedspersonalet på
alle tidspunkter og lokationer i sundhedssektoren. Opmærksomheden omkring
udviklingen og indførelsen af EPJ´en er i de seneste år blevet skærpet i Dan-
mark, blandt andet på grund af forsinkelser og vanskeligheder ved at kommu-
nikere på tværs af EPJ systemer. Desuden er sundhedssektoren et komplekst
domæne at indføre IT-systemer i, fordi den nuværende praksis, i de eksisterende
systemer/strukturer, er veletableret og gennemarbejdet.
Visionen for projektet er, at hypermedieteknologi kan anvendes til at udvide
EPJ´en, så det gøres muligt at udveksle informationer hurtigt mellem sund-
hedspersonale, f.eks. ved at etablere links mellem vigtig information om en
patient.
Ved hjælp af åben hypermedieteknologi og structural computing, er der, i for-
bindelse med afhandlingen, udviklet en prototype, som understøtter brug af hy-
permediefunktionalitet i en EPJ kontekst, men i mindre skala. Udgangspunktet
herfor er et samarbejde mellem IT-firmaet CSC Scandihealth, som udvikler EPJ
systemer både i og udenfor Danmark.
For at håndtere udfordringen omkring IT-integrationen i sundhedssektoren
inddrages brugerorienteret design som et element i udviklingen. Brugere, med
relation til den danske sundhedssektor samt CSC Scandihealth, har været in-
volveret under designprocessen for at bibringe deres idéer og krav til et sådant
system.
6
8. Chapter 4
Introduction and Motivation
The topic Electronic Patient Journals (EPJ) has in most recent years come closer
to the awareness of many. For several years the EPJ has been under development
and is expected to modernize and rationalize the Danish health sector.
This information technology master thesis is devoted to a small area of the
EPJ, namely the support of hypermedia functionality.
The primary goal with the thesis is to develop a framework that can provide hy-
permedia functionality in a generic way, meaning that it should be usable within
diverse applications and domains. Secondly, the functionality of the framework
will be demonstrated in a pilot program to simulate an EPJ but in smaller scale.
4.1 Vision
It is a desire, seen from a medical point of view, quickly to be able to share im-
portant information about a patient with others. Imagine that a patient has been
x-rayed and the doctor in the examination of the picture afterwards identifies
an area with illness and wants to share this important piece of information in a
faster way than just to write a note. This could be handled using a link from the
EPJ to the xray picture.
4.2 Scenario
The job of the scenario is to expound the vision and describe how it can be
implemented. This presents a practical aspect on the vision.
Link example
In the following it is assumed that a doctor has studied an x-ray and found an
area of illness. To make it easy for the next doctor to get updated on the area, the
first doctor makes a link from a descriptive text in the given EPJ to the specific
area in the x-ray. How this is carried out practically depends among others of
the graphical user interface implementation of the EPJ. The scenario starts with
the fact that a new doctor must get information from an EPJ about a given pa-
tient, maybe because the patient is ill and a new doctor need to browse the EPJ
7
9. Motivation
for information. At a certain time in the browsing process the doctor becomes
aware of the link, that leads to the x-ray and the area with illness.
The link in the descriptive text could look as follows.
Figure 4.1: Descriptive text.
When the doctor clicks the link, the x-ray is presented and the area with ill-
ness is highlighted by a rectangle. The x-ray looks like this:
Figure 4.2: Image link in xray.
4.3 Motivation
The motivation for the work conducted in this thesis originated from a desire to
do research in the field of hypermedia. The author has become acquainted with
research in the health sector and neuro diseases in Denmark through work in the
research unit NANEA (North Atlantic Neuro Epidemiology Alliances). www.nanea.eu
In relation to this the author has met Jan Mark from CSC Scandihealth, who
develops EPJ systems in Denmark and other countries, who seemed to be inter-
ested in instituting a cooperation.
8
10. Goals
4.4 Goals
The main work to be carried out can be divided into three goals:
Primary goal
The primary goal is to develop a framework, that can provide hypermedia func-
tionality with the following properties:
1. Capable of handling diverse link types
2. Usable in different domains without changing the core of the framework
Secondary goal
Demonstrate the functionality of the framework by developing a pilot program
that simulates the look and behavior of an EPJ nevertheless in much smaller
scale.
The pilot program will feature a graphical user interface. It should support link
creation and deletion as well as traversal of the different link types.
Third goal
Integrate the framework into the EPJ from CSC Scandihealth.
When the framework has been embedded into the pilot program and the func-
tionality is demonstrated, the next step is to integrate the functionality within
the EPJ from CSC Scandihealth. However, CSC Scandihealth is in a position
competing with other vendors about EPJ solutions. Therefore, implementation
details about their EPJ are kept within the company and thus not available to the
project. Moreover, the integration is ample, meaning that the EPJ is a complex
piece of software, which will certainly lead to a difficult and time consuming
process of integrating the two.
4.5 Delimitations
The project focuses on the link aspect of hypermedia in the EPJ. Hence, other
hypermedia related issues such as collaboration and Human Computer Interac-
tion issues takes a secondary role in the project.
9
11. Thesis Method
4.6 Thesis Method
The work to be conducted in relation to this thesis concentrates on a develop-
ment project targeted for the health sector. It focuses on combining hypermedia
technology with the EPJ.
The project follows a development plan comprising the following phases, where
each may be iterated:
1. Domain analysis
2. Design
3. Implementation
4. Evaluation
Moreover, participatory design (Schuler and Namioka, 1993) are brought in as
an element in the project, in order to involve the end users in the development
phases. This helps to ensure that the product meets their needs and requirements
(Kensing and Blomberg, 1998). Together, EPJ development companies and hos-
pital users can bring their ideas and concerns based on their background.
During the progress of the thesis writing and source coding, a web site has ac- www.spangsberg.net/masters/
companied the project. It contains various documents from the project. Further-
more, it provides a diary, that gives a historic overview of the project.
10
12. Chapter 5
Hypermedia Concepts
This chapter describes the development of hypermedia. It starts with a brief
history of the field and continues with open hypermedia systems. From here the
chapter relates to the transition from open hypermedia systems to the field of
structural computing.
5.1 Brief History of Hypermedia
Hypermedia is a field concerned with structure and the desire to organize con-
tent. It can be defined as:
A concept that encourages authors to structure information as an associative
network of nodes and interrelated links (Bieber et al., 1997)
This linking and cross-referencing can also be defined as non-linear text or
hyper-text, which is the contrary to reading a book from start to end. Here
small chunks of information can arbitrary be connected via relations or links. It
was first recognized as a field by Vannevar Bush, when he published the article
As We May Think (Bush, 1945). Herein he presented a hypothetical machine
called the Memex, which was basically a way to store and retrieve information
on microfilm. The idea behind the Memex was to extend the human memory.
As Bush claimed:
There should be a tool that would enhance human memory and thinking and that
allows people to retrieve information from a computer in many of the same ways
in which retrieval is accomplished within human memory (Bush, 1945)
Through the Memex the user could create associative links between documents
and thus it was much similar to what we now call hypertext. The links could be
chained into a collection, known as a guided tour. The Memex helped form the
basis for fully implemented hypermedia systems. It was not only a magnificent
idea; it made people think in another way about how they did their job. Bush
even anticipated an entirely new job function, known as trail blazer, for expe-
rienced users with the main job of following and creating these guided tours in
Memex. A very interesting thing in Memex (compared to the development of
the field) was the view specification that, along with the content to be displayed,
11
13. Efforts toward Open Hypermedia
instructed Memex how to display it.
The pioneering work of Bush has marked the field of hypermedia and are still
part of the research today. Due to the theoretical nature of the Memex, it could
not be tested in a real practical way. However, several systems were devel-
oped in the years after that were based on the ideas of Bush. Most prominent
were NLS/Augment (Engelbart, 1984), KMS (Akscyn et al., 1988), Intermedia
(Yankelovich et al., 1988) and NoteCard (Halasz et al., 1987). They included
advanced hypermedia functionality compared to their time. Features such as
video conferencing in NLS/Augment and advanced link construction as well as
storage (as in Intermedia), showed that these were outstanding hypermedia sys-
tems with a lot to offer for their users. But within their domain only. As long
as the user stayed inside the system he or she could take advantage of the fea-
tures. However, it was impossible to go beyond the boundaries of the system
because they suffered from a monolithic nature. They were closed. It was not
possible to exchange data between the systems neither use your favorite editor
nor application and still get hypermedia functionality.
Furthermore, the systems were diverse in their implementation. The fact that
NLS/Augment used statements, KMS frames, NoteCards cards and Intermedia
documents to hold information, and that their linking capabilities differed, rang-
ing from one-way embedded to directionally external, illustrated that they were
developed differently, which made it hard to compare them and interchange be-
tween them.
5.2 Efforts toward Open Hypermedia
5.2.1 Halasz Seven Issues
In the time after the development of the classic hypermedia systems, Frank Ha-
lasz who co-created the NoteCards hypermedia system wrote an article called
Reflections on NoteCards: Seven issues for the next generation of hyperme-
dia systems (Halasz, 1988), criticizing NoteCards, which was a member of the
group of classic hypermedia systems and thus represented it. The output was
seven issues that according to Halasz could free the next generation of hyper-
media systems from the drawbacks of being monolithic and closed. These issues
should be taken into account when the next generation of hypermedia systems
were being developed. The issues were:
Search and Query
Halasz identified the need for improvements of retrieving the various objects
in hypermedia systems. Being able to navigate within the system is a defining
property of hypermedia systems and hence it should support an advanced search
and query mechanism. Halasz imagined that effective mechanisms would not
only help users get quick access to their information but also filter unwanted
content from the interesting.
12
14. Halasz Seven Issues
The search and query mechanism should support two types of queries: con-
tent and structure based. The content based should search for objects matching
a particular parameter in the data. Give me all objects that contain the string
"medicine" could be an example of a content based search. Structure based
should on the other hand search for special structural characteristics within the
objects whereas Give me all objects where the type property is "imageanchor"
could be an example of a structure based search.
Composites
Ability to group links and nodes in larger objects to represent them as one were
poorly supported in NoteCards, that featured the special card called a FileBox
which could contain other cards. The problem was that the Filebox only ref-
erenced sub cards and not included them. When links pointed to sub cards in
the Filebox they just pointed to that card and not also to the head card and the
Filebox thus failed representing the containing cards as a one unit.
Halazs looked for more sophisticated ways of implementing composites.
Virtual Structures
The classic hypermedia systems featured structures too static to cope with dy-
namically generated content. It should be possible to perform a search and query
and present the resulting content as a virtual structure on the same level with
other objects in the system.
Virtual structures can be related to the view feature of the relational database
management system (RDBMS) where a dynamic table can be created based on
a query in the Structured Query Language (SQL). Views behave the same way
and can be applied to the same operations as ordinary tables except that they are
kept in the memory exclusively.
Computation
The classic hypermedia systems were passive in their behavior meaning that,
although it was possible for the user to create links and nodes, the system did
nothing on its own initiative. Halasz proposed the idea of having an engine
perform computations on the structures of the users, the link network e.g. The
purpose was to to personalize the system for the user. Examples of such com-
putations are seen on many shopping web sites, where the system adapts to www.amazon.com
your particular interests and offers items that match the one you have previously
bought.
The computation mechanism could make the next generation hypermedia
systems behave less static and suit the users better.
Versioning
In order for the next generation of hypermedia systems to fit a broad range of
application domains they should support versioning of the various objects like
links and nodes etc. NoteCards did not offer any versioning control, in that it
was only possible to keep track of one copy of a card.
13
15. Meyrowitz´ Eight Issue
Halasz mentions software engineering as an area where the classic hyper-
media systems faced problems. Being able to administer multiple versions of a
given software is vital as far as a software engineering project is concerned.
Extensibility and Tailorability
Eventually Halasz recognized the need for hypermedia systems to be extensi-
ble to suit particular needs in an easy way. KMS, NoteCards and Intermedia all
supported extension via application program interfaces or object oriented frame-
works. But they were all targeted for programmers or people with experience in
computer science and it was thus rather difficult for the common person, who
was only interested in using the system and not in knowing all about it, to extend
it. One solution could be to include script languages or macros, so people with-
out experience in programming languages could make minor changes to their
system.
5.2.2 Meyrowitz´ Eight Issue
Following Frank Halasz´ seven issues, Norman Meyrowitz added an eight issue
to the collection published in the article The Missing Link: Why We Are All
Doing Hypertext Wrong (Meyrowitz, 1989).
In the article Meyrowitz identified one factor that, according to him, pre-
vented the classic hypermedia systems from widespread use and integration in
software. It was due to the fact that they were monolithic in nature. Even though
the systems proved successful in providing hypermedia services within their do-
main, they had not been able to go beyond that and be a part of other software. It
was impossible for a user to step outside of the systems, into his or hers favorite
program to edit a given content and still have the hypermedia support. If the next
generation hypermedia systems were to overcome that, their services should be
available at the operating system level, enabling developers to integrate it like
the copy, cut and paste convention.
5.2.3 The Dexter Hypertext Reference Model
The Dexter Hypertext Reference Model (Halasz and Schwartz, 1994) is a result
of work conducted by many influential people related to the hypermedia com-
munity. The model takes its name after the first meeting between the people,
which was held at the Dexter Inn, Sunapee, New Hampshire.
The Dexter model tries to address many areas of hypermedia systems that lacked
generality. The classic hypermedia systems did provide hypermedia functional-
ity but in their own definition of links, nodes and format. They were diverse. The
Dexter model tries to unify these definitions more generally in order to compare
different systems to each other and exchange data between them.
Examples of contributions from the Dexter model was a general hypermedia
architecture, generalization of links from binary to arbitrary dimensions and an
upgrade of links, nodes and composites as first class objects. The Dexter archi-
tecture is depicted in Figure 5.1.
14
16. The Dexter Hypertext Reference Model
Figure 5.1: Dexter model architecture (Halasz and Schwartz, 1994).
The architecture is composed of three layers: runtime, storage and within-
component of which the storage layers is of the greatest interest.
Runtime Layer
The runtime layer manages all with respect to presenting the hypertext to the
user. With help from presentation specifications, the hypermedia structures may
be displayed differently according to the user.
As the user may recall, content in Memex could be displayed with a view specifi-
cation allowing the user to define how it should be presented (see 5.1 at page 11).
The view specification is what Dexter calls presentation specification or PSpec
and it emphasizes that Vannevar Bush was ahead of his time in terms of hyper-
media research.
Storage Layer
The storage layer is responsible for storing and retrieving links and anchors.
Thus it is only the hypermedia structures the storage layers manages and not the
content they apply to. The separation of structure and content, though made the
interaction with the surrounding interfaces important, hence the anchor is a vital
part of the model since it is the connection between the two. In the model an
anchor is an object with a unique identifier so it is addressable within the sys-
tem. Furthermore, it defines a part of content that remains unspecified, having
the advantage of not constraining future implementations.
Within-Component Layer
The within-component layer was not further specified in the model due to the
same concerns just mentioned.
15
17. Open Hypermedia
5.3 Open Hypermedia
One of the major desires for hypermedia as a piece of software has been the vi-
sion that hypermedia functionality should be integrated into all software. Prefer-
ably it should be integrated at the lowest level of interaction meaning the oper-
ating system in the same way as the ’copy, cut and paste’ convention, which is
part of almost every software programs today. The reasons why the vision has
not yet been realized is roughly twofold:
1. Hypermedia functionality is, by many developers, not categorized as manda-
tory as ’copy, cut and paste’ and therefore not built into programs.
2. Hypermedia software that provide the functionality is closed and hard to
integrate into third party software. A central hindrance herein was identi-
fied by Meyrowitz in (Meyrowitz, 1989) as the lack of support of hyper-
media functionality within the editors that companies already used.
Number 1 reason is hard to control because it relies on each individual developer
to implement the functionality, and thus it will only be the people that prioritizes
it. 2 is rather more straightforward to work with and that was the approach the
research community followed and still follows to improve the chances of the
vision to be fulfilled. While the monolithic systems where designed as an inde-
pendent environment without or with limited awareness of other software, the
open hypermedia systems are characterized as being developed using open stan-
dards and protocols. An Open Hypermedia Systems Working Group has been
created to assist the future course of the open hypermedia systems.
Examples of open hypermedia systems include:
• Chimera (Anderson and Taylor, 2000)
• Microcosm (Hall et al., 1996; Davis et al., 1994)
• Devise Hypermedia (Grønbæk and Trigg, 1994)
• HyperDisco (Wiil and Leggett, 1997)
The proceeding sections will describe them in more detail.
5.3.1 Chimera
Chimera (Anderson and Taylor, 2000) is an open hypermedia system developed
at the University of Colorado, Boulder and the University of California, Irvine.
The system is developed in Java.
The development of Chimera has a background in software development en-
vironments. Such applications often contain a set of diverse objects that are
interrelated in a way. Examples of such include requirement specifications, dia-
grams, source code, test results etc. The process of initializing and maintaining
16
18. Chimera
the objects and their relations is challenging, and therefore Chimera was created
as an attempt to build a hypermedia system to handle this area of software engi-
neering.
A distinguishing feature of Chimera is the viewer1 concept, which relates to
the fact that a frequently required functionality in software development envi-
ronments is the ability to view a given object from different perspectives. For
instance if you design a web page, it is convenient to be able to view the actual
graphical look (WYSIWYG) of the web page as well as the source code be-
hind. This job is well supported in Chimera, as you create a viewer that presents
the graphic aspects of the program and a viewer that presents the lines of code
behind. In both cases it is merely the source code file the viewers take as pa-
rameter. This is very similar to health care systems, where medical results may
be viewed as a table or a graph, much like data in a spreadsheet that can be ob-
served as the raw data columns and rows or a graph figure.
Plug-ins for Microsoft Word, Adobe FrameMaker also exist and the hypermedia
services provided within Chimera can be extended to cover those applications
as well. Figure 5.2 depicts an image-to-image link traversal example.
Figure 5.2: Chimera Image-to-Image Example.
1See http://ftp.ics.uci.edu/pub/chimera/overview/concepts/viewers.html for details on viewer
concept
17
19. Microcosm
Chimera does not support versioning control. However, it was described in the-
oretic terms in (Anderson and Taylor, 1994).
In the preliminary phase of this project when research had only just begun,
Chimera was considered a possible system to use and further develop. The
major downside of the system, however, was the fact that it is an old piece of
software. In fact, it is not developed anymore, which makes it uninteresting to
work with.
5.3.2 Microcosm
Microcosm (Davis et al., 1994) is an open hypermedia system developed at the
University of Southampton. It featured a shared link server and client integra-
tions with several third party applications. Microcosm was easy to implement in
applications, since it could be accomplished in various degrees of integration:
1. Fully aware
If the target application allowed extension through script language or macros,
Microcosm could be integrated at a lower level. This way the target appli-
cation was augmented with a hypermedia menu making the solution more
sophisticated, since it looked more as if the application were designed
with hypermedia capabilities from the start.
To communicate with Microcosm in this mode, five communication pro-
tocols were defined. The term Fully Aware refers to applications able of
participating in all five protocols. However, is was also possible to interact
with a subset.
2. Universal viewer
Applications with no communication facilities except the one hosted by
the operating system, could be integrated using a "shim" program called
the Universal Viewer which placed itself in the title bar of the target pro-
gram. The Universal Viewer took care of communication between the
target application and Microcosm. From here the user could manage var-
ious hypermedia tasks, such as following links etc.
Figure 5.3 and 5.4 illustrates the two integrations.
Creating anchors and following them were managed by the link server, making
it easier to implement applications because it put smaller demands when they
were releaved of these tasks. It posed a drawback though, since Microcosm had
to be compatible with the applications in order for the hypermedia functionality
to work and significant improvement had to be done to update Microcosm when
an application changed.
Links in Microcosm where one-way, consisting of two anchors each comprising
the name of the media, the selection and an offset to locate it. An interesting
feature sprung from the idea of underspecifiyng an anchor, which enabled var-
ious types of links such as generic links (with selection as the only parameter
18
20. HyperDisco
Figure 5.3: Fully Aware integration in AutoCad.(Davis et al., 1994)
Figure 5.4: Universal Viewer integration in Microsoft Calendar.(Davis et al., 1994)
specified) where every occurrence of a given selection would be marked as a
link in every media.
5.3.3 HyperDisco
HyperDisco (Wiil and Leggett, 1997) is an open hypermedia system devel-
oped at the University of Aalborg. HyperDisco focuses on distribution and
collaboration and was created with the goal to make a general open hypermedia
system that focused on providing tools for both collaboration and distribution,
19
21. Devise HyperMedia
and that the system would influence the future systems in that direction.
The hypermedia structures within the system where stored in a link base; a
concept like the relational database management system but designed to store
hypermedia structures. The link base or hypermedia database management sys-
tem (HDBMS) allowed to work collaborated on material because it did not re-
quire each user to have write permissions to the material. Moreover, the link
base could be distributed across a network or the Internet allowing people to
work on it at distant locations. Furthermore HyperDisco provided a rich way of
integrating applications:
1. Full
Closely related programs could have their data and hypermedia structures
stored in the link base.
2. Partial
Applications not capable of fully interaction with HyperDisco could have
hypermedia structures stored within HyperDisco, while the content resided
somewhere else e.g. inside the filesystem.
3. None
Applications not developed for hypermedia were integrated in such a way
that they constituted destination anchors in a link only and not source
anchor as HyperDisco did not have control of the format or application.
5.3.4 Devise HyperMedia
Devise HyperMedia (Grønbæk and Trigg, 1994) is a hypermedia framework
developed at the University of Aarhus. It was based on the Dexter Reference
Model and the primary goal was to prove both the validity of the model and
its defects. As with Chimera and HyperDisco, Devise HyperMedia made use
of a link base structure, in the form of an object oriented database (OODB), to
store links and other hypermedia structures. The use of external storage made
it possible to apply linking in other media than text documents. Hence Devise
HyperMedia was able to reference many types of media (Grønbæk et al., 1997).
The developer did not build Devise HyperMedia strictly in accordance with
the Dexter model. Among others they decided to include dangling links in the
system, with the argument that it enables flexible link construction.
Another interesting feature was the notion of link directionality explored in the
project. Three notions were identified:
• Semantic direction
Defines a semantic meaning in a given relationship. For instance, a diag-
nose explanation (A) supports a complex diagnose used in the EPJ (B).
• Creation direction
Determines the order in a creation what will be source and destination
anchor. The first becomes source and the second becomes destination
20
22. Application Integration
• Traversal direction
The direction is set explicit by the user in a creation. The link may then
only be traversed in that direction
Devise Hypermedia has been used in conjunction with research projects with
Mjoelner Informatics and EuroCode. Furthermore it has been subject to tests in www.mjolner.dk
reallife situations and use.
5.3.5 Application Integration
Meyrowitz realized that if hypermedia should have widespread use in software,
it should be done through augmentation of third party applications. In that way,
applications that lacked proprietary file formats or were otherwise closed could
talk to each other and exchange information between them. Integrating such ap-
plications is difficult due to the closed nature of the applications. For instance, it
is difficult to store links within the documents, if the structure of the document
is unknown, rendering it necessary to store links externally in databases (link
bases).
The degree to which applications can be augmented with open hypermedia sys-
tems depends on the architecture of the application, communication protocols
and file formats among others. If the application is easy to integrate, a solution
with different integration degrees like Microcosm or HyperDisco is possible.
This means that the hypermedia services can be implemented with an applica-
tion program interface (API) between the application and the hypermedia frame-
work. This is the ultimate solution, but it obviously puts higher demands on the
application, such as available source code. Often software companies refuse to
release the source code to their products due to competitive concerns, which
makes this type of solution unavailable. In that case a less challenging integra-
tion can be made via the fundamental services the operating system provides.
Example of such is the Universal Viewer in Microcosm.
5.3.6 Summary
Open hypermedia systems development aspire to address some of the problem-
atic issues (see 5.2,at page 12) related to the classic hypermedia systems.
Firstly, open hypermedia systems are designed to be integrated into other appli-
cations and provide hypermedia functionality instead of providing applications
already capable of doing that. As Meyrowitz recognized in his eight issue (Mey-
rowitz, 1989), hypermedia services should be integrated into the favorite editors
of the people instead of developing hypermedia programs not used, because of
discrepancies from their usual programs.
Secondly, the classic systems were diverse in several areas such as terminol-
ogy (frame, document, note-card), linking capability and file format. The Dexter
Hypertext Reference Model (Halasz and Schwartz, 1994) (see 5.2.3 at page 14)
tried to find a common path and identity for hypermedia systems by suggest-
ing a general hypermedia model with respect to presentation and storage of the
21
23. Summary
structures. Devise HyperMedia was developed as a Dexter-based hypermedia
systems and thus adapting many of the principles of the model. HyperDisco
encompassed many of the issues (5.2.1) proposed by Halasz (Halasz, 1988).
A characteristic among the open hypermedia systems is the use of externally
stored links, which is required to overcome the fact that the resource they in-
terconnect can be unknown or out of control of the system. Thus they are not
always able to place the link anchors within the resource. Externally stored links
benefit the system so that it facilitates the process of computing graphical views
of a web of links. Furthermore, it makes link handling flexible since users can
have multiple link bases.
Grønbæk and Trigg (1999) have compared the approach of embedding links
within the resource with external links separated from the resource. Table 5.1
illustrates the comparison.
Embedded link ap-
proach
External link approach
Storage of links Jump addresses inside
content.
Link objects in separate
database.
Openness with re-
spect to linking
Closed, requiring special
content formats like
HTML or VRML.
Open, requiring no spe-
cial formats; material in
the applications´ format
can be linked
Media support Links are mostly sup-
ported from text-based
data.
Links may interconnect
segments in any data-type
e.g. video.
Maps of link
structures
It´s difficult (often impos-
sible) to see the links to a
specific document (search
engines give only partial
answers).
Link relations can be in-
spected and maps gener-
ated.
Distribution Simple - only content has
to be distributed.
More complicated - links
have to be stored and ac-
cessed separately.
Table 5.1: Comparison of link storage approaches (from Grønbæk and Trigg (1999,
page 50)).
Another discrepancy between open hypermedia and classic systems is the way
some systems provide degrees of integration for third party applications. Mi-
crocosm included the fully aware and universal viewer solution and HyperDisco
full, partial and none. This may constitute yet another way to provide hyperme-
dia functionality to as many applications as possible like Meyrowitz recognized
(Meyrowitz, 1989)
Referring to Figure 7 in Appendix B - Hypermedia architecture development
22
24. Summary
at page 81, the transition from the classic hypermedia systems to the open is de-
picted in Figure 1b - Abstraction of Applications where application is abstracted
away from the system. This means that third party applications can be extended
to support hypermedia functionality.
Additionally, Figure 1c - Abstraction of Store illustrates how the storage of
hypermedia structures are abstracted from the system meaning that the systems
do not employ proprietary formats, nonetheless they are able to exchange data
across different systems.
23
25. Structural Computing
5.4 Structural Computing
Just as open hypermedia systems were a progression from the classic systems,
in a response to the major disadvantage of being monolithic, structural comput-
ing is, by many, perceived as the breakthrough in the evolution of the field of
hypermedia. In 1997 Peter Nürnberg et al. published the article As We Should
Have Thought (Nürnberg et al., 1997). Herein he and his co authors argued that
the ideas of hypermedia should be generalized into a new research field called
Structural Computing.
The main point of the article is that structure should take primacy over data.
Data has always been rated above structure. Examples include operating sys-
tems and programming languages which provide data abstracting concepts such
as files, objects and basic primitives such as integers and strings. Instead a
file could be modeled as structure with content. Furthermore, it is a claim, in
the article, that navigational hypermedia is just a specialized domain of struc-
tural computing (Nürnberg et al., 1997). Other domains like spatial hypermedia
or taxonomic hypermedia could likewise be considered specializations of this
general way of doing computing as we may view structural computing. It is a
fundamentally new way of seeing these concepts and consequently it requires a
shift in paradigm.
In Hicks and Wiil (2003) two observations are identified that are worth men-
tioning since they may help to understand why structural computing are funda-
mentally different from how computing was viewed before. The two observa-
tions spring from work that researchers have made about existing hypermedia
systems.
1. Current hypermedia systems offer good support for the navigational do-
main. Nevertheless, when it comes to an emerging set of new domains, it
fails, because the terminology for navigational hypermedia is not general
enough to accommodate requirements of other and different domains as
spatial and taxonomic hypermedia.
2. Hypermedia is a field concerned with structure and organization. More-
over, it is about creating and using structure over information (Hicks and
Wiil, 2003). However, major software are developed on the basis that data
is more important than structure and hence structure is rated thereafter.
Instead it would be a natural progression to focus on structure instead of
data. This might ease the structure related tasks performed in hypermedia
systems.
The shortcomings of those two observations may already have swayed negative
influence on the development of hypermedia systems (Hicks and Wiil, 2003).
Therefore structural computing emerged as the new evolutionary step for hyper-
media to renew itself as a research field.
The practical implications on hypermedia development are seen in the systems
based on structural computing. In open hypermedia systems, the hypermedia
24
26. Themis
functionality was an integral and defining part of the system. In structural com-
puting systems, however, the hypermedia functionality is banned. If included
within the framework it would be too specific to accommodate the vision by
Nürnberg about multiple domains. Therefore they only define how to model
data generally in terms of structure. If targeted for hypermedia use this func-
tionality must be developed and integrated with the framework.
The next two chapters describe two such systems. They are Themis and Small
SC.
5.4.1 Themis
A concrete piece of software that has been developed to cope with the weak-
nesses in the two observations is Themis (Anderson et al., 2003b,a), which is
a structural computing system created by researchers at the University of Col-
orado, Boulder. The purpose is to provide a generic information store to a broad
spectrum of domains. The Themis system consists of four parts:
1. Framework
2. Structure server that implements the framework
3. Template extension mechanism
4. Structure transformation mechanism
Figure 5.5 illustrates how the various parts are organized.
The Themis framework provides classes that enable developers to model many
different types of structures without adding new classes to the framework. This
is an attractive feature because it keeps the framework simple.
At the core of the framework are the classes Element, Atom and Collection.
Atom and Collection are sub classes from Element. Elements contain attributes
to describe their content. Furthermore, the Collection class is capable of hold-
ing other Elements which allows the framework to model complex hierarchical
structures.
In order to make the elements available, they are stored in the class Repository
which is also responsible for persistence and provides search and query func-
tionality. The framework is then hosted by a server from where clients can
access its services.
The two extension mechanisms Template and Structure transformations adds
powerful features to the framework. A template is a commonly used structure in
a specific domain that is defined with a set of properties. Templates are stored
in a template repository and can be instantiated when demanded by the clients.
The great advantage of the template is that it does not require additional coding
of classes when new domain objects are needed since they are kept outside of
the application.
25
27. Small SC
Figure 5.5: Themis architecture.
The second extension mechanism Structure transformation enables the frame-
work to perform transformation between any two templates in the template
repository.
The architecture in Themis enables developers to create dynamic data models.
Thanks to the template mechanism, developers can spend less time in defining
and creating domain specific objects without the need to add more hard-coded
classes to the framework.
However, Themis is heavy-weight, meaning that it is complex to install and
setup, due to its comprehensive nature (server, framework, client, extensions
mechanisms).
5.4.2 Small SC
Small SC (Anderson, 2005) is a structural computing framework that aims to
provide the same flexible capabilities in the form of structural templates but in
a simpler fasion compared to Themis. It may be used to generate data models
for diverse applications and has seen use in domains such as requirements en-
gineering (Anderson et al., 2002), scientific computing (Anderson, 2005) and
context-aware hypermedia (Anderson et al., 2006). Furthermore, it provides ba-
sic functionality like storage, retrieval etc. of diverse domain objects that all
it-systems utilize to some extent.
26
28. Small SC
Small SC is developed with the purpose of enabling developers to adopt the
framework to their particular domain. An objective was to create a package
easy to distribute and use for developers. Small SC meets these requirements
successfully considering the fact that it only constitutes a single Java package
file (jar) easy to include in various projects. The framework may then be cus-
tomized for individual purposes (as in this project) or used with its standard
structural computing capabilities.
Figure 5.6 presents the Small SC data model, derived from the contextual hy-
permedia system HyCon (Bouvin et al., 2003). The framework has been further
developed through its use and now comprises search and query functionality,
among other features, compared to the initial versions.
*
Object
<<creates>>
Template
Repository
Template
Manager
Query
Query
Manager
Query
Item
*
*
*
Attribute
Values
SCValue
property
Figure 5.6: Small SC data model. Modified version from (Anderson et al., 2006)
The classes Object, Repository and Template make up for the essential pack-
age to provide a framework with structural computing capabilities. Templates
are entities that define and create objects associated with a pre-defined set of
attributes. Objects are stored in the repository where they can be retrieved and
modified.
The framework also defines a generic class called SCValue, from which
all values used by the system are modeled. In the framework values such as
strings, lists and integers are modeled using SCValue as the basic building block
(Nürnberg et al., 1997).
Using these classes allows to create different objects without adding more
code to the framework. In other words the framework enables the user to create
27
29. Small SC
large data models and still maintain its small and simple nature since all domain
data used in the system are defined and created as objects and thus only require
one hard-coded class.
To keep the data model persistent, it is augmented with a persistence mecha-
nism. At the time of writing the framework employs XML files to handle per-
sistence but can switch to others like a DBMS or network.
Template mechanism
Figure 5.7 presents a code example of how to create a template for the objects
locator and imageanchor. When templates are defined, they may be instanti-
ated by the repository as objects. This is illustrated by Figure 5.8. Using the
1 Template imageanchors = Template.instance("imageanchor");
2 imageanchors.addProperty("resource", "smallsc.atts.SCString", new String());
3 imageanchors.addProperty("locator", "smallsc.atts.SCId", new Id());
4
5 Template locator = Template.instance("locator");
6 locator.addProperty("x", "smallsc.atts.SCInt", new Int());
7 locator.addProperty("y", "smallsc.atts.SCInt", new Int());
8 locator.addProperty("width", "smallsc.atts.SCInt", new Int());
9 locator.addProperty("height", "smallsc.atts.SCInt", new Int());
Figure 5.7: Code example of how to create templates.
1 Object loc = Repository.instance().createObjectOfType("locator", "loc");
2 loc.setProperty("x",new SCInt(r.x));
3 loc.setProperty("y",new SCInt(r.y));
4 loc.setProperty("width",new SCInt(r.width));
5 loc.setProperty("height",new SCInt(r.height));
6
7 Object anchor = Repository.instance().createObjectOfType("imageanchor","i1");
8 anchor.setProperty("resource",new SCString(_res.getId().toString()));
9 anchor.setProperty("locator",new SCId(loc.getId()));
Figure 5.8: Code example of how to instantiate a locator and imageanchor template.
template mechanism and attribute values construction, Small SC relates appro-
priately to the fact that structure emphasizes structure over data. As the example
code illustrates, the first thing to do is define the structure of a particular named
template and associate it with properties. Each property is assigned a name, a
type and a value. The type and value are derived from the generic class SCValue.
Both the definition of the template and association of the properties involve cor-
relating content with structure.
28
30. Small SC
Query mechanism
Small SC is able to perform searches in the repository using its query mecha-
nism (Anderson et al., 2006). It comprises the classes QueryManager, Query
and QueryItem.
A query is created with a number of query items. One query item corre-
sponds to a given property of an object. An example query could be to search
for all objects in the repository that are of the type Anchor and where the name
property is textanchor03. Figure 5.9 presents such a query. Queries can
1 Query query = new AndQuery();
2 QueryItem item = new QueryItem("type", new StringIsFilter(), "Anchor");
3 QueryItem item2 = new QueryItem("name", new StringIsFilter(), "textanchor03");
4
5 query.addItem(item);
6 query.addItem(item2);
7
8 Object[] result = query.find();
Figure 5.9: Code example of a query that finds anchors with name "textanchor03".
have various logical meaning when created. Figure 5.9 illustrates a query of
the type And, whose result objects only satisfy the query if both query items
are fulfilled. Queries can also be of the type Or, which requires only one
of the query item to be fulfilled with respect to the example above. The de-
gree to which a property of an object satisfies the query item can also be var-
ied in that each query item are associated to a filter. The filter defines how
properties match. Small SC includes several filters that enable many levels
of matching, among them the above used StringIsFilter where a property
value meets the criteria only if the exact value matches the property of the query
item. Other filters are StringContainsFilter, StringStartWithFilter and
StringEndsWithFilter.
Using appropriate filters and query types provide users of the framework
with flexible and powerful ways of finding structures in the framework.
As far as scalability is concerned, Small SC has proved capable of handling
very large numbers of objects. When Small SC was deployed in the SOS sys-
tem it managed thousands of objects (Anderson, 2005).
The core of the Small SC framework provides some of the functionality re-
quired in the project and therefore some of the work associated with creating
the framework is completed. The following part of the thesis concentrates on
work required to adapt and extend the framework for this particular project and
domain. This will involve adding various methods to manage link traversals and
creation, deletion and editing of anchors. When this is accomplished the next
step is to develop a program that can demonstrate the functionality in a way
similar to an EPJ, but in a smaller scale. This work will be described in the next
chapter.
29
31. Summary
5.4.3 Summary
Structural computing is the next phase in the development of hypermedia. It was
introduced by (Nürnberg et al., 1997) as a response to the fact that it was hard to
describe other domains of hypermedia systems from navigational terminology.
Nürnberg et al. describes structural computing as a new paradigm in which hy-
permedia is a special case.
Themis and Small SC are examples of structural computing systems built on
the philosophy that structure is above data. Compared to the open hypermedia
systems, structural computing systems defines a broader spectrum of use. Con-
trary to open hypermedia systems, structural computing systems can be used to
anything related to structuring of information not necessarily involving hyper-
media.
Both, Themis and Small SC, are instances of systems which allows to define,
create and manage generic structures in the form of templates. However, they do
not define hypermedia functionality such as linking since this is a special task
for structural computing. Being a part of the core, they would not constitute
structural computing but hypermedia systems.
30
32. Chapter 6
Domain Analysis
This chapter describes work conducted in relation to the health sector and EPJ
systems. It starts with an introduction to the transition from paper to electronic
patient journals. Following that, it relates to the development and integration of
EPJ systems in Denmark, including the EPJ from CSC Scandihealth. Moreover,
examples of efforts to bring hypermedia into the health sector are described.
Eventually, it provides information about features and characteristics required
in a future framework, which is derived from meetings with external people in
the health sector. Finally, a summary concludes the chapter.
6.1 From Paper to Electronic Patient Journals
Still in the 21th century, many hospitals use paper journals to manage the vari-
ous data concerning a patient. This is inefficient, when taking into account that
IT-systems are widely integrated in hospitals and at general practitioners. Much
of the information concerning patients are stored digitally and used among the
staff. To take advantage of the material, the EPJ is being introduced and inte-
grated in hospitals not only in Denmark but also in countries around the globe.
A major drawback of the paper journals is due to their physical nature. They
can get lost and offer limited availability, meaning that the journal must be trans-
ported between different parts of the health care system in a course of illness.
However, an EPJ can be open at multiple locations at the same time (assuming
proper rights) providing better service for its users than its paper counterpart.
6.2 EPJ in Denmark
In 1996 the design and implementation of the EPJ was started, when the danish
health authorities published the report "Handlingsplan for Elektroniske Patient-
journaler" (Sundhedsministeriet, 1996). On basis of that report, 13 EPJ projects
were granted funding to develop and integrate EPJ systems in the danish hospi-
tals. At the same time the organization EPJ-observatoriet , was established in www.epj-obs.dk
order to monitor the projects, which includes major IT-companies like Acure, www.acure.dk
Systematic Softwareengeneering, WM-data and CSC Scandihealth. Figure 6.1 www.systematic.dk
www.wmdata.dk
www.scandihealth.dk
presents an overview of which county/region each company provides EPJ sys-
tems to.
31
33. Goals and expectations
Figure 6.1: Companies providing EPJ technology to counties.(Vingtoft et al., 2005)
6.2.1 Goals and expectations
One of the aims of implementing the EPJ in Denmark, is to give quick access
to information about a patient. EPJ Observatoriet describes the EPJ as follows
(translated from danish):
The omnipresent information container including the patients data, securing ac-
cess to all interested parties involved in the situation of the patient (Vingtoft et al.,
2005, page 9)
In order words the vision is a tool that facilitates access to information about
a patient where-ever and whenever needed, not only for the doctor but all peo-
ple involved in the process. This is also known as the continuous health sector.
Behind that lies that the EPJ is more than just a technology used - it is a deve-
lopment of the organization and the work processes contained within it.
The EPJ has been subject to development in almost 30 years. Figure 6.1 il-
lustrates the progression quite well. In the beginning the dominant focus of the
EPJ was on document processing and supporting the staff in their work. The
32
34. Heterogeneity
Generation 0 1 2 3
Philosophy Office support
and document
handling
Availability
and security.
Replace paper
journal.
Clinical
process
support, in-
tegration and
work flow
Omnipresent
Platform DOS/Windows
Mainframe
Windows NT
Mainframe
Integration
platforms
Pervasive
computing
Table 6.1: EPJ development (based on (Steenberg, 2003)).
systems were local with respect to data exchange and standards. From here
it has progressed to second generation EPJ systems which focus more on the
process of a patient in the health sector. Furthermore, it operates according to
(inter)national standards in a distributed environment. Finally, the third genera-
tion supports the description just mentioned about the omnipresent EPJ, which
is available everywhere and anytime. The use of pervasive computing in relation
hereto aid this.
According to the newest status report from EPJ Observatoriet, an approximate
of 28 percent of the hospital beds in Denmark are covered by EPJ systems1.
Compared to own expectations and other countries the short term goal has been
met. However, there are some disagreements on how to define an EPJ when esti-
mating the coverage, hence the numbers should be taken with some reservation.
Implementing EPJs in Denmark is not without trouble. The project has been
postponed many times due to various difficulties. A contributor hereto include
the fact that many of the EPJ projects are bounded within a given county in Den-
mark, which has resulted in local solutions, that works fine within the county but
not across. A communication model, defining how data in an EPJ should be ex-
changed across systems, called G-EPJ, has developed in parallel with the EPJ
development and is currently put on hold in version 2.2. However, many of the
EPJ systems does not meet the G-EPJ and it is thus difficult to use EPJ sys-
tems in a larger scale in Denmark because they are unable to communicate with
each other. Therefore, the estimated deadline has been set to 2015 according to
EPJ-observatoriet (Vingtoft et al., 2005, page 28). The hospitals, however have
a more optimistic assessment of when they will finish implementing the EPJ.
Their deadline is 2008.
6.2.2 Heterogeneity
The EPJ interacts with other systems in the health sector. Examples are:
• Patient Administrative Systems (PAS)
• Laboratory information systems
1A bed is covered, if EPJ functionality to medicate and registrate clinical information about
the patient is used
33
35. CSC Clinical Suite
• Blood bank systems
• Various hospital systems aiding CT/MR scannings
PAS systems are used by the general practitioner to hold information about a
patient. Informations contained within it may be results from blood samples
or other examinations (exchanged from the laboratory information system) and
medical condition if the patient suffer from an illness. The laboratory informa-
tion systems keep information about test results from blood samples and other
human fluid or tissue samples. These data are exchanged between the general
practitioners or hospitals. Blood bank systems contain information about storage
of blood used in operations, transfusions etc. Finally, the hospitals use various
systems to perform tests like xrays and CT/MR scannings.
The EPJ must be able to interface to these systems and display selected
data from them. This makes the environment surrounding the EPJ highly het-
erogeneous, due to the discrepancy between systems and their characteristics.
Resources are distributed across different systems and are out of control of the
hypermedia system. Thus, it is a necessity that the framework can handle this
and is able to interconnect the resources even though they are beyond its own
domain.
6.2.3 CSC Clinical Suite
The EPJ from CSC Scandihealth is called Clinical Suite (CSC Scandihealth,
2005). It is developed using the J2EE2 framework and is coded in Java which,
in theory, makes the system platform independent. This feature, however, may
be absent due to the heterogeneity just described. With reference to the deve-
lopment of the EPJ described earlier in 6.1, Clinical Suite is a 2nd generation
EPJ, which means that it is focused on the clinical process. It is based on a
modular architecture that facilitates diverse usages, since modules can be added
or removed according to the particular need.
The underlying persistence mechanism for the EPJ is Oracle HTB (Health-
care Transaction Base), which is a special clinical database created to support
the diverse set of clinical data. These are available through application program
interfaces.
Linking Capabilities
Clinical Suite does not contain any built-in linking features. However CSC had
both the idea and request from customers (see page 85), nevertheless it is not an
implemented part of the EPJ.
In the absence of implementation details, chief architect at CSC Scandihealth,
Jan Mark, has assisted in the design of the framework regarding characteristics
and capabilities with the intent of implementing it in Clinical Suite. This work
is described in 6.4.
2Java 2 Enterprise Edition
34
36. Efforts to Introduce Hypermedia in the Health Sector
Figure 6.2: CSC Clinical Suite.
6.3 Efforts to Introduce Hypermedia in the Health
Sector
Hypermedia is not a completely new concept in the health sector. Through-
out the development of hospital systems and the introduction of electronic pa-
tient journals, work, towards bringing hypermedia into this sector, has been con-
ducted in various projects. These projects try to introduce hypermedia concepts
like Computer Supported Collaborative Work (CSCW) and linking as a tool to
save time.
6.3.1 Hospitexte
Hospitexte (Charlet et al., 1998) is a project from 1998, which aimed to create
a hyper textual electronic patient journal. The idea behind, was the claim that
medicine is an empirical domain and thus fundamentally resists formalization.
The normal solution to model a paper journal electronically would be to create a
database and store all information there as seen in CSC Clinical Suite. However,
two reasons conflicts this solution (both outline from (Charlet et al., 1998)):
1. Medicine is not a science it its daily practice. It is a practice in which
context plays a major role.
2. Medicine continues to evolve, and many of the medical categories, proce-
dures and vocabularies change over time.
Instead of applying the traditional database solution, Hospitexte employs hyper-
text functionality, to create a workspace, for the staff, that supports structuring
35
37. Integrating TeamRoom+ in the NHS, UK
of documents and annotation. Furthermore, it is based on structured, textual
documents in the form of SGML/HTML.
The project behind Hospitexte, accentuate the importance of tools that sup-
port information described in natural languages. Examples include annotation
features that enable the staff to create documents including knowledge about
personal questions or tasks.
6.3.2 Integrating TeamRoom+ in the NHS, UK
In 2000, the National Health Service in the United Kingdom explored how to
employ CSCW-technology to support their teams in improving health service
and modernization (Connor and Finnemore, 2003). They utilized the IBM de-
veloped software TeamRoom (Roseman and Greenberg, 1996b,a) to make better
use of their time. Specifically, they explored the possibilities in CSCW software
to develop their usual same time/same place work methods to any time/any place
according to the four quadrant time and space model (Kaplan, 1997). They con-
cluded that:
(...) the key to successful technology supported collaboration depends not only on
the technology, but also on the organization´s ability to adopt an entirely new way
of working (Connor and Finnemore, 2003)
Thus, integrating hypermedia technology, be it CSCW or linking functionality,
impacts an organization because it changes the work processes in it.
6.4 Field work
Throughout the project period various fieldwork has been conducted. This has
mainly consisted of meetings and interviews with people in relation to the health
sector in Denmark, who have brought their ideas, thoughts and concerns to the
project.
It is important to ensure that the future users of the program or framework
(even though it may be few or none) are involved in the process because they
will be the one struggling with it if the process of designing and developing it
has been insufficient.
People involved in the project are:
Jan Mark
Jan Mark is chief architect at CSC Scandihealth . www.scandihealth.dk
Inge Spangsberg
Inge Spangsberg is a radiologist at Randers Centralsygehus. She is a future user
of the EPJ being developed in Denmark.
36
38. Usage
Poul Thorsen
Poul Thorsen, MD and PhD leads the research unit Nanea , who conducts re- www.nanea.eu
search in the field of cerebral palsy, autism, preterm delivery etc.
The following text is based upon several meetings. For full summary refer to
Appendix D and E at page 83 and page 85 respectively.
Being doctors, Inge and Poul may take the role described in the scenario (4.2)
where a doctor examines an xray, creates a link to a specific area in the xray so
that other doctors may obtain that information quickly.
6.4.1 Usage
The way staff in the danish health sector use hypermedia does not differ signif-
icantly compared to the classic hypermedia systems and their use. They also
enabled the user to establish connections between objects of interest and navi-
gate between them. However, hospital staff, like Inge, are busy and do not have
time to spend unnecessary effort in using them. If the final design is poor the
functionality will not be used. Similar opinion was expressed by Jan, who put
a more concrete angel to it by mentioning that it should be possible to operate
the functionality in 1-2 seconds. If it takes longer or is too complex, the people
will most likely not use it because of pressured time schedules. A contribut-
ing reason is that the tools being used at hospitals may not be state of the art,
nonetheless they work and the staff is familiar and satisfied with them (Tange,
1995). Hence, it makes it difficult to change peoples work habits and routines to
something new and different. Even though it is new functionality, it is also extra
functionality that must be included in the normal procedures.
Therefore, the benefit, of using the system, must be clear and significant for
the staff in order for them to use it. In this context, simplicity plays a vital role.
Moreover, there are some hypermedia aspects in relation to the EPJ compared
to the paper journal, which should be considered when developing hypermedia
functionality for the EPJ. Being materialistic, the paper journal supports the use
of applying additional information to it, in the form of post-it notes, surround-
ing of text or comments, a feature often used by people administering patient
journals (Bringay et al., 2004). The reason why formulars and other documents
are annotated is because hospital staff cannot include all information they want.
Therefore by changing to electronic form we introduce a potential loss of knowl-
edge, hence it is important to supply this feature in the EPJ as well (Bringay
et al., 2004).
Since the hypermedia functionality (ideally) should be used as an integral part
of the EPJ, much effort should be put into the user interface of the EPJ as seen
in (Nygren et al., 1992). At minimum, we should ensure that it supports normal
tasks like reading and navigation at equal speed compared to the paper journal
(Nygren and Henriksson, 1992). Results from Finland (Niinimaki et al., 1989),
with an EPJ system revealed that more time and effort was needed in order to
navigate and read the content compared to a paper journal.
37
39. Usage
Use Scenarios
To illustrate how hypermedia services can be used within the health sector three
use scenarios are provided below. They have been created in collaboration with
Jan and Inge.
1. The first situation is where a doctor is writing a note or diagnosis and
wants to link to an external explanation of the diagnosis, which may be
helpful for younger and less experienced doctors. Additionally hospitals
maintain intranet knowledge databases and web sites of diseases, diag-
noses and other related information to keep the staff updated.
This type of link is rather simple because it merely requires the link en-
gine to launch the webrowser with the appropriate address (internal or
external).
SUGGESTED SOLUTION:
A feature similar to the generic link is a tangible solution to this scenario,
because it enables the system to produce links automatically without di-
rect intervention from its users (see 5.2.1 Computation). If no explanation
exists in the intranet, search engines like Google may be used. This way, www.google.com
the doctor can click on a link explaining a given complex term.
2. The second situation is where a doctor wants to support a conclusion or
diagnosis with the information that lead to it. The supporting information
usually reside within the EPJ system or its surrounding applications and
the link goes from one user interface setup to another in the EPJ.
A variant of this is when a clinician is inspecting the results of an ex-
amination. An example of this is a radiologist (see 7) that has scanned a
patient, looks for anything suspicious, finds an area with illness and wants
to store the exact area in the xray. This type of link goes from the descrip-
tive text in the electronic patient journal to the xray image stored within
the system aiding the scanner.
The feature of creating anchors in different resources and especially re-
sources related to radiologists (xrays, CT/MR scans) and using the anchor
to direct the attention of a person, inspecting the EPJ, is very useful ac-
cording to Inge. However, it is not possible in the system she operates at
the moment. In order to highlight something in an image, she makes a
copy of it, places it in a folder and writes a note describing it.
SUGGESTED SOLUTION:
To provide a solution for this scenario, the applications displaying the
conclusion text and xray image must be augmented with a hypermedia
extension in order to establish the link.
38
40. Security
3. The third case is when a doctor is busy with the EPJ of one patient and
need to focus attention on another, and thus wants to make a bookmark so
he or she can quickly return to the patient previously in focus.
SUGGESTED SOLUTION:
Switching between different views within the EPJ is to a large extent the
responsibility of the EPJ user interface and thus placed at CSC Scandi-
health.
Resources
The job of connecting something presumes that content exists to connect. In the
health sector many types of resources are used in order to describe and illustrate
the status of a patient and to handle the work flow in a hospital or at a gen-
eral practitioner. Compared to the paper journal that includes text descriptions
and printed images in the form of xrays, the EPJ comprises other and newer re-
sources. Technology makes it possible to create and store clinical data digitally.
This opens up prospects of creating relations between the digital resources and
accelerates the navigation process.
What type of resources exists that can be interconnected in the EPJ? Table 6.2
introduces some examples:
Resource Practical example
Text Notes, diagnoses, explanations etc.
Tables/charts Electrocardiogram (EKG)
Pictures Digitized (CT/MR single pictures)
Not digitized (old x-ray pictures, sketches or photographs)
Audio Dictations
Video Recorded operations, examinations (ultrasound) etc.
3D objects CT/MR scannings (large collection of pictures)
Modeling and location of tumor
Table 6.2: Examples of clinical data.
There are many reasons to separate the hypermedia structures from the con-
tent and store them in a link base (see Table 5.1). (1) it would be difficult to
embed anchor information in non-text resources like audio or video. (2) there
are potentially many users accessing and creating anchors within the resources,
rendering it unhandy with to have anchors shared between them due to access
concerns. (3) data from surrounding systems may be proprietary to the system
making it difficult for the EPJ to know the internal structure.
6.4.2 Security
Security is another priority mentioned by all. If a doctor makes a mistake in the
treatment of a patient it may have far-reaching consequences for the hospital, the
39
41. Theoretic implementation
individual doctor and the patient. Hence all tools that can assist in minimizing
mistakes are appreciated.
When a doctor makes an assessment, he or she may support it with related in-
formation in the form of a link to an external resource containing information
about a similar case. To help future cases, he or she can make this particular case
available for other in the form of a anchor to which other can link to in order to
support their case.
Another example pointed out by Inge is when a radiologist makes a link in
a image, it both serves as a link from which others may traverse, but also as a
visual proof of the assessment made by the doctor. In case of disagreements
between the doctor and patient, it is possible to go back and inspect the visual
anchor in the image to determine if the doctor has made a mistake.
6.4.3 Theoretic implementation
Hypermedia is not yet integrated in Clinical Suite (6.2) as a tool for intercon-
necting diverse resources. So how do we accomplish it? After discussions with
Jan, one feasible solution is to divide the hypermedia system in two: a general
part and a specific part.
General part
The general part consists of a link engine which is responsible for performing
tasks such as going from A to B in a link traversal or displaying annotations
for a particular link marker. The link engine is embedded into the EPJ where it
provides linking functionality for the users.
Specific part
The specific part of the solution encompasses structures that are hard to define
generally such as anchor specifications and registrations describing with what
application to display a given resource type. How anchors are attached to re-
sources are defined by the nature of the resources. A text anchor connects dif-
ferently to a text file than an image anchor, thus adding a new anchor type to
the system should be done in form of an add-on describing the specific informa-
tion needed by the system in order to support the new anchor type. Figure 6.3
displays this in graphically terms.
EPJ
Link Engine
Add-on1 Add-on2 Add-onN
Figure 6.3: Conceptual illustration explaining how to implement hypermedia function-
ality into Clinical Suite.
40
42. Summary
6.5 Summary
Chief architect from CSC Scandihealth Jan Mark, radiologist Inge Spangsberg
from Randers Centralsygehus and Poul Thorsen, MD, PhD from Nanea have
provided their opinion on how to develop and implement hypermedia function-
ality in the EPJ.
The framework should support hypermedia functionality for diverse resource
types like text, graphics, video, audio and 3D etc. Performing the individual
attachment of the resources depends on the nature of each resource. Attaching
an anchor in a text file differ from an image or video file. To accomplish this,
the framework will make use of externally stored links kept in a link base. There
may be several link bases enabling users to have their own collection of links
etc. The fact that the EPJ operates in a heterogeneous environment also calls for
a solution with link bases, because the resources may reside in locations out of
control of the EPJ which makes it difficult to employ embedded links.
In relation hereto, flexibility is important in the framework. It should sup-
port a wide range of resources, but also be flexible enough to accommodate an
easy addition of new anchor and resource types or completely new objects. And
even though the framework is supposed to be used in an EPJ context and are
developed hereafter, it should still be usable in other domains. This puts high
requirements to the framework.
Simplicity is a key characteristic when incorporating something new into the
EPJ. The user interface should be simple and quick to operate. In order to be
used, the benefit of using the system should be clear and significant.
Implementing the framework in Clinical Suite is a major task and it will not
be possible to carry it out within the scope of this project (see 6.2). However,
theoretical guidelines are available. The framework should be divided in a gen-
eral part and a specific part. The general part includes a link engine, which
provides traversal functionality. The specific part encompasses definitions on
how to create anchors in resources, viewers and registrations.
41
43. Chapter 7
System Design
This chapter concentrates on the work conducted in order to design and develop
the framework for the EPJ. First the architecture of the system is presented and
described. Following that, a detailed representation is provided comprising the
framework and the pilot program. Finally, the system is evaluated.
Work conducted in this chapter builds on the other chapters, especially the
domain analysis chapter.
7.1 Architecture
Figure 7.1 depicts the architecture of the system.
Notepad
Services
Runtime layer
(framework)
Repository
Storage layer
XML, network, DBMS etc.
Non-hypermedia
aware viewers
Open Closed
ImageViewer
Viewer
Applcation layer
(pilot program)
Small SC
Hyper
Manager
Figure 7.1: Architecture.
42
44. Architecture
The architecture is inspired by the Dexter HyperText Reference Model (5.2.3)
and in particular by the layer rearrangement from (Grønbæk et al., 1997). It is
essentially a three layered architecture. At the bottom the storage layer is located
which ensure that objects in the system are kept persistent. In the project, XML
files is employed to store the objects since it is a straightforward and simple
solution in a development phase, however it may be changed to a network or
database solution if to be used in larger scale.
In the middle of the figure, the runtime layer is located, which comprises the
HyperEPJ framework. It is one of the utmost importance as it is the provider of
the different hypermedia services used by the system. Essentially the framework
provides an API that the surrounding modules can interface with in order to
communicate with the framework.
The interface Viewer and the class Services are the two most crucial parts
in addition to the Small SC framework. Viewer defines methods for working
with hypermedia structures such as anchors and links. Services implements
functionality like link traversal, anchor creation etc. Each will be described in
detail in the following.
Objects depicted in Figure 7.1 are hard-coded. Other objects or structures,
needed by the system, are generated by the Small SC framework using its tem-
plate mechanism and kept in the repository. In the following, a HyperEPJObject
refers to such a structure.
Finally, the application layer is on top. In this project the pilot program en-
compasses two applications Notepad and ImageViewer. Together they form the
application layer.
43
45. Storage layer
7.2 Storage layer
The storage layer is responsible for making the various objects in the system per-
sistent. Contrary the architecture just described, containing hard-coded classes,
the storage layer only deals with structural templates created by Small SC (5.4.2),
since they form the objects communicated in the system. The following table
presents a list of templates employed. They will be described in more detail in
the proceeding text.
Template Name Description
Registration A registration is a mapping between one or more file
extensions and an application.
Resource Holds information (name,path) about a resource
(text file, image, URL etc.)
ClosedAnchor Anchor type used by hypermedia unaware applica-
tions.
TextAnchor Holds information about anchors in text based docu-
ments. The TextAnchor includes locator properties.
ImageLocator Used to describe a selection in an image.
ImageAnchor Holds information about anchors in images. The lo-
cator information to describe a selected area in an
image is kept in the ImageLocator template. Reason
for doing so is the amount of information required.
Arc An arc is the binding between two endpoints in a
link. Each endpoint comprises an anchor of a partic-
ular type.
Link Encapsulates a link comprising a list of arcs.
Table 7.1: Structural templates used by the system.
Figure 7.1 is by no means exhaustive , since new template definitions may be
needed to accommodate future features. This is eased by the flexible template
mechanism in Small SC (see 5.4.2).
The templates are stored in an XML file. Figure 7.2 and 7.3 presents an ex-
ample of how a text anchor is stored. As mentioned in 5.4.2, templates are
defined with a set of associated attributes, that point to the structural building
block SCValue holding a particular primitive (string, int, id etc.). The first part
of the storage (7.2) comprises the template instance and the second (7.3) the
attribute values. All referencing between attributes and template instances are
resolved by Universally Unique Identifiers.
44
46. Storage layer
1 (...)
2 <HyperEPJObject>
3 <creationDate>1166187816984</creationDate>
4 <modificationDate>1166187816984</modificationDate>
5 <properties>
6 <property>
7 <name>arcs</name>
8 <id>39c4358f-0239-4132-95ee-8be31ad786c8</id>
9 </property>
10 <property>
11 <name>id</name>
12 <id>3cdd2529-24b2-4f43-93b6-351fd94ecf1c</id>
13 </property>
14 <property>
15 <name>name</name>
16 <id>d34e6a5b-a46c-423b-ad5e-1d235f6bff45</id>
17 </property>
18 <property>
19 <name>type</name>
20 <id>387df5bb-a5fc-4985-94b5-d2638d85c935</id>
21 </property>
22 </properties>
23 </HyperEPJObject>
24 (...)
Figure 7.2: XML storage example of a link template instance.
1 (...)
2 <!-- List reference to arcs -->
3 <entry>
4 <id>39c4358f-0239-4132-95ee-8be31ad786c8</id>
5 <HyperEPJList>
6 <entry>
7 <HyperEPJId>36dc16ac-77ba-4030-8e81-036e6d03e761</HyperEPJId>
8 </entry>
9 </HyperEPJList>
10 </entry>
11
12 <!-- Id -->
13 <entry>
14 <id>3cdd2529-24b2-4f43-93b6-351fd94ecf1c</id>
15 <HyperEPJId>96380aa2-fd08-43b0-ae72-cda49c93cdb7</HyperEPJId>
16 </entry>
17
18 <!-- Name -->
19 <entry>
20 <id>d34e6a5b-a46c-423b-ad5e-1d235f6bff45</id>
21 <HyperEPJString><![CDATA[link1]]></HyperEPJString>
22 </entry>
23
24 <!-- Type -->
25 <entry>
26 <id>387df5bb-a5fc-4985-94b5-d2638d85c935</id>
27 <HyperEPJString><![CDATA[link]]></HyperEPJString>
28 </entry>
29 (...)
Figure 7.3: XML storage example of attributes belonging to a link.
45
47. Runtime layer - HyperEPJ Framework
7.3 Runtime layer - HyperEPJ Framework
This section builds on the topics covered in the related work chapter specifically
the one concerning structural computing at page 24 and Small SC at page 26.
The development of the HyperEPJ framework consist of adapting the Small SC
framework to this context and developing specific functionality targeted for it.
Small SC is the core of the framework. It provides basic structural comput-
ing features like creation of structural templates with predefined properties and
option to retrieve them via search and queries. First, the data model for the Hy-
perEPJ is presented in Figure 7.4. Three components have been added to the
*
HyperEPJ
Object
<<creates>>
Template
Repository
Template
Manager
Query
Query
Manager
Query
Item
*
*
*
Attribute
Values
HyperEPJ
Value
property
Services
Viewer
Hyper
Manager
Figure 7.4: HyperEPJ data model.
Small SC framework: HyperManager, Viewer and Services. Each component is
described in detail in the proceeding text.
7.3.1 Link model
Figure 7.5 depicts the link model in HyperEPJ. It is inspired from the one in
Bouvin et al. (2003) and designed to be general so that it is able to model a di-
verse set of link and anchor types.
46
48. Link model
Anchor
TextAnchor
TypeProperty
HyperEPJId
HyperEPJString
HyperEPJString
HyperEPJString
HyperEPJString
resource
text
treewalk
context_pre
context_post
ClosedAnchor
TypeProperty
HyperEPJIdresource
ImageAnchor
TypeProperty
HyperEPJId
HyperEPJId
resource
locator
Locator
TypeProperty
HyperEPJInt
HyperEPJInt
HyperEPJInt
HyperEPJInt
x
y
width
height
Link
TypeProperty
HyperEPJList
HyperEPJList
arcs
objects
Arc
TypeProperty
HyperEPJId
HyperEPJId
endpoint1
endpoint2
Resource
TypeProperty
HyperEPJString
HyperEPJString
type
path
Figure 7.5: HyperEPJ link model.
Links in HyperEPJ are composed of a list of arcs. Each arc contains the prop-
erties endpoint1 and endpoint2, which are of the type Anchor. An anchor is the
structure that hooks up to the given resource from which it is guiding a link to, in
a traversal (see Figure 7.6). There may be created numerous anchor types in the
framework as it is only a new instance of the HyperEPJObject class associated
with properties.
HyperEPJ supports 3 anchor types: TextAnchor, ImageAnchor and Closed-
Anchor, all of which share the property resource. What separates them though,
is the information needed to locate a specific area within their type of resource.
This information varies according to the anchor type. The text anchor employs
information about text, surrounding the selection, to locate the correct anchor
while an image anchor uses a coordinate set (x,y) joint with dimension informa-
tion (width, height) to locate an anchor in an image. Finally, a closed anchor
uses a the resource path only to describe the resource.
The list structure in Link enables for multi-headed links. Furthermore, it is pos-
sible to "under specify" an anchor (seen in Microcosm 5.3.2), enabling special
link types like generic links. How this is implemented is described in 7.4.1.3.
Compared to other linking models like XLink (Derose et al., 2001) for instance,
the claim is that the linking model in HyperEPJ is more general, thanks to the
structural computing capabilities. Linking models like XLink provides generic
linking capabilities in both XML documents and non-XML resources and has
seen use in many systems offering open hypermedia such as Xspect (Christensen
et al., 2003) and xlinkit (Nentwich et al., 2002). These systems provide naviga-
47
49. Link model
tional hypermedia using XLink in conjunction with XPath (Clark and DeRose,
1999) and XPointer (DeRose et al., 2001). However, being suitable for naviga-
tional hypermedia, XLink faces problems when dealing with other domains of
hypermedia such as spatial or context-aware. Experiences include results men-
tioned in the development of the XSpect prototype (Christensen et al., 2003).
True, a link model based on XLink would provide the same features when de-
veloped for navigational hypermedia, but it would also restrict the potential use
in other domains and thus the extensibility and tailorability issue recognized by
Frank Halasz (5.2.1).
Compared to traditional object oriented approaches, the HyperEPJ model is
more flexible, due to the template mechanism in Small SC. When adding a new
anchor type to an object oriented model, a new class is needed in order to sup-
port the functionality. In HyperEPJ no additional hard-coded classes are needed,
only a new template definition, which can be created during runtime avoiding
compilation. Results from porting the object oriented data model from the con-
text aware hypermedia system HyCon to a structural computing based, was a
more simple and flexible model (Anderson et al., 2006).
It should be noted however, that the couple between structural templates and ob-
ject oriented languages poses a performance loss. Therefore, in a domain where
parameters like performance and efficiency are key to success a customized so-
lution might be preferable. The health sector relies, in many cases, on mission
critical software which qualify as such a demanding domain. However, as men-
tioned in 5.4.2 Small SC has proved capable of handling thousands of objects
when deployed in the SOS systems (Anderson, 2005), but whether it is sufficient
will be determined by future development of the framework.
A
nchor
R
esource
R
esource
Arc
A
nchor
Figure 7.6: HyperEPJ link structure.
’To and from’
When discussing link traversal, the user activates a link marker in a given re-
source and is taken to whatever anchor(s) the link is associated to. Simple link
types (from the Internet) consist of a pointer that allows the user to go from a
given source anchor to a given destination anchor and not back again. The terms
to and from are not right when compared to the abilities of the framework. Here
a link is merely a structure that takes as properties a list of arcs each consisting
of two endpoints. Which endpoint is the source, may not be explicit in the con-
struction (besides it is not important as long as there is an endpoint in the other
end). If you traverse a two-way link, you are taken to the destination of the link.
Then if you click the destination anchor it now takes the role of being the source
48
50. Hypermedia Augmentation
of the link, hence endpoints change semantic direction (see 5.3.4) depending on
the particular traversal, thus, referring to a to and from directionality, with re-
spect to the link model structure, is not quite accurate.
7.3.2 Hypermedia Augmentation
A key part of the framework is how it implements hypermedia services, as they
are not part of the Small SC framework. This process is described in the follow-
ing.
7.3.2.1 The Viewer Interface
In order for a given open application to work correctly with the framework,
some shared definitions on how to create anchors, links etc. must be established
between both parts. The interface Viewer takes care of that. The illustration
below depicts the interface:
void createAnchor(HyperEPJObject selection)
void setRessource(HyperEPJObject ressource)
void attachAnchors()
void displayAnchor(HyperEPJId anchorId)
HyperEPJObject getRessource()
HyperEPJObject getSelection()
Id _clientId
String _clientName
Viewer
Figure 7.7: Viewer interface.
Each client, that implements the interface, includes a clientId and clientName
variable to identify itself to the framework and other surroundings. Then it pro-
vides code for the methods listed in the interface that enables the user to create
anchors, attach anchors and display anchors when traversed. All parameters
passed to the various methods are of the type HyperEPJObject or the structural
building block HyperEPJValue. Instead of having hard-coded classes for selec-
tions and resources, they can be modeled as a structural template and individu-
alized in their set of properties.
When a client is developed to work with the framework, it simply implements
the interface and provides functionality for the methods in the interface. This
way the communication and flow of information takes place under agreed terms.
7.3.2.2 Hypermedia Services
The second extension to the Small SC framework is the class Services. This
class comprises the functionality available in the system. Services is a central
49
51. Hypermedia Augmentation
component in the framework, because it is the entry point for the application
layer. When the user performs an action in the system interacting with lower
layers, Services is involved. Figure 7.8 presents a class diagram of the Services
class.
Set<HyperEPJObject> findLinksToAnchor(HyperEPJId anchor)
void traverseLink (HyperEPJObject link, HyperId srcAnchor)
void createStructure(HyperEPJObject structure)
void deleteStructure(HyperEPJId structure)
Set<HyperEPJObject> getRegistrations()
HyperEPJObject getViewerName(HyperEPJString extension)
HyperEPJString _baseURL
Services _services
Services
Figure 7.8: Services class diagram.
Due to its vital role in the framework, Services is constructed to be general in
terms of its methods, that to a large extent interface to template instances (Hyper-
EPJObjects) or the basic structural building block (HyperEPJValue) similar to
the Viewer interface. An instance of this is seen in the methods createStruc-
ture(HyperEPJObject structure) and deleteStructu- re(HyperEPJId
structure) which are responsible for creating and deleting hypermedia struc-
tures in the system. The impact of having these methods interface structural
templates is that there may be created many different objects, only limited by
Small SC. However, if special program logic is required for a particular tem-
plate, this still needs to be handled in the method.
Indeed, it would be possible for modules to interact directly with the reposi-
tory in the framework, but I assessed that it would be better to included this
responsibility in the Services class, even though it is an extra stop on the way to
the repository. The motivating reason is the fact that the application layer only
has one entry point to interface, which makes it easier to develop applications
for the framework.
In order to handle traversals of two-way links in the framework, the traverse-
Link() method needs a parameter specifying from where the link traversed,
in the form of a source anchor id. Using the id, the framework matches with
both endpoints of the link and displays the resource connected to the anchor not
matching the source anchor id.
7.3.2.3 Administration of Hypermedia Structures
In conjunction with the Viewer interface, the framework includes a small graph-
ical user interface to administer hypermedia structures (anchors and links) in the
systems. The interface provides an overview of source and destination anchors
and links. Figure 7.9 depicts the interface.
50
52. Degrees of Integration
Figure 7.9: Administration of hypermedia structures via the HyperManager user inter-
face.
7.3.3 Degrees of Integration
Applications can interact on different degrees with the HyperEPJ framework.
Open hypermedia systems like Microcosm (5.3.2) and HyperDisco (5.3.3) em-
ployed similar approaches with the Fully Aware and Universal Viewer solution
and Full, Partial and None interaction respectively. Making applications interact
on several levels give potential for a broader spectrum of application than just
the one being developed specifically with hypermedia in mind.
Referring to Figure 7.1 the reader may recognize that the architecture is di-
vided in two levels vertically: open and closed. This means that the framework
supports two degrees of interaction with respect to the resources being displayed
in a link traversal, anchor handling etc.
Open
If an application implements the Viewer interface, it is developed in accordance
with the framework, meaning that it supports creation of anchors and links and
following traversal of these from the application.
Closed
If an application does not implement the Viewer interface, it is closed in terms
of the framework. Such applications can only be target in a link traversal(whole
component). When a user initiates a link traversal to an anchor displayed by
a closed application, the framework simply launches the application with the
resource as parameter. Figure 7.10 presents the degrees above (and potential
additions) in relation to the services provided by the framework.
51
