Patient Access Brands Call Notes - Argonaut Project (2024)

Meetings every Wednesday 1-2 PM Central for 6-8 weeks

• PLEASE sign in (attendance sheet)

• Calendar
• Zoom call
• Zulip Chat
• Patient Access Brands spec
  • Examples

• Welcome and intros!
• What are you bringing / what do you need?
• Hot topics / discussion
  • Identifiers beyond URLs? Guidance...
    • NPIs?
      1. Ensure that orgs can include NPIs and other identifiers that they configure
      2. It's probably worth including top-level organizational NPIs as a default practice
      3. We could use more feedback on the cost/benefit of including (potentially hundreds) of additional lower-level NPIs insideOrganization.Identifiers
  • How will brand information be discoverable?
    • In-band: given a SMART server endpoint, the ./well-known/smart-configuration file has a way to link to a brand bundle
    • Through ONC's CHPL: each vendor has a link to their Endpoint list – so that's the most complete and reliable thing, but still involves some human steps.
    • Suggestion for ONC: vendors should submit
      • Link to developer docs
      • Specific deep link(s) to the FHIR Bundles, so that ONC can publish a list of those deep links in a computable way
    • Rob: CHPL today has an JSON API
      
      • curl 'https://chpl.healthit.gov/rest/certified_products/11455/details' -H 'accept: application/json' -H 'api-key: 12909a978483dfb8ecd0596c98ae9094'
  • International: Organization Addresses. The "Address" datatype has "Address.country" – should we provide guidance about
    • Populating this element at all
    • Populating it with a standardized value (base spec says "ISO 3166 2- or 3- letter codes MAY be used in place of a human readable country name.")
  • What about individual provider information, beyond just org level?
    • Out of scope for now, but clients can cross-correlated with NPI
  • Latency of data – is it complete, accurte
    • HTI-1 requires quarterly review (requirements can get passed down from EHRs to customers to ensure timely updates)
    • UAB spec has ETag-based negotiation for queries; plus Bundle timestamp, and optional resource-level lastUpdated timestamps
  • Repeating a parent org's endpoint details on child brands – if you don't repeat the details right now, Inferno will fail the bundle. This seems like punishing developers for including extra info (i.e., the sub-brand details).
    • May need to ask ONC for clarification

• Review spec, current build location – https://build.fhir.org/ig/HL7/smart-app-launch/brands.html
• Tour https://brand-editor.argo.run/
• Tour https://brand-browser.argo.run/config
• Plans / Questions?
  • Samuel at Meditecdh– bringing existing endpoints + newer work on branding, aligned with HTI-1. Will have a bundle on fhir.meditech.com, with actual customer data, mostly simple stuff from our existing data set, but a few more complex examples for testing.
  • Dana at Athena – will try to bring a functional example connecting to our test brands
  • Cooper at Epic – aiming to brin
    • bundle with a handful of fully fleshed out brands, real data
    • a second with more... filler-style data, but larger to facilitate scale testing
  • Gino – Argo staff, reference implementation with a server for testing; possibly client
  • Brian at PatientLink – mostly observing but will bring a third party app perspective. Looking at cutover from internal models to Brands.
  • JP & Patrick at TCP – Working on ingestion of Brands into existing backend; available for display in dev env for android app users
  • Bill at Optum – Observing. Looking at use within our org.
  • Eric – Argo staff, observing
  • Ricky at Apple – will bring team for ingesting and testing brand files
• Other discussion
  • Cooper: Brand bundle passing inferno; having some display issues in the browser.
    • TODO: share a copy; Josh will debug!

