Teorinis pagrindas EUDAMED domeno modeliavimui

Entities, part II.

Tikslas

Šiame dokumente išdėstomas teorinis pagrindas EUDAMED domeno modeliavimui. Jame pateikiamas nuoseklus būdas nustatyti, ar objektas yra reali esybė, MDR sąvoka, ar duomenų bazės įrašas, ir kaip šie trys dalykai susiję. Taip siekiama, kad duomenų modelis būtų grindžiamas aiškiomis skirtimis, o ne painiava, kylančia, kai tas pats objektas laikomas ir sąvoka, ir realia esybe.

Kontekstas

Šis požiūris remiasi trimis esamų darbų kryptimis.

Pamatinė ontologija konceptualiam modeliavimui. UFO (Guizzardi 2005) ir jos kalba OntoUML atskiria individus nuo tipų, kuriuos jie įkūnija, taip pat atskiria rigid tipus (Kind, kuriuo daiktas negali nustoti būti) nuo rolių, kurias daiktas atlieka ir gali nustoti atlikti (Role). DOLCE „Descriptions and Situations“ (Masolo et al. 2004) rolę traktuoja kaip sąvoką, apibrėžtą aprašo ir atskiriamą nuo daiktų, kurie pagal ją klasifikuojami. BFO informacinio artefakto darbas (Smith ir Ceusters 2015) atskiria įrašą nuo daikto, apie kurį jis yra. Kartu tai suteikia tris čia naudojamas rūšis: realią esybę, rolę ir įrašą, taip pat principą, kad jų negalima sulieti.

Kaip reglamentas kuria esybes. Searle (1995) skiria brute faktus nuo institucinių faktų, kurie kuriami taisykle „X counts as Y in context C“. Tai mechanizmas, kuriuo įmonė tampa gamintoju. Eriksson, Johannesson ir Bergholtz (2018) šią idėją pritaiko informacinėms sistemoms: registras ne tik aprašo iš anksto egzistuojančią realybę, bet ir iš dalies ją sukuria, nes sistemos išduodamas identifikatorius yra sistemos sukurtas faktas.

Reglamento ir jo sistemos santykis. Governatori ir Sadiq (2009) compliance apibrėžia kaip santykį tarp dviejų atskirų specifikacijų – proceso ir normos. Taigi sistema yra viena šio santykio pusė, bet ne pati norma. Breaux ir Antón (2008) parodo, kad didelės dalies reglamento programinė įranga negali interpretuoti ir kad tam reikia žmogaus sprendimo. Hildebrandt (2011) pažymi, kad sistema, kuri neleidžia atsirasti neatitikčiai, pakeitė normą, o ne užtikrino jos laikymąsi. MDR 33 straipsnis su tuo dera: EUDAMED skiriamas vaidmuo įgalinti laikytis prievolių ir padėti institucijoms, o ne vykdyti reglamentą.

Pagrindinė mintis

Paimkime „gamintoją“. Jis pasirodo trijose skirtingose vietose, tačiau tai nėra tas pats dalykas:

• Realybėje: ACME Ltd, reali įmonė.
• MDR: „Manufacturer“, teisės aktu apibrėžta rolė.
• EUDAMED: aktoriaus įrašas su SRN.

Tai trys atskiri dalykai: įmonė, teisinė rolė ir duomenų bazės įrašas. Laikant juos vienu dalyku ir kyla didelė dalis modelio painiavos. Juos modeliuoti reiškia aprašyti, kaip šie trys dalykai yra susiję.

Kiekvienas iš jų priklauso savo sričiai, todėl „egzistuoti“ kiekvienoje iš jų reiškia skirtingą dalyką:

Ši skirtis remiasi UFO (Unified Foundational Ontology, Guizzardi 2005), bendra teorija apie tai, kokių rūšių objektai egzistuoja, sukurta siekiant suteikti konceptualiems modeliams griežtą pagrindą. Jos terminais reali esybė yra Substantial (esybė, kuri egzistuoja savarankiškai ir turi tapatybę), o MDR rolė yra Role, kurią esybė atlieka. Šiame dokumente vietoj šių specializuotų terminų vartojami paprastesni terminai „reali esybė“ ir „rolė“.

