1. Allergies/Intolerances: 1.1 Allergy Type: Message element: intoleranceCondition.value Comment in spec is “Critical for identifying the allergy or intolerance. However, because the attribute is not used for SNOMED, it is optional.” Since we do not support SNOMED, we are treating this element as mandatory.

1.2 Related Reaction Reaction-Code: Message element: intoleranceCondition.support.causalityAssessment.subject.observationEvent.value Comment in spec is: “Specifies the kind of reaction, as experienced by the patient. Ensures consistency in tracking and categorizing the reaction type. Helps ensure that only proper allergies are categorized as allergy. The attribute is optional because it will not be used for SNOMED. The attribute is CWE because not all possible types of reactions are expressible by coded values.” Since we do not support SNOMED, we are treating this element as mandatory. Further – we are only accepting ICD10CA codes for this value – we have tightened the conformance from CWE to CNE.

1.3 Related Reaction Reaction-Cause Exposure Material: Message element: intoleranceCondition.support.causalityAssessment.startsAfterStartOf.exposureEvent.cons umable.administrableMaterial.administerableMaterialKind.code Comment in spec is “Indicates the type of agent that the patient was exposed to which caused the adverse reaction. This includes Drug, Food, Latex, Dust, etc. Allows different kinds of reaction agents to be distinguished. Coding strength is set to CWE because the exposure agent type may not always be codified. The attribute is populated because there is little point in communicating about the exposure to an agent if it is not known what the agent is, however it may not always be coded. Also, the code may sometimes be masked, in which case a "null flavor" must be specified.” If this element is sent, up until now, we had only accepted FDB HIC in this field (tightened the conformance to CNE from CWW). We plan to further open this field up to allow DIN, GCN_SEQNO and FDB Allergen Group code (OID needs to be registered) to deal with the requirement of a particular implementing vendor.

1.4 Related Reaction Reaction-Cause Route Code: Message element: intoleranceCondition.support.causalityAssessment.startsAfterStartOf.routeCode Comment in spec is: “The method by which the patient was exposed to the substance. Element is declared as CNE and vocabulary is defined as RouteOfAdministration.” This is one area where we, in conjunction with another jurisdiction, have extended the vocabulary to include the FDB Route of Administration – OID is 2.16.840.1.113883.4.80 – and have constrained the standard to only accept this code set.

1.5 Allergy Test Result Message element: intoleranceCondition.support.allergyTestEvent.value Comment in spec is: “A code indicating result of the allergy test. Allows other providers to evaluate the test. There is no point in associating an allergy test with unknown results with an allergy or intolerance however the element is optional because this information may be post-coordinated in the 'code' attribute using SNOMED. Since we do not support SNOMED, we are treating this element as mandatory (in the event that an Allergy Test element is provided).

2. Adverse Reactions With Adverse Reactions, we have all the same constraints as we do with allergy related reaction elements.

2.1 Reaction Reaction-Code Message element: reactionObservationEvent.value Comment in spec is “Specifies the kind of reaction, as experienced by the patient. Ensures consistency in tracking and categorizing the reaction type. Helps ensure that only proper allergies are categorized as allergy. The attribute is optional because it will not be used for SNOMED. The attribute is CWE because not all possible types of reactions are expressible by coded values. Since we do not support SNOMED, we are treating this element as mandatory. Further – we are only accepting ICD10CA codes for this value – we have tightened the conformance from CWE to CNE.

2.2 Reaction Reaction-Cause Exposure Material: Message element: reactionObservationEvent.subjectOf3.causalityAssessment.startsAfterStartOf.exposureEv ent.consumable.administrableMaterial.administerableMaterialKind.code Comment in spec is “Indicates the type of agent that the patient was exposed to which caused the adverse reaction. This includes Drug, Food, Latex, Dust, etc. Allows different kinds of reaction agents to be distinguished. Coding strength is set to CWE because the exposure agent type may not always be codified. The attribute is populated because there is little point in communicating about the exposure to an agent if it is not known what the agent is, however it may not always be coded. Also, the code may sometimes be masked, in which case a "null flavor" must be specified.” If this element is sent, up until now, we had only accepted FDB HIC in this field (tightened the conformance to CNE from CWW). We plan to further open this field up to allow DIN, GCN_SEQNO and FDB Allergen Group code (OID needs to be registered) to deal with the requirement of a particular implementing vendor.

