Open vahurmetsala opened 8 months ago
Lepime kokku loendi ja selle kasutamise. Praegu on kolm varianti: patsiendi sõnul, retsepti põhjal, arsti loodud. Ma näiteks leidsin pubkeskusest kogemata sellise loendi (panin IG-sse, et näidata või ajutiselt kasutada): https://build.fhir.org/ig/TEHIK-EE/FHIR-PoC/branches/ravimiskeem/CodeSystem-ravimi-andmete-tyyp.html
Loend "Ravimi andmete tüüp" (tehniline loend) on kasutusel amb. ja stats. epikriisil ravimi andmete sektsioonis. Kasutatakse, et eristada kas tegu on välja kirjutatud retseptiga või tervishoiutöötaja poolt patsiendile antud ravimiga.
Siis oleks mõneti loogiline, kui väärtused oleks samad, mis ravimiskeemis, sest tõenäoliselt nende süsteem seostaks ravimiskeemi lisatavaid ridu epikriisile märgitud andmetega?
@KristiinaKuldkepp kas siin on mingit uut infot? Kuidas me sellega võiks edasi minna? :)
Uut infot ei ole aga minu arust võiks seda loendit kasutada. Lisaksime sinna ühe koodi siis. Mingi hetk me arutasime seda koodi lisamist aga siis oli Rutt puudu ja jäi lahtiseks kuidas see term.serveris käiks. Tänaseks olen seal juba isegi mõne koodi teinud ja võibolla saaks ka hakkama. Ainult, et kas lisatav kood oleks siis XXX - TJTs loodud ravim ja PRE jääks retseptikeskusest genereerituks? Või PRE oleks TJTs genereeritud ja XXX retseptikeskusest? Kumb tundub loogilisem? @rlindstrm
Kas @vahurmetsala sul on mingit viidet dokumentatsioonile, et oleks vaja eristada retseptikeskusest retseptide põhjalt loodud ravimiskeemi ridu ja TJT-s otse loodud ridu? Või olen ma selle ise välja mõelnud, et elu keeruliseks teha? Sest MedicationStatementis on ju rida derivedFrom, mille kaudu saab info, et rida on tehtud retsepti põhjal (mitte vastupidi). Seega statementOriginCategory-sse pakutud loendit ei oleksgi vaja muuta, sest seda kasutaks ainult siis kui rida luuakse patisendi ütluse põhjal (ja see kood on seal juba olemas). Ja kui puudub derivedFrom ja statementOriginCategory on tühi, siis ongi TJT-s loodud tuttuus ravimiskeemi rida...
@KristiinaKuldkepp kahjuks pole asi nii lihtne... Kui me Ravimiskeemi kinnitame, tekitatakse MedicationStatement põhjal retseptid rets.keskusesse, ning nende viited pannakse derivedFrom atribuuti.. ehk et siis tekib olukord, kus me ei oska tavalisi ja retseptide põhjal genereeritud ridu eristada. Variant on muidugi ka minna seda teed, et me kasutame category ainult siis kui on patsiendi ütluse põhjal ja RK retseptide põhjal genereeritud ridadele ei tekita ID-d, vaid paneme identifier'i milleks oleks RK retsepti number koos RK system viitega. See oleks ka alternatiiv. Otsuse koht :)
@vahurmetsala kui nüüd on retsepti numbri ja RK system viitega rida ravimiskeemis ja seda soovib järgmine arst "pikendada" - kas siis tekib lisaks retseptinumbrile ka ravimiskeemi rea ID? Või tekib paralleelne (uus) rida? Või kirjutatakse algne rida üle? Mis saab pärast järgmist kinnitamist?
Hei, siin on diskussioon soiku jäänud - võtan teema uuesti üles :) Pikendamise puhul jääb MedicationStatement ID samaks, seda muudetakse ja uue versiooniga peaksid jääma seotuks uued retseptid
@vahurmetsala kontrollib arenduses üle, hetke lahendus on see, et statementOriginCategory on täidetud ainult siis kui on tegemist patsiendi sõnul ravimiga
Siin on hetkel olnud justkui kaks erinevat väärtust laual:
Simplifier-i teksti alusel: SEE KATEGOORIA DEFINEERIB ÄRA, KAS RAVIMISKEEMI RIDA ON LOODUD RETSEPTIKESKUSE RETSEPTI PEALT VÕI PATSIENDI SÕNUL.
Kas siin peaks olema ka alati välja toodud, kui tegemist on TJT-s loodud ravimiskeemi reaga ja eristama seda nendest, mis on Retseptikeskuse ridade puhul genereeritud? Või on siin mõte, et kõik mis ei ole patsiendi sõnul on alati PRESCRIPTION_CENTER("pc")?