bilag 4 - fase 4 - arkitektur - slutprodukter · eksperter i danmark med erfaring indenfor...

Beslutningsstøtte i bløderbehandlingen Arkitektur: Slutprodukter i 2. iteration / fase 4

Side 1 af 19

Center for Telemedicin, Region Midtjylland. www.telemedicin.rm.dk

Indholdsfortegnelse Arkitektur: Status for 2.iteration ..................................................................................... 2

Status på integration mellem de to user interfaces .......................................................... 2

Status på målarkitektur ............................................................................................... 2

Arbejdsmøde 8/6-2017 .................................................................................................. 5

Referat ...................................................................................................................... 5

IdP ......................................................................................................................... 5

Concent .................................................................................................................. 6

FHIR ...................................................................................................................... 6

Gemme data ........................................................................................................... 6

Patient service ......................................................................................................... 6

Minimalistisk telemedicinsk infrastruktur til bløderprojektet ................................................ 7

It løsning ................................................................................................................... 7

Projektkontekst .......................................................................................................... 8

Samarbejde ............................................................................................................... 8

Drift .......................................................................................................................... 8

Funktionalitet ............................................................................................................. 8

CE-mærkning .............................................................................................................. 10

Møde 7/8-2017......................................................................................................... 10

Formål .................................................................................................................. 10

Forløb ................................................................................................................... 10

Resultat ................................................................................................................ 10

Risikoanalyse – 1 version ........................................................................................... 12

Risk team ............................................................................................................. 12

Risikoprocedure (Annex C) ...................................................................................... 12

Risikoanlyse .......................................................................................................... 16


Side 2 af 19


Arkitektur: Status for 2.iteration Primær fokus for arkitekturarbejdet i iterationen har været at skabe forbindelse mellem app og web prototypen med det formål at kunne lave dybere usability og systemtests. Derudover er der arbejdet yderligere med at konkretisere målarkitekturen. Der er en række punkter, hvor arkitekturen ikke lever op til regionens og lovgivningens krav, og i de tilfælde vil der foretages kompenserende handlinger. Disse kompenserende handlinger beskrives eksplicit i et arkitekturdokument, der udarbejdes i starten af 3.iteration.

Status på integration mellem de to brugergrænseflader Status på integration mellem app(patient) og webinterface(kliniker) er, at der er etableret forbindelse mellem de to brugergrænseflader, og at integrationen er testet (Se resultatet af testen i separat dokument om test). Journls platform skal overholde HL7/FHIR standarden i sin kommunikation med den telemedicinske infrastruktur. Det kræver først og fremmest, at Journls datamodel for kliniske data mappes mod FHIR standardens ressourcer. Dette arbejde er i sin spæde start, men vil forløbe henover resten af projektperioden. Mapningsarbejdet vil kræve inddragelse af eksperter og reviews.

Status på målarkitektur I 2.iteration har fokus bl.a. været på at definere grænsefladerne mellem Journl platformen og den telemedicinske infrastruktur fra KvalitetsIT (Dette er beskrevet neden for i afsnittet ”Minimalistisk telemedicinsk infrastruktur til bløderprojektet”). Nedenunder vises afgrænsningen for Journls platform. Elementerne der ikke ligger indenfor afgrænsningen varetages af den telemedicinske infrastruktur leveret af KvalitetsIT. Målarkitekturen for Journls platform indeholder 3 brugerinterfaces:

1. Journl Citizen app: Den mobile cross platform app, der allerede nu findes i prototyper på iOS og Android

2. Journl Clinician browser: Webinterface til klinikeren 3. Journl Backoffice browser: Webinterface der i starten skal bruges af Journl selv ift.

administration af løsningen. Dette interface kan på sigt gøres tilgængelig for kunden ift. intern support og administration.

Bagved de 3 user interfaces ligger der en microservice arkitektur, der primært at udgjort af 3 Backends-for-frontends (BFF).


Side 3 af 19


Udenfor Journls platform er der identificeret en række komponenter, der skal udvikles til den telemedicinske infrastruktur. HL7/FHIR

