| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ id |
MedicationDispense. identifier |
Conversion between CeRX -> FHIR is less complicated, particularly if it's updating or creating a local FHIR resource. The dispense identifier can be determined using the extension that is tied to the medication dispense OID (ex: 2.16.124.9.101.1.1.3 is the OID PEI uses to identify dispense messages). However, given the possibility of duplicative values when considering multiple identifierSystems (jurisdictional DIS), it's recommended to also include IdentifierType (JHN) and identifierSystem in the FHIR element. URLs for the DIS systems should be utilized and matched to the OID present in the sender/device/id of the CeRX (PEI uses 2.16.124.9.101.1.1 to identify its DIS as a sending entity) |
In order for the medication dispense business identifier on a FHIR resource to always convert to the medication dispense number present in medicationDispense/id… the source of the FHIR resource would need to ensure that the business identifier was globally unique. When this becomes scaled to include multiple DIS, special attention will need to be paid to ensure that duplicative business identifiers are not used for different dispenses, one way of doing this would be to include the resource generator's identifiers as part of the resource business Id that is shared publicly (2.16.124.9.101.1.1^987654321). It would need to conform to the II.BUS_AND_VER business and version data type (https://infocentral.infoway-inforoute.ca/extra/ca/cerx442-html/html/datatype.html?II.BUS_AND_VER) |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ statusCode |
MedicationDispense. status |
In order to be lossless from CeRX-> FHIR some modifications (any capitalization turned undercase) and tense changed on some values to ensure they match the value set that is required in the FHIR profile. CeRX mandates the use of the ActStatus value set which matches the value set bound to in FHIR. Interestingly, PEI was found to use one formatting convention in the CeRX medication statement example("active") while the same DIS used another convention ("COMPLETE") in the CeRX medication dispense message. These variations should be further investigated once more test messages are acquired from jurisdictional DIS. |
It will likely be easier to convert FHIR -> CeRX here because of the strictness on the use of the required value set (ActStatus). Some complications could arise if DIS require the status to be stored exactly as they have in their test data particularly when it varies from the recommended format in CeRX (ex: if PEI DIS does in fact only accept capitalized values for medicationDispense/statusCode). |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component3/ supplyEvent/ product/ COCT_MT220210CA/ medication/ player/ codeSystem |
MedicationDispense. medication. CodeableConcept.system |
OIDs that DIS are using will need to be mapped to the correct code system (HC-DIN is mandated by CeRX with no extensibility) in order to convert correctly into a system URL (OIDs not recommended in FHIR element). So long as the DIS uses the correct OIDs and the converter is informed of the correct code system URL, conversion should be lossless. Those FHIR code systems will also need to be populated with expected codes as well if code and display are expected to be supported. To align with the CA Baseline medicationDispense profile, the CCDD was a preferred value set binding (many systems accept DIN/HPN only if a CCDD code is not available) however it could present issues converting FHIR-> CeRX |
The recommended binding from the FHIR profile (preferred CCDD value set) may not be strict enough to ensure lossless FHIR-> CeRX conversion can occur with all CeRX implementors. The severity of CeRX binding to the ManufacturedDrug value set (HC-DIN & HC-NPN=.16.840.1.113883.5.1105 & 2.16.840.1.113883.5.1107) with no extensibility may mean that codes in the generated FHIR resource that fall outside of what can be translated into the HC-DIN or HC-NPN (DIN, GTIN, UPC can be translated) could not populate the medication/player/code which would result in the CeRX value being null (conformant as long as null is populated). |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component3/ supplyEvent/ product/ COCT_MT220210CA/ medication/ player/ code |
MedicationDispense. medication. CodeableConcept.code |
CeRX medication/player/code supports HC-DIN codes as well as translation between multiple code sets for drugs (e.g. DIN, GTIN, UPC). It's bound to use values from the ManufacturedDrug value set. As long as the code maps to codes in the provided code system (OID) there shouldn't be an issue with lossless conversion into FHIR. |
The same issue raised above impacts the codes that may be used in the native FHIR resource converting into conformant CeRX HC-DIN/HC-NPN codes. Lossless FHIR-> CeRX is only expected if the source of the FHIR resource ensures that the medication code/code system is one of the systems acknowledged or translatable in the ManufacturedDrug value set identified by infoway. Any code system outside of (hc-DIN, hc-NPN, GTIN, and UPC) may not be supported given the CNE binding strength enforced by CeRX for medication codes/code systems |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component3/ supplyEvent/ product/ COCT_MT220210CA / medication/ player/ text |
MedicationDispense.medication. CodeableConcept. display |
If text is present and correct as defined in the system (in this case HC DIN), there should be no issues with lossless semantic conversion from CeRX-> FHIR, if display string is not one identified by the known code system or the code system does not define text representations to display, the display element may not be populated in the FHIR output |
CeRX does not have the same constraints on text display matching the code system/code referenced (that FHIR has). So whatever is entered into medication code display will be converted into medication/player/description as unvalidated free-text, meaning conversion will be lossless but there may not be as many "checks" in place as there is for CeRX-> FHIR. Parentheses are acceptable unicode characters for the string data type that is used in FHIR. |
| PORX_IN060220CA/ QUQI_MT120000CA/ controlActEvent/ queryByParameter/ parameterList/ patientID/ value |
MedicationDispense. subject |
Conversion between CeRX -> FHIR is less complicated, particularly if it's updating or creating a local FHIR resource. Some concerns may arise if jurisdictional HCNs require additional version codes to reduce duplicate numbers in the same jurisdiction. |
Conversion between FHIR-> CeRX only works if both the source of the FHIR resource and the DIS all agree to use HCN as the business identifier. The CeRX specification notes that DIS can use unique identifiers assigned to a person by Federal, Provincial and Territorial jurisdiction. What identifiers jurisdictional DIS are using in production will be critically to understanding if FHIR-> CeRX for patient IDs is possible in reality. Additional issue may arise if a subject (patient) is not present in the FHIR resource, as CeRX has a 1..1 cardinality for PORX_IN060220CA/controlActEvent/queryByParameter/parameterList/patientID/value (currently the only way patient is tied to the medicationDispense message itself- typically tied to the prescription that is referenced in the CeRX medication dispense message) |
| No semantic equivalent. CeRX supports provider role type (e.g. Dr, Pharmacist, Psychiatrist) but it's not the same as performer.function (e.g. Distinguishes the type of performer in the dispense. For example, date enterer, packager, final checker) |
MedicationDispense. performer.function |
|
|
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ Performer/ COCT_MT090107CA/ assignedPerson/ id |
MedicationDispense. performer.actor |
Conversion between CeRX -> FHIR is less complicated, particularly if it's updating or creating a local FHIR resource. In FHIR, the performer is assumed to be the actor that is dispensing the medication. Some concerns may arise if in fringe cases whereas single provider could have more than one medical license numbers for the same jurisdiction but it's currently unclear whether that is a risk in any or all jurisdictions. The converter would also have to understand which OIDs used in the CeRX message are identifier systems for providers vs organizations. One consideration when creating the provider resource from CeRX messages: CeRX recommends a HealthcareProviderRole Type but the value set/code system cannot be found publicly and the only reference that was found in the PEI example messages were "PSY" & "DR". |
One concern is that the FHIR performer has a cardinality of 0..*, meaning multiple performing providers could be recorded, whereas CeRX only allows assignedPerson to have a 1..1 cardinality. Problems could arise in CeRX conformance is multiple providers are provided. One way around this (if capturing multiple providers is critical) is to capture performer function and use it to place the provider into the correct assignedPerson slot (CeRX supports capturing assignedPerson in multiple locations- prescribing provider, pharmacist, tech). The role itself is sometimes not enough to determine function of the assigned person, for example pharmacists can sometimes also be the prescribing provider. Conversion between FHIR-> CeRX only possible if the manager of the FHIR resource explicitly uses provincial medical license number as the business identifier and captures which jurisdictional system the medical license number is tied to (ex: so it doesn't unintentionally write a NB medical license number as the assigned personID in a CeRX message for a PEI DIS that assumes the medical license number is for PEI. Need to determine if all provinces provide a pharmacist and technician license number. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ Location/ COCT_MT240003CA/ serviceDeliveryLocation/ id |
MedicationDispense. location |
Again, CeRX->FHIR is simple is only updating or creating a local FHIR resource. The converter would also have to understand which OIDs used in the CeRX message are identifier systems for providers vs organizations. |
Some issues may arise in FHIR-> CeRX is the location used in the natively created FHIR resource is when a medication is dispensed to a location type that falls outside of the types CeRX supports (e.g. Pharmacy, Medical clinic, hospital). One example of a serviceDeliveryLocation that may not be recognized in CeRX is a Patient's Home (prescription mailed or drug administered at home). CeRX implementors store a mandatory unique identifier with the healthcare service location that allows them to do further lookup, if homes/non-healthcare locations were introduced as supported under the use cases, then additional analysis would need to be performed to ensure those locations can be adequately identified since CeRX does not allow a null-value for service location id. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ inFulfillmentOf/ substanceAdministrationRequest/ id |
MedicationDispense. authorizingPrescription |
The Prescription Order Number that is the identifier for the authorizing prescription is generated by the DIS and remains constant over the lifetime of the order (regardless of the number of pharmacies involved in dispensing the order). If the FHIR resource generated by the CeRX values will only be stored locally, then conversion into the business identifier for MedicationRequest resource is exact. If the business identifier for MedicationRequests is expected to be unique across all DIS, then the DIS that assigned the prescription order number originally should be included in the identifier somehow. |
FHIR-> CeRX is a little more complicated for two reasons. In order to have semantic consistency across implementors (and make querying for medicationRequests easier) all medicationRequest resources will need to include the DIS assigned prescription order number as one of the external business identifiers. If a prescriber's EHR creates the MedicationRequest and assigns it an identifier that is separate from the identifier that gets assigned once it lands in the DIS, then there could be downstream issues that would require matching of resources. FHIR has unlimited cardinality (0..*) for authorizing prescription. CeRX has a 1..2 cardinality (business and version identifiers captured under DIS. SET II BUS AND VER data type) for substanceAdministrationRequest IDs, meaning some issues may arise if more than two medicationRequests are associated with the MedicationDispense that is being converted into a CeRX message. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component3/ supplyEvent/ code |
MedicationDispense.type |
As long as the CeRX message is in conformance with the CeRX spec that requires a non-extensible binding to an ActPharmacySupplyType code, conversion to the ActPharmacySupplyType codes in the FHIR profile should be lossless |
FHIR-> CeRX is a little trickier in this case because CeRX mandates that the message must have a code present (doesn't accept null values) from the complete ActPharmacySupplyType value set (non-extensible). So if the FHIR resource generated natively, included an alternate concept not included in the value set (because none of the values were applicable to the situation) then there could be issues with conformance to the CeRX spec (since null value isn't an option). These fringe codes would need to be discussed and evaluated under the Request For Change process that CeRX outlines. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component3/ supplyEvent/ quantity/ value |
MedicationDispense. quantity.value |
Simple conversion between CeRX-> FHIR is expected. No cardinality or binding considerations. If for some reason the quantitySystem was required in the FHIR profile (not currently required) then the extraction and conversion tool(s) would need to be aware of what systems to imply based on what the respective DIS uses and what is populated in the unit string...not sure what additional value that would supply for the investment required to build that business rule into the tool. |
Because Quantity is mandatory (null values not accepted) in PORX_IN060220CA/PORX_MT060090CA/medicationDispense/component3/supplyEvent, the FHIR resource would need to ensure quantity was populated prior to conversion. The FHIR profile currently identifies quantity as must support but maintains a 0..1 cardinality to align with US Core and CA Core efforts to date. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component3/ supplyEvent/ quantity/ unit |
MedicationDispense. quantity.unit |
Simple conversion between CeRX-> FHIR is expected. No cardinality or binding considerations. If for some reason the quantitySystem was required in the FHIR profile (not currently required) then the extraction and conversion tool(s) would need to be aware of what systems to imply based on what the respective DIS uses and what is populated in the unit string...not sure what additional value that would supply for the investment required to build that business rule into the tool. |
Because Quantity is mandatory (null values not accepted) in PORX_IN060220CA/PORX_MT060090CA/medicationDispense/component3/supplyEvent, the FHIR resource would need to ensure quantity was populated prior to conversion. The FHIR profile currently identifies quantity as must support but maintains a 0..1 cardinality to align with US Core and CA Core efforts to date. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component3/ supplyEvent/ expectedUseTime/ value |
MedicationDispense. daysSupply.value |
Difficult to determine complexity of converting CeRX-> FHIR for other DIS until additional test messages are received. Some calculation of days (to conform to the FHIR simpleQuantity data type) is anticipated if implementors use the data format required by CeRX is IVL.WIDTH <TS.FULLDATE> . However in examining the test messages from PEI, the DIS uses the format to communicate expected days supply left |
Because CeRX requires the IVL.WIDTH <TS.FULLDATE> data format, any values present in the native FHIR daysSupply element would likely have to be converted to include a full date. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component3/ supplyEvent/ expectedUseTime/ width |
MedicationDispense. daysSupply.unit |
Difficult to determine complexity of converting CeRX-> FHIR for other DIS until additional test messages are received. Some calculation of days (to conform to the FHIR simpleQuantity data type) is anticipated if implementors use the data format required by CeRX is IVL.WIDTH <TS.FULLDATE> . However in examining the test messages from PEI, the DIS uses the format to communicate expected days supply left |
Because CeRX requires the IVL.WIDTH <TS.FULLDATE> data format, any values present in the native FHIR daysSupply element would likely have to be converted to include a full date. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ component2/ sequenceNumber |
MedicationDispense. dosageInstruction.sequence |
No anticipated issues converting from CeRX->FHIR |
Technically, integers in FHIR can be negative (CeRX only accepts positive integers like 1 or higher and the maximum digit length is two digits). But given the context of use to describe sequencing, this is not expected to cause a problem converting FHIR->CeRX. The only consideration is that the FHIR cardinality (0..1) allows for no sequence number to be provided, whereas dosageInstruction sequenceNumber is a mandatory element in CeRX (null values not accepted) |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ text |
MedicationDispense. dosageInstruction.text |
dosageInstruction/Text allows for free-text entry so conversion is expected to be lossless. The dosage text from CeRX component1/dosageInstruction was converted into DosageInstructionText for the FHIR Resource. One concern is that while dosage text at a minimum is expected from the DIS, it is not guaranteed to be present in every CeRX dispense message (required cardinality allows nulls if it's not known). The FHIR profile sets a cardinality of 1..1 given the critical nature of the dosage instruction text to both clinicians and patients. Implementors/Gateway architects may need to consider adding a null value when dosage text is not present. Alternatively, the cardinality constraint could be removed from the profile. |
So long as it doesn’t exceed 2000 characters, conversion of FHIR dosageText to CeRX administration Instructions should be lossless. One design consideration is for FHIR-> CeRX conversion is handling multiple dosage instruction lines when they arise. CeRX has a 1..1 cardinality for administrative instructions whereas FHIR allows multiple dosage elements that can be separated by dosage sequence integers (may need to be combined into one administration instruction upon conversion) |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ effectiveTime/ lowValue |
MedicationDispense. dosageInstruction. timing.repeat.bounds.period.start |
Conversion between CeRX -> FHIR is almost exact if CeRX only includes YYYYMMDD. There will need to be dashes added if MM and DD are present to conform to the DateTime FHIR format. Hours and minutes are not expected given the CeRX format IVL <TS.FULLDATE> only supports YYYYMMDD. |
Conversion between FHIR--> CeRX may require reformatting of the DateTime stamp to ensure conformance with the CeRX IVL <TS.FULLDATE> format of YYYYMMDD (changes include removal of dashes) |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ effectiveTime/ highValue |
MedicationDispense. dosageInstruction. timing.repeat.bounds. period.end |
See above |
See above |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ approachSiteCode |
MedicationDispense. dosageInstruction.site |
|
|
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ routeCode |
MedicationDispense. dosageInstruction.route |
If other jurisdictions are using GCRT codes (instead of the v3 Route Of Administration codes recommended by CeRX) then further effort is required to identify human-readable descriptions to the gCRT codes since it's not provided in the CeRX example messages today. If other jurisdictions' DIS use v3 RouteOfAdministration codes then no concerns anticipated when converting CeRX-> FHIR |
FHIR->CeRX easy due to loose conformance requirements for bound value sets. The RouteOfAdministration bound value set in CeRX is considered optional, so the use of other value sets in a native FHIR resource, should not cause conformance issues when converted into a CeRX message. Both CeRX and FHIR share a cardinality of 0..1 for these fields, so no cardinality issues anticipated. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ component2/ dosageLine/ doseQuantity/ value |
MedicationDispense. dosageInstruction. doseAndRate. doseQuantity.value |
The converting tool will need to decipher between when a CeRX value best fits the Range or SimpleQuantity data type. The example message from PEI allowed for simple conversion of doseQuantity broken up into two FHIR sub-elements: doseRange.value and doseRange.unit |
Similarly, the converter tool will need to determine how to structure the CeRX dosageLine/doseQuantity to support a range data type if it's utilized in the native FHIR resource. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ component2/ dosageLine/ doseQuantity/ unit |
MedicationDispense. dosageInstruction. doseAndRate. doseQuantity.unit |
See above |
See above |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ component2/ dosageLine/ rateQuantity |
MedicationDispense. dosageInstruction. doseAndRate .rateRatio |
|
|
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ maxDoseQuantity/ numeratorValue |
MedicationDispense. dosageInstruction. maxDosePerPeriod. numeratorValue |
CeRX-> FHIR & FHIR->CeRX are both anticipated to be a simple conversion since both the CeRX maxDoseQuantity and the FHIR maxDosePeriod support numerator (dose) and denominator (time period) values, some effort is expected to parse out the individual values/units to ensure they are converted to the FHIR sub-elements accordingly |
CeRX-> FHIR & FHIR->CeRX are both anticipated to be a simple conversion since both the CeRX maxDoseQuantity and the FHIR maxDosePeriod support numerator (dose) and denominator (time period) values, some effort is expected to parse out the individual values/units to ensure they are converted to the FHIR sub-elements accordingly |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ maxDoseQuantity/ numeratorUnit |
MedicationDispense. dosageInstruction. maxDosePerPeriod. numeratorUnit |
see abaove |
see above |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ maxDoseQuantity/ denominatorValue |
MedicationDispense. dosageInstruction. maxDosePerPeriod. denominatorValue |
see abaove |
see above |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component1/ PORX_MT980040CA/ dosageInstruction/ maxDoseQuantity/ denominatorUnit |
MedicationDispense. dosageInstruction. maxDosePerPeriod. denominatorUnit |
see abaove |
see above |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component2/ substitutionMade/ code |
MedicationDispense. substitution.type |
Because CeRX requires that values from the ActSubstanceAdminSubstitutionCode be used with no extensibility, and the example set provided in the FHIR includes those same codes as a subset, no problems are anticipated in the conversion from CeRX-> FHIR |
The CeRX CNE binding to the mandatory 4 codes in the ActSubstanceAdminSubstitutionCode value set makes conversion of FHIR->CeRX more tricky. The example value set in the profile supports 5 additional values that CeRX does not support without a Request For Change. If a FHIR resource includes a "TG" value (therapeutic generic) for substitution type, it would be considered non-conformant to include as the CeRX message. If the substitutionMade code was considered anything other than mandatory, a null value could be used in situations of non-conforming codes, but it isn't the case. Since the FHIR profile only prompts the ActSubstanceAdminSubstitutionCode as an example value set, other value sets may be used creating some potential downstream issues converting this field from FHIR-> CeRX |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component2 / substitutionMade/ reasonCode |
MedicationDispense. substitution.reason |
CeRX-> FHIR lossless expected. CeRX requires the use of one of four substitution reason codes from SubstanceAdminSubstitutionReason which are included in the SubstanceAdminSubstitutionReason value set preferred in the FHIR profile. |
While the value sets are the same, the cardinality is not. Some issues may arise due to the FHIR profile allowing infinite (0..*) substitution reasons while CeRX only allows 0..1 substitution reasons to be present. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ component2/ substitutionMade/ responsibleParty/ agent/ id |
MedicationDispense.substitution. responsibleParty |
Conversion between CeRX -> FHIR is less complicated, particularly if it's updating or creating a local FHIR resource. In FHIR, the performer is assumed to be the substituting responsible party is the provider that is initiates the substitution. The FHIR profile was constrained to remove practitionerRole as a possible reference type, meaning the converting system will only need to be aware of which OIDs the DIS are using to identify the different providers (doctors, pharmacists, etc) |
Conversion between FHIR-> CeRX only possible if the manager of the FHIR resource explicitly uses provincial medical license number as the business identifier and captures which jurisdictional system the medical license number is tied to (ex: so it doesn't unintentionally write a NB medical license number as the assigned personID in a CeRX message for a PEI DIS that assumes the medical license number is for PEI. ) While the value sets are the same, the cardinality is not. Some issues may arise due to the FHIR profile allowing infinite (0..*) substitution reasons while CeRX only allows 0..1 substitution reasons to be present. Cardinality also presents an additional consideration. The FHIR profile allows an infinite number of responsible parties for substitution, whereas CeRX only allows 1..1 responsible party to be included...meaning that a FHIR resource that includes multiple responsible individuals could create a conformance problem if converted to CeRX. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ subjectOf2/ PORX_MT980030CA/ detectedIssueEvent/ statusCode |
MedicationDispense. detectedIssue.status |
Even if the PEI example had used the required "completed" value there still would be issues converting it from CeRX->FHIR because "completed" is also not a recognized value in the observation status value set. The closest semantic match would = "final" but that would require intervention/conversion of the value to another value altogether |
The same problem arises if a FHIR resource uses any value from the required value set to communicate detected issue status…the value would not be "completed" and therefore would not conform to the requirements of that CeRX field. Because the CeRX field is considered mandatory, a null value could not be used when this scenario occurs. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ subjectOf2/ PORX_MT980030CA/ detectedIssueEvent/ text |
MedicationDispense. detectedIssue.detail |
detectedIssueEvent/text allows for free-text entry so conversion is expected to be lossless. The detected issue text from CeRX detectedIssueEvent was converted into detectedIssue.detail for the FHIR Resource. |
One consideration for detected issue as a whole, is that FHIR allows for unlimited detectedIssue reference resources (0..*) whereas CeRX allows up to 25 (0..25) potential subjectOf2 instances (indications of detected issues) and PEI messages had a note indicating the ability to support 0..50) detected issue instances. So there is a deviation from the larger specification but also a potential conversion issue if the FHIR resource has more than 25 detected issues. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ subjectOf2/ PORX_MT980030CA/ detectedIssueEvent/ mitigatedBy/ detectedIssueManagement/ code |
MedicationDispense.detectedIssue. mitigation.action |
mitigatedBy/detectedIssueManagement/code and detectedIssue.mitigation.action use the same value sets which makes conversion from CeRX->FHIR lossless in this example |
Mandatory, 1..1 cardinality for both. One consideration is that the CeRX ActDetectedIssueManagementCode value set is mandatory with no extensible values and only includes 22 possible values, the FHIR value set contains 24...later versions of CeRX (MR2009) added code 22 and code 23 (missing values). So if the DIS operates on a version lower than MR2009 and does not recognize values 22 or 23 when they are sent in the FHIR detectedIssue status element, there could be conformance issues when converting FHIR-> CeRX |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ subjectOf2/ PORX_MT980030CA/ detectedIssueEvent/ mitigatedBy/ detectedIssueManagement / author/ time |
MedicationDispense.detectedIssue. mitigation.date |
Conversion between CeRX -> FHIR is almost exact if CeRX only includes YYYYMMDDHHMMSS+/-ZZZZ. There will need to be dashes , "T", colons, and potentially time zone added to conform to the DateTime FHIR format. |
Conversion between FHIR--> CeRX may require reformatting of the DateTime stamp to ensure conformance with the CeRX IVL <TS.FULLDATETIME> format of YYYYMMDDHHMMSS[.S[S[S[S]]]]+/-ZZZZ (changes include removal of dashes, colons, T). Additionally, FHIR does not require the population of mitigation date (cardinality of 0..1) but CeRX does (1..1) which could present a problem with conformance...however a null value can be used in the CeRX message if mitigation date is unknown. |
| PORX_IN060220CA/ PORX_MT060090CA/ medicationDispense/ subjectOf2/ PORX_MT980030CA/ detectedIssueEvent/ mitigatedBy / detectedIssueManagement/ author/ assignedPerson/ id |
MedicationDispense. detectedIssue. mitigation.author |
Conversion between CeRX -> FHIR is less complicated, particularly if it's updating or creating a local FHIR resource. In FHIR, the mitigation author is assumed to be the practitioner who determined the mitigation and takes responsibility for the mitigation step occurring. |
Conversion between FHIR-> CeRX only possible if the manager of the FHIR resource explicitly uses provincial medical license number as the business identifier and captures which jurisdictional system the medical license number is tied to (ex: so it doesn't unintentionally write a NB medical license number as the assigned personID in a CeRX message for a PEI DIS that assumes the medical license number is for PEI. ) No cardinality considerations both CeRX and FHIR allow 0..1 cardinality for author. |
