Test Cases

Introduction

Reviewing and changing this document

The content of this document was developed by Canada Health Infoway to provide a guide to implementers on how to test their applications and to provide a different view towards understanding the HL7 standard.

This document is being posted to the WIKI because it is intended to become a communal document. We expect and want people to change it. If you feel there is an error in the interpretation of the existing specification, then fix the test cases accordingly (and be sure to reference your source in the rationale for the change you record). There are also many test cases others have thought of which are not included here. Please add them so we can make this document as complete as possible

However, if you think that the tests do in fact represent the existing rules, but in reviewing the test cases have come to the conclusion that the existing rules are inappropriate, please don’t remove the test-case. Instead add a suggestion, in the appropriate markup, indicating the change to the standard you’d like to see happen to make the necessity for the test case go away.

I suspect after we let this document burble away for 5 or 6 months we’ll have a sizable list of additional constraints to add to the RIM, datatypes and individual committee specifications which will make them much more realistic and implementable. When those changes have been made, we’ll be able to trim down this document to reflect more realistic testing.

In some cases, we may leave the underlying specification unconstrained, with the recognition that implementers will need to rise to the challenge of supporting more sophistication than they’re used to. Hopefully there will be sufficient rationale gathered in these pages that the reasons for the functionality will be clear and implementers will understand how the content is to be used

At some point in the future, HL7 may choose to incorporate this content as a section in the ballot, perhaps split up on a “per topic” basis. However, for the time-being it is purely informative and intended to provide guidance to implementers.

Before you panic

The intention of this document is to reflect the testing required to ensure conformance to the v3 specification rules as they currently exist and are expressed. In many cases, the tests proposed will seem patently absurd to any realistic exchange of data in a healthcare environment (e.g. allowing the original text for sending administrativeGender to contain several gigabytes of data). The intention is not to suggest that the HL7 specification itself is absurd. In some cases, the original text may well be a high-definition video-clip which may indeed take a few gigabytes to transmit, and the ability of HL7 to support capturing such information in some cases is reasonable. Most systems will not require attributes such as ‘language’ to be declare with name and address parts. However, in some cases those pieces of information will be useful.

The key to making HL7 usable that specifications must be appropriately constrained to the use-case for which they are intended. If the maximum original text that should reasonably be captured for a particular use-case is 100 characters, then that limit should be expressed in the specification. In some cases, constraints are essential. For example, no physically implemented system can possibly support infinite lengths, infinite repetitions or infinite recursions. Therefore these characteristics should always be constrained, ideally in the balloted standard. (Allowing a free-for-all of different systems assigning different lengths will lead to interoperability issues).

Where the constraint occurs depends on the level of knowledge of the environment. At the RIM level, attributes and associations can be used for so many diverse purposes, that meaningful constraints can only be applied in a few circumstances. However, by the time a specification is constrained to the implementable (i.e. Message Type) level, things should be tightened down considerably. One of the things made clear by this document is that datatype flavors will definitely be required for datatypes such as AD, EN and GTS.

Some might argue that constraints are not necessary to prevent the sending of information which is not reasonable to be sent anyhow. However, experience shows that ‘reasonable’ is in the eye of the beholder, and that the only mechanism to ensure interoperability is to have tight specifications.

If applying some of these tests to a system would result in behavior that seems unreasonable to expect, then encourage the appropriate constraints to be introduced in future versions of the standard. At a minimum, create a conformance profile indicating the constraints to which you’ve designed your application to comply. That will provide a clear expression of the assumptions on which your application was constructed and will allow other systems to determine their potential for interoperability.

Test cases

The reality of testing is it is never possible to exhaustively test a healthcare communication system. The number of variables are simply too large. However, to ensure patient safety and security of protected information, it is essential that testing of interfaces be as thorough as possible. This document attempts to identify various aspects of an HL7 v3 interface that should be tested and how the interface might be tested.

This list of test considerations provided here is not comprehensive. Implementers are responsible for all aspects of testing their systems. Purchasers and the users of third-party software are responsible for verifying the correct operation of software they acquire. This responsibility includes the development of test cases based on the suggestions in this document, as well as the construction of additional test cases based on the known operation of the software, the operating environment in which the software will operate and the risks most of concern to implementers.

The set of test cases found here may also help to emphasize and clarify aspects of the specification that may not have been obvious in the initial read. Some of the contents are messaging-specific. However most of the test-cases are equally applicable to structured documents.

Testing considerations

It is not expected that each of the possible tests will be performed on every single attribute and association described by a specification. However, each type of test should be performed at least two or three times throughout the variety of test cases developed for an interface.

When performing testing, it is important to test both what a system is able to send as well as what it is able to receive. Testing of what can be sent includes testing of what the user interface allows to be collected, as well as how the information collected translates into what goes over the wire. Similarly testing of what can be received includes ability to parse and extract data from a message or document, as well as how that information is rendered to system users.

The version 3 specification documents what requirements are expected to be met. When testing a sending system, it is important to verify that the system cannot construct instances which are not valid against the v3 specification. For receiving systems, it is important to test that the system is able to successfully and receive all instances which are valid according to the specification. However, it is also essential to test that the receiving system can also handle instances which are not valid against the v3 specification. Non-valid messages can be handled in a number of ways:

• The receiving system might send a negative acknowledgement (NAK) indicating the received message was invalid
• The message might be redirected to an error log or otherwise prevented from being stored in the receiving system
• Unexpected ‘extra’ content in the received message could be ignored, and a warning message returned to the sender indicating that the extra data had been ignored. (The warning is necessary to deal with the circumstance where the ‘extra’ information might be necessary to appropriately interpreting the received instance.)