FHIR standarden implementeres gennem HAPI (Health API) interfaces leveret i infrastrukturen. Enkelte FHIR ressourcer er implementeret i infrastrukturen allerede, men det forventes først fuldt implementeret i slutningen af projektet med mindre andet prioriteres fra Region Midtjyllands side. Audit logning

Det relevante niveau af auditlogning skal implementeres i Infrastrukturen, som Journl platformen kan benytte sig af. Dette er endnu ikke implementeret. Fejllogning

Det relevante niveau af fejllogning skal implementeres i Infrastrukturen, som Journl platformen kan benytte sig af. Dette er endnu ikke implementeret. Patientlogin

Patientlogin bliver en del af infrastrukturen. Login-komponenten er endnu ikke implementeret. De endelige data for implementering af komponenten fastlægges i 3.iterations planlægningsfase. Kliniker login

Klinikerlogin bliver en integreret del af infrastrukturen. Komponenten er ikke designet endnu, og der skal træffes en række strategiske beslutninger omkring komponenten. Det skal bl.a. afklares, om det er uhensigtsmæssigt at integrere login komponenten til region Midtjyllands Brugeradministration(BSK). Denne model vil ikke være sværere at skalere, når infrastrukturen skal implementeres i andre regioner og kommuner. Afklaringerne forventes i 3.iteration. Samtykke Samtykke vil være en integreret del af infrastrukturen, men er ikke endelig specificeret og godkendt af regionens ITafdeling. Dette arbejde vil foregå i 3.iteration. Opslag i CPR register (patient stamdata)

Der er identificeret et behov for at kunne lave opslag i CPR registeret gennem infrastrukturen. Komponenten er dog ikke specificeret endnu.

JOURNL


Side 4 af 19


Medicin lager/udlevering

Der er identificeret et behov for at kunne registrere udlevering af medicin til patienten. Det vil gøre det muligt at styrke medicinlogistikken og lagerstyringen af den dyre medicin helt ud til patientens hjem. Der har været løbende dialog med de to hospitalsapoteker omkring integration til Apovision. Beslutningen omkring at udsætte integrationen blev taget i 1.iteration, og derfor er der ikke foretaget yderligere ift. denne komponent. Komponenten vil ikke være en del af infrastrukturen. Repository

Repository til opbevaring og deling af data skal identificeres, og integrationen vil ske på bagsiden af FHIR HAPI interfaces og evt. relevante open source convertere. Det er indtil videre vurderingen fra Region Midtjylland, at der ikke findes et repository, der vil være relevant eller mulig at integrere til på den korte bane. Det undersøges dog løbende i projektperioden, om der opstår mulighed for integration.


Side 5 af 19


Arbejdsmøde 8/6-2017 Dato: 8/6-2017 Deltagere: Thomas Stigsen - Journl Eskild Mads Eskildsen - Journl Eva Troels - KvalitetsIT Peter Lundkvist - KvalitetsIT Lars Simesen – Region Midtjylland Dagsorden • Præsentation af arbejdet indtil nu (herunder målarkitektur) • Repository til opbevaring af data • Klargøring af infrastruktur til afprøvning i efteråret med rigtige paitentdata

Referat Udgangspunktet for mødet var en gennemgang af skitsen for målarkitekturen nedenunder.

Bilag 1 Følgende punkter blev gennemgået med henblik på at finde en konkret løsning til at løfte arkitekturopgaverne:

• IdP: Clinician og Patients • Concent (samtykke) • Implementering af FHIR (Mapning af ressourcer og teknisk implementering) • Gemme data (XDS repositories og CDA converter) • Patient Service

IdP Der er to relevante IdP’er for projektet (den for patienter og den for klinikerne). Det blev på mødet aftalt, at der arbejdes på en patient IdP, der er baseret på KvalitetsITs oplæg til ”Venlig Login". For patienten betyder det, at de skal logge ind med NemID første gang, de bruger Journl app’en. I den forbindelse opretter brugeren en pinkode, og der gemmes et token på devicet. Der vil også blive udviklet et webinterface til patienten, hvor denne kan logge ind med NemID og fjerne et device igen.

