Difference between revisions of "201605 Workflow"
| Line 44: | Line 44: | ||
==Scenarios== | ==Scenarios== | ||
<!-- What will be the actions performed by participants? --> | <!-- What will be the actions performed by participants? --> | ||
| + | |||
| + | |||
| + | ===Find place to send referral to=== | ||
===Create Referral=== | ===Create Referral=== | ||
| Line 54: | Line 57: | ||
===Send Referral and Receive Acknowledgement=== | ===Send Referral and Receive Acknowledgement=== | ||
| + | |||
| + | Client: Create ReferralRequest and store on server | ||
| + | Client: Create ActionRequest with Reference to Referral Request and store in sever | ||
| + | |||
| + | Server (at some stage): Create matching ActionResponse with status = 'pending' and store | ||
| + | |||
| + | Client: Poll for ActionResponse (ie ActionResponse where request=ActionResponse) | ||
| + | |||
| + | Alternate scenarios: | ||
| + | * server rejects request (create ActionResponse with status='rejected') | ||
| + | * there is an error of some sort (?business ie this type of referral not accepted) | ||
| + | * ?where the request has a 'callback' (?CommunicationRequest) that the server uses to push notifications) | ||
===Grade Referral=== | ===Grade Referral=== | ||
| + | Server: update status of ActionResponse to 'accepted' (?new version or a new resource) | ||
| + | Client: Poll for responses and display appropriately | ||
| + | |||
| + | |||
| + | ===Cancel Referral=== | ||
| + | |||
| + | Client: locate original ActionRequest, create a new OrderResponse with status set to cancel ??should this be on the request instead | ||
| + | |||
| + | Server: ??? | ||
===Create Appointment=== | ===Create Appointment=== | ||
| + | |||
| + | Server: Create an appointment with reference to ActionRequest or ReferralRequest. ?Create new new ActionResponse or update existing | ||
| + | Client: Poll for responses and display appropriately | ||
==TestScript(s)== | ==TestScript(s)== | ||
Revision as of 00:19, 6 March 2016
Workflow
Submitting WG/Project/Implementer Group
FHIR Infrastructure, Patient Care, Patient Administration
Justification
Workflow is a primary focus of the upcoming release. A number of new approaches are being proposed and they need to be tested
Proposed Track Lead
See Connectathon_Track_Lead_Responsibilities Keith Boone (keith.boone@ge.com) Skype: kwboone
Expected participants
TBD
Roles
Submitter
The actor that creates the referral
Recipient
The person or organization that received the referral
Grader
The person who prioritizes the referral for urgency
Scheduling Clerk
The person that makes the appointment for the person to attend
Services Registry
A system that knows what services are available at what institutions to assist a referrer to find the correct place to send the referral
Scenarios
Find place to send referral to
Create Referral
- Action:
- Precondition:
- Success Criteria:
- Bonus point:
Send Referral and Receive Acknowledgement
Client: Create ReferralRequest and store on server Client: Create ActionRequest with Reference to Referral Request and store in sever
Server (at some stage): Create matching ActionResponse with status = 'pending' and store
Client: Poll for ActionResponse (ie ActionResponse where request=ActionResponse)
Alternate scenarios:
- server rejects request (create ActionResponse with status='rejected')
- there is an error of some sort (?business ie this type of referral not accepted)
- ?where the request has a 'callback' (?CommunicationRequest) that the server uses to push notifications)
Grade Referral
Server: update status of ActionResponse to 'accepted' (?new version or a new resource) Client: Poll for responses and display appropriately
Cancel Referral
Client: locate original ActionRequest, create a new OrderResponse with status set to cancel ??should this be on the request instead
Server: ???
Create Appointment
Server: Create an appointment with reference to ActionRequest or ReferralRequest. ?Create new new ActionResponse or update existing Client: Poll for responses and display appropriately
