EKG Opsamling Rapport - Hjemmesider på Ingeniørhøjskolen i Århus

Multidisciplinær SW-Ingeniøropgave. Teknisk IT, IHA/AU 2008 

Distribueret opsamling og præsentation af EKG målinger. 

Multidisciplinær SW-Ingeniøropgave 

af 

Jesper Rosholm Tørresø 

Ingeniørhøjskolen i Århus 

August 2008. 

Jesper Rosholm Tørresø: 20060653 Side 1 26-08-2008


Indholdsfortegnelse 

Indholdsfortegnelse..............................................................................................................................2 

Forord...................................................................................................................................................3 

Konceptuelt oplæg for opgaven ”Opsamling og præsentation af EKG målinger”. .............................3 

System til indsamling og præsentation af sundhedsdata..................................................................3 

Overordnet generel systemarkitektur...........................................................................................3 

System med ”Kine Myo ECG” måleudstyr. ....................................................................................5 

Hospitalsdomænet........................................................................................................................5 

Sundhedscenterdomænet..............................................................................................................6 

Privatsfæredomænet.....................................................................................................................7 

Opsamling på konceptuelt oplæg.....................................................................................................8 

Use Cases der ønskes udført ................................................................................................................8 

Use Case ”EKG måling”..................................................................................................................8 

Kommentarer til Use Case ”EKG måling”. .................................................................................9 

Use Case ”Visning af EKG diagram” ..............................................................................................9 

Kommentarer til Use Case ”EKG måling”. .................................................................................9 

Beskrivelse af det udførte system. .....................................................................................................10 

Indledning ......................................................................................................................................10 

HealthCare@Central ”Persistence” service. ..............................................................................11 

”RealTimeKMUI” komponenten på Base Station PC. ..............................................................17 

HealthCare@Central ”Kine ECG Presenter”.............................................................................19 

Udviklings- og deploymentmiljø. ..............................................................................................23 

Konklusion.........................................................................................................................................23 

Mål. ............................................................................................................................................23 

Komponentorienteret udviklingen. ............................................................................................23 

SIH sammenhæng. .....................................................................................................................24 

Generelt......................................................................................................................................24 



Forord. 

Oplægget til denne multidisciplinære SW-ingeniøropgave er givet på følgende hjemmeside 

http://staff.iha.dk/jrt/TIMUDSWP/ under betegnelsen ” Opgave 1. System til præsentation af 

indsamlede måledata fra SIH systemet” og ” Opgave 3. Datacentreret referencemodel for en 

serviceorienteret SIH infrastruktur ”. 

Konceptuelt oplæg for opgaven ”Opsamling og præsentation 

af EKG målinger”. 

Udbredelsen af informationsteknologiske systemer (IT) inden for sundheds- og plejeområdet i 

Danmark er en opgave, der har været i gang stort set siden elektronisk databehandling, EDB, er 

blevet taget i brug i den offentlige og private forvaltning. IT-systemerne har spillet og spiller særligt 

rollen som administrative systemer og som planlægnings- og styringsværktøjer, men samtidigt har 

det procesudstyr, apparater, instrumenter etc., som bruges i selve sundheds- og plejearbejdet 

gennemgået en udvikling, hvor computere er blevet en vigtig del af og for apparaternes funktion. 

Integrationen mellem de to domæner, administrativ IT og IT-baseret procesudstyr, er ikke en 

disciplin, som har foregået i stor stil, sideløbende med de to først nævnte domæners udvikling. 

Denne opgave er et forsøg på at vise et eksempel på, hvorledes en sådan integration kan udføres. 

System til indsamling og præsentation af sundhedsdata. 

Nuværende elektroniske patientjournalsystemer (EPJ) er fokuserede på dokumentation af 

behandlinger på sygehusene, via data opsamlet og indlagt i EPJ'en af sygehuspersonalet. 

Denne opgave har som grundlag, at vise en mulig automatisering af dataopsamling med mulighed 

for efterfølgende visning af indsamlede ”sundhedsdata”. 

Som en, i hvert fald i Danmark, utraditionel fremgangsmåde opsamles data i hjemmet eller på det 

sted hvor den person, som data opsamles, fra befinder sig, hvorfra data så distribueres/formidles 

videre til hospitalets patientjournal system. 

Casen der bruges er opsamling af elektrokardiografiske data (EKG data) for et hjertes rytme. 

Præsentationen af data skal være et diagram 1 fra en EKG-målingssensor. EKG sensoren skal om 

muligt fungere i en SIH HealthCare systeminfrastruktur I [1]. I denne opgave af valgt en Kine Myo 

ECG sensor, se beskrivelsen i afsnit Fejl! Henvisningskilde ikke fundet.. 

Opgaven udføres i samarbejde med Systematic System Engineering A/S, med kontakt til Per Leth 

Jensen. Systematic har et ønske om at vise EKG signaler i deres EPJ system "Columna". 

Overordnet generel systemarkitektur. 

Den overordnede arkitektur til et system for dataopsamling og visning er bestående af de tre 

komponenter vist i Fejl! Henvisningskilde ikke fundet.. Kort beskrevet er disse tre komponenter: 

1. Columna EPJ komponenten i form af en Systematic Columna Server. Præsentationen af 

indsamlede måledata skal kunne vises i en indlejret HTML/HTTP Browser (eller via anden 

teknik/princip) på en Columna klient (ikke vist i diagram), idet data ikke umiddelbart skal 

indgå, som bilag i EPJ patientjournalerne. Udvælgelse af data skal om muligt foregå gennem 

Columna. Systematics Columna EPJ komponenten har således en formidlingsfunktion. 

2. HealthCare Persistence komponenten, som er en Dataservice Server under SIH 

HealthCare, og tilbyder en Webservice-HTTP / REST-HTTP 2 baseret service for beskrivelse 

1 EKG diagrammer er omfattet af en helt fastlagt standard for visning af EKG signalet 

2 REST = Representational State Transfer 



af indsamlede data og til at hente data i et simpelt visnings format, dvs. HTML side med 

grafik. Det er endvidere via HealthCare Persistences Webservice, at opsamlede data 

persisteres. 

3. HealthCare Application komponenten, som virker sammen med målingsudstyret, og som 

via SIH HealthCare’ infrastruktur kommunikerer med Dataservicen i punkt 2. Personen der 

er vist, er den person, som der ”måles” på, men også samtidig repræsentationen af selve 

måleudstyret (her Kine Myo ECG). 

Figur 1 Generelt system til automatisering af opsamling og præsentation af sundhedsdata fra et hjem til et 

hospital (Navngivning lånt fra IHA SIH HealthCare projektet) 



System med ”Kine Myo ECG” måleudstyr. 

Indeldningsvis skal det bemærkes at udviklingen af komponenterne HealthCare@Application og 