2.3 Reaction Reaction-Cause Route Code: Message element: reactionObservationEvent.subjectOf3.causalityAssessment.startsAfterStartOf.routeCode Comment in spec is: “The method by which the patient was exposed to the substance. Element is declared as CNE and vocabulary is defined as RouteOfAdministration.” This is one area where we, in conjunction with another jurisdiction, have extended the vocabulary to include the FDB Route of Administration – OID is 2.16.840.1.113883.4.80 – and have constrained the standard to accept only this standard. In fact, anywhere in the message standard where a routeCode is to be specified, we now require this code system.

3. Medical Conditions 3.1 Condition Type Message Element: medicalCondition.value Comment in spec is: “A code indicating the specific condition. E.g. Hypertension, Pregnancy. This is the central piece of information in recording a condition. However because when using SNOMED the actual diagnosis will be sent in the 'code' attribute, this element is optional.” Since we do not support SNOMED, we are treating this element as mandatory.

4. Prescriptions 4.1 Prescription Drug Specification: Message Element: combinedMedicationRequest.directTarget versus combinedMedicationRequest.code element. Comment in spec (on combinedMedicationRequest.code) is: “Indicates that this is a prescription for a drug as opposed to an immunization. For SNOMED, may also contain information regarding drug and route. If using SNOMED, the drug specification would be here and the optional directTarget element would not be provided. Since we are not using SNOMED, we treat the directTarget element as a mandatory field and expect “DRUG” to be specified in the combinedMedicationRequest.code code attribute.

4.2 Prescription Drug Type: Message element: combinedMedicationRequest.directTarget.medication.player.code Comment in spec: An identifier for a type of drug. Depending on where the drug is being referenced, the drug may be identified at different levels of abstraction. E.g. Manufactured drug (including vaccines), generic formulation, generic, therapeutic class, etc. Used to ensure clear communication by uniquely identifying a particular drug product when prescribing or dispensing. This attribute is only marked as 'populated' because some custom compounds will not have unique identifiers. Vocabulary is ClinicalDrug and strength is CNE. Although it is not recorded in the specification within the message documentation, PE had submitted an issue paper (Issue # 27 recorded in the Standards Development Tracking Logs Spreadsheet) requesting that the vocabulary for this be opened up too allow for proprietary code sets. This was approved with the requirement that at a future date (when mapping available thru FDB) that we provide the SNOMED CT translation as well. Therefore – FDB GCN_SEQNO and (FDB HIC for ingredients) are assumed to be part of the ClinicalDrug vocabulary from PEI’s perspective (whether this is clear from the spec or not). For prescriptions with the PEI implementation, the set of code sets allowed for specifying the drug in this element are: DIN (2.16.840.1.113883.5.1105) and GCN_SEQNO (2.16.840.1.113883.4.64) or left unspecified (i.e. nullFlavor provided), but only when a compound is being sent and the drug is identified by a name and optionally the specification of multiple ingredients. These constraints apply on the prescription anywhere the Medication CMET is used and a drug code is used to identify the drug product being prescribed.

4.2 Prescription Drug Form Code Message element: combinedMedicationRequest.directTarget.medication.player.formCode Comment from the spec: Indicates the form in which the drug product must be, or has been manufactured or custom prepared. Vocabulary is defined as CNE and specified as OrderableDrugForm. This is one area where we, in conjunction with another jurisdiction, have extended the vocabulary to include the FDB Dosage Form Code – OID is 2.16.840.1.113883.4.79 – and have constrained the standard to accept only this code set. In fact, anywhere in the message standard where a drug form code (not applicable to the containerPackagedMedication.formCode element where we are using the standard code system) is to be specified, we are using this code system.

4.3 Prescription Drug Ingredient Specification Message element: combinedMedicationRequest.directTarget.medication.player.code.ingredient.ingredient.c ode Comment from the spec: Allows un-ambiguous identification of the ingredients of a drug for performing various alert checking. If specifying an ingredient, we require the ingredient code. The code attribute is defined as CNE and vocabulary is spercified as ActiveIngredientDrugEntityType. As described for the prescription drug code specification, in issue paper #27, we requested that this vocabulary be opened up to allow for specification of proprietary code systems. We are requiring that this element use either DIN (2.16.840.1.113883.5.1105) or FDB HIC (2.16.840.1.113883.3.84). Everywhere throughout the specification (Prescriptions, Immunizations, Other Medications, Dispenses) that an ingredient could be specified, we have these constraints in place.

4.4 Prescription Authoritative Element Message element: combinedMedicationRequest.precondition Comment from the spec: If true, indicates that the prescription is non-authoritative. I.e. A paper copy must be viewed before the prescription can be dispensed. Allows distinguishing prescriptions where the paper copy is authoritative vs. the electronic copy being authoritative. This attribute behaves as a 'mandatory' element where the presence of the association indicates that a paper prescription is needed and the absence of the association indicates that one is not. In PEI, all prescriptions are non- authoritative meaning that this element must be present in all messages.

4.5 Prescription Dispensing Instruction Constraints In addition to the areas already discussed (form code, medication code, ingredients) when specifying a dispensing instruction element in a prescription message: combinedMedicationRequest.component3.supplyRequest.component.supplyRequestItem In order to always know the exact quantity to be dispensed from a prescription, we have constrained the specification so that both the number of fills and the standard fill supply quantity are always specified OR that the total prescribed quantity is specified. All of these can be sent, but at a minimum, either the first two or the last one must be sent. These equate to the following fields in the message: Number of fills: combinedMedicationRequest.component3.supplyRequest.component.supplyRequestItem. component1.subsequentSupplyRequest.repeatNumber Standard Fill Supply Quantity: combinedMedicationRequest.component3.supplyRequest.component.supplyRequestItem. component1.subsequentSupplyRequest.quantity Total Prescribed Quantity: combinedMedicationRequest.component3.supplyRequest.component.supplyRequestItem. quantity

5. Dispenses In addition to the areas already discussed (form code, route code, ingredients) dispenses have the following constraints.

5.1 Prescription id Message element: medicationDispense.inFulfillmentOf.substanceAdministrationRequest.id The element used to specify the prescription id within the dispense message (the inFulfillmentOf element) is optional in order to support inferred prescriptions where the prescription details are determined based on the data from the dispense. In PEI, deferred prescriptions are not supported and the inFulfillmentOf element should be treated as a mandatory element where the prescription id must be specified.

5.2 Specification of the Drug Message element: medicationDispense.component3.supplyEvent.product.medication.player.code (also within component2.dosageInstruction element)

For dispenses with the PEI implementation, the set of code sets allowed for specifying the drug in this element are: DIN (2.16.840.1.113883.5.1105) and OPINION (2.16.840.1.113883.5.1102) or left unspecified (i.e. nullFlavor provided), but only when a compound is being sent and the drug is identified by a name and optionally the specification of multiple ingredients. These constraints apply on the dispense anywhere the Medication CMET is used and a drug code is used to identify the drug product being prescribed.

6. Immunizations In addition to the areas already discussed (form code, route code, ingredients) dispenses have the following constraints

6.1 Specification of the Drug Message element: immunization.consumable For immunizations, the immunization.code element has the following comment: “Indicates that the type of administration is an administration, and for SNOMED, also indicates the specific type of administration. Thus the attribute is mandatory. The datatype is CD to allow for SNOMED post-coordination.” The immunization.consumable element is optional to allow for the case where the immunization type is specified via SNOMED. In the PEI case, we are not supporting SNOMED and therefore, are treating the immunization.consumable element as a required field. The code system values accepted in the immunization.consumable.medication.player.code element are: DIN (2.16.840.1.113883.5.1105) or left unspecified (i.e. nullFlavor provided), but only when a compound is being sent and the drug is identified by a name and optionally the specification of multiple ingredients.

6.2 Specification of Next Course of Treatment Message element: immunization.inFulfillmentOf.immunizationPlan When specifying the next course of treatment for the immunization, the immunizationPlan element has two optional child elements called fulfillment and successor - fulfillment is used to indicate the date on which the overall immunization therapy is to be repeated and successor is used to indicate the date on which the next sequential dose for the immunization course is to be given. Although the schema does not enforce this, you would only use one of the fulfillment or successor elements and not both.

7. Other Medications In addition to the areas already discussed (form code, route code, ingredients) dispenses have the following constraints

7.1 Specification of the Drug Message element: otherMedication.consumable.medication.player.code. The code system values accepted in this element are: DIN (2.16.840.1.113883.5.1105) and OPINION (2.16.840.1.113883.5.1102) or left unspecified (i.e. nullFlavor provided), but only when a compound is being sent and the drug is identified by a name and optionally the specification of multiple ingredients.

8. Queries 8.1 Query Continuation The PEI DIS does not support any of the elements used for query continuation. These can be provided, but they will be ignored.

8.2 IncludeIssuesIndicator In several query messages (allergy, reaction, conditions, observations) there is an includeIssuesIndicator parameter in the parameter list in spite of the fact that the specific entities are not intended by the standard to have issues recorded against them. For all of these, the includeIssuesIndicator will be ignored if provided and issues are never returned in a query response for these messages.