RM

Utility

Data

Security


Side 6 af 19


For klinikeren vil der på sigt blive udviklet en integration til regionens BSK, men indtil videre er det planlagt at fortsætte med den kliniker login komponent, der findes i prototypen for infrastrukturen. Det betyder, at klinikerne ikke vil kunne administrere deres eget kodeord.

Concent KvalitetsIT har et designudkast på en basal version af en samtykkeservice og interface. Det er dog usikkert, om designudkastet overholder Regionens ønsker og krav til den type service. Derfor indstilles der til, at samtykkehåndtering udskydes til efter 3.iteration. Afklaringer omkring en samtykke service kan dog med fordel indgå i 3.iteration.

FHIR KvalitetsIT har mulighed for at udstille de relevante FHIR ressourcer som webservices, og dermed gøre det nemt for Journl og andre leverandører at overholde HL7/FHIR standarden gennem HAPI interfaces. Den største udfordring bliver dog at kortlægge de relevante patientdata og kliniske data op mod FHIR/CDA standarden. Der kom på mødet flere forslag til, hvordan dette kunne gribes an. Det letteste er, at Journl i samarbejde med KvalitetsIT og potentielt Region Midtjylland kortlægger ressourcerne. Men det kunne også være relevant at inddrage MEDCOM og andre i dette arbejde. Det vurderes dog, at det ikke vil være muligt at nå projektets deadlines, hvis MEDCOM skal inddrages. Derfor arbejder Journl og KvalitetsIT videre med at kortlægge ressourcerne bedst muligt og vil inddrage regionen i dette arbejde. Sideløbende er der forventning om at inddrage relevante eksperter i Danmark med erfaring indenfor området. Der kan evt. også indledes en dialog med MEDCOM. Journl er indforstået med, at denne tilgang kan betyde, at der er behov for tilretning af kortlægningen over tid i takt med, at der er efterspørgsel efter data i andre systemer, eller konkurrerende systemer udvikles, hvor det er vigtigt, at data kan deles mellem dem.

Gemme data Målsætningen er at gemme kliniske data fra Journls platform og dermed bløderprojektet i et relevant XDS repository. Der er dog for nuværende ikke et relevant repository, der kan anvendes. Derfor leverer KvalitetsIT i deres infrastruktur et datalager til brug, indtil der er identificeret et XDS, og data kan flyttes til denne. Dette vil højest sandsynligt ske gennem allerede tilgængelige FHIR til CDA convertere, som implementeres i infrastrukturen.

Patient service Målarkitekturen indeholder en idé om en patientservice, der kan håndtere patienternes stamdata (f.eks. kontaktoplysninger) på tværs af løsninger. Den service vil dog først give værdi, hvis flere leverandører viser interesse for at implementerer servicen. Ideen er heller ikke modnet til et niveau, hvor den kan implementeres. Derfor vil patientservicen ikke indgå i infrastrukturen eller Journls platform i dette projekt. Parterne er dog villige til at stille op til sparring omkring emnet. Men Journl vil indtil videre opbevare kontaktoplysninger selv. (Infrastrukturen ift. projektet beskrives yderligere i næste afsnit).


Side 7 af 19


Minimalistisk telemedicinsk infrastruktur til bløderprojektet (Forfattet af KvalitetsIT: Version 1.0)

It løsning Formålet med en telesundhedsinfrastruktur (navnet arbejder vi på - det bliver ikke som nu. Ordene infrastruktur og telemedicin vil nok ikke indgå) er i første version (0.5), at få bløderprojektet og andre web/app baserede projekter hurtigere i reel drift. Det gøres ved at benytte reelt genbrugelige komponenter samlet i en infrastruktur baseret på principperne fra FUT (Fælles Udbud af Telemedicin). Infrastrukturen gør, at funktionalitet, der før skulle implementeres af flere telemedicinske projekter i hver deres løsning nu kun skal implementeres et sted.

