Abstract: The described implementations relate to updating views in a database system. One implementation can identify an active view that retrieves records from a database and determine one or more physical tables in the database that are referenced by the active view. The implementation can track one or more columns in the physical tables that are used by the active view and identify a change to the physical tables in a transaction log of the database. If the change does not affect the one or more columns, the change can be treated as an ignorable change for the active view.

Abstract: The described implementations relate to updating views in a database system. One implementation can identify an active view that retrieves records from a database and determine one or more physical tables in the database that are referenced by the active view. The implementation can track one or more columns in the physical tables that are used by the active view and identify a change to the physical tables in a transaction log of the database. If the change does not affect the one or more columns, the change can be treated as an ignorable change for the active view.

Abstract: In one example, a phrase analyzer may analyze a text input stream to identify phrases contained in the text input stream. The phrase analyzer may receive a specification, which includes dictionaries of phrases and synonyms, and a specification of the phrases, or sequences of phrases to be matched. The phrase analyzer may compare the input stream to the specification and may produce, as output, an identification of which phrases appear in the input stream, and where in the input stream those phrases occur.

Abstract: The described implementations relate to updating views in a database system. One implementation can identify an active view that retrieves records from a database and determine one or more physical tables in the database that are referenced by the active view. The implementation can track one or more columns in the physical tables that are used by the active view and identify a change to the physical tables in a transaction log of the database. If the change does not affect the one or more columns, the change can be treated as an ignorable change for the active view.

Abstract: The described implementations relate to updating views in a database system. One implementation can identify an active view that retrieves records from a database and determine one or more physical tables in the database that are referenced by the active view. The implementation can track one or more columns in the physical tables that are used by the active view and identify a change to the physical tables in a transaction log of the database. If the change does not affect the one or more columns, the change can be treated as an ignorable change for the active view.

Abstract: The described implementations relate to updating views in a database system. One implementation can identify an active view that retrieves records from a database and determine one or more physical tables in the database that are referenced by the active view. The implementation can track one or more columns in the physical tables that are used by the active view and identify a change to the physical tables in a transaction log of the database. If the change does not affect the one or more columns, the change can be treated as an ignorable change for the active view.

Abstract: In response to receiving a request for data stored according to a first version of a data type, a second version of the data type supported by the requester is determined, and the requested data is transformed from the first version to the second version to provide access to the data.

Abstract: The described implementations relate to secure and verifiable data handling. One implementation can receive a request to add information from a drop-off site to a user account. The request can include a location element and a security element. This implementation can also obtain encrypted units of the referenced data from the drop-off site based upon the location element. This implementation can associate the information with the user account and store the security element.

Abstract: The described implementations relate to secure and verifiable data handling. One implementation can receive a request to upload information, wherein the information includes a referencing element and at least one blob of referenced data. This implementation can also receive a chunk of an individual blob. The chunk can include multiple blocks. Individual blocks can be hashed. Upon receipt of an indication that all chunks have been uploaded, this implementation can create an overall hash of the information from the block hashes rather than from the information.

Abstract: Described herein are techniques for enabling a patient to pre-register for a medical visit to a healthcare facility (e.g., a hospital) online. Also described herein are techniques that enable a hospital staff to pre-process a patient's pre-registration intake forms before the patient arrives for the medical visit at the healthcare facility. With some of the described techniques, the patient's pre-registration intake forms may have been customized to match the needs and desires of the healthcare facility, its departments, and/or the healthcare providers (e.g., nurses, physicians, etc.) taking care of the patient during the visit.

Abstract: In response to receiving a request for data stored according to a first version of a data type, a second version of the data type supported by the requester is determined, and the requested data is transformed from the first version to the second version to provide access to the data.

Abstract: At least one implementation described herein relates to evaluating queries structured according to a first format against one or more objects structured according to a second, different format without serializing the object. Typically, evaluating an XML (eXtensible Markup Language) query against a CLR (Common Language Runtime) object required serializing the CLR object and deriving an XML construct from the serialized data. The query is then be evaluated against the XML construct. In the described implementations, significant system resources are realized by creating an infoset model that maps properties of an object to an object infoset. The query is then evaluated using the infoset to locate object values and, thus, no serialization is required. Dynamically generated IL is used and re-used to efficiently perform subsequent evaluation steps on similar queries.

