Need some help for configuration

[apcloic]

Hi,

 

We've just bought 3 licences for Express Dictate, i've installed Express Delegate, we have 2 typists that works for all the 3 speakers.

 

Here's how we would like Express Delegate to work :

- all the three speakers send their dictations to the typist pool (2 typists)

- the two typists receive all the dictations from the 3 speakers with Express Scribe (kind of joblist)

- the two typists transcribe the dictations using Express Scribe and dispatch to express delegate

- finished dictations are removed from Express Scribe (the joblist) for the 2 typists (on next automatic sync)

 

Is there any way to configure it like this ?

 

For instance :

- i've tried to set a typing pool, created a rule to forward all the dictations to the typist pool, but the dictations only go to one of the two typists (i've read in the help file that dictations are sent to the first typist available...but i don't know why and how Express Delegate choose her ?). Not OK --> i need all the dictations to go to the two typists

 

- i've tried to set a single typist account, create a rule to forward all the dictations to the single typist account, and then i've set this single typist account in both Express Scribe. OK --> the two typists have the complete joblist with all the dictations, but when a dictation is finished and dispatch, it's removed from the Express Scribe joblist but only for the typist who did the job, i've tried to sync again and again but the dictations remains in the joblist of the 2nd typist, she have to remove it manually with the "delete" button.

 

 

Don't know if i'm clear or not (sorry for my poor english), but i really need some help.

Thanks for your help, byye

 

We're using :

- Express Delegate v4.00

- Express Scribe v4.29

- Express Dictate 5.05

[mpappert]

I am just about to do a similar test (with Typing Pools) and am hoping that EVERYONE assigned to a typing pool will receive copies of the dictation file. Here is my reasoning as to why this should exist (or at least as an "option" at the bottom of creating a pool - like a checkbox that reads "send to all typists" or something of the sort).

 

We have doctors that dictate in two languages (English and French) - we have transcriptionists for both languages. So, the transcriptionists download the cases and as they get to each one and start listening if it's their language they type it and send it - if it's not, they delete it.

 

If there is a better workflow for this type of scenario then please let me know ... otherwise, I second the request to have at least an option in the typist pools to send the dictations assigned to that pool to all typist recipients.

 

Cheers!

M.

[mpappert]

Also, this option is required as there is no "reject" option - i.e. if a transcriptionist downloads a case that s/he cannot type (language restrictions to use the same example as above) they cannot "return to queue" ... the only option that exists is one to dispatch it back which will mark it as completed. It would be nice to see a "return to queue" in Express Scribe but also, when editing the transcription in Express Delegate there should be a way to "unassign" the dictation and return it to the pool again.

 

M.

[Damian Lettie]

I am just about to do a similar test (with Typing Pools) and am hoping that EVERYONE assigned to a typing pool will receive copies of the dictation file. Here is my reasoning as to why this should exist (or at least as an "option" at the bottom of creating a pool - like a checkbox that reads "send to all typists" or something of the sort).

 

We have doctors that dictate in two languages (English and French) - we have transcriptionists for both languages. So, the transcriptionists download the cases and as they get to each one and start listening if it's their language they type it and send it - if it's not, they delete it.

 

If there is a better workflow for this type of scenario then please let me know ... otherwise, I second the request to have at least an option in the typist pools to send the dictations assigned to that pool to all typist recipients.

Unfortunately Delegate currently works with the limitation that one recording maps to exactly one transcript.

 

You could achieve what you want by getting the speaker to upload the recording twice, with a different tag each time (eg. <english /> and <french />, or <lang>english</lang> and <lang>french</lang>), then using rules to assign the English jobs to typist A and the French jobs to typist B, but that's obviously not ideal.

 

An official way of mapping one recording to multiple transcripts is definitely wanted.

[mpappert]

Thanks for the reply. So, as an interim solution until an official supported method is released, would it be possible to implement the forwarding feature (which gets disabled when using Delegate) or an option to "return to queue" so another transcriptionist can download the case?

[apcloic]

An official way of mapping one recording to multiple transcripts is definitely wanted.

 

Hi,

 

I really need this function, my clients are waiting for it and are not very happy with Express Scribe/Dictate/Delegate because of this problem...

Any idea when it will be released ?

 

Thanks for your help.

loic

[Damian Lettie]

I really need this function, my clients are waiting for it and are not very happy with Express Scribe/Dictate/Delegate because of this problem...

Any idea when it will be released ?

It is not in the current internal build of Express Delegate v4.01. No news about future releases.

[apcloic]

It is not in the current internal build of Express Delegate v4.01. No news about future releases.

 

Hi,

 

thanks for your fast answer, so we'll have to wait and maybe go back to dicta+ for a while.

Best regards, loic

[mpappert]

oK, so thinking outside the box ... one undocumented feature we've encountered (hopefully it is not a bug) is when a transcriptionist deletes a dictation the next time they "sync" it appears again. It stays in the queue until it's dispatched. So ... using this logic, could we create an email address (instead of a typing pool) and register every transcriptionist with that email address and they will get a copy of the dictations whenever they sync? Theoretically, it should behave that way given what I've seen with a single client setup.

 

Can you confirm whether this work-around could indeed work?

 

M.

[mpappert]

oK, so thinking outside the box ... one undocumented feature we've encountered (hopefully it is not a bug) is when a transcriptionist deletes a dictation the next time they "sync" it appears again. It stays in the queue until it's dispatched. So ... using this logic, could we create an email address (instead of a typing pool) and register every transcriptionist with that email address and they will get a copy of the dictations whenever they sync? Theoretically, it should behave that way given what I've seen with a single client setup.

 

Can you confirm whether this work-around could indeed work?

 

M.

 

Can someone from NCH reply to this please? I don't really want to "test" this now as we went live with one client on the new system and I don't really want to take a chance at losing anything.

 

Thanks,

M.

[Damian Lettie]

one undocumented feature we've encountered (hopefully it is not a bug) is when a transcriptionist deletes a dictation the next time they "sync" it appears again. It stays in the queue until it's dispatched.

If you delete an unfinished dictation from Scribe, only the local copy is deleted. As far as the server is concerned that dictation is still assigned to you, and still not finished, so it will reappear next time you sync. That's by design.

 

So ... using this logic, could we create an email address (instead of a typing pool) and register every transcriptionist with that email address and they will get a copy of the dictations whenever they sync?

I wouldn't recommend you do this. The first problem that comes to mind is that the dictation would be marked as finished after the first typist dispatches their transcript, leaving no other typist able to dispatch their transcript. (Otherwise it would violate the one recording to one transcript relationship mentioned earlier).