150 dele, og hvad hver enkelt er til.

Booking og planlægning

Planlægningsmotoren under alt andet — kalendere, tilgængelighed, lokaler og de regler, der afgør, hvilke tider en klient reelt må se.

• En tilgængelighedsmotor, der omsætter ugentlige timer, daterede undtagelser og eksisterende bookinger til ledige tider
• Planlæggere, værter, lokationer og lokaler, med kapacitet og kollisionsregistrering
• Tidsregler, ventelister og automatiske tilbud om tider, når en booking frigives

Betalt mødebooking

Sælger enkeltsessioner som kreditter. Det er modulet, der gør køb og booking til to adskilte trin, hvilket gør det muligt at sælge en pakke i dag og planlægge den over flere måneder.

• Sessioner solgt som kreditter mod et produkt, enkeltvis eller som pakke
• Pakkeaftaler accepteret ved køb og bevaret i den version, der blev accepteret
• Trindelte afbestillingspolitikker med varselsvinduer, gebyrer og en kulanceperiode

Klinikplatform

Applikationslaget: behandlere og deres offentlige profiler, mobil-API’et, indhold og fællesskab, notifikationer og klientens egen konto.

• Ekspertprofiler med en verifikationsarbejdsgang, kvalifikationer, ydelser og kalendere
• Anmeldelser, vurderinger, offentlige spørgsmål og ekspertoversigten bag dem
• REST-endepunkter til mobilappen, JWT-autentificering og WebSocket-sessioner

Clinic

Klinikrapporter

De sytten ledelsesrapporter. Tolv spørger, om klinikkens journal svarer til det, der skete; fire sammenligner, hvordan behandlerne klarer sig; én ligger over dem alle.

• Afstemningslister: fastlåste sessioner, ubookede kreditter, dækning mod efterspørgsel, pengekæden, gebyrbogen
• Udbetalingsparathed, afbestillingsadfærd, compliance-mappe, klientkontinuitet og modereringskøen
• Sessioner uden rapport, og aflyste sessioner læst sammen med adfærd

Sessionsrapporter

Det kliniske notat, en behandler skriver efter en afholdt session — gemt som et sikkert dokument om klienten frem for som et bilag på et møde.

• En rapport skrevet mod sessionen og registreret som værende om klienten
• Krypteret i hvile på den sikre dokumenttjeneste, med en nøgle pr. version
• Adgang afgøres kun af plejeteamsopløsningen, aldrig af en rolle eller anciennitet

Medlemskaber

En fast ordning frem for et køb hver gang: en plan solgt i butikken og en klients medlemskab mod den.

• Planer er butiksprodukter med billede og beskrivelse; det offentlige katalog ligger på /memberships
• Et medlemskab bærer sessionskreditter, chatadgang og offline konsultationsminutter
• Kreditter forbliver almindelige sessionskreditter, så booking aldrig lærer et andet regelsæt

Målte chatkonsultationer

Ekspertens tid købt som minutter frem for som en aftale, brugt i chat og opgjort til minuttet.

• En ydelse kan sælge et budget af ekspertminutter, med et valgfrit gyldighedsvindue
• Takstkort på virksomheden, kan tilsidesættes pr. ydelse
• En bogføringspost pr. opkrævning og en opgørelse, både klienten og eksperten kan åbne

Indtagelsesskemaer

Spørgeskemaet, en klient udfylder før første session, gemt som klinisk indhold frem for som undersøgelsessvar.

• En ydelse navngiver det spørgeskema, der hører til den
• Klienten udfylder det før sessionen, fra sine egne sider
• Svar skrives direkte til et krypteret dokument — aldrig efterladt i undersøgelsens eget lager

Gennemgang af offlinebetaling

Bankoverførsel som betalingsrute, til klinikker der vil have en person til at se på hver ordre før og efter pengene flytter sig.

• Godkend ordren, fakturér den, modtag overførselsbeviset, godkend beviset, og udsted så kreditterne
• Kreditter fremkommer først, når beviset er godkendt, så en ubetalt ordre ikke kan booke en session
• En afvisning bærer sin begrundelse, og ordren går tilbage til den, der kan rette den

Offlinebetaling — klientsider

Klientvendt halvdel af offlineruten: hvor de betaler, hvad de uploader, og hvad ordren venter på.

• Hver tilstand har sin egen farve og mærkning på Mine ordrer, så ventende ser anderledes ud end afvist
• Betal og upload beviset i én dialog, uden at forlade ordren
• Afvisningsårsagen vises, hvor den, der skal handle på den, læser den

Regnskabsoversigt

Bøgerne, på et dashboard for sig: hvad der kom ind, hvad der skyldes, hvad leveringen kostede, og hvad der stadig kommer. Adskilt fra administratorens med vilje — at jagte en ubetalt faktura på gulvet er ét job, og at føre hovedbogen er et andet.

• En startside med fire pengefelter, seks sundhedsforhold, seks diagrammer og en markeringsliste
• Enogtyve rapporter: kontanter, omsætning, leveringsomkostning, prognose, lækage og to kontrollister
• Periodiseret eller kontant, fem perioder og et brugerdefineret interval, båret igennem hver gennemgang

Teamoversigter

Hvad der skal gøres, for de fire teams omkring klinikken. Salg, medarbejdere, markedsføring og levering får hver en side, og hver side åbner med det samme spørgsmål: hvad er forsinket, hvad er nu, hvad kommer, og hvad har ingen lovet at handle på.

• Fire dashboards, hver en post frem for kode, så en pakke kan tilføje et
• Aktivitetsbåndet på hver side: forsinket · i dag · planlagt · intet planlagt · kræver opmærksomhed
• „Intet planlagt“ er båndet, Odoo ikke har nogen tilstand for — en åben post, ingen har lovet at gøre noget ved, og som ikke vises på nogen anden skærm

Dashboards — CRM, Salg, Levering, Medarbejdere

