Alix Goss

Bob Dieterle

Rick Geimer

Dan Chaput

Alex Kontur


Directory Tiger Team assigned solutions:

  • Endpoint discovery
  • Resource version identification
  • Guaranteed message delivery
  • Standards-based endpoint access


Solutions Document

Alix – last week, Tiger Team reviewed first draft of the solutions proposal template & documentation. Based on Tiger Team leads call, templates were updated and assigned to Tiger Teams. We have been asked to try writing up one of our solutions by July 15

  • Bob – we are supposed to take what we have already worked on [listed in the Problems to be Solved section] and start proposing solutions


Bob – I don’t think we ever saw the “guaranteed message delivery” capability from the use cases

  • Alex – it was assigned to us in the capabilities chart. Are we supposed to design solutions to the barriers we identified or the capabilities from the use cases?
  • Bob – last week we talked with Patrick about solutioning the barriers


Bob – unclear what is the difference between “endpoint discovery” and “standards-based endpoint access”


Guaranteed message delivery

  • Geimer – will need to differentiate between RESTful (w/real-time errors and ability to retry if there is a failure) vs. asynchronous. We haven’t talked much about reliable messaging protocols yet
  • Alex – I think it’s referring to finding a provider’s information/endpoint for sending messages
  • Bob – you have to assume there is an intermediary for it to make sense. And if there is an intermediary, we’re really talking about scaling
  • Geimer – we could say something like “if you require guaranteed message delivery, here are the protocols that support it” and if you are using REST, “here is how you would do it”
  • Bob – that’s not a scaling issue though. Guaranteed message delivery is an intermediary problem…through an HIE, a clearinghouse, etc. We’ve discussed intermediaries in the context of scaling. We don’t have protocols that support end-to-end delivery through an intermediary. This is subsumed into our scaling solution
  • Alex – are you considering something like a HISP an intermediary?
    • Bob – yes, anybody that sits between the originator of a message and the intended recipient
    • Alex – specifically pertaining to the message? Not ISPs or the like? (Bob – correct)


Bob – the use cases never dealt with scaling

  • Alix – they had difficulty estimating the scope of the use cases


Bob – capabilities for synchronous/asynchronous transactions are assigned to the Exchange Tiger Team, but it’s really an intermediary issue. The purpose of the Exchange Tiger Team is if we have an intermediary, what information is necessary to do message routing?

  • Alex – they are mostly a content focused group?
  • Bob – consider the transaction header…if I’m a provider connecting to a payer and I know the endpoint, I don’t have to worry about much else. But if I have an intermediary, they are they endpoint. How do I tell them what the real destination is? What metadata do I need to include so they can handle the necessary routing. May be true of a payer as well, if they present a single endpoint for prior auth but reroute the transactions to third-parties for specific transaction types
  • Alex – so are we talking about FHIR as the delivery mechanism or the content of the message? If we are referring to FHIR APIs, I’m probably just writing to the API not using an intermediary
  • Bob – if you are pushing a message, you have to deal with routing. Even pulls have to deal with routing because I might connect to a single endpoint (e.g. for the HIE or CH) and expect to be able to reach anybody else inside
  • Alex – I’m questioning how guaranteed message delivery fits into an initiative that is specifically looking at using FHIR to do things. If we are using the API side of FHIR, there is no intermediary. I’m just writing to the recipient’s API
  • Bob – unless you want to maintain the ability to access thousands of endpoints, an intermediary can still simplify the process. When dealing at scale, intermediaries are essential. May be easy to find an endpoint to write to, but much more difficult to manage permissions and access credentials for each. There are ~30k provider systems and 1800 payers. The large payers deal with most providers…do they really need to have the ability to individually connect with each one?
  • Alix – similar to the point-to-point EDI connections in the 80s/90s…nobody wants that overhead
  • Bob – intermediaries also provide validation, trust framework, etc. Capabilities like message delivery, asynch/synch transaction support, etc. are scaling challenges. We’re dealing with problems like what do you need to do if you need a real-time response from an intermediary, what if trust frameworks need to be established? The Exchange Tiger Team is looking at the content necessary to make it work
  • Bob – FHIR doesn’t necessarily preclude the use of an HIE. Some HIEs are using FHIR
  • Alex – but they are all using FHIR for queries as opposed to message delivery. The query and push paradigms are usually separate for HIEs. The ones looking at FHIR are still typically sending messages using other protocols
  • Bob – Josh Mandel and Argonaut are doing work on Subscription, which requires an intermediary. If I want to simplify connections, and I have an EHR that is generating alerts for a care team, I want to be able to give those alerts to an intermediary. The intermediary subscribes to the alerts, and the recipients subscribe to the intermediary. The intermediary acts as an exchange in the middle so a single EHR doesn’t have thousands of users subscribing to it
    • Alex – doesn’t the Subscription model say something like “I have updated data, come query for it”
    • Geimer – it can also push the data…there are various channels (e.g. REST hook, web sockets, email). You can subscribe to something and receive a notification that it’s updated, or you can specify that you want the payload in XML or JSON. This is being redesigned under the Argonaut subscriptions project, to allow you to receive notifications when something was deleted. Creating a new resource called “Topic”
    • Alex – How is the payload delivered?
    • Geimer – depends on the channel, e.g. if you do a REST hook it’s in the body of the POST. The email channel isn’t well specified, some have implemented as an email attachment, others in the body of the email, others don’t include the payload at all (i.e. human readable notification to look for the updated data). The Argonaut project is focused on REST hooks and web sockets, the email channel will need additional work
    • Alix - Are we still triggering off of the patient/provider combination or identifiers?
    • Geimer – Currently trigger off of a FHIR search string. The Topic resource is supposed to allow for more complex search criteria. Adds functionality but doesn’t remove any
    • Alix – pub/sub model in the HIE world requires a trigger mechanism to create linkage
    • Bob – the new model removes significant functionality… EHR declares “here are the things I will alert on/you can subscribe to”. Before it was an open-ended query string, which is being removed. E.g. you can subscribe to the creation/change of an encounter, along w/specific additional filters such as patients w/a particular insurance or patient’s age
    • Alix – EHR set what filters/notifications it supports. As an end user you have to check those, understand your system’s capability, subscribe to them, and deal with an intermediary in the middle
    • Bob – the intermediary actually removes complexity, e.g. for every entity the intermediary subscribes to, I can ask for info whenever one of my members is admitted, discharged, or receives a new medication. Up to the intermediary to detect what I want and route it to me. Substantially reduces the burden on the EHR and subscriber


