240 likes | 482 Views
ICH Ballot Reconciliation. November 24, 2009. Agenda. Confirm reconciliation items: Functional RMIMs, schemas and MIFs for Part 2 Medication dosing and units of measurement Causality Assessments Use of codes and identifiers (OIDs) Wrappers, Attachments and Acknowledgements.
E N D
ICH Ballot Reconciliation November 24, 2009
Agenda • Confirm reconciliation items: • Functional RMIMs, schemas and MIFs for Part 2 • Medication dosing and units of measurement • Causality Assessments • Use of codes and identifiers (OIDs) • Wrappers, Attachments and Acknowledgements
Functional RMIMs, schemas and MIFs for Part 2 • Relates to ICH comments: • 2-1, 2-2, 2-6, 2-7, 2-10, 2-11, and 2-12 • Need clarification for (ICH #2-11): “Some of the schema files contain elements that have been defined with no namespace. All the elements need to live in the HL7 namespace”. • Need clarification for (ICH #2-12): “The schema files do not validate against the W3 "XML schema" schema” • Relates to EU parsing errors.
Functional RMIMs, schemas and MIFs for Part 2 • All items have been referred to Woody Beeler and John Quinn for resolution under JI agreement • No current status on final publication environment and need to decide how to move forward to produce material for ICH alpha testing and DIS ballot
Medication dosing and units of measurement • Relates to ICH comments: • 2-18, 2-19, and 2-22 • St. Louis discussions: • Explain in the IG the differences when coding B.1.2.2b = Explain when to use PQ (UCUM units) and CE (for ICH trimester and decade) • Gunther suggested we use OBS code for: "gestation period in trimesters", "gestation period in weeks", "gestation period in months", "gestation period in days"
Medication dosing and units of measurement • St. Louis discussions: • B.1.10.7.r.d: Explain on the telecom 11/24 what PINF means and also include example in the IG how to populate this field • ICH 2-22: Start, stop and duration • Confirmed that requirement is to capture any one or two of each item. It is not expected that all three would be in the same message instance
Medication dosing and units of measurement • Therefore: • Start date = effectiveTime/low@value • End date = effectiveTime/high@value • Duration = effectiveTime[@xsi:type="IVL_TS"]/width@value *Note that the email exchange 10/12/09 with Tom De Jong provided four examples for duration. These can be incorporated into the guideline
Medication dosing and units of measurement • Cyclical, Total and As Necessary: • Resolution is to adopt medication dosing recommendations by Pharmacy as expressed in the Netherlands guide and Lloyd’s response to capturing the concept of cyclical
Proposal for Total Dose (per T. De Jong) Dear Pharmacites, Recently, in an e-mail exchange that was initiated because of the ICSR ballot, we discussed two ways of making a statement about the ‘ reported dose’ of a certain medication. This is what we would use in Medication Statements (used whenever somebody makes a statement about medication use without referring to a prescription or dispense). The two variants we discussed were Dose per administration (the usual interpretation of doseQuantity) A variant of this was discussed, where the actual administration cycle is unknown. Total dose (when all that is known is a usage interval) I would like to add a third variant, and check with you if my interpretation is correct: Daily dose represented as: <effectiveTime xsi:type="PIVL_TS"> <!-- basically, this says: each day during the day --> <phase> <width value="1" unit="d"/> </phase> <period value="1" unit="d"/></effectiveTime><doseQuantity> <center value="[daily dose value]" unit="[daily dose unit]"/></doseQuantity> If we agree about this representation, I will add this to a proposed update of the RIM definition for doseQuantity
Cyclical • Nick’s example: "20 mg/kg given on a cyclical basis” • Lloyd’s response: “If you want to convey the amount given "per dose" without conveying the frequency of the dosing, use doseQuantity and put a PIVL in effectiveTime with a frequency of UNK”
As Necessary • Per Netherlands guide: “captured in a precondition/observationEventCriterion. The code attribute of the observationEventCriterion will not have any value. In stead a nullFlavor is used with the value ‘NA’ (not available) *Lise confirmed with Tom that the example for the null flavor is a typo. NA=not applicable Use NAV
Causality Assessments • Relates to ICH comment 2-21 • FDA is proposing modeling changes to address this change; however we have not discussed the modeling changes on HL7 calls yet
Causality Assessments • Mead generated test files for Jason to test modeling changes in the XFORM • Jason confirmed the need to retain the id references for AE and product use • Need to confirm current status of RIM database testing (Gunther) • Upon confirmation that proposals work, will bring forward to the HL7 committee for discussion and voting
Use of Codes and Identifiers • Lise followed up with Mead on the following questions raised during meetings and teleconferences: • Identifiers • ISO country codes • Identifiers: • Needed to confirm how to handle multiple patient identifiers: The current model allows a person to have mulitple IDs, in the IdentifiedEntity role. Role code can be used to indicate "specialist medical record number", "GP MRN" and so on. Suggest we create role codes (e.g., "MRN“) to code these
Use of Codes and OIDs • Unknown OIDs: • Concern was expressed about how to deal with identifiers when the OID information is unknown. There have been discussions about this in HL7 and a proposal is to: • Use a null flavor (=UNK?), leave Id root out, and provide a value for Id extension (e.g., this is where the MRN would be captured) • Id=extension 11111 null flavor = UNK
Use of Codes and OIDs • ISO Country Codes: • Mead went through the E2B, and it has 5 places where country is sited: • country of the reporter • county for a study (or is it country assigning study id? Yes), • country where the reaction occurred • country where the drug was obtained • country authorizing marketing and distribution of the drug.
Use of Codes and OIDs • A place entity is used to capture the place of occurrence (with place.code for country code) for a, b, c, and e. • For d, we are constrained to look like the CMET that is used in clinical statement so we have stated that country be included in the address. • However, the address part type is a string. This could be the country text name, its text abbreviation, or a numeric (or alphanumeric) code. Note, we could, and maybe should add a located entity for the performer of acts in our "clinical statement like" model. That would raise one more item to work out with PA as we try to adjust the assigned entity CMET • Also, as a footnote, for (b), the country of the study, our sample message currently maps this to the assigning authority text in the ID. The model does not insist on this – this refers to the CMET and is no longer valid b/c
Wrappers • Relates to ICH comments 2-8 and 2-9 • 2-8: Issue related to manually editing the batch wrapper to include the HL7 interaction IDs for the payload • 2-9: Issue related to reference to transaction wrapper material that appears to have been deprecated
Wrappers • 2-8: Not sure about ballot reconciliation comment: Not persuasive or should we just add the interaction IDs to the message instance example in Part 2? The issue is that some HL7 messages support multiple interaction IDs and it is expected that implementers would customize to suit their needs
Wrappers • 2-9: Per Woody Beeler, the material is not deprecated until a formal ballot is reconciled to remove the material. The issue is that MnM previously discussed this material but has not maintained the process to move forward with deprecation. Therefore the material is still considered normative. We should include a footnote in ICSR and request that MnM update the description for the FDIS
Attachments and Acknowledgements • Relates to ICH comments 2-23 and 2-24 • 2-23: Add acknowledgement information to Part 2: Persuasive comment • 2-24: Believe this comment needs to be addressed in ICH’s implementation guide. HL7 has provided two alternatives as part of the ICSR message specification which is its area of purview: Non persuasive comment