The CA:CSD is based on the IHE mobile Care Service Directory (mCSD) (version 3.8.0).
To help ensure that French, and other languages, are handled properly FHIR has chosen to make UTF-8 its only acceptable character encoding. As HTTP's default encoding is not UTF-8 both the sender and receiver must state that want UTF-8 to be used. This is done by adding the preferred encoding to the header or including it in the URL
Header:
Accept: application/fhir+xml;charset=utf-8
Accept: application/fhir+json;charset=utf-8
Include in URL:
include _format parameter in the URL.
To help ensure that both the consumer and supplier are using the same method it is recommended that any any directory based on the CA:CSD FHIR specs include a section in their guide that states which method(s) will be supported.
You can find more information on how to handle the encoding in this blog article written by Firely.
| Resource.element | Details |
|---|---|
| [resource].id | The logical id is assigned by the server and may change when the same resource is sent to another server. It is not meant to be shown the end user. |
| [resource].identifier | The identifier is a business, or real world, identifier that will not change as the resource is sent between systems. Some examples are: a Patient heathcare number, MRN, practitioner license number |
| Resource.element | Details |
|---|---|
| HealthcareService.availableTime | The hours that the service is available at the associated location |
| Location.hoursOfOperation | The general hours that this location is avaiable, regardless of what services may be provided during that time. |
i.e. A health center is open from 8am - 8pm, but some services are only available from 9am - 5pm. The healthcare service available time would be 9am - 5pm and the location hours of operation would show 8am - 8pm
The following table shows which phone number to consider based on the reason for the call.
| resource | Reasoning |
|---|---|
| HealthcareService.telecom | This number should resolve to the department or person providing the health service at the associated location |
| Location.telecom | This number may resolve to a general front desk location that supports multiple services, which may be open at different hours. |
| Organization.telecom | This number would be for a general office that oversees all the locations associated with it |
The recommended format for phone numbers is:
(+[countrycode]-)[AreaCcode]-[exchange]-[subcriberNumber]( ext. [extension])
Examples:
The location resource is used to indicate a (physical or virtual) location of where the healthcare service is being provided. A location can be part of another location, such as a family Doctor's office that is part of a larger medical building that hosts several healthcare disciplines.
The medical building may be part of a larger organization such as a health region or a chain of health care locations. In this case the LocationFacility may be used, that would associate the location with a corresponding OrganizationFacility.
When a server supports queries based on distance, the LocationDistance resource can be used any place that a location resource is needed. If the Location is part of a facility or jurisdiction the associated resources can be used and the optional position elements can be populated.
| resource | Derived from | summary |
|---|---|---|
| Location | mCSD Location version 3.8.0 | This is the base Location resource used for the majority of situations |
| LocationDistance | mCSD LocationDistance version 3.8.0 | position.latitude and position.longitude are both required |
| LocationFacility | mCSD FacilityLocation version 3.8.0 | The Managing Organization is mandatory; type has a fixed value |
| LocationJurisdiction | mCSD JurisdictionLocation version 3.8.0 | The Managing Organization is mandatory; type has a fixed value |
Note: Additional recommendations and requirements provided by IHE can be found at 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.
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, specifically the use of the ATNA Profile (see ITI TF-1: 9).
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.
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 the endpoint.
The period and status can be used to indicate
You can access the mCSD guidance on Endpoints for more information on how Endpoints can be used at the organization level