0.1.0 - trial-use
KisimScheduling - Local Development build (v0.1.0). See the Directory of published versions
If the client system does not know the internal patient identification for KISIM, this use case applies. This might be the case for online booking services which offer appointment bookings through a website.
At first the client needs to query the actual available slots. This can be done by the search operation searchSlotByPlan. Found slots are only valid for a certain amount of time. Usually this is 30 minutes, but depending on the server this might be more or less.
Request
GET [base]/Slot?query=searchByPlan&planIcode=[UUID]&maxDays=10
Response
```
{
"resourceType": "Bundle",
"id": "647e4f74-fa60-419b-bd85-31acd484c3c9",
"meta": {
"lastUpdated": "2021-03-09T18:00:52.264+01:00"
},
"type": "searchset",
"total": 9,
"link": [
{
"relation": "self",
"url": "/fhir/r4/*/Slot?_query=searchByPlan&maxDays=1&planIcode=f7999bfe-b5df-4b52-a636-95532ffa9ea2"
}
],
"entry": [
{
"fullUrl": "/fhir/r4/*/Slot/145_1",
"resource": {
"resourceType": "Slot",
"id": "145_1",
"schedule": {
"reference": "Schedule/145_KONS_1277"
},
"status": "free",
"start": "2021-03-10T09:40:00.000+01:00",
"end": "2021-03-10T10:20:00.000+01:00"
}
}, ...
}
```
Each found slot has a corresponding Schedule Resource. This Schedule can be read and it will contain an actor which might be either a Practitioner or a Location. This actor can be added to the participant value of the Appointment resource. This is only needed, if there is no contained patient as participant added to the appointment.
Request
GET [base]/Schedule/145_KONS_1277
Response
```
{
"resourceType": "Schedule",
"id": "145_KONS_1277",
"serviceCategory": [
{
"coding": [
{
"system": "2.16.756.5.30.1.163.1.2.124.2",
"code": "LANSCRAM001",
"display": "Covid 19 Screening"
}
]
}, ...
],
"actor": [
{
"reference": "Location/KONS-1277",
"display": "Screening 1"
}
],
"planningHorizon": {
"start": "2021-03-12T14:05:00+01:00",
"end": "2021-03-13T14:05:00+01:00"
}
}
```
The client sends an Appointment resource containing a slot, participant and status to the server. The slot time can be overwritten by setting the appointment start and end. Those times need to stay inside the original slot time. This means the client system can only book a slot part-time if it needs to. This is important if the client system does the time-handling by itself e.g. does not use the parameter splitSlots in the searchSlotByPlan query. Additionally, the client should if available also send a contained Patient resource with the appointment. This is not necessary, but it would help on the server side to handle the patient clearing and the client does not need to add a location or practitioner from the schedule to the appointment. In the response the client receives an appointment ID. This appointment ID then has to be used in the ServiceRequest.
Request
POST [base]/Appointment
Request body
```
{
"resourceType": "Appointment",
"contained": [
{
"resourceType" : "Patient",
"id" : "p1",
"name" : [
{
"family" : "Bond",
"given" : ["James"]
}
],
"gender" : "male",
"birthDate": "1950-01-01T00:00:00.000+00:00"
}
],
"identifier": [
{
"system": "http://yourproduct-example.com/fhir/apps/referralids",
"value": "yourproduct_4019"
}
],
"slot": [
{
"reference": "Slot/34_1"
}
],
"serviceType": [
{
"coding": [
{
"system": "2.16.756.5.30.1.163.1.2.1.1",
"code": "FKLMAMAB",
"display": "Abschlussko. Mamma"
}
]
}
],
"status": "proposed",
"participant": [
{
"actor": {
"reference": "#p1"
}
}
]
}
```
Response
```
{
"resourceType": "Appointment",
"id": "22875",
"identifier": [
{
"system": "http://cistec.com",
"value": "22875"
}
],
"status": "pending",
"serviceCategory": [
{
"coding": [
{
"system": "http://hl7.org/fhir/ValueSet/service-category",
"code": "35",
"display": "Hospital"
}
]
}
],
"start": "2021-03-15T08:00:00.000+01:00",
"end": "2021-03-15T08:10:00.000+01:00",
"participant": [
{
"actor": {
"reference": "Practitioner/CISRBIRR",
"display": "R. Birri"
},
"status": "accepted"
}
]
}
```
Start and end set in appointment. This overwrites the slot start/stop.
Request
POST [base]/Appointment
Request body
```
{
"resourceType": "Appointment",
"contained": [
{
"resourceType" : "Patient",
"id" : "p1",
"name" : [
{
"family" : "Bond",
"given" : ["James"]
}
],
"gender" : "male",
"birthDate": "1950-01-01T00:00:00.000+00:00"
}
],
"identifier": [
{
"system": "http://yourproduct-example.com/fhir/apps/referralids",
"value": "yourproduct_4019"
}
],
"slot": [
{
"reference": "Slot/34_1"
}
],
"serviceType": [
{
"coding": [
{
"system": "2.16.756.5.30.1.163.1.2.1.1",
"code": "FKLMAMAB",
"display": "Abschlussko. Mamma"
}
]
}
],
"status": "proposed",
"start": "2021-03-15T08:00:00.000+01:00",
"end": "2021-03-15T08:10:00.000+01:00",
"participant": [
{
"actor": {
"reference": "#p1"
}
}
]
}
```
Response
```
{
"resourceType": "Appointment",
"id": "22875",
"identifier": [
{
"system": "http://cistec.com",
"value": "22875"
}
],
"status": "pending",
"serviceCategory": [
{
"coding": [
{
"system": "http://hl7.org/fhir/ValueSet/service-category",
"code": "35",
"display": "Hospital"
}
]
}
],
"start": "2021-03-15T08:00:00.000+01:00",
"end": "2021-03-15T08:10:00.000+01:00",
"participant": [
{
"actor": {
"reference": "Practitioner/CISRBIRR",
"display": "R. Birri"
},
"status": "accepted"
}
]
}
```
The final step of the booking procedure is the ServiceRequest. In the service requzest the client needs to send the Appointment ID from the previous step and additionally a contained Patient ressource. This ressource is used to perform a Patient clearing inside KISIM. This Patient Clearing is done manually by a controller.
Request
POST [base]/ServiceRequest
Request body
```
{
"resourceType": "ServiceRequest",
"id": "SomeId",
"contained": [
{
"resourceType" : "Patient",
"id" : "p1",
"name" : [
{
"family" : "Bond",
"given" : ["James"]
}
],
"gender" : "male",
"birthDate": "1950-01-01T00:00:00.000+00:00"
}
],
"identifier": [
{
"system": "http://yourproduct-example.com/fhir/apps/referralids",
"value": "yourproduct_4099"
}
],
"status": "active",
"intent": "plan",
"subject": {
"reference": "#p1",
"display": "Bond James"
},
"requester": {
"reference": "#p1",
"display": "requester"
},
"supportingInfo": [
{
"reference": "Appointment/22875",
"display": "appointment"
}
]
}
```
Response
```
{
"resourceType": "AppointmentResponse",
"appointment": {
"reference": "Appointment/22875"
}
}
```
After the patient clearing and the necessary administrative steps are done, the client receives a AppointmentResponse with the new status of the Appointment. This can be accepted or cancelled, depending on the steps done inside KISIM. Additionally the response will contain the start and stop time of the appointment. The client could receive multiple appointmen responses, for example if an appointment is moved after it was accepted. It is the clients responsibility to handle those responses accordingly.