Hvordan det går, i den app, ledere allerede åbner. Fire sider i Odoos egne Dashboards, i en egen sektion kaldet Klinikteams, bygget som dens Salgs- og Udgiftssider er bygget.

• Fire sider — CRM, Salg, Levering, Medarbejdere — ved siden af Odoos egne
• Fire KPI-felter pr. side, hver med den foregående periode ved siden af
• To diagrammer og to til fire top-N-tabeller pr. side, hver åbner posterne bag

Dashboards — Fremmøde, Fravær, Personaleudbetalinger

Tre sider mere i samme sektion, holdt adskilt, fordi hver kræver en app, klinikken måske ikke bruger.

• Fremmøde: aktuelt indtjekket, poster, arbejdstimer, ekstra timer, pr. medarbejder og pr. afdeling
• Fravær: anmodninger der afventer svar, godkendte dage, afslag, og hvor fravær falder pr. måned, type og afdeling
• Personaleudbetalinger: skal rapporteres, skal valideres, skal refunderes, og hvad der blev krævet i perioden

Supporthenvendelser

En offentlig formular, der gør et spørgsmål til en opgave, nogen ejer.

• En formular på /support/ticket, som alle kan bruge, logget ind eller ej
• Hver indsendelse åbner en opgave, tildelt butiksadministratoren
• Indsenderen følger sin egen henvendelse, og administratoren får besked i Discuss

Plejeforløb

Et plejeforløb med en start, en slutning og en plan — rygraden, alt andet i den kliniske journal hænger på. Pleje er ikke en strøm af aftaler, og journalen siger det.

• Et forløb åbnes ved den første afholdte session, og en klient har ét åbent ad gangen
• En behandlingsplan pr. forløb: problem → mål → delmål, tre niveauer og ikke flere
• Et mål bærer en titel, en måldato og et resultat — hvad der blev arbejdet hen imod, og hvordan det gik

Kliniske notater

Notatskabeloner som en ordnet liste af typede felter, så et notat er svar frem for prosa, ingen kan søge i.

• En skabelon er en versioneret, udgivet liste af typede felter — tekst, tal, skala, valg, dato
• Et udfyldt notat er svarene plus et gengivet sikkert dokument
• Svar kan læses præcis når deres dokument kan: én adgangsregel, ikke to der glider fra hinanden

Notatskabelonbibliotek

Startindholdet til skabelonmotoren: tusind navngivne notatformater, så en klinik ikke begynder med et tomt bibliotek.

• Over tusind navngivne skabeloner — SOAP, DAP, BIRP, indtagelse, gennemgang — grupperet efter fagområde
• Installeret som data, kan redigeres bagefter som enhver skabelon, klinikken selv skriver

Målopfølgning

Hvad en klient registrerer mellem sessionerne, knyttet til det mål, det måler. Et program, der rapporterer mod ingenting, er sådan opfølgning bliver til lektier.

• Et programbibliotek med seks elementtyper: spørgeskema, måling, valg, dagbog, upload, opgave
• Et program sendes til et mål, så hver registrering rapporterer mod noget, planen faktisk bad om
• Klienten registrerer på sin egen plan: det, der forfalder i dag, først, derefter hvert mål og hvad der er åbent mod det

Scorede spørgeskemaer

Klinikejede scorede instrumenter. Intet instrumentindhold leveres, og ingen licens påstås: klinikken indtaster det, den har ret til at bruge.

• En score gemmes med den instrumentversion, der frembragte den, og genberegnes aldrig
• Bånd og tærskler pr. instrument, hvor et risikobånd rejser et flag, nogen skal kvittere for
• Udfyldt af klienten på portalen eller i sessionen, og kanalen registreres uanset hvad

Gruppesessioner

Ét notat skrevet én gang og journalført hos hver deltager som deres eget dokument.

• Én forfattet kilde, ét journalført dokument pr. deltagende klient
• Et privat felt mangler i en anden deltagers dokument, det er ikke skjult inde i det
• Journalført hos dem, der deltog, ikke hos alle, der var booket

Genkaldelse og opfølgning

En forfaldsdato, en behandler sætter, når en session slutter, handlet på, når den ankommer.

• En genkaldelse er en dato og en årsag, oprettet ved sessionens afslutning
• Den inviterer; den booker aldrig
• Forfaldne genkaldelser vises i klinikoversigten, før nogen besked sendes automatisk

ICD-10-CM-kodning

Diagnosekoder, hvor faktureringen har brug for dem, søgbare frem for tastet fra hukommelsen.

• Søgbare ICD-10-CM-kapitler og -koder
• En kode registreret på klienten og ført videre til ordrer og fakturaer

Én formularbygger

Én spørgsmålsliste i produktet, og de tre ting, den ikke bærer selv: en stabil svarnøgle, synlighed pr. spørgsmål og et flag for det ene tal, der må forlade chifferteksten.

• Produktet var vokset til fire bygere — notatskabelonens typede felter, planlæggerens egne spørgsmål, opfølgningselementer og undersøgelsen bag indtagelsesskemaet
• Fire bygere er fire steder at tilføje en spørgsmålstype, fire gengivere og fire svar på „hvor blev svaret af“
• En spørgsmålsliste udformes i survey.survey og ingen andre steder

Bookingspørgsmål i undersøgelse

En plans spørgsmål udformet i Survey og journalført krypteret, så bookingplanlæggeren kan forblive en planlægger.

• En planlægger navngiver en undersøgelse, og den offentlige bookingside gengiver den med den ene gengiver
• Svar journalføres i et krypteret dokument mod bookingen
• Planlæggerens egen spørgsmålsmodel bliver, og skal: et telefonnummer, en reference, et samtykkekryds og dem, der skriver direkte på kontaktposten, hvor en receptionist skal læse dem

Bibliotek over psykologiformularer

Den scannede psykologiformularpakke som søgbare poster, med en valgfri levende formular, når en scanning er gjort til en.

• Den scannede pakke indlæst som poster med deres OCR-tekst, så en formular kan findes ud fra det, der står på den
• En taksonomi efter det system, hver formular er rettet mod
• En valgfri undersøgelse, oprettet når en scanning gøres til en levende formular

