Navngivning

[rockphotog]

Forslag fra flere: Profiler som er en del av nasjonale profiler bør ikke hete noe med "helse-api", da de også kan benyttes til andre regimer, som messagning, documents.

[kennethmyhra]

@rockphotog Starter straks på profileringen av patient og practitioner, navngivningen vil være essensiell å få avklart på forhånd pga. av canonical url.

[rockphotog]

@thomiz @oaassv @HL7Norway/utviklere-basisprofiler Forslag? no-core? no-rway? no-std? no-..? Hvis ikke bruker vi no-helseapi-, selv om dette kan brukes til annet enn (Helse)API.

[thomiz]

Det finnes mange muligheter:
hl7.no/fhir/StructureDefinition/no-core-api
hl7.no/fhir/StructureDefinition/no-argo
hl7.no/fhir/StructureDefinition/helseapi
hl7.no/fhir/StructureDefinition/(no-)core-query
hl7.no/fhir/StructureDefinition/no-core

Slik jeg ser det:
Det vi skal navngi er beskrivelse av en metode å hente kjerneinformasjon om pasient/behandling/observasjoner som er viktig for pasientbehandlingen. Spesifikasjonen vi lager er knyttet til API og baserer seg på REST metoder for å hente informasjon. Spesifikasjonen bygger på no-basis som KAN sees på som felles informasjonsmodell. Spesifikasjonen bygger videre på denne ved å angi nødvendige krav som er nødvendige å oppfylle for å utveksle/hente informasjonen på en effektiv måte over et REST API.

Slik sett ER spesifikasjonen faktisk knyttet til teknologien og må antakelig skrives om hvis vi skal distribuere informasjonen pr. meldinger eller et radikalt nytt regime. Det kan hende vi ønsker å lage en helse-melding spesifikasjon etterhvert, i de tilfeller vi ønsker å kjøre informasjon over et annet paradigme. Strengt tatt burde vi kalle informasjonsmodellene noe generelt og API spesifikasjonen noe spesielt (for eksempel helseapi). Men da innfører vi ett nytt lag i profileringsregimet vårt strengt tatt.

1. Ressurs fra HL7 internasjonal
2. no-basis ressurs
3. no-core ressurs (informasjonsmodell, ikke teknologiavhengig)
4. helseapi spesifikasjon (knyttet til API), helsemelding spesifikasjon (knyttet til meldingsutveksling)
5. prosjektspesifikk implementert spesifikasjon

Siden vi uansett skal knytte dette til API transaksjoner kan vi godt kalle det helseapi for min del.

[oaassv]

Hei, Nivå 3 er generiske gjenbrukbare strukturer utover basisprofilene, men hvor går da skillet mellom 4 og 5? Er det hvordan vi knytter de generiske profilene på nivå 3 til API, men uten at dette er en prosjektspesifikk implementering? På mandag 23. september 2019, 22:16:12 CEST skrev Thomas Tveit Rosenlund <notifications@github.com> følgende: Det finnes mange muligheter: hl7.no/fhir/StructureDefinition/no-core-api hl7.no/fhir/StructureDefinition/no-argo hl7.no/fhir/StructureDefinition/helseapi hl7.no/fhir/StructureDefinition/(no-)core-query hl7.no/fhir/StructureDefinition/no-core Slik jeg ser det: Det vi skal navngi er beskrivelse av en metode å hente kjerneinformasjon om pasient/behandling/observasjoner som er viktig for pasientbehandlingen. Spesifikasjonen vi lager er knyttet til API og baserer seg på REST metoder for å hente informasjon. Spesifikasjonen bygger på no-basis som KAN sees på som felles informasjonsmodell. Spesifikasjonen bygger videre på denne ved å angi nødvendige krav som er nødvendige å oppfylle for å utveksle/hente informasjonen på en effektiv måte over et REST API. Slik sett ER spesifikasjonen faktisk knyttet til teknologien og må antakelig skrives om hvis vi skal distribuere informasjonen pr. meldinger eller et radikalt nytt regime. Det kan hende vi ønsker å lage en helse-melding spesifikasjon etterhvert, i de tilfeller vi ønsker å kjøre informasjon over et annet paradigme. Strengt tatt burde vi kalle informasjonsmodellene noe generelt og API spesifikasjonen noe spesielt (for eksempel helseapi). Men da innfører vi ett nytt lag i profileringsregimet vårt strengt tatt. - Ressurs fra HL7 internasjonal - no-basis ressurs - no-core ressurs (informasjonsmodell, ikke teknologiavhengig) - helseapi spesifikasjon (knyttet til API), helsemelding spesifikasjon (knyttet til meldingsutveksling) - prosjektspesifikk implementert spesifikasjon Siden vi uansett skal knytte dette til API transaksjoner kan vi godt kalle det helseapi for min del. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[rockphotog]

