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 ScienceDepartment of Information and Media Studies

Aarhus Universitet

Contents

1 Foreword 31.1 Structure of this Thesis . . . . . . . . . . . . . . . . . . . . . . 31.2 About the Author . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Abstract 5

3 Danish Summary 6

4 Introduction and Motivation 74.1 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.2 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.4 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.5 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.6 Thesis Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Hypermedia Concepts 115.1 Brief History of Hypermedia . . . . . . . . . . . . . . . . . . . 115.2 Efforts toward Open Hypermedia . . . . . . . . . . . . . . . . . 12

5.2.1 Halasz Seven Issues . . . . . . . . . . . . . . . . . . . 125.2.2 Meyrowitz´ Eight Issue . . . . . . . . . . . . . . . . . . 145.2.3 The Dexter Hypertext Reference Model . . . . . . . . . 14

5.3 Open Hypermedia . . . . . . . . . . . . . . . . . . . . . . . . . 165.3.1 Chimera . . . . . . . . . . . . . . . . . . . . . . . . . . 165.3.2 Microcosm . . . . . . . . . . . . . . . . . . . . . . . . 185.3.3 HyperDisco . . . . . . . . . . . . . . . . . . . . . . . . 195.3.4 Devise HyperMedia . . . . . . . . . . . . . . . . . . . 205.3.5 Application Integration . . . . . . . . . . . . . . . . . . 215.3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.4 Structural Computing . . . . . . . . . . . . . . . . . . . . . . . 245.4.1 Themis . . . . . . . . . . . . . . . . . . . . . . . . . . 255.4.2 Small SC . . . . . . . . . . . . . . . . . . . . . . . . . 265.4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Domain Analysis 316.1 From Paper to Electronic Patient Journals . . . . . . . . . . . . 316.2 EPJ in Denmark . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.2.1 Goals and expectations . . . . . . . . . . . . . . . . . . 32

1

Contents

6.2.2 Heterogeneity . . . . . . . . . . . . . . . . . . . . . . . 336.2.3 CSC Clinical Suite . . . . . . . . . . . . . . . . . . . . 34

6.3 Efforts to Introduce Hypermedia in the Health Sector . . . . . . 356.3.1 Hospitexte . . . . . . . . . . . . . . . . . . . . . . . . 356.3.2 Integrating TeamRoom+ in the NHS, UK . . . . . . . . 36

6.4 Field work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.4.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.4.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 396.4.3 Theoretic implementation . . . . . . . . . . . . . . . . 40

6.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7 System Design 427.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427.2 Storage layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.3 Runtime layer - HyperEPJ Framework . . . . . . . . . . . . . . 46

7.3.1 Link model . . . . . . . . . . . . . . . . . . . . . . . . 467.3.2 Hypermedia Augmentation . . . . . . . . . . . . . . . . 497.3.3 Degrees of Integration . . . . . . . . . . . . . . . . . . 517.3.4 Registrations . . . . . . . . . . . . . . . . . . . . . . . 527.3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.4 Application layer - Pilot Program . . . . . . . . . . . . . . . . . 547.4.1 Notepad . . . . . . . . . . . . . . . . . . . . . . . . . . 547.4.2 ImageViewer . . . . . . . . . . . . . . . . . . . . . . . 587.4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.5.1 Test Sessions . . . . . . . . . . . . . . . . . . . . . . . 617.5.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8 Conclusion 648.1 Integration of Hypermedia in a Medical Context . . . . . . . . . 658.2 Reflections on Structural Computing . . . . . . . . . . . . . . . 668.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Bibliography 68

List of Figures 72

List of Tables 74

Appendices 75Appendix A - Usage examples . . . . . . . . . . . . . . . . . . . . . 75Appendix B - Hypermedia architecture development . . . . . . . . . . 81Appendix C - Installation guide lines . . . . . . . . . . . . . . . . . . 82Appendix D - Meetings with Inge Spangsberg . . . . . . . . . . . . . 83Appendix E - Meeting with CSC Scandihealth . . . . . . . . . . . . . 85Appendix F - The attached cd-rom . . . . . . . . . . . . . . . . . . . 87

2

Chapter 1

Foreword

1.1 Structure of this Thesis

The thesis starts with an introduction to the preliminary work in chapter 4In-troduction and Motivation. This chapter describes the vision for the thesis, ascenario concreting the vision, the motivation for doing the thesis, goals for it,its delimitations and the method applied.

The report continues in chapter 5Hypermedia conceptsdescribing backgroundknowledge in the field of hypermedia. The chapter both follows a historic timeline, from the start of the field and its progression, including concrete systemsdeveloped, and the transformation of the field from being monolithic and closedto open. The background knowledge is completed in section 5.4Structural Com-putingdescribing the reorientation of the field of hypermedia.

The thesis then progresses with chapter 6Domain Analysis. Firstly, it analyzesthe health sector focusing on electronic patient journals and secondly it describesthe communication and intervention work between the author and people in re-lation to the health sector.

In chapter 7System Designthe system is designed and implemented on basisof the results in chapter 6Domain Analysis.

Finally, in chapter 8Conclusion, the work is summarized including future thoughtsand reflections.

1.2 About the Author

The author of this master thesis is Søren Mygind Spangsberg, who is a masterstudent of information technology. Furthermore, Søren holds a bachelors degreein computer science.

3

Acknowledgments

1.3 Acknowledgments

Several people should receive special thanks for their work in relation to thisthesis:

Niels Olof Bouvin, Supervisor, Associate Professor, University of AarhusKenneth M. Anderson, Associate Professor, University of Colorado

Jan Mark, Chief Architect, CSC Scandihealth

Inge Spangsberg, MD, Radiologist, Randers CentralsygehusPoul Thorsen, MD, PhD, North Atlantic Neuro Epidemiology Alliances (NANEA)

Anna Hapunik, English Teacher, Master student of English Philology

4

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 healthsector to the staff. The development and integration of the EPJ in Denmark hasin recent years come closer to the awareness of many due to delays and troublesof communicating across EPJ systems. Furthermore, it is complicated to bringnew 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 thehealth sector staff, by creating links between vital information regarding a pa-tient etc.

Through open hypermedia technology and structural computing, a prototype hasbeen 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 companyCSC 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 healthsector and CSC Scandihealth are involved during the design process in order tobring their ideas and demands to the prototype.

5

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 afinformation omkring en patient, som er tilgængelig for sundhedspersonalet påalle tidspunkter og lokationer i sundhedssektoren. Opmærksomheden omkringudviklingen 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 komplekstdomæne at indføre IT-systemer i, fordi den nuværende praksis, i de eksisterendesystemer/strukturer, er veletableret og gennemarbejdet.

Visionen for projektet er, at hypermedieteknologi kan anvendes til at udvideEPJ´en, så det gøres muligt at udveksle informationer hurtigt mellem sund-hedspersonale, f.eks. ved at etablere links mellem vigtig information om enpatient.

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. Udgangspunktetherfor er et samarbejde mellem IT-firmaet CSC Scandihealth, som udvikler EPJsystemer både i og udenfor Danmark.

For at håndtere udfordringen omkring IT-integrationen i sundhedssektoreninddrages brugerorienteret design som et element i udviklingen. Brugere, medrelation 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ådantsystem.

6

Chapter 4

Introduction and Motivation

The topic Electronic Patient Journals (EPJ) has in most recent years come closerto the awareness of many. For several years the EPJ has been under developmentand is expected to modernize and rationalize the Danish health sector.

This information technology master thesis is devoted to a small area of theEPJ, 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 withindiverse applications and domains. Secondly, the functionality of the frameworkwill 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 beenx-rayed and the doctor in the examination of the picture afterwards identifiesan area with illness and wants to share this important piece of information in afaster way than just to write a note. This could be handled using a link from theEPJ to the xray picture.

4.2 Scenario

The job of the scenario is to expound the vision and describe how it can beimplemented. 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 anarea of illness. To make it easy for the next doctor to get updated on the area, thefirst doctor makes a link from a descriptive text in the given EPJ to the specificarea in the x-ray. How this is carried out practically depends among others ofthe graphical user interface implementation of the EPJ. The scenario starts withthe 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

Motivation

for information. At a certain time in the browsing process the doctor becomesaware 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 todo research in the field of hypermedia. The author has become acquainted withresearch in the health sector and neuro diseases in Denmark through work in theresearch unit NANEA (North Atlantic Neuro Epidemiology Alliances). www.nanea.eu

In relation to this the author has met Jan Mark from CSC Scandihealth, whodevelops EPJ systems in Denmark and other countries, who seemed to be inter-ested in instituting a cooperation.

8

Goals

4.4 Goals

The main work to be carried out can be divided into three goals:

Primary goal

The primary goal is todevelop 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 programthat simulates the look and behavior of an EPJ nevertheless in much smallerscale.

The pilot program will feature a graphical user interface. It should support linkcreation 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 withinthe EPJ from CSC Scandihealth. However, CSC Scandihealth is in a positioncompeting with other vendors about EPJ solutions. Therefore, implementationdetails about their EPJ are kept within the company and thus not available to theproject. Moreover, the integration is ample, meaning that the EPJ is a complexpiece of software, which will certainly lead to a difficult and time consumingprocess of integrating the two.

4.5 Delimitations

The project focuses on the link aspect of hypermedia in the EPJ. Hence, otherhypermedia related issues such as collaboration and Human Computer Interac-tion issues takes a secondary role in the project.

9

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 hypermediatechnology with the EPJ.

The project follows a development plan comprising the following phases, whereeach may be iterated:

1. Domain analysis

2. Design

3. Implementation

4. Evaluation

Moreover, participatory design (Schuler and Namioka, 1993) are brought in asan element in the project, in order to involve the end users in the developmentphases. 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

Chapter 5

Hypermedia Concepts

This chapter describes the development of hypermedia. It starts with a briefhistory of the field and continues with open hypermedia systems. From here thechapter relates to the transition from open hypermedia systems to the field ofstructural 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 associativenetwork of nodes and interrelated links(Bieber et al., 1997)

This linking and cross-referencing can also be defined as non-linear text orhyper-text, which is the contrary to reading a book from start to end. Heresmall chunks of information can arbitrary be connected via relations or links. Itwas first recognized as a field by Vannevar Bush, when he published the articleAs We May Think(Bush, 1945). Herein he presented a hypothetical machinecalled the Memex, which was basically a way to store and retrieve informationon 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 thatallows people to retrieve information from a computer in many of the same waysin which retrieval is accomplished within human memory(Bush, 1945)

Through the Memex the user could create associative links between documentsand thus it was much similar to what we now callhypertext. The links could bechained into a collection, known as a guided tour. The Memex helped form thebasis for fully implemented hypermedia systems. It was not only a magnificentidea; it made people think in another way about how they did their job. Busheven anticipated an entirely new job function, known astrail blazer, for expe-rienced users with the main job of following and creating these guided tours inMemex. A very interesting thing in Memex (compared to the development ofthe field) was theview specificationthat, along with the content to be displayed,

11

Efforts toward Open Hypermedia

instructed Memex how to display it.

The pioneering work of Bush has marked the field of hypermedia and are stillpart of the research today. Due to the theoretical nature of the Memex, it couldnot 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 prominentwere NLS/Augment (Engelbart, 1984), KMS (Akscyn et al., 1988), Intermedia(Yankelovich et al., 1988) and NoteCard (Halasz et al., 1987). They includedadvanced hypermedia functionality compared to their time. Features such asvideo conferencing in NLS/Augment and advanced link construction as well asstorage (as in Intermedia), showed that these were outstanding hypermedia sys-tems with a lot to offer for their users. Butwithin their domain only. As longas 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 systembecause they suffered from a monolithic nature. They were closed. It was notpossible to exchange data between the systems neither use your favorite editornor application and still get hypermedia functionality.

