Thanks to That Person

In my first computer class, we entered our programs using a line editor, and unless we were unlucky, had a CRT to work with (although the unlucky still go stuck with the linotype).  We had a text book, some well thumbed compiler manuals on a bookshelf that were shared among the many students, and there was always, somewhere, that guy (or less often but still present, that girl), who soaked it up and knew the answers to the real tricky stuff.

As I moved into the workplace, we had CRTs still, but some had graphics capabilities, there were still tons of manuals on our shelves (and for most of us, we each had our own copy).  If you were one of the lucky ones, you got graphics.  The manuals were less well thumbed, and somewhere in the office, there was that guy (or more frequently, that gal) who knew how to find the answers.

Later, we all got to move up to 16, then 256, then 16384 colors, with 640 x 480 resolution, and then 800 x 600, and if you were one of the lucky ones, 1024 x 800 displays.  Email came to the fore. Manuals were still handy, yet there was still that person.  Sometimes they'd be in another office. You'd pick up the phone, or send them an email.  After two or three forwards and days, or more depending upon the challenge, the e-mail would come back with the answer.  And because that person had email, if they didn't know the answer, they at least knew who did.

And then came the Internet, and CD drives.  Instead of a shelf of books and a file drawer full of disks you saved because you just might need them again, there was the almighty CD.  And books were fewer.  And if you were one of the lucky ones, you had INTERNET!  And that guy or gal might be a half-continent away, and e-mail was reliable and you'd only need to way a few hours.  And he or she probably had Internet, at least at home, because they still sucked it all in, and knew where to find the answer, on the Internet, or on the CD.  Of course, you still had a drawer full of CDs, but at least it was a normal one instead of a file drawer.

Now we have StackTrace, and web sites, and volumes of data.  You can ask Google or Bing. Training is online, complete with slides and audio. that person has a blog, and a twitter account or a linked in, or all three. You no longer need to be lucky to have a laptop, though if you have a touch screen or tablet, you can probably to count yourself among the lucky.  You can read what that person has to say daily, or even listen to them or better yet watch them. That person now has fans.

I'm a fan of lot of people out there.  You know who you are.  I couldn't this person without you being that person.  Thanks.

-- Keith

Handling Extra OAuth2 Authentication Parameters

I'm deep into spec'ing out an OAuth 2 implementation, which means that I have to give all the detailed rules about what to do with parameters sent to the authorization endpoint of an OAuth2 server.  The question arose, what do we do with parameters that aren't recognized.  Fortunately, OAuth2 clearly resolves this issue for us (and for you):

In the section describing the OAuth2 Authorization endpoint, what OAuth2 says is

"The authorization server MUST ignore unrecognized request parameters."

There's a very good reason for this.  It allows profilers of OAuth2 to add parameters with additional specified behaviors.  You won't find the SMART on FHIR "launch" parameter anywhere in the OAuth2 spec. For those endpoints that do recognize it, they can do something useful with it.

The same thing works for unrecognized scopes.  If you don't recognize it, it isn't an error, just ignore it and it should go away (the application that sent it should be expected to behave correctly when it is ignored).

Postel's law rules.

Thinking about Client Application Configuration for OAuth2 Authorization Grant Flow

In trying to understand how to implement the OAuth2 protocol, it helps to consider what both parties have to do.  It's kind of like playing chess, after you reach a certain level, you have to consider the plans for both black and white.

If you are implementing a client, you can probably get away with just worrying about your opening, but as a server, you have to think about how clients are architected.

In the Authorization Grant flow (the subset of OAuth2 supported by SMART on FHIR), the client has three different components that need to work with the server's two endpoints.

1. The "login" component of the client provides the user's experience for interacting with the server, supporting the servers ability to request login credentials, authorization and in SMART on FHIR, patient selection UI.  
2. The application service component is responsible for taking the authorization grant (or auth code) and converting in into an access token for the remainder of the work it needs to perform.
3. Finally, the redirect URL endpoint is the piece in the middle that acts as the glue between the user interface at the front-end, and the service component under the covers.

Thinking about these three client components as three separate but coordinating components, with different sets of capabilities makes is much clearer how OAuth2 is supposed to work, or at least did for me today.

I suppose if you've actually implemented an OAuth2 client first this would be obvious.  Duh.  I'm not always smart the first time.

When do you need to create an IHE XDS formatCode

In the cross enterprise document sharing family of IHE profiles, one of the metadata attributes associated with a document is formatCode.  When XDS was created, we felt we needed a way to distinguish between content based on the set of business rules it adhered to.  This is more than just mime-type or schema.  It's closely related to CDA's templateId element or FHIR's profile tag.

As part of an affinity domains configuration, the governors of that domain can specify what formatCode values should be used for submitted documents, and when.

Recently a representative of a national program asked me:  Should we create our own format codes or use IHE format codes, noting that his national program had added rules to IHE profiles for which IHE had already created formatCodes.

The answer to that question is "Yes", or more accurately, "it depends."

Within your affinity domain (for which you set the policies), will you have cases where distinguishing between documents using IHE format codes and your own additional requirements is necessary?  If so, create your own format codes for these documents.  Otherwise, simply add the requirement to your domain policy that all documents must meet national requirements as well as adhere to IHE templates, and stick with the IHE formatCodes (as it is both simpler, and will require less effort on behalf of developers who already know how to use those).

Creating your own format codes, even when others already exist is perfectly legitimate.  Format codes are a way to express a concept that is needed to manage an affinity domain.  If what is there doesn't let you manage the domain, then there's nothing that says you cannot apply your own set. However, if you are smart, you will do your best to stick with what already exists when you can, and ONLY when it doesn't let you do what you need, will you do something different.

   Keith