Bob Dieterle

Alix Goss

Jason Walonoski

Rick Geimer

Tim Young

Patrick Murta

Alex Kontur

Regulatory Barriers

Patient identifiers

• Bob – unless you have a deterministic approach to patient matching (e.g. a unique ID) vs. a probabilistic approach, will be difficult to accurately match patients. Unfortunately, deterministic approach probably requires legislative changes. Therefore, we should identify the risks associated w/not having a deterministic approach.
  • Jason – industry generally supports a single patient identifier, therefore we should make that recommendation
  • Alix – deidentification methods don’t even work particularly well anymore, can essentially derive a single identify from deidentified data given modern computing techniques
  • Bob – Do we need more powerful protections around using healthcare information (e.g. can’t use it for employment, wages, coverage eligibility, etc.)? Inadvertent release of information may have a social impact, but shouldn’t have a functional impact
  • Alix – permitted uses has more importance in today’s landscape than in the past
  • Bob – in some cases we already have single patient IDs (e.g. Medicare, Medicaid, DoD/VA) and we haven’t experienced widespread abuse

Data blocking

• Bob – as we increase volume of transactions through APIs, cost increases as well. Could become a barrier to implementing and scaling
  • Alix – increasing transactions/exchange over APIs will help prevent data blocking, e.g. makes it easier to identify/address data blocking if an entity doesn’t offer an API
  • Bob – 3 data blocking issues, mostly concerned about the third: won’t let you connect to me, won’t give it to you, will give it to you but only for a fee
    • Murta – not just per transaction costs, but other indirect costs as well (e.g. user must provide stipend for infrastructure)
    • Bob – we are reasonably comfortable that the first two issues are addressed in the current/previous rules
    • Murta – concerned about the timing of onboarding…service providers have the right to recoup costs of building infrastructure. Therefore, early adopters will be punished
    • Bob – what if an entity outsources API services to third party. Are fees charged by the third party covered by the rule? E.g. connecting to a hospital participating in Commonwell. What if they charge a fee because Commonwell charged them a fee? Have to consider actual costs for data holder and any intermediary…implies that entities like clearinghouses can’t charge a premium. Have to ensure that intermediaries don’t become cost barriers (via “outsourcing API”)

Landscape analysis

Murta – compared one pagers to identify common items

• Dimension – which TT issue was it about (directory, versioning, scale)
• Segment – what part of the market do they operate in (e.g. consumer vs. healthcare)
• Relevant service – what do they do now or in near term that can inform what TT does
• Synergies
• Cross-pollination – what other TTs do they support
• Clients – who does the entity target

Apple

• Does everything at scale
• Leading consumer hardware, software, and app developer (i.e. has the supporting infrastructure)
• Use of FHIR for consumer services
  • Relies on consumer as owner of data, OAuth as technical solution to trust
• History of innovation/development, trusted by consumers

Walonoski – Apple also has internal policies for onboarding/testing participants (e.g. hospitals/providers, EHRs), which provides some level of trust/assurance

• Bob – onboards providers/EHRs and makes them available through a controlled environment

Bob – have watched Fortune 50 companies enter/exit healthcare industry many times. Is there something about healthcare that is challenging for traditional consumer-facing companies? Are those challenges something we imagine can be solved? Is Apple going to persist in the healthcare space over the long-term?

• Murta – unique aspects in healthcare that make it difficult to succeed, however the technology used in healthcare and the traditional consumer market is increasingly aligning (e.g. APIs)