Furthermore, the systems were diverse in their implementation. The fact thatNLS/Augment used statements, KMS frames, NoteCards cards and Intermediadocuments to hold information, and that their linking capabilities differed, rang-ing from one-way embedded to directionally external, illustrated that they weredeveloped 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 calledReflections on NoteCards: Seven issues for the next generation of hyperme-dia systems(Halasz, 1988), criticizing NoteCards, which was a member of thegroup of classic hypermedia systems and thus represented it. The output wasseven issues that according to Halasz could free the next generation of hyper-media systems from the drawbacks of being monolithic and closed. These issuesshould be taken into account when the next generation of hypermedia systemswere being developed. The issues were:

Search and Query

Halasz identified the need for improvements of retrieving the various objectsin hypermedia systems. Being able to navigate within the system is a definingproperty of hypermedia systems and hence it should support an advanced searchand query mechanism. Halasz imagined that effective mechanisms would notonly help users get quick access to their information but also filter unwantedcontent from the interesting.

12

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 matchinga particular parameter in the data.Give me all objects that contain the string"medicine"could be an example of a content based search. Structure basedshould on the other hand search for special structural characteristics within theobjects whereasGive 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 werepoorly supported in NoteCards, that featured the special card called a FileBoxwhich 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 inthe Filebox they just pointed to that card and not also to the head card and theFilebox 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 queryand present the resulting content as a virtual structure on the same level withother objects in the system.

Virtual structures can be related to the view feature of the relational databasemanagement system (RDBMS) where a dynamic table can be created based ona query in the Structured Query Language (SQL). Views behave the same wayand can be applied to the same operations as ordinary tables except that they arekept 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 didnothing on its own initiative. Halasz proposed the idea of having an engineperform computations on the structures of the users, the link network e.g. Thepurpose 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 towww.amazon.com

your particular interests and offers items that match the one you have previouslybought.

The computation mechanism could make the next generation hypermediasystems behave less static and suit the users better.

Versioning

In order for the next generation of hypermedia systems to fit a broad range ofapplication domains they should support versioning of the various objects likelinks and nodes etc. NoteCards did not offer any versioning control, in that itwas only possible to keep track of one copy of a card.

13

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 agiven 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 allsupported extension via application program interfaces or object oriented frame-works. But they were all targeted for programmers or people with experience incomputer science and it was thus rather difficult for the common person, whowas only interested in using the system and not in knowing all about it, to extendit. One solution could be to include script languages or macros, so people with-out experience in programming languages could make minor changes to theirsystem.

5.2.2 Meyrowitz´ Eight Issue

Following Frank Halasz´ seven issues, Norman Meyrowitz added an eight issueto the collection published in the articleThe Missing Link: Why We Are AllDoing 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 insoftware. It was due to the fact that they weremonolithicin nature. Even thoughthe 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. Itwas impossible for a user to step outside of the systems, into his or hers favoriteprogram to edit a given content and still have the hypermedia support. If the nextgeneration hypermedia systems were to overcome that, their services should beavailable at the operating system level, enabling developers to integrate it likethe copy, cut and paste convention.

5.2.3 The Dexter Hypertext Reference Model

The Dexter Hypertext Reference Model (Halasz and Schwartz, 1994) is a resultof 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 lackedgenerality. The classic hypermedia systems did provide hypermedia functional-ity but in their own definition of links, nodes and format. They were diverse. TheDexter model tries to unify these definitions more generally in order to comparedifferent systems to each other and exchange data between them.

Examples of contributions from the Dexter model was a general hypermediaarchitecture, generalization of links from binary to arbitrary dimensions and anupgrade of links, nodes and composites as first class objects. The Dexter archi-tecture is depicted in Figure 5.1.

14

The Dexter Hypertext Reference Model

Figure 5.1: Dexter model architecture (Halasz and Schwartz, 1994).

The architecture is composed of three layers:runtime, storageand within-componentof which the storage layers is of the greatest interest.

Runtime LayerThe runtime layer manages all with respect to presenting the hypertext to theuser. With help from presentation specifications, the hypermedia structures maybe 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 PSpecand it emphasizes that Vannevar Bush was ahead of his time in terms of hyper-media research.

Storage LayerThe storage layer is responsible for storing and retrieving links and anchors.Thus it is only the hypermedia structures the storage layers manages and not thecontent they apply to. The separation of structure and content, though made theinteraction with the surrounding interfaces important, hence the anchor is a vitalpart of the model since it is the connection between the two. In the model ananchor 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, havingthe advantage of not constraining future implementations.

Within-Component LayerThe within-component layer was not further specified in the model due to thesame concerns just mentioned.

15

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 ispart of almost every software programs today. The reasons why the vision hasnot 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 tointegrate 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 developerto implement the functionality, and thus it will only be the people that prioritizesit. 2 is rather more straightforward to work with and that was the approach theresearch community followed and still follows to improve the chances of thevision to be fulfilled. While the monolithic systems where designed as an inde-pendent environment without or with limited awareness of other software, theopen hypermedia systems are characterized as being developed using open stan-dards and protocols. An Open Hypermedia Systems Working Group has beencreated 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 developedat 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 areinterrelated in a way. Examples of such include requirement specifications, dia-grams, source code, test results etc. The process of initializing and maintaining

16

Chimera

the objects and their relations is challenging, and therefore Chimera was createdas 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 tothe fact that a frequently required functionality in software development envi-ronments is the ability to view a given object from different perspectives. Forinstance if you design a web page, it is convenient to be able to view the actualgraphical 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 presentsthe graphic aspects of the program and a viewer that presents the lines of codebehind. 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 maybe 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 hypermediaservices provided within Chimera can be extended to cover those applicationsas 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 viewerconcept

17

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. Themajor downside of the system, however, was the fact that it is an old piece ofsoftware. In fact, it is not developed anymore, which makes it uninteresting towork with.

5.3.2 Microcosm

Microcosm (Davis et al., 1994) is an open hypermedia system developed at theUniversity of Southampton. It featured a shared link server and client integra-tions with several third party applications. Microcosm was easy to implement inapplications, since it could be accomplished in various degrees of integration:

1. Fully awareIf 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 moresophisticated, since it looked more as if the application were designedwith 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 ofparticipating in all five protocols. However, is was also possible to interactwith a subset.

2. Universal viewerApplications with no communication facilities except the one hosted bythe operating system, could be integrated using a "shim" program calledtheUniversal Viewerwhich placed itself in the title bar of the target pro-gram. The Universal Viewer took care of communication between thetarget 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, makingit easier to implement applications because it put smaller demands when theywere releaved of these tasks. It posed a drawback though, since Microcosm hadto be compatible with the applications in order for the hypermedia functionalityto work and significant improvement had to be done to update Microcosm whenan application changed.

Links in Microcosm where one-way, consisting of two anchors each comprisingthe name of the media, the selection and an offset to locate it. An interestingfeature 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

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 alink 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 ondistribution andcollaboration and was created with the goal to make a general open hypermediasystem that focused on providing tools for both collaboration and distribution,

19

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; aconcept like the relational database management system but designed to storehypermedia 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 linkbase could be distributed across a network or the Internet allowing people towork on it at distant locations. Furthermore HyperDisco provided a rich way ofintegrating applications:

1. FullClosely related programs could have their data and hypermedia structuresstored in the link base.

2. PartialApplications not capable of fully interaction with HyperDisco could havehypermedia structures stored within HyperDisco, while the content residedsomewhere else e.g. inside the filesystem.

3. NoneApplications not developed for hypermedia were integrated in such a waythat they constituted destination anchors in a link only and not sourceanchor 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 frameworkdeveloped at the University of Aarhus. It was based on the Dexter ReferenceModel and the primary goal was to prove both the validity of the model andits defects. As with Chimera and HyperDisco, Devise HyperMedia made useof a link base structure, in the form of an object oriented database (OODB), tostore links and other hypermedia structures. The use of external storage madeit possible to apply linking in other media than text documents. Hence DeviseHyperMedia was able to reference many types of media (Grønbæk et al., 1997).

The developer did not build Devise HyperMedia strictly in accordance withthe Dexter model. Among others they decided to include dangling links in thesystem, with the argument that it enables flexible link construction.

Another interesting feature was the notion of link directionality explored in theproject. Three notions were identified:

• Semantic directionDefines a semantic meaning in a given relationship. For instance, a diag-nose explanation (A) supports a complex diagnose used in the EPJ (B).

• Creation directionDetermines the order in a creation what will be source and destinationanchor. The first becomes source and the second becomes destination

20

Application Integration

• Traversal directionThe direction is set explicit by the user in a creation. The link may thenonly be traversed in that direction

Devise Hypermedia has been used in conjunction with research projects withMjoelner Informatics and EuroCode. Furthermore it has been subject to tests inwww.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 couldtalk to each other and exchange information between them. Integrating such ap-plications is difficult due to the closed nature of the applications. For instance, itis difficult to store links within the documents, if the structure of the documentis unknown, rendering it necessary to store links externally in databases (linkbases).

The degree to which applications can be augmented with open hypermedia sys-tems depends on the architecture of the application, communication protocolsand file formats among others. If the application is easy to integrate, a solutionwith 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 theapplication, such as available source code. Often software companies refuse torelease the source code to their products due to competitive concerns, whichmakes 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 beintegrated into other appli-cationsand provide hypermedia functionality instead of providing applicationsalready capable of doing that. As Meyrowitz recognized in his eight issue (Mey-rowitz, 1989), hypermedia services should be integrated into the favorite editorsof the people instead of developing hypermedia programs not used, because ofdiscrepancies 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 DexterHypertext 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

Summary

structures. Devise HyperMedia was developed as aDexter-basedhypermediasystems and thus adapting many of the principles of the model. HyperDiscoencompassed many of the issues (5.2.1) proposed by Halasz (Halasz, 1988).

A characteristic among the open hypermedia systems is the use of externallystored 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 notalways able to place the link anchors within the resource. Externally stored linksbenefit the system so that it facilitates the process of computing graphical viewsof a web of links. Furthermore, it makes link handling flexible since users canhave multiple link bases.

Grønbæk and Trigg (1999) have compared the approach of embedding linkswithin the resource with external links separated from the resource. Table 5.1illustrates the comparison.

Embedded link ap-proach

External link approach

Storage of links Jump addresses insidecontent.

Link objects in separatedatabase.

Openness with re-spect to linking

Closed, requiring specialcontent formats likeHTML or VRML.

Open, requiring no spe-cial formats; material inthe applications´ formatcan be linked

Media support Links are mostly sup-ported from text-baseddata.

Links may interconnectsegments in any data-typee.g. video.

Maps of linkstructures

It´s difficult (often impos-sible) to see the links to aspecific document (searchengines give only partialanswers).

Link relations can be in-spected and maps gener-ated.

Distribution Simple - only content hasto be distributed.

More complicated - linkshave 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 waysome systems provide degrees of integration for third party applications. Mi-crocosm included the fully aware and universal viewer solution and HyperDiscofull, 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 inAppendix B - Hypermedia architecture development

22

Summary

at page 81, the transition from the classic hypermedia systems to the open is de-picted inFigure 1b - Abstraction of Applicationswhere application is abstractedaway from the system. This means that third party applications can be extendedto support hypermedia functionality.

Additionally, Figure 1c - Abstraction of Storeillustrates how the storage ofhypermedia structures are abstracted from the system meaning that the systemsdo not employ proprietary formats, nonetheless they are able to exchange dataacross different systems.

23

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 ofhypermedia. In 1997 Peter Nürnberg et al. published the articleAs We ShouldHave Thought(Nürnberg et al., 1997). Herein he and his co authors argued thatthe ideas of hypermedia should be generalized into a new research field calledStructural Computing.

The main point of the article is thatstructure 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 suchas files, objects and basic primitives such as integers and strings. Instead afile could be modeled asstructure with content. Furthermore, it is a claim, inthe article, that navigational hypermedia is just a specialized domain of struc-tural computing (Nürnberg et al., 1997). Other domains like spatial hypermediaor taxonomic hypermedia could likewise be considered specializations of thisgeneral way of doing computing as we may view structural computing. It is afundamentally new way of seeing these concepts and consequently it requires ashift 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 hypermediasystems.

1. Current hypermedia systems offer good support for the navigational do-main. Nevertheless, when it comes to an emerging set of new domains, itfails, because the terminology for navigational hypermedia is not generalenough to accommodate requirements of other and different domains asspatial and taxonomic hypermedia.

