Presentation is loading. Please wait.

Presentation is loading. Please wait.

LRI Validation Suite Meeting November 15th, 2011.

Similar presentations


Presentation on theme: "LRI Validation Suite Meeting November 15th, 2011."— Presentation transcript:

1 LRI Validation Suite Meeting November 15th, 2011

2 Agenda Check list of message priority – 10 minutes IG Value Sets Spreadsheet Review (Vocab WG) – 5 minutes Review of EHR Test Plan – EHR Pre-test setup and Test Message Configuration If there is time – Juror document discussion continuation If there is time – Data Management Spreadsheet-Mapping Messages – CLIA/CAP/COLA Requirements and Testing (CDC) ~30 minutes?? Planning

3 EHR Test Harness Test Flow—Testing the EHR (Model 1) EHR Lab Message ACK Validation LRI EHR Test Harness Inspection Testing can be performed by: 1.On-site inspection 2.Over a webex like technology 3.Screen-scraper or screen-capture (include clock) 4.Printed Reports Inspection Testing Techniques 1.EHR display screens 2.Database access 3.Configuration files Communication Automated Testing Acknowledgement Message Limited Utility LRI Test Message Validation Report Test Data Test Case Use Case Juror Document ACK

4 Possible EHR Pre-test Configuration HL7Message ElementNIST Provided Values/Comments MSH.3Sending ApplicationNIST TEST LAB APP^2.16.840.1.113883.3.72.5.20^ISO MSH.4Sending FacilityNIST Lab Facility^2.16.840.1.113883.3.72.5.21^ISO PID.5Patient NameList of patient names provided in test cases PID.3Patient Identifier ListRecord Patient ID Number assigned by EHR when patient record is created for test case (message) configuration. Or use Patient ID Number provided in the test cases (if EHR doesn’t automatically assign) PID.7Date/Time of BirthDOB associated with the patient PID.8Administrative SexGender associated with the patient OBX.3Observation IdentifierThe LOINC (LN) code system will be used. For a list of in- scope LOINC codes for the test plans refer to the NIST LRI Test Plan Overview document Appendix [TBD] OBX.23Performing Organization Name Details of the performing organization as specified in the implementation guide. Values will be associated with a given test case. Order InformationDoes order information have to be entered into the EHR prior to testing? Will it depend on the EHR? In order for the EHR to receive a test message, what EHR setup is required, typical? Static Data that may be Required for EHR Vendor Setup

5 Possible EHR/Message Element Configuration HL7Message ElementComments MSH.5Receiving ApplicationElement is optional; however vendor may need to fill in if their EHR requires/needs it. MSH.6Receiving FacilityVendor (EHR) enters value for their system. PID.3Patient Identifier ListThe test case will contain patient information including the name and patient identifier. The vendor can choose to use this patient record or a patient record that already exists in their system. If the vendor chooses to use the provided patient record then a new patient record needs to be created in the EHR SUT that matches the demographic information in the test case. If the EHR assigns an identifier that needs to be recorded and entered into the test message (tool). If the vendor chooses to use a test patient record that already exists then the test patient information needs to be entered into the test message (tool). Associated test documents will be created dynamically. OBR.2Placer Order NumberIf the EHR requires an order and a specific placer order number be associated with a lab test request then the test message can be modified as needed. OBR.4Universal Service IdentifierThe test message will provide a LOINC coded order request in the first triplet identifying the requested observation. The vendor can value the second triplet in accordance with their local representation of the lab tests (“equivalent to the LOINC code given in the test case). OBR.16Ordering ProviderThe test case will contain ordering provider information including the physician name and identifier. The vendor can choose to use this physician information or a physician account that already exists in the system. If the vendor chooses to use the provided physician information then a new physician record needs to be created in the EHR SUT that matches the physician information in the test case. If the vendor chooses to use a physician account that already exists in their EHR then the ordering physician information needs to be entered into the test message (tool). Associated test documents will be created dynamically. OBR.28Results Copy ToSame method for OBR.16 except substitute “Results Copy To” information. Order InformationWill the EHR require that order information be entered into their system prior to testing? If an order is needed then the validation tool has to import that information into the message.

