Alix Goss

Bob Dieterle

Rick Geimer

Patrick Murta

Alex Kontur


Scaling Proposed Solution


Current state:

  • No FHIR-based solution operates at scale today
    • Geimer – Sequoia has a FHIR API available today that is operating at scale. Others (e.g. Cerner, Epic) would also say they do FHIR at scale. Suggest revising to say “Limited FHIR-based solutions….”
    • Bob – do we know their transaction volume, or number of users?
    • Geimer – no, could reach out to Eric Heflin
    • Alex – Sequoia offers FHIR integration specifically for their directory, not for clinical information exchange. Not aware of any exchange-based solutions that are operating at scale
    • Murta – revise to say that no solution today operates at the scale that we anticipate will be required for the future
    • Bob – revise to: limited experience with FHIR based solutions operating at scale to support anticipated healthcare needs
  • Current scaling solutions cannot handle anticipated volume and response time requirements
    • Lack of predictability of response times
    • Uncertain ability to handle anticipated increase in transaction volume
  • Multiple incompatible potential solutions for scaling (HIEs, clearinghouses, Sequoia, Carequality, CommonWell)
    • Geimer – suggest saying “potentially incompatible”. There are workarounds to make them work together. “Incompatible” makes it seem like they could never work together. It might take work to make them scale, but it’s not impossible
    • Murta – they are competing solutions
    • Bob – revise to: Multiple competing and potentially incompatible solutions for scaling (HIEs, clearinghouses, Sequoia, Carequality, CommonWell)
  • Inconsistent legislative, regulatory, and policy environments
  • Current issues related to privacy and security create barriers to national adoption of FHIR
  • No standard to determine location of patient/member records creates repetitive tasks and data gaps
    • Bob – not necessarily a scaling problem
    • Geimer – means you potentially have to look at hundreds or thousands of places for records, which does impact scaling
    • Bob – revise to: no standard to determine location of patient/member records creates repetitive tasks and data gaps as well as incremental transaction volume
  • Limited ability to push relevant information to interested parties
  • Process to handle synchronous exchanges and state via intermediary are poorly documented
    • Bob – do intermediaries even have the ability to handle synchronous exchanges and maintain state?
    • Revise to: Processes to handle synchronous exchanges and maintain state via intermediaries are poorly tested
    • Bob – what if I do a GET, but it is routed through two intermediaries? How do I maintain state
    • Murta – revise to: lack of documented standards to handle synchronous exchanges and maintain state among intermediaries
    • Geimer – do we need to include the word “synchronous”? Applies to asynchronous exchange as well
    • Bob – they are different problems
    • Geimer – agreed, but we have problems with both. Any exchange involving an intermediary requires more thought, due diligence, documentation, etc.
    • Bob – there are ways to handle asynchronous exchange. If you do something asynchronously, you normally pass something that tells you where to respond. You don’t have that with synchronous exchange. If I do four queries, I have to maintain state for each
  • Concern with multiple intermediaries and impact on performance, scaling, synchronous transactions
    • Bob – multiple intermediaries requires each to maintain state with the last one
  • No practical experience in scaling FHIR transactions via intermediaries
    • Geimer – add “limited”. Lantana and other organizations are proxying requests. So it is through intermediate systems, but not necessarily intermediate organizations
    • Murta – lack of standard or documented process for transactions via intermediaries. We all have a little experience with it, but not expertise
    • Bob – I’d argue that we don’t have any experience scaling through intermediaries
    • Geimer – I’d disagree because FHIR uses REST over HTTP and there is already plenty of experience with scaling RESTful web services through intermediaries. Because we are talking about REST, folks know what to do. But healthcare hasn’t done it yet in a standardized way
    • Bob – revise to: Limited practical experience in scaling FHIR transactions via intermediaries
  • Impact of interoperability models on data blocking, e.g. are endpoints inaccessible depending on the model used?
    • Bob – if I use one intermediary and somebody else uses a different intermediary, are we able to get to all of the same endpoints. Effectively becomes a form of information blocking if I can’t use an intermediary to get to where I need to go
    • Alix – what is the value of taking this on? If somebody isn’t enabling a hop to occur, it isn’t necessarily an intentional act of information blocking
    • Bob – you could argue that with all of the information blocking constructs. Is the issue with including “information blocking” or is it the general concept?
    • Murta – Are we trying to say that the lack of a proven FHIR model at scale could be construed as information blocking?
    • Bob – if I use an intermediary, I am limited by whatever support they provide for getting me to an endpoint
    • Murta – then you need to specify that we are talking about intermediaries
    • Bob – We have a number of interoperability models (e.g. business associate, switch, clearinghouse, point-to-point, etc.). If I want to connect to a provider and they’re only available through an intermediary that I don’t connect to, I can’t reach them. Revise to: impact of competing interoperability models on access to data, e.g. are endpoints inaccessible depending on the model used
  • Note: defining intermediaries as business associates, clearinghouses, HIEs, “switches”, etc.