Ovenstående tegning skitserer i den røde kasse den funktionalitet som bløderprojektet skal udvikle for at overholde krav og lovgivning. I stedet for at udvikle denne (ikke projektspecifikke) funktionalitet i bløder applikationen, lægges funktionaliteten i telesundhedsinfrastruktur. Det gør, at de mere generelle komponenter kun skal udvikles en gang og vedligeholdes et sted. De generelle komponenter kan udvikles af eksperter inden for eksempelvis sikkerhed, login eller samtykkehåndtering. Det vil gøre det hurtigere for bløderprojektet at komme i drift - med færre fejl.

Standardkomponenter til login, sikkerhed, dataadgang, test og installation vil være en del af den telemedicinske infrastruktur. Det vil kunne reducere tidslinjen fra et projekt sættes i gang, til det kommer i produktion, da en række af de generelle krav allerede er udviklet, testet og i produktion og de enkelte projekter derfor ikke behøver at forholde sig til det.


Side 8 af 19


Projektkontekst En telesundhedsinfrastruktur vil indgå i kontekst af andre projekter illustreret nedenfor:

FUT, PRO, SÅR (telemedicinsk sårvurdering) etc er regionale landsdelsprojekter/nationale projekter, der skal frembringe telesundhedsløsninger. Deres funktionalitet erstatter evt. relevante dele af telesundhedsinfrastrukturen. Derudover eksisterer regionale projekter som f.eks. bløderprojektet, der har konkrete behov for drift, sikker login, datadeling osv. Det kunne også være Fælles Service Center, der dog ikke er tegnet ind. På nationalt niveau er der bl.a. MaTIS projektet, i regi af MEDCOM med f.eks. KIH databasen og det er den nationale serviceplatform NSP.

Samarbejde Med en regional telesundhedssinfrastruktur etableres der et økosystem, der fordrer at flere parter bidrager. I forhold til bløderprojektet vi parterne være Journl, KvalitetsIT, 4S og evt. MedCom. På sigt vil dette felt blive naturligt udvidet både i forhold til leverandører af apps og bidragsydere til telesundhedsinfrastrukturen. Over tid vil komponenterne formodentlig blive erstattet af nye, mere generelle komponenter i forbindelse med andre indkøb og udbud, herunder FUT. Økosystemet vil forblive relevant. Desuden vil der kunne etableres et samarbejde med forskellige parter omkring profileringer/mapninger i forbindelse med fastlæggelse af standarder.

Drift Telesundhedsinfrastruktur vil kunne driftes hos Regionen eller hos en ekstern driftsleverandør. Der lægges op til at der vælges en ekstern driftsleverandør. Dette skyldes udelukkende hastigheden, hvormed miljøet kan sættes op. Valg placering drift placering er en naturlig forudsætning for at komme i gang med telesundhedsinfrastruktur.

Funktionalitet Helt overordnet laves følgende funktionalitet som en del af telesundhedsinfrastrukturen

● Sikker og skalerbar drift, hvor ny version af bløderapplikationen let og sikkert kan udrulles og driftes

● Login ○ Nem 2-faktor login eller lignende for medarbejder (der vil være en dialog der

fastlægger de specifikke krav) ○ Nem 2-faktor login for patienter

● Samtykke ○ Tilkendegivelse af samtykke ○ Tilbagekaldelse af adgang


Side 9 af 19


● Deling af data via XDS ● Simpel brugsrethåndtering ● Sikkerhedshåndtering og styring af adgang


Side 10 af 19


CE-mærkning I 2. iteration har der først og fremmest været arbejdet med en strategi for CE-mærkningen af produktet i projektet. Det er resulteret i et udkast til en Intended use og en 1. version af en risikoanalyse.

Møde 7/8-2017 Dato: 07/08-2017 Deltagere: Michael Jensen, Product Owner – Journl A/S Mette Munch, Konsulent – Addaction

Formål At påbegynde et samarbejde og initale tiltag for CE-mærkningsstrategien for Journls kerneprodukt med udgangspunkt i projektet - Beslutningsstøtte i bløderbehandling.

