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.

Thursday, October 6, 2016

Preadopting FHIR Release Content

There are many times when you aren't quite ready to adopt a new release, either because it isn't fully baked yet (as for FHIR STU3), or you just aren't ready to suck up a whole release in a development cycle to get the ONE feature you would really like to have.

The FHIR Extension mechanism is a way that you can add new stuff to an existing FHIR release. But how should you use it for problems like those described above?

I'm going to be playing with this in the near future because I have some STU2 stuff going on right now, but I really need some of the fixes to Coverage in STU3.  Right now, STU2 talks about subscriber*, but doesn't actually link the coverage to the member (the actual patient being treated)! STU3 fixes that, and I want to preadopt the fix.

So, how am I going to handle my extensions?  Well, first of all, for every field I add, what I want to do is to name it using the STU3 (Draft) URL (and later to the STU3 URL).  So my extension URL becomes something like, and bang, I have a referenceable URL that pretty clearly defines the extension.

What does FHIR say about that?

The url SHALL be a URL, not a URN (e.g. not an OID or a UUID), and it SHALL be the canonical URL of a StructureDefinition that defines the extension.

Apparently what I've done isn't quite right because it doesn't follow the FHIR rules (even though it follows the spirit) of FHIR requirements for extensions. Right? So, NOW what?  Somehow we need to give each extension a name.

Actually, let's see what happens when I plug StructureDefinition into this equation.  I now get:  Click the link to open where that goes in a new window.  Dang!  Pretty fricken close. StructureDefinition/Coverage produces a redirect that goes to fhir/coverage.html instead of fhir/2016Sep/coverage.html.  So close.

In fact, that's nearly close enough for me.  It seems that if we were to fix the redirect problem on the HL7 Server, this would do exactly what I need.  Note: It's NOT a structure definition that defines an extension, its a structure definition that defines a resource.  But really?  Do I have to point you to a structure definition that defines it AS an extension?  Or can I just do the nearly right thing and get away with it.

I may want to adopt a resource that doesn't even exist yet.  Say I want to use some clinical decision support, but I've invested a bit already in Argonaut stuff based on STU2.  How do I handle that? Fortunately, FHIR has the Basic resource, but I'm going to need to extend the heck out of it.  No problem, I just use the same technique, with gusto, and even better, I could put some automation behind it to populate my stuff.  And so could anyone else.

I wonder what Grahame will think about this?


P.S. *  Also broken as defined in STU2, and not yet fixed in STU3 because I am not a patient at my wife's OB/Gyn practice, nor am I a patient at my children's Pediatric practice, but they clearly have me on file as some sort of RelatedPerson.  There's already a tracker for this.

Tuesday, October 4, 2016

FHIR to EHR Data Mappings

I've looked at a lot of EHR database schema over my career.  One of the things that I've found about FHIR is that it captures the essential model of an EHR system (just about ANY EHR system).  There really shouldn't be any surprises here.  It's based on six years of work that led to CCD, C32 and CCDA as well as a lot of other good information sources.  You can also find a good bit of that model already present in in CIMI via some of Intermountain's detailed clinical modeling efforts from the past.  What FHIR does differently is expose the right grain size I think, from what prior efforts in HL7 have attempted.

As both Graham and John have pointed out, yesterday's diagramming work still leaves a lot to be desired.  However, I will continue on to see where it goes.  I think there's an important piece of information there we should all be looking at very carefully.  I was already quite pleased to see that the patient and physician show up right in the center of it all.  Clustering algorithms like those used in GraphViz tend to surface interesting relationships like that.

I'm wondering if there are some better clustering algorithms to play with that might help identify interesting groupings and see how we did with resource classification.  Clearly the grouping of Individuals nailed it in Identification (under Administration).  Something like these might be worth digging into.

   -- Keith

Monday, October 3, 2016

Towards a FHIR UML Resource Relationship Diagram

One of the things that I feel is missing from FHIR documentation is a UML-like diagram of the Resources and their relationships to each other.  With over 100 resources, this is rather challenging to produce.  Fortunately, due to the data driven nature of FHIR development, the production can be automated using layout tools like GraphViz (Grahame had a love-hate relationship with GraphViz during early FHIR development, which resulted in him using something else).

What I did was create an XSLT which produced a graphviz input file after processing all of the FHIR StructureDefinition inputs.  To create a single XML file, I cheated a bit, and simply ran:

