Tuesday, November 25, 2014

One Less Thing

This one showed up last week in my inbox while I was busing being overwhelmed with AMIA ... From my perspective, this is a good thing, because it takes one more thing OUT of my travel budget, coordinating a number of different activities. I wish there was more of this kind of collaboration, and less of the other ...

Dear IHE USA participants,

Today, a strategic partnership between the Interoperability Workgroup (IWG), HIMSS and IHE USA was announced to streamline the process for achieving connectivity between EHR and HIE systems. This alliance will strengthen IHE USA's current program to improve the quality, value, and safety of healthcare by enabling rapid, scalable, and secure access to health information at the point of care. ICSA Labs  has been selected as the testing and certification body for this effort. Read the full Press Release to learn more.

"Both IWG and IHE USA have worked independently with notable accomplishments. However, the consolidation of our efforts, along with the commitment of these organizations, offers the most promise to create a real, lasting impact and make interoperability a reality in healthcare," said Joyce Sensmeier, MS, RN-BC, CPHIMS, FHIMSS, FAAN, president of IHE USA.

IWG, HIMSS and IHE USA will announce the opening of the new testing and certification program at the IHE North American Connectathon Conference 2015 in Cleveland, Ohio at the HIMSS Innovation Center on Wednesday, January 28, 2015. We cordially invite you to join us as we announce the next phase for IWG's testing and certification program. Visit IHE USA's website to learn more about this conference and register online today.

Thank you for your support and efforts as we raise the bar for interoperability and industry standards in the US. If you have any additional questions please contact iheusa@himss.org.

Sincerely,



The leadership and staff at the Interoperability Workgroup, HIMSS and IHE USA.


Monday, November 24, 2014

Workflow Automation

I've now seen more than a dozen, and written almost a half-dozen workflow profiles over the past two years.  After the first two, the remainder get simpler.  After the first three, if I cannot automate some part of the process, I must be sleeping.  For my last five, I automated a huge chunk of the content development.  And as it turns out, with BPMN 2.0, there is an XML expression for the semantics of what gets depicted in an IHE Workflow profile, addressing things like task ownership, attachments, messaging, and sequencing.  As workflows get more complex, we'll need to incorporate branching and notifications as well.

So for the next IHE PCC cycle of profile development I will be building an Appendix to the PCC Technical framework profiling the use of BPMN to describe IHE Workflows.  The next IHE Workflow profile to come out of PCC (and Radiology): Remote Read, will take advantage of what I get done to facilitate implementation.

A couple of quick notes on the value of this:

  1. I've shown that you can automate development of conformance rules, test plans, and implementation testing via an XML representation of the workflow.
  2. I've also shown that a lot of documentation can also be generated from the XML representation.
  3. You could actually plug the BPMN into your workflow automation tools to simplify your implementation.

It remains to be seen whether I can profile BPMN 2.0 and its XML representation of the workflow semantics (I care some about the pretty pictures, but not terribly much) to provide the same set of capabilities.  But so far, early investigations are promising.  Since I already have a set of five workflows that I've developed my own little DSL for, basically I'll be looking for how to represent that DSL in BMPN 2.0.

It's one of those things you'll get to look forward to here in 2015 as I develop that content in IHE.  And hopefully, as the IHE/HL7 Joint Workgroup continues on its slow but steady process to creation, we'll be able to look at capturing workflow details in FHIR.  But that will have to wait at least for DSTU 3 (the content train for DSTU left the station months ago).

    -- Keith

Friday, November 21, 2014

My First AMIA

Believe it or not (and most people there found it difficult to believe), prior to last week, I had never been to an AMIA meeting before.  I think part of the reason few believed I had never been is because I knew so many people there, whom I have met in HL7, IHE, HIMSS, HITSP, S&I Framework or other settings over the past decade.  And while I knew so many, even more knew me.