Kaip šie trys jungiasi

Juos sieja trys paprasti santykiai:

• Reali esybė atlieka MDR rolę. ACME yra gamintojas; ligoninė yra investigation site. Rolę apibrėžia MDR, o įmonė ar ligoninė egzistuoja nepriklausomai nuo šios rolės.
• EUDAMED įrašas yra apie realią esybę. SRN įrašas yra apie ACME. Įrašas nėra įmonė ir turi savo gyvavimo ciklą (sukurtas, pakeistas, uždarytas), kurio įmonė neturi.
• EUDAMED įrašas atitinka MDR rolę. Aktoriaus forma „Manufacturer“ rolę paverčia laukais ir apribojimais.

Rolė nėra reprezentacija

Du iš šių dalykų dažnai abu vadinami „reprezentacija“, tačiau jie skiriasi:

• Rolę atlieka esybė. Ligoninė yra investigation site.
• Reprezentacija atstoja kitą esybę. Įrašas nurodo į ligoninę.

„Investigation site“ yra rolė. „Aktoriaus įrašas“ yra reprezentacija. Šiuos terminus verta laikyti atskirai.

Ar visada reikia visų trijų

Modelio tinkamumas priklauso nuo jo paskirties. Todėl mažesnis modelis taip pat gali būti tinkamas:

• Jei modeliuoji tik realybę, išvardini įmones, ligonines ir prietaisus, o MDR rolių pavadinimus palieki. Tai teisinga, jei tave domina realybė.
• Jei modeliuoji tik roles, išvardini gamintoją, importuotoją ir site, o įmones palieki. Tai taip pat teisinga, tačiau reikia išlaikyti ryšį, kuris kiekvienai rolei suteikia prasmę: site visada yra kažkokio tyrimo site.

Visų trijų viename modelyje reikia tada, kai teiginys apima kelias sritis. „Šis įrašas yra apie tą ligoninę“ reikalauja, kad ir įrašas, ir ligoninė būtų tame pačiame modelyje, kitaip tokio ryšio negalima pavaizduoti. EUDAMED klausimai dažnai apima kelias sritis: ar šis įrašas atitinka realią įmonę, ar jis atitinka teisingą rolę, ar galime jį atsekti. Todėl EUDAMED reikia vieno modelio.

Vienas modelis nebūtinai reiškia vieną diagramą. Gali būti atskiras vaizdas kiekvienai sričiai, jei ta pati įmonė išlaiko tą pačią tapatybę visuose vaizduose. Ta pati tapatybė, atskiri vaizdai – gerai. Atskiri modeliai, kurie niekada nesusiejami, neleidžia pavaizduoti ryšių tarp sričių.

Ar reali esybė yra modelyje

EUDAMED formoms, laukams, rolėms ir būsenoms realios esybės kaip atskiros esybės nereikia, ir EUDAMED taip sukurta sąmoningai. Jos vienetas yra Actor, kuris yra rolė, identifikuojama SRN. Reali įmonė pasirodo tik kaip aktoriaus įrašo atributai (pavadinimas, adresas), o ne kaip atskira esybė, jungianti kelias tos pačios įmonės roles. Tai yra dizaino sprendimas, o ne trūkumas: EUDAMED nėra įmonių registras. Autoritetinga juridinio asmens tapatybė yra nacionaliniuose registruose, į kuriuos EUDAMED nurodo, o ne pati ją valdo.

Šis pasirinkimas turi kainą. Kai kurie klausimai apima kelis aktorius, todėl EUDAMED negali į juos atsakyti remdamasi vien savo duomenimis:

• Ta pati įmonė, kelios rolės. Manufacturer ir importer kaip viena įmonė yra du aktoriai su dviem SRN, nesusieti tarpusavyje.
• Dublikatai. Viena įmonė, užregistruota du kartus, yra du aktoriai. Pavadinti tai dublikatu reiškia lyginti pavadinimą ir adresą, o ne remtis bendru įmonės esybės modeliu.
• Skaičiavimas. Klausimas „kiek gamintojų?“ reiškia aktorių skaičių, o ne įmonių skaičių, todėl šie skaičiai gali skirtis.

