Bob Dieterle

Alix Goss

Danielle Friend

Jason Walonoski

Patrick Murta

Alex Kontur

 

Summary of Initial Requirements

Themes

  • Alix – Final theme (80:20 rule) is particularly important to note
  • Bob – Deliverables from the other Tiger Teams will likely have implications for our work. We may want to discuss how their goals/deliverables might guide our work.


Requirements - Directory Assumptions

[“Supports information exchange for Treatment and Administrative purposes”]

  • Alix – does “administrative” exclude payment purposes under HIPAA?
    • Bob – administrative includes things like coordination related to who is in an ACO, quality measures that aren’t tied to an individual. Not directly related to treatment, but important for value-based care
    • Murta – from a payer perspective, administrative typically refers to X12 transactions/claims
    • Jason – are we excluding anything?
      • Murta – classic X12 transactions themselves
        • Bob – e.g. claims submission, remittance advice, and other HIPAA transactions
        • Jason – why exclude x12 transactions? FHIR has mechanisms to support them
          • Murta – the X12 versions are specifically out of scope. Not saying that the FHIR representations are out of scope

[“Pre-condition of patient and provider identification information readily available”]

  • Danielle – Should this assumption reference another P2 FHIR tiger team?
    • Alix – like the identity tiger team?
    • Danielle – yes, is the work they are doing going to meet our needs? Is there a dependency on another Tiger Team (if so, we should note that)?
    • Bob – we assume patient/provider identification have already happened. Not in the scope of this tiger team to solve the issue
  • Jason – what about situations where there isn’t a patient, e.g. eCQMs based on a population or cohort?
    • Bob – let’s add a “when necessary and appropriate” to the statement

[“CDS Hooks support for CDS services”]

  • Bob – CDS hooks for CDS services should be accommodated in the directory
    • Goss – some discomfort with this topic re: how far we get into operations
    • Murta – good to call out, since CDS hooks may not be FHIR services

[“Support of both fully automated process and those requiring human intervention to support response generation”]

  • Goss – realize that we have a goal of fully automated, but we may need a glide path to get there

[“Existence of test and production environments”]

  • Bob – may need a way to indicate that an endpoint is a testing endpoint rather than a production endpoint. Providing a way to discover them via a directory
    • Murta – typically in this space, you would also have the ability to onboard (e.g. onboarding to BlueButton sandbox). Should we call out that onboarding should be painless, and that availability of test data is required
      • Bob – not seeing a role for a directory to support that, but we can note the comment. If there is a standard approach to onboarding (e.g. passing a digital identity), may need to find a way to represent the approach in the directory. E.g. here is a test endpoint, it supports a particular onboarding mechanism

[“Costs will vary by model and entity type architecture choices”]

  • Goss – there was a comment in a meeting about costs on both ends related to use of FHIR services, and that cost is going to depend on implementation/architectural choices
    • Bob – I’d suggest we move both the support for mixed models and the costs related bullets to the scaling section. May want to add a new concept here: Useful to tell whether I’m connecting to an endpoint owned by the organization maintaining the endpoint or by an intermediary service

 

Requirements - Directory Trust & Legal Aspects

  • Bob - Directory needs to accommodate different legal/trust models
    • Bob – related to conversation about public data vs. proprietary data
    • Goss – how much do we want to try to create standardization around trust/legal frameworks?
      • Bob – suggest we change “legal” to “regulatory”
      • Goss – how do you differentiate between legal and regulatory frameworks?
      • Bob – e.g. HIPAA, which is a regulatory framework. We create trust frameworks in which we agree about how we will operate with each other. Trust agreements are not purely legal, e.g. they also often include operational requirements. Agree on the things we will do, how we will treat information we receive/provide, how we will protect data, etc.
      • Bob – add DURSA as an example of a trust framework
  • Bob – expect to have IGs or implementation guidelines for a number of things (e.g. testing, acknowledgement responses, authentication, authorization, etc.)…what will a directory need to do to support them
    • Bob – will need to come back to “downstream uses of a payload” à is it out of scope?
      • Goss – what do I have in my operational data store? What version is it? Do I need to provide it in response to another query?
      • Bob – should be moved to the versioning section

 

Environmental scan

  • Bob – spent some time discussing exemplary/important industry services to understand. Discussed both directory services and scaling services. Looking for volunteers to take the lead on writing up a high level overview of each of the organizations we determined were highest priority. Will spend some time next meeting discussing what type of content to include in the one-pager
  • No labels