My 5 Answers to 5 JASON Report Questions: Sept. 26 #HITsm Tweetchat

Many thanks to Greg Meyer, distinguished engineer at Cerner (and @Greg_Meyer93 on Twitter), for moderating this week’s #HITsm tweetchat about the JASON Report.

Every Friday, from Noon to 1:00 EST as many as a hundred or so #HITsm (Health Information Technology Social Media) pundits, plus possibly thousands of lurkers, and tens of thousands of innocent bystanders experience #HITsm tweetchat. Sometimes I even write a #HITsm themed blog post (such as this one) and tweet links to specific paragraphs. Such is the case today for discussion of the JASON Report.

The first half of this blog post is background, which I encourage you to read. But you can also jump directly to the #HITsm topics and my answers:

I’ve already written about what I think of the JASON Report in a blog post titled Out Of The Health IT Tar Pit: My Comments on A Robust Health Data Infrastructure. I’ve tweeted about the JASON Report too. Of course, I tweet a lot about a lot period. Anyway, I’ve embedded some of those tweets below, thematically connected to one or more of each of the five #HITsm questions.

Here’s my initial reaction (before I wrote my incisive commentary).

Reactions to the JASON Report have been varied. From, “See, I told you so!” to muted defensiveness. My reaction was mixed too. On one hand I agree that Meaningful Use has not be particularly effective regarding to the goal of ubiquitous and seamless patient data interoperability. On the other hand, I’m not particularly impressed or a fan of more top-down mandated health IT architectures or initiatives. By the way, my reference to OSI, Open Systems Interconnection, in the following tweet? TCP/IP won that battle. (OSI: The Internet That Wasn’t: How TCP/IP eclipsed the Open Systems Interconnection standards to become the global protocol for computer networking and The “good guys,” led by Cerf, Kahn, Walden, and others defeated the governments, PTTs, and giant corporations by using well-engineered, open protocols — stuff that worked and was robust.)

Then there’s my actual blog post about the JASON Report.

From my post:

Out Of The Tar Pit is about why software is so difficult. Software is difficult because it is complex, by which the authors mean it is difficult to understand (not the more formal concept of computational complexity). They list reasons — state, control, and code volume — to which I will return.

Why did I think of Out Of The Tar Pit when I read the JASON report? Because software architectures are about managing, attempting to reduce by design, complexity, to get to more understandable and reliable software systems. Divide and conquer: if we can reduce a software system into understandable components, and understand their interactions, we can hope to understand the whole, and make it do what we wish more reliably.

So far, so good. The JASON-suggested software architecture for healthcare information exchange is a valiant effort. It’s only missing one key ingredient: process-aware information systems. Now, the architecture is, indeed, intended to be agnostic about what specific software platforms should be used to implement it. I, however, am not agnostic. I believe, without a doubt, that many of health IT’s problems regarding usability, interoperability, and cost, are due to not using technologies that have been prevalent in other industries for years, in some cases, even decades. These are the workflow technologies, including workflow management systems, business process management, and dynamic and case management systems.

Workflow tech is used by, embedded in, a wide variety of social, mobile, analytics and cloud platforms. From speech recognition and natural language processing systems to “big data” and machine learning workflows, executable process models are helping to manage software complexity, increase understandability and reliability. I will visit some of the boxes of this architecture in a later post: stovepipe legacy systems, UI apps, middleware apps, semantics and language translation, as well as privacy services. However, before I do so we need to review the major sources of software complexity the JASON architecture seeks to tame.

Out Of The Tar Pit blames software complexity on

  • state (data values)
  • control (order of execution) and
  • code volume (lines of text).

Out Of The Tar Pit suggests programmers think more declaratively about what the software does, not how it is accomplished. This would go a long way to reduce software complexity. In other words, if health IT could better manage software state, control, and code volume, this would go a long way toward accomplishing the same higher-level goal that motivates the JASON architecture.

The better health IT manages state, control, and code volume, the more it will reduce complexity and achieve goals motivating the JASON architecture. On all three points, workflow technology contributes.”

At this point I’ll relegate the rest of my tweets to the end of this post, except the following:

The JASON Report is not a solution. It is a symptom of health IT’s workflow-oblivious infrastructure, tools, and mindset. The solution is to attack workflow oblivity itself. In this regard, I hold this weekly #HITsm tweetchat in high regard! It’s half technical and half social. As long as I show up and respect shared conventions and etiquette (more-or-less) I get to blather on about workflow and workflow tech, and the very nice #HITsm folks let me. Sometimes they intentionally push my buttons, so to speak, since I’m predictably consistent when it comes to jumping on every possible workflow-related tweet or angle.

So, finally, this week’s #HITsm questions (and my answers):

Topic 1: Has MU “achieved meaning interoperability ‘in any practical sense’”? Does the report downplay progress since its research period? #HITsm

I’d like to reword this question: Has MU “achieved meaning interoperability ‘in any pragmatic sense’”? I’d argue that what has been missing from health IT interoperability initiatives, focusing on syntactic and semantic interoperability, is Pragmatic Interoperability. Even when syntactic and semantic interoperability are achieved, it’s not flexible or scalable. That requires the next level up, of pragmatic interoperability. And the best infrastructure and tools to achieve pragmatic interoperability is workflow technology, particularly BPM (Business Process Management) and related technologies. Check out my longer post on this: From Syntactic & Semantic To Pragmatic Interoperability In Healthcare.

Topic 2: Should public APIs become a requirement in MU3, & is MU an effective method to accelerate change? Is the approach too aggressive? #HITsm

I’ve already answered this question, during a previous #HITsm chat.

Design of great interfaces, computer-to-computer (APIs) or human-to-computer (usability) cannot be mandated. Rush them. Try to do too much. You’ll get crappy interfaces. Instead, encourage, raise consciousness, fund research, create and share reference implementations, hold contests, anything! Just. Don’t. Mandate. The combination of a long list of features and a hard deadline just causes misery, for programmers, for users, and, ultimately, for patients.

Topic 3: Should ONC mandate a detailed #HealthIt architecture or should they simply recommend “patterns” and leave impl details to vendors? #HITsm

See my previous answer to Topic 2.

Topic 4: What impact do factors (barriers?) such as legal/policy, jurisdiction, & biz models play on interop and how do we mitigate them? #HITsm

First, just as the US funded the creation of the Federal interstate highway system, we should have funded a means to securely transmit healthcare data, with a focus on both security AND cost. By keeping the cost low, new transportation companies came into existence. New health IT companies would have, and will, if we still proceed in this direction. However mandating the structure (syntax) and content (semantics) has the opposite effect. By analogy, it’d be like mandating what and who trucks and cars carry. In spite of belief these efforts reduce cost, it’s has had the effect of preventing entry of new and innovative companies into the health IT space.

Second: An emerging, model for government policy and support for technological innovation is how the Maker Movement is beginning to be recognized as a force for “re-industrialization” of America. From White House Maker Faires to seeding technology to schools to convening and facilitating routes and means for turning prototypes into products, the urge to create solutions to problems is universal human urge. Frankly, I’m not sure exactly how to operationalize this relative to interoperability, but we need to support TCP/IP approaches to health IT interoperability, not OSI approaches (see above). For more on this topic, see my National Health IT Week Thoughts: Let’s Replace “Meaningful Use” With “Meaningful Creation” or, Health IT, Join The Maker Movement!.

Topic 5: Is a new “common data-level API” needed for clinical research, or are current models sufficient? What’s the patient’s role? #HITsm

By all means! Just. Don’t. Mandate. It. If it’s any good, folks will use it. If not, it will deserve to fail in the market place of both ideas and products and services. The patient’s role? Well, if they’re really good at designing APIs (such an intersection is surely not null) encourage them to do so.

Again, many thanks to Greg Meyer, distinguished engineer at Cerner (and @Greg_Meyer93 on Twitter), for moderating this week’s #HITsm tweetchat about the JASON Report.

P.S. Here are the rest of those tweets I mentioned. Feel free to RT!

This entry was posted in healthcare-BPM. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

You can add images to your comment by clicking here.