Seeking beta-testers

If you've been following this blog, you may have noticed I've mentioned our internal product development.  Our work on VistA, Ruby and the iPhone have all been products of our work on our first product, CompleteNote.

We just recently launched our beta-test program.  We are looking for clinical sites to give our stuff a try. The primary information(including beta program info) about CompleteNote is located here  -> http://www.blenderhouse.com/products/
In a nutshell, we've developed machine-learning technology that learns the patterns of how individual physician's diagnose and treat patients, and how they document this in an electronic health record(like VistA).  Our current feature set is then around reducing the amount of time a clinician spends on data-entry, but will soon extend to very cool clinical decision support.

Anyway, if you like trying new cool technology, and hate data-entry, let us know, we'd be happy to get you involved.

And, hey, the focus right now is on VistA, but we are also seeking development partners for Allscripts, NextGen, Epic and others.

iCPRS v 1.0.1

We released a new version of iCPRS with some minor feature additions and fixes.  It should be available for upgrades and downloads today(2/17) or tomorrow.
A few items:
1.  Long list for the all patients selection screen is now available.  You can select more at the bottom of the list.
2.  Default login information for the OpenVistA Demo server.  If this server is the current one, iCPRS automatically fills in the standard user login, PU1234 and the password.
3.  Some users had complain it was too easy to hit the back button to logout, so we added a warning
4.  We are trying out iAd to help recoup the cost of the Apple Developer program.  Just on the login screen.
5.  Other minor fixes and tweaks.

Next up:
We are anticipating the following features next:

• SSH support
• Add/Edit Vitals
• Problem list management

iCPRS: VistA for iPhone/iPad

So I ported vistarpc4r to iOS for our product development needs and I realized...why not create an iPhone/iPad version of CPRS, the Windows GUI front end to the VA VistA electronic health record system.
So we did.  Apple today approved iCPRS for listing in the App Store, so we are letting people know.

iCPRS

Version 1.0.0 is a very basic version.  It mimics the functionality of the cover sheet tab in the CPRS GUI in a read-only fashion.

• It's free.
• Does not require any additional software to be installed.
• By default, it will login into Medsphere's OpenVista demo server with the demo access and verify code(PU1234 and PU1234!!).
• Additional servers can be added by clicking on the switch button.
• It has been tested with OpenVista and WorldVista.  It should work with any version of VistA that is based on the VA FOIA and has RPC Broker enabled.
• Uses the same RPC calls as CPRS.
• Advice button on the patient information screen is for users of our clinical decision support product, CompleteNote.  This is completely optional.  We also intend it to be used for any one interested in the Infobutton HL7 standard.

Known issues:

• Long lists of patients.  If selecting all patients, right now the app only shows the first 40 or so.  Will be addressed in next release
• Visual cue for network fetching.  Right now, there is no indication that the application is fetching data from the VistA server.  I'm working on modify the ios vistarpc code to allow for it.  

Future:

If people like it, we'll add the rest of the CPRS functionality: the other tabs, ability to create and modify information, etc.

Enjoy!

Moving...

Well, after a good long run at 5933 Baum Blvd(thanks Mark and Skip), we are moving to our new digs at 5530 Penn Ave.  We'll probably have fewer happy hour/creative thinking sessions at BRGR, and more at Salt of the Earth, and Verde.  And we get WINDOWS!!!

AMIA Conference and Paper

So, I went to my first academic conference as an author.  The American Medical Informatics Association's Annual Symposium in Washington, DC.  I had submitted a one page paper describing the results of our NIH SBIR Phase I study, and they accepted it for the Tuesday poster session.
At the session, I had a pretty good turn out.  I had lot of people ask me questions, and got a lot of good feedback.  Big thanks to Maggie for creating a very attractive poster!

Here is the paper, now that it is published - AMIA Annu Symp Proc. 2011 Oct 25 ;2011:1710.

Automated creation of clinical progress notes with machine learning

Michael Cham, CTO, Raymond Benza, MD, Jaime Carbonell, PhD

BlenderHouse, Pittsburgh, PA; Allegheny General Hospital, Pittsburgh, PA; Carnegie Mellon University, Pittsburgh, PA

Abstract

The goal of this project was to demonstrate that our machine learning approach could mimic individual physician’s diagnostic and care planning abilities by learning from clinical progress notes.  Using 500 notes from 3 physicians, we were able to achieve accuracies in excess of 97%.  This technology will be embedded in a product that can improve clinical efficiency and patient safety through electronic medical records and clinical decision support systems.

Introduction

