I'm new to Outlook (a physician trying to nudge his 4-doc practice from
pen/paper/19th century towards early 21st).
My first project with the SBS 2008 Server I've installed was to create a
calendar in a Public Folder on our Exchange 2007 server (part of the default
install of SBS 2008) for docs and staff to get an overview of who's working,
who's away, what meetings are coming up, etc. Right now, I've set it so that
I and the office manager are the only people who can edit the calendar
(she's not yet ready to do so), but all of us can view it.
Making this work correctly both locally, over OWA, and over Outlook Anywhere
took me several days (should give readers a clue as to my lack of
familiarity with how Outlook works under the hood). I'm not a TOTAL newbie,
however; I was able figure out how to make my Mac Pro tower at home accept
the SBS Server OS in a native installation on one of its internal drives and
run two different wireless networks for initial testing (one with dhcp
managed by the Server whenever I'd be testing, the other with dhcp managed
by one of my two 802.11n routers so that my wife and kids didn't shoot me
WHILE I was testing).
Having created our practice calendar (this isn't anything as ambitious as
patient scheduling - we'll leave that to a commercial electronic health
record that we'll purchase once our Uncle Samuel in DC tells us which ones
he endorses), I've started contemplating putting our patient demographic and
referring physician contact information into Outlook. This would be part of
our prep for our eventual installation of commercia EHR
Is it likely that a non-programmer could create a custom Outlook contact
form that would store additional fields that require patterned input; e.g.,
"social security number", or pick-list limited input; e.g., "referring
physician" (which would link to the referring physician's own entry in the
Outlook database) or custom check box fields; e.g., "active", "deceased",
"dialysis patient", etc..
The main purpose of this form would be to get this information into a simple
database that would provide us temporary access to it but also help prepare
us for the implementation of a true commercial EHR (we'd hope to be able to
export the data then for import into the EHR).
Thanks so much,
Jim Robertson