Ignacio Valdes Implementation Log/Episode4

Keane records integration/population

[Keane [1] is a commercial vendor of financial software designed for Long Term Care facilities.]

Ignacio Valdes Date: Thu, 17 Jul 2008 14:53:20 -0500

Dave applied the Chris Uyeh patch at http://pastebin.com/f6aa67ea and authentication now works. Next step is to begin configuring and think about populating/integrate the system with whatever we can get out of the Keane financial system. Midland might work with Keane, apparently Keane has some interest in doing this. How does one do this?

-- IV

Chris U Date: Thu, 17 Jul 2008 13:55:06 -0700 (PDT)

Short term - comma delimited dump? Will you be doing double entry? If so, how long? Possibly looking at an interface?

Just some thoughts for you to chew on, Chris

Ben Mehling Date: Thu, 17 Jul 2008 15:56:22 -0700

Ignacio-

Midland is not a Keane shop, although other customers have interfaced with Keane. Is your plan to use a real time interface or do an MPI conversion at the time of go-live? What type of transactions are you looking to support? What type of patient population and movements are required?

- Ben

I, Valdes Date: Thu, 17 Jul 2008 21:00:49 -0700 (PDT)

Probably two events really define the data flow between Keane to VistA: admission and discharge. So all the useful (probably demographic) data getting entered on admission should appear in VistA nearly simultaneously. -- IV

Ben Mehling Date: Thu, 17 Jul 2008 21:52:58 -0700

Ignacio-

New registrations should also flow across the interface. Would you handle transfers and other patient movements (e.g., ASIH, etc.) w/in VistA, using the native menu options? In other words, would your staff do all admission and discharge work in Keane, then switch to VistA for other movements?

You also need to consider master files that will require synchronization or maintenance, such as NEW PERSON, RACE, RELIGION, etc. Those files/codes will need to match between the two systems.

- Ben

Vipen Mahajan Date: Fri, 18 Jul 2008 22:04:38 +0530

I have worked on Open Source (Free too) ERP/CRM, Compiere/Adempiere/OpenBravo. It can handle the financials, and can be modified for the missing links, provided someone can define them. It should also be possible to add the Practice management part. Besides having inbuilt multi-currency etc features, it can be readily extended, as it is a meta-data driven application, which can be ASP hosted.

Can anyone team up with us for the specs and a beta site? (Thanks to Hardhats, I know enough VistA to be dangerous ! ).

-- Vipen Mahajan

Nancy Anthracite Date: Fri, 18 Jul 2008 13:32:11 -0400

In other words, you are looking for someone with a live implementation to volunteer to be the test bed for this, not a development server to work on as a cooperative project, correct?

-- Nancy Anthracite

Vipen Mahajan Date: Sat, 19 Jul 2008 00:16:52 +0530

Nancy, I am looking for a partnership, or whatever, so we can develop extensions to Open Source VistA, so it can be a global solution. We intend using the Open Source process to develop the requirements of the modules to be added to VistA, then we will develop the software, and test it out on the beta site.

Additionally, if we can be given the VistA configuration steps/process, we can develop the complete implementation process (VistA + ERP) for three segments of clients, small practices/GPs, clinics, med size hospitals (< 50 beds), large hospitals (51-2000 beds). The processes and solutions would differ for each segment, probably ASP hosted for clinics and mid size hospitals and in house for the big guys. We can provide in-built multi-language facilities.

My biggest hurdle has been what is VistA? After 2 years of cracking (not very whole heartedly though, but as a back burner project, off and on), having played around with QEMU and Bhaskar's Toasters (a big help, thanks KSB for the help), and Medsphere's OpenVista, read about the VistA monograph,, I donot know what can be done with VistA, there being no business process based documentation of the processess in Health care, and how VistA can automate/streamline them, and what needs of the above segments are not addressed in the existing VistA solutions (which VistA makes sense is another challenge), How to secure it, and keep up with the patches, additionally software needed (imaging?, CPT codes and what not).

I prefer to build and test it with a live beta site as in my experience that makes the developed software much more realistic, else I have noticed that the requirements wish list just bloats up.

Will need to stoke up the Open Source ERP community, get folks interested and also build a small dedicated development team (probably India based) who knows enough about VistA,MUMPS, Java and the OSS ERP and can be the anchor for the Sourceforge intended project, with a proper CVS, source control, etc. like what is already being done for the Open Source ERP project.

With VistA's functionality, this should be a far better than many of the existing FOSS Health Care packages based around Php etc. Like VistA it will be scaleable.

Vipen Mahajan

Fred Trotter Date: Thu, 24 Jul 2008 14:08:30 -0500

Medical Accounting and Billing is not equivalent to ERP. The differences are:

Medical Accounts Receivable Needs to support multiple payers in complex fall-through fashion Medical Billing needs to support the multiple-party EDI when the "partner" has no financial incentive to work with you.

There are other differences, but one should not assume that plugging into an Open Source ERP is going to replace Keane.

-- Fred Trotter http://www.fredtrotter.com

Woodhouse Gregory Date: Thu, 24 Jul 2008 20:00:23 -0700

I've seen that, too. Business people often have a hard time understanding that conventional ERP products are not necessarily a good fit for a medical setting. And, frankly, I can understand their skepticism, though I think you're absolutely right here.

Sent from my iPhone

Vipen Mahajan Date: Fri, 25 Jul 2008 18:54:22 +0530

Fred,

