cancel
Showing results for 
Search instead for 
Did you mean: 

Web BLOB pass-through and document corrections

Joel_Fabrey
Confirmed Champ
Confirmed Champ

Hello, we are looking at implementing the web BLOB pass through. The MRG says that 

Epic will remain the source of document corrections for Web BLOB Pass-through documents. With this integration, documents that are routed from the Epic BLOB will be editable in Epic and read-only in OnBase. This means document corrections are triggered through Epic and registered within OnBase

Does this mean that the healthcare corrections process needs to also be implemented so these docs can be corrected? We want to allow docs to come in through epic but they go through substantial workflow processes that may change keywords and even document types - will this no longer be possible of they come from the BLOB?

 

thanks,

Joel

1 ACCEPTED ANSWER

Julia_Tabaj
Employee
Employee

Hi Joel, 

Any Web BLOB Pass-through document in OnBase is locked down. OnBase cannot edit the image or the keywords for that document. Because of that, any correction needs to take place through Epic's processes. If a clinician ends up sending a WBP document to document corrections through the Healthcare Corrections button, the current workflow your organization uses for managing corrections should be edited to filter these documents into their own queue. That queue can then be used a list to login to Epic and fix. Ideally though, the clinicians would continue using whatever process they have in Epic to fix those documents. In general, these documents are opened from the single document links using Epic's viewer - which will not have the OnBase Healthcare Corrections button. But if they open them in OPW, they could send it to workflow that way - which is why we would want to have the queue. 

Thanks

Julia

View answer in original post

11 REPLIES 11

Julia_Tabaj
Employee
Employee

Hi Joel, 

Any Web BLOB Pass-through document in OnBase is locked down. OnBase cannot edit the image or the keywords for that document. Because of that, any correction needs to take place through Epic's processes. If a clinician ends up sending a WBP document to document corrections through the Healthcare Corrections button, the current workflow your organization uses for managing corrections should be edited to filter these documents into their own queue. That queue can then be used a list to login to Epic and fix. Ideally though, the clinicians would continue using whatever process they have in Epic to fix those documents. In general, these documents are opened from the single document links using Epic's viewer - which will not have the OnBase Healthcare Corrections button. But if they open them in OPW, they could send it to workflow that way - which is why we would want to have the queue. 

Thanks

Julia

Thanks - we have a fairly extensive and highly automated corrections process - I'm not sure if we should integrate it with that or implement the canned corrections process, with the canned process we would be more in line with the London build and it would be easier to administer having to know just one version instead of 2 complex processes. Oh well, decisions, decisions!

@Julia Tabaj ,

 

I am very confused now. The way you are talking is that the documents will stay in the Epic BLOB server. However, the way that the WBPT was described and informed to us is that any documents going forward of the implementation would be redirected to OnBase. As well, if a document is pulled up in Epic, then a copy of that document will then be sent to OnBase all-in-all making OnBase the primary source of the documents. Is this not correct now? Are you truly saying that the documents would remain in the Epic BLOB server?

 

Thanks.

Sorry for the confusion. Documents that are enabled for WBP are in OnBase, yes, but when Epic calls out to open them, they are using Epic's native viewers. So if you clicked a blue hyperlink or a row in Media Manager for an After Visit Summary (something that can be passed-through), the viewer that opens is not a Hyland viewer, it is Epic's document viewer. 

The document itself lives in OnBase, but to an Epic end user, it wont look like anything changed - including the correction process. 

Everything you said is correct except the document's get sent to OnBase when they are created, not when they are accessed for viewing. 

Does that help clear it up?