Difference between revisions of "Appointment Management"

From Hiasobi - FHIR
Jump to: navigation, search
(Appointment Accept/Reject)
(Appointment Accept/Reject)
Line 50: Line 50:
  
 
== Appointment Accept/Reject ==
 
== Appointment Accept/Reject ==
* Appointment requests are retrieved from the cloud  
+
* Appointment requests retrieved from the cloud are processed
 +
* Appointments are attempted to be made in the PMS
 +
* Result will be accepted or declined appointment allocation
  
Clinic will update appointment to accept or reject it
+
 
 +
Practice adapter will create/update appointments:
 +
 
 +
FHIR add/update appointment using Oridashi-Hiasobi interface
  
 
  PUT [base]/Appointment/<id>
 
  PUT [base]/Appointment/<id>
  
 +
* Patient matching can occur based on Name, Date of Birth, Gender (or other identifying information)
 +
* Provider matching can occur based on Name, Provider Number (or other identifying information)
 +
* Submitted appointment will be as per appointment request obtained from cloud endpoint
  
Structure is like:
+
FHIR add/update response (success)
  
 
  Appointment
 
  Appointment
 +
  status=booked
 
   participant[0]
 
   participant[0]
     status = accepted | declined
+
     status = accepted
 +
  participant[1]
 
   participant[2]
 
   participant[2]
     status = accepted | declined
+
     status = accepted

Revision as of 16:44, 13 October 2017

Information

See: Core FHIR Resources Appointment, Schedule, Slot

Todo: Oridashi Profiles for Appointment, Schedule and Slot

Available Slots

  • Schedules (Appointment Book) can be retrieved from FHIR interface (FHIR Schedule)
  • Each FHIR Schedule is for a provider (FHIR Practitioner); there may be multiple sessions per day
  • A FHIR extension defines the nominal slot period length for each Schedule
  • Free/Busy slots are available (FHIR Slot)

Appointments Requiring Action

  • Practice components search for requested/cancelled appointments from a cloud endpoint
  • Search by:
    • Appointment.status=pending - are requests that are not confirmed yet (indicates a request)
    • Appointement.location.identifier - identifies the practice associated with the appointment request

FHIR API search request:

GET [base]/Appointment?status=pending&location.identifier=<siteid>&_include=Appointment:actor

FHIR API search response:

  • Return a FHIR Bundle
  • Bundle.entry will contain Appointment resources
  • Appointment indicating are request structured like:
Appointment
 status=pending - indicates appointment needs attention
 start - expected visit start date/time
 end - expected visit end date/time
 slot - optional reference to a free/busy Slot resource
 participant [0] - participant practitioner
   type=PPRF|http://hl7.org/fhir/v3/ParticipationType - coded participation (primary performer is the attending clinician) 
   actor is Practitioner - reference to Practitioner  (FHIR internal identifier) 
   required=required - coded indicates this participation in the appointment is needed
   status = needs-action - coded indicates the participation is not confirmed
 participant [1]
   type = null
   actor is Patient - reference to Patient (FHIR internal identifier) 
   required = required- coded indicates this participation in the appointment is needed
   status = accepted - coded indicates the participation is not confirmed
 participant [2] 
   type = null
   actor is Location - reference to Location (FHIR internal identifier) 
   required = required- coded indicates this participation in the appointment is needed
   status = needs-action - coded indicates the participation is not confirmed

Appointment Accept/Reject

  • Appointment requests retrieved from the cloud are processed
  • Appointments are attempted to be made in the PMS
  • Result will be accepted or declined appointment allocation


Practice adapter will create/update appointments:

FHIR add/update appointment using Oridashi-Hiasobi interface

PUT [base]/Appointment/<id>
  • Patient matching can occur based on Name, Date of Birth, Gender (or other identifying information)
  • Provider matching can occur based on Name, Provider Number (or other identifying information)
  • Submitted appointment will be as per appointment request obtained from cloud endpoint

FHIR add/update response (success)

Appointment
  status=booked
  participant[0]
    status = accepted
  participant[1]
  participant[2]
    status = accepted