How Did We Get Here? The Evolution of Open
Open is a journey, not a destination. Open means you facilitate the exchange of information between programs; you make it easy for your software to talk to other people’s software. The need for Open technologies has shaped standards, which evolve over time to meet new challenges and address shortcomings of previous standards.
It All Started with Punch Cards, EBCDIC and ASCII
Back in the ‘60s there were two competing standards for how computers would store data—one was proprietary to IBM main frame computers called EBCDIC. Pretty much everyone else used the other standard, called ASCII.
EBCDIC can trace its roots back to the punch card standard, invented by Herman Hollerith in 1894 to help tabulate the 1890 U.S. Census. He also founded a business that evolved to be the company we all know today as IBM. EBCDIC represented how card punches used to work—how do you convert those holes in the cards into binary? How about a hole is a one, and a “not hole” is a zero. Today, computers still store everything in bits of 1’s and 0’s.
IBM standardized everything they did on EBCDIC. IBM printers expected data coming to them to be in EBCDIC, tape drives, and of course IBM computers. While EBDIC could represent card punch data easily, it wasn’t up to the task of storing data.
“The web is the ultimate platform for exchanging information and the world needed a better way to view documents on computers, which was the impetus behind HTML”
Enter the “new” Open standard of ASCII. The rest of the industry adopted the common character standard ASCII. Printers made by Data General , Digital Equipment, Unisys, Xerox — they were all interchangeable because they spoke a common language. That common exchange format enabled these companies to innovate and compete against one another.
In those days of yore, you could say you were Open if you stored data in ASCII. That’s how data was sent from component to component. But soon people wanted to do more; they wanted to share data from system to system.
Sharing Data Between Systems with EDI and HL7
In the 1960s, ‘70s and ‘80s EDI (Electronic Data Interchange) was a filebased messaging protocol that enabled grocery stores, banks and others to do business with one another more easily. EDI described a particular file format for requests, placing orders, responding, etc. There were lots of pipes “|” and carets “^”—making it nearly impossible for humans to read it easily.
In the late ‘80s and early ‘90s, healthcare borrowed a lot of the concepts from EDI and started creating its own set of standards that we know and love as HL7. HL7 messages. HL7 messages look like this (very abbreviated) MSH|^~&|Reg|Hosp|OE|ImagingCtr|20060529090131-0500||ADT^A01^ADT_A01|01052901|P|2.5 EVN||200605290901||||200605290900
State-of-the-art healthcare data interchange in the ‘90s involved some level of HL7 interface support. In those days, that’s what “Open” meant—it meant we can collaborate with other pieces of software through an EDI-like data waltz. That was as far as the industry and the vendors would allow.
Then the World Wide Web Really Caught On
The web is the ultimate platform for exchanging information. The world needed a better way to view documents on computers, which was the impetus behind HTML. HTML is largely a visual standard—how is my web page laid out? Where are the buttons? HTML was the format that web browsers had to understand, and web site creators had to be able to produce.HTML gave birth to another standard that better represents data, called XML. Rather than being positional and rigid, like EDI or HL7, XML enables developers to tag data and extend formats on the fly.
Web services are not going to replace HL7 any time soon. There are still lots of important data exchanged with HL7. But web services lend themselves to building truly Open, integrated systems. Where EDI and HL7 focus on all of the data for a transaction, web services are far more interactive.
With web services, you can ask finer-grained questions. For example, if a clinician is writing a prescription, she should be able to engage with other applications to find out “What allergy manifestations are possible?” “What strengths does this medication have?” “Does this medication have any potential reactions with this patient?”
We used our web services to build all of our iPad products. You can read and write all areas of clinical information— allergies, vitals, results, orders, clinical documentation and more. It’s not enough to merely look up data, you have to be able to modify it, add to it—and put it back with the patient’s other records.
The Evolving Definition of Open
Standards have evolved from merely representing data, to storing it, to sharing it. In today’s technological landscape, when we say a platform is Open that’s because it offers a rich, comprehensive set of web services to reach deeply into the underlying system.
Open means we can connect systems more completely than we ever have before, we can exchange data in little, relevant snippets rather than in volumes at a time, and finally build collaborative, cooperative, innovative systems