Search Results for 'interoperability'

The Real Impediment to Interoperability

Medical device interoperability is one of my favorite subjects. With the meteoric rise of  IoT, there’s more and more discussion like this: Why we badly need standardization to advance IoT.

The question for me has always been: Why is standardizing communications so hard to achieve?  Healthcare providers, payors, EMR vendors, etc. have their own incentives and priorities with respect to interoperability.  The following is based on my experiences as a medical device developer and has many similarities to the IoT world.  As such, these observations are probably not applicable to many parts of the healthcare domain.

The Standard API

Let’s use a simple home appliance scenario to illustrate why interoperability is so important. Let’s say you have a mobile application that wants to be able to control your dishwasher. It may want to start/stop operation, show wash status, or notify you when a wash is complete.  An App without and with interoperability are shown here:


  • Without a standard API: The application has to write custom code for each dishwasher vendor. This is a significant burden for the App developer and prevents its use by a wider customer base.
  • With a standard API: New dishwasher models that implement the “dishWasher API” will just work without having to change the application (ideally anyway).  At the very least, integration of a new model is much easier.

Having a standard API that every App (and as importantly, other devices) can use to interoperate is critical for IoT (appliances and medical devices) growth. Besides all of the obvious benefits, in the healthcare industry the stakes are even higher (from Center for Medical Interoperability — Need for Change):

It will improve the safety and quality of care, enable innovation, remove risk and cost from the system and increase patient engagement.

The other important thing to note is that the API communication shown above requires full Semantic interoperability. This is the most rigorous type of interoperability because the App must understand the full meaning of the data in order to function properly. E.g., knowing that a temperature is in ºF as opposed to ºC has significant consequences.

Let me also point out that even though semantic interoperability is not easy, the barriers to achieving it are generally not technical. There may be points of contention on protocols, units of measure, API signatures, and functional requirements, etc., but when you’re working within a specific discipline these can usually be worked out.  Non-healthcare industries (telecom, banking, etc.) have proven it can be done.

Cost of Standards

There are a number of adoption hurdles for using standards (e.g. HL7, FHIR, etc.). The cost of implementing and maintaining compliance with a standard are non-trivial.

  • The additional development and testing overhead required. On the development side, these interfaces are many times not ideal for internal communication and can have a performance impact.
  • Some standards have a certification process (e.g. Continua Certification Process) that require rigorous testing and documentation to achieve.
  • If you have a data element that the standard does not currently cover, you may be faced with having to deal with the standard’s approval process which can take a significant amount of time. For example, see the FHIR Change Request Tracking System which currently has thousands of entries. Again, this is not a technical issue. Having to deal with bureaucracy is just part of the overhead of conforming to a standard.

Company Motivations

Now let’s try to understand what’s important to a company that’s trying to develop and market a product:

  1. Product differentiation. Provide vendor-unique features (a “niche”) that are not available from competitors.
  2. Time to market. Being there first is critical for brand recognition and attracting customers.
  3. One-stop shop (multi-product companies). “If you use our product family your experience will be seamless!”

The last item is particularly important. Following the appliance theme:

This strategy is of course how Apple became the largest company in the world. In most industries, the big companies have the largest market share. This “walled garden” approach is the most natural way to lock out both large and small competitors.

The First Hint of Problems

Notice that the cost of interoperability can affect all three of the market goals a company is trying to achieve. Standards are:

  1. A “me too” feature.
  2. They take time to implement.
  3. They punch holes in the desirable closed platform.

The actual impact depends on a lot of factors, but it can be significant.

The Real Impediment

But the real elephant in the room is this: Return on Investment:

The ROI on interoperability is inherently very low and often negative (Gain < Cost). This is because:

  1. As noted above, conforming to an external standard has a significant cost associated with it.
  2. Lack of demand. Interoperability is not something a customer is willing to pay extra for (zero Gain).

I think companies really do care about patient safety, quality of care, and healthcare cost reduction. This is what motivates their business and drives innovation. The reality is that ROI is also a factor in every product decision.

Side note: If conforming to a standard was mandated as a regulatory requirement, then the ROI becomes moot and the expense would just be part of the cost of doing business.

I’m sure that interoperability is on every company’s feature backlog, but it’s not likely to become a primary actionable priority over all of the other higher ROI functionality. Those other features also contribute to improving healthcare, but the bottom line is hard to ignore.