2. Hypermedia is a field concerned with structure and organization. More-over, it is aboutcreating and using structure over information(Hicks andWiil, 2003). However, major software are developed on the basis that datais more important than structure and hence structure is rated thereafter.Instead it would be a natural progression to focus on structure instead ofdata. This might ease the structure related tasks performed in hypermediasystems.

The shortcomings of those two observations may already have swayed negativeinfluence 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 systemsbased on structural computing. In open hypermedia systems, the hypermedia

24

Themis

functionality was an integral and defining part of the system. In structural com-puting systems, however, the hypermedia functionality is banned. If includedwithin the framework it would be too specific to accommodate the vision byNürnberg about multiple domains. Therefore they only define how to modeldata 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 SmallSC.

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 isa structural computing system created by researchers at the University of Col-orado, Boulder. The purpose is to provide a generic information store to a broadspectrum 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 manydifferent types of structures without adding new classes to the framework. Thisis an attractive feature because it keeps the framework simple.

At the core of the framework are the classesElement, Atom andCollection.Atom and Collection are sub classes from Element. Elements contain attributesto describe their content. Furthermore, the Collection class is capable of hold-ing other Elements which allows the framework to model complex hierarchicalstructures.

In order to make the elements available, they are stored in the classRepositorywhich is also responsible for persistence and provides search and query func-tionality. The framework is then hosted by a server from where clients canaccess its services.

The two extension mechanismsTemplateand Structure transformationsaddspowerful features to the framework. A template is a commonly used structure ina specific domain that is defined with a set of properties. Templates are storedin 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 codingof classes when new domain objects are needed since they are kept outside ofthe application.

25

Small SC

Figure 5.5: Themis architecture.

The second extension mechanismStructure transformationenables the frame-work to perform transformation between any two templates in the templaterepository.

The architecture in Themis enables developers to create dynamic data models.Thanks to the template mechanism, developers can spend less time in definingand creating domain specific objects without the need to add more hard-codedclasses to the framework.

However, Themis is heavy-weight, meaning that it is complex to install andsetup, due to its comprehensive nature (server, framework, client, extensionsmechanisms).

5.4.2 Small SC

Small SC (Anderson, 2005) is a structural computing framework that aims toprovide the same flexible capabilities in the form of structural templates but ina simpler fasion compared to Themis. It may be used to generate data modelsfor diverse applications and has seen use in domains such as requirements en-gineering (Anderson et al., 2002), scientific computing (Anderson, 2005) andcontext-aware hypermedia (Anderson et al., 2006). Furthermore, it provides ba-sic functionality like storage, retrieval etc. of diverse domain objects that allit-systems utilize to some extent.

26

Small SC

Small SC is developed with the purpose of enabling developers to adopt theframework to their particular domain. An objective was to create a packageeasy to distribute and use for developers. Small SC meets these requirementssuccessfully considering the fact that it only constitutes a single Java packagefile (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 standardstructural 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 furtherdeveloped through its use and now comprises search and query functionality,among other features, compared to the initial versions.

*

Object

<<creates>> Template

Repository

TemplateManager

Query

QueryManager

QueryItem

*

*

*

AttributeValues

SCValue

property

Figure 5.6: Small SC data model. Modified version from (Anderson et al., 2006)

The classesObject, Repository andTemplate make up for the essential pack-age to provide a framework with structural computing capabilities. Templatesare entities that define and create objects associated with a pre-defined set ofattributes. Objects are stored in the repository where they can be retrieved andmodified.

The framework also defines a generic class calledSCValue, from whichall values used by the system are modeled. In the framework values such asstrings, 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 morecode to the framework. In other words the framework enables the user to create

27

Small SC

large data models and still maintain its small and simple nature since all domaindata used in the system are defined and created as objects and thus only requireone 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 mechanismFigure 5.7 presents a code example of how to create a template for the objectslocator andimageanchor. 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());45 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));67 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 examplecode illustrates, the first thing to do is define the structure of a particular namedtemplate and associate it with properties. Each property is assigned a name, atype 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

Small SC

Query mechanismSmall SC is able to perform searches in the repository using its query mecha-nism (Anderson et al., 2006). It comprises the classesQueryManager, QueryandQueryItem.

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 searchfor all objects in the repository that are of the type Anchor and where the nameproperty istextanchor03. 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");45 query.addItem(item);6 query.addItem(item2);78 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 ofthe typeAnd, whose result objects only satisfy the query if both query itemsare fulfilled. Queries can also be of the typeOr, which requires only oneof 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 howproperties match. Small SC includes several filters that enable many levelsof matching, among them the above usedStringIsFilter where a propertyvalue meets the criteria only if the exact value matches the property of the queryitem. Other filters areStringContainsFilter, StringStartWithFilter andStringEndsWithFilter.

Using appropriate filters and query types provide users of the frameworkwith flexible and powerful ways of finding structures in the framework.

As far as scalability is concerned, Small SC has proved capable of handlingvery 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 creatingthe framework is completed. The following part of the thesis concentrates onwork required to adapt and extend the framework for this particular project anddomain. This will involve adding various methods to manage link traversals andcreation, deletion and editing of anchors. When this is accomplished the nextstep is to develop a program that can demonstrate the functionality in a waysimilar to an EPJ, but in a smaller scale. This work will be described in the nextchapter.

29

Summary

5.4.3 Summary

Structural computing is the next phase in the development of hypermedia. It wasintroduced by (Nürnberg et al., 1997) as a response to the fact that it was hard todescribe 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 onthe philosophy that structure is above data. Compared to the open hypermediasystems, structural computing systems defines a broader spectrum of use. Con-trary to open hypermedia systems, structural computing systems can be used toanything 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 managegenericstructures in the form of templates. However, they donot define hypermedia functionality such as linking since this is a special taskfor structural computing. Being a part of the core, they would not constitutestructural computing but hypermedia systems.

30

Chapter 6

Domain Analysis

This chapter describes work conducted in relation to the health sector and EPJsystems. It starts with an introduction to the transition from paper to electronicpatient journals. Following that, it relates to the development and integration ofEPJ 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 requiredin a future framework, which is derived from meetings with external people inthe 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 thatIT-systems are widely integrated in hospitals and at general practitioners. Muchof the information concerning patients are stored digitally and used among thestaff. 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. Theycan 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 (assumingproper 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 danishhealth authorities published the report "Handlingsplan for Elektroniske Patient-journaler" (Sundhedsministeriet, 1996). On basis of that report, 13 EPJ projectswere granted funding to develop and integrate EPJ systems in the danish hospi-tals. At the same time the organization EPJ-observatoriet , was established inwww.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.1www.systematic.dk

www.wmdata.dk

www.scandihealth.dkpresents an overview of which county/region each company provides EPJ sys-tems to.

31

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 accessto 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 abouta patientwhere-everandwheneverneeded, 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

Heterogeneity

Generation 0 1 2 3Philosophy Office support

and documenthandling

Availabilityand security.Replace paperjournal.

Clinicalprocesssupport, in-tegration andwork flow

Omnipresent

Platform DOS/WindowsMainframe

Windows NTMainframe

Integrationplatforms

Pervasivecomputing

Table 6.1: EPJ development (based on (Steenberg, 2003)).

systems were local with respect to data exchange and standards. From hereit has progressed to second generation EPJ systems which focus more on theprocess 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, whichis available everywhere and anytime. The use of pervasive computing in relationhereto aid this.

According to the newest status report from EPJ Observatoriet, an approximateof 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 beenmet. 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 beenpostponed many times due to various difficulties. A contributor hereto includethe fact that many of the EPJ projects are bounded within a given county in Den-mark, which has resulted inlocal solutions, that works fine within the county butnot 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 EPJdevelopment and is currently put on hold in version 2.2. However, many of theEPJ 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 witheach other. Therefore, the estimated deadline has been set to 2015 according toEPJ-observatoriet (Vingtoft et al., 2005, page 28). The hospitals, however havea 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 aboutthe patient is used

33

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 apatient. Informations contained within it may be results from blood samplesor other examinations (exchanged from the laboratory information system) andmedical condition if the patient suffer from an illness. The laboratory informa-tion systems keep information about test results from blood samples and otherhuman fluid or tissue samples. These data are exchanged between the generalpractitioners or hospitals. Blood bank systems contain information about storageof blood used in operations, transfusions etc. Finally, the hospitals use varioussystems to perform tests like xrays and CT/MR scannings.

The EPJ must be able to interface to these systems and display selecteddata 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 thehypermedia system. Thus, it is a necessity that the framework can handle thisand is able to interconnect the resources even though they are beyond its owndomain.

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, maybe 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 generationEPJ, which means that it is focused on the clinical process. It is based on amodular architecture that facilitates diverse usages, since modules can be addedor 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 supportthe diverse set of clinical data. These are available through application programinterfaces.

Linking CapabilitiesClinical Suite does not contain any built-in linking features. However CSC hadboth the idea and request from customers (see page 85), nevertheless it is not animplemented 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 characteristicsand capabilities with the intent of implementing it in Clinical Suite. This workis described in 6.4.

2Java 2 Enterprise Edition

34

Efforts to Introduce Hypermedia in the Health Sector

Figure 6.2: CSC Clinical Suite.

6.3 Efforts to Introduce Hypermedia in the HealthSector

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 conceptslike Computer Supported Collaborative Work (CSCW) and linking as a tool tosave time.

6.3.1 Hospitexte

Hospitexte (Charlet et al., 1998) is a project from 1998, which aimed to createa hyper textual electronic patient journal. The idea behind, was the claim thatmedicine is an empirical domain and thus fundamentally resists formalization.The normal solution to model a paper journal electronically would be to create adatabase 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 whichcontext 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

Integrating TeamRoom+ in the NHS, UK

of documents and annotation. Furthermore, it is based on structured, textualdocuments 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 annotationfeatures that enable the staff to create documents including knowledge aboutpersonal questions or tasks.

6.3.2 Integrating TeamRoom+ in the NHS, UK

In 2000, the National Health Service in the United Kingdom explored how toemploy CSCW-technology to support their teams in improving health serviceand modernization (Connor and Finnemore, 2003). They utilized the IBM de-veloped software TeamRoom (Roseman and Greenberg, 1996b,a) to make betteruse of their time. Specifically, they explored the possibilities in CSCW softwareto develop their usualsame time/same placework methods toany time/any placeaccording to the four quadrant time and space model (Kaplan, 1997). They con-cluded that:

(...) the key to successful technology supported collaboration depends not only onthe technology, but also on the organization´s ability to adopt an entirely new wayof 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 hasmainly consisted of meetings and interviews with people in relation to the healthsector in Denmark, who have brought their ideas, thoughts and concerns to theproject.

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 theywill be the one struggling with it if the process of designing and developing ithas been insufficient.

People involved in the project are:

Jan MarkJan Mark is chief architect at CSC Scandihealth . www.scandihealth.dk

Inge SpangsbergInge Spangsberg is a radiologist at Randers Centralsygehus. She is a future userof the EPJ being developed in Denmark.

36

Usage

Poul ThorsenPoul 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 toAppendix 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 sothat 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 alsoenabled the user to establish connections between objects of interest and navi-gate between them. However, hospital staff, like Inge, are busy and do not havetime to spend unnecessary effort in using them. If the final design is poor thefunctionality will not be used. Similar opinion was expressed by Jan, who puta more concrete angel to it by mentioning that it should be possible to operatethe functionality in 1-2 seconds. If it takes longer or is too complex, the peoplewill 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,nonethelessthey work and the staff is familiar and satisfied with them (Tange,1995). Hence, it makes it difficult to change peoples work habits and routines tosomething new and different. Even though it is new functionality, it is alsoextrafunctionalitythat must be included in the normal procedures.

Therefore, the benefit, of using the system, must be clear and significant forthe 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 comparedto the paper journal, which should be considered when developing hypermediafunctionality for the EPJ. Being materialistic, the paper journal supports the useof 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 patientjournals (Bringay et al., 2004). The reason why formulars and other documentsare 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 (Bringayet al., 2004).

Since the hypermedia functionality (ideally) should be used as an integral partof the EPJ, much effort should be put into the user interface of the EPJ as seenin (Nygren et al., 1992). At minimum, we should ensure that it supports normaltasks 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 tonavigate and read the content compared to a paper journal.

37

Usage

Use ScenariosTo illustrate how hypermedia services can be used within the health sector threeuse scenarios are provided below. They have been created in collaboration withJan and Inge.

1. The first situation is where a doctor is writing a note or diagnosis andwants to link to an external explanation of the diagnosis, which may behelpful for younger and less experienced doctors. Additionally hospitalsmaintain 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 orexternal).