Ekspertbetaling

Sessionsvilkår på medarbejderkontrakten og den betalingscyklus, der afregner dem. Intet genberegnes ved udbetaling — hver session frøs sin egen fordeling, da den blev booket.

• Fire betalingstyper: månedsløn, timesats, fast honorar pr. session eller en procentdel af hver session
• Vilkår holdt på kontraktversionen, så historikken er dateret, og én er gældende ad gangen
• Betalingscyklusser — ugentlig, hver anden uge, månedlig eller kvartalsvis — forankret i kalenderen eller kontraktens start

Ekspertbetaling — e-signatur

Sender engagementskontrakter til underskrift fra den post, de hører til, og bevarer den underskrevne historik på den post.

• Send en kontrakt til underskrift fra selve kontrakten
• Hver anmodning bevaret mod den post som dens historik
• Sessionsbetaling kan tilbageholdes under en kontrakt, ingen endnu har underskrevet

Ekspertplaner

Selvstændige eksperter lejer platformen på en plan, vi bygger. Dette modul rummer planerne, abonnementerne og de regler, der siger, hvad et abonnements tilstand lader en ekspert gøre.

• Planer bærer en kanal — praksis, markedsplads eller begge — månedlige og årlige priser og takstlinjer skrevet som sætninger
• En plans funktionskontakter læses fra de installerede moduler frem for at blive tastet ind
• Et abonnement kopierer planens takster og funktioner, når eksperten underskriver, og læser dem aldrig tilbage, så en prisændring i morgen lader dagens abonnementer være

Ekspertattribuering

Hvem der bragte hver klient til hver ekspert — det ene faktum, hvert gebyr en selvstændig ekspert betaler afhænger af, og det, platformen ikke registrerede.

• Én række pr. ekspert-og-klient-par, med kilden og ejeren: ekspertens klient eller en platformsklient
• Ejerskab fastsættes ved første kontakt og ændres kun ved en overførsel fra personalet, med en begrundelse
• Ekspertens korte link, /e/: en person, der følger det, tilmelder sig og bliver den ekspertens klient

Ekspertopkrævning

Når eksperten tager klientens penge, skylder eksperten virksomheden dens andel. En månedlig kørsel, der fakturerer dem for det og følger det til betalt.

• Når eksperter godkender ordrer og sender betalingslinks, bærer tilbuddet, fakturaen og betalingssiden ekspertens eget firmanavn, adresse og moms som sælger
• Om eksperten opkrævede, fryses på sessionen ved booking, ved siden af andelsfordelingen, så en ændring af indstillingen i morgen ikke rækker tilbage i sidste måned
• Ingen ny formel: virksomhedens andel siger allerede, hvad virksomheden beholder, og hvis eksperten sidder med kontanterne, er det tallet, de skylder

Platformens funktionskatalog

Listen over, hvad de installerede moduler kan, erklæret af hvert modul selv, så planer kan slå funktioner til og fra.

• Ingen taster kataloget ind: et modul med noget, der er værd at sælge, leverer én funktionspost pr. kapacitet
• Odoo opretter disse poster, når modulet installeres, og sletter dem, når det afinstalleres, så kataloget altid beskriver, hvad denne database faktisk kan
• Ingen scanning, intet synkroniseringsjob og ingen anden liste ved siden af modullisten, der kan komme ud af takt med den

Sikre dokumenter

Selve tjenesten. En model tager den i brug på én linje og får sine dokumenter, en optælling og en journaliseringsdialog, der på klart sprog siger, hvem der kan åbne resultatet, før det gemmes.

• Krypteret i hvile med en nøgle for sig, gemt uden for Odoos filstore og aldrig serveret gennem /web/content
• Adgang efter eksplicitte regler, nægt som standard: en matchende tilladelsesregel og ingen matchende afvisningsregel, hver gang
• At være administrator, leder eller den, der journalførte det, giver ikke i sig selv noget

Sikre dokumenter: kryptering

Det kryptografiske lag, holdt som et modul for sig, så nøglehåndtering kan gennemgås og revideres uden at læse resten af applikationen.

• AES-256-GCM-konvolutkryptering: en tilfældig datanøgle pr. dokumentversion, pakket ind under en driftsnøgle
• Nøglekrypteringsnøglen gemmes aldrig i databasen
• Chiffertekst i en mappe for sig, uden for filstore

Sikre dokumenter: portal

Hvor en person læser de dokumenter, der er delt med dem om dem selv, på /my/documents — og kun dem.

• Et emne ser et dokument, når en emneadgangsregel giver det, og intet afviser det — aldrig blot fordi det handler om dem
• Psykoterapinotater, forseglede dokumenter og dokumenter under en gældende tilbageholdelsesbeslutning vises aldrig, uanset hvad deres regler siger
• Ét filter brugt af hver rute, så der kun nogensinde er én definition af, hvem der må se hvad

Sikre dokumenter: kontakter

Journalfører sikre dokumenter mod kontakter — det almindeligste emne, da den person, et dokument handler om, normalt er den, det journalføres mod.

• Tilføjer den sikre dokumenttjeneste til res.partner
• Installerer sig selv, når begge sider er til stede, og afinstalleres uden at røre nogen af dem
• En bro pr. applikation, så brug af tjenesten på en kontakt ikke trækker urelaterede apps med

Sikre dokumenter: CRM

Journalfører sikre dokumenter mod salgsmuligheder — en due diligence-pakke er ikke noget klinisk og har præcis de samme krav.

• Tilføjer den sikre dokumenttjeneste til crm.lead
• Krypteret, regelstyret og logget ved hver læsning, som ethvert andet sikkert dokument
• Installeres og afinstalleres rent og uafhængigt af de andre broer

Sikre dokumenter: medarbejdere

Journalfører sikre dokumenter mod medarbejderposter — en disciplinærsag eller en arbejdsmedicinsk rapport er noget, en leder journalfører, og de fleste i HR ikke må kunne åbne.