Contributing resources and putting a logo on a standards organization’s sponsor website is not the same thing as actually implementing and maintaining real interoperability in a product.

Apologies for the cynicism. It’s just frustrating that nothing has really changed after all these years. Interoperability: Arrested Progress is close to four years old, and same old, same old (insanity) still prevails.

I think the reasons outlined here are a plausible explanation of why this is so. We’re all still waiting for that game-changer.

Fast Healthcare Interoperability Resources (FHIR)

fhir-logoThe HL7 FHIR (pronounced “fire”) standard has been under development for a while. It became a Draft Standard for Trial Use (see DSTU Considerations) in Jan 2014. The recent announcement of the vendor collaboration Argonaut Project has fueled some “interoperability excitement”™.

The best technical overview I’ve read is this whitepaper: The HL7 Games Catching FHIR. In particular, it does a good job of comparing FHIR with HL7 v3. Summay:

HL7’s FHIR™ standard has learned from the mistakes of HL7 v3, and is surprisingly delightful.


FDA Recognition of Medical Device Standards for Interoperability

This is a follow-up to Interoperability: Arrested Progress.

The FDA has recognized voluntary interoperability standards for medical devices: Improving Patient Care by Making Sure Devices Work Well Together.

The FDA and HHS has (my highlight):

published a list of recognized standards for interoperability intended to assist manufacturers who elect to declare conformity with consensus standards to meet certain requirements for medical devices.

The standards are searchable here: Recognized Consensus Standards. The Software/Informatics area currently lists 54 items.

Some consider this a “landmark announcement” (see here) but “voluntary” and “elect to declare” just seem like more of #1 (same old, same old) to me.

UPDATE (9/4/2013): More here: FDA Updates List of Recognized Standards, Confusion Ensues

Interoperability: Arrested Progress

When it comes to the state of interoperability in the medical device industry there couldn’t be a better metaphor than Arrested Development*.  A dysfunctional family made up of eccentric well-meaning personalities each doing their own thing, oblivious to each other and the rest of the world.

Healthcare Un-Interoperability has long been one of my favorite subjects. Let’s review where things are these days.

The article Health IT Interoperability: How Far Along Are We? provides a nice summary of the current state of HIT interoperability. This is particularly important because:

hospitals using basic EHR systems tripled from 12.2 percent in 2009 to 44.4 percent in 2012

For better or worse, it’s the monetary incentives of the Affordable Care Act that push doctors to electronic medical records and is the primary reason for the accelerated rate of EHR adoption. The goal of having more electronic health records is to improve the quality of patient care. Reduction of medication-related errors is a great example: Lack of Interoperability has Ownership for Medication ErrorsThe rapid uptake of these systems can also present problems. For example, in Emergency Departments: EHR systems pose serious concerns, report says.

Nevertheless, it’s clear that electronic medical records is the future in healthcare data management. The down-side of this growth from an interoperability point of view is that there are that many more systems out there that don’t talk to each other!

Initiatives like CommonWell and Healtheway are moving in the right direction but are just getting off the ground. Also, these types of efforts are often far removed from the medical device industry and have little impact on software development and interface decision making.

Let’s step back and look at the HIMSS definition of Interoperability:

  1. Foundational: Data exchange with no interpretation.
  2. Structural:  Allows identification of data structure (fields) but not necessarily data content.
  3. Semantic: Data structuring and codification (interpretation) of the data.

For all practical purposes only #3 (semantic) has value when in comes to the exchange of data with a medical device. As noted in Interoperability: Not a non-issue:

Semantic interoperability continues to be a major challenge and, if not addressed, will have a serious impact on the quality of care.

The same point is made here: Interoperability vs Health Information Exchange: Setting the Record Straight.  Just because you can send it (exchange) doesn’t mean the recipient can understand it (interoperability).

One area that is always part of this discussion are standards. It’s unfortunate that due to technical and (mostly) non-technical reasons the following is often true:


Even more disheartening is when you read that a standards-based organization (OpenStack in this case) can’t necessarily make interoperability magically happen:

… success depends upon a single large vendor assuming leadership. Interoperability will follow, but it won’t be designed by committee.

The distress of a well-focused cloud computing API involving a hand-full of vendors makes the outlook for HIT interoperability look particularly bleak.  To make matters worse, the use of OSS in FDA regulated products face additional challenges that are not even seen in most other industries (see Open Source Medical Device Connectivity)