6 CDC E-mail Comments/Questions I Test report date: HL7 IG (page 123) recommends using OBX-19. However, this has not been the prior interpretation by all agencies. During the time of hardcopies, it was the date and time the hardcopy was printed. However, CMS CLIA has stated the date (and time) of reporting cannot change. The electronic era has thus interpreted this requirement as the date and time the report becomes available to a healthcare provider, such as the date and time the result is finalized in the LIS with the generally accepted assumption of near real time availability to the provider. Please advise if OBX- 19 was suggested by CMS CLIA? Specimen source: SPM-8 is most applicable. However, additional input is needed on field description and determination if other fields may also apply, e.g. SPM-4, 5, 9, 10. – SPM-8, 5, 9, and 10 are optional (i.e., won’t be tested); SPM-4 is Required (SPM segment is RE) Patient’s age: No field option for age located in the HL7 IG. Only DOB appears to be available. – Not sure why this is a problem (calculate); Is Age/DOB a CLIA requirement? Specimen collection date and time: Appears to have two options in the HL7 IG. SPM-17 and OBR-7. SPM-17 description states it should be identical as OBR-7. Should the validation suite verify the data is present and these two sources are identical? – Yes. The conformance statements need to be cleaned up. For OBR-7 the statement is clear. For SPM- 17 (“This value should be the same as OBR-7, unless a new specimen was drawn at the testing laboratory)

7 CDC E-mail Comments/Questions II Results and interpretation: OBX-5 represents the results; OBX-6 represents the units of measure. Unclear which element represents the interpretation of the patient result in relation to the reference range (OBX-7), which may be provided in addition, e.g. Hi, Lo, Critical. (Example. Patient result: 120 mg/dL; Reference Range: 80-100 mg/dL; Interpretation of patient result: Hi). OBX-8 is possible, but is titled “Abnormal Flag”, which is outdated terminology as it may not be considered abnormal. Also note that OBX-8 describes a microbiology interpretation for ceftazidime of “S” for susceptible as an abnormal flag, which is also a misnomer as it is not “abnormal”. Result flag/Interpretation would have been a more appropriate field name. Corrected report identifier: Unclear if the field description addresses this requirement. This is a guess. FDA disclaimers: Appear to be included as part of test name at OBX-3. Concern is for proper and separate display of the name before and the disclaimer after the results (e.g. comment type field). UCUM: There are references in the HL7 IG to adopting Unified Code for Units of Measure. Has the laboratory field had input on adopting this reference as the standard? http://unitsofmeasure.org /http://unitsofmeasure.org / – This is a recommendation; to be in pilots. Should our test message include UCUM? If not, what? Interpretive reports: Authentication (pathologist signature, date and specialty) is required for interpretive reports by the CMS Conditions of Participation at 42 CFR 482.24(c )(1).

8 CLIA Requirements 42 CFR 493.1291(c) The test report must indicate the following: 1.For positive patient identification, either the patient's name and identification number, or a unique patient identifier and identification number 2.The name and address of the laboratory location where the test was performed 3.The test report date 4.The test performed 5.Specimen source, when appropriate 6.The test result and, if applicable, the units of measurement or interpretation, or both 7.Any information regarding the condition and disposition of specimens that do not meet the laboratory's criteria for acceptability

9 CLIA Requirements Mapped to Data Elements 42 CFR 493.1291(c) The test report must indicate the following: 1.For positive patient identification, either the patient's name and identification number, or a unique patient identifier and identification number – PID-3 : Unique patient identification number – PID-5 : Patient Name 2.The name and address of the laboratory location where the test was performed - OBX-23/24/25: Lab Identification Fields 3.The test report date - OBX-19: Date/Time Analysis 4.The test performed - OBX-3: LOINC codes for Observation Identifier 5.Specimen source, when appropriate – SPM-4: Specimen Type 6.The test result and, if applicable, the units of measurement or interpretation, or both – OBX-5: Observation Value – OBX-6: Units – OBX-7: Reference Range – OBX-8: Abnormal Flag – OBX-11: Observation Result Status 7.Any information regarding the condition and disposition of specimens that do not meet the laboratory's criteria for acceptability – SPM-21: Specimen Reject Reason – SPM-22: Specimen Quality

