HTI1 Update - Allscripts #96
Description
New HTI catalog with filter
Issues with FHIR Endpoint & Resource Clarity
Issue #1: Ambiguity with Endpoint.managingOrganization and Multiple Organization References
There are two or more top-level Organization resources (with the same name and id) that list the same Endpoint reference under their endpoint[] field.
However, when examining the Endpoint resource itself, it contains an embedded Organization under the contained[] section.
This contained Organization:
• Has the same name as the external Organization resources added as managing org in Endpoint.
• But has a different id than those Organization resources.
• And is referenced in Endpoint.managingOrganization using a local reference (org id : "72b3f675-72e8-49a8-a084-fb3b58546e6f"),
(org id : "d06a59e0-1f95-470d-bde1-09b65c88f198"),
Issue #2: No Clear Way to Determine FHIR Version for Each Resource Base URL
Currently, there is no standardized or explicit indication in each resource's fullUrl (or surrounding metadata) that tells us which FHIR version the resource belongs to (e.g., DSTU2, STU3, R4, R4B, etc).
Because of this, in order to ensure we are interacting with the correct FHIR version for a given endpoint or organization, we are forced to:
• Manually parse the fullUrl (which is often non-standard and inconsistent)
• Issue a /metadata request for each unique base URL, just to determine which FHIR version it supports
• Wait for the response to parse the FHIR version
Impacts:
• Performance Degradation: Increases load times due to extra network calls per base URL
• Throttling & Rate Limits: We've hit rate limits and throttling when performing this discovery across many resources
Issue #3: No Clear Way to Identify the Resource Audience (Patient vs. Practitioner)
While integrating and parsing the available FHIR endpoints, we’ve encountered another ambiguity: there is no standardized way to determine whether a particular endpoint or resource is intended for a Patient or Practitioner use.
Currently, there is no field, naming convention, or metadata within the resource including the /metadata (CapabilityStatement) that clearly indicates the intended audience or access level of that resource or endpoint.
This makes it nearly impossible to:
• Programmatically route requests correctly based on audience
https://developer.veradigm.com/Content/fhir/VC_PTE_TestingPatientApps_VEHR.pdf
https://forms.office.com/Pages/ResponsePage.aspx?id=i56fdW3P8k6wvN1L3x58VjJDS0A7ZoVItluNrek8TQ9UODlCUEJRN1hQREoxRVY1RTBGWTFBQVdVRC4u
Requested sandbox access on May 5th, may take up to 1 week .