Vendor Compliance Checklist. Version 1.4

Transcription

1 Vendor Compliance Checklist Version 1.4

2 Revision History Date Version Description Author September 22, Initial Draft Angela Lawlor September 27, Removing duplicates Angela Lawlor October 10, Divided items in to categories Angela Lawlor October 17, Incorporating feedback from DH Angela Lawlor

3 Table of Contents 1. Introduction Purpose/Audience Conformance Contact Information Compliance Checklist Security and User Access Client Identification Local & DIS Profile Prescribing Dispensing PEI Jurisdictional Variations Business Technical...13

4 PEI DIS Compliance Checklist 1. Introduction The PEI Department of Health is building a Drug Information System (DIS) to electronically link community pharmacies, physician offices, family health centres, addictions centres, hospital pharmacies and emergency rooms with a database that maintains patient medication records. Pharmacists in PEI will be required under ADAP (All Drugs All People) legislation to submit transactions to the DIS of every prescription medication they dispense to Island residents. This document provides a technical checklist for Pharmacy Software Vendors to conform to the HL7 v3 specifications, and to the jurisdictional variations for the PEI DIS Purpose/Audience The purpose of this document is to provide a Compliance Checklist for vendors to reference as they modify their software to meet HL7 v3 messaging standards, and those variations of the standards particular to Prince Edward Island. The audience is those Pharmacy Software Vendors' with products in PEI pharmacies, and in particular the technical team of these vendor companies. This document is not intended to replace the Implementation Guide, but is instead intended to be a quick reference for developers. It is recommended that all vendors be familiar with and use the Implementation Guide for development purposes. 2. Conformance For the purposes on the DIS project in PEI, conformance is described as the ability to comply with all of the HL7 rules and constraints surrounding the DIS. The conformance rules are outlined in PEI's Implementation Guide, found via a link at As well, a Conformance Plan outlining the steps involved in becoming Compliant to the PEI DIS will be provided with this document Contact Information The contact person for the PEI Department of Health for DIS conformance is Patricia Holland, Technical Analyst. She can be reached at pmholland@gov.pe.ca or (902) Confidential DeltaWare Systems Inc.,

5 3. Compliance Checklist *Identifies any items that have a jurisdictional variation. 3.1 Security and User Access 1. The local system must: Force the use of passwords at least 6 characters long; Force the Provider to change passwords within 90 days; and Prevent immediate reuse of a password. 2. Unique User IDs must be assigned to each individual who requires access. 3. User IDs must be authorized to access an authorized set of system functions (e.g., filling prescriptions, stock control, etc.). 4. The local system must place a User ID in a revoked status after a maximum of five (5) consecutive failed sign on attempts. Initialization of the User ID requires intervention of the manager or system administrator with a higher level User ID. 5. A high level User ID must be defined to control security access and other restricted system functions. This User ID s functionality must not include the ability to process PhIP transactions. 6. The software must have functionality to revoke or disable User IDs. 7. Each Provider must be able to set their own password. 8. A security application must force Providers to set a new password after a password has been reset or a new User ID is assigned. 9. Passwords must be stored by the local system in an encrypted file that cannot be read. 10. Password characters must not be displayed on monitors when entered. 11. Passwords must not be hard coded into any system file or routine and must be keyed in by the Provider each time the Provider signs on. 12. All access to the DIS must be approved by the Department of Health and take place on systems with anti virus software installed and running. The anti virus software engine and signature file(s) must be kept up-to-date. The anti virus software must be set to run in constant scan mode. 13. In order to communicate with the DIS, each transmitting PC must be connected to the Internet. The PC must have TCP/IP software and a connection to a router which itself is connected to the Internet. This may be achieved by connecting the PC to the local area network (LAN). If the router being used is not an ITSD router, the sub-domain name or the IP address range for the site must be communicated to the DIS Health Information Access Layer (HIAL) to ensure site access is enabled. 14. The Department of Health requires no specific hardware to be in place. Hardware requirements will be determined by the Pharmacy and Physician vendors, and must be such to meet the requirements of adequately interacting with the DIS. Confidential DeltaWare Systems Inc.,

