Wes Rishel

If anyone things that nerds are unemotional, they need only go to a standards meeting. The notion of using web services to support reliable computer-to-computer messaging gets as much passion from the partly-informed as did the demotion of Pluto.

After looking into this I confess that I have added to the confusion. As I have learned, a big part of the confusion is because people don’t mean the same thing when they say “web services.” It’s a bit like a fan from Manchester, NH and a chap from Manchester, England arguing about “football.” For example:

1. To some a web service is any service that can be obtained computer to computer using HTTP.
2. To some, a web service must at least use SOAP.
3. To others, it ain’t a true Web Service unless it is architected like the diagram below
4. Finally, there are those that also require the WS-* protocols.

Web Services Architecture

The Wikipedia article cited above attempts to clarify the set of choices by describing the world as being divided into two camps “RESTful Web Services” (number 1, above) and “Big Web Services” (all other combinations, including numbers 2, 3 and 4). This probably represents the main two camps in the nerd wars very well, but it is clear that the advocates of the RESTful style of architecture would not gladly accept into their camp everyone who confines their use of protocols to HTTP. For example, those that use only the HTTP commands but hide other commands in the URIs are mere pretenders, trying to make their approach look RESTful-ish but not legitimate claimants to all the benefits outlined in the Fielding dissertation.

Rather than some up with a taxonomy of names I think a better approach to Simple Interop would be to look at the capabilities needed to support  computer-to-computer communications outlined in Simple Interop: Issues Associated with Automatic Processing and, for each item on the list, answer these questions:

• Is this capability that Wes dreamed up really necessary for simple interop?
• Is it being done already enterprise-to-enterprise  healthcare apps on the Internet?
• If not in healthcare is this capability being provided broadly in other enterprise-to-enterprise apps that use the public Internet?
• If the capability is used, how much is based on standards and how much is defined ad hoc pair wise or in larger groups by the dominant trading partner?

Almost by definition any encrypted, reliable communications with scalable authentication (X.509 certs) based on “just HTTP” is going to match up with the fourth bullet.  To adopt a bilateral or  dominant-partner specification we need to have some consensus that would permit ONC to recognize it as a standard. I hope to find an approach that is, at least, used with a bunch of trading partners in production. If so, perhaps others will agree that adopting it would be the most expedient way to roll out simple interop to support the meaningful use interoperability measures.

I am explicitly staying away from a separate question, “what standards are available?” My rule is, if you want to pick something that will roll out quickly, pick something that has already been rolled out.

Digression on the term “Computer to computer messaging.”
This term also creates confusion. Aren’t all communications computer to computer? Isn’t a user in a Web browser or a thick client using a computer? What we are really trying to describe is a message that is sent without oversight by a user. So a lab technician approves the instrument result for the last test in a battery and then instantly moves to the next test in a different battery for a different patient. Sometime later the LIS transmits the results to the physician’s EHR, but there is no person in the lab watching it.

This is a lot different than the situation where that same technician is using on-line banking to change his postal address. Typically after one pushes the submit button the browser window goes dead until the bank has sent back another page saying it has accepted the transaction. In the latter case we have a person watching to see that things went well and, presumably,  willing to push Submit again or start over if some disruption in the Internet connection causes the transaction not to succeed.

Another term we have though of is “unattended messaging.”

Sir Blogsalot has written quite a bit about the idea of simple interoperation, each post developing some aspect of the idea.

Recently I combined all the ideas in a single PPT presentation. You can download it by clicking here to leave the Gartner Blogs web site and then clicking on the link to the presentation.

It will come from my personal web site for two reasons.

• I offer it under a creative commons license that allows you to use it as you wish, including incorporating it in commercial material.
• Gartner’s policy for blogging is not to post files in formats that might be dangerous. My laptop seems well protected by and my web site is maintained by a seemingly reliable ISP but I urge that you use the same precautions that you would or should when downloading any Office document — just in case.

There is some new material in the presentation that is not in any of the previous blogs on the topic. This includes:

• An idea about structuring the roll-out into “quick” and “extensive” phases with the quick phase hopefully sufficient to meet the minimum interoperability measures for Stage 1 of the criteria for receiving the meaningful use incentive. The “extensive” phase is more scalable.
• Discussion of the relationship to disease registries.
• Expanded use cases cast in terms of the meaningful use requirements.
• A discussion of business opportunities for open source and proprietary providers of technology, hardware and services.
• Some open issues are cited.

After you have reviewed the presentation I would love to hear your comments added to this blot posting. You are free to re-use the presentation as you wish, but I would appreciate a comment here, an email or a tweet letting me know how you are using it.

Kudos to Motorcycle Guy (aka Keith Boone) for Implementation Technology Specifications. It puts in context four separate efforts to simplify the XML representation of clinical information in HL7 Version 3 and CDA and to achieve a RESTful URL. I know I speak for a lot of people that have the greatest respect for the precision with which clinical data is represented in its V3 products but feel the transparency of the resulting XML is an important barrier to adoption.

One hopes these efforts include a program of diet and exercise that is effective in reducing OID metastasis.

Through Clayton Christiansen’s work on disruptive technology we learn that designing for the high end of the requirement space is far from being a bonus that tops off a good design effort. It introduces nearly gratuitous complexity that makes the product more complex and therefore automatically less accessible to the majority of the market. OIDs are a clear example of such high-end design.

I applaud my many friends in HL7 for taking this on and Keith for finding the time to participate and report on it in such a lucid manner.

After publishing “It Takes a Region:” Progress Without EHRs I received an email from Alan Glaseroff updating me on the current state of the chronic disease efforts and the proliferation of EHRs, which is now up to 41% by physician count. With his permission I am including portions of his email here:

We did use C-DEMS (open source) as our registry but have used PECSYS from Aristos the last 5 years or so. It is proprietary, but allows us to customize (we have great programmers). We are also implementing an e-referral system called IRIS across the whole county and will use it to create a master patient index (the Holy Grail of regional health care data).