Taigi tai yra apimties sprendimas, nustatytas pagal tikslą. Rolėmis grindžiamam sekimui aktorius kaip vienetas yra tinkamas dizainas, o reali įmonė gali likti už sistemos ribų ir būti pasiekiama per išorinę tapatybę. Kryžminei tapatybei („viskas, ką daro įmonė ACME“) reikėtų pridėti realią įmonę kaip bendrą esybę, su kuria būtų susiejamos rolės. EUDAMED pasirinko pirmąjį kelią sąmoningai.

Pirmos klasės esybė, atributas ar visai nėra

Sprendimas, kas EUDAMED sistemoje tampa pirmos klasės esybe (t. y. turi savo įrašą ir identifikatorių), yra modeliavimo sprendimas, o ne tiesioginė MDR interpretacija. EUDAMED turi daug tokių esybių: Actor, Device, CI/PS, Notified Body, Certificate ir kitų. Tačiau ne viskas iš MDR tampa pirmos klasės esybe: kai kurie dalykai yra kitos esybės atributai, o kai kurie sistemoje visai neatvaizduojami. Ribinius atvejus verta įvardyti:

• Reali įmonė. Ji egzistuoja tik kaip Actor įrašo atributai (pavadinimas, adresas), o ne kaip pirmos klasės bendra esybė (žr. aukščiau).
• Investigation site. Jis egzistuoja tik kaip CI/PS įrašo atributas, o ne kaip pirmos klasės aktorius su savo identifikatoriumi.
• Distributor. Jo nėra. Tai reguliuojama rolė (economic operator, 2 str. 35 d.) be SRN, todėl EUDAMED ji visai neatvaizduojama (31 str.).
• SRN. Tai atvirkštinis atvejis: pirmos klasės EUDAMED objektas, kurio reikalauja MDR (31 str.), bet realybėje jis neturi atitikmens. EUDAMED sukuria faktą, o ne jį užrašo.

Esmė: viena MDR rolė EUDAMED sistemoje gali būti atvaizduojama kaip pirmos klasės esybė, atributas arba visai neatvaizduojama. Kurį variantą pasirinkti yra modeliavimo sprendimas, priimamas sąmoningai, o ne faktas, tiesiogiai paveldimas iš reglamento.

MDR rolė be EUDAMED įrašo parodo, kad EUDAMED nėra MDR kopija. Site ir distributor yra du tokie atvejai.

Modeliavimo gairės

1. Pirma nuspręsk, ką modeliuoji ir kodėl. Subjektas gali būti realus pasaulis, MDR rolės, EUDAMED įrašai arba ryšiai tarp jų. Tikslas (suprasti reglamentą, kurti sistemą ar ją operuoti) nustato, kurios trys rūšys patenka į apimtį, o kurios lieka už jos ribų. Šį sprendimą reikia priimti prieš pradedant modeliuoti.
2. Laikyk tris dalykus atskirus, net jei jie yra viename įraše. Aktoriaus įraše yra rolė (aktoriaus tipas), įmonės atributai (pavadinimas, adresas) ir pats įrašas. Tai gerai, kol aiškiai žinai, kas yra kuris laukas, ir nelaikai jų vienu dalyku.
3. Rolė nėra ją atliekančios esybės potipis. Nedaryk „Manufacturer“ įmonės potipiu. Ar įmonė yra sava esybė, ar, kaip EUDAMED atveju, tik Actor atributai, rolė vis tiek yra tai, ką esybė atlieka, o ne įmonės rūšis.
4. Įrašas nėra tai, į ką jis nurodo. „Is about“ reikėtų modeliuoti kaip ryšį, o ne kaip tapatumą. Šių dviejų dalykų supainiojimas yra viena iš pagrindinių registro duomenų modeliavimo klaidų priežasčių.

