Making EMRs Fast, Easy and Intuitive to Use: Removing the Burden of Structured Data

I was cruising around last week and came across "The Burden of Structured Data: What can Healthcare Learn From The Web Experience" from Andy Oram who's writing I have quoted here before.  In the second part of the article (the second part is the reason I didn't respond to it last week) he states "ICD should be replaced with something that embodies semantic meaning" and then goes on to say "A big problem in electronic health records is their insistence that certain things be filled out for every patient." resulting in a "Cartesian explosion" and "bloated records."


As we have found before, Andy makes some good observations, but like the healthcare industry in general, he has no clue how to solve the problem or that the problem has already been solved.  It seems to me that Google, Bing, and all the other major search engines pretty much licked this problem a long time ago.  They give you a two stage search where what you type in generates suggestions AS YOU TYPE with popular searches.  That isn't quite the entire solution for healthcare, but that is a great place to start.


The entire solution is to use a purpose built database like SNOMED CT that is designed from the outset for documenting patient encounters and combining it with Bing style searches.  That is precisely what we have done here at Sentia Systems, for our sister company Sentia Health. Our solution takes it a bit farther even.  We took all the concepts in the SNOMED and made a word table with the number of unique occurrences of every word in every concept.  When the user picks a word out of the autocomplete list, we insert that word and a space making compound word searches possible.  For example, "abd" would give you "abdominal" and "pa" would give you "pain" and f course we are bright enough to return the matching word with the highest number of occurrences first.  Then we do the bing/google thing and search the appropriate concept type for places where "abdominal" is near or next to "pain."  This isn't just a wildcard search either.  For you techies out there, it is a full text index, meaning that we search for words that SOUND LIKE "abdominal" and "pain" in case the user didn't pick from the list, and in reverse order and NEAR each other, not just next to, or in the same description.

Here are a few pictures to illustrate what we mean:

First we navigate to the appropriate record, open the search window and type "lo":

Then we pick (or continue typing) lower and continue with "ab":

Then we continue typing (or pick) "pa":

Finally, we click the Populate button to actually do the search:

There are quite a few things to notice here:

1. The autocomplete doesn't give you popular searches, like Google does.  It simply corrects your spelling.  This allows you to only get 25 results with two letters instead of scrolling through thousands of results that would take a long time up load in any case.
2. You can type your entire entry with out picking anything.  If you don't want to use the mouse or the scroll buttons, don't.
3. The thing you actually wanted to see is at the top, number one position.  Other things that might be similar are ranked below.
4. If you choose to type, without picking anything in the autocomplete, the spell checking still kicks in.  If you search 'hedayk' you still get a list of things with headache in the title, just like Bing.

So yes, Andy (or is it Mr. Oram?), we have conquered the structured data challenge.  We document our cases in regular SOAP Notes that are in English (SNOMED also supports many other languages and will translate them automatically) with modifiers (like "left" or "severe") indented and prefaced with a dash.

This is what software is supposed to do: solve problems.  We believe that we can enter in a note as fast as we could have typed it in and with far fewer typographical errors.  Even better, we now can search for patients with a diagnosis, or with certain symptoms because those things are captured in a structured way. 

So tell your Cerners and your Epics and every other vendor of electronic health records out there that they are just doing it wrong.  When you factor in the fact that an Epic or a Cerner installation will cost hundreds of millions of dollars to implement, the response time is abysmal, the patient encounter still has to be coded to be paid by the insurance company, and our sister company Sentia Health will do all this, and do it better than the competition can even imagine, and do it for $10/month I think the choice is clear.

So no, Andy, there is no burden, you just need a few good programmers to show you how to do it.

Beware of Buzzwords. Software Companies Are Selling You a Bill Of Goods

