Alix Goss

Bob Dieterle

Patrick Murta

Karl Davis

Pavel Smirnov

Danielle Friend

Rick Geimer

Alex Kontur

 

[Bob recapped goals/structure of the P2 FHIR project & Directory Tiger Team. Please see previous notes and/or slides for more info]

 

Endpoints (How can a provider or payer identify the appropriate FHIR endpoints and the specific “services” they support for P-P exchanges?)

Vision

  • Karl Davis – are we assuming that providers already know the identity of other providers? (e.g. What if the patient is unconscious?)
    • Geimer – If we have a layer of FHIR services, we may be able to query to discover those relationships. Will need to determine whether there is a single point of entry, or whether we first have to discover who/where someone is and then locate their endpoint
    • Murta – Currently, the use cases start with the assumption that we know something about the patient (e.g. their relationship to a payer/plan); I know who I need to talk to, find me the appropriate endpoint for the type of information I’m looking for. The use cases are not focused on discovering information about who/where the patient has been seen
    • Bob – knowing only who a patient is (based on their information), is it possible to discover the endpoint of their payer and/or providers?
      • Geimer – If the organizations have endpoints related to them, and those organizations are related to the patient through other resources, then yes it is possible (assuming use of a FHIR API)
    • Murta – Karl’s original question hasn’t been defined as a use case. Not saying it should/shouldn’t be
    • Karl – We may be punting on an important/difficult problem if provider discovery isn’t a use case
    • Bob – implies a need for a national directory of patients/providers (could be federated or centralized)

Research

  • Karl – how many payers are there in the US?
    • Bob – roughly 1800
      • Karl – 1800 isn’t a very large number, it’s entirely conceivable that some future regulation might require each payer to provide a directory type service for patient lookup
        • Bob – directory services would only cover currently insured individuals
        • Goss – also wouldn’t cover ability to get clinical information for self-pay
        • Bob – likewise, there are other things you can’t disclose due to privacy rules

Standards

 

Scaling

Vision

  • Bob – there will be one place that everyone can connect to for managing all endpoints
    • Danielle Friend – acts as a router that tells me where I need to go depending on what I’m looking for
  • Bob – there will be no need for one place to connect to for all endpoints (everything can be done point-to-point)
  • Davis – there is a middle option as well, where you have a marketplace of “centralized” routing/clearinghouse services
    • Goss – similar to the approach being taken [under TEFCA]
    • Bob – have there been fundamental changes in technology that make clearinghouses obsolete? Putting a clearinghouse in the middle creates a cost…is that cost offset by some other benefit (e.g. only having to connect to one or a few places). Compare to the banking industry (which doesn’t have entities in the middle)
      • Karl – there are actually some middlemen in the banking industry to translate APIs for consumer needs
    • Goss – historically, one size does not fit all. What about the small or mid-sized entities that don’t want to manage the problem on their own and prefer to connect to some middleman
    • Karl – is there is a history of clearinghouses for payer-payer connections?
      • Bob – the clearinghouses we typically think of are payer-provider. They were created because there wasn’t a standardized format for claims…they became translators. If every payer/provider had to implement a named x12 standard themselves (not through a business associate), would we have clearinghouses? One of the reasons we have them is because nobody is required to implement the standard, except for the clearinghouses themselves. Entities may communicate with a clearinghouse in a non-standardized process. They serve primary purposes, translator and router. If we require FHIR to be standard at the endpoints, we no longer need translators
      • Karl – would have to be standard version of FHIR, and a conformance test kit
      • Bob – in the past, we never required the endpoints to conform to a standard. Has that fundamentally changed?
      • Geimer – are we talking about once and done certification, or real-time validation of live data? Big problem early on w/CDA was that validation was only on test files for certification. Real-world data often didn’t validate against schemas.
      • Karl – indicates the importance of service level agreements. It’s not useful if I can find an API and it isn’t “up” a significant portion of the time
  • No labels