6 15. All parties using third-party software applications to access the DIS must agree to the following release management requirements: Written notification to the PhIP System Administrator describing changes or upgrades to the local software is required before Pharmacy Software Vendors (PSVs) may release the changes to production users; Prior to compliant software being installed for production use, the PSV must sign a Confidentiality Agreement with the Provider; The PhIP System Administrator has an option to evaluate any release of a local software application before it is put into production use; and A PSV may be exempted from a compliance evaluation at the discretion of the PhIP System Administrator if it can be determined that all functionality related to DIS functions has not been affected in any way. 16. All third-party software vendors must submit the following before an exemption from a compliance evaluation will be considered by the PhIP System Administrator: Purpose of the change; Description of change and/or functionality; Anticipated impact on IHIS data and/or transactions; Version number; and Anticipated release date. 17. A version number must uniquely identify each iteration of a local software application that has achieved a compliant status. The version number must be provided within the message structure as defined in the appropriate standards. Audits will be performed to ensure that the version number being transmitted correlates with the version of the application that has been approved for use in PEI. The local software version number must increment when a new release is issued. 18. The compliance team will be made available, at no cost to the vendor, up to a maximum of one compliance evaluation and one follow up evaluation per software release. When additional evaluation dates are required, the vendor must provide the PhIP Administrator with a written request. 19. The local system must ensure that all users are properly locally authenticated and access is restricted to authorized personnel. 20. All users must be a configured provider with the correct password within the provider module. 21. The local software must restrict a User ID s access to authorized business functions regardless of physical location within the building. For example, a clerk who has access to the local computer system(s) must not be able to sign on to the pharmacy system and gain access to confidential patient data. Confidential DeltaWare Systems Inc.,

7 22. Physical and logical controls must be placed on the local system to restrict access to all system components to only those individuals who actually require access to that part of the system as part of their job. 23. All remote access to the local system must: Use a cryptographic tunneling protocol to provide confidential, sender authentication, and message integrity to achieve intended privacy; an IPSec VPN or a clientless SSL VPN (Medical Practitioner s only) are suggested by the Department; and Carry a digital certificate from the Island Health PKI to authenticate the server. 24. All health data traffic must be encrypted when: The data is transmitted beyond a single physical network; The network connections are between two or more IHIS participants; and The network is shared by more than one business entity. 25. The encryption method used must comply with the following standards: Secure Sockets Layer V3 (SSL); and Transport Layer Security V1 (TLS). Confidential DeltaWare Systems Inc.,

8 3.2 Client Identification 1. If the ISP does not assign the IP address, it must be registered with the Internet Assigned Number Authority at 2. The local system must not include an xsi:schemalocation attribute in any message. 3. The local system must include a namespace declaration, such as xmlns= urn:hl7-org:v3, for all messages transmitted to the host system. 3.3 Local & DIS Profile 1. The local system must support adding the following records to the Patient profile: Allergies; Intolerances; Immunizations; Oveservations; Medical Conditions; and Notes. 2. *The local system must support retrieval and display of the client clinical profile. 3. *The local system must permit the Patient and/or User to supply a keyword for profile access. 4. *The local system must permit the User to supply a reason for profile access. 5. *The local system must update the local Patient profile to reflect the information available from the DIS. 6. The local system must transmit changes to the Patient profile to the DIS. 7. The local system must provide a differentiation between notes to be retained only locally versus notes that are meant to be shared within the context of a clinical record. 8. The local system must clearly indicate in search results whether the displayed records are stored locally or not. 9. The local system must permit establishing a local prescription from the information available in a DIS supplied prescription. Confidential DeltaWare Systems Inc.,

9 10. The local system must maintain correct linkage between DIS supplied identifiers and locally supplied identifiers. 11. The local system must provide the user with a means of updating the local system record from the DIS. 3.4 Prescribing 1. *At least two characters of the last name must be provided if the last name is included as a search term. 2. *The local system must support Client Registry searching using any combination of Health Number, Name, Date of Birth, and Gender. 3. *Gender may not be used exclusive of other search terms. 4. *The client keyword must not be stored locally on the system in a permanent data store but it may be retained for the duration of the user s interaction with the patient record. 5. *The local system must be capable of indicating that data provided may be incomplete due to clinical data masking. 6. *The local system must permit the Patient and/or User to supply a keyword for profile access. 7. The local system must permit the User to supply a reason for profile access. 8. The local system must support releasing a prescription via the DIS. 9. The local system must make electronic prescription available for use by the user. 10. The local system must support storing a prescription for a future fill without transmitting it to the DIS. 11. When using number of fills to determine whether to pay an invoice, the following must be done: An electronic prescription number must be used to tie a series of invoices together in order to determine when all fills have been completed. This number will be assigned by the DIS and will be returned in the CeRx dispense message; and Invoices from electronic prescriptions must communicate the electronic prescription number using the substanceadministrationintent.id field when sending an Invoice Adjudication Request. 12. *The local system must search both local and Client Registry for matching records. 13. The local system must merge patient records based on the Health Number. 14. The local system must support the collection of medical conditions. 15. The local system must transmit additions/changes to medical conditions to the DIS. Confidential DeltaWare Systems Inc.,

