Sunday, July 31, 2016

Why is Pokemon Go! so Freakin' Cosmopolitan?

While appreciate the way that games like Ingress and Pokemon Go! encourage people to get out of their homes, away from their game consoles, into the streets... I also find it profoundly disturbing how cosmopolitan this phenomenon is. Of course, I understand - Pokemon Go is based on Ingress, which relies on this concept of XM which is based on population density and high foot traffic areas, so while Google Maps provides a uniform service to all parts of the globe, based on satellite orbit patterns, games based on the Google Maps API provide much better service in cities. Period. You want to catch them all? Go to Santa Monica. I love these games, but I find them disturbing for two reasons:

  1. It goes against canon. The Pokemon storyline goes something like this: Pokemon Trainer Ash explores the continent, making friends and having adventures, learning to triumph over various gym leaders; he succeeds in finding the rarest pokemons in the most obscure places. In the augmented reality game, you need to breed to succeed, and battling gyms is a secondary concern. To get the rarest pokemons, you need to incubate and hatch 10 km eggs, and go to the densest nests. These are high traffic areas. Like Ingress, I'm sure there will be events that will provide access to extremely rare pokemons, and I am entirely sure these will happen in dense, high population, high technology areas.
  2. This is not how ubiquitous access works, at least not for everyone. Imagine you discover you have an odd rash - perhaps you suspect you have Lyme disease, and you have done some preliminary investigation on various public health websites. This is a huge concern. Treatment for Lyme disease should happen ASAP. If you live in a cosmopolitan area, your first concern may be finding a clinic or emergency department that has short wait lines; whereas, if you are in the country, telehealth may be a better option. You may email a doctor a photo of the rash. If you are in an LMIC country or remote region, you may not have easy access to healthcare. Ubiquitous access and a mobile phone may be your only way to get an effective, fast diagnosis and treatment. 
I live in a large cosmopolitan area, surrounded by water, and still, I only have to travel 10 kilometers out of range for the poke-details to dry up. That doesn't seem right. While I understand that this is an augmented reality, it also strikes me that this is a highly one-sided and cosmopolitan view of my reality. This is another Music for Airports, a distraction which encourages city-dwellers to develop good exercise habits and occupy their own event horizons; easy to enjoy, easy to tune out; profound with breadth but not with depth. I suspect that this will, however, result in longer battery life, cheaper secondary batteries. This will drive the industry forward.

Thursday, December 31, 2015

Health and Human Services HL7 FHIR Code-a-thon

This upcoming code-a-thon was news to me, and in a way it’s quite exciting because of the context. HL7 International has run FHIR connectathons at each of its working group meetings since 2011, and these have brought a lot of maturity to the standard, and moved ownership of the draft standard away from the modelling community to the implementer community where it really belongs; Project Argonaut has brought more urgency, using Meaningful Use as a vehicle, and people like Dr. John Halamka and Josh Mandel have been very vocal about its importance.

But this is HHS, which has put a lot of support behind the NIEM Health Domain. To be fair, there could be massive crossover potential between NIEM and HL7, since both are more or less resource-based, using what NIEM calls Exchange Packages, and FHIR calls Bundles. In the long view, it’s not much of a stretch for a health information package (message or document) to contain information formatted as both kinds of resources, bundled as JSON, backed by XSD or CAM.

For anyone interested in Integrated Case Management and crossover potential between Justice and Health, this is definitely exciting. What's probably most important here, though, is the message about SMART on FHIR apps operating with an Argonaut API. This is complete blue sky at this point, but when you look at the number of EHR vendors involved with Argonaut (MEDITECH, Cerner, McKesson, and Epic, to name a few), this could become a reality very quickly.

Friday, June 05, 2015

My jsFiddle Bag of Tricks

I'm just going to say it, I love Like others pastebins such as Gist or, jsFiddle allows you to rapidly prototype HTML/JavaScript/CSS and test the result in real time. There is extensive library support, and you can do tricky things like embed your results as an iframe on a GitHub page, or use GitHub to back up a demo. But the basics of jsFiddle are that you can create a small to medium application, share it easily so others can fork it, and tweak it to your heart's content, with easy to use restful routing and version control. What's not to love?

