Monday, December 28, 2009

Dueling Data Formats - A Publisher Template

This post is a follow-up to these links:
Below is a data grid (spreadsheet) from a Publisher Template demo that shows how data can be organized prior to creating a CSV data file from it. Notice that the data are organized in the cells in logical structures/formations/arrangements, which reflect the underlying data model in a way that is easily read by computers and understood by people.

By organizing the data in this manner means there is no need to reorganize (transform) them when it’s time to present reports, which reduces processing requirements and results in very rapid information display when generating dynamic graphs and tables.

Also, the cells can be color-coded, named, and have comments attached, which help people inspect the template model and comprehend the relationships between the pieces of content stored in different cells.



And here's what it looks like when converted to the CSV with the lables removed (the conversion is almost instantenous):


Dueling Data Formats - Continued


This is in response to Steve Elkins critical comments about my post regarding XML and CSV data formats at this link.

Let me being for thanking Steve for his comments about use of CSV data format compared XML. It's only through such debate that useful understanding can emerge and progress promoted.

As Steve Elkins said, a CSV (comma separated value) file is just rows of raw data (no formatting or formulas) in which each data element (piece of data) is separated by a comma (delimiter). This makes CSV literally the most efficient (least resource consuming) way to store and send data.

Enabling a CSV file to provide all the benefits of XML (and more) requires using CSV in a novel way. As I described elsewhere on my blog, this is done using a novel software method I invented, called CP Split™, which splits content (data and information) from presentation (the formatting instructions that render it for viewing).

What makes the CP Split method unique is the way it uses pairs of data grid template software (automated spreadsheet programs) coupled with CSV data files. One template creates the data file and the other consumes (parses) and renders it. This method provides all the advantages of XML (and more), as well as the ability to consume and use XML, while avoiding XML's disadvantages (i.e., its complexity, verbosity, and bandwidth requirements). Following I explain this novel software process in response to Steve Elkins' four points.