10 16. *The local system must support transmitting allergy and intolerance records to the DIS. 17. *As a result of receiving the entire allergy data structure, including the reactions and tests, the xml structure received must include all pertinent information for the allergy data. 18. As a result of receiving the complete reaction data, including all exposure events, the xml structure received must include all pertinent information for the reaction data. 19. As a result of receiving the complete medical condition data, including all notes, the xml structure received must include all pertinent information for the medical condition data. 3.5 Dispensing 1. The local system must support dispensing against a transferred prescription. 2. *On a reversal, the local system must cancel the dispense event on the DIS. 3. The local system must reverse the dispense event for each third party payor submitted. 4. The local system must respect and enforce the current status (stopped, etc) recorded on the DIS for the prescription. 5. *The local system must support manually marking a dispense as DIS cancelled and/or TPP reversed in the event that a cancel/reverse was not electronically possible. 6. *The local system must transmit a Pickup Notification event when the dispense is delivered and/or picked up. 7. The local system must not permit further dispenses against a prescription that has been transferred to another pharmacy. 8. The local system must provide the ability to locate a locally stored clinical dispense. 9. The local system must provide the ability to locate a locally stored invoice dispense (claim). 10. The local system must have the ability to reverse all invoice dispense events. 11. The local system must display both locally dispensed and externally dispensed prescriptions in the same view. 12. The local system must transmit the dispense to the DIS prior to third party payors. 13. The local system must associate the prescription with the associated dispense events. 14. The local system must cope with a clinical dispense event being accepted with warnings the user may wish to consider as reason to issue a correction. 15. The local system must transmit the DIS dispense identifier with the invoice event. Confidential DeltaWare Systems Inc.,

11 16. The local system must be able to use the manage issues interaction to record the Pharmacist management of returned issues. 17. The local system must support providing intervention (issue management) codes with the clinical dispense event. 18. The local system must support providing intervention (issue management) codes with the dispense invoice event. 19. The local system must support providing intervention (issue management) codes after the fact for clinical dispense events using the issue management interactions. 20. The local system must send the local dispense identifier to the DIS. 21. The local system must initialize the prescription/dispense from the DIS prescription. 22. The local system must enforce the CeRx status codes on the prescription and dispense records. 23. The local system must support viewing notes on the clinical dispense records. 24. The local system must include the authorization identifier in subsequent invoice dispenses until the confirmed quantities have been consumed. 25. *The local system must provide the user with a method of explicitly asking for a pre-determination which will result in the following: Dispense event in not submitted to the DIS; CPhA invoice claims are automatically reversed; and NeCST pre-determination/authorization requests are cancelled. 26. Once the first fill has been picked up, the system must do the following: Change the status of the Rx from New to "Active"; and Change the status of the dispense from Active to Completed. 27. The PaymentRequest id must match the DIS dispense identifier that is returned to the pharmacy after the CeRx dispense response has been sent. 28. The CMPNDFEE invoicedetailelement must be provided as a component of the group representing the compound invoice; code = CPNDDRGING. 29. The local system must not permit dispensing against a released prescription. 30. The local system must maintain a record of the transfer by either making use of a transfer function or by inactivating the transferred Rx. 31. *When using the determine coverage function, the Pharmacist and/or local system must provide the following to determine the eligibility: Client s Provincial Health Number (mandatory); Date of Service (mandatory); and Program Code (suggested). 32. *The local system must support all Provincial Drug Programs currently offered. 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. Confidential DeltaWare Systems Inc.,

