Many thanks to Greg Meyer, distinguished engineer at Cerner (and 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:
- Topic 1: Has MU achieved interoperability?
- Topic 2: Should public APIs be required?
- Topic 3: Should ONC mandate architecture?
- Topic 4: How to mitigate barriers?
- Topic 5: Common data-level API?
I'll be! On workflow aspects … https://t.co/Vz6XJMPDkO RT : Will you be blogging on JASON report?
— Charles Webster MD ()
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).
Thru JASON Robust Health Data Infrastructure report twice: workflow tech angles > complexity, state, control, code volume, cost, privacy, UX
— Charles Webster MD ()
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.)
. sorry. You. Can't. Mandate. Interop. No. More. Than. You. Can. Mandate. Usability. JASON holds up OSI as example. It failed.
— Charles Webster MD ()
Then there’s my actual blog post about the JASON Report.
My new blog post > Out Of The Tar Pit: My Comments on A Robust Health Data Infrastructure JASON report
— Charles Webster MD ()
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:
. in other words JASON Report is a symptom not a solution: Out Of The Health IT Tar Pit
— Charles Webster MD ()
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.
T1: API mandates could result in unusable programming interfaces as functionality mandates resulted n unusable user interfaces
— Charles Webster MD ()
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 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!
. my own comments on JASON report it really is all about workflow, API necessary but not sufficient
— Charles Webster MD ()
. very kind of you 4 the RT Frankly, don't see any way to build the JASON interop architecture w/o workflow tech: maybe catalytic!
— Charles Webster MD ()
. Excellent idea. IMO need JASON arch to combine modular EHR components also see
— Charles Webster MD ()
Participation in reinforced my belief tech is essential 2 realizing JASON report architecture
— Charles Webster MD ()
. kind of you 2 mention me! I discuss "software complexity" re JASON report in a blog post
— Charles Webster MD ()
. slide 19 "JASON focused on only documentation & storage of clinical notes & data & ignored … workflow orchestration" 1/2
— Charles Webster MD ()
Interoperability: supply & demand blames workflow on non-IT issues, IMO lack of workflow tech!
— Charles Webster MD ()
. PCAST & JASON reports implicate workflow (my blog posts): PCAST JASON
— Charles Webster MD ()