Miscellaneous, etc.

From a technical perspective, the easiest solution to architect and implement would be one large central storage location. Everyone's data would be stored in one place and everyone would know where to go when they needed the information.

On the face of it this sounds reasonable. It meets some of our most importation criteria: it's simple and easy to understand, it makes sense. But think about this for a minute… What other successful system is setup in the same way? How did we architect other really important systems, like banking?

Most of our important infrastructure is distributed. First, it helps us avoid the largest architectural flaw: a central point of failure. When we spread our resources across a network, we ensure that at least some of those resources are available even in the case of a disaster. Second, it supports a secure environment by spreading out our resources. If someone were to get unauthorized access to our clearinghouse, they would effectively have access to everything we are storing. In a network, when a node is compromised is can be cut off from the rest. Only one small chunk of our data would be exposed in the case of a break-in.

Lastly, it's difficult to find someone to be the caretaker of such an important data store. All of the medical data about every person in the country is an impressive idea and we'd want that data protected by someone who we can trust. Someone who is above corruption. In reality, probably someone who doesn't really exist.

In a network, we're talking about smaller stores of data, it's less scary right off the bat. We're talking about ourselves and our immediate family. We're talking about the data that our primary care physician's office manages, we're talking about the data that our dentist is managing. We know who these people are and we already have a relationship with them. In many cases we are already trusting them with our health and well being, with our lives.

In the network scenario, you know who is storing and managing your data. If you feel that your primary care physician's office isn't storing your data according to your wishes, you are free to find another primary care physician and move your data. That is one of the most important pieces of the puzzle: you, the customer, the patient, have the final call on who manages your medical data.

It's still early days for the Flower project. We are hard at work and at this stage we are still sketching out what the specification would look like. Still, even now, it's clear that a network is the way to go. Health data needs to be distributed, it needs to be managed by the people who the patient has entrusted with their information.

In the Flower ecosystem, each health care organization would manage their own Flower node. The organization would store (or replicate) all of their customer's data in their Flower node. For instance, if the organization didn't have an electronic medical record system they might be able to put a very simple system together that interacted with their Flower node directly. If an organization had already made an investment in a system, that system could interface with their Flower node by letting it know whenever a patient's data had been changed and pulling new data from the Flower network through the node and into their system.

In most cases your primary care physician's office would represent your "Flower Home", the place where most of your medical data was stored. While you won't be required to keep all of your data in your Flower Home, for most people this will be the easiest way to manage their data.

Let's say you are referred to another physician, Dr. Daviss. Your primary care physician would most likely be in communication with Dr. Daviss and they would have already discussed your care. Dr. Daviss would send a request to your primary care physician's Flower node for the data about you that they feel they need. You would be notified, perhaps by an e-mail, and you would need to approve that request. Once you approve that request the two Flower nodes would be linked, your primary care physician's office would be sharing some of your information with Dr. Daviss' office.

The model is that of publishers and subscribers. Your primary care physician is publishing some of your data (the information Dr. Daviss requested and you then approved) to Dr. Daviss. When your physician adds or updates your data, the Flower node would publish the bits of that information that was shared out to Dr. Daviss. In effect Dr. Daviss is a subscriber to some of your medical information.

The beauty of this system is that information can flow both ways. In most cases your primary care physician would also request access to the data that Dr. Daviss is writing about you. This would be another request that you would need to approve and, most likely, you would do so. Your primary care physician would then become a subscriber of Dr. Daviss' office. Whenever Dr. Daviss updated your medical data, these changes would be published to your primary care physician.

Sometimes there are very good reasons for a central data store, the Flower system can participate in a clearinghouse. The only catch is that every person represented in the clearinghouse will be required to grant that clearinghouse access to their data.

This works identically to the example above. You, the patient, would be required to grant the clearinghouse access to some of your medical data. If at some point in the future you decided that you no longer wanted to participate, you would revoke the clearing-house's permission to your data.

As I said, the Flower project is just starting to heat up. Things are in flux and subject to change. Right now we are envisioning Flower nodes directly connected to the public Internet. Each Flower node would use the same industrial strength encryption that is used by your bank, Transport Layer Security (TLS) and Secure Sockets Layer (SSL). In this setup, each node would provide a certificate that establishes it's identity through a trusted third party.

The rights of access that you grant will reside with the publisher. In the above example, your primary care physician would keep track of the organizations to whom it was publishing data on your behalf. If you were to sever your relationship with Dr. Daviss, you would have your primary care physician's office cease publication to Dr. Daviss' Flower node.

There might be situations where you wanted to actually remove data that you had shared from another organization's Flower node. Perhaps an organization you used to work with is changing focus or merging with another organization and you don't want them to retain your records. Your primary care physician will stop publishing data to that organization's node but what happens to data that the node has already received?