I was reading along yesterday when I ran across this from my buddy Anne Zieger over at EMR and HIPAA crowing about how Machine Learning might tame healthcare's Big Data.  First, there is no such thing as Big Data.  Depending on whom you talk to, the term big data was either coined by Dr. Francis Diebold at UPenn in a paper called A Personal Perspective on the Origin(s) and Development of \Big Data": The Phenomenon, the Term, and the Discipline or Roger Magoulas from Ultimately, big data is more about attitude than tools; data-driven organizations look at big data as a solution, not a problem.  Either way, Big Data is a sales tool to get you to buy that worthless piece of nothing called Hadoop.  Beware of Trojans bearing gifts and beware of people trying to sell you things.  Hadoop and Map Reduce are combined to give a programmer the ability to sift through huge amounts of unstructured data.  The problem with that is that they use Java to loop through this massive data store to look for things. If you've been following along with our blog, you already know why Java is particularly unsuited for this kind of work.  Plus, we already have a tool for that and we've had it since 1979.  Its called a database.  No, databases can't handle unstructured data, but there is no such thing as unstructured data, there is only data that hasn't been structured yet.  At Sentia, our solution is to structure the data, shove it into a database and run queries against it.  That requires no new technology and the first query will take about as long as doing it the dumb Hadoop way.  The second Hadoop query will take just as long as the first, because it works exactly the same way as the first, but the second database query will take thousands of times less, because the data is already structured.  If your database server can't handle the volume of data that your Hadoop servers can, format the boxes that Hadoop is installed on and add them to your database cluster.  That should solve the problem.

Second (did you forget there was a first already?) just like Big Data, there is no such thing as Machine Learning, at least not yet.  Margaret Rouse posted this definition on TechTarget, where she states that machine learning is used by Facebook "... to personalize each member's feed. If a member frequently stops scrolling in order to read or "like" a particular friend's posts, the News Feed will start to show more of that friend's activity earlier in the feed."  

We here at Sentia call that a query (yes, on a database) and have been doing it for decades.  Here's an example of how we do it.  In the Electronic Medical Records (EMR) application we wrote for our sister company Sentia Health, we query the database to find the top twenty diagnoses by doctor in a rolling six week average and rank them by number of occurrences.  This allows us to show the doctor a list of the most common things he or she is diagnosing that changes over time.  for example, in the fall and winter influenza (the flu) rises to the top of the list and when the doctor selects it, he or she can duplicate the first instance of that diagnosis and copy it over to the new patient, literally completing the patient documentation with one click.  We wrote that query in 2002, before there was "Big Data," Hadoop or "Machine Learning."  Heck, that was before there even was a Facebook and long before it was open to everyone and FAR before they started using "Machine Learning" to update your newsfeed.

Why do we mention all this to you?  We told you above: Beware of Trojans bearing gifts.  The people who came up with all this are trying to sell you something.  The reporters, in this case bloggers, don't have the faintest idea what they are talking about.  Their job is to publish or perish, not to tell it to you straight.  While Walter Cronkite didn't have to know what he was talking about to report the news, he just told you what happened and he tried not to put a spin on it.  That isn't the case today.  The sales people, and everyone hates a sales person, don't care what you think or what the product is as long as they get your cash.  They are paid to come up with new verbiage to part a fool from his money.  If you are falling for this, yes, you are a fool.  If you don't have the tools necessary to winnow the wheat from the chaff in your software purchases, you are an idiot and you deserve what you get.  that's fine as long as you are happy with it, but this affects everyone.  It is most of the reason that healthcare is claiming 20% of the Gross Domestic Product in the United States.  Idiot administrators are buying buzzwords from dishonest salespeople.

Here's another example: Athena Health claims they are a cloud based EMR.  Athena is practice management and uses VPN to log in to a desktop remotely.  Yes, you log into a windows machine with an installed, windows based application on it.  That means every one of their clients has its own installation of their product.  Talk about an expensive administration nightmare.  That doesn't even count setting up all those machines with the application installed on them.  "Cloud" is their buzzword.  They want you to think their product is SaaS (Software as a Service) like our sister company Sentia Health provides, but the can't because they don't know how to build applications that run in a browser.
 