SUGGESTED SOLUTION:A feature similar to thegeneric linkis 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 explanationexists 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 ordiagnosis with the information that lead to it. The supporting informationusually reside within the EPJ system or its surrounding applications andthe 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 apatient, looks for anything suspicious, finds an area with illness and wantsto 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 withinthe 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 anchorto 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 atthe moment. In order to highlight something in an image, she makes acopy 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 theconclusion text and xray image must be augmented with a hypermediaextension in order to establish the link.

38

Security

3. The third case is when a doctor is busy with the EPJ of one patient andneed to focus attention on another, and thus wants to make a bookmark sohe 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 theresponsibility of the EPJ user interface and thus placed at CSC Scandi-health.

ResourcesThe job of connecting something presumes that content exists to connect. In thehealth sector many types of resources are used in order to describe and illustratethe 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 descriptionsand 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 andaccelerates the navigation process.

What type of resources exists that can be interconnected in the EPJ? Table 6.2introduces some examples:

Resource Practical exampleText Notes, diagnoses, explanations etc.Tables/charts Electrocardiogram (EKG)Pictures Digitized (CT/MR single pictures)

Not digitized (old x-ray pictures, sketches or photographs)Audio DictationsVideo 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 toembed anchor information in non-text resources like audio or video. (2) thereare potentially many users accessing and creating anchors within the resources,rendering it unhandy with to have anchors shared between them due to accessconcerns. (3) data from surrounding systems may be proprietary to the systemmaking 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 thetreatment of a patient it may have far-reaching consequences for the hospital, the

39

Theoretic implementation

individual doctor and the patient. Hence all tools that can assist in minimizingmistakes 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 informationabout a similar case. To help future cases, he or she can make this particular caseavailable for other in the form of a anchor to which other can link to in order tosupport their case.

Another example pointed out by Inge is when a radiologist makes a link ina image, it both serves as a link from which others may traverse, but also as avisual proof of the assessment made by the doctor. In case of disagreementsbetween the doctor and patient, it is possible to go back and inspect the visualanchor 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 withJan, one feasible solution is to divide the hypermedia system in two: a generalpart and a specific part.

General partThe general part consists of a link engine which is responsible for performingtasks such as going from A to B in a link traversal or displaying annotationsfor a particular link marker. The link engine is embedded into the EPJ where itprovides linking functionality for the users.

Specific partThe specific part of the solution encompasses structures that are hard to definegenerally such as anchor specifications and registrations describing with whatapplication 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 tothe 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.3displays 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

Summary

6.5 Summary

Chief architect from CSC Scandihealth Jan Mark, radiologist Inge Spangsbergfrom Randers Centralsygehus and Poul Thorsen, MD, PhD from Nanea haveprovided their opinion on how to develop and implement hypermedia function-ality in the EPJ.

The framework shouldsupport hypermedia functionality for diverse resourcetypeslike text, graphics, video, audio and 3D etc. Performing the individualattachment of the resources depends on the nature of each resource. Attachingan anchor in a text file differ from an image or video file. To accomplish this,the framework will make use ofexternally stored linkskept in a link base. Theremay be several link bases enabling users to have their own collection of linksetc. The fact that the EPJ operates in a heterogeneous environment also calls fora solution with link bases, because the resources may reside in locations out ofcontrol 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 aneasy addition of new anchor and resource types or completely new objects. Andeven though the framework is supposed to be used in an EPJ context and aredeveloped hereafter, it should still beusable in other domains. This puts highrequirements to the framework.

Simplicity is a key characteristic when incorporating something new into theEPJ. The user interface should be simple and quick to operate. In order to beused, the benefit of using the system should be clear and significant.

Implementing the framework in Clinical Suite is a major task and it will notbe 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, whichprovides traversal functionality. The specific part encompasses definitions onhow to create anchors in resources, viewers and registrations.

41

Chapter 7

System Design

This chapter concentrates on the work conducted in order to design and developthe framework for the EPJ. First the architecture of the system is presented anddescribed. Following that, a detailed representation is provided comprising theframework and the pilot program. Finally, the system is evaluated.

Work conducted in this chapter builds on the other chapters, especially thedomain 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-hypermediaaware viewers

Open Closed

ImageViewer

Viewer

Applcation layer(pilot program)

Small SC

HyperManager

Figure 7.1: Architecture.

42

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 isessentially a three layered architecture. At the bottom the storage layer is locatedwhich ensure that objects in the system are kept persistent. In the project, XMLfiles is employed to store the objects since it is a straightforward and simplesolution in a development phase, however it may be changed to a network ordatabase solution if to be used in larger scale.

In the middle of the figure, the runtime layer is located, which comprises theHyperEPJ framework. It is one of the utmost importance as it is the provider ofthe different hypermedia services used by the system. Essentially the frameworkprovides an API that the surrounding modules can interface with in order tocommunicate with the framework.

The interfaceViewer and the classServices are the two most crucial partsin addition to the Small SC framework. Viewer defines methods for workingwith hypermedia structures such as anchors and links. Services implementsfunctionality like link traversal, anchor creation etc. Each will be described indetail 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, aHyperEPJObjectrefers to such a structure.

Finally, the application layer is on top. In this project the pilot program en-compasses two applicationsNotepadandImageViewer. Together they form theapplication layer.

43

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 tablepresents a list of templates employed. They will be described in more detail inthe proceeding text.

Template Name DescriptionRegistration 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 animage is kept in the ImageLocator template. Reasonfor doing so is the amount of information required.

Arc An arc is the binding between two endpoints in alink. 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 beneeded to accommodate future features. This is eased by the flexible templatemechanism 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 aredefined with a set of associated attributes, that point to the structural buildingblock SCValue holding a particular primitive (string, int, id etc.). The first partof the storage (7.2) comprises the template instance and the second (7.3) theattribute values. All referencing between attributes and template instances areresolved by Universally Unique Identifiers.

44

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>1112 <!-- Id -->13 <entry>14 <id>3cdd2529-24b2-4f43-93b6-351fd94ecf1c</id>15 <HyperEPJId>96380aa2-fd08-43b0-ae72-cda49c93cdb7</HyperEPJId>16 </entry>1718 <!-- Name -->19 <entry>20 <id>d34e6a5b-a46c-423b-ad5e-1d235f6bff45</id>21 <HyperEPJString><![CDATA[link1]]></HyperEPJString>22 </entry>2324 <!-- 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

Runtime layer - HyperEPJ Framework

7.3 Runtime layer - HyperEPJ Framework

This section builds on the topics covered in the related work chapter specificallythe one concerning structural computing at page 24 and Small SC at page 26.The development of the HyperEPJ framework consist of adapting the Small SCframework 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 andoption 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

*

HyperEPJObject

<<creates>> Template

Repository

TemplateManager

Query

QueryManager

QueryItem

*

*

*

AttributeValues

HyperEPJValue

property

Services

ViewerHyperManager

Figure 7.4: HyperEPJ data model.

Small SC framework: HyperManager, Viewer and Services. Each component isdescribed 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 inBouvin 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

Link model

Anchor

TextAnchorTypeProperty

HyperEPJIdHyperEPJStringHyperEPJStringHyperEPJStringHyperEPJString

resourcetexttreewalkcontext_precontext_post

ClosedAnchorTypeProperty

HyperEPJIdresource

ImageAnchorTypeProperty

HyperEPJIdHyperEPJId

resourcelocator

LocatorTypeProperty

HyperEPJIntHyperEPJIntHyperEPJIntHyperEPJInt

xywidthheight

LinkTypeProperty

HyperEPJListHyperEPJList

arcsobjects

ArcTypeProperty

HyperEPJIdHyperEPJId

endpoint1endpoint2

ResourceTypeProperty

HyperEPJStringHyperEPJString

typepath

Figure 7.5: HyperEPJ link model.

Links in HyperEPJ are composed of a list of arcs. Each arc contains the prop-ertiesendpoint1andendpoint2, which are of the typeAnchor. An anchor is thestructure that hooks up to the given resource from which it is guiding a link to, ina traversal (see Figure 7.6). There may be created numerous anchor types in theframework as it is only a new instance of the HyperEPJObject class associatedwith properties.

HyperEPJ supports 3 anchor types:TextAnchor, ImageAnchor andClosed-Anchor, all of which share the propertyresource. 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 employsinformation about text, surrounding the selection, to locate the correct anchorwhile 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 anchoruses a the resource path only to describe the resource.

The list structure inLink enables for multi-headed links. Furthermore, it is pos-sible to "under specify" an anchor (seen in Microcosm 5.3.2), enabling speciallink 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 thestructural computing capabilities. Linking models like XLink provides genericlinking capabilities in both XML documents and non-XML resources and hasseen use in many systems offering open hypermedia such as Xspect (Christensenet al., 2003) and xlinkit (Nentwich et al., 2002). These systems provide naviga-

47

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 ofhypermedia 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 usein other domains and thus the extensibility and tailorability issue recognized byFrank Halasz (5.2.1).

Compared to traditional object oriented approaches, the HyperEPJ model ismore flexible, due to the template mechanism in Small SC. When adding a newanchor 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 avoidingcompilation. Results from porting the object oriented data model from the con-text aware hypermedia system HyCon to a structural computing based, was amore 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 whereparameters like performance and efficiency are key to success a customized so-lution might be preferable. The health sector relies, in many cases, on missioncritical 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 objectswhen deployed in the SOS systems (Anderson, 2005), but whether it is sufficientwill be determined by future development of the framework.

Anchor

Resource Resource

ArcAnchor

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 linktypes (from the Internet) consist of a pointer that allows the user to go from agiven source anchor to a given destination anchor and not back again. The termsto andfromare not right when compared to the abilities of the framework. Herea link is merely a structure that takes as properties a list of arcs each consistingof 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 otherend). 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

Hypermedia Augmentation

of the link, hence endpoints changesemantic direction(see 5.3.4) depending onthe particular traversal, thus, referring to ato and fromdirectionality, 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 theyare 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 establishedbetween both parts. The interfaceViewer takes care of that. The illustrationbelow depicts the interface:

void createAnchor(HyperEPJObject selection)void setRessource(HyperEPJObject ressource)void attachAnchors()void displayAnchor(HyperEPJId anchorId)HyperEPJObject getRessource()HyperEPJObject getSelection()

Id _clientIdString _clientName

Viewer

Figure 7.7: Viewer interface.

Each client, that implements the interface, includes a clientId and clientNamevariable 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 createanchors, attach anchors and display anchors when traversed. All parameterspassed to the various methods are of the type HyperEPJObject or the structuralbuilding 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 implementsthe interface and provides functionality for the methods in the interface. Thisway 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 classServices. Thisclass comprises the functionality available in the system. Services is a central

49

Hypermedia Augmentation

component in the framework, because it is the entry point for the applicationlayer. When the user performs an action in the system interacting with lowerlayers, Services is involved. Figure 7.8 presents a class diagram of the Servicesclass.

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 _baseURLServices _services

Services

Figure 7.8: Services class diagram.

Due to its vital role in the framework, Services is constructed to be general interms of its methods, that to a large extent interface to template instances (Hyper-EPJObjects) or the basic structural building block (HyperEPJValue) similar tothe Viewer interface. An instance of this is seen in the methodscreateStruc-ture(HyperEPJObject structure) and deleteStructu- re(HyperEPJIdstructure) which are responsible for creating and deleting hypermedia struc-tures in the system. The impact of having these methods interface structuraltemplates is that there may be created many different objects, only limited bySmall 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 thisresponsibility in the Services class, even though it is an extra stop on the way tothe repository. The motivating reason is the fact that the application layer onlyhas one entry point to interface, which makes it easier to develop applicationsfor the framework.

