{
  "description": null,
  "_filename": "profile-immunization.StructureDefinition.json",
  "package_name": "ForgePatientChart.0830",
  "date": "2021-03-01T20:10:58.0169287+00:00",
  "derivation": "constraint",
  "meta": {
    "versionId": "2",
    "lastUpdated": "2022-08-10T17:44:15.3343832+00:00"
  },
  "publisher": null,
  "fhirVersion": "4.0.1",
  "name": "Immunization",
  "mapping": [ {
    "uri": "http://hl7.org/fhir/workflow",
    "name": "Workflow Pattern",
    "identity": "workflow"
  }, {
    "uri": "http://hl7.org/v2",
    "name": "HL7 v2 Mapping",
    "identity": "v2"
  }, {
    "uri": "http://hl7.org/v3",
    "name": "RIM Mapping",
    "identity": "rim"
  }, {
    "uri": "http://hl7.org/fhir/fivews",
    "name": "FiveWs Pattern Mapping",
    "identity": "w5"
  }, {
    "uri": "http://hl7.org/v3/cda",
    "name": "CDA (R2)",
    "identity": "cda"
  } ],
  "abstract": false,
  "type": "Immunization",
  "experimental": null,
  "resourceType": "StructureDefinition",
  "title": null,
  "package_version": "0.1.0",
  "status": "draft",
  "id": "45e5c091-2721-46ab-a07f-3ecfc4adb735",
  "kind": "resource",
  "url": "http://telus.com/fhir/patientChart/StructureDefinition/profile-immunization",
  "version": null,
  "differential": {
    "element": [ {
      "id": "Immunization",
      "path": "Immunization",
      "mustSupport": true
    }, {
      "id": "Immunization.id",
      "path": "Immunization.id",
      "comment": "Usage Note:   This will usually be a GUID that is assigned by the sending application.\r\n\r\nThe only time that a resource does not have an id is when it is being submitted to the server using a create operation.",
      "mustSupport": true
    }, {
      "id": "Immunization.meta",
      "path": "Immunization.meta",
      "mustSupport": true
    }, {
      "id": "Immunization.meta.lastUpdated",
      "path": "Immunization.meta.lastUpdated",
      "mustSupport": true
    }, {
      "id": "Immunization.meta.source",
      "path": "Immunization.meta.source",
      "mustSupport": true
    }, {
      "id": "Immunization.meta.profile",
      "max": "1",
      "path": "Immunization.meta.profile",
      "comment": "Usage note:  added this to align with PS-ON - \r\n\r\nIt is up to the server and/or other infrastructure of policy to determine whether/how these claims are verified and/or updated over time.  The list of profile URLs is a set.",
      "mustSupport": true
    }, {
      "id": "Immunization.meta.security",
      "path": "Immunization.meta.security"
    }, {
      "id": "Immunization.meta.security.system",
      "path": "Immunization.meta.security.system",
      "mustSupport": true
    }, {
      "id": "Immunization.meta.security.code",
      "path": "Immunization.meta.security.code",
      "mustSupport": true
    }, {
      "id": "Immunization.text",
      "path": "Immunization.text",
      "comment": "Conformance Rule:     This must be formatted, as closely as possible what was presented to the user in the originating system and must include all clinical data.    \r\n\r\nContained resources do not have narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied).  This may be necessary for data from legacy systems where information is captured as a \"text blob\" or where text is additionally entered raw or narrated and encoded information is added later.",
      "mustSupport": true
    }, {
      "id": "Immunization.text.status",
      "path": "Immunization.text.status",
      "mustSupport": true
    }, {
      "id": "Immunization.text.div",
      "path": "Immunization.text.div",
      "mustSupport": true
    }, {
      "id": "Immunization.identifier.system",
      "min": 1,
      "path": "Immunization.identifier.system",
      "mustSupport": true
    }, {
      "id": "Immunization.identifier.value",
      "min": 1,
      "path": "Immunization.identifier.value",
      "mustSupport": true
    }, {
      "id": "Immunization.status",
      "path": "Immunization.status",
      "comment": "Conformance Rules:   EMRs will use the status of not-done should be included in the export\r\nConformance Rules:   All status's should be supported though this may be filtered based on use case.  Example:  Entered-in-error - \r\nFor patients, entered-in-error may not be returned in queries.   \r\nFor EMR API, all status's are exposed as they do not know the requestor.  \r\n In the context of a patient chart, entered in error would not be shared.  Other implementations such as DHIR will have their own business rules to adhere to. \r\n\r\nNotes - \r\nMA - active status on the task (future) - eg first dose out of 3 and the others are to be scheduled.   Cancel status maps to not-done.   \r\nPSS - do not have entered-in-error,  in PSS, refusal - if not-done this will map to refuse and a reason of \"PAJOBJ\" - patient objection.\r\nMS - all three can be supported\r\nDHIR - Status is fixed to completed\r\nCA Core - supported\r\n\r\n\r\nWill generally be set to show that the immunization has been completed or not done.  This element is labeled as a modifier because the status contains codes that mark the resource as not currently valid.",
      "mustSupport": true
    }, {
      "id": "Immunization.statusReason",
      "path": "Immunization.statusReason",
      "binding": {
        "strength": "extensible"
      },
      "comment": "Usage:  If EMRs are able to capture they should send this as either code or text.\r\nExample use cases:  Patient already has immunity - common, ruebella; medical condition, indicates they should not get the immunization.\r\nExample 2 - \"Patient refused\" text, will have an PATOBJ code and an Immunization.status of \"not done\"\r\n\r\nMapping Notes:   \r\nPSS does not handle all reasons, but does handle patient refusal - see MA below as PSS will do the same\r\nMA has a cancel reason that would need to be mapped into a code. \" Patient Declined\" and will map to \"PATOBJ\"\r\nMS -- text field with reason for refusal, but not codified - text only. \r\nCA-Core - supported  \r\n\r\n\r\nThis is generally only used for the status of \"not-done\". The reason for performing the immunization event is captured in reasonCode, not here.",
      "mustSupport": true
    }, {
      "id": "Immunization.statusReason.coding",
      "path": "Immunization.statusReason.coding",
      "comment": "Usage Note:   Local codes must always be sent when codes exist in addition to the code system   \r\n\r\nCodes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information.  Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.",
      "mustSupport": true
    }, {
      "id": "Immunization.statusReason.coding.system",
      "path": "Immunization.statusReason.coding.system",
      "mustSupport": true
    }, {
      "id": "Immunization.statusReason.coding.code",
      "path": "Immunization.statusReason.coding.code",
      "mustSupport": true
    }, {
      "id": "Immunization.statusReason.coding.display",
      "path": "Immunization.statusReason.coding.display",
      "mustSupport": true
    }, {
      "id": "Immunization.statusReason.text",
      "min": 1,
      "path": "Immunization.statusReason.text",
      "mustSupport": true
    }, {
      "id": "Immunization.vaccineCode",
      "path": "Immunization.vaccineCode",
      "comment": "Usage Note:   This will be use case dependent; DHIR uses CVC codes and other implementations may use other codes.  CVC codes are SNOMED codes and seem to align with DHDR and Core \r\nConformance Rule:  Local codes/original codes (eg HICL, DIN) should not be sent\r\n\r\nMapping Notes :\r\nCanadian Core has a preferred code set, for Generic and TradeName (2 slices).    \r\nPanorama ???\r\nPSS:   Maps into Ontario MD Standard - shortform (Column C - eg PSS:   Maps into Ontario MD Standard - shortform Canadian Vaccine Catalogue\r\nMA - Patient Chart--> Imm. --> Task Category: \"Immunization\" --> Type\r\nMS - original code would be a DIN (source code for mapping)\r\nDHIR:  binding to CVC TradeName, subset of SNOMED\r\n\r\n*Jim advises that CVC includes some codes on this list that are not immunizations, immunglobulins.  BCG could be a diagnostic/test agent rather than a vaccine, but agent used to be used in vaccines\r\n\r\n**Binding should be to SNOMED (code system) , and CVC (value set)\r\n\r\nexample:   \"vaccineCode\": { \"coding\":  {\r\n \"system\": \"http://snomed.info/sct\",\r\n \"version\": \"http://snomed.info/sct/20611000087101\",\r\n \"code\": \"61153008\",\r\n \"display\": \"MMR\" \r\n\r\nPSS:   Maps into Ontario MD Standard - shortform (column C) - Canadian Vaccine Catalogue\r\nMA : - TRAVIS TO CONFIRM - JN - looks like we expose local codes ONLY; but maybe in background they map into CVC codes for Ontario MD\r\nMS:   DINS - text only; CVCatelogue provides a mapping into DIN\r\n\r\n\r\nNot all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.",
      "mustSupport": true
    }, {
      "id": "Immunization.vaccineCode.coding",
      "min": 1,
      "path": "Immunization.vaccineCode.coding",
      "comment": "??? how many codings do we support?\r\n\r\nMappings:\r\nCA-Core:  1:* supported\r\nPSS: Maps into Ontario MD Standard - shortform (Column C - eg PSS:   Maps into Ontario MD Standard - shortform Canadian Vaccine Catalogue\r\nMA: Patient Chart--> Imm. --> Task Category: \"Immunization\" --> Type\r\nMS:  ??\r\n\r\n\r\nDiscussion:   Are local codes permitted?\r\n\r\nCodes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 \r\nCore Principles for more information.  Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.",
      "slicing": {
        "rules": "open",
        "discriminator": [ {
          "path": "$this",
          "type": "type"
        } ]
      },
      "mustSupport": true
    }, {
      "id": "Immunization.vaccineCode.coding.system",
      "min": 1,
      "path": "Immunization.vaccineCode.coding.system",
      "comment": "**** to be confirmed \r\n\r\nThe URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...).  OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.",
      "fixedUri": "http://snomed.info/sct",
      "mustSupport": true
    }, {
      "id": "Immunization.vaccineCode.coding.code",
      "min": 1,
      "path": "Immunization.vaccineCode.coding.code",
      "mustSupport": true
    }, {
      "id": "Immunization.vaccineCode.coding:CVCGeneric",
      "max": "1",
      "path": "Immunization.vaccineCode.coding",
      "binding": {
        "strength": "preferred",
        "valueSet": "https://cvc.canimmunize.ca/v3/ValueSet/Generic"
      },
      "comment": "Usage:   Aligns with CA-Core:\r\n\r\nCodes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information.  Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.",
      "sliceName": "CVCGeneric",
      "mustSupport": false
    }, {
      "id": "Immunization.vaccineCode.coding:CVCGeneric.system",
      "min": 1,
      "path": "Immunization.vaccineCode.coding.system",
      "fixedUri": "http://snomed.info/sct",
      "mustSupport": true
    }, {
      "id": "Immunization.vaccineCode.coding:CVCGeneric.code",
      "min": 1,
      "path": "Immunization.vaccineCode.coding.code",
      "mustSupport": true
    }, {
      "id": "Immunization.vaccineCode.coding:CVCTradeName",
      "max": "1",
      "path": "Immunization.vaccineCode.coding",
      "binding": {
        "strength": "preferred",
        "valueSet": "https://cvc.canimmunize.ca/v3/ValueSet/Tradename"
      },
      "comment": "Usage:   Aligns with CA-Core\r\n\r\nCodes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information.  Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.",
      "sliceName": "CVCTradeName",
      "mustSupport": true
    }, {
      "id": "Immunization.vaccineCode.coding:CVCTradeName.system",
      "min": 1,
      "path": "Immunization.vaccineCode.coding.system",
      "fixedUri": "http://snomed.info/sct",
      "mustSupport": true
    }, {
      "id": "Immunization.vaccineCode.coding:CVCTradeName.code",
      "min": 1,
      "path": "Immunization.vaccineCode.coding.code",
      "mustSupport": true
    }, {
      "id": "Immunization.vaccineCode.coding:DIN",
      "path": "Immunization.vaccineCode.coding",
      "comment": "Usage Note:    The CVCGeneric or CVCTradename must be used where known.   In some cases, there is not a 1:1 mapping to SNOMED and therefore DIN may be specified instead.   eg Flumist comes out with a new DIN each year; this is not specified at this level in SNOMED as there is a single code.  DIN should also be used when there is no CVC code.    When mapping has occured from a local DIN to CVC codes, it is good practice to include the DIN in addition to the CVC code.\r\n\r\nCodes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information.  Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.",
      "sliceName": "DIN"
    }, {
      "id": "Immunization.vaccineCode.coding:DIN.system",
      "min": 1,
      "path": "Immunization.vaccineCode.coding.system"
    }, {
      "id": "Immunization.vaccineCode.coding:DIN.code",
      "min": 1,
      "path": "Immunization.vaccineCode.coding.code"
    }, {
      "id": "Immunization.vaccineCode.text",
      "min": 1,
      "path": "Immunization.vaccineCode.text",
      "mustSupport": true
    }, {
      "id": "Immunization.patient",
      "path": "Immunization.patient",
      "mustSupport": true
    }, {
      "id": "Immunization.patient.reference",
      "min": 1,
      "path": "Immunization.patient.reference",
      "comment": "Usage Note:   This should contain the name of the Patient, which can then be used in narrative\r\n\r\nUsing absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed eco-system boundaries.   Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the URL conforms to the structure \"/[type]/[id]\" then it should be assumed that the reference is to a FHIR RESTful server.",
      "mustSupport": true
    }, {
      "id": "Immunization.patient.display",
      "path": "Immunization.patient.display",
      "mustSupport": true
    }, {
      "id": "Immunization.encounter",
      "path": "Immunization.encounter",
      "comment": "Core-CA - not supported\r\nDHIR - not supported\r\nCHR - may be able to support - consider for future\r\n\r\nImport - Jim - this has little value - this would not be added into the patient chart\r\nDW - often encounter centric so perhaps in future\r\nMS - does not support\r\n\r\nReferences SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository."
    }, {
      "id": "Immunization.occurrence[x]",
      "path": "Immunization.occurrence[x]",
      "comment": "Mappings:  Canadian core is not mandatory however, the core FHIR profile is 1..1\r\n\r\nUsage Notes:   DHIR makes this mandatory.   They added an extension for estimated date (boolean).\r\n\r\nUsage Note:  Dukoral prescription may be taken by the patient.   The occurrence date may be set to the prescription date as the exact date/time of the occurrence is unknown.\r\n\r\nMapping:  \r\nPSS - no issues\r\nMA - No issues \r\nMS - No way to determine if date is estimated or not - this is a GAP    Date is mandatory when vaccine has been administered; estimated value = false.   If no date, the records would not be shared  \r\n\r\nWhen immunizations are given a specific date and time should always be known.   When immunizations are patient reported, a specific date might not be known.  Although partial dates are allowed, an adult patient might not be able to recall the year a childhood immunization was given. An exact date is always preferable, but the use of the String data type is acceptable when an exact date is not known. A small number of vaccines (e.g. live oral typhoid vaccine) are given as a series of patient self-administered dose over a span of time. In cases like this, often, only the first dose (typically a provider supervised dose) is recorded with the occurrence indicating the date/time of the first dose.",
      "mustSupport": true
    }, {
      "id": "Immunization.recorded",
      "path": "Immunization.recorded",
      "comment": "Mappings:\r\nCA-Core:  not supported\r\nDHIR: \r\nMA: Patient Chart--> Imm. --> Task Category: \"Immunization\" --> Observation --> Date and Time\r\nPSS:   TBD\r\nMS:  TBD",
      "mustSupport": true
    }, {
      "id": "Immunization.primarySource",
      "min": 1,
      "path": "Immunization.primarySource",
      "comment": "Mapping Notes:\r\nCore-CA - this is mandatory in these profiles and therefore mandatory here\r\n************ revisit and see what Core-CA does  - they will likely downgrade\r\n\r\n** This is a low impact field that is only of concern to DHIR.  \r\nDHIR -  Conformance Rule:   true if the immunizaiton was administered by the submitting clinical \"OFFICE\"; otherwise this is false.  On query result, there is an additional conformance rule:  This will be true if the immunization was administered by the IMMPHU - Public health unit\r\n\r\nExample:1   An immunization may be recorded without an event, eg when records are imported from a paper chart.   It is an external event but it is challenging to determine that it is external as there is no event recorded in the EMR, or the user did not flag as internal or external when it was recorded.     \r\nExample 2:   Imported the patient from another EMR; immunization is recorded as a primary immunization (not external); upon import it is external, but the record stays as internal when it is now really external.     Unless further logic is applied (eg compare users with historical users in the clinic) this will read falsely.  \r\n\r\nTELUS can conform to the DHIR rules\r\n\r\nPSS - there is an optional external flag to indicate someone else administered; decision on older records.  If date is older then this is likely not the primary source.   When vaccine record includes the clinician who administered, this should be set to true.   This is more complicated as this may not always be there with older records, though this is a rare case \r\n\r\nCHR - are able to add a record without indicating who performed this;  though rare, prefer this is not mandatory\r\n\r\nMA - TRAVIS - ??\r\nMS - Not stored as is but may be derived from dates, and the fact that it was administered by the provider at the clinic.  Similar to PSS\r\n\r\nReflects the “reliability” of the content.",
      "mustSupport": true
    }, {
      "id": "Immunization.reportOrigin",
      "path": "Immunization.reportOrigin",
      "binding": {
        "strength": "example",
        "valueSet": "https://cvc.canimmunize.ca/v3/ValueSet/RepSource"
      },
      "comment": "DHIR:  Conformance Rule:  Required if the primary source is false.     Note:  When reporting immunizations this value would not be required as the EMR is always the primary source.   This is never returned in query results from DHIR.  \r\n\r\nPatient Chart Conformance Rule:   When sharing immunization records, EMRs should include this data if known.   PSS, MA and MS do not have a \"code\" today but it will be supported for future use.  Text may be populated.\r\n\r\nCA-Core:   1:1 Supported - value set binding with no further constraints on codeable concept\r\nPSS:  Captures text string - map to text\r\nMS:   not cpatured\r\nMA\"   TRAVIS\r\n\r\nExample from DHIR follows.  Value set is CVC - SNOMED codes\r\n\r\nValueSet: [basecvc]/ValueSet/RepSource - for DHIR this will be the binding but this is not national\r\nSupported codes are \r\n223366009 Healthcare professional (occupation)\r\n116154003 Patient (person)\r\n423374008 Review of systems section (record artifact) - eg Immunization records (third party app to a repository)\r\n\r\n\r\n\r\n \"system\": \"http://snomed.info/sct\",\r\n \"version\": \"http://snomed.info/sct/20611000087101\",\r\n \"code\": \"223366009\",\r\n \"display\": \"Health care provider\"   \r\n\r\nShould not be populated if primarySource = True, not required even if primarySource = False.",
      "mustSupport": true
    }, {
      "id": "Immunization.reportOrigin.coding",
      "path": "Immunization.reportOrigin.coding",
      "mustSupport": true
    }, {
      "id": "Immunization.reportOrigin.text",
      "path": "Immunization.reportOrigin.text",
      "mustSupport": true
    }, {
      "id": "Immunization.location",
      "path": "Immunization.location",
      "comment": "CA - Core:   not supported\r\nDHIR:   not supported\r\nPatient Chart:    This aligns with Canadian and DHIR and will be not supported \r\n\r\n\r\nReferences SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository."
    }, {
      "id": "Immunization.manufacturer",
      "path": "Immunization.manufacturer",
      "comment": "Canadian Core - not supported\r\nDHIR - not supported on create or query.    \r\nPatient Chart - not supported; if the vaccine code is a brand name the manufacturer will be known.    Conformance Rule:   If EMR has captured \"text\", this can be mapped to display.\r\n\r\n\r\nPSS - captured as a text field (OMD requirement) - may be populated in display\r\nMA - captured as a text field (OMD requirement) - may be populated in display\r\nCHR - captured as a text field (OMD requirement) - may be populated in display\r\n\r\nReferences SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository."
    }, {
      "id": "Immunization.manufacturer.display",
      "path": "Immunization.manufacturer.display",
      "mustSupport": true
    }, {
      "id": "Immunization.lotNumber",
      "path": "Immunization.lotNumber",
      "comment": "Core-CA:   Not supported\r\nPS-CA and PS-ON\r\nDHIR:   Optional on create; Optional on query response; Support a query by lot number \r\nConformance Rule:  Must be populated when known.  Rationale:   If there is a recall this is relevant if sending to another EMR as it is relevant to the primary physician.   \r\nNote:  It is not in the Patient Summary as it is irrelvent in this context.\r\n\r\nPSS - captured as a text field (OMD requirement) - may be populated in display\r\nMA - captured as a text field (OMD requirement) - may be populated in display\r\nMS - - captured as a text field \r\nCHR - captured as text\r\n\r\n\r\nNote that FHIR strings SHALL NOT exceed 1MB in size",
      "mustSupport": true
    }, {
      "id": "Immunization.expirationDate",
      "path": "Immunization.expirationDate",
      "comment": "Core-CA:   Not supported\r\nDHIR:   Optional on create; Optional on query response; Support a query by lot number (extension on medication returned by CVC); and also returns the expiration date returned\r\n\r\nPatient Chart:   Not supported.   This is captured by text, not date in some EMRs.  Additionally, this can be queried or discovered by other means if necessary and is therefore redundant.    \r\n\r\nPSS - captured as a text field (OMD requirement) - potential issue - as a date field (month/year) is expected\r\nMA - captured as a text field (OMD requirement) -  \r\nMS - - not recorded\r\nCHR - Marc - if capturing as a date, then we shoud support this"
    }, {
      "id": "Immunization.site",
      "path": "Immunization.site",
      "binding": {
        "strength": "preferred",
        "valueSet": "https://cvc.canimmunize.ca/v3/ValueSet/AnatomicalSite"
      },
      "comment": "CA-PS - http://hl7.org/fhir/uv/ips/ValueSet/target-site-uv-ips (preferred, SNOMED) - must support = false\r\nON-PS - https://cvc.canimmunize.ca/v3/ValueSet/AnatomicalSite (preferred, SNOMED?) - must support = true, coding must be supported (ISSUE)\r\nCA-Core - supported, optional using SNOMED (preferred) Value set is CVC, text is acceptable and added here\r\nDHIR -  Supported, optional , using SNOMED, no value set is specified.   MUST BE CODED VALUE therefore cannot be sent and text is optional. \r\n\r\n\r\n***EMRs DO NOT SUPPORT A CODED VALUE TODAY; THEREFORE THIS CAN ONLY BE SENT AS TEXT \r\nPatient Chart - Use https://cvc.canimmunize.ca/v3/ValueSet/AnatomicalSite (preferred).  \r\nConformance Rule:   Must be populated when known.  \r\n\r\nPSS - text only\r\nMA - Text is easiest; captured in configurable observation template - manageable list/dropdown but customization is allowed- Mapping could be tricky due to customization option.  \r\nMS - text only\r\nCHR -  - there is a dropdown list, potential for mapping and also a value of \"other\" without any associated text \r\n\r\nCA-Core below\r\n https://cvc.canimmunize.ca/v3/ValueSet/AnatomicalSite (preferred)\r\n\r\n368208006 Left upper arm structure (body structure)\r\n368209003 Right upper arm structure (body structure)\r\n16217701000119102 Structure of left deltoid muscle (body structure)\r\n16217661000119109 Structure of right deltoid muscle (body structure)\r\n66480008 Structure of left forearm (body structure)\r\n64262003 Structure of right forearm (body structure)\r\n123851003 Mouth region structure (body structure)\r\n244506005 Both anterior nares (body structure)\r\n723608007 Structure of left anterior naris (body structu\r\n\r\n\r\n\r\nNot all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.",
      "mustSupport": true
    }, {
      "id": "Immunization.site.coding",
      "path": "Immunization.site.coding",
      "comment": "Usage Rule:   Not expected to be used initially as current EMRs are supporting text only\r\n\r\nCodes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information.  Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.",
      "mustSupport": true
    }, {
      "id": "Immunization.site.coding.system",
      "path": "Immunization.site.coding.system",
      "fixedUri": "http://snomed.info/sct",
      "mustSupport": true
    }, {
      "id": "Immunization.site.coding.code",
      "path": "Immunization.site.coding.code",
      "mustSupport": true
    }, {
      "id": "Immunization.site.text",
      "path": "Immunization.site.text",
      "mustSupport": true
    }, {
      "id": "Immunization.route",
      "path": "Immunization.route",
      "binding": {
        "strength": "preferred",
        "valueSet": "https://cvc.canimmunize.ca/v3/ValueSet/RouteOfAdmin"
      },
      "comment": "Usage Note:   As this is supported by IPS, CA and ON, vendors must be able to derive and populate this data element where available.\r\n\r\nMapping:   \r\nCanadian Core - Value set is Canadian Core\r\nDHIR - route is optional but must be coded if present; text is not supported.     binding to CVC\r\nPS-ON- https://cvc.canimmunize.ca/v3/ValueSet/RouteOfAdmin (preferred), must support, coding+text\r\nPS-CA - RouteOfAdminUvIps (preferred), must support, text only (Nov '21)\r\n\r\nMS - not captured, not even text - cannot be sent\r\nPSS - data is available if vaccine was recorded as FDB IDC code. (conforamnce example)\r\nMA - potential mapping to method - text - supported in Ontario\r\nCHR - drop down list that likely maps easily[;  not required field; can set up a default \r\n\r\nUsage Ntoe:  This is determined by the name/code of the immunization \r\n\r\nNot all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.",
      "mustSupport": true
    }, {
      "id": "Immunization.route.coding",
      "path": "Immunization.route.coding",
      "comment": "DHIR - code is mandatory; text is not supported - we cannot support this so will send text only\r\nUsage:   in future this could be used\r\n\r\nCodes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information.  Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.",
      "mustSupport": true
    }, {
      "id": "Immunization.route.coding.system",
      "path": "Immunization.route.coding.system",
      "fixedUri": "http://snomed.info/sct",
      "mustSupport": true
    }, {
      "id": "Immunization.route.coding.code",
      "path": "Immunization.route.coding.code",
      "mustSupport": true
    }, {
      "id": "Immunization.route.coding.userSelected",
      "path": "Immunization.route.coding.userSelected",
      "mustSupport": true
    }, {
      "id": "Immunization.route.text",
      "path": "Immunization.route.text",
      "mustSupport": true
    }, {
      "id": "Immunization.doseQuantity",
      "path": "Immunization.doseQuantity",
      "comment": "Mapping:\r\nCA-PS and CA-ON- not supported\r\nDHIR - supported as optional, value and unit (as a string) fields are required when populated\r\nPSS - dose field, if populated - unit required; almost always ML\r\nMA - no mapping\r\nMS - text only - may be able to parse the number?\r\nCHR - dropdown units (ML, MG, G, Capsule, Vial)\r\n\r\n\r\nThe context of use may frequently define what kind of quantity this is and therefore what kind of units can be used. The context of use may also restrict the values for the comparator.",
      "mustSupport": true
    }, {
      "id": "Immunization.doseQuantity.value",
      "min": 1,
      "path": "Immunization.doseQuantity.value",
      "mustSupport": true
    }, {
      "id": "Immunization.doseQuantity.unit",
      "path": "Immunization.doseQuantity.unit",
      "mustSupport": true
    }, {
      "id": "Immunization.performer",
      "path": "Immunization.performer",
      "comment": "Mapping:   \r\nDHIR - On the create supported as optional; with function and actor mandatory when provided.   Function fixed value as AP (Adminstering Provider)\r\nDHIR - On the query response, this is just a name\r\nCanadian Core - support as optional; with function and actor mandatory when provided\r\nPS-CA and PS-ON do not support\r\nPatient Chart - For create profiles to align with Core and DHIR, we will incldue all data (Identifier, names, telecom, etc)\r\nPatient Chart - appropriate info such as licence number, name.   NOT billing number, NOT phone number\r\n\r\nCHR - Injected by",
      "mustSupport": true
    }, {
      "id": "Immunization.performer.function",
      "min": 1,
      "path": "Immunization.performer.function",
      "comment": "Conformance Rule:   DHIR -mandatory when performer is provided.  Function fixed value as AP (Adminstering Provider) \r\nPatient Chart Rule:   This should not be limited to AP\r\n\r\nNot all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.",
      "mustSupport": true
    }, {
      "id": "Immunization.performer.function.coding",
      "path": "Immunization.performer.function.coding",
      "mustSupport": true
    }, {
      "id": "Immunization.performer.function.coding.system",
      "min": 1,
      "path": "Immunization.performer.function.coding.system",
      "fixedUri": "http://terminology.hl7.org/CodeSystem/v2-0443",
      "mustSupport": true
    }, {
      "id": "Immunization.performer.function.coding.code",
      "min": 1,
      "path": "Immunization.performer.function.coding.code",
      "mustSupport": true
    }, {
      "id": "Immunization.performer.function.coding.userSelected",
      "path": "Immunization.performer.function.coding.userSelected",
      "mustSupport": true
    }, {
      "id": "Immunization.performer.function.text",
      "path": "Immunization.performer.function.text",
      "mustSupport": true
    }, {
      "id": "Immunization.performer.actor",
      "path": "Immunization.performer.actor",
      "type": [ {
        "code": "Reference",
        "aggregation": [ "bundled" ]
      } ],
      "comment": "Canadian Core - has restricted to http://hl7.org/fhir/ca/baseline/StructureDefinition/profile-practitioner\r\nDHIR - defined a practitioner profile - ca-on-immunizations-profile-submission-clinician-Practitioner-submitter (identifier OneID, name, phone + email)\r\nPatient Chart - Will use a TELUS profile for Practitioner, PractitionerRole and Organization (eg pharmacy) that aligns with both of the above.   \r\n**Potential issues with PractitionerRole because Organization is mandatory and EMR may not always know the organization/clinic where the immunization occurred.   In the case where there is a single EMR instance supporting multiple location/orgs, the exact org where the immunization occurred may not be known.   Data model does not capture always.   \r\n** New PractitonerRole Profile is requried HERE with an optional Organization\r\n\r\nCHR -->   how do they capture this?   \r\n\r\n***May wish to create a scaled down profile for this purpose, eg PractitionerPerformer and also one for PractitonerRole\r\n***** For patient chart, the provider roles may need to be extended for Nurse, Nurse Practitioner, pharmacists, etc\r\nPSS, MA, MS  - all systems are capable of sending provider data\r\n*** Role code may be useful so we may wish to point to PractitionerRole\r\n \r\n\r\nWhen the individual practitioner who performed the action is known, it is best to send.",
      "mustSupport": true
    }, {
      "id": "Immunization.note",
      "path": "Immunization.note",
      "comment": "Usage Note:  This is supported by Patient Chart; is not supported by CA, PS_ON and PS-CA - if this is available, this should always be sent in all cases.  \r\n\r\nMappings:\r\nCA-Core - not supported\r\nPS-ON and PS-CA - not supporting\r\nDHIR - not supported\r\nPSS -  instructions field\r\nMA -  Task Instructions, Nursing Notes and Doctor notes.   MA - has a boolean to indicate that patient received education which could be mapped here\r\nMS - Comment field \r\nCHR - comment field\r\n\r\nFor systems that do not have structured annotations, they can simply communicate a single annotation with no author or time.  This element may need to be included in narrative because of the potential for modifying information.  *Annotations SHOULD NOT* be used to communicate \"modifying\" information that could be computable. (This is a SHOULD because enforcing user behavior is nearly impossible).",
      "mustSupport": true
    }, {
      "id": "Immunization.note.text",
      "path": "Immunization.note.text",
      "mustSupport": true
    }, {
      "id": "Immunization.reasonCode",
      "path": "Immunization.reasonCode",
      "comment": "TBD\r\n\r\nMapping:  \r\nCanadian Core - supports a reference to condition, diagnosis, etc\r\nDHIR - not supported\r\nPSS - Not supported at the Immunization \"adminstered\" level.    \r\nMA - TRAVIS - JN sees a reason field at the task level\r\nMS - not supported\r\n\r\nNot all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination."
    }, {
      "id": "Immunization.reasonReference",
      "path": "Immunization.reasonReference",
      "comment": "Mapping Notes:\r\nCA-Core - supported\r\nDHIR - not supported\r\nPSS, MA, MS - not supported\r\n\r\nReferences SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository."
    }, {
      "id": "Immunization.isSubpotent",
      "path": "Immunization.isSubpotent",
      "comment": "Mapping:\r\nCA- core:  not supported\r\nDHIR: not supported\r\nPSS, MA, MS - not supported\r\n\r\nTypically, the recognition of the dose being sub-potent is retrospective, after the administration (ex. notification of a manufacturer recall after administration). However, in the case of a partial administration (the patient moves unexpectedly and only some of the dose is actually administered), subpotency may be recognized immediately, but it is still important to record the event."
    }, {
      "id": "Immunization.subpotentReason",
      "path": "Immunization.subpotentReason",
      "comment": "Mapping:\r\nCA- core:  not supported\r\nDHIR: not supported\r\nPSS, MA, MS - not supported\r\n\r\nNot all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination."
    }, {
      "id": "Immunization.education",
      "path": "Immunization.education",
      "comment": "Mapping:\r\nCA- core:  not supported\r\nDHIR: not supported\r\nPSS, \r\nMA - has a boolean to indicate that patient received education\r\nMS"
    }, {
      "id": "Immunization.programEligibility",
      "path": "Immunization.programEligibility",
      "comment": "Mapping:\r\nCA- core:  not supported\r\nDHIR: not supported\r\nPSS, MA, MS - not supported\r\n\r\nNot all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination."
    }, {
      "id": "Immunization.fundingSource",
      "path": "Immunization.fundingSource",
      "comment": "Mapping:\r\nCA- core:  not supported\r\nDHIR: not supported\r\nPSS, MA, MS - not supported\r\n\r\nNot all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination."
    }, {
      "id": "Immunization.reaction",
      "path": "Immunization.reaction",
      "comment": "Mapping:\r\nUsage:   FHIR - expects an allergy record to be recorded; in Allergy, the Reaction.substance.code would be the medication/immunization\r\nCA- core:  supported, reference to an observation\r\nDHIR: not supported\r\n\r\nPSS:  may record this and can be tied to immunization record - connected allergy record\r\nMA - TRAVIS - is this a coded observation? \r\nMS -  not supported; may be recorded separately \r\n\r\nA reaction may be an indication of an allergy or intolerance and, if this is determined to be the case, it should be recorded as a new AllergyIntolerance resource instance as most systems will not query against past Immunization.reaction elements."
    }, {
      "id": "Immunization.protocolApplied",
      "path": "Immunization.protocolApplied",
      "comment": "Mapping:\r\nCA- core:  not supported\r\nDHIR: not supported\r\nPSS, MA, MS - not supported\r\n\r\nThis may be recorded as notes in the EMR"
    } ]
  },
  "baseDefinition": "http://hl7.org/fhir/StructureDefinition/Immunization"
}