Difference between revisions of "Interface-Driven Tasking"

From Galen Healthcare Solutions - Allscripts TouchWorks EHR Wiki
Jump to navigation Jump to search
 
(One intermediate revision by one other user not shown)
Line 2: Line 2:
 
__TOC__
 
__TOC__
 
===General Notes===
 
===General Notes===
*Interface-driven tasking facilitates automatic generation of requests or reminders for an action
+
*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.  
 
*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====
 
====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:
 
*The provider has to be a user to get a task and also needs to be configured to enable electronic workflow:
 
[[Image:Tasking Provider Setup.jpg]]
 
[[Image:Tasking Provider Setup.jpg]]
 +
 
==Results (FileResult_CMS inbound stored procedure)==
 
==Results (FileResult_CMS inbound stored procedure)==
 
===FAQ/Common Issues===  
 
===FAQ/Common Issues===  
Line 60: Line 61:
  
 
== Documents (FileDOCWORKSTranscription inbound stored procedure) ==
 
== 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:
+
Document status is not determined by the interface, but rather by the document type filed against and the user-provider filed to.  If a document is in the final status neither a verify task nor a sign note will be created, however a review task can be created.
 
{| {{table}} border=1
 
{| {{table}} border=1
 
| align="center" style="background:#f0f0f0;"|'''Doc Type'''
 
| align="center" style="background:#f0f0f0;"|'''Doc Type'''

Latest revision as of 21:46, 4 March 2013

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:

Tasking Provider Setup.jpg

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. If a document is in the final status neither a verify task nor a sign note will be created, however a review task can be created.

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. Electronic Signature will create a sign note and electronic verification will create a verify task. Both electronic signature and electronic verification will create review tasks. Doc Elec Workflow.gif

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

Position Parameter Definition Units of Measure Range Allowed Values Defaults Mandatory on Vector?
38 @cc_list List of additional recipients (besides owner) of this document N/A Up to 8000 characters Pipe-delimited list with caret-delimited data for each entry specifying recipient and printer None Optional

Example: @cc_list = 'PRINT^DZANG^28^PROV^DASH^HPlaserj^^Document^1^2^Y^DASH^HPlaserj^1^documentenv^addr1^addr2^libertyville^il^60015^|'

FileDOCWORKSTranscription parameter 26 - RoutingList:

Position Parameter Definition Units of Measure Range Allowed Values Defaults Mandatory on Vector?
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.