We've talked about buzzwords before.  Buzzwords are designed to obfuscate facts and to put lipstick on the pig that a sales person is trying to foist off on you.  Yes, YOU, dear reader.  If you go to a doctor (or any other business) that buys into this, and all of you do, you end up paying for that polished porcine piece of prevarication out of your own personal pocket.

If you want real software, built without using mind numbing buzzwords, you know who to call.  Don't make out with the red lipped porker, or buy a pig in a poke.

"Thinking outside the box," buzzwords and other dumb things that business people say and do

Management consultants and business guys in general are infamous for their meaningless clichés like "drink the Kool-Ade," "open the kimono" or "paradigm shift."  Unless you studied Latin or Greek (I did) don't crow to me about paradigms.  The worst of these is "thinking outside the box."  The business people I have run across don't have the training or experience to truly even know where the walls of "the box" are, much less what is inside or not.  I'm not really sure what an MBA prepares a person to do, but I can assure you it isn't innovative thinking.

For example, Sentia had a contract with Jack Henry & Associates in Charlotte to help them add on some regulatory functionality to their Cruise application for Credit Unions.  The regulation was called "Tila/Respa."  I don't recall what that meant but it was a disclosure of loan terms to the borrower. the regulation was huge, about 50 entities and and average of 20 attributes per entity, or a little over a thousand database fields.  My guy got there on September 1 last year and the functionality had to be implemented by October 1.  Designing and building a database, designing and building a middle tier and designing and building a user interface using two guys for a thousand plus fields is getting close to impossible.  My guy wrote a tool that took the specification, scraped out the names and datatypes of the attributes, assigned them to entities and generated a database.  The other guy, meanwhile, was working on a tool to generate Windows forms (yes it was a Windows application, ewww) from the same specification.  My guy then pointed Sentia's Object Relational Mapper (ORM) at the new database and generated the middle tier.  After some trial and error with naming conventions and such, the generated front end was mated to the generated middle tier and while ugly, worked fine.  This whole process took a week.  Of course then then the specification changed (six more times) but because we chose to generate the application in toto, all we had to do was regenerate the application and make it pretty.

Why do I tell you this story?  As problem solvers, those two guys really "thought outside the box" and delivered not what the client asked for, but what they needed and compensated for the changes they knew were coming.  Instead of doing as they were told and "coding tila/respa" (whatever that means) they looked ahead to changed they knew would come (they always do) and instead of slaving away, they designed a flexible solution that would solve the real problem.  It was still a lot of hard work, and harder work than "coding tila/respa" (again, whatever that means) but less of it, and flexible enough to compensate for the shifting sands of a requirements document left until the last possible second.  So these same two guys knowing that Cruise itself was a complete train wreck with possibly a dozen ways to access its own database, procedural code that has been around since the VB4 days, and generally didn't work and couldn't be fixed, suggested that they use the same methods to cut out all the old middle tier code and replace it with the new code generated from the database schema.

What was the response?  "That can't be done."

Well, yes it can and my guy just did it.  

In fact, our sister company Sentia Health, just went through a complete rewrite of its EMR's entire user interface a few months ago.  That is fairly comparable to what my guy suggested to Jack Henry.  In another month or so, we are going regenerate the middle tier with an upgraded version from the new ORM that we have developed.  that is PRECISELY what we suggested to Jack Henry and they said couldn't be done.

I still haven't given you the reason I made you read the Jack Henry Story.  Here it is: Business doesn't want "outside the box" thinking.  Further, they don't recognize it when they see it, or even when it is shoved down their throats and proven to work.  There it is.  THAT is the reason.

So yeah, we still haven't addressed buzzwords.  The business guys don't get those either.  XML, Web Services, XAML, Big Data, WPF, WCF, SOAP, REST, NoSQL, Hadoop, don't make sense in most applications and some don't make any sense at all.  "The smart guys  got a PhD for a dissertation on Big Data so I need some Big Data in my solution!"  Well, no, you don't and there is no such thing as big data.  Microsoft has a Big Data solution and it has been around for decades: SQL Server.  Don't run procedural code against your unstructured data, structure it and run set based code using a database engine.

