Due to privacy and security concerns, there are and will be circumstances
where persons will have more than one health identifier. In some
circumstances the identifiers will be associated and in others they will not
be associated and will not be recognized as belonging to the same person (or
even known).
As you've probably recognized, individuals may have more than one "plan" for
eligibility, insurance, payment methods, etc. And some of those plan-person
associations will include family or significant other members covered. I'm
not sure what your three tables you named below represent, but I'd have a
table of individuals, a table of "plans", a table of family associations
(two columns for each person and a column for the kind of relation {person
one relative to person two}), and a table of "plan coverage" with a column
for the plan account ID, plan ID, and person IDs. (Of course, with VA
FileMan judicious use of multiples will help maintain referential
integrity.) Visits, encounters, episodes, etc, would be associated with the
patient ID and the plan account ID. Billing would simply join all the
diagnoses and procedures associated with the visit episode (by time or
billing period).
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thurman
Pedigo
Sent: Tuesday, February 07, 2006 12:00 PM
To: hardhats-members@lists.sourceforge.net
Subject: RE: [Hardhats-members] Billing Module for VistA
I haven't carefully explored the VistA AR system, though what I have done
indicated that there are something like 11 options that appear to expand
into as much as 50-75 additional options seemingly geared to the VA needs. I
don't get much more help from the manual.
Continuing the discussion of Accounts Receivable (AR) management, I wanted
to test this groups thinking regarding relationships in the AR file. We
recently had discussions of identifiers, which drives quite a bit of my
concern. For over 25 years I have built the AR around a family oriented
structure. While it is a great tool, it gets awkward managing individuals.
We had recent discussion of identifiers without settling many issues. In my
thinking that becomes even more important in design considerations for AR
management. I am basing my concerns on some considerations presented below
and will ask guidance from this group. I must also share my prejudice that
that I consider a split system (separate but linked) a SERIOUS HANDICAP for
EHR practice management execution.
Since the early 80's I have listened to Mike Fitzsmaurice (ARQ), Ed Hammond
(Duke University) and others debate the identifier. In a 2005 document they
address recommendations - beware of wrap:
http://www.connectingforhealth.org/assets/reports/linking_report_2_2005.pdf
"...a health identifier as having six theoretical characteristics:
. Unique Only one person has a particular identifier
. Non-disclosing The identifier discloses no personal information
. Permanent The identifier will never be re-used
. Ubiquitous Everyone has an identifier
. Canonical Each person in the system has only one identifier
. Invariable A person's identifier won't change over time"
I plan to create three new files (ARFILE, RPFILE, & INSURFILE) related to
accounts management and insurance filling. I won't be surprised if I have to
add other new files before the project is complete. My interest is NOT to
build something using the identifier, but to anticipate potential problems.
Since interest remains in VistA billing, I wanted to share these thoughts
and get feedback. I expect to run the proposed AR system with ScreenMan
interface, though as I get more familiar with other VistA options I (or
someone) may find another interface.
Thanks,
thurman
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:hardhats-
> [EMAIL PROTECTED] On Behalf Of Greg Woodhouse
> Sent: Monday, February 06, 2006 2:41 PM
> To: hardhats-members@lists.sourceforge.net
> Subject: RE: [Hardhats-members] Billing Module for VistA
>
>
> --- Thurman Pedigo <[EMAIL PROTECTED]> wrote:
> > The
> > downside is it is in FileMan - not VistA and it has a few files not
> > represented in VistA.
> >
>
> What do you mean? There is nothing wrong with creating new files (so
> long as you stsay within your namespace and numberspace, to avoid
> possible conflicts with other VistA modules). In fact, it is be
> expected that new applications (modules) will introduce new files.
>
>
> ===
> Gregory Woodhouse <[EMAIL PROTECTED]>
> "All truth passes through three stages: First, it is ridiculed.
> Second, it is violently opposed. Third, it is accepted as
> being self-evident."
> --Arthur Schopenhauer
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Hardhats-members mailing list
> Hardhats-members@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