Over the past year EHRs have struck in Humboldt with a vengeance, mainly in the FQHCs and other safety net clinics. Open Door Community Health Centers (6 sites) are on EPIC via the Portland-based Oregon Community Health Improvement Network (OCHIN).  The tribal clinics are on NexGen. Mobile Medical has ECW. One large private practice is on Allscripts (Eureka Internal Medicine) and another (Eureka Family Practice) has Practice Partner. There a few others in the specialists offices… so now we are at 41% penetration by physician count (not by practice, as the small offices haven’t yet succumbed). EHRs have only helped the registry because we have figured out how to extract data by creating reports that access the “back end” and pull out what we need (mostly weekly, some more often). We may be the first to solve this without very costly real-time interfaces. So the registry is alive and well (and results continue to improve dramatically – our IPA ranked in the top group for statewide P4P (one of 2 IPAs to achieve this in a world of well-resourced staff model multispecialty groups such as Kaiser, Sharp Rees-Stealy, Health Care Partners, and the Palo Alto Medical Foundation).

We believe we can reach most of the physicians not on EHRs. Our plan is to get them to turn ARRA incentive $ over to us. We will do (or subcontract for) the installing, training, system maintenance. [The project approach will get them] to meaningful use. … I’m hopeful the model will become more patient-centered and system-focused, rather than viewing practices as stand-alone entities.

The model for small practice EHR installation comes from the Tulare initiative undertaken by the California Health Care Foundation (CHCF). We will borrow their approach.

What lessons should I take from this new information? First off, I am prouder than ever to be in this County and to have this opportunity to sneak in some boosterism.

I would argue that it was the early community health and P4P successes that engenders cooperation that will create the specific kinds of interoperability that impact patient care. This shows that interoperability begets interoperability. Such begetting is not a technical phenomenon; it is a social one. Achieving some success makes it easier to talk about more efforts. If Alan is successful in getting physicians to assign incentive payments to cover his program it will be in part because of pre-EHR, IT-enabled successes.

I will be delighted if the Simple Interop approach enables other communities to build P4P and other capabilities without tying their success to universal roll-out of EHRs and the creation of a full formal HIE.

This is a sermonette on what can be accomplished absent EHRs and an HIE when there is a a strong leader in a leadable community.

In It Takes A Region CD-Rom: Improving Chronic Illness Care the Robert Wood Johnson foundation proselytizes work it sponsored on regional approaches to managing chronic disease by the Wagner model. I reside in Humboldt County, one of the two rural counties that comprise the region in the title. Indeed, I am proud to say that the strong leader featured in the CD-ROM is my own physician, Dr. Alan Glaseroff.

With nary an EHR in site the Humboldt Diabetes Project has brought down the A1Cs of at-risk diabetics, more than doubled follow-up on and achieved these improvements in the SP-12 scores of diabetics in the study.

Humboldt Diabetes Project SP-12 survey results.

The only Health IT enabler has been a Web-based community version of the open-source Chronic Disease Electronic Management System (CDEMS) registry. Physicians that started using it for diabetic care have extended their interest to other diseases.

In part, it has been seeing the work here that has directed my interest to interconnecting the community of physicians that have EHRs and the rest of the healthcare world. I actively support the roll out of EHRs and the full-bore, carefully managed exchange and look up of patient information through HIEs. At the same time the success of Alan and this community makes it clear that IT-enabled progress does not need to wait and it will be necessary to support the interface between the two communities for many years.

In Simple Interop: Use Cases we have made a somewhat unorthodox proposition, to support mixed communication between people and automatic computer processing programs. We have done so because of the issues raised in Rant on Heath Information Technology Asynchrony . This proposition entails solving some issues. For example, what if

• The email is never delivered to the recipient?
• The email is delivered but cannot be processed?
• The email is delivered but some of the attachments cannot be processed?
• A recipient later claims it never got a message and cannot be liable for not having acted on it?
• A sender later claims that it never sent a certain message, so it cannot be liable for erroneous contents?
• Some of the attachments associated with the message don’t contain a structured patient ID? How do we know they are all about the same patient? Is there a way to allow the same message to contain information about different patients?
• An automated message is routed to a recipient that is a person and needs some context to understand the messages.

There are probably other issues as well, and I look forward to hearing about them in the comments to this posting.

We believe that there are straightforward solutions to these issues that can be introduced without greatly adding to the amount of new technology that must be introduced to get started with this approach.

In Simple Interop: Use Cases we set the challenge of communicating among people and Health IT systems in a manner that does not create a “walled community” where all those that practice with EHRs and HIEs have no ability to use the Internet to communicate with those that don’t. The biggest challenge in such a mixed environment is dealing with structured data. We posit that the structured data will be transferred as file attachments.

First we will review the basics of how file attachments and multimedia are packaged in the Internet protocols for email and Web posting.

MIME Provides the Package
The Multipurpose Internet Mail Extensions (MIME), which are used to send attachments in email, Although MIME was originally conceived for email it has proven a very versatile protocol, entirely independent of the protocols that specify mail transmissions. It is now used to upload or download files to or from Web servers.

MIME is also what enabled the transition from plain text email to HTML message. As I described this in Rant on Heath Information Technology Asynchrony the transition was accomplished by the simple ruse of having the sender send both a plain text copy and an HTML copy in the same message, and letting the receiver decide which to display. We propose a similar approach to breaching the walls between the “walled communities.”

Structured Data as File Attachments
Our basic approach is simple. The secure emails that are sent from one healthcare organization to another can contain free form text and structured data in file attachments. To use MIME for structured attachments it will be desirable to obtain Internet media types from the IANA in order to assure that browsers and email clients can use the files uniformly across operating systems. Internet media types are also called MIME types or content types. They are registered strings that indicate what kind of data is in a part of a MIME package. Some existing Internet content types are image/png, text/html and application/EDI-X12. Until the content types are obtained experimental content types are available.

Processing Structured Attachments Files
Transmission can be initiated by a user in an email client or any other program that can generate email, including EHRs or components of them.

In general we do not presume that the sender knows how the receiver will process the file. Receivers will process incoming messages in one of three ways.

The message will be viewed by a person who can read the plain-text portion of the email and may have “viewers” for some of the attachments. Viewers are programs that such as Acrobat Reader that are easily installable on client systems and display file attachments for a person to read. We postulate the availability of open source viewers for all healthcare structured formats specified as a required capability for meaningful use. Nonetheless, there is no guarantee that the recipient has viewers for all the attachment types that the sender can create. If a few researchers around the country have developed a novel way to represent gene networks or some yet uninvented bit of medical data, we want them to enable to secure exchange of patient data in this format so that industry can easily get an experience base on which to base solid standards.

From time to time, the situation will arise where information sent to a person cannot be read by that person. It can’t be represented in plain text, perhaps, and the person does not have and cannot download a viewer for the file. We accept that as the price of progress and expect the communicating parties to work it out, probably using fax or PDFs.

On the other hand, we believe that if there are viewers are available for all the standards that EHRs are required to generate or accept for each stage of meaningful use, and if physicians use PDFs for reports, EKG strips and other unstructured data, and if DICOM viewers are available we believe the level of actual interchange of structured data will rise substantially with the simple interop approach.

The message and attachments will be viewed by a person and then passed to an EHR to be added to the patient record. This depends on the EHR software providing the user with a way to present the data to the EHR. We don’t care to standardize how this happens although we will note that the user functions in general will require the user to aid the EHR in matching the data with a patient. Some EHRs may compete by making this easier for users. For example, they could examine the structured data for patient identification information and use that to accelerate the search needed to match the data with existing patients.

The “user name” portion of the health email address is not associated with a person. The email represents a transaction that goes direct into the workflow of the receiving system. For example, a health email address such as labs_in@medinfo.yubapeds.com might examine the file for structured attachments that the EHR understands for lab results. The EHR might attempt to use order number or an automated patient lookup to match the report with existing patients. Upon success it might store the data in the EHR and set up an alert for the ordering physician to review the labs. If the EHR fails to find lab attachments, finds other attachments that it cannot understand, or cannot match a patient the message would go into a workflow queue for a staff person to deal with it.

Adding HIE and Other Special Services
We can envision a number of special services built around systems that are not EHRs For example in Simple Interop: the PHR we describe a way that PHRs might use the user name part of the health internet address to file incoming information for the consumer.

The original recipient could be a system that relays a file, adding value. If the incoming email address were lab_routing@medinfo.YubaHIE.org, then the HIE might look up the ordering physician, choose to deliver both to labs_in@medinfo.yubapeds.com and it might amend the message to add the specific patient ID that Yuba Pediatrics uses for the patient. If the message indicates that a copy should go to a consulting physician it may be able to resolve the location of the physician from the info in the report and send the message as email or a faxed printout according to the capabilities of that physician. If the message was a positive report that must go to public health it might automatically deliver the message to public health.

Ensuring Standard “Standard File Attachments”
We expect that certification programs contemplated as part of ARRA will assure that EHRs can produce and consume standard attachments. We would like to see ONC use its influence, funding and authority to also ensure that file viewers for the standard attachments are available free for all major technology suites. Ideally these viewers will come from open source communities. A certification process could ensure that a specific communities’ viewer is more than “demoware” and installs easily. Such readers could be certified as “components” of EHRs although they are likely to be used in facilities that don’t have fully certified EHRs.

Enabling New Ideas in Structured Data
We also advocate the use of non-standard structured attachments. Indeed, we don’t think it is practical to avoid their being used in an environment that supports person-to person communications. To minimize the impact when two parties interact we advocate some policies that allow such experimentation to flourish. These include

• Using the plain text part of the message to identify the purpose and type of the structured file.
• Encourage that file viewers be produced as part of projects that create non-standard formats

These policies cannot be rigidly enforced. On the other hand, the notion of readers is widely accepted in the Internet culture.

Frankly, we hope that our approach will encourage experimentation and trial implementations of proposed new standards. We would love to see future standards become Federal imperatives only after they have been implemented and provided out inside a secure Internet infrastructure.

Such experimentation may lead to the development of interactive applications better implemented over HTTP rather than SMTP. This is no problem, our simple Interop approach is a secure shell that can incubate RESTful applications as well.

Upward Compatibility in Standard Formats
When I wrote the original specifications for HL7 version 2 I included an approach that ensured the best possible interaction between two systems running on different point releases of the standard. Under that approach:

• If a system that had upgraded to a new point release received a message from a system using the old point release, it processed that data from available in the old release and assumed “undefined” for new data items. Depending on the application it may not be able to function with undefined data but most of the times it could.
• If a system that had not upgraded received a message from a system that had upgraded, the receiver would ignore the new data. Because it had not upgraded it could not possibly need that data to fulfill its functions.

Although the HL7 v2 standards were created following this discipline it was seldom used in the field. Care delivery organizations relied more on mapping in their interface engines instead. As we scale interoperability up from connecting a few hundred systems within a large CDO to tens of thousands, it is time to revisit this principle.

Wrapping Up
This pretty much wraps up a series of posts that have evolved as the idea has grown through discussions in comments and email. There are still many loose ends, the most important of which are addressed in Simple Interop: Issues Associated with Automatic Processing.

We look forward to hearing your thoughts on this through comments. You might consider this important question, after you have read the Interim Final Rule on meaningful use, produced by ONC. Should our Simple Interop approach be put off until Stage 2 of meaningful use certification, or could it be considered a voluntary way of meeting the requirements for Stage 1?

This post zeroes in on exactly why the simple interop approach is important. It does so by listing a number of use cases. They illustrate the issues of getting to interoperability while an industry is in transition – and are industries ever not in transition?

We are mindful of the specific kinds of interoperability required to obtain incentive funds under the ARRA. The regulation is available at this time here. Our approach is directly applicable to all of them except ePrescribing. However our approach is also mindful of one of the main challenges of going able from being able to interoperate to actual interoperation. To make the most use out of interoperability provided to EHR vendors it will be necessary to interoperate with many healthcare organizations that don’t have EHRs. (See Rant on Heath Information Technology Asynchrony for more specifics.)

Use Cases
We expect the simple interop approach to handle both person-to-person communication and the automated transmission of information from one information system to another. Some examples of these two modes of communication are listed below.

1. Doctor A sends a secure email to Doctor B, an attending physician at the local ED, about a complex patient who is rushing over. Docs A and B both have EHRs but there is not yet HIE in their town to connect them or they are signed up with different HIEs.
2. Doc A sends the same secure email to Doc B, but Doc B does not have an EHR.
3. A physician sends an email to a patient (at his health Internet address) about the patient’s case
4. At the close of each encounter, an EHR automatically sends a summary to the PHR designated by the patient.
5. Upon discharge a patient asks that the discharge summary to be sent to her home physician in another state; she has the physician’s health email address in her address book.
6. After and ED visit for breathing difficulties a mom asks that a summary be sent to her son’s pediatrician. She is able to provide the name of the physician and the town where the pediatrician practices, but is not sure of the name of the practice. The ED staff is able to find an unambiguous entry in a health Internet 411 service but it is not clear whether the pediatrician has an EHR or not.
7. Upon reading a preop treadmill ultrasound a cardiologist needs to send the report to the surgeon and the primary care provider, and to the patient. The patient and his PCP live in a rural county across a state line a different medical services region than the cardiologist and surgeon.
8. A patient is brought to the ED with severe cardiovascular symptoms. The patient says he was treated six weeks ago at another hospital. The other hospitals is not connected to an HIE. The patient gives consent to get the records from the other hospital, so the local ED staff calls the hospital. Over the phone the ED gives the other hospital information to identify its healthcare email address and the records are sent from the other hospital’s EHR to the ED which adds the contents to its EHR. Some of the contents were sent as structured data including a patient summary and others of the contents were textual reports with the minimum structure necessary to identify the report with the patient and give the type of test reported.

These cases are similar in the following respects.

• Communication occurs across healthcare organizations
• It is likely that the two organizations will be at different levels of adoption of healthcare information technology.
• It is desirable to send structured data when possible
• It is desirable to send human-readable information when it is not possible
• It is tedious (in fact impossible) for one HCO to keep track of the status of another with respect to its ability to use structured data formats.

We submit that these are the real challenges of actually achieving interoperability about a lot of patients for a lot of healthcare organizations over the next four years.

Our next post,   Simple Interop: The Payload describes how to exchange structured using the simple interop approach.

This blog was amended on 7 January 2010 per user comments.

Here is some pseudo XML.

<joke style=”jocular, but with a purpose”>There are these two young fish swimming along and they happen to meet an older fish swimming the other way, who nods at them and says “Morning, boys. How’s the water?” And the two young fish swim on for a bit, and then eventually one of them looks over at the other and goes “What the hell is water?” (From David Foster Wallace, novelist, speaking at Kenyon College, 2005.)</joke>

The water in the healthcare IT pond is the slow and asynchronous adoption of new technology. We know that small healthcare organizations are slow to adopt new technologies and large organizations adopt new technologies slowly.

The ARRA money and a certification program for EHRs can make a bump in the adoption curve. However, we know that not all providers are eligible, not all hospitals are eligible and not all generators of important clinical data (such as labs) are rewarded by the incentive program. We know that not all those that are eligible will take advantage of the incentives.

We expect that the incentive-bump will create a ripple of adoption of interoperable HIT. We hope the ripple will be a good-sized wave. The wave will ultimately reach those not directly incented in the program, as they find it in their interest to interoperate with those that adopted because of the incentives. The same ripple wave will ultimately bring along those who chose not to pursue the incentives in the first two years.

So what’s the big deal? Slow adoption of technology is as obvious as, um, water.

The big deal is interoperability. Compound adoption curves apply. If 2/3 of the HCOs in the country have reached a certain level adoption the probability of intereopration for any given transfer of information is 4/9=44%.

Changes to standards are rolled out by vendors and self-developers in release cycles, and most release cycles take about three years to reach 90% roll-out. With those parameters after one year 11% of sites could interoperate on the new standards. The number is actually a lot lower because the vendors will release new versions of their product at different times.

These numbers could improve as more clients by remotely hosted EHRs and if vendors release interoperability changes at the same time for all clients for a fee included in the maintenance or subscription fees. These improvements could occur over time but that is a long-term consideration.

The big question is what happens to interoperability among EHR users that are on different versions of the standard? Many of the readers of this blog will remember a time when Internet email clients only supported plain text. Nowadays most email clients support HTML. This change did not happen by everyone switching over from plain-text to HTML mail clients. It happened through new readers being developed that sent both plain text and HTML. Old clients read the plain text continued to write plain text. A new client, when receiving a message from another new client was able to display the decorated text in its full glory. However it could still understand and display text from old clients. My recollection is that the period of transition from the point where < 10% of Internet email users had new clients until the point where > 90% did probably took more than 10 years. It might have taken longer except that the vast majority of current email users started during the transition period, thereby getting new email clients to start. Early users of hand-held email devices benefited from the “dual-mode” because the devices were made simpler by not having to support HTML.

It must be the same in healthcare as it was for email clients. New releases of software that embody new standards must not shut down interoperation with other older releases of software.

This post seeks not to define the full scope of interactions of a PHR but simply to define a simple connection between PHRs and other health IT systems. We make two claims for this approach. (1) it greatly simplifies the roll-out of connections between PHRs and other healthcare IT systems, thus accelerating the roll-out of EHRs that can meet anticipated requirements for meaningful use in 2013; and, (2) the combination of this link with our other simple interop proposals comprises a national health internet for the U.S. that allows substantial progress unimpeded by the slow pace of the resolution of policy issues around information sharing.

In our definition we provide a minimalist definition of the PHR, taken from the ARRA. We don’t begin to describe the advanced capabilities that could be built on such a record. A PHR is characterized by giving control of personally identifiable information to the consumer or someone using the PHR on behalf of the consumer. As an exemplar Gartner clients can read my November 2007 analysis of the Microsoft HealthVault privacy policy at Microsoft HealthVault Is One Important Step Toward a Workable Personal Health Record. However we do not rely on anything specific to Microsoft or any other vendor in these definitions. We are satisfied to know that consumers are willing to trust the vendor of whatever PHR they choose.

The PHR limits sharing of the consumer’s protected health information (PHI) to those transfers where the consumer has given explicit consent. Such transfers can be incoming to the PHR or outgoing to another health IT system. The transfers may happen one-time or the consumer may give consent for recurring transfers. The PHR need not enforce most jurisdictionally-specific requirements for limiting data exchange. Explicit consent from the consumer trumps most of those requirements.

There is the opportunity for those that offer PHRs to be endlessly creative in finding ways to provide value to the consumer based on her accumulated health information. Whatever their full value propositions it seems likely that they all have to include solutions to certain problems:

1. Receiving information about the consumer from multiple healthcare organizations (HCOs) and associating that information with the correct consumer (even though each sending organization has a different ID for the consumer)
2. Delivering information to authenticated healthcare organizations as directed by the consumer, identified so that the receiving healthcare organization can file the information properly by patient.

We would like to encourage the developers of PHRs to enhance their business value by designing new ways to interconnect with other health IT systems. New ways will often involve proprietary interfaces. At the same time, we believe PHRs should support a simple, “least common denominator” interface that is very easy for developers of EHRs to implement. Such a common interface is a necessity if a substantial number of EHRs will be able to implement connections to the PHR of the patient’s choice in 2013 in order to meet expected requirements for meaningful use.

The approach specified in Simple Interop: The Health Internet Node provides a straightforward way to provide standard support for these functions. The key to this approach is the the  health email address. It is an Internet email address for which the domain name is a health domain name. The user name is assigned arbitrarily the organization that operates the health Internet domain. There is no a priori reason to believe that wrishel@BigBoxStore_clinic.com, wrishel@StJosephsEureka.org and wrishel@MyFavoritePHR.com are the same purpose or to know for certain that any of them has the last name “Rishel.”

All operators of PHR would agree to certain premises for communication of protected health information. They need not agree to use this approach to the exclusion of other communication approaches, but the one described here would be common to all PHRs.

The PHR would

• Have a health Internet domain for the purpose of accepting email transmissions from and sending them to other health Internet domains.
• Assign health consumer emails addresses from their health Internet domain to the subjects of personal health records. (Sidebar, this is not always the user of the PHR, since the user may be a parent, adult child or other representative of the consumer)
• Allow subjects to have multiple email addresses concurrently while keeping a common record of information collected for the subject via multiple email addresses.
• Allow subjects to discontinue the use of any of their email addresses in the PHR domain upon request.
• Accept incoming email according to the rules for a health Internet node (TLS and only from other healthcare domains) and file the information contained in the mail in the PHR of the subject related to the email address.
• Accept instructions from authenticated PHR users to send selected information about the subject to another health Internet address (presumably that of a healthcare organization).

All the points above about multiple health email addresses for a subject combine to meet two goals: (1) to enables people to assure that their health email addresses to not constitute an ad hoc key to all their protected health information; and, (2) it enables users to deal with a compromised health email address with no more difficulty than dealing with a compromised credit card number.

How Relationships Are Established
Patients that use PHRs would have established a health Internet address associated with the PHR. They would give this information to their healthcare provider. The healthcare provider could use it to exchange secure email with the patient. It could also use it to dispatch specific or recurring reports of visits to the PHR of the patient. Hopefully these payloads will be structured to the maximum extent practical but we wouldn’t rule out simple email messages typed by the physician and PDFs where they made sense.

PHRs receiving the information would rely on the security associated with health Internet nodes to affirm the sender of the document.

Providers that are able to receive information from PHRs would, at a minimum be able to give their health Internet address to the PHR vendor when giving consent to send information. In following the guidelines we describe for a health Internet link they would confirm that the receiver has a current, unrevoked digital certificate each time they use TLS to send information to the domain name in the provider’s health Internet address.

Emergency Health Summaries
We are trying to avoid dictating or assuming what functions would make business sense for providers of PHRs Nonetheless, we have to mention that many of them will want to support the release of information under circumstances where the patient cannot get on-line to give consent. They could be being treated for problems that interfere with their dexterity. They could be being treated in a location where consumer Internet access is not practical. They could be unconscious.

Once a patient has authorized the PHR operator to release information under such extraordinary circumstances, we can imagine any number of ways that a vendor might decide to accept the authorization. The user could carry a card with a freely accessible URL for the PHR, the consumer’s PHR-issued health Internet address and a “break the glass” authorization code that is only valid for a short period after it is first used.

The vendor could accept faxed requests showing a copy of the card and then go to some lengths to verify that the request came from a valid provider. We can imagine that some vendors would offer better (and more expensive) services such as a key fob barely bigger than a USB port that automated connecting to the PHR operator’s portal and uploading the patient’s identity information. Cell-phone pictures of bar codes on the card come to mind. The point here is not to specify standard gadgetry but enable the market to settle on some that provide a reasonable value proposition.

As the notion of Simple Interop grows PHR operators will likely find it convenient to print on the card a health internet address for incoming requests, such as emergency@medinfo.biggerbetterPHR.com.

The CDO might email in the request from ED@medinfo.humongousuniveristy.edu.

When a CDO chooses to use simple interop email the PHR vendor may use the fact that the request came in from a valid a valid healthcare domain name as part of their rationale for determining that it is okay to send the information.

Likewise, PHR vendors can vary in terms of what information that patient can pre-authorize for transmission. One might offer a specially constructed summary of problems, meds, allergies and the names of CDOs that have treated the patient. Another may offer the most recent report that appears to be a patient summary.

We expect that most vendors that include “break the glass” service in their value proposition will want to be able to send the information to CDOs with as few preconditions on the IT capability of the CDO as possible. As such, they will no doubt offer delivery modes that include fax and display on a browser for printing.

As the notion of simple interop expands we would expect they would also find it convenient to deliver the information to the health email address of the CDO and to deliver it in a multipart format that allows it to be viewed and printed, but also allows those CDOs with suitable EHRs to import structured data into their system.

This exemplar of a patient-carried emergency access card illustrates multiple uses of the health Internet address, one for the patient and one for the PHR operator that provides the emergency information service.

To repeat: we are not suggesting or prescribing specific PHR approaches to this important function. We only mean to indicate how simple interop would evolve into a key alternative for facilitating the interactions, particularly as the ability to work with structured informational attachment becomes widely available.

Nationwide Health Information
This blog post creates linkages between two domains of health information sharing that are separated by the manner in which consent to share information is managed. By definition PHRs exchange information when authorized by the patient or his agent. The other information-sharing domain that we have described is for secure exchange among healthcare organizations where the sender relies on external means to determine that the receiver should legally receive the information.

We have used the fax machine as an analogy for information sharing in this second domain, but of course we mean to imply that, unlike faxes, the information being shared can also be in standard structured formats such as those described in the interim final rule Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology. (As of 30 December this IFR is “on display” at this link. It is expected to be in the Federal Register on 13 January.)

Linking these domains together with few other restrictions provides broad opportunities to establish interoperability without making assumptions about the availability of intermediary organizations. Where an HIE is established it can work as a proxy for a healthcare practice, providing the health Internet node for communications. At the same time the HIE may provide many other value added services to a community.

Where an EHR vendor provides systems to small practices it can operate a health Internet node on behalf of their customers.

If it makes business sense a hospital or an ISP may work to qualify themselves to operate a health Internet node and provide services to physicians that only have email or Web support.

Where other policy concerns require the full complement of IT services defined by the NHIN Trial Implementation project there should be no barrier to using those protocols. In the long run, because they offer more complex ways of resolving consent and other policy issues and more security they could come to be the approach chosen vendors and users of health IT.

These relationships are illustrated in the figure below.