In 2014, we’re faced with a similar issue as we specify query/retrieve standards to “pull” healthcare data from various sources for care coordination, care management, and population health.
At present, the industry has implemented several functional approaches to query/retrieve, each incorporating both open standards and proprietary implementations:
CommonWell
Epic Care Everywhere
Cerner Resonance
eClinicalWorks P2P and eHX
eHealth Exchange/Healtheway
Surescripts
Regional HIEs such as the MassHIWay
Differing standards and architectures are used based on workflow, use cases, and policy constraints. Some are synchronous and some are asynchronous. It's too early in the process to declare any of the enabling open standards as either winners or losers. Rather than regulate an answer (i.e. XCA must be used, FHIR must be used), it is better at this point to embrace functional criteria for query/retrieve capabilities that will enable an ecosystem to develop as the market evolves. Adoption will be our metric for success, and we'll be able to reduce optionality over time by evaluating implementation experience.
Interoperability in other industries, taking examples from Google, Amazon, Facebook, Apple, and Alibaba, is based entirely on RESTful, JSON/XML, and OAuth approaches for open APIs that enable and authorize data-level and document-level exchanges. We are in a transitional period between an older standards profile (IHE XCA) that is complex (particularly for today's agile, multi-platform environment)/does not support data-level open APIs and an emerging standard (FHIR resource definitions & profiles) which is based on currently prevailing architectural and design principles/does support both document- and data-level access. The dilemma is that this emerging standard requires some focused development attention before it's ready for prime time. Although healthcare is indeed a bit delayed in its adoption of information technology, its needs are quite similar to those of other industries, so it is not an edge case that requires a different approach. To help align healthcare with current technology trends, it is critical that we not lock ourselves into an older healthcare-specific standard -- else we will suffer the consequences of higher costs, longer development cycles, and less compatibility with current enterprise and consumer technologies. Based on everything we know about the work to date in HITSP, HITSC, S&I, SDOs, and HIEs, the best approach for the future seems to be:
Vocabulary - centralize all vocabulary resources for download/real time retrieval at the value-set level -- curated and provisioned by the NLM's Value Set Authority Center.
Content - both profile-constrained document and discrete data approaches should be supported. A constrained CCDA based on a small number of templates that limit vocabulary and metadata optionality and are focused on a small number of high value use cases is a reasonable document format for the next 5 years. An entry-level set of FHIR resource definitions and profiles can be developed in the next 12-24 months as an open API that supports both document-level access to static CCDAs and data-level access. That is a reasonable discrete data approach for the next 5 years that will serve high-value clinical use cases for the near-term but, more importantly, build a gateway to rich interoperability founded on JSON/XML approaches for the future.
Transport/Security - We should accept both SOAP/SAML and REST(HTTP)/OAuth 2.0 as reasonable approaches for the next 5 years -- though we anticipate a continuing and accelerating decline in support for SOAP/SAML, with a corresponding increase in adoption of HTTP/OAuth, across all IT environments.
Thus, we should allow multiple approaches to enable the marketplace for the next 2 years, while working to constrain CCDA and complete FHIR resource definitions and profile specifications. in 2017, we'll have enough experience with query/retrieve and adequate standards maturity to begin convergence to fewer standards in a way that still supports the older standards for those who don't want to "rip-and-replace" but also provides a pathway for those who would like to start building on newer standards to carry them further into the future.
We believe that incentives for cross-boundary sharing (e.g. MU incentives, as well as emerging market incentives) will work better to move the industry forward than forcing technical compliance to complex standards. We should focus on the outcome rather than the process.
Networks require considerable additional work beyond the implementation of particular standards. With this recommendation, we are encouraging the evolution of multiple robust networks that enable and facilitate query/retrieve, with the expectation that these networks will create appropriate bridging techniques to other networks, in response to incentives and market demands.
What about HIE governance?
HIE is still largely a highly heterogeneous and locally-dispersed regional activity based on local policies, technologies, and use cases. Forcing a single governance approach in the next 2 years will quash innovation, limit adoption, and negatively misalign incentives.
ONC should have a role in defining outcomes, but not prescribing standards yet, at this critical juncture where some are maturing and fading but the successors haven’t fully emerged yet. There are active communities effectively developing solutions. That includes SDOs, broad industry groups, and the actual networks created by CommonWell / HealtheWay / Surescripts. This is more than some kind of vague “invisible hand of the market”, there is real work happening with responsible players with whom ONC can collaborate.
The Affordable Care Act and new economic incentives are aligning payers, providers, and patients to share data. These economic incentives are more powerful than meaningful use regulation and should be allowed to shape the standards and governance of HIE for the next 2 years. In 2017, as the standards have matured, and the marketplace has made implementation choices, the notion of a single national standard for query/retrieve should be revisited.
0 komentar:
Posting Komentar