OK Everybody, Synchronize your Resources

You know how in secret agent TV shows in the 70's and 80's, where at the start of a major intervention the agents all synchronize their watches to ensure that they knew what was to happen and when?  And if you failed to do that, you could really mess things up, because you wouldn't be doing the appropriate things at the right time.  Inevitably something messes up in those shows [the target gets back on the elevator to collect a forgotten item], and somehow a message needs to be sent from one party to another to ensure that everyone keeps on track and out of trouble [after seeing a morse code flash from a car mirror at the street level, someone posing as a secretary on the 11th floor distracts the target long enough for the agent to finish his data download].  And of course the communicated signal might have requested "Abort!", but that's not what actually happens, but everything works out in the end.

We have similar problems in healthcare when dealing with workflows.  The problem is really in how we communicate and ensure that the processes of two different organizations involved in a workflow remain synchronized.  Let's look at a sample set of communications in a workflow to produce a laboratory report:

Physician/Order Placer	Lab/Order Filler
I need lipids, an A1C, and a cardiac panel for this patient and sample.
	OK, got it.
	Hey, can you send me a new sample, this one is spoiled.
OK, got it.
Here's a new sample.
	Thanks, got it.
	Tests are in progress.
...	...
How are those tests doing?
	Lipids are in progress.  A1C in progress.  Cardiac Panel completed, awaiting final review.
	Here are the lipids results.
	Here's the A1C results.
I need those results STAT!
	Tests are all done.
	Here's the cardiac panel.
	Tests are all done.
	Here's the cardiac panel again, the results were amended.