Forløb Til mødet præsenterede Michael Journls produktudviklingsaktiviteter i projektet og ud fra det diskuteredes og vurderedes intended use, software safety class og klassificering af produktet som medicinsk udstyr. Dette gennem en præsentation indeholdende en præsentation af virksomhed, bløderprojekt og forventet produkt outcome og herunder udkast til Intended Use og klassifering af software safety class jf. EN 62304, både generisk og specifik for bløderprojektet. Det blev vurderet grundet alvorsgraden ved eventuel fejl ved brug af systemet, at en alvorlig konsekvens hos patient, som bruger af system er mulig, hvorfor software safety class vurderes som Class C. Efterfølgende blev der diskuteret klassificeringsstrategi, omkostninger og vurdering, samt anbefaling af mest effektive Notified Bodies i Europa. Der er ingen anbefalede Notified Bodies i Danmark. I den forbindelse gøres der opmærksom på ny forordning, som er en stramning af beskrivelsen medicinske produkter indenfor software, som i 2020 vil høre inden for klasse IIA. Udgangspunktet er, at Journl sigter efter en klasse IA i dette projekt og efterfølgende en klasse IIA både i forhold den resterende platform, som skal bygges og den nye forordning i 2020. Herfra skal Journl udover at arbejde videre med dokumentering i den regulatoriske del i CE-mærkningsprocessen i form af bl.a. risikoanalyse og risikomanagement. Derudover også vurderes det tekniske dokumentations setup med bl.a. Quality Management System. I den forbindelse skal valg af både den teknisk dokumentation og valg af leverandører undersøges og vurderes videre.

Resultat