This is a situation where Flower only specifies the behavior that it can control. No one expects Flower to erase the memories of your data from another physician or health care provider's mind, likewise the Flower network has only limited control over the nodes on that network. In this situation the publisher's node will issue a revocation message to the subscriber's node. The request will detail the information that the subscriber's node is required to purge. The subscriber's node will then purge the data and send a confirmation message to the publisher.

The responsibility for purging the data lies with the subscriber's node. Technically the Flower network cannot force the purge, it is conceivable that the subscriber node could send the confirmation without purging the data. Information that had been shared by the Flower node with other systems that the subscriber works with are also beyond the control of the Flower network. This level of enforcement needs to be handled legally, perhaps through agreements that all members of the Flower network need to abide.

In my next installment I'll talk about identity and how the Flower network identifies individual people and organizations as a whole.

Right now Flower is in flux, it's early days and people are only beginning to outline the goals for Flower. What has been decided is that…

• Flower will provide the mechanism that health care organizations use to transmit medical data between each other.
• Flower will provide an interface that people will use to ensure that they have control over who has access (or has accessed) their medical data.
• Flower will provide an easy-to-use and intuitive mechanism that will enable health care professionals to ask a patient for access to some or all of their data as well as a mechanism for people grant or deny that access.

Flower isn't trying to provide a personal health or electronic medical record. What they are trying to do is sketch out how an emergency room physician at your hospital might reach out to your primary care physician to find out more about you, and how this can be done in such a way that you feel in control and your privacy is protected while at the same time ensuring that you get the best care possible. It is no small feat! If you look around for other products that are working to meet this need, you won't find much. Flower looks to be the trailblazer, in fact, they may be the only people trying to address this very real need.

Right now there isn't a formal process for getting your medical records from one organization to another. More likely is that everytime to work with another health care professional, they open their own file about you. For instance, your primary care physician may refer you to a specialist. That specialist won't have any information about you at all and will start collecting by asking you about your history. Anything new that the specialist learns may not make it back to your primary care physician. That information is effectively locked up, it's only available if you instruct other health care professionals to contact that specialist and collect that information.

When you get into a situation where you are seeing more than one or two specialists, the situation quickly becomes difficult to manage. If you were to get into an accident and were receiving care from an emergency room, collecting all this information quickly becomes impossible. If you are incapacitated and can't speak, there's little that can be done; the emergency room physicians will simply do the best with what little information they have on hand.

The situation with prescriptions is not much better. Because communication between health care professionals is loose and ad-hoc, it's very difficult for them to keep in touch with each other. Surprisingly, the Internet hasn't helped this situation much at all. While it's true that they could send e-mail back and forth, e-mail itself is not a very secure method of communication. Even if it were, it's difficult to sort the important information from advertisements and junk-mail. Take a look at your own inbox and I'm sure you'll get an idea of what I mean.

This is the problem that Flower will solve: communication between health care professionals. Even better, it will also help them communicate with you!

One of the interesting things about Flower is the role of the patient. In Flower's view, the owner of the data should be the person making the decisions about where that data goes and who has access to that data. In almost all cases, according to Flower that person is you, the patient.

The vision is that when you visit a health care organization, the professional you are dealing with, let's say Dr. Stanley, will let you know what kind of information about you they need. If you are participating in Flower, they will send a request (via Flower) to the health care organization that has that information, in this case your primary care physician Dr. Morris. The system that Dr. Morris works with will receive the Flower request that Dr. Stanley sent and will check to see if you have granted Dr. Stanley access to this data. Dr. Morris' system will see that you have not and will hold the request, it will not send any data.

You will then log into your health care portal, which is also participating in Flower. The new request from Dr. Stanley will be visible and you will have the opportunity to approve the request. Once you do, the information that Dr. Morris has will be provided to Dr. Stanley's system.

The architects of the Flower system are discussing the nitty-gritty details of how this access will be managed right now. Perhaps you will grant Dr. Stanley access to the information he needs for a specific window of time. There's also talk of a mechanism that lets you revoke access, for instance if you end your relationship with Dr. Stanley.

The key difference between Flower and the competition is the role of the patient: it's your data and you decide who gets access to your data.

Another way Flower is challenging our notions of how data is shared is the idea that not all data needs to be shared all of the time. When a health care professional begins a relationship with a person, they don't necessarily want access to the entirety of their medical data since that person's birth. That's a lot of information and they often know exactly what information they need.

Every time a health care organization collects data about you, they become responsible for insuring the validity, integrity, and security of that data. The less data they need to store, the less data they need to worry about. Flower takes a good amount of this concern about privacy and security out of the hands of health care professionals. For the most part, if they have access to some of your medical data it's because you granted them access to that data.

When you decide that a health care professional or organization shouldn't have access to your data anymore, Flower will ensure that they know it.

While all this sounds great, how does this Flower system work? Where is the data stored and how does it get from one organization to another? There was talk about people managing their own medical data, how does that work?

I will explore these topics in the coming blog posts as more information comes to light. Even though is early days for Flower, there are still exciting things happening. Putting together the nuts and bolts of a decentralized medical data storage system is an exciting task!