As you can see, there are several points where control passes from one system to another in order to complete the workflow, and, in order to remain synched up, the two systems may need to signal each other in some way.  One way is to query for information [e.g., how are those tests doing] to be sure that the current state is recorded (you might have missed a message somewhere).  Another way is to respond to a "request" with an acknowledgement that you have accepted work [OK, got it], or moved it to a new state [Tests are in progress].  Out of band, even though one system might be "in control", another system could assert privileges to regain control (e.g., an out of band message to change priority [I need those results STAT!], or not shown: [Cancel that order]).  And you may tap someone on the shoulder to say, whoops, something changed [Here's the cardiac panel again ...].

The challenge here is that the Test Order as a resource is actually two (or more) information objects. The physicians "Order" resource is managed at the Order Placer system.  The Lab's "Order" resource is managed at the Order Filler system.  These two systems could communicate using their own resources, but then you have to worry about how gets to edit which resource when, and that gets complicated.  Some have suggested that there are two resources: The Request and the Response, and that the request is owned and managed by the placer, and the response by the filler.  All that does is hide the fact that there are two information objects that need to be synchronized, it's simply the whack-a-mole problem.  We hide the complexity over here, and it pops up over there.  Others, like myself are saying: There's one or two resources, and how you use them to manage your workflow depends on how your systems are integrated, and that your "internal" workflow management infrastructure and your "external" workflow management infrastructure could be looking like the same things, but be managed differently.

FHIR needs to support order management workflows in environments where the norm is Choreography [collaborating systems], and in environments where the norm is Orchestration [centrally controlled systems].  

I'm still trying to figure how to address this.  I think the first step is to acknowledge that the step of "Synchronizing our workflows" has to occur, and that some communications may need to be exchanged which may NOT be a full resource.

The real trick in all of this is making sure that whatever the workflow is, it all works out in the end.

   Keith

Finding the problem is ONLY the first step

There's something just not right with this model. I don't know what it is, but ... It niggles at the back of my brain. It doesn't work.  It's missing these properties that I expect, but I don't know how to get them out of it, or bake them into it.  And I should... it's just math.

I fuss and fight with it, and finally, I see what I'm missing. It should have been obvious all along.  I no longer wonder about what is wrong with the model, but now have to go and fix it.  I don't know how to do that yet, but I know where I can go find out.

Sometimes finding out what the problem doesn't immediately lead to a solution, but it's a good first start. Now to go find some more magic smoke.

    -- Keith

der's yer problem, yah let ahl der smoke out pic.twitter.com/pV2uXq2hdV

— Keith W. Boone (@motorcycle_guy) December 2, 2015

P.S. Technology is just like normal stuff this way.  The other day I headed out for an appointment, but the bike wouldn't start (and my eldest had the truck). It's cold out I thought... battery probably needs to be put on the trickle charger these days.  So I was going to roll it down the driveway and start it that way, but it wouldn't roll easily.  Thinking I was in gear, I turned the key on (there was enough juice to operate the controls, just not enough to start it), but was in neutral.  I checked more closely, and sure enough the rear tire was flat.  Must be a slow leak I thought, have to fix that, let's grab the compressor to put air in it.  Picked up the compressor and the handle broke off the plastic hose.  So I cancelled my appointment, fixed the compressor, started to put air in the tire, found that air was leaking out the valve stem.  Tried to find a valve stem online, failed.  Called the shop, they explained that the valve is attached to the tube (not a tubeless tire as I'd though), and so I arranged for them to come get it and replace the tube.  I could do it myself, but I got other stuff people pay me to fix (like the problem above) so that I can pay others to fix my stuff.

What is a Standard?

In my spare time [yes, such a thing does exist], I've been thinking about how my "PubMed for Standards" capstone project should index standards.  Which leads to the question in the title of this posting.

It's not the usual form of this question, but rather, what I'm trying to figure out is what is teh "unit of indexing" in the database.  Let's take some examples:  IHE Cross Enterprise Document Sharing (XDS), Web Access to DICOM Objects (WADO), DICOM Key Object Selection Document, HL7 Messaging Standard Version 2.3.1 (HL7 V2.3.1), HL7 V2.3.1 Patient Administration Message, HL7 Version 3, HL7 Clinical Document Architecture Release 2, HL7 Version 3 Person Registry, the IHE PCC Technical Framework, HL7 Consolidated CDA, HL7 CCD Version 1.1, and FHIR.

Now, how would you like to see these indexed in a retrieval system?  Each of these "publications" works in different ways.  XDS lives in the ITI Technical Framework, and is described in Section (Chapter) 10 of Volume 1, and several sections in Volumes 2a, 2b, and nearly all of 2x.  Web Access to DICOM Objects is the last of 18 sections in the DICOM Standard.  A Key Object Selection Document is a DICOM Information Object found in section A.35.4.1 of Part 3 of the DICOM standard.  HL7 Version 2.3.1 is 1026 page document with 12 chapters and 5 appendices, Patient Administration Messages make up one of these chapters (chapter 3). HL7 Version 3 is an aggregation of several standards published on the web by HL7 under the Version 3 title.  Clinical Document Architecture is one of those several standards published under the Universal Domains section of the previous publication, where Person Registry is a topic are under the Patient Administration domain of the Universal Domains section in the same.  The IHE PCC Technical framework is a collection of profiles developed by the Patient Care Coordination Domain.  HL7 Consolidated CDA is an implementation guide, the HL7 CCD Version 1.1 is a type of document described in the previous. FHIR is a standards framework: a collection of data types, resources, and protocols used for the development of health IT interfaces and systems.

Every single one of these may be relevant in a query for information about relevant standards.  As a system designer I may want to learn about all of FHIR, or just a single resource, all of CDA, or just a single template, all of DICOM or just a single part or part of a part, et cetera.

The challenge this creates for developing an appropriate index is trying to understand the granularity. Publication unit is just one level of granularity.  What makes the unit size is perhaps best understood as the smallest invariant unit size for provenance of the information: what is the smallest unit to which you'd provide author information about, or even better, what requires a briefer explanation of the thing being described as a whole.

What I've finally worked out is that an indexable unit is something to which I can identify some form of abstract: A subsection labeled abstract, description, introduction, purpose, scope or some similar heading is what I'm going to call a "Standard" -- for the purpose of indexing them.  Because that's the level at which they can be used or reused.

Where I won't go is in indexing templates beyond those of a document in CDA, or publication units below Implemetation Guide in FHIR, because the degree of proliferation once I break that level of granularity becomes unreasonable ... at least for the scope of my capstone project.

So, if I can reasonably find an abstract, and it isn't a fine grained data object, I would index it.  Where does that leave FHIR resources or OpenEHR templates?  Honestly, I don't know.  Both are as fine grained as CCDA or IHE PCC templates, and yet, they are also considered by some to be primary standards with some level of separately maintained provenance.  I think what I want to do is leave them out for now.

The next area for me to address is vocabularies and value sets, but the real answer for that is that it is out of scope.  I'm trying to fill a gap, and for value sets and vocabulary, UMLS, VSAC, and PHINVADS all address the location problem for these resources.  I don't need to do something to address that non-gap.

   Keith

Why should HealthIT Workflow integration be Different?

In a traditional (read "non-Healthcare" related) workflow scenario:

1. A workflow produces a good or service through the collaboration of different parties.
2. The good or service is developed in various stages with through various processes coordinated between parties, with various checkpoints to ensure quality.
3. Along the way, various information, services or goods are consumed as inputs, or produced as outputs, eventually generating the final good or service that is the goal of the workflow.

Under the above description, lab tests, imaging or other diagnostic studies, screenings, treatments, medication orders, or referrals are all activities involving workflow.  The good or service produced by a diagnostic study is information about a patient used in the diagnosis of disease.  Treatment provides a service that will either cure, or at least alleviate the symptoms of illness.  So really, there is no difference here.

The flow in workflow is of outputs to inputs between tasks being executed by different participants. The fundamental unit of work is a task.  This is reflected in many different models of workflow in the various standards that I discussed yesterday.  Tasks have a fundamental state diagram that is well described in OASIS Human Task.  Essentially, they are first created, then ready to be claimed, then reserved (claimed), and finally in progress and completed (or failed).  Some special states exist to account for non-recoverable errors (recoverable errors eventually complete or fail), premature exit (e.g., cancellation of an order), or on becoming obsolete (it is no longer necessary to treat a patient whose is no longer ill).  Tasks can also be in a special suspended (held) substate from which they return once they are unsuspended (e.g., putting a medication on hold while surgery is being performed).  It's conceivable that a task can go from any of the previously mentioned states to any other (Interface engine administrators often "requeue" messages that "unrecoverably" failed after patching the code).

Tasks have potential performers, those who could perform the task, an actual performer, a creator, and an administrator who can change it (often the creator and administrator are the same party).  Many of these roles can be delegated or reassigned (forwarded).

Tasks have inputs and outputs. These are essentially named slots to which you can attach things (much like Parameters used with FHIR operations).

There are a couple of other attributes of task that might be useful: Priority, type (of task), type of performer (used to qualify potential owners).

Here's my first crack at what Task looks like in FHIR.

<Task xmlns="http://hl7.org/fhir"> 
 <identifier><!-- 0..1 Identifier Task Instance Identifier --></identifier>
 <type><!-- 0..1 CodeableConcept Task Type --></type>
 <performerType><!-- 0..* Coding Task Performer Type --></performerType>
 <priority><!-- 0..1 Coding Task Priority --></priority>
 <status><!-- 1..1 Coding Task Status --></status>
 <subject><!-- 0..1 Reference(Any) Task Subject --></subject>
 <definition value="[uri]"/><!-- 0..1 Task Definition -->
 <created value="[dateTime]"/><!--  1..1 Task Creation Date -->
 <lastModified value="[dateTime]"/><!--  1..1 Task Last Modified Date -->
 <owner><!-- 0..1 Reference(Device|Organization|Patient|Practitioner|RelatedPerson) Task Owner -->
 </owner>
 <creator><!-- 1..1 Reference(Device|Organization|Patient|Practitioner|RelatedPerson) Task Creator -->
 </creator>
 <manager><!-- 0..* Reference(Device|Organization|Patient|Practitioner|RelatedPerson) Task Manager -->
 </manager>
 <input>  <!-- 0..* Task Input -->
  <name value="[string]"/><!-- 0..1 Input Name -->
  <value[x]><!--  0..1 * Input Value --></value[x]>
 </input>
 <output>  <!-- 0..* Task Output -->
  <name value="[string]"/><!-- 0..1 Output Name -->
  <value[x]><!--  0..1 * Output Value --></value[x]>
 </output>
</Task>

As a resource this is very well aligned with HumanTask and XDW, and would integrate fairly well in a workflow system defined using BPMN and/or orchestrated or choreographed using other. It doesn't have any specific requirements about "how" the task is managed, but enabled it to be managed and tracked.

Task Resources like this MAY be aggregated into a workflow instance resource, which allows a collection of related tasks associated with a given workflow to be managed together.  My first crack at that resource looks something like this:

<Workflow xmlns="http://hl7.org/fhir"> 
 <identifier><!-- 0..1 Identifier Workflow Instance Identifier --></identifier>
 <name value="[string]"/><!-- 1..1 Workflow Name -->
 <description value="[string]"/><!-- 0..1 Workflow Description -->
 <subject><!-- 0..1 Reference(Any) Workflow Subject --></subject>
 <definition value="[uri]"/><!-- 0..1 Workflow Definition -->
 <created value="[dateTime]"/><!-- 1..1 Creation Date -->
 <author><!-- 1..1 Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson) Workflow Author --></author>
 <tasks><!-- 0..* Reference(Task) Workflow Tasks --></tasks>
 <status><!-- 1..1 Coding Workflow Status --></status>
 <failureReason><!--  0..* CodeableConcept Failure Reason --></failureReason>
</Workflow>

Now, if you want to put these two together, you can manage just about any workflow someone wants to throw at you.  Do medication orders for certain substances need to be reviewed before being filled?  That's a task that is part of the medication ordering workflow.  Does a positive result need to be confirmed by the lab supervisor?  That's a task that  is part of the laboratory testing workflow. These tasks can be associated with their subjects through the subject reference, without ever interfering with the interpretation of the subject resource.  If you want to dig into the workflow associated with an order, you could query for workflow.subject = resource, or task.subject = resource, and find the workflows still open, or the tasks as yet uncompleted.

This approach simplifies integration of clinical workflows with clinical data without making any assumptions about the workflows that go along with it.  And best of all, almost none of it is specific to healthcare.  Everything I've described above comes from existing IT standards and systems, but can be readily applied to healthcare.  

A Brief History of non- HealthIT Workflow Standards

I first started playing with workflows standards in the late 90's, before I ever got involved in Healthcare.  Digital publication was (and still is) all the rage, but back then it was only for high-end users, and there was a good deal of workflow involved that crossed multiple organizations.  It was a critical concern of many customers of the XML database product I worked on.

If you wanted to publish an article, you might need some photos or graphics to go with it.  You needed to acquire those, negotiate rights, develop and approve content, layout, et cetera, before the article ever went live.  You may even have needed some time to covert the article from a proprietary format to a standard format using XML.

Back then there were numerous workflow engines (I recall one from Toshiba that I investigated fairly deeply), and also some standards.  The Workflow Management Coalition (WfMC) had been around for a bit (about 5 years) and had some workflow APIs it had evolved.  A number of workflow engines even supported those APIs.  It was like a DOM for workflow, except that back then we had to interface to those APIs using CORBA, because REST hadn't been invented yet.  There were also a number of other workflow products, including a family of products described as group-ware, the most famous of those had a darling little name that we morphed into an epithet describing its most egregious failure, we called it Bloats [Lotus Notes].

We are now looking into workflow in FHIR, but I think at the moment only superficially, assuming that there are some common structures and capabilities built into (mostly) ordering and fulfillment processes.  Here's where I'd advise taking a step back from "Healthcare IT", and look at what is already available in existing IT. But to do that, we probably need a brief history lesson on what already exists, and its purpose as it relates to workflow.

WfMC created XPDL and Wf-XML, but these weren't even extant at the time I was looking at their efforts.  Instead, what I had been looking at was the Workflow Client Application (Interface 2) Application Programming Interface, otherwise known as WAPI.  This specification, circa 1996 describes the "things a client needs to do" to integrate with a workflow engine.  We want to integrate workflows in healthcare, not integrate with a workflow engine, but this is a pretty good description of some of the functional capabilities we need to support.

OASIS formed the BPEL workgroup sometime in 2003, to develop Business Process Execution Language.  Object Management Group (OMG) developed BPMN, and eventually BPMN 2.0 to be the format for Business Process Modelling Notation.  All of this stuff is fine, but the reality is that it doesn't meet the needs for workflow implementers very well.  XPDL, BPEL and BPMN make it possible to describe workflows and execute workflows, but they don't really help much in enabling the capture of essential data for workflow management.  There's a whole passel of discussion in the workflow community on Choreography vs. Orchestration, but the reality is that it doesn't matter to us, both describe execution, which is a step beyond where we want to be in FHIR at first.

OASIS Human Task does support some of the information capture needs.  If you look at Human Task and many of the operations it supports, you'll see a great deal of overlap with WAPI described above.  Human Task defines a WSDL for its operations; an API or set of functionality that systems supporting workflow need.  Where Human Task succeeds is in describing the data that is needed to manage a workflow.  Where it mostly fails is in the heavyweight SOAP/WSDL based approach used to manage that workflow.

Human Task became the basis for IHE's Cross Enterprise Document Workflow (XDW) [now in Final Text form!]  IHE's XDW takes that description in Human Task and turns it into the closest thing to a workflow resource that we have today: an XML Document that becomes a repository for a specific workflow instances state. Updating that document updates the state of the workflow. The biggest challenge that XDW implementers have is in the grain size.  It's off by one.  What they want to update is the task in a workflow, not the entire workflow.

So, take a look at the various references for workflow here.  Next time I'll explain what I think we need to do with this in FHIR, and how it will enable healthcare workflows in Healthcare IT.

   Keith

If I were designing the perfect FHIR Profile Authoring Tool

First of all, when it installed, I'd have it ask a few questions about who I was, my name, e-mail, et cetera. Then I'd have it ask some questions about the organizations I was affiliated with, possibly selecting some of them (e.g. HL7, IHE, etc) from a pick list, or adding others.

When the application starts, I'm going to want to do one of three things: Start where I left off from my last project, or from where I left off on a recent project, or start a new project.  When first loaded, I'm going to have to create a project.

That project is going to be one of five things: Creating an IG, a value set, a profile, an operation or an extension.  That project is going to be created on behalf of one of my organizational affiliations, which will have some preset rules for how the project structure works (or maybe I want to apply my own personal rules -- because I might be setting them for the organization).  Those rules affect where in the project certain files are stored, and in what sort of repository they are stored (e.g., CVS, SVN, a file system, a website or FHIR Server, et cetera).  Having some useful presets would be good.  For example, for GAO, I set up a particular file system structure for the contents of the IG, and the files were checked into SVN.  Files are named in a certain way based on the kind of resource, its id and a few other bits of trivia perhaps.  You could come up with a couple of different schemes.

An IG would start off with one of a few sample IG starter page sets, adhering to a particular content design.  I could swap them out for the most part without fear that my customized content would be messed up.  Similarly for a profile, value set, operation or extension would also allow for some preset designs and customized content files.

When creating an IG, a wizard would guide me through certain selections, "style", kinds of content to include (profiles, value sets, extensions, operations), et cetera.  It would take me through the process of identifying actors (an IHE term mostly closely associated with Application Role in HL7 Version 3), to which a conformance statement might apply.  It would have me define the conformance statement for each actor, including some optional features that might implemented (right now, FHIR conformance resources don't really have support for options though).

When creating a profile in an IG, I'd specify the resource and possibly a role being played.  The tool would create the profile name based on the IG name/code, and the resource name and role.  Thus, a profile for a patient resource in the Guideline Accountable Ordering IG (GAO) would be named gao-patient, and one for a ordering provider might be gao-ordering-practitioner (the form defaulting to igcode[-role-name]-resourcename).

After having named a profile, I'd basically be asked to check of those properties that I wanted to profile, and then quickly modify their values (cardinality, must support, etc).  Where an existing value set was present, I'd be asked if I wanted to restrict or extend it where permitted.  On creating a new value set, I'd be given simple ways to select codes from existing value sets that I'd used previously or which already exist).  On creating an operation, I'd be asked to name the parameters, and further specify their details.  As things went on, I'd discover the need to create a new profile, and could add that profile to a resource elsewhere, and the tool would remember that I referenced an as yet unknown profile, and would put it on my to-do list to create.

Building the IG would be a two stage process.  The first stage would take the information I supplied in separate component files, and put it together into FHIR resources sufficient to be the guide.  The second stage would be to compile those FHIR resources into the content we see on the FHIR IG site today, essentially running the FHIR IG build part of the process over those resources.  The tool would also verify that I followed a number of best practices... that I had validating examples for each profiled resource, that I had examples of input and output parameters, and that I had conformance statements that linked to those profiles, and that no profile or valueset or operation was not linked back to something in the IG (ever create a set of constraints that weren't ever referenced any where?  It's been done before.  I'll bet you can't find the CCD template that was never referenced by any other CCD template, and so hardly ever used).

Anyway, that's my wish list.  Get crackin' on it guys, would you.

   Keith

The Tinker Tax

This weekend I replaced the leaky radiator in my truck.  I know from past experience that this is about a half day job.  A shop would probably charge me 2-3 hours of labor for it.  It took me two days.  I saved about $150 on the labor, but in the process, broke my transmission fluid line, and did so in a way that I couldn't fix it myself.  It cost me about $400 to have that repaired professionally (because that's not a job I would take on not having the tools, and having already screwed it up once). The end result is that I paid about $400 to save $150, so a $250 educational experience.

