IHE PCC Referral Status Query
0.0.1-current - ci-build
IHE PCC Referral Status Query
0.0.1-current - ci-build
IHE PCC Referral Status Query, published by IHE Patient Care Coordination Technical Committee. This guide is not an authorized publication; it is the continuous build for version 0.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/PCC.SDOH.RSQ/ and changes regularly. See the Directory of published versions
TODO: Provide an end-user friendly overview of what the profile does for them. Keep it brief (a paragraph or two, up to a page). If extensive detail is needed, it should be included in Section XX.4- Use Cases.
**TODO: Explicitly state whether this is a Workflow, Transport, or Content Module (or combination) profile. See the IHE Technical Frameworks General Introduction for definitions of these profile types. The IHE Technical Frameworks General Introduction. **
The following actors and transactions are defined in this implementation guide:
The figure below shows the actors directly involved in the SDOH Referral Status Query Profile and the relevant transactions between them.
Table X.1-1: SDOH-RSQ Profile - Actors and Transactions
| Actors | Transactions | Initiator or Responder | Optionality | Reference |
|---|---|---|---|---|
| Referral Status Consumer | Retrieve SDOH Referral Status | Initiator | R | PCC TF-2: 3.Y6 |
| Referral Status Provider | Retrieve SDOH Referral Status | Responder | R | PCC TF-2: 3.Y6 |
Note 1: For example, a note could specify that at least one of the transactions shall be supported by an actor or other variations. For example: Note: Either Transaction Y3 or Transaction Y4 shall be implemented for Actor E.
Note 2: For example, could specify that Transaction Y4 is required if Actor B supports XYZ Option, see Section XX.3.X.
The actors in this profile are described in more detail in the sections below.
The Client queries for blah meeting certain criteria and may retrieve selected blah.
FHIR Capability Statement for Client
The Sever processes query request from the Client actor.
FHIR Capability Statement for Server
The transactions in this profile are summarized in the sections below.
This transaction is used to do things
For more details see the detailed transaction description
Options that may be selected for each actor in this implementation guide, are listed in Table 3.2-1 below. Dependencies between options when applicable are specified in notes.
Table XX.1-1: Actor Options
| Actor | Option Name |
| Actor A | Option AB |
| Actor B | none |
**TODO: describe this option and the Volume 1 requirements for this option
Describe any requirements for actors in this profile to be grouped with other actors.
This section specifies all REQUIRED Actor Groupings (although “required” sometimes allows for a selection of one of several). To SUGGEST other profile groupings or helpful references for other profiles to consider, use Section XX.6 Cross Profile Considerations. Use Section X.5 for security profile recommendations.
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) (Column 3 in alternative 2).
If this is a content profile, and actors from this profile are grouped with actors from a workflow or transport profile, the Reference column references any specifications for mapping data from the content module into data elements from the workflow or transport transactions.
In some cases, required groupings are defined as at least one of an enumerated set of possible actors; this is designated by merging column one into a single cell spanning multiple potential grouped actors. Notes are used to highlight this situation.
Section XX.5 describes some optional groupings that may be of interest for security considerations and Section XX.6 describes some optional groupings in other related profiles.
Two alternatives for Table XX.3-1 are presented below.
alternative 1 Table XX.3-1: Profile Name - Required Actor Groupings
All actors from this profile should be listed in Column 1, even if none of the actors has a required groupings. If no required grouping exists, “None” should be indicated in Column 2. If an actor in a content profile is required to be grouped with an actor in a transport or workflow profile, it will be listed with at least one required grouping. Do not use “XD*” as an actor name.
In some cases, required groupings are defined as at least one of an enumerated set of possible actors; to designate this, create a row for each potential actor grouping and merge column one to form a single cell containing the profile actor which should be grouped with at least one of the actors in the spanned rows. In addition, a note should be included to explain the enumerated set. See example below showing Document Consumer needing to be grouped with at least one of XDS.b Document Consumer, XDR Document Recipient or XDM Portable Media Importer
The author should pay special consideration to security profiles in this grouping section. Consideration should be given to Consistent Time (CT) Client, ATNA Secure Node or Secure Application, as well as other profiles. For the sake of clarity and completeness, even if this table begins to become long, a line should be added for each actor for each of the required grouping for security. Also see the ITI document titled ‘Cookbook: Preparing the IHE Profile Security Section’ at http://ihe.net/Technical_Frameworks/#IT for a list of suggested IT and security groupings.
Table XX.3-1: Actor Groupings
| this Profile Acronym Actor | Actor(s) to be grouped with | Reference | Content Bindings Reference |
|---|---|---|---|
| Actor A | external Domain Acronym or blank profile acronym/Actor e.g., ITI CT / Time Client |
TF Reference; typically from Vol 1 e.g., ITI-TF-1: 7.1 |
-- |
| Actor B | None | -- | -- |
Actor C In this example, Actor C shall be grouped with all three actors listed in column 2 |
external Domain Acronym or blank profile acronym/Actor |
-- | See Note 1 |
| external Domain Acronym or blank profile acronym/Actor | -- | See Note 1 | |
external Domain Acronym or blank profile acronym/Actor |
-- | See Note 1 | |
Actor D (See note 1) In this example, the note is used to indicate that the Actor D shall be grouped with one or more of the two actors of the two actors in column 2. |
external Domain Acronym or blank profile acronym/Actor |
-- | See Note 1 |
external Domain Acronym or blank profile acronym/Actor |
-- | See Note 1 | |
Actor E In rare cases, the actor to be grouped with must implement an option. An example is in column 2.) |
external Domain Acronym or blank profile acronym Actor e.g., ITI RFD Form Filler with the Archive Form Option |
TF Reference to the Option definition; typically from Vol 1 (e.g., ITI TF-1: 17.3.11) |
|
| e.g., Content Consumer (See Note 1) | ITI XDS.b / Document Consumer | ITI TF-1: 10.1 | PCC TF-2:4.1 (See Note 2) |
| ITI XDR / Document Recipient | ITI TF-1: 15.1 | PCC TF-2:4.1 (See Note 2) | |
| ITI XDM / Portable Media Importer | ITI TF-1: 16.1 | PCC TF-2:4.1 (See Note 2) | |
| e.g., Content Consumer | ITI CT / Time Client | ITI TF-1: 7.1 | -- |
Note 1: This is a short note. It may be used to describe situations where an actor from this profile may be grouped with one of several other profiles/actors.
Note 2: A note could also be used to explain why the grouping is required, if that is still not clear from the text above.
alternative 2 Table XX.3-1: this Profile Acronym Profile
All actors from this profile should be listed in Column 1. If no required grouping exists, “None” should be indicated in Column 3.
Guidance on using the “Grouping Condition” column:
Table XX.3-1: Actor Groupings
| this Profile Acronym Actor | Grouping Condition | Actor(s) to be grouped with | Reference |
| Actor A | -- | None | -- |
| Actor B | Required | external Domain Acronym or blank profile acronym/Actor e.g., ITI CT / Time Client |
TF Reference; typically from Vol 1 (e.g., ITI TF-1: 7.1) |
| Actor C | With the Option name in this profile Option | external Domain Acronym or blank profile acronym/Actor | Where the Option is defined in this profile Section XX.3 z |
Actor D if an actor has both required and conditional groupings, list the Required grouping first |
Required | external Domain Acronym or blank profile acronym/Actor | TF Reference; typically from Vol 1 |
| If the Option name in this profile Option is supported. | external Domain Acronym or blank profile acronym/Actor | TF Reference; typically from Vol 1 | |
| If the other Option name in this profile Option is supported. | external Domain Acronym or blank profile acronym/Actor | TF Reference; typically from Vol 1 | |
Actor E (In rare cases, the actor to be grouped with must implement an option, an example is in column 3) |
Required | external Domain Acronym or blank profile acronym/Actor with the option name e.g. ITI RFD Form Filler with the Archive Form Option |
TF Reference to the Option definition; typically from Vol 1 (eg ITI TF-1:17.3.11) |
This section shows how the transactions/content modules of the profile are combined to address the use cases.
Use cases are informative, not normative, and “SHALL” language is not allowed in use cases.
If needed, this section provides an overview of the concepts that provide necessary background for understanding the profile. If not needed, state “Not applicable.” For an example of why/how this section may be needed, please see ITI Cross Enterprise Workflow (XDW).
It may be useful in this section but is not necessary, to provide a short list of the use cases described below and explain why they are different.
Actors and transactions are used to achieve this use-case…
Figure X.X.X.X-X: Use Case 1 Process Flow
This section defines the actors and transactions in this implementation guide.
One or two sentence simple description of this particular use case.
Note that Section XX.4.2.1 repeats in its entirety for additional use cases (replicate as Section XX.4.2.2, XX.4.2.3, etc.).
Describe the key use cases addressed by the profile. Limit to a maximum of one page of text or consider an appendix.
Diagram and describe the process flow(s) covered by this profile in order to satisfy the use cases. Demonstrate how the profile transactions are combined/sequenced. To provide context and demonstrate how the profile interacts with other profiles, feel free to include transactions and events that are “external” to this profile (using appropriate notation.)
The set of process flows will typically be exemplary, not exhaustive (i.e., it will address all the use cases, but will not show all possible combinations of actors, or all possible sequencing of transactions).
If there are detailed behavioral rules that apply to a specific process flow or multiple process flows, an appendix may be added as needed.
The roles at the top of the swimlane diagram should correspond to actor names, include the profile acronym:actor name if referencing an actor from a different profile.
Modify the following “Swimlane Diagram”.
If process flow “swimlane” diagrams require additional explanation to clarify conditional flows, or flow variations need to be described where alternate systems may be playing different actor roles, document those conditional flows here.
Delete the material below if this is a workflow or transport profile. Delete the material above if this profile is a content module only profile.
Pre-conditions:
Very briefly (typically one sentence) describe the conditions or timing when this content module would be used.
Main Flow:
Typically in an enumerated list, describe the clinical workflow when, where, and how this content module would be used.
Post-conditions:
Very briefly (typically one sentence) describe the state of the clinical scenario after this content module has been created including examples of potential next steps.
See ITI TF-2x: Appendix Z.8 “Mobile Security Considerations”
The following is instructions to the editor and this text is not to be included in a publication. The material initially from RFC 3552 “Security Considerations Guidelines” July 2003.
This section should address downstream design considerations, specifically for: Privacy, Security, and Safety. These might need to be individual header sections if they are significant or need to be referenced.
The editor needs to understand Security and Privacy fundamentals. General Security and Privacy guidance is provided in the FHIR Specification. The FHIR core specification should be leveraged where possible to inform the reader of your specification.
IHE FHIR based profiles should reference the ITI Appendix Z section 8 Mobile Security and Privacy Considerations base when appropriate.
IHE Document Content profiles can reference the security and privacy provided by the Document Sharing infrastructure as directly grouped or possibly to be grouped.
While it is not a requirement that any given specification or system be immune to all forms of attack, it is still necessary for authors of specifications to consider as many forms as possible. Part of the purpose of the Security and Privacy Considerations section is to explain what attacks have been considered and what countermeasures can be applied to defend against them.
There should be a clear description of the kinds of threats on the described specification. This should be approached as an effort to perform “due diligence” in describing all known or foreseeable risks and threats to potential implementers and users.
Authors MUST describe:
what could be done in system design, system deployment, or user training
At least the following forms of attack MUST be considered: eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle. Potential denial of service attacks MUST be identified as well. If the specification incorporates cryptographic protection mechanisms, it should be clearly indicated which portions of the data are protected and what the protections are (i.e., integrity only, confidentiality, and/or endpoint authentication, etc.). Some indication should also be given to what sorts of attacks the cryptographic protection is susceptible. Data which should be held secret (keying material, random seeds, etc.) should be clearly labeled.
If the specification involves authentication, particularly user-host authentication, the security of the authentication method MUST be clearly specified. That is, authors MUST document the assumptions that the security of this authentication method is predicated upon.
The threat environment addressed by the Security and Privacy Considerations section MUST at a minimum include deployment across the global Internet across multiple administrative boundaries without assuming that firewalls are in place, even if only to provide justification for why such consideration is out of scope for the protocol. It is not acceptable to only discuss threats applicable to LANs and ignore the broader threat environment. In some cases, there might be an Applicability Statement discouraging use of a technology or protocol in a particular environment. Nonetheless, the security issues of broader deployment should be discussed in the document.
There should be a clear description of the residual risk to the user or operator of that specification after threat mitigation has been deployed. Such risks might arise from compromise in a related specification (e.g., IPsec is useless if key management has been compromised), from incorrect implementation, compromise of the security technology used for risk reduction (e.g., a cipher with a 40-bit key), or there might be risks that are not addressed by the specification (e.g., denial of service attacks on an underlying link protocol). Particular care should be taken in situations where the compromise of a single system would compromise an entire protocol. For instance, in general specification designers assume that end-systems are inviolate and don’t worry about physical attack. However, in cases (such as a certificate authority) where compromise of a single system could lead to widespread compromises, it is appropriate to consider systems and physical security as well.
There should also be some discussion of potential security risks arising from potential misapplications of the specification or technology described in the specification.
This section also include specific considerations regarding Digital Signatures, Provenance, Audit Logging, and De-Identification.
Where audit logging is specified, a StructureDefinition profile(s) should be included, and Examples of those logs might be included.
This section is informative, not normative. It is intended to put this profile in context with other profiles. Any required groupings should have already been described above. Brief descriptions can go directly into this section; lengthy descriptions should go into an appendix. Examples of this material include ITI Cross Community Access (XCA) Grouping Rules (Section 18.2.3), the Radiology associated profiles listed at wiki.ihe.net, or ITI Volume 1 Appendix E “Cross Profile Considerations”, and the “See Also” sections Radiology Profile descriptions on the wiki such as http://wiki.ihe.net/index.php/Scheduled_Workflow#See_Also. If this section is left blank, add “Not applicable.”
Consider using a format such as the following:
other profile acronym - other profile name
A other profile actor name in other profile name might be grouped with a this profile actor name to describe benefit/what is accomplished by grouping.
IG © 2024+ IHE Patient Care Coordination Technical Committee. Package ihe.pcc.rsq#0.0.1-current based on FHIR 4.0.1. Generated 2024-05-10
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change