This is all good news for businesses that provide products and services that fill the connectivity gap. Companies like CapsuleiSirona, and Nuvon are many times the only effective way to provide an integration solution to a large number of customers.

I should note that there are some bright spots in the interoperability landscape. For example, the Continua Health Alliance has successfully pulled together over 200 companies to create a vision for inter-operable personal connected health solutions.  Also, the West Health Institute is building standardized communication protocols into their embedded software for medical devices. These and numerous other successes provide hope, but are still just the tip of a very large iceberg.

Dr. Julian Goldman sums up the current situation in Medical Device Interoperability: A ‘Wicked Problem’ of Our Time:

Our years of work on medical device interoperability have led us to see the barriers (including technical, business, liability, standards, and regulatory factors) as “wicked problems,” in which there is little agreement about “the problem,” no agreement on a solution, and problem solving is complex because of external constraints.

Others (Is HIT interoperability in the nature of healthcare?) see the proprietary business model of major HIT companies as the primary culprit.

So what are some possible scenarios for the future?

  1. Same old, same old.  This is essentially Einstein’s definition of insanity: doing the same thing over and over again and expecting different results.
  2. Federally enforced standards and regulations.  Dr. Goldman’s suggestion to require manufacturers to fully disclosure their communication interfaces?   Given the current anti-regulatory environment and budget restrictions, this seems unlikely to happen.
  3. A hegemon, like OpenStack above?  The healthcare industry is too diverse and complex. There is no single player that could even begin to tip the scales.

At least for the foreseeable future it looks like #1 (insanity) is going to prevail. If I’m missing some huge game-changer, please let me know.

In the mean time, let another episode begin!

*No deep meaning here. Certainly not like Arrested Criticism.  I’m just comparing the medical device industry to a bunch of fictional crazy people.

Standards & Interoperability (S&I) Framework

There’s a new standards organization in town: Standards & Interoperability (S&I) Framework.

The objective of the S&I framework is to create a robust, repeatable process based on federal best practices that will enable ONC to execute on initiatives that will help improve interoperability and adoption of standards and health information technology.

The question is where is this new effort going to squeeze itself into the bigger picture of Healthcare Un-Interoperability?

It’s been close to four years and nothing has really changed.

A lot of effort was put into HITSP, but “the S&I Framework is not envisioned to be the “sequel” to HITSP, but a new evolution in standards harmonization.”  Your have to wonder how YASC (Yet Another Standards Committee) initiated by the government is going to add clarity to an already confused standards landscape — again.

Technically, you have to love a standard that fully embraces acronyms:

  • Computational Independent Model (MDA-CIM)
  • Platform Independent Model (PIM)
  • Platform Specific Model (PSM)
  • Information Exchange Package Documentation (IEPD)
  • National Information Exchange Model (NIEM)
  • NIEM Health IEPD

Together, the CIM, PIM and PSM will be compiled to generate the NIEM Health IEPD.

Interoperability is a Big Word!

There was a statement in one of the HIStalk Readers Write 5/10/10 articles in that I haven’t been able to get out of my mind. In Digging for Gold in your HIT Applications, Ron Olsen writes:

One of the most over-used buzz words in healthcare IT is “interoperability,” a is really a big word that self-important people use to describe data transfer.

OMG, I’ve been using that word for a long time…

All joking aside, for the most part Mr Olsen’s advise to get more out of existing IT tools is a reasonable suggestion. Unfortunately, interoperability means a lot more than just “data transfer” (see Healthcare IT Interoperability Defined), and is where the advise breaks down.

Scripting tools can manipulate those files, turning them into almost any format imaginable. With the correct format, data can be transferred to disparate systems, individually or concurrently, via a data stream.

The fundamental flaw in this statement is the oversimplification (sorry, another big word) of the problem. Simple scripts are good for simple tasks. Communicating medical data reliably and securely between disparate systems is not a simple task.

I would also encourage all HIT professionals to fully understand the tools at their disposal in order to improve the efficiency and effectiveness of their organizations.  There may be a few nuggets, I’m not so sure that there will be a whole lot of gold to be found when it comes to  interoperability.

Interoperability: Google Protocol Buffers vs. XML

