spelled out name of the IHE Profile, published by IHE IT Infrastructure 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/supplement-template/ 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. **
Actors and transactions are used to achieve this use-case…
Table XX.1-1: Profile Acronym Profile - Actors and Transactions
| Actors | Transactions | Initiator or Responder | Optionality | Reference | |---------|---------------|------------------------|-----------------|--------------------------------------------| | Actor A | Transaction 1 | | R | [Domain Acronym TF-2: 3.Y1](./domain-Y1.html) | | | Transaction 2 | | R | [Domain Acronym TF-2: 3.Y2](./domain-Y2.html) | | Actor F | Transaction 1 | | R | [Domain Acronym TF-2: 3.Y1](./domain-Y1.html) | | | Transaction 2 | | R | [Domain Acronym TF-2: 3.Y2](./domain-Y2.html) | | Actor D | Transaction 1 | | R | [Domain Acronym TF-2: 3.Y1](./domain-Y1.html) | | Actor E | Transaction 2 | | R | [Domain Acronym TF-2: 3.Y2](./domain-Y2.html) | | | Transaction 3 | | O ( See Note 1) | [Domain Acronym TF-2: 3.Y3](./domain-Y3.html) | | | Transaction 4 | | O ( See Note 1) | [Domain Acronym TF-2: 3.Y4](./domain-Y4.html) | | Actor B | Transaction 3 | | R | [Domain Acronym TF-2: 3.Y3](./domain-Y3.html) | | | Transaction 4 | | O ( See Note 2) | [Domain Acronym TF-2: 3.Y4](./domain-Y4.html) | {: .grid} 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.* ### XX.1.1 Actors The actors in this profile are described in more detail in the sections below. #### XX.1.1.1 Client The Client queries for blah meeting certain criteria and may retrieve selected blah. FHIR Capability Statement for [Client](CapabilityStatement-IHE.ToDo.client.html) #### XX.1.1.2 Server The Sever processes query request from the Client actor. FHIR Capability Statement for [Server](CapabilityStatement-IHE.ToDo.server.html) ### XX.1.2 Transaction Descriptions The transactions in this profile are summarized in the sections below. #### XX.1.2.1 ToDo do transaction This transaction is used to **do things** For more details see the detailed [transaction description](domain-YY.html) ## XX.2 ToDo Actor Options Options that may be selected for each actor in this implementation guide, are listed in Table XX.2-1 below. Dependencies between options when applicable are specified in notes.Table XX.2-1: Actor Options</p>
| Actor | Option Name |
|---------|-------------|
| Actor A | Option AB |
| Actor B | none |
{: .grid}
### XX.2.1 AB Option
**TODO: describe this option and the Volume 1 requirements for this option
## XX.3 ToDo Required Actor Groupings
*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.
* If there are no required groupings for any actor in this profile,
use alternative 1 as a template.
* If an actor in this profile (with no option), has a required
grouping, use alternative 1.
* If any required grouping is associated with an actor/option
combination in this profile, use alternative 2.
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 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 In this example, Actor C shall be grouped with all three actors listed in column 2 external Domain Acronym or blank profile acronym/Actor external Domain Acronym or blank profile acronym/Actor 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 external Domain Acronym or blank profile acronym/Actor 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) Table XX.3-1: Actor Groupings 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 D if an actor has both required and conditional groupings, list the Required grouping first Actor E (In rare cases, the actor to be grouped with must implement an option, an example is in column 3) 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)
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
* Required Actor Groupings
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:
* If an actor has no required grouping, Column 2 should contain "--".
See Actor A below.
* If an actor has a required grouping that is not associated with a
profile option (i.e., it has no condition), column 2 should contain
"Required". See Actor B below.
* Sometimes an option requires that an actor in this profile be
grouped with an actor in another profile. That condition is
specified in Column 2. See Actor C below.
this Profile Acronym Actor
Actor(s) to be grouped with
Reference
Content Bindings Reference
Actor A
--
Actor B
None
--
--
--
See Note 1
external Domain Acronym or blank profile acronym/Actor
--
See Note 1
--
See Note 1
--
See Note 1
--
See Note 1
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
--
## XX.4 ToDo Overview
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.
### XX.4.1 Concepts
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.
### XX.4.2 Use Cases
#### XX.4.2.1 Use Case \#1: simple name
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.).
##### XX.4.2.1.1 simple name Use Case Description
Describe the key use cases addressed by the profile. Limit to a
maximum of one page of text or consider an appendix.
##### XX.4.2.1.2 simple name Process Flow
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".
this Profile Acronym Actor
Grouping Condition
Actor(s) to be grouped with
Reference
Actor A
--
None
--
Actor B
Required
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
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
Required
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.
## XX.5 ToDo Security Considerations
See ITI TF-2x: [Appendix Z.8 "Mobile Security Considerations"](https://profiles.ihe.net/ITI/TF/Volume2/ch-Z.html#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](https://tools.ietf.org/html/rfc3552).
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](http://hl7.org/fhir/R4/secpriv-module.html) 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](https://profiles.ihe.net/ITI/TF/Volume2/ch-Z.html) 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:
* which attacks have been considered and addressed in the specification
* which attacks have been considered but not addressed in the specification
* 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.
## XX.6 ToDo Cross-Profile Considerations
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 © 2021+ IHE IT Infrastructure Technical Committee. Package ihe.domain.profile#0.0.1-current based on FHIR 4.0.1. Generated 2024-11-01
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change