Pavyzdys

Manufacturer / ACME Ltd:

• MDR turi rolę Manufacturer (2 str. 30 d.).
• Realybėje yra ACME Ltd – įmonė, gaminanti ir tiekianti prietaisą į rinką.
• EUDAMED turi aktoriaus įrašą + SRN, kuris yra apie ACME ir atitinka Manufacturer rolę.

Trys dalykai, trys ryšiai.

EUDAMED įgalina, bet nevykdo

EUDAMED nevykdo reglamento. MDR to pats neteigia: 33 straipsnio 1 dalis sako, kad EUDAMED sukurta „to enable“ gamintojus ir kitus operatorius „to comply with their obligations“ ir „to enable the competent authorities … to carry out their tasks“. Teisinis sistemos tikslas yra įgalinti ir palaikyti, o ne vykdyti reglamentą. Tą patį pabrėžia ir compliance literatūra: compliance yra santykis tarp sistemos ir normos, o ne pati norma (Governatori ir Sadiq 2009). Praktiškai EUDAMED sukuria vienus faktus (SRN, SIN, Basic UDI-DI), užrašo kitus, riboja tai, ką galima įvesti, ir parodo kai kuriuos pažeidimus institucijai. Tik paskutinis veiksmas yra artimas vykdymui, tačiau jį atlieka institucija, o ne duomenų bazė.

Už EUDAMED ribų (hipotezė)

Dauguma informacinių sistemų veikia tam tikroje realaus pasaulio srityje, kurią paprastai reguliuoja įstatymai. Todėl tos pačios trys rūšys turėtų būti taikomos plačiau, ne tik EUDAMED: realus pasaulis, jį reguliuojanti teisė ir sistemos įrašai.

Mokesčių sistema turi mokesčių mokėtojus, mokesčių įstatymus, deklaracijas ir mokesčių ID. Įmonių registras turi įmones, įmonių teisę ir registracijos numerius. Nekilnojamojo turto registras turi sklypus ir pastatus, nuosavybės teisę ir registro įrašus.

Kiekvienu atveju identifikatorius, kurį išduoda sistema (mokesčių ID, įmonės numeris, SRN), yra sistemos sukurtas, o ne rastas realiame pasaulyje. Be to, šios trys rūšys nesutampa viena su kita vienas prie vieno. Jei tai galioja, čia aprašytas požiūris nėra specifinis EUDAMED, o bendras būdas modeliuoti bet kurią sistemą, veikiančią reguliuojamoje srityje.

Literatūra

• Breaux, T. D. & Antón, A. I. (2008). Analyzing Regulatory Rules for Privacy and Security Requirements. IEEE Transactions on Software Engineering, 34(1), 5–20.
• Eriksson, O., Johannesson, P. & Bergholtz, M. (2018). Institutional ontology for conceptual modeling. Journal of Information Technology, 33(2), 105–123.
• Governatori, G. & Sadiq, S. (2009). The journey to business process compliance. In Handbook of Research on Business Process Modeling (pp. 426–454). IGI Global.
• Guizzardi, G. (2005). Ontological Foundations for Structural Conceptual Models. Daktaro disertacija, University of Twente, Enschede. Telematica Instituut Fundamental Research Series No. 015.
• Hildebrandt, M. (2011). Legal Protection by Design: Objections and Refutations. Legisprudence, 5(2), 223–248.
• Masolo, C., Vieu, L., Bottazzi, E., Catenacci, C., Ferrario, R., Gangemi, A. & Guarino, N. (2004). Social Roles and their Descriptions. In Proceedings of KR 2004 (pp. 267–277). AAAI Press.
• Reglamentas (ES) 2017/745 (Medicinos priemonių reglamentas), 33 straipsnis. OL L 117, 2017 05 05.
• Searle, J. R. (1995). The Construction of Social Reality. The Free Press, New York.
• Smith, B. & Ceusters, W. (2015). Aboutness: Towards Foundations for the Information Artifact Ontology. In Proceedings of ICBO 2015, CEUR-WS Vol. 1515, 1–5.