The scientific sessions were probably the most interesting.  Adam Wright had a great presentation on using Possion parameters to detect changes in alert activation levels.  What was cool about that was that you could apply the technique to any countable event, and I've got a ton of different applications for that.  Another presenter had shown (or though she had shown) that NOT using a system was better than using it badly, but in fact, as it turned out (at least in my analysis), she had NO data in the study to illustrate that at all, and in fact, in her control arm, where the system was not used, folks did not fair as well as when the system was used imperfectly.

One session I attended was about the formation of Healthcare Services Platform Consortium (HSPC), a panel discussion led by Stan Huff and other HSPC members.  Wow!  Just what I needed.  Another consortium to pay attention to.  Oh, and this one is run by physician centered organizations, so it is clear that it will be balanced.  I get a little tired of consortium creation and a job function.  After all, there's already not enough things going on, including IHE, HL7, CCC, HIT Standards Committee, CommonWell, S&I Framework (and before that HITSP), CIMI and ...  I honestly don't know how Stan does it, given that he's leading up four (now five) of these efforts, but I sure don't have the travel budget for this.  Don't get me wrong, I really don't have any complaints about direction, just lack of coordination.  We have plenty of that going on already.

There was quite a bit of buzz about FHIR going on throughout AMIA, and it played a major role in at least 5 sessions that I attended.  Healthcare Informatics called it a Smoking Hot Topic at the meeting, and Neil Versel talked about it as a Public API on his blog over at Healthcare IT News.  I think we've just recast Phoenix Rises as a FHIR-bird.

Probably my favorite activity was the poster session, where I got to meet people doing some very real implementation work, many using the standards that I know and love, and write about here.  There were easily half a dozen projects that I found interesting, and I really enjoyed spending time with the people investigating the use of these standards.  In several cases I was able to point them to some other things they might also look at to improve further.  For example, one person was showing a system he and others had built to merge CCD documents, so I pointed him to the IHE PCC Reconciliation profile for some advice on how to identify and display reconciled medication lists.

I also find it fun to walk down University row, and say "Sorry, I'm already in a program..." whenever anyone asks me if I'm interested.

Of course, while AMIA was going on, the rest of the world didn't stop.  I had double homework in one class (at least if I wanted extra credit), and a draft of my term paper due for another.  Which meant that I got precious little sleep.  I'll plan better for next year, because while this year is my first visit to AMIA, it won't be my last.



Saturday, November 15, 2014

IHE PCC Profiles for 2015

Several IHE Domains met last week to discuss work items for the coming season of interoperability. IHE IT Infrastructure's 2015 Plan is described by John Moehrke on his blog.  IHE PCC started with eight work items, which we reduced to six and moved forward with.

RECON on FHIR takes the IHE Reconciliation work and adapts it for use with FHIR.  The basic challenge addressed by this profile is how to represent the reconciliation act.  Fortunately, FHIR has the List resource, and that actually covers everything we probably need for this profile, and was designed in part for this kind of use.

Clinical Decision Support for Radiology is one we'll be developing on behalf of IHE Radiology, but will likely remain a PCC profile.  The idea behind this one is that ordering physicians and radiologists here in the US will soon be required to verify that certain kinds of imaging orders are appropriate in order to get paid.  Other countries, while not so draconic in policies, are starting to have an interest in this sort of order review as well.  So, we want to have some sort of CDS verify the order as it is created, and as it is received, and to gather additional information if necessary.  For this, we'll likely use something like RFD if additional information needs to be gathered, but otherwise, simply return a token of some sort from the CDS system indicating that the order is deemed appropriate according to some guideline.  Then the receiver can simply verify the token if so desired, or test the order against its own set of appropriateness guidelines.

