LifePortal — Rough Draft

You know how mint.com aggregates personal banking information? What if there was a site that aggregated all kinds of information? A dashboard for your life?
A single site where you can see how much you owe on your car, when your next insurance premium is due and if there are any recalls on your car.
A single site that can also show you when your last physical was, when your next dental exam is and if your child’s immunizations are up to date.
A single site that can also show you when tuition is due, when and where the Biology 101 final is and if your Tivo is set to record next Saturday’s big game.
My vision is for a web-based portal that is the holistic equivalent of an electronic health record in which there is no single record or single storage point, but rather bits of the record from the various sources that adhere to a data definition that allows them to be collated and sorted and presented as a whole record. This concept could be applied to just about every aspect of life.
For example, let’s assume a user has a car. Based on the VIN and other information provided by the user, a system could query the manufacturer to find out when and where the car was produced and if there are any recalls that have been or need to be performed. The system could also query the bank identified by the user to show information on the car loan or query an insurance company to show insurance information. Perhaps a local auto mechanic participates in the program and the system can query repair and service records. Each of these disparate datasources would use a defined dataset including keys such as the VIN and account number from the auto loan bank in order to provide parts of a complete record. This life portal data is stored either by the vendor or hosted for the vendor in a secure fashion. The data is not, however, generated or stored by the life portal.
The portal is used to present data from various datasources. By separating the data from the user interface, portal hosts would be allowed to add value. For example, a portal provider could show trade-in value for the car presented in the example above. A vendor could perhaps even sell ads to car dealers to display next to information about my car. However, neither the dealer nor the portal provider store my personal data nor have access to it. Portal providers could provide specialty portals for parents or students or professionals. For example, if I am a college student and my school participates in the program, I can view the equivalent of my transcripts online; perhaps even view a syllabus for my current courses; view student loan information; or find out when the next sporting event is. While all of this information is useful to a student, it wouldn’t be used by most professionals who are not students. Therefore, an education portal provider could emerge as a market leader among 18 to 24 year olds.
To implement a “life portal” would require several features including a strictly defined data dictionary; storage and usage requirements of the data; security, privacy, authorization and authentication structures; and participation requirements on the part of service providers and portal providers.
A strictly defined data dictionary would identify goods and services that could be monitored. Goods such as cars and cell phones and services such as banking and healthcare would all require very specific definitions and associated definitions. A car, for example, would have different attributes than a cell phone or a farm tractor. But, they each have data that could be presented on a dashboard and linked to data from a bank or a cellular service provider. Cable and satellite providers could adhere to a given data definition so that account holders can view their balance, but also the programming guide specific to an account.
All portal data should be stored in a specific format for easy consumption by portal providers. XML, for example, would provide sufficient key value pairs and could be easily consumed. Physical storage of the data should be distributed. That is to say that any portal provider with sufficient authorization and authentication should have access to the same data as any other duly authorized provider. Whether the data is hosted by a third-party as contracted by the data provider or hosted by the data provider should not matter. A large healthcare organization may chose to house it’s own portal data whereas a small doctor’s office may find it more feasible to use a contract service to securely host the data. In order to provide transaction history, a separate storage system should be used to record transactions.
Data must be securely stored. This should include encryption of the data as it is stored on the disk. The data should be entirely private, viewable only by the terminal user. The portal provider, data host and data generator should not have access to view the data. Users must opt-in to the goods or service provider’s portal program. If the user does not opt-in or chooses to opt-out at any time, no data will be stored. In other words, portal data files should not be created or stored until there is a portal user. The user should be considered the owner of the data and thus can order the data destroyed.
There are essentially three parties involved in a portal: the end user, the data provider and the portal host. The only possible surrogate is a data host on behalf of the data provider. The end user must agree with the data provider to collect and provide data to the portal host. The end user must agree with the portal host to access the data. The data provider must agree to allow the portal host access to the data. Only when the triangle of trust and agreement is met can the user view the data. If the user terminates the agreement with the host or the data provider, then all other related agreements are nullified. If the data provider does not agree to allow the portal to access data, then all other agreements are nullified. If the host does not trust the data provider then all other agreements are nullified. These agreements must be in place to ensure that the data definitions are strictly enforced, so that data security and integrity are recognized and so that the end user can maintain control of his/her data.

