MedicationRequest CeRX <--> FHIR Considerations

CeRX Element FHIR Element Lossless CeRX-> FHIR Considerations Lossless FHIR-> CeRX Considerations
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ id MedicationRequest. identifier Conversion between CeRX -> FHIR is less complicated, particularly if it's updating or creating a local FHIR resource. 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 MedicationRequest 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. 1) 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. 2) 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ statusCode MedicationRequest. status Be aware that PEI uses the following values: NEW, active, suspended, ABORTED, completed, SUPERCEDED and NULLIFIED (original capitalization kept from notes in PEI test message). Some of those values fall outside of the MedicationRequest status value set that is required by the FHIR profile. Given the strict requirement of the MedicationRequest status value set, values will either be limited or will require some level of semantic conversion/ or use of unknown value. In order to transform FHIR-> CeRX the FHIR resource will be limited to the values either accepted by the DIS (only active and completed values have exact overlap) or values that can be semantically converted to values accepted by the DIS (PEI uses NEW, active, suspended, ABORTED, completed, SUPERCEDED, and NULLIFIED).
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf6/ refusalToFill/ reason/ detectedIssueEvent/ code OR if the status is the result of an issue in the original message/ query... PORX_IN060260CA/ QUQI_MT120000CA/ controlActEvent/ subjectOf/ PORX_MT980020CA/ detectedIssueEvent/ code MedicationRequest. statusReason The FHIR profile provides an example value set of medicationRequest Status Reason Codes but the binding does not require use, so CeRX-> FHIR is lossless. It's recommended that the converter be aware of the values that CeRX requires for this field (medicationRequest Status Reason Codes) so that it can display the system and human readable description to allow for meaningful interpretation by patient & clinicians Given that the suggested field isn't a perfect semantic match, it's an inferred mapping when values are present, mapping FHIR-> CeRX is not recommended. CeRX is more strict about what values it accepts in the both mappable locations. The refusal to fill and the detected issue with the query are both mandated to use values from ActDetectedIssueCode.Therefore if any other values outside of that value set is used, it would result in a non-conformant CeRX message.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/moodCode MedicationRequest. Intent No concerns regarding the FHIR 1..1 cardinality. Both the CeRX act that the mood code is pulled from and the mood code element are both mandatory... meaning there has to be a non-null value present if the message is conformant to CeRX. When inferred from the Record Dispense Processing Request (PORX_IN020190CA) , the value of "RQO" can be pulled from medicationDispense/ inFullfillmentOf/ SubstanceAdministrationRequest/ mood code. As long as the FHIR Resource includes a value or "order" the value can be converted into the semantic equivalent in the CeRX value set (x_ActMoodDefEvnRqo): RQO. Converting proposal and plan is more difficult as EVN and DEF are not perfect equivalents for proposal and plan. More investigation on how DIS are utilizing EVN and DEF is recommended.
No 1:1 semantic match exists, possible options that were explored: CombinedMedicationRequest/ subjectOf6/ refusalToFill, OR CombinedMedicationRequest/statusCode ( suspended, aborted, absolete, nullified) , OR Component3/supplyRequest/statusCode MedicationRequest. doNotPerform No 1:1 semantic equivalent in CeRX exists for doNotPerform (boolean value). Presence of a Refusal to Fill indicator is the closest value to a boolean value of "true" for the doNotPerform FHIR element, however the CeRX act is described as a refusal to fill noted by the dispenser (past tense) so the uses are limited to prescriptions that have already attempted to be filled and refused. The recommendation at this time is to keep the element optional and work with the participating DIS to identify how/if they'd like to identify when a prescription should not be performed. If doNotPerform is populated with a boolean true in a natively generated FHIR resource, a RefusalToFill act could potentially be created with fixed attributes for classCode, moodCode, and statusCode (as the attributes are fixed in CeRX)…but no additional elements or associations could be drawn from the boolean alone. The refusal would have to have an associated author and location (refused by/at) or it would be considered non-conformant given the mandatory conformance strength those associated values require.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ derivedFrom/ sourceDispense MedicationRequest. reported It's not 100% literally lossless since there are conversion efforts required to turn completed-->true. Because the absence of the "completed" value is not a guarantee that the prescription was not reported (could be message configuration problem) it's not recommended that the opposite conversion be performed (e.g. lack of "completed"="false"). Reported is not a required field, so this recommendation shouldn't cause any issues in conformance. Similarly, presence of "true" in the FHIR element can reasonably converted into the creation of a derivedFrom/sourceDispense/statusCode fields in a generated CeRX message. derivedFrom/sourceDispense should only be present if confirmation exists, so a lack of a value or a value of "false" in the MedicationRequest.reported field should not create those fields in the generated CeRX message.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ directTarget/ COCT_MT220110CA/ medication/ player/ codeSystem MedicationRequest. 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 medicationRequest 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ directTarget/ COCT_MT220110CA/ medication/ player/ code MedicationRequest. 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ directTarget/ COCT_MT220110CA/ medication/ player/ name MedicationRequest. 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subject/ COCT_MT050203CA/ patient/ id MedicationRequest. 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. There are two differences from MedDispense that reduce concerns of converting FHIR-> CeRX. Patient has a required cardinality of 1..1 for both message types, it's present in the body of the message in addition to the query message (CeRX dispense message only notes patient in the query message). But.. the FHIR cardinality of the subject (patient) in MedicationRequest is also 1..1 (it's 0..1 in MedDispense). So as long as the FHIR resource is conformant to the cardinality, the missing patient is not a concern in this conversion.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ author/ time MedicationRequest. authoredOn In cases where the received CeRX message uses the correct format YYYYMMDD, only dashes will needed to be added to be FHIR conformant with the dateTime data type. In cases like the PEI message this is based off of, where hours and minutes are provided the converter will have to also add a timezone as well as the "T" and colons. Conversion between FHIR--> CeRX may require reformatting of the DateTime stamp to ensure conformance with the CeRX format TS.FULLDATE. If any hours, minutes, seconds, or time zone is present in the FHIR element they will need to be removed (in addition to the removal of dashes, colons, T). Additional consideration: FHIR does not require an authoredOn date (0..1 cardinality) but CeRX requires a value be present (1..1). If no authoredOn date is available in the FHIR resource, then it should be changed to "null" when converted to a CeRX message (allowed).
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ author/ COCT_MT090107CA/ assignedPerson/ id MedicationRequest. requester There are a few considerations implementors need to be aware of for CeRX-> FHIR conversion. CeRX allows for the ID of the prescription authoring provider to be null (value is required but can be null). Name of the authoring provider is mandated in CeRX and cannot be null. In the cases where no authoring provider ID is available, a contained resource with that providers name should be created because it wouldn't be possible to point to a full local resource that has a business id based on the provider ID. FHIR-> CeRX is tricky in the cases where the FHIR requester element is not present (0..1 cardinality in profile). This is because Author/Assigned Person/RepresentedPerson in CeRX is a mandatory element with a 1..1 cardinality. AssignedPerson.ID is allowed a null value, but at a minimum a name must be present for represented person.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ location/ COCT_MT240003CA/ serviceDeliveryLocation/ id OR PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ fulfillment1/ medicationDispense/ performer/ COCT_MT090107CA/ assignedPerson/ id OR PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ fulfillment1/ medicationDispense/ location/ COCT_MT240003CA/ serviceDeliveryLocation/ id MedicationRequest. performer There are a few considerations implementors need to be aware of for CeRX-> FHIR conversion. (outside of an OID--> ID aware conversion mentioned throughout the profiles). CeRX allows for the ID of the medication dispensing provider to be null (value is required but can be null). Name of the dispensing provider is mandated in CeRX and cannot be null. In the cases where no dispensing provider ID is available, a contained resource with that provider's name should be created because it wouldn't be possible to point to a full local resource that has a business id based on the provider ID.Performing provider is not a required element so even if a value is not found for some reason, it won't cause conformance issues with the FHIR profile. Some issues may arise in FHIR-> CeRX if there is no dispense performing organization or provider present in a FHIR MedicationRequest that has been dispensed against (since dispense location & performer are mandatory in CeRX). Same concerns around non-medical location identification are present if 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 intended to be mailed or 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ fulfillment1/ medicationDispense/ performer/ COCT_MT090107CA/ assignedPerson/ code MedicationRequest. performerType No additional considerations. Both the FHIR element and CeRX field have 0..1 cardinality. The FHIR profile does not require a specific value set be used. But the value set should be known by the converter in order to display a human-readable description. PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ fulfillment1/ medicationDispense/ performer/ COCT_MT090107CA/ assignedPerson/ code- While assigned person is mandatory - code (Provider Type) is 0..1 and required binding (meaning null values can used).
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ reason/ PORX_MT980050CA/ indications/ observationDiagnosis/ code/ codeSystem MedicationRequest. reasonCode. CodeableConcept.system No significant considerations converting FHIR-> CeRX. Both CeRX and FHIR allow multiple indications to be present (0..* cardinality). The converting system will need to be aware of the url that maps to the OID provided in the first codeSystem (CeRX has two potential codeSystem locations within indications- see details below). Because the FHIR profile only offers an example binding to Condition/ Problem/Diagnosis SNOMED Codes there should be no issue with DIS using a known code system (SNOMED and ICD10-CA). The code and display carry the same conversion considerations as other codeable concept fields (when converting to FHIR the code must be an established known code that is part of the converted code system) In the cases where no code or code system is present and the text is the only data available (like the 3rd indication), populating the FHIR CodeableConcept.text (not CodeableConcept.display) should be considered. Ensuring the system knows how to configure the indication CeRX fields based on the type of code provided in the native FHIR resource, will be critical. When the code system indicates SNOMED, it will need to populate the code system tied to ObservationDiagnosis Code. When the code system indicates ICD-10, then the code system for code will not be present, code will be fixed to "DX' and the ObservationDiagnosis value and value codeSystem will instead be populated with the ICD 10 code and OID respectively. Depending on the version of the intended CeRX message, the value set including ICD-10 CA that have become deprecated (DiagnosisValueSecondary- 2.16.840.1.113883.2.20.3.41 after MR02.05 release).
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ reason/ PORX_MT980050CA/ indications/ observationDiagnosis/ code/ code MedicationRequest. reasonCode. CodeableConcept.code Given that CeRX allows free-form text for the text field and has a maximum of 120 characters set, it's recommended that whenever possible the converter populate the FHIR Codeable Concept display field with text that maps to the provided code (rather than carry over whatever text is provided in the CeRX text field. One major consideration is that while the ObservationDiagnosis is considered optional the coding strength is CNE for the bound value sets (SNOMED and ICD-10-CA). Meaning that if another non-SNOMED, non-ICD-10-CA code system is used in the native FHIR resource, it cannot be carried over to the generated CeRX message. In these cases, the converter could populate the code with DX and then only populate the text field (value field is optional).
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ reason/ PORX_MT980050CA/ indications/ observationDiagnosis/ text MedicationRequest. reasonCode. CodeableConcept.display The code and display carry the same conversion considerations as other codeable concept fields (when converting to FHIR the code must be an established known code that is part of the converted code system) In the cases where no code or code system is present and the text is the only data available (like the 3rd indication), populating the FHIR CodeableConcept.text (not CodeableConcept.display) should be considered. One major consideration is that while the ObservationDiagnosis is considered optional the coding strength is CNE for the bound value sets (SNOMED and ICD-10-CA). Meaning that if another non-SNOMED, non-ICD-10-CA code system is used in the native FHIR resource, it cannot be carried over to the generated CeRX message. In these cases, the converter could populate the code with DX and then only populate the text field (value field is optional).
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ reason/ PORX_MT980050CA/ indications/ observationSymptom/ value/ codeSystem MedicationRequest. reasonCode. CodeableConcept.system No significant considerations converting FHIR-> CeRX. Both CeRX and FHIR allow multiple indications to be present (0..* cardinality). The converting system will need to be aware of the url that maps to the OID provided in the first codeSystem (CeRX has two potential codeSystem locations within indications- see details below). Because the FHIR profile only offers an example binding to Condition/ Problem/ Diagnosis SNOMED Codes there should be no issue with DIS using a known code system (SNOMED and ICD10-CA). The code and display carry the same conversion considerations as other codeable concept fields (when converting to FHIR the code must be an established known code that is part of the converted code system)In the cases where no code or code system is present and the text is the only data available (like the 3rd indication), populating the FHIR CodeableConcept.text (not CodeableConcept.display) should be considered. Because CeRX allows for three types of indications (ObservationDiagnosis, ObservationSymptom, and ObservationIndication) the converter will need to know how to classify the reason in the native FHIR resource that is being converted. Additionally, there are some issues that will arise if more than five reasons are present in the native FHIR resource. CeRX allows for a 1..5 cardinality for reasons. Because it has a required cardinality a null value can be used in the cases where no reason is present in the FHIR resource. Implementors will have to decide on a method for addressing which reasons get included in the CeRX message if more than five are present. While CeRX allows for reason prioritization, FHIR does not have this same field (meaning there isn't a clear way to prioritize what is included based on what is provided in the FHIR resource).
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ reason/ PORX_MT980050CA/ indications/ observationSymptom/ value MedicationRequest. reasonCode. CodeableConcept.code Given that CeRX allows free-form text for the text field and has a maximum of 120 characters set, it's recommended that whenever possible the converter populate the FHIR Codeable Concept display field with text that maps to the provided code (rather than carry over whatever text is provided in the CeRX text field. The code would need to be from one of the established CeRX value sets (SNOMED or ICD10-CA). In the case where ICD10-CA code is used to describe a symptom, "SYMPT" will populate the code field (no codeSystem needed) and the value field must be populated (mandatory) with the coded value.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ reason/ PORX_MT980050CA/ indications/ observationSymptom/ text MedicationRequest. reasonCode. CodeableConcept.display The code and display carry the same conversion considerations as other codeable concept fields (when converting to FHIR the code must be an established known code that is part of the converted code system). This consideration lead the CeRX text "Headache symptom" to be converted into a known ICD 10 display value: headache. In the cases where no code or code system is present and the text is the only data available (like the 3rd indication), populating the FHIR CodeableConcept.text (not CodeableConcept.display) should be considered. There are not the same constraints in matching the display text to the code in the value set (like FHIR does) but there is a maximum length of 120 characters that implementors must be aware of.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ reason/ PORX_MT980050CA/ indications/ otherIndication/ text MedicationRequest. reasonCode. CodeableConcept.text In the cases where no code or code system is present and the text is the only data available (like the 3rd indication), populating the FHIR CodeableConcept.text (not CodeableConcept.display) should be considered. Unlike the other two types of indications, OtherIndications has a 0..1 cardinality for code, meaning that if only the text is available from a FHIR resource that it could populate the OtherIndictions.text field with little concerns around conversion outside of the 120 character limit. However, if a code is provided and it's intended to map to OtherIndication, than the code is required to come from the Act Non Observation Indication Code value set (CWE binding strength).
No semantic mapping identified in CeRX MedicationRequest. groupIdentifier No semantic equivalent could be found for groupIdentifier in the test message. No semantic equivalent could be found for groupIdentifier in the test message.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ componentOf/ workingListEvent/ code MedicationRequest. courseOfTherapyType No considerations for CeRX->FHIR conversion, considering they rely on the same value sets. Cardinality is one consideration that makes FHIR->CeRX more difficult. CeRX mandates the ComponentOf/workingListEvent/code be populated (1..1 cardinality with no ability to provide null values if a value isn't found in the native FHIR resource). If no mappable value is present in the FHIR courseOfTherapyType (0..1 cardinality), WorkingListEvent is allowed to appear with a flavor of null to indicate that no information is known about the courseOfTherapy type, the converter will need to be configured to address this in those cases.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ coverage/ coverage/ id MedicationRequest. insurance Assuming the coverage resource is being managed locally at the DIS, as long as an ID is present it should be possible to transform into a FHIR resource or a contained FHIR resource. While coverage itself is optional (0..5) CeRX field, if it is present, additional fields can be expected: Coverage ID, Author, Payer Identifier, and underwriting org/payor name are all mandatory elements. The FHIR equivalent insurance element has a 0..* so no cardinality problems are expected from CeRX-> FHIR, though the same cannot be said for FHIR-> CeRX. There is a cardinality consideration that implementors must be aware of when converting insurance info in FHIR resources into coverage info in CeRX messages. CeRX allows up to 5 payors to be included as coverage, FHIR allows an infinite upper constraint. While it is an unlikely occurrence, if a patient has 6 or more insurance plans recorded in a FHIR resource, there could be problems converting more than 5 of the insurers/payors.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf3/ COCT_MT120600CA/ annotation/ author/ COCT_MT090107CA/ assignedPerson/ representedPerson/ name MedicationRequest. note.author There are a few considerations implementors need to be aware of for CeRX-> FHIR conversion. CeRX allows for the ID of the note authoring assigned person to be null (value is required but can be null). Name of the note authoring assigned person is mandatory in CeRX (can't be null). In the cases where no note authoring assigned person ID is available, a contained resource with that providers name should be created because it wouldn't be possible to point to a full local resource that has a business id based on the provider ID. Cardinality considerations also come into play for FHIR-> CeRX, since FHIR has a 0..1 cardinality for author- meaning there could be situations where an author is not provided when a note is available. CeRX considers Annotation Author Assigned Person a mandatory 1..1 element, meaning that if no author exists for a note in the native FHIR resource, it could cause issues in conformance when converted into a CeRX message.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf3/ COCT_MT120600CA/ annotation/ author/ time MedicationRequest. note.time 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 note date (cardinality of 0..1) but CeRX does (1..1) which could present a problem with conformance...primarily due to the conformance strength making an author/time mandatory (null values are not accepted).
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf3/ COCT_MT120600CA/ annotation/ text MedicationRequest. note.text No considerations, annotation text is mandatory with 1..1 cardinality in both FHIR and CeRX. No cardinality considerations, annotation text is mandatory with 1..1 cardinality in both FHIR and CeRX. But there is a consideration implementors need to be aware of with annotations overall. The FHIR profile allows an infinite number of notes (0..*) whereas CeRX only allows one note in the SubjectOf3/Annotation field (cardinality of 1..1) those the definitions in CeRX refer to plural comments and notes- this requires additional investigation. As well as awareness that CeRX may not accept notes that are not authored by the physician in charge, without first verifying the note with the responsible party (from the Annotation Design Comments: Public Health requires all clinical notes to be 'verified' by a responsible party if not created by physician in charge. This model conveys the correct semantics, but is inconsistent with other uses of "author" participation in POIZ models. Any changes here will have to be reconciled with other projects using this same cmet.)
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ component2/ sequenceNumber MedicationRequest. dosageInstruction. sequence No considerations, sequence line is mandatory with 1..1 cardinality in CeRX so it will always be present when dosageInstructions are available. If dosageLine is used then sequenceNumber is a mandatory element (1..1 cardinality) because it helps distinguish between multiple dosageLines that occur at the component2 level (allows for 0..20 cardinality so up to 20 dosageLines possible). The FHIR profile does not require a dosage line, but one may need to be generated by the converter to ensure conformance to the CeRX spec if one is not provided in the native FHIR resource.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ text MedicationRequest. dosageInstruction.text No considerations for CeRX-> FHIR. If dosageInstructions are available, CeRX will always populate them (mandatory with 1..1 cardinality). If dosageInstruction in the FHIR profile is used, the text also has a 1..1 cardinality. One concern with dosageInstructions in general: the FHIR Profile allows zero to infinite dosage instructions (0..*) whereas CeRX format requires that the shell that holds dosage instructions (Component 1) is populated at least once and at a maximum of ten times (1..10 mandatory cardinality). If no dosage instruction is available or if more than 10 dosage instructions are present, there could be conformance issues in the conversion to a CeRX message.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ effectiveTime MedicationRequest. dosageInstruction.timing. repeat.boundsPeriod.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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ effectiveTime MedicationRequest. dosageInstruction.timing. repeat.boundsPeriod.end See above. If the upper-bound date is not specified in the CeRX message then the Prescription date is open-ended or will default to a stale-date based on regulations. See above
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ approachSiteCode MedicationRequest. dosageInstruction.site Some cardinality considerations. CeRX allows up to 5 sites to be provided (0..5 cardinality), whereas the FHIR profile only allows one site. Both CeRX and FHIR utilize codes from the HumanSubstanceAdministrationSite (bodySite) value set. The converting system will need to be aware of any DIS that do not use codes from the HumanSubstanceAdministrationSite (bodySite) since no OID is present in the CeRX message to distinguish the code system being used. The CeRX conformance of optional for this value set means that only DIS that declare their decision to use the value set in their conformance statement. Any elements received by DIS that have not declared their conformance must be ignored. The code and display carry the same conversion considerations as other codeable concept fields (when converting to FHIR the code must be an established known code that is part of the converted code system). Given the optional CeRX conformance, there are additional considerations that need to be made on how a FHIR resource could also generate a CeRX conformance statement that indicated the declaration of use of optional value sets.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ routeCode MedicationRequest. dosageInstruction.route If other jurisdictions are using GCRT codes (instead of the v3 RouteOfAdministration 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ code MedicationRequest. dosageInstruction. doseAndRate.type It may be possible to create a default value of ordered when generating a MedicationRequest FHIR resource from a CeRX PORX_IN060260CA message. However it would likely need to be performed based on the message type and not the originally recommended field. CeRX requires a default value of "Drug" whenever the type of dosage is not a SNOMED code. This mapping likely will not remain in the next iteration given the additional comments we've found in the test message indicating how the field is being used in CeRX.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ component2/ dosageLine/ doseQuantity MedicationRequest. dosageInstruction. doseAndRate. doseRange The converting tool will need to decipher between when a CeRX value best fits the Range or SimpleQuantity data type. A design decision must be made for how the converter will handle cases when a range is not performed (when the DIS supplies the same value at both high and low ends)...i.e. should it remain a range data type or be considered a SimpleQuantity type (shown in the example). 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ component2/ dosageLine/ doseQuantity MedicationRequest. dosageInstruction. doseAndRate. doseRange The example message from PEI allowed for simple conversion of doseQuantity broken up into two FHIR sub-elements: doseRange.value and doseRange.unit. Units of measure (ex: mg) are the same in both CeRX and in FHIR.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ component2/ dosageLine/ rateQuantity MedicationRequest. dosageInstruction. doseAndRate.rateRatio No transformation performed due to no value for rateQuantity being present in the test message. See note regarding scenarios of use (intravenous administration and other routes involving flow rates). No transformation performed due to no value for rateQuantity being present in the test message. See note regarding scenarios of use (intravenous administration and other routes involving flow rates).
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ maxDoseQuantity/ numeratorValue MedicationRequest. dosageInstruction. maxDosePerPeriod. numeratorValue CeRX-> FHIR is anticipated to be a simple conversion since both the CeRX maxDoseQuantity and the FHIR maxDosePeriod support numerator (dose) and denominator (time period) values. FHIR->CeRX is also anticipated to be a simple conversion since both the CeRX maxDoseQuantity and the FHIR maxDosePeriod support numerator (dose) and denominator (time period) values.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ maxDoseQuantity/ numeratorUnit MedicationRequest. dosageInstruction. maxDosePerPeriod. numeratorUnit Some effort is expected to parse out the individual values/units to ensure they are converted to the FHIR sub-elements accordingly. The same effort is expected to parse out the individual values/units to ensure they are converted to the FHIR sub-elements accordingly.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ maxDoseQuantity/ denominatorValue MedicationRequest. dosageInstruction .maxDosePerPeriod. denominatorValue See above See above
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component1/ PORX_MT980040CA/ dosageInstruction/ maxDoseQuantity/ denominatorUnit MedicationRequest. dosageInstruction. maxDosePerPeriod. denominatorUnit See above See above
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ fulfillment3/ supplyEventFirstSummary/ quantity MedicationRequest. dispenseRequest. initialFill.quantity.value CeRX -> FHIR is expected to be a simple conversion than FHIR-> CeRX because the FHIR cardinality is loose (allowing 0..1) whereas CeRX cardinality is 1..1 if a prescription has been filled at least once. FHIR->CeRX is more complicated because CeRX mandates a 1..1 cardinality for supplyEventFirstSummary, meaning that a quantity value must be present if an initial fill as occurred. Implementors should be aware that there may be conformance issues if the MedicationRequest FHIR resource is tied to a MedicationDispense resource but the initialFill element is not populated. If FHIR->CeRX is pursued, this is a case for the Gateway team to consider for advanced use cases (identification of values across multiple linked/semi-linked resources).
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ fulfillment3/ supplyEventFirstSummary/ quantity MedicationRequest. dispenseRequest. initialFill.quantity.unit Data types are not expected to be changed, simply broken into sub-elements of value and unit in the FHIR resource. Data types are not expected to be changed, simply broken into the value and unit for supplyEventFirstSummary/quantity.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ component/ supplyRequestItem/ component2/ initialSupplyRequest/ expectedUseTime MedicationRequest. dispenseRequest. initialFill.duration.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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ component/ supplyRequestItem/ component2/ initialSupplyRequest/ expectedUseTime MedicationRequest. dispenseRequest. initialFill.duration.unit See above See above
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ component/ supplyRequestItem/ component1/ subsequentSupplyRequest/ effectiveTime MedicationRequest. dispenseRequest. dispenseInterval.value Exact transformation based on what was found in the test message. Compiling other test messages to determine similarities in expressing effectiveTime is recommended given that the test message is believed to be varied in the CeRX specification of effectiveTime being captured under the IVL.WIDTH <TS.FULLDATE> data type and both test messages we reviewed only included the width value and unit: number of days (no datestamp found). If no time stamp is required for CeRX and requirements mimic what was found anecdotally in test data, then conversion from FHIR-> CeRX should be relatively simple. Both only allow for the UCUM representation of times (days, weeks, etc) but it appears the use of days is more frequent given clinical relevancy.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ component/ supplyRequestItem/ component1/ subsequentSupplyRequest/ effectiveTime MedicationRequest. dispenseRequest. dispenseInterval.unit See above FHIR data type constraints on Duration requires that if there is a value a code is required and that code must be an expression of time. Given the CeRX element is defined as the number of days that each standard fill is expected to last, it is not expected to be a problem- but implementors should be aware none-the-less.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ effectiveTime MedicationRequest. dispenseRequest. validityPeriod.start No cardinality considerations expected (both 0..1). The CeRX message will only ever send 8 characters for TS.FULLDATE type fields, so the considerations of partially complete hours/minutes/seconds/timezone that existed in other time based conversions are not found here. Dashes will need to be added to comply with the FHIR dateTime data type. CeRX IVL TS.FULLDATE only allows 8 characters (YYYYMMDD). If hours, minutes, seconds, or timezone are included in the FHIR resource, they will need to be removed upon conversion to remain conformant with the CeRX specification.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ effectiveTime MedicationRequest. dispenseRequest. validityPeriod.end See above. If the upper-bound date is not specified in the CeRX message then the Prescription date is open-ended or will default to a stale-date based on regulations. See above.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ component/ supplyRequestItem/ component1/ subsequentSupplyRequest/ repeatNumber MedicationRequest. dispenseRequest. numberOfRepeatsAllowed Both CeRX and FHIR profile has number of repeats as 0..1 cardinality so no concerns converting from CeRX->FHIR given the simplicity of the integer data type. Unlikely scenario, but because CeRX only allows for a positive integer with maximum length of three characters…If there the FHIR resource indicated more than 1000 fills it would be non-conformant. Very unlikely but structurally possible. Both FHIR and CeRX have a 0..1 cardinality for this element so minimal concerns converting FHIR-> CeRX.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ component/ supplyRequestItem/ component1/ subsequentSupplyRequest/ quantity/ value MedicationRequest. dispenseRequest. quantity.value CeRX-> FHIR is anticipated to be a simple conversion since both the CeRX SubsequentSupplyRequest/Quantity and the FHIR dispenseRequest.quantity use value and units to describe quantity of the medication to be dispensed to the patient for each normal fill following the first fill, no cardinality concerns (both use 0..1). FHIR-> CeRX is anticipated to be a simple conversion since both the CeRX SubsequentSupplyRequest/Quantity and the FHIR dispenseRequest.quantity use value and units to describe quantity of the medication to be dispensed to the patient for each normal fill following the first fill, no cardinality concerns (both use 0..1).
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ component/ supplyRequestItem/ component1/ subsequentSupplyRequest/ quantity/ unit MedicationRequest. dispenseRequest. quantity.unit Some effort is expected to parse out the individual values/units to ensure they are converted to the FHIR sub-elements accordingly. Some effort is expected to parse out the individual values/units to ensure they are converted to the FHIR sub-elements accordingly.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ component/ supplyRequestItem/ component1/ subsequentSupplyRequest/ expectedUseTime MedicationRequest. dispenseRequest. expectedSupplyDuration. value Exact transformation based on what was found in the test message. Compiling other test messages to determine similarities in expressing effectiveTime is recommended given that the test message is believed to be varied in the CeRX specification of effectiveTime being captured under the IVL.WIDTH <TS.FULLDATE> data type and both test messages we reviewed only included the width value and unit: number of days (no datestamp found). If no time stamp is required for CeRX and requirements mimic what was found anecdotally in test data, then conversion from FHIR-> CeRX should be relatively simple. Both only allow for the UCUM representation of times (days, weeks, etc) but it appears the use of days is more frequent given clinical relevancy.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ component/ supplyRequestItem/ component1/ subsequentSupplyRequest/ expectedUseTime MedicationRequest. dispenseRequest. expectedSupplyDuration. code See above FHIR data type constraints on Duration requires that if there is a value a code is required and that code must be an expression of time. Given the CeRX element is defined as the number of days that each standard fill is expected to last, it is not expected to be a problem- but implementors should be aware none-the-less.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ component3/ supplyRequest/ location/ COCT_MT240003CA/ serviceDeliveryLocation/ id MedicationRequest. dispenseRequest. performer CeRX->FHIR is simple if 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 organizations. Some issues may arise in FHIR-> CeRX if the organization 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf5/ substitutionPermission/ code OR PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf5/ substitutionPermission/ negationInd MedicationRequest. substitution.allowed There are some transformation considerations for CeRX -> FHIR. The substitution.allowed FHIR element uses a boolean (true/false) data type. CeRX alternatively communicates the presence of substitution permission with a coded value (ex: G) and lack of permission with a boolean value of false in the negationIndicator attribute. If the coded value is found the FHIR value can be transformed to true. If the false value is found under negationIndicator it can be carried over exactly. Because both the CeRX values for substitution permission are locked into attributes that only support one value each (G for substitution allowed, false for substitution not allowed) the transformation from the boolean true/false value in FHIR is less complicated and is anticipated to be bi-directional in practice.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf5/ substitutionPermission/ reasonCode OR PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ fulfillment1/ medicationDispense/ component2/ substitutionMade/ reasonCode MedicationRequest. substitution.reason The comments in the CeRX test message point to "ALGAT" being pulled from SubstanceAdminSubstitutionNotAllowedReason value set that is part of the v3 Act Reason Code System…however, the code "ALGAT" could not be found. The value set binding is preferred meaning a source system that does not send codes from that value set could send other codes if necessary and remain conformant. Alternatively, the semantically equivalent "ALGINT" could be used/swapped in by the converter. Given the FHIR definition of this element, there are two cases in which a substitution reason code is recorded. 1) Reason substitution is not allowed, and 2) reason substitution occurred. If the FHIR resource is recording why the substitution is not allowed it will need to supply a code from the Substance Admin Substitution Not Allowed Reason (ActReason) value set to be conformant with the CeRX standard. Because the CeRX field in the first case has a 1..1 cardinality, some value must be provided if the substitution is recorded as not allowed...however, the conformance strength allows that value to be null if absolutely necessary. In the case where substitution.reason is referring to a dispense that has already occurred and had a reason the substitution was made, the FHIR value will have to match a value from the Substance Admin Substitution Reason (ActReason) value set to be conformant to the CeRX standard (value set has a CNE binding). If the value in the FHIR resource is not supported by that code set than it risks non-conformance to the CeRX spec, one solution to this particular case is to not provide any code as the CeRX value has a 0..1 cardinality, other solutions should be explored by the design & implementation teams.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ predecessor/ priorCombinedMedicationRequest/ id MedicationRequest. priorPrescription 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. 1) 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. 2) 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf1/ PORX_MT980030CA/ detectedIssueEvent/ statusCode MedicationRequest. 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 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf1/ PORX_MT980030CA/ detectedIssueEvent/ text MedicationRequest. 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf1/ PORX_MT980030CA/ detectedIssueEvent/ mitigatedBy/ detectedIssueManagement/ code MedicationRequest. 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 Act Detected Issue Management Code 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf1/ PORX_MT980030CA/ detectedIssueEvent/ mitigatedBy/ detectedIssueManagement/ author/ time MedicationRequest. 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_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf1/ PORX_MT980030CA/ detectedIssueEvent/ mitigatedBy/ detectedIssueManagement/ author/ assignedPerson/ id MedicationRequest. 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.
PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ subjectOf4/ controlActEvent OR PORX_IN060260CA/ PORX_MT060340CA/ combinedMedicationRequest/ predecessor/ priorCombinedMedicationRequest/ id MedicationRequest. eventHistory eventHistory is less of a concern transforming CeRX -> FHIR as it is transforming FHIR-> CeRX. No cardinality concerns. The required 1..1 fields that are part of the provenance resource (target resource, recorded date, agent involved) are all mandated elements in CeRx. One consideration in converting from FHIR-> CeRX is the upper bounds (0..20) on the cardinality for CeRX subjectof4 (the act relationship that the individual controlActEvent history is tied to). The FHIR profile allows an infinite number of event history, so implementors will need to agree on the design/approach to scenarios where more than 20 eventHistory provenance resources are noted in the FHIR resource.