Device Observation Semantic Bridge will probably get renamed.  The point of this one is that some EHR systems would like to have a simplified summary of device observations created to make it easier for them to store the information, in CDA rather than HL7 V2 format.  So, we'll have a content profile that explains how to convert V2 device observations to CDA, create a summary and link it to the device observation.  We'll also have another integration profile that explains how to get vocabulary mappings from one system to another.  We will likely using CTS 2 to support that, although there may be some interaction also with FHIR.  One supplement, two profiles.

Remote Patient Monitoring takes what Continua and IHE have been doing and demonstrating for the last half decade and make it into a profile.  This one should really be very simple. The main point is to have a profile that enables Continua specifications to be tested at connectathon.  This one may go back to PCD once we have finished it, and we expect this one to come out early because it is so well understood.

Remote Read is a Workflow profile that will likely be owned by IHE Radiology when it is complete, but which will be supported by PCC during development.  I also expect to work on an appendix for IHE PCC which shows how to define a Workflow Profile using BPMN 2.0.

Data Access Framework will be an interesting animal.  One part of it will be a framework for supporting document queries in health information exchange, which will become a PCC Profile. Another part of it will be developing US National extensions, mostly on IHE ITI profiles for how they are to be used (which options and vocabulary are required, for example), and a last part of it will be an implementation guide which pulls it all together, that to be developed in IHE USA.

One profile didn't make it through because the author wasn't there to defend it at all. Other work includes cleaning up some long-standing problems with a missing transaction for "Share Content" in Content profiles, and doing further outreach in Nursing.




Thursday, November 13, 2014

Overdue...

As I said last week, I've got a lot going on.  This week I'm at IHE meetings and I'll update you tomorrow on what we did, but I need to take care of something else that's been overdue, also related to what PCC is doing at IHE last week.

Last cycle Patient Care Coordination accepted the Data Access Framework White Paper (DAF) as a work item, and we are proceeding with it further this year.  This couldn't have happened without the contributions of one person in particular.  He was assigned to this task as an ONC Contractor, and like many, had not been deeply involved in IHE before.  But he adapted well to the process, and with a bit of guidance on my part, developed a good deal of the content for the white paper on his own, incorporating into it feedback from the S&I Framework group on DAF.  That white paper was completed early, and went out for two rounds of public comment, and was finally published a couple of weeks ago.

IHE has a lot going on, and this particular white paper involved something like a dozen IHE profiles from two domains (PCC and IT Infrastructure), and quite a bit of complexity to address the various needs for interoperability within, between and across organizations.  Our intrepid author was able to dig into the details of those profiles, and understand a new set of processes for him, and even help us invent new processes in PCC to address the development of the framework.

He'll be joining us again this year to help move the Data Access Framework as a profile, a set of national extensions, and an Implementation Guide (in IHE USA) that will help set forth the standards for interoperability we could be seeing in the near future in this country, and also to explain the IHE framework that has been used internationally for Information exchange.  Without further ado, let me thank the next recipient of the Ad Hoc Harley:


This certifies that  
Nagesh (Dragon) Bashyam of Drager Consulting 


Has hereby been recognized for his contributions to IHE and to Interoperability in the US

Thanks again Dragon, and I look forward to working with you again this year!


Thursday, November 6, 2014

Small talk and small things

November is a packed month:


  • I'm in Saudi this week, teaching people how to teach others what we have been doing for the past two years.
  • Next week is the IHE Technical Face-To-Face Meeting
  • Following that, I'll be headed to AMIA for my first time (as a Student)
  • I have a term paper due shortly.
  • Boxes still have to be unpacked, and I need to remove leaves from more than an acre of property.