LifePortalYou know how mint.com aggregates personal banking information? What if there was a site that aggregated all kinds of information? A dashboard for your life? A single site where you can see how much you owe on your car, when your next insurance premium is due and if there are any recalls on your car.A single site that can also show you when your last physical was, when your next dental exam is and if your child’s immunizations are up to date.A single site that can also show you when tuition is due, when and where the Biology 101 final is and if your Tivo is set to record next Saturday’s big game.
My vision is for a web-based portal that is the holistic equivalent of an electronic health record in which there is no single record or single storage point, but rather bits of the record from the various sources that adhere to a data definition that allows them to be collated and sorted and presented as a whole record. This concept could be applied to just about every aspect of life.
For example, let’s assume a user has a car. Based on the VIN and other information provided by the user, a system could query the manufacturer to find out when and where the car was produced and if there are any recalls that have been or need to be performed. The system could also query the bank identified by the user to show information on the car loan or query an insurance company to show insurance information. Perhaps a local auto mechanic participates in the program and the system can query repair and service records. Each of these disparate datasources would use a defined dataset including keys such as the VIN and account number from the auto loan bank in order to provide parts of a complete record. This life portal data is stored either by the vendor or hosted for the vendor in a secure fashion. The data is not, however, generated or stored by the life portal.
The portal is used to present data from various datasources. By separating the data from the user interface, portal hosts would be allowed to add value. For example, a portal provider could show trade-in value for the car presented in the example above. A vendor could perhaps even sell ads to car dealers to display next to information about my car. However, neither the dealer nor the portal provider store my personal data nor have access to it. Portal providers could provide specialty portals for parents or students or professionals. For example, if I am a college student and my school participates in the program, I can view the equivalent of my transcripts online; perhaps even view a syllabus for my current courses; view student loan information; or find out when the next sporting event is. While all of this information is useful to a student, it wouldn’t be used by most professionals who are not students. Therefore, an education portal provider could emerge as a market leader among 18 to 24 year olds.
To implement a “life portal” would require several features including a strictly defined data dictionary; storage and usage requirements of the data; security, privacy, authorization and authentication structures; and participation requirements on the part of service providers and portal providers.
A strictly defined data dictionary would identify goods and services that could be monitored. Goods such as cars and cell phones and services such as banking and healthcare would all require very specific definitions and associated definitions. A car, for example, would have different attributes than a cell phone or a farm tractor. But, they each have data that could be presented on a dashboard and linked to data from a bank or a cellular service provider. Cable and satellite providers could adhere to a given data definition so that account holders can view their balance, but also the programming guide specific to an account.
All portal data should be stored in a specific format for easy consumption by portal providers. XML, for example, would provide sufficient key value pairs and could be easily consumed. Physical storage of the data should be distributed. That is to say that any portal provider with sufficient authorization and authentication should have access to the same data as any other duly authorized provider. Whether the data is hosted by a third-party as contracted by the data provider or hosted by the data provider should not matter. A large healthcare organization may chose to house it’s own portal data whereas a small doctor’s office may find it more feasible to use a contract service to securely host the data. In order to provide transaction history, a separate storage system should be used to record transactions.
Data must be securely stored. This should include encryption of the data as it is stored on the disk. The data should be entirely private, viewable only by the terminal user. The portal provider, data host and data generator should not have access to view the data. Users must opt-in to the goods or service provider’s portal program. If the user does not opt-in or chooses to opt-out at any time, no data will be stored. In other words, portal data files should not be created or stored until there is a portal user. The user should be considered the owner of the data and thus can order the data destroyed.
There are essentially three parties involved in a portal: the end user, the data provider and the portal host. The only possible surrogate is a data host on behalf of the data provider. The end user must agree with the data provider to collect and provide data to the portal host. The end user must agree with the portal host to access the data. The data provider must agree to allow the portal host access to the data. Only when the triangle of trust and agreement is met can the user view the data. If the user terminates the agreement with the host or the data provider, then all other related agreements are nullified. If the data provider does not agree to allow the portal to access data, then all other agreements are nullified. If the host does not trust the data provider then all other agreements are nullified. These agreements must be in place to ensure that the data definitions are strictly enforced, so that data security and integrity are recognized and so that the end user can maintain control of his/her data.

Leave a Reply