I am powerfully influenced by stories. Stories - not just from a book or as
told by my mother. I’m talking about movies, books, newspaper articles,
worldviews, parables, mission statements, commercials, gossip, sports games,
worship services, and the lies that I tell myself when I don’t want to face a
But I am not alone. We all are people who live by stories. Dr. James K.A.
Smith brings this out in his book, Imagining the Kingdom: How Worship
“What we do is driven by who we are, by the kind of person we have become.
And that shaping of our character is, to a great extent, the effect of
stories that have captivated us, that have sunk into our bones -- stories
that “picture” what we think life is about, what constitutes “the good
life.” (Smith, James K.A., Imagining the Kingdom)
I think that is why Jesus spoke in stories.
Years ago, I remember being frustrated that the Bible was full of poetry and
stories, history and drama. I remember wanting to find principles of right
living and belief well laid out in orderly propositions ready to be learned
and memorized and lived.
What do I mean by “getting propositional truths” from the Bible? Just asking
“what does that parable mean?” is in one sense an attempt to derive a truth
statement, a proposition, from the biblical passage as a gem of truth. We do
it all of the time. It is said that when T.S. Eliot read his poem “The
Wasteland”, which is a tad long and very complicated, after he finished
someone asked him what it meant. At that point T.S. Eliot merely read the poem
all over again.
Anyway, since I knew that the Bible wasn’t laid out in propositional form, I
thought that the goal of Bible study was to ferret truths out of the Bible as
propositions of hidden gems of meaning. Why weren’t the biblical writers more
logical and organized? I thought to myself.
But what I had failed to see back then, which I am starting to see now, is
that I had naively bought into the Western rationalistic worldview that
believed that all truth could be distilled into propositional form. To my
mind, the propositional form was truth in a more “pure form”. It never
occurred to me in my wildest imagination that converting the biblical stories,
poetry, and the other literary genres found in the Bible into propositional
form was actually losing as much truth as I thought that I was gaining. I
wasn’t making the truth more pure, I was corrupting it. I did not know that
story itself was a container for truth that propositions could never be. I did
not know that distilling a parable into what it means written as a proposition
was tantamount to pouring fine wine into a leaky bottle -- too much value is
lost and I never realized it.
But why can stories hold more truth than propositions? What makes propositions
so ill suited for conveying all truth? It probably has something to do with
the fact that God made humans, not computers.
God made all of us as narrative animals. We are people of stories. We don’t
just appreciate stories, or like them, or love them. It is much more than
that. We don’t just understand stories better than propositional truths.
“We need stories like we need food and water: we’re built for narrative,
nourished by stories, not just as distractions or diversion or
entertainments but because we constitute our world narratively. It is from
stories that we receive our “character,” and those stories in turn become
part of our background, the horizons within which we constitute our world
and engage in action. I cannot answer the question, what do I love? without
(at least implicitly) answering the question, what story do I believe? We
tell ourselves stories in order to live.” (Smith)
So what? Where is this going anyway?
Just this. We need and thrive on stories because God made us that way. That is
it in a nutshell. That explains why when I see a powerful movie, that it
invades my dreams and even my waking thoughts for a day or so afterward. That
is why propositional truth in it’s many forms can seem so dry and uninspiring
-- yes, it is true but the truth in that form “has lost it’s muchness.”
A good story can convey not only a truth but an emotional experience as well.
Take Ernest Hemingway’s 6 word story, for example.
“For sale: baby shoes, never worn.”
James Smith noted that maybe the biblical equivalent would be this.
“He is not here; he has risen, just as he said.”
God gave us stories because he made us creatures that are driven and inspired
by our imaginations, which are in turn fired by our emotions, which in turn
are activated by stories.
God’s stories, or better and more accurately, God’s story, is explained and
explored from cover to cover in the Old and New Testaments. And God’s story is
overflowing with hope and wonder and promises for good things for his people.
God has provided his people, who are called by his name, a family history in
the biblical text. Our family history is there because it is the story of
God’s people and we are God’s people too.
So, as we read God’s Word as individuals and families, as congregations and
small groups, day by week by month, year, and decade -- we are immersing
ourselves in God’s great story. We allow it to define our character as it
shapes who we see ourselves to be. We allow it to touch our emotions and by
that touch, like the touch of the Master himself, we are changed degree by
degree, here a little, there a little. God’s stories do what truth in
propositional form can never do -- they impact us at the emotional level. And
it is at that level, the level of the heart, that we discover who we are and
who we belong to. We belong to the God of hope and promise and if the Bible is
anything, it is a book of God’s testimony to us his people of how wide and
long and deep are the promises of God for his people, who are called by his
While not wanting to make too much of what amounted to a passing comment, the
Midwife-EMR software did receive a word of praise from Philippine Department
of Health officials during a licensing inspection of the clinic where the
software is being used.
In a text I received from the founder of the clinic:
"DOH spent 5.5 hours inspecting clinic today regarding new licensing
requirements. They loved your EMR system. They were very, very impressed!
They particularly liked the summary report and at a glance thing."
I'm glad that they liked what they saw. They weren't there to inspect the
software, just the clinic. But since the clinic, as far as prenatal exams are
concerned, operates by means of the Midwife-EMR software, the software has now
become quite central to their operations. Midwife-EMR was used to manage 988
prenatal examinations in May and 1024 examinations in June.
In my last post I mentioned that I was writing a "mini-pilot" using AngularJS
that will allow authorized users of Midwife-EMR to review historical changes
of any patient record. This is essentially a SPA application within a regular
full page refresh application which will allow the users to go into "history
mode" to quickly review historical changes.
At the data level, what makes all of this possible are triggers on nearly all
of the patient tables that store a copy of all changes to the database
(inserts, updates, and deletes) to a corresponding log table. For example, the
pregnancy table has a matching pregnancyLog table with the same field
structure and an additional "replacedAt" field and "op" field. The primary
index on the log table is on the "id" and "replacedAt" fields as opposed to
just the "id" field. For each table, there are three database triggers to
handle inserting changed records into the corresponding log table - one for
insert, update, and delete. The "op" field records which of these three
operations were involved in the record change. There are 21 tables that are
logged in this fashion.
At the application level, all of these logging activities are behind the
scenes. With the logging triggers in place, the "business" logic of the
application doesn't have to concern itself with the need to log all changes to
the corresponding log table because it just happens.
In order to make the maintenance of the log tables and triggers much easier,
the creation of the log tables and triggers are managed by shell scripts. This
makes schema changes a lot easier as well as helping to insure that
inadvertent coding errors don't sneak into the trigger logic itself - or at
least it becomes a bit less likely.
All of this logging has been in place since the beginning of the project which
means that the historical data is already in place and ready to be used once
the history viewing "mini-SPA" comes online. That makes getting the data for
viewing historical changes relatively easy because it is already right there
"for the taking".
The midwife using Midwife-EMR on a tablet.
Midwife-EMR is being used on 6 different Nexus 7 (2nd generation) tablets in
addition to the various laptops, desktops, and a few phones. Mercy Maternity
Clinic purchased the tablets because they were less expensive than laptops and
they did not require a desk like a laptop would. Space is at a premium at the
clinic and there physically was not enough room for a desk next to each
examination table. But a tablet, on the other hand, is extremely portable and
Midwife-EMR is a web application. It uses standard web technologies like
laptop or the tablet. Each action results in a page refresh and the pages
Responsive design is used to allow the view presentation to adapt to the
screen resolution of the various devices such as desktops, laptops, tablets,
As a developer, I have always wanted to build Midwife-EMR as a single page
application (SPA) using AngularJS and possibly using web sockets for the
communication layer with the backend. For the pilot, I resisted doing this
because I estimated that an SPA architecture would have added about 30% to 50%
additional work to the initial effort in order to bring the project to pilot.
I'm glad I made that choice in hindsight because we got to pilot faster but I
still think that a SPA design could provide the users with a better user
Though I have to admit that the users have been much more accepting and
enthusiastic about the standard web technologies that I used, i.e. full page
refresh for each page, than I would have guessed. Actually, I have been more
than surprised at this. Maybe they have just been so appreciative to have
any software to use? Maybe the standard full page refresh is not as "bad" of
a user experience as I think it is for this type of application? Maybe they
don't understand what a SPA designed application is and what it would mean for
their user experience?
In order to pursue this idea a bit further, as a small mini-pilot, I am
developing a new feature for the Midwife-EMR project that does use SPA
technology. The feature will allow the user with the proper permissions to
view the historical changes of a patient over time. All historical records
will be read-only and allow the user to move forward and backward through time
seeing the screens as they appeared at any particular point in history.
Basically, this is a means for a supervisor to see who changed what and
when in a patient's prenatal history, which is a pretty useful feature to
have for a medical application.
I'm using AngularJS version 1.4 for this with standard AJAX for communicating
with the backend. I'm developing a REST-like API on the backend that returns
all of the historical records in JSON format to the client. Due to the
triggers on the database that log all changes for later reference,
querying this information from the database is dead simple. All of this occurs
over HTTPS with appropriate security just like the regular portion of the
Initial tests and prototypes are positive. I am hopeful that the users will
appreciate both greater access to the historical data than they now have as
well as the improved user experience that is often a characteristic of a SPA
design. Based on how this is received, we will see how feasible it is to
refactor the whole application to use a SPA design sometime in the future.
Whenever anyone asks me about the bit of jogging that I do, I usually answer
with the refrain, "I may not run far, but I'm slow." But I have learned not to
say that to someone whose first language is not English because invariably the
joke somehow gets lost in translation. Generally speaking, jokes don't survive
a language barrier.
Another thing that does not survive the communication barrier is trying to
explain why it takes a long time to develop custom software for a signifcantly
large project like Midwife-EMR.
And I can understand that. I mean, there are only so many screens and a
handful of reports and getting it to run on a low-powered device a little
bigger than a credit card. Is it really all that complicated?
Well, yes - it is rather complicated. But I don't know how to communicate
that. I know that trying to explain it to someone who is not another software
developer is not going to work. Just like a tax accountant explaining subtle
nuances of corporate law or an electrical engineer explaining how circuit
boards work, most of us don't have the patience for listening to an
explanation outside our own fields of interest and expertise. That is not bad,
So how do I convey the level of effort involved? One metric that has always
been a part of software development are the number of lines of code. I won't
get into the pros and cons of the number of lines of code as a measurement
tool at this point. (Since the metric is not being used in my own performance
review, I don't mind sharing them now.)
As of May 8, 2015 there are 32,425 lines of code in the Midwife-EMR project
(code that I have personally written, not 3rd party code). Yes, that includes
comments and whitespace, but I think that comments and whitespace are part and
parcel of writing decent code. It also includes all of the various languages
- Jade: 5,744
- SQL: 2751
- Bash: 268
- CSS: 198
Why do I write this? Is it to try to justify my own efforts to this point? Is
it to boast about what I have done? Or is there really any difference between
trying to justify my own efforts and boast about what I have done?
I am feeling insecure about what I have done. Even though the software is
being used and is really appreciated by the maternity clinic, the insecure
side of me wants the assurance that I have done well.
But this type of insecurity is not solved by lines of code or appreciative
comments or someone telling me that I did well. As a Christian, basing my
self-worth upon something as volatile as the ability to write code is shaky
ground. I am justified by Jesus who died for me and it is not based upon my
performance, but his. Sometimes I just need to remind myself of this again ...
So I find in the end that the one who is sure and steady does win the race.
But it is not in reference to me or my code or the project or the clinic that
is using it. The sure and steady one is Jesus who is the rock of my salvation
and whose kingdom will never end or fail.