So once again, it is conclusion time.  Until we quit letting the MBAs run anything, including their mouths, we are never going to get anywhere useful.  Regular readers will recognize the Bob Cratchit theory: Businesses are doing nothing differently now than they did in 1843 at Scrooge and Marley's counting house, they just have the spreadsheets on a computer today.

The conclusion of the conclusion is to let the MBAs worry about funding and shares and corporate structure.  Let the truly smart people decide HOW things are going to be done.  THIS is what we have and THAT is what we want and we software guys will show you the best way to get from THIS to THAT.  At Sentia we have automated entire businesses.  Not just one, not two, but many.  We took an existing business and automated it to the point that there is nothing to do but click the "Send bills" button at the end of the month.  Literally.  In the most recent case of Coffee County Alabama Office of the Constable, We spent three days writing a system for the deputy constables to issue electronic tickets.  No paper.  No filing cabinets.  No lost documents.  We wrote it for free and they use it for a $10 monthly subscription per login.  The automatic generation of cases for the constables and the automatic generation of court dockets alone pay for the system, since they no longer have to pay someone to produce these reports.  Even better, If you get pulled over in Coffee County, you probably are only going to be issued a warning, because they now have the ability to see if you are an habitual offender.  You don't live there, so you get a warning.

That is the way we do things: Automation, make it easy.  Doesn't everyone need some of that?

You Can't Automate Judgment and You Should Not Try

I have been corresponding recently with a couple of my code monkey buddies, both hard working, brilliant developers.  They are complaining about the big applicant tracking packages employed by larger companies, that is, Oracle's Taleo, iCIMS, Bullhorn, et al.  
They complain about several things:

• duplicating information
• complicated password algorithms
• dumb questions with "N/A if no" answers
• half hour or more to apply for a job  

Yes, there are some jobs that can't and shouldn't be automated.  Stock trading.  Engineering.  Putting eyeballs on a resume.  In the new age of information, We have people doing all kinds of menial tasks like opening and filling out spreadsheets and then emailing them around, that could and should be automated.  Then we have some dumb piece of software actually making value judgments about something that even the person who came up with the requirements doesn't understand.  Here is an example: My friend Randy is applying for a web developer job.  One of the questions, after he retyped all his employment and education history that was in his resume of course, was "How much Web API experience do you have?" For those of you who don't know, Web API is nothing more than an MVC controller with HTTP methods like GET, POST and PUT.  So instead of having a Create method in the Person Controller, you'd have a Post method with the exact same implementation.  The only difference is the naming convention.  Randy has built dozens of MVC applications, but has never even created a Web API application, because there is nothing to know.  If he answers truthfully, he will certainly be passed over.  If he give s a more correct answer, like 'all of it' he could been fired down the road for padding his resume.  

This is indicative of the biggest problem in business today.  The people running a company literally have no idea what the company does or how it does it and can't even recognize talent when it comes knocking.  Years ago, the big buzzword was XML.  Every job description you read REQUIRED the applicant to be able to read and write XML.  Don't get me wrong, it's a great technology for inter-operation and essential to web services like SOAP.  However in 20 some years of development, I've never had to read nor written XML.  It's kind of like saying 'Do you have and can you explain your experience with breathing?'  
'Yes, and no' in that order.  Yes, I breathe, no, I am not going to give you a lecture in the chemistry of what happens in my lungs.  You don't need to know.

Almost 30 years ago, I was helping my father frame a house.  I stood up on the joists and he cut off and handed rafters up to me.  Having been exposed to trigonometry, I was amazed that not only did Pop remember all the tables we had to memorize for trig, but that he was doing all the calculations for the rafter length in his head.  I asked him how he did that.  He said "you don't need to know."

I stewed on that for about 30 minutes and decided that I do need to know. I got a little belligerent and more forcefully posed the question again: "How do you know how long to cut off the rafters?"  

He looked a little sheepish and replied "I don't know how long to cut off the rafters.  It's built into the carpenter's square.  Literally, you don't need to know." then he showed me how to cut off rafters with a carpenter's square.

What is the moral of the story?  Sometimes, you just don't need to know.  Randy doesn't need to know how long to cut rafters, he doesn't need to know how to breathe, he doesn't need to know XML and he doesn't need to know Web API.  You just don't need to know.

In our post at SentiaHealth.com on September 2, 2016, Theory of Constraints: An Holistic Approach To Solutions Architecture: Why You All Are Doing It Wrong and What To Do Instead, we introduced Eli Goldratt and the Theory of Constraints and its application to the software industry. Mr. Goldratt states

Technology can bring benefits if and only if it diminishes a limitation.  Long before the availability of technology we developed modes of behavior, policies, measurements and rules to help us accommodate that limitation.  If we want to be successful with the implementation of new technology, we must find the things that helped us live with the old limitations and change the rules to take advantage of the new methods.

So what we need are smart people doing smart things, not Human Resources managers looking for buzzwords and weeding out people who don't have them.  If you are going to successfully remove weeds, first you have to know what a weed looks like.  Today we are picking on Human Resources but that department is just indicative of the larger problem.  The problem is that literally nobody is taking advantage of the new technology to rid us of the limitations we have imposed to solve problems that we no longer have.  You don't need spreadsheets anymore.  Conversely, an in this example with Taleo et al, we have a limitation that technology cannot help with.  You cannot (currently?) teach a computer to read a resume.  You have to have human eyeballs and human judgement to figure out if someone is qualified for a technical job.  That is it, No way around it.  I say this, me, the guru or all things automation.

Even worse, Human Resources itself is attempting to do a job they aren't designed to do.  They don't understand the technology, clearly, or they wouldn't be using software to automate an unautomatable job.

Yes, technology can help. Your "apply for this job application" should be a link to upload your resume.  Process automated.  You don't go to the hardware store and ask the clerk about the materials used to create your wrench or hammer or pliers.  You don't know how to make those things so even if the clerk told you that this particular wrench was constructed from chrome plated, cold forged, 4140 chrome-molly billet, and he can't because he doesn't know either, you won't understand what that meant anyway.

Once more, if you can't do what I do, and you can't, don't presume to tell me how to do it.  Go get a copy of Eli Goldratt's "Necessary But Not Sufficient."  80% of any business today can be automated.  That means 80% fewer people, 80% fewer buildings, 80% electricity savings and 80% less cost.  It also means you should be able to cut the price of your product or service by 80% and still make the same profit.  I know this is true because I run MY business that way and I have automated 80% of the production of my products and I am 80% less expensive than any competition.  Know what the 20% is that can't be automated, however.  Get to know old Pareto.  Let's remove the old limitations and free the spreadsheet emailers of the world to think and innovate and be a profit center, not a cost center.  Let's think and innovate and NOT attempt to automate the unautomatable.


        

Due Diligence In Selecting Technology

Information Technology is not a religion.  Your buzzwords are not a mantra.  When a developer is confronted with a new technology s/he must evaluate this new technology and decide what the value is in relation to the learning curve, not just jump on the bandwagon.  Even worse is the management type who decides he is going down a technological path because he met the Tableau salesman on the golf course.  

At Sentia we take the technology selection process VERY seriously.  We choose Microsoft not because we are told to or because we are familiar with it, we choose Microsoft because it is the ONLY vendor who provides a complete solution from database to desktop to web.  We choose Windows not only because it is the Microsoft operating system, but because it doesn't require a six figure administrator to configure and make work.  We choose SQL Server because it is faster than Oracle (the only other real choice) on Windows. We choose .NET because it has a well documented amazing Integrated Development Environment (IDE) in Visual Studio, and it doesn't need a ton of other tools to develop applications. Gradle. Eclipse.  IntelliJ.  YourKit.  Clover.  The list goes on ad nauseum.  

We are so adamant about choosing the right tool for the job that we didn't even develop web applications until 2009 when Microsoft introduced their version of the Model/View/Controller (MVC) technology that got rid of the notion of statefulness across the internet and gave us a way to build web applications that made sense.  At the time it didn't make sense to jump ship to Apache/PHP on Unix/Linux (pronounced Line-Ux, the guy's name is Linus Thorvald) just to get web technology that makes sense.  I might make a different decision today.

Sure, Microsoft has made some grabs at the money tree with SharePoint and BizTalk.  These applications are designed to make a complicated task easier than it is.  SharePoint is nothing more than FrontPage (a WYSIWYG web page generating tool), along with document management.  You already have a powerful tool to develop webpages and web applications in Visual Studio (the IDE we talked about above) and you don't need documents.  No really.  You don't need documents.  An attorney MIGHT need a signature, but the contents of the document should be put in the database so it can be indexed and searched.  SharePoint is the electronic version of a file cabinet and the people who advocate, develop for, and use it should be fired.  BizTalk is more of the same.  It allows developers to use disparate data sources as native.  We already have a way to use any data source as native with SQL Server Linked Servers.  In fact, Linked Servers is the basis for Sentia's Information Integrator, an ETL tool that is so easy to use we think anyone can do it.  

Yes, we also know that we have to use JavaScript or can use jQuery or AngularJS or some other plug in to make out webpages look pretty and add functionality.  Microsoft was so dead set on ASP and ASP.NET that they attempted to force everyone to use their technology.  Now however with the advent of MVC and NuGet, we can use these plugins and maintain versioning on them (there seems to be a new version every week) easily with Microsoft tools.

What do we get for this loyalty?  We get a single group of developers who can do everything that needs to be done, from start to finish, without having to learn the latest flavor of some dumb Java tool or write a servelet to make Apache work, or know nothing about database design and development because they have never seen one.  We get to say 'This is the way we do things' and if that way changes, we all change together.  We get to build tools that automate the development of software because we all agree that 'this is what we do, and this is the way we do it.'  We don't have some new guy saying 'Gee I know this and I use that'  We have the old guys saying 'this the the best way and we know because we spent the time and did the due diligence to make sure that it is.'

The conclusion is that with this methodology, and the tools we have developed to generate about 80% of the code we deploy, we always do the same thing, the same way every time.  This makes the code base easy to read, intuitive and simple to maintain.  That doesn't even count the elimination of 80% of the development time and expense for our clients.

Really, if you have anyone else develop your applications, you are making a mistake.  If your project is done differently, it is done wrongly and you will save your time, money and effort.  Even better, if we can automate what we do, we can automate what you do.  We have clients who used to run themselves ragged 80 or 100 hours per week, dozens of employees, emailing spreadsheets and working fingers to the bone, who now only click a button to generate bills at the end of the month.  80-100 hours to 35 seconds and dozens of expensive employees to none.  It isn't religion, it is efficiency.  That is what we do.

http://sentiasystems.com

Object Relational Mappers: Why and Why NOT Use Them

As developers, we find that the database king; it is the foundation on which all other software is written.  The problem with that is that nobody starts out as a database developer.  In our quest to become the perfect developer, almost all of us neglect the first and most important step, learning about databases.  First, we find ourselves struggling to wrap our minds around set based programming (remember trying to find a quarter sized rock using tweezers and a magnifying glass instead of two boxes, one with holes slightly larger than a quarter and the other with holes slightly smaller?)  Second, we have to pick some type of data access language and understand that whatever it is that we pick probably has memory leaks and definitely has a ton of overhead.  If you live in Microsoft's world you have to remember to close your ADO.NET connection and dispose of your objects when you are done with them.  Third, we have to decide how to model the middle tier objects and what logic goes where.  There is little wonder that most (I've heard as high as 90%) new software begun has never seen production.

So there has to be a better way, right?  Surely someone has written an application that does all this grunt work for you.  Enter the Object Relational Mapper.  Wikipedia states:

"Object-relational mapping (ORM, O/RM, and O/R mapping tool) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to construct their own ORM tools."

"That sounds great!" you say.

"I want one!" you exclaim.

"Which one do I use?" you ask.