• Connectathon intros
  • Debi + Brian from MyLinks, a consumer app looking at formats for endpoints. We spend too long sorting these out and making them useful to patients. We won't be coding today (learne about the event too late) but are here to watch + learn. Brian is our domain expert for onboarding endpoints.
    • Brian: +1, will take the opportunity to read through the spec, which looks well aligned with our needs
  • Andrew from Oracle Cerner. Most of our clients are in the "easy case" of 1 endpoint, 1 org, 1 brand. But would like to talk today through some of teh more complex cases. We brought a sample file, too!
    • Sample file - https://gist.github.com/Arkitechtual/a78fd625dc58157d0653aa75164633ed
    • breakout to discuss edge cases
  • Meera, Arya, Ricky from Apple team, working with partners where we connect to FHIR APIs. Especially interested in orgs with multiple FHIR endpoints, many locations, and other edge cases. Bringing a prototype test client app that can parse files from the 2022 connectathon. Planning to test this on files from today's event and can demo what we have! We've worked through a lot of edge cases in our existing app + backend, handling complexities for different scales of org, geo-distributions, multiple EHR vendors per site, etc.
    • Demo of current view
  • Marty, working with Social Security on provider directory over the long term. Interesting in helping patients who fill out disability applications and are presented with a large list of organizations. Complex, with mergers, re-branding, etc. Multiple endpoints beyond FHIR, including IHE, physical locations etc – a bit broader scope than this Argo project, but interested to see where we can apply these techniques in VA/DOD, workers comp, etc.
  • Cooper from Epic. Some questions came up as I put together a file. e.g.
    • Sample bundle: https://serve-basket.s3.us-east-2.amazonaws.com/SMART-Brands.json
    • I added a "brand-flags: hidden" parent org above each org. Want to understand whether this is something that folks like?
    • For our customers that require client_secrets, there's a link to a client management page for setting up details.
      • Talk through this use case – for example, with Children's Texas + child brands of Children's Plano + Children's Dallas, each with endpoints and each pointing up to a hidden parent. In this example, Epic can publishin its "client secret" distribution list an org ID that cross-maps to the branding Orgs.
    • HTI-1 feedback, how would Endpoint brands interact? Any misalignments or opportunities?
      • https://www.federalregister.gov/d/2023-07229/p-961 is the relevant section.
      • Discuss today?
        Comments from SMART Health IT Team
        

        FHIR Endpoint for Service Base URLs

        We strongly support the ONC’s addition of specific metadata requirements for endpoint URL lists to help patients identify the correct endpoints for their healthcare providers. We are concerned about the specificity of the guidance around FHIR resources and data elements in the regulations and believe that introducing more detailed functional requirements instead would encourage the industry to refine and align on technical data profiles.

        Our Recommendations

        1. Enhance the existing functional requirements by mandating that published endpoint lists support: physical locations, organizational hierarchies, patient-facing brand names, and institution logos.
        2. Encourage industry evaluation of detailed FHIR implementation guides to meet these functional requirements. A starting point is the Argonaut Project's 2022 "SMART Patient Access Brands" profiles (available at https://build.fhir.org/ig/HL7/smart-app-launch/branches/pab/brands.html)
        
  • Josh H and Sam A from Meditech. Jason Vogt is out the week. We have an endpoint set up with a brand file. Curious to see how apps will use the info in branding bundles to help us focus.
    • Sample file at – https://devmtx-restapis-stable.meditech.com/v1/uscore/R4/Brands
    • Entry point for discovery: https://devmtx-restapis-stable.meditech.com/v1/uscore/R4/.well-known/smart-configuration
  • JP + Patrick from The Commons Project. For Common Health app on Android, we're building import tools for endpoints, and integrating Endpoint Brands as part of the project. We have a reference app that parses out endpoint + org data and adds it to our backend. Still very basic UX.
    • Demo of how this looks!
• Other topics
  • Patrick: For logos, should we distinguish between a "thumbnail" and a full-scale logo for use in different contexts?
    • Meera: would love to compare notes
    • Marty: many orgs have similar names across the country. Logos might not be recognized. Patients may know rough locations without knowing spsecific addresses. Often patients don't understand and won't understand the full hierarchy.
• Meeting notes!
  • Let's with demos of target UX for consumer-facing apps.
    
  • Apple demo: demo from parsing last year, basic table of orgs + associated endpoints
  • Apple demo: current Health app. Starts with default suggestions showing nearby locations if a patient shares their location.
    • If you search by org name, you get typeahead results ("lab" → labcorp, BioReference, Laboratories, etc)
    • Orgs set their own logos
    • Orgs can set their exact locations as well as subtitles
    • Orgs can set their own hierarchies, e.g. by region/location/department, or "just one entry"
    • Questions: Should we have a separate "search terms" extension, or are subtitles / aliases enough?
  • TCP demo
    • "no frills admin backend" – we don't have a self-serve platform for providers; we manage the details ourselves in our own backend.
    • We model a parent org with title + description. Under the hood, >=1 "Gateways" which are like FHIR endpoints. Within each gateway there can be 0 or more "sites" that correspond to sub-brands.