HealthCare@Persistence fra Figur 1 er i fokus for denne opgave. Columna EPJ komponenten skal 

”kun” konfigureres 3 , og da der benyttes en webapplikation, som præsentationskomponent, er 

bindingen til enheden, der viser data meget svag. Resten af denne rapport omtaler derfor 

fremviserne, som ”ikke andet” end en HTTP-HTML browser, eksempelvis Internet Explorer eller 

Firefox. 

Systemet kan geografisk være spredt over tre forskellige domæner Privatsfære, Sundhedscenter og 

Hospital, som vist i Figur 2, og dette er den type placering, der arbejdes med i dette projekt. 

Figur 2 Mulig geografisk placering af enheder i Kine Myo ECG System. 

Den geografiske opdeling er betinget af fuld adgang til Internettet (Internet Service Provider ISP 

forbindelserne i Figur 2), men en sådan opdeling er ikke et krav for systemet. Privatsfæren kunne 

ligeså godt være en sengestue på hospitalet og Sundhedscenteret en del af hospitalets IT-server 

park. 

Domænerne beskrives således 

Hospitalsdomænet 

Centreret omkring Columna Serveren, der benytter sin egen database på EPJ DB serveren. 

Systematics Columna Server er baseret på Java Enterprise Edition (Java EE) og afvikles på en IBM 

Websphere Application Server, en såkaldt flere lags klient-server virksomhedsapplikation. 

3 Denne opgave er bundet til den aktuelle version, der er installeret af Columna systemet. 

Jesper Rosholm Tørresø: 20060653 Side 5 26-08-2008 

Radioforbindelse


Klienterne, der er vist til venstre i Hospitalsdomæner, er her en række forskellige PC’er, som via 

Java Web Start teknologien afvikler EPJ systemet overfor personalet på hospitalet. Det er ved hjælp 

af disse klienters indlejrede http-html browser, at de opsamlede data fra Kine Myo ECG (KME) 

måleudstyret skal vises. EPJ-klienterne er funktionsmæssigt fuldt afhængige af opsætning af serversiden 

i systemet, og det er derfor konfigurationen på server-siden, der bestemmer hvilken adgang 

klienterne får til resten af systemet, HealthCare@Persistence, i denne opgave. Sagt på en anden 

måde, adgangen fra EPJ klienter til HealthCare@Persistence komponenten foregår indirekte 

gennem Columna Serveren. 

Databasen er en Oracle RDBMS server, og ikke har nogen direkte betydning i denne opgave. 

Sundhedscenterdomænet 

Dette domænes opgave er populært sagt at formidle data mellem ”producent”/ måleudstyr og 

”forbruger”/fremviser. Problematikker, som koblingen mellem en person og det måleudstyr, der er 

tilknyttet denne person løses tilsvarende i dette domæne. De to servere, der er vist i Figur 2, er for 

HealthCare DB’ vedkommende en Microsoft 2003 SQL Server (MSSQL) og for 

HealthCare@Central’ vedkommende en Microsoft Internet Information Services ver. 6.0 (IIS) med 

ASP.NET ver. 3.5. 

Sundhedscenterdomænet og Privatsfæredomænet har en tæt kobling omkring funktionalitet i SIH 

HealthCare projektet og tilsvarende i dette projekt, men kan/skal alligevel kunne fungere 

uafhængigt af hinanden. De to enheder HealthCare@Central og base stationen HealthCare@Home 

står for koblingen mellem de to domæner. Base stationen beskrives nærmere i Fejl! 

Henvisningskilde ikke fundet. afsnittet. 

Komponenten HealthCare@Persistence (se Figur 1) er en primær komponent på 

HealthCare@Central. I dens nuværende udgave (pr. juni 2008) er dens opgave, at stille et service 

interface til rådighed for persestering i og fremskaffelse af data fra databasen. I dette projekt 

udvides komponenten med en fremvisningskomponent ”Kine ECG Presenter” (se Figur 4). 



Privatsfæredomænet 

Det mest ”uformelle” af de tre domæner. Valget af Kine Myo ECG udstyret, se Figur 3, er et udtryk 

herfor. Kine’ trådløse EKG måler betyder, at personen der får målt sit EKG kan fungere i en næsten 

normal hverdag uden at skulle håndtere en masse ledninger, papirstrimler med EKG målinger etc. 

Figur 3 ”Hjemme i Privatsfæren” Set fra venstre vises ”HealthCare@Home Base Station” med dette projekts HealthCare@Application 

RealTimeKMUI applikation i drift. Nederst midterst og forrest ses Kine’ EKG måler til placering på brystkassen på personen i fokus. Via 

trådløs forbindelse overfører EKG måleren data til Kine’ Base Station, den blå enhed i midten til højre. Kine base stationens antenne ses helt 

til højre og bag på enheden ses RS232C forbindelsen til HealthCare@Home Base stationen. 

Den lille enhed, som ses forrest på billedet, skal af og til placeres foran på Kine Base stationen for 

at få opladet sit batteri. 

HealthCare@Home basestationen er i dette projekt en ganske almindelige bærbar PC, hvor 

HealthCare@Application applikationen ”RealTimeKMUI” er udviklet til at kunne fungere sammen 

med Kine Base stationen og HealthCare@Persistence. RealTimeKMUI er uden sammenhæng med 

SIH projektets framework for en Basestation 4 . ”RealTimeKMUI” fungerer med eller uden 

HealthCare@Persistence komponenten. 

Kine udstyret kan måle på een afledning, den såkaldte sinusrytme. Når RealTimeKMUI 

applikationen foretager en måling, vises resultat i realtid på en EKG graf på basestationens skærm, 

så personen, der måles på, eller andre interesserede kan følge med i forløbet. Applikationen er 

udviklet til at foretage en tidsbegrænset måling, som gemmes og tages frem til senere visning. 

Bogstaveligt talt skal systemet kunne erstatte den slags målinger, hvor resultatet gemmes på en 

papirstrimmel. 

En måling på Kine udstyret fungere ved at RealTimeKMUI applikationen via den medfølgende 

Kine driver beder Kine Basestationen starte en optagelse i et angivet tidsrum f.eks. 30 sekunder. 

EKG målingerne foretages med en samplefrekvens på 625 Hz. Via Kine driveren afleveres i blød 

realtid datablokke med 117 målinger (.NET float a 4 byte) til applikationen. I takt med at 

målingerne modtages sendes de til grafen på skærmen og lagres sekventielt i modtaget rækkefølge 

applikationen. Når målingen er færdig bliver opsamlede data formateret til en graf, der gemmes 

4 Efter dette projekts udviklingsfase porterede Jasper Molkte Nygaard efterfølgende RealtimeKMUI applikationen til 

SIH Basestations Framework. 



lokalt på HealthCare@Home Basestationen, som et billede og sendes til HealthCare@Persistence, 