Google recently open sourced Protocol Buffers: Google’s Data Interchange Format (documentation, code download). What are Protocol Buffers?

Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler.

The documentation is complete and worth a quick read through. A complete analysis of PB vs. XML can be found here:  So You Say You Want to Kill XML…..

As discussed, one of the biggest drawbacks for us .NET developers is that there is no support for the  .NET platform. That aside, all of the issues examined are at the crux of why interoperability is so difficult. Here are some key points from the Neward post:

  1. The advantage to the XML approach, of course, is that it provides a degree of flexibility; the advantage of the Protocol Buffer approach is that the code to produce and consume the elements can be much simpler, and therefore, faster.
  2. The Protocol Buffer scheme assumes working with a stream-based (which usually means file-based) storage style for when Protocol Buffers are used as a storage mechanism. … This gets us into the long and involved discussion around object databases.
  3. Anything that relies on a shared definition file that is used for code-generation purposes, what I often call The Myth of the One True Schema. Assuming a developer creates a working .proto/.idl/.wsdl definition, and two companies agree on it, what happens when one side wants to evolve or change that definition? Who gets to decide the evolutionary progress of that file?

Anyone that has considered using a “standard” has had to grapple with these types of issues. All standards gain their generality by having to trade-off for something (speed, size, etc.). This is why most developers choose to build proprietary systems that meet their specific internal needs. For internal purposes, there’s generally not a need to compromise. PB is a good example of this.

This also seems to be true in the medical device industry.  Within our product architectures we build components to best meet our customer requirements without regard for the outside world. Interfacing with others (interoperability) is generally a completely separate task, if not a product unto itself.

Interoperability is about creating standards which means having to compromise and make trade-offs.  It would be nice if Healthcare interoperability could be just a technical discussion like the PB vs. XML debate. This would allow better integration of standards directly into products so that there would be less of the current split-personality (internal vs. external  needs) development mentality.

Another thing I noticed about the PB announcement — how quickly it was held up to XML as a competing standard. With Google’s clout, simply giving it away creates a de facto standard. Within the medical connectivity world though, there is no Google.

I’ve talked about this before, but I’m going to say it again anyway. From my medical device perspective, with so many confusing standards and competing implementations the decision on what to use ends up not being based on technical issues at all. It’s all about picking the right N partners for your market of interest, which translates into N (or more) interface implementations. This isn’t just wasteful, it’s also wrong. Unfortunately, I don’t see a solution to this situation coming in the near future.

Microsoft Interoperability Principles

As with many Microsoft press offerings, Microsoft Makes Strategic Changes in Technology and Business Practices to Expand Interoperability has created quite a stir. When you think about interoperability, Microsoft isn’t the first thing that pops into your head.

The talk in the open source community regarding this announcement is understandably negative (read through the Slashdot commentary). According to the Interoperability Principles, Microsoft is opening up their protocols and APIs and embracing industry standards. That’s good. But look at the Open Source Compatibility (I.5, my highlight):

Microsoft will covenant not to sue open source developers for development and non-commercial distribution of implementations of these Open Protocols.

This plus the licensing of patented software “at low royalty rates” have made the Microsoft naysayers say “nay” (yet again) and that this is all just another marketing ploy.

Maybe so. This philosophical change is not meant to make Microsoft a FOSS (free open source software) company. Their goal is still to make money, which is exactly what their shareholders demand.

I think providing an improved forum for open source interoperability, and presumably better support moving forward, is a good thing. As long as Microsoft continues to own the desktop, the easier it is to inter-operate with their “high-volume products”, the better. This will certainly be true for the healthcare industries, which like most others, depend on Microsoft products.

UPDATE (3/4/08):

Check out Microsoft’s Interoperability Principles and IE8 (and here). This is good news for the Web development community. Doing the right thing must be good for business.

Healthcare IT Interoperability Defined

I guess I’ve been obsessed with interoperability (or lack thereof) lately.



Dictionary interoperability 1,0,0,0;interoperability=555039

Main Entry: in·ter·op·er·a·bil·i·ty Listen to the pronunciation of interoperability
Pronunciation: \ˌin-tər-ˌä-p(ə-)rə-ˈbi-lə-tē\
Function: noun
Date: 1977
: ability of a system (as a weapons system) to work with or use the parts or equipment of another system


The ability of two or more systems or components to exchange information and to use the information that has been exchanged.

