Felles definisjoner, tolkninger og krav

Denne seksjonen beskriver essensielle definisjoner og tolkninger som brukes i HelseAPI IG.

Konformitetsverbene som benyttes i integrasjonsguiden er definert i konformitetsreglene for FHIR. Følgende norske oversettelser er benyttet for verbene:

Felles klinisk datasett - Dataelementer

Nr

Dataelement

HelseAPI profil

FHIR ressurs

(1)

Pasientens personidentifikator

HelseAPI Patient

Patient

(2)

Pasientens navn

HelseAPI Patient

Patient

(3)

Kjønn

HelseAPI Patient

Patient

(4)

Fødselsdato

HelseAPI Patient

Patient

Må støttes (mustSupport)

I konteksten av HelseAPI SKAL mustSupport på ethvert dataelement tolkes som følger:

Referanser i HelseAPI profilene

Mange av profilene i denne guiden har referanser til andre FHIR ressurser som også er HelseAPI profiler. Disse er definert i de formelle profildefinisjonene. For referanser der det ikke formelt er definert en HelseAPI profil BURDE den refererte ressursen være en HelseAPI profil dersom denne eksisterer.

Syntaks leseoperasjoner

Interaksjoner er definert med følgende syntaks:

GET [base]/[Resource-type]/[id] {parameters}

For mer informasjon se FHIR RESTful API.

Syntaks søkeoperasjoner

I den simpleste form utføres et søk ved en GET-operasjon i RESTful-rammeverket:

GET [base]/[Resource-type]?name=value&...

I det ovenstående eksemplet på et RESTful-søk er parameterne et sekvenspar med name=[value] kodet i URL-en. Søkeparameterne er definert pr. ressurs. Se FHIR søk for mer informasjon vedrørende søk.

Syntaks for søk som er begrenset til en pasient

Det er flere potensielle muligheter å søke etter ressurser som er assosiert med en spesifikk pasient avhengig av kontekst og implementasjon. Følgende søk vil ende opp med det samme resultatet:

  1. En eksplisitt angitt pasient ved bruk av "patient" parameteren som begrenser resultatet innenfor den ressurstypen det søkes på til den angitte pasienten.

  2. Pasienten KAN være en implisitt del av konteksten, slik som ved bruk av SMART. I disse tilfellene kan pasient-parameteren utelates:

Søk på tvers av plattformer

Det er ikke et krav om at HelseAPI tjenere skal støtte eksterne URL-er som går på tvers av deres systemmiljø(er).

Veiledning på begrensning av antall resultater ved søk

For å kunne begrense antall søkeresultater som returneres i hvert enkelt kall, kan serveren velge å returnere resultatene som en serie med sider. Søkeresultatet inneholder ett sett med URL-er som klienten kan benytte når den gjør en forespørsel om flere sider fra søkeresultatet, for mer informasjon se FHIR paginering.

Håndtering av versjonskonflikter

Tapte oppdateringer der to klienter oppdaterer den samme ressursen, og nummer to skriver over endringene til nummer én kan unngås ved å bruke en kombinasjon av headerene ETag og If-Match.

For å støtte oppunder håndtering av versjonskonflikter SKAL servere alltid returnere en ETag:

HTTP 200 OK
Date: Sat, 09 Feb 2013 16:09:50 GMT
Last-Modified: Sat, 02 Feb 2013 12:02:47 GMT
ETag: W/"23"
Content-Type: application/fhir+json

ETag SKAL være identisk med versjonsidentifikatoren for ressursen på serveren. (Burde vi si noe om formatet? Spesifikasjonen sier: Servers are allowed to generate the version id in whatever fashion that they wish, so long as they are valid according to the id data type, and are unique within the address space of all versions of the same resource.)

Ved oppdatering av en ressurs SKAL klienten angi headeren If-Match som siterer ETag headeren som ble returnert av serveren:

PUT /Patient/347 HTTP/1.1
If-Match: W/"23"

Ved oppdateringer SKAL Serveren kreve at klienten angir headeren If-Match, dersom headeren mangler SKAL serveren returnere HTTP statuskoden 412 Pre-condition failed.

For mer informasjon, se Managing Resource Contention.

Responshåndtering

Både ved bruk av REST og FHIR med REST er det viktig at svar fra en tjener følger standardisering av HTTP status koder, for anbefalinger vedrørende responshåndtering ved tilgangsnekt se Sikkerhet .

HTTP standarden definerer følgende status kodeserier: