Spending a day writing code makes me feel younger. Writing code well into the evening and next morning makes me remember I'm not so young any more. I code like I write, getting out the raw ideas on the page, and then going back and neatening up afterwards. What is most important is the raw concept. I often start out with a high level outline of what I want the code to do, especially if it's implementing a complex algorithm.
Modern tools make it easier to go back and refactor my code, which I do rather often. When I wind up doing the same thing twice or three times in different places, I usually copy and paste the first one or two times. The third or fourth time, I create a method to do it, often in the class I'm writing. After a while, I collect a bunch of these methods that are helpers, and put them somewhere else.
Modern tools also make it very easy to document my code. Sometimes I start with the documentation, at other times, I start with the code. I leave a lot of bread crumbs, little TODO markers about things I haven't finished, or things I'd like to do differently later. These are things I can do in later iterations, but often aren't essential to the raw idea I'm trying to finish right now.
As I finish each task, I check my code back in to a source repository. Most of the time I'm not working with others, but when I am, that also means that I have to be careful to merge my changes back in. Coding has a necessary build and test component. When I make changes, I have to be sure they work. After I've merged changes back, I have to make sure that a) my changes still work and b) that the code I've merged back with still works.
There's nearly nothing like this when writing Healthcare standards, but it is certainly changing. One of the nice things about what Grahame Grieve has done with FHIR is develop a great set of tools that produces the standard. There are a variety of resources that you can create and edit, and when you are done, there is a build process that generates the standard. If there's a problem, the build tells you what is wrong.
He's even gone so far (and at this point I'm guessing), as to take the data from the standard, and turning it into code automatically.
The same thing is true for tools like MDHT. You build a model, based perhaps on an existing one (e.g., like CCDA is on CDA). From that, you generate the guide. And the testing tools. And a reference implementation in one or more programming languages. While it's taken us nearly two decades to get from the clunky compilers and code development tools we had to where we are today with modern IDE's, FHIR and MDHT have done so in a lot less time (a year, and a few years respectively). MDHT builds on some of the same modern tools we use to write code. No, there isn't really a FHIR IDE environment. That's much closer to my ideal of simple things put together in really interesting ways to produce a complex result.
I haven't done much standards development with FHIR or MDHT, and should really be doing more. If I did, I'm sure I could figure out a way to make it possible to build some kinds of IHE profiles much more quickly. For example, a simple spreadsheet containing the actor transaction table written in a certain way could be used to automatically generate the Actor/Transaction diagram. Some of the IHE Connectathon tools do this using GraphViz (an open source graph generator). I've done similar things using a database of IHE Actors and Transactions.
The challenge with this is that this kind of change impacts standards developers who are familiar with the current way of doing things pretty radically. Some will never use new tools, because they are already quite comfortable with what they've been using. And new tools take time to develop and make their impact felt. They usually don't start out solving the whole problem. In order for them to be adopted, they have to address enough of the existing problems better than existing tools, and not create enough new issues that cause more pain (the whack-a-mole problem). You also need to have a cadre of people who have enough interest in trying out a new way of doing things to make it take hold. And they have to be willing to deal with change and potential of the new way of doing things.
To have time to build these tools, other urgent problems might have to wait. That makes it even more challenging, especially now when so many things are going on. This is where you need to step back and thing about what your priorities are. If you can't ever reduce the rate of production to increase later capacity, then you have a critical challenge. Someone else is likely to figure out how to automate your process and will eventually be able to outpace you.
What is really scary about this is the end result. If the current pace of standards development is impacting you severely, increasing it yet further is not something you might be willing to consider. You have to move beyond scary, and realize that even though the pace of innovation might increase, the amount of effort could decrease quite dramatically. I'd be happy producing twice the output with two thirds of the existing effort.
The one thing that we aren't automating is the review stage of standards. MDHT and FHIR both rely dramatically on using data to generate standards. They make it relatively easy to generate hundreds of pages of text (and thousands of lines reference code) from a dozen or so models. Reading hundreds of pages of text to ensure that it is right is still a daunting task. I'll write a bit more about that later.
-- Keith
P.S. Just to show you how my mind works, I started writing this post without any idea where it was headed. The first two sentences were on my mind, so I wrote them down. The rest of the post wrote followed from there.
0 comments:
Post a Comment