• Tilføjer den sikre dokumenttjeneste til hr.employee
• Nægt-som-standard-adgang, så en HR-rolle ikke åbner en sag i kraft af at være en HR-rolle
• Installeres og afinstalleres rent og uafhængigt af de andre broer

Sikre dokumenter: projekt

Journalfører sikre dokumenter mod opgaver — en fortrolig kontrakt eller en underskrevet leverance, opbevaret der, hvor arbejdet følges.

• Tilføjer den sikre dokumenttjeneste til project.task
• Installerer sig selv, når begge sider er til stede, og afinstalleres uden at røre nogen af dem

Sikre dokumenter: salg

Journalfører sikre dokumenter mod ordrer — en underskrevet aftale eller en kundes identitetsdokumenter, opbevaret mod det salg, de hører til.

• Tilføjer den sikre dokumenttjeneste til sale.order
• Installerer sig selv, når begge sider er til stede, og afinstalleres uden at røre nogen af dem

Fjernnøglemyndighed

Valgfrit: flyt nøglekrypteringsnøglen væk fra Odoo-værten, så en kopi af databasen ikke er en kopi af dokumenterne.

• Dokumentnøgler pakket ind og ud gennem en fjernmyndighed frem for lokalt
• Nøglekrypteringsnøglen ligger aldrig på den maskine, der betjener applikationen
• Slået til pr. udrulning; den lokale backend forbliver tilgængelig og uændret

Kliniske journaler

Afgør plejeteamet. En terapeut når journalerne for de personer, der er på vedkommendes egen sagsliste, ikke klinikkens — hvilket gør minimum-nødvendigt-princippet håndhævbart frem for ønsketænkning.

• Plejerelationer — behandler til klient, med en art, en start og en slutning
• Adgang ophører, når relationen gør, efter en kulanceperiode, der er lang nok til at afslutte udestående notater
• Kliniske roller, der afgør, hvilken del af applikationen nogen når, aldrig hvad de kan åbne

Kliniske journaler: Den Europæiske Union (GDPR)

GDPR-laget: det rettigheds- og styringsmaskineri, HIPAA ikke har noget tilsvarende til, hvilket er grunden til, at en US-standardopbygning ikke dækker EU.

• Retsgrundlag registreret pr. dokumenttype — art. 9, stk. 2, litra h, for behandlingsjournaler, ikke samtykke
• Sletning (art. 17) udført ved at ødelægge nøglen, så retten overholdes uden at slette beviset for, hvad der var opbevaret
• En sletningsvurdering, og intet ødelagt, så længe en juridisk tilbageholdelse eller opbevaringsperiode står

Kliniske journaler: kvittering for oplysning via e-signatur

En bro, ikke en opbygning — forbinder en underskrevet privatlivsmeddelelse med kvitteringsposten, så journalen kan svare på, hvilken version de faktisk så.

• En gennemført signatur skriver kvitteringen én gang — en webhook leveret to gange må ikke gøre optællingen af, hvem der mangler, forkert
• Signaturanmodningen navngiver meddelelsens version, fordi det er det eneste spørgsmål, en kvittering bliver stillet
• En kuglepen på en formular i receptionen er stadig en skriftlig kvittering; broen tilføjer en vej og erstatter ikke den almindelige

Kliniske journaler: Storbritannien

UK GDPR og Data Protection Act 2018 på samme tekniske kerne — med testen for alvorlig skade bygget som en arbejdsgang frem for som et flag.

• Testen for alvorlig skade (DPA 2018 Sch. 3 Pt. 2) registreret med hvem der besluttede, hvornår, over hvilke dokumenter og hvorfor
• Kan kun foretages af en, der har en gældende plejerelation, hvilket systemet kontrollerer frem for antager
• Vises i en gennemgangskø, før den udløber, og bortfalder af sig selv efter seks måneder

Kliniske journaler: Styring

De administrative sikkerhedsforanstaltninger — den halvdel af HIPAA, der ikke handler om kryptering, og den halvdel, håndhævelsen oftest citerer.

• Risikoanalysen som en øvelse med en periode, et omfang og en metode, adskilt fra registret over det, den fandt — så næste år kan sammenlignes med dette
• Hver risiko ført videre til næste vurdering med et link tilbage, for et register, der starter blankt hvert år, mister optegnelsen over, hvad der blev besluttet
• Den iboende vurdering beregnet og restvurderingen bevidst ikke — en restvurdering regnet ud ved at trække en kontrolscore fra er en fiktion, der siger det samme om en kontrol testet i sidste uge og en skrevet i en politik

Kliniske journaler: USA (HIPAA)

HIPAA-laget. Adskillelsen af psykoterapinotater holder i lageret frem for at hvile på, at adgangsreglerne er rigtige.

• Det udpegede journalsæt (45 CFR 164.501) markeret pr. dokumenttype, så et svar på indsigtsanmodning ikke kan omfatte det, der ligger uden for det
• Psykoterapinotater i deres eget nøglenavnerum — nøglen, der åbner den almindelige journal, åbner dem ikke
• En emnetildeling på notater afvist ad alle veje, også en direkte skrivning til regeltabellen

Kliniske journaler: Tyskland

Den tyske opbevaringsperiode, som en regel dokumenttjenesten tæller, frem for en linje i en politik, ingen anvender.

• § 630f BGB: ti år efter sidste kontakt, lagt ind som en opbevaringsregel
• Afgrænset til dette modul frem for til hele EU-pakken, fordi perioden er national

Klinik: Norge

De norske regler, GDPR-laget ikke dækker, hver især placeret, hvor handlingen sker, frem for i en politik: at offentliggøre en profil, at bekræfte en udbetalingskørsel, at videregive noget til en forælder.