• Discussion
  • Apps MAY filter out top-level orgs (i.e., hide them) if they have zero associated endpoints and only act as grouping constructs
  • Top-level orgs that are "hidden" / have no endpoints / exist only for "grouping" SHALL NOT be the only source of key information like aliases, logos, etc, because they will never be directly displayed by apps.
  • Sub-brands SHALL have self-contaned / complete names and aliases, not "Tenant 1", but "Dignity Tenant 1"
  • Where do app developers associate their client ID / secrets?
    • Endpoint 1fhir2 .managingOrg → UnityPoint
    • Endpoint 1fhir4 .managingOrg → UnityPoint
    • Associated Physicians of Madison – .partOf UnityPoint
    • Org 1 Tenant 2 – .partOf UnityPoint
    • → In this example, any app's client_secret could be associated with UnityPoint
  • Helping app developers connect to the right help desk when something goes wrong
    • Endpoint.contact – we should document that Endpoint contact info can be phone, email, or web
    • Cooper: Given that these are public files, we want to protect, say, hospital departments from receiving unsolicited inbound communications
    • Josh
      • TODO: add guidance that Endpoint.contact should include the URL for a self-service developer portal
      • TODO: Clarify that "alias" is broad – "anything folks might search for when we want to find this org"
      • TODO: add a note pointing to FHIR reference semantics with
        • full URLs (urn:uuid: or https:)
        • relative URLs
  • Hot Topic / Discovered Issues:
    • ONC's proposal in HTI-1 recommends Organization.endpoint refernces, where we use Endpoint links. Should we flip our profiles? Is there any compelling reason to keep Endpoint.managingOrganization?
    • Bundle entry resolutions
      • "fullUrl": "https://example.org/fhir/Organization/123", "resource": {... "partOf": {"reference": {"Organization/123"}}
      • "partOf": {"reference": {"Organization/123"}}
      • "partOf": {"reference": {"urn:uuid:411"}}

• Review spec, current build location – https://build.fhir.org/ig/HL7/smart-app-launch/branches/pab/brands.html
• Include additional recommendations for optional logo:
  • "SHOULD" - ensure logo size is less than 2MB
  • "SHOULD" - ensure logo is legible at small sizes (e.g., as small as 50x50 pixels/points). Tips to achieve this:
    • If the logo contains both a brandmark and a wordmark, separate them and use just the brandmark
    • If the logo is predominantly horizontal, consider creating a vertically-oriented logo that is still recognizable when scaled to smaller sizes
• TODO(jmandel)
  
  • fix bullets and backticks
  • fix

    "valueUrl": "https://unitypoint.org/logo/main.1024x102.png"

• Cooper (Epic) will bring WIP code for Brand bundles
• Jason (Meditech): will bring prototype data set and server (has been trumped by some other focus areas)
• Ricky (Apple): Meera will attend, planning to bring prototype client app, looking to work with sample structured data files from vendor
• Andrew (Oracle): Will bring a brand Bundle file, looking for confirmation about modeling different org structures and talk through the detail
• JP (TCP): Working on bulk import for endpoints, designed to work with directories. Probably on't be ready to show but we'll want to test the artifacts and provide feedback.
• Josh: Heads up on extension URLS – as we've migrated the content into an IG, extension bases are updated. Important for clients and servers.

• Participants
  • EHR
    • Epic
      • Cooper Thompson
      • Bringing a file, some real mixed with synthetic, not suitable for real-world use
      • Brands file: https://serve-basket.s3.us-east-2.amazonaws.com/Brands.json
      • ^^ "Children's Health System of Texas" is the one example showing multiple sub-brands
    • MEDITECH
      • Jason Vogt, Sam Ashby
      • Brands file: https://fhir.meditech.com/brands.json
      • ^^ Mockup data for testing the IG. Includes examples with one brand and with multiple (health system with hospital + pharmacy, each with different locations)
  • App
    • Argo staff
      • Josh Mandel, Brett Marquard, Dan Gottlieb
      • Brands file: https://raw.githubusercontent.com/argonautproject/patient-access-brands-editor/main/src/fixtures/example-brand-bundle.unitypoint.json
      • App: https://brand-editor.argo.run/picker?
      • App: https://github.com/sync-for-science/procure-wip
      • ^^ Send feature requests on Zulip
    • The Commons Project
      • Ben Tseytlin, JP Pollak
      • Pre-tested in app
    • Apple
      • Meera Srinivasan
      • Working with sample Brand file
• Hot topics / discussion
  • How to tell if a Brands file supports the Argo Brands spec? – right now, it's out of band.
    • Should we add a tag or a profile on Bundle.meta? Daniel Gottlieb to propose an approach
  • Coordinate an example of cross-vendor example with Epic + MEDITECH?
    • To do this: populate a shared Organization.identifier
  • "nearby-zipcodes" extension. Surfaced data already stored in an Epic db

• Connectathon is June 2, 11a-3p CT
• Connectathon Scenarios
  • EHRs
    • P0: Host a Patient Access Brands file (e.g., "brands.json") with provider-level data for FHIR R4 endpoints and orgs
    • P1: Allow Healthcare Providers to submit/manage/update their brand entries
    • Participants include Epic, Meditech, Nextgen (TBD – reviewing sample data)
  • Healthcare Providers
    • P0: Draft your Brand entries as you would like to see them in real life
    • P1: Work with your EHR to include your content in their brands.json file
  • Consumer App Role
    • P0: Build a "Connect" workflow powered one or more Patient Access Brands files
    • P0: Allow selection by name, state
    • P1: Display logos and descriptions
    • P2: Support "merging" of cards when identifiers match
    • At least two participating apps (developers from Apple and The Commons Project)
  • Payors and other non-EHR API Servers
    
    • P0: Draft your Brand entries as you would like to see them in real life
    • P1: Link to your brands.json file from your .well-known/smart-configuration
• Review spec
  • Note potential changes for Organization.address
    • Some slipperiness between "geographical areas serviced by the Org" vs "specific addresses associated where the org's clinics are"
  • Note potential changes for extension URLs
• Other discussion?

• Daily health checks: what are the inputs / outputs
  • Epic: we were considering updating Endpoint.status based on daily checks (e.g., if a customer has downtime during a system upgrade). Without this, we often get inbound requests from app developers to let us know or ask about this downtime.
  • Updating Endpoint.status wouldn't change the Organization.meta.lastUpdated time, so we don't have to worry about thrashing on that
  • Decision: add Endpoint.status to the definitions, describing as 1..1 and Must-Support. Note that EHR vendors MAY update status based on automated health checks to indicate error when an endpoint is known to be down
• Next steps → ()
  • Are we ready to take what we've got and try it?
  • Agree x~4, nobody disagrees
  • So where do we go, from this spec?
  • Q. Ricky: Should initial implementations include real data from customers, or should it be based on synthetic orgs / brands that vendors manage?
  • A. Jason: today we'd need to start with mocked data for the Branding info because we haven't collected all of; the Endpoint and basic org names we do have
  • A. Gino: working with real-world limitations will also be good for apps, because IRL similar kinds of limitations will apply
• Should we do a connectathon type process?
  • Interest in this, yes. At least 2 EHR vendors and 2 app developers would participate.
  • When would folks be ready? Roughly targeting May/June; will follow up with specifics.
  • Connectathon: might just be synthetic brand info; could be more.
  • Plan: decide on a date by next week!
  • Plan: invite Lantern team to participate!
  • Plan: include discussion about CHPL identifiers in Endpoint.extension
• Collab over the next couple of months?
  • Bring issues to zulip
  • can schedule ad-hoc calls as needed
• Other areas of project scope? Nothing that we've identified on critical path. e.g.
  • National Directory of endpoints. Hope is that any work here can act as a source for the national endpoint directory without detailed coordination.
  • Lantern / ONC infrastructure aims to correlate endpoints with Certified EHRs, e.g. by inclusion of CHPL IDs identifying certified software and versions. If this lands in []/metadata vs in Endpoint directory, responsibilities for maintenance varies.
    • There won't necessarily be one CHPL ID that applies to all of a vendor's endpoints at a specific moment in time – at least for some (most? many?) EHR vendors
    • Most vendors offer different products (acute vs outpatient vs homecare, say) all with different CHPL IDs, but all of which could be included in the vendor's Endpoint bundle
    • e.g., might have O(1000) endpoints and a total of O(10) different CHPL IDs
    • Would this information surface within patient-facing apps? Not necessarily.
    • Value prop is ONC bookkeeping – but also reporting / publicizing progress on policy goals
    • Certification can happen and CHPL IDs can be minted long after deployment; we don't want to have to update a server just to slot in this new metadata field, because that requires coordinated deployment activity.
    • Proposal: talk with Lantern team about Endpoint vs CapabilityStatement, vs populating CapabilityStatement with some non-CHPL vendor specific version that externally can be cross-walked to a CHPL id
• Other other?

• Updates / changes
  • Demo editor
    • blank example
    • starting from "UnityPoint" example
    • source at https://github.com/argonautproject/patient-access-brands-editor
  • Moved "technical contact" to Endpoint
  • Removed the explicit "merge" extension in favor of Identifier-based matching
• Discussion on "why Endpoint→Org instead of Org→ Endpoint"
  • separation of responsibilities for consistent management
    • adding a new Endpoint doesn't need to "touch" (change) multiple resources, just the one Endpoint resource
    • orgs can manage their branding by changing just the Org resources
    • vendors can add a new endpoint without having to change multiple Orgs or ask their customers to review/update "their" resource
  • Cooper: we spent 1-2h talking through this in another project (Lantern discussions). One point is that "Endpoint.managingOrganization" may not capture the precise semantics of the "Endpoint has primary brand" relationship.
    • Josh we could always add an Endpoint.extension[has-managing-org] if we wanted more precise semantics
    • Cooper: yeah; the core spec semantics are fairly vague, so I'm OK with where we are (Endpoint→Org, via Endpoint.managingOrganization
• Review min cardinality and MS requirements
  • Endpoint.managingOrganization
    • supporting an identifier + external bundle link could be hard early on
      • not challenging in its own right, but is this necessary for an MVP?
  • Organization.contact (main website)
    • see the value; EHR developers may not have this already, so gathering/maintaining can be challenge
      "org-managed-data-not-readily-known-to-ehr-vendor"
  • Organization.partOf: can we limit the depth of "affiliated brands" to a depth of 2? I.e. an affiliated brand always is partOf a top-level brand.
    • Nobody is making the case for arbitrarily deep hierarchies
    • decision: limit to 2
  • Organization.address – agree with 0..* MS. But what makes a valid address?
    • state
    • city, state
    • city, state, zip
    • street, city, state, zip
    • zip
  • Organization.type – there's value in supplying types.
    • We should simplify the valueset to consolidate "health-system", "hospital" and "outpatient" into one "clinical
    • So: clinical, lab, pharmacy, insurer, network, aggregator
    • DaVinci plan-net has use case extensions for things like payment, care, etc (on Endpoint)
      • https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/ValueSet-EndpointUsecaseVS.html
  • Organization.extension[portal name]
    • org-managed-data-not-readily-known-to-ehr-vendor
  • Organization.extension[portal url]
    • org-managed-data-not-readily-known-to-ehr-vendor
  • Organization.extension[portal description]
    • org-managed-data-not-readily-known-to-ehr-vendor
  • Forelements tagged with org-managed-data-not-readily-known-to-ehr-vendor
    • Will they be key up to date?
    • Orgs are doing this with Apple Health and CommonHealth today
    • Somethings things become unreachable and orgs are invited to fix it
    • Even if this is hard and not 100% accurate, it's still easier to keep it updated in one place than in every app
    • We can document the trade-off here as a pattern: we know the data may not always be accurate or complete, but marking as "1..1 MS" emphasizes the fact that client developers should be able to write their apps with this in mind.
    • Would we want a "data absent reason"
      • Josh: happy to if there is a specific proposal; I'm agnostic.
      • If these are all missing on day 1, what would be a helpful way to communicate?
      • Cooper: we can (and probably would) always provide a DAR even if the spec is silent on this
      • Cooper: not sure if we need to track quality or staleness of these fields more granularly than the Brand info itself
      • Josh: lastUpdated at the Brand level could be a good middle group

• TODO: Add topics here!
• Examples: https://hackmd.io/@argonaut/patient-access-brand-examples
• Notes, reactions, questions:
  • Walking through the document
  • is "audience descriptor" too specific?
  • can we track versions or "last updated" or some other way to disambiguate Branding info published in different places?
    • Added meta.lastUpdated at Bundle and (optionally) resource level
  • Discussion about synchronization between the consolidated and endpoint-specific bundles
  • "What definition of must support":
    • Josh implicit definition was "an EHR support this spec should allow customers the option to populate this value"
  • Conformance: can we separate out the smart-configuration vs the vendor managed list?
    • Rolling out support for changes to smart-configuration takes more time
  • Portal URL: may need to relax – want to understand considerations here
    • This hasn't come up in discussion (Epic), maybe because the OAuth process is downstream of portal access
    • Do authz URLs always lead to portals, or are they sometimes separate?
    • Apple perspective: would be nice to show users where to go to get help, see data online, etc. OAuth authz URL does'nt do this job.
    • Another use case: help people disambiguate and "try out" / see their data first
    • Apple has a health system URL displayed in the detail view today (since 2018)
    • Right now we have a helth system URL and also a portal URL – is there a reason to have both?
    • Help patients avoid navigating complex multi-portal providers if we can surface both, directly
    • Challenge: EHRs vendors might need to ask every custom to inform them of their portal URLs. For Epic ~95% of orgs we'd know the portal URLand for 5% we'd need manual ongoing process maintenance
    • Pragmatically 95% coverage is good – we want to lablel a "SHALL" but recognize that in real life, data might still be missing soemtimes.
  • Organization addresses vs locations. Should we use a Location resource, or Organization.address, or both?
    • Discussion: are there benefits to externalizing address details into Location?
  • Should Endpoints→Organization, or Organization→Endpoint?
  • De-duplication – may not be so much of an edge case! Can we provide a consistent approach?
    • Stuff that a vendor can manage
    • Stuff that needs to emerge consistently across vendors
  • Jason: Could we solve a smaller problem? Do less and just populate a small set of fields?

• Other agenda?
  • How does this fit with Optum, sharing data about payments or related clinical data?
• Josh to propose a design: https://hackmd.io/@argonaut/patient-access-brands
  • Cooper: I see design space with REST API or static data – ONC workshops have been focused on REST API approaches
  • Is it clear whether there's a list of Orgs vs a list of Endpoints?
  • If there's more than one endpoint, do they share an authz token?
  • Notes, reactions, questions:
    • Walking through the document
    • is "audience descriptor" too specific?
    • can we track versions or "last updated" or some other way to disambiguate Branding info published in different places?
    • Discussion about synchronization between the consolidated and endpoint-specific bundles
    • "What definition of must support":
      • Josh implicit definintion was "an EHR support this spec should allow customers the option to populate this value"
    • Conformance: can we separate out the smart-configuration vs the vendor managed list?
      • Rolling out support for changes to smart-configuration takes more time
    • Portal URL: may need to relax – want to understand considerations here

• More sharing
  • Jason to demo current / vnext work
  • Dan to demo Procure (http://procureproject.org )– the "apps without cloud" story and challenges
  • Michele to share background on CareEvolution patient access "connect to records" workflow
• Existing efforts – can we review and do we plan to reuse?
• Are we going to start with existing efforts (e.g., Lantern) as a baseline?
  • Maybe – let's start with use cases and evaluate existing spec

Meditech Endpoint (pre-production "stable" env)

Next to other API docs, two lists of endpoints

• Argonaut DSTU2
• US Core R4
• 
• Includes FHIR collection-type Bundle with Endpoint resources
  
• address of endpoint, name, and managingOrganization
  • managingOrganization is a reference, but not yet resolvable
  • details for what goes into this are TBD
• Today, customers send us information that we populate into a central database. We might prefer to pull this information from our customers instead of having them push it to us.
  • Internal EHR db captures endpoint address; this is synchronized to the central db
  • The name is maintained by meditech, manual process for updating it for now
• Do clients need to be registered for API access?
  • Yes, that's a separate consideration, but the endpoint lists are openly published
  • Also working with Carequality to support dynamic registration
• Have you considered aliases, identifiers, logos, etc?
  • We're starting to, with this Argo project
  • Today we've got just the highest-level org names, and we know that there may be sub-brands that are better recognized by some patients
• Michele: A list of endpoint but now way to register across them... leaves apps stuck. We have this challenge with Cerner and Meditech today
  • Josh: yes this is painful, agreed. It's outside the scope of this project today
  • Cooper: sure, but if there no scalable registration process, even a registration link would be good
  • Josh: Agree – might want to publish technical contacts associated with an Endpoint, or a "Manual registration" URL in a .well-known/smart-configuration document

Procure (App experience)

• https://github.com/sync-for-science/procure-wip – open source browser-based application supporting patient data donation for research studies. Researchers can host Procure to help participants share EHR data via SMART on FHIR. Procure can connect to endpoints with authorization from the patient.
• 
• 
• Basic type-ahead search of named endpoints. It's not that easy for patients to know what to type into the search box. There are many orgs with similar names (e.g., "Mt Sinai Medical Center" vs "Mt Sinai Health System", or rebranded orgs like "Partners" vs "Mass General Brigham).
• Unlike large or well-funded apps (e.g., Apple Health Records) that can host their own configuration UX and get providers to customize listings, these kinds of small open source apps don't really have this option. Would be helpful if the automatically discoverable metadata were sufficient to drive a more comprehensive UX.
• Procure internally maintains its own endpoint lists by pulling in published lists from Epic/Cerner. Today that's just a FHIR URL and a name; Procure then decorates these endpoints with config metadata (e.g., its own client_id)
  • e.g. as an offline process to pull in the latest Epic endpoints, an app administrator can just use curl to HTTP GET. Very powerful to be able to pull in data from a public endpoint to bootstrap Procure's configuration
• 
• Bottom line: name alone hasn't been enough to provide a really helpful UX, but an app like Procure isn't well positioned get more
• Michele: you mentioned NextGen -- do they have a published list?
  • Dan: I think so; will check
• Dan: With Procure, noticed mixed R2/R4 endpoints in the Epic-published bundles. We de-duplicated with name-based heuristics. We might want to keep these separate, or include explicit verioning information
  • Cooper: would the contained org ID help?
  • Dan: There was an issue; is it possible the guids weren't aligned between the two lists?
  • Cooper: will check

CareEvolution (App experience)

• MyFHR is a web + native mobile app
• 
• Straight list of providers that a user can search through
• 
• Confusion with sites like "Mercy" which return ambiuous results
• We also index states and zip codes to allow searches like
  
• We're working on a better version with more information
  • Provider logos
  • More geographical information (addresses) for area-based search; our users come from across the US but folks mostly want to connect to providers near home
• Internally we maintain a list of providers and get logos and zip codes
• 
• 
• All of this information we have to collect manually.
• We wrote tool to import the Epic and Cerner endpoint list, to bootstrap the process, but all the extra information needs to be manually maintained
• It'd be very help to get some of this automatically; we spent staff hours hunting down this information, re-importing/diffing roughly every week to look for new sites and track down the data by googling provider names, etc. Or we reach out to providers to ask.
• That said, the realpain point is registration, because no amount of work allows us to actually register our app with endpoints if the vendor doesn't offer a scalable/repeatable process
• What about names/aliases etc?
  • When we work directly with providers, we ask them. We support aliases
  • When we discover providers from endpoint lists (e.g., Epic) we use names from Epic + whatever we can discover on the web
• Cooper: are you using Epic's FHIR bundle or the old JSON format?
  • Old JSON format, because our tool has been around for a while
• Cooper: do you ever have trouble detecting changes vs new entries?
  • Yes, if name and endpoint both change, this looks to us like a new provider
• Cooper: where to logos from from?
  • Provider websites – but we don't display these in our UI yet.

1. Kick-off and Welcome
2. Administrivia
   1. Calendar
   2. Sign-in

   3. Expectations

      1. active participation in calls
      2. follow and help with notes
      3. prototype applications/servers
      4. implement the agreed-upon format on your live sites!
   4. Timeline
3. Scoping
   1. Vendors have a regulatory obligation to post Endpoint information: https://www.federalregister.gov/d/2020-07419/p-1405
      1. Focused on patient access
      2. Centralized by the vendor, even if API endpoints are hosted by customers
   2. → Our aim is to support a good consumer experience for connecting an app to a provider's site
   3. 6-8 week effort.
4. Learn about what systems have already done today
5. Use Case/Scope

Apple implementation

• "Add Account" presents a list of orgs by physical proximity, combining the phone's location and the healthcare providers' published street address(es).
  
• Some orgs are nationwide, like Quest Diagnostics. They can choose to list a single brand in the main list, while also providing detailed street addresses to support proximity-based recommendations. In other words, orgs can control specific entries in the list (brands), as well as sub-brants, and can associate any number of locations with each entry. These details are decided by the providers – there's a fair amount of flexibility based on real-world usage over many years. Significant institutional experience accumulated in these choices.
• 

• Some orgs needed to create multiple sub-brands to accommodate multiple portals from different EHR vendors. For example, Dignity where each sub-brand (e.g., "Arizona") may have many locations internally tracked, and each is affiliated with a single portal.
  
• Each brand can also list a "main website" associated with each Organization, wihch are user-facing sites (e..g, hospital system website or portal website)
• Apple maintains a self-service portal where orgs can manage these choices. https://support.apple.com/guide/healthregister/1b-register-a-fhir-api-endpoint-apd95701b57f/web documents part of this process, including UX consistency recommendations for logos when provided (dimensions, colors/transparency, file format, etc).
  
• Q. How are locations supplied?
  • A. E.g. Quest can upload a CSV with thousands of clinic/lab locations
• Q. Can one entry in the list be associated with >1 FHIR endpoint?
  • A. Each endpoint surfaces as one (or more) entries in the list, and they can be branded however the org chooses (e.g., same branding or different)
• Q. Is this content available in a set of FHIR endpoints or other resources?
  • A. The underlying infrastructure here does not currently use the FHIR Endpoint resource as it was developed >4 years ago. There are also contractual relationships with the organizations uploading logos, etc., and those obligations preclude making the dataavailableexternally.

Epic Endpoint lists

• https://open.epic.com/MyApps/Endpoints supports several formats including
  
  • HTML
  • JSON file with arrays of{{name, url}} pairs
  • JSON file with FHIR Bundle of Endpoint resources with contained Organization
• Published metadata does not include logos
• Onboarding process for providers is analogous to Apple's.
  • Customer decides to deploy a FHIR endpoint and follows a setup checklist
  • (Not all customers choose to set up a FHIR endpoint, not all covered by regs)
  • "Not self-service" – today involves e-mailing an Epic representative, so mistakes can be caught early
    • Epic staff gets data loaded
  • Epic's testing tools check that the loaded data are valid
  • Epic also performs daily health checks including OAuth flow in headless browser environment
    • One test pt per site, not comprehensive but finds connectivity breaks
• Each organization may have multiple brands associated with their entry. Branding info collected from the customer today is:
  • Endpoint URL
  • Endpoint Name (patient friendly branding)
  • Contained Organization name (may be a more obscure business entity name)
  • Q. What about aliases?
    A. Today we just have support for one patient friendly name; might be worth exploring aliases in future
• When customers migrate endpoints (e.g., rebranding and new DNS) we give them a process to update their URL and we recommend that they set up redirects or aliases, but in the directory, we just do a straight cutover
• Are .well-known/smart-configuration files hosted by customers or by Epic?
  • Vast majority are hosted by Epic; a few self-host
  • Some tooling in EHR administration side that lets customers set things like Base URL, because the EHR doesn't always know its own URL when it sits behind a reverse proxy. Epic manages public keys etc.
• Future plans for endpoint bundle include zip code and facility NPIs
• App developers today also need to manage per-endpoint secrets – ideally developers would have an easy way to associate these secrets with the specific endpoints where they're use
  

Cerner Current State + Roadmap

• Names and base URLs currently published on GitHub
  
• Planning to replace this with a Bundle of FHIR endpoints, and to add embedded Organizations with addresses
  • "There's one too many Mercy Healths"
• We're looking at other kinds of identifiers for Orgs (e.g., Tax ID, which the Social Security Admin uses)
• Also looking at Org hierarchies, because each FHIR endpoint might be associated with a whole set of related orgs, or related sub-orgs might have different FHIR endpoints
• All the data are managed centrally, even if the EHR implementations are self-hosted
• Q. For addresses, will there be many (for all the sites of an org)?
  A. Starting at top level but as we support hierarchies we'd plan to associate addresses with sub-orgs in the hierarchy

What about technical support when something goes wrong with an app?

• Epic experience handling Q&A from app developers is that we get a lot of questions where it wouldn't make sense to involve a client site. we can triage and handle most questions ourselves.
• Cerner: similar story
• For FHIR APIs and patient access in general, providers are somewhat anxious about the support burden

Timeline

Scope

1. Published structure in publicly accessible location.

out of scope

1. Building a prototype directory
2. Balloting the final product

Next Steps