ARCHITECTURE FOR INTEROPERABILITY

WE CAN SUPPORT YOUR IMMEDIATE GOALS WHILE MAKING SURE THAT YOUR INVESTMENT BRINGS YOU CLOSER TO A SCALABLE, EXTENSIBLE ARCHITECTURE THAT WILL MEET TOMORROW'S GOALS AS WELL.

We are always pleased when approached by a client who has a time horizon that extends beyond the next round of mandates and incentives. The Stage 1 criteria for certification of Meaningful Use of EHRs sets near term, minimum requirements. In contrast, implementers who do not see the larger framework out of which these criteria have been selected will  react to  each new set of criteria as de novo requirements without developing the framework within which interoperability is an intrinsic function.

We prepare our clients by working with them to develop an architecture for interoperability. We start with where the client is today, thoroughly review their requirements including the clinical and operational environment, and we work with them to develop an incremental path to achieve interoperability as a core function ensuring that future requirements are met with minimal disruption, data loss or expensive conversion projects.

The primary components of an HIT architecture for interoperability include:

  • Data Modeling: Rarely is it appropriate to re-structure an existing data store for standards-compliance, so facilities – private and public – have to adapt through development of a virtual layer or interface that can operate in a standards-based environment
  • Terminology: Wherever possible, we design for native adoption of standard terminology to minimize expensive and hard to maintain data mapping. Data mapping is a fact of life in most environments. We design data mapping for “safe mediation” to ensure accurate and safe interpretation. A comprehensive terminology architecture must address interface and reference terminologies, exchange requirements and terminology services.
  • Communication: We are fluent in and can design to all current exchange protocols including HL7 Version 2, Version 3, all flavors of XDS (XD*), web services and REST.
  • Component Management: Components, here, may include CDA Templates, instances data elements, versions of standards and implementation guides, etc. Often, these requirements lie outside the core function of enterprise systems.