Alix Goss

Bob Dieterle

Patrick Murta

Rick Geimer

Tim Young

Pavel Smirnov

Jason Walonoski

Alex Kontur

 

Scaling

3 models:

  1. One place where everyone can connect to manage all endpoints
    1. Spoke & hub – one switch, route, or clearinghouse
  2. No need for one place, because we can do everything point-to-point
    1. Direct connections (not centralized)
  3. Marketplace with routing/clearinghouse services enabling entities to select which to use
    1. Regional, interconnected spoke and hub

 

Bob - When you have an intermediary in an exchange, what value does the intermediary bring to the table? (not a negative comment, but want to understand the value proposition for an intermediary in a FHIR-based model)

  • Tim Young – would a clearinghouse (CH) do any sort of transformation/normalization? Value-add to me would be reduction in implementation hours. Don’t want to have to worry about doing custom implementations with each endpoint
    • Bob – you’ve made an assumption that you have to manage different endpoints differently. Is that correct?
      • Young – yes, ideally that wouldn’t be the case
    • Bob –well-constrained profiles and testing to demonstrate support for those profiles would help make endpoints more similar
  • Geimer – many CHs will offer a service that converts to the FHIR-based model for you
    • Young – ideal to have CH interact w/FHIR services as well as FHIR servers. One endpoint where I don’t have to worry about hitting individual services
    • Geimer – would be beneficial if you could submit via FHIR and the CH could convert to something else (e.g. X12)
    • Bob – assumption is they would have everything necessary to populate and X12 transaction (Geimer – yes)
    • Bob – value is going to be one endpoint only. Translation to different standards. ability to manage operations vs. standard RESTful transactions. Managing trust issues by connecting to a single trusted endpoint and having the intermediary manage the trusted connections to others
  • Murta – CHs were developed for HIPAA transactions in part because implementing w/another endpoint is burdensome (e.g. certificate validation). Even if the transactions are standard, still need to do authentication, handshakes, etc.
    • Bob – value in managing authentication, authorization, and identity
  • Young – would CH impact BAAs?
    • Bob – If it’s CE to CE, there is no BAA requirement. Depending on definition of CH, they are a CE. If we have a new CH that isn’t a CE, would need to have a BAA, but only need one. Potentially creates complexity
  • Walonoski – CH may provide other services like patient identity management (patient matching)
    • Bob – ability to take payer’s definition of a patient and map it to a provider’s definition (e.g. MRN)
    • Walonoski – also record merging, multiple record consolidation
    • Young – is that really a service of the CH? Who is going to manage false positives/negatives
    • Jason – I believe entities like Commonwell do those things today. CH may want to have those capabilities as well
    • Bob – talking about an MPI functionality
  • Murta – also the concept of provider matching (navigating between TIN, NPI, etc.)
    • Bob – how often do you have a situation where you have a provider with both?
    • Murta – most providers have both. much stuff is processed at the TIN level when it comes to payment. CHs have some provider directory reconciliation functions
    • Young – may provide a provider directory
    • Murta – CH prompts providers to update their information (e.g. address)
  • Murta – the intermediary may do nothing but endpoint resolution to enable dynamic point-to-point exchange
    • Bob – the base use case would be an intelligent switch? (murta – yes). Similar to a telephone network…I dial a number and it gets me there, and I don’t care how
    • Murta – even more basic, I hit the directory and you tell me what to call
      • Bob – slightly out of scope, already covered under the endpoint directory discussion we’ve had
    • Bob – for me to connect to somebody else at the other end, I have to deal with authentication, identification, etc., or do I? If I’m using an intelligent switch, assuming it uses a trust framework
    • Murta - Protocol router. Endpoints deal with authentication and other things themselves
  • Bob – what’s the next thing we would want an intelligent switch to handle? I’m assuming it would be the trust framework stuff (ID management, authentication). What else?
    • Geimer – would this have something to do with FHIR versioning/conversion?
      • Bob – unclear, may not be possible to convert FHIR versions at all
    • Murta – automated voice messaging, i.e. it becomes an error handler if the side that’s being called doesn’t respond or is unable to respond.
      • Bob – is that a value-add or an inherent part of the base functionality?
      • Goss – base functionality…acknowledgement/failure message if the other end fails
      • Jason – in other words, the base has to honor the FHIR contract
      • Bob – it has to honor the endpoint establishment contract
      • Jason – If I make a request (e.g. search), it has to reply with a proper search response
        • Bob – you went a level beyond what Patrick suggested…if I ask you a question and you respond w/something I don’t understand or “static”, the intermediary does some error resolution
        • Jason – Assuming that this intermediary adheres to the FHIR spec itself. Therefore when I send FHIR requests, it’s sending a response that adheres to the FHIR spec
  • Bob – first thing we have to do is determine a valid endpoint for a particular org, provider, service, etc. (2) identify ourselves and authenticate (i.e. right to ask a question) (3) ask a FHIR question
    • Jason – in my world, the intermediary is the only endpoint I’m connecting to. They know my identity.
      • Jason – establish connection to the routing intermediary. I ask it to find what I’m looking for (e.g. information about a specific medical record). The intermediary transparently does the querying that I need.
      • Murta – my thought was that the person making the request wouldn’t issue a broad request. The intermediary would broker a connection between me and the endpoint I’m trying to connect to
        • Jason – how does it know which endpoint I want to connect to?
        • Goss – established trusted ecosystem of payers/providers that I can request information from. May not return everything you want b/c everybody may not be in the ecosystem
        • Bob – are you basically looking for HIE functionality at a national scale through an intermediary?
          • Jason – essentially
          • Bob – you are assuming there is a nationwide patient/provider directory
          • Goss – not necessarily, that information can be reconciled across endpoints
          • Young – HIEs struggle with this everyday (record location). It’s a large architecture. EMPI talking to multiple MPIs. RLS. How do you scale it?
          • Jason – so is it just providing a directory of FHIR endpoints?
          • Bob – may be federated, but it’s still a national directory
          • Murta – my thought is that we weren’t trying to have an intermediary with HIE functions like an MPI, RLS, etc.
          • Bob – let’s document this as an ideal state
  • Bob – how important is the need to translate into and out of other protocols?
    • Geimer – depends on who you ask. For providers that already feel their IT budget being squeezed, they will probably feel it is very important. Likewise, new providers to this space (that don’t have an X12 infrastructure and may want to use FHIR instead)
    • Bob – how many providers have an X12 infrastructure as opposed to using a CH that has an X12 infrastructure?
    • Goss – When I think about FHIR, I think about clinical data, not payment data
      • Jason – FHIR includes EOB, claims, other financial resources
      • Bob – generally starting to see merger of clinical and administrative data. Current state is more siloed, but next phase is increasingly integrated
    • Bob – Do you envision providers as having one way of consuming/expressing information (i.e. FHIR), or multiple ways and we need a way to bridge provider-provider differences
      • Geimer – expect that different providers will have different capabilities. Would like to move everybody to FHIR, but that’s not likely in the near-term. Reality is that there will be different standards used (CDA, FHIR, X12, etc.). Important to include conversion capabilities, but I don’t think we can consider it a requirement. Considered a value-add service…CH can provide it at a cost that’s less than managing it yourself across many different endpoints
      • Young – one issue is that there is so much data in narrative (e.g. in CDA), how do you translate that to FHIR
        • Geimer – relatively easy, because FHIR resources can have narrative
  • Bob – 3 models: no intermediary, single intermediary, hybrid w/multiple intermediaries as well as point-to-point. Not hearing anybody supporting a pure point-to-point environment.
    • Goss – we’ve focused on intermediaries, haven’t necessarily discussed pure point-to-point. Hearing that we have to potentially support all of them because there is too much variability
      • Bob – They are mutually exclusive. Hearing only support for a hybrid/mixed model. There are some people that believe we will get to a pure point-to-point model using FHIR, but I’m not hearing that from this group
    • Alex – is the internet a mixed model, or primarily point-to-point?
      • Geimer – Google is like a lightweight intermediary providing directory services
      • Murta – argue that the internet in its purest form is point-to-point. Not necessarily intermediaries that route the traffic once you discover the address. Some lightweight services on top

 

Bob – next week, would like to discuss endpoint detection and scaling in the context of which organizations we consider important to addressing them

  • No labels