Medication Prescription and Delivery (MPD)
0.1.0 - ci-build
Medication Prescription and Delivery (MPD)
0.1.0 - ci-build
Medication Prescription and Delivery (MPD), published by Integrating the Healthcare Enterprise (IHE). This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/pharm-mpd/ and changes regularly. See the Directory of published versions
The MPD profile is a Workflow and Content profile. It describes the data exchange between systems for electronic prescriptions and dispenses.
IHE MPD is a Gemini project. This means that the specifications are hosted by IHE …..
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.
For use Cases please go here.
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 © 2021+ Integrating the Healthcare Enterprise (IHE). Package ihe.pharm.mpd#0.1.0 based on FHIR 5.0.0. Generated 2024-10-26
Links: Table of Contents |
QA Report
Version History |
|
Propose a change