både som billede og som binære data. 

Opsamling på konceptuelt oplæg. 

Lægger op til at indgå i serviceorienteret arkitektur (SOA) og benytter derfor løs kobling mellem 

komponenter, komponenter med høj kohæsion (begrænset funktion), og så vidt muligt asynkron 

interaktion/kommunikation. 

Use Cases der ønskes udført 

Use case i dette projekt er ikke nødvendigvis et (/er ikke) udtryk for et brugerdrevent behov. 

Systemet der udvikles på er et prototypesystem, så use casene bruges mere som krav til, hvad der er 

brug for af funktionalitet. 

Da systemet for dataopsamling omfatter to ret løst sammenhængende dele, selve 

dataopsamlingsdelen (producentdelen) og fremviserdelen (forbrugerdelen) omfatter dette projekt to 

use case som ønskes udført. Det to use cases kaldes: 

1. ”EKG Måling” 

2. ”Visning af EKG diagram” 

Use Case ”EKG måling” 

Denne use case gennemføres i Privatsfæredomænet. 

Forudsætninger for dens gennemførelse er at: 

• HealthCare@Home Basestationen er tændt og at RealTimeKMUI applikationen er startet. 

• Den serielle forbindelse mellem RealTimeKMUI og Kine Basestationen er til stede. 

• Kine Basestationen og Kine ECG måleren har forbindelse (Batteriet er opladt på ECG 

måler) og måleren er påklæbet korrekt på brystkassen af personen der skal måles på. 

• Hvis data senere skal fremvises på hospitalets EPJ, skal HealthCare@Home Basestationen 

internetforbindelse være åben og samtidig skal HealthCare@Central serveren i 

Sundhedscenterdomænet være i drift. 

Use Casen forløber således: 

1. Der vælges et tidsinterval for målingens varighed. I denne udgave vælges mellem 30 sek., 1 

min., 1,5 min og 2 min. 

2. Det bestemmes nu, om målings data skal gemmes hhv. lokalt som billede på basestationen 

og centralt på Sundhedscenteret. Billede der gemmes lokalt kan også vælges sendt til 

Sundhedscenteret. 

3. Målingen startes. 

4. En EKG graf vise dynamisk resultatet på basestationens skærm. 

5. Efter ca 15 sek. indsvingningstid begynder dataopsamlingen. 

6. Når måleintervalstiden er udløbet sker følgende 

a. Hvis ønsket, oprettes et billede af EKG diagrammet, der gemmes lokalt på 

basestationen (En almindelig billedfremviser vil herefter kunne vise diagrammet). 

b. Hvis data skal sendes til Sundhedscenteret overføres de rå måledata hertil 

c. Hvis angivet sendes også billedet fra punkt a til Sundhedscenteret. 



Kommentarer til Use Case ”EKG måling”. 

Meget mere automatisering for ”målepersonen” måske ønskeligt. Beror på fremtidig infrastruktur i 

SIH HealthCare projektet. 

Use Case ”Visning af EKG diagram” 

Visningen af EKG måledata i form af diagrammer generet under Use Case ”EKG måling” betragtes 

som eksterne data i forhold til Columna EPJ systemet, idet de ikke er målt og dermed kvalificeret af 

hospitalets personale. 

Forudsætninger for use casens gennemførelse er at: 

• Internetforbindelse til Sundhedscenterdomænet skal være åben og samtidig skal 

HealthCare@Central serveren være i drift. 

• EPJ systemet er konfigureret til at åbne for adgangen til HealthCare@Central serveren og 

EPJ klienten indlejrede browser skal være i stand til at vise en normal HTML hjemmeside 

med billeder. 

Alternativt kan en ganske almindelig browser som MS IE eller Firefox 

bruges i stedet for EPJ klienten. 

• Personnummeret for den person, der skal vises EKG diagrammer for, er kendt for EPJ 

brugeren og der er diagrammer til rådighed (Use Case ”Ekg Måling” er udført på forhånd) 

Use casen forløber således: 

