Do we need to store a whole document for every document we create?

Hi everyone,

A recent discussion raised the scenario that there are many documents that may be printed for a Customer or Patient that are largely static in content. These include documents with merged content and without. Whilst the event of creating and printing such a document for a customer/patient should definitely be recorded within their medical record and the nature of its content be confidently demonstrated, do these documents need to be stored as a whole document every time they are used? Could just a placeholder indicate the document was used for the Customer/Patient? Currently OpenVPMS stores every document as a document within the database. Is this an unnecessary use of space?

To give an example,

Patient A gets a "All you need to know about Pet insurance" handout. The medical record shows that the patient received the handout. If I want to see what the Patient received, I need only bring up the handout content. If the handout is revised/updated, versioning (storing old version) should allows us to accurately document the content of the handout to meet any legal/regulatory requirements. In this arrangement, the document is stored once within the database rather then a copy of it every time it is used.

I also think there might be an advantage to start classifying our documents so that we can group and filter our documents better. If you are like us and have many patient forms, when choosing from a list it can get unwieldy. Making sure you name them cleverly so they sort well is a good step, but people might just want documents relevant to a particular step to appear, or a Group filter that allows you to just see, "aftercare" or "admission" docs.

Cheers,
Matt C

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Do we need to store a whole

Hi Matt,

Actually not all documents are stored in the database for every instance.  Any customer or patient form is merged from the associated template at time of view or print.  So in your scenario above if the handout is a form then no document is actually stored in the patient clinical record and there is just the one document for all instances stored with the template.

Other documents such as letters, attachments, images are obviously stored per instance which makes sense.

The idea of a grouping fiedl is a good one.

Cheers

Tony

Re: Do we need to store a whole

Hi Tony, My mistake. I thought it created a unique document every time we created a patient/customer form. Boy my staff seem to like attaching stuff to clinical records! Our Documents section of the database is nice and fat!

With respect to the grouping, what do you think the best option is? i) A classification system where a document may belong to one or several groups or ii) A system where the document can be assigned to a single group?

Whilst multiple groupings is intuitively what I would like (just like adding classifications to customers/patients) how might this be applied to the task of filtering selections in the Document browser?

Matt C

On Mon, 26 Oct 2009 06:12:41 +0000 (UTC), tony@openvpms.org wrote:

> Hi Matt, > Actually not all documents are stored in the database for every instance. 

> Any customer or patient form is merged from the associated template at time

> of view or print.  So in your scenario above if the handout is a form then

> no document is actually stored in the patient clinical record and there is

> just the one document for all instances stored with the template. > Other documents such as letters, attachments, images are obviously stored > per instance which makes sense. > The idea of a grouping fiedl is a good one. > Cheers > Tony > _______________________________________________ > OpenVPMS User Mailing List > users@lists.openvpms.org > To unsubscribe or change your subscription visit: > http://lists.openvpms.org/listinfo/users > Posts from this mailing list can be viewed online and replied to in the > OpenVPMS User's forum- http://tinyurl.com/openvfu >

_______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu

Re: Do we need to store a whole

Hi Matt,Can you give me an example of when you may need multiple classifications on a document ?Either way we woudl need to provide an additional filter on the document search dialogue.  If use classifications I assume you would some kind of multi selector rather than just a combo box ? CheersTony On Mon, Oct 26, 2009 at 8:24 PM, mpcosta <mpcosta@boroniavet.com.au> wrote:
Hi Tony, My mistake. I thought it created a unique document every time we created a patient/customer form. Boy my staff seem to like attaching stuff to clinical records! Our Documents section of the database is nice and fat! With respect to the grouping, what do you think the best option is? i) A classification system where a document may belong to one or several groups or ii) A system where the document can be assigned to a single group? Whilst multiple groupings is intuitively what I would like (just like adding classifications to customers/patients) how might this be applied to the task of filtering selections in the Document browser? Matt C On Mon, 26 Oct 2009 06:12:41 +0000 (UTC), tony@openvpms.org wrote: > Hi Matt, > Actually not all documents are stored in the database for every instance.  > Any customer or patient form is merged from the associated template at time > of view or print.  So in your scenario above if the handout is a form then > no document is actually stored in the patient clinical record and there is > just the one document for all instances stored with the template. > Other documents such as letters, attachments, images are obviously stored > per instance which makes sense. > The idea of a grouping fiedl is a good one. > Cheers > Tony > _______________________________________________ > OpenVPMS User Mailing List > users@lists.openvpms.org > To unsubscribe or change your subscription visit: > //lists.openvpms.org/listinfo/users" target="_blank">http://lists.openvpms.org/listinfo/users > Posts from this mailing list can be viewed online and replied to in the > OpenVPMS User's forum- //tinyurl.com/openvfu" target="_blank">http://tinyurl.com/openvfu > _______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: //lists.openvpms.org/listinfo/users" target="_blank">http://lists.openvpms.org/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- //tinyurl.com/openvfu" target="_blank">http://tinyurl.com/openvfu

