From 30980eaa390ae37f034530600f0fe5f5aed265c6 Mon Sep 17 00:00:00 2001 From: Mary Jungers Date: Wed, 10 Aug 2022 13:39:19 -0500 Subject: [PATCH 1/6] updated Organization of This Guide section --- input/pagecontent/index.md | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/input/pagecontent/index.md b/input/pagecontent/index.md index 93826ca4..1e156f20 100644 --- a/input/pagecontent/index.md +++ b/input/pagecontent/index.md @@ -19,24 +19,23 @@ architectures and support a wide array of care workflows. ### Organization of This Guide This guide is organized into the following four main sections: -1. Volume 1: [46 mCSD Introduction](volume-1.html) - 1. [46.1 mCSD Actors, Transactions, and Content Modules](volume-1.html#1461-mcsd-actors-transactions-and-content-modules) - 2. [46.2 mCSD Actor Options](volume-1.html#1462-mcsd-actor-options) - 3. [46.3 mCSD Required Groupings](volume-1.html#1463-mcsd-required-actor-groupings) - 4. [46.4 mCSD Overview](volume-1.html#1464-mcsd-overview) - 5. [46.5 mCSD Security Considerations](volume-1.html#1465-mcsd-security-considerations) - 6. [46.6 mCSD Cross-Profile Considerations](volume-1.html#1466-mcsd-cross-profile-considerations) - 7. [46.7 mCSD Deployment Considerations](volume-1.html#1467-mcsd-deployment-considerations) - 8. [46.8 mCSD Endpoint Usage Considerations](volume-1.html#1468-mcsd-endpoint-usage-considerations) +1. Volume 1: Profiles + 1. [mCSD Introduction](volume-1.html) + 2. [mCSD Actors, Transactions, and Content Modules](volume-1.html#1461-mcsd-actors-transactions-and-content-modules) + 3. [mCSD Actor Options](volume-1.html#1462-mcsd-actor-options) + 4. [mCSD Required Groupings](volume-1.html#1463-mcsd-required-actor-groupings) + 5. [mCSD Overview](volume-1.html#1464-mcsd-overview) + 6. [mCSD Security Considerations](volume-1.html#1465-mcsd-security-considerations) + 7. [mCSD Cross-Profile Considerations](volume-1.html#1466-mcsd-cross-profile-considerations) + 8. [mCSD Deployment Considerations](volume-1.html#1467-mcsd-deployment-considerations) + 9. [mCSD Endpoint Usage Considerations](volume-1.html#1468-mcsd-endpoint-usage-considerations) 2. Volume 2: Transaction Detail - 1. [3.90 Find Matching Care Services \[ITI-90\]](ITI-90.html) - 2. [3.91 Request Care Services Updates \[ITI-91\]](ITI-91.html) - + 1. [Find Matching Care Services \[ITI-90\]](ITI-90.html) + 2. [Request Care Services Updates \[ITI-91\]](ITI-91.html) 3. [Test Plan](testplan.html) - 4. [Changes to other Profiles](other.html) -Click on any of the links above, go to the [table of contents](toc.html), or +Click on any of the links above, navigate the contents using the [table of contents](toc.html), or if you are looking for a specific artifact, check out the [index](artifacts.html). ### Conformance Expectations From 13eb9a651e90b9022d90e3eba931aa47914635ce Mon Sep 17 00:00:00 2001 From: Mary Jungers Date: Wed, 10 Aug 2022 14:52:57 -0500 Subject: [PATCH 2/6] punctuation and capitalization updates, transaction number format updates --- input/pagecontent/issues.md | 52 ++++++++++++++++++------------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/input/pagecontent/issues.md b/input/pagecontent/issues.md index cf80472f..ba59766f 100644 --- a/input/pagecontent/issues.md +++ b/input/pagecontent/issues.md @@ -29,7 +29,7 @@ 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. -In ITI-90, we've added a number of required search parameters to support +In \[ITI-90\], we've added a number of required search parameters to support queries for OrganizationAffiliation and Endpoint. Is it sustainable to require this many search parameters? Should we move some to SHOULDs or MAYs? Note that the main use case is locating an Organization based on its business, not network, attributes (already @@ -44,14 +44,14 @@ 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/](https://hl7.org/fhir/uv/vhdir/)? -[mCSD\_11](https://github.com/IHE/ITI.mCSD/issues/96). Should we assume federation of (i.e. connectivity to) child +[mCSD\_11](https://github.com/IHE/ITI.mCSD/issues/96). 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. +(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. [mCSD\_12](https://github.com/IHE/ITI.mCSD/issues/97). 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. +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\]. [mCSD\_14](https://github.com/IHE/ITI.mCSD/issues/98). Consider doing something similar to what [HL7 UDAP Security](https://build.fhir.org/ig/HL7/fhir-udap-security-ig/branches/main/) did, and @@ -61,12 +61,12 @@ where compatibility is assured as well as what each IGs focus is. For example, maintenance and validation of the content of directories, while mCSD covers how to represent and search complex structures. -[mCSD\_15](https://github.com/IHE/ITI.mCSD/issues/99). In [section 1:46.8](volume-1.html#1468-mcsd-endpoint-usage-considerations), +[mCSD\_15](https://github.com/IHE/ITI.mCSD/issues/99). In [Section 1:46.8](volume-1.html#1468-mcsd-endpoint-usage-considerations), we mention the US TEFCA RCE maintaining a consolidated directory spanning multiple networks. Can we identify an international example? -[mCSD\_16](https://github.com/IHE/ITI.mCSD/issues/100). In [section 1:46.8.2](volume-1.html#14682-endpoint-to-a-structure), -we say that a hierarchy formed by Organization.partOf implies federation of (i.e. connectivity to) child +[mCSD\_16](https://github.com/IHE/ITI.mCSD/issues/100). In [Section 1:46.8.2](volume-1.html#14682-endpoint-to-a-structure), +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 @@ -74,9 +74,9 @@ of “DocShare-federate” to be explicitly related to any parent-child relation We did not choose this because its impact on existing directory structures would be substantial. [mCSD\_18](https://github.com/IHE/ITI.mCSD/issues/101). Should we specify details of addressing federated recipients, at least for some -profiles (see [section 1:46.8.2](volume-1.html#14682-endpoint-to-a-structure))? -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. +profiles (see [Section 1:46.8.2](volume-1.html#14682-endpoint-to-a-structure))? +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\]. [mCSD\_20](https://github.com/IHE/ITI.mCSD/issues/102). There is minimal usage guidance for REST endpoints. Figure [1:46.8.3-1](volume-1.html#14683-grouping-actors) shows connectionType = hl7-fhir-rest and @@ -99,7 +99,7 @@ normatively anywhere. We have seen directories add a custom code "HCID" that shows that an identifier is a HCID, and have seen them use the system of "urn:ietf:rfc:3986" and a URN-encoded OID. In committee discussions, we walked this through, and the general consensus was that -for identifying an organization to meet the MHD to a Federation use cases (i.e. to +for identifying an organization to meet the MHD to a Federation use cases (i.e., to determine connectivity), whether or not an identifier happened to be a HCID was not significant. If we were to get into more detail about addressing federated recipients (see issue 15 in this list), we might need to make decisions like whether HCID must be @@ -109,16 +109,16 @@ a specific identifier type and whether it should be URN-encoded. to indicate that the endpoint is not constrained, should payloadType and payloadMimeType be empty, or fully populated? [mCSD\_24](https://github.com/IHE/ITI.mCSD/issues/105). In the [Resource Profile: mCSD Endpoint for Document Sharing](StructureDefinition-IHE.mCSD.Endpoint.DocShare.html), -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? +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? [mCSD\_25](https://github.com/IHE/ITI.mCSD/issues/106). In the [Resource Profile: mCSD Endpoint for Document Sharing](StructureDefinition-IHE.mCSD.Endpoint.DocShare.html), 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. [mCSD\_26](https://github.com/IHE/ITI.mCSD/issues/107). In the [Resource Profile: mCSD Endpoint for Document Sharing](StructureDefinition-IHE.mCSD.Endpoint.DocShare.html), would a Proxy service that is supporting OrgAff be a good example of NOT putting a homeCommunityId in the endpoint.identifier? -[mCSD\_27](https://github.com/IHE/ITI.mCSD/issues/108). Need to align and flesh out the examples better with the guidance in [section 1:46.8.2](volume-1.html#14682-endpoint-to-a-structure). For example, could we see an example for an organization accessible via two different exchanges? +[mCSD\_27](https://github.com/IHE/ITI.mCSD/issues/108). Need to align and flesh out the examples better with the guidance in [Section 1:46.8.2](volume-1.html#14682-endpoint-to-a-structure). For example, could we see an example for an organization accessible via two different exchanges? -[mCSD\_28](https://github.com/IHE/ITI.mCSD/issues/109). Grouping of actors is mentioned in [section 1:46.8.3](volume-1.html#14683-grouping-actors). +[mCSD\_28](https://github.com/IHE/ITI.mCSD/issues/109). Grouping of actors is mentioned in [Section 1:46.8.3](volume-1.html#14683-grouping-actors). Does Karen's Cross apply here? If so, how? Should OrganizationAffiliation be required? [Karen's Cross](https://wiki.directproject.org/w/images/3/3e/2011-03-09_PDF_-_XDR_and_XDM_for_Direct_Messaging_Specification_FINAL.pdf#page=6) @@ -173,7 +173,7 @@ preserved in responses and respected in requests. With opaque federation, identi consolidated/overwritten with the identifiers of the "parent" organization. Probably, but the implications of opaque federation are complex. Some aspects may be consolidated -(e.g. golden patient record) while others are not (separate documents). Perhaps we could limit scope +(e.g., golden patient record) while others are not (separate documents). Perhaps we could limit scope to whether federated communities (Organizations with an ID of type HCID) are addressable in requests and responses. Seeking input from reviewers. @@ -191,7 +191,7 @@ either managingOrganization or contact must be populated. [mCSD\_33](https://github.com/IHE/ITI.mCSD/issues/114). 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](https://github.com/IHE/ITI.mCSD/issues/89). -[mCSD\_34](https://github.com/IHE/ITI.mCSD/issues/58). Should we add a subscription model for receiving updates instead of or in addition to ITI-91 for resource updates? +[mCSD\_34](https://github.com/IHE/ITI.mCSD/issues/58). Should we add a subscription model for receiving updates instead of or in addition to \[ITI-91\] for resource updates? ### Closed Issues These issues have been decided and documented in the publication. @@ -312,13 +312,13 @@ generalized to allow usage with mCSD as well as other directory IGs like Duplicate of mCSD\_10 -*mCSD\_17. In [section 1:46.8.2](volume-1.html#14682-endpoint-to-a-structure), +*mCSD\_17. In [Section 1:46.8.2](volume-1.html#14682-endpoint-to-a-structure), we say that a hierarchy formed by the mCSD Additional Hierarchies extension -does not imply federation of (i.e. connectivity to) child organizations. Should it?* +does not imply federation of (i.e., connectivity to) child organizations. Should it?* Extension has been removed. -*mCSD\_19. In [section 1:46.8.2](volume-1.html#14682-endpoint-to-a-structure), +*mCSD\_19. In [Section 1:46.8.2](volume-1.html#14682-endpoint-to-a-structure), why do we use OrganizationAffiliation for an organization's membership in an HIE, as opposed to the mCSD Additional Hierarchies extension? Because we don't wish to constrain the use of resources that define organizational structure, @@ -328,7 +328,7 @@ its examples.* Extension has been removed. -*mCSD\_22. In ITI-90, we've added a number of required search parameters to support +*mCSD\_22. In \[ITI-90\], we've added a number of required search parameters to support queries for OrganizationAffiliation and Endpoint. Is it sustainable to require this many search parameters? Should we move some to SHOULDs or MAYs? Note that the main use case is locating an Organization based on its business, not network, attributes (already @@ -343,11 +343,11 @@ Combined into related open issue 7. - Added [Use Case #5: Organization Affiliation](volume-1.html#146425-use-case-5-health-information-exchange-hie-membership-discovery), describing how OrganizationAffiliations can represent non-hierarchical relationships between Organizations - Added [Use Case #6: Health Information Exchange (HIE) Endpoint Discovery](volume-1.html#146426-use-case-6-health-information-exchange-hie-endpoint-discovery), showing an example of querying a directory with Endpoint resources -- Added new section [1:46.8 mCSD Endpoint Usage Considerations](volume-1.html#1468-mcsd-endpoint-usage-considerations), +- Added new Section [1:46.8 mCSD Endpoint Usage Considerations](volume-1.html#1468-mcsd-endpoint-usage-considerations), describing how to populate and use a directory with Endpoint resources to enable electronic communications -- ITI-90: added OrganizationAffiliation and Endpoint resources to [Description and Message Semantics](ITI-90.html#239041-find-matching-care-services-request-message) -- ITI-90: added expected search parameters for [Organization](ITI-90.html#23904122-organization-resource-message-semantics) to support OrganizationAffiliation and Endpoint resources -- ITI-90: added sections for expected search parameters for [Endpoint](ITI-90.html#23904128-endpoint-resource-message-semantics) and [OrganizationAffiliation](ITI-90.html#23904129-organizationaffiliation-resource-message-semantics) +- \[ITI-90\]: added OrganizationAffiliation and Endpoint resources to [Description and Message Semantics](ITI-90.html#239041-find-matching-care-services-request-message) +- \[ITI-90\]: added expected search parameters for [Organization](ITI-90.html#23904122-organization-resource-message-semantics) to support OrganizationAffiliation and Endpoint resources +- \[ITI-90\]: added sections for expected search parameters for [Endpoint](ITI-90.html#23904128-endpoint-resource-message-semantics) and [OrganizationAffiliation](ITI-90.html#23904129-organizationaffiliation-resource-message-semantics) - Added the following to deal with FHIR R4 Endpoint.connectionType being limited to one value from an HL7 valueSet (see [FHIR-12342](https://jira.hl7.org/browse/FHIR-12342): need more detail to connect to an IHE Document Sharing endpoint): - A code system [mCSD Endpoint Types](CodeSystem-MCSDEndpointTypes.html) to define IHE Endpoint types beyond those in the FHIR core, using the same abstract codes HL7 uses like "ihe-xca", but adds child codes like "XCA-RespGateway-Query" @@ -358,7 +358,7 @@ Combined into related open issue 7. - Added structure definitions for resource profiles: - [mCSD Endpoint](StructureDefinition-IHE.mCSD.Endpoint.html): general Endpoint - [mCSD Endpoint for Document Sharing](StructureDefinition-IHE.mCSD.Endpoint.DocShare.html): - Endpoint that supports IHE Document Sharing (e.g. XCA, MHD), using the [extension for Endpoint Specific Type](StructureDefinition-ihe-endpointspecifictype.html) + Endpoint that supports IHE Document Sharing (e.g., XCA, MHD), using the [extension for Endpoint Specific Type](StructureDefinition-ihe-endpointspecifictype.html) - [mCSD Organization Affiliation](StructureDefinition-IHE.mCSD.OrganizationAffiliation.html): general OrganizationAffiliation. - [mCSD Organization Affiliation DocumentSharing](StructureDefinition-IHE.mCSD.OrganizationAffiliation.DocShare.html): OrganizationAffiliation that supports IHE Document Sharing, using a fixed code "DocShare-federate" that indicates that the affiliation implies electronic access to the participatingOrganization (see [1:46.8 mCSD Endpoint Usage Considerations](volume-1.html#1468-mcsd-endpoint-usage-considerations)) - Added [examples](artifacts.html#example-example-instances) for OrganizationAffiliation and Endpoint From 3cb9a034272ba5e0761456c7a43036edfc230450 Mon Sep 17 00:00:00 2001 From: Mary Jungers Date: Wed, 10 Aug 2022 15:43:46 -0500 Subject: [PATCH 3/6] couple minor wording updates --- input/pagecontent/volume-1.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/input/pagecontent/volume-1.md b/input/pagecontent/volume-1.md index 6ee99919..ff3dde21 100644 --- a/input/pagecontent/volume-1.md +++ b/input/pagecontent/volume-1.md @@ -380,7 +380,7 @@ The mACM Profile defines the means to send an alert to practitioners. The mCSD P ### 1:46.7.1 Simple Deployment -A deployment may only have a single server that will maintain data. In this case, you would only need the Care Services Selective Supplier (or Care Services Update Supplier) to send search results back to one or more Care Services Selective Consumers (or Care Services Update Consumer). See Figure 1:46.7.1-1. +A deployment may only have a single server that will maintain data. In this case, you would only need the Care Services Selective Supplier (or Care Services Update Supplier) to send search results back to one or more Care Services Selective Consumers (or Care Services Update Consumer). See Figure 1:46.7.1-1 below.
{%include simple-deployment.svg%} @@ -391,7 +391,7 @@ A deployment may only have a single server that will maintain data. In this case ### 1:46.7.2 Federated and Cross-Jurisdictional Deployments -A Federated Deployment has multiple levels of the Care Services Update Suppliers linked to Care Services Update Consumers. These Update Consumers may also support being Care Services Update Suppliers so that higher level Update Consumers can receive their updates. They may also support being a Care Services Selective Supplier so that Selective Consumer clients can query that level of information. See Figure 1:46.7.2-1. +A Federated Deployment has multiple levels of the Care Services Update Suppliers linked to Care Services Update Consumers. These Update Consumers may also support being Care Services Update Suppliers so that higher level Update Consumers can receive their updates. They may also support being a Care Services Selective Supplier so that Selective Consumer clients can query that level of information. See Figure 1:46.7.2-1 below. Interrelated content is maintained by the Care Services Update Consumer. The Care Services Update Consumer routinely obtains new or updated content from Care Services Update Suppliers by polling them. These updates may refresh a data cache which the Update Consumer maintains. The Update Consumer’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. From b8eb3a00385bf02ffab2f3ece445deda7f2182fe Mon Sep 17 00:00:00 2001 From: Mary Jungers Date: Wed, 10 Aug 2022 16:05:49 -0500 Subject: [PATCH 4/6] capitalization updates, punctuation updates --- input/pagecontent/other.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/input/pagecontent/other.md b/input/pagecontent/other.md index 8acd2ded..35967e25 100644 --- a/input/pagecontent/other.md +++ b/input/pagecontent/other.md @@ -1,5 +1,5 @@
-This section contains modifications to other IHE publications and profiles, and is not a part of the mCSD profile. The content here will be incorporated into the target narrative at a future time, usually when mCSD goes final-text. +This section contains modifications to other IHE publications and profiles, and is not a part of the mCSD Profile. The content here will be incorporated into the target narrative at a future time, usually when mCSD goes final text.
## IHE Technical Frameworks General Introduction Appendix A: Actors From e4a3281f01d7b5762ea02b906f0acb55946089f2 Mon Sep 17 00:00:00 2001 From: Mary Jungers Date: Wed, 10 Aug 2022 16:08:02 -0500 Subject: [PATCH 5/6] removed extra spaces between sentences --- input/pagecontent/testplan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/input/pagecontent/testplan.md b/input/pagecontent/testplan.md index e16c08fd..d63e3557 100644 --- a/input/pagecontent/testplan.md +++ b/input/pagecontent/testplan.md @@ -1,5 +1,5 @@
-This Test Plan page is a prototype. We expect the maturity of the content will improve over time. For now, we summarize high level testing scope and available tools. Comments are welcome. +This Test Plan page is a prototype. We expect the maturity of the content will improve over time. For now, we summarize high level testing scope and available tools. Comments are welcome.
From 6ffc4db9748a1a10b5079797784d3314a39cc5b9 Mon Sep 17 00:00:00 2001 From: Mary Jungers Date: Wed, 10 Aug 2022 21:34:04 -0500 Subject: [PATCH 6/6] minor format update --- input/pagecontent/ITI-90.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/input/pagecontent/ITI-90.md b/input/pagecontent/ITI-90.md index 4ed747ad..853050fc 100644 --- a/input/pagecontent/ITI-90.md +++ b/input/pagecontent/ITI-90.md @@ -302,7 +302,7 @@ If the Care Services Selective Supplier is unable to produce a response in the r ###### 2:3.90.4.4.2.1 Care Services Resource Definition in the Context of Care Services Resource Response The Care Services Resource definition in the context of a retrieve interaction is the FHIR definition of the various Care Services Resources. Table 2:3.90.4.4.2.1-1 lists the resources with where to find the additional constraints. -**Table 2:3.90.4.4.2.1-1: Care Services Resource Constraints** +**Table 2:3.90.4.4.2.1-1: Care Services Resource Constraints** | Resource | Section | | ------------------- | --------- |