Wes Rishel

A member of the Gartner Blog Network

Wes Rishel
VP Distinguished Analyst
12 years at Gartner
45 years IT industry

Wes Rishel is a vice president and distinguished analyst in Gartner's healthcare provider research practice. He covers electronic medical records, interoperability, health information exchanges and the underlying technologies of healthcare IT, including application integration and standards. Read Full Bio

Coverage Areas:

Web Services: What’s In a Name?

by Wes Rishel  |  January 30, 2010  |  4 Comments

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

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.”

4 Comments »

Category: Healthcare Providers Interoperability Vertical Industries     Tags: , , , , , , , , ,

4 responses so far ↓

  • 1 Walter Sujansky   January 31, 2010 at 2:31 am

    Great post, Wes, I think one can find some interesting answers to your 4 bulleted questions by looking at how HealthVault and GoogleHealth implemented web services, particularly in their interactions with large trading partners such as Clevelend Clinic and CVS/Longs. When I last looked at this closely, neither was using SOAP, per so, although HealthVault was using an XML-based message protocol, while GoogleHealth’s was much more RESTful (based on its gAtom interface model, which is used for interoperability inGoogle Calendar, gmail, and its other applications that offer “business-to-business” APIs) These interfaces, therefore, were defined in a proprietary manner largely by Microsoft and Google, although each has been able to get other large trading partners to use them. It would be interesting to probe further why neither of them used SOAP… Nevertheless, neither is likely to become the de facto standard for other kinds of interoperability (lab-to-practice, practice-to-pharmacy, practice-to-practice, etc.) – Microsoft and Google can’t even agree with each other on a single way of doing this…

    As far as the right terminology to distinguish “attended” vs. “unattended messaging,” I’ve thought about this myself and can’t say that I’ve found a satisfactory nomenclature. One pair of terms I’ve heard is “browser-based” versus “business-to-business”, but that doesn’t encompass all of the examples of either “attended” or “unattended” transactions. Another candidate terminology used in the security literature, is the notion of a “front-channel” communication (“attended”) versus a “back-channel” communication (“unattended”). For example, these terms are defined in a document I read recently outlining various ways of providing federated identity (http://www.kerberos.org/software/kerbweb.pdf ):

    • Back Channel: this describes transactions between service providers that occur directly, without relying
    on user-wielded tools (typically, although not exclusively, a web browser) to act as an intermediary.
    E.g. an e-commerce site interacting directly with a user’s banking site, without re-directing
    communications through the user’s web browser. These transactions may either be invoked in
    response to an action performed by a user (for example, logging into a service provider) or be
    initiated automatically by software agents.

    • Front Channel: this describes interactions between service (and identity) providers occurring
    indirectly via a user-wielded tool – typically, although not exclusively, a web browser. These
    interactions are normally invoked in response to an action performed by a user. For example,
    attempting to access a “protected” web page, and being asked to login at one’s identity provider as a
    result.

    • Front and Back Channel combined: this describes interactions that involve elements of Front and
    Back Channel activity (for example, a Back Channel transaction that is authorized using a token that
    was established previously in an earlier authentication event while the user was online).

    These terms seem to be currently used most often in discussions of federated identity and single sign-on mechanisms (esp. involving SAML authentication assertions), but perhaps could be generalized if they capture the distinctions between “attended” and “unattended” communications that you have in mind. One key distinction seems to be whether a human user needs to authenticate for the communication to occur. Another may be whether a human user needs to explicitly initiate the communication. I guess in defining the right terms that capture the distinction between the concept of “attended” and “unattended”, one has to ask what the operational implications of the distinction are and how these implications influence the design of an infrastructure to enable interoperability… i.e., does the distinction matter with respect to addressing, authenticating, authorizing, formatting, logging, etc. of health information exchanges?

    By the way, our discussion the other day brought to mind Albert Einstein quote, “Everything should be made as simple as possible, but not simpler.” ;-) Probably a good litmus test for the kinds of H.I.T. interoperability solutions we’re both trying to design.

    Regards,

    -Walter

  • 2 Wes Rishel   January 31, 2010 at 2:51 pm

    Thanks, Walter. It will be interesting to see where there are commonalities with the work you are doing to help define an HIE architecture for California.

    I am wondering if we shouldn’t first divide the world of transactions into “unitary” and “composite.” Once a channel has been established a unitary transaction involves a single exchange, either sending information and getting an acknowledgement or making a request and getting the information back. At that point the channel could be closed and the mission would have been accomplished. Composite transactions are designed to involve sequences of unitary transactions in order to accomplish a mission. Web browsing is usually complex because you get a page and follow a link to another page in order to accomplish your machine. Searches are composite transactions.

    It might seem convenient to equate unitary with unattended and composite with attended transactions. With a person at the helm the notion of processing the information from the first response to decide where to click next, or what fields to fill-in in the follow-up response is obvious. However we know that Web services of all flavors are almost always designed to support composite patterns of interactions which is why the standards include state machines and ladder diagrams. Web Services was really designed to support that level of complexity.

    Simple interop is a game of finding a subset of all communications that can be rolled out quickly and provides enough value that end users will want it. (Meeting Stage-1meaningful use criteria is a proxy for “enough value.”) Under that premise we have further decided to focus on a limited set of queries on the basis that queries require a protocol that is complex enough to establish trust on some role-based level.

    Our goal is to keep the trust model “off-channel” implying that there is no need for the programmatic and protocol complexity necessary to mediate trust as parte of the transaction. It is easier to determine trust off-channel by a person answering the question, “do I trust this organization well enough to send some specific piece of PHI to someone there?” than it is by a person answering the question “do I trust this organization well enough to let any of its users browse all of my data?”

    Through this chain of thought I am working to limit simple interop to “pushed” messages and inquiries that represent a pushed request that is processed by a person who then pushes a response.

    The gamble that I am making is that this subset of all useful communications meets Einstein’s rule.

  • 3 Walter Sujansky   January 31, 2010 at 5:10 pm

    Wes, I believe our thinking is highly aligned, with one significant difference: I believe that the minimal trust infrastructure requires trusted authentication of the “principals” to HIE transactions (my term — see below) , not just authentication of the information systems that they use (i.e., “Internet Health Nodes” — your term) . Given the prevalence of “phishing” and other malicious spoofing behavior on the internet these days as well as the need for organizations to fastidiously log/audit HIE transactions, I am concerned that health care organizations will not accept pushes or pulls of PHI that don’t include some trusted authentication of the organization, department, or specific user involved in the transaction. I don’t believe that digital certificates for registered Internet Health Nodes will be sufficient for that, especially when those nodes are legally distinct entities from the organizations sending or requesting the PHI (e.g., the case of a server owned by an IPA or HIO that is handling transactions on behalf of a specific physician practice).

    Hence, I think there is a need for trusted authentication assertions of the *principals* that are initiating HIE transactions, assertions that are distinct from the trusted authentication assertions of *health internet nodes* provided by TLS. If I’m understanding the simple interop model correctly, the digital certifications assigned to health internet nodes are the only authentication assertions used in the simple interop model. In the model we’ve been considering for California, there needs to be, in fact, three different types of assertions that correspond to the three different levels of “identity” required for trusted communications of PHI:

    1. Information Systems [analogous to "health information nodes" in your model]. These are nodes on the internet that can be reachable (“addressable”) from any other system that wishes to exchange information. These nodes must be registered in a trusted repository (along with their digital certificates) that is accessible via a web-services interface. Some widely trusted body(ies) must be responsible for provisioning and credentialing these nodes and revoking credentials when appropriate. The digital certificates and private keys assigned to these nodes are needed to support mutual authentication, encryption, and integrity protection when health information is transmitted “on the line” from point A to point B. They will enable nodes to fulfill the security requirements of meaningful use related to authentication, encryption, and message integrity. [NOTE: I believe this type of identity is roughly identical to the "Health Internet Node" in your conception]

    2. Legal Entities [analogous to "health domain names" in your model, I think]. These are organizations (large or small) that are willing to take on the legal responsibility for provisioning, credentialing, and authenticating their users, departments, and other *principals* that may engage in HIE transactions [see below], as well as for publishing accurate directory information about the addresses to which certain transactions should be directed and the protocols/standards that the information systems at those addresses support for the transactions. These entities must also be registered in a trusted repository (along with digital certificates) that is accessible via a web-services interface, and they must also be provisioned and credentialed by a trusted body. The purpose of these identities is to *sign* various other artifacts that are part of transmitted messages and are needed to enable trusted communications. These artifacts include authentication assertions for the principals engaging in HIE transactions (under our assumption that entities will be authenticating principals themselves, rather than through a centralized identity provider), authorization assertions that indicate the role of the principal with respect to the subject and the purpose of the information exchange, and directory entries that bind specific principals to the addresses at which and the protocols/standards with which they can process specific kinds of transactions.

    3. Principals [analogous to "user names" in your model]. These are the “senders of record” and intended recipients of HIE transactions, which may include persons, departments (such as EDs or clinics), or data repositories (such as immunization registries or PHRs) . They must each be associated with a specific legal entity, and their identities must be unique in the context of that entity (although not necessarily globally – e.g., a physician may have different identities within different organizations). Entities must maintain registries of their principals that include certain minimum attributes and must be responsible for authenticating their principals. Note, however, that principals need not be provisioned, credentialed, or authenticated by a trusted third party — it is sufficient for them to be provisioned, credentialed, and authenticated by a legal entity that has, itself, been provisioned, etc. by a trusted third party. The purpose of “principal” identities is (1) to provide entries in searchable directories that allow data trading partners (people or systems) to identify and locate intended recipients, (2) to provide information about principals that enables the recipients of HIE transactions to make authorization decisions, and (3) to provide a record of the principal that provided or requested information for purposes of logging and audit.

    With these three types of identities as first-class objects in the trust infrastructure, it seems a number of desirable properties are conferred:

    – Only information systems and legal entities need to be globally registered (i.e., provisioned and credentialed) in the trusted registries. Principals may be provisioned, credentialed, and authenticated by entities or sub-parts of entities, as long as there exists a chain of trust back to the registered legal entity. Directory entries for principals can also be asserted by entities or sub-parts of entities, as long as there is a chain of trust back to the registered entity.

    – Entities or sub-parts of entities can sign authentication assertions and authorization assertions included in individual transactions, as long as there is a chain of trust back to the registered entity. These assertions (assuming they’ll be trusted by counterparties), may be used as the basis for access-control decisions as well as logging/auditing. Although the recipient of an HIE transaction will not authenticate the principal itself, nor will a trusted third party, the legal entity that did authenticate the principal will authenticate itself to the receiving party via its trusted registry entry and will have directly validated (sign) the assertions about the principal which access-control decisions are made.

    – HIE transactions intended for a specific principal may be sent to a third-party system that is responsible for its ultimate delivery, as long as the third-party system is a registered information system. The identity of the third-party system may be different than the identity of the intended recipient (principal) and the third-party system can forward the transaction in whatever way is appropriate to reach the information system of the principal. Because the various authentication and authorization assertions that have been made about the sender (principal) are included within the transaction (rather than solely part of the TLS handshake between the sending and receiving systems), access-control decisions and logging can be performed at any point along the way based on the information in these signed assertions.

    – Legal entities can publish directory entries on behalf of their principals, with no need for a trusted “central” body to validate the directory entries. It’s the legal entities’ responsibility that the entries they sign are correct, that the addresses in the entries are registered information systems that are routable, and that the protocols/standards in the entries are supported by the addressed information systems. Directory entries must be signed by the entities with which the referenced principals are associated, (i.e., the principals to whom the directory entry corresponds) and if entities trust each other to publish and maintain their directory entries correctly, they will trust that the entries are valid (i.e., they won’t be concerned that intentionally bogus entries are in the directory).

    This model is certainly less simple than the one you propose, since it necessitates the need for signed security assertions within HIE transactions (e.g., using SAML or a similar language). However, it provides two additional levels of authentication beyond the mutual authentication of information systems provided by TLS (specifically, formal identification of the *principals* to HIE transactions and trusted authentication of the *legal entities* that are vouching for the principals’ identities). It is open to debate whether these additional levels of authentication are needed for the M.U. stage-1 “push” transactions. I believe they are because, in their absence, there will remain sufficient fear, uncertainty, and doubt about the risk of phishing-type attacks, as well as insufficient trust in the information that entities need to log for each HIE transactions. I’m very interested in your thoughts on this, however, both from the perspective of necessity and near-term feasibility..

  • 4 Tweets that mention Web Services: What’s In a Name? -- Topsy.com   February 1, 2010 at 11:47 am

    [...] This post was mentioned on Twitter by Brian Ahier, Tim Sturgill, Wes Rishel, HealthIT Policy, Anthony Guerra and others. Anthony Guerra said: RT @wrishel: Last big issue for simple interop: computer-to-computer messaging. Web services or no? http://bit.ly/aubxy6 #healthIT #EHR #MU [...]