Proposed solution - Endpoint discovery/directory services


Current state

  • No single place to identify/locate endpoints (multiple places, e.g. Sequoia, Commonwell, HIEs, DirectTrust)
  • Amount of information associated with an endpoint varies dramatically depending on the source of the information
  • Each source of endpoint information has its own implied trust framework
  • Degree of audit and currency of the information varies tremendously
    • No initial/recurring validation of endpoints (to ensure endpoint is compliant with FHIR spec)
  • Method of access to endpoint information (i.e. a directory) varies tremendously
  • No current ability to utilize an intermediary for routing to specific endpoints


Bob – not aware of any directories or FHIR endpoints that describe what types of services are available (not simply a CapabilityStatement), e.g. an operations endpoint

  • Geimer – should be included in the CapabilityStatement, what other info do you need?
  • Bob – If have a FHIR operations endpoint to submit claims, I can’t necessarily ask for a CapabilityStatement
  • Geimer – what do you mean by a FHIR “operations endpoint”? You can have a FHIR endpoint that allows PUTs/POSTs on Claim resources. If you want a custom operation to do something like auto-adjudicate claims…should be in the CapabilityStatement
  • Bob – you are assuming there is a full FHIR server behind the endpoint
  • Geimer – not necessarily a full server, but assuming that the endpoint for processing a resource is compliant. If we’re not talking about a RESTful FHIR endpoint, it could be any arbitrary custom API that accepts a FHIR resource, and therefore has its own rules
  • Bob – but there is no directory that will tell you that. E.g. a CDS endpoint. May not be a conventional FHIR endpoint, but you can send/receive FHIR resources. What do you consider that?
  • Geimer – not a FHIR endpoint, rather a CDS service. It isn’t something you query, rather it takes a specific POST in a specific JSON format. The documentation for a CDS service to receive a hook is a custom API (per the CDS hooks specification). Assumes the ability to go back to a FHIR server to query for more data


Bob - Do any directory services today allow you to discover an endpoint for a specific provider (or only for an organization)?

  • Geimer – Sequoia is based around organizations
  • Bob – if I know a provider, and I want to find their endpoints…they might work in multiple places. I’d have to discover the provider’s relationship to those places and then ask about the place
  • No labels