Feature request: "merge" fields for note templates

[wjstarck]

If there is a way to somehow create "merge" fields in the note templates it would sure be nice!

For example, right now I have a note template for D0150 that looks like:

__ yo __ __ referred by ___________ for _____

BP- P-

PMH: *Noncontributory
MEDS: *None
ALL: *NKDA

PE: *No oral masses or lesions. TMJ and neck normal. ____________

PANO: ________
A: ____________
P: ______________________ Disc. risks, benefits and complications. Informed consent signed. - WJ Starck, DDS

Where everything that is ____________ is filled in by hand, including the *'d stuff if that is anything other than normal. This is incredibly tedious/laborious, especially since the staff has already typed this info somewhere else in OD, and I have to exit the chart module to go to the family module and look up the patient's age and referring dentist.

So, wouldn't it be nice if instead OD could pull data from the database and fill in this info for me:

<<age>> yo <<race>><<sex>> referred by <<referral>> for <<chief complaint (maybe this field could be added?)>>

PMH: <<medical history>>
MEDS: <<meds>>
ALL: <<allergies>>

PE: (would still have to be largely hand typed)

PANO: (would still have to be hand typed)

A: (would have to be hand typed, since dentistry doesn't have the equivalent of ICD-9 codes)
P: <<treatment planned codes>> and<< tooth numbers>>

Hope that's clear - thanks for listening

[sparkly]

i belive that's exactly what EagleWing is working on with AutoNotes. it shows up in version 5.4. there's a post about it from the last couple days about possible bugs/function/tutorial.

[wjstarck]

From what I can see so far, AutoNotes is different from what I'm talking about...

I want special fields that will be filled in automatically from data already entered into OD, kind of like merges work in Word.

[jordansparks]

We actually just built a framework for that. So far the only part of OD to be moved over to that framework is the labels function in version 5.4. But I consider that to be very important. We make a major thrust in that direction about once a year, but each thrust has so far largely fizzled. Maybe the current thrust will be the one that pans out. I think the latest solution is quite elegant and extensible. Anyway, watch out for it in the future. We've called it "sheets" internally. A better name would be "forms", but that name has just been so overused that we had to pick something else. The goal of the sheets framework is to handle nearly all printing functions except reports. So that would include statements, treatment plans, postcards, simple letters, referrals, etc. Pretty much anything that you print except reports. Usually you're talking about one "sheet" for one patient. It would also (and this is the exciting part) also handle all input forms. This would include consent forms, registration forms, medical history forms, etc. Even forms for the staff to fill out on screen to automate office processes. Lots and lots of potential with sheets. It would naturally include images.

I have no idea how long it will take this new framework to mature to the point where it will include all the fields you listed, but I suspect it won't take long. You wouldn't actually have to print the sheet for it to be retained as part of the record.

[wjstarck]

I just nominated you for the Nobel Peace Prize.

Thank you!

[sparkly]

wj-sorry for the bad suggestion. i saw the blanks and missed the most important line of your question. i'm not used to actually having to READ the <<code>> .

is this 'sheets' way of integrating info directly from the databases going to be included in email generation/automation? we've been dying for the last year for customizable emails, especially in the recall area (where all you can generate is a postcard printout...yes, i know you can then email the document you generate, but patients already have short attention spans and i'm not about to ask them to start opening attachments).

to pull data out like that (preferred name, age, date/time fo next appointment, date of last appointment, etc etc) will definitely go a long way in making the office look good to patients (personalization is a +) as well as making all users' tasks much easier and faster. hope it makes it into a more robust email-capable OD.

[jordansparks]

It's a very good idea, and something that we should strive very hard for. I can't give you an immediate answer to that question because of the complexity. It's something we'll have to mull over for a while. One alternative is to enhance the email merging functions entirely independently of sheets. We'll see.