• Pasientjournalforskriften § 14: patienten læser hver adgang til hver journal om vedkommende, også de journaler, vedkommende ikke får vist — efter type, aldrig efter titel
• En opbevaringsart helt uden bortskaffelsesdato, fordi Norge opbevarer journaler, så længe de er nødvendige; årene er et gennemgangsinterval, og en person afgør, med en begrundelse
• En journaloverdragelse til en efterfølger, Norsk helsearkiv eller Nasjonalarkivet, bygget i det øjeblik, den downloades, registreret som en videregivelse pr. dokument og kan downloades én gang

Klinik: Finland

De roller, finsk lov får en udbyder til at udpege, og de pligter, der hænger på hver. Uafhængig af den norske pakke — begge slås til ud fra virksomhedens land, så én database kan rumme begge.

• Autoriserede og titelbeskyttede professionelle holdt adskilt, fordi det er forskellige rettigheder: psykoterapeutti er en beskyttet titel i Finland og et frit ord i Norge
• Terhikki-nummer, datoen for arbejdsgiverens kontrol og om det var et registeropslag eller beslutningsdokumentet; et indtastet nummer tæller som erklæret, ikke kontrolleret
• En serviceenhed med sin egen registrering og vastuuhenkilö som udpegning pr. enhed, så en fjortendedag uden nogen, der svarer for den, bliver rapporteret

Klinik: Schweiz

Schweiz adskiller kvalifikationen fra tilladelsen til at praktisere, tæller forsikrede sessioner mod en læges ordination og binder leverandøren til den samme strafferetlige tavshedspligt som behandleren. Tre ting, kernen ikke kan udtrykke, og intet andet.

• Den føderale titel er ikke tilladelsen: en praksistilladelse er kantonal, én pr. kanton, hver med sin egen udløbsdato, så en behandler kan have navnet i Schweiz og retten til at arbejde ét sted
• En profil med en beskyttet titel nægtes offentliggørelse uden både et kontrolleret PsyReg-nummer og en gældende, kontrolleret kantonal tilladelse — og afvisningen siger, hvilken af de to der mangler
• Hvor en titel er kontrolleret og en tilladelse ikke er, siger den offentlige status det frem for at antyde en; et uverificeret marked tjenes ikke af en opførelse, der ligner en verificeret

Compliance-sundhedstjek

En fast liste af spørgsmål stillet til selve udrulningen. Det meste af kontrollen fandtes allerede og var spredt; dette er siden, der læser det ét sted.

• Et register over kontroller, en kører efter tidsplan og en rapport over begge
• Kun det, der er galt, rapporteres: en kontrol, der består, siger intet, så siden er tom, når udrulningen er sund
• Hvert fund navngiver den regel, det kom fra, og den post, det blev fundet på

E-sign — kerne

Selve signaturtjenesten: en portalsigneringsceremoni, jurisdiktionspolitikker og et hashkædet revisionsspor. Selvhostet, så intet dokument forlader ejendommen for at blive underskrevet.

• En portalsigneringsceremoni med identitet og hensigt registreret i det øjeblik, der underskrives
• Et hashkædet revisionsspor, ingen kan redigere eller slette
• Jurisdiktionspolitikker, der styrer, hvad en gyldig signatur kræver

E-sign — kontrakter

Hvem der var bemyndiget til at underskrive for en modpart, og om deres legitimation stadig er gyldig — kontrolleret frem for antaget.

• Bemyndigelse til at forpligte sporet pr. modpartsunderskriver
• Underskrevne aftaler opbevaret som poster med en løbetid
• Behandlerlegitimationer rykket for, før de udløber

E-sign — sundhed

Hvad en klinisk signatur kræver ud over et navn: handleevne, bemyndigelse til at underskrive på nogens vegne, supervision og samtykke, der kan trækkes tilbage.

• Erklæring om handleevne registreret i det øjeblik, der underskrives
• Underskrift på en klients vegne, med bemyndigelsen registreret
• Supervisors medunderskrift, hvor ydelsen kræver det

E-sign — sundhed (USA)

De elementer, HIPAA kræver af en tilladelse, valideret frem for overladt til en skabelon.

• Validering af de krævede elementer i en HIPAA-tilladelse
• 42 CFR Part 2-materiale adskilt fra resten
• Redegørelsen for videregivelser, en omfattet enhed skal fremlægge på anmodning

E-sign — HR

En handling Anmod om signatur på ansøgere og medarbejdere, så et tilbud eller en politik underskrives, hvor personen allerede er.

• Anmod om signatur på en ansøgerpost
• Anmod om signatur på en medarbejderpost
• Anmodninger bevaret mod posten som dens historik

E-sign — Salg

En handling Anmod om signatur på tilbud og indkøbsordrer.

• Anmod om signatur på en salgsordre
• Anmod om signatur på en indkøbsordre
• Det underskrevne dokument opbevaret mod ordren

E-sign-aftaler

Placerer signaturskabeloner, hvor klinikken sælger: knyttet til en behandler eller en ydelse, sendt automatisk ved køb og synlige som en status.

• E-sign-skabeloner knyttet til en ekspert eller en ydelse
• Sendt ved køb, uden at nogen skal huske at sende det
• Underskrevet status vist til behandlere i portalen og i mobilappen

Sikre sessioner

Afslutter en session, ingen bruger. 45 CFR 164.312(a)(2)(iii) beder om afslutning efter en forudbestemt periode med inaktivitet og overlader perioden til dig — så det er en indstilling, med håndhævelsen på serveren frem for i browseren.

• Inaktivitetsperiode, advarselsperiode og et absolut loft, indstillet pr. virksomhed
• Kontrolleret på serveren ved hver autentificeret forespørgsel, så det intet giver at slå browsertimeren fra
• En advarsel, før sessionen slutter, så ingen mister et halvskrevet notat til en kontrol, der er ment til at beskytte dem

AI-bro

Forbinder Odoo Community til enhver stor sprogmodel, bag en grænseflade — så leverandøren kan skiftes uden at forretningslogikken ved det.

• Udbydere konfigureret pr. udrulning, med legitimationen holdt uden for applikationskoden
• Agenter defineret som prompts med de værktøjer, de må kalde
• Værktøjskald, så en model kan handle frem for kun at svare

