Handwritten / INK notes as an option for a Visit Note in Synapse

Theoretical mockup.

The problem with most of these approaches is that the content of that encounter is now in a 3rd party container.

And we don't get to see what was written without having to load it up.

Problem: content in 3rd party container.

Benefit: faster than typing, more patient-centered, easily done while with patient, natural, similar to what non-computer docs are doing, easily review last notes, easily find similar notes (ie. last physical).

Regarding the control-key issue ... I believe voice activatation can turn that on.

As for inking ... this is the scenario I am suggesting:

• choose a PDF template eg. Llayne's FU pdf template
• Invoke PDF annotator
• Ink appropriately
• Save and close PDf Annotator
• Click on "import pdf" ... and it gets saved to the Synapse database in cache-listener.

ie. similar to export and import to Word.

Hey PainDoc, How about using Paper ? Read "The Paper Bridge".

Paindoc, would the restriction of having to select the "Form"/"Template" before printing be too restrictive ?

Put another way, would you be wanting to add "other" forms/templates after you printed a Paper Bridge Form ?

• choose a PDF template eg. Llayne's FU pdf template
• an entry in the "Consults" section is made (which will link to the item).
• Synapse Invokes PDF annotator opening the selected template in cache-listener, or some temporary directory or the Windows Explorer Directory.
• Ink appropriately
• Save and close PDF Annotator
• <strike>Click on "import pdf" ... and it gets saved to the Synapse database in .</strike>

How about this edit version ?

PainDoc Note: this method as described thus far would create 1 .pdf per encounter.

Is this what you would prefer ?

Or would you prefer my method ? I open the patient's "ink notes" file (one file per patient) and I add the images I need to use for that day, as I see the patient and ink on the images or just freehand. I use plain old Windows Journal files for 95% of patients, and 5% of my patients are on Magellan Writer (Company might be bankrupt). I was always planning on migrating to Magellan (BTQnet)'s new INK app, but development has stalled due to lack of money.

What are the drawbacks of my method:

(1) No internal document versioning - note: no current standalone inkable file format has versioning.


I add successive notes to the same document. Windows Journal files (and Magellan Writer) are not versioned. I think this could cause problems in a court of law, as I can easily change any old note. (Maybe this is a good thing, power to the doctor !). However, realizing this limitation, I have setup a unique backup system, that I feel constitutes a legal method of document versioning. Essentially any time a note changes, my backup program makes a copy of it. If the lawyers wanted to know what my patient's chart looked like on any day, I could find the appropriate backup.

What are the bonuses of my method:

(1) you can see old notes. I can't describe the pleasure of using the scrollbar to review my old notes. Nothing like reviewing everything I ever wrote about a patient by just dragging the scroll bar. I find it extremely useful and effective.

As a slight bonus to the Windows Journal users of the world, you can now *EDIT* (and view of course) Windows Journal on plain Windows XP (and Vista) as some keen XP hackers brought Windows Journal to XP (I've installed it and it works great !).

I have PDF Annotator ... always searching for a use for it . It has gotten quite good over the last 6-12 months. The method of adding "templates" to a PDF annotator .pdf would be through the convenient [Add image] ... it works quite well. If you use large images and colour the PDF file sizes will bloat but that's not too worrisome if you are going to have one file per encounter.

The workflow would be (1) print an encounter sheet, (2) see the patient and ink on it, (3) drop it in the scanner, (4) the item automatically files itself. That's pretty good. Consider this workflow for Patient consent forms ?

Synapse would be able to link to the .pdf. and if "tagged" the visit's consult entry, you could easily find previous encounters.

Your edit version won't work ... Synapse has to know when to import the document/pdf.

The PDf Annotator FAQ says to wait for Annotator to close, but that means Synapse would go into a blocking wait ... which is no good.

But the question remains .. how to attach this to a consult?

It could be added as an attachment ( which also means adding as a result ) ... but currently attachments do not show in the new view . You have to switch to classic view to see attachments.

And then you're going to have to click on it to load it up .... instead of what we have now ... viewable by expanding the consults.


Is that what you really want?

Why can't it just know what the name is ..... and link to it. It is too limited to just be able to import DONE items. If cache-listener needs a MD5 hash then can another directory be used ?


Alternatively, maybe the documents can be named such that they can be Auto-imported ? The workflow might be that if the doctor saves the files to the import directory, they will be automatically imported based on filename. If saved elsewhere, (ie. where the PDF was created by synapse) they would stay there until the doctor moves them to the import directory.

No. It isn't appropriate to do the attachment via results method.

Won't work .. the cache-listener is not accessible to clients.

remember, this is n-tier architecture.

Is it possible to have a different directory for "PDF visits", other than cache-listener ?

Permanantly ?

Temporarily ?

Let's say we have a button that creates a blank Journal file in the patient's paperport directory.

We also create a blank encounter entry that we can put some metadata for the Journal file.

And then maybe we need to be able to import that Journal file into the cache-listener for archiving.

And also a button to access the Journal file ....

BTW, there seems to be absolutely no information on Journal's com interface on the MS website.

I doubt it has one.

I'll ask around.

COM interfaces seem more for "apps MS can charge $$ for". COM = COMmerce ? []

Looks like you're right.

I tried creating a Journal.application and that gave me an invalid string.

This is an open source Journal type program written in Javahttp://www.dklevine.com/general/software/tc1000/jarnal.htm

Have a play ... maybe I can use this instead of Journal.

It can't embed images which is the major time saver.

Inking on images = fast.

You need to elaborate further.

I was able to open up a pdf as a background and ink on it.