A friend of mine (Gila Pyke) calls that the tinker tax.  It's a useful measure of the value of a learning experience. In this case, I actually did learn how to do something, just a bit too late for it to pay off THIS time. Next time I'll know better and be able to save myself the hardship of having to take my broken repair job to a pro to fix the fix.

How does this apply to Health IT?  Well, the first time you do something you've never done before, you need to be ready to pay the tinker tax.  The tinker tax isn't always measured in dollars. Sometimes it is measured in time.  Either way, you should budget for it.  I knew when I undertook my radiator repair job that if I failed I could afford to take it somewhere else, and quite honestly, the additional work that was done wasn't wasted (I didn't badly break something that wouldn't have needed repair soon anyway).  But often, Health IT projects are undertaken without any cushion, without any contingency, and with the assumption that everything will work the first time.

Really?  When's the last time that happened for you in any other undertaking that you did for the first time?  Be prepared to pay the tinker tax.

Just in time for Christmas, an Armor Class upgrade

My first motorcycle jacket was made of ballistic cloth and padded, with plastic plates beneath.  It worked just fine, looked OK but not great, and protected me for the one accident I ever had, but on hitting the pavement the jacket ripped, and I've worn it rarely since.  My second was simple black classic leather.  It looked great but has a couple of flaws for winter riding: The zippers are wicked difficult to open with gloves on, and getting it all the way closed in for cold riding was difficult, and uncomfortable.