In order to handle traversals of two-way links in the framework, thetraverse-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 withboth endpoints of the link and displays the resource connected to the anchor notmatching 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 thesystems. The interface provides an overview of source and destination anchorsand links. Figure 7.9 depicts the interface.

50

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 solutionand Full, Partial and None interaction respectively. Making applications interacton several levels give potential for a broader spectrum of application than justthe 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:openandclosed. This means that the frameworksupports two degrees of interaction with respect to the resources being displayedin a link traversal, anchor handling etc.

OpenIf an application implements the Viewer interface, it is developed in accordancewith the framework, meaning that it supports creation of anchors and links andfollowing traversal of these from the application.

ClosedIf an application does not implement the Viewer interface, it is closed in termsof the framework. Such applications can only be target in a link traversal(wholecomponent). When a user initiates a link traversal to an anchor displayed bya closed application, the framework simply launches the application with theresource as parameter. Figure 7.10 presents the degrees above (and potentialadditions) in relation to the services provided by the framework.

51

Registrations

Closed:launch only

Partial

Other services(collaboration, versioning etc.)

Open: anchor creation, link following

lowest

highest

degrees ofintegration

Figure 7.10: Conceptual overview of degrees and corresponding services by the frame-work (and potential additions).(inspired by Wiil et al. (2001, Figure 2))

The fact that the framework "only" supports these two interaction degrees isa design choice due to limited resources for this project. However, the rangecould be fine differentiated if a partial interaction degree, like the one from Hy-perDisco, (see 5.3.3) was developed.

7.3.4 Registrations

When a user initiates a link traversal from a source anchor, the frameworkprocesses the traversal to find the destination anchor(s). In order to displaythe resource(s) properly the framework needs information about the application,which is stored as a structural template namedRegistration. A registrationtakes as properties, a string of file extensions, an application to display them andthe type of the registration. The type refers to the previously described degreesof integration. Figure 7.11 illustrates a registration:

Figure 7.11: Registration.

Early versions of the framework required the setup of registrations both for open

52

Summary

and closed applications. From my point of view though, it obstructed an easyusage of the system, because the users were expected to know the location ofclosed applications on their computer which they probably would not, except ifthey were interested in computers. So the registration module was further de-veloped to take advantage of the file extension to application bindings used inoperating systems. The actual implementation is done via a C program calledShelex capable of launching a resource with its binded application.

Using this approach, whatever bindings of applications, that are present inthe operating system, are made available to the user automatically, which broad-ens the spectrum of applications usable as closed viewers. However, Shelexexploits a Windows SDK function in order to work and thus restricts the use toWindows operating systems which is a clear drawback. Future releases should,if possible, employ a platform independent solution.

7.3.5 Summary

The HyperEPJ framework comprises the Small SC framework, augmented withservices providing hypermedia functionality (7.3.2.2) and guidelines for devel-oping applications to interact with the framework (7.3.2.1). To a large extent,the hypermedia services interface to the applications in the form of Small SCtemplates, which makes it simple and flexible to use. An example of this is thelink model, which are constructed solely on templates and thus only one baseobject (HyperEPJObject). This simplifies the framework and facilities inclu-sion in other projects. The link model is flexible because it supports many linktypes. An example of this is generic links, which are links that only comprisea selection and no resource. This is done by under-specifying the anchor, so itcontains only the selection information. However, a drawback of this templatebased solution is the potential loss of performance in a large scale use.

53

Application layer - Pilot Program

7.4 Application layer - Pilot Program

The pilot program builds upon the framework. It makes use of features suchas link creation and traversal provided from the framework. Two applicationshave been developed for the project, which both implements the Viewer inter-face, enabling hypermedia support. The two applications are called Notepad andImageViewer and are each described in the following sections. They are bothprototypes and should be subject to further development if used in large scale.

The purpose of the pilot program is to simulate an EPJ but in smaller scale.The simulation is based on the hypothesis thatthe idea of using hypermedia in amedical context works. Thus, aspects like whether the user interface is designedso it supports the operation in 1-2 seconds (6.4.1) is less important in relationhereto. The goal of the pilot program is therefore not to make it look like an EPJ,but to facilitate a work process used by the staff in the hospitals. This involves,among others, writing notes on patients.

The hypothesis just mentioned will be tested in the Evaluation (7.5) chapterat page 61.

7.4.1 Notepad

Notepad is the first application in the pilot program. It is a normal text editoraugmented with hypermedia features from implementing the Viewer interface.In Notepad the user can create anchor in the text and connect them to other an-chors creating links. Figure 7.12 illustrates Notepad. A text file is loaded into theeditor and a couple of link markers are displayed. Normal link markers are blue.The red link marker illustrates that this instance of Notepad is the endpoint in alink traversal. Anchors are created by marking a selection of characters in theeditor, right clicking and choosingCreate Anchorfrom the popupmenu. After-wards, anchors may be connected using the HyperManager (7.3.2.3). Traversalof link markers are carried out similar to anchor creation.

7.4.1.1 High Demands

Being a text editor, users add, remove or edit existing text. The text may behighly dynamic, which complicates integration of hypermedia support in it. Toenable hypermedia use, proper ways to create and delete anchors and connectanchors must be incorporated in the application. Related to operation in a dy-namic environment like text editors are challenges like consistency of hyperme-dia structures when text changes. To place a link marker (Halasz and Schwartz,1994) correctly within text requires information about the text selection and lo-cation information comprising either an offset number or segments of text sur-rounding the selection. This is described in the following.

54

Notepad

Figure 7.12: Screen shot from Notepad.

7.4.1.2 Anchoring Mechanism

When a resource contains anchors, the application using the framework instructsthe framework to perform an anchor search for that particular resource in orderto make them visible for the user. This is carried out by an anchoring mechanismor by other terms an anchoring algorithm. The process of doing that involvessearching the repository for anchors that match a predefined set of criteria. Thepurpose of the criteria is to make sure that the algorithm is able to determinewith an acceptable threshold that the anchors that matches the criteria really be-long to the particular media. The following will describe in more detail how thealgorithm is designed.

The algorithm employs three different criteria to help it determine the degreeto which a text anchor belongs to a given resource (Phelps and Wilensky, 2000).They are:

1. Unique ID

2. Tree walk

3. Context information

Unique ID

First the algorithm tries to find a unique id within the document that identifiesthe anchors. This approach is not always feasible because the anchors needto be embedded in the media and thus making the concept of external linksimpossible.

55

Notepad

Tree walk

If the unique id criteria fails the next criteria is a tree walk. A tree walk, asthe name implies, is a walk through a tree finding a specific object of interest.The object of interest is the location specifying where a given anchor should beplaced. An example tree walk is depicted in Figure 7.13:

test.html

html

head title

p

body

h3

The initial obstetric medical journals can be viewed here 0 1 2 3 4 5 6 7 8

Tests carried out as follows

Figure 7.13: Tree walk example.

The treewalk uses XPointer expressions to specify the location of anchors. Inplain text the tree walk expression can be described as:

3/medical/0 1/H3 0/BODY 0/HTML /test.html

Read right to left the text can be interpreted as starting from the root in the me-dia called test.html. Then we take the 1st child meaning the <HTML> element,then taking the 1st child of <HTML> element being the <BODY> element, thentaking the 2nd child element of the <BODY> element meaning the <H3> ele-ment. Finally we decode the 3/medical/0 as being the 4th word in a text stringmeaning the wordmedicaland furthermore the 0 guides the algorithm to thepoint just before the m in medical.

This approach only works when dealing with resource where the content areordered hierarchal, such as HTML or XML files. When it comes to plain textfiles the tree walk will not be of much use except the filename information in thebeginning. Therefore a third criterion is used.

Context information

Context information is a portion of text surrounding the anchor text. Contextinformation comprises text placed on each side of the anchor text. If the treewalk is successful, the context information serves as an additional criteria tofurther secure that it is the correct anchor being attached to the resource. If onlythe filename information of the tree walk is used the context information is the

56

Notepad

primary criteria. An example context information is in continuance of the treewalk:

The initial obstetricmedicaljournals can be viewed here

The context information criteria posses some vulnerabilities in that there maybe more than one occurrence in a given text media that satisfies the contextinformation having the consequence that one anchor may be attached multipleplaces. To handle this frailty the context information criteria can be augmentedwith a mechanism that checks the order of each occurrence in a text resourceand the anchor to verify that they match. If an anchor is supposed to be attachedwithin the 3rd occurrence of the context information the algorithm can count theamount and attach the anchor when they match.

7.4.1.3 Generic Links

Use scenario 1 describes a doctor who is writing a note and wants to support acomplex term with an external explanation. This can be accomplished using alink that the doctor creates manually. However, as pointed out by people relatedto health care (see 6.4), new functionality even if it has potential, must be verysimple to use in order for it to be accepted. One way to achieve this is to enablethe functionality automatically so users do not have to spend more time thannecessary. Providing generic links in a medical context is a good idea, becausethey do not apply to one particular resource one but all resources, thus there canbe many links available for the users, even though they have not created any.

The task of supporting a note containing complex diagnoses with externalexplanations is therefore very easy fulfilled with generic linksassumingthatlinks for the specific terms have be created in the system.

Generic links apply different to certain resources. As described above it makesgood sense to use it within a medical context and in text based resources. Withthe absence of resource information in the anchor, only the text selection is stillpresent. When the application attaches anchors in a particular resource and getsa generic link, it finds all occurrences where the text selection matches and in-serts an anchor. However, when it comes to other resources than text based, itapplies different. In images, for instance, a selection like (1,2) and width: 100pxand height: 200px will certainly match some images. However, it does not holda strong association to the actual content being displayed by the image. Samegoes for audio or video, since the only thing to match the generic anchor againstis technical definitions like x,y coordinates or minutes. Thus the claim is thatgeneric links is most usable withing text based resources.

How generic links are implemented in Notepad is illustrated in Figure 7.14,which presents a piece of code used to create a new text anchor. In a normalanchor all properties are given values. However a generic anchor only utilizesthe text property as highlighted in the code. When the application attaches theanchor, it is recognized as generic due to the absence of the other properties.Hence, an anchor is inserted with every occurrence, which is illustrated by Fig-ure 7.15.

57

ImageViewer

1 HyperEPJObject anchor = new HyperEPJObject().newInstance(newId(),"generic_anchor",Template.instance("textanchor"));

23 anchor.setProperty("text", new HyperEPJString (" S- Relaxin ") ) ;4 anchor.setProperty("medium", new HyperEPJString(""));5 anchor.setProperty("treewalk", new HyperEPJString(""));6 anchor.setProperty("context_pre", new HyperEPJString(""));7 anchor.setProperty("context_post", new HyperEPJString(""));89 _viewer.createAnchor(anchor);

Figure 7.14: Under-specifying a text anchor to accomplish generic behavior.

Figure 7.15: Use of generic links in Notepad. The displayed generic anchor is linkedto a Google search for "S-Relaxin".

A solution that would further automate the use of hypermedia functionality isto render every possible selection in a text based resource a subject in a searchquery employing a search engine such as Google or likewise. Such a featurejoined with the generic link will improve the computation and search and querycapabilities with respect to the issues described by Halasz (see 5.2.1). This ex-tension, however, is not implemented.

7.4.2 ImageViewer

ImageViewer is the second application in the project supporting hypermediause. Compared to Notepad many of the tasks involved in providing hypermediafunctionality are the same, however the implementation differ because they usediverse resources. To create an anchor or describing a selection in a text resource

58

ImageViewer

is fundamentally different from an image resource. The picture below illustratesImageViewer:

Figure 7.16: Screen shot from ImageViewer.

7.4.2.1 Anchoring mechanism