1. Via Columna EPJ systemet vælges funktionen, som kan vise eksterne måledata (Den 

indlejrede http-html fremviser. 

2. Herefter angives CPR nummeret for den person EKG diagrammer skal vises for. 

3. Der vælges mellem to former for visningsforløb 

a. Visning af alle diagrammer for valgte person 

I. Ældste diagram vises først og via ”frem” eller ”tilbage” funktionen 

bladres mellem mulige diagrammer 

II. Afhængig af diagrammets varighed rulles der frem og tilbage i 

diagrammet. 

b. Visning af en liste med hvilke diagrammer der findes for pågældende person. 

I. Via listens oplysninger om tidspunkt for optagelse af diagrammet kan 

der nu vælges et diagram til visning 

II. Afhængig af diagrammets varighed i tid rulles der frem og tilbage i 

diagrammet 

4. En ny persons data skal vælges og der vendes tilbage til punkt 1. 

Kommentarer til Use Case ”EKG måling”. 

Udvælgelsesmekanisme er meget simpel. Data overføres til visning i EPJ vha. CPR nummer. 



Beskrivelse af det udførte system. 

Indledning 

En række beslutninger taget omkring arkitekturen af EKG opsamlingssystemet påvirker selve 

designet af systemet. Valget af en komponent og service orienteret arkitektur sikre en lav kobling 

og særligt løs kobling mellem komponenterne. Så længe de enkelte komponenter enten 

implementere eller benytter en given service som specificeret, så står udførelsen af en given 

komponent ret åbent/frit. 

I dette projekt har valget af host platform, dvs. computer og operativsystem, været en afgørende. 

Faktor. At driveren til Kine Base stationen er udført i C# .NET har en afgørende indflydelse på 

valget af programmeringsplatform og sprog til udførelse af HealthCare@Home Base Stationen, som 

ikke overraskende udføres med C# .NET. 

Den nuværende udgave af SIH projektets HealthCare@Central komponenter/services bruger også 

C#. NET og den nye komponent, der tilføjes, udføres således også i C#.NET. Som en 

webapplikation, hvilket sikre en løs, skalerbar og meget åben kobling til fremvisere/aftagere af 

EKG måledataene. Figur 4 viser den faktiske komponentarkitektur for systemet. 

«Offentlig Host» 

sih2.sn.iha.dk 

«PC'er» 

Columna Klient 

Persistence 

«C# .NET» 

HealthCare@Central 

«C# .NET Webapplication» 

Kine ECG Presenter 

HTTP Server 

EPJ Klient HTML Browser 

WSDL //http:sih2.sn.iha.dk/HealthCare@Central/Persistence/Service.asmx?wsdl: 

«Webservice» 

HTTP Soap 

«Windows XP» 

Base Station PC 

«Kontrol Enhed» 

Kine Myo Base Station 

«C# .NET» 

RealTimeKMUI 

«Seriel/COM port» 

Kine Data Protokol 

Data Service 

«Radio Link» 

Unit Channel 

Firmware 

URL http://sih2.sn.iha.dk/HealthCare@Central/Persistence/EcgSelectorUsr.aspx: 

«Måler» 

ECG Unit 

Figur 4 Komponenter og serviceinterfaces i Kine Myo ECG systemet. URL og WSDL til services er vist som 

noter i diagrammet. 

Person in focus 

Komponenterne for dette projekt er beskrevet i det efterfølgende. Rækkefølgen for udviklingen af 

komponenterne har været: 

1. Persistence service, som på forhånd var under udvikling til andre projekter. Som følge af det 

iterative udviklingsforløb sammen med RealTimeMUI, ændres komponenten noget under 

dette projekt. 



2. RealTimeKMUI, der er basereret på Kines demosystem af samme navn. Den allerede 

eksisterende Peristence service kunne umiddelbart integreres i komponenten, da dennes 

dataopsamling var klar til brug. 

3. Kine ECG presenter blev påbegyndt udvikling, så snart en EKG måling fra Kine MYO ECG 

var gemt i HealthCare Databasen vha. Peristenceservice. 

HealthCare@Central ”Persistence” service. 

Første udgave af SIH Projektet HealthCare@Central Persistence service er en Webservice baseret 

grænseflade til en relationsdatabase (RDB), opbygget som vist i Figur 5. En databaseopbygning 

som er inspireret af ISA-88 standarden for industrielle produktionssystemer og foreslået af i AFP af 

Søren Rasmussen og Rune Søe-Knudsen. II 

HistoryLog 

EquipInclude 

EquipmentID 

ClassEquipmentID 

Description 

RecordID 

EquipmentID 

UTC 

LocalTime 

RecordAlias 

NewValue 

OldValue 

EngrUnits 

Block 

EquipElement 

EquipmentID 

EE_Type 

EE_Level 

Description 

ContainedIn 

Figur 5 HealthCare Databasens Relationer (Tabeller) og Relationships 

EquipLink 

EquipmentID 

ToEquipmentID 

Description 

EquipProperty 

EquipmentID 

PropertyID 

PropertyValue 

EngrUnits 

Description 

Princippet for databasens opbygning er i stor grad inspireret af det objektorienterede princip, hvor 

der bruges klasser og objekter for hhv. typer og fænomener/instanser, og hvor sammenhørigheden 

mellem klasser udtrykkes ved nedarvning eller aggregering og komposition, mens objekter kun 

benytter aggregering og komposition. 

I HealthCare Databasen defineres ”klasser” og ”objekter” i ”EquipmentElement” relationen 

vha. attributten ”EE_Type” hhv. med værdien ”1” eller ”2”. Type ”1” enheder skal ses som 

metaenheder, beskrivende enheder, og type ”2” enheder skal ses, som faktiske enheder. 

Nedarvning er ikke mulig i en RDB, men erstattes af et inkluderings-relationship mellem de 

forskellige enheder, som findes i EquipElement relationen. De forskellige ”inkluderinger”, som er 

nødvendige, er angivet i EquipInclude relationen vha. af en sammensat primærnøgle, hvor den ene 

halvdel EquipmentID referer til enheden der ”nedarver” og den anden halvdel ClassEquipmentID 

referere til den enhed (”Superklassen”) der ”nedarves” fra. 

En tilsvarende konstruktion er brugt til aggregering/komposition, hvor relationen EquipLink 

angiver de nødvendige sammenkoblinger. Igen EquipmentID angiver her enheden der ”linkes” fra 

og ToEuipmentID angiver enheden der ”linkes” til. 



Konkrete datafelter eller egenskaber for de forskellige klasser og objekter (enheder), der 

optræder i et systemet, angives i EquipProperty relationen. Hver eneste enkelt felt eller egenskab 

tildeles sit eget unikke ID PropertyID, som vha. af en sammensat primærnøgle kobles med 

EquipmentID til ejerenheden i EquipElement relationen. En egenskab på en type ”1” enhed, klasse, 

betragtes som en logisk egenskab, mens en egenskab på en type ”2” enhed er den faktiske værdi for 

en givne enheds egenskab. 

Der er ingen bindinger i databasen, der gør at en type ”2” enhed skal inkludere en eller flere type 

”1” enheder, eller have alle eller kun de egenskaber, som den type ”1” enheder, der inkluderes, 

angiver. 5 

Datalogninger i forhold til en given enhed (EquipElement) gemmes i HistoryLog relationen, hvor 

hver enkelt logning får sin egen unikke identifikation, RecordID, og knyttes til enheden, der logges 

på, via en reference til EuipmentID i EquipElement relationen. I HistoryLog er feltet Block et 

såkaldt BLOB (Binary Large OBject) og alle former for måledata kan derfor gemmes heri. 

Brugen er de enkelte felter i relationerne er beskrevet nærmere i forbindelse med de metoder, der 

tilbydes i webservicen. 

Webservice Persistence opbygning er baseret på Microsofts Webservice og LINQ-to-SQL 

faciliteter inkluderet i .NET 3.5 platformen og VisualStudio 2008 samt nogle Stored Procedures og 

Functions i MS SQL 2003 databasen, og derved opbygget med en relativ enkel 2 lags lagdelt 

arkitektur, hvor lagene er afspejlet i komponenterne vist i Figur 6. Webinterfacet er udført i 

komponenten Service. 

Figur 6 Komponentarkitektur for Persistence Service 

Databasen opbygning er vist i Figur 5. Al adgang til databasens relationer, ”Stored Procedures” og 

”Functions” sker gennem DataClassesDataContext komponenten. 

Service komponenten er kodet i sin egen C# klasse, klassediagrammet ses i Figur 7. To 

hjælpeklasser er tilføjet til brug for Service komponenten, PersonalDataSelector og 

RawDataDTO. 

5 Opsætningen af modellen for konkret system kræver et ”administrationsværktøj” der håndterer de forskellige regler. 

Dette værktøj/system er endnu ikke udviklet. 



PersonDataSelector er klasse for kobling/mapning mellem selve problemdomænet og den rå 

generiske database. I dette projekt bruges een metode der omsætter et CPR nummer til en unik 

systemidentifikation (EquipmentID). For sammenkobling af udstyr og personer se senere [Set en ref 

her] 

RawDataDTO er en simpelt databærende klasse (Data Transfer Object), som bruges til via 

Webservice, at overføre en persons persisterede måleresultat fra HealthCare@Ccentral til en 

aftagerapplikation. 

Figur 7 Klassediagram for Persistence service. Klasserne DataClassesDataContext, EquipElement, HistoryLog, 

EquipPorperty og getPersonMeasureDataResult er generet af .NET LINQ to SQL. 

Service interfacet, sih2.sn.iha/HealthCare@Central/Persistence/Service.asmx, tilbyder pt. 

metoderne som er vist i Figur 8, der også beskriver funktion bag hver metode. De komplette 

signature beskrives ikke her, da er ”selvdokumenterende” efter import og kodegenerering fra 

WSDL filen. 



• getBindId Endnu ikke komplet metode, men nuværende udgave returnerer et mulig NFC 6 

tag på baggrund af en enheds unikke EquipmentID. 

• getEquidId Returnerer en enheds unikke EquipmentID udfra enhedens MAC 7 adresse. 

• getLogId Pba. af en enheds EuipmentID returneres det unikke EquipmentID for den 

person enheden er tilknyttet. Sammenkoblingen af udstyr og en person foregår via en 

såkaldt CareProcess en abstrakt enhed hvortil man ”linker” personer og udstyr. Der er 

kun tilknyttet en person til en CareProcess 

• getRawData Returnere alle persisterede målinger fra et givent tidsinterval og en given 

person angivet ved dennes EquipmentID (evt. hentet med getLogID metoden). 

• getUniqueId Returnere MAC adressen for en enhed ud fra dennes EquipmentID. 

• rawDataByteSec Metode for persistering af en sekvens af byte. Benytter en typestærk 

parameterliste for enkel datakonvertering. 

• rawDataFloatSec Metode for persistering af en sekvens af floats. Benytter en typestærk 

parameterliste for enkel datakonvertering. 

• rawDataTimeSec Anden udgave af en metode til persistering af data. Alle parametre på 

nær tidsstempling angives via byte arrays, hvilket giver en åben men også besværlig type 

håndtering 

• rawDataSec Første udgave af en metode til persistering af data. Alle parametre angives 

via byte arrays, hvilket giver en åben men også besværlig type håndtering 

• setPair Tom metode til fremtidig brug 

Figur 8 Metode på Persistence service. 

Mange af metoderne er ”kun” første iteration i forhold til SIH projektet. Primærer fokus har i 

foråret 2008 været rettet mod indrapporteringsmetoderne præfikset med ” rawData..”. 

Ideen bag metoderne er, at en enhed, producent, med så få oplysninger og så simpelt som muligt 

kan aflevere en ”bunke data” fra en person til persistering. Signaturen for en af de fire ”rawData” 

metoder er vist her i C# .NET syntaks, forskellen for de andre tre er brugen af type i signaturen: 

[WebMethod ] 

public string rawDataFloatSec(float[] data, DateTime time,string logtype, long personid, 

long sensorid, long secid) 

{… 

hvor data er sekvensen af måledata, time er tidspunktet for datamåling, logtype er typen af måling, 

personid unik ID, EquipmentID, for personen der er målt på, sensorid er unik ID for måleenhed 

bag målingen og secid til fremtidig brug for ”krydscheck” af korrekt sensor etc. Returværdien er en 

string som enten returnere en unik id, RecordID, for den gemte måling eller en simpel fejlbesked. 

Der er i metoderne på ingen måde taget hensyn til kontekst for målingen, format af data og den 

videre brug disse, data betragtes udelukkende som enkle binære datablokke. Det forudsættes at 

sensor og person er korrekte sammenhørende og at logtype er bestemt i sammenhæng med hhv. 

producent og aftager, eksempelvis for dette projekt som "Kine ECG rawdata" for en binære rå data 

målesekvens og "Kine ECG paper" for et EKG diagram i form af et JPEG billede. 

CareProcess princippet. 

En ”CareProcess” er moduleringsbegrebet 8 for omsorg og er scenariet, der omfavner udførelsen en 

sundhedsopgave overfor en person. En CareProcess omfatter, som den vigtigste del, den person 

6 NFC Near Field Communication 

7 MAC adresse MediaAccesControl adresse, bruges særligt ved Ethernet og Bluetooth netværk. 



sundhedsopgaven drejer sig om, samt det udstyr, kontrolenheder, computere og programmer som 

indgår i processens afvikling. 

ISA88 database standardens generiske designkoncept betyder at der ikke er ”bundet” regler ind i 

dens database struktur. ISA88 er udviklet til batchproduktion der skal kunne gentages og 

dokumenteres for korrekt udførelse etc. eksempelvis medicinfremstilling. 

Da ISA88 er udviklet til store virksomheder med national og international udbredelse opstiller 

standarden en model for distributionen af produktionen, der skal beskrives og dokumenteres. Denne 

model passer til databasestrukturen i Figur 5. Modellen er overført til SIH HealthCare projektet og 

danner indtil videre basis for, hvorledes Persistence servicen virker. 

Modellen for distribution for både ISA88 og SIH er vist i Figur 9. Modellen benytter syv niveauer 

for graden af distribution og pakkerne vist i diagrammet afspejler fra niveau et, logiske domæner 

ned til niveau syvs konkrete enheder i tråd med principperne for lagdeling, med abstrakte toplag og 

konkrete bundlag. I databasen indeholder EquipElemt relatione en felt EE_Level som netop 

angiver enhedens konkrete niveau. 

ISA88 konceptet skal ikke omtales her, og pakkerne til højre i Figur 9 er ”kun” med som 

illustration. 

SIH distributionsmodellen er en hovedsageligt hierarkisk opbygget træstruktur. Domænet ”Public” 

på niveau 1 er omverdenens systemer i forhold til HealtCare projektets systemer. Columna EPJ 

systemet hører til her og repræsentere et hospital. På niveau 2 er ”Central” domænet og her 

begynder HealthCare systemet at optræde, Sundhedscenteret og HealtCare@Central services tilhøre 

dette domæne, se Figur 2. De to nævnte domæner betragtes både som logiske og konkrete, vist 

skraveret i modellen. 

8 At modulere begrebet ”Omsorg” er en næsten umulig/halsløs opgave, derfor bruges den mere tekniske betegnelse 

CareProcess som afspejler nogle simple arbejds- eller funktionsgange og noget udstyr. 



Figur 9 ISA88 inspireret distributionsmodel for SIH HealthCare projektet. Skraverede pakker er både logiske 

og konkrete domæner. Prikkede pakker er rent logiske organisatoriske domæner. Den ternede pakke er 

software 



De to efterfølgende domæner Home, på niveau 3, og CareProcess, på niveau 4, er rent logiske 

organisatoriske størrelser, vist prikket, og bruges, indtil videre, som bindeleddene mellem udstyr, 

systemer og personer. Næste domæne ”Base” på niveau 5 er konkret som computeren, 

basestationen, hvorpå HealthCare@Home applikationerne afvikles. ”Sensor/Device/Person” 

domænet på niveau 6 er ligeledes konkret idet alt udstyr samt personen, der benytter udstyret, hører 

til her. Sidste domæne ”Agent” på niveau 7 er et softwaredomæne og HealthCare@Home 

applikationerne er tilhørende her. ”Agent” domænet vil få betydning i forbindelse med 

opbygningen af Framework’et til Basestationen og Centrale services. 

I dette projekt og nuværende udgave af Persistence service er fokus på sammenkoblingen af de tre 

domæner ”CareProcess”, ”Base” og ”Device/Sensor/Person” samt på kommunikationen mellem 

”Base” og ”Central” domænerne. 

En række CareProcess’er, forskelligt udstyr og personer er oprettet i databasen og via EquipLink er 

udstyr og en person koblet til en CareProcess. I Figur 10 er vist et udtræk fra EquipInclude 

relationen. 

EquipmentID ToEquipmentID Description Kommentar (Ikke i DB) 

489 789 Basestation Nr 1 

539 789 CareProces til Hansen 

564 789 EKG/Puls til Hansen 

664 789 SIH Centrak Nr 1 

714 864 CP CSOmron BP 

839 864 CareProcess Fru Hansen 

989 789 Kardiogram som "Strimmel" 

1114 1339 CorSicence Corbelt to 

Villadsen Proces 

1314 1339 Villadsen to Villadsens Care 

Proces 

1364 1339 Hidalgo Equivital to Villadsen 

Personen ”Hansen” 489 og 

dennes udstyr knyttet 

sammen i CareProcess nr 

789 

”Fru Hansen” 839 og 

CareProcess nr 864 

Hansen og dennes CP igen 

Jens Villadsen 1314 og 

CareProcess nr 1339 

Figur 10 Indhold af EquipLink. Viser CareProcess'er med koblede personer og enheder på nuværende tidspunkt 

at SIH projektet. EquipmentID referer til enheder fra EquipElement relationen. 

Tre enheder er blevet brugt i dette projekt. Personen ”Hansen” med EquipmentID ”489” tilføjet en 

egenskab ”CPRNR” = 2101814365, Kine måleudstyr med EquipmentID ”989” og slutteligt en 

CareProcess med EquipmentID ”789”. 

”RealTimeKMUI” komponenten på Base Station PC. 

Udførelsen af ”RealTimeKMUI” er vist i Figur 11. Arkitekturen er baseret på en realtimedemo 

prototype fra Kine, som er ændret og udvidet med de to klasser ”Form2” og ”HealthCareCental” 

samt en Web reference dk.iha.webhotel7.Service(), som forbinder ”HealthCentral” med 

HealthCate@Central Persistence servicen. 

Realtidsafviklingen af applikationen er styret vha. i alt fire tråde, hvoraf to er aktive under måling. 

Interaktionsdiagram, sekvensdiagram, er vist i Figur 12. Trådende kommunikere indbyrdes ved 

hjælp af C#.NET delegates, asynkrone kald, som sutomatisk er trådsikretsikret. 

Behandlingen af datablokkene, 117 .NET float, som Kine Base stationen i blød realtid sender til 

applikationen omfatter to funktioner. Scope klassen, som udfører visning af et tidsvindue, x antal 

målinger, i ”Realtidsgrafen”, og HealthCareCentral klassen der udfører en komplet lagring af data 

fra hele måleintervallet, eks 30 sek. samplet med 625 Hz svarende til 18750 målinger. 



Rå binære data gemmes i hhv. en private List datakollektion, der sendes til 

HealthCare@Central, som et array vha. List.ToArray(); 

Formateringen af data benytter .NET System.Drawing standard fremgangsmåden via Graphics til 

visning på skærm, GraphicsPath til formatering til en graf samt Bitmap og Image til formatering 

af billeder. Grafen, der som billede, gemmes lokalt i en fil og sendes til Centralen, konverteres via 

MemoryStream’s. 

Skaleringen af det endelige EKG diagrams billede sker til JPEG format med en højde på 400 pixels 

og en bredde på 4800 pixel per 30 sek. Selve grafen der er dannet er skaleret i forhold største og 

mindste måleværdi, således at alle værdi vises inden for de 400 pixel højde. Formatering er ikke 

normaliseret i forhold til standarden for EKG diagrammer. 

Arkitekturen er langt fra endelig (”perfekt”), men tjener også kun et formål som prototype 

dataopsamling. 

Form2 

RealTimeKMUI 

frmMain 

HealtCareCentral Scope 

KineMyoDriver 

HealthCare@Central 

Persistence 

UserControl 

Figur 11 RealTimeKMUI’s klassediagram. 

Refresher 

KineLib.dll 

KineMyoDriver.dll 


måletid etc. er 

valgt 

Person i fokus 

Start måling 


Main Thread 

form2 

Brugerens 

grænseflade 

”Form2.cs” 

central 

StartRecording 

ShowDiaglog 

Send data til Central 

Gemmer og 

konvertere alle data 

lokalt og på Central 

”HealtCareCentral.cs 

” 

Kaldet stopper 

tråden i måletiden 

ConvertSampleData 

AddData(buf) 

Windows for 

Realtime visning 

”frmMain.cs” 


frm 

Local Thread RunKmUI 

scope 

Init (”Serial”) 

StartRecording (sec) 

Local Thread 

ekgToolbox_OnDataRecievedEvent(buf,index) 

AddData (buf,index) 

Timerstyret EKG 

Graf kontrol 

”Scope.cs” 

Update Window 

Kine Base Driver 

”KineMyoDriver.cs” 

ekgToolbox 

Local Thread 

Init 

117 float’s 

Figur 12 RealTimeKMUI Interaktionsdiagram. Når en måling foretages er ”scope” tråden og ”ekgToolbox” 

trådene eneste aktive tråde. Tilgangen til ”scope” data er beskyttes af to låse, således at trådene under ”scope” 

og ”ekgToolbox” ikke føre til ødelagte data, når de tilgår objektet. 

Refresher 

Kine Base 

HealthCare@Central ”Kine ECG Presenter” 

”Kine ECG Presenter” er en delkomponent af den samlede ”Persistence” komponent. 

Som et første forslag til en simpel framework arkitektur til HealthCare@Central’ applikationer 

opstilledes en ikke teknisk fokuseret model, som er vist i Figur 13 og som er inddraget i udførelsen 

af ”Kine ECG Presenter”. Kort fortalt opdeler den viste arkitektur sig i tre dele, vist med lodrette 

streger i diagrammer. Princippet bag frameworket er kort at både andre systemer og applikationer 

samt brugere skal kunne benytte services på fra frameworket, ”Service” og ”Brugegrænseflade” 

delene. Koordineringen af servicerne sker gennem ”Central Control” i ”Kontrol og data”, hvor også 

specifik databehandling, som eksempelvis billede- og grafikformatering, sker. Frameworket er pt. 

udført vha. ASP.NET frameworket. 

Dette projekt omfatter de hvide komponenter. ”Persitence” komponenten er beskrevet i afsnit 

HealthCare@Central ”Persistence” service. ”Kine ECG Presenter” klassediagrammet er vist i figur 

Figur 14, og komponenten er en enkel webapplikation.


Service Kontrol og data Brugergrænseflade 

Persistence 

Subskriber 

ECG Presenter 


Central Application Framework 

Central Control 

DataBase Acces 

ECG Formatter 

Persistence User 

Subscriber User 

ECG Presenter User 

Figur 13 Iteration 1 på Central Framework arkitektur. Gråtonede komponenter er ikke med i dette projekt. 

Figur 14 Klassediagram for Kine ECG Presenter komponent. Klasserne KineECGFormatter og 

DataClassesDataContext implementer hhv. komponenterne ”ECGFormatter” og ”DataBase Access” i Figur 13. 



Fordelen ved webapplikationen er, som nævnt tidligere er, at den stort set kan afvikles i en hvilken 

som helst browser. 

”Kine ECG Presenters” eneste opgave er, at fremfinde og vise lagrede EKG diagrammer i form af 

JPEG billeder i HealthCare Databasen af ”RealTimeKMUI” applikationen. 

Indgangssiden er ”ECGSelectorUsr.aspx” og afhængig af, om der vælges enkeltvisning eller 

visning af alle diagrammer (se afsnit ”Use Cases der ønskes udført”), redirigeres til hhv. 

”ECGPresenterUsrSingle.aspx” eller ”ECGPresenterUsr.aspx”. Forskellen i de to ”linjer” i ”Kine 

ECG Presenter” er kontrollen med, hvilke måling der vises. 

Diagrammet/-erne på de to ”Presenter” sider vises i en HTML Iframe, der tillader brugerne er 

scrolle vertikalt gennem diagrammet uden at skulle scrolle hele ”Presenter” siden. De to sider, 

”IframeImageLoad.aspx” og ”IframeImageLoadSingle.aspx”, er siderne der vise ”Presenternes” 

Iframe. 

”Iframe siderne” er udelukkende opbygget med en Image ASP.NET kontrol og tildeles i ”Code 

Behind” delen indholdstypen (ContentType) "image/jpeg" , hvilket gør det muligt at sende/skrive 

et JPEG billede direkte ind på siden til Image kontrollen via ASP.NET Response.OutputStream. 

JPEG billederne fremfindes gennem ”KineECGFormatter.cs” klassen, der står for 

databaseadgangen, søgning på og omformateringen af de binære billeder fra databasen til JPEG 

billedeformatet. Formateringen af binære data til JPEG sker vha. .NET System.Drawing biblioteket. 

Billeddata sendes i appklikationen via en .NET memorystream og ”pumpes” derfor simpelt ind på 

”Iframe sider” som beskrevet tidligere. 

Kontrollen med, hvilken måling/ hvilket billede der vises, sker vha. af data gemt i ASP.NET 

Session og ”Iframe sidernes” Page_Load metoder. Se nærme beskrivelse i Figur 15 og Figur 16. 

protected void Page_Load(object sender, EventArgs e) // ECGSelectorUsr.aspx 

{ 

KineECGFormatter formatter; 

if (!IsPostBack) 

{ 

formatter = new KineECGFormatter(); 

Session["KineECGFormatter"] = formatter; // Fremskaf og formatter data. 

Session["NoOfPapers"] = 0; //Antal billdeder ved ”Vis alle målinger”. 

Session["BrowserIndex"] = (int)0; //Den første i rækken. Bruges samme med DB index 

Session["PaperPersonId"] = 0L; //EuipmentID for Person der er valgt. 

Session["SingleRecID"] = 0L; //Måling der vises ved ”Udvælg måling”. 

} 

} 

Figur 15 Session data for visning af billeder og kontrol med udvælgelse. Page_Load metoden gælder for 

ECGSelectorUsr.aspx” siden. 

Lidt ”ASP.NET julelege” er brugt i forbindelse med ”Udvælg måling” funktion (ASP.Net Button 

Button2) . 

ASP.NET kontrollen GridView er tilføjet ”ECGSelectorUsr.aspx” siden med ”Select” egenskaben 

sat, men uden initial binding til en datakilde/database tabel, hvorfor GridView kontrollen ikke vises 

derfor automatisk, når siden kaldes. Ved aktivering af ”Udvælg måling” knappen, ASP.NET Button 

kontrol, tilføjes en datakilde til GridView’et, i form af et udtræk fra HealthCare databasen 

HistoryLog. Ved ”reload” af ”ECGSelectorUsr” siden vises GridView’et nu med relevante data. 

GridView Select funktion håndteres af GridView2_SelectedIndexChanged metoden. De to 

metoder bag udvælgelsen er vist i Figur 17. 



protected void Page_Load(object sender, EventArgs e) // IframeImageLoad.aspx 

{ 


Response.ContentType = "image/jpeg"; 

MemoryStream memStream = new MemoryStream(); 

formatter = (KineECGFormatter)Session["KineECGFormatter"]; 

int noofpapers = formatter.CountKinePaperECG((long)Session["PaperPersonId"]); 

Session["NoOfPapers"] = noofpapers; 

formatter.KinePaperECGFormatterMS((long)Session["PaperPersonId"], 

(int)Session["BrowserIndex"], memStream); 

memStream.WriteTo(Response.OutputStream); // Send billede til Iframe siden 

} 

protected void Page_Load(object sender, EventArgs e) // IframeImageLoadSingle.aspx 

{ 


Response.ContentType = "image/jpeg"; 

MemoryStream memStream = new MemoryStream(); 

formatter = (KineECGFormatter)Session["KineECGFormatter"]; 

formatter.KinePaperECGFormaterMSSingle((long)Session["SingleRecID"], 

memStream); 

memStream.WriteTo(Response.OutputStream); // Send billede til Iframe siden 

} 

Figur 16 Iframe sidernes Page_Load metoder. 

protected void Button2_Click(object sender, EventArgs e) // “Udvælg måling” 

{ 

if (setPersonId(TextBox1.Text)) 

{ 

DataClassesDataContext db = new DataClassesDataContext(); 

var showlist = from meas in db.HistoryLogs 

where ((meas.EquipmentID == (long)Session["PaperPersonId"]) && 

(meas.EngrUnits == "Kine ECG paper")) 

select new { meas.RecordID, meas.EquipmentID, 

meas.LocalTime,meas.EngrUnits, 

meas.UTC, meas.RecordAlias }; 

GridView2.DataSource = showlist; 

GridView2.DataBind(); 

} 

} 

protected void GridView2_SelectedIndexChanged(object sender, EventArgs e) // ”GridView Select” 

{ 

GridViewRow row = GridView2.SelectedRow; 

long paperselect = long.Parse(row.Cells[1].Text); // RecordID/Måling der skal vises 

Session["SingleRecID"] = paperselect; 

GridView2.DataSource = null; 

GridView2.DataBind(); 

Response.Redirect("./ECGPresenterUsrSingle.aspx"); 

} 

Figur 17 Koden bag udvælgelsesfunktionen på ”ECGSelectorUsr” serversiden. 



Udviklings- og deploymentmiljø. 

De to komponenter, ”HealthCare@Central Persistence” og ”Kine ECG Presenter”, er udført i et 

samlet udviklings- og deployment miljø. ”RealTimeKMUI” er udført, som en selvstændig 

uafhængig komponent og applikation. Udviklingsmiljøet er vist i Figur 18. 

Subversion https://svn2.iha.dk/svn/sih/@central_jrt/trunk/Persistence: 

«VS2008 Solution» 

Persistence 


Deploy 

Development 

Persistence 

Kine ECG Selector 

Subversion https://svn2.iha.dk/svn/sih/@home_jrt/trunk/EPJECG: 

«VS2008 Solution» 

EKG 

i9400-002.iha.dk VS2008 

Development PC 

Development and deploy 


Type 

RealTimeKMUI 

Figur 18 Udviklings- og deployment-miljø. Udvikling foregår med Microsoft Visual Studio 2008 IDE og med 

versionsstyring via Subversion. 

Konklusion. 

Mål. 

Målet med opsamling og visning af EKG data i en ægte distribueret sammenhæng er ramt. 

Målingerne fra Kine MYO ECG udstyret opsamles i Privatsfæren, sendes til Sundhedscenteret og 

kan vises i en browser. Den endelige integration med Columna EPJ er ikke af prøvet, idet der endnu 

forstår en opgradering af EPJ systemet. 9 

Nogle punkter fra oplægget er ikke blevet udført, muligheden for at via et serviceinteface at 

foretage udvælgelse af måledata, ”Webservice Control” vist i Figur 1, eller at foretage en 

abonnering på måledata, når disse gemmes vha. Persistence servicen. 

”RealTimeKMUI” komponenten indeholder nogle delvist udviklede mekanismer for start og stop af 

målinger, men disse er ikke færdige og bruges ikke (To knapper på brugerens billede er disablet). 

Brugereren kan starte en måling og venter så denne afslutning. Da SIH projektet Basestations 

framework skal tage over omkring brugerinteraktion, er den videre udvikling lagt her. 

Komponentorienteret udviklingen. 

Målet med opsamling og visning af EKG data i en ægte distribueret sammenhæng er ramt. 

Den gennemgående komponentorienterede orientering i såvel oplæg, systemarkitektur og design af 

kode har sammen med C#.NET platformen gjort udførelsen af de forskellige dele i systemet til 

”Opsamling og præsentation af EKG målinger” til en forholdsvis simple opgave. Og fremtidige 

udgaver af systemet er også rimelige enkle at iterere videre på, idet de enkelte hovedkomponenter, 

se Figur 4, kan ændre og udvikles uafhængigt af hinanden. 

9 Er under udførelse pr 15. august 2008


Eksempelvis, for adgangen til Kine Base stationen, har den komponent orienterede driver gjort det 

yderst enkelt at fortage en dataopsamling. 

SIH sammenhæng. 

Peristence service er gennemgåede en udvikling underprojektet dels med udgangspunkt i dette 

projekt, men også udfra tilbagemeldinger fra andre projekter. Funktioner omkring, identifikation, 

sammenkoblingen af udstyr og personer, samt lagring af mange målinger med ofte ret store 

datamængder, 300kB til 1,5mB, er blevet udviklet og afprøvet gennem dette projekt, efter devisen 

”Hold det simpelt”. 

Brug af en service orienteret arkitektur og en central service letter og vil lette fremover meget 

arbejdet med at udvikle HealthCare@Home Applikationer. 

Dette projekt har lang fra fulgt SIH projektet hvad angår hjemme delen, men som tidligere nævnt 

har Jaspe Molke Nygaard portet ”RealTimeKMUI” til SIH frameworket. Et forhold som skal 

fremhæves i denne sammenhæng er Kine håndtering af de serielle porte, hvor deres driver selv 

finder frem til hvilken serielport Kine Base Stationen er koblet på. Den form for selvstændighed 

harmonerer ikke med SIH Basestations framework, idet dette selv bestemmer og tildeler 

kommunikationsforbindelser til applikationerne. Kine driveren bør ændres til at bruge den seriel 

port/ data stream SIH frameworket tildeler. 

Administrationen af HealthCare Databasen er et område hvor nogle administrationsværktøjer er 

påkrævet. I dette projekt er benyttes nogle manuelt oprette enheder og sammenkoblinger. Dette er 

som sådan transparent for applikationerne, der benytter Persistence og HealthCare@Central, men på 

sigt, og her og nu, er regler og deres implementation, for hvorledes SIH HealthCare projektet skal 

virke essentielle for det videre forløb. 

Den foreslåede databaseatruktur og CareProcess paradigmet anses for en brugbar og 

holdbar/skalerbar løsning. 

Generelt. 

Projektet har været sjovt at arbejde med, og for udviklerens side har særligt kodningen af grafik 

funktionerne været lærerige. 

Et problem omkring filer og grafik på ”Kine ECG Presenter” komponenten ramte et ”sort hul” i 

Microsoft .NET System.Drawing. Det var ganske enkelt ikke muligt at gemme et billede i en fil på 

hosten hvorpå komponenten afvikles. Fejlen skyldes, vist nok, at grafik behandles i Windows OS 

lager og at låsningen af lageret er skrøbelig. Oprindelig skulle webapplikationen have brugte en 

Ajax komponent til visning af diagrammer baserede på filer, hvilket ville have givet en særdeles 

hurtigt visning af og bladning mellem diagrammerne. Denne teknik blev fraveget til fordel for en 

teknik, hvor et billede hentes fra databasen og skrives direkte på hjemmesiden, hver gang det skal 

vise, en lidt langsommere løsning, som dog også fjernede et problem med fil oprydning på 

webserveren. 

Under arbejdet med Ajax viste der sig flere ”huller” i Ajax implementation, idet de enkelt Ajax 

komponenter ikke har den fulde tilgang til ASP.NET frameworket, eksempel Session objeket med 

dettes oplysninger, hvilet også gjorde at Ajax blev afskrevt i denne omgang. 

Som sædvanlig viste Webservice sin styrke med hensyn til simpel implementation og brug, men det 

er ikke nogen nyhed. 

Jesper Rosholm Tørresø 


I Se reference SW dokument om SIH 

II Sørens og Runes projekt

EKG Opsamling Rapport - Hjemmesider på Ingeniørhøjskolen i Århus

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?