-- ______________________________________________________________________Principal ConsultantVertical Connect Pty LtdPhone :  +61 (0) 3 97229824Mobile:  +61 (0) 4 21347105Email   :  tony@verticalconnect.net Web    :  //www.verticalconnect.net">http://www.verticalconnect.net

Re: Do we need to store a whole

Hi Tony,

One example might be where a document could serve equally as a pre procedural information handout and a post surgical handout. Some documents may be appropriate to fit in many categories, such as information about pet insurance which might be accessed from future work-flows by receptionists or consulters.

In the future it may be desirable for users to have their own "favourites" document list. eg. 3 specialists working on the same system but sharing exclusive and non exclsuvie documents. A multiple classification system would allow individual documents to appear in multiple lists.

 

My conception is classification to be applied in the following hypotheticals:

1. In filtering of the general document selection browser.

2. In default filtering of document browsers as part of worklfows.

eg. Admit workflow defaults to "Admission" docs. Discharge workflow defaults to "Discharge" docs

3. In User or Group defined lists (more of a permissions settings perhaps, but it may be that the system needs to be more liberal then a permissions system might allow. The Orthapedic surgeon may need to print an Internal Medicine handout from time to time.)

 

Other filtering that could be useful;

1. Species specific docs

 

Cheers,

Matt C

 

On Tue, 27 Oct 2009 08:07:46 +1100, wrote:

Hi Matt,

Can you give me an example of when you may need multiple classifications on a document ?

Either way we woudl need to provide an additional filter on the document search dialogue.  If use classifications I assume you would some kind of multi selector rather than just a combo box ?

CheersTony

On Mon, Oct 26, 2009 at 8:24 PM, mpcosta <mpcosta@boroniavet.com.au> wrote:

Hi Tony, My mistake. I thought it created a unique document every time we created a patient/customer form. Boy my staff seem to like attaching stuff to clinical records! Our Documents section of the database is nice and fat!

With respect to the grouping, what do you think the best option is? i) A classification system where a document may belong to one or several groups or ii) A system where the document can be assigned to a single group?

Whilst multiple groupings is intuitively what I would like (just like adding classifications to customers/patients) how might this be applied to the task of filtering selections in the Document browser?

Matt C

On Mon, 26 Oct 2009 06:12:41 +0000 (UTC), tony@openvpms.org wrote: > Hi Matt, > Actually not all documents are stored in the database for every instance.  > Any customer or patient form is merged from the associated template at time > of view or print.  So in your scenario above if the handout is a form then > no document is actually stored in the patient clinical record and there is > just the one document for all instances stored with the template. > Other documents such as letters, attachments, images are obviously stored > per instance which makes sense. > The idea of a grouping fiedl is a good one. > Cheers > Tony > _______________________________________________ > OpenVPMS User Mailing List > users@lists.openvpms.org > To unsubscribe or change your subscription visit: > //lists.openvpms.org/listinfo/users" target="_blank">http://lists.openvpms.org/listinfo/users > Posts from this mailing list can be viewed online and replied to in the > OpenVPMS User's forum- //tinyurl.com/openvfu" target="_blank">http://tinyurl.com/openvfu > _______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: //lists.openvpms.org/listinfo/users" target="_blank">http://lists.openvpms.org/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- //tinyurl.com/openvfu" target="_blank">http://tinyurl.com/openvfu

-- ______________________________________________________________________Principal ConsultantVertical Connect Pty LtdPhone :  +61 (0) 3 97229824Mobile:  +61 (0) 4 21347105Email   :  tony@verticalconnect.net Web    :  //www.verticalconnect.net">http://www.verticalconnect.net

Syndicate content