My move is complete, and we are quite happy with it (when I'm there).  School is going fairly well. I've got two courses this semester, Scientific Writing, which I love, and Introduction to Biostatistics, which I'm also enjoying.  So far, both classes have been pretty easy for me, although I seem to want to make my writing class harder than it needs to be.  The same is probably true for by Biostatistics class.  But I have allocated the time for these classes, so I'm pushing myself to learn as much as possible in them, even if that goes beyond the curriculum set.

One of my current challenges is finding a doctor for my family in my new home town.  I have some criteria they have to meet:
  1. They absolutely must have a patient portal.
  2. The should have an office within 15 minutes of the house.
  3. They probably should be in my home state (Massachusetts), even though I'm two minutes from Woonsocket, Rhode Island.  The rationale for this is that the hospitals that I would want to go to (or have a family member in) if need be are both in Massachusetts, and that makes things a lot simpler.
  4. What I read about them online should be positive.
  5. If possible, I'd like them to be in a physician group large enough to include the variety of specialties that we've used in the past, including pediatrics, orthopedics, gastroenterology and ob/gyn.  In addition, with my mother living with us part of the year, I'd also like them to have someone in the practice that specializes in gerontology.
The biggest challenge has been finding a physician who meets this criteria and who is taking new patients.  So far, I've been striking out.  Technology doesn't help much for a patient in this situation.  My health insurer's information is insufficient.  They have little about the availability of a patient portal, focusing only on Physicians who work with their own Health IT product, and not reporting about portals supported by anyone else, and they say nothing about whether or not the physician is taking new patients.  And taking new patients is a dubious term when at least two physicians who are "taking new patients" don't have an appointment for more than four months out.  

The last time I changed physicians was with my last move, and it was easy.  I picked up the phone and called one, and they made an appointment for me.  But back then, I lived a heck of a lot closer to Boston, a major city with a serious medical industry in it. Now I am learning what it means to be living in a rural area, near smaller cities, and being stuck with the choices that many are stuck with.  I've also set a much higher bar this time than I had the last time.  Fortunately, I can probably go another three months before I need to have a new physician in place.

This is definitely a first world problem, and it gives me a new found understanding of what a physician shortage might actually look like.  Frankly, for me and most of my family, and our health issues, we don't much need a physician.  I've been thrilled with the care that my children get from their NP, and would be just as happy with an NP or PA for most of my ailments.  By the time it gets serious, I would need to see a specialist in most cases, and it's been pretty obvious even to me what kind of specialist I need.

There are a lot of big problems in healthcare.  This is a small one.  An annoyance.  But I wonder why I have to put up with it, and the many other small annoyances that come with our healthcare system in this country.  We tend to focus on the big things in Healthcare IT, but what if we paid attention to the myriad of small things somewhere?  What would be the economic impact of that?  For most of my life, the cost of those small annoyances probably adds up to a significant amount in terms of my time and money.  Telemedicine just became an option for me, and so I'm thinking about exploring the possibility further.  

And I'll also be thinking a good bit about how Health IT could be addressing those small problems for patients as well.

   Keith

Wednesday, October 29, 2014

Contained FHIR Resources

Currently under discussion in the FHIR community is what to do with contained resources, and how they could be searched (or not).  I argue that they should be able to be searched, and that FHIR should specify how they can be returned in a standard way, but also that NOT every FHIR conforming system need be able to search for contained resources.  At present, to retrieve any type of contained resource in FHIR, you must perform a query that will return its container, and you cannot directly query the resource type of that resource.  You can chain a query into the resource type, but you have to know then, the association between the container and the contained resource.

But not every system will know that, and it may not very well have ever been considered by the system designer. In analytics, the analytic engines often pick up some pretty strange associations in the data that they process. They completely ignore any notion of what you or I would consider to be elegant information system design.  Even so, having found an association through analytics, now you want to be able to do something based on it.  You might use the presence of a particular fact to drive some sort of decision support, perhaps a dashboard, or something else.  So, you need to be able to get to instances of that fact without necessarily knowing the association.

"Wait!" You argue, "of course the analytics system knows the associations too."  And so it does.  For this design.  But the association discovered could be an important trigger that works with other systems that work with similar, but not identical data.  You find these sorts of associations published all the time in the medical literature: Presence of X leads to Y.  So even the analysis may be from somewhere else.  And you don't care about the container.  You care about finding all the instances of resource X so that you can prevent Y, or treat Y, or even simply reward the behavior associated with X and its related resources.  You might want to count all the Xs, or inspect them further to see if this case qualifies for some sort of intervention, or do something else with them.  What you need to do is not particularly important, just that you need to do something with these things.  So, if you cannot find a particular X, then you have data locked away that isn't all that useful.

Let's look at the mechanics of how this might be implemented:

Using an analogy, lets say you have a system representing people, drivers, cars, registrations, drivers, licenses, and a registration authority and a licensing authority.  Each could be represented as a separate resource and might have a separate identity. And a road trip resource might have a destination, and be associated with driver, a car and the people who are its passengers.

But what do you do about the hitchhiker that you might need to keep track of for the road trip, but don't much care about later?  In FHIR, you could create the hitchhiker as a contained passenger resource associated with the road trip.  After all, outside of the context of the road trip, he doesn't much matter, but he should be listed as part of the resources associated with the road trip.

Now, as resources go, any person resource can be searched, and you can locate any person who has been on a road trip from Chicago to Milwaukee.  Or can you?  Actually you cannot.  Because if John picks up a hitchhiker (Keith) for a road trip from Chicago to Milwaukee, and decides he doesn't care to track Keith as a person, he could just contain Keith as a person resource in the road trip resource using the passenger attribute of the road trip resource.

So far, so good.  But now look at what happens when John goes to do some queries about how his car is being used.  The way that FHIR works today, we would be able find all the drivers, all the road trips associated with the car registered in his name, but what he cannot find is all the passengers who have been in his car.  That's fine, you say, we didn't care about that passenger enough to make it a full blow resource anyway.  And there is some benefit here, because you don't have to return that contained passenger as a resource.

BUT: What happens when you query for road trips?  The query specification says that you are permitted to support chaining of queries across associations.  So John could arguably query for a road trip where Keith was listed as a passenger.  But he could not query for passengers named Keith who have been on road trips with him and get that one where Keith was listed as a contained resource.  So even though the contained resource couldn't be returned, it still needs to be indexed so that the chained search works right.

Implicitly, you can view a containment as a particular kind of association (an aggregation).  The container had the contained resource embedded within it.  And the contained resource has this implicit association with one and only one container.  So what if we said that "_container" acted as if it was an attribute on the Any resource that resolved to the resource that held a contained resource.  If we did that, we could resolve a lot of challenges with search on contained resources.

If you wanted to search for resources that were only contained, you could do that by ensuring that _container was valued.  If you wanted to search for resources that were not contained, you could do that by ensuring _container was not valued.  If you wanted to search for resources that were contained by a resource of a particular type, you'd use _container:ResourceType, just as you would for other associations.

The mechanics of how this would work are pretty clear, and for those use cases for when you want to access "contained" resources, now you have a way to specify that they be present in the search results.  For a contained resource, you could ask to _include resources that appear along the _container association.  If I lost you, let me put it this way.  When John goes to search for people who have been on road trips in his car, he can say GET [base]/Person?_container:RoadTrip&_include=Person._container and he would get a bunch of Person resources, and where they were contained, he would get their containers (which would happen to include those Person resources)*.

Now, an analytics system that simply wants to keep track of what Keith is doing really doesn't care whether the activity is RoadTrip, or Sleeping.  It just wants to find Keith and see what he is up to.  It doesn't care about all the associations, it just needs to report to Keith's wife what he is doing.  Now it can do so without any prior knowledge about how John is keeping track of what he does with Keith.

   -- Keith

* Looking at this a bit more deeply, I can see that GET [base]/Person?_container:RoadTrip is pretty useless without the _include=Person._container.  I'm not sure where to go with that.  We could determine that use of _container required _include, we could make that automatic, or we could come up with something else.  For now, I'm not really worried about it, since it doesn't much matter for the immediate discussion.