Mobile Care Services Discovery (mCSD)
3.3.1 - ci-build

Mobile Care Services Discovery (mCSD) - Local Development build (v3.3.1). See the Directory of published versions

mCSD Open and Closed issues

Significant changes from mCSD, Rev 3.3:

  • FHIR Implementation Guide instead of pdf - Rev. 3.3
  • Removed inline UML text and moved it to images-source/
  • Removed reference to setting meta.profile as it is redundant
  • Added sections in actor requirements describing the requirement of providing a capability statement Volume 1
  • Updated the canonical URL for the organization hierarchy extension to
  • Added links to the structure definitions for resource profiles to ITI-90 and ITI-91
  • Changed structuredefinitions for Facility and Jurisdiction to use an invariant for the type requirement instead of slicing.


IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues may be submitted to the Public Comment form.

As issues are submitted they will be managed on the mCSD GitHub Issues, where discussion and workarounds may be found. These issues, when critical, will be processed using the normal IHE Change Proposal management and balloting. It is important to note that as soon as a Change Proposal is approved, it carries the same weight as a published Implementation Guide (i.e., it is testable at an IHE Connectathon from the time it is approved, even if it will not be integrated until several months later).

Open Issues and Questions

These issues were known as part of the publication, and IHE invites comments.

mCSD_7. Should there be additional required search parameters? Should we also require any reverse chaining (_has) options for the search? Should we require any reverse includes (_revinclude)? These would add complexity to the server and most will have similar options through include and normal chaining.

Closed Issues

These issues have been decided and documented in the publication.

mCSD_1. Should we include the FreeBusy transaction and use cases or just remove them?

  • Take this out, and possibly add later if needed as an option.

*mCSD_2. Should we include the aggregate reporting use case from Care Services Discovery (CSD) or remove with a reference to Aggregate Data Exchange (ADX) in cross profile considerations? This use case would define options for the actors in this use case to return aggregate data. *

  • At this time we do not believe these are key uses cases, but request feedback.

*mCSD_3. How do we capture data about community health workers? In some environments, there are community health workers that are associated with a facility but don’t actually work there. Such a worker might have a set area of villages that they rotate through providing community-based care. The villages are within the catchment area of a Health facility, and the supervisor of the community health worker may be based at that facility. *

Not quite sure the best way to capture this when looking at:

*It is clear that we have a hierarchy of locations to capture the geographic hierarchy (jurisdictions): *

  • The health facility in question would be situated at a location above the village level, say at the county or district level - this we can capture in the parent-child relationship “partOf” in the location resource

  • The community health worker is providing services at several villages - this we can capture through the location data field of the role in the practitioner resource

  • The community health worker is associated to a health facility - again we can capture this through the location field but perhaps we would use a different role to indicate that they’re community health worker associated to this facility but not directly providing services at the facility, only its catchment area

  • In case a community health worker is reporting to a supervisor - that’s not captured anywhere that I can see in FHIR. I think this is a larger that exists beyond the community health worker context

Perhaps the best way to model this is to define each village as a location, and associate that worker with each location they rotate through. Each village is a partOf the health district. The facility is also a location that is partOf the district. The practitioner is related to the village locations with a “delivers care to” role; and to the facility with a “based out of” role.

mCSD_4. Do we need to include more geospatial data (such as polygons or more complex geometry types) stored with Locations and how? This would be so jurisdictions (such as districts or counties) could include that data instead of just a position (latitude/longitude). CP#13391 has been opened for this.

As per the request, FHIR has added a standard extension to address this:

mCSD_5. With a federated deployment, data may come from multiple sources and there can be an issue with resolving duplicate records and maintaining the mapping. Patient has a link field and we have opened a CP for Organization, Location, and Practitioner. CP GF#13264 has been opened for this. There is also the Linkage resource, but it is maturity level 0.

FHIR has closed the issued with the recommendation to use the Linkage resource to handle this.

mCSD_6. We need a way to deprecate identifiers. For now we can use period and we have created a CP to add an entry to the use field: GF#13265.

FHIR has added an additional Identifier.use code of “old” for this case.

mCSD_8. IHE has updated mCSD to add support for organizational facilities. As part of this revision of mCSD, we have removed the “Organization Option”, “Location Option”, “Practitioner Option”, and “Healthcare Services Option”. These options existed to enable servers to focus only on a small subset of the resources. The actual burden to support all resources is small and set of options seems to add unnecessary complexity. The result would be that servers shall support all of the FHIR Resources, the clients can use the FHIR Resources in the way defined. If there is concern with the removal of these options, please submit a Public Comment.

No comments received so changes are being kept, but any additional comments are welcome.

mCSD_9. We have added a requirement to include a meta.profile tag for all compliant resources. This is so that in a mixed server that has these resources as well as others, a Care Services Selective Consumer can limit the results of Find Matching Care Service [ITI-90] to only mCSD resources using the _profile parameter. Since this type of parameter isn’t allowed for the _history transaction for Request Care Services Updates [ITI-91] the Care Services Update Consumer may have to filter results if required. Is this a common configuration and is this step necessary?

Removed the references to meta.profile.