10 Required CLIA Report Elements – PID-3 : Unique patient identification number (R) – PID-5 : Patient Name (R) – OBX-3: LOINC codes for Observation Identifier (R) – OBX-5: Observation Value (RE) – OBX-6: Units C(R/RE) – OBX-7: Reference Range (RE) – OBX-8: Abnormal Flag (RE) – OBX-11: Observation Result Status (R) – OBX-19: Date/Time Analysis (RE) – OBX-23/24/25: Lab Identification Fields (R/R/RE) – SPM Segment (RE - Required but may be Empty) – SPM-4: Specimen Type (R) – SPM-21: Specimen Reject Reason (O) – SPM-22: Specimen Quality (O) Are all elements required to be displayed on screen (including the components and subcomponents of these fields)?

11 Format of the EHR Juror Document Follow the workflow of the EHR Grouping of Data – Display patient name, ID, and lab results – Additional demographics – Performing Labs Information Demographics What should be displayed on the EHR and what can be assessed via database access – Also take into account CLIA and MU Requirements

12 Action Item List I Select message to handle core lab results – Identify 20 or so common lab results (In progress) – Obtain/Adapt/Create test messages to cover the core set of lab results (In progress) Identify/List all pertinent data elements (In progress) – Create spreadsheet of all data elements with usage of R, RE, and C (rows) – Columns will identify: Juror Document (How to assess the element) Identify the elements required for CLIA testing Identify static, configurable, or indifference data elements Identify/create/verify value sets (In progress) – Create Spreadsheet; convert to NIST XML tool format – Incorporate the value sets in PHINVADS – Develop download mechanisms and transformation of values to support the NIST tooling format

13 Action Item List II Review LRI implementation Guide and create a list of all conformance requirements (Not Started) – Create matrix based on data elements – Link all conformance requirements to data elements when possible – Create “higher” level list of conformance requirements Determine the policy for assessing receiver side terminology (Done: need to write policy statement) – Inspection test requirements and procedure – Automated test requirements and procedure Complete development of LIS Test Plan Skeleton Complete development of EHR Test Plan Skeleton

14 Action Item List III Identify and document the test dimensions (Not Started) – Coverage of Lab Results – Scenarios (e.g., Preliminary, Final, Corrected) – Reporting formats – Negative testing – Minimally and maximally populated Contact CLIA and CAP inspectors to get their lab inspection process (Need contacts) Determine a process for verifying test cases (Not Started) Implement process for verifying test cases (Not Started) Research ELINCS Test Tool (DONE) – Determine what we can leverage – Process flow, source code, test messages

15 Action Item List IV Identify all the public health reportable lab results (Done) Identify the data elements that differ from the public health IG and the S & I LRI IG (Not Started) Determine a policy for validating LRI messages using EHR PH lab results messages (Not Started) Develop spreadsheets for managing test cases/data (In progress) – Adapt tooling to process and incorporate data – Phase 1 nearly complete – Phase 2 will include the multiple dimensions (Data, Profile, Juror) Create the HL7 standard message profiles (Starting soon) – MWB (then produce XML message template) – Need to make updates to the message profile based on changes made in version 2.7 and 2.7.1 – Write XSLT to modify XML message profile

16 Action Item List V Identify the CLIA conformance requirements and compare to the requirements in the implementation guide (In progress) – Mark in spreadsheet – (DONE) – Make sure conformance requirements and IG match – Write conformance requirements in IG where necessary to match CLIA requirements Prototype tool (In progress) – Requirements and design (In progress) – Development (In progress) – Incorporate test cases (Not Started) – Testing (Not Started)

17 Action Item List VI Identify a strategy for testing systems that supports unique identifiers and those that don’t (Not Started) – So far, will test on for properly formatted OIDs for the GU Profile Vocabulary (value sets) (In progress) – Need to be reviewed (Vocab WG- C. Johns) – Import into PHINVADS ??


Download ppt "LRI Validation Suite Meeting November 15th, 2011."

Similar presentations


Ads by Google