Breaking bluebutton.js into single use modules

[robdodson]

What do you guys think about taking the current implementation of bluebutton.js and breaking it down into smaller modules that can be composed together? Right now it's tricky to test bluebutton.js and if you add something to it, then all developers must now accept that feature, even if it's something they don't want.

It seems like because medical records are so complex, and there are a number of different styles of XML (CCDA, C32, etc?), that it might make more sense to build a chain of modules instead of having one big library. Just looking at the current implementation I think xml.js could be its own module, codes.js could be its own module, the ccda/ dir could be one and the c32/ dir could be one.

I guess in my mind, an almost ideal scenario might look a little like how the Connect framework deals with http requests. In Connect a request comes in and then it's acted upon by "middleware". Typically middleware is an npm module that exports a single function that just does something to the request or response object. For instance, adding something to the session or gzipping an asset, etc. You can chain middleware together (that's the point) and do really powerful stuff out of simple pieces.

http request -> logger -> basicAuth -> gzip -> response sent

I'm wondering if you could do something similar when working with bluebutton. Even if it's not the exact same paradigm, I think breaking the library down into smaller pieces will make it easier to test and will encourage more people to submit pull requests because they'll be more comfortable working on a tiny piece of code instead of the entire library.

Thoughts?

@jmandel @blacktm @mjacksonw @thetylerhayes

[jmandel]

I agree that restructuring for

• customizability (vendor-specific plugins)
• testability
• developer approachability

is a win. Of course, having a default, "best practice," ready-to-go configuration becomes key...

[robdodson]

Perhaps bluebutton.js would become that ready-to-go thing but internally it would just be composed of all of these modules. That's kind of what Express is to Node.js and Connect.

[blacktm]

I think it's a great idea. Not exactly sure what the "middleware" flow would be yet. I now know of several companies experimenting with bb.js, but a major issue is that their stacks are all different (Ruby, Python, JS, etc.). So maybe we can attack both issues here by defining a first middleware component to transform an XML definition (in JSON) to a desired JSON representation. For example, a set of rules for CCDA allergies would look like: https://gist.github.com/blacktm/7608828#file-ccda_allergies-json

@robdodson You know way more than me about all the latest JS techniques and goings on, so feel free to lay out what a path forward might look like. This isn't really a healthcare problem here, but a "how to deal with nasty XML" problem.

[kachok]

I like this idea. Not sure how exactly "middleware" would work, though. Should it be something like blah(input_xml, output_json, next)? So each following "middleware" method can improve on produced output of JSON based on incoming XML(or whatever other format data may be in).

I would also suggest to follow (at least for CCDA) separation of parser into smaller pieces, e.g. Templates/Sections/Entries. (So there are independent pieces that can be replaces/called independently).

[robdodson]

@blacktm I like that JSON transformation :)

@kachok

Should it be something like blah(input_xml, output_json, next)? So each following "middleware" method can improve on produced output of JSON based on incoming XML(or whatever other format data may be in).

That's kind of what I'm thinking. Another thing to look at is Node's use of streams and pipe. John Resig built a cool stream playground to help people experiment with the concepts.

I don't know if middleware/streams are exactly the right direction, but breaking everything down into smaller, composable modules feels like it would add a lot of flexibility and make things easier to test.

[kachok]

I was thinking about it and so far has only limited idea for "middleware" nesting mostly for: detect format () parse some format dynamically () strip stuff we don't need for HTML visualization () (e.g. strip all the codes to make JSON light, to push to browser)

most modularity will come in parser though, I think there we can detect sections (allregies/meds/visits, etc) dynamically one by one and stream them through dedicated/modular parsers e.g. allergies_parser(). This way it will be easier to configure and maintain custom modular parsers for everyone (in case some people don't want to use master to avoid breakage)

[jmandel]

I'm not sure stream-based processing is the right paradigm here, given that we basically need an in-memory DOM to make any sense of the C-CDA. (But maybe you have something else in mind when you bring up streams?)

In any case though, making the parsers more modular and more declarative is a great plan.

I think Tom's example is very clear. For my (now bit-rotting) alternate declarative approach, see these descriptors.

[robdodson]

@jmandel yeah I agree. streams and middleware are probably not the right concepts. I just want to get to that space where everything is small and composable and easy to test.

[blacktm]

+1 to small and composable plus cross-language declarative approach. More broadly, I think what we really need is an SDK for healthcare. A lot of these ideas transcend BB.js.

[kachok]

So i'm looking into this and puzzled how to implement modularity (e.g. node.js modules) but keep bb.js workable in browser? What is community opinion on Node.js vs browser usage for bb.js? Also can we submit bb.js into NPM registry? (just to make it easier on Node.js side)

[jmandel]

Have you looked at doing this with http://browserify.org/ ? I've used it for a similar project in the past and been pretty happy.

On Wed, Dec 11, 2013 at 4:26 PM, Dmitry Kachaev notifications@github.comwrote:

So i'm looking into this and puzzled how to implement modularity (e.g. node.js modules) but keep bb.js workable in browser? What is community opinion on Node.js vs browser usage for bb.js? Also can we submit bb.js into NPM registry? (just to make it easier on Node.js side)

— Reply to this email directly or view it on GitHubhttps://github.com/blue-button/bluebutton.js/issues/79#issuecomment-30378943 .

[robdodson]

The way we're currently doing this is by wrapping everything in a UMD. It's not the perfect solution but it does satisfy browsers, RequireJS/AMD and Node/CommonJS. We could do the same for new modules that we write. Or as Josh points out, we could use browserify.

[kachok]

I did, it adds complexity vs simple Githubissues.

Githubissues is a development platform for aggregating issues.