Unattributed Code Systems

Copyright Fragment

This fragment is available on download.html

This publication includes IP covered under the following statements.

Copyright and Registered Trademark Uses

External References

Type Reference Content
web example.org address : http://example.org/pacs
web example.org address : http://example.org/xca/query
web example.org address : http://example.org/xca/retrieve
web profiles.ihe.net
web profiles.ihe.net
web github.com Mobile Care Services Discovery (mCSD), published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 4.0.1-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.mCSD/ and changes regularly. See the Directory of published versions
web www.ihe.net IG © 2022+ IHE IT Infrastructure Technical Committee . Package ihe.iti.mcsd#4.0.1-current based on FHIR 4.0.1 . Generated 2025-05-21
Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web github.com Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web github.com Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web profiles.ihe.net Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web www.ihe.net Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web profiles.ihe.net A Directory SHALL also support the requirements in ITI TF-2: Z.6 , Populating the Expected Response Format.
web profiles.ihe.net Access controls should be considered 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.
web profiles.ihe.net See ITI TF-2: Appendix Z.8 for common mobile security considerations.
web profiles.ihe.net A Directory shall support responding to a request for both the JSON and the XML messaging formats as defined in FHIR. A Query Client shall accept at least one of either the JSON or the XML messaging formats as defined in FHIR. See ITI TF-2: Z.6 for more details.
web profiles.ihe.net See ITI TF-2: Appendix W for informative implementation material for this transaction.
web profiles.ihe.net It shall also support the requirements in ITI TF-2: Z.6 , Populating the Expected Response Format.
web profiles.ihe.net See ITI TF-2: Appendix Z.6 for more details on response format handling. See ITI TF-2: Appendix Z.7 for guidance on Access Denied.
web profiles.ihe.net See ITI TF-2: Appendix Z.6 for more details on response format handling. See ITI TF-2: Appendix Z.7 for guidance on Access Denied.
web profiles.ihe.net They shall also support the requirements in ITI TF-2: Z.6 , Populating the Expected Response Format.
web www.omg.org Mappings for ServD ( http://www.omg.org/spec/ServD/1.0/ )
web www.who.int A Practitioner is a health worker such as defined by WHO ; a Practitioner might be a physician, nurse, pharmacist, community health worker, district health manager, etc. Practitioners have contact and demographic attributes. Each Practitioner may be related to one or more Organizations , one or more Locations and one or more Healthcare Services through a Practitioner Role . Specific attributes may be associated with the Practitioner relationship with these other entities.
web en.wikipedia.org Both Bundle.link and Bundle.entry.link are defined to support providing additional context when Bundles are used (e.g. HATEOAS ).
web github.com The source code for this Implementation Guide can be found on IHE GitHub .
web www.ihe.net Some content from IHE® Copyright © 2015 IHE International, Inc .
Show Usage
web www.google.com Search This IG
web profiles.ihe.net IHE uses the normative words: “REQUIRED”, “REQUIRED NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” according to standards conventions .
web profiles.ihe.net The use of RequiredSupport in StructureDefinition profiles is equivalent to the IHE use of R2 as defined in Appendix Z .
web github.com Fix for Issue 166 on physicalType cardinality
web github.com Fix for Issue 157 on partof search parameter requirement to SHOULD
web github.com Fix for Issue 158 on linking to the capability statement display for search parameters
web github.com Changed CapabilityStatements to use FSH and added expectations to fix Issue 185
web profiles.ihe.net Renamed 1:46.8 mCSD Endpoint Usage Considerations to “mCSD as a Health Information Network Directory” and simplified the section; removing content that is duplicative of the IHE Document Sharing Across Network Topologies white paper
web www.ihe.net FHIR Implementation Guide instead of pdf - Rev. 3.3
web github.com IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues may be submitted at ITI Public Comments .
web www.ihe.net IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues may be submitted at ITI Public Comments .
web github.com 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).
web wiki.ihe.net 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).
web www.ihe.net 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).
web github.com 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.
web github.com mCSD_12 . Should we specify details of addressing to federated recipients, at least for some profiles (see Section 1:46.8.2)? For example, with MHD [ITI-65] we could pass the Organization.identifier in the intendedRecipient field. There is already an IG for passing a Direct address in an XDR [ITI-41].
web github.com mCSD_14 . Consider doing something similar to what HL7 UDAP Security did, and describe mCSD within the larger family of directory IGs, making clear where compatibility is assured as well as what each IGs focus is. For example, https://hl7.org/fhir/uv/vhdir/ covers maintenance and validation of the content of directories, while mCSD covers how to represent and search complex structures.
web github.com mCSD_18 . Should we specify details of addressing federated recipients, at least for some profiles? For example, with MHD [ITI-65] we could pass the Organization.identifier in the intendedRecipient field. There is already an IG for passing a Direct address in an XDR [ITI-41].
web github.com mCSD_20 . There is minimal usage guidance for REST endpoints. Is this necessary? Can clients discover anything they need to know about REST from the CapabilityStatement?
web github.com mCSD_21 . This profile says very little about home community ID, yet it is called out in mCSD issue #2 . The profile on Endpoint for Document Sharing says to put the HCID in the Endpoint.identifier. The Example of an mCSD XCA Query Endpoint shows an Endpoint.identifier.type with coding for a HCID. But this is not specified normatively anywhere.
web github.com mCSD_21 . This profile says very little about home community ID, yet it is called out in mCSD issue #2 . The profile on Endpoint for Document Sharing says to put the HCID in the Endpoint.identifier. The Example of an mCSD XCA Query Endpoint shows an Endpoint.identifier.type with coding for a HCID. But this is not specified normatively anywhere.
web github.com mCSD_23 . In the Resource Profile: mCSD Endpoint for Document Sharing , to indicate that the endpoint is not constrained, should payloadType and payloadMimeType be empty, or fully populated?
web github.com mCSD_24 . In the Resource Profile: mCSD Endpoint for Document Sharing , should payloadType and payloadMimeType be required to be the same for Endpoints that reflect grouped actors (i.e., XCA/XDS/MHD Query and XCA/XDS/MHD Retrieve), thus replicating the capability at both endpoints?
web github.com mCSD_25 . In the Resource Profile: mCSD Endpoint for Document Sharing , should payloadType and payloadMimeType be specified for an XCA Query endpoint? It did not seem right that Query be indicated with a mimeType of ebRegistry as that is not helpful to the use-case.
web github.com mCSD_26 . In the Resource Profile: mCSD Endpoint for Document Sharing , would a Proxy service that is supporting OrgAff be a good example of NOT putting a homeCommunityId in the endpoint.identifier?
web wiki.directproject.org Karen’s Cross (see 3.0 Interaction Patterns. Also described here ) is a mapping table defined by the Direct Project (not by IHE), that tells how to get to and from different flavors of IHE Document Sharing “Push” (XDR, XDM) and the Direct Protocol. It was done at a “whiteboard” level of detail, and resulted in specific requirements for transforming messages more or less isomorphically from one flavor to another. Later, additional requirements were added for encoding Direct addresses in XDR SubmissionSet.intendedRecipient. It should be noted that the Cross is incomplete; neither Direct nor IHE has any analogous requirements for transforming, say, an XCA Query and Retrieve response into an XDM file. XCDR and MHD Push and Pull are also missing. That said, IHE Document Sharing profiles (not counting Direct) are generally considered similar enough that transformations should be obvious.
web healthcaresecprivacy.blogspot.com Karen’s Cross (see 3.0 Interaction Patterns. Also described here ) is a mapping table defined by the Direct Project (not by IHE), that tells how to get to and from different flavors of IHE Document Sharing “Push” (XDR, XDM) and the Direct Protocol. It was done at a “whiteboard” level of detail, and resulted in specific requirements for transforming messages more or less isomorphically from one flavor to another. Later, additional requirements were added for encoding Direct addresses in XDR SubmissionSet.intendedRecipient. It should be noted that the Cross is incomplete; neither Direct nor IHE has any analogous requirements for transforming, say, an XCA Query and Retrieve response into an XDM file. XCDR and MHD Push and Pull are also missing. That said, IHE Document Sharing profiles (not counting Direct) are generally considered similar enough that transformations should be obvious.
web wiki.directproject.org Karen’s Cross (see 3.0 Interaction Patterns. Also described here ) is a mapping table defined by the Direct Project (not by IHE), that tells how to get to and from different flavors of IHE Document Sharing “Push” (XDR, XDM) and the Direct Protocol. It was done at a “whiteboard” level of detail, and resulted in specific requirements for transforming messages more or less isomorphically from one flavor to another. Later, additional requirements were added for encoding Direct addresses in XDR SubmissionSet.intendedRecipient. It should be noted that the Cross is incomplete; neither Direct nor IHE has any analogous requirements for transforming, say, an XCA Query and Retrieve response into an XDM file. XCDR and MHD Push and Pull are also missing. That said, IHE Document Sharing profiles (not counting Direct) are generally considered similar enough that transformations should be obvious.
web docs.google.com Karen’s Cross (see 3.0 Interaction Patterns. Also described here ) is a mapping table defined by the Direct Project (not by IHE), that tells how to get to and from different flavors of IHE Document Sharing “Push” (XDR, XDM) and the Direct Protocol. It was done at a “whiteboard” level of detail, and resulted in specific requirements for transforming messages more or less isomorphically from one flavor to another. Later, additional requirements were added for encoding Direct addresses in XDR SubmissionSet.intendedRecipient. It should be noted that the Cross is incomplete; neither Direct nor IHE has any analogous requirements for transforming, say, an XCA Query and Retrieve response into an XDM file. XCDR and MHD Push and Pull are also missing. That said, IHE Document Sharing profiles (not counting Direct) are generally considered similar enough that transformations should be obvious.
web github.com mCSD_29 . Is OrganizationAffiliation sufficiently mature to base this profile on? Is it appropriate to say the .organization is the “parent-like” org that rolls up content from .participatingOrganization orgs? There is a .network field; should that be used instead?
web github.com mCSD_31 . Currently, only synchronous XDS/XCA/XDR and MHD Push are supported. This scope was limited for the public-comment deadline. After public comment, we plan to add in asynchronous (WS-A and AS4) and full MHD. One area that needs work is Digital Certificates to support async end-to-end security (Not needed for sync that uses TLS).
web github.com mCSD_32 . In mCSD Endpoint , rather than managingOrganization 1..1, create an invariant so that either managingOrganization or contact must be populated.
web github.com mCSD_33 . FHIR R5 will allow Endpoint.connectionType to be greater than 1, so we can use the IHE-defined codes in addition to the HL7 ones. We won’t need Endpoint.extension:specificType anymore. See Issue 89 .
web github.com mCSD_33 . FHIR R5 will allow Endpoint.connectionType to be greater than 1, so we can use the IHE-defined codes in addition to the HL7 ones. We won’t need Endpoint.extension:specificType anymore. See Issue 89 .
web github.com mCSD_34 . Should we add a subscription model for receiving updates instead of or in addition to [ITI-91] for resource updates?
web github.com mCSD_10 . Section 1:46.8 mCSD Endpoint Usage Considerations, describes how to populate and use an endpoint directory. Given that this IG is more about how to deploy and use directories than what to put in them, would this content be better as a white paper instead? And could this content be generalized to allow usage with mCSD as well as other directory IGs like https://hl7.org/fhir/uv/vhdir/ ?
web profiles.ihe.net Streamlined and renamed section 1:46.8 and referenced the white paper Document Sharing Across Network Topologies white paper
web github.com mCSD_11 . Should we assume federation of (i.e., connectivity to) child organizations when related by .partOf? Currently the IG does (see Section 1:46.8.2), and we believe this is what is done in practice. The downside is that there is no way to represent a hierarchical relationship that does not imply routing.
web profiles.ihe.net This topic is now covered in the white paper Document Sharing Across Network Topologies white paper
web github.com mCSD_15 . In Section 1:46.8 , we mention the US TEFCA RCE maintaining a consolidated directory spanning multiple networks. Can we identify an international example?
web profiles.ihe.net This section has been removed and we instead reference the white paper Document Sharing Across Network Topologies white paper
web github.com mCSD_16 . In Section 1:46.8.2, we say that a hierarchy formed by Organization.partOf implies federation of (i.e., connectivity to) child organizations. Should we? We believe this is what is done in practice. The downside is that there would be no way to represent a hierarchical relationship that does not imply routing. An alternative proposed design would require OrganizationAffiliation with a code of “DocShare-federate” to be explicitly related to any parent-child relationship to imply connectivity. We did not choose this because its impact on existing directory structures would be substantial.
web github.com mCSD_27 . Need to align and flesh out the examples better with the guidance in Section 1:46.8.2. For example, could we see an example for an organization accessible via two different exchanges?
web github.com mCSD_28 . Grouping of actors is mentioned in Section 1:46.8.3. Does Karen’s Cross apply here? If so, how? Should OrganizationAffiliation be required?
web github.com mCSD_30 .Currently there is one code in mCSD Organization Affiliation Types. Should there be at least two, one for transparent federation vs opaque federation? The expectations would be different: with transparent federation, federated identifiers would be preserved in responses and respected in requests. With opaque federation, identifiers would be consolidated/overwritten with the identifiers of the “parent” organization.
web profiles.ihe.net Editor, add the following new or modified actors to the IHE Technical Frameworks General Introduction Appendix A :
web profiles.ihe.net Editor, add the following new or modified transactions to the IHE Technical Frameworks General Introduction Appendix B :
web profiles.ihe.net Use cases and solutions using mCSD are outlined in the mCSD White Paper .
web whqlibdoc.who.int 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.
web profiles.ihe.net 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 .
web profiles.ihe.net 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 .
web profiles.ihe.net 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.
web wiki.ohie.org 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 .)
web www.who.int 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.
web profiles.ihe.net Actors are expected to follow the recommendations and requirements found in ITI TF-2: Appendix Z.8 “Mobile Security Considerations” .
web profiles.ihe.net 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.
web profiles.ihe.net 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.
web www.ihe.net 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 .
web profiles.ihe.net Readers who are interested in representing a document sharing network in a Directory are strongly encouraged to read the IHE Document Sharing Across Network Topologies white paper for additional guidance in representing the network structure.

Internal Images

mCSDRelationships.png
mCSDRelationships.png