“Nearly all existing EHR systems are built with an explicit domain model– a common approach in current EHR software development practice. This means that the hard coded medical domain knowledge in the system results in higher cost when new requirements in clinical documentation routines occur.” Weber-Jahnke, J. & Price, M. (2007).
One of the major limitations in regards to the current
generation of Healthcare IT capabilities is the relative lack of ability to
integrate multiple structured and unstructured data sources. Most if not all EHR/EMR
systems today are built utilizing a single relational database structure with
minimal consideration of how to manage data structures that do not easily fit
within the “record” itself. It occurred to us that the problem here is both
technical and derived partly from the metaphor chosen to build these solutions
around. The current metaphor; an “Electronic Record,” does not properly
approximate the traditional capability encompassed within the Medical Chart. A
more accurate context is the ability to exist as a continuous “Healthcare
Portfolio.” The Portfolio as a metaphor is a flexible and infinitely extensible
instrument. This instrument can hold or point to “n” records from “n” different
providers or systems. This instrument can also provide an information and
collaboration ‘portal’ interface for the patient, all associated caregivers and
administrative personnel.
The Portfolio metaphor can also be extended to the Group
level rather gracefully which also helps to serve as natural mechanism for
shielding certain types of privacy data per HIPAA regulations for group-level
analytics. This paradigm shift is founded upon the realization that a complex
architecture can be centrally managed “logically” yet manifested across a
federated environment. In other words, all elements of a patient’s portfolio do
not need to exist in one location; however the central management mechanism
requires access to the portfolio to be controlled to ensure data integrity and
to allow the portfolio to retrieve information from the appropriate data stores
and caches. This is referred to as “meta-information” and can be considered a
Semantic Layer that binds that federated environment into a logical integration.
The core architectural paradigm behind the next generation
of automated Healthcare solutions is likely to be data fusion. The reason for
this is simple – complexity. The key enabling mechanism within data fusion is reliance
on metadata or meta-information. Metadata has been managed historically within
individual system stacks. What that means is that the metadata was usually
stored within the same system or if in more complex configurations within the
system or component close to the primary user interface (and in the case of EMR
solutions, the Medical Chart UI). The problem with this for Healthcare is that
the community of Medical knowledge is expanding exponentially. Any attempt to centrally
manage all types of medical knowledge in one system’s metadata framework is
bound to fail. Part of the true strength of any such solution ought to be the
ability to accommodate information not originally anticipated.
The implications of this are important, as there is no
consistent method of coordinating metadata across multiple metadata sources
except through custom interface development or management in most of today’s EHRs.
As the scope of custom integration grows, interface management and integration
become mores difficult to manage. In other words, those architectures simply are
not scalable.
Copyright 2012 - Technovation Talks, Semantech Inc
0 comments:
Post a Comment