Intended Use udkast - til videre vurdering i projektets forløb “to provide easy access to information related to patient`s health conditions or treatment” “To help patients document, show or communicate medical conditions to health care providers”


Side 11 af 19


“provide patients with a simple tool to organize and track their health information and communicate medical conditions to health care providers” Software Safety Class: Class C – “Death or SERIOUS INJURY is possible”.

Opsætning for procedure og gennemføring af risikoklassificering og risikostyring Se 1. version af risikoanlyse nedenfor. Se dokument med generel RiskManagement_principle_1_draft (kan udleveres, hvis det ønskes).

Guidance for klassificering. Se bilag med generel 2_4_1_rev_9_classification_en_MEDDEV (kan udleveres, hvis det ønskes). Se bilag med generel Beslutning MD(kan udleveres, hvis det ønskes).

Forordning_SW_klassificering Ny forordning pr. 2020.

Bilag A4, forordning_SW_klassificering 1


Side 12 af 19


Risikoanalyse – 1 version Det giver først mening at lave en endelig risiko analyse, når det står klart præcist, hvad løsningen skal indeholde, og dermed hvad intended use er. Da dette er et OPI projekt, går en del af projektet ud på at definere løsningen for at sikre, at vi løfter behovene fra klinikere og patienter. Det er først i slutningen af 2.iteration og efter usability tests, at det er ved at falde på plads for alvor. Dette er derfor en 1. version af en risikoanalyse, og i 3. iteration vil den blive endelig fastlagt.

Risk team Function Name

CEO Eskild Eskildsen CTO Thomas Stigsen PO Michael Jensen Development Sofie Nielsen Development Lyng Salling QA/Clinical Mette Munch*

Risikoprocedure (Annex C)

Pos. Characteristics that could impact on safety (ISO 14971, Annex C)

Applic

able

Not

applic

able

Specify Reference

C.2.1 What is the intended use and how is the medical device to be used?

Intended use suggestions have been formulated.

Arbejdsmøde 2. iteration CE-mærkning Journl 130817

What is the essential performance of the medical device? (IEC 60601-1, ed. 3)

In progress. C. 2.1

C.2.2 Is the medical device intended to be implanted?

N/A Journl is not intended to be implanted

C.2.3 Is the medical device intended to be in contact with the patient or other persons?

N/A Not in contact as such - the device is standalone software.

C.2.4

What materials and/or components are incorporated in the medical device or are used with, or are in contact with the device?

N/A Standalone software.

C.2.5 Is energy delivered to and/or extracted from the patient?

N/A

The Journl software does not deliver and/or extract energy from the patient.

C.2.6 Are substances delivered to and/or extracted from the patient?

N/A No.


Side 13 af 19


C.2.7

Are biological materials processed by the medical device for subsequent re-use, transfusion or transplantation?

N/A No.

C.2.8

Is the medical device supplied sterile or intended to be sterilized by the user or are other microbiological controls applicable?

N/A No.

C.2.9

Is the medical device intended to be routinely cleaned and disinfected by the user?

N/A No.

C.2.10 Is the medical device intended to modify the patient environment?

N/A No.

C.2.11 Are there any measurement taken? N/A No - not directly.

C.2.12 Is the medical device interpretative?

A Waiting for audit.

C.2.13

Is the medical device intended for use in conjunction with medicines or other medical technologies?

N/A No - not directly.

C.2.14 Are there unwanted outputs of energy or substances?

N/A No.

C.2.15 Is the medical device susceptible (sensible) to environmental influences?

N/A No.

C.2.16 Does the medical device influence the environment?

N/A No.

C.2.17

Are there essential consumables or accessories associated with the medical device?

N/A No.

C.2.18 Is maintenance and/or calibration necessary on the medical device?

N/A No.

C.2.19 Does the medical device contain software? A It is software in itself.

C.2.20 Does the medical device have restricted shelf-life? N/A No.

C.2.21 Are there any delayed and/or long term effects?

N/A No delayed or long term effects

C.2.22 To what mechanical forces will the medical device be subjected?

N/A not subjected to any extraordinary mechanical forces


Side 14 af 19


C.2.23 What determines the lifetime of the medical device? N/A No.

C.2.24 Is the medical device intended for single use N/A No

C.2.25 Is safe decommissioning or disposal of the medical device necessary?

N/A No.

C.2.26

Does installation or use of the medical device require special training or special skills?

A

To be used by healthcare personal and patients - usability test needed.

C.2.27 How will information for safe use be provided?

A A user manual is provided.

C.2.28 Will new manufacturing processes need to be established or introduced?

N/A No new manufacturing processes as such.

C.2.29

Is the successful application of the medical device critically dependent on human factors such as the user interface?

A

Yes - user interface is essential. Instructions will be provided to secure proper use.

C.2.29.1 Can the user interface design features contribute to user error?

A

To be used by healthcare personal and patients - usability test needed.

C.2.29.2

Is the medical device used in an environment where distractions are commonplace?

N/A Yes - it is a possibility for both healthcare personal and patients.

C.2.29.3 Does the medical device have connecting parts or accessories?

A Integrations will be possible.

C.2.29.4 Does the medical device have a control interface?

A Software user interface.

C.2.29.5 Does the medical device display information?

A Yes

C.2.29.6 Is the medical device controlled by a menu? A Yes

C.2.29.7 Will the medical device be use by persons with special needs

N/A Not known? What is special needs?

C.2.29.8 Can the user interface be used to initiate user actions?

A Yes

C.2.30 Does the medical device use an alarm system?

N/A Notifications only.

C.2.31 In what way(s) might the medical device be deliberately misused?

A Manual input of wrong data.


Side 15 af 19


C.2.32 Does the medical device hold data critical to patient care? N/A Only an assisting tool.

C.2.33 Is the medical device intended to be mobile or portable?

A No.

C.2.34 Does the use of the medical device depend on essential performance?

N/A

The use of the Journl software is not life-sustaining, but possible.

C.2.35

Does the medical device incorporate, as an integral part a human blood derivative or tissues of animal origin?

N/A No.

C.2.36

Does the medical device contain phthalates which are classified as carcinogenic, mutagenic or toxic to reproduction?

N/A No.


Side 16 af 19


Risikoanlyse Current situation Risk Control Remarks

Haz

ard n

o.

Potential Hazard for the user or Hazardous situations during use

Potential harm for the user

Sev

erity

of H

azar

d (

S)

Iden

tify

the

cause

for

the

pote

ntial

haz

ards

or

haz

ardous

situ

atio

ns

Exi

stin

g M

itig

atio

n?

Spec

ify

Exi

stin

g M

itig

atio

n

Probab

ility

of

har

m (

P 1 +

P2)

Ris

k Acc

epta

bili

ty

Suggested Risk Control Measures

Person Responsible For Risk Control

Use this column to make additional notes to the analysis

Manufacture

Human

S1

Clinician chooses wrong patient for care plan

Patient adheres to wrong medical dosis in careplan - serius injury possible

Human error

?

?

100% In progress

In progress.

In progress.

S2

Patient registrate medicine, but does not comply.

Clinician gives advice/careplan adjustment based on wrong data.

Human error

?

?

100% In progress

In progress.

In progress.

S3

Patient takes medicine, but do not registrate via medical device.


Human error

?

?

100%

In progress In progress.

In progress.

S4

Patient registrate placement of bleeding incorrectly.


Human error

?

?

100% In progress

In progress.

In progress.

Clinician application

S5

Clinician chooses wrong patient for care plan

Patient adheres to wrong medical dosis in careplan - serious injury possible

UI/UX ?

?

100%


In progress.


Side 17 af 19


Current situation Risk Control Remarks

Haz

ard n

o.



Sev

erity

of H

azar

d (

S)

Iden

tify

the

cause

for

the

pote

ntial

haz

ards

or

haz

ardous

situ

atio

ns

Exi

stin

g M

itig

atio

n?

Spec

ify

Exi

stin

g M

itig

atio

n

Probab

ility

of

har

m (

P 1 +

P2)

Ris

k Acc

epta

bili

ty




Manufacture

S6

Patient registrate placement of bleeding incorrectly.


UI/UX ?

?

100%


In progress.

S7

Clinician application shuts down. Clinician unable to use application.

Patient might have a unupdated careplan.

System error

?

?

100% In progress

In progress.

In progress.

S8

A medicament can not be choosen for careplan.

Patient unable to registrate medicine correctly - in worst case unable to receive careplan.

System error or human error

?

?

100% In progress

In progress.

In progress.

Patient application

S9

Patient application shuts down. Patient can not use patient application.

Patient might not be reminded of when to take medicine, which can result in serious injury.

System error

?

?

100% In progress

In progress.

In progress.


Side 18 af 19



Haz

ard n

o.



Sev

erity

of H

azar

d (

S)

Iden

tify

the

cause

for

the

pote

ntial

haz

ards

or

haz

ardous

situ

atio

ns

Exi

stin

g M

itig

atio

n?

Spec

ify

Exi

stin

g M

itig

atio

n

Probab

ility

of

har

m (

P 1 +

P2)

Ris

k Acc

epta

bili

ty




Manufacture

S10

Patient application shuts down. Patient can not use patient application.

Patient can be empowered or adjust own treatment via patientdata, which can result in serious injury.

System error

?

?

100% In progress

In progress.

In progress.

S11 ?

?

100%


In progress.

S12 ?

?

100%


In progress.

Logic

S12

Clinician can not log in to Clinician application. Clinician can not monitor patient data.

Patientdata can not be communitated, which can result in serious injury.

System error

?

?

100%


In progress.

S13

Patient can not log in to Patient application. Clinician can not monitor new patient data.

Patientdata can not be communitated, which can result in serious injury.

System error

?

?

100%


In progress.

S14

Clinician adjust careplan Clinician application, but patient application does not comply.

Patient adheres to wrong medical dosis in careplan - serious injury possible

System error

?

?

100% In progress

In progress.

In progress.


Side 19 af 19



Haz

ard n

o.



Sev

erity

of H

azar

d (

S)

Iden

tify

the

cause

for

the

pote

ntial

haz

ards

or

haz

ardous

situ

atio

ns

Exi

stin

g M

itig

atio

n?

Spec

ify

Exi

stin

g M

itig

atio

n

Probab

ility

of

har

m (

P 1 +

P2)

Ris

k Acc

epta

bili

ty




Manufacture

S15

Delete function in patient application regarding patient registration(s) does not comply.


System error

?

?

100%


In progress.

bilag 4 - fase 4 - arkitektur - slutprodukter · eksperter i danmark med erfaring indenfor...

Documents