DB protocol on CL6.0 – couple of questions

[Donna Bailey]

I am new to using this DB protocol…but am working on setting up an interface with it.  We’ve got the DB schema set up and the protocol thread reads the file into the engine…..

1. It comes into SMAT as a VRL, comma delimited file….so do I need a VRL configured to use this data in a translation now?

2.  Can we delete the record from the DB once it’s read in? Or would it be better to have a field designated to say the record was processed already?

3.  Can we delete or modify the DB on the inbound protocol for either option in #2?

Thanks for any help I can get!

Donna

Donna Bailey
Tele: 315-729-3805
dbailey@microstar.health
Micro Star Inc.

Topic

[Peter Heggie]

Hi Donna,

1) the VRL is created for you internally when you configured the Table Schema  (specified the database schema, table and columns). So it is available in the translator configuration – instead of selecting HL7 for the format, and then the version and then the message/event type, you select Database Schema as the format, and then when you select the Connection and Table Schema, the vrl will show up on the inbound side of the translator.

2) whether to delete or not to delete, that question is an application design issue. If these rows are used for other purposes, then you probably want to leave them there, and maybe mark them as retrieved, but that introduces a timing issue – if more rows are added between the time of the retrieval and the time of marking them as retrieved.

The inbound protocol does allow for post-query actions – success or failure queries, and you could use those places to mark the rows as retrieved but there is no guarantee that a new row has not come into the table since the original retrieval. But it could be done if you use a more complex query, like a stored procedure that creates a timestamp, selects all rows that you want and updates them with the timestamp, and then retrieves all rows that have that timestamp.

We use a post-query success query to delete the rows, and we decided ‘not to worry’ about new rows coming in between the inbound query and post-inbound query because there are so few rows and the protocol/query is so fast.

3) yes, you can delete – for our inbound DB protocol, the Read Action content was a select from

, and our Read Success Action was a delete , basically deleting all rows.

Peter Heggie

[Author]

Replies