Brugerudvidelse

At konvertere en bruger mellem intern og portal i hånden betyder at redigere adgangsrettigheder i den rigtige rækkefølge og huske bivirkningerne. Det gør det til en knap.

• Et felt Brugertype på brugerformularen, i listen og i søgefiltrene
• Knapperne Konvertér til intern og Konvertér til portal på brugerformularen
• En handling Konvertér brugertype i brugerlisten, til flere brugere ad gangen

Det offentlige sites skal

Header, footer og loginsiden i ét layout, opkaldt efter virksomheden i denne database.

• Ét layout til headeren, footeren og loginsiden
• Det viste navn er virksomheden i denne database, ikke en værdi tastet ind i en skabelon
• Logoadresse og en tilpasset copyright-linje er systemparametre, som også kan redigeres under Indstillinger → Website → Offentligt brand

Aftaler — kerne

Aftalen, dens parter, dens strukturerede vilkår med oprindelse, dens versioner og en arbejdsgang af konfigurerbare trin knyttet til fem faste faser.

• Aftaler med parter, strukturerede vilkår og vilkårenes oprindelse
• Versioner, så „hvad stod der i marts?“ bliver ved med at kunne besvares
• Konfigurerbare trin knyttet til fem faste faser

Aftaler — forhandling

Bygget så gennemgangen rettes mod det, der er ændret, og det, der afviger, og aldrig mod uændret standardtekst — hvilket er der, aftalesystemer normalt opgives.

• Et klausulbibliotek knyttet til strukturerede vilkår, så accept af en reserveløsning sætter det vilkår, den bærer
• Playbooks, runder, emner og registrerede afvigelser
• Møder som forhandlingsrunder i egen ret, der bevarer begrundelsen og positionerne

Aftaler — godkendelser

Godkendelse afgjort på mere end én akse. At behandle det som anciennitet alene er den almindelige designfejl: en standard-NDA uanset værdi kræver ingen senior.

• Godkendelse efter værdi, afvigelse, aftaletype og risiko
• Afvigelse som en akse i egen ret frem for en modifikator på værdi
• Godkendelse ved en stedfortræder registreres altid som sådan — „på vegne af“ er et andet faktum

Aftaler — tillæg

Registrerer, hvad et tillæg ændrede, ikke blot at det findes.

• Udførelse af et tillæg lukker de vilkårsrækker, det ændrer, og åbner nye på ikrafttrædelsesdatoen
• Alt afledt af et ændret vilkår genberegnes, og bevægelsen vises før udførelsen
• Modstridende tillæg opdaget ved udførelsen

Aftaler — forpligtelser og datoer

Underskriften er begyndelsen på forpligtelsen, ikke slutningen af en arbejdsgang. Dette bærer det, der sker bagefter.

• Forpligtelser i begge retninger, med dokumentation, hvor dokumentation kræves
• Afledte datoer beregnet ud fra vilkår frem for tastet ind, og flyttet, når deres drivende vilkår flyttes
• En eskalationsstige, der ikke bygger på at minde den, der allerede ikke har handlet

Aftaler — projekter, tid og omkostning

To omkostninger, holdt adskilt: hvad en aftale kostede at vinde, og hvad den koster at levere. At kombinere dem giver et tal, der ikke besvarer nogen af spørgsmålene.

• Forhandlingsindsats registreret som overhead, uanset om aftalen bliver underskrevet
• Leveringsomkostning inddrevet mod aftalens værdi
• Aftaler knyttet til projekter mange-til-mange med en rolle, fordi ét projektfelt går i stykker ved den første rammeaftale

Aftaler — fakturerbar tid og honorargrundlag

Hvad en time er værd, hvad honoraret tillader, og de fire tal, der kræver begge.

• Takster, et fakturerbart flag og en faktureret tilstand på registreret tid
• Honorargrundlag angivet på aftalen
• Inddrivelse — faktureret mod værdien af registreret tid

Aftaler — modpartsportal

Den fjerde udvekslingskanal: modparten læser den aktuelle version her, kommenterer og uploader sine rettelser som en indgående runde.

• Modparten åbner den aktuelle version, kommenterer den og returnerer sine rettelser
• Rettelser ankommer som en indgående runde med filen vedhæftet, ikke som en e-mail, nogen skal huske at journalføre
• Intet internt er synligt — ikke positioner, afvigelser, godkendelser, playbooken eller interne notater

Aftaler — e-signaturbro

Hvordan en aftale bruger signaturtjenesten. Gennemførelse er hændelsen, der sætter alt andet i gang.

• Godkendelser skal være fuldstændige, før en version kan sendes
• Underskriverens bemyndigelse til at forpligte kontrolleret mod deres legitimation
• Versionen låst, når den sendes ud, så enhver senere påstand om, hvad der blev underskrevet, kan bevises

Aftaler — bro til sikker opbevaring

At kryptere hver aftale gør systemet ubrugeligt; at kryptere ingen gør det usikkert. Så fortrolighed er et niveau på aftalen.

• Kun aftaler markeret som sikre sender deres dokumenter ind i den sikre dokumenttjeneste
• Kryptering pr. version under en nøgle holdt uden for databasen
• Nægt-som-standard-adgang, og hver læsning logget, før indhold returneres

Aftaler — rapporter

Flaglister, der bør være tomme, og de ledelsesvisninger, der er værd at diskutere.

• En flagliste rummer kun det, der er ude af trit — en tom liste er det gode resultat
• Et flag, hvis model ikke er installeret, rapporterer som ikke relevant frem for at fejle
• Ubegrænset ansvar vist som en liste, aldrig som et tal lagt ind i en sum

Juridiske rapporter — klienter, jurister og ledelse

Tre læsere, én aritmetik. De samme tal beregnet én gang og gengivet på tre måder, frem for at blive udledt igen pr. skærm, hvor de ville glide fra hinanden.