Electronic medical records (EMR) systems and clinical decision support (CDS) systems have the potential to address preventable readmissions and medical errors problems in the U.S., but are missing key pieces of functionality or aren’t well integrated enough into the clinical workflow to help.  Additionally, EMRs are actually introducing new kinds of medical errors and negatively impact the productivity of clinical staff.

The goal of the study was to prove that the technology at the core of our product, CompleteNoteTM, could learn to mimic individual physician’s diagnostic and patient care planning abilities, learned from actual electronic clinical progress notes. Adding this capability to EMR and CDS systems would improve the efficiency and accuracy of documentation and provide customized, patient-centric decision support.

Methods

We obtained 500 de-identified clinical progress notes from the Heart Failure, Heart Transplant and Pulmonary Hypertension Clinic at Allegheny General Hospital.  Three different physicians composed the notes. The notes were in Microsoft Word format, directly from a dictation/transcription service. The notes were then parsed and stored into a MySQL database, breaking down the notes into logical sections, vitals, problem lists, medications lists, lab results, diagnoses, and care plans.  

We utilized our proprietary, support vector machine-based, multi-statement prediction approach and generated eight statistical models.  There are two models for each of the three physicians, one for predicting patient diagnoses, and the other for predicting care plans.  For each physician model, we only used notes that they created.  We also created models for the union of all three physicians, which effectively blends the abilities of all the physicians.  The union models used all the notes from all physicians.  All of the models were restricted to predicting statements that appeared in at least 2% of the notes, in order to produce significant results.  We achieved the best results using linear kernels, but did test Polynomial, Sigmoid and RBF kernels.

Results

The prediction accuracy results are shown in Figure 1, calculated using a 5-fold cross-validation on linear kernels:

Prediction model	Accuracy	Prediction Model	Accuracy
Physician #1 Diagnosis	97.65%	Physician #1 Plans	97.86%
Physician #2 Diagnosis	97.94%	Physician #2 Plans	97.88%
Physician #3 Diagnosis	97.51%	Physician #3 Plans	97.52%
Consolidated Diagnosis	97.94%	Consolidated Plans	97.95%

Figure 1. Prediction Accuracy results

Conclusion

We conclude that it is feasible to predict diagnosis and care plan information learned from progress notes using the CompleteNote technology.

vistarpc4r Tutorial 3: Lists (part one)

So now we have a running system, we can configure some basic elements, and we can add providers and patients.  What's next?
Well, VistA has a ton of data already loaded for you, so let's check it out.

Most things(objects) in VistA have an internal and external representation.  Basically this means each object has an internal id and a value.  The internal id is generally a positive integer(often referred to as an IEN or IFN or DFN).  The value is generally a human readable string.
Lists are returned as an array of string.
Here are the first bunch with Ruby code:

Providers

array = broker.call_a("ORQPT PROVIDERS")
puts array[0]  # outputs providerIEN^providername  e.g. 42^ USER,PHYSICIAN

Locations
Clinics - Outpatient

array = broker.call_a("ORWU CLINCLOC", ["", "1"])
puts array[0]  # outputs locationIEN^locationname e.g. 15^CARDIOLOGY

Wards - Inpatient

array = broker.call_a("ORQPT WARDS")
puts array[0] # outputs locationIEN^locationname e.g. 2^MED/SURG

Patients - There are many ways to get lists of patients.  Some examples:
By Ward

array = broker.call_a("ORQPT WARD PATIENTS", [wardIEN])
puts array[0] # outputs patientIEN^patientname  e.g. 17^SMITH,BETTY

All Patients

array = broker.call_a("ORWPT LIST ALL", ["", "1"])

This call returns a preset number of patients out of the list.  You need to use this call in a loop where you call the RPC additional times using the last array entry from the previous call as the first argument until it returns an array of size 0.

You can also get lists of patient by provider, appointment dates, teams, and others.  Let me know if you need help finding the RPCs

Problems
Problems use a search approach.

array = broker.call_a("ORQQPL PROBLEM LEX SEARCH", ["hypertension", "100", "", "0"])

Argument 1 is the term you are looking for
Argument 2 is the maximum number of matches
Argument 3 is something to do with view...leaving it blank
Argument 4 is the date to use for determining when problems were valid in the VistA system.

puts array[0]  # problemIEN^problemname^codename^codeIEN^code source
# for example:  60339^Hypertension *^401.9^2477^ICD-9-CM

Up next...medication lists, procedure lists, and other order lists.

vistarpc4r Tutorial 2: Users, Locations, Patients, Dates

This second tutorial continues where we left off in tutorial #1, and assumes you have an OpenVistA system setup on Ubuntu.  