12 34. *The local system must support the use of the AUTO Provincial Drug Program type whereby the payor system will choose the coverage to use. 35. The local system must use the CeRx coding to identify the author of the prescription. 36. The local system must permit the user to enter and transmit Schedule II and III drugs to the DIS. 37. *The local system must support transmission of a clinical professional service. 38. *The local system must be capable of indicating that data provided may be incomplete due to clinical data masking. 39. The local system must be able to re-create the control act event identifier of a prior action. 40. *The local system must transmit the control act event identifier for the event to be undone. 41. *The local system must support a manual undo in the event that the DIS does not permit the undo to be conducted electronically but rather through manual processes (i.e. the permitted period of time has elapsed). 42. The local system must support update messages where provided. 43. The local system must support cancel messages where provided. 44. The local system must support reversal messages where provided. 45. *The local system must support undo messages where update/cancel/reversal messages are not provided. 46. *The local system must support a per-coverage or a per-payor daily reconciliation report. 47. The local system must support the summary statement of financial activity query. 48. The local system must permit the display of DIS supplied notes. 49. The local system must support a clinical-only predetermination request in which the user may transmit the proposed prescription to the DIS solely for the purposes of Drug Utilization Review. 50. The local system must support a predetermination request in which the user transmits the proposed prescription to the DIS and all user selected TPP with an implicit reversal for any TPP that may return an authorization (NeCST) or a claim reversal (CPhA). 51. The local system must support the eligibility query without requiring the submission of an invoice. 52. The local system must cancel the invoice event in the event of a reversal. 53. *The local system must retain Provincial Drug Program eligibility for a Patient. 54. The local system must respect COB processing rules for both NeCST and CPhA. 55. The local system must permit the user to transmit the prescription to the DIS. 56. The local system must retain the DIS supplied prescription identifier. 57. The local system must support the CeRx interaction to release a prescription. Confidential DeltaWare Systems Inc.,

13 58. *The local system must send the identical message in re-transmitted requests unless correcting an invalid reversal request. 59. The local system should execute searches against its local patient source concurrently with transmitting the search request to the DIS. 60. The local system must provide the ability to selectively choose the elements of the patient information that is updated in the local system. 61. The local system must retain a transactional log of the user, patient, and reason. 62. The local system must transmit the reason text in all CeRx message interactions with the DIS. 63. The local system must provide a report/view of these reasons which may be queried by user and patient. 64. *The local system must cope with either a rejection or acceptance with DUR issues. 65. *The local system must retain the control act identifiers originally submitted to permit the subsequent undo request. 66. *The local system must support the NeCST Summary SOFA interaction. 67. The local system must support the prescription status management interactions. 68. The local system must respect the prescription status as supplied from the DIS. 69. The local system must support the Patient Note interactions. 70. The local system must clearly indicate that all notes other than Patient Notes cannot be modified or removed. 71. The local system must support viewing notes on the clinical prescription records. 72. The local system must support viewing notes on the allergy/intolerance records. 73. The local system must store the returned authorization identifier. 74. *The local system must update the locally stored coverage records with the information supplied by the payor system. 75. Due to the nature of the DIS all requests are dealt with immediately. As such the local system must specify a responsemode of Immediate. 76. The local system must support the ability to re-transmit a message in whole in the event that it does not receive a successful response from the host system. 77. The local system must consider a message as non-delivered in the event that a response message is not received as follows: A response is not received within a pre-determined timeout (Jurisdictional variations will exist); A network layer connection error occurs; or Any non documented response is returned. 78. The local system must supply all known participants in each message that is transmitted to the host system. In particular this must include the following: Confidential DeltaWare Systems Inc.,

14 Pharmacist (Dispenser); Prescriber; and Pharmacy Technician. 79. The local system must support receipt of message responses that have been compressed as per the standard RFC Specifically, the local system must accept both gzip and deflate compressed content. 80. *Until widespread support for NeCST is available pharmacy vendors must handle situations where a pre-determination is performed against a mixture of both NeCST and CPhA payors. 81. *Vendors must take care to properly retain the type of results returned by NeCST Payors that conditionally return a pre-determination or a special authorization. 82. In the case where the NeCST payor returns a special authorization the local system must choose to either retain the special authorization result for future use or to have the special authorization cancelled/reversed. 83. In order to facilitate consistent compound processing the following constraint rules have been applied: Compounds must be expressed as a single list of ingredients; and The primary ingredient must be the first item in the list. 84. Update Other Active Medication - An update does not include the ingredient list or administration instructions so these must be copied over and attached to the new version of the other medication record. 85. Transferring custodianship - The facility-id in the message (indicating where the message is coming from) must be equal to the currently assigned pharmacy owner id of the Rx in order for any transfers to take place. 86. When referencing a previous prescription number to create a new prescription, the status of the referenced prescription must be changed to Obsolete. 87. The purpose of a stop-rx message is to indicate that a prescription should no longer be filled or administered and thus the status must be changed to stopped/aborted. This can be done prior to a fill or after a fill. 88. Record a non-fill of a prescription - The message must include the rationale behind the decision for the refusal to fill; reason code(s), textual reason and optionally a list of issues that indicate the reason to refuse the fill. 89. A NeCST Compound invoice must resemble the following: Root InvoiceGroup for the Invoice (code is RXCINV) Root InvoiceGroup to identify the compound (code is CPNDDRGING) Child Invoice Group for first compound Ingredient (code is CPNDINDING ) Confidential DeltaWare Systems Inc.,