• Én fristvisning: afledte aftaledatoer, forpligtelser i begge retninger, handlinger aftalt på møder og leveringsfrister
• Projektstyring: omsætning, arbejdskraft, bundne omkostninger, margin og estimatafvigelse, som en lagret visning, så den kan grupperes
• En klientvendt visning af, hvor langt arbejdet er nået, og hvad der skyldes

Aftaler — IP-regler

To regler, og kun to — dem, der sammenligner poster og derfor ikke kan udtrykkes som konfiguration.

• En underlicens' territorium skal ligge inden for dens overordnedes
• To eksklusive licenser må ikke overlappe
• Holdt adskilt fra IP-pakken, så en virksomhed kan installere aftaletyperne uden kontrollerne

Aftaler — juridiske regler

Interessekonfliktkontrol ved aftalemodtagelse, på samme måde som ved sagsåbning. Den spærrer trinovergangen; den advarer ikke.

• En modpart kontrolleret mod eksisterende klienter, modparter i verserende sager og kendte tilknyttede enheder
• Spærrer trinovergangen frem for at give en advarsel, der kan afvises
• Selve kontrollen uforanderlig, når den er registreret — hvem der kørte den, over hvilket omfang, og hvad de fandt

Aftaler — generel pakke

Startpakken. Installér kernen og denne, og en virksomhed kan køre aftaler fra dag ét uden at konfigurere noget.

• NDA’er, rammeaftaler, arbejdsbeskrivelser, tjenester, rådgivning, levering og indkøb
• De vilkår, hver type bærer, og den arbejdsgang, den bevæger sig igennem
• Porte, der forhindrer en aftale i at nå underskrift halvfærdig

Aftaler — HR-pakke

Ansættelse, kontrahentengagement, rådgivning og forlig.

• Aftaletyper, vilkårstyper, klausulbibliotek og playbook til ansættelsesaftaler
• Forpligtelsesskabeloner for opsigelse, prøvetid og vilkår efter fratræden
• Forlig er sikre som standard — hvert ord tæller, og en tilsynsmyndighed spørger senere til dem

Aftaler — juridisk pakke

Advokatfirmaer — aftaler for klienter og med dem — og interne juridiske afdelinger. Det samme system tjener begge opgaver med skarpt forskellige standarder.

• Engagementsbreve, retainere og instruktioner til rådgivere
• Et klausulbibliotek med den regulerede ordlyd markeret som obligatorisk
• Et firmas engagementsbrev er som standard fortroligt og specificeret

Aftaler — IP-pakke

Licensgivere, patent- og varemærkeindehavere, teknologioverførselskontorer, universiteter og brandejere.

• Licenser, overdragelser og optioner som aftaletyper, med licensvilkårstyper
• Klausulbibliotek, playbook og forpligtelsesskabeloner
• Intet aktivregister, bevidst — et patents sagshistorik hører til porteføljesystemet, der allerede rummer den

Aftaler — ejendomspakke

Lejeaftaler, aftaler om leje, brugsrettigheder, salg, servitutter og de skøder, der hænger på en leje.

• Opsigelsesdatoer som datadrivende vilkår, fordi en opsigelsesret udløber i stilhed
• Varselsvinduet som en forpligtelse afledt af opsigelsesdatoen, og begge eskalerer
• Vilkår om huslejeregulering, fællesudgifter og istandsættelse

Aftaler — finanspakke

Gældsdokumenter: kreditaftaler, garantier, sikkerhed, mellemkreditor- og efterstillelsesaftaler.

• Finansielle covenants som strukturerede vilkår, med afledte testdatoer
• Overholdelsescertifikatet som en forpligtelse, hvor dokumentation kræves
• „Hvilke faciliteter testes dette kvartal, og på hvilke tal?“ bliver et spørgsmål med et svar

Aftaler — byggepakke

Hovedentrepriser, underentrepriser, rådgiverudpegninger, sikkerhedsgarantier og de dokumenter, der omgiver dem.

• Bygget omkring kæden: en hovedentreprise lover en dato, kun underentreprenørerne kan levere
• Back-to-back-vilkår holdt som strukturerede vilkår, så de kan sammenlignes ned gennem kæden
• Ansvar, som underentreprenørerne og erhvervsansvarsforsikringen skal bære

Aftaler — databeskyttelsespakke

Databehandleraftaler, business associate-aftaler og underdatabehandlervilkår.

• DPA-, BAA- og underdatabehandleraftaletyper med de vilkår, de bærer
• Vinduet for anmeldelse af brud som et vilkår for sig, fordi det måles i timer
• Revisionssvar og underdatabehandlermeddelelse som afledte datoer

Log ind og tilmeld

At komme ind i appen, og aldersporten, der afgør, om en konto overhovedet må bruges.

• Splash og routing ved første kørsel, så en vendt tilbage bruger lander, hvor de slap
• Registrering og login mod gatewayen, med tokens i sikker lagring
• Nulstilling af adgangskode via e-mail

Identitets- og aldersverifikation

Kontrollen, der lader nogen handle, herunder de tilstande, en person befinder sig i, mens et menneske gennemgår det, det automatiske trin ikke kunne afgøre.

• Guidet introduktion, der forklarer, hvad der spørges om, og hvorfor
• Ansigtsscanning og dokumentkontrol som alternativ vej
• Grænsetilfælde og under-gennemgang-tilstande, så personen aldrig efterlades i uvished

Hjem — indholdsfeed

Den første fane. Et rangeret feed af artikler, videoer og opdateringer, plus de udgivere bag dem.

• Et rangeret indholdsfeed leveret af gatewayen
• Indholdsvisning med billeder og rig tekst
• Udgiverprofiler, så en læser kan følge en kilde

Opdagelse og vurderinger

Selvguidede værktøjer: vurderinger, en person selv tager, deres resultater og de partnerfunktioner, der er bygget omkring dem.

• Tag en vurdering, og læs resultaterne
• Glædeskortet — en personlig visning og en delt
• Tilføj, tilslut, invitér og sammenlign partnere

At finde en behandler

Kataloget, som en klient møder det: at gennemse, sammenligne, gemme, spørge og den chat, der følger.