c:\build\publish> for /r %f in (*.profile.xml) type %f >>all.fhir.xml

After that, I edited all.fhir.xml and stripped all the extra XML declarations, and wrapped it in an element named FHIR (in the FHIR namespace).  There are other ways to do that to automate that, but this was simple and easy.  Note: The output will include some things that may have been part of the FHIR Build, but not part of the specification (e.g., Account in STU2).  I dealt with that in a later step.

After that, I used a number of different layouts supported by GraphViz to see which worked.  Just using the basic options produces a drawing about 30" x 150".  That's not really easy to use.  The best layout I could find was sfdp, which produces a clustered layout based on edge weights, using a force dependent spring model.  The layout stilled looked dramatically ugly because the lines overlap the nodes, so I set the edges up to use orthogonal connectors.

That looked close enough to be useful, so the next thing I did was to color code the nodes based on the Resource categorization used on the Resources page.  Clinical resources took on a range of purple colors (by subcategory), identification resources were red, workflow became cyan, infrastructure blue, conformance various shades of gray, and finance was green.  The colors helped me to understand how things were clustering in the diagram, so that I could possibly hand tune it.

I plan on doing hand tuning with a graphics editing tool.  Right now I'm checking out GraphVizio, a Visio plugin that lets me import GraphViz drawings.  Running the compute on the graph through Visio is something that is worthy of a long coffee break (actually, the same is true for the various layout methods).  I'm hoping Visio gets out of my way long enough to make this a worthwhile exercise, otherwise, I may have to revert to some other drawing tools.  I still don't like all the stuff Visio added for connecting stuff.  As soon as I move something a bit, it auto-reroutes stuff I've carefully positioned, screwing things up again.  I haven't played around with it long enough to figure out how to turn that off.

While I'm messing around with the diagram, I thought I'd show my initial progress:

As you can see, there's still a ways to go.  The diagram is still way too big, and you cannot even zoom it large enough to read.  What is interesting is that in fact, the FHIR Resources do tend to cluster, and Patient, Practitioner, and RelatedPerson find themselves at the center of care, just like you might expect.

Friday, September 30, 2016

A long journey ends...

OK.  So I've been at this Master's degree thing for the majority of the time I've been with my current employer.  It took me three+ years to find the program that would take me (the Online MBI Program at Oregon Health & Science University), and almost three more, but I'm FINALLY FINISHED!  And the funny thing was, that I finished in the first place I first looked some six or more years ago.

Wow.  What a journey.  I think my favorite three classes are in order:

  1. Human Computer Interaction (the most recently completed)
  2. The Practice of Healthcare (the one I thought for sure was going to kill me)
  3. Introduction to Informatics (one that had me on the floor laughing in the first week)
