Posts Tagged ‘emr’

Speak Customer: Why Business Specific Languages Will Revoluntionize IT

January 27, 2011

For many decades, IT was regarded as a support engine for many business functions. However, the actual role of IT was a lot more than that. It became the master of business processes, and it imposed a new way for business domain experts to do their work. It forced those experts to change the way they approach their own work. The best example of this horrible crime is health IT. For many years, IT was set out to convince people in the medical domain that they should use software to conduct business. They need to use a program to express themselves, and document patient’s history and present treatment plans. After all, it is so much easier for the doctor/nurse to pull up the patient’s records all in one place than to search among endless papers that are all over the office. It is also easier to transfer information to other locations to ensure faster and more efficient treatment experience.

This is all beautiful. The medical domain bought into it. And it was all for a good cause. However, medical software became more and more complicated. We have also run out of acronyms to describe all the programs created to support what used to be a simple medical workflow. Today, we have EMRs, EHRs, PM (Practice Management), PHM (Practice Health Management), etc. Doctors and nurses found themselves lost in a big jungle of software navigation mess. Thousands of fields to fill out. Fields spread over hundreds of pages and forms. Fields whose names change periodically, as well as their location. Fields whose values are hard-coded in drop downs that made sense to a computer programmer who created them. If I collected a penny for every complaint I heard from a nurse or a doctor over how a field name or value did not make sense to any of the medical staff but it was imposed by the programmer who was responsible for that page…

There is a major move in the IT industry toward the promise land of IT. The land where IT knows its role and responsibilities, and what it needs to deliver in order to support (not take over) the business. This move is specifically led by the adoption of DSL (domain specific languages). Software developers started to realize that maybe business experts are the best at expressing business rules and workflow. Maybe, the business expert should not just hand a requirements document to the IT person to implement. Instead, maybe the IT person should create the tool necessary for the business person to be able to express those rules herself. DSL delivers just that. It adds a new layer above the technical implementation by software engineers. A layer that allows business experts to write their own rules in simple enough to understand language. Then, a software will run to convert those expressions into more computer-like language that IT understands, just enough to run and govern those rules.

With DSL, many technologies blossomed such as scripting languages (Groovy, Ruby on Rails, etc.) because they are very simple to use, and they eliminate all the ceremony in code writing. This made it easy for less-technical staff to write rules and logic, that was later enforced by a deeper technology (typically the technology that compiles and runs those rules expressed using those scripting language). Other technologies such as BRMS (business rules management systems) allow software engineers to create an environment where the business expert can create business rules to be enforced later using a business rules engine.

2011 will be the year where IT moves out of the way, and back to behind the curtains, driving the support engine rather than steering the car wheel. This is the year where business experts will have a bigger role controlling their own business rules, and data flow. This is not just an opinion, but an observation by the more than obvious move to DSL in various industries.

At MedCPU, we are pushing the bar higher, or farther. We founded the company just about two and a half years ago because we believe that DSL is not good enough! It is not enough for IT to create the tools necessary for business experts to create their rules and flow. This is a good step, but not deep enough. At the end of the day, DSL was intended to push the work to the business unit in describing the rules and data flow in simple enough language terms that not only the business expert understands, but also the application itself. With DSL, not only IT has to compromise by allowing the business to express their own rules, but also the business person involved by having to learn something outside of their domain so the software they are using can understand what they are trying to say! At the end of the day, the business expert is not going to write her rules using her own language that she is used to write with, because the software is not capable of understanding her native language. She is still using a new language imposed by IT, albeit a simpler one than before. At MedCPU, we continue to realize that the business person is the end goal. However, we believe that to accomplish the ultimate goal of IT (working as a stepping stone and not an obstacle), we need to allow the business expert to speak her own language without compromise. It is IT that will have to do all the compromise needed to analyze and interpret what the business person is saying, and translate this into what the application can process.

Domain specific languages are too generic to express how one specific domain speaks. However, a business specific language (BSL) is the language of business that IT will have to learn (and not vice-versa). No need to use a language that is generic enough to support multiple business lines within the same domain if we can write code that speaks the language of the specific business line. This is the future of IT, being an enabler rather than the driver of business.

Using the medical example I pointed out above, at MedCPU we raised the bar of IT. Instead of requiring all medical staff to understand the language of IT and type data into structure fields so IT applications can understand it, we tell the doctor/nurse to type data using their own language they learned at school in free form. It is the job of the IT to take free form text, lab orders/results, pharmaceutical orders, and convert into structured format before processing the application on the data. The MedCPU system connects to all data repositories at our clients’ sites, and “listens” to all incoming data in real time. This data is mostly in free form, but that is no problem because with our Medical Text Processor (MTP) component, we can analyze the text and extract medical elements within the context of the patient case. Sometimes it is hard to understand the context from within the text, but that is no problem. Our Protocols Processor (PP) unit massages the data, and puts all extracted keywords within context. We spend most of our time learning how the doctor or nurse does their job, rather than impose our own rules or language on them. A doctor/nurse collects all information they can find from various repositories, and then run their own medical logic to make sense of this data. EFW (estimated fetal weight) is relevant until the baby is delivered. And that is no problem. Context processing after text extraction and analysis allows to put things into perspective. What did you say? Start pcn (penicillin)? Here is a contraindication alert because we remember what a doctor documented in a field that is never interpreted or read by any software in the world, last year. He documented that the patient is allergic to penicillin in the all but forgotten comment field towards the bottom of a 100 field form. Does the doctor have to manually go into the allergies field and document that the patient is allergic to penicillin? Does the doctor then have to manually go and check that list of allergies every time she prescribes a drug? Why not have everything in one place that is easy to document and read from at the time of treatment? If that is what you are used to, if you like to document everything in one place, and read everything from one place, then we are going not only to support that, but enable you to easily make sense of this data that is sitting right in front of you. That is what IT is about. It is about continuing what the business expert used to do, but “add” more value. Not take away what the business user used to do and replace it with another framework, methodology or approach. A doctor or a nurse is not used to knowing where each data element needs to go in a heavy weight EMR system with thousands of fields. That is not their job. That is not what they get paid to do. That is not what they were trained on. Yet, to be able to do their job, they need to be experts in navigating complex software that continues to evolve and change. That is, counter-intuitive.

2011 and beyond will be the year where IT will continue down the path of changing its ways. Moving from low level languages, to general purpose and easy to read languages, to scripting languages that are more to the point without the ceremonies of programming, to domain specific languages where all the ceremonies of irrelevant syntax is out of the way, to business specific languages where the business entity will “continue” to write their business rules in their own natural (business specific) language. It will be the responsibility of IT to evolve and understand this language with higher and higher rates of accuracy, and provide additional tools to enable the business expert to do their job better and more efficiently.