Recently I was offered a jacket to try out a review, and since I needed I new jacket, I chose this one to check out from Motorcycle House.









A couple of things attracted me to this jacket:

• The pockets. 
  
  For some reason, I like having lots of pockets.  This jacket has a ton of pockets. The outer ones fit my riding gloves (something I couldn't say about the classic leather jacket I was using).  The inner ones are accessible even with the liner installed.  And the zippers can all be operated with gloves on.
  
  
  
• The reflective stripes.
  My bike is black.  My jeans are black.  My chaps are black.  Riding in the dark means that pretty much I'm an otherwise invisible headlight or taillight with a black jacket on. The built in reflective trim makes it possible to see me, which makes me feel a bit safer.
  
• It looks good.

Two things I discovered I like about this jacket after I tried it out:

• Comfort. The jacket fits me well, and is comfortable around the neck when I close it up.  And it's warm in the cold.  I had planned to write this review sooner, but it's kinda hard to write a review about a jacket that you are going to use for cold weather riding when you haven't had any cold weather to ride in.  What cold weather we've had recently has also overlapped with travel. Finally we got some today, so I took a half-hour for a good ride over lunch.  It fits my final criteria, it's warm.
  
• It's also armor.  Padded leather is about AC 8 on a DnD scale, but I'd give this jacket a +1 for ease of movement in it.  It has armor at the back, shoulders and elbows, but I didn't even notice it until I hung the jacket up.  You simply don't feel it.

While I was given the jacket in exchange for this review, the price is also pretty good, at $99.99. And given that today is Cyber Monday, you can also get it on sale.

I don't usually do reviews except for books, and this is my first review for something that most of my usual audience might not appreciate.  I'm probably not going to make a habit of it, but then again, I won't rule it out completely either.  After all, what good is to have a blog if you don't try something different every now and then.

Passion is the Midi-clorian particle for HealthIT Jedi

What does it take to become a Health IT Jedi?  Do you have to have some special skill?  Is there some genetically contributed factor, some Health IT midi-chlorian particle that you need large quantities of to really succeed?

I think not.  The critical factors are, I think, in this order:

1. Passion
2. Opportunity
3. Persistence

Passion

If you have a passion for your craft, you will have an appetite, a curiosity, perhaps even a voraciousness to learn more about it. The more you learn, the more you can do.  The more you can do, the more others will recognize you for your ability. At some point, you too will recognize it (often a long time after others have).

Opportunity

Passion unspent leads to frustration.  It needs an outlet, a doorway, an escape, in order to be realized fully.  Opportunity is that means of egress.  Opportunities come in thousands of ways.  A new software component needs to be developed, will you invent it fully yourself, or learn from the work of others and spend your creative energy adding new value? A group of people need help, will you pitch in and make some time to help them, and at the same time learn more, or will you sit by the wayside and wait for them to do the heavy lifting?  When you don't understand, will you ask the question that may lead to better understanding?  Or will you be silent and hope that someday you will get it?  

What if you have no opportunities?  Then you aren't looking hard enough.  Be creative.  Let that frustration inspire you.  Take a chance.  I guarantee that if you do look closely, you will find a way, which leads to the final attribute.

Persistence

Practice makes perfect.  Doing leads to learning.  I often tell my students that the best thing that they can do for themselves after taking a class is to DO something with it, and the best time to take a class is just before you need to use the material it teaches, or perhaps just a little bit later than that (so that you learn what you need to learn).  Your first opportunity will lead to learning, but probably not stellar success. Along the way you WILL fail.  If you don't or haven't, you aren't trying hard enough.  

Passion helps here, because it gives you the drive to try again ... and again and again and again.

I have failed.  I have found opportunities -- sometimes even the slimmest of chances.  I care deeply about what I do.  As a result, I have one of the most rewarding of careers I could have ever imagined. 

You could too.  It starts with passion -- the midi-clorian particle for a Health IT Jedi.

   -- Keith

P.S. Thanks to Rene Spronk, and the Furore FHIR DevDays team for the great photo above.

Just Proud

What is it about age that makes us proud of our youth?  Over the last week I've had several opportunities to be proud of the accomplishment of others.

I'll start first with my youngest daughter, who overcame several setbacks this summer to brave her way through 20+ hours a week for several months of practice and rehearsal and 2-3 competitions each weekend to finally win (along with her classmates) the title of USBANDS National marching band champions.  That's just a proud dad talking.  To the left is a video of the band arriving home from their victory.

Then there's the team of students I taught Interoperability and Standards to this summer; whose class project sailed through IHE Patient Care Coordination for implementation in the 2016 - 2017 season. That's just a proud TA talking.

Then there's the team of students (see image at the right) from Heilbronn University who won the FHIR DevDays student competition.  I have no reason to be proud of them except that they did something cool with FHIR. That's just a proud co-developer talking.

Then there's the team of OHSU Informatics students who won the AMIA student competition, giving OHSU two wins in two years.  That's just a proud alum talking.

Then there's the four high school students who presented at AMIA.  I have no excuse to be proud of them, other than I see something in them that maybe I had at their age, or perhaps just wished I had at that age.   I guess I'm just proud to see others succeed.

Preaching to the Converted

I'm on day 8 of 12 days of travel, having arrived in Amsterdam yesterday for the start of FHIR Dev Days.  My presentation this morning covered some of what we've learned in IHE "Profiling FHIR". The presentation is entitled "Preaching to the Converted" because at this event I don't have to explain what FHIR is, or why people should use it.

The presentation is below.

OHSU Student Project Approved for IHE PCC 2016-2017 Cycle

As I mentioned about a month ago, several OHSU students created an IHE Profile proposal which went (at this stage) before both the planning and technical committees.  The profile was approved by the Technical committee today to move forward as a 2016-2017 work item.

    Keith

FHIR Best Practices or Everything I needed to know about FHIR profiling that I learned in Kindergarten

1. Rules are good.
   When profiling, set up your conventions, so that you don't have to think about it.
2. Explain what you are doing and why.
   Description fields explain what you are doing.  Requirements fields explain why.  Use full sentences.
3. Show is better than tell.
   You need to have examples, plan for it.
4. Don’t do any more than you have to.
   When profiling, don't profile stuff you don't care about (and don't profile out stuff just because you don't care.  It makes it easier for others to reuse resources they may already have).  That may mean using slices to make sure that you have "one like this."  That may be hard at first, but your implementers will thank you.
5. Make the biggest one do the heavy lifting.
   Make the server be the one to implement all the options, and let the clients choose when there is more than one way (e.g., GET/POST, JSON vs. XML), et cetera.
6. Don’t expect to be great at it at first.
   We're all learning this stuff, even Grahame makes mistakes.

The Medical Industrial Complex

I belong to a lot of different mailing lists.  The obvious ones are HL7 and IHE workgroups, but other lists relate to S&I Framework activities, AMIA informatics workgroups, and the Society for Participatory Medicine.  One of the things I find most interesting, and also the most frustrating about these lists is the sometimes ethnocentric bias commonly found.  Nobody is exempt from this (even me).

A recent term showed up on one of these lists: Medical Industrial Complex

Usually this term is used disparagingly. I find that each different list thinks about this term somewhat differently.

• Some think about it as "the vendors", referring to sellers of medical devices, software, et cetera (e.g., like my employer).  This often shows up from the perspective of providers, and sometimes the government.
• Others think about it as "the payers", referring to the health insurance industry.  Many times, this shows up from either perspective of providers, or patients. 
• Others think about it as "the healthcare providers", referring to doctors, hospitals, et cetera. This is most often the perspective of patients, although sometimes the perspective of individual providers dealing with institutional providers (hospitals or groups).
• Others think that a significant chunk of the Medical Industrial Complex is sponsored and controlled by "the government", a perspective espoused often by any group other than "the government".

The Medical Industrial Complex, or its constituents as an aggregate group (all of the above) are easy targets.  They are motivated by money (profit or savings depending on the role), not saving lives. They have no interest in the concerns of any other stakeholder, including the patient.  

The medical industrial complex is in fact too easy a target.  We oversimplify the situation in ways that rarely result in any problem being solved.  Claiming, for example, that "____ are against interoperability because it is not in their best interest." is simply divisive, and not useful.  Oh, and I've seen that sentence filled out at least three different ways.

Presently, the Medical Industrial Complex is a multi-player, zero-sum game.  That means where one group gains, another loses.  All of us reading this blog are players in this game in some way.  If the game isn't fun, what we need to do is change the rules, but that's going to require all of us in this thing that people call the "Medical Industrial Complex" to work together.  Yes, that means you.  What are you going to do about it?

     Keith

FHIR Dev Daze

Yep, I did say daze.  As in deer caught in the headlights, glassy eyed, OMG, is that happening to me?  Shortly I'll be about and abuzz on FHIR, on a ten-day whirlwind tour.

In Amsterdam, I'll be at Dev Days, along with Grahame Grieve, Ewout Kramer, Lloyd McKenzie and Josh Mandel -- basically the Who's Who of FHIR.  It's an honor to be there, and I'm glad to have been asked to present.

I'll be talking about some of the work we did last year in IHE using FHIR, some of the challenges we ran into, and some of the solutions we came up with. Included in my discussion will be an overview of:

• Guideline Appropriate Ordering (GAO) - A profile to support clinical decision support that adds an operation on the Order resource.
• Clinical Mapping (CMAP) - A fairly straightforward profile of an operation on the ConceptMap resource.
• Reconciliation on FHIR (RECON) - Adaptation of the RECON profile to support exchange of reconciled lists in FHIR.
• Mobile Access to Health Documents (MHD) - Essentialy a FHIR-based implementation of XDS (shh... don't tell anyone that, its a secret).
• Patient Demographics Query for Mobile and Patient Identifier Cross-Referencing for Mobile (mobile in IHE speak is a code-word for FHIR).
• RESTful Queries in ATNA - Adding a query capability to the ATNA profile.

I'll be building some of this talk from material I'll be using the week before, where I'll be explaining FHIR profiling to IHE profile developers.  The focus of that talk will be more on what you need to know to profile FHIR, and some best practices that we've discovered thus far.

In between the two of these events, I'll be attending the IHE technical committee meeting where I expect we'll be talking about FHIR in Care Planning, and following that, headed off to AMIA, where I expect to hear a number of people buzzing around about FHIR, sort of like moths to a flame.

   -- Keith

Moth and candle image via Ray MacLean

Help HL7 improve clinical information exchange

If you are a healthcare provider (physician, physician assistant, nurse practitioner, nurse or other licensed provider), HL7 would like to hear from you about the information you think is relevant and pertinent to exchange in support of continuity of care.  If you want to participate, all you need to do is take a short survey.  You will need to act quickly. We are trying to gather this data before the end of the year, and due to the volume of provider responses, we are expecting to close the survey at the end of November.

We are planning on using your responses to develop an HL7 informative publication on what sort of information should be included in clinical summaries.

The slide presentation below explains the purpose of this project in more detail.  If your organization would also like to participate more deeply, there is another opportunity as well.  We have a separate engagement process for governance groups such as your organization's Informatics steering committee to allow them to provide input as a consensus body.  If you want more information about that opportunity, contact me via e-mail.

A “PubMed” for HealthIT Standards

By way of a short introduction, this was the outline I submitted for my capstone project at OHSU.  As you might guess, starting my capstone means I'm in the home stretch.  I'll be writing more about this over the next six months.

  -- Keith

---

Capstone Project Charter for Keith W. Boone

Abstract

Newcomers to the use of health IT standards often ask the question “Where do I start?”.  It is often difficult to find applicable standards from the various organizations who are often the sole publishers of these documents.  This project will develop an online index supporting search and retrieval of the standards.  During the project, the index will be populated with content from several standards organizations.  The search capabilities will be piloted by interested individuals.  Data will be collected about usage of the system, and the utility of it to end users.

Introduction and Background

One of the most common questions asked by people who are trying to understand health IT standards is “Where do I start?”  Each standards development organization (SDO) has its own web site and is often the principle (and possibly the only) publisher of its standards.  Health IT implementers may need to identify or access content from multiple standards developers, either to compare the capabilities of each, or to implement a system that users each possibly in different ways.  Other health IT leaders have suggested that there be a common way to access this information[1], but none is yet available.

While the American National Standards Institute (ANSI) in the US provides an index[2] of all its approved standards and is an authorized source for standards from the International Organization for Standards (ISO), many organizations developing health IT standards are not members of ANSI, nor are all health IT standards necessarily available through ISO.  Furthermore, both organizations publish standards for more than just health IT systems, making it difficult to locate healthcare specifications by themselves.

Health Level 7 (HL7) has developed several specifications that can be applied to this effort.  The HL7 Templates Registry Business Requirements[3] specification describes metadata, policies, navigational, security, search and other capabilities for a registry of specifications using one or more of the HL7 standards.  They also published a metadata specification based upon a review 20 different standards or specifications from four different SDOs in support of unifying metadata across clinical quality standards[4].  Both specifications are applicable, but have not yet been implemented in a system that searches across specifications from multiple SDOs.

The United States Health Information Knowledgebase (USHIK)[5] provided by the Agency for Healthcare Research and Quality provides a standards portal[6] describing the data elements found in the ANSI Health Information Technology Standards Panel (HITSP), American Standards Committee (ASC) X12, and National Council on Prescription Drugs (NCPDP) standards.  This portal enables search for data elements available in a limited number of standards, but does not support searching for the standards themselves.

Project Design and Scope

The purpose of this project is to pilot a source of entry into the variety of different standards available to health IT implementers, informaticists and educators who want to learn more about health IT standards.  The concept is based loosely upon PubMed, a singular source of information for information from medical journals, but is applied to standards published by SDOs.  Rather than populating the information in the index manually, this project proposes to use existing information resources via RSS and/or Atom feeds provided by an authoritative source (e.g., the SDO itself).  Metadata information will be captured from this feed and indexed in a repository, allowing those interested in Health IT standards to search for, and compare applicable standards for different use cases.

Methods

The project will develop a metadata model for health IT standards based upon existing work, create a database to support search of this metadata, enable population of the database via commonly available Internet subscription formats (RSS and Atom feeds), and develop and test a search interface for accessing health IT standards.  The database will be populated with content from at least three SDOs.  Once populated, the pilot will be publicized to members of these SDOs and other organizations with an interest in learning more about health IT standards.

Data Collection

The site will be instrumented to capture usage statistics in two ways.  Google analytics will be used to capture specific details about web site interactions (links clicked, search paths used, et cetera).  Some individually identifiable data may be present in data captured via Google Analytics results (network and location).  The site will also be instrumented to collect other data from users including specific search requests, time on site, and feedback about the usefulness of the site.  Individually identifiable user information will not be captured or stored from this instrumentation (e.g., user identity, computer or network characteristics, et cetera).

Success Criteria

Upon completion of this project, I expect to have shown the capability to readily create an index of standards from multiple SDOs, the utility of such a site to the health IT community, and to have gathered feedback about how to improve searching of health IT standards.  Hopefully such a standards index will find a permanent home within the health IT standards community.

---

[1].     Halamka, J. The United States Health Information Knowledgebase. November 7, 2012. Life as a Healthcare CIO.  Available on the web at http://geekdoctor.blogspot.com/2012/11/the-united-states-health-information.html

[2].     ANSI Standards Store. American National Standards Institute. Available on the web at http://webstore.ansi.org/

[3].     Gower C, Curry J, Stechishin A, Shafarman M, Roberts J. HL7 Templates Registry Business Process Requirements Analysis, Release 1. December 2013. Health Level 7 International, Inc. Available on the web at http://www.hl7.org/implement/standards/product_brief.cfm?product_id=328

[4].     Boone K, Boxwala A, Rhodes B, Moehrke J. Clinical Quality Metadata Conceptual Model. December 11, 2014. Health Level 7 International, Inc. Available on the web at http://www.hl7.org/implement/standards/product_brief.cfm?product_id=391

[5].     Fitzmaurice JM, Donnelly J, Barnes R. The Standards and Interoperability Framework Portal in the United States Health Information Knowledgebase. September 29, 2011.  Standards and Interoperability Framework Initiative. Available on the web at http://wiki.siframework.org/file/view/USHIK+SIF+9.29.11p+v2.1.ppt

[6].     United States Health Information Knowledgebase. the Agency for Healthcare Research and Quality. Available on the web at https://ushik.ahrq.gov/