Alix Goss

Bob Dieterle

Tim Young

Danielle Friend

Ed Martin

Jason Walonoski

Dan Chaput

Alex Kontur

 

Alex – This Tiger Team will need to define what we mean by an endpoint

  • Ed - Reference to a URI that accepts web requests and returns resources
  • Danielle – the URL that you hit to contact a system’s FHIR server
  • Tim Young – won’t just include the address. Also the identifier domain and payload types
  • Alex – Capability statement associated with a FHIR server will define possible operations, parameters, etc. that you can access through the endpoint
  • Dan – will need to scope what we mean by an endpoint
    • Ed - Are we talking about FHIR endpoints? RESTful endpoints? SOAP endpoints? A plain old webpage uri?
    • Jason – I think our scope should be FHIR endpoints over a RESTful API
    • Bob – Should we include operational endpoints that aren’t FHIR server endpoints, but accept RESTful transactions, HTTP transactions, and/or SOAP transactions where the payload is a FHIR resource? Endpoints for CDS hooks? (i.e. provide FHIR services)
      • CDS hooks implies that there has been a hook implemented in an EHR that allows you to call back to an application
      • Friend – If I’m able to receive a call from an EHR, do I have a CDS hook endpoint?
      • Event happens in EHR workflow. Gives you the ability to call out to an application (e.g. a SMART on FHIR app, a CDS algorithm). The application can access the EHR or other endpoints to obtain patient data
      • Bob - Not limited to an EHR, a hook can call anything. Could be an endpoint for a FHIR service
      • The “card” that the hook returns isn’t necessarily a FHIR resource
      • Bob – we’re looking to figure out how do I discover an endpoint to do something? The operation that happens after that is outside of our scope. E.g., EHR has to discover the endpoint for a hook service provided by a payer. I propose that any endpoint that involves the exchange of FHIR resources is appropriate for us to include
      • The only required field in the CDS hook spec is a “card”
        • Bob – still falls under our purview because the card may include a FHIR resource
    • Alex – Do we include Direct, since you can receive FHIR resources via Direct?
    • Bob – discovery implies identification w/o pre-coordination
      • Dan – wouldn’t there always be some pre-coordination, even if it’s as simple as a user registering w/your site?
        • Bob – not all endpoints require pre-registration (e.g. CMS CRD service)
      • Alix – also based on some legal/regulatory framework (e.g. knowing that a provider is part of my network)
      • Can dynamically discover endpoints, by virtue of participation in a trust framework
        • Bob – may be necessary to have applicable trust frameworks recorded as part of an endpoint
  • Bob – What other characteristics of an endpoint do we need to think about as part of endpoint discovery, e.g. who owns it, availability information, authorization requirements, what kind of payload it receives/what specific standards does it support
    • Technical specifications for connecting, authorizing, authentication. Operationally, what are the SLAs?
    • Also have to think about scalability. Endpoints are often going to have to handle bulk data efficiently
  • No labels