There is some danger in ignoring data. HL7 should come up with a policy indicating whether this should be allowed or not. If allowed, there should also be a policy about the use of warnings. (In the absence of warnings, critical information could be ignored. However, the presence of warnings could get very annoying very fast.

• The message might be accepted and the data integrated. If this is done, care must be taken that the receiving system is able to handle the additional data. For example, if more repetitions of an attribute are sent than the specification allows, and the receiver chooses to accept the data, then the receiver must be able to display the data accepted to the user as is done with ‘standard’ data. The system must also have a mechanism for dealing with circumstances where it needs to retransmit the information stored to ensure that the outgoing messages it transmits remain valid. I.e. If it accepts 7 repetitions inbound, but is only allowed to send 5 repetitions, the application must be able to determine what data to filter to ensure that the outgoing instance remains valid.

When performing tests, it is important to test both initial ‘request’ messages, as well as ‘response’ messages, including the ability to handle non-valid responses. I.e. sending systems should be able to handle errors in all types of acknowledgement/response messages as sent by a receiver.

As a receiver, it is acceptable to process elements that are included in a specification, even if those elements are not included or permitted as part of the specification. Similarly, it is acceptable to proceed with processing even when mandatory elements are missing from the input message. I.e. It is not an error to successfully process data that is included in a message, even if the specification says the data is not supposed to be there or there is data missing. If the decision is made to process the data rather than ignoring it or raising an error, the receiving application must use caution:

• It must ensure that the data processed is handled in the same manner as any data which was expected as part of the specification
• It must ensure that functions which rely on the data are able to be executed. For example, a system which requires an identifier to query data cannot accept a ‘create’ request for data which is missing a mandatory identifier.
• If the system retransmits information in subsequent messages, it must ensure that outgoing messages remain compliant with the specification, despite the data it has accepted. For example if the specification for both the received message and the outgoing message allow for 2 to 5 repetitions, but the receiver accepts an instance that contains only one instance or 7 instances, it must still comply with the 2 to 5 repetitions for the outgoing message to remain compliant.

If an application chooses to ignore unexpected additional information and there are receiver responsibilities to the interaction, the response message sent should include a warning message indicating that the additional information has been ignored. (This is important so that the sender realizes that not all of the transmitted information has been accepted.)

Throughout many of these tests, there is a reference to “the specification”. This can actually refer to many different levels. It can refer to the balloted standard, to a realm-specific balloted variant, to a conformance or implementation profile, to datatype flavors and to templates. Instances are expected to comply with all specifications with which they declare support.

Many of the following test cases refer to the ability to “display” information. In most cases, this will be the use to which information received by messages will be put. However, if the purpose of the application is to persist, print, summarize, or otherwise manipulate, then the word “display” should be inferred to mean these other things instead. The key consideration is that the application should be able to ‘process’ the data in an equivalent manner to any other data that it processes, whatever the type of processing might be.

General requirements

There are a number of behaviors which should be tested which are completely independent of which HL7 version 3 messaging specification is being implemented and which apply to all elements within a v3 specification, both attributes and associations. Examples of these behaviors include:

Extensions

For applications which send extensions in foreign namespaces, verify that all such extensions appropriately derive from RIM attributes or RIM associations. I.e. The instance conveyed must be properly derived from the RIM, whether extension or not.

Verify that systems which declare support for profiles which use extensions are capable of capturing and sending and/or receiving and displaying the extension elements.

Versioning

Verify that sending systems appropriately declare the ‘oldest’ version with which their instance is compatible using the various version attributes, including:

• ITS version
• Batch/Message version
• Interaction version (as part of the interaction identifier)
• MessageType version (as part of the typeId attribute)

Conformance

The implementation being tested should provide a conformance statement declaring for every attribute, association and property which is optional in the underlying specification whether the system supports the concept (has marked it as ‘required’) or does not support the concept (has marked it as ‘not permitted’). For the purpose of testing, all elements marked as supported should be treated as if they were required by the underlying specification, and all elements marked as non-supported should be treated as if they were ‘not permitted’ in the underlying specification.

Verify that the sending application is able to capture all required attributes and associations in its user interface, and either does not capture, or does not transmit, any attributes and associations marked as not permitted.

Verify that the receiving application is able to parse and display all required attributes and associations in its user interfaces. Verify that the application is capable of functioning with all “not permitted” attributes and associations either present or absent from the instance, and when present, that those not-permitted items are ignored.

Handling of null flavors

Verify that null flavors can be captured by the user interface, transmitted, parsed and successfully rendered for all attributes and attribute properties which are not mandatory. (For non-mandatory properties where the ITS does not support null flavors, the test may be skipped.) Test the same characteristics for all non-mandatory associations.

Applications are expected to support all null flavors for all datatypes. For example, administrativeGender may have a null flavor of PINF (positive infinity).

Suggest adding constraints to the abstract datatype specification stating that: PINF and NINF are only permitted for datatypes derived from QTY. OTH is only permitted for datatypes derived from QTY or CD.

Mandatory elements

Verify that it is not possible to cause an application to send an instance where a mandatory element is missing or populated with a null flavor. For example, try recording or updating a piece of information marked as mandatory such that no value is specified or a null flavor is asserted. The interface should not permit it.

For receiving interfaces, verify that if a null flavor or missing value is transmitted to the receiver, that it is either capable of handling and storing the null flavor, or is able to appropriately detect the error in the transmitted instance.

Constraints

Test that the conditions of constraints are met. For multi-clause constraints (e.g. Condition1 and condition2; Condition 1 or condition2), test each combination of allowed values. I.e. Test where condition 1 is true, and condition 2 is true; condition 1 is true and condition2 is false; condition 1 is false and condition 2 is true, etc. For conditions involving less-than/greater-than comparisons, perform the test with values exactly equal, slightly less and slightly more.

In some cases, a constraint may be applied to an attribute, datatype property or association which constrains the allowed value for that datatype. In those cases, the constraint takes precedence over the normal expectations for the element when subjecting it to testing.

Minimum & maximum repetitions

Verify that ‘sending’ systems always capture at least the minimum number of repetitions either by requiring the user to specify at least that many values (or if the element is not mandatory, null values).

Ensure that all attributes and associations with a minimum cardinality of “1” which are not mandatory require the user to specify a value or select a null flavor.

Test that receiving applications are able to successfully receive, process and display the minimum number of repetitions and maximum number of repetitions of all attributes and associations. Also test that they either reject, ignore or successfully receive, process and display instances which contain fewer than the minimum number or greater than the maximum number of repetitions of attributes and associations.

Note: There should be no circumstances where an application is expected to implement a message specification which allows for an unbounded (infinite) number of repetitions. All systems will by definition have to place some sort of finite limit. By not declaring a maximum, it is assured that different systems will make different assumptions and therefore be incompatible. If during testing a non-limited repeating attribute or association is found, the underlying specification or profile should be updated to include a limit.

The v3 Generator tool should be modified to create a warning message for any interaction which references an attribute with unconstrained repetitions. We might want to do the same for any specification that references an attribute which doesn't reference a datatype flavor or other constraint putting limits on the repetitions of its properties.

Update modes

Verify that sending applications only use the update modes supported by the underlying specification, if any for all attributes and associations.

Ensure that receiving applications are able to handle at least the update modes supported by the underlying specification, and either handle or raise error messages for or ignore non-supported update modes.

History handled

Verify that applications are capable of capturing, transmitting, receiving and displaying history information for each element where the History flag is supported.

General association considerations

The following types of tests only apply to associations, not elements.

Realm

Ensure that the realm associated with each instance is declared in the root element. For systems that support multiple realms, ensure that the receiving system is able to handle transitions of realm at any association.

The requirement that realm be declared for the root element should be expressed in the RIM.

All tests of vocabulary and CMETs on an application should be performed using the realms which the system declares support for.

Ensure that systems which receive instances referencing realms they do not support reject the instance (if it has receiver responsibilities) or ignore it after logging the error (for notifications and other interactions with no receiver responsibilities.)

Choices

Ensure that both sending and receiving applications are able to support all of the possibility values in a choice.

For repeating associations targeting a choice, ensure that receiving applications are able to handle instances where there are random combinations of target classes. E.g. choice 2, then 1 then 3 then 1 then 1 again, etc.

Recursions

Ensure that systems are capable of capable of capturing, sending, receiving and displaying recursive associations up to the level of nesting supported by the specification

Note: Any implementable specification which allows recursive associations must indicate a limit on the maximum depth of recursion that must be supported by applications. Every application will have some limit on the recursions that can be supported. If no limit is identified by the specification then applications will be incompatible. If during testing a non-limited recursive association is found, the underlying specification or profile should be updated to include a limit.

Similar to repetitions above, the v3Generator should raise warnings about the presence of unconstrained recursions in message designs, and perhaps in referenced datatypes as well. Implementing this may need to wait until there is a standardized mechanism for indicating a limit on recursion depth.

Repetitions

Ensure that receiving systems are not dependent on the order in which associations are transmitted. E.g. Send associations in random order according to their time, sequenceNumber and/or priorityNumber. The ability of the receiving system to display the data in a logical order should not be impacted.

General Attribute considerations

The following types of tests only apply to attributes, not elements.

Attribute Specializations

Test that receiving systems are capable of accepting any of the allowed specializations of the datatype included in the specification. For example, if the specification has a datatype of ED, the receiving application must appropriately handle an incoming type of ST.

Vocabulary

Ensure that all sending systems are able to either:

• Directly capture each of the codes approved for use for each attribute by the realm(s) which the system supports; or
• Directly capture alternative codes with sufficient granularity that they can be translated to each of the codes approved for use for each attribute by the realm(s) which the system supports

It’s not clear whether the granularity requirement applies or not. If not, it means that data gathered will not necessarily represent the full semantic range which the HL7 specification desires. For example, if the messaging specification requires the capture of ‘Gender’, is it legitimate for the original data gathering to be captured in a codeset limited to ‘female’ and ‘other’? The vocabulary documentation in the methodology should make this clear.

Ensure that all receiving systems are able to extract the HL7-approved code for the realm(s) supported for each attribute regardless of where it appears in the translation hierarchy. (Applications are permitted to extract non-approved codes which they support natively if those natively supported code-systems appear lower in the translation hierarchy than the HL7 realm-approved code system.)

When the code system is transmitted, ensure that all code system OIDs correspond to code systems which have been registered with HL7, including local code systems.

For attributes with ‘small’ (<10) codes, particularly those where the codes are likely part of the decision making behavior of the receiving application, verify receiver application behavior with each of the allowed codes

Vocabulary Strength

For attributes with coding strength of CNE, verify that the sending application requires a selection from the specified code-set, and where the attribute is null, allows the selection of ‘other’, which should be transmitted as a null flavor. I.e. The sending system should not be capable of transmitting a local code or original text without specifying an HL7-approved code.

For attributes with a coding strength of CWE, ensure that interface allows capture of alternate codes and/or original text in addition to the approved code-set. Ensure the receiver is capable of capturing the same.

The methodology requires more explicit rules about exactly what CNE means and how it differs from CWE, particularly in the right of systems to make use of local translations and to send original text. Guidance on when to send original text, when to send display name and when to send both would also be helpful.

Identifiers

Ensure that when ‘common’ identifiers are transmitted, they use the OID found in the HL7 registry for that type of identifier.

AFAIK this is "guidance", not a requirement at this point in time. Rene spronk 08:03, 18 Feb 2006 (CST)

Collections

Verify that senders transmit information in LIST attributes ‘in order’ according to the order defined by the specification. Similarly, ensure that receivers retain the order of LIST elements and are capable of conveying the order information in their displays (either by displaying them in the same order or by some other means).

Verify that receivers are not dependent on receiving SET and BAG information in any particular order by sending data in more or less random order and verify that the application is still able to present information in a semi-logical or consistent manner.

Verify that both the sending and receiving application are capable of handling duplicate values for LIST and BAG attributes.

Verify that the sending system is not capable of entering or transmitting duplicate values for SET attributes.

For both of the above tests, ensure that applications are using the ‘equality’ rules defined by the abstract datatypes specification, rather than exact value equality.

Fixed and Default values

For those realms or environments which do not require that all fixed and default values be transmitted, ensure that the receiving application appropriately interprets the data as if the default or fixed value had been present if the value is omitted from the instance.

For those realms which require that fixed and default values be transmitted::

• Verify that the sender explicitly populates all default and fixed values (with the exception of those where the default or fixed value is a null flavor of “No Information” (NI)).
• Verify that the sender declares the typeId for the root message/batch element, as well as each time the message type change, including the root element for each wrapper, payload and CMET.

A decision is required on whether default and fixed values should be transmitted, as it has significant impact on how applications can process instances. Suggest requiring that all values which are not defaulted or fixed at the RIM level should be required to be specified in the instances. The only cost is a slight increase in the size of the message instances being transmitted. In the grand scheme, this is a small price to pay to allow for transforms and processing which function based on typeCodes, classCodes and moodCodes rather than transient element names.

Datatype Lengths

At present most HL7 v3 tools do not support capturing lengths associated with datatypes and datatype components. However, support for this information does exist in the HL7 data-model and in the future tools will be capable of capturing it. The following rules apply to those specifications where minimum and maximum lengths exist.

We need to get tools capturing this information. In some cases, minimum and/or maximum lengths should be assigned within the RIM and abstract datatype specifications.

Verify that it is not possible for sending systems to create instances where the length of the non-null content within an attribute or datatype property is less than the minimum length or greater than maximum length. (Remember that lengths are based in characters, not bytes.)

Verify that receiving systems are capable of accepting and rendering information with the minimum and maximum lengths. Further, verify that if data is received which exceeds the maximum lengths that the application behaves gracefully. For example, if the specification has an upper limit of 10 characters, and the application receives several million characters, the application should not fail, but should either reject the message, ignore the content or truncate the content (and should ideally raise warning messages if it performs one of the latter.)

Datatypes

Several of the HL7 datatypes have additional semantics and behaviors which must be appropriately tested. Some of the sections below list multiple datatypes. In general the tests described apply to all of the datatypes listed. However, in some cases, datatype specializations place constraints on the use of some components that will render some of the tests non-applicable.

ANY

Ensure that both the sending and receiving system is able to comply with the datatype tests for all defined datatypes. I.e. For every attribute define as type ANY, sender and receiver must be able to transmit CD, BL, AD, TEL, ED, GTS, MO, etc. Applications must also be able to manage complex combinations of types, such as PIVL<PQ>, IVL<UVP<TS>>, LIST<HIST<RTO<MO,PQ>>>, etc.

Note: Implementation-level specifications will likely wish to constrain exactly what specializations of ANY are permitted.

BL

Verify that systems are able to capturing, transmit, receive and render null values in addition to ‘true’ and ‘false’. In addition, any logical functions performed with the boolean value must take into account that they are working with 3-value logic, not 2-value logic. I.e. True and null = null, True or null = True, etc.

ED

Verify that systems are capable of capturing, transmitting, receiving and rendering exceptionally large (multiple gigabyte) lengths of content, regardless of underlying MIME type.

Verify that both sending and receiving systems are able to handle all of the MIME types marked as ‘required’ in the abstract datatypes specification, as well as any of the ‘recommended’ and ‘indifferent’ MIME types for which the application has claimed support.

Ensure that the sending system never produces instances containing a MIME type which the abstract specification has marked as ‘deprecated’.

Ensure that both sender and receiver are capable of communicating and managing circumstances where the language of the ED differs from the default for the realm.

Verify that senders and receivers are capable of supporting data compressed using any of the compression mechanisms allowed by HL7.

Verify that senders and receivers are capable of conveying references to information using a variety of TEL reference types, including Fax-back, FTP, HTTP, SMTP, etc.

Ensure that systems are capable of producing, transmitting, accepting and verifying the integrity of ED content as well as referenced ED content according to all possible types of Integrity Check Algorithm. Receivers should be tested with both valid and invalid checksums, and must appropriately identify and deal with non-validating data. Checksums should work on embedded XML within an ED, including variations of non-significant white-space, encoding of empty elements, etc.

The abstract datatype specification should provide guidance on the canonicalization algorithm to be used prior to calculating an integrity-check value for XML content.

Ensure that systems are capable of functioning with any combination of reference and content with or without thumbnail

For systems which support v2 of the datatypes, verify that an unlimited version of translations between different media types and different languages is supported, including multiple translations of a representation, as well as sequential translations of A translated to B translated to C, etc.

NOTE: Unconstrained, the full ED datatype cannot be implemented by any real system as it allows for both infinite recursions and infinite repetitions of translations. Any implementable specification should include constraints on the number of repetitions and depth of recursion expected to be supported.

ST

In the absence of explicit limits, verify that systems are capable of capturing, transmitting, receiving and rendering exceptionally large (multi-gigabyte) strings.

Ensure that both sending and receiving systems are able to capture the language associated with the string attributes and properties.

STT

For applications supporting v2 of the datatypes specification (and thus the Translatable String datatype), check that STT attributes and properties comply with all of the conformance tests of the ST datatype.

In addition, verify that an unlimited version of translations between different media types and different languages is supported, including multiple translations of a representation, as well as sequential translations of A translated to B translated to C, etc.

NOTE: Unconstrained, the full ST datatype cannot be implemented by any real system as it allows for both infinite recursions and infinite repetitions of translations. Any implementable specification should include constraints on the number of repetitions and depth of recursion expected to be supported.

SC

Verify that SC attributes and properties comply with all conformance tests of the ST datatype. In addition, verify that the sending system is capable of capturing a code for each string.

Verify that the sending system never transmits a code without also sending an accompanying string.

Ensure that systems are capable of capturing, transmitting, receiving and displaying both the string and the original text for the attribute or property should the two values be different.

Consider the following changes in the abstract datatypes specification: In the abstract datatype specification, add an assertion that SC.data = SC.code.originalText. Also add a constraint to SC in the XML datatype specification that originalText is not permitted in the code of an SC (given that it would just be duplicate information)

Ensure that the communication of the ‘code’ portion complies with all of the rules associated with the coded datatypes

CD, CE, CV, CS

Verify that sending and receiving systems are capable of dealing with the maximum possible length of any code and code-system which has been registered with HL7. Ensure that both sending and receiving systems can handle originalText with lengths of several gigabytes.

Verify that both sending and receiving systems are able to capture originalText in a variety of media including text, audio, video, scanned image, etc. Also verify that the full set of tests for ED are met for the originalText property.

Verify that applications are able to convey codeSystemNames, versions and displayNames which are several gigabytes in length.

Suggest that in the abstract datatypes specification codeSystemName be constrained to 150 characters, version constrained to 30 characters and display name constrained to 40 characters at the abstract datatypes level.

Ensure that the receiving system is able to display appropriate labels for codes even if the display name is not permitted.

To ensure that the recipient human users can extract the meaning of an instance even if they don’t have a copy of the code system used available to them (because of licensing, technology, time or other access constraints), consider requiring in the abstract datatypes specification that either originalText or displayName or both be mandatory when transmitting codes.

Verify that senders and receivers are able to handle both inverted and non-inverted concept roles when sending qualifiers.

Verify that sending systems are only capable of sending qualifiers specifically designed for use with the underlying code system. I.e. free-hand mixing and matching of codes and qualifiers is not permitted by the user-interface.

Verify that an unlimited version of translations between is supported, including multiple translations of a single code, as well as sequential translations of A translated to B translated to C, etc. Similarly, verify that an infinite number of qualifiers, an qualifiers of qualifiers, etc. is also supported.

NOTE: Unconstrained, the full CD datatype cannot be implemented by any real system as it allows for both infinite recursions and infinite repetitions of translations and qualifiers. Any implementable specification should include constraints on the number of repetitions and depth of recursion expected to be supported.

II

Ensure that sending systems can never populate the root with a string that does not follow the string rules for OID or GUID or match one of the HL7-reserved identifiers.

Is there actually any intention of HL7 creating reserved identifiers? If so, for what, and when? We should not have both OIDs and reserved identifiers for a given concept, thus we can’t use reserved identifiers for any identifier type or code system to which we’ve already issued an OID.

Verify sending systems follow the rules for encoding extensions for “common identifiers” in terms of punctuation and other formatting.

Verify that receiving systems are able to appropriately label displayable identifiers even in the absence of assigningAuthorityNames.

Ensure that receiving systems reference the ‘displayable’ property to determine whether to display a particular identifier by default. (Drill-downs or menu options to allow the display of “non-displayable” identifiers are acceptable.)

Ensure that sending and receiving systems are capable of dealing with identifiers where the root, extension and/or assigningAuthorityName are several gigabytes in length.

Suggest placing an upper limit in the abstract datatypes specification on root of 100 characters, extension of 30 characters and assigning authority name of 100 characters within the abstract datatypes specification.

TEL

Ensure that systems are able to capture, transmit, receive and display telecom information with all of the allowed URL schemes including mllp and nfs.

Ensure that the sender constructs addresses which comply with the URL scheme specified. Ensure that the sender is able to detect invalid URL schemes if the application actually depends on using the URL. (I.e. If the application will be dialing or otherwise accessing a URL, it must be able to detect badly constructed URLs.) URL tests should include complex constructs such as international phone numbers with hard pauses and extensions, sub-references with escaped spaces within URLs, etc.

Ensure that the address can handle multiple gigabytes strings

Suggest constraining address length in the abstract datatypes specification to 30 characters for tel, fax and modem and 300 characters for all other schemes at the abstract datatype level.

Verify that the application is able to capture and transmit or receive and display the usablePeriod for the address to the full level of sophistication supported by the GTS. (Refer to the GTS datatype for recommendations on how to test the usablePeriod component.)

Verify that the application is able to capture and transmit or receive and display multiple uses for the same telecommunication address. Furthermore, when handling collections of addresses, it should be capable of dealing with multiple addresses with the same usage codes.

Verify that the application allows conflicting usage codes to be sent for a single address. E.g. “primary home” and “vacation home”.

Suggest that constraints be added in the abstract datatypes specification that prohibit conflicting codes, though the only two I could see are HP and HV. All of the other combinations are theoretically valid.

AD

Test that both sender and receiver are able to capture, exchange and render address information at a variety of levels of granularity:

• A single string representing the entire address
• A simple string broken up with delimiters
• A simple mixed text string where some components (e.g. state, country, postal-code) are identified while others are left as non-delimited text (should include intermixed tags and non-tagged content).
• Encoded where all content is contained within address parts
• Fully encoded where the most discrete possible components are used to separate pieces of address information. (I.e. sending “Appt”, “21”, “B”, 125th, “Street” and “SW” as separate address parts in the string “Appt. 21B, 125th Street S.W.”.

If working with datatypes release 2, verify that codes can be sent and received for all codable datatype parts, including: Unit Designator, Country, County/Parish, City, Delivery Installation Type, Delivery Mode, Direction, Street Type and State. Also confirm that the sender populates the string portion of the SC when transmitting a code.

Verify that an infinite number of address parts can be supported and that duplicate address parts are supported (i.e. multiple street lines, cities, postal codes, etc. can be sent). Also check that the same information can be captured at different levels of granularity (e.g. both SAL and BNR)

Suggest that in the abstract datatypes specification the maximum number of parts within an address be restricted to 30. Also suggest that a constraint exist that only the explicitly coded parts of delimiter, additional locator and street address line be allowed to repeat. (That means that SAL could repeat, but BNR could not). Finally, restrict that either a type can be used or its specializations, but not both. I.e. you can’t have SAL and BNR in the same instance.

Verify that the position information present in an instance is retained by receiving applications unless the ‘isNotOrdered’ property is true. I.e. If country is listed first in the address, then it will be listed first when printing the address label. This is necessary to support addresses from different countries which may require a different ordering of components.

Ensure that, in the absence of constraints in the specification, that all address parts can contain strings of several gigabytes in length and that they are also able to convey the language associated with each address part.

Suggest that in the abstract datatypes specification the maximum length of individual address parts be limited to 100 characters, and that the overall length of non-tagged content within an address be limited to 500 characters. Also suggest that ‘language’ be not permitted for address part types. (It theoretically exists, but I can’t imagine a system that would capture it as useful information.)

Verify that the application is able to capture and transmit or receive and display the usablePeriod for the address to the full level of sophistication supported by the GTS. (Refer to the GTS datatype for recommendations on how to test the usablePeriod component.)

Verify that the application is able to capture and transmit or receive and display multiple uses for the same address. Furthermore, when handling collections of addresses, it should be capable of dealing with multiple addresses with the same usage codes.

Verify that the application allows conflicting usage codes to be sent for a single address. E.g. “primary home” and “vacation home”.

Suggest that in the abstract datatypes specification constraints be added that prohibit conflicting codes: specifically both HP and HV; and more than one of ABC, SYL and IDE. All of the other combinations are theoretically valid.

EN, PN, ON and specializations

Test that both sender and receiver are able to capture, exchange and render name information at a variety of levels of granularity:

• A single string representing the entire name
• A simple string broken up with delimiters
• A simple mixed text string where some components (e.g. given, family) are identified while others are left as non-delimited text (should include intermixed tags and non-tagged content).
• Encoded where all content is contained within name parts

If working with datatypes release 2, verify that codes can be sent and received for all codable datatype parts, including: Prefix and Suffix. Also confirm that the sender populates the string portion of the SC when transmitting a code.

Verify that an infinite number of name parts can be supported and that duplicate name parts are supported (i.e. multiple prefixes, suffixes, given names and family names can be sent).

Suggest that in the abstract datatypes specification the maximum number of parts within a name be restricted to 10.

Verify that the position information present in an instance is retained by receiving applications. I.e. If a ‘family name’ is listed first in the name, then it will be listed first when displaying the name unless specific sort rules have been applied. This is necessary to support names from different countries which may require a different ordering of components.

Ensure that, in the absence of constraints in the specification, that all name parts can contain strings of several gigabytes in length and that they are also able to convey the language associated with each address part.

Suggest that in the abstract datatypes specification the maximum length of individual name parts be limited to 50 characters, and that the overall length of non-tagged content within an address be limited to 300 characters.

Verify that the application is able to capture and transmit or receive and display the validTime for the name to the full level of sophistication supported by IVL<TS>. (Refer to the IVL and TS datatypes for recommendations on how to test the validTime component.)

Ensure that the system can support associating multiple qualifiers for each name part, including conflicting parts such as Birth and Spouse

Suggest that constraints be added in the abstract datatypes specification that prohibit conflicting qualifiers from being specified for the same name part. Examples include: Birth and Spouse; VV, AC, PR, NB,LS, CL, TITLE

Question: Aren’t professional, academic and legal status types of titles? I.e. Don’t they all apply to the name as a whole? If so, shouldn’t they be specializations of TITLE?

Verify that the application is able to capture and transmit or receive and display multiple uses for the same name. Furthermore, when handling collections of names, it should be capable of dealing with multiple names with the same usage codes.

Verify that the application allows conflicting usage codes to be sent for a single name. E.g. “alphabetic” and “syllabic”.

Suggest that constraints be added in the abstract datatypes specification that prohibit conflicting codes: specifically more than one of ABC, SYL and IDE. All of the other combinations are theoretically valid.

INT

Ensure that the system is capable of supporting the full range of integers including both positive and negative values, and can support numbers running into the thousands of digits.

Suggest that in the abstract datatypes specification the maximum number of digits to be supported by an integer be restricted to 15.

Ensure that the system is capable of capturing null values, including the distinct flavors PINF and NINF. Ensure that mathematical comparisons take into account null flavors for calculations, such as: x > Null = unknown, x < PINF = true, x > NINF = true, PINF < PINF = unknown; x + unknown = unknown; x + PINF = PINF; PINF/PINF = Unknown

REAL

Apply all of the tests used for integer. In addition, verify that the system is capable of expressing fractions with thousands of decimal places, or thousands of trailing expressing fractions with thousands of decimal places, or thousands of trailing zeros. I.e. n*E999999, or n*E-999999, etc. Also allow for thousands of significant decimal places.

Suggest that in the abstract datatypes specification the effective number of significant decimal places of real numbers be restricted to 15, and that the exponents be restricted to a range of +/- 200.

RTO

If not otherwise constrained, ensure that the sender and receiver can both handle any of the possible quantity datatypes as numerator and denominator. E.g. RTO<TS, MO>, RTO<PQ, INT>, etc.

Ensure that the receiving system appropriately renders information distinguishing the numerator from the denominator, and that any mathematical manipulation does not combine the numerator and denominator quantities.

PQ

Ensure that the value portion of the PQ passes all of the tests for Real.

Test that both sender and receiver are capable of handling any of the possible codes from UCUM, including complex rations such as kg*[lb_av]/uN^3.

Ensure that receiving applications that perform computational comparisons between PQ measurements are able to include the semantics of the units in their measurements. E.g. 1 m/s = 3.6 km/hr

We need to standardize on either case sensitive or case-insensitive UCUM

Verify that sending and receiving systems support an infinite number of translations.

Verify that translations support all of the characteristics of codes

Verify that PQ units and can gigabytes in length

Suggest that the maximum length for PQ units be 30 characters

MO

Ensure that the value portion of the MO passes all of the tests for Real.

Ensure that systems support all forms of currency allowed by the code system

TS

Ensure that both sender and receiver are able to capture time information at a variety of levels of significance, corresponding to the following grammar: YYYY[MM[DD[hh[mm[ss[.s[s[s[s]]]]]]]]][+/-ZZZZ]

Ensure systems which populate timezone appropriately modify the timezone transmitted based on time of year and daylight savings time use.

Ensure that comparisons between timestamps take into account timezone. For example, 20050101123000.0000-0700 < 20050101133000.0000-0900. Similarly, the answer to the question “is 20050101 < 20050102?” is unknown. (depending on the timezone, it could be before or after.

IVL

Apply all the rules for the datatypes of the components being transmitted.

Ensure that systems are able to handle various combinations of components, such as “high + low”, “high + center”, “low + width”, etc.

Ensure systems can handle one of the transmitted components being null, and when performing decision logic can still make inferences based on the known values. For example, the question “is 2 part of the range [3..unknown]” is false, while “is 4 part of the range [3..unknown]” is unknown.

Ensure that the system is capable of capturing, sending and/or receiving and displaying high-closed and low-closed and including them in decision logic. I.e. “is 3 part of the range [3..unknown]” is true if lowClosed is true, false otherwise.

HIST

Ensure that the systems can support conveying either the validTime or the controlActIdRef or both. If both are sent, verify that the validTime corresponds to the ControlAct.effectiveTime of the control act referenced by the controlActIdRef property.

UVP

Ensure that systems can handle circumstances where the probability is null

PIVL

Verify that systems can handle phase specifications that are missing or are well in the past or well in the future. (And can take into account leap-years and other information to translate the phase to current time for calculation and comparison purposes.)

Verify that systems can handle periods expressed in various units of time including milli-seconds, seconds, minutes, hours, days, weeks, months and years.

For systems following v2 datatype specifications, ensure that sending systems transmit either frequency or period, but not both.

Verify that the “calendar aligned” flag can be sent and received, and is taken into account when performing calculations and comparisons

Verify that the institutionSpecified flag can be captured and displayed.

EIVL

Ensure that systems support both positive and negative offsets

GTS

Ensure that systems are able to support the full suite of set operations between different types of timing specifications, including union, intersection, interleave, periodic hull, etc.

Ensure that systems can support various combinations of intervals, sets, periodic intervals and event-related intervals.

Ensure that systems can capture, transmit, receive and display GTSs made up of 1000s of set operations on different types of timing specifications, including further nested timing specifications.

Note: Because GTS allows an infinite number of set operations, and infinite nesting of set operations using GTS itself, the full GTS type is not implementable. Instead, constraints on GTS should be used.

Suggest that the maximum nesting depth and maximum number of sequential set operations within a GTS be limited to 10.

ITS-level Tests

This section contains tests that are specific to the ITS used to convey v3 instances

XML ITS Tests

When constructing and parsing messages using the HL7 XML ITS, compliance with underlying XML requirements must be maintained. This includes:

• Verifying that instances specify the appropriate HL7 v3 namespace when constructing instances
• Verify that receiving systems can handle various mechanisms of specifying namespaces for an element, including specifying a default namespace for the instance, as well as using namespace prefixes.
• Verify that sending systems appropriately escape characters as required, including ampersands (&), less-than (<), greater-than (>), and quotation marks (‘”).
• Verify that receiving systems are able to handle data which has been escaped using different mechanisms, including use of #PCDATA, references (e.g. &) as well as character references (e.g. )
• Verify that receiving systems are able to handle all supported v3 character-sets, including:
• Verify that receiving systems appropriately ignore processing instructions, non-significant white-space, comments, etc.
• Verify that receiving systems retain all significant white-space, as defined in the w3c XML specification.
• Verify that receiving systems are able to ignore any DTD and/or schema definitions defined within the instance, except where DTD instances are used to define entities referenced elsewhere within the message.
• Verify that the sending system places any ‘extension’ elements into the appropriate namespace for that extension as based on the profiles which it implements
• Verify that the receiving system appropriately strips out all ‘extension’ elements from foreign namespaces that are not defined by profiles referenced by the instance and recognized by the receiving application.
• Verify that the receiving system does not strip out foreign namespace elements sent within ED elements, including Act.text, Act.certificateText, Observation.value, etc. where the MIME type for ED type allows XML data.
• Verify that the sending application appropriately identifies the character-set in use as defined within the w3c XML specification
• Verify that the sending application does not make use of any character-set which HL7 has declared “deprecated”. (Preference is to use either US-ASCII or UTF-8)
• Verify that the receiving application is able to appropriately process content received in both the US-ASCII and UTF-8 character sets
• Verify that the receiving application is able to appropriately detect all other character sets supported by the XML specification, and either properly process their contents or raise the necessary internal error indicating lack of support for the character-set
• Verify that the receiving application is able to process instances both with and without the <?xml?> declaration.
• Verify that none of the above variations have any impact on the ability of any digital signature mechanism to be appropriately enforced

UML ITS Tests

<Grahame – Do you have content to throw in here?>

Transport-level Tests

General Transport Protocol Tests

<At present this section is empty. Anyone familiar with the transport protocol is welcome to add appropriate test cases specific to the protocol.>

ebXML Transport Protocol Tests

<At present this section is empty. Anyone familiar with the transport protocol is welcome to add appropriate test cases specific to the protocol.>

MLLP Transport Protocol Tests

<At present this section is empty. Anyone familiar with the transport protocol is welcome to add appropriate test cases specific to the protocol.>

Web Services Transport Protocol Tests

<At present this section is empty. Anyone familiar with the transport protocol is welcome to add appropriate test cases specific to the protocol.>

Transmission-level Tests

These tests deal with functionality related to the transmission layer of messaging, including both the contents of the transmission layer, as well as the dynamic behavior required to interoperate at the transmission level. This document assumes that applications are dealing with release 2 of the transmission specification.

General comments

Transmission-level information is an exception in that it is generally not exposed to the user of the receiving application. In fact, it is typically not persisted on a long-term basis. Persistence only exists to perform basic communication functions such as the detection of duplicate instances and the matching of acknowledgement interactions to their original requests. The primary function of transmission is delivery of information. Receiver applications are therefore expected to extract and use the information needed to ensure a message is successfully delivered to the target recipient, and that any acknowledgements find their way back to the appropriate application.

Any or all of the information in the transmission wrapper may be displayed to users in the event of communication errors.

Recipient tests

Try sending a message to a receiver where it is not identified as the correct recipient application id. The message should be rejected with an error code of xxx

Verify that the sender correctly populates the sending application id and other sender information it has claimed conformance for. Verify that it also populates the ‘reply to’ if so configured.

Non-supported communication parameters

Try sending messages values that are not supported by the receiver for:

• ITS Version
• Message.interactionId
• Message.processingCode (Only test with codes other than ‘T’ – Training if you are sure that: a) the system won’t support the other mode; or b) There is a way to reverse the storage of any content submitted as part of the test (including audit-type information to prevent any impact on production data.)
• Message.processingModeCode
• Message.responseModeCode
• Message.version

In all cases, the application should respond with an error code

Try sending messages with unrecognized content in attentionLines. The receiver application should ignore any attention information it does not recognize.

Duplicate id

Resend a copy of a previously successfully submitted interaction, keeping the message id the same. The receiver should either:

1. Return the same application acknowledgement response as initially returned in response to the original interaction
2. If sufficient time has expired, re-process the interaction and attempt to make the update again. (This should only happen if a significant period of time has elapsed since the original interaction. Ideally at least 24 hours, better if even longer (weeks or months).

Respond to

Test that when ‘respond to’ is unspecified, application acknowledgement is sent to ‘sender’.

Test that when ‘respond to’ is specified, application acknowledgment is sent to ‘respond to’, not ‘sender’

Test that when ‘respond to’ is not recognized or cannot be communicated with that an ‘accept NAK’ is sent to the ‘sender’ (provided that the incoming message requested that ‘accept NAKs’ be sent with the acceptAckCode.

Accept ACKs and NAKs

Verify that Accept ACKs and NAKs (if requested by the initial interaction’s ‘acceptAckCode’) are sent back to the ‘sending’ application, even if a ‘reply to’ application id is specified.

Ensure that sending systems which initiate interactions with no receiver responsibilities, but which have ‘acceptAckCode’ values other than ‘NE’ are able to receive ‘accept NAKs’ (and where supported, ‘accept ACKs’) back from the target system.

Ensure that sending systems which request accept NAKs are able to appropriate process the negative acknowledgement, either by retrying (in case the negative acknowledgement contained a Reject (AR) instead of an unrecoverable error (AE); with a discrete limit on the number of retries) or by logging the failure and bringing it to a user’s or administrator’s attention.

If ‘accept NAKs’ are not supported in the chosen acceptAckCode, then ensure that both the sender and receiver are capable of communicating any transmission-level errors in the appropriate application acknowledgement interaction, as indicated by an interaction's receiver responsabilities.

Profiles

Verify that the receiver is capable of processing messages where no profileIds are specified.

Verify that the receiver is capable of processing messages where only ‘non-supported’ profileIds are specified. (I.e. Send a message with a profileId that is random junk.)

Verify that the receiver is capable of recognizing a profileId that is supported even when the profile is embedded somewhere in the middle or at the end of a list of non-supported profileIds.

Verify that the receiver is capable of recognizing multiple supported profileIds and either supporting the extensions communicated by all profiles or supporting the extensions defined by the first listed profile.

Sequence # protocol

The following tests only apply if the systems involved declare support for the sequence number protocol.

Try sending a sequence number of -2 in an outgoing request. The link should be frozen.

Try sending a sequence number of -2 in an acknowledgement. The link should be frozen.

Try sending a sequence number in an outgoing request which is lower than the most recently sent outgoing sequence number. The link should be frozen

When messages are being transmitted, break the connection or otherwise interfere with the transmission such that one of the messages initiated by the sender is not delivered to the receiver. When the subsequent message is successfully delivered, the receiver should respond with an accept NAK indicating the sequence number of the previously successful message. The sending application should then resend the message that was missed and then continue sending messages in order.

Try sending a number lower than the last successfully processed sequence number – after sending a sequence number of -1. Message is successfully processed, sequence number is re-set to begin counting at new sequence number

Try sending a number several steps higher than the last successfully processed sequence number – after sending a sequence number of -1. Message is successfully processed, sequence number is re-set to begin counting at new sequence number

When the sequence number has reached into the 1000s due to successful processing, try acknowledging with a sequence number of “1”. The initial sender should either begin retransmitting back with message number 1, or should freeze the link. (It should not ‘die’.)

Suggest that the discussion of sequence number indicate that it only applies where either acceptAckCode is ‘AL’ (Always) or where acceptAckCode is ‘NE’, responseMode is ‘I’ (Immediate) and the outgoing interaction’s has receiver responsibilities that all have associated interactions. Rationale: The sequence # protocol depends on their being an immediate response to every outgoing message. These identified constraints are the only two mechanisms which ensure that such a combination will exist.

Non-matching interaction ids

Try submitting an interaction using the XML ITS whose outer tag references an interaction identifier that differs from the interaction id specified in the interactionId attribute within the XML. The receiver should either:

• Send a transmission error response indicating that the interactionId was invalid
• Log the message as an error; or
• Process the message based on the interactionId as communicated in the message. I.e. The interactionId in the attribute takes precedence over the interactionId in the tag. (Note that schema validation will not work correctly if this approach is used.)

Acknowledgements

Try sending an application acknowledgement for a message with an identifier that was never sent by the sender. (I.e. acknowledge a message that doesn’t exist.) The receiver of the acknowledgment should either respond with an error message indicating that acknowledged id was not recognized (if the acknowledgement itself supports acknowledgements), or should log the event as an error.

Try requests with different types of ‘acceptAckCode’ some with errors and some without. Ensure that the receiver only sends accept-level acknowledgements for the circumstances requested (i.e. only errors, only non-errors, both or neither.)

Discussion: There is no such thing as an application acknowledgement in v3. Any interaction sent as a receiver responsability is an Application Response. Given that the use of respondTo may result in an Application Response being sent to an "unexpecting" application, the receipt of an "unexpected" Application Response should NOT result in any errors. If the addressing is correct, it should be processed, unless a message with the same ID has been processed before. --Rene spronk 00:01, 25 Aug 2005 (CDT)

Error messages

Confirm that the only types of messages sent in AcknowledgementDetail are those related to the successful transmission of the message. I.e. No business errors or warnings should be sent at this level.

Test how a receiver behaves when it receives an AcknowledgementDetail which refers to a message location which is unknown. The application should either log an error, or (preferably) process the error message and ignore the location information.

Test how a receiver behaves when it receives an AcknowledgementDetail which refers to a message location which is known (including references to nested recursions, specific occurrences within repeating elements, etc.) The application should either ignore all location information of that type, or should highlight the places within the message instance to which the error corresponds. I.e. Verify that the application highlights the correct field if it highlights anything.

Confirm how a receiving application appropriately handles errors, warnings and information messages at the ‘transmission’ level. I.e. It should appropriately display or log all information, but should not mistake warnings and information messages for errors.

Test how an application behaves when it receives an acknowledgement with a typeCode of ‘AA’ but which also contains an AcknowledgmentDetail with a typeCode of ‘E’. The application should either:

• Log or display an error message
• Treat the message as if it were an “ER” due to the presence of errors
• Look to the interaction identifier (for application-level acknowledgements) to determine whether the interaction has been successfully processed and behave accordingly.

We should have a constraint that says that AcknowledgementType can only be ‘AA’ if there are no AcknowledgmentDetails with a typeCode of ‘E’, and can only be ‘AR’ or ‘AE’ if there is at least one AcknowledgementDetails with a typeCode of ‘E’.

Test the behavior of an application to error responses with acknowledgement types of ‘AR’ (error reject) and ‘AE’. The system should retry (where it supports retrying) ‘AR’ messages, but not ‘AE’ messages.

Batch tests

Try submitting a batch containing ‘request’ messages where some of the requests process successfully and others process unsuccessfully. The receiver should successfully handle the mixture of successes and responses, communicating back the acknowledgements for each. (I.e. Each message within the batch should be treated as an independent unit of work.)

Try submitting a batch where the batch totals do not correspond with the values within the message. The entire batch should be rejected with a transmission-level error. I.e. No messages should be processed if the batch totals don’t match. (If a batch contains sub-batches, only the sub-batches whose totals don’t match should be rejected. Other sub-batches should be processed. Again each is an independent unit of work.)

Need a way of ‘qualifying’ each total so we know what it’s a total of

Combo of good & bad messages – processed independently

Trigger Event (Control-Act)-level Tests

Try sending a request message that creates history (e.g. Suspend prescription, revise allergy, etc.) where ControlAct.code is not specified. When subsequently querying the record in history, the ControlAct.code for the ControlAct associated with the message sent should be populated with the Trigger Event code associated with the interaction of the message.

Try sending a request message where the ControlAct.code is populated with a different value than the trigger event code associated with the interaction for that message. One of two things should happen:

1. An error message should be raised indicating that the interaction id and ControlAct.code do not agree; or
2. The ControlAct.code should be ignored and the message should be processed based on the trigger event associated with the interaction. This code should be visible in subsequent query responses showing history.

Query Tests

The following tests apply to all query/response type interactions

Query result sets

Try performing a query that returns no matching rows. The querying application should deal with the issue gracefully, either displaying no data, displaying a “no records found” indication, or initiating business error logic should the lack of matching rows indicate a business error.

Try performing a query that returns multiple matching rows when only one row is expected but the message specification wasn’t explicitly constrained to only allow a single row response. The application should either gracefully display all of the rows or should invoke business error logic if the presence of multiple rows signifies a business error. In no circumstances should it only display a single row unless the sort order of the results is explicit in the query definition and it is known that only the first or last row is required based on that sort order.

Try performing a query where the matching of some of the rows is “unknown”. E.g. A query using a specific date of birth as a query parameter matching on rows where the date of birth is only known to the year or year and month, or where the date of birth is unknown; a time-range query where the time of the matching row is unknown, etc. The query should include the rows flagged in some matter as ‘possible matches’.

We need to add support for two data elements to the RIM:

• On queries, an indicator of whether “unknown” matches should be included in the result set, or only exact matches
• On query result sets, an indicator of whether a given result row is an exact match or is a ‘possible’ match based on unknown/null values

Suggest it is too late for such additions. Some domains are already defining query parameters to support more sophisticated systems that have, for example, confidence-level matching. Moreover, specification of how parameters are valued for things like wildcard searches are currently under the control of individual domain committees. Testors should therefore refer to the particular query specification that they are working with.

Try submitting a query whose parameters are not valid against the schema. If the application chooses to process the query anyhow, verify that it is able to echo back the query parameters “as submitted”, and that the querying application is also able to cope with the non-validating query parameters. (The second step of this test can be skipped if the sending application cannot be forced to send non-schema-valid instances as part of regular operations.)

Query continuation

Submit a query restricting the result-set to a small number of rows at a time. Query responder should appropriately return only the number of rows requested, also indicating the total number of matching rows.

Submit a query indicating a start row number somewhere in the middle of a result-set, without having retrieved intervening rows. The result should be returned starting at the requested row.

Submit a query continuation request to return the remaining rows in a result-set when the data underlying the query response has changed. (E.g. submit a query for a patient’s prescriptions and request the first 2 rows. Then add 10 prescriptions for the patient. Then send a query continuation to return the remaining prescriptions for the query.) The query response should only include rows that would have been part of the original result-set and should not be affected in any way by the modifications to the data. (Some applications might choose to include a Control-Act level warning or information message indicating that the result-set has or may have changed since the query was originally processed.)

Submit a query continuation request for rows preceding the rows recently retrieved. E.g. Start with a query returning 10 rows. Then retrieve rows 73 through 98. Then retrieve rows 30 through 47. The responding application should provide the rows requested.

Query behavior

Try submitting a query with a bad value for a key field. (I.e. A key that does not exist.) Receiver should respond with an application acknowledgement either showing no rows, or with an error communicated in the ControlAct indicating that the specified key does not exist.

Generic Dynamic behavior

Attempt to submit an update for a record using an identifier that does not exist. The receiver should respond with an application error indicating that the record could not be found.

Attempt to submit an update for a record using an “out-of-date” version identifier. (The distinction between standard identifiers and version identifiers will be described in a proposal to be posted by Charlie McCay.) The receiver should respond with an application error indicating that the identified record has changed since it was last queried and that it must be re-queried prior to the updates being submitted. The submitting application should either perform the necessary query and resubmission automatically or prompt the user to do so.

Attempt to submit a request for a user that does not have the necessary permission to perform the requested action. The receiver should respond with an application error indicating that the user/application/supervisor/facility/whatever does not have the necessary permissions.

Attempt to submit a request that results in multiple errors and warnings. All errors and warnings should be exposed to the user.

Attempt to submit a request that violates business rules, such as submitting a reason code that is valid within the overall value-set, but is not deemed “appropriate” according to business rules. An error should be highlighted in the ControlAct of the application response.

We need a mechanism to identify a particular field within a message that resulted in a business error, in much the same way as we can identify a location in a message that caused a transmission error.