Simple Patient Information and Payment Portal

Many of you know I’m all about keeping things simple, effective and useful. It’s better to have something simple that does a killer job at what it does than to have something so complex that no one uses it. In fact, that’s really the basis of my simple plan for meaningful use. Of course, this can often be confused as not valuing other items. However, that’s just not the case. You just start with reasonable goals and do amazing things with it. Then, you expand once you’ve conquered something simple, but I digress. The point is that I really enjoy seeing simple systems that just flat out work.

That’s why I was intrigued by an email I received from a reader about their system called ePatientHistory. I think it can best be described as a simple patient portal that tries to do 2 things really well: online patient registration and online patient payments.

I should make a disclaimer that I haven’t used this service other than the demos on their website. However, I really like some of the concepts and I wish more EMR companies would try to create something simple and effective that focus on small goals as opposed to trying to cure the whole world with a patient portal that is so complex no one uses it (man I’m in a ranting mood today). Let’s talk about each function which they call ePatientHistory and ePatientPayments.

ePatientHistory – Online Patient Registration
I tested the demo for this and it was a little buggy and not as intuitive as I would have liked it to be. For example, it didn’t have the standard * next to all the required fields and the pop up that was shown for the required fields didn’t make much since to me. A small thing that makes a big difference. Maybe this just wasn’t shown in the demo, but it would have been nice to had nested questions that were only shown if I’m female for example. That way I can skip the pap smear questions and go straight to the testicular self exam ones.

Also, it was awkward to have to register and then choose the form I want to fill out. Ideally the doctors office could just send me an email that has basically registered me into the system. The email would include a link which I click and get taken to a step by step webpage of what the doctor’s office wants me to do for my appointment. Then, I can’t screw it up as a patient. After I’ve filled out the important paperwork, then let me see the full login and the other features that I may want to use.

Of course, when you’re dealing with a standalone portal like this, the question really is how are you going to get the information out of the system. This system seems to offer a CSV file which can then be imported into an EMR. Ideally, I’d like this company to show me a list of EMR companies that support this type of import. I know that all of them could since CSV is pretty standard, but how many would and if they do would that data be inserted into your EMR in a useful way? Of course, many might just want the health history form to be a nice PDF file that they can upload to their EMR. However, it’s just sad to lose all that data in a PDF file.

The cost structure for this service is interesting. Basically it’s $695 up front and $39.95 per month for hosting. Seems a little pricey to me, but if they can make sales that’s a really good business model to have. You get the up front money and a residual income.

ePatientPayments – Online Patient Payment
This is an interesting module since it’s basic idea is to collect payments. Although, one good part of this system is that it will collect payments over time according to a payment plan. I think this can be really useful in collecting harder to collect accounts. Plus, it can be scheduled to be done automatically thanks to the power of Paypal.

Similar to the other description above, I’m not sure how the patient will know how much to pay. I didn’t see anywhere in the admin that seemed like a place that someone in a clinic could notify someone that they have a bill to pay and come to this portal to pay it. That would be nice functionality. Although, it would be really sweet functionality if it was tied to the EMR where the actual charges arrive. Of course, this is the challenge of using a system that’s not connected to your EMR.

The cost for this is similar to the other one with $395-495 a month up front and then $29.95 per month for hosting. One thing it doesn’t say is how the charges that Paypal charges will be handled. I’m guessing they pass those on to you the end user as well. Paypal is an amazing platform and great for developers since it costs nothing to get started and use it. However, Paypal instead gets paid on the back end with the highest percentage fees of any other credit card processor. I imagine ePatientPayments will want to switch to something other than Paypal as they grow. The savings of using another credit card processor over PayPal will basically pay for the ePatientPayments and then some.

I think we’re going to see a lot more little services like this pop up. I think a number of them could be very beneficial if they’re integrated or used alongside a great EMR. The other good part is that it seems like using stand alone services like this one will still allow you to be considered a “certified EHR” and possibly receive some of the $36 billion of EMR stimulus money.

Now, just to provide some background on this specific company, here’s a copy of the email I received about how ePatientHistory came about:
As a web developer, professionals seeking online solutions that make sense for their particular business often approach my company for advice. A local physician recently asked if I could develop online patient registration and payment services tailored to his medical practice. Since these types of services are commonplace on the Internet, I began to research options that might already exist for his purposes.

What I discovered were complicated, often expensive options for services that appear to take advantage of a basic lack of knowledge regarding web-based application implementation. Advances in technology have resulted in a wealth of web-based software options that companies with in-house IT departments find effortless to implement. It appears that health care providers typically outsource their requirements in this area, often at a very high cost. The requirements to be HIPAA compliant add to the complexity, and thus to the cost.

The physician approaching my company for online services was not seeking an EMR system, but rather a simple, affordable way to accept online patient payments and permit online patient registration. After analyzing and meeting the HIPAA compliance requirements, we accomplished his objectives, providing an online service that involves no hardware or software purchase, and requires no staff training to implement, at an affordable price. Patient history data can now be securely collected and stored electronically for import into an EMR system. Patients may now make online payments.

At the suggestion of this physician, our company has made these services available to any health care provider, as well as other businesses.

About the author

John Lynn

John Lynn

John Lynn is the Founder of the, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference,, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.


  • Hi, John.

    Interesting post. The problem with these “solve one problem” offerings is that the task of integration (e.g. downloading, translating, importing the CSV file) falls to the physician (or his office staff or IT provider). It’s just not easy enough for most docs, IMHO.

    I’m a subscriber to your blog, and particularly like your “Getting Real” (37signals) approach to the EMR problem.

  • Hi Mike,
    Thanks for reading and subscribing to my blog. I think I’ve mentioned before that I have an intense interest in Venture Capital and entrepreneurship in general and so I find your company incredibly intriguing.

    You’re right about my philosophies often coming very similar to 37 signals. It’s interesting, because I don’t really know any EMR company that has built a 37 signals type product. Although the one above is a step in that direction.

    I also just saw your company is in Fort Worth. I’m going to be down there at the beginning of next month. It’s a short trip, but maybe we could do lunch? I’ll drop you an email.

    More to the point of this blog post, I think many physicians can do it. However, I just don’t see many EMR companies making this feature available to a physician. Goes back to lack of good standards for interoperability.

  • John, thank you so much for taking the time to review our services. Your feedback helped me refine the site demo to emphasize the customization features of our services, and add some new features!

    As per your comments, all the standard * is now next to the required fields. I had left this out so entire forms did not require completion for demo purposes, but that has now been clarified. Although nesting the questions as you suggested isn’t quite practical, I did reformat the form into smaller “panels” that accomplish the same end. Now, if a male patient land on a female-related portion of a questionnaire, it can be skipped, and vice-versa.

    As for why PayPal was selected, our focus group of practitioners agreed that setup, configuration, and training staff to maintain an online payment gateway was less desirable than PayPal with which most of their staff is familiar and comfortable. As for cost, yes it is incurred by each individual client in their own PayPal account and, unless the volume is very large, the fees are comparable with other payment gateways. Should a client prefer or request an alternative gateway, that is not a problem.

    There is a feature in the Admin for creating custom payment plans, which can be emailed directly to the patients – as you mentioned. This is where the amount of the payments are entered for custom payment plans. As for “pay-on-acccount” feature, the patient enters the amount from the statement they receive.

    I am surprised you feel our service is pricey given the levels of HIPAA security employed, and the extreme customization that will be extended at no extra charge to our clients. This was what made ePatientHistory so attractive and affordable to our focus group, because it means they can securely capture exactly the data they require. As for it being awkward to register and choose the form wanted, since there are HIPAA requirements to be met in conjunction with registration, and one must select a form if there is more than one available, I see no way around this issue.

    The biggest issue in my mind is the export of CSV files for import into an EMR, and I will take your advice to approach big name EMRs in an attempt to determine a list of those that can import data. As you stated in reply email to me, “most live in closed gardens and only create interfaces for specific purposes.” Since our services only enhance, not compete with, EMRs I hope that I can be successful in this approach.

    Again, thank you so very much for your input. It is very much appreciated, as we excel in customization and will do everything possible to make our services work for our clients. It is sometimes difficult to convey this in a demo version, as there are so many variables that can be customized!

  • No doubt, some of it might have been the demo system. Nice to see that your development environment is agile enough to be able to make changes like the required fields this quickly. Oh the beauty of web apps.

    To your “Biggest Issue”

    The biggest issue in my mind is the export of CSV files for import into an EMR. I am curious as to why you seem to feel the responsibility for import into an EMR lies with our service, when it is clearly a feature that an EMR would have to include in a program. Our databases will be configured to have the same “fields” and “tables” as a client’s EMR system, thus data import should be a simple process. There is literally no way for me to know what EMR companies do or do not support CSV data import, but in my opinion, they are negligent if they don’t. Otherwise, data captured outside these systems in any manner must be hand-entered? That seems archaic.

    It’s not that your company needs to create the import into the EMR. Of course, the EMR vendor has to provide this functionality. What your company should be doing is working with every big name EMR company out there to make sure that they can import your file and get their permission to list their company as a company that supports your service. If you’re trying to sell me on your product, I want to see a large list of EMR companies that can work with your system. Then, either my EMR is on the list, or I can go to my EMR company and ask them why they can’t do it if all these other EMR companies can.

    I think you’ll be surprised how few EMR companies support CSV imports like this. Most are trying to live in closed in gardens and only create interfaces for specific purposes. We could go into all the reasons why this is wrong, messed up, bad practice, etc, but it’s just the reality of where we’re at and something your service will have to battle to make sells imho.

    I’ll be interested to see how your product evolves over time.

Click here to post a comment