In order to make the most of jsFiddle, however, I had to sort out a few things. Please feel free to share your own bag of tricks, and here are some of mine.
  1. Use the Ionic bundle as an External Resource. You can select AngularJS 1.2 from Frameworks and Extensions, but if you add the following links to External Resource, you will get a bundle containing both AngularJS and the Ionic Framework, which allows you to do some clean mobile UI.

    You may strip out the Ionic stuff before you release your work, but I have found it to be a great framework for rapid prototyping with a Mobile First mindset. Cards are great. Also, ngCordova is an extension for Ionic which allows you to embed your work into iOS or Android using PhoneGap.
    Ionic may not be perfect (it's still in beta), but it is very Mobile First, useful for rapid development, and has a lot of similarities with Bootstrap. Try it out.
  2. Embedded results pages are great, but they often fail to load until you change "https" to "http". Same goes for the External Resources. Get used to quietly deleting the "s" during demos, and hoping that nobody notices.
    GitHub and jsFiddle can work very well together. I suspect you could get similar results with Gist or Codepen, but I personally prefer jsFiddle. Learn to use social repositories to create individual code samples and project pages.
  3. JSONP can work, this is very handy. I often set up JSONP files, JSON wrapped in a function call, on a GH Page on GitHub, so that I can access them later as though they were an actual API. In order to do so, rather than echoing the call from the jsFiddle itself, I have a useful Angular directive I use:

    rhizomeBase.factory('jsonpService', function ($http) {
        var svc = {}, jsonp_data   
        jsonp = function(data) {
            jsonp_data = data
        svc.getData = function(callback, url) {
                method: "JSONP",
                params: {
                    input: "GM",
                    callback: "jsonp"
                url: url,
                isArray: true
            }).success(function(data, status) {
            }).error(function(data, status) {
        return svc

    All this service does is set up an http: request as a promise, and then apply a callback whether the request succeeds or fails. It turns out that when the request succeeds, jsFiddle treats this as a failure, but all of this gets hidden in the service. In practice, once you have an Angular application set up in jsFiddle, you can call inject the service into your controller or directive and invoke it with a very direct call like this:
    jsonpService.getData(function(data) {
    }, url)
    One of the things a pastebin allows you to do is prototype a client application without having to worry about building a server-side API first. Hosting a handful of sample messages on GitHub is a good way to accomplish this.
  4. Use appropriate standards. This is really the flip side of  building a client-side application first. If you have access to a JSON-based standard like NIEM, or you can use a snippet gleaned from, this will save you some design time and get you moving in a forward trajectory. In my case, the JSON flavour of HL7 FHIR, the component-based nature of Angular, and the ease of use and built in UX touches of Ionic are a perfect storm for the kind of work I like to do, and jsFiddle is the glue that holds these together.
    If you can, learn and use appropriate standards.

Sunday, January 04, 2015

Using AngularJS with HL7 FHIR Questionnaire

This  is a very simple example using Angular templating (no directives) with an HL7 FHIR Questionnaire resource, which I am using directly from one of the public FHIR servers (Grahame's to be precise). In addition to the machine-readable content for question groups and answers, I am creating a rudimentary service to manage coded concepts (ie value sets), and I am displaying the human-readable portion of the resource (the HTML text div) as well. This is really just a beginning, and one thing I would like to build into this demonstration is the ability to use embedded SVG for the human-readable portion, as it seems to me that existing PDF questionnaires could be converted to SVG and thus embedded. Makes for a large resource file, but this would be a great way to retain the look and feel of existing documents, once an easing library is used to zoom in on the appropriate area of the SVG. I'm calling this demonstration "QuestionCare" because I think it would also be useful to be able to use Careplan within this context.

We begin with a root HTML that sets up my Single Page Application, and a reference to my Rhizome library, which contains a number of useful client-side services:
<body id="content" style="display: none;" ng-app="questioncare">
      <h3 ng-controller="ErrorController" ng-bind="errorText" ng-show="showError"></h3>
      <div id="request" ng-controller="RequestController">
        <button id="view-questionnaire" ng-click= "viewQuestionnaire()">View Questionnaire</button>
      <ng-include src="res/templates/Questionnaire.html"> </ng-include>

This corresponds to a single line in the javascript initialization:
var questioncare = angular.module('questioncare', ['rhizome', 'ngSanitize']);
 We'll see how the ngSanitize module is required in order to handle rendering the human-readable HTML div from the Questionnaire resource as HTML, instead of text, using ng-bind-html. In any case, we are setting up a controller to handle a request, and then we are including a template to handle the response. The rest, as we shall see is handled through controller code and client-side services, but let's take a quick look at the included template for Questionnaire:
<div id="questionnaireResponse" ng-controller="QuestionnaireController" ng-show="showQuestionnaire">
  <div ng-bind-html="humanReadable"></div>     <hr/>
  <div ng-bind=""></div>
  <div ng-bind="group.header"></div>
  <ol id="questions">
    <li ng-repeat="question in group.question">
      <div ng-bind="question.text"></div>
      <ol id="options">
        <li ng-repeat="option in getOptions(question.options.reference)">                    [<span ng-bind="option.code"></span>]:
      <span ng-bind="option.display"></span>
 That takes care of the HTML. The request controller invokes an adapter (this is running on IBM Worklight), and then sends the response to the questionnaire controller using $rootScope.broadcast, but first it calls a client-side service which I have made responsible for managing codes; in this case, the value sets for the different options you can pick when you answer the questionnaire.
questioncare.controller( 'RequestController',
  function($scope, $http, $rootScope, errorService, codeService) {

    $scope.viewQuestionnaire = function() {
      var invocationData = {
        adapter: 'FHIR',
        procedure: 'getQuestionnaire',
        parameters: []
      WL.Client.invokeProcedure(invocationData, {
        onSuccess : function(result) {
          if (200 == result.status) {
            var ir = result.invocationResult;
            if (true == ir.isSuccessful) {
              $scope.$apply(function () {
                var questRes = ir.content;
      codeService.loadCodedConcepts(questRes.contained);          $rootScope.$broadcast('qr', questRes);
            } else {
      errorService.worklightError('Bad Request');
          } else {
      errorService.worklightError('Http Failure ' + result.status);
      onFailure : errorService.worklightError
The codeService itself is quite simple, although, since value sets could potentially come from a variety of places, this service could become a lot more complicated. In this case, I am just scraping contained value sets from the Questionnaire resource itself:
rhizome.factory('codeService', function($rootScope, errorService) {
  var codeService = {};
  codeService.codedConcept = Object;
  codeService.loadCodedConcepts = function(contained) {
    for (c in contained) {
      codeService.codedConcept[contained[c].id] = contained[c].define.concept;
  codeService.getCodedConcept = function(opt, remHash) {
    if (remHash) {
      opt = opt.substr(1);
  return codeService;
Angular services can be difficult to grasp at first, but they are one of the more important features of the framework, since they allow you to make your client-side more portable and standardized; however, this particular service is little more than a stub at this point. It deals with a hash sign which is probably included with the value set id, which is useful. Once the coded concepts have been scraped out of the Questionnaire, the document is displayed using the included template and a response controller.
questioncare.controller( 'QuestionnaireController',
  function($scope, errorService, codeService) {
    $scope.showQuestionnaire = false;
    $scope.$on('qr', function (event, arg) {
      $scope.questionnaire = arg;
      $ = $;
      $scope.humanReadable = $scope.questionnaire.text.div;
      $scope.showQuestionnaire = true;
    $scope.getOptions = function(opt) {
      return codeService.getCodedConcept(opt, true);

Again, there is nothing too complicated here. Notice how the humanReadable questionnaire text div gets bound into an element that allows HTML to be rendered. Also, a second function is used to get and then display the options because these need to be repeated, as you can see in the Questionnaire.html. In addition, the entire questionnaire template is hidden until it is populated.

Next steps here will be to work with nested questionnaires, where selected options will traverse through a hierarchy of question groups. At this point, it may be useful to use Angular custom directives, although I am also trying to be careful about anything that will be subject to change with Angular 2.0, such as controllers.

More and more as I work with Angular, Worklight and HL7 FHIR, it strikes me that what is important here is building a library of standard services and templates on the client side, and then simply binding into it. Once DSTU2 is complete for FHIR it will become less of a moving target, but resources like Questionnaire, which has been the subject of several connect-a-thons now, seem especially stable.

Tuesday, December 30, 2014

MatchstickTV and FirefoxOS

Earlier this year, I spent some time developing for FirefoxOS, a Mobile OS based on a linux kernel and Mozilla browser. To be honest, I have a Revolution phone from Geeksphone which flashes between Android and FirefoxOS, and it has been Android since day one. It work well for what it needs to do as an Android device. However, the idea of an instant developer community for FirefoxOS is compelling - it just hasn't appeared yet because the OS hasn't become a large enough target yet. And, like ChromeOS before it, this may never happen.

MatchstickTV is a recent kickstarter project that takes FirefoxOS and uses it to run an HDMI dongle very similar to Chromecast, but based on open source apps on an open source development platform and an open source OS. It's a little cheaper as well, but I suspect that is not an important selling feature. On the other hand... because there is nothing in particular to license here, this sort of thing could become a great conference giveaway over time, just like USB sticks used to be.

Honestly, I think a tablet using FirefoxOS with a bunch of onboard educational applications - similar to the original OLPC program, perhaps - would be a really good thing. There is a niche for browser-based mobile, and Mozilla is doing a lot of smart, good things to capture it.

Monday, December 29, 2014

Atomized Integration, IBM Worklight and AngularJS

Over the past year, I have worked fairly extensively with IBM Worklight, Big Blue's enterprise mobility package. In the coming year, I plan to find more things to do with Bluemix, IBM's cloud mashup line; for now, some thoughts.

In general, my guidance has been to use open source mobility frameworks, PhoneGap for cross-platform, Bootstrap for Responsive Web Design, Angular for templating, and some form of OAuth2 for security, at least until the vendor solutions from IBM, Oracle, et al reach a higher level of maturity, since these are stepping stones.

If you look at the latest Gartner quadrants for enterprise mobility and cloud for the previous year, you will see IBM maturing in the MADP space and Oracle maturing in the cloud space... but maturity in both areas is necessary for enterprise mobility to fire on all pistons.

Worklight does three things really well:
  1. Simple adaptation on the server-side, using Rhino-based Javascript adapters.
  2. Integrating with existing Websphere and SAM infrastructure.
  3. Increasing productivity through modularization and emulation.
Probably the biggest win here is 3. I started out 2014 working with Firefox OS, Saxon-CE and AngularJS, so I was already committed to using Javascript and XSL as much as possible, and Worklight Adapters played into this approach nicely; however, after *hating* the slowness of native Android development using the Android toolkit, what I appreciated most about Worklight was being able to use an emulator that ran as smoothly as the Firefox OS simulator (which is really just a browser plugin). On the server-side, we are becoming more accustomed to devOps tools like JRebel; on the client-side, we should have similar expectations - is, don't use the Android emulator if you can avoid it. It sucks.

I have mentioned previously how much I like Worklight's lightweight Rhino-based adapters. They are intentionally lightweight, eschewing any sort of SOA reusability. A Worklight adapter does one thing, and it does it well. This can be initially quite pleasant, then very frustrating, and then liberating, as you sort out how much integration you need to do in your client applications. My experience has been that a well designed piece of XSL can convert an XML data source into some standards-compliant JSON, and then a client-side library service can take it from there.

For instance, consider that I have an XML data source containing a number of patient records. Let's say it is NIEM compliant XML. I could build a client application that can consume NIEM compliant JSON, and then all I would need to do in Worklight is create a very simple boilerplate adapter that transforms the XML into JSON. This is assuming that my server-side data source doesn't already support JSON-flavoured NIEM, which would be even simpler. In other words, if my intent is to take a NIEM compliant data source and build a NIEM compliant mobile application, this is quite straightforward. Server-side Worklight adaptation transforms XML into JSON; client-side Angular data-binding injects JSON into the HTML-based presentation layer, and presto, you have an application.

Granted, the development process is not that easy, and let's consider now that we have a number of data sources, some of which are NIEM compliant, some of which are HL7 compliant, some of which are based on direct SQL access, and some of which are ad hoc.

When you look at the various Worklight adaptation examples, you might get the idea that RSS is treated preferentially, which is untrue; however, thinking of these adapters as syndication is still a useful approach.

Throughout the past year, I have been working with HL7 FHIR, a draft standard from HL7 that among other things introduces a JSON-based pattern for aggregation and composition that is essentially Atom syndication in JSON instead of XML. It turns out that if all of my Worklight adapters create Atom-compliant JSON on the server-side, then I can use a Javascript Atom library in the client, and it really doesn't matter what format my data sources are using. By the time they reach my client application, they are all Atom-based.

The client-side service that I have written - using Angular for modularization - is responsible for merging multiple Atom streams. Once I have a single Atom stream, data-binding takes place, so that information can be presented. In practice, this can be frustrating because Atom is intended for serialization of information, but an Atom bundle can also contain relative links between entries. This is fundamental to the way HL7 FHIR works, but not NIEM, so I have ended up creating synthetic and essentially schemaless resources as necessary. Ideally, all information could be mapped into Atom-syndicated FHIR resources. Maybe that's a good project for this year.

Adaptation frameworks always run into a problem based around the decision to go lightweight or go modular. I like that Worklight has gone lightweight, but I am frustrated that I can't reuse just a little bit more code between adapters. In particular, I would really like to use a single set of XSL transforms to support multiple adapters. Perhaps there is a way to do this, but for now, I am still forcing myself to prune my adaptation code as much as possible to keep it easy to maintain. If I find myself using the full set of DocBook or DITA transforms in an adapter, it's probably time to rethink my approach.

On the whole, I have enjoyed working with Worklight adapters immensely; I don't think this would be the case if I was not also using Angular or some other Javascript framework to support development of client-side services. I haven't particularly used the built-in Worklight support for Dojo or JQuery, but I'd go so far as to say that without some sort of hybrid framework support, you will lose much of the productivity that Worklight gives you. After a year, I have reached an understanding that I would not enjoy using a framework like Angular without a platform like Worklight, and I would not enjoy using a platform like Worklight without a framework like Angular.

Unless, of course, the platform was also a framework, which is what approaches like Meteor promise. 


Saturday, December 27, 2014

Some Canadian Context for HL7 FHIR

I work in Healthcare Messaging in Canada; specifically, I work in messaging in British Columbia, where we work primarily with Point of Service applications and Clinical Information Systems that generate and consume messages in the HL7 v2 pipe and caret notation, with a foundation of registries and repositories that use a version of HL7 v3 Messaging XML. More or less, this follows Canada Health Infoway's iEHR blueprint; however, following Infoway's original blueprint, we would have HL7 v3 at the Point of Service as well as the foundation.

HL7 v2 is still used extensively in other Canadian jurisdictions. Some use v2 almost exclusively. In Canada, we have a mix of v2, v3, with some CDA. The United States, on the other hand, never embraced v3, creating a desperate need for a better messaging layer. In this case, FHIR will accomplish things in the U.S. that v3 could not, and that leaves Canada in a challenging position - continuing on with further investment in HL7 v3 makes little sense. Like CDA before it, FHIR can be used to augment these projects; there are enough similarities between FHIR XML and v3 Messaging to make this plausible.

Ongoing CDA projects in Canada are bound to continue as such, which will be worth paying attention to as CDA projects in the States start shifting to HL7 FHIR as an implementation standard. The message from Infoway recently here is to use the appropriate standard for the work at hand, and I expect this message to percolate on both sides of the border; but what does this really imply? How do you decide? For new business cases which would previously have required a document standard like CDA, HL7 FHIR is going to be compelling, as well as low risk, local, and greenfield projects.

Worth noting is the four ways that FHIR can be used. As previously discussed, FHIR supports both Messaging and Document use cases; but, perhaps more importantly, FHIR also supports both REST and Service use cases. In addition, FHIR is in many ways custom built for the security and transport requirements of mobile use cases, and contains resource definitions that will enable social use cases like circle of care and information provenance. For existing health information systems and applications, as well as new, FHIR creates new ways to expose, access, and share information; providing not only tools, but also challenges.