Mobile Care Services Discovery (mCSD)
4.0.0-comment - ballot
Mobile Care Services Discovery (mCSD)
4.0.0-comment - ballot
This page is part of the IHE ITI Mobile Care Services Discovery (v4.0.0-comment: Publication Ballot 8) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
The Mobile Care Services Discovery (mCSD) Profile supports creating, updating, deleting and discovery of care services resources using a RESTful interface in interrelated, federated environments.
Use cases and solutions using mCSD are outlined in the mCSD White Paper.
The profile supports querying for:
Organization – Organizations are “umbrella” entities; these may be considered the administrative bodies under whose auspices care services are provided such as Healthcare Information Exchanges(HIEs), Integrated Delivery Networks (IDNs), Non-Government Organizations (NGOs), Faith-Based Organizations (FBOs) or even a one-physician family practice. An organization has a unique identifier and may have additional administrative attributes such as contact person, mailing address, etc. Departments of an institution, or other administrative units, may be represented as child Organizations of a parent Organization.
Facility – Facilities are physical care delivery sites such as hospitals, clinics, health outposts, physician offices, labs, pharmacies, etc. A Facility has a unique identifier, geographic attributes (address, geocode), contact attributes, attributes regarding its hours of operation, etc. Each Facility is defined by a pairing of Location and Organization.
Location – Locations are physical places where care can be delivered such as facilities, buildings, wards, rooms, or vehicles. Locations also include jurisdictions such as a village districts or regions. A Location has a unique identifier and may have geographic attributes (address, geocode), attributes regarding its hours of operation, etc. Each Location may be related to one Organization. A location may have a hierarchical relationship with other locations.
Jurisdiction – Jurisdictions are political administrative units or other territories over which authority is exercised. A Jurisdiction has a unique identifier, geographic attributes, etc. Jurisdictions include political administrative units such as village districts or regions. Each Jurisdiction is defined by a pairing of Location and Organization.
Practitioner – A Practitioner is a health worker such as defined by WHO (in Chapter 1 of the World Health Report 2006); a Practitioner might be a physician, nurse, pharmacist, community health worker, district health manager, etc. Practitioners have contact and demographic attributes.
PractitionerRole – A PractitionerRole links a Practitioner with the role they perform. Each PractitionerRole may be related to one or more Organizations, one or more Locations, and one or more Healthcare Services. Specific attributes may be associated with the PractitionerRole’s relationship with these other entities.
Healthcare Service – Each healthcare service has a unique identifier. Examples include surgical services, antenatal care services, or primary care services. The combination of a Healthcare Service offered at a Location may have specific attributes including contact person, hours of operation, etc.
Endpoint - An Organization may be reachable for electronic data exchange through electronic Endpoint(s). An Endpoint may be a FHIR server, an IHE web services actor, or some other mechanism. If an Organization does not have an Endpoint, it may still be reachable via an Endpoint at its parent Organization or an affiliated Organization.
OrganizationAffiliation - An Organization may have relationships with other organizations that are not hierarchical. These relationships may indicate an electronic routing path to other organizations that cannot be reached directly. OrganizationAffiliation can be used to specify relationships such as supply chains or administrative reporting structures.
The capabilities detailed in this profile support consumer-centric queries such as finding “where is the closest youth mental health services clinic” or “what are the hours of a physiotherapist near my workplace”. In addition, mCSD supports crucial health system management workflows. This can include reporting and analyses, such as “what are my health human resource capacities, by facility, by cadre,” “what are all the services offered at this facility,” or conversely, “where are all the facilities that offer this service.” The mCSD Profile may be employed to support, for example, the Provider Queries listed by the US Office of the National Coordinator as part of the Standards and Interoperability Framework. In addition, mCSD can enable connectivity by providing service endpoint lookup, such as “What is the FHIR server for this organization?”.
The loosely coupled design and flexible querying capability of the mCSD Profile means it can be deployed within a variety of eHealth architectures and support a wide array of care workflows.
The profile provides optional support for RESTful transactions to create, update and delete care services resources.
This section defines the actors, transactions, and/or content modules in this profile. Further information about actor and transaction definitions can be found in the IHE Technical Frameworks General Introduction Appendix A: Actors and Appendix B: Transactions.
Figure 1:46.1-1 shows the actors directly involved in the mCSD Profile and the relevant transactions between them. If needed for context, other actors that may be indirectly involved due to their participation in other related profiles are shown in dotted lines. Actors which have a mandatory grouping are shown in conjoined boxes.
Figure 1:46.1-1: mCSD Actor Diagram
Table 1:46.1-1 lists the transactions for each actor directly involved in the mCSD Profile. To claim compliance with this profile, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”).
Table 1:46.1-1: mCSD Profile - Actors and Transactions
| Actors | Transactions | Initiator or Responder | Optionality | Reference |
|---|---|---|---|---|
| Directory | Find Matching Care Services [ITI-90] | Responder | R | ITI TF-2: 3.90 |
| Request Care Services Updates [ITI-91] | Responder | O | ITI TF-2: 3.91 | |
| Care Services Feed [ITI-130] | Responder | O | ITI TF-2: 3.130 | |
| Query Client | Find Matching Care Services [ITI-90] | Initiator | R | ITI TF-2: 3.90 |
| Update Client | Request Care Services Updates [ITI-91] | Initiator | R | ITI TF-2: 3.91 |
| Data Source | Care Services Feed [ITI-130] | Initiator | R | ITI TF-2: 3.130 |
Most requirements are documented in ITI TF-2: Transactions. This section documents any additional requirements on mCSD actors.
mCSD supports querying for Organization, Facility, Location, Practitioner, PractitionerRole, Healthcare Service, OrganizationAffiliation, and Endpoint. However, Directories, Query Clients, Update Clients, or Data Sources are not required to contain data on all of these.
The Directory processes received queries from Query Client and returns information about mCSD resources.
When the Directory supports the Update Option, it can provide updates about mCSD resources in response to a refresh request from an Update Client. The updates include new or modified information since a previous refresh.
When the Directory supports the Feed Option, it receives updates to information about mCSD resources from a Data Source.
The Directory SHALL publish an instance CapabilityStatement at the metadata endpoint following ITI Appendix Z.3 using the FHIR capabilities interaction.
All supported interactions shall be specified. All supported search parameters and search methods (GET, POST) SHALL be specified. The search parameters and message semantics defined in [ITI-90] SHALL be supported. When the Update Option is supported, the search parameters and message semantics defined in [ITI-91] shall be supported. When the Feed Option is supported, the message semantics defined in [ITI-130] SHALL be supported for each message: create response, update response, delete response, and process response. Other parameters may be supported.
This capabilities response will typically include all of the capabilities inclusive of all grouped actors and additional functionality. The following are some examples:
The Query Client queries the Directory for information about mCSD resources.
No additional requirements. The following are two example capability statement resources that a Query Client could support:
The Update Client can query for updates since a previous refresh, to information about mCSD resources from one or more Directories that support the Update Option.
No additional requirements. The following are two example capability statement resources that a Update Client could support:
The Data Source can provide updates about mCSD resources to a Directory. The updates include create, update, or delete requests to individual resources or a batch/transaction request for a bundle of resources.
No additional requirements. The following are two example capability statement resources that a Data Source could support:
Options that may be selected for each actor in this profile, if any, are listed in Table 1:46.2-1. Dependencies between options when applicable are specified in notes.
Table 1:46.2-1: mCSD - Actors and Options
| Actor | Option Name | Reference |
|---|---|---|
| Directory | Location Distance Option | Section 1:46.2.1 |
| Directory | Update Option | Section 1:46.2.2 |
| Directory | Feed Option | Section 1:46.2.3 |
| Query Client | Location Distance Option | Section 1:46.2.1 |
| Update Client | No options defined | – |
| Data Source | No options defined | – |
The Location Distance Option enables querying Location resources based on relative distances.
A Query Client or Directory that supports the Location Distance Option SHALL implement the semantics for the Location Distance Option of the Find Matching Care Services [ITI-90] transaction. See ITI TF-2: 2:3.90.4.1.2.2 and ITI TF-2: 2:3.90.4.2.2.2.
The Update Option enables sending bulk updates to the Update Client from the Directory.
A Directory that supports the Update Option SHALL implement the Request Care Services Updates [ITI-91] transaction.
The Feed Option enables receiving feed updates from the Feed Client from the Directory.
A Directory that supports the Update Option SHALL implement the Request Care Services Updates [ITI-91] transaction.
An actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the requirements for the grouped actor (Column 2).
Section 1:46.5 describes some optional groupings that may be of interest for security considerations and Section 1:46.6 describes some optional groupings in other related profiles.
Table 1:46.3-1: mCSD - Required Actor Groupings
| mCSD Actor | Actor to be grouped with | Reference | Content Bindings Reference |
|---|---|---|---|
| Directory | None | -- | -- |
| Query Client | None | -- | -- |
| Update Client | None | -- | -- |
| Data Source | None | -- | -- |
The Mobile Care Services Discovery (mCSD) Profile supports queries for resources related to care services discovery. The relationship between these entities is illustrated in Figure 1:46.4.1-1.
Figure 1:46.4.1-1: Top-level Relationships Between Care Services Entities
The patient, Vera Brooks, consults with her physician who recommends surgery. The physician can assist the patient in finding a suitable surgeon, taking into consideration the location and specialty of the surgeon.
Vera Brooks sees her family physician, Dr. West, regarding a recent knee injury.
Dr. West diagnoses the problem as a torn ACL and decides to refer Vera to an orthopedic surgeon.
Dr. West uses her EMR query tool, which implements a Query Client to search for orthopedic surgeons within 30km of Vera’s home.
The EMR retrieves the information from a Healthcare Worker Registry (HWR) and displays it to Dr. West.
Vera and Dr. West decide on an orthopedic surgeon; Dr. West prepares a referral.
The interactions between the various actors in this use case are shown in Figure 1:46.4.2.1.2-1.
Figure 1:46.4.2.1.2-1: Provider Query Use Case
During an emergency event, medical volunteers may report to assist. At an emergency site, the mCSD service can be queried to quickly identify and grant permission to credentialed providers to enter the scene.
During Hurricane Katrina, health care volunteers were turned away from disaster sites because there was no means available to verify their credentials. During the Ebola outbreak in West Africa, it was unclear which health workers were available and had been trained in clinical care techniques.
Resources from jurisdictional areas can be reported up to a central location so there is a single point of access. This would make it easier for responders on location to verify the credentials of a reporting health worker.
A jurisdictional (state/district) Directory will provide data to a central Update Client (National HIE).
The National HIE will be a Update Client grouped with a Directory.
An emergency responder (e.g., police on site controlling access) can use a Query Client to validate the credentials of a reporting health worker from the central Directory.
Based on the result, the emergency responder can allow or deny access to the reporting health worker.
The interactions between the various actors in this use case are shown in Figure 1:46.4.2.2.2-1.
Figure 1:46.4.2.2.2-1: Federated Data Site Management Workflow
Projects like the U.S. President’s Emergency Plan for AIDS Relief (PEPFAR)’s Data for Accountability, Transparency, and Impact (DATIM) need to have public health and service delivery indicators reported from a large number of sites (health facilities, communities, warehouses) within an Operating Unit (country/region). Within an Operating Unit, there are multiple, possibly overlapping, jurisdictions in operation which are managed by multiple organizations (e.g., ministries of health (MoH), faith-based organizations, international non-governmental organizations). The project needs to receive indicator submissions from pre-existing data systems hosted by these organizations. This data exchange requires a way to share site lists and implement identifier mapping between the sites in these lists.
Figure 1:46.4.2.3.1-1: Cross-Jurisdictional Data Exchange
An Operating Unit (OU) will run a Update Client and Directory for a specific geographic area (e.g., country). This Update Client will query other organizations (ministries of health, partners) operating in the geographic area to get updated site data for the sites managed by the OU.
An OU Update Client will query a sub-unit Directory (e.g., MoH) to get an updated list of sites under the sub-unit.
An OU Update Client will query a subunit Directory (e.g., partner) to get an updated list of sites under the subunit.
The OU Update Client will use entity matching to determine if there are duplicated sites in the combined data and flag them for review. (See https://wiki.ohie.org/display/documents/OpenHIE+Entity+Matching+Service.)
The interactions between the various actors in this use case are shown in Figure 1:46.4.2.3.2-1.
Figure 1:46.4.2.3.2-1: Cross-jurisdictional Site Management Workflow
A developing country has decided to implement a Master Facility List (MFL) based on recommendations from the WHO in the MFL Resource Package. This resource includes a minimum data set to uniquely identify, locate, and contact a specific facility. Since this will be a single source of information for the country, there may be differing hierarchies that need to be supported for the facilities. For example, one hierarchy would be the administrative hierarchy for the country (region, district, county). Another would be the supply chain hierarchy where hubs may be located separately from administrative regions. Yet another could be a reporting hierarchy used to send data to international organizations.
A Master Facility List (MFL) will run a Directory for an entire country. A Human Resources Information System (HRIS) will run a Update Client to retrieve the list of facilities. A Logistics Management Information System (LMIS) will run a Update Client to retrieve the list of facilities.
An HRIS will query the MFL for an updated list of facilities where Practitioners can provide care.
An LMIS will query the MFL for an updated list of facilities for the supply chain to deliver health care supplies.
The MFL will return updated facilities to each of these systems with multiple hierarchies.
The interactions between the various actors in this use case are shown in Figure 1:46.4.2.4.1-1.
Figure 1:46.4.2.4.2-1: Master Facility List Workflow
In this use case, a healthcare worker needs to identify the organizations active in the State/Province Health Information Exchange (HIE) that have been added since 2017, to make contact with new organizations and negotiate future clinical exchange.
Membership in an HIE is a more dynamic and transitory business relationship than the “parent-child” hierarchy represented by Organization.partOf. For these more flexible business relationships, the OrganizationAffiliation resource allows for organizations to relate to each other in non-hierarchical and more dynamic business relationships. Unlike partOf, the relationship is itself a resource, so it can be categorized with codes, status, etc.
In the example below:
The organization defines a role for the relationship, e.g., “HIE/HIO” or “member”, and the participatingOrganization fills the role.
Figure 1:46.4.2.5.1-1: Organization.partOf vs. Affiliation
organization is the HIE, active is true, and period.start is 2017 or later.The interactions between the various actors in this use case are shown in Figure 1:46.4.2.5.2-1.
Figure 1:46.4.2.5.2-1: Health Information Exchange (HIE) Membership Discovery Workflow
Users in Health IT systems often need to be able to obtain clinical information electronically from outside systems, for example, in preparation for an encounter. This use case describes how a user in a system identifies the organizations a patient has received care from, as well as criteria for the kinds of clinical documents of interest, and then how their EMR queries the directory for a Health Information Exchange (HIE) to search for each organization and a compatible services endpoint the EMR can use.
An HIE publishes a directory that contains all of its member organizations and their electronic endpoints.
Note: Guidance for usage of endpoints in directories is provided here.
The diagram below shows an excerpt of the HIE directory, showing one participant in the HIE that implements IHE XCA with two Endpoints, and another that only uses one.
Figure 1:46.4.2.6.1-1: Health Information Exchange
The interactions between the various actors in this use case are shown in Figure 1:46.4.2.6.2-1.
Figure 1:46.4.2.6.2-1: Health Information Exchange (HIE) Endpoint Discovery Workflow
A country or region may have a central facility registry and allow the facilities to directly manage its services and the relationship to its health workers:
Actors are expected to follow the recommendations and requirements found in ITI TF-2: Appendix Z.8 “Mobile Security Considerations”.
The resources exchanged in this profile may contain information which pose a privacy risk, or in some cases, a safety risk, to providers and other personnel, as well as patients. For example, practitioner phone numbers and home addresses may be conveyed. Implementers should determine what data will be exposed by the system and what level of public access there will be if any.
Access controls should be considered when allowing updates to the data in a directory to ensure only allowed users and/or systems are able to update data. This may include resource or element level controls as well as Provenance for documenting the data source. These access controls could be addressed by the client or the server as dictated by the implementation. It is recommended to use IUA for authorization.
The Endpoint Resources exchanged in this profile will expose information about the particular APIs and web services running on the underlying host systems. This might attract malicious activity or provide hints to potential attackers on how to attack a particular host system. Implementers should consider this when determining the access policies for these Resources. System administrators for the underlying host systems must follow industry best practices for authentication, authorization, auditing, timely application of software patches, etc.
There are many reasonable methods of security for interoperability transactions which can be implemented without modifying the characteristics of the transactions in the mCSD Profile. The use of TLS is encouraged.
User authentication on mobile devices and browsers is typically handled by more lightweight authentication schemes such as HTTP Authentication, OAuth 2.0, or OpenID Connect. IHE has a set of profiles for user authentication including Internet User Authentication (IUA) for REST-based authentication. The network communication security and user authentication are layered in the HTTP transport layer.
The IHE QRPH Aggregate Data Exchange (ADX) Profile enables reporting of public health and service delivery indicators in various locations. A reporting system may play the role of a Update Client to ensure that it has an updated list of the resources for the reporting locations.
Additionally, a service that contains information on practitioners (and may be a Directory) can also be used to generate an ADX message to satisfy the use case of a district health manager running an aggregate report on staffing levels by facility and health worker type from the ITI Care Services Discovery (CSD) Profile.
A Care Services Directory in the CSD Profile can be grouped with the Directory from mCSD. The CSD Care Services InfoManager could implement the mCSD Update Client and the Directory Actors. The CSD Service Finder could implement the mCSD Query Client. This enables the CSD actors to allow RESTful transactions without having to change the underlying data store.
A Provider Information Source in HPD can also implement the Directory from mCSD. Note that in this case the Provider Information Source would be queried for updates instead of pushing the updates to the HPD Provider Information Consumer. The HPD Provider Information Directory could implement the mCSD Update Client and the Directory Actors. The HPD Provider Information Consumer could implement the mCSD Query Client. This enables the HPD actors to allow RESTful transactions without having to change the underlying data store.
The mACM Profile defines the means to send an alert to practitioners. The mCSD Profile provides a way to query that list of practitioners. A mACM Alert Reporter can be grouped with a Update Client or a Query Client to ensure that it has an updated list of practitioners.
A basic deployment may only have a single directory that will maintain data internally. In this case, you would only need the Directory to send search results back to one or more Query Clients (or Update Clients). The Update Client could be a system that caches bulk updates for local reference and doesn’t do individual queries. See Figure 1:46.7.1-1 below.
Figure 1:46.7.1-1: Basic Deployment
A more common deployment may have a single directory with one or more data sources that feed data into the directory. This would also have one or more query or update clients to query the data in the directory. The Update Client could be a system that caches bulk updates for local reference and doesn’t do individual queries. See Figure 1:46.7.2-1 below.
Figure 1:46.7.2-1: Simple Deployment
A Federated Deployment has multiple levels of the Directories linked to Update Clients. These Update Clients may also support being Directories so that higher level Update Clients can receive their updates. See Figure 1:46.7.3-1 below.
Interrelated content is maintained by the Update Client. The Update Client routinely obtains new or updated content from Directories by polling them. These updates may refresh a data cache which the Update Client maintains. The Update Client’s cache is refreshed at an appropriate interval specified by the implementing jurisdiction. The implementing jurisdiction will consider the implications of out of date information when setting the refresh interval between cache updates. The normal delays in updating listings will also be part of this consideration.
The various data sources would maintain definitive data regarding one or more Care Services Resources and implement the Directory. These Directories would respond to a Update Client’s request for new or updated content since a specified date and time. To support this capability, a Directory should support time stamped updates. Data elements that are deprecated should not simply be deleted, but rather are updated to an appropriate status indicating their deprecation.
This deployment may also have cross-jurisdictional considerations if any of the Directories have overlap in the data they manage. In this instance, the Update Client would need to resolve any conflicts before sharing this information as a Directory. The way in which these conflicts are resolved is defined by the implementing jurisdiction of the Update Client.
Figure 1:46.7.3-1: Federated and Cross Jurisdictional Deployment
The Query Client is the actor that queries for information about interrelated care services. These queries are sent to the Directory who develops a response based on the content in its local data store. When a Directory is combined with a Update Client (Global and Country servers from Figure 1:46.7.3-1), it should maintain a cache of the aggregated information from all the configured Directories it is linked to.
In order for the Update Client’s (Global and Country servers) cached content to be able to serve its role as an interlinked data source, the following conditions should be met by Directories who maintain content.
Implementing jurisdictions may mandate terminologies for Organization Type, Service Type, Location Type, Location Status, Practitioner Type, Practitioner Status, Contact Point Type, Credential Type, Specialization Code, and language code. Directories would be configurable to use these terminologies, where mandated. In the case of a cross jurisdictional deployment, mapping between the terminology used by the various jurisdictions may need to be maintained.
Implementing jurisdictions may mandate conventions regarding the types, components and formatting of Name, Address and Address Line elements. Directories would be configurable to use these formatting conventions, where mandated.
Implementing jurisdictions may mandate the source of truth regarding Organization ID, Healthcare Service ID, Location ID and Practitioner ID. Directories would ensure that all cross-referenced IDs match corresponding resources in the jurisdictionally mandated sources of truth.
For guidance on handling challenges regarding the representation of names across multiple languages and in different cultures, refer to the ITI TF-2: 3.24.5.2.3.1. This section in the ITI Technical Framework describes the use of the language tag as documented in IETF RFC1766 and the HL7 XCN name data type.
All referenced terminologies from a Directory may be pre-coordinated or they may be resolvable from one or more terminology services. Though it is out of scope of the mCSD Profile to define the means of interacting with a terminology service, this could be provided, for example, through the Sharing Valuesets, Codes, and Maps (SVCM) Profile.
This section provides guidance for populating and using Endpoint resources in an mCSD directory to enable electronic communication, for example defining local points of connectivity within a community, or defining a Health Information Exchange (HIE) that allows multiple communities to interoperate.
Many current Endpoint directories based on FHIR are purpose-built, which is to say they are deployed to a server that only hosts Organization and Endpoint resources, and only for the use case of Endpoint lookup. For this reason, directories often reflect network details directly in the Organization resource, such as:
When the organization’s structure and its network capabilities need to vary independently (e.g., an organization uses two connectivity vendors), directories typically handle this by creating parallel instances of the Organization resource that then have to be merged by custom code to display.
We anticipate these conflicts increasing over time due to many forces:
In this guidance, we allow organization structure and network details to vary independently by moving network details out of the Organization and into the Endpoint and OrganizationAffiliation resources.
The simplest usage model for a client is when the organization it needs to contact has a dedicated Endpoint resource in Organization.endpoint. Because this Endpoint is Organization-specific, it does not matter to the client who hosts it. Some examples follow.
Note: The managingOrganization of an Endpoint is who users need to contact for support. It may or may not be the same as the organization that hosts it. Since hosting is not reflected in the directory, we are indicating it in the diagrams below by the URLs.
Organization A hosts its own Endpoint:
Figure 1:46.8.1-1: Organization-specific Endpoint Hosted by the Organization
Organization A is directly reachable by an endpoint hosted by its parent Organization B:
Figure 1:46.8.1-2: Organization-specific Endpoint Hosted by Parent
Organization C is directly reachable by an endpoint hosted by its affiliated Organization D:
Figure 1:46.8.1-3: Organization-specific Endpoint Hosted by Affiliation
Organization E is directly reachable by an endpoint hosted by a hidden (i.e., not in the directory) Intermediary F:
Figure 1:46.8.1-4: Organization-specific Endpoint Hosted by Hidden Intermediary
When an Organization with an Endpoint has a complex structure, for example, sub-organizations, clients can often make use of this structure:
Figure 1:46.8.2-1: Endpoint to Organizational Hierarchy
Typical directories will take an organizational hierarchy to imply accessibility to parts of the structure, for example:
Specific details of addressing to federated recipients are out of the scope of this IG.
Examples of this kind of federated structure are shown in ITI TF-1: Appendix E.9, for XCA Responding Gateways.
By contrast, OrganizationAffiliations by themselves do not necessarily imply this kind of electronic accessibility. For this reason, this IG defines the code “DocShare-federate”, which explicitly declares that the participatingOrganization is accessible as a federated organization via the OrganizationAffiliation.endpoint.
The following diagram shows the same accessibility, but using OrganizationAffiliation.
Figure 1:46.8.2-2: Endpoint to Organizational Affiliates
In addition, these mechanisms may be combined. This may be useful, for example, when adding an existing organizational structure to an HIE.
Figure 1:46.8.2-3: Endpoint to Hybrid Organizational Structure
Grouped actors may be represented as well, although not explicitly. In the following example, Participant A is reachable by either an MHD endpoint or XDR endpoints. The directory does not reflect which endpoint is the adapter or the adaptee.
Figure 1:46.8.3-1: Endpoints to Grouped Actors
The following example shows the steps used by a Query Client to navigate a directory to find suitable electronic service Endpoints to some desired Organizations. In this example, a “suitable” Endpoint means it supports an IHE Document Sharing profile, and is based on .connectionType, .extension:specificType, .payloadType, .payloadMimeType, and status (both Endpoint.status as well as the actual status of the electronic service). The example uses the [mCSD-profiled OrganizationAffiliation] StructureDefinition-IHE.mCSD.OrganizationAffiliation.DocShare.html) that indicates federated connectivity for Document Sharing (e.g., affiliated organizations may be addressed as intendedRecipient). The pseudocode below uses a depth-first, first-match search, and does not protect against loops.
Until a suitable Endpoint is found or the search is complete, check the following in this order:
Rather than a first-match search, the Query Client might search for and decide among multiple electronic paths to the same Organization. For example:
IG © 2022+ IHE IT Infrastructure Technical Committee. Package ihe.iti.mcsd#4.0.0-comment based on FHIR 4.0.1. Generated 2025-03-12
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change