The job of creating and attaching anchors in an image is unlike the one with re-ference to Notepad. To locate something within an image you need a referenceto point to a specific area in the image. Compared to Notepad, where a layeredalgorithm attempts to locate potential anchors with help from context informa-tion, it is a simple task in an image. It merely requires a coordinate set (x,y) andan associated figure to surround the area. Indeed if an image anchor from thelink model (see Figure 7.5) describes x,y as 120,240 and width,height as 100,50it is quite straightforward for the attaching mechanism to locate and insert theanchor. Figure 7.16 illustrates ImageViewer displaying an image with two an-chors. In both cases the anchor is attached by locating the x,y in the image anddrawing a rectangle to surround it. The point constitutes the top left corner ofthe rectangle.

If several anchors intersect each other and a user clicks inside the intersection,ImageViewer extracts the coordinates, requests the framework to find links thatbelong to the anchor(s) and passes them to thetraverseLink() method of theServices class (7.3.2.2) which traverses them.

59

Summary

From a medical point of view the shape that surrounds the area of interest maybe used to highlight diseased tissue etc. Indeed it may constitute a visual proofor likewise likewise as suggested in 6.4.2.

7.4.3 Summary

Two viewers, Notepad and ImageViewer, have been developed in conjunctionwith the framework. They are integrated by a pilot program and may be launchedfrom here. Together they constitute a simulation of an EPJ that supports hyper-media functionality.

Notepad is a text editor, where users can put their notes. Furthermore they cancreate anchor, both local and global (generic) and interconnect them to links.

ImageViewer works the same way, except on images. However, the conceptof local links is not applicable when speaking of images. A selection in an im-age without a resource may not have a semantic binding to what the image isactually displaying. Thus local links are not supported in ImageViewer.

The purpose of the pilot program is to test the hypothesis that hypermedia usein an EPJ works. This is clarified in the next section.

In order to test the framework and pilot program please refer to Appendix C- Installation guide lines at page 82.

60

Evaluation

7.5 Evaluation

To get an impression of how the system works in a practical context, simpletests and demonstrations have been conducted with some of the people alreadyinvolved in the project. Along with the tests, I constructed a hypothesis, whichI wanted to test during the session.

The hypothesis comprised the following assumptions:

1. The idea of using hypermedia in a medical context works

a) It may save time in the work flow

b) It will be used

The test sessions included few prerequisites. I brought a laptop on which thesystem was installed. The people involved were radiologist Inge Spangsberg andPoul Thorsen, MD, PhD. The setup constituted a small test which was realisticfor me to do.

Inge had been in the design process from the beginning whereas Poul hadnever seen the system before. Having a person with historic knowledge of thedesign process, I hoped to get a practical view of whether the system met the re-quirements and characteristics we had discussed through the process. Moreover,having a person without prior knowledge, I aimed at simulating a first-time useroperating the system and following getting concrete and direct feedback.

In addition to the tests, I presented the system at CSC Scandihealth to Jan Markin order to hear his view of the potential uses of the framework in CSC ClinicalSuite (6.2). Details from the presentation may be seen in 8.3.

7.5.1 Test Sessions

Inge SpangsbergAccording to Inge, the red link marker, indicating a traversal, is good because itfocuses the doctors eye to the area. But it also displaces attention from the restof the picture. One of the critical things in the life of a radiologist is toremainobjective to the image. All extra added graphics makes it harder to be objective.

Therefore, she mentioned an on/off feature used to toggle between displayof hypermedia structures and the "clean" resource.

The fact that link traversal, in Notepad, is accomplished by selecting a pieceof text instead of just clicking on the link, was not an issue to Inge. However,when discussing whether it would be used in the daily work, she mentioned thatit might not, because of the extra time effort.

Inge confirmed that the idea of using hypermedia in a medical context works(part 1) and that it may save time in the work flow (1a), but was unsure whetherit will be used (1b).

61

Results

Poul ThorsenDuring the session, Poul mentioned security as important, so that sensitive in-formations are kept uncompromised.

The hypothesis was not fully confirmed. He clearly remarked, that hyper-media functionality will only be used, if it is simple and quick to operate. Somuch work must be put into designing a suitable user interface if part 1a and 1bof the hypothesis is fulfilled.

When discussing the possibilities and usage, Poul mentioned that there is a vari-ation in how much assistance each doctor needs. Hence, it should be possibleto differentiate it somehow. Furthermore, link traversal in Notepad should beimproved so it is possible just to click on the link instead of selecting the text,right clicking and choosingFollow Link.

7.5.2 Results

The results from this small test setup was that the hypothesis was partially con-firmed. Inge and Poul both agreed that the idea of using hypermedia in a medicalcontext works, and that it may prove to be a valuable tool enabling staff to geta quick overview, when browsing the EPJ. Both mentioned several potential usescenarios, similar to the ones developed in 6.4.1, where the functionality wouldbe of great use. However, they questioned part 1a, whether it will be used. Ingepointed out, that the tools currently in use at Randers Centralsygehus in factworks fine. So ensuring this part of the hypothesis, requires that staff experi-ences two things:

1. Using the functionality actually saves time

2. The user interface provides for a quick operation

Achieving no. 1 is dependent on no. 2, hence the efforts should be put in devel-oping such an interface.

Consequences in the DesignBased on the evaluation, some aspects of the system should be changed:

1. On/off featureOpen applications should include an on/off mechanism in order to ensurethat staff remain objective to the material as Inge pointed out. There areseveral ways, this could be implemented. One is to let the CTRL-key (orlikewise) act as the trigger, so when it is pressed, anchors and link markersare displayed in the resource and when not, only the clean resource isdisplayed.

2. Improved Notepad link traversalThe procedure of following links in Notepad should be improved so thatthe user initiates a link traversal just by clicking the link marker and notselecting it first. This will speed up the operation and reduce errors whenthe selection does not match exactly the link marker.

62

Results

3. Multiple link basesFrom a medical point of view it would be a nice feature if more than onelink bases could be used with the system. As mentioned by Poul, newdoctors may want additional help in the form of more diagnosis expla-nations, compared to experienced doctors. Therefore, the pilot programshould be extended to accept multiple link bases.

4. Better user interfaceFinally, to achieve a user interface, that provides for a quick operation,other and more extensive methods in the design and evaluation processshould be used. Within this project, simple and low cost methods likecognitive walkthroughs (Lewis and Wharton, 1997) and small user tests(Tognazzini, 1992) are possible.

Future integration in CSC Clinical SuiteAfter demonstrating the system at CSC Scandihealth, Jan Mark stated that thefuture integration of the framework in Clinical Suite seems possible within fewyears. The framework should be subject to further development, not least be-cause the technical association between the framework and Clinical Suite arevery limited due to the absence of implementation specifics about the EPJ.Future development of the framework implies:

1. Efforts to suit the framework and EPJ technicallyIn order to integrate the two, they should match with respect to data for-mats and exchange.

2. Stepwise introduction of hypermediaA stepwise introduction of making the EPJ hypermedia capable shouldbe initiated. This involves extending one or two applications, displayingresources in the EPJ, so they implement the Viewer interface (7.3.2.1).

Based on experiences from this work will determine further integration.

63

Chapter 8

Conclusion

The developed framework builds on the structural computing framework SmallSC (Anderson, 2005), which is capable of generating dynamic data modelsbased on structural templates. An advantage, compared to traditional solutionslike object oriented models, is, that structural templates are instances ofonehard-coded class, which simplifies the framework. Moreover, they are definedand created with a set of properties at run-time. Due to this, the framework isable to model complex data structures with few classes. Compared to objectoriented approach, use of structural templates is a more flexible solution since itremoves the need to interact at the lowest level of the system, which means thedefinition of a hard-coded class and subsequent compilation. Furthermore, byabstracting domain objects to one structural "unit" there is a clear interface be-tween the runtime layer and the storage layer. This is utilized in the hypermediaextension, which augments the Small SC framework (see 7.3.2.2).

The linking feature of the framework employs externally stores links. A ma-jor reason is that the EPJ operates in a heterogeneous environment interfacingnumerous systems. Moreover, many of the resources used in the health sector(video, audio, 3D models etc.) are either not suited for embedded links or com-prise an unknown structure. Thus, the resources to be linked are out of controlof the framework, which calls for an external solution.

Two client applications, Notepad and ImageViewer, are developed in conjunc-tion with the framework. Together, they are integrated in a pilot program capableof demonstrating the possibilities of the framework. Both enable the user to cre-ate anchors, connect them to other anchors and traverse the link, in text andimage resources. In order to broaden the spectrum of applications available tothe framework, it operates at two levels of integration: open and closed. Notepadand ImageViewer are open viewers. Closed applications are only able to launcha resource. They may be all applications installed on a given computer and areautomatically made available to the framework. This opens up many possibili-ties for potential linking of resources.

The framework and pilot program have been evaluated, both by the people in-volved in the design process and people without prior knowledge, functioningas first-time users. The evaluation provided benefits as well as drawbacks of

64

Integration of Hypermedia in a Medical Context

the implementation. More importantly, the hypothesis, about the plausibility ofusing hypermedia in a medical context, was confirmed.

In relation to the initial goals (4.4) of the project, I believe that the work con-ducted has been sufficient in order to satisfy the primary and secondary goals.The third goal about implementing the technology within the EPJ from CSCScandihealth was not practically carried out, but merely laid out as theoreticguidelines.

However, the framework might be a part of the CSC EPJ in a few years.Based on the developed prototype and its capabilities, Jan Mark from CSC Scan-dihealth assessed that the system holds potential for being implemented in theirEPJ within few years (see 8.33rd meetingfor further details). Though, theframework should be subject to further development in order to be integrated.Preliminary arrangements to carry this out practically has been initiated betweenthe author and CSC Scandihealth.

8.1 Integration of Hypermedia in a Medical Context

Hypermedia is not a new concept in the medical world. Projects like Hospi-texte (Charlet et al., 1998) and TeamRoom for the National Health Service inthe United Kingdom (Connor and Finnemore, 2003) are examples of efforts tointroduce hypermedia technology to the health sector. Thus, the framework toprovide hypermedia capabilities to the EPJ, is designed and developed on basisof experiences from the hypermedia research field, related projects just men-tioned, and research conducted within the medical domain not least.

Results derived from this work, include the fact thatstaff working at hospi-tals are actually satisfied with the tools currently available to thembecause theyare familiar with them. The task of integrating something new into the EPJ, isthus not only dependent on the quality of the technology, but on whether staffare willing to change their work habits and use it even if it takes longer in the be-ginning. According to people, closely related to daily work in the health sector,successful integration of hypermedia functionality, like linking features, impliesthat:

• the technology is simple and quick to operate

• the benefit of using the technology is clear and significant

Features like linking and annotations are valuable tools in the daily work withthe EPJ. However, the user interface is an area that requires effort in order tofulfill the conditions mentioned above about successful integration. Achievingthis will require more users participating in the design process and extensivetests. A setup that is not realistic within the boundaries of this project.

65

Reflections on Structural Computing

8.2 Reflections on Structural Computing

Experiences with structural computing in this project has proved its entitle-ments, however in a smaller scale compared to the visions in (Nürnberg et al.,1997). As far as dealing with general concepts is concerned, structural com-puting is suitable. The range of potential uses in reference to underlying datamodels seems infinite, which makes the paradigm powerful. Furthermore, whenutilizing structural computing framework capable of handling templates, suchas Small SC or Themis, the classes, necessary to generate the data model, arekept at a minimum, which results in a simple solution.

The fact, that object oriented data models have been replaced by structuralcomputing frameworks, with a simpler and more flexible data model as result(Anderson et al., 2006), proves its capabilities.

If used in large scale, a feasible solution to transfer the hypermedia structures,like locators, anchors, links etc. must be developed. A potential usage of struc-tural computing is in relation to the basic standard for electronic patient journalsin Denmark known as G-EPJ1. Since G-EPJ is built on the condition, that dataare structured, in order to facilitate reuse etc., it supports the idea behind struc-tural computing well. A solution where G-EPJ defines a communication pro-tocol of structured data provided by HyperEPJ is a preliminary but reasonablesuggestion.

