This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "AppointmentResponse FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
Line 27: Line 27:
  
 
==Scope of coverage==
 
==Scope of coverage==
 +
As the AppointmentResponse resource is directly related to the Appointment Resource it provides the accountability and transparency of the overall appointment.
  
<!-- Define the full scope of coverage for the resource.  The scope must be clearly delineated such that it does not overlap with any other existing or expected resource.  The scope will be used to govern "what is the set of potential applications to consider when evaluating what elements are 'core' – i.e. in the 80%"
+
The scope of the appointment response includes:
 +
* The acceptance status of the response
 +
* the reference to the appointment
 +
* which entity that is responding to the appointment request
 +
* the details that the participant accepts (or wants to accept)
 +
* any additional notes that the participant wants to provide with respect to the response
  
Scope should consider numerous aspects of breadth of scope, including:
 
* Subject: Human vs. non-human vs. non-patient (e.g. lab bench medicine)
 
* Disciplines: Environmental Health, Palliative, Respiratory, Psychology, Maternity, Clinical Research
 
* Delivery environment (Community, Geriatric, Home care, Emergency, Inpatient, Intensive, Neonatal, Pediatric, Primary)
 
* Locale: Country, region
 
 
As a rule, resources should encompass all of these aspects.
 
-->
 
  
 
==RIM scope==
 
==RIM scope==
 
<!-- Identify the formal RIM mapping for the root concept of the resource.  The expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. -->
 
 
Act(ActMood = actMoodAppointmentRequest or actMoodAppointment)
 
Act(ActMood = actMoodAppointmentRequest or actMoodAppointment)
  
 
Note: Not a direct relationship
 
Note: Not a direct relationship
 +
  
 
==Resource appropriateness==
 
==Resource appropriateness==
 +
This resource is required to be able to communicate disparate responses to appointment requests.
  
<!-- Does the resource meet the following characteristics?
+
Note: The existing iCal Standard also has this concept covered in it's basic structure.
  
Must
 
* Represents a well understood, "important" concept in the business of healthcare
 
* Represents a concept expected to be tracked with distinct, reliable, unique ids
 
* Reasonable for the resource to be independently created, queried and maintained
 
 
Should
 
* Declared interest in need for standardization of data exchange</span>
 
* Resource is expected to contain an appropriate number of "core" (non-extension) data elements (in most cases, somewhere in the range of 20-50)
 
* Have the characteristics of high cohesion & low coupling – need to explore whether coupling is good some places, not elsewhere – layers from Bo’s document
 
-->
 
  
 
==Expected implementations==
 
==Expected implementations==
 +
This resource is expected to be implemented by community clinics, general practice and specialist software solutions to receive and publish their appointments directly to/from users external to the organization providing the information.
  
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. -->
 
  
 
==Content sources==
 
==Content sources==
 +
The appointment response resource has a lot of similarities with the iCal standard and a mapping to this standard will be expected.
  
<!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult
 
 
Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? -->
 
  
 
==Example Scenarios==
 
==Example Scenarios==
 +
An appointment has been requested for a physician, room (location) and the patient to meet. A response will be created for each of these participants indicating their acceptance status.
 +
Once all participants have responded the overall status of the appointment can be processed and updated.
  
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource.  They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) -->
 
  
 
==Resource Relationships==
 
==Resource Relationships==
 
The AppointmentResponse Resource only references the Appointment that it is providing a response for, and which participant.
 
The AppointmentResponse Resource only references the Appointment that it is providing a response for, and which participant.
 +
  
 
==Timelines==
 
==Timelines==
 
Given the progress to date, we expect that this resource will be ready for inclusion in the next Ballot (expecting September 2014) the resource has already undergone a great deal of review in PA over the last 6 months.
 
Given the progress to date, we expect that this resource will be ready for inclusion in the next Ballot (expecting September 2014) the resource has already undergone a great deal of review in PA over the last 6 months.
 +
  
 
==gForge Users==
 
==gForge Users==

Revision as of 04:12, 28 April 2014



AppointmentResponse

Owning committee name

Patient Administration

Contributing or Reviewing Work Groups

  • "None"

FHIR Resource Development Project Insight ID

pending

Scope of coverage

As the AppointmentResponse resource is directly related to the Appointment Resource it provides the accountability and transparency of the overall appointment.

The scope of the appointment response includes:

  • The acceptance status of the response
  • the reference to the appointment
  • which entity that is responding to the appointment request
  • the details that the participant accepts (or wants to accept)
  • any additional notes that the participant wants to provide with respect to the response


RIM scope

Act(ActMood = actMoodAppointmentRequest or actMoodAppointment)

Note: Not a direct relationship


Resource appropriateness

This resource is required to be able to communicate disparate responses to appointment requests.

Note: The existing iCal Standard also has this concept covered in it's basic structure.


Expected implementations

This resource is expected to be implemented by community clinics, general practice and specialist software solutions to receive and publish their appointments directly to/from users external to the organization providing the information.


Content sources

The appointment response resource has a lot of similarities with the iCal standard and a mapping to this standard will be expected.


Example Scenarios

An appointment has been requested for a physician, room (location) and the patient to meet. A response will be created for each of these participants indicating their acceptance status. Once all participants have responded the overall status of the appointment can be processed and updated.


Resource Relationships

The AppointmentResponse Resource only references the Appointment that it is providing a response for, and which participant.


Timelines

Given the progress to date, we expect that this resource will be ready for inclusion in the next Ballot (expecting September 2014) the resource has already undergone a great deal of review in PA over the last 6 months.


gForge Users

brian_pos ewoutkramer grahameg