Many of the VistA RPC calls you can make though vistarpc4r require either a patient, provider, location or date.  In some cases, all of them.  Most VistA flavors come with some sample patients, providers or locations, but if you are developing software to work with VistA, you probably need to create some of your own.  

However.....standard VistA does not include a RPC to create ANY of them.  There are a variety of reasons, many non-technical ones regarding politics surrounding Federal software development can be read at the Hardhats google group.  I prefer to think it is because the actual users of CPRS aren't the ones creating the patients, and user accounts, so no need, no build.  

But....I have at least one work around.

So first, users, or usually referred to as providers.

User creation

For user creation, it's terminal time(although I believe Astronaut has a user config tool)

I need super providers for my development sandbox.  By that I mean, they have the ability to do just about everything in the VistA GUI.  For me that means a provider that can sign orders containing narcotics.  

I prefer Fileman to create users so:

$ openvista open

OPEN> D P^DI               # start Fileman

Login as man,sys

Select Option 1:  Add/Edit Entries

Select the NEW PERSON file

Edit All Fields                   # which is painful, but you won't miss anything

Select NEW PERSON NAME  - type in your new users name in LAST,FIRST format

You will then start going through fields.  ? and ?? give good answers as to what is expected.  

But some key fields:

ACCESS:  basically your login name

VERIFY:   a password

KEYS:  PROVIDER, ORES    # these are necessary to sign orders

SECONDARY MENU OPTIONS:  OR CPRS GUI CHART

PRIMARY MENU OPTION:  RGWBMAIN

CPRS TAB: RPT
CPRS TAB: COR

AUTHORIZED TO WRITE MED ORDERS:  YES

DEA: 2 letters, followed by 7 numbers, but there is an algorithm

ELECTRONIC SIGNATURE CODE:  A string the user types in to verify its them.  like JSMITH

Once you create one, you can clone it!

Go into EVE, which is D ^ZU, instead of D P^DI

Select User management

Select Grant access by profile 

Use your existing user as a template, and create new users!
Don't forget to change for each user: Access, verify, DEA, Signature

Add Locations(no RPC for this either)

Adding a location is a similiar experience to adding your first user. In this case edit file 44, the location file. Fill out what makes sense. Again ? and ?? will show you fairly good help.

Add Patients

So I have a RPC for this, but I don't feel good about. VistA does not come with one out of the box, but the Astronaut folks have created one. For my purposes, I needed to be able to add a lot of patients in bulk(but very few providers and locations). So I jammed the Astronaut modification into my plain vanilla OpenVista.

KIDS is the name of VistA's patching capability. People can bundle up their code changes as KIDS builds and distribute them for people to patch their system. In this case, I grabbed the KIDS build out of the Astronaut source tree installed it.

Grab kids.ov.tar.gz from

http://bazaar.launchpad.net/~ivaldes-hal-pc/astronaut-vista-server/trunk/files/head:/astro-distro/openvista

From that archive, we need the 0.8-2/TMG1-1.0-2d.KIDS file. Make sure it is on the OpenVistA server.

From the archive, I followed the commands in the file 0.8-2/TMG1-1.0-2d.TOY.sh

First we load the new code into the instance:

$ openvista open

OPEN> S DUZ=1,DUZ(0)="@"

OPEN> D ^XPDIL

# enter the path and filename for the KIDS file

# answer YES

OPEN>  h  # to halt

Then we install the code so that it runs and is available

$ openvista open

OPEN> S DUZ=1,DUZ(0)="@"

OPEN> D ^XPDI

TMG1*1.0*2

NO

NO

OPEN> h

During this installation process, you WILL GET ERRORS.  Wierd, nasty looking errors.  That is the part I don't feel good about.  But the add patient RPC works!!!!  

To use:

broker.call_s("TMG ADD PATIENT", [ [ 

    ["\"COMBINED NAME\"", "Test,Patient"],

    ["\"DOB\"", "12/1/68"],

    ["\"SEX\"", "M"],

    ["\"SS_NUM\"", "000000000"]

    ]]

The RPC returns the DFN, or internal identifier(which is an integer), for this new patient. 

For bulk loading, our experience is that the RPC breaks after a number of consecutive calls.  It looks like a timing bug.  Surrounding the call with the usual BEGIN/RESCUE/END, and resetting the connection works. 

Fileman Dates

Lastly, most of the RPCs that require dates for their arguments need them in Fileman format. Fileman format means take your usual YYYYMMDD.HHMMSS format and subtract 17000000.  For example, 20110911.090123 would be entered as 3110911.090123

Well, that gives you some basic infrastructure.  Enjoy.

Up next will be reviewing some specific RPCs that give you lists of stuff.