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-centricwithout 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:
Pick out a domain area that you have experience in and have entrepreneurial interest in.
- Nov 22, 2023, you can now follow development of Hiveware's built-in apps. Just go to top Hiveware domains, then find and click on (DEV). This will show you a pdf of and history of these projects development from a GUI perspective.
- June 15, 2021, Presented CableLabs with Hiveware Inc and Microsoft findings that their DOCSIS 3.1 gateway modem specifications have not led to ISP venders implementing IPv6 end point to end point Reachability. Local Reachability succeeds, but both Intra-ISP and Inter-ISP cable modem Reachability fail.
- Sept 15, 2020, Determined that ISPs that offer Ipv6 like Cox and Comcast, are not inter-connectable. See my explanation, which means Microsoft's socket library, Winsock2, is not to blame.
- May 18, 2020, Hiveware Ipv6-Ipv6/Ipv4-Ipv4 connectability succeeded Debug and Release. This breaks the stranglehold NAT has on Hiveware residential deployability (but only for intra-ISP comms for now, fx, XfinityWifi does not work where the problem lies with either Microsoft, Xfinity or Cox).
- March 17, 2020 opens Hiveware for Ipv4Ipv6Comms initial hive offering until June 19th, 2020.
- March 16, 2020, Hiveware for MyFiles private Digital Asset App Offering closed and March 17th, 2020, Hiveware for MyFiles public Digital Asset App Offering opens and will close again on June 19th, 2020.
- March 16, 2020, Hiveware BigBang Test 2-PC Basic succeeded again, but this time using Ipv6. This is the '1' of the decentralized '3-2-1 persistence' model.
- March 17, 2019, Hiveware for MyFiles public ICO began and ended June 16th, 2019
- December 17, 2019, Hiveware for MyFiles private Digital Asset App Offering began and closes March 16th, 2020.
- January 17, 2019, Hiveware BigBang Test 2-PC Basic succeeded. This is the '1' of the decentralized '3-2-1 persistence' model.
- October 1, 2018, Hiveware LittleBang preview running again, this time using production engine code
- August 17, 2018, Hiveware for MyFiles private ICO will begin
- July 17, 2018, Hiveware ICO ended. SoftCap not reached.
- Jun 3, 2018, first to file for Securities Act of 1933 compliance regarding HVW-generating dapp ownership ICO sale
- May 11, 2018, Microsoft delivers native MFC (C++) on ARM64, opening mobile devices and market up to Hiveware code
- April 17, 2018, Hiveware ICO began
- April 13, 2018, white paper published
- Dec 27, 2017, Hiveware engine (4th rewrite) POC done