From the National Alliance for Health Information Technology (NAHIT) definition:

In healthcare, interoperability is the ability of different information technology systems and software applications to communicate, to exchange data accurately, effectively, and consistently, and to use the information that has been exchanged.

The four NAHIT levels are:

  1. Non-electronic data. Examples include paper, mail, and phone call.
  2. Machine transportable data. Examples include fax, email, and un-indexed documents.
  3. Machine organizable data (structured messages, unstructured content). Examples include HL7 messages and indexed (labeled) documents, images, and objects.
  4. Machine interpretable data (structured messages, standardized content). Examples include the automated transfer from an external lab of coded results into a provider’s EHR. Data can be transmitted (or accessed without transmission) by HIT systems without need for further semantic interpretation or translation.

From IEEE 1073 (Point of Care Medical Device Communications) and IEEE-USA Interoperability for the National Health Information Network (NHIN) — original definitions are from IEEE Standard Computer Dictionary: Compilation of IEEE Standard Computer Glossaries, IEEE, 1990:

Functional: The capability to reliably exchange information without error.

  • Shared architectures (conceptual design)
  • Shared methods (processes and procedures)
  • Shared frameworks (goals and strategies)

An architecture is the conceptual design of the system. Systems inter-operate if their architectures are similar enough that functions that execute on one system execute identically (or nearly identically) on another system.

Shared methods refer to the processes and procedures that a system performs. To ensure interoperability, these operations must be capable of being performed identically at any point in the network, regardless of implementation.

A shared framework is a shared set of goals and strategies. Stakeholders must agree on a shared set of goals and approaches to implementation.

Semantic: The ability to interpret, and, therefore, to make effective use of the information so exchanged.

  • Shared data types (types of data exchanged)
  • Shared terminologies (common vocabulary)
  • Shared codings (standard encodings)

Shared data types refer to the types of data exchanged by systems. Interoperability requires that systems share data types on many different levels, including messaging formats (e.g. XML, ASCII), and programming languages (e.g. integer, string).

Shared terminologies refer to establishing a common vocabulary for the interchange of information. Standardized terminology is a critical requirement for healthcare applications to ensure accurate diagnosis and treatment, and has led to developing standards such as SNOMED-CT.

Shared codings refer to establishing standard encodings to be shared among systems. Codings refer not only to encoding software functions, but also to encoding medical diagnoses and procedures for claims processing purposes, research, and statistics gathering (e.g. ICD9/10, CPT).

At Healthcare Informatics Technology Standards Panel (HITSP) I came across a maturity model of interoperability types from the Mayo Clinic. Even though this table is taken out of context, the Technical-Semantic-Process model shows yet another view of interoperability.

Mayo Clinic Interop Types

There are also a number of Models of Interoperability that describe abstract interoperability. For example, a finer grained layered model is called Conceptual Interoperability. This model encompasses the previous healthcare IT definitions:

Levels of Conceptual Interoperability Model (LCIM)

Besides these definitions there are many articles (and books), especially as it relates to healthcare and EMR/EHR, that espouse the benefits of interoperability.

From a broader software industry point of view you can imagine the number and variety of issues that a company like Microsoft has to deal with. They claim Interoperability by Design. Of course Microsoft has gotten a lot of attention about their push to get Open Office XML (OOXML) approved as a standard by EMCA — some quite negative:


Even though I don’t believe the healthcare industry has the equivalent of ‘Da Bill’ (or maybe it does?), this points out one of the necessary components for the implementation of interoperability: standards.

I was on an ASTM standards committee a number of years ago (E1467-94, now superseded) , so I have some understanding of how difficult it is to get consensus on these types of issues. The process is long (years) and can sometimes be contentious. Even after a standard has been balloted and approved, there’s no guarantee that it will be widely adopted.


In my previous post on this subject I pointed out the plethora of healthcare IT standards and their confusing inter-relationships. The definitions of interoperability can be just as confusing. Each of the different models has a slightly different way of looking at the same thing. This is certainly one reason why there are so many overlapping standards.


Interoperability in healthcare IT is multi-faceted and complex. This makes it difficult to agree upon exactly what it is (the definition) and even harder to develop the standards on which to base implementations.

Healthcare Un-Interoperability

