hiveware for patients

The Hiveware peer-to-peer platform presents a unique opportunity to make a significant contribution to the nation-wide effort of making our health-care records electronic. The current approach is woefully inadequate. Health-care record systems are designed and offered by each medical entity. Already there are too many systems to choose from and integration issues abound. No single provider can completely control the industry although that hasn’t stopped each provider from trying. Inefficiencies abound the most egregious of which is injurious data inaccuracy due to constant reentering and omission.

Here is what Information Weekly had to say about the problem:

Top Patient Node

It makes sense for each person/patient to use the computer and network to always know what one’s current prescribed medications are, to know who is in charge of prescribed procedures and treatments we are paying for, to know what the hierarchy of management and professionals who are moment-by-moment making decisions about our health care is, and to know what the running costs are. A simple approach to solving this problem is to make a health-care system that is patient-centric without the need for large server farms that are expensive to maintain. Hiveware for Patients is a node too with these kinds of sub-nodes:

Here’s how it would work: the Hiveware® for Patients developer would secure connection rights and capabilities with as many providers as possible. This would be the Kaiser Permanentes, Aetnas, GoldenRules and the many others. Each has its own stovepipe or silo system as it is called. Their legal argument is that their patient’s data is rightfully owned by the patient who paid for it. Their financial argument would be that the providers would be compensated for their contributions. Each provider would be viewed from Hiveware as an author who outputs data each time one of their doctors, technicians or labs creates some information regarding the patient which is all the time or any time. True to Hiveware, that information would be pushed to all other participants, one of which is the patient. All see the same set of data, but only each author/provider would be able to change that data. The patient can trust that each professional’s data he views and makes decisions from would always be up-to-date. Each professional would always see each other’s latest information too.

Next step is to create a hive that creates hives for patients. Hiveware doesn’t operate with the notion of apps anymore. Instead, there is an ancestor value-adder. The first value-adder is the Hiveware for Patients developer organization. When their initial development is release (it can change any time though), hives for patients can be created connecting up individual patients and their coterie of professional. Again, the participants are always in flux. The semantic structure would always be preserved. For example, if a patient has chemotherapy on Thursdays at the National Institute of Health because she is a clinical trial participant, then the hive nodes would reflect that.

Use that hive to create a hive for a patient like Linda:

Hiveware takes care of the rest by establishing real-time connections to everybody. Players may tread in and out of contributor roles over time. For example, Linda participated in two NIH Phase I and Phase II studies. Some of her attending professionals were the same and some were different. Her set of NIH professionals would contribute information while they were generating it, but move back to reader-only role for the duration.

The PC of the clinical trial’s head doctor and his team of nurses and technicians’ PCs would all be hive members, but group under him at his institution. Other hive members would be the patient’s health insurance’s organization assigned to the patient all organized under that health organization. Of course, the patient’s personal physician would be a hive member.

Inherent Security

Hiveware® is an inherently secure technology. Based on IPv6 each piece of a document/activity is sealed off from the other pieces by having its own IPv6 address. A document is therefore like a honeycomb if individual cells transmitting and receiving independently of each other. The only device that holds them together, and additionally gives it meaning, is the joint context in the form of an evolving document grammar. Never is either the whole grammar or the whole document transmitted at one time like files are today. Only changes are transmitted to fix up that particular piece at each of the replicate sites. Even if an intruder were able to capture and unencrypt any particular transmission, it would not make sense without its whole.

Since Hiveware® is not dependent on data being persisted on hard drives, group data may remain in the collective memory chips of the participant computers. Any sign of danger or inappropriate authentication or authorization, the data will disappear from that or those machines.

Replication Means Data Safety

It is a known problem that large data stores are in the long term inherently insecure. The computer science community agrees that the only really secure data safety approach is replication. Since each piece of Hiveware® information is algorithmically replicated, the more authors and the more replications, the more persistent the data is forever.

Three Steps to become a Hiveware^® for Patients domain or sub-domain owner and entrepreneur:

1. Pick out a domain area that you have experience in and have entrepreneurial interest in.
2. Read our policy.
3. Send an email to info@hiveware.com indicating your wish to begin.