Kern:
Understand. Not an easy situation. But entirely normal in this field of
endeavor.
Did not snip anything on this post. If it carries on pieces should be
snipped....
Kern Carboni writes:
Quote
Hi Dave;
Yeah; I have been dropped in the deep end but surviving so far;
I need to knock up a dictation system pronto to replace our existing system
which has
proved unusable since purchased.
Situation normal.
Quote
A simple use case - radiologist scans an unreported xray film which has a
visitnumber barcode;
If everything is being driven from the visit -- then I'd consider
the design wrong. Others may think different. Presuming this is a
clinic... still
As I asked previously -- Is this a clinic taking only appointments? If
so the design is simpler than emergency + appointments. What is your
situation?
Quote
The screen then needs to be populated with the patient's details plus entire
visit history incase radiologist needs to view previous visit.
Why the patient details at this point? Looks like there is no Patient DB
filled in previously? This should be a lookup since I presume that a
Patient Record must be created at some point. Or you create an appt, a
dummy patient ID and then fill in the other details when they arrive. Do
you not need to know the nature of the exam so you can allocate
equipment and schedule beforehand? If you have one piece of equip. this
is not relevant of course... (MRI, CAT scan, _small_ clinic.)
Adding Appt. DB and Patient file could do some wonders for your design?
Is this in Delphi? If so you could use the Old Paradox File format if
you are version 7 or below and add some DB tables that could make the
work flow issues simpler to deal with.
Quote
The radiologist then dictates report. On saving,
the report is attached to visit, visit updated and sent to intranet. The
patient object is then
moved to a workflow list on screen so radiologist can monitor workload.
This tells you what happened.... Doesn't tell you future workload --
which in my opinion is more important... Unless you mean that you want
to display a tally sheet showing finished reports vs. waiting cases. The
it does - sort of. What are the issues?
Quote
Problem is I am designing for an existing legacy db (15 year old c-isam) so
a new db or refactoring is impossible;
Not really. Add needed DB's in a new DB format. Paradox, Interbase or
whatever. It does add some complexity -- but it is manageable. Done that
before. It can work. If you have not tackled it before it can seem
overwhelming though. Just step by step, inch by inch... :-))
Quote
The database has the following tables which I have loosely mapped to
corresponding objects:
Patient - no links to visits
Visit - linked to Patient via patient_number
Ahhh!! This is correct. You add a table or do queries to support this.
Whether OO or SQL queries or other ways - doesn't matter. Missing appts.
is problematic in the entire project though...
Quote
VisitReport - linked to visit via visit_number and each line in a report is
a row in db ie visit number + line number + report text (80 characters)
Doctor - linked to visit via doctor_code
No problem here this is as it should be.
Quote
I am really just fiddling at the moment, trying to get a feel of things;
hence the questions of the patient->visit relationship;
Look at the visit as the "centre of the universe" - with links radiating
to the visit, and the report (and the appt. and requisition links --
which do not exist). :-)
The visit and the report should be the result of the appointment +
requisition. In other words it is data collection.
This gives you a simpler model for the DB and the OO design.
Not sure what your table design here is exactly it should be .... (I think)
Visit (table) (V) (Visit#, PatientID, other req info)
-->Exam Item (Table with rows) (EI) Visit#, ExamID
-->Procedures Performed (PP)
Visit#, ExamID,Procedure(exam/film)# (row in PP table
Reports should be something like (IMO)
Report (Table) (R) (ReportID, Visit#, RadID etc...)
-->Report Lines Table (RL) (ReportID,VisitID,ExamID,Line# etc...)
(: Note 3 FK's in above table)
I am ignoring supporting DB's as there should be a table of coded
allowable exams - there always is a set of exams which are allowed by a
gov't medical systems and anything else won't be paid -- this I know...
There should be a report record (and Object) for each diagnostic
procedure performed -- at least in the local rad. universe -- according
to my specialist here. :-)
It should even allow multiple reports (lines) on the same ExamId as
often second opinions are garnered... And it should allow multiple
reports by the same physician -- as they often re-examine films/records.
(Verified by in-house specialist.) In other words... Multiple reports by
any number of rads.. Or consider it "pre-broken".
The if you "load up" a record it becomes easy to create and populate the
objects on the fly.
Quote
Thanks for the comments
Other people may have other opinions.... :-)
However, this while very terse should give you a "kick-start" if you
have never done a scheduling/data collection integrated application.
However (#2) this is only an open ended data collection system as it is
with no "closed loop". This allows missed reports and missed appt.
verification. IMO -- a bad system. (Others may disagree here too.) But I
do not see the system as professional and "workable. Again peoples
opinions may vary, and I see design like this all the time. Did I say I
did not like that methodology? :-)
Quote
Kern
"DaveR" <XXXX@XXXXX.COM>writes
news:XXXX@XXXXX.COM...
>Kern:
>
>You may be tackling the object design a little early in the process --
>but then maybe you just haven't told us the whole story. :-)
>
>See below...
>
>***********
>
>Kern Carboni writes:
>>Kiaora;
>>I've been struggling with this so I thought I'd ask the gurus;
>>
>>Currently I have a TPatient class with a TVisitCollection;
>>The patient number will be rarely used for this small project, with
most
>>users interacting with the system via
>>scanning of a visit number. Using the visit number I'd like to end
up
>>with the relevant Patient object and
>>all of their related visits including the current visit.
>
>Don't see the relationship between visit and patient -- unless there is
>an appointment. Do all visitors have appointments? (Read requisition if
>that terminology is better.) Hospitals (and clinics that handle
>emergencies) can behave a bit differently than clinics -- that is why I
>ask...
>
>This sounds like a clinic -- as opposed to a hospital application. Is
>that correct? If so then yes -- you _need_ an appointment book -- other
>wise the design gets messy.
>
>Hospitals should always -- but might not -- have a requisition --
>assuming emergency cases where the paper might follow later or the
>requisition might be made up later (...if during a surgery another view
>is requested and you are recording what happened as opposed to a
>prescribed set of views).
>
>>Seemed a bit messy
>>capturing the visit number, looking up the
>>visit, reading the patient number from the visit and then populating
the
>>patient and visit objects.
>>
>
>It is -- see above.
>
>>I have read posts that indicate that the above is probably not the best
>>design anyway and I should look at incorporating a third
>>class ie TAppointmentBook(??) which could handle such intracacies
>with a bit
>>more style.
>
>Yes see above. and below...
>
>>
>>Any comments/pointers appreciated
>>
>
>Most "large" systems are messy... BTW
>
>You really should do the System and Database design first or this gets
>really messy. Or maybe you have and aren't sharing -- yet. :-)
>
>This is a classic scheduling and data collection problem. (Presuming it
>is a clinic and I think it is by your questions.)
>
>
>E.G. ...
>
>Requisition is supplied and appointment is made...
>So you have the appointment and the "work" to be done. The appointment
>book method will be used I presume - and is fairly easy -- one db entry
>per patient per visit -- and any number of procedures in a "test
>schedule" DB... attached to the visit item (we have at least the
>following DBs at this point -- patient, appt record, test items)
>
>The patient arrives (in the future) and gets "logged in".
>(we now need a visit log to tie to the appt. you might get a 2nd visit
>tied to the appt. or you might insist on a new appt. -- your call)
>
>The diagnostic procedure is done and the data is collected.
>(results get attached to req. test items -- so we need at least one
>m,ore DB - and set of objects here.)
>
>I presume that in some procedures the examination is repeated. (The
>patient is asked to wait while the film is developed, or computer images
>are reviewed by the rad. or the rad. tech. makes the decision to repeat
>if image quality is not up to standard. (So you need to log quality info
>in a DB as well.) (At least one more DB and object set here.)
>
>(If you do mamos, I know that here at least they have a quality
>assessment program which means additional tracking and reporting. --
>this can wait...)
>
>The exam may then be repeated. So each exam may actual collect multiple
>data sets.
>
>You need then to attach diagnostic info and reporting. (another DB and
>object set here)
>
>You may also need to link previous visits to new requisitions so that
>you can tie events together. (at least one table here...)
>
>You may also want to consider a machine DB and a machine availability
>schedule - since they are your limiting factor and are usually easier to
>schedule than the techs... (and you then have to design all the related
>objects.) Besides -- if the machine is "down" or has scheduled
>maintenance you want your appoints either moved, or simply not booked in
>the affected periods.
>
>
>I have used DB where I was not sure if more than one table is
>appropriate and table where I was sure that it was a simple relation.
>(But remember what you paid... :-) )
>
>Haven't covered anything I think would be obvious to you -- Tables (DB)
>for Rads, Techs, etc. (And associated objects...) Nor Have I covered the
>availability schedule for same as I think the extension from the info
>above should be obvious... If not you can always ask.
>
>
>Hope that helps.
>
>And yes - I have designed scheduling systems since you ask. :-) And yes
>I do know a bit about Rad. depts. since that would be your second
>question. And to answer your third question - No -- not as much as you
>about the Rad. depts. -- but that person is a desk away. :-)
>
>
>
>>Regards
>>Kern Carboni
>>Fulford Radiology
>>New Zealand
>>
>>
>
>
>--
>Dave.
>PMC Consulting
>pmccl.com
--
Dave.
PMC Consulting
pmccl.com