The data model built by Small SC is indeed flexible, however when transfer-ring template objects between SC and OOP, some work is required in order toextract the information. When used in large scale the generic nature of structuraltemplates may pose a loss of performance in domains where efficiency and per-formance is key. This might be an issue in the health sector that in many casesrelies on mission critical software. However, as pointed out in 5.4.2 the use ofstructural templates in conjunction with the Small SC framework has provedreliable in a large scale when it was deployed in the SOS system (Anderson,2005).

The final remark is that a solution based on structural templates should un-dergo further development/optimization if embedded to the EPJ in order to en-sure that is up for the challenge in the health sector.

8.3 Future Work

As mentioned in the previous section, the third goal is not achieved practically.To accomplish this, the framework should be improved in relation to its fea-tures. The prototype developed in this project features linking. However, otherhypermedia features like a graphical overview, automatic computation of thestructures etc. should be included within it. Furthermore, results from the eval-uation (7.5.2) should be incorporated.

Extending the framework can be done in various ways. Besides the specific ad-

1Grundstruktur for Elektroniske PatientJournaler

66

Future Work

ditions mentioned above, another more sophisticated change would be to adaptthe framework to handle the context aware domain as well as the navigational.The following claim justifies such a solution:

Medicine is not a science it its daily practice. It is a practice in which contextplays a major role(Charlet et al., 1998)

In such a scenario the hypermedia system receives input not only from users butalso from sensors registering various data about the context. This may concerna particular patient or which doctor is presently using the EPJ etc.

Implementing such an extension requires much change to the framework aswell as the EPJ obviously. However, the use of structural computing may aidthe process.

67

Bibliography

Akscyn, R. M., D. L. Mccracken, and E. A. Yoder (1988, July). KMS: A dis-tributed hypermedia system for managing knowledge in organizations.Com-munications of the ACM 31(7), 820–835.

Anderson, K. M. (2005, November). Towards lightweight structural computingtechniques with SmallSC. InProceedings of the Metainformatics Symposium,Esbjerg, Denmark.

Anderson, K. M., F. A. Hansen, and N. O. Bouvin (2006). Templates and queriesin contextual hypermedia. InHYPERTEXT ’06: Proceedings of the seven-teenth conference on Hypertext and hypermedia, New York, NY, USA, pp.99–110. ACM Press.

Anderson, K. M., S. A. Sherba, and W. V. Lepthien (2002). Towards large-scaleinformation integration. InProceedings of the24th International Conferenceon Software Engineering, pp. 524–534. ACM Press.

Anderson, K. M., S. A. Sherba, and W. V. Lepthien (2003a, January). Structuraltemplates and transformations: The Themis structural computing environ-ment.Journal of Network and Computer Applications 26(1), 47–71.

Anderson, K. M., S. A. Sherba, and W. V. Lepthien (2003b, August). Struc-ture and behavior awareness in Themis. In L. Carr and L. Hardman (Eds.),Proceedings of the14th ACM Hypertext Conference, Nottingham, UK, pp.138–147. ACM Press.

Anderson, K. M. and R. N. Taylor (1994, September). A proposal for versioningsupport for the chimera system. InProceedings of the Workshop on Versioningin Hypertext Systems. Held in connection with ECHT ’94, Edinburgh, UK, pp.45–54. ACM.

Anderson, K. M. and R. N. a. Taylor (2000, July). Chimera: Hypermedia forheterogeneous software development environments.ACM Transactions onInformation Systems 18(3), 211–245.

Bieber, M., F. Vitali, H. Ashman, V. Balasubramanian, and O. Kukkonen (1997).Fourth generation hypermedia: some missing links for the World Wide Web.International Journal for Human-Computer Studies 47, 31–65.

Bouvin, N. O., B. G. Christensen, K. Grønbæk, and F. A. Hansen (2003). Hy-Con: A framework for context-aware mobile hypermedia.The New Reviewof Hypermedia and Multimedia 9, 59–88.

68

Bibliography

Bringay, S., C. Barry, and J. Charlet (2004). Annotations: A new type of docu-ment in the electronic health record.

Bush, V. (1945, July). As we may think.The Atlantic Monthly 176(1), 101–108.

Charlet, J., B. Bachimont, V. Brunie, S. E. Kassar, P. Zweigenbaum, and J.-F. Boisvieux (1998). Hospitexte: towards a document-based hypertextualelectronic medical record. InProceedings / AMIA ... Annual Symposium.AMIA Symposium, Volume 713-7. Hanley Belfus.

Christensen, B. G., F. A. Hansen, and N. O. Bouvin (2003, May). Xspect:bridging open hypermedia and XLink. InProceedings of the12th Interna-tional World Wide Web Conference, Budapest, Hungary, pp. 490–499. W3C:ACM Press.

Clark, J. and S. DeRose (1999, November). XML Path language (XPath) version1.0. W3C Recommendation 16 November 1999, W3C.

Connor, M. and P. Finnemore (2003, Apr). Living in the new age: using collab-orative digital technology to deliver health care improvement.InternationalJournal of Health Care Quality Assurance 16(2), 77–86.

CSC Scandihealth (2005). CSC clinical suite. Technical report.

Davis, H. C., S. Knight, and W. Hall (1994, September). Light hypermedialink services: A study of third party integration. InProceedings of the 1994ACM European Conference on Hypermedia Technology, Edinburgh, UK, pp.41–50. ACM.

DeRose, S., R. Daniel, Jr., P. Grosso, E. Maler, J. Marsh, and N. Walsh (2001,September). XML Pointer Language (XPointer). W3c candidate recommen-dation, W3C.

Derose, S., E. Maler, and D. Orchard (2001, June). XML Linking Language(XLink). W3C Recommendation 27 June 2001, W3C.

Engelbart, D. (1984). Authorship provisions in Augment. InProceedings of theIEEE Compcon Conference, San Francisco, USA. IEEE.

Grønbæk, K., N. O. Bouvin, and L. Sloth (1997, April). Designing Dexterbased hypermedia services for the World Wide Web. In M. Bernstein, L. Carr,and K. østerbye (Eds.),Proceedings of the8th ACM Hypertext Conference,Southampton, UK, pp. 146–156. ACM Press.

Grønbæk, K. and R. H. Trigg (1994, February). Design issues for a Dexter basedhypermedia system.Communications of the ACM 37(2), 40–49.

Grønbæk, K. and R. H. Trigg (1999).From Web to Workspace. Cambridge,Massachusetts. London, England: The MIT Press.

Halasz, F. G. (1988). Reflections on NoteCards: Seven issues for the next gener-ation of hypermedia systems.Communications of the ACM 31(7), 836–852.

69

Bibliography

Halasz, F. G., T. P. Moran, and R. H. Trigg (1987, April). NoteCards in anutshell. InProceedings of ACM Conference on Human Factors in ComputingSystems and Graphics Interface, Toronto, Canada, pp. 45–52.

Halasz, F. G. and M. Schwartz (1994, February). The Dexter hypertext referencemodel.Communications of the ACM 37(2), 30–39.

Hall, W., H. C. Davis, and G. Hutchings (1996).Rethinking Hypermedia: TheMicrocosm Approach. Norwell, USA: Kluwer Academic Publishers.

Hicks, D. L. and U. K. Wiil (2003, June). Searching for revolution in structuralcomputing.Jounal Of Network and Computer Applications 26, 27–45.

Kaplan, S. (1997). The cscw column: the quadrant model of groupware.SIG-GROUP Bull. 18(2), 11–14.

Kensing, F. and J. Blomberg (1998, sep). Participatory design: Issues and con-cerns.Computer Supported Cooperative Work (CSCW)(3), 167–185.

Lewis, C. and C. Wharton (1997). Cognitive walkthroughs.Handbook ofHuman-Computer Interaction, Completely revised edition, 717–732.

Meyrowitz, N. K. (1989). The missing link: Why we’re all doing hypertextwrong. In E. Barrett (Ed.),The Society of Text: Hypertext, Hypermedia andthe Social Construction of Information, pp. 107–114. Cambridge, USA: MITPress.

Nentwich, C., L. Capra, W. Emmerich, and A. Finkelstein (2002). xlinkit: aconsistency checking and smart link generation service.ACM Transactionson Internet Technology 2(2), 151–185.

Niinimaki, T., H. Poutanen, B.-M. Myllyla, and R. Tervo-Pellikka (1989). Com-puters in the ward: orthopaedic care with a paperless medical record and nurs-ing plan.MEDINFO 89, 818–821.

Nürnberg, P., J. Leggett, and E. Schneider (1997, April). As we should havethought. InProceedings of the ACM Hypertext Conference, Southampton,UK, pp. 96–101.

Nygren, E. and P. Henriksson (1992, Sep-Oct). Reading the medical record. i.analysis of physicians’ ways of reading the medical record.Computer Meth-ods and Programs in Biomedicine 39(1-2), 1–12.

Nygren, E., M. Johnson, and P. Henriksson (1992, Sep-Oct). Reading the med-ical record. ii. design of a human-computer interface for basic reading ofcomputerized medical records.Computer Methods and Programs in Bio-medicine 39(1-2), 13–25.

Phelps, T. A. and R. Wilensky (2000, May). Robust intra-document locations.In Proceedings of the9th International World Wide Web Conference, Amster-dam, Holland, pp. 105–118. W3C.

Roseman, M. and S. Greenberg (1996a). Teamrooms: groupware for sharedelectronic spaces. InCHI ’96: Conference companion on Human factors incomputing systems, New York, NY, USA, pp. 275–276. ACM Press.

70

Bibliography

Roseman, M. and S. Greenberg (1996b). Teamrooms: network places for col-laboration. InCSCW ’96: Proceedings of the 1996 ACM conference on Com-puter supported cooperative work, New York, NY, USA, pp. 325–333. ACMPress.

Schuler, D. and A. Namioka (1993).Participatory Design. Principles and Prac-tices.Lawrence Erlbaum Associates., Hillsdale, New Jersey.

Steenberg, P. (2003). Fremtidens elektroniske patientjournal. Technical report,CSC Scandihealth.

Sundhedsministeriet (1996, oct). Handlingsplan for elektroniske patientjourna-ler.

Tange, H. (1995, sep-oct). The paper-based patient record: It is really so bad?Computer Methods and Programs in Biomedicine 48(1-2), 127–131.

Tognazzini, B. (1992).Tog on Interface. Addison-Wesley Professional.

Vingtoft, S., M. Bruun-Rasmussen, K. Bernstein, S. K. Andersen, and C. Nøhr(2005, October). EPJ observatoriet: Statusrapport 2005.

Wiil, U. K., D. L. Hicks, and P. J. Nürnberg (2001, August). Multiple openservices: A new approach to service provision in open hypermedia systems.In H. Davis, Y. Douglas, and D. G. Durand (Eds.),Proceedings of the12th

ACM Hypertext Conference, Århus, Denmark, pp. 83–92.

Wiil, U. K. and J. J. Leggett (1997, April). Workspaces: The HyperDisco ap-proach to Internet distribution. In M. Bernstein, L. Carr, and K. østerbye(Eds.),Proceedings of the8th ACM Hypertext Conference, Southampton, UK,pp. 13–23. ACM Press.

Yankelovich, N., B. J. Haan, N. K. Meyrowitz, and S. M. Drucker (1988, Janu-ary). Intermedia: the concept and the construction of a seamless informationenvironment.Computer, 81–96.

71

List of Figures

4.1 Descriptive text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.2 Image link in xray. . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.1 Dexter model architecture (Halasz and Schwartz, 1994). . . . . . . 155.2 Chimera Image-to-Image Example. . . . . . . . . . . . . . . . . . . 175.3 Fully Aware integration in AutoCad.(Davis et al., 1994) . . . . . . . 195.4 Universal Viewer integration in Microsoft Calendar.(Davis et al.,

1994) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.5 Themis architecture. . . . . . . . . . . . . . . . . . . . . . . . . . 265.6 Small SC data model. Modified version from (Anderson et al., 2006) 275.7 Code example of how to create templates. . . . . . . . . . . . . . . 285.8 Code example of how to instantiate a locator and imageanchor tem-

plate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.9 Code example of a query that finds anchors with name "textanchor03". 29