But quite frankly, I enjoyed every single one, and aced them all (save one, in which I only got an A, and it wasn't in any of the ones above). I'm about 2/100ths of a point from perfect, which quite honestly does NOT reflect my own perception of my ability at all.

I think the biggest thing that I learned over the last three years was the dramatic gulf that still existing between the "practical", technical, software engineering disciplines, and the academic, but also highly intuitive medical disciplines.  The latter are both more and less science than the former, or perhaps I have that reversed.  At the population level, the math and science in healthcare is all there.  Across the software engineering disciplines, not so much.  In the aggregate, software is still high art.  And yet at finer grains, healthcare is so much more art than the day-to-day of writing code and implementing algorithms, which is almost all logic (math).

One of the things that I have very clearly decided is that I will focus much more attention on teaching in the future.  I've always loved teaching.  The most enriching experiences I had was being a TA for the Standards and Interoperability class.  In most of the teaching I do, I see students for a day or two. I never really get to know them or see them grow over the course of a term.  Even though my time teaching was very short, working with others over a period of seven weeks, the last of which covered almost a week together in the same space, was truly different.  I got to see people learn and grow and even change the way that they think in ways I would not have expected, and yet pleasing none-the-less.

Again, I have to profusely thank my advisor, Dr. William Hersh.  Without his support I would never have entered the program, let alone finished it.  I have to say he made it interesting for me in many ways I didn't expect, one of which I hope you'll be seeing in a journal sometime in the next year.

Today, I sign off differently, tomorrow I'll be back to the same-old, same-old.  

   Keith W. Boone, MBI

P.S.  In a couple of weeks I'll be able to share the content of my capstone report with you.  Hopefully I'll be able to put all that writing energy that's been going elsewhere for the last three years back into this blog.

Friday, September 16, 2016

Other People's Stuff

Everyone likes to use their own toothbrush.  We know where it has been, and it fits our hand perfectly.  Someone else's toothbrush is just, well, ick!

The problem with standards is that they often have that "other person's toothbrush" feel to them.  It's not the way I'd do it, or I don't understand why they did X when clearly Y is so much better.  It takes a while sometimes to overcome that icky sensation of putting that thing in our mouth.

Eventually, if we keep at it, it becomes ours, to the point that we might actually find ourself facing the very same challenge trying to convince others to use what has now become "our standard."

It is certainly a true statement that trying to learn something new, or use something different that we are accustomed to is hard.  "I don't have time for this, why can't I just do what I've been doing?" I hear.  In fact, you might actually not have time.  But you may also be missing an opportunity to learn from what others have done.  Only you can decide which is more important.

Standards is all about using other people's stuff.  Few people are in a position to craft standards, many more are in a position to use them.  If, though, after asking yourself the question of "Is this the stuff I need to be worrying about, or is something else more important?"  you come to the conclusion that there is something more important to be worrying about, consider whether using other people's stuff might benefit you, so that you can move on to that more important thing.

It's always easier to understand what you did on your own, rather than to comprehend someone else's work and logic.  But that logic and rationale is present.  If you learn the knack of it, you can do awesome things.


Wednesday, September 7, 2016


Ch-ch-ch-ch-Changes (Turn and face the strange)Turn and face the strainCh-ch-ChangesDon't have to be a richer manCh-ch-ch-ch-ChangesCh-ch-Changes (Turn and face the strange)Don't want to be a better manTime may change meBut I can't trace time -- David Bowie

I'm more than six months into my new position, and there have been a lot of changes over the past few months.

I dropped my eldest daughter off at college last week.  I still haven't adjusted to that.  I found myself wondering at 4:00 today why she wasn't home from school yet.  Oh yeah, I reminded myself.  November for Thanksgiving.

Next week I finish my last class in my Masters in Bioinformatics.  That and turning in my final capstone paper are all that stands between me an my degree.  I've learned a lot over the last three years in that program, and I cannot recommend it highly enough.  Bill Hersh has put together a great program at OHSU.  Whether you go for the certificate, the masters, or even just the 10x10 program, it's all good stuff.

My standards work is slacking off as my implementation work is picking up.  I'm principle architect for three teams working on Interoperability stuff.  I wear three hats. Some days I'm an architect, others a product manager, and others, an engineering manager.  Some days I do all three, sometimes at the same time.

My schedule is split between three time zones, the usual left-coast right-coast for the US that has been the norm for most of my life, but now also about 4 hours in the middle of the night (12am -4am) Bengaluru time.  I sleep when I'm tired, which is not as you would expect to be "most of the time".

I still struggle with what I want to be when I grow up, forgetting that since I managed to reach 50 without doing so a couple of years back, I don't actually have to grow up, and I have a certificate from my family to prove it.

I suppose that some day when I retire, I will want to teach full time, rather than spending about a third to half of my time doing that.  What I think that really means is that my projects will become my students, rather than having students because of my projects.

Now if I could just figure out how to get the next six things done that I need to before the day is over, without moving to somewhere like Mars, or worse yet, Mercury or Venus.


Tuesday, September 6, 2016

FHIR in India

In case you missed me, I've just gotten back from a fifteen-day long trip, where I spent the last eleven days of it in India.  While there I conducted three training sessions on FHIR, one internally at GE offices in Whitefield, Bangalore, one for HL7 India, and a final one for a partner organization in Mumbai.  While in India I gave an overview of FHIR to nearly 200 software developers working in Healthcare.

Image via @msharmas

There's a great desire to learn more about FHIR in India, and I was privileged to be there to spark the fires as it were.  I am grateful to HL7 India who was able to pull together a half-day plus session in Bangalore on short notice.  I expect we'll be doing more together to follow up, as I expect I'll be back later to conduct some advanced sessions.  I'm also trying to get a FHIR Connectathon started in India as well, more on that later as plans come together.