Point 1 – Steve Elkins wrote:
The first drawback of a CSV file is that it includes no metadata [data about the data], i.e., there is nothing in the CSV file that explains its contents…[With XML, on the other hand, all] of the information needed to interpret the contents of the message (i.e., the "metadata") is included in the message, itself. This is why, as Stephen [Beller] points out, an XML record is many times the size of a CSV record (and why a HL7 v3 record is many times the size of a HL7 v2.x record).
My (Steve Beller's) reply:

While it's true that a CSV record (i.e., a CSV data file) is much smaller, our novel technology interprets the meaning (semantics) of a data file's contents using the data grid templates. By way of example, take the CCR shown at this link. The metadata contained within the CCR's markup tags (i.e., between the angle brackets <…>) for the first blood test result is written in XML code as:


Using the metadata in the XML code provides the following interpretation: Blood collected on 2000-03-23 was tested for HBG (hemoglobin). The test had a LOINC description code of 30954-2. The data value of the test was 13.2 g/dl and the normal (reference) range for the test was between 13 and 18.

In contrast, using the CP Split method, a data grid template automatically arranges the raw data (without the metadata) into particular cells in a grid (spreadsheet). For example, it might arrange the blood test result data above in a row of adjacent cells in which cell A1—the cell in the first column (A) and first row (1)—contains "2000-03-23", cell A2 contains "LOINC 30954-2", cell A3 contains "HGB", etc. When it converts the cell contents to a CSV data file, the first row of cells in the grid becomes a line of data containing those data separated by commas, as such:

3-23-2000,LOINC 30954-2,HGB,13.2,g/dl,13,18

The result is that the XML requires 432 characters to store the data set, while the CSV data file requires only 42 (over a ten-fold size reduction).

The CSV data file, however, doesn't have any metadata, as Steve Elkins pointed out. So, lacking such metadata, what interprets the 1st group of numbers (to the left of the first comma) as the date of the blood collection, the 2nd as the terminology standard code, the 3rd as the name of the test, the 4th as the value, the 5th as the unit measure, the 6th as the lower normal range value, and the 7th as the upper normal range value?!? The answer follows.

As I mentioned earlier, the CP Split method uses two corresponding data grid template (spreadsheet) software programs. The first template, called the Publisher Template (PT), creates the CSV data file. The second, called the Subscriber Template (ST), consumes, interprets and renders the data file's contents. Here are the basic steps of this process:
  1. After obtaining the necessary data from the data source(s), the PT arranges the data into meaningfully/logically organized preplanned structures in which each data element is stored in a particular predetermined cell in a particular data grid (spreadsheet).
  2. The PT then takes the data from the grid and stores them in a CSV data file.
  3. The PT then ships the CSV data file to a corresponding data grid template software program, called the Subscriber Template (ST). This template which "knows" what the data in the CSV file mean based on their location in the file. That is, the ST interprets each data element's meaning based on the datum's row number and the number of commas preceding it on that row. The ST gets this "knowledge" during the construction of the PT and ST, whereby metadata is stored in the templates, not in the CSV data file.
  4. The ST then consumes (parses) the CSV data file and sends its contents into the cells of a data grid in a way that reflects the location of the data in the CSV file (e.g., the first data element on the first row of the CSV is put in call "A1" of the data grid). This maintains the ST's knowledge of what the data's means.
  5. The ST may then:
    • Export the those data from the data grid to a database and/or
    • Retrieve the data from the data grid and presents the data in dynamic reports by applying any required labels, formatting instructions and analytic algorithms.

Bottom line: As the data move from the PT to the ST via shipment of the CSV data file, there is no loss of data meaning even though the CSV file contains no metadata!

Point 2 – Steve Elkins wrote: "A XML message can be validated against standards before it is generated and/or accepted. Thus, bad data can be stopped at the source."

My reply: The same can be done via the PT and ST. Any validation rules can be written in the PT by which data are validated before generating the CSV data file. And any rules can be written in the ST by which data are validated before the CSV data file is accepted.

Point 3 - Steve Elkins wrote: "The flexibility of the XML format means that the sender can send as much or a little data as required by the context, within a single messaging framework."

My reply: The same can be done by the PT, i.e., it can include any portions of any data set in a single CSV data file as is necessary. In addition, a CSV data file can be decomposited so that only certain parts can be sent/accessed by a ST based on any context rules. AND multiple CSV data files sent from one or more PTs to a single ST can be combined into a single data file and/or composite report by the ST.

Point 4 - Steve Elkins wrote: "It's easy to add additional types of data to an XML messaging framework without having to go back and change existing sections of the framework."

My reply: Any types of data can be added easily to a CSV data file by the PT. Just as XML would require a change to the XSD/DTD schema file if a new data type is added, the PT and ST would have to be adjusted accordingly. In addition, although not previously discussed, the CSV data files and the templates can manage hierarchical data as does XML.

Conclusion

Anything XML can do CSV can also do using the novel method I describe above. And using CSV data files and data grid templates has distinct advantages in terms of speed, simplicity, and resource conservation. Another advantage of CSV and data grids, that was not discussed above, is the ease by which graphs are presented—since data can be stored in preconfigured arrays in the CSV data file and read by graph-generating templates in the ST—all without the extra overhead and complexity of XSLT data transformation.

I do believe, however, that XML has an import role to play, especially when dealing with large blocks of text (as opposed to numeric value and short data strings). I'm very interested in discussing the pros and cons of using CSV data files via the patented CP Split method compared to using XML method for particular use cases, and examining how the two methods can complement each other.

---

In response to a comment received, I added a screenshot of a Publisher grid template and the CSV file it creates at this link.

Monday, December 21, 2009

The push for ‘push’ technology for the NHIN


At this link, an article titled "New technology a 'push' toward EHR future" discusses how "…push messaging, a likely first step in rolling out a proposed national health information network in time for healthcare organizations to use electronic health-record systems in a 'meaningful manner' and qualify for federal EHR subsidy payments under the American Recovery and Reinvestment Act of 2009."

The article discusses how:
David Blumenthal, head of the Office of the National Coordinator for Health Information Technology at HHS called for pause in the planning of the NHIN…[as the government wait for an] outline of a "lighter" NHIN than has been the focus of much planning and development work in the past.
…[T]he new emphasis on so-called 'push technologies"—for example, the movement of a care summary "pushed" from a primary-care physician's EHR to a specialist—could come to the fore. The tools and techniques needed for these sorts of messages are less complex and will be far more readily available to a broader range of providers than so-called "pull" technologies, an example of which would be the system required for an emergency room physician to search for and pull copies of a patient's medical records scattered across many provider organizations via a query placed to through a regional health information organization.
It goes on to explain how a health internet of …
"health nodes" [reference]…would create a platform for basic messaging between its registered users, but would allow for growth, such as accommodating e-mail attachments, which "opens up the opportunity for health e-mail messages to be used for intersystem communications, such as receiving structured lab results, transmitting CCDs [continuity of care documents] from one practice to another and transmitting information to vaccination or chronic care registries."
And although it's not meant to close out pull technology…
it's hard to foresee what this new federal push toward push technology will mean or how it eventually will fit into a broader national healthcare communications scheme…"the drive to an alternate pathway is because docs need to by 2011 to be able to talk to one another to satisfy meaningful use"…[because it] is just sending a report or a document to another physician via e-mail and fax, only it will be more secure."
This is wonderful news!!! We've been promoting a peer-to-peer publish/subscribe node network architecture since 2002, which operates securely, inexpensively, durably, and conveniently using push technology (such as encrypted e-mail attachments). Unfortunately, few took us seriously. Instead, the mainstream focus has been on developing complex, expensive, monolithic, centralized, pull-based architectures that have serious security, scalability and interoperability concerns (e.g., see this link. While such centralized systems have a useful place within large organizations, they are simply not a sensible way to connect all parties via the NHIN (National Health Information Network)! It does my heart good to see a rational, open-minded dialogue finally taking place!

Related posts:

Sunday, December 20, 2009

Combining Cloud Computing, Client-Server and Novel Pub/Sub Mesh Node Network Architectures (Part 2 of 2)

In my previous post, I described three key architectures for deploying health IT software programs and exchanging patient information in a national health information network (NHIN). They are:
  1. Cloud computing
  2. Client server
  3. Publish/subscribe mesh node networks.
In this post I describe the use cases of each, as well as cautions to be taken in their implementation.

Cloud Computing Architecture Use Cases

The cloud is most useful in use cases where (a) Internet bandwidth is high and connectivity is constant and consistent; (b) data and technology standards are well-established; and (c) there is concrete assurance that if a web service provider goes out of business, the healthcare organization will have ample opportunity to recover all the data stored there. A primary benefit of cloud computing is lower upfront cost compared to client-server architectures. That is, if your local computer doesn't have the resources necessary to run a software program, it may be cheaper, faster, or more convenient to run the program in the cloud than through traditional client-server architecture.

Cloud Computing Security Concerns

When cloud computing is used, however, caution should be taken to protect sensitive patient data in a cloud through end-to-end encryption or by storing only de-identified patient data. Because it is so important, I've included the following quotes from several sources about cloud security issues:

  • "[Trend Micro, the] security company, in its in its predictions for 2010 predictions report for 2010, identified cloud computing as a trend that will amplify threats to companies over-reliant on cloud computing vendors. It… warned the nature of the cloud makes it an attractive target to hackers, who are drawn to the ease of going after a single cloud serving various customers and taking down 'multiple systems secured the same way'…The increased amounts of data handed over to cloud providers will also pose risks in terms of availability and data privacy, it said. Companies open themselves to the possibility of service providers going out of business, or having physical and internal breaches…It highlighted the importance of avoiding cloud lock-in and being able to switch providers "at will or in line with business needs", so as to retain control over the company's IT processes…Beyond the data center, threats lie in connectivity to the cloud…Web protocol technologies such as SSL (Secure Sockets Layer), DNS (Domain Name System) and BGP (Border Gateway Protocol) are still works in progress, being 'developed before security was a consideration'. Security researchers have been identifying flaws in these technologies--last year, a BGP vulnerability was revealed to have been known in the industry for over a decade, but remained an inherent problem…'The question is whether any cloud vendor could reasonably ensure that unauthorized access is not possible, that a hacker will never be able to copy millions of user records, login credentials, online banking information, billing information, transaction records and the like." [Reference]
  • "DATA PROTECTION: cloud computing poses several data protection risks for cloud customers and providers. In some cases, it may be difficult for the cloud customer (in its role as data controller) to effectively check the data handling practices of the cloud provider and thus to be sure that the data is handled in a lawful way. This problem is exacerbated in cases of multiple transfers of data, e.g., between federated clouds…INSECURE OR INCOMPLETE DATA DELETION: when a request to delete a cloud resource is made, as with most operating systems, this may not result in true wiping of the data. Adequate or timely data deletion may also be impossible (or undesirable from a customer perspective), either because extra copies of data are stored but are not available, or because the disk to be destroyed also stores data from other clients. In the case of multiple tenancy and the reuse of hardware resources, this represents a higher risk to the customer than with dedicated hardware…MALICIOUS INSIDER: while usually less likely, the damage which may be caused by malicious insiders is often far greater. Cloud architectures necessitate certain roles which are extremely high-risk. Examples include CP system administrators and managed security service providers." [Reference]
  • "…[B]usiness technology pros what worries them about cloud computing, security concerns…[may] end up sinking any move to the cloud… IT departments…aren't as confident of where pain points such as security flaws may be. What new intrusion points are introduced? How can a company be sure that its data sitting in the vendor's data center is safe? When should information be encrypted?...[S]ecurity defects in the technology…[is] a top concern with cloud computing …One of the biggest risks of cloud computing is that of the unknown… One can't assume that encryption is available in all cloud services…Encryption creates a lot of overhead, and suppliers don't want to degrade application performance or absorb the cost if customers don't put a premium on it…[C]ompanies need to think of their networks now extending beyond their own physical environments and into the supplier's data center. As companies stitch more cloud services together, that challenge multiplies. A related complication comes from the fact that cloud services have been designed in vacuums, with each vendor securing its own connections but not the others…[T]he more data that goes into the cloud, and the more valuable that data, the more appealing it becomes as an attack target…That's why companies, once they've worked their way through the network security issues of transferring data to and from a cloud provider, need to probe the vendor's data center operations…[C]ompanies must determine how comfortable they feel putting data and applications in the cloud…Only a brave few dive in…completely…Vendors acknowledge the fear…[and a] lack of trust about cloud service security." [Reference]
  • Not only do security concerns exist outside the cloud, but as discussed below, privacy concerns exist inside the cloud since cloud vendors are able to look at your database. “'Cloud computing is a trap, warns GNU founder Richard Stallman…It’s stupidity. It’s worse than stupidity: it’s a marketing hype campaign'…Somebody is saying [that cloud computing] is inevitable – and whenever you hear somebody saying that, it’s very likely to be a set of businesses campaigning to make it true…Amazon’s marketing of a ‘VPN to the cloud’…as the solution to a company’s security concerns…[but] Amazon just doesn’t get it…’It’s them against us…thousands of hackers attacking and we just don’t have the resources.’…We can easily guesstimate that at any given point in time we’d have at least 1,000,000 hackers willing to compromise any mega corporation...Amazon’s response appears to be focused on creating a moat in front of their cloud, and while that’s not a bad idea, in no way does this alleviate the threats inside of the cloud itself not to mention an array of other reasons…’Computer security researchers had previously shown that when two programs are running simultaneously on the same operating system, an attacker can steal data by using an eavesdropping program to analyze the way those programs share memory space. They posited that the same kinds of attacks might also work in clouds when different virtual machines run on the same server…The bottom line is, how can you defend the outside of your cloud when you might not even be able to trust the inside of your cloud...Is a cloud provider willing to allow you to perform an in-depth penetration test to ensure you meet compliance? For now, can even forget about the outside threat to your cloud, those threats will always exist, what can you do to defend the insider? Seriously…So when a provider states that: ‘We reserve the right to invade your privacy at any given point in time,’ it just doesn’t sound so appealing, especially when companies are looking to potentially store customer data in the cloud. Do you honestly want a third party viewing your customer database?...[When Amazon states that] ‘It’s important to note that we take the privacy of our customers very seriously, and don’t inspect the contents of instances’…[and] ‘Abusers who choose to run their software in an environment like Amazon EC2, make it easier for us to access and disable their software’…how would Amazon know whether something is a rogue or a misconfigured application, without taking a look?...they’d HAVE TO look at it.” [Reference]
  • "…[Y]ou can transfer risk but never responsibility…no cloud provider will give you the security you need. There can never be a cloud computing provider who can give you the kind of security protections that an in-house security team can and the logic behind this statement is a simple and factual one: a cloud provider won't lose as much as you would at the end of the day. Therefore the incentives to go 'above and beyond' can never and will never exist…Cloud computing providers can only cover so much ground when it comes to security and what they will cover is often a baseline based on often obsolete guidelines. Even if they could cover all the necessary bases, the virtualized environment itself would forever be at odds with forensics…When a machine is virtualized, its states change rapidly and the possibilities of doing forensics is out of one's hands and out of your company's control and in fact, even outside of the cloud providers' control. A cloud provider will not…take dozens if not hundreds of other virtualized machines offline to make a forensic replica should the need arise…Cloud services are especially difficult to investigate, because logging and data for multiple customers may be co-located and may also be spread across an ever-changing set of hosts and data centers. If you cannot get a contractual commitment to support specific forms of investigation, along with evidence that the vendor has already successfully supported such activities…[you're] worse off [with the cloud] than keeping things in house from a forensics point of view and an incident response point of view." [Reference]
  • "There are always risks involved when dealing with working online, regardless of how secure a host might say a web application is, that fact of the matter stands that the security risk of running an application of the Internet is more significant than when running an application on a standalone desktop computer. Some applications require more security than others, playing Sudoku on a web application would cause little concern, but dealing with sensitive corporate formulas or accounting details in a web environment might be determined risky." [Reference]
  • "Web applications are exposed to more security risks than desktop applications. You can have a total control over the standalone applications and protect it from various vulnerabilities. This may not be the case with web applications as they are open to a large number of users in the Internet community thus widening the threat." [Reference]
  • "Working online has its own set of risks like hacking and virus threats. The risk is higher compared to a desktop computer, since a malfunction of the desktop can result in loss of partial data. The crash of a web server can result in consequences beyond the control of a business." [Reference]
  • "Local applications installed on your computer give you better security and do not require a connection to the web. Also, in many cases, local applications provide better integration with the operating system." [Reference]
  • "The Internet abounds with security threats; some users have reported automatically losing accounts and data with Google or other web services after hacker break-ins; cross-site scripts which install key logging software are especially problematic because passwords can be recorded and stolen as they are being typed; hackers routinely break into accounts with simple passwords (names, personal data, words from the dictionary, or anything less than 10 characters)." [Reference]
  •  Clouds at Amazon, Google, Microsoft, AT&T, Paypal, Sony, the CIA, Citibank and Twitter have all been hacked [Reference1], [Reference2], [Reference3].
  • "The hack into a Gizmodo writer’s Amazon and Apple accounts over the [first] weekend [of Aug 2012] is being used as a cautionary tale for consumers, a call to action for cloud providers regarding security policies and a sounding board for concerns about the rush to the cloud...an attacker quickly found his way into [a user's] iCloud account and wiped everything from his Mac, iPhone and iPad, all of which were linked to Apple’s cloud service. The attacker also hacked into his Twitter and Gmail accounts...larger concern was how quickly and easily the attacker...was able to get gain control of [the] account through just a couple of phones calls to Amazon and Apple [using] social engineering" [Reference] and [important comments].
Cloud Computing Use Cases

Taking security into account, use cases for the cloud computing architecture include:
  • Providing access to browser-based EHRs and EMRs with end-to-end encryption in either:
    • Tightly controlled private clouds
    • Non-private clouds only if the patient identifiers are stored in encrypted data files (in the cloud or in local storage).
  • Storing de-identified patient data in centralized databases for public access or for restricted access by authorized persons (e.g., for research purposes).
  • Storing practice guidelines in public clouds.
  • Home monitoring, whereby data from measurement devices (e.g., a glucometer) are streamed to a provider's private cloud with end-to-end encryption.
  • CRM, business intelligence, content management and research-based applications in private clouds with end-to-end encryption.
  • Hosting Web conferences to dispersed audiences.
  • Enabling real-time collaboration in private clouds with patient data encrypted end-to-end or in public clouds with de-identified patient data only.

Client-Server Architecture Use Cases

The client-server model is most useful in use cases where the data remains within an organization's boundaries (i.e., behind the firewall) and subject to strong central control (authorizations, etc.); such use cases include:
  • Managing patient data in a provider organization's EMRs and EHRs
  • Running an enterprise health information management system (HIMS), including both clinical and financial applications
  • Running business intelligence (analytical) applications within an organization
  • Running protocol/medication adherence management and post discharge software programs, e.g., having text messages trigger alert that are sent to case managers informing them to contact certain patients under certain circumstances based on an organization's rules (algorithms).

Novel Pub/Sub Node Network Architecture Use Cases

The pub/sub node network model is most useful when:
  • Exchanging sensitive patient data beyond organizational boundaries (i.e., beyond the firewall)
  • The cost of infrastructural build-out for centralized systems is prohibitive
  • At least some end-users must access data at times when bandwidth is low, connectivity is intermittent, or network latency is high
  • Exchanging data between disparate databases
  • Individuals prefer to have complete control over their own data
  • Large scale emergencies disrupt communication networks relying on the Internet.
Use cases for such a node network architecture include:
  • Exchanging patient data across organizational boundaries, including sending data between disparate data stores (e.g., exchanging data between incompatible EMRs, EHRs and PHRs).
  • Sending de-identified patient data from PHRs and EHR/EMRs to data centers in HIEs/RHIOs and an NHIN repository.
  • Connecting multiple cloud, client-server and desktop-based systems by providing nodes to able to access the applications and data sources in each system.
  • Locally storing data collected through cloud-based applications in encrypted CPS data files, and enabling those data to be sent back to the cloud-based system as necessary. The same goes for client-server applications.
  • Exchanging patient data in emergency disaster situations in which command & control units and first responders (fire fighters, police, EMTs, trauma center staff, etc.) must communicate quickly and effectively even when they each have different data needs and when the Internet is unreliable. This includes overcoming the "last mile problem"—which refers to the challenge to provide connectivity to all end-users' devices at all locations due to bandwidth mismatches and other connectivity constraints—by providing multifaceted asynchronous communications capability that includes radio, land line, and satellite communication options.
  • Preventing any single point of failure problem of centralized systems by mimicking the landline telephone system, which always has a dial tone even when power goes out.
  • Supporting an automated decision-support system in which the nodes host a "loosely-coupled decision network" of people from multiple locations and with different roles who sometimes work together to make decisions beyond the knowledge or skills of any individual. The nodes use their data transformation and universal translation capabilities to accommodate the diverse information needs and preferences of the participants in a way that reduces misunderstandings due to regional, departmental or cultural differences.
  • Doing eligibility checking, i.e., when a patients go to their healthcare providers, the nodes send data back and forth between the nodes connected to insurance company databases to exchange eligibility data.
  • Exchanging data between nodes connected to labs, providers and patients.
  • Automatically sending certain data concerning communicable diseases and other biosurveillance data to and from the Center for Disease Control (CDC) via nodes connected to providers' EHRs/EMRs, patients' PHRs and the CDC's databases.
  • Providing remote access to imaging data stored locally.
For more use case scenarios, see these links on our Wellness Wiki:

Conclusion

All three architectures have important use cases. The novel node-based architecture I've been promoting enables all three to work together in order to receive the benefits of each.

Related posts:

Friday, December 18, 2009

Combining Cloud Computing, Client-Server and Novel Pub/Sub Mesh Node Network Architectures (Part 1 of 2)


There are at least three key architectures for deploying health IT software programs and exchanging patient information:
  1. Cloud computing
  2. Client server
  3. Publish/subscribe mesh node networks.
Each of these architectures has its own use cases and, as I discuss below, I've concluded that using all three provides the best solution for operating a national health information network (NHIN).

Cloud Computing Architecture Described

Here's a definition of the cloud computing architecture that I believe captures its essence: Cloud computing architectures store software programs and data in servers that are accessed over the Internet via services (e.g., software as a service, SaaS); web browsers provide end users an online interface to those services. The servers—along with the software and centralized databases they contain—may be owned and managed by third-party vendors (public cloud), by the end user's organization (private cloud), or by both (hybrid cloud). In other words, typical cloud computing enables applications to be accessed online from a Web browser, while the software and data are stored on remote servers. Also see this link.

Client-Server Architecture Described

Then there's the client-server architecture in which the data are stored in centralized or distributed databases through servers controlled by the end-user's organization or third-party vendors. Each client sends data to, and receives data from, those databases. Like the cloud, the data are not stored locally on the end-users' computers.

Novel Publish/Subscribe Mesh Node Network Architecture Described

Then there is a publish/subscribe (pub/sub) mesh node network architecture, which I've been promoting. A "node" in this architecture is a connection point in a network, and a "mesh node network" is a federated/distributed node structure in which any nodes can communicate with any other nodes, just like the telephone system works.

Each node consists of a desktop (standalone) software program installed in a personal computer/laptop/notebook, smart phone, or other computerized device that access patient data from any appropriate data store (hard drive, flash drive, smart card, memory stick, etc.). This desktop software gives each node both publisher (sender) and subscriber (receiver) functionality. Thus, a publishing node sends data to its subscribing nodes (i.e., the nodes subscribing to it). Such data exchange can be done asynchronously in near real time, which means data can be sent rapidly whenever it is ready without having to wait until the receiver signals that it's ready to receive them. Note that a node may be partially automated (i.e., require some human input) or it may operate in a completely automated (unmanned) manner.

This node-to-node architecture is, in many ways, unlike the typical peer-to-peer (P2P) file-sharing systems, such as Gnutella and Napster. As described in the italicized link above), my proposed system uses a unique underlying technology—the patented CP Split™ (CPS) software method I invented 12 years ago—by which:
  • CPS publishing nodes use data grid templates to create maximally efficient CPS data files. These dense small files are encrypted and shipped inexpensively and securely by e-mail (or other communication protocols).
  • CPS subscribing nodes retrieve the CPS data files in near real time, store them locally, and use corresponding data grid templates to consume (open and use) those data files. They then present (display) customized reports or export the data to other data stores (e.g., local databases).