6.1 Companies providing EPJ technology to counties.(Vingtoft et al.,2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.2 CSC Clinical Suite. . . . . . . . . . . . . . . . . . . . . . . . . . . 356.3 Conceptual illustration explaining how to implement hypermedia

functionality into Clinical Suite. . . . . . . . . . . . . . . . . . . . 40

7.1 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427.2 XML storage example of a link template instance. . . . . . . . . . . 457.3 XML storage example of attributes belonging to a link. . . . . . . . 457.4 HyperEPJ data model. . . . . . . . . . . . . . . . . . . . . . . . . 467.5 HyperEPJ link model. . . . . . . . . . . . . . . . . . . . . . . . . . 477.6 HyperEPJ link structure. . . . . . . . . . . . . . . . . . . . . . . . 487.7 Viewer interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 497.8 Services class diagram. . . . . . . . . . . . . . . . . . . . . . . . . 507.9 Administration of hypermedia structures via the HyperManager user

interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.10 Conceptual overview of degrees and corresponding services by the

framework (and potential additions).(inspired by Wiil et al. (2001,Figure 2)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.11 Registration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.12 Screen shot from Notepad. . . . . . . . . . . . . . . . . . . . . . . 557.13 Tree walk example. . . . . . . . . . . . . . . . . . . . . . . . . . . 567.14 Under-specifying a text anchor to accomplish generic behavior. . . . 58

72

List of Figures

7.15 Use of generic links in Notepad. The displayed generic anchor islinked to a Google search for "S-Relaxin". . . . . . . . . . . . . . . 58

7.16 Screen shot from ImageViewer. . . . . . . . . . . . . . . . . . . . . 59

1 Associating a link base to the system. . . . . . . . . . . . . . . . . 752 Anchor creation in Notepad. . . . . . . . . . . . . . . . . . . . . . 763 Connecting the newly created anchor to an URL reference. . . . . . 774 Traverse the link. . . . . . . . . . . . . . . . . . . . . . . . . . . . 785 Link traversal between Notepad and ImageViewer. . . . . . . . . . 796 Traversal from Notepad to GhostView. . . . . . . . . . . . . . . . . 807 Hypermedia architecture development (Nürnberg et al., 1997). . . . 81

73

List of Tables

5.1 Comparison of link storage approaches (from Grønbæk and Trigg(1999, page 50)). . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.1 EPJ development (based on (Steenberg, 2003)). . . . . . . . . . . . 336.2 Examples of clinical data. . . . . . . . . . . . . . . . . . . . . . . . 39

7.1 Structural templates used by the system. . . . . . . . . . . . . . . . 44

1 Folders on the attached cd-rom. . . . . . . . . . . . . . . . . . . . . 87

74

Appendices

Appendix A - Usage examples

This appendix provides examples of using the system. The pilot program shouldbe started.

Associating a link base to the systemTo be able to work with hypermedia structures, the system must be associatedto a link base. The link base is the storage mechanism holding all structures.To set the link base chooseTools–> Set Link Base–> Change–> Select the filerepository.xml.

Figure 1: Associating a link base to the system.

When the link base is set. ChooseStart–> Notepad

75

Appendix A - Usage examples

Create an anchorFigure 2 then illustrates the next step: creation of an anchor, which is done inNotepad. ChooseFiles andOpenand select a file (test resources are located inthetest resourcesfolder). Make a selection in the text and right click the mouseand chooseCreate Anchor. The text is then underlined gray, illustrating that itis an anchor but not part of a link.

When creating anchors in ImageViewer, simply press and hold the left mousebutton and move the mouse. This will create a rectangle forming the selection.

Figure 2: Anchor creation in Notepad.

76

Appendix A - Usage examples

Connect the anchor with another anchorThe newly created anchor is then connected to another anchor. This anchor is asimple URL reference to a web site. Create the closed anchor from the Hyper-Manager by choosingEdit –>Start HyperManager. Type an URL (www.nanea.dk,www.daimi.au.dk etc.) or a path to file on the computer in the resource text fieldand click theCreatebutton. Hold down CTRL-key and select one Source/Globalanchor and one Destination anchor with the mouse. Press the buttonCreate Link.

Figure 3 illustrates how the anchor in Notepad and the URL reference anchor iscombined into a link by selecting them both.

Figure 3: Connecting the newly created anchor to an URL reference.

77

Appendix A - Usage examples

Traverse the linkTo test the link, select it, right click the mouse and selectFollow Link (the selec-tion must match exactly). The framework then processes the request and opensthe appropriate viewer displaying the endpoint(s) of the link. Here it is Firefoxdisplaying the URL reference.

Figure 4: Traverse the link.

78

Appendix A - Usage examples

Notepad to ImageViewerFigure 5 depicts a traversal between the two open viewers Notepad and Im-ageViewer. When traversing a link, the destination endpoint(s) are highlightedred.

Figure 5: Link traversal between Notepad and ImageViewer.

79

Appendix A - Usage examples

Traversals to closed viewerFigure 6 illustrates a link traversal from Notepad to a closed viewer, in this caseGhostView.

Figure 6: Traversal from Notepad to GhostView.

80

Appendix B - Hypermedia architecture development

Appendix B - Hypermedia architecture development

Figure 7: Hypermedia architecture development (Nürnberg et al., 1997).

81

Appendix C - Installation guide lines

Appendix C - Installation guide lines

The following text describes how to install and run the framework and pilot pro-gram.

1. Install Java Runtime Environment version 6. It is located in thesupportfolder on the attached cdrom (see page 87).

2. Copy thedist folder to a location on the hard disk.

3. Double click thestart.batfile.

Refer to Appendix A - Usage examples (see page 75) for an introduction on howto operate the prototype.

82

Appendix D - Meetings with Inge Spangsberg

Appendix D - Meetings with Inge Spangsberg

30th of April 2006

The 30. of April 2006 I had a talk with my aunt Inge Spangsberg in relationto the project. She works as a radiologist at Randers Centralsygehus and istherefore a future user of the EPJ systems being developed in Denmark.

The talk was especially exciting because she holds the position of being thedoctor that the scenario talks about in page 7. In that context I thought it could beinteresting to hear her points of view about hypermedia and particularly linking.She told me that they already have the functionality of creating links in xrays,however not in the EPJ, but rather embedded into the program that processes thexray pictures afterwards. But she mentioned the functionality to be importantbecause it saves a lot time in the daily work.

The fact that the program radiologist use to create links and annotations areonly available in their domain compares to the monolithic hypermedia systemsthat also limit the special functionality to their proprietary program and formatand are hard for other systems work with. Similar the EPJ may be compared tothe OHS. The situation here is thus much alike the one previous described frommonolithic to open hypermedia systems and issues hereto related.

6th of August 2006

The 6th of August 2006 I had a second talk with my Aunt Inge Spangsberg. Iwanted to demonstrate the example from the scenario. The purpose of this wasto show her an example of a link between a text and an image. The good thingabout the scenario example is that the image is an xray where a part of it is an-chored (to highlight a decease). She told me it would ease the job of transferringvital information between doctors because it could supplement the text descrip-tion, help preventing errors in the communication both for the creator and thereceiver.

I also demonstrated the pilot program to show her another type of link, namelyweb links. The type is though extended compared to the one on the Internet. Ishowed her a link traversal from a text selection to a multi-headed destinationanchor (Several web sites). She told me this could be very useful when complexterms are used in the various descriptions in the electronic patient journal. Ifan unexperienced doctor reads a description and feel uncertain about an illness,diagnose of general term he or she can follow the link (if the doctor creatingthe description made a link) and get information. If there are no link, they maycreate it themselves, so future uncertain users will have the benefit.

83

Appendix D - Meetings with Inge Spangsberg

12th of November 2006

The 12th of November 2006 I had arranged a third meeting with Inge Spangs-berg. The purpose of the meeting was to test the pilot program. Doing that Ihoped to get Inges practical view of the program. Furthermore, I wanted to testsome hypotheses about usage of the system etc. The first waswhether the ideaworked in such an environment even though the graphical user interface wasnot fully developed. Inge conformed that, but made a remark that the interfaceshould be improved. If not it would be too time consuming to use the system ina larger scale. An important characteristic of the interface is logic. If it logicallybuilt it will be easier for a user to operate it.

84

Appendix E - Meeting with CSC Scandihealth

Appendix E - Meeting with CSC Scandihealth

4th of April 2006

The 4th of April 2006 I had a meeting with chief architect Jan Mark from CSCScandihealth. Being that Jan Mark leads the development of the electronic pa-tient journal from CSC Scandihealth. In the beginning of the meeting I presentedmy idea and a draft vision which he examined. He seemed interested in the ideaand told me that the functionality was not a part of the CSC EPJ. However theyhad both had the idea and demand from customers but not developed it yet.

To exemplify the idea I demonstrated him the Chimera system much like thescenario at page 7 describes it. After that Jan Mark was very interested andasked questions in relation to the EPJ. They were:

1. How does the underlying architecture look like compared to an EPJ?

2. among this, how does the connections between the links stay persistentduring changes?

3. How to develop a graphical user interface, that supports the hypermedia-functionlity in a fast manner (1-2 sec.)?

I found it hard to provide qualified answers for the questions at the time of themeeting so I told Jan Mark that I would continue the work and try to include thequestions here. At a practical level we decided to arrange a meeting after easterthis year. Furthermore Jan seemed very interested in issuing a collaboration indeveloping hypermedia functionality to the EPJ. However it would most likelytake time because both software packages are complex and thus needs to bestudied thorough.

22nd of August 2006

The 22nd of august 2006 I had arranged a 2nd meeting with Jan Mark from CSCScandihealth. It had been a while since our last meeting (see section 8.3) so Iwas eager to put the cooperation in the highest gear once again. At the meetingI explained my progress since our last meeting. I told him about the frameworkand demonstrated the pilot program. After that we had a very good discussionabout how the framework could be integrated theoretically. An approach weboth agreed on was to put a hypermedia engine inside the EPJ that could per-form most hypermedia related tasks (linking, annotation etc.) and then installadd-ons containing viewers, and program logic to handle anchor creation. Theobvious idea is to avoid having to modify the EPJ system. When boiling downthe linking aspect of a hypermedia system, all it does is to go from an entity ofsource points to an entity of destination end points and eventually display theannotations. Hence this work can be defined in a general way so the hypermedia

85

Appendix E - Meeting with CSC Scandihealth

engine can perform this task.

We talked about the fact that the process of linking encompasses a general partand a specific part. The general part is the process of going from somethingtowards something else (A to B). The specific part consists of the different an-chor types and corresponding viewers connecting and displaying A and B. Thisinformation is difficult to describe in general terms because it relates to howto create anchors in a given medium (text, graphics, audio, video etc.) and af-terwards the displaying the anchor. The process of creating an anchor in a textdocument is fundamentally different from doing it in a image or video and there-fore the information about should be contained in modules and connected to thehypermedia engine. The add-on packages could just be jar files included in theclasspath of the EPJ.

12th of December 2006

The 12. of December 2006, I met with Jan Mark from CSC Scandihealth. Thepurpose of the meeting was to finish the project. I demonstrated the system forhim. He seemed very interested and we discussed it.

Concerning implementation in the CSC EPJ, we talked about the potential waysof doing so. Considered that the system does not require major change to theEPJ, but is merely an add-on, Jan assessed that, through further development ofthe project, it may be implemented in the EPJ in reasonable time.

According to Jan, the system allows for a stepwise introduction where it maybe introduced and if successful it can be extended. The fact that the Viewerinterface only defines 6 methods that must be implemented is a good featuremaking it simple to work with the framework.

86

Appendix F - The attached cd-rom

Appendix F - The attached cd-rom

The attached cd-rom contains various data concerning this project. It is orga-nized in several folders:

Folder Description/dist/ This is the compiled version of the source code files

packed in a zip file. For guide lines on installing theframework and pilot program refer to Appendix C -Installation guide lines at page 82.

/src/ Contains all source code files/support/ The framework and pilot program requires the Java

Runtime Environment version 6, which is located inthis folder.

/thesis/ Contains the thesis report in pdf format.

Table 1: Folders on the attached cd-rom.

87