An appointment may include a visit either in person or remote (by phone, video conference, etc.). All that matter is that the time and usage of one or more individuals, locations and/or pieces of equipment is being fully or partially reserved for a designated period of time. When using a request-response style of appointment this is done using Appointment and Appointment Response resources. The request is made in the form of an Appointment with a proposed or pending status, and the list of actors with a participation status of “needs-action”.
Participants in the appointment respond with their acceptance (or not) to the appointment by creating Appointment Response resources. Once all the participants have replied, then the Appointment resource is able to be updated with an overall status which collates the results of all the participants and presents the approved details of the appointment.
The participant type property can be used to represent a specific role that a practitioner is required to perform for the appointment. This could be specified without an actor when the actual practitioner is not known and will be filled in closer to the scheduled time. This property must be the same between the Appointment-participant and the Appointment Response so that the appropriate values can be allocated. If you need multiple actors of a specific type, then multiple participants with that type value are included on the appointment.
Appointments can be considered as Administrative only, and the Encounter is expected to have clinical implications. In general, it is expected that appointments will result in the creation of an Encounter. The encounter is typically created when the service starts, not when the patient arrives. When the patient arrives, an appointment can be marked with a status of Arrived. In an Emergency Room context, the appointment Resource is probably not appropriate to be used. In these cases, an Encounter should be created.
Fast Healthcare Interoperability Resources (FHIR) is a draft standard describing data formats and elements (known as “resources”) and an application programming interface (API) for exchanging electronic health records. The standard was created by the Health Level Seven International (HL7) health-care standards organization.
Its goal is to facilitate interoperation between legacy healthcare systems, to make it easy to provide healthcare information to healthcare providers and individuals on a wide variety of devices from computers to tablets to cell phones, and to allow third-party application developers to provide medical applications which can be easily integrated into existing systems.
FHIR provides an alternative to document-centric approaches by directly exposing discrete data elements as services. For example, basic elements of healthcare like patients, admissions, diagnostic reports and medications can each be retrieved and manipulated via their own resource URLs (Uniform Resource Locators). FHIR was supported at an American Medical Informatics Association meeting by many EHR (Electronic Health Record) vendors which value its open and extensible nature.