Javascript is not a toy

This is really impressive!

Tech Team

Ron Ward whom I work with is slowly teaching me the advantages of working with Javascript. So far I have been utterly amazed at the advantages of doing just about everything in Javascript. I needed someone like Ron to show me real world examples because to be honest I never would have given Javascript the time of day.

Here is a quick example written by Ron which demonstrates the speed at which Javascript can accomplish a programming task that is extremely well suited to C,/C++ type languages.

Prime number generator

C++

Time taken to run: 1.358 seconds

#include <stdio.h> #include <stdlib.h> class Primes{ public: int getPrimeCount() const { return prime_count; } int getPrime(int i) const { return primes[i]; } void addPrime(int i) { primes[prime_count++]=i; } bool isPrimeDivisible(int candidate){ for(int i=1; i<prime_count; ++i){ int currentPrime = primes[i]; if( (candidate % currentPrime)==0 ) return true; } return false; } private: volatile int…

View original post 380 more words

JSLint, The Javascript Code Quality Tool

This website will hurt your feelings, as his creator Douglas Crockford says but it is definitely a must use tool for every Javascript programmer. See it below.

HL7v2 in JSON – Performance Considerations

After my last post about using HL7v2 in JSON I received some feedback from my colleagues that asked about performance: what is the overhead of parsing such a large message in JSON compared to a the same message in ER7.

Messages

For this benchmark I’m using a OMP^O09 message that has the following segments has “header”: MSH, NTE, PID; then 2 medications entries using two of each of the following segments: ORC, TQ1, RXO, NTE and RXR.

Size

To compare sizes, the same message was transformed to JSON format following the method described on the previous post. Some numbers about the sizes of each message:

     |Characters (with spaces)|Size (bytes)|
ER7  |                   1272 |       1279 |
JSON |                   3323 |       3330 |

As one can see, the message represented in ER7 is 40% the size of the same message in JSON. But, is this really meaningful? 3.3 kb vs 1.3 kb? On todays reality? Think not… Let’s see if the use of JSON has impact on performance.

Performance

To measure the performance impact of this change to JSON, I used Mirth Connect, an open-source HL7 interface engine, widely used and my favorite too. The first scenario is how Mirth Connect behaves when parsing ER7 and JSON to obtain the Given Name of a Patient => PID.5.2. The same message is sent to two Channels, one for ER7 and the other for JSON. The ER7 one receives the message and then Mirth uses it’s internal parser, that transforms the ER7 into a XML and then extracts the data and prints the given name to the console. The JSON one receives the message as raw data and parses it using the JSON.parse() method. After obtaining a Javascript object, the patient’s given name is printed to the console. To measure the impact of using raw data or HL7v2 XML data internaly in Mirth Connect, the start and end of the processing phase on each channel is also printed to the console. So let’s see the results:

                  |   ER7   |   JSON   |
Preprocessor log  |  0.000s |   0.000s |
Given Name Output |  0.007s |   0.003s |
Postprocessor log |  0.027s |   0.031s |
Total             |  0.034s |   0.034s |

Well, the first time I saw this numbers I couldn’t believe what I was seeing. To those of you who don’t know how Mirth does it’s internals regarding Javascriot, it uses Rhino, an open-source implementation of JavaScript written entirely in Java that does pretty well in parsing JSON.

These two channels don’t really do much processing (only print to the console the given name) so we can see the impact of switching from ER7 to JSON when using Mirth Connect. But the really important test is when we change from MLLP to HTTP and Mirth Connect can use both.

REST Webservice on Mirth Connect

For this test, we’ve sent the same JSON message as a POST using the Postman REST client application for Chrome. The same timings as above but now with HTTP. For the ER7 message, a MLLP server was configured to measure the impact of a TCP server.

                  |   ER7   |   JSON   |
Preprocessor log  |  0.000s |   0.000s |
Given Name Output |  0.006s |   0.003s |
Postprocessor log |  0.038s |   0.076s |
Total             |  0.044s |   0.079s |

As expected, the use of a REST web service, using the Jetty embedded web server used on Mirth Connect couldn’t be as fast as a simple TCP server like the one used on a MLLP listener. Nevertheless, the benefits of using HTTP instead of pure TCP sockets might be sufficient to forget this performance penalty in many scenarios, like refered on my previous post.

As a conclusion and with simple tests and data, the performance impact of using JSON instead of ER7 doesn’t seem important. A stress test, with concurrency, is necessary to verify if it can handle a real life scenario.

By Alexandre Santos

HL7v2 in JSON – HTTP

Introduction

It’s been some 3 years now since i first saw HL7 v2 messages. At first I couldn’t understand it, then when I understood what it was I hated it – but then when I started using it on a daily basis I realized how powerful they were and why they are still here after two decades and will be here for sure for another two, at least.

Now I find the use of H7 v2 messages the most efficient way to implement interoperability between health information systems. Despite this, I consider that there is room for improvement. Two examples:

• Better legibility: experienced users look at a HL7v2 message in ER7 format and can immediately translate what is there. They all know what the PID segment is about and where the patient’s family name is… yes, PID.5.1
• Network protocols: Minimal Lower Layer Protocol (MLLP), is the absolute standard for transmitting HL7 messages via TCP/IP. It’s very efficient, light and perfect for ER7 messages. Nevertheless, no security layer present, for instance.

To address those two examples mentioned there are some workarounds already implemented on the standard itself or by the people that implements HL7 on the field. Two of those workarounds are the use of XML and the use of secure tunnels. The first splits the message, surrounding each field with XML tags, like:

RXR|OTH^Other/Miscellaneous

becomes

<RXR>
    <RXR.1>
        <RXR.1.1>OTH</RXR.1.1>
        <RXR.1.2>Other/Miscellaneous</RXR.1.2>
    </RXR.1>
 </RXR>

The other uses third-party tools like stunnel (http://stunnel.org) to create a secure channel between two systems.

Using JSON for HL7v2

One of the most obvious reasons for people getting frightened with HL7v2 is it’s ER7 format. The first time someone sees a HL7 message it’s like looking for one of Tank’s monitors on the film Matrix (it’s what my colleagues tell me). The only codes that appears are the segments codes (MSH, PID, etc) which are useless for someone that doesn’t know the standard and the fields are separated by pipes, ampersands, etc… For instance, is it possible to tell what this segment means and which information is there (this is a simple one…)?

PV1||CON|8152879||||||||||||||||16164813

Even using XML, the information that one can get is as usefull as with ER7. So, the alternative I present here is the use of JSON but not just a translation from the XML but a new approach: using meaningful terms and descriptions of the information on each segment.

"patientVisit": {
    "patientClass": "CON",
    "assignedPatientLocation": {
        "pointOfCare": "8152879"
    },
    "visitNumber": {
        "idNumber": 16164813
    }
 }

As one can see, even someone that never read a HL7v2 manual can figure out that we are sending here information regarding a patient visit, with it’s class, location with a point of care ode and a visit number id. The description of each entry follows the description of each segment and fields on the HL7v2 standard.

REST Webservices

The use of JSON as the representation of each message makes obvious that the way to exchange this information is now HTTP and not MLLP, using REST webservices. Now, several of those weaknesses present on MLLP have disappeared:

• Security: possibility to use authentication on the HTTP layer
• Security: secure channels with HTTPS
• Parsing: JSON is a lightweight form of sending information and is native Javascript. Much faster than XML and can be consumed by any browser

NoSQL Databases

The use o JSON as the way to represent a HL7v2 message has another great advantage: it’s possible to store it immediately on a noSQL Document based Database like MongoDB without any need to parse and normalize data.

Alexandre Santos