Alix Goss

Bob Dieterle

Dan Chaput

Ed Martin

Jason Walonoski

Danielle Friend

Alex Kontur

 

P2 FHIR Task Force/Da Vinci Meeting at Interoperability Forum

  • Primarily a level-setting discussion, encompassing general information that has been presented on these calls
  • Still trying to understand how information will be shared between Tiger Teams

 

Testing/Certification

Bob – had a conversation w/Lee Barrett: discussed the concept of testing/certification for something with the magnitude of FHIR endpoints. Consensus that there should be an automated process by which the owner of the endpoint could validate the endpoint. Endpoint would be issued a certificate that says the endpoint was validated to do something based on a standard. May or may not expire.

  • Bob - What part of an endpoint’s capability statement should have been tested/certified? What if the endpoint is just a service endpoint and doesn’t have a capability statement?
  • Ed – for a FHIR-based endpoint…would it be possible to have an attribute about whether it has passed a specific type of testing. Trickier for service endpoints. Should the directory have a capability statement with a testing-related endpoint attribute?
  • Bob – an API has been tested…an API defined by what?
    • Ed – an implementation guide or ability to return a capability statement

Bob – assumption that there will be something in the directory that indicates that the endpoint supports something (e.g. a capability statement or IG), and that it has been tested against it

  • Jason – Seems a little weird. I can’t think of any other service where they have a certificate or attestation that they have passed some type of testing. Even if they did, would you trust it?
  • Alix – usually part of a legal obligation to do business
  • Jason – a lot of that happens out of band. It’s not dynamic discovery of whether an API complies with some API document
  • Bob – why would you not want to do that? Right now we typically have a formal process by which you prove you can do something (i.e. by joining a trust framework)
  • Ed – closest parallel I can think of is an SSL certificate
  • Bob – certificate as proof that you can do what you say you can do
  • Jason – if you are a client and you hit an endpoint, what are you going to do differently depending on whether they say they’ve passed a test or not?
  • Bob – maybe not connect at all
  • Bob – somebody has published an endpoint that claims to do something. You receive a record that is invalid or incomplete from it. Wouldn’t you want to know before you try accessing the endpoint what you are going to get?
  • Jason – the service is going to work or it isn’t.

Ed – it’s almost as if we are talking about maturity levels. No capability statement, capability statement, capability statement + testing. Point is to convey the level of trust you might have in the endpoint.

  • [consensus that directory should be able to reasonably describe what, if any, testing/certification has been passed]

Ed – is information about testing/certification updated automatically or manually?

  • Bob – would argue that we have to support both, depending on the process used by the directory

 

Other endpoint-related concepts

Bob - Does the directory maintain any kind of access token to the endpoint?

  • Ed - I would think that is something outside the scope of the directory and has to be negotiated between the owner of the endpoint and the caller

 

Bob – does the directory have to maintain information about restrictions associated with the endpoint?

  • Ed – e.g. an endpoint for mental health information
  • Bob – Let me rephrase: should everything in this directory be open to everybody, or should there be some restrictions that say “unless we know who you are, or unless you have some sort of authentication/authorizations, you cannot see/use these endpoints”
  • Ed – agree there should be an attribute like that
  • Bob – an attribute about who has the right to know this endpoint exists. Implies a need for identification. Does the directory maintain an audit of who has asked and what they asked for?
  • Jason – you have to be careful about this. Have to enable innovators that want to develop apps leveraging patient data. Don’t want to set the bar so high that people can’t access them
  • Alix – do we need to keep an audit log just to see how the directory/endpoint is being used? Foundational question: what is the directory intended to enable?
    • Bob – we will need to discuss the scope of the directory. E.g. if there is an endpoint that lets you get into the DOJ to discover information about pending actions against providers…is that endpoint supposed to be discoverable by everybody? Currently we try to protect the information that’s available, should we also protect information about how to get it?

 

Scope of Directory

Bob – what is within scope for a directory of endpoints? E.g. if we are talking about endpoints that can be used for treatment…implies that provider endpoints/any endpoint through which you can reach a clinical record are within scope

  • Ed – what problem are we trying to solve with a directory?
  • Bob – we’ve had little guidance as to the details of the problem. Overall problem is discovery of FHIR endpoints. At broadest, encompasses all FHIR endpoints. Goal is to scale FHIR-based solutions, primarily between provider and payer, but expanded to provider to provider within the context of specific use cases (e.g. advanced imaging). Basic purpose is to discover any FHIR endpoint intended to support any provider to payer use case.

Ed – who is the user of the directory? E.g business analyst, product manager, architect/developer

  • Bob – I would have said: “I’m a provider, and I need to find out if prior auth is a requirement for the patient I am seeing in front of me”
  • Ed – directory provides the definition of what can be achieved
  • Bob – (1) directory needs to define what it has so a developer can use it (2) once a developer has built that capability
    • Jason – development vs. production use

Ed – would be helpful to have specific use cases of where this would be used

  • Bob – that’s something that the Use Case Tiger Team is working on. I can provide the high-level set of use cases they are working on. e.g. use cases oriented around common themes like alerting, use cases around core infrastructure which will be reused by other use cases


  • No labels