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)