I have often wondered if the NHIN could be built on an enhanced Gnuetella or Napster architecture. Imagine a physician working within Meditech, Epic or whatever vendor’s system and deciding they need to search for outside information on a particular patient. They submit a query, much like a person does in Napster or Limewire. Each HIT vendor has written a front-end for their system to retrieve inquiries from the network, process them and forward as needed. The inquiry is propagated across the NHIN. The physician then sees his screen populate with potential “hits” based on the search criteria. (Bear with me, I realize that security / privacy are huge issues, but I think the system could be modified to accommodate this.) The physician could then highlight those returned results he/she is interested, click a button at which time the browser requests the patient data from the selected systems and then pulls the data into a cohesive record that could be explored by the physician.

Here are a few of the hurdles that would need to be overcome:

- Security and Privacy – the patient needs to have the ability to “opt-out” in terms of what is shared on the network with a further option for a “break glass” capability in the event of a serious medical emergency. Perhaps the patients enroll in the network and answer a series of questions and options that determine exactly how their information is shared. The HIT vendor’s through their front-end software could use this patient privacy / security database to determine how they respond to a given request from the network. Also, the information has to travel across the network encrypted and all systems would need enough security to know they are talking to a legitimate requestor.

- Standards need to be finalized for passing normalized information between the vendor systems and the client browser software need to be formalized so that the client can properly tabulate the results.

- The “fuzzy” logic used in the querying needs to be sophisticated enough to adequately match up patients with a high level of accuracy. The query needs to contain enough information that the returned results are “reasonable” – perhaps a rating in terms of quality of the match could be listed with each returned entry. (It would be nice if we had a single patient identifier, but I’m not holding my breath that we will see that for many years.)

Some advantages to this environment:

- The HIT vendors still have control of their products and can develop their own “client” software to access NHIN. Some HIT vendors might choose to imbed the available patient information from the NHIN into their own stored data, while some vendors might have the user go to a separate query screen to retrieve results from the network – separate of the stored patient information.

- I believe the system could be developed in a way that the patient has control of his/her information.

- It provides a single, proven mechanism (Napster / Gnuetella) for making requests across the network and then retrieving results. There would need to be modifications to these mechanisms to ensure all sites are queried, but the concept is proven.

- The HIT vendors would write a front-end for their own systems to participate in the NHIN. This would help eliminate the need for each healthcare organization, RHIO or other entities from having to develop their own methodologies.

I am not naïve – I know there are tons of holes that this sort of architecture introduces that would either need to be filed or could eliminate thie architecture from contention. In addition, as I mentioned I have not kept up in the details of the current NHIN models – maybe this is the approach that they are pursuing. However, I at least hope they have considered this architecture.

This is exactly why I love the web, you find you share a concept with someone; you can virtually dialogue, incorporate various viewpoints and tips (i.e., Bob’s caution about using SNMP in its rightful place) and evolve.