Forskjellen på nivå 4 og 5 f.eks. for HelseAPI er ikke så viktig, det kan godt hende noen implementerer HelseAPI (implementasjonsguide), "as is", og dermed er nivå 4 og 5 like for alle praktiske formål. Men HelseAPI/ISP/Argonaut Query/US Core/bla bla er minimumssett, så det legges jo opp til at den enkelte (EPJ) utvider det (nivå 5).

Nivå 5 bør ikke bare kalles prosjektspesifikt, men spesifikt endpoint/API/instans - dette vil uansett være det nederste laget i et hierarki, og jeg IKKE ha noe nivå 6 nå - enig/uenig?

Nivånumrene er uansett mest til forvirring, men må illustreres. Det er ikke et strikt hierarki - man kan ha instans-endpoint med profiler for "all over".

[thomiz]

Enig med Espen nivå 5 er ikke prosjektspesifikt. Vi bør dessuten ikke alltid knytte nivå til om det er en informasjonsmodell eller full impelementasjonsguide med ConformanceStatements for alle kommunikasjonsparadigmer heller. Det vi må tenke på er kanskje mest dette:

• Er noen av de informasjonsstrukturene vi lager nå aktuelle å benytte også innenfor andre kommunikasjonsparadigmer enn API?

Hvis svaret er ja (noe jeg tror det er når jeg har tenkt meg om) så bør vi kanskje likevel kalle det core eller noe annet som ikke er implementasjons-spesifikt.
Stemmer for no-core, så har vi en jobb med å kommunisere forskjellen på basis og core, samt hvordan de henger sammen.

NB! Jeg ønsker egentlig ikke å ta til orde for å introdusere enda ett nivå i conformance modellen :-)

[oaassv]

Enig i at det ikke er optimalt med et nivå til i modellen :). I og med at nivå 3 kan være både et relativt minimumsssett, men også et rikere sett - blir i tilfelle nivået under slik jeg skjønner det mer tilpasning av dette til API. Det er en fare for at dette kan bli en litt krevende kommunikasjonsjobb? Min oppfatning er også at de strukturene vi har laget i basis - og i prinsippet også de vi lager på nivå av nasjonale profiler - bør ha som utgangspunkt at de kan brukes på tvers av paradigmer. øyvind På tirsdag 24. september 2019, 07:22:26 CEST skrev Thomas Tveit Rosenlund <notifications@github.com> følgende: Enig med Espen nivå 5 er ikke prosjektspesifikt. Vi bør dessuten ikke alltid knytte nivå til om det er en informasjonsmodell eller full impelementasjonsguide med ConformanceStatements for alle kommunikasjonsparadigmer heller. Det vi må tenke på er kanskje mest dette: - Er noen av de informasjonsstrukturene vi lager nå aktuelle å benytte også innenfor andre kommunikasjonsparadigmer enn API? Hvis svaret er ja (noe jeg tror det er når jeg har tenkt meg om) så bør vi kanskje likevel kalle det core eller noe annet som ikke er implementasjons-spesifikt. Stemmer for no-core, så har vi en jobb med å kommunisere forskjellen på basis og core, samt hvordan de henger sammen. NB! Jeg ønsker egentlig ikke å ta til orde for å introdusere enda ett nivå i conformance modellen :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[kennethmyhra]

Ressursene slik de står nå er tenkt uavhengig av paradigme.

Stemmer for no-core. Vi kan legge det som omfatter spesifikasjon av REST API i eget kapittel i IGen i stedet for som underkapittel på ressursen slik det er på confluence i dag. Det burde da være enkelt å utvide med nye paradigmer når nødvendig.

[oaassv]

Jeg kunne godt tenke meg at vi tenker litt mer på navn, og ikke lander dette endelig nå. Ulempen med no-core er at det tilsvarer basisprofiler for eksempel i Nederland, det kan på sikt bli litt forvirrende hvis flere andre land velger core for basis. øyvind På tirsdag 24. september 2019, 09:00:44 CEST skrev Kenneth Myhra <notifications@github.com> følgende: Ressursene slik de står nå er tenkt uavhengig av paradigme. Stemmer for no-core. Vi kan legge det som omfatter spesifikasjon av REST API i eget kapittel i IGen i stedet for som underkapittel på ressursen slik det er på confluence i dag. Det burde da være enkelt å utvide med nye paradigmer når nødvendig. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.