Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Friday, June 23, 2017

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











Tuesday, June 20, 2017

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.

Wednesday, June 14, 2017

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.

Friday, June 9, 2017

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

Thursday, May 11, 2017

L or l? The Ucum Liter code

Filed under stupid stuff I know.

The code for Liter in UCUM Case Sensitive is both l and L.  You can use either.

See http://unitsofmeasure.org/ucum.html#section-Derived-Unit-Atoms for details.  Basically what they say:
In the case sensitive variant the liter is defined both with an upper case ‘L” and a lower case ‘l’. NIST [63 FR 40338] declares the upper case ‘L’ as the prefered symbol for the U.S., while in many other countries the lower case ‘l’ is used. In fact the lower case ‘l’ was in effect since 1879. A hundred years later in 1979 the 16th CGPM decided to adopt the upper case ‘L’ as a second symbol for the liter. In the case insensitive variant there is only one symbol defined since there is no difference between upper case ‘L’ and lower case ‘l’.
So much for using codes to define distinct meanings for atoms of this vocabulary.  Ah well.  At least they defined L in terms of l.

   Keith 

Friday, April 28, 2017

From $450 to 450¢

From $450 to 450¢ is a 99% savings.  That's what I recently found in reviewing my medication costs.

I recently compared prices on a medication a family member is using.  It comes in several dose forms, and strengths.  To keep the math the same, I'll call the strengths 1,2,3,4,6 and 9.  They can be taken in capsule or tablet form (but not in all strengths), or in oral (pediatric) form.  Not all combinations are available from our PBM, but most are.

Here are the approximate prices and sigs for a 90 day supply:

Strength 1 Capsule 6xDay: $13.50
Strength 2 Capsule 3xDay: $4.50
Strength 4 Capsule + Strength 2 Capsule: $17.50
Strength 1 Tablet 6xDay: $561.00
Strength 2 Tablet 3xDay: $422.00
Strength 6 Tablet 1xDay: $445.00

To be very blunt about this: What the FUCK!?

So now I've gone through EVERY prescription in the household, and so far this is the only one that is that whacked out. But like I said, WTF?

   -- Keith







Wednesday, April 26, 2017

Refactoring Standards

Code and standards (which are a special kind of code) grow with age.  When you started with your code, you had a plan.  It was fairly simple and so you wrote something simple, and it worked.  After a while you realized you could make it do something special by tweaking a little piece of it. Sometimes (if you designed it right), you can add significant functionality.  After a while, you have this thing that has grown to be quite complex.  Nobody would ever design it that way from the start (or maybe they would if they had infinite time and money), but it surely works.

The growth can be well-ordered, or it can have some benign little outgrowths, or they can even be tumorous.  Uncontrolled growth can be deadly, whether to a biological or a computer system.  You have to watch how things grow all the time.  After some time, the only solution may be a knife. Sometimes the guts of the patient will be majorly overhauled afterwards, even though fully functioning and alive.

When the normal adaptive processes work in standards, these growths naturally get pruned back.
It's interesting to watch some of the weird outgrowths of CCR become more and more vestigial over time through various prunings in CCD and CCDA.  FHIR on the other hand, well, that started as a major restructuring of V3 and CDA, and is very much on the growing side.

   -- Keith