Or maybe that should be “non-interoperability”? Anyway, I have ranted in the past about the state of the EMR industry. I thought I’d add a little meat to the bone so you could better appreciate the hurdles facing device interoperability in healthcare today.

Here’s a list of the standards and organizations that make up the many components of health information systems. I’m sure that I’ve missed a few, but these are the major ones:

Medical Coding

  • SNOMED (Standardized Nomenclature for Medicine)
  • LOINC (Logical Observation Identifiers Names and Codes)
  • ICD9/10 (The International Classification of Diseases)
  • CPT (Current Procedural Terminology)


  • FDA CDRH (Food and Drug Administration Center for Devices and Radiological Health)
  • NHIH (National Health Information Network)
  • HIMSS (Healthcare Information and Management Systems Society)
  • CCHIT (Certification Commission for Healthcare Information Technology)
  • PHIN (Public Health Information Network)
  • VISTA (Veterans Health Information Systems and Technology Architecture)


  • HL7 (Health Level Seven: v2 and v3)
  • HIPAA (The Health Insurance Portability and Accountability Act of 1996)
  • 21 CFR Part 11 (FDA/HHS Electronic Records and Signatures)
  • IEEE-1073 (Point of Care Medical Device Communications)
  • IHE (Integrating the Healthcare Enterprise)
  • DICOM (Digital Imaging and Communications in Medicine)
  • HITSP (Healthcare Information Technology Standards Panel)
  • EHRVA (HIMSS Electronic Health Record Vendors’ Association)
  • NCPDP (National Council for Prescription Drug Programs)
  • openEHR (International Foundation that promotes Electronic Health Records)
  • CEN (European Committee for Standardization)
  • CCR (Continuity of Care Record)
  • ANSI X12 (Electronic Data Interchange)
  • MLLP (Minimal Lower Layer Protocol)
  • ebXML (Electronic Business using eXtensible Markup Language)

This list does not include any of the underlying transport or security protocols. They are either data formatting (many based on XML) or specialized messaging systems.

The diagram below gives an overview of how many of these standards are related (from an IEEE-USA purchased e-book — copying granted for non-commercial purposes):

Taxonomy of Core Standards for the NHIN

I don’t know about you, but trying to make sense of all these standards and protocols is not an easy task. A discussion of next generation PHRs summarizes the situation well:

… not only is information scattered, but standards for defining and sharing the data are still evolving; where standards exist, many of them predate the Internet. Standards about how to define consistently the information (clinical standards) and to transmit and exchange the information (technical standards) are not yet formalized and agreed upon.

The point about predating the Internet is an important one. This particularly pertains to HL7 v2.x which still uses ASCII delimited messages for transmission over serial lines. For all you 21st century programmers that may have never seen one before, here’s what an HL7 v2.x message looks like:

|19670824|M|||123 West St.^^Denver^CO^80020^USAPV1||O
||Produces hives~Rash~Loss of appetite

HL7 v3 uses XML for it’s message format but it has not been widely adopted yet. A good history of HL7 v2 and v3, and an explanation of their differences, can be found here (pdf).

HL7 v2 is commonly used in hospitals to communicate between medical devices and EMR/HIS systems. Even though the communications framework is provided by HL7, new interfaces must still be negotiated, developed, and tested on a case-by-case basis.

Most of the large EMR companies provide HL7 interfaces, but many of the smaller ones do not. This is because hospitals are not their primary market so they don’t generally need device interfaces. These EMRs are essentially clinical document management, patient workflow, and billing systems. The only external data they may deal with are scanned paper documents that can be attached to a patients record. The likelihood that they would conform to any of the standards listed above is low.

I’m not sure things will improve much with the recent PHR offerings from Microsoft (HealthVault) and Google (Google Health — not yet launched) . Microsoft appears to be embracing some of these standards as discussed in Designing HealthVault’s Data Model, but there are a couple of telling comments:

Some of the data types we needed in order to support our partners’ applications where not readily available in the standards community.

Our types also allow each vendor to add “extensions” of their own making to item data – so to the extent that we are missing certain fields, they can be added – and the industry can rally around those extensions if it makes sense.

Microsoft says they are not the “domain experts”, so they’re leaving it to the industry to sort it all out. Great! This is probably the same attitude that got us to where we are today.

Hopefully you can now see why I’ve used the words “mess” and “chaos” to describe the current situation. The challenges facing interoperability in healthcare are immense.



Twitter Updates