Future State:

  • Mixed model fully supported
  • Intermediaries are capable of handling volume, response time, and routing to all available endpoints
  • Legislative, standards, and legal trust framework allow unlimited, authorized access to information for stated purpose


Alix – note: Compare and contrast today’s HIEs and clearinghouses with the functionality we want for the future, especially as it relates to endpoint information (and eventually address for scaling)


Diagram:

  • Bob – unclear how to create a swim-lane for a scaling solution
  • Alex – may be more appropriate to do a web diagram, we can show transactions between intermediaries
  • Bob – will include a point-to-point model, single intermediary model, and multiple intermediary model. Do we show one organization at each end connected to all three models, do we show one organization connecting to three different organizations, etc.?
  • Murta – should show the different combinations
  • Bob – e.g. Humana participating in a single network (e.g. HIE), a multi-network (e.g. clearinghouses), and a point-to-point exchange. Is that done through a single endpoint (e.g. a FHIR endpoint accepting data from all three models)?
  • Murta – yes, provider on the left side and payer on the right side, with intermediaries in the middle. Single endpoint on each side. All of the combinations in a single diagram
  • Bob – connection to one payer via each of the three routes from three different providers
  • Murta – the Exchange Tiger Team has a precedent for representing intermediaries using a swim-lane diagram that we can use


In scope:

  • Interoperability models including point-to-point, single intermediary, and multiple intermediaries
    • Murta – most people think about intermediaries as a single hop, but multi-hop intermediary models are also in scope
  • Issues related to RESTful exchanges via intermediaries
  • Planning for future volume increase
  • Establishing SLA and performance requirements for intermediaries and endpoints
  • Establishing functionality of endpoints
    • Bob – depending on the type of endpoint, e.g. a documentation endpoint that is only available from 8-5. You have to be able to declare that


Out of scope:

  • Identification, security, directory, versioning, metadata, certification, or piloting
  • Ownership models
  • Trust frameworks
  • Legal agreements
  • Non-RESTful exchange methods (e.g. Direct w/a FHIR payload)
  • Technical implementation


Assumptions:

  • FHIR transactions include both the FHIR payload and the RESTful operations for exchange of the payload
    • Bob – exchanging FHIR data using Direct is out of scope
  • Identification, security, directory, versioning, metadata, and certification are defined and supported by all participants
  • Service level agreements/statements are established and enforced


Pre-conditions:

  • Endpoints must be available to support FHIR transactions
  • Endpoints are compliant with established FHIR standards (and indicate conformance)


Post-conditions:

  • The FHIR transaction environment works at scale with no significant issues


Solution component analysis:

  • Alex – we are looking for a solution for scaling…what does that mean exactly, other than it has to scale (i.e. accept a large number of transactions on a consistent performance basis). What does the industry actually have to do to make that happen?
    • Bob – e.g. agree that payers will make their endpoints accessible to any point-to-point or intermediary solutions (so that no matter how I connect I can always reach them); could indicate that there is a national expectation that any synchronous transaction will happen in under x seconds regardless of what the intermediaries look like; you have to declare if you can support state all the way through or something that requires repetitive queries. We can set some standards that say “you have to declare this” so that people can decide if they want to use the solution or not
    • Alex – I see those things more as expectations than solutions. If I’m building a system, they provide functional requirements but not the actual technical components that enable them. You need to have a certain amount of bandwidth to run that many transactions, certain network or server functionality, high-speed internet etc. I could theoretically build a system that does the things Bob listed but it wouldn’t necessarily scale nationally
    • Bob – If I set a requirement that you have to handle any transaction end-to-end in under 1 second, it doesn’t matter what your scope is. Not everybody will need to scale nationally, but within your scope you need to support a certain capability
    • Alex – seems to contradict what we implied earlier, that regional networks aren’t happening at scale. Epic is providing an API across all of its implementations. Isn’t that considered at scale?
    • Bob – no, they are providing it but that doesn’t mean it’s being used at scale. Providing an endpoint doesn’t necessarily mean it’s being used at scale
    • Alex – what are the other components that would indicate something is being used at scale?
    • Bob – the SLAs are ultimately the deciding point. If you provide a FHIR endpoint, whether an intermediary who is responsible for getting a transaction from one place to another or an endpoint responsible for responding to the traffic, you have to meet the SLA. It means you have to be up 24/7, less than 10 minutes of downtime a year, response time for whatever volume you serve, or whatever the requirement is
  • No labels