Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

June 19 2012

Why health IT systems integrate poorly today, and what future EHRs can do about it

Physicians, patients, healthcare providers, and other health industry participants have been clamoring for modernization of health IT systems for years. Recently, the HITECH Act, meaningful use, and other major government initiatives led by the Office of the National Coordinator (ONC) have been accelerating the demand. Unfortunately, as stated eloquently in the recent New England Journal of Medicine (NEJM) article "Escaping the EHR Trap - The Future of Health IT," health IT systems are trapped in legacy infrastructures:

"It is a widely accepted myth that medicine requires complex, highly specialized information-technology (IT) systems. This myth continues to justify soaring IT costs, burdensome physician workloads, and stagnation in innovation — while doctors become increasingly bound to documentation and communication products that are functionally decades behind those they use in their 'civilian' life."

The problem is not that engineers don't know how to create the right technology solutions or that we're facing a big governance problem. Rather, the real cross-industry issue is much bigger: Our approach and the methods we have chosen for integration are opaque, decades old, and they reward closed systems. Drs. Mandl and Kohane summarize it well in their NEJM article by saying "a few companies controlling much of the market remain entrenched in 'legacy' approaches, threatening other vendors' viability." They elaborated further on what they feel is the reason:

"We believe that EHR [electronic health record] vendors propagate the myth that health IT is qualitatively different from industrial and consumer products in order to protect their prices and market share and block new entrants. In reality, diverse functionality needn't reside within single EHR systems, and there's a clear path toward better, safer, cheaper, and nimbler tools for managing healthcare's complex tasks."

From the 1950s through the mid-1990s, systems integration required every system to know about each other in advance, agree on what data they would share, engage in governance meetings, put memoranda of understanding or contracts in place, and so on. In the age of the web, the approach has changed to one where the owner of the data provides whatever they decide (e.g., through a web server) and whoever wants it can come get it through a secure access method (e.g., through a browser or HTTP client). This kind of revolutionary approach in systems integration is what the health IT and medical device sectors are sorely lacking, and something that ONC, the U.S. Department of Health and Human Services (HHS) and the National Institute of Standards and Technology (NIST) can help promote. No amount of government money will solve health IT integration issues so long as our approach is incorrect.

As users of health IT systems, Drs. Mandl and Kohane have identified the problem of legacy approaches doing a lot of damage. What can we in the technology industry do to help? Let's take a look at the major issues holding back modernization of IT and integration of systems in healthcare, and what the government and systems owners — such as EHR vendors — can do about it.

We don't support shared identities, single sign on (SSO), and industry-neutral authentication and authorization

Most health IT systems create their own custom logins and identities for users, storing metadata about roles, permissions, access controls, etc., in an opaque part of a proprietary database. Without identity sharing and exchange, there can be no easy and secure application integration capabilities, no matter how good the formats are. ONC should mandate that all future EHRs use industry-neutral and well supported identity management technologies so that each system has at least the ability to share identities. ONC does not need to do anything new — they can can simply piggyback on the The White House's National Strategy for Trusted Identities in Cyberspace (NSTIC) that is already defined and being managed by the National Institutes for Standards and Technology (NIST).

I'm continually surprised how little attention is paid to this cornerstone of application integration. There are very nice open identity exchange protocols, such as SAML, OpenID, and OAuth, as well as open roles and permissions-management protocols, such as XACML, that allow identity and permission sharing. Free open source tools such as OpenAM, Apache Directory, OpenLDAP, Shibboleth, and many commercial vendors have drop-in tools to make it almost trivial to do identity sharing, SSO, attribute-based access control (ABAC), and role-based access control (RBAC). It's quite hard to believe, but most current enterprise health IT systems don't even support Active Directory or LDAP.

We're too focused on "structured data integration" instead of "practical app integration" in our early project phases

In the early days of data collection and dissemination (it's sad to say that after 50 years of computing, health IT is still in those early days, but it's true), it's not important to share structured data at detailed machine-computable levels. Instead, different applications need immediate access to portions of data they don't already manage. When industries take on structured data integration too early, they often waste time because they don't understand the use cases well enough to specify best-case solutions. Poor implementations result.