• Gennemse og filtrér kataloget over behandlere
• En profil med kvalifikationer, sprog, ydelser og anmeldelser
• Gemte behandlere — Mine eksperter

Ydelser

Hvad der faktisk kan bookes, med prisen, varigheden og om det er online eller på stedet.

• Gennemse ydelser udbudt på tværs af klinikken
• Ydelsesvisning med pris, varighed og leveringsform
• Direkte til booking eller køb fra ydelsen

Butik og kasse

At købe — en enkelt session, en pakke eller et produkt. Det er her, den kredit kommer fra, en klient senere bruger.

• Produktkatalog og produktvisning
• Kurv, kasse og den serviceaftale, der accepteres ved køb
• Ordrebekræftelse og ordrehistorikken bag den

At booke en session

At bruge en kredit på et bestemt tidspunkt i en bestemt kalender — og alt, klienten ser om det bagefter.

• Opret en booking mod reel tilgængelighed, i klientens egen tidszone
• Bookinglisten, med hver status en session kan have
• Bookingvisning: deltagelseslink, sted og lokale, ombooking og aflysning

Spørgsmål, henvendelser og partnere

At spørge offentligt, at spørge privat og de personer, en klient vælger at dele fremskridt med.

• Et offentligt spørgsmålsfeed og at stille et spørgsmål, før man forpligter sig til noget
• Spørgsmålsvisning med behandlerens eget svar
• Supporthenvendelser — opret en, følg den, læs svarene

Profil — klientens hub

Den tredje fane og svaret på de fleste supportspørgsmål. Alt, appen ved om personen, på én skærm.

• Bookede møder og mødehistorik, med feedback og sessionsanmeldelser
• Kreditter, købte sessioner og favoritter
• Faktureringsadresse, fakturaer, fakturavisning, betalingsmetoder

Profil — ekspertens praksis

Den samme fane, set af en behandler. Det er det, der gør en hel praksis mulig at køre fra en telefon frem for fra et skrivebord.

• Tilgængelighed: ugentlige timer og daterede undtagelser i skemaet
• Klienters chats og klienthistorikken bag hver samtale
• Indsend en sessionsrapport fra den session, den hører til

AI-assistent

En samtaleassistent i appen, streamet gennem gatewayen, så ingen modellegitimation nogensinde når enheden.

• En chatskærm med streamede svar
• Samtalehistorik, så en tråd kan genoptages senere
• Routet gennem gatewayens AI-grænseflade, der løser til en rigtig udbyder eller en mock

Indstillinger, privatliv og juridisk

De kontroller, en person forventer at finde, herunder dem, en tilsynsmyndighed forventer, at de kan finde.

• Appindstillinger og sprogvalg på tværs af 23 sprogversioner
• Privatlivsindstillinger, og hvilke notifikationer der ankommer på hvilken kanal
• Sikkerhedsindstillinger, herunder enhedssessioner

Appkerne

Det, hver funktion ovenfor er bygget på. Ikke en skærm, men grunden til at skærmene opfører sig ensartet.

• Netværk mod gatewayen, med tokenfornyelse og fejlhåndtering ét sted
• Sikker lagring af tokens og sikker enhedstilstand
• Routing, så en notifikation kan åbne præcis den skærm, den henviser til

Identitet og konto

Mæglet login mod forretningskernen og udsteder kortlivede tokens af sin egen. Appen holder aldrig en kernelegitimation.

• Log ind, tilmeld, forny og log ud, med JWT udstedt af gatewayen
• Den aktuelle bruger og deres profil
• Enhedsregistrering, så pushnotifikationer når den rigtige telefon

Katalog og udbud

Alt, en klient gennemser, før de bruger noget, serveret hurtigt og cachet, hvor det er dyrt.

• Behandlere, deres profiler, tilgængelighed og ydelser
• Ydelseskategorier og bookbare produkter
• Anmeldelser og vurderinger, med modereringstilstand respekteret

Booking og penge

Den transaktionelle halvdel. Køb, kredit, booking, faktura og betaling, hver afbildet på forretningskernen frem for genimplementeret.

• Opret, ombook og aflys en booking, med politikken anvendt af kernen
• Ordrer og de kreditter, de frembringer
• Fakturaer og fakturadokumenter

Indhold og fællesskab

Den læsetunge halvdel: det, en person gennemser, når de ikke booker.

• Det rangerede indholdsfeed og indholdsvisning
• Offentlige spørgsmål og svar
• Opdagelse, vurderinger og deres resultater

Beskeder og realtid

WebSocket-hubben. Chat, tilstedeværelse, AI-streaming og signalering til tale og video, på én forbindelse.

• Håndtering af WebSocket-forbindelser og tilstedeværelse
• Chat mellem klient og behandler, og gruppekanaler
• Signalering til tale- og videoopkald

Dokumenter og medier

Filer, holdt så appen aldrig taler direkte med lageret, og intet serveres fra en gættelig URL.

• Adgang til sikre dokumenter, der respekterer kernens adgangsregler frem for at afgøre dem igen
• Medieupload og -hentning, proxyet gennem gatewayen
• Billeder skaleret og cachet, så en kataloglisting er billig på en telefon

Support, konfiguration og AI

Resten: at oprette en henvendelse, at bede om en konsultation, at fortælle appen, hvad denne udrulning har slået til, og at tale med en model.

• Supporthenvendelser og deres svar
• Konsultationsanmodninger
• Runtime-konfiguration, så appen kun viser de funktioner, denne virksomhed har aktiveret

Udbydergrænseflader (mock først)

Fire funktionsflag, der hver løser til en rigtig udbyder eller en mock. Det er grunden til, at ejendommen kan demonstreres, udvikles og testes uden nogen ekstern konto.

• DATA_SOURCE — Odoo-forretningskernen eller et mock-datasæt
• PAYMENTS — en rigtig udbyder eller en mock, der opfører sig som en
• NOTIFICATIONS — Firebase Cloud Messaging eller en mock