You need a Data Asset—not a Data Warehouse—Family Health Guy
A data asset is a collection of all the information relevant to an organization, regardless of source and of type. We call it an “asset” because this data, not the systems that created it or that are used on any given day to interact with it, represents the true long-term capability of an organization to thrive. The potential of that organization to measure itself, to learn, to adapt to new situations and technologies, to predict future outcomes and improve operations, all rely on its ability to find, use and re-use data.
This is what Amalga does – it captures all the information, and stores it in data atomic form. “Data atomic” means that rather than try to selectively normalize incoming data elements into some predetermined information model, we simply capture them exactly as they arrive – and save every scrap of metadata that comes along with them in self-contained “data atoms.” By doing this, we ensure that we never lose fidelity, history or context.
A great post on on the differences between structured and unstructured patient information—characterized as an enterprise–data asset. Missing is the the much greater set of health information—the patient–data asset (both normalized and non–normalized or atomic). Because for any given enterprise–data asset, there are numerous patient–data assets that it is derived from. The enterprise–data asset is the sum of the individual (derivative) patient–data assets captured by its data acquisitions (broadly construed).
The patient–data asset constitutes the set of all health information pertaining to the patient. The enterprise–data asset comprises that subset of the patient–data asset that is stored or in a state of utilization separate from storage by the enterprise. Similarly, the data asset of a Health Information Exchange (HIE) is derivative of the enterprise–data assets undergoing the exchange. The HIE–data asset is a second derivative of the personal–data assets stored/utilized by the enterprises comprising the exchange.
Different models may be constructed based upon the structures and the derivations of data assets. Exchanges of data assets may occur in two manners. One, where the data is unstructured, e.g., paper, fax, unstructured text, mail, image (non–digitalized), etc. Two, where the data has been structured—which may be further broken down by type of structure and type of transport.
| Proprietary Quasi–Proprietary |
Open Standard | |
|---|---|---|
| Structure | ? | HTML, XML |
| Transport (Protocol) |
? | HTTPS, XMPP |
Two generalized models exists: enterprise–centric (ECM) and patient–centric (PCM). With an ECM, the enterprise is a placeholder for hospital, physician(s) practice, pharmacy, etc.—an enterprise is anywhere patient data may reside in a manner not directly and fully controlled by the patient. In other words the distinction between the two models is over the concept of ownership. The ECM (infra) is an attempt to capture what it looks like in the wild (many owners). The PCM is hypothetical and predicated upon the patient as owner and the use of structured data and open standards exclusively. The atomic data (non–normalized data) forms the residual background that may need inclusion on a need basis, but shouldn’t impede a conceptual model that is lean and clean.
Movement within the models is dependent on structuring and transport protocols. Where enterprises, within an ECM, need to exchange unstructured or incompatibly structured data a mechanism is required either to transmit form and content (e.g., a fax) or content alone (e.g., HIE). With a PCM, where structure and transport protocol are the same, movement between enterprises is direct without any mechanism required.
Enterprise–Centric Data Asset Model (ECM)
Patient–Centric Data Asset Model (PCM)
Under an ECM, where multiple ownership interests exists, there is the concern (from a patient’s perspective) of the permanency of derivative data that will reside within the enterprise or HIE (where utilized). Additional concerns arise where this derivative data may be used in a secondary data market—the market for deidentified data. Deindentification is where the data is striped of all person–identifying information. The secondary data is useful for research, public health, commercial marketing, etc. Where there exists a secondary data market, there must also exists a tertiary data market. A tertiary data market consists of those enterprises engaged in the striping of person–identifying information as a service offered to those enterprises within the primary data market—the ECMs.
Data Asset Derivatives
Under a PCM, ownership of patient–data asset and all derivatives resides with the patient. Use of the patient–data asset is more like a utility service—where a permanent (and single instance) of storage is utilized by the enterprise providing service in a just–in–time (看 板) manner. Secondary and tertiary data markets gain access to the primary data market directly based upon a patient–permission model. This is very important from a funding standpoint, because the secondary data markets are lucurative ventures for enterprises under an ECM. When considering the construction and funding of a PCM, the secondary data markets may be an important consideration for inclusion in the design.
Data Asset Federation
Enterprises within a data asset federation always provide services within a complete informational representation of the patient’s health. The information byproducts of their service delivery provides an ongoing contribution to that continuously evolving informational representation.
This is a companion post to structuring and focusing information.
