This wiki has undergone a migration to Confluence found Here

Difference between revisions of "201605 Workflow"

From HL7Wiki
Jump to navigation Jump to search
Line 58: Line 58:
 
:Bonus point: A client is developer that can update the registry, adding new services to it.
 
:Bonus point: A client is developer that can update the registry, adding new services to it.
  
===Create Referral===
+
===2. Create Referral===
  
  
 +
:Action: The submitter creates a referral on the referral server. This will involved creating [http://hl7-fhir.github.io/referralrequest.html referralRequest] and a [http://hl7-fhir.github.io/task.html task] resource that refers to it
 +
:Precondition: There is a server established as the 'referral manager' - that can maintain Task and ReferralRequest resources
 +
:Success Criteria: The workflow resources (Task, ReferralRequest) are successfully created
 +
:Bonus point: The client that creates the referral can also query for the current status of the referral.
  
 +
 +
'''Notes'''
 
Against the target server Create a ReferralRequest resource, then a Task resource with the Task.owner pointing to an organization, Task.concerning referring to the patient and the  Task.subject referring to the  ReferralRequest. The task.status will be 'created'
 
Against the target server Create a ReferralRequest resource, then a Task resource with the Task.owner pointing to an organization, Task.concerning referring to the patient and the  Task.subject referring to the  ReferralRequest. The task.status will be 'created'
 
 
 
Creator is a Practitioner (the GP)
 
 
 
 
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
:Precondition: <!-- What setup is required prior to executing this step? -->
 
:Success Criteria: <!-- How will the participants know if the test was successful? -->
 
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
 
 
<!-- Provide a description of each task -->
 
  
 
===Receive Referral ===
 
===Receive Referral ===

Revision as of 20:17, 25 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. It implements queries against a healthcareservice resource

Architecture

Describe the architecture here - where all tasks are created on the server where the referral is tobe processed. Discuss that there can be other architectures - eg a centralized 'referral manager' server.

Scenarios

1. Find place to send referral to

Action: The Submitter makes queries against the Service Registry to locate a suitable location to send the referral to.
Precondition: There is a server acting in the role of a Service Registry exposing queries that enable the submitter to locate the service type they need. For the sake of this scenario it is assumed that there will be an organization that meets the needs of the referral (ie that the registry has suitable Organization resources).
Success Criteria: A suitable organization is located
Bonus point: A client is developer that can update the registry, adding new services to it.

2. Create Referral

Action: The submitter creates a referral on the referral server. This will involved creating referralRequest and a task resource that refers to it
Precondition: There is a server established as the 'referral manager' - that can maintain Task and ReferralRequest resources
Success Criteria: The workflow resources (Task, ReferralRequest) are successfully created
Bonus point: The client that creates the referral can also query for the current status of the referral.


Notes Against the target server Create a ReferralRequest resource, then a Task resource with the Task.owner pointing to an organization, Task.concerning referring to the patient and the Task.subject referring to the ReferralRequest. The task.status will be 'created'

Receive Referral

The recipient of the referral assigns the task to a grader (by setting the owner to a practitioner ) & sets the status to ready

Could locate by direct query against task or use an operation

query needs to be all referralrequest tasks for this organization in the created state

Grade Referral

Practitioner locates referrals assigned to them in a 'ready' state. Could locate by direct query against task or use an operation

Accept: change owner to the scheduling department (another organization)

Reject: change status to 'failed'. Assign owner to the initial creator (the GP)

Create Appointment

Scheduling department (Organization) create appointment

query is all tasks where the subject is a referralrequest and owner is that organization and state changes to completed - because we assume that the purpose of the task was to arrange an appointment for a patient.

Could create a new task for the outpatient clinic (where the appointment is to be) - with task.input set to the appointment

TestScript(s)