Difference between revisions of "Interface-Driven Tasking"
Line 122: | Line 122: | ||
====Interface Components==== | ====Interface Components==== | ||
FileDOCWORKSTranscription parameter 38 - CCList | FileDOCWORKSTranscription parameter 38 - CCList | ||
+ | |||
+ | FileDOCWORKSTranscription parameter 26 - RoutingList: | ||
+ | {| {{table}} | ||
+ | | align="center" style="background:#f0f0f0;"|'''26 @RoutingList List of users or teams to''' | ||
+ | |- | ||
+ | | receive notification about | ||
+ | |- | ||
+ | | this document | ||
+ | |- | ||
+ | | N/A Up to 255 | ||
+ | |- | ||
+ | | characters | ||
+ | |- | ||
+ | | Pipe-delimited list of | ||
+ | |- | ||
+ | | U:xxx or T:xxx where xxx | ||
+ | |- | ||
+ | | is the eentrymnemonic of | ||
+ | |- | ||
+ | | the user (U) or team (T) | ||
+ | |- | ||
+ | | None Optional | ||
+ | |} | ||
+ | |||
===Custom Tasking=== | ===Custom Tasking=== |
Revision as of 16:03, 30 December 2011
General Notes
- Interface-driven tasking facilitates automatic generation of requests or reminders for an action
- Customized logic can be setup to selectively task users. A typical approach is to setup a ConnectR translation table which can be managed to control which providers/users and/or groups receive tasks.
V11 Provider Setup for Tasking
- The provider has to be a user to get a task and also needs to be configured to enable electronic workflow:
Results (FileResult_CMS inbound stored procedure)
FAQ/Common Issues
Q: Why are some of the result tasks assigned to "New Result Team"?
A: This is the default behavior if the tasked provider is not a user or if the tasked provider is inactive.
Tasks are not created for pending results
If tasks are not properly being generated for a particular provider, ensure that the following parameters are set to 'F' for a status of final, else the task will not properly generate:
FileResult_CMS parameter 44 - ItemResultStage
FileResult_CMS parameter 45 - OrderResultStage
More on result stage and tasking can be found here
Verify Results
Background
Verify Results tasks allow providers to “sign off” on results like they would on paper. Typically all providers who will be viewing their results in the EHR will have Verify Results tasks created for them.
Task Type: | Module: | Is created by: | When: | And the Task Action is: | And Assigned to: | And is resolved: |
Verify Patient Results | Result | The system | This task provides notification that a result is available for verification. The task facilitates the verification of patient results. The task is created when a result is filed that requires verification. The task priority is dictated by the Result Status. | Verify Patient Results | Ordering provider | Completed when the all results associated with the encounter and ordering provider combination have either been verified or the ordering provider for the result has been changed another user. |
Interface Components
FileResult_CMS parameter 25 - Acknowledgement Request Flag
Review Results
Background
There are occasions when a practice will have the results of a test carbon copied (CC) to providers aside from the Ordering Provider. If your Other Vendor supports CCs, you can have the associated CC providers tasked in TouchWorks. These tasks will be Review Results tasks.
Task Type: | Module: | Is created by: | When: | And the Task Action is: | And Assigned to: | And is resolved: |
Review Results | Result | The system | When a user is CC’d on a result with a notification method of task, a review result is created for them when the result is verified or if it does not need verification, when it is filed. | Process Result | Ordering provider | Manually completed or completed when the user who was CC’d performs the \"Mark as Reviewed\" action on the order |
Interface Components
FileResult_CMS parameter 98 - Routing List
Custom Tasking
Background
Interfaced Results also offer the capability of generating custom tasks and task priorities. If an appropriate taskname parameter is passed with the results in the interface, then the result-related tasks will be generated in addition to the verify result task. There will only be one instance of this task per result.
Interface Components
FileResult_CMS parameter 114 - TaskTypeCode
FileResult_CMS parameter 115 - TaskPriorityName
Documents (FileDOCWORKSTranscription inbound stored procedure)
Document status is not determined by the interface, but rather by the document type filed against and the user-provider filed to:
Doc Type | User Electronic Workflow | Initial Document Status |
Non-electronic | Y | Final Receipt |
Non-electronic | N | Final Receipt |
Electronic Signature | Y | Unsigned |
Electronic Signature | N | Final Receipt |
Electronic Verification | Y | Unverified |
Electronic Verification | N | Final Receipt |
Also the type of task that is generated is dictated by the workflow defined for the document type in question:
Verify Document
Task Type: | Module: | Is created by: | When: | And the Task Action is: | And Assigned to: | And is resolved: |
Verify Doc | Document | The system | A transcription comes over an interface or through AE-EHR Scan | Verify Transcription | Provider selected in the transcription source file | Automatically when the user verifies or invalidates the transcription |
Sign Note
Task Type: | Module: | Is created by: | When: | And the Task Action is: | And Assigned to: | And is resolved: |
Sign note | Note | The system | The Note has been signed but not finalized because the user doesn’t have ownership authority sufficient for the note nor finalizing authority for the note. Initial signing indicates note input has been completed or is ready for next clinician. Task can be manually generated at any time as well | Sign Note | Note owner (or a manually linked provider) | When the document is signed by the assignee. |
Review Document
Task Type: | Module: | Is created by: | When: | And the Task Action is: | And Assigned to: | And is resolved: |
Review Document | Document | A user or the system | When a user is selected to receive a Carbon Copy of the document via a Task (rather than a printed or faxed copy) AND after the document completes a step that triggers its distribution (i.e. if configured to generate on Final, tasks are generated for any CC task recipients when the document is finalized.) | Process Note | The recipient of the CC | When the user clicks Done. |
Interface Components
FileDOCWORKSTranscription parameter 38 - CCList
FileDOCWORKSTranscription parameter 26 - RoutingList:
26 @RoutingList List of users or teams to |
receive notification about |
this document |
N/A Up to 255 |
characters |
Pipe-delimited list of |
U:xxx or T:xxx where xxx |
is the eentrymnemonic of |
the user (U) or team (T) |
None Optional |
Custom Tasking
The OverrideTaskFlag parameter can force documents to Final Receipt even if they normally would require verification. This is useful for conversion and inpatient document scenarios.
Interface Components
FileDOCWORKSTranscription parameter 60 - OverrideTaskFlag
Custom Solution
An example describes an approach to replace the standard Sign Note/Verify Doc task with a client defined task added to the 'Task Name' dictionary.