See this link for a depiction of how CPS nodes provide a simple, low-cost, secure way to exchange health data.

In addition to their asynchronous pub/sub functionality (described above), CPS nodes have other critical capabilities including:
  • Data transformation
  • Universal translation
  • Composite reporting.
These capabilities, which are described below, enable CPS node networks to exchange patient information easily no matter what data structures and terminology standards are used, and where the original data are stored. This means that data transformation and universal translation provide a means for modifying (transforming, translating) data as they pass between the nodes, so that all subscriber nodes receive from their publisher nodes the right data, in the right format (structure) and language, and with the right terms (semantics). This means the nodes accommodate all data standards, as well as any non-standardized (local or domain/discipline specific) data. It also means that composite reporting combines data multiple sent publisher nodes to a single subscriber node in order to generate composite reports containing information from multiple sources.

Data Transformation Capabilities

CPS nodes use their extensive data transformation capabilities when data structures have to be modified to allow disparate databases to exchange their data. This happens when, for example, the databases have (a) different table and field names, (e.g., one database may use the field "birth_date" and another "dob" or (b) different data formats/syntax, e.g., whether the birth data is month/day/year (as in U.S.) or day/month/year (as in Europe), as well as how many digits or characters are used in the date.

One way to deal with the issue of exchanging data between incompatible databases is forcing everyone to use the same data standard. One such method is transforming all data to XML format, using a common "schema" (data structure), before shipping those data between databases. While the CPS nodes can exchange XML files, there are distinct advantages to having a publisher node (a) convert XML data into CPS data files before shipping them to other nodes and (b) convert data from a database directly into a CPS data file without any XML. As I discussed at this link, two advantages of the CPS data files over XML are: (1) they are easily 1000% to 2000% (10 to 20 times) smaller than XML files containing the same data and (2) they are much simpler and more efficient to process (i.e., parse and render) than XML.

As the data are being sent to the CPS data file, the publishing node transforms them depending on the data format needed by each subscribing node. The publisher then ships the transformed data to the subscribing node. The transformation process requires that the publisher node be notified in advance as to the data transformations required by each subscribing node. This notification process can happen during when a subscribing node registers with a publishing node, or upon a subscribing node's request for data from the publishing node.

Universal Translation Capabilities

CPS nodes use their universal translation capabilities when publishers use a different language or terms than their subscribers. This is most likely to happen when people in loosely-coupled professional and social networks share information; that is, when diverse groups of individuals exchange data from diverse data sources. One such example is the vast diversity of people who will exchange a great variety of data across a national health information network. Sometimes language translation is necessary (e.g., English to Spanish), which is fairly straightforward. Other times different people use different terms (their local terminology standards) to refer to the same concept (thing or idea), which can be a complex problem.

One common strategy used to deal with complex terminology problems is to discard local terminology standards by forcing everyone to adopt the same global terminology standards. This is done by agreeing on one set of terms (semantics) for a particular thing. While such global standards for health-related terms can foster widespread communications between people from different regions, organizations and disciplines, there is a serious downside to eliminating the local standards people rely upon; the problem is the loss of important information due to reduced semantic precision and nuance.

Take, for example, the term "high blood pressure;" there are 126 different terms referring to this concept of elevated blood pressure levels. These terms include "malignant hypertension," which refers to very high blood pressure with swelling of the optic nerve behind the eye; it's a condition usually accompanied by other organ damage such as heart failure, kidney failure, and hypertensive encephalopathy. "Pregnancy-induced hypertension," on the other hand, is when blood pressure rises during pregnancy (also called toxemia or preeclampsia). These are very different types of hypertension. So, while referring to a person's condition using a global standard term such as "hypertension" clearly conveys that the person has high blood pressure, the standardized term loses important details found in the more detailed local standard terms. These lost details, in turn, could very well affect treatment decisions and outcomes. So, there is a good reason to have multiple terms that refer to the same health-related concept.

An advantage of the nodes' universal translation capabilities, therefore, is that they enable end-users to keep existing local standards, support the evolution of those standards, and use the data translation described above to ensure everyone gets the information needed using the terms they need and understand. In a node network, this can be accomplished in a way similar to data transformation. But instead of having the publishing node transform the data, it replaces specific terms with the alternate terms required by the subscribing nodes.

Composite Reports

The nodes can also generate composite reports that are comprised of data sent from multiple publisher nodes to a single subscriber node. The subscriber node takes all that information from multiple sources and combines it into a single integrated patient health report that is tailored to the needs of the individual.

For example, let's say a primary care physician (PCP) wants to keep track of the treatment a patient is receiving from several provider specialists. The PCP's node, which serves as the subscriber, would send a request for certain data from all the patient's specialists. Upon receipt of the data request, the specialists' nodes, which serve as the publishers, retrieve the requested data from their different electronic health record databases, transform and translate the data as necessary, and then send the data automatically to the PCP's node. The PCP's node then incorporates the data into a composite report tailored to the PCP's needs and preferences, and presents the report on screen for the PCP to view. The PCP's subscriber node could also be instructed to request data from the patient's node connected to his/her personal health record and, upon receipt, add the data into the same report. Likewise, a patient node could create composite reports in a similar manner from data sent by multiple provider nodes.

So, which architecture is best—cloud, client-server, the novel pub/sub node network, or a combined solution that embraces all three? I contend that it's the latter, whereby the benefits of each architecture are realized in different use cases.

In my next post, I will share my thoughts about this multifaceted solution by presenting possible use cases.

Related posts:

Monday, December 14, 2009

Omnibus Workflow Technology: Streamlining Clinical and Business Processes


An interesting article by Walter Kerstead at this link, titled Software's Guiding Hand, discusses how workflow technology helps clinicians at behavioral (psychological/psychiatric) hospitals/agencies avoid mistakes while increasing efficiency by promoting best practices. Following are some quotes:
…in most behavioral healthcare agencies best practices are detailed in policy/procedure manuals gathering dust on shelves…because they are not readily available at the point of service…[and] usually are not written in a quick-to-read format…[If put online, you would only] have readily accessible reader-unfriendly information.
The answer is to convert best practice narratives into administrative and clinical processes that a software system interprets to guide patients along care pathways...Staff members no longer need to worry what the next intervention is, who should do it, where, when, or how…[which reduces] your chances of being noncompliant with best practices…[without requiring] more staff and expense.
…In healthcare...we can report to managers on a minute-by-minute basis the "time remaining to a state of noncompliance" (e.g., "you will be noncompliant with the best practice in 12 hours"). Put a sufficient number of alerts at the right places on care paths and you can detect evolving problems and take action…The results are increased staff efficiency, greatly reduced administrative and clinical errors, increased throughput, improved compliance, and improved outcomes.
Such workflow technology can be applied not only to behavioral healthcare, but to all healthcare disciplines in which treatment is more than a "one-shot" (single visit/session) process. That's because it expands the capabilities of computerized clinical pathways.

Clinical pathways software transform evidence-based practice guidelines into a series of interventions spanning multiple days of care. This heatlhcare is for hospitalized patients and for patients being treated by multidisciplinary teams focused on providing coordinated care. Care events are mapped on a timeline or series of tasks including tests/assessments, treatments/procedures, medications, consultations, diet, teaching (including patient education), and preparing for discharge or transfer. The pathways, therefore, are clinical workflows depicting the activities/interventions to be done based on specific criteria. They also document deviations/departures (variance) from the recommended tasks. More advanced pathways also provide guidance in determining diagnoses and related procedures (through expert systems), collecting outcome data, identifying reasons for and nature of any variance, and showing how the variance relates to outcomes.

How does the workflow technology Mr. Kerstead described increase the capabilities of computerized clinical pathways? By also focusing on business workflows related to the clinical workflows. For example, in addition to providing clinical pathways functions, it guides and streamlines:
  • Compliance reporting processes, which include informing clinicians, mangers and office staff when certain forms must be completed and sent to authorization and accreditation organizations.
  • Implementation of key business processes, ranging from billing and submitting insurance claims, to tracking and ordering supplies, to managing human resources, etc.
Because this omnibus technology manages both clinical workflows (pathways) and associated business workflows in a coordinated manner, the benefits to a healthcare organization, and those they serve, are greatly increased.

Friday, December 04, 2009

Business Processes Associated with Healthcare Delivery

I just want to bring your attention to a conversation recently started at this link on LinkedIn that examines business process associated with healthcare delivery. I referenced a set of diagrams on our Wellness Wiki at this link, which has received many positive comments. It presents the blueprint of a "Wellness Model" that promotes both a patient-centric value chain and a provider-payer value chain. It shows how these two intersecting value chains ensure efficient and effective patient care management, and maximum utilization and efficient use of provider resource. Internet-related, interoperable products and services apply to each segment of the model.

Wednesday, December 02, 2009

A Novel Way for Everyone in the Nation to Exchange Health Data Simply, Inexpensively and Securely

It's becoming increasingly clear that while a monolithic centralized network is useful for sharing patient data within a large healthcare organization, it not a suitable architecture for interconnecting everyone in the nation (and world), including all patients/consumers, healthcare practitioners/clinicians, researchers, clinics and hospitals, labs, pharmacies, regional and state health information exchanges, and others. Why? Because the centralized model is much more expensive & complex, and arguably less secure, than decentralized (distributed, peer-to-peer, node-to-node) networks that are encrypted end-to-end.

This novel technology--which includes an optional proprietary (patented) component--connects all parties in a way similar to the telephone system. It enables massive amounts of patient data to be exchanged securely and inexpensively between any parties. It accommodates standalone and networked computers, as well cloud-based computing. It operates cost-effectively even when bandwidth is low and connectivity is intermittent regardless of available bandwidth, transmits comprehensive health data in the most efficient way possible, fosters collaboration among loosely individuals and organizations in coupled professional and social networks, and promotes the dissemination of ever-evolving knowledge providing evidence-based decision support that continually improves outcomes and lowers costs for greater healthcare value.

In this proposed architecture, the nodes are in a decentralized peer-to-peer (P2P) publish/subscribe mesh node network. The nodes can reside on any suitable computerized device, including computer hard drives, smart phones, smart cards, USB flash drives, etc. and it can works in conjunction with desktop (stand-alone; client-server) and cloud computing systems.

Related posts:

Tuesday, December 01, 2009

Health IT: Comparing Cloud Computing and Desktop Applications (Part 3)


This debate about the pros and cons of Cloud versus Desktop computing, which I posted at this link, has continued on another forum. Following are excerpts.

One commenter wrote:
Cloud computing is going to be revolutionary in coming era. Earlier we have concern about bandwidth and performance of the application in terms of speed, traffic limit etc etc... as evolution of the technology and communication system like HSDPA and HSUPA with high-end bandwidth for data packet transfer we wont be feeling the difference between a cloud computing and desktop computing. The other hand in UK the government and NHS collaboration going to bring up a revolutionary "CENTRALIZED HEALTHCARE SYSTEM" accross the country. NHS is spending near about 1.2 B$ for the NHS IT and Care For Health. Now US President also declare a stimulus package for Health Reform which enhancing using the electronic media in Healthcare and making a centralized system of Patient Health Record and Electronic Medical Record. I still feel we can see the advantages of the cloud computing and how best we optimized this, in terms of developing web based apps. Microsoft Silverlight is one of the success pillar of the cloud computing and web 2.0 is the optimized technology for enhancing the Speed, Performance, User Interface etc. I hope our next generation technology will be more focus and drive towards Cloud Computing. In terms of the security what you mentioned most in your blog is going to be no more a threat in web based app. Although we and our psychology still retain us in the concept that we can have better security in desktop computing. But think an incident of computer crash or natural calamities or disasters can break all the boundary of the desktop and intranet environment.
To which I replied:
Thank you for your thoughtful reply. I also see value in cloud computing and centralization in certain healthcare use cases. For example, storing deidentified patient data in a central database in the cloud for research purposes makes good sense to me because the primary purpose is on aggregate data analyses of massive numbers of records (and privacy & security issues are much less). A good case can also be made for central databases behind an organization's firewall. Another is off-premises storage of encrypted files. But in many other situations, a mesh node network (telephone system-like) cyberarchitecture makes more sense in terms of cost, complexity, security and privacy, as well as supporting data exchange and collaboration in loosely coupled health information networks. For example a P2P publish/subscribe node network (see this link) would offer a convenient, secure, lower-cost and simpler way for:
• Primary care physicians to exchange patient information with the specialists to whom they refer.
• Patients who want to input, retrieve and share portions of a locally stored PHR with their providers without logging onto the Web.
• Individual practitioners and clinicians from a small organization (clinic, group practice, etc.) who want to access patient information offline.
• The exchange of patient data between disparate HIEs/RHIOs.
• Situations where bandwidth is low, network access is intermittent, networks are congested, or servers are strained causing unacceptable latency.
• Money is tight and expensive infrastructural build-out is unwanted.
Note that the benefits of the desktop node-to-node network are expanded by deploying an exceptionally efficient novel data structure and using e-mail to transmit data files in an innovative (see this link).
Concerning an incident of computer crash, natural calamities and disasters, the system we're proposing includes data file backups (on- and off-premises), UPSs, and an "auto-failover" process by which the best available alternative methods of data transmission would be used—such as using dial-up, radio, or satellite communication.
Another comment responded:
I think advances in software architectures and increasing data transmission capacity will take precedence over traditional issues on adjusting the place of functionality and computational capacity. So the borders between desktop computing and the cloud is disappearing and each desktop is going to be a part of the cloud ( A piece of cloud will be the cloud itself.).
I studied the links and I think that although your approach is a genuine idea, but its time is passed. Maybe the best surviving method be to develop proper conceptual model for finding the right attachment point and taking a free ride of the Cloud Computing wave, instead of competing.
To which I replied:
I thank you for your thoughts and would like to have a better understanding of your points.
When you say the desktop will be a piece of the cloud or the cloud itself, the key difference between the cloud and the kind of node-to-node (n2n) network I'm presenting appears to be that the cloud approach: (a) MUST rely on a central server to enable data exchange and (as least some) computation, (b) rejects SMTP (email attachments) as a viable transport protocol, and (c) doesn't consider the value of using preplanned data containers and grid templates as a means of structuring and presenting data.
Nevertheless, I am VERY OPEN to any ideas about how to merge the cloud and n2n architectures, so that the best of each can be applied to different use cases. It seems that you're alluding to such a hybrid approach when you say "finding the right attachment point and taking a free ride of the Cloud Computing wave, instead of competing." Please do elaborate.
Note that I'm working on a diagram to clarify the n2n model in which pub/sub nodes, disparate data stores, and APIs enable fluid connectivity between all end users and third-party applications (EHRs, PHRs, CDSs, BI tools, etc.).
Another commenter then wrote:
I think cloud computing is the future, however, because of the sensitivity of the data we deal with (clinical research data in my case), we must think in terms of private clouds, public clouds and hybrid clouds. With the greater availability and affordability of disk storage and virtualization, private clouds are with in the realm of possibility for most research institutions.
And I responded:
Don't get me wrong, there are certainly good use cases for the clouds, and using them form aggregating and analyzing de-identified patient data is a fine example. A private cloud could also be useful for storing identified patient data behind an organization's firewall. However, I contend that it is a poor choice for storing identified patient data that it is accessible by parties outside an organization's the firewall. Like many others, therefore, I'm reluctant to store certain of my personal health data with MS or Google, but I realize a hospital might use a private cloud to store my data behind their firewall and that's OK. Likewise, I would not want my data to be stored in identified form in an HIE, RHIO, or NHIN cloud where they can accessed by others because there are more secure, lower cost alternatives.

Related posts:

Who should Own a Patient’s Health Data, Where should they be Stored, and How should they be Exchanged (Part 2 of 2)

This post is a follow-up to a prior post at this link. It is a thought-provoking conversation that examines whether the patient data stored in the national health information network (NHIN) will, within the next five years, likely be "owned" by major firms such as Oracle, Google, and Microsoft.
I wrote:
While a patient ought to "own" all their health data, it doesn't mean that such ownership is the same as having actual physical possession of them all. After all, each healthcare provider...has physical possession of the data that they collect. It's UNREASONABLE to expect that all those data (including images) be shipped to the patient for local storage and to ask the patient to release those data each time a provider needs them. Instead, the data should be stored where it is collected.
There is one exception, however: the PHR. All PHR data should always be stored with (i.e., physically possessed by) the patient (preferably, imo, in an encrypted data file), even if collecting data through the PHR is done via a kiosk in a doctor's office or through a provider's web site. Furthermore, all EMR/EHR data (with some possible exceptions, such as a psychotherapist's notes) should be sent automatically to the patient's PHR; and the PHR should have the means to help the patient understand what those clinical data mean.
To deal with the privacy issue, the PHR should possess functionality that enables a patient to identify the particular data able to be shared with particular types of providers. In addition, patients' PHRs should give them guidance and warnings about who should have access to particular data based on their roles and responsibilities. In that way, any data are stored in a provider's database/warehouse could only be shared with third parties when explicitly authorized by the patient.
Another commenter wrote then:
From a health delivery context, there are a number of stakeholders and providers who use patient information and who contribute to it...But to me ownership also means who decides where the information is to come from, what form it should take and the analysis of it etc, all questions related to the skills of the medical practitioner. The family physician is the medical practitioner who oversees and looks after the patient's overall health and as such has access to all information contained in a patient's medical record. It is the role of the GP to make diagnosis and recommend treatment, prescribe medications, monitor patient health, refer treatment to other clinical specialists and give other health related advice etc. It seems to me that the owner of the patient's medical health record is collaboration between the patient and the family physician. The patient has the right to know what is contained in that record but ultimately it is the GP who decides what goes there, and how best to use it.
...From NHIN or network perspective, there is a physical ownership component. An administrative entity is needed to manage where a medical health record resides, how it will look like, and where it is to be distributed to. Different parts of the health record will be supplied by different providers. Standards need to be applied and privacy concerns need to be satisfied. Time is another element. Access to accurate medical information in a timely manner are the two overarching considerations of the NHIN.
I replied:
It sounds like you're describing the Medical Home model with the GP controlling the flow of patient data. In that scenario, the patient would authorize a "community of referral," i.e., "trusted partner" clinicians to which the GP can refer and exchange patient data. I agree that the patient need not specify which data should be exchanged with a particular specialist every time the GP makes a referral. But the patient should indicate, at least once, which data can be shared with different types of clinicians. This can be done, for example, by having the patient approve (or modify) a recommended data set and let the GP decide the particulars within that set of data.
...I see the NHIN containing minimal data sets as defined by standard CCR/CCDs. This patient data subset includes provider and patient identifying data; contacts and advanced directives; patient's insurance and financial data; and patient health status, which includes codes for diagnoses, problems, and conditions; allergies; medication prescription information; immunizations; vital signs; recent laboratory results; codes/descriptions for procedures and assessments rendered; history of encounters; and care plan recommendations. By contrast, here's a link to what I consider a comprehensive data set, which includes advanced PHR data and addresses the information needs of the multidisciplinary teams comprising a medical home.
Although an NHIN could make certain important data available to clinicians at great distances, the vast majority of communications are between providers within local/regional HIEs (and other communities of referral), not between those at great distances. So, there's no need for the complexities of a monolithic centralized system for everyday data exchange. It's much simpler, convenient and less costly to use a node-to-node pub/sub architecture that relies on desktop/standalone apps and encrypted e-mail attachments. Such a mesh node network model (which resembles the telephone system) makes more sense than forcing all transactions through a central server. The NHIN would be most useful for biosurveillance and for clinical research since it is a centralized data warehouse provides an easy way to aggregate huge numbers of de-identified records from around the country. The NHIN would also be a good way to store backups of patients' encrypted data files. And since an NHIN would not contain comprehensive data sets, connecting pub/sub nodes with local data stores to one another in a decentralized manner is a more efficient and secure way to exchange extensive patient data. This is why I propose a hybrid cyber-architecture in which nodes connected to central data stores, along with nodes connected to local data stores, are the primary vehicles of data exchange.
And he then wrote:
Some of the models that I have seen rely on a central backbone for communication and coordination. It follows the SOA pattern and would have nodes connecting to a central highway. It seems that connectivity is a big consideration in being able to collect patient information from a variety of sources and providing front end interfaces for people to access information. Collection might be more onerous in a decentralized model. Implementing a monolithic centralized system certainly has its challenges though. For one, there is a larger burden to get a consensus from all of the stakeholders and to determine the most efficient architecture. I suppose there are disadvantages and advantages to both centralized and decentralized approaches. For example if my home is in New York and I travel to San Francisco and get sick, presumably the hospital in SF would have ready access to my health record in the centralized NHIN. I am not sure how transparent that would be in the more decentralized or node to node implementation. There would be connection issues, knowing who to connect to and login issues etc. But I agree with you there are certainly merits to a hybrid (best of both worlds) approach.
To which I replied:
...I think of a central communication backbone as being the Internet with pub/sub nodes connecting to each other across the central highway by exchanging encrypted e-mail attachments asynchronously.
The front end interfaces I'm proposing are programmable data grid templates used by the node to produce the data files (via a node's publisher function) and consume & present the data files (via a node's subscriber functions). The software programs used by the publishing nodes automatically (a) retrieves data from any necessary data store (local and remote) by whatever means required (SQL, XML or CSV parsing, etc.); (b) performs any necessary data pre-processing (i.e., data transformations and translations, analytics, etc.); (c) packages the resulting data set in an encrypted data file; and (d) attaches the file to an e-mail, addresses the e-mail, puts it to the outbox, and ships it to the appropriate subscribing node(s). Corresponding data grid templates, residing with the subscribing node(s), then consume and render the e-mail attachment. All this using local resources and without the complexities of a big centralized system.
[Alternative to having everything stored in a centralized NHIN include]...carrying your encrypted data file (containing a lifetime of health data down to just an emergency data subset) and respective templates on a memory stick or smart card. Another is to have a centralized directory of GP e-mail addresses and patient identifiers whereby your GP's address can be located.
He then responded:
GE Healthcare refers to eHealth as the total healthcare IT infrastructure that connects and adds value to the healthcare delivery system across multiple hospitals or a region, including physicians, care providers, patients, and others. http://www.hospitalhealthcare.com/default.asp?title=Highfocusonpartnershipsandinnovativetechnologies&page=article.display&article.id=19448
Applying the GE definition to an overall strategy not dependent on any one technology but encompassing a number of value added solutions, a best of breed approach if you will, which could be applied to the design and deployment of an efficient, cost effective and improved healthcare IT infrastructure , is close to what you are advocating, I think Steven. A strategy in which a solution is not locked into anyone particular vendor, which rules out the Oracle, Google and Microsoft monopolies, but matches vendor strengths and functionality to the task at hand.
Another commenter then wrote:
MSFT, Google, and Oracle would not want to "own" or be responsible for the safekeeping of the data. I expect the NHIN will end up being a decentralized network. No one will own the NHIN. The US Government will serve an administrative role.
I then added:
The GE model is close to what I'm advocating. I didn't notice any mention by GE for the inclusion of decentralized, asynch, P2P, pub/sub, mesh node networks--which I claim are essential for connecting all parties--but they didn't exclude it either.
I envision all vendors of health IT apps providing APIs that connect to the nodes, i.e., PHR/PHA apps would connect to consumer-facing nodes, EHR/EMR would connect to provider-facing nodes, and CDS (clinical decision support) apps would connect to the aforementioned apps. In addition, APIs for research-related analytic apps would connect those apps to nodes accessing the centralized NHIN data warehouse for which the Feds have the administrative role. I think this is consistent with the previous comments.
Another commenter then wrote:
The system will need to be portable, secure, and inexpensive. While I have a dog in this fight, I feel smart cards are the way things will/should turn out. The systems needs to be architected in a manner in which the data/information follows the patient - the only way to do that is to make it portable, i.e. a smart card (like most of the rest of the world uses). It will need to be secured, using the most modern web-based technolgiiues, such as PKI. The solution, we feel, is smart cards designed for healthcare.
And I replied:
IMO, use of smart cards and memory sticks are certainly part of the solution, and numerous vendors are in this niche. Inclusion of PKI is a good idea. The primary issue, I believe, has to do with determining the best ways to get the data stored in such portable storage devices (as well as in other data stores including DBMSs, XML files and delimited data files) shipped around the country as needed and accessed by any number of diverse third parts software programs. And that issue has to do with factors such as available bandwidth and connectivity, security, privacy, convenience, simplicity, and, of course, cost. I contend that the node-to-node model I'm proposing provides the greatest overall benefits in those terms.
As such, the smart card reader would be connected to a node, in the same way PCs, servers, memory cards, smart phones, etc. have their node connections. The hybrid mesh node architecture, I further contend, would be the most flexible and useful (see this link).
Where I (my company) have a vested interest is in having the nodes utilize optimally efficient delimited data files, modular data grids templates, and email (SMTP) transport to minimize resource consumption, expense, hassle, etc.
A previous commenter then added:
Many folks including GE, and many of us here are advocating mechanisms to provide an appropriate healthcare IT infrastructure...I was involved for three years on a comprehensive project at a cost of millions to build an eHealth system...The eHealth architecture was a centralized model. Cost was a major factor in this project and as I was leaving a re-think and re-planning effort was being carried out to keep the costs down. It seems that flexibility is one of the key words. I think it is terribly important to [be]...thinking outside the box. 
I then wrote:
I would want my de-identified info sent to a regional HIE and the NHIN for research purposes (at least a minimal data set). And I would consider storing a backup of my entire health info over my lifetime remotely in the NHIN, but ONLY if it was in an encrypted data file for which only I had authorized access. Then--in case I could not access by local copy of the file (e.g., if it was destroyed, if I didn't have it with me on a smart card or memory stick and my PC was unavailable, or if I was unconscious or otherwise incapciated and the ER docs needed my emergency data)--data sets that I've (previously) authorized could be extracted from that remotely stored file and sent to appropriate providers. I would want this to be done in a node-to-node (n2n) network, so that no human would have direct access to my data file, and I would also want to use biometric indicators as the universal IDs.
Another commenter then wrote:
All those involved in the management of a patient, including the patient (if compus mentus) should be able to have variable access to the patient's data. Ideally the patient should have a health manager (typified previously by the "Family General Practitioner) who delegates the relevant access to the necessary data in order to optimize the patients' management...The patient needs to take responsibility for his own health care management and thus should hold all the keys in all but emergency situations, and this is where biometrics could be used to review critical data.
My thought is that while the patient should have the option to give the GP authorization to have full and complete control of one's health data without any constraints, such global authorization is not mandatory. If a compus mentus patient refuses to allow certain data to be accessed and/or shared, even though it puts the patient in jeopardy, the patient, with ample warning and education, can still prevent that data from being used; doing so, however, would release the providers from liability and may even increase the patient's liability/cost if lack of that data results in worsening health.
Another commenter then wrote:
The NHIN concept will need to involve a lot of technologies to make it work, including patient identification, information access, information sharing, as well as data storage. Concepts including cloud computing, smart cards and/or memory sticks, mesh node networks, and many others will all play into the NHIN in one form or another.
From an historical IT perspective, there has been a long-standing conflict between the "functionally driven" vs. the "data driven" development models. My position is that a data driven infrastructure is, in the long run, more effective, secure, and adaptable. This allows innovation occurring among vendors and regions as well as the changing trends in healthcare services, patient needs, and ultimately the quality of care to be facilitated.
In my "user/patient" perspective, I want to insure that my information from care received while in the military, as well as the information I received as a child (before I even understood the long-term ramifications involved), is available to my current primary care physician and any specialists. I also want to insure that they have information that I have forgotten or may not realize is pertinent to any pending care I am about to receive.
To support this, I believe a decentralized model can be built more affordably. However, care must be made to insure that a cumbersome set of duplicated data is not created. The worst thing that could happen in the NHIN design would be allowing multiple versions of information to exist for a single patient.
Here are a few of my proposed design requirements:
1) Each provider or stakeholder would continue to have a data repository that is built for speed to allow "current care" efficiencies and reliability (the various EHR initiatives in progress today).
2) Regionally, data warehouses would be created using a common standard for the data architecture (but remaining agnostic from a vendor point of view such that in one place it may be a Microsoft solution and in another it could be Oracle, etc.). These would form the Regional HIO's and become the backbone of the HIE. The "primary" data warehouse for each patient should be located in the region where the most frequent access would occur, such as the one associated with their primary care physician.
3) To complete the NHIN concept, various applications would then be developed that would aggregate the appropriate collections of data from multiple data warehouses for the purpose of satisfying their objectives. I would assume these applications would usually exclude any patient-identifiable data. Otherwise, there needs to be a mechanism for patient authorization of access.
4) As patients travel outside of their regions, local clinics and hospitals who need access to information from the data warehouse would use applications to pull pertinent information specifically associated to the patient for the purpose of providing quality of care (this is where a smart card or some other form of secured patient access tool would be needed). Once this link is established, the regional data warehouse would pull any new data from that facility's repository.
5) If a patient makes a permanent move from one region to another, a set of applications would also exist to move (not copy) the data warehouse information from one region to another. When this happens, some form of an alert could be provided to the local systems/data repositories to place their information in an "inactive" status, or re-link it with the new warehouse.
All of the other technologies and applications associated with the Health IT Infrastructure would then be built and designed based on this model. Some may link to a specific repository associated with a single hospital or provider, relying on the link between it and the regional data warehouse for any long-term information; while others may link directly to the appropriate regional data warehouse.
And another added:
Can I throw an exception here? We have a significant number of people in the U.S. who are mentally competent legally but who either won't understand that they have control over their healthcare data or how to exercise that control, or who simply can't be bothered with it. That doesn't mean they have made the decision to relinquish control, however...Any health info policies and technical infrastructures need to take these folks into account...Poor judgment on the part of a not-terribly-bright or enfranchised patient could lead to disastrous medical care.
A commenter then added this:
I am a firm believer that the data should follow the patient and that the patient should retain control in an entirely decentralized manner. Centralizing the data in any way in the US is fraught with failure. Even in England, in a one payer system, they cannot get it done and that project is now over budget by billions of pounds.
Security is an entirely separate subject but the reality is that a username and password...is not going to work. The system will not work if people do not trust it. So trust and encryption and authentication will be paramount.
...In a smart card system, the identities of the patient (regardless of how many institutions they have been treated at) is federated on the card. The card can act as a much stronger security mechanism than anything else being proposed (offering both PKI keys, the obvious two-factor authentication model, and a photo on the card itself!), can offer portability and interoperability, is inexpensive, and is both scalable and sustainable.
And I chimed in with:
Although we've been having a largely technical discussion to this point, the last two comments reflect the need for sound governance concerning health data at rest and in transit. The point about determining if someone is able, willing and competent to make decisions about controlling the personal data, and if not, what should be done, are examples of areas for which policy and procedure are necessary. Whatever architectural models are used, they must be flexible enough to accommodate policies that may have yet to be established.
I'd like to add to the proposed design the three tier architectural requirements proposed, I believe, by CMS:
(1) RHIO / Regional HIE. (2) State level HIE. and (3) NHIN.
This goes beyond the local data stores, of course, and as I understand it, the data to be managed by each of these has to do with the relevancy of the data for certain purposes. For example, level 1 would be focused on data related to the local 'community of referral,' i.e., PCP/GPs exchanging patient data with the specialists to whom they refer, as well as data shared between hospitals and outside clinicians. Level 2 focuses on data required for public health, as well as for people in state facilities (nursing homes, prisons, etc.). And the NHIN would be focused on data for people in federal facilities, as well as nationwide biosurveillance (e.g., for communicative disease) and other things affecting public safety. I believe there's more to it, but I think this is the general concept.
The issue of what particular data sets would be managed by each tier, what data can and cannot be de-identified, the process for feeding data to each tier, exchanging data between the tiers, and issues related to privacy and security, are governance-related decisions. I'm seeking an architecture that would provide the necessary data relevant to the needs of each tier, but in a way that eliminates (or at least minimizes) overlap and (a) avoids storing patient-identifiable data in centralized databases at any of the tiers while (b) transmitting and presenting the necessary data with minimal resource consumption and cost.
A commenter then wrote:
Biometrics will obviate the need to carry data storage devises...The big hurdle will be getting historical data on file and in the format necessary to access it....Education around responsible healthcare and the results of ignorance would be cheaper for governments than adopting multiple methods and levels of responsibility taking for patients. Determining a level of "legal competence" to decide if a patient retains or loses their right to determine how their data is distributed is a difficult task and requires developing a robust test which takes into account origin and education of the individual i.e special tests formulated for different races/nationalities/religions etc
Another one wrote:
The points about corpus mentus patients: I am a familiar with a term called breaking the glass. Patients would normally make decisions about their healthcare but when incapacitated there is a policy in place to allow other clinical caregivers to make those decisions.
[The]…comments about governance and security are well taken. It would require some form of legislation to be passed that would enact policies for information privacy. Nobody wants Big Brother watching. Security is probably one of the most overarching concerns affecting the implementation of an NHIN.
From what I am reading, aggregated data which would be used for historical trending analysis and could be retained in a centralized repo whereas current data would be local and accessed only by the family doctor and other clinical specialists pertinent to patient care. There are still issues of portability where a patient's medical information needs to be accessed in locales other than where he resides. Encrypted memory sticks, node to node access etc. are options.
And this:
From a security and privacy perspective, the smart card suggestion has a lot of merit to it. The readers and updaters would have to be implemented on a national scale to allow the smart card to be read and updated anytime anywhere. Possibly something accessible through USB would be the most appropriate. With every medical visit the card could be updated with that visit. There could be software running in the provider's office to take information from office records for that patient, aggregate it, and reformat etc to fit with the electronic health record on the smart card. This approach would be simpler and is a medium that folks use and are familiar with. In terms of adding aggregated information to a national repo, providers could download software that would perform the aggregation function. That probably would be voluntary but the information would aid in formulating more effective healthcare policy.
...Also we need an electronic solution for managing drug prescriptions. There would have to be a system for the doctor to electronically transmit a prescription to a pharmacy...Again security and privacy concerns are central issues...conformance is also a major challenge in getting both clinicians and pharmacists to agree to a standard data format.
To which a commenter responded:
Your comment below is exactly what our HealthID software solutions does...We aggregate the data *using HL7 or SOAP/REST) from the HIS or EMR, make it useable for rules and workflow and CCR, and then have some very capable encryption software to write those data to the cards and federate the identities among trusted orgnaizations.
On another blog, a similar conversation was taking place. In it, someone wrote:
I think everybody can agree that patients have a right to see all their medical data and a right to decide who can see what portions of it and be notified of all disclosures of their medical records. I also think that HIPAA already mandates this...My pain point with these new proposals is...it is way too complicated...Unless, we make Internet healthcare equally simple for both doctors and patients, it will not gain adoption...One of the main reasons doctors are not jumping on the EHR bandwagon is the inherent complexity and the lack of proven hard ROI to the doctor. I submit that the same will happen with consumers and PHRs.
...The PHRs that are discussed here and elsewhere require patients to take control of the data. That means setting up the PHR, coming up with provider lists and entering them in the software with proper authorizations for various levels of access. Keeping these authorization lists current. Managing one's credentials and also family members credentials. Making sure that all is up to date. Changing authorizations to various providers and care givers based on changes in health status and on and on....
To which I replied:
It seems to me that with a little creativity and adequate field testing, PHRs can accomplish all that's required...via simple P2P pub/sub node networks.
Let's take the medical home model, for example. Every PCP (GP) establishes a community of referral, i.e., specialists to whom s/he refers patients as needed. The PCP and specialists would establish connections between their decentralized pub/sub nodes, which would enable them to exchange patient data with a few button clicks. The node-based software they use would automatically populate lists of these network connections. By using the e-mail based system I've been presenting, the lists would need little more than each specialist's name, e-mail address, area clinical licensure, and other possible metadata.
Prior to making a referral, the PCP would discuss with the patient why the referral is being made and explain why a particular specialist is being selected, just like things are currently done. Although no authorization by the patient is needed at this point, the patient may request a different specialist for whatever reason. The PCP would then click a button and the referral e-mail is sent.
Once the PCP receives the specialist's referral acceptance e-mail, the data for a CCR or CCD (or some similar data set) would be sent in an encrypted data file via e-mail to the specialists. But prior to sending it, the PCP's node software would determine which data appropriate for that specialist must be excluded from the data file based on the patient's privacy wishes. These data sharing authorizations would have previously come from the patient's PHR by having the patient's node send that information to the PCP's node at an earlier date. The patient would establish the authorizations by, for example, (a) viewing lists showing the types of data that are appropriate for particular types of specialists (and why they are needed) and (b) enabling the patient to modify the list at any time (with appropriate warnings when data elements are deselected). The lists could be organized hierarchically to ease the viewing and selection process. It would even be possible (although I don't know if necessary) to have the data set descriptions e-mailed to the patient for approval prior to routing the data file to the specialist.

Related posts: