If you are following this blog, I would love it if you added Ankhos.wordpress.com to your subscriptions. With the advice of John from "EMR and HIPAA" and example of Greg from gregorus.wordpress.com, I have decided to make the change.
Hopefully I'll see you there!
Sunday, December 27, 2009
Friday, December 25, 2009
Design Decision: Python and Django
Python is one of the leading professional programming languages in use today. It was the official programming language of my previous employer and, boy, am I glad I had the chance to learn it! C++ is not much of a web language these days. Many people use Java, PHP and Perl for their web programming. These are all fine languages but it is my personal opinion that they are all inferior to Python for this project.
I have three main reasons to use Python:
1. loosely-typed language
For those non-technical, a loosely-typed (or duck-typed) language forgoes many programming formalities and allows you to make changes to code more quickly. In an atmosphere where I plan to make many changes to accommodate my customer, ease-of change is essential.
2. Readablity
The code for many other programming languages (ahem, PERL) tends to end up messy, with indentation irregularities and differences in formatting. But with Python, indentation is part of the logic flow and the code is more readable from the get-go. Sure, with Python you can make code illegible, but it is much easier to do so in most other languages.
3. Existing libraries
The Django web framework is written in Python. Django is a well-tested, comprehensive and exhaustively documented web framework which, to me is just magical. I have worked with several web frameworks and none is as flexible and easy to use as Django.
Django abstracts many of the mundane and error-prone link table creation out into a fantastic Python API. Django is also sufficiently performant to support numerous production Internet sites. See the Django Website for more information.
I have three main reasons to use Python:
1. loosely-typed language
For those non-technical, a loosely-typed (or duck-typed) language forgoes many programming formalities and allows you to make changes to code more quickly. In an atmosphere where I plan to make many changes to accommodate my customer, ease-of change is essential.
2. Readablity
The code for many other programming languages (ahem, PERL) tends to end up messy, with indentation irregularities and differences in formatting. But with Python, indentation is part of the logic flow and the code is more readable from the get-go. Sure, with Python you can make code illegible, but it is much easier to do so in most other languages.
3. Existing libraries
The Django web framework is written in Python. Django is a well-tested, comprehensive and exhaustively documented web framework which, to me is just magical. I have worked with several web frameworks and none is as flexible and easy to use as Django.
Django abstracts many of the mundane and error-prone link table creation out into a fantastic Python API. Django is also sufficiently performant to support numerous production Internet sites. See the Django Website for more information.
Design Decision: 'Web-based' EMR
One of the lessons my client (Carolina Oncology Specialists... COS) learned with their previous foray into the EMR market was that it is important to have all records available at all locations. In some cases, patients went between locations on the same day, or even different days and the EMR product they had was not efficient at handling multiple sites.
So, in order to accomplish the goal of immediate clinic-wide access to up-to-date patient information we decided to implement our EMR system as a centralized 'web' server. I put web in quotation marks because, although it is serving data via http(s) requests, it is not on the public Internet. There are very large security concerns when operating outside of a more secure intranet.
This allows us not only to meet the requirements of the practice, but it also allows us many technical flexibilities because web servers are:
1. OS-independent
2. programming language-independent
3. easily replicable
4. able to benefit from Model, View, Controller (MVC) framework, providing even more flexibility
This decision also frees many restrictions on the client computers within the office. The client application is abstracted to a web browser, which is also platform-independent.
This could mean that you could implement your desktop and server architecture without paying a dime in Microsoft licensing! Go Linux! (You could even run this application on a Mac if you are an enthusiastic devotee.)
So, in order to accomplish the goal of immediate clinic-wide access to up-to-date patient information we decided to implement our EMR system as a centralized 'web' server. I put web in quotation marks because, although it is serving data via http(s) requests, it is not on the public Internet. There are very large security concerns when operating outside of a more secure intranet.
This allows us not only to meet the requirements of the practice, but it also allows us many technical flexibilities because web servers are:
1. OS-independent
2. programming language-independent
3. easily replicable
4. able to benefit from Model, View, Controller (MVC) framework, providing even more flexibility
This decision also frees many restrictions on the client computers within the office. The client application is abstracted to a web browser, which is also platform-independent.
This could mean that you could implement your desktop and server architecture without paying a dime in Microsoft licensing! Go Linux! (You could even run this application on a Mac if you are an enthusiastic devotee.)
Thursday, December 24, 2009
Be ferocious!
Of the many inspiring essays from Paul Graham's I find two particularly poignant. The first "Why to Not Start a Startup" and the second is "You Weren't Meant to Have a Boss".
I began reading Paul Graham's essays in a time where my current Software Development job was hitting a lull. I enjoyed the environment, people and managers at the company. It is still a great place to work, but due to budgeting issues I was pushed off my project and into an internal 'stable' while we waited for business to pick up.
Every enlightening paragraph I read of Graham's made me feel like I was missing something big. With no creative release, I felt like a caged animal. His relentlessly encouraging words about startups and innovative, agile development made me squirm in my seat. I had to do something. I had to be ferocious.
I was a drain on resources at the company and was chomping at the bit to get back to 'hacking'. So the company and I decided to part on amicable terms so I could pursue an opportunity to create something new. I want reshape the face of Oncology patient tracking software. That is my goal, and I am ferocious about it.
I began reading Paul Graham's essays in a time where my current Software Development job was hitting a lull. I enjoyed the environment, people and managers at the company. It is still a great place to work, but due to budgeting issues I was pushed off my project and into an internal 'stable' while we waited for business to pick up.
Every enlightening paragraph I read of Graham's made me feel like I was missing something big. With no creative release, I felt like a caged animal. His relentlessly encouraging words about startups and innovative, agile development made me squirm in my seat. I had to do something. I had to be ferocious.
I was a drain on resources at the company and was chomping at the bit to get back to 'hacking'. So the company and I decided to part on amicable terms so I could pursue an opportunity to create something new. I want reshape the face of Oncology patient tracking software. That is my goal, and I am ferocious about it.
Please the customer and the rest will follow
I am a "True Fan" of Paul Graham's. His unabashed optimism and clear message of "Customer first and the rest will follow" resonates in my mind. As such, I am approaching this project as a I would one of his startups.
Before I even began brainstorming about any technical aspects of the program I was about to write for COS, I asked myself "Am I ready for this?". I wanted to assure myself that I would go into this project full steam. I was confident in my programming knowledge and administration skills, but was I ready to commit to this full-time project? Then, I realized that the doubts about my own commitment were not the only ones I had. Were my customers also ready for this project?
I called a conference with the lead physician and head nurse to make sure that THEY were also committed. I told them that if they wanted the best product possible, I would require lots of input, opinion and correction; that this would be an involved process with many iterations, about which they would be queried often. They were overjoyed. It was clear that with the experience they had had with our previous EMR, the prospects of having input on the software they purchase was a novel and welcome notion.
After this conversation, I realized that my job had become orders of magnitude easier. If my goal was to please the customer, and the customer was chomping at the bit to tell me exactly what they want then the rest was a matter of implementation.
Before I even began brainstorming about any technical aspects of the program I was about to write for COS, I asked myself "Am I ready for this?". I wanted to assure myself that I would go into this project full steam. I was confident in my programming knowledge and administration skills, but was I ready to commit to this full-time project? Then, I realized that the doubts about my own commitment were not the only ones I had. Were my customers also ready for this project?
I called a conference with the lead physician and head nurse to make sure that THEY were also committed. I told them that if they wanted the best product possible, I would require lots of input, opinion and correction; that this would be an involved process with many iterations, about which they would be queried often. They were overjoyed. It was clear that with the experience they had had with our previous EMR, the prospects of having input on the software they purchase was a novel and welcome notion.
After this conversation, I realized that my job had become orders of magnitude easier. If my goal was to please the customer, and the customer was chomping at the bit to tell me exactly what they want then the rest was a matter of implementation.
Productivity first, electronic records second
A few months back, Carolina Oncology Specialists(COS) purchased a product named Varian and implemented it in the office. This program performed its duties as a comprehensive data repository but ultimately, it lacked flexibility and was not productive for COS. There was also no benefit to the patient experience. In fact, the experience was so counter-productive that the staff at COS demanded to return to paper charts. Kudos to salesmanship.
But the client base (unfortunately) at COS is growing and it is clear that a paper charting system will not scale. If an EMR system was not needed now, it would be soon. This is where I come in.
Before I began the implementation of any type of EMR system, I conducted interviews with the staff and did some research into the oncology EMR products on the market. There are innumerable products, each claiming to be 'easy to use' and completely interoperable with other products. Some by large vendors, some by small open-source communities. We signed up for a few interactive demos and had phone conferences with sales people but none could offer the features needed by a medium-sized oncology practice like COS.
The Oncology clinical workflow is different from most medical workflows. Not only do drugs need to be ordered and labs reviewed, but entire treatment schedules need to be managed. Many of the patients are in-patients and need to be monitored not only between office visits, but during one, as well.
Busy Doctors, nurses and administrative staff just don't have time to fiddle with clunky interfaces ill-designed for minute-by-minute patient tracking. My job has become to help this office not just convert their charting data to an electronic format but also to provide a product that will _improve_ their office efficiency, quality of service and patient throughput .
COS (and Oncology practices, in general) need more than an EMR, they need an patient tracking engine.
But the client base (unfortunately) at COS is growing and it is clear that a paper charting system will not scale. If an EMR system was not needed now, it would be soon. This is where I come in.
Before I began the implementation of any type of EMR system, I conducted interviews with the staff and did some research into the oncology EMR products on the market. There are innumerable products, each claiming to be 'easy to use' and completely interoperable with other products. Some by large vendors, some by small open-source communities. We signed up for a few interactive demos and had phone conferences with sales people but none could offer the features needed by a medium-sized oncology practice like COS.
The Oncology clinical workflow is different from most medical workflows. Not only do drugs need to be ordered and labs reviewed, but entire treatment schedules need to be managed. Many of the patients are in-patients and need to be monitored not only between office visits, but during one, as well.
Busy Doctors, nurses and administrative staff just don't have time to fiddle with clunky interfaces ill-designed for minute-by-minute patient tracking. My job has become to help this office not just convert their charting data to an electronic format but also to provide a product that will _improve_ their office efficiency, quality of service and patient throughput .
COS (and Oncology practices, in general) need more than an EMR, they need an patient tracking engine.
Wednesday, December 23, 2009
Oncology EMR - Lofty Goals
Speaking in a pseudo-panic, I called the lead physician at Carolina Oncology Specialists and asked this question.
"Why do you need this EMR software?"
I had been commissioned to write an electronic medical records program for this medium-sized oncology office in Western North Carolina, but had suddenly become unconvinced that what I was writing was 1. necessary and 2, relevant. COS has had a long history of success and prestige in its market and although its customer base was rapidly expanding, its paper charting system was working well. Why fix what ain't broke?
I didn't want this project to become a case study in wasted development and poor planning; I needed validation that this software would truly improve the lives of the patients and employees of COS. The lead physician, Dr Orlowski (My Father) eased my panic and we concretized our previously nebulous goals. The on-going pursuit of these goals will be the foundation of further discussion on this blog:
The goals we outlined are:
1. Improve patient safety -- dosing precautions, tracking allergies, etc.
2. Increase office productivity -- less time looking for charts/patients
3. Reduce patient waiting time
4. Record an up-to-the-minute accounting of office events
5. Create auditable data trails for reporting and potential future government quality assesments
6. Provide backwards-compatability with the current paper chart system.
and...
7. Call it an EMR
We agreed that "having an EMR" was not enough. It had to actually make life better for the people who used it. What good is having an EMR if it grinds your office to a halt?
"Why do you need this EMR software?"
I had been commissioned to write an electronic medical records program for this medium-sized oncology office in Western North Carolina, but had suddenly become unconvinced that what I was writing was 1. necessary and 2, relevant. COS has had a long history of success and prestige in its market and although its customer base was rapidly expanding, its paper charting system was working well. Why fix what ain't broke?
I didn't want this project to become a case study in wasted development and poor planning; I needed validation that this software would truly improve the lives of the patients and employees of COS. The lead physician, Dr Orlowski (My Father) eased my panic and we concretized our previously nebulous goals. The on-going pursuit of these goals will be the foundation of further discussion on this blog:
The goals we outlined are:
1. Improve patient safety -- dosing precautions, tracking allergies, etc.
2. Increase office productivity -- less time looking for charts/patients
3. Reduce patient waiting time
4. Record an up-to-the-minute accounting of office events
5. Create auditable data trails for reporting and potential future government quality assesments
6. Provide backwards-compatability with the current paper chart system.
and...
7. Call it an EMR
We agreed that "having an EMR" was not enough. It had to actually make life better for the people who used it. What good is having an EMR if it grinds your office to a halt?
Subscribe to:
Posts (Atom)
Posts