What I like about Open Source, and Compiere is that Compiere is not merely an ERP, but can also be treated as a rapid application development platform, which can generate applications, with minimal coding, after defining the additional tables and data model, and process model. Thereby Compiere provides a framework for ERP applications, somewhat like what Ruby on Rails does for dynamic database driven web-sites.

However I do agree with you that Medical billing could be a different process and one may not use a classic ERP's Accounting and billing features. That is why I would look it as a RAD tool, for development.

Vipen

fred trotter Date: Fri, 1 Aug 2008 12:33:38 -0500

That could work... hard to say.

The problem with RAD or the Rails approach is that while it handles the development of the general case really quickly. Healthcare is so full of "strange cases" that often the RAD environment slows you down as much as it helps.

Of course one could argue that tools like FileMan are essentially RAD tools *for* healthcare, and are therefore exempted from this caveat.

Still I wish you the best of luck. Let me know if you would like help with specs for a billing /AR system. You should probably also take a moment and read what I have already published on Medical Billing... it might help.

-FT

I, Valdes Date: Tue, 25 Nov 2008 14:26:02 -0800 (PST)

FYI what I ended up doing on this was dumping as much demographic data out of Keane as I could and batch adding it with Kevin Toppenberg's GUI-Config tool with a .csv spreadsheet file. Some stock fields that the system needed such as VETERAN status I put default data into (NO). More complicated things like insurance information I did not attempt. About 30,000 records were added. Problems where that many records had invalid social security numbers like 999-99-9999 and my WorldVistA rejects it.

This solution via spreadsheet import is not optimal as the systems can now diverge, there is some double entry and some staff work cannot be reused at this time. However, the business staff only works during business hours. The hospital clinical staff works 24/7 and must be able to register and change new or old patients independently of the business system and people. The divergence may or may not be a problem. I made the decision to go ahead and import all of the demographics because it can save us time. Further problems are that the messages on batch add from Kevin's program are a work in progress, race and ethnicity didn't work for me but GUI-Config does the job overall and I now find GUI-Config to be nearly indispensible.

The information that I was able to use out of Keane where:

Field NAME:

NAME SEX DATE OF BIRTH SOCIAL SECURITY NUMBER

Health Record Number (HRN)

SERVICE CONNECTED? TYPE MULTIPLE BIRTH INDICATOR

STREET ADDRESS [LINE 1] STREET ADDRESS [LINE 2] CITY STATE ZIP CODE

PHONE NUMBER [RESIDENCE] RACE INFORMATION

VETERAN ETHNICITY INFORMATION

Field NUMBER: <.01> <.02> <.03> <.09> <0>

<.301> <391> <994>

<.111> <.112> <.114> <.115> <.116> <.131>

<2> <1901> <6>

-- IV

Nancy Anthracite Date: Tue, 25 Nov 2008 19:07:26 -0500

Ignacio, I don't know if you noticed the post about changing SS number and some of the veteran's information to not being required. I wonder if that would solve some of your import problems.

http://opensourcevista.net:8888/NancysVistAServer/FixForWVEHR-6-14-08POS-Required.txt

-- Nancy Anthracite

I, Valdes Date: Tue, 25 Nov 2008 18:31:21 -0800 (PST)

Thank you, this should be outstandingly helpful and allow me to get about 10,000 or so more records loaded. -- IV

I, Valdes Date: Mon, 1 Dec 2008 14:54:16 -0800 (PST)

I am considering generating a pseudo SSN via spreadsheet prior to loading through Kevin's GUI-config so as to improve the quality of the data I have of patients with invalid SSN's. Does anyone know the exact algorithm that VistA uses to generate this so that I could write a function to pre-generate it in a spreadsheet? According to Dave, it takes the birthdate, first letter of first and last name and then does some kind of hash with that.

-- IV

kdtop Date: Mon, 1 Dec 2008 15:18:58 -0800 (PST)

Here is the description in the Data dictionary for my system.

But before you put too much time into this, try just one patient. Because I think that I found that there is a crash when you try to add a pseudo-ssn via the Fileman DB API. I've written about this before.

Kevin

DESCRIPTION:

Enter the applicants social security number as nine digits, i.e., 123456789. If the social security number is unknown and you need to assign a pseudo SSN follow it with a 'P', i.e., 123456789P. Simply enter a 'P' if you wish the system to determine the proper pseudo SSN. Pseudo SSN's are determined as follows:

• 1. Based on the following table assign the first three numbers of the pseudo SSN based on the patient's three initials in first-middle-last initial order. For example, if the name is 'SMITH,JOHN P' the table would be used to convert JPS (the initials for JOHN P SMITH) into 467.

ALPHA	NUMBER	ALPHA	NUMBER
A,B,C	1	D,E,F	2
G,H,I	3	J,K,L	4
M,N,O	5	P,Q,R	6
S,T,U	7	V,W,X	8
Y,Z	9	NO INITIAL	0

• 2. Using the patient's date of birth convert it to six numerics in month-day-year order. Where a month, day or year consists of less than one numeric, i.e., JUNE=6, precede it by a zero, i.e., JUNE=06. If the month and/or year of birth are unknown indicate them as '00'.

EXAMPLES

Patient Name	DOB	Pseudo SSN
SMITH,JOHN P	Jan 3, 1917	467010317P
SMITH,JOHN P	Jan 1917	467010017P
SMITH,JOHN P	1917	467000017P
SMITH,JOHN	Dec 15, 1945	407121545P

Episode 3 Log Homepage Episode 5