15 Invoice Detail for first ingredient drug cost (code is DIN or ingredient code system i.e. HIC) Invoice Detail for first ingredient markup (code is MARKUP) Child Invoice Group for second compound Ingredient (code is CPNDINDING ) Invoice Detail for second ingredient drug cost (code is DIN or ingredient code system i.e. HIC) Invoice Detail for second ingredient markup (code is MARKUP) Child Invoice Group for nth compound Ingredient Invoice Detail for nth ingredient drug cost Invoice Detail for nth ingredient markup 90. The root for a compound invoice must always be present to identify the compound. 4. PEI Jurisdictional Variations 4.1 Business CP-UC1-SS2 Existing Patient, New Prescription - Updates to the Client Registry are not supported; - Non-Residents cannot be allocated Health Numbers from pharmacies; and - Non-Residents that visited a Provincial hospital or care facility will have a Health Number allocated. CP-UC1-SS8 View/Enter Patient Record - Prince Edward Island Non-Resident persons information is not presently recorded; and - Prince Edward Island personal demographic updates may not be transmitted to PhIP. CP-UC4-SS1 - Identify Client - PEI Health Cards are supplied with a magnetic strip that can be used to retrieve the Health Number and vendors are encouraged to card-enable their software offerings. CP-UC4-SS2 Client Data Masking - PEI does not support the ability to allow external entities to adjust masking of the clinical profile through messaging. Confidential DeltaWare Systems Inc.,

16 CP-UC4-SS2-PE Client Keyword - PEI does not provide a message based solution for creating/changing/removing keywords. CP-UC4-SS3 Undo of Prior Action - PEI has chosen a period of seven (7) calendar days for most undo events and (2) calendar days for other subsequent undo events; - Undo events are not supported for interactions that provide clearly established business processes for undoing (i.e. invoices must be reversed, not undone). CP-UC4-SS5 Daily Fiscal Reconciliation - PEI is supporting only the summary SOFA query CP-UC4-SS8 Pre-determine or Request Authorization - PEI will continue to support the common practice of submitting an invoice followed by a reversal until such a time as sufficient payors implement the required NeCST message support to fully support the coordination of benefits. CP-UC4-SS9 Coverage Extension - PEI is not supporting the use of a coverage extension. 4.2 Technical CP-UC1-SS3 New Patient, New Prescription - Updates to the Client Registry are not supported; - Non-Residents cannot be allocated Health Numbers from pharmacies; - Non-Residents that visited a Provincial hospital or care facility will have a Health Number allocated. CP-UC4-SS1 - Identify Client - PEI Health Cards are supplied with a magnetic strip that can be used to retrieve the Health Number and vendors are encouraged to card-enable their software offerings. CP-UC4-SS2 Client Data Masking - The PEI implementation does not support message based masking of the clinical profile; - The PEI implementation does not mask demographic data. Confidential DeltaWare Systems Inc.,

17 CP-UC4-SS2-PE Client Keyword - PEI does not provide a message based solution for creating/changing/removing keywords. CP-UC4-SS3 Undo of Prior Action - PEI has chosen a period of seven calendar (7) days for most undo events; - Undo events are not supported for interactions that provide clearly established business processes for undoing (i.e. invoices must be reversed, not undone). CP-UC4-SS5 Daily Fiscal Reconciliation - PEI is supporting only the summary SOFA query CP-UC4-SS8 Pre-determine or Request Authorization - PEI will continue to support the common practice of submitting an invoice followed by a reversal until such a time as sufficient payors implement the required NeCST message support to fully support the coordination of benefits. CP-UC4-SS9 Coverage Extension - PEI is not supporting the use of a coverage extension Confidential DeltaWare Systems Inc.,