For example, instead of asking for HL7 (the health IT vendors' evolved standard) or other structured data about patients, we can use simple techniques like HTML widgets to share "snippets" of our apps. Widgets are portions of apps that can be embedded or "mashed up" in other apps without tight coupling. The Department of Veterans Affairs' successful Blue Button approach has demonstrated the power of app integration versus structured data integration. It provides immediate benefit to users while the data geeks figure out what they need for analytics, computations, etc.



Once app integration, SSO, identity sharing, and simple formats like JSON are in good shape, we can shift our focus to structured data integration, with all the governance and analytics associated with it. Future EHRs must master the production and consumption of secure authenticated application widgets using industry-standard approaches such as JavaScript and JSON.

We focus more on "pushing" versus "pulling" data than is warranted early in projects

A question we commonly ask at the beginning of every integration project is "what data can you send me?" This is called the "push" model, where the system that contains the data is responsible for sending the data to all those who are interested (or to some central provider, such as a health information exchange). What future EHRs should do is implement syndicated Atom-like feeds (which could contain HL7 or other formats) for all the data they can share and allow anyone who wants it to subscribe to the data. This is called the "pull" model. Data holders allow secure authenticated subscriptions to their data and don't worry about direct coupling with other apps. If our future EHRs became completely decoupled, many of our integration problems would go away. Using ATOM and JSON as formats, the Open Data Protocol (oData), which has free open source implementations, should be used to actually open patient data in days rather than months.

To make sure security and privacy are maintained in the decoupled systems, automated auditing of protected health information can be enabled by logging data transfers through use of syslog and other reliable methods with proper access control rules expressed in standards like XACML.

We're too focused on heavyweight industry-specific formats instead of lightweight or micro formats

Appointment scheduling in the health IT ecosystem is a major source of health IT integration pain (in fact, much worse than most other areas). If EHRs just used industry-standard iCalendar/ICS publishing and subscribing we could solve, based on my experience, a large majority of appointment schedule integration problems. Think about how your iPad can sync with your Outlook/Exchange server at work — it's not magic; it's an industry-neutral standard widely used and supported.

Another example of outmoded industry practice is the use of HL7 ADTs for patient profile exchanges instead of more common and better supported SAML (which emerged to meet the need for industry-neutral user identities and profile exchange). If you've ever used your Google account/profile to log into another app on another website, you're using SAML. Again, no magic. It works millions of times a day with "good enough" security and user-controlled privacy.

Data emitted is not tagged using semantic markup, so it's not securable or shareable by default

In many existing contracts CIOs have signed, the vendors of systems that house the data also "own" the data. The data can't be easily liberated because the vendors actively prevent it from being shared. The healthcare industry sets up large data governance structures where vendors are cajoled and are often begged for access to patient data, but vendors claim that it's not easy or not possible because health data is special. However, Drs. Mandl and Kohane, like me, think otherwise and clearly state "some types of data used in healthcare are stored and used in ways that are unique to the medical field, but the field is not unusual in its need to share data across diverse electronic systems." Even when systems are opened up after data governance establishes the sources and sinks of data along with specifications of data ownership rules, vendors only do the minimal tagging possible. They do structured data integration and then present information on the screen (usually as HTML), failing to tag data with proper semantic markup when it's basically free to do (no extra development is required).

One easy way to create semantically meaningful patient data is to have all HTML tags generated with companion RDFa or HTML5 Data Attributes using industry-neutral schemas and microformats similar to the ones defined at Schema.org. Using microformats and RDFa as a start, EHRs can then start tagging (in backward-compatible HTML) so that it's easier to discover metadata and allow simple securing and sharing of data. None of this is technically challenging if we really care about integration and are not just giving it lip service. Google's recent implementation of its Knowledge Graph is a great example of the utility of this semantic mapping approach. Once even basic microformats are in place with RDFa for authenticated or unauthenticated semantic tagging, we can then create SPARQL endpoints to make data easier to understand.

When health IT systems produce HTML, CSS, JavaScript, JSON, and other common outputs, it's not done in a security- and integration-friendly manner

Future EHRs should start to use industry-neutral CSS frameworks like Twitter's Bootstrap (which is free and open source). When using JavaScript, EHRs should use common lightweight and integration-friendly libraries like jQuery, instead of JavaScript frameworks that take over the app and prevent easy discovery and integration. Lastly, instead of emitting just complex XML or non-semantically aware HTML, EHRs should emit JSON from APIs so client-side applications can be easily written to take advantage of data. Also, they should be sure to offer both JSON and JSONP so that integration can occur more easily without getting into security problems, like cross-site scripting. Modern engineers who care about integration should always assume that their user interfaces (UI) might be "scraped" or connected to other systems. These interfaces should make it easy for others to securely take UI-focused data and create secure secondary uses.

All of these techniques I've mentioned are widely accepted secure web practices that need to make their way into our EHRs. Drs. Mandl and Kohane summed up the benefits of these approaches perfectly in their NEJM article:

"Health IT vendors should adapt modern technologies wherever possible. Clinicians choosing products in order to participate in the Medicare and Medicaid EHR Incentive Programs should not be held hostage to EHRs that reduce their efficiency and strangle innovation. New companies will offer bundled, best-of-breed, interoperable, substitutable technologies — several of which are being developed with ONC funding — that can be optimized for use in healthcare improvement. Properly nurtured, these products will rapidly reach the market, effectively addressing the goals of 'meaningful use,' signaling the post-EHR era, and returning to the innovative spirit of EHR pioneers."

I'll go one step further and say that the government's multi-billion-dollar incentives push won't do much if the technical methods and approaches being promoted don't match the commonly accepted, lightweight, and modern approaches mentioned above.

OSCON 2012 Healthcare Track — The conjunction of open source and open data with health technology promises to improve creaking infrastructure and give greater control and engagement to patients. Learn more at OSCON 2012, being held July 16-20 in Portland, Oregon.

Save 20% on registration with the code RADAR

Related:

May 06 2012

Principles of patient access in Directed Exchange

The Health Insurance Portability and Accountability Act (HIPPA) is good law. HIPPA formalized principles of patient privacy that should have been codified industry norms for more than 50 years (better late than never). HIPPA provided the right to patients in the U.S. to get access to their own healthcare records. The law struck reasonable balances on hundreds of complicated issues in order to achieve these goals. The law solved more problems, by far, than it created. Which is as close to the definition of good government as I can imagine. Patients are better off after HIPPA than before.

Sadly, the "letter of the law" in HIPPA is frequently either ignored or worse, fully embraced, in order to make patient access to their own healthcare data more cumbersome. This is evidenced nowhere better than Regina Holiday's experience with access to her husband's medical records. To make a long story short, she was able to acquire an unpublished manuscript of a Stephen King novel, sooner and for less money than she was able to get her husband's medical records.

Principle zero: Some clinicians will do anything they can to make patient access to their health records impossible or cumbersome.

Regina's work, detailing her experience with her husband is titled 73 cents, because that's how much it cost to get one page of her husband's medical record. HIPPA allows hospitals and clinicians to charge a "reasonable" copying fee for access to patient records. The problem with that is that in the digital age, a single healthcare record print out looks like this:

A single EHR record, printed out
A partial printout of a patient's medical record.



This is what happens when you print out a digital health record. Having patients pay the copying costs for access to medical records makes a simple presumption: there are only a few pages there. Obviously no patient will be able to afford copying costs in the age of all-digital records.

Principle one: Patient access to their own healthcare records must be digital once the record is digital.

Once you concede that access to the patient's medical record must be digital, we can discuss the push vs. pull question. When someone else on the Internet has data that is important to you, you can generally find ways to have it "pushed" to you or you can choose to "pull" it. The simplest example is the weather. You can always check the weather easily online by visiting a website (by pulling). But you can also have software text you when it is going to rain (by pushing).

There are advantages of both push and pull approaches for patient access to data. People who are excited about the pull model tend to focus on the benefits of the "portal" requirements in Meaningful Use, and those that favor the push model are excited about directed exchange. Without getting into the debate, I can posit that there are some cases where push access to patient data is critical. Without supporting patient participation in directed exchange we regulate patients to second-class citizens with regard to healthcare exchange. That is unacceptable. Patients should be first-class citizens in healthcare exchange.

Principle two: Patients should be able to participate in health information exchange as first-class citizens.

The Office of the National Coordinator for Health Information Technology (ONC) should be applauded for requiring directed exchange with patients in the current proposed rule. I hope that ONC does not back off of this new requirement.

The current proposed rule making, however, is silent on a critical issue for directed health information exchange. How do we ensure that providers will not refuse to communicate with patients over directed exchange because of bogus "security concerns"? As we see with the copying costs under HIPPA, every potential barrier to a patient's access to data will be used against patients.

There are already rumors of cases in the pilots of directed exchange where organizations are using the trust architecture of the Direct Project to refuse to communicate with certain parties. While that might be reasonable between institutions (do you really think Planned Parenthood will ever automate communication with Catholic charity clinics or vice-versa?), it is absolutely critical that this not hamper patient-clinician communication.

When we first designed the Direct Project Trust model, we presumed that patient-clinicians communication would take place based on "business-card" identity verification. That meant that when a patient provided a clinician with a public key (no matter how they did that) the clinician would trust it because the patient provided the public key. We did this because we knew that if clinicians could reject a patient's public key based on "security concerns," they would do so. Either the clinicians (or more likely the vendors that they hired) would choose directed exchange "partners" that were "approved" and "secure," ensuring that the patient's experience of directed exchange was merely a more extensive menu of patient portal options. Patient data is very valuable and controlling the flow of patient data is central to more business plans than I care to count.

In order for patients to be first-class citizens in health information exchange, they should have the right to send their records, in an automated fashion, anywhere they want. Even if it meant sending it to a service that the patient was enthusiastic about, but the clinician disapproved of (i.e. qpid.me). In the world of secure email enabled by public-key infrastructure (PKI), that translates to clinicians must accept any public key/direct address presented by a patient in a reasonable manner. This acceptance must be unconditional, but should probably mean limiting the acceptance of that key to communication with just that patient. Anything less than this means that the patient is a second-class citizen with regards to the information exchange of their own data.

Conclusion: ONC should require that clinicians communicate with a patient's chosen directed exchange provider, which means accepting any public key presented by a patient in a reasonable manner.

The community at Direct Trust is working hard to agree on what "reasonable manner" should mean, exactly. Here is my latest proposal on the subject, and here are similar ideas from Dr. David Kibbe. Eventually the Direct Trust community will knock out a firm understanding on the specific ways that might be "reasonable" for a patient to provide a certificate. But we are certainly agreed that without firm requirements on certificate acceptance, this issue will be used by clinicians to limit where patients can send their own data.

As the U.S. federal government is preparing to pay healthcare providers to adopt electronic health records (EHR) they will insist that those doctors/hospitals/etc. show that they are using the new software in clinically meaningful ways. On Monday (May 7, 2012) they will be accepting comments on the second stage of the requirements that clinicians must meet in order to receive compensation. These requirements are usually short-handed as "meaningful use."

I will be submitting this blog post as my comments to that process. Others will be submitting comments that directly contradict the principles and conclusions I write here. Most notably the American Hospital Association (AHA) has argued that the requirements for patient portals and for providing patients with access to their digital record should be entirely removed from the meaningful use standards (PDF). Specifically:

"Our members are particularly concerned with the proposed objective to provide patients with the ability to view, download and transmit large volumes of protected health information via the Internet (a "patient portal"). The AHA believes that this objective is not feasible as proposed, raises significant security issues, and goes well beyond current technical capacity. We also believe that CMS should not include this objective because the Office of Civil Rights, and not CMS, regulates how health care providers and other covered entities fulfill their obligations under the Health Insurance Portability and Accountability Act (HIPAA), including the obligation to give patients access to their health records."

This is fairly ironic, since the report also says:

"To date, OCR has received comments on its own significantly flawed original proposal to implement this section of HITECH, but has yet to finalize the standard."

Apparently, AHA is not satisfied with any government agency's interpretation of giving electronic access to patient data. The AHA would prefer that patients continue to wait the same amount of time for access to their digital records that they do for their paper records. Specifically:

"Further, 30 days are necessary to make determinations about how to respond to a request no matter the format of the protected health information. While providing an electronic copy of protected health information maintained in an EHR eventually may be facilitated more easily by technology, the process of determining which records are relevant and appropriate takes the same amount of time as it does for evaluating paper records."

Of course, this is entirely false. Indeed, HIPPA does maintain that certain parts of healthcare records (i.e. a psychiatrist's notes) and disclosures (i.e. when the FBI asks for records) are not subject to patient access. An EHR should be capable of understanding which parts of an EHR record are subject to HIPPA and which are not. If the EHR system can understand this distinction, then responses to HIPPA requests can be made in near-real-time. If the EHR system cannot make the distinction between which portions of the record to automatically provide to honor a HIPPA patient access request, then having 30 days is not going to be enough. Can you imagine a nurse reading through the entire stack of papers above to ensure that a certain mental health diagnosis is redacted?

One of the most critical features of patient participation in directed exchange is the patient's capacity to prevent the spread of bad information as it is happening. Apparently, the AHA believes that patients should tolerate the spread of mis-information in their health records to other institutions for a month before correcting it. This of course works in every situation where patients can wait a whole month to get correct information to other hospitals and clinicians.

I would like to be the first to welcome the American Hospital Association to the digital age. (Okay, maybe the second.) From a technology perspective, there is nothing at all that would prevent patients from receiving copies of their updated digital health records seconds after it is "signed" by their clinicians. Inside those seconds is plenty of time to digitally determine whether sharing with the patient is appropriate, legal and safe. Seconds after a patient like me receives data, I intend to process it in an automated fashion. It is not unreasonable, in this new digital world, for me to get a text message that a doctor has ordered a medication that I am allergic to. I wish to get that message after the doctor has ordered the medication, but before I receive it in my IV.

In this new digital world, 36 hours is unreasonable. It means that humans continue to be involved in tasks that can be performed perfectly by a computer without errors. Even 36 hours means that doctors, nurses and hospital administrators are still "thinking in paper." Thirty-six hours means that you still do not view me, the patient, as an equal data partner. It means that I am blind to the data in your hospital at the only time it really matters, which is right now. Health data that is 36-hours old can only be analyzed as a post-mortem and data that is 30-days old is already rotting. As a patient, 36 hours is a short-term solution. It is an opportunity for you to rethink how information flows in your hospitals. It is an opportunity for you to rethink the notions of "inside" the hospital and "outside" the hospital.

This is not that I do not take your point regarding the reconciliation of the policies from the perspective of HIPPA and meaningful use. Two time-lines for compliance is difficult. But the reconciliation is to speed HIPPA up, not slow meaningful use down. The notion that you will give patients a stack of paper like the one above 30 days after it is useful is a bad joke. It was a bad joke 20 years ago, when the technologies already existed to fix the problem, but you decided that the patient's experience was not worth that investment.

There is always something you can do, if you feel as strongly about this as I do.

Meaningful Use and Beyond: A Guide for IT Staff in Health Care — Meaningful Use underlies a major federal incentives program for medical offices and hospitals that pays doctors and clinicians to move to electronic health records (EHR). This book is a rosetta stone for the IT implementer who wants to help organizations harness EHR systems.

Photo: Medical record printout by jodi0327, on Flickr

Related:

February 23 2012

Direct Project will be required in the next version of Meaningful Use

The Direct ProjectThe Office of the National Coordinator for Health Information Technology (ONC) announced that the Direct Project would be required in stage 2 of Meaningful Use.

As usual the outside world knew almost instantly because of Twitter. Nearly simultaneous posts from @ahier (Brain Ahier) and @techydoc (Steven Waldren MD). More information followed shortly after from @amalec Arien Malec a former leader for the Direct Project.


There are some other important announcements ahead of the official release, such as the end of support for CCD, but this requirement element has the deepest implications. This is jaw-dropping news! Meaningful Use is the standard by which all doctors and hospitals receive money for Electronic Health Record (EHR) systems from the federal government. In fact, the term "Electronic Health Record" is really just a synonym for "meaningful use software" (at least in the U.S. market). Meaningful Use is at the heart of what health IT will look like in the United States over the coming decades.

The Direct Project has a simple but ambitious goal: to replace the fax machine as the point-to-point communications tool for healthcare. That goal depends on adoption and nothing spurs adoption like a mandate. Every Health Information Exchange (HIE) in the country is going to be retooling as the result of this news. Some of them will be totally changing directions.



This mandate will make the Direct Project into the first Health Internet platform. Every doctor in the country will eventually use this technology to communicate. Given the way that healthcare is financed in the U.S., it is reasonable to say that doctors will either have a Direct email address to communicate with other doctors and their patients in a few years, or they will probably retire from the practice of medicine.

It was this potential, to be the first reliable communications platform for healthcare information, that has caused me to invest so heavily in this project. This is why I contributed so much time to the Direct Project Security and Trust Working Group when the Direct Protocol was just forming. This is an Open Source project that can still use your help.



The Direct Project is extensively covered in "Meaningful Use and Beyond" (chapter 11 is on interoperability). I wrote about the advantages of the Direct Project architecture. I helped arrange talks about about Direct at OSCON in 2010, and in 2011, I gave an OSCON keynote about the Health Internet , which featured Direct. I wrote a commentary for the Journal of Participatory Medicine, about how accuracy is more important than privacy for healthcare records and how to use the Direct Project to achieve that accuracy. I pointed out that the last significant impact from Google Health would be to make Direct more important. I am certainly not the only person at O'Reilly who has recognized the significance of the Direct Project, but I am one of the most vocal and consistent advocates of the Direct Project technology approach. So you can see why I think this a big announcement.

Of course, we will not know for sure exactly what has been mandated by the new revisions of Meaningful Use, but it is apparent that this is a huge victory for those of us who have really invested in this effort. My hat is off to Sean Nolan and Umesh Madan from Microsoft, to Brian Behlendorf and Arien Malec, who were both at at ONC during the birth of Direct, to Dr. David Kibbe, Brett Peterson and to John Moehrke. There are countless others who have contributed to the Direct Project, but these few are the ones who had to tolerate contributing with me, which I can assure you, is above and beyond the call of duty.

Obviously, we will be updating "Meaningful Use and Beyond" to include this new requirement as well as the other changes to the next version of Meaningful Use (which apparently will no longer be called "stage 2"). Most of the book will not change however, since it focuses on covering what you need to know in order to understand the requirements at all. While the requirements will be more stringent as time goes on, the core health IT concepts that are needed to understand them will not change that much. However, I recommend that you get a digital copy of the book directly through O'Reilly, because doing so entitles you to future versions of the book for free. You can get today's version and know we will update your digital edition with the arrival of subsequent versions of the Meaningful Use standard.



I wonder what other changes will be in store in the new requirements? ONC keeps promising to release the new rule "tomorrow." Once the new rules emerge, they will be devoured instantly, and you can expect to read more about the new standards here. The new rule will be subject to a 60-day commentary period. It will be interesting to see if the most dramatic aspects of the rule will survive this commentary. Supporters of CCR will be deeply upset and there are many entrenched EHR players who would rather not support Direct. Time will tell if this is truly a mandate, or merely a strong suggestion.


Meaningful Use and Beyond: A Guide for IT Staff in Health Care — Meaningful Use underlies a major federal incentives program for medical offices and hospitals that pays doctors and clinicians to move to electronic health records (EHR). This book is a rosetta stone for the IT implementer who wants to help organizations harness EHR systems.

Related:

February 10 2012

Preview of HIMSS 2012

I am very happy to be attending the Healthcare Information and Management Systems Society (HIMSS) conference this year. We are at a pivotal moment in the history of healthcare in this country and health IT is playing a very prominent role. This will be one of the most important healthcare conferences of the year. If you can't make it to Las Vegas in person, there are opportunities to attend virtually. Just go to himssvirtual.org for more information.

I will be moderating panel presentations at the HIMSS Social Media Center on Tuesday and Wednesday. This year I expect social media to play a much larger presence in the conference, and the new location for the pavilion will put it front and center. Since the keynote this year is from one of the founders of Twitter, Biz Stone, I'm sure there will be a social media flavor throughout the event.

I will also be participating in the brand new eCollaboration Forum at HIMSS on Thursday. The Collaborative Health Consortium has partnered with HIMSS to sponsor a new, exclusive event focused on the shift to collaborative care platforms to take place at the conference. The event will focus on collaborative platforms as foundations for transformation to accountable care. Attendees will be able to learn what a collaborative healthcare platform is and why the healthcare industry needs it, discover paths to take to effectively implement collaborative technologies, and get further resources to help evaluate the solutions available in the shift toward an accountable care health model.

I am honored to be moderating a panel with David C. Kibbe, MD MBA, senior advisor at the American Academy of Family Physicians; Jonathan Hare, chairman of Resilient Network Systems; and Scott Rea, vice president GOV/EDU Relations and senior PKI Architect at DigiCert.

Our session, "Developing Trust in the Health Internet as a Platform," will focus on the tools, technologies and rules we must decide upon to establish trust in the Internet as the platform for healthcare. Effective health information exchange of any resource requires deep trust, following from the right architecture and the right rules. We will discuss efforts like DirectTrust.org and the EHR/HIE Interoperability Workgroup as conveners that are creating a community to move us forward.

My fellow Radar blogger Andy Oram will also be on hand to provide context and his own unique perspective (as well as keep me focused on what matters).

Related:

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl