Implementation Guide - Questions for November 2007

Transcription

1 Implementation Guide - Questions for November Local & DIS Profile 1. The local system must support adding the following records to the Patient profile: Immunizations; Observations; Medical Conditions; Question : The pharmacist don t make immunization, observation or medication conditions currently. Will we need to develop that? Yes, it is a requirement to support the storage of these records locally. Please note that in the case of immunizations, if the pharmacist dispenses the immunization drug, than it is recorded as a dispense. However, if a patient provides a history including an immunization, then it is to be recorded as an immunization Prescribing 9 The local system must make electronic prescription available for use by the user. Question : What is an electronic prescription? Electronic prescriptions are part of the CeRx messaging; there is an entire section of messages to do with e-prescribing. These messages support the ability of prescribers (doctors) to enter prescriptions electronically from their offices directly to the DIS, where the pharmacists can download them. The prescription remains on the DIS and on the patient's profile (unless intentionally removed). In PEI, these electronic prescriptions must be supported with a print-off of the presciption and the prescriber's signature, or any of the other valid presciption methods (phone call to pharmacist, fax, etc) The local system must support storing a prescription for a future fill without transmitting it to the DIS. Question : If we understand, the future rx will never be transmitted to the DIS. Is it true? No, with each "first fill" dispense, the add prescription (or create Rx Order) message must be sent to the DIS Dispensing 5 The local system must send the local dispense identifier to the DIS. Question: What is the local dispense identifier? The local dispense identifier is the unique identifier you use within your software to identify dispenses *When using the determine coverage function, the Pharmacist and/or local system must provide the following to determine the eligibility: Question: Could you send more information about coverage function? This is in reference to PEI Provincial Drug Programs. Please see section 6.11 of Volumes 2 and 3 of PEI's Implemenation Guide for more information. 06

2 33 *The local system must support submitting multiple invoices to separate Provincial Drug Programs as part of a single invoice to account for cases where a Patient has multiple applicable coverages. Question: Do you know if we could have a coordination of benefice between 2 provincial drug plan for the same patient? This If yes, statement currently, means is it that work multiple like invoices that? (with would PHiP) be required for each of the Provincial Drug Programs with the appropriate previously paid supplied (each plan would see all the patient's coverage with all of the previously paid amounts). Here's how our developer explains it: Basically the flow is along these lines: Write despense Previously paid :=0.00 While has non-applied coverage records and previously paid < total amount a. Prepare Claim b. Send claim (with total of previously paid) c. Previously paid := previously paid + plan pays amount Client pays := toatl amount - previously paid So, for our case, we want to look just like any other program The local system must support transmission of a clinical professional service. Question : Do you have more information about what kind of clinical professional service we must support? There is vocabulary associated with the professional services - please find this in the CeRx Materials under Technical Artifacts in the Vocabulary Status spreadsheet (ActProfessionalServiceCode). PEI is using the Canadian Classification of Intervensions codeset for the ActProfessionalServiceCode The local system must transmit the reason text in all CeRx message interactions with the DIS. Question: In what situation that this applies?. Where these reason must be stored? Locally? The reason is also a codeset; your system must support adding a reason for accessing a patient's profile, but the pharmacist is not required to enter a reason. For instance, if a pharmacist is conducting a dispense, then the dispense record can act as the reason that the profile was viewed. However, in other situations (patient inquiry or patient counselling, for example), the pharmacist may wish to record a reason for accessing the profile. The reason code must be stored both locally and on the DIS if entered The local system must provide a report/view of these reasons which may be queried by user and patient. Question: Could we have some samples of xml transaction? This refers to the local systems being able to print a report or on-screen view of the reason that was entered for a particular profile access. The presumption here is that these reasons need to be stored locally. 10

3 2 *The local system must permit the Patient and/or User to supply a keyword for profile access. Question : How the patient could enter the password? For that, we need to install a keyboard in the front of the laboratory. Is it true? you can optionally have a numerical PINpad installed at your stores (as all passwords are numerical only) for the patient to enter their password, however this is not required. The patient can supply the password verbally to the pharmacist; the pharmacist has the right to refuse service if the patient does not supply the password. However, if the patient does supply the password, the pharmacist can not store this password; it must be given by the patient each time. 11 What do we do if the network is not up? Your system must queue transactions to be sent to the DIS when the connection is re-established. Please see section of Volume 3 of the PEI Implementation Guide for more information. 12 Could you shed some lights about the role enforcement from the DIS if any? By that we mean do you enforce the provider role on the message level meaning certain message can t be processed if they are created by an invalid provider considering the message requirements (ex: Pharmacy tech can t do a pickup message) We don't enforce those types of rules at all; the only time you will have a rejection from the DIS is if there is a technical issue with the message. 13 How do you test messages that are not in the supported workflow of TestHarness? For example the DrugDocument message (POME_IN010010CA) is supported in an incomplete SubWorkFlow. These will not be tested as part of conformance how ever these can be tested via the test harness on the PEI DOH test environment. Responses will be generated by the DIS server. As an alternative the venders are welcome to modify or generate their own workflows as needed.

4 The DrugDocument response message (POME_IN010020CA) the message content can be a PDF, HTML, HL7 CDA document or a reference to where the medication document can be accessed on the network via HTTP or FTP. Do you favor a format in the actual Production DIS or are all the formated supported? HTML In the Add Prescription message (PORX_IN010380CA) can we send one medication per message even if a prescription contains more than one medication? Most pharmacy system treat each medication independently even if they are all related from the original prescription. Yes - one medication per message is what we require How can you confirm that a specific prescription exists on the DIS? There seem to be no Query Prescription. Do we use the Dispense to test the existence of a prescription? We understand that since the TestHarness initial database is empty its WorkFlow require an AddPrescription all the time. But in a real case scenario this won t do. There is a set of query prescription messages (query medical profile, query prescription summary, query prescription detail) all contain data related to what prescriptions are present on the dis for the given patient. There are several ways that prescriptions can be added to the test harness initial data. You can add them by modifying the testdata.xml file by hand or the preferred way by other venders is to send in the initial records via the messaging then save the testdata.xml file via the test data tab and from that point on use the new test data file when they wish to have preloaded data in the test harness. Furthermore, you are required to do an Add Prescription message if it doesn t already exist on the DIS What are the supported allergy code for the REPC_IN000012CA message? FBD code and SNOMED are supported FDB HIC is what is being supported for allergies in PEI We need to create your own OIDs? Can we get a reference in the PEI documentation about that? The PEI OIDs are listed on our website ( under the Other Reference Material and Information Section. Examples of OIDs you would want to register yourself are: Local dispense ID, Query IDs, Message IDs, Control Act IDs, etc. You can register an OID for Emergis, then subdivide this OID for each entity submitting messages, and then further subdivide for items within the message (the ID s listed above). The URL for registering OIDs is You'll find a link at the top of the page called "Click to Obtain or Register an OID".

5 PORX_IN010450CA, PORX_IN010460CA, PORX_IN010520CA, PORX_IN010530CA, PORX_IN010540CA, PORX_IN010560CA, PORX_IN010570CA, PORX_IN010580CA, PORX_IN010630CA, PORX_IN010640CA PORX_IN010840CA, PORX_IN010850CA, PORX_IN010860CA, PORX_IN060490CA, PORX_IN060500CA, QUCR_IN200102, QUCR_IN210102, QUCR_IN800102, QUCR_IN Samples of all messages supported in PEI can be found within our examples.zip file (found with the Implementation Guide on our website, What is the list of supported message within the test server of the PEI DIS? PEI's DIS Test server environment supports the messages listed in the Volume 4 Section 2.1 Errata (found under the Implementation Guide link on our website at What is the difference between: Drug Quantity and Dispense Quantity? In the Necst invoice message - there is a dispense qty in the dispensing information and a drug quantity in the drug cost section - so what is the difference? No difference, they should have the same value. Technically speaking, I guess it was designed this way because the quantity in the payment section (invoiceelementdetail) is used for costing and the quantity in the dispensing information (supplyevent1) is used for clinical purposes. As for the other question about NeCST id's, the document explaining this can be found at

6 22 CommonClinicalObservationType For example there are 2 codes for height and weight (measured and stated), can we just pick one or would we need to accommodate both. Also are these measurements using metric or imperial values (I'm assuming metric). We would only send for 1 code and when we update our local system we could map either code to the one code we are using locally. I can see the difference between the 2, but really at the pharmacy level it isn't important to differentiate. They don t need to support sending both measured and stated, but what approach will they take for queries when they draw down the profile and the observation type is different from what they support? Again, as far as imperial and metric, if they want their software to do the calculation and convert what they receive into one standard unit (i.e. cm), that would not be a problem from the point of view of compliance with the standard. I also brought it to our pharmacist - her comments: A measured observation would have more validity than a stated since a healthcare provider determined the value of the observation rather than the patient stating it. Glucose Bld Test STR Auto-mCnc :This value would be obtained using a blood glucose meter which most diabetics use because it's a more accurate value. Glucose Bld Manual Strip-mCnc: This value would be from a visual strip. No meter involved the strip changes color and you match the color to a blood glucose value - not very accurate. So, based on this, I think we would recommend that they support entering both measured and stated in their software, however at the very minimum, they need to support displaying what other pharmacies have entered Also there are 2 for glucose, same question for this one could we just pick one? Are the actual measurement values the same for each glucose test code? Also would the DIS be expecting a single measurement for this i.e. 7 mmol/l or could we send 3 measurements (i.e. before meals, after a meal, bedtime). I don't know whether there is any clinical difference between the two types "Glucose Bld Test STR Auto-mCnc" and "Glucose Bld Manual StripmCnc" - I'm assuming they are different. (see our pharmacists comments above) The same measurement is used for each - mmol/l. Again - no problem sending 3 of these for different times of the measurements. I understand that Blood Pressure has sub-observations (diastolic, systolic, pulse). Do we send a value in the Observation Value or just the sub-observation value? Also I noticed (if I'm reading it correctly) that there are only 2 repetitions for sub-observation in the REPC_IN000051CA interaction. So can we only send 2 values?

7 When sending blood pressure, don't send a value in the observation value and do send subobservations as follows: <commonobservationevent> <code code=" "/> <!-- blood pressure --> <statuscode code="completed"/> <!-- The dateand time at which the observation applies. --> <effectivetime value=" "/> <!-- don't send value here for blood pressure, but send two subobservations --> <!-- <value unit="cm" value="175"/> --> <subject> <patient> <id root=" " extension=" "/> <telecom use="h" value="tel: "/> <patientperson> <!-- The name by which the patient is known and which apply to a particular clinical action that has been reported or recorded --> <name use="l"> <given>patti</given> <family>patient</family> </name> <!-- Indicates the gender (sex) of the patient. --> <administrativegendercode code="f"/> <birthtime value=" "/> </patientperson> </patient> </subject>

8 25 <! Represents one of the two components (systolic and diastolic) of a blood pressure measurement Allows both parts to be captured as part of a single measurement. --> <component> <subobservationevent> <!-- Distinguishes between the two type of blood measurement. This can either be code for SYSTOLIC or DYSTOLIC - CommonClinicalObservationType --> <code code=" "/> <!-- systolic bp --> <statuscode code="completed"/> <!-- blood pressure measurement --> <value unit="mm[hg]" value="60.6"/> </subobservationevent> </component> <component> <subobservationevent> <!-- Distinguishes between the two type of blood measurement. This can either be code for SYSTOLIC or DYSTOLIC - CommonClinicalObservationType --> <code code=" "/> <!-- DYSTOLIC bp --> <statuscode code="completed"/> <!-- blood pressure measurement --> <value unit="mm[hg]" value="157.6"/> </subobservationevent> </component> </commonobservationevent> How is respiratory rate measured? Respiratory rate is measured with units 1/min. Here is some information about the relationships of the observation types and the units for each: Here's a breakdown of the different LOINC codes accepted for commonobservationevent.code and the units that might apply for each one - or at least what we've done in our Portal - there's nothing that would prevent you from expanding on this - i.e. sending metre as well - we simply didn't want to clutter up the UI.

9 body height - measured (cm, [in_i]) body height - stated (cm, [in_i]) body weight - measured (kg, [lb_av]) body weight - stated (kg, [lb_av]) heart beat (1/min) blood pressure (don't send a value element, instead send two component.subobservationevent elements with value element with unit attribute = mm[hg]) intravascular systolic (mm[hg]) intravascular diastolic (mm[hg]) body temperature (Cel, [deg]) these were not in the vocab spreadsheet initially and we had to make a special request to get them added - you may not see them looking at the x_basicunitsofmeasure vocabulary in the Sept 2006 release of the CeRx standard, but I checked and they are in the vocab spreadsheet that was put out in July - I noticed that they are using [deg] - they told us the vocab would be degf glucose (mmol/l) glucose (mmol/l) respiratory rate (1/min) I was wondering how PEI will be sending the response for the Query Patient Observation Request REPC_IN000054CA interaction message? Assuming that we request the query for all Observations (we don't query on a specific LOINC code). Will PEI be combining any of the information for the Observations? For example will Blood Pressure be returned with both the Diastolic and Systolic values? I saw a sample and in one Observation there was the main Observation for Height and then 2 sub-observations for diastolic and systolic blood pressure. We will be returning the observations exactly as they were submitted - for example, if there is a bp observation submitted with both systolic and disatolic values (this is the way bp measurements are supposed to be submitted) then this is how we will return it. Does the Department of Health - treat the dispensing of Methadone (Methadone Carriers) any different than regular prescriptions? IE: The pharmacy can dispense today a methadone rx with 3 carriers.. meaning that these 3 carriers are to be taken daily starting tomorrow for 3 days.

10 From our Pharmacist: When we bill for methadone it would be like any other med for DCAP. If we observed one dose and the patient was entitled to 3 carries, we would bill for 4 doses and the patient would be given 3 bottles as carries labeled drink the contents of one bottle (X mg) daily There are times where we access our patient records for business reasons (e.g. To look up the patient's phone number). Are you expecting that we will do a concurrent search against the Client Registry in these cases as well, or only in the context of filling a prescription? There is no expectation of a concurrent search against the Client Registry when patient records are being accessed for business reasons. Would I be able to get confirmation on whether the QueryRequestLimit vocabulary set is also not required in the schemas that you are supporting? The QueryRequestLimit vocabulary is not required. Are you supporting the Split Order Scenario discussion outlined by Infoway (Volume 1 - Pharmacy, section 8.3.9)? A split order is when 'a prescription results in two or more dispense events to fulfill the intent of the order e.g. an order for 50 mg which is fulfilled with one dispense for 10 mg and another for 40 mg' Yes, the PEI DIS will support this.