cardinality specification and testing recommendations

Download Cardinality Specification and Testing Recommendations

Post on 23-Feb-2016

38 views

Category:

Documents

0 download

Embed Size (px)

DESCRIPTION

Cardinality Specification and Testing Recommendations. LOI and LRI MU Certification November 14, 2013 V3.0. Wiki Comments. Note: definition of vital includes/implies specific segments/elements as unlimited (0/1,*) and others as bounded (0/1,n). Specific comments: - PowerPoint PPT Presentation

TRANSCRIPT

Meaningful Use Supplement

Cardinality Specification and Testing RecommendationsLOI and LRI MU CertificationNovember 14, 2013 V3.01#Wiki Comments2CategoryCountIndividualsConfirm As Is5151Question re Vital1515Specific suggestions147Not applicable11Specific comments:C1:1: For limits verify with clinical expertsC2:17: Unlimited list OBR, OBX, NTE, NTE-3C3:36: Notify both sending and receiving parties if supported occurrences exceededC4:41: Issue regarding partial or complete rejection C5:52: Imperative?C6:58: Process to grow (e.g. 10%)C7:72: Ability to have local agreement that meets base standard but violates IG on cardinalityC8:74: Requested examples of Patient SafetyC9:75: Multiple levels of ACKC10:77: Option to stop processing on CEC11:78: Is there a flavor between Partial and Hard Stop?C12:79: Partial consumption of results no this is a CLIA issueC13:80: Error response behavior of client site message replication C14:81: New codes to avoid confusion with usage; suggestion on specific limits and usageNote: definition of vital includes/implies specific segments/elements as unlimited (0/1,*) and others as bounded (0/1,n)#Responses to Comments3C1:1: For limits verify with clinical expertsR1:1:Include as part of redefining * to n for limited occurrence items and testing for unlimited items

C2:17: Unlimited list OBR, OBX, NTE, NTE-3R2:17: yes, this is the recommended minimum list for unlimited occurrences update tables

C3:36: Notify both sending and receiving parties if supported occurrences exceededR3:36: Yes, new Notification slide with recommendations

C4:41: Issue regarding partial or complete rejectionR4:41: Reviewed with CLIA required to reject all under 493.1291 report all results and associated information in a secure, reliable, accurate manner see new CLIA slide

C5:52: Imperative?R5:52: No response required

C6:58: Process to grow (e.g. 10%)R6:58: Include with R1:1 as part of testing limit evaluation

C7:72: Local agreement that meets base standard; increase upper limit for IG on cardinalityR7:72: Yes, new slide with approach: appropriate adjustments in behavior at upper limit#4C8:74: Requested examples of Patient SafetyR8:74: Requested from LRW and CDC/FDA

C9:75: Multiple levels of ACKR9:75: See discussion on new slide deferred to discussion on Acknowledgements

C10:77: Option to stop processing on SER10:77: Option will be added to table

C11:78: Is there a flavor between Partial and Hard Stop?R11:78: No see R4:41

C12:79: Partial consumption of results no, this is a CLIA issueR12:79: See answer R4:41

C13:80: Error response behavior of client site message replicationR13:80: Recommendations on new slide deferred to discussion on Acknowledgements

C14:81: New codes to avoid confusion with usage; suggestion on specific limits and usageR14:81: Agreed will update tables#Issues related to upper limitsIf standard says 0,10If guide says 0,5 thenTest can send 0-5Test that we can receive and consume 0-5SendingError if unable to send 0Error if unable to send up to 5Error if send more than 5Receiving Error if unable to receive 0Error if unable to receive and consume less than 5Error if receive more then 5 Can create new derived profileMay not decrease upper limit below IGMay increase upper limit up to base standardThen may increase the error on upper limit for sending or receiving to be equivalent to the new upper limit5#Overview6#Cardinality DefinitionCardinality identifies the minimum and maximum number of occurrences that a message element must have in a conformant message Some elements shall always be present (e.g., cardinality [1..1], [1..n]) Other elements shall never be present (e.g., cardinality [0..0]) Other elements may or may not be presentzero or more occurrences (e.g., cardinality [0..n]) A conformant message must always contain at least the minimum number of occurrences, and shall not contain more than the maximum number of occurrences7#How is Cardinality Tested?Limited case - if cardinality specification is [1..5], per the standard a conformant message must always contain at least one occurrence and shall not contain more than five occurrencesSenders must be capable of sending up to 5 instances of the element andReceivers must be capable of processing 5 elements. Receiver behavior defined in associated functional requirements for the element.Testing the sender we have a test case where we provide data for 1 instance of the element and validate based on that.In another test case, we provide data for 5 instances and we would validate to check that 5 instances were in the message.Another test case we could provide data for 6 instances. Now the application interface may very well allow for this and this is OK (because it could support other use cases), what we would test for here is that only 5 are sent (present in the message). If 6 instances are sent then the application is not conformant.If we dont provide any data, the application should recognize that data is needed.Testing the receiver we would inspect that the number of elements we sent are correctly processed/associated/stored depending on the element.

8#How is Cardinality Tested?Unlimited case a cardinality of [1..*] indicates that implementations must be capable of supporting an unlimited number of instances for that elementCurrently, an arbitrary number is selected for testing when the maximum upper limit is indicated with *Testing proceeds exactly as indicated on the previous slide since an arbitrary upper limit is selected, i.e., [1..*] [1..x]In the case of *, implementers are not excused from supporting unlimited occurrencesthere is just a practical limit that can be testedIn current MU testing, under-testing is typical because creation of relevant test cases usually is difficult and resource-consumingNIST welcomes guidance for testing a minimum upper limit for unlimited cardinality elements.9#Recommendations for LOI/LRI Implementation GuidesThe specification of * for unlimited occurrences of an element should remain as isThat is, systems are required to support unlimited * occurrences of elementsThis applies for both the Sender and ReceiverThere is no need for the proposed [0..x, *] conformance construct; the x is described in the Testing Guidance document and is only guidance not a requirement (i.e., unlimited, when specified, remains the requirement)nothing has effectively changed for implementersWhat is new is that guidance for testing is being specified in a separate document and does not affect implementation requirements.10#Definition of TransactionFor the purpose of this analysis and recommendation, the following is the definition of a transaction Limited to a single MSH and associated segmentsDoes not have an impact on previous or future transactions, e.g., failure to consume a corrected report or a report that completes preliminary or partials does not require removal of an earlier preliminary, partial or final report.May include one or more orders (ORC/OBR) up to the total number of orders reported under the same MSHLimited to a single patientLimited to orders that were placed together on the requisition or single order transaction On reporting, may include any reflex and add-on ordersNote: After reporting a final order (ORC/OBR) (all components are complete), the recommended method is to not report the order again unless there is a change (e.g. corrected result).

11#ConclusionFailure due to exceeding cardinality limits in a certified EHR expected to be be a very rare occurrence (

Recommended

View more >