Wednesday, December 5, 2012

The Healthcare Portfolio

Today's post is a continuation of the discussion from yesterday's post:

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


Post a Comment