Abstract: Embodiments herein prevent or mitigate attacks on inverse query engines by providing safe mode routines that allow for the acceptance of third party messages and/or query expressions, as well as prevent trusted sources from accidental attacks. The mitigations fall into two categories: compile-time and runtime. Compile-time mitigations prevent query expressions from being accepted and compiled that are susceptible to known attacks. For example, the complexity of query expressions may be limited to functions with linear runtimes; constant memory usage; or ones that do not create large strings. Further, language constructs for the criteria in the query expression may not allow for nested predicates complexities. Runtime mitigations, on the other hand, monitor the data size and processing lengths of messages against the various query expressions. If these runtime quotas are exceeded, an exception or other violation indication may be thrown (e.g., abort), deeming the evaluation as under attack.

Abstract: Medical records may be evaluated in order to assign condition codes to the records in a medical vocabulary. In one example, the medical vocabulary contains a list of codes (e.g., numeric codes) that correspond to specific conditions, where each code is associated with a concept description. Text from a medical record may be used to form a query, and the query may be evaluated against the concept descriptions to determine which code(s) match the query. A code may be selected based on how well the description associated with that code matches the query. The process of converting text from medical records into queries, and then comparing the query to concept descriptions in a medical vocabulary, may be used to automate the process of assigning formal medical codes to arbitrary text records.

Abstract: In one example, a phrase analyzer may analyze a text input stream to identify phrases contained in the text input stream. The phrase analyzer may receive a specification, which includes dictionaries of phrases and synonyms, and a specification of the phrases, or sequences of phrases to be matched. The phrase analyzer may compare the input stream to the specification and may produce, as output, an identification of which phrases appear in the input stream, and where in the input stream those phrases occur.

Abstract: At least one implementation described herein relates to evaluating queries structured according to a first format against one or more objects structured according to a second, different format without serializing the object. Typically, evaluating an XML (eXtensible Markup Language) query against a CLR (Common Language Runtime) object required serializing the CLR object and deriving an XML construct from the serialized data. The query is then be evaluated against the XML construct. In the described implementations, significant system resources are realized by creating an infoset model that maps properties of an object to an object infoset. The query is then evaluated using the infoset to locate object values and, thus, no serialization is required. Dynamically generated IL is used and re-used to efficiently perform subsequent evaluation steps on similar queries.

Abstract: A scalable event notification system is provided. The event notification system manages the set of topics available for notification via a topic manager network. The event notification system transmits event notifications to event consumers via a subscription manager network. The configuration and operation of the subscription manager network may to reconfigured in response to changing load and fault conditions to facilitate the timely delivery of event notifications. The notification to subscribers also includes mechanisms to provide individual privacy and non-tampering of notifications. Notification may dynamically be delivered to alternative locations and localized to accommodate different natural languages.

Abstract: Implementations described herein relate to evaluating multiple queries represented in an opcode tree having opcode nodes and branch nodes. Each opcode node comprises an opcode that is a part of an opcode block derived from compilation of a query, the opcode block consisting of a linear sequence of opcodes. Opcode nodes are arranged in the tree according to location of its corresponding opcode in the opcode block with opcodes that occur earlier in the opcode block being represented at a higher tree level than subsequent opcodes. Only one opcode node corresponds to a common opcode block segment that is included in multiple queries. Executing the opcode tree against an input evaluates each of the multiple queries represented in the opcode tree.

Abstract: At least one implementation described herein relates to using multiple filter engines to optimize query processing. A filter engine comprises a general matcher and at least one optimized matcher, a matcher being a filter engine in its own right. When the filter engine receives an input, the input is analyzed to determine if it can be handled by the optimized matcher. While the general matcher is fully compliant with a query language, the optimized matcher only handles a subset of the query language. Therefore, inputs that can be processed in the optimized matcher are compared against fewer filters, making the filtering process more efficient. The filter engine may also process only a portion of an input in the optimized matcher and another portion of the input in the general matcher, which reduces processing overhead.

Abstract: The present invention extends to methods, systems, and computer program products for relaying messages through firewalls. A message relay negotiates first communication parameters with relay components inside a firewall and (potentially different) second communication parameters with applications outside the firewall. The message relay receives a message from an outside application in accordance with the second negotiated parameters and maps an electronic address in the received message to an inside application. The message relay transforms the message and sends the transformed message over an established connection through the firewall to a relay component in accordance with the first negotiated parameters. The relay component receives the transformed message and transforms the transformed message back into the message. The relay component delivers the message to the inside application in accordance with the second negotiated parameters.