Brukes til å registrere en forespørsel om en helserelatert tjeneste eller aktivitet som skal utføres av en kliniker, organisasjon eller virksomhet.
Arketypen er designer som et rammeverk som kan brukes som grunnlag for:
- En forespørsel om en helserelatert tjeneste, fra en kliniker eller organisasjon til en annen kliniker eller organisasjon. For eksempel: En henvisning til en spesialist for behandling eller second opinion, ansvarsoverføring til akuttmottaket, monitorering av vitale tegn hver 4. time, eller hjemmesykepleie fra kommunen.
- En forespørsel om oppfølging fra samme kliniker eller organisasjon, for eksempel kontroll på poliklinikk om 6 uker.
Kliniske brukseksempler:
- Dersom en kliniker setter opp en kontrolltime om 6 uker: "Tjenestenavn" settes til "Kontroll". Dersom klinikeren skriver inn "6 uker" som tid for kontrolltime i brukergrensesnittet, vil det kliniske systemet registrere datoen 6 uker etter registreringsdatoen i elementet "Dato/tid forfall".
- Dersom en kliniker setter opp en pasient til "undervisning om diabetes" i "Tjenestenavn". Verdiene for "Årsak for forespørsel" kan være "Ny diagnose" og "Forebygging av ketoacidose". "Klinisk indikasjon" kan være "Diabetes type 1", som kan lenkes til en Problem/diagnose og/eller et Laboratorieprøveresultat. Dersom det er nødvendig med et kurs på 4 uker, med 4 ukentlige undervisningsøkter, må en bruke arketypene CLUSTER.service_direction og CLUSTER.timing_nondaily for å registrere kompleks timinginformasjon.
- Dersom en kliniker ordinerer en gjentagende blodprøve, som for eksempel INR: Den komplekse timingen for dette krever bruk av arketypene CLUSTER.service_direction og CLUSTER.timing_nondaily for å definere hver timing i en sekvens, for eksempel "daglig i en uke, ukentlig i 4 uker, månedlig i 6 måneder".
En grunnleggende antagelse for denne arketypen er at den er en forespørsel for én enkelt helsetjeneste. Dersom man trenger en gjentagende tjeneste, kan dette spesifiseres ved å bruke arketypen CLUSTER.service_direction i SLOTet "Kompleks timing".
I mange situasjoner vil det være mulig å registrere stegene som gjennomgås i utførelsen av forespørselen ved hjelp av den generiske arketypen ACTION.service. Imidlertid vil det være mange tilfeller der det vil være behov for en spesifikk ACTION-arketype, for å kunne oppfylle behov om spesifikke dataelementer, registreringsmønstre eller prosesstrinn. Eksempler på dette er ACTION.screening og ACTION.health_education.
Organisasjon: Ocean Informatics, United Kingdom
E-post: ian.mcnicoll@oceaninformatics.com
Opprinnelig skrevet dato: 2009-12-08
Organisasjon: Ocean Informatics, United Kingdom
E-post: ian.mcnicoll@oceaninformatics.com
Opprinnelig skrevet dato: 2009-12-08
- Licence: This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/.
- Custodian Organisation: Nasjonal IKT
- References: Avgrenet fra: Helsetjenesteforespørsel, Publisert arketype [Internet]. Nasjonal IKT, Nasjonal IKT Clinical Knowledge Manager [sitert: 2018-06-27]. Hentet fra: https://arketyper.no/ckm/#showArchetype_1078.36.153
- Current Contact: Heather Leslie, Atomica Informatics
- Original Namespace: no.nasjonalikt
- Original Publisher: Nasjonal IKT
- Custodian Namespace: no.nasjonalikt
- MD5-CAM-1.0.1: 662517860A4CD65197A7E737FD63FA2E
- Build Uid: e85cf2a6-6988-4ac7-bd03-f8551e1a087f
- Revision: 1.0.2
Koding av tjenestenavnet med et kodeverk er ønskelig, dersom tilgjengelig. For eksempel: "henvisning" til en endokrinolog for diabetesoppfølging.
Koding av tjenestetypen med et kodeverk er ønskelig, dersom tilgjengelig. Dersom "Tjenestenavn" er kodet kan dette elementet i noen tilfeller utledes fra koden. For eksempel klinisk biokjemi eller mikrobiologisk laboratorium, ultralyd eller CT.
Dette dataelementet kan brukes til å beskrive den aktuelle tjenesten i mer detalj, for eksempel hvordan den skal utføres, pasientens egne ønsker, eller problemer man kan støte på under utførelsen.
Koding av forespørselsårsaken med et kodeverk er ønskelig, dersom tilgjengelig. Dette dataelementet tillater flere forekomster, for å gjøre det mulig for brukeren å registrere flere svar om nødvendig. For eksempel "følge opp diabeteskomplikasjoner".
For eksempel "Pasientens diabetes har i det siste blitt vanskeligere å stabilisere, og nyrefunksjonen er under forverring".
For eksempel "angina" eller "diabetes mellitus type 1". Koding av indikasjonen med et kodeverk er ønskelig, dersom tilgjengelig. Dette dataelementet tillater flere forekomster.
For eksempel kan en henvisning til en spesialist ha som hensikt at spesialisten tar over oppfølgingsansvaret for pasienten, eller det kan være å få en second opinion for behandlingsmuligheteter. Koding av hensikten med et kodeverk er ønskelig, dersom tilgjengelig. Dette dataelementet tillater flere forekomster, for å gjøre det mulig for brukeren å registrere flere svar om nødvendig.
Spesifikke definisjoner av "akutt" og "haster" vil variere mellom kliniske settinger, kliniske systemer, og forespørselens natur, og de er derfor ikke definert i arketypen. Dersom det er nødvendig å bruke eksplisitt timing, bør "Tjenesteintervall" oppgis.
Mulige datatyper:
Kodet tekst- Akutt [Forespørselen krever øyeblikkelig oppmerksomhet.]
- Haster [Forespørselen krever prioritert oppmerksomhet.]
- Rutine [Forespørslene krever ikke prioritert oppmerksomhet.]
Fri eller kodet tekst
Dette dataelementet tillater registrering av timing for én tjeneste, enten som dato/tid, intervall av dato/tid, eller som en tekstbeskrivelsen som kan understøtte "neste tilgjengelige". I praksis vil klinikere ofte tenke i omtrentlig timing, for eksempel "revurdering om 3 måneder, 6 måneder eller 12 måneder. Siden kliniske systemer trenger mer eksakte tidsangivelser, vil "3 måneder" som regel konverteres til en eksakt dato 3 måneder fra registreringsdatoen, og lagres i dette dataelementet. Dersom det er behov for kompleks timing eller sekvenser av timing, bruk arketypen CLUSTER.service_direction i SLOTet "Kompleks timing". I disse tilfellene blir dette dataelementet redundant.
Mulige datatyper:
Dato/Klokkeslett
Intervall av dato/klokkeslett
- Fri eller kodet tekst
For eksempel "vitale observasjoner hver time i 4 timer, deretter hver 4. time i 20 timer", eller "hver tredje onsdag, totalt 3 ganger".
Inkluder:
openEHR-EHR-CLUSTER.service_
Denne dato/tiden representerer den tidligste datoen/tiden tjenesten kan utføres på. For eksempel må noen ganger en viss tid løpe før en tjeneste kan utføres, f.eks. ved noen prosedyrer er en avhengig av at pasienten har seponert legemidler i en periode før prosedyren.
Denne dato/tiden representerer den seneste datoen/tiden tjenesten kan utføres på. For eksempel i noen tilfeller må en tjeneste være utført før en annen hendelse, f.eks. planlagt kirurgi.
Registreres som SANN for å eksplisitt registrere at forespørselen ikke har noen utløpstid. For eksempel kan dette elementet brukes når det sendes henvisning til en spesialist for langvarig eller livslang oppfølging.
Tillatte verdier: {true}
Eksempel: Detaljer om prøvemateriale for en forespørsel om laboratorieanalyse, eller anatomisk lokalisering for en forespørsel om en prosedyre.
Inkluder:
Alle ikke eksplisitt ekskluderte arketyper
Inkluder:
openEHR-EHR-CLUSTER.multimedia.v1 og spesialiseringer
Registrer som SANN dersom ytterligere informasjon er identifisert, og vil bli ettersendt når den er tilgjengelig. For eksempel: ufullstendige prøvesvar.
Tillatte verdier: {true}
Inkluder:
Alle ikke eksplisitt ekskluderte arketyper
Som regel tilsvarende HL7 Placer Order Identifier.
Mulige datatyper:
- Fri eller kodet tekst
Identifikator
Inkluder:
Alle ikke eksplisitt ekskluderte arketyper
Som regel tilsvarende HL7 Filler Order Identifier.
Mulige datatyper:
- Fri eller kodet tekst
- Identifikator
Inkluder:
Alle ikke eksplisitt ekskluderte arketyper
Status brukes for å vise om dette er den primære forespørselen, en endring eller supplerende informasjon. Koding med en terminologi foretrekkes, der det er mulig.
Inkluder:
openEHR-EHR-CLUSTER.distribution.v1
For eksempel lokale informasjonsbehov eller ytterligere metadata for å kunne tilpasse til tilsvarende konsepter i FHIR eller CIMI.
Inkluder:
Alle ikke eksplisitt ekskluderte arketyper
Tomas Alme, DIPS ASA, Norway
Vebjørn Arntzen, Oslo University Hospital, Norway
Koray Atalag, University of Auckland, New Zealand
Silje Ljosland Bakke, Nasjonal IKT HF, Norway (openEHR Editor)
Lars Bitsch-Larsen, Haukeland University hospital, Norway
Anita Bjørnnes, Helse Bergen, Norway
Lisbeth Dahlhaug, Helse Midt - Norge IT, Norway
Einar Fosse, UNN HF, Norwegian Centre for Integrated Care and Telemedicine, Norway
Hildegard Franke, freshEHR Clinical Informatics Ltd., United Kingdom
Heather Grain, Llewelyn Grain Informatics, Australia
Knut Harboe, Stavanger Universitetssjukehus, Norway
Sam Heard, Ocean Informatics, Australia
Ingrid Heitmann, Oslo universitetssykehus HF, Norway
Andreas Hering, Helse Bergen HF, Haukeland universitetssjukehus, Norway
Anca Heyd, DIPS ASA, Norway
Hilde Hollås, DIPS AS, Norway
Evelyn Hovenga, EJSH Consulting, Australia
Lars Ivar Mehlum, Helse Bergen HF, Norway
Lars Morgan Karlsen, DIPS ASA, Norway
Shinji Kobayashi, Kyoto University, Japan
Heather Leslie, Atomica Informatics, Australia (openEHR Editor)
Hallvard Lærum, Direktoratet for e-helse, Norway
Rose Mari Eikås, Helse Bergen, Norway
Ole Martin Sand, DIPS ASA, Norway
Hildegard McNicoll, freshEHR Clinical Informatics Ltd., United Kingdom
Ian McNicoll, freshEHR Clinical Informatics, United Kingdom (openEHR Editor)
Bjørn Næss, DIPS ASA, Norway
Andrej Orel, Marand d.o.o., Slovenia
Anne Pauline Anderssen, Helse Nord RHF, Norway
Pablo Pazos, CaboLabs.com Health Informatics, Uruguay
Rune Pedersen, Universitetssykehuset i Nord Norge, Norway
Jussara Rotzsch, Hospital Alemão Oswaldo Cruz, Brazil
Line Silsand, Universitetssykehuset i Nord-Norge, Norway
Norwegian Review Summary, Nasjonal IKT HF, Norway
Line Sæle, Nasjonal IKT HF, Norway
Nyree Taylor, Ocean Informatics, Australia
John Tore Valand, Haukeland Universitetssjukehus, Norway (Nasjonal IKT redaktør)
Richard Townley-O'Neill, Australian Digital Health Agency, Australia
Gro-Hilde Ulriksen, Norwegian center for ehealthresearch, Norway