Aye, but there's the rub.  Honestly, if you don't understand what all this automagic stuff is doing, you probably shouldn't use it.  First, I eschew using anything that doesn't allow me to pull back the curtain as see how it works.  Microsoft provides Entity Framework which installs all kinds of visual geegaws to access your data, and all kinds of code with the warning (and I paraphrase) 'You don't know what this does so don't mess with it.'  If that particular code doesn't do what I think it should do, I want to know why and I simply can't.  All of the ORMs I have used and heard of suffer from this problem.

Another problem is that you don't know what kind of set based code is getting run on your sever.  One of the biggest problems with any application is "it's running slowly" and everyone looks at the database.   If you can't see the code running, you certainly can't troubleshoot it. 

Best database design practices are to lock the users out of the table structure and all data access is done through stored procedures, so we can apply logic and security and auditing.  Unless your ORM writes procedures (and it doesn't) you have to write them yourself.  That kind of makes the ORM useless as a code generation tool, since you have to write your own code anyway.  Even worse, all the set based code I've seen, is horrible.  if you venture one little pinky toe outside of simple Create/Read/Update/Delete (CRUD) operations and you will, you have to do searches at a minimum, the set based code passed by these ORM tools gets hairy fast.

We, here at Sentia wrote our own ORM, and we call it the Object Relational Mapper (of course).  We think of it less as an ORM and more of a code generation tool that we use to produce the same code that we would have written by hand anyway.  Sentia's ORM produces all the stored procedures for CRUD and additionally provides a Search capability as well.  More stored procedures are generated to access related data.  If we want all the blue cars we do a search where car.ColorID = 36 (36 is blue and we can search for that as well) but we can also search for many to many relationships.  If we want to get a student's class schedule it might look like this Class class = new Class(student.StudentID, GetClassesByForeignKey.ByStudentID).  That might be the very first line of code we have written in this application, it uses stored procedures so we can be secure, and it is returned by code that a good developer might write, not some black box that has a skull and crossbones warning on it.

There are several things we've had to do over the years to make the code produced by Sentia's ORM more usable.  We put all the generated code in a 'Generated Code' folder so we can tell what was produced and what was hand written.  All the generated code is put into partial classes so that we can extend the functionality of them without having to come up with kludgy new names.  We are working on an application where the user can sign up for the service.  All calls to the database require a username and password that a new user won't have.  We has to extend the Professionals class with a new method that took a new professional object with its properties set called CreateNew that didn't require a User Name and Password.  This is all seamless to the downstream developer of course.  he would expect to see professionals.Add or Professionals.Delete in the intellisense menu, and now s/he can also see CreateNew(Professional).

What is the conclusion?   We decided that Sentia's ORM should write the code that we would write if we were absolutely perfect and did everything that we were supposed to do.  In many ways, generating code like that is the ONLY way to get it.  Otherwise, using nHibernate or the Entity Framework or whatever other half-assed thing you need to get the job done is ok, if you are writing a movie list application for your mother to access her collection online or you are a junior developer who can't get the job done any other way.  If you are a junior developer and you can't get things accomplished any other way, know that you are going to have scalability and security problems.  Even worse, you can't write the code that Sentia's ORM generates.  We can't.  Even we end up cutting corners sometimes, and it takes us weeks or months to do the same work completed in seconds with Sentia's ORM.

What should you do, dear reader?  You should either come to work for us, or give up and have us write your application for you.  Heck, if you sell it for the price you think you can produce it for, call us and we'll do it for half. 

It ain't arrogant if it is true.

If You Are Using Email for Workflow, Excel or QuickBooks At All, You Are Wasting Time and Money

That statement probably just cheesed a whole lot of you off and the sad part is that it is 100% true.  Here is what you are doing now: you get some kind of information over email from someone in your organization.  You do a little number crunching in Excel and attach the spreadsheet to an email that you then send to accounting.  In accounting, the spreadsheet is opened, maybe some more number crunching goes on, the data gets entered into QuickBooks and maybe a check is issued or a report generated. Sound about right?  This is absolutely wrong, and it’s not just the top three offenders here, it is every separate application you type anything into.

Don’t feel badly, that’s the way everyone, from Bank of America on down, does it.   There is a better way.  What if the person who generated the data originally could type it into a custom built application that does exactly what you do, for you?  Let’s take an example.  You have a guy on the loading dock receiving shipments.  Usually, s/he will count the number of boxes and sign a bill of lading and hand carry a copy to Accounts Payable who types the items in to QuickBooks then issues a check.  What if, instead, the guy/girl at the loading dock, scanned each box as it came in and this hypothetical piece of software recorded it, counted it, added it to inventory and issued a check to pay for it and put it in the ledger all in one fell swoop?  What if the warehouse person scanned the box and the barcode at some location in the warehouse where the box is going to live until the contents are needed?  Then you know where the box is, what and how many it contains, how long it has been there and what it has cost you to warehouse it, since you know how many cubic feet are in the warehouse, what the fixed and variable costs for it are and the size of the box.  You just eliminated all the overhead in your company that doesn’t actually move the ball forward AND gained valuable insights into cash and inventory flow.

We already told you that everyone runs a company the former way and not the latter.  Many of you are too young to remember Braniff, so we’ll use a more recent example (and we’ll also discount the financial sector since they are not too bright (how to you have billions in assets and go bankrupt? (the question is rhetorical, I know what happened (and they are still idiots (and I know you love my nested parentheticals)))) and the energy sector since they financial sector took them down in 2008 (…and Enron cooked the books)).  USAir filed one of the largest bankruptcies in history for the same reason Braniff did: they don’t know how much it costs to fly you from Point A to Point B.  Substitute Chrysler. Substitute Worldcom.  We use USAir because what they do is more of a commodity.  So if they don’t know how much it costs to fly you where you want to go, and someone else has a sale and can do it cheaper and the brass at USAir thinks that nobody can do it better, they price their service lower, and less than it can be provided for, and BAM bankruptcy.

I tell you the USAir story for one reason.  If they used a system like the one I can build for you, they wouldn’t have failed.  They would know that it takes X number of pounds of kerosene for your particular trip and that the kerosene going into that airframe was bought for Y dollars per pound and the airframe itself can be amortized over Z years at a cost of W per year and the pilot makes V dollars per flight and the attendant makes U dollars per hour and the maintenance is Q dollars per month (they don’t wait for parts to fail, when they get so many hours they replace them (you can’t just pull over on the side of the sky) and on and on ad nauseum.  The point is, it is calculable, and they could have done it and didn’t, they depended on YOU, dear reader, to bail them out.  So if they knew how to calculate the cost of your trip, they could add whatever profit they deem appropriate and go about their business.  When American or Delta offers a sale that is less than the cost of providing the service, you can laugh up your sleeve and let them. Then you can watch Delta and American go file bankruptcy.

Notice how we switched from USAir to you?  Yes this all applies to you.  Whether you are a roofer or an accountant or Brian Moynihan (of Bank of America) if you are emailing spreadsheets, or even have separate applications for HR, Accounting, Warehousing,  Project/Process Management, you are missing the boat.  You need one application to rule them all so that when the product hits the dock, the check gets printed (or ACHed, whichever).  Or when you make a sale, the proceeds go directly into accounting, no typing, and therefore no people required.  People are expensive and they make mistakes.  Software is comparatively free and doesn't need to type.  If you have this kind of application in place you can automate everything but the actual hammering of nails and selling of houses (or building and selling Chryslers (they automate a lot of the production too) or flying people around the country).  …and you can automate a lot of the marketing as well.

So yes, Virginia, there is a Santa Claus.  If nobody else is doing business this way, and you can, you should.  …and put your competitors out of business.  If you go to one of our sister company’s website http://sentiahealth.com we will explain how we automated the entire health insurance industry.  That will save the American health insurance consumer about 1/3 of their bill.  Not $300, $200.  Not $1200 for your family, $800.  Collectively, we will save you (all) one trillion dollars.

We have done the same for several companies, and we can do it for yours.