Alix Goss

Bob Dieterle

Karl Davis

Ed Martin

Tim Young

Pavel Smirnov

Rick Geimer

Dan Chaput

Alex Kontur

 

Characteristics/Elements of an Endpoint

Authorization/authentication

  • Digital certificate associated with the endpoint
  • Identities needed to access the endpoint (including both human and system identities)
    • May have system authenticating to a system/service
    • May have human authenticating to a system/service
    • Permission requirements may look differently depending on the actors involved
  • Once you are authenticated, what do you have access to? (probably tied into the contractual framework associated with the endpoint)

What types of contractual agreements are needed to use an endpoint?

  • Karl Davis – SLA, up-time, performance

Bob – we want the ability to specify an IG that the endpoint supports. Tells the entity accessing the endpoint what the endpoint is capable of doing. Also want to be able to indicate that an endpoint’s capabilities are “certified”

  • Does that go beyond saying “I support these resources, profiles, etc.”? Are you talking about something that goes beyond the current FHIR capability statement?
  • Bob – the FHIR capability statement doesn’t indicate an IG that the server supports?
  • Geimer – actually R4 version of the CapabilityResource does have an implementationGuide element
  • Bob – There are complex operations being implemented as an endpoint, e.g. I send an Operation resource to an endpoint. Not necessarily sending to a full FHIR server, therefore it wouldn’t have a CapabilityStatement. We need a way to identify that in a directory
    • Geimer – e.g. a web service that provides a FHIR resource, but doesn’t have a CapabilityStatement. We should encourage those implementers to publish a CapabilityStatement
    • Bob – these types of “operational” endpoints may not support RESTful methods
  • Bob – what type of certification information would we want to represent?
    • Alix – legal obligations vs. testing/validation. Is this being covered by the testing Tiger Team?
    • Bob – thinking of this as testing/certification of endpoints, not necessarily the entity that maintains the endpoint. An organization may have many endpoints, only a subset of which are certified to behave a certain way
    • Most of the time when we create a relationship w/a trading partner, “certification” is understood or part of contractual obligation
    • Geimer – need to ensure ongoing certification in some cases, as well as certification against real-world environments
    • Bob – envisioning there would be a standard interaction pattern for automated testing
    • Geimer – There is a FHIR test script resource for FHIR servers. Obviously doesn’t apply to other types of endpoints. May want to consider reaching out to Mario Hyland/AEGIS about testing endpoints
    • Bob – We have the vision that Touchstone could be used for live patient data
    • Bob - Should connect w/the Testing Tiger Team for awareness. We would be where their work on testing resides. How to define, record, and make available the results of testing/certification for an endpoint. Common expectations, value sets, etc. that result from testing/certification. Should we have a conversation now?

Karl – if we are talking about a directory that lists endpoints to do standard things, what’s the point of listing non-standard service endpoints?

  • Bob – you are presupposing that everything we are talking about has an associated FHIR server. They may still be standard services
    • Bob – For example, CDS hooks don’t necessarily use a FHIR endpoint, but are quite capable of exchanging FHIR resources. Organizations would want to be able to declare those and their capabilities
  • Geimer – the Endpoint resource currently supports non-FHIR endpoints (endpoint connection-type value set)

Number of people using the endpoint (as an optional element)…when using an endpoint, it would be useful to have a sense of how many users are using it

  • Bob – how would you maintain that?
    • Most API management systems would record that type of information
  • As a business, would you really want to publish that information? Potentially proprietary
  • Bob – there may be a desire to use the number of accesses as an indicator of maturity
  • Goss – may provide some indication of whether issues with the endpoint are persistent or one time only

Alex – some indication of whether an endpoint is associated with a trust framework

  • Alix – indicates that entity maintaining an endpoint has agreed to behave a certain way…how is that different than certification of an endpoint?
  • Bob – think of it like a DURSA. Certification implies capabilities, not necessarily the rules the entity maintaining the endpoint has agreed to abide by
  • Alix – how is that different than contractual obligations
  • Bob – contracts may be at any level, physical agreements between entities. An entity may have restricted information that is only accessible via a contractual agreement. Participation in a trust framework doesn’t necessarily equate to access rights to all members of the framework
  • No labels