Brontekst bekijken van mp:Vissue-MP-2279 MedicationProcess9 FHIR

= Boundaries and relationships =
== Building blocks and profiles ==

The exchange of data within the MP9 standard version {{VersieInfo|mp9|release=V3.0.0}} is largely based on the 2020 publication of the Dutch Health and Care Information Models (Dutch: ‘zorginformatiebouwstenen’ or ‘zibs’). The objects that are present in the functional data set of the MP9 standard (and which are actually exchanged) are referred to as ‘medication building blocks’.

The medication building blocks in the functional data set have deviated from the corresponding zibs they were originally based on, making them incompatible in varying degrees from a technical point of view. Therefore it was not possible to implement the FHIR profiles for these medication building blocks by building on and extending [[FHIR:V1.0_FHIR_IG_R4#Functional_definitions|the nl-core profiles]] based on zib publication 2020. Hence the profiles for these building blocks have been created ‘independently’ from these profiles, meaning that the MP9 profiles have no dependency on the zib2020-package.

Because the way 90 million numbers are exchanged is not compatible with the 2020 publication of zib PharmaceuticalProduct, a fork of the corresponding nl-core profile called 'mp-PharmaceuticalProduct' has been introduced.

{{NoteBoxNictizR4Package|p1=nictiz.fhir.nl.r4.medicationprocess9|v1={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}|p2=nictiz.fhir.nl.r4.nl-core|v2={{VersieInfo|nictiz.fhir.nl.r4.nl-core|release=V3.0.0}}}}

Note that the package versioning does not follow the versioning of the information standard, as MP9 version 2.0.0 was the first release of the MP9 information standard based on FHIR R4 (and largely based on zib publication 2020). This means that:
* MP9 version 2.0.0 makes use of version 1.0.0 of the nictiz.fhir.nl.r4.medicationprocess9 FHIR package;
* MP9 version {{VersieInfo|mp9|release=V3.0.0}} makes use of version {{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}} of the nictiz.fhir.nl.r4.medicationprocess9 FHIR package.

=== Medication building blocks ===

As described above, the main medication building blocks have no dependency on any zib2020 counterparts, resulting in so-called ‘mp’ profiles. Moreover, note that the building block VariableDosingRegimen does not have a zib counterpart, hence it makes sense to include it as an mp profile as well.

{| class="wikitable"
|-
! style="font-weight: bold;text-align:left;" | Building block (EN)
! style="font-weight: bold;text-align:left;" | Building block (NL)
! style="font-weight: bold;text-align:left;" | FHIR resource
! style="font-weight: bold;text-align:left;" | FHIR profile
|-
| MedicationAgreement
| Medicatieafspraak
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| VariableDosingRegimen
| WisselendDoseerschema
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-VariableDosingRegimen|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| DispenseRequest
| Verstrekkingsverzoek
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| AdministrationAgreement
| Toedieningsafspraak
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| MedicationDispense
| Medicatieverstrekking
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationDispense|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| MedicationUse2
| Medicatiegebruik2
| MedicationStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| MedicationAdministration2
| Medicatietoediening2
| MedicationAdministration
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAdministration2|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|}

For the MedicationAdministration2 building block, only administrations that have actually been performed are in scope.
Therefore, all MedicationAdministration instances used in MP9 SHALL have status = "completed". Other FHIR MedicationAdministration statuses are out of scope for this information standard.

=== Supporting building blocks ===

Additionally, the standard uses several supporting building blocks referenced from the main medication building blocks. All supporting building blocks are part of the [[FHIR:V1.0_FHIR_IG_R4#Functional_definitions|‘nl-core’ package]]<ref>Although the nl-core package is still in beta-status, HL7 Netherlands has validated the profiles mentioned and assigned the status 'STU-NL' for use in the MP9 Kickstart, see [[Media:HL7_Nederland_disclaimer_STU-NL.pdf]]</ref>.

{| class="wikitable"
|-
! style="font-weight: bold;text-align:left;" | Building block (EN)
! style="font-weight: bold;text-align:left;" | Building block (NL)
! style="font-weight: bold;text-align:left;" | FHIR resource
! style="font-weight: bold;text-align:left;" | FHIR profile
|-
| Patient
| Patient
| Patient
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.nl-core|release=V3.0.0}}}}
|-
| PharmaceuticalProduct
| FarmaceutischProduct
| Medication
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-PharmaceuticalProduct|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| Contact
| Contactpersoon
| RelatedPerson
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-ContactPerson|nictiz.fhir.nl.r4.nl-core|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.nl-core|release=V3.0.0}}}}
|-
| rowspan="2" | HealthProfessional
| rowspan="2" | Zorgverlener
| PractitionerRole
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.nl-core|release=V3.0.0}}}}
|-
| Practitioner
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.nl-core|release=V3.0.0}}}}
|-
| rowspan="2" | HealthcareProvider
| rowspan="2" | Zorgaanbieder
| Location
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.nl-core|release=V3.0.0}}}}
|-
| Organization
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.nl-core|release=V3.0.0}}}}
|-
| BodyHeight
| Lichaamslengte
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight|nictiz.fhir.nl.r4.nl-core|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.nl-core|release=V3.0.0}}}}
|-
| BodyWeight
| Lichaamsgewicht
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight|nictiz.fhir.nl.r4.nl-core|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.nl-core|release=V3.0.0}}}}
|}

Note the following:
* Each occurrence of the zib HealthProfessional is normally represented by '''two''' FHIR resources: an instance of nl-core-HealthProfessional-PractitionerRole and an instance of nl-core-HealthProfessional-Practitioner. Sending systems should only fill the reference to the PractitionerRole instance where relevant. Receiving systems can resolve the reference to the Practitioner resource from that PractitionerRole instance.
* The zib HealthcareProvider is mapped to both a Location and Organization profile. Most often, the Location profile acts as the focal resource, because most references to this zib are concerned about the recording of the physical location where the care to patient/client takes place rather than the organizational information. For the latter, the profile on Organization is used which is referenced using the {{fhir|Location.managingOrganization}} element. Sending systems should only fill the reference to the Location instance where relevant. Incidentally, concepts that are only concerned with organizational information can refer to the Organization instance.

=== Transaction specific profiles ===

For several transactions, additional profiles are provided. For each transaction the profile relevant is explicitly mentioned in the corresponding subsection.

{| class="wikitable"
|-
! style="font-weight: bold;text-align:left;" | Transaction profile (EN)
! style="font-weight: bold;text-align:left;" | Transaction profile (NL)
! style="font-weight: bold;text-align:left;" | FHIR resource
! style="font-weight: bold;text-align:left;" | FHIR profile
|-
| MedicationPrescription
| Voorschrift
| Bundle
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationPrescription-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| MedicationPrescriptionProcessing
| VoorschriftAfhandeling
| Bundle
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationPrescriptionProcessing-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| ProposalDispenseRequest
| VoorstelVerstrekkingsverzoek
| Bundle
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ProposalDispenseRequest-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| rowspan="2" | ReplyProposalDispenseRequest
| rowspan="2" | AntwoordVoorstelVerstrekkingsverzoek
| Bundle
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalDispenseRequest-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| Communication
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalDispenseRequest|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| ProposalMedicationAgreement
| VoorstelMedicatieafspraak
| Bundle
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ProposalMedicationAgreement-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| rowspan="2" | ReplyProposalMedicationAgreement
| rowspan="2" | AntwoordVoorstelMedicatieafspraak
| Bundle
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalMedicationAgreement-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|-
| Communication
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalMedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}}}
|}

====Bundle profiles====
The profiles on Bundle serve as guidance both on what is needed to differentiate between transactions (for example setting {{fhir|.meta.tag}} or a specific value of {{fhir|.intent}}, see also [[#Differentiating_between_transactions|Differentiating between transactions]]) and on which building blocks can be expected to be included in a Bundle within a transaction.

All building blocks defined in the functional specification of a transaction have been added as slices on {{fhir|.entry}}. This is not a limited list, a sending system has the option to include more referenced resources if needed. Note that where the functional specification of a transaction specifies a minimum cardinality of 1 for a building block, the minimum cardinality in a Bundle profile has been set to 0. Because there are different ways in FHIR to reference to building blocks, senders are not required to include it in the Bundle. The different ways to reference building blocks in MP9 can be found in the last paragraph of [[#Mappings_between_profiles_and_data_set|section 2.2]].

Where the functional specification of a transaction expects a HealthProfessional building block, both [[#Supporting_building_blocks|the profiles on resource types PractitionerRole and Practitioner]] have been included in the Bundle profile. The same goes for the HealthcareProvider building block with its profiles on Location and Organization.

== Mappings between profiles and data set ==
Each transaction described in the [[#Transactions|section Transactions]] starts with a table containing links to its functional definition in the ART-DECOR publication and ends with a list of the FHIR profiles that need to be supported when implementing that particular transaction. The FHIR profiles of the medication building blocks contain mappings to the elements in the transaction and are prefixed with 'mp-dataelement9x'. For FHIR elements with no mapping to the functional definition, additional guidance is provided. As for the FHIR profiles of the supporting building blocks, these contain mappings to zib elements. Sections [[#Medication_building_blocks|2.1.1]] and [[#Supporting_building_blocks|2.1.2]] provide an overview of the medication and supporting building blocks.
 
In the functional definition in ART-DECOR, the cardinality and conformance of the relevant elements are specified and can be stricter than the cardinality of the elements in the FHIR profiles because of [[FHIR:V1.0_FHIR_Profiling_Guidelines_R4#Open_vs._closed_world_modeling|open world modelling]]. The general rule is that the  cardinality of the functional definition is leading when it comes to exchanging building blocks in the context of the specific transaction. For example: in the mp-MedicationAgreement profile, {{fhir|.requester}} has a cardinality of 0..1, while in the ‘Serve Medication data’ ART-DECOR transaction, the Prescriber element has a cardinality of 1..1 R. Therefore, {{fhir|.requester}} is expected to be populated with either a Reference to an nl-core-HealthProfessional-PractitionerRole resource or a [http://hl7.org/fhir/R4/extension-data-absent-reason.html DataAbsentReason extension], see the [[FHIR:V1.0_FHIR_IG_R4#Missing_information|general FHIR IG on ‘Missing information’]].

 
Each transaction contains a Patient building block with cardinality 1..1 M. This patient is the subject of all other building blocks in the transaction, although no explicit relation exists in the data set. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in {{fhir|.subject}} of each FHIR instance of each building block.
 
Relations between different building blocks exist in transactions by means of concepts with a name starting with ‘Relation…’ (Dutch: ‘Relatie…’) and an underlying concept 'Identification' of data type Identification, for example RelationAdministrationAgreement (mp-dataelement9x-1328) in building block MedicationAgreement. These relations are mapped to the FHIR data type ‘Reference’. Implementers SHOULD use literal references (using {{fhir|.reference}}) instead of logical references (using {{fhir|.identifier}}) when it's possible to resolve the reference, see the [[FHIR:V1.0_FHIR_IG_R4#Use_of_the_reference_data_type|general FHIR IG on the Reference data type]].
However, when HL7v3 systems are involved, it is advised to use one of the following types of references to accommodate compatibility in transformations to and from FHIR:
* Only a logical reference {{fhir|.identifier}},
* Both a logical {{fhir|.identifier}} and literal reference {{fhir|.reference}}
* Only a literal reference {{fhir|.reference}} when the resource which is being referred is included in the bundle.

== Pharmaceutical treatment ==
The MP9 transaction data sets reference a container ‘Pharmaceutical treatment’ (Dutch: ‘Medicamenteuze behandeling’), which contains all medication building blocks relevant to the transaction. For the specification of the Pharmaceutical treatment, see [[mp:Vprepub-3.0.0_Ontwerp_medicatieproces_9_ENG#The_concept_of_.E2.80.98pharmaceutical_treatment.E2.80.99|the functional specification]]. In FHIR, the Pharmaceutical treatment does not have an explicit resource representation. Instead, each medication building block contains the PharmaceuticalTreatmentIdentifier extension which contains the ‘Pharmaceutical Treatment Identifier’. This Identifier shall be the same across different related medication resources that constitute one Pharmaceutical treatment. As mentioned in [[#Resource_identification|‘Resource identification’]] the system of the identifer SHALL be an OID to accommodate compatibility in transformations to and from FHIR. The custom search parameter {{fhir|pharmaceutical-treatment-identifier}}, see [[#Search_parameters|‘Search parameters’]], is used within the ‘Medication data’ transaction to query a server for all building blocks within a specific Pharmaceutical treatment.

== Patient identification ==
This implementation guide assumes that the client system is able to make a connection to the right server that contains the patient's information. It does not provide information on finding the right server nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification. 

Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a [https://www.hl7.org/fhir/r4/search.html#chaining chained search parameter] for all resource types except Patient, so only the records associated with the authenticated patient are returned.

When patient identification requires the use of search parameters, the following search parameters SHALL be supported:
* Patient: {{fhir|identifier}}
* MedicationRequest: {{fhir|patient.identifier}} and {{fhir|subject:Patient.identifier}}
* MedicationDispense: {{fhir|patient.identifier}} and {{fhir|subject:Patient.identifier}}
* MedicationStatement: {{fhir|patient.identifier}} and {{fhir|subject:Patient.identifier}}
* MedicationAdministration: {{fhir|patient.identifier}} and {{fhir|subject:Patient.identifier}}

An example of a request that retrieves all MedicationRequest resources of a patient with a fake BSN of 11122233:

<pre>GET [base]/MedicationRequest?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333</pre>

Note: All request examples in this document do not include patient identification mechanisms, partly because we want to generalize this technical design as much as possible (it being applicable to both MedMij and other contexts), and partly because this would convolute all search request examples. Requesters are assumed to include these if necessary. Since there currently are only transactions in the context of a single patient, the patient identification mechanism is actually implicitly assumed to be present in all search requests.

== Resource identification ==
All profiles used within the MP9 information standard contain {{fhir|.identifier}} elements with a cardinality of 0..* because of open world modelling. However, all ART-DECOR transactions referenced within this IG assign a 1..1 R cardinality, meaning a stable identifier SHOULD be provided, or [[FHIR:V1.0_FHIR_IG_R4#Missing_information|the DataAbsentReason extension if a value is missing]]. Identifiers SHALL contain both a {{fhir|.system}} and a {{fhir|.value}}.

Because in HL7v3 (CDA) an identifier can only be composed using OIDs, the {{fhir|.system}} SHALL be an OID to accommodate compatibility in transformations to and from FHIR. The [https://hl7.nl/component/zoo/item/publicatie-van-de-hl7v3-cda-implementatiehandleiding-basiscomponenten-versie-2-3.html?highlight=WyJkYXRhdHlwZSIsImlpIl0= Netherlands HL7v3 datatype II] also defines additional restrictions on the maximum length of both <code>@root</code> and <code>@extension</code> (equivalent to respectively {{fhir|.system}} and {{fhir|.value}} in FHIR). For the same compatibility reasons, {{fhir|.system}} SHALL have a maximum of 128 characters and {{fhir|.value}} SHALL have a maximum of 64 characters.

Systems that encounter or resolve references, either logical or literal, in resources they receive, SHALL NOT rewrite these references to a copy of these resources (with {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/ext-CopyIndicator|nictiz.fhir.nl.r4.nl-core|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.nl-core|release=V3.0.0}}}} present) they may store. This means that [https://hl7.org/fhir/r4/references.html relative literal references] may need to be rewritten to absolute ones. This also goes for [[FHIR:V1.0_FHIR_IG_R4#Including_.22secondary.22_resources_when_sending_information|included secondary resources in transactions]].

== Differentiating between transactions ==
All transactions described in this IG use the same medication building blocks in different combinations and settings, making it necessary to differentiate between them. Several mechanisms are used to achieve this. Aside from PUSH/PULL, the type of medication building blocks, supporting resources like List and Communication for specific transactions and fixing the value of specific FHIR elements in applicable profiles, the {{term|actionable}} tag is used. The latter is described more in depth in the following section. Next to that, a summarizing table is provided.

Note that {{fhir|Resource.meta.profile}}, although present in each building block (see [[FHIR:V1.0_FHIR_IG_R4#Profile_use_and_declaration|the general FHIR IG on ‘Profile use and declaration’]]), SHOULD [https://hl7.org/fhir/r4/resource.html#profile-tags not be used for identification of the building block type] and therefore for differentiating between transactions.

=== Actionable tag ===
To differentiate between sending or serving building blocks that are either of informative nature or of actionable nature, the {{term|actionable}} tag is used. [https://hl7.org/fhir/r4/resource.html#tag Tags] are {{datatype|Coding}} elements present in {{fhir|Resource.meta.tag}} used for workflow management.

If applicable, the profiles used by a transaction require the use of {{fhir|.meta.tag}} with {{fhir|.system}} = {{term|<nowiki>http://terminology.hl7.org/CodeSystem/common-tags</nowiki>}} and {{fhir|.code}} = {{term|actionable}} to indicate that the resource is part of a request intended to be acted upon. The absence of this tag indicates that the resource is merely of informative nature.

It is up to systems to determine how and when the transactions using the {{term|actionable}} tag are handled from a functional perspective. Systems may store the resource including the {{term|actionable}} tag or remove it either upon storing or when the request is acted upon. However, systems SHALL make sure the tag is removed when serving or sending the resource as part of an informative transaction.

=== Summarizing table ===
{| class="wikitable" 
|-
! style="font-weight: bold;text-align:left;" | Transaction
! style="font-weight: bold;text-align:left;" | PUSH/PULL
! style="font-weight: bold;text-align:left;" | Building blocks
! style="font-weight: bold;text-align:left;" | {{term|actionable}} tag
! style="font-weight: bold;text-align:left;" | FHIR element value
! style="font-weight: bold;text-align:left;" | Other
|-
| Medication data (Retrieve/Serve)
| PULL
| One or more of all building blocks
| No
|
| 
|-
| Medication data (Send/Receive)
| PUSH
| One or more of all building blocks
| No
|
|
|-
| Medication prescription (Send/Receive)
| PUSH
| MedicationAgreement, DispenseRequest (optional)
| Yes
| {{fhir|MedicationRequest.intent}} = {{term|order}} (for both MedicationAgreement and DispenseRequest building blocks)
| 
|-
| Medication prescription processing (Send/Receive)
| PUSH
| AdministrationAgreement, MedicationDispense (optional)
| Yes
| 
| 
|-
| Proposal dispense request (Send/Receive)
| PUSH
| DispenseRequest
| Yes
| {{fhir|MedicationRequest.intent}} = {{term|plan}}
| 
|-
| Reply proposal dispense request (Send/Receive)
| PUSH
| 
| Yes
| 
| Communication resource with reference to DispenseRequest
|-
| Proposal medication agreement (Send/Receive)
| PUSH
| MedicationAgreement
| Yes
| {{fhir|MedicationRequest.intent}} = {{term|plan}}
| 
|-
| Reply proposal medication agreement (Send/Receive)
| PUSH
| 
| Yes
| 
| Communication resource with reference to MedicationAgreement
|}