Patent Application
20200058408
The present embodiments are directed generally to improving clinical pathways for disease treatment using hereditary data. More particularly, the embodiments relate to analyzing hereditary data to predict diseases and optimize clinical pathways for treatment, and identify hereditary patterns that are shared by multiple family trees in order to recommend treatments to unrelated patients.
Predicting and diagnosing diseases is, for doctors, a task that involves years of study and practice in order to perform effectively. Recent advances in computer networking have allowed doctors to communicate research and patient outcomes to other doctors who may be working with similar patients. Although the communication of information can provide more resources for doctors to create clinical pathways for treating patients, oftentimes the amount of information can be overwhelming for a doctor to filter through. Additionally, when treatment by a doctor is initially dependent upon a patient first coming to the doctor with an issue, the patient may have already missed opportunities for earlier treatment.
The present disclosure is directed to systems, methods, and apparatuses for linking medical records and predicting medical conditions to improve clinical pathways toward treatment. In some embodiments, a method is set forth for providing notifications based on changes to electronic medical records (EMRs). The method can be performed by a computing device and include steps of: receiving event data that identifies a medical event associated with a first patient that is related to a second patient, and receiving measurement data associated with the second patient. The steps can also include identifying a code for classifying the measurement data, wherein the code represents measured medical data that falls within a range of values represented by the code. The steps can further include determining, at least partially based on the code, a probability of the medical event occurring for the second patient, and sending, to a network device associated with the second patient, a notification that relates to the medical event. Additionally, the steps of the method can include receiving relationship data that indicates a familial linkage between the first patient and the second patient. Determining the probability of the medical event occurring for the second patient can be further based on the familial linkage between the first patient and the second patient. Determining the probability of the medical event occurring for the second patient can include determining a first weighted score for the relationship data and a second weighted score for the code that classifies the measurement data. The method can include steps of modifying a first electronic medical record (EMR) associated with the first patient to include an event identifier corresponding to the medical event, and modifying a second electronic EMR associated with the second patient to include the event identifier and the probability of the medical event occurring for the second patient. The steps can further include receiving, from a remote storage device, research data that provides a correspondence between the measurement data and the medical event. Determining the probability of the medical event occurring for the second patient can be further based on the research data.
In other embodiments, a non-transitory computer-readable medium is set forth. The non-transitory computer-readable medium can store instructions that when executed by one or more processors of a computing device, cause the computing device to perform steps that include: identifying first relationship data corresponding to a first group of persons, wherein the first group of persons is identified in electronic medical records (EMR) accessible to the computing device. The steps can also include identifying second relationship data corresponding to a second group of persons, wherein the second group of persons is identified in electronic medical records (EMRs) accessible to the computing device, and wherein the second group of persons are non-relatives of the first group of persons. The steps can further include determining, based on one or more data points associated with the first group of persons and the second group of persons, a similarity measure between the first group of persons and the second group of persons. Additionally, the steps can include, in response to a determination that the similarity measure satisfies one or more criteria, identifying, using the first relationship data and the second relationship data, a common familial linkage between at least two persons in each of the first group of persons and the second group of persons. The steps can further include identifying, in a first electronic medical record (EMR) of the first group of persons, a medical event that is at least partially influenced by the identified common familial linkage, and modifying a second EMR of the second group of persons to include an identifier for the medical event. Identifying a medical event that is at least partially influenced by the identified familial linkage can include determining whether the medical event is associated with a hereditary disease. Additionally, identifying the medical event that is at least partially influenced by the identified familial linkage can include identifying the medical event in at least two EMRs of the first group of persons. In some embodiments, the steps can include modifying a third EMR of the second group of persons to include the identifier for the medical event, wherein the second EMR and the third EMR identify the at least two persons of the second group of persons. The first relationship data can describe at least part of a genealogy of the first group of persons. The common familial linkage is a degree of separation in an ancestral lineage of the at least two persons.
In yet other embodiments, a computing device is set forth as having one or more processors and a memory. The memory can be configured to store instructions that when executed by one or more processors cause the one or more processors to perform steps that include modifying a first electronic medical record (EMR) of a first patient to include treatment data, the treatment data corresponding to a treatment received by a first patient having a condition. The steps can also include identifying, using familial linkage data accessible to the processor, a second EMR of a second patient that is a relative of the first patient, wherein the familial linkage data identifies a first degree of separation in ancestral lineage of the first patient and the second patient. The steps can further include determining, using the familial linkage data, that the second patient has, or is at risk for having, the condition, including: identifying, in a database accessible to the one or more processors, other patients that are non-relatives of the first patient and the second patient and have the condition, and comparing the first degree of separation to a second degree of separation in ancestral lineage of the other patients. The steps can further include modifying a second EMR associated with the second patient to include prospective treatment data that identifies the treatment received by the first patient. Determining that the second patient has, or is at risk for having, the condition can include using the familial linkage data to determine a probability that the second patient has, or will have, the condition. The steps can also include identifying common medical data in the first EMR and the second EMR, and determining, using a data table accessible to the processor, a weight of the common medical data as an indicator of the condition. The common medical data can be a code that is identified in both the first EMR and the second EMR, and the code can represent measured medical data that falls within a range of values represented by the code. The steps can further include generating a report file that identifies the condition and the prospective treatment data, and causing the report file to be transmitted to a personal computing device associated with the second patient. Identifying other patients that are non-relatives of the first patient and the second patient can include analyzing a plurality of family trees stored in the database using a deep neural network. Identifying other patients that are non-relatives of the first patient and the second patient can include analyzing a plurality of family trees stored in the database using a Hidden Markov Model.
A “computing device” can be implemented in numerous ways (e.g., such as with dedicated hardware) to perform various functions discussed herein. A computing device can be a controller that employs one or more microprocessors that may be programmed using software (e.g., microcode) to perform various functions discussed herein. Examples of computing device components that may be employed in various embodiments of the present disclosure include, but are not limited to, conventional microprocessors, application specific integrated circuits (ASICs), and field-programmable gate arrays (FPGAs).
In various implementations, a processor or controller may be associated with one or more storage media (generically referred to herein as “memory,” e.g., volatile and non-volatile computer memory such as RAM, PROM, EPROM, and EEPROM, floppy disks, compact disks, optical disks, magnetic tape, etc.). In some implementations, the storage media may be encoded with one or more programs that, when executed on one or more processors and/or controllers, perform at least some of the functions discussed herein. Various storage media may be fixed within a processor or controller or may be transportable, such that the one or more programs stored thereon can be loaded into a processor or controller so as to implement various aspects of the present invention discussed herein. The terms “program” or “computer program” are used herein in a generic sense to refer to any type of computer code (e.g., software or microcode) that can be employed to program one or more processors or controllers.
In one network implementation, one or more devices coupled to a network may serve as a controller for one or more other devices coupled to the network (e.g., in a master/slave relationship). In another implementation, a networked environment may include one or more dedicated controllers that are configured to control one or more of the devices coupled to the network. Generally, multiple devices coupled to the network each may have access to data that is present on the communications medium or media; however, a given device may be “addressable” in that it is configured to selectively exchange data with (i.e., receive data from and/or transmit data to) the network, based, for example, on one or more particular identifiers (e.g., “addresses”) assigned to it.
The term “network” as used herein refers to any interconnection of two or more devices (including controllers or processors) that facilitates the transport of information (e.g., for device control, data storage, data exchange, etc.) between any two or more devices and/or among multiple devices coupled to the network. As should be readily appreciated, various implementations of networks suitable for interconnecting multiple devices may include any of a variety of network topologies and employ any of a variety of communication protocols. Additionally, in various networks according to the present disclosure, any one connection between two devices may represent a dedicated connection between the two systems, or alternatively a non-dedicated connection. In addition to carrying information intended for the two devices, such a non-dedicated connection may carry information not necessarily intended for either of the two devices (e.g., an open network connection). Furthermore, it should be readily appreciated that various networks of devices as discussed herein may employ one or more wireless, wire/cable, and/or fiber optic links to facilitate information transport throughout the network.
The term “user interface” as used herein refers to an interface between a human user or operator and one or more devices that enables communication between the user and the device(s). Examples of user interfaces that may be employed in various implementations of the present disclosure include, but are not limited to, switches, potentiometers, buttons, dials, sliders, a mouse, keyboard, keypad, various types of game controllers (e.g., joysticks), track balls, display screens, various types of graphical user interfaces (GUIs), touch screens, microphones and other types of sensors that may receive some form of human-generated stimulus and generate a signal in response thereto.
It should be appreciated that all combinations of the foregoing concepts and additional concepts discussed in greater detail below (provided such concepts are not mutually inconsistent) are contemplated as being part of the inventive subject matter disclosed herein. In particular, all combinations of claimed subject matter appearing at the end of this disclosure are contemplated as being part of the inventive subject matter disclosed herein. It should also be appreciated that terminology explicitly employed herein that also may appear in any disclosure incorporated by reference should be accorded a meaning most consistent with the particular concepts disclosed herein.
In the drawings, like reference characters generally refer to the same parts throughout the different views. Also, the drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention.
The described embodiments relate to using patient and family tree data to predict, diagnose, and/or treat medical conditions. Typically, medical diagnosis occurs on or after the time of patient testing, therefore it is possible that a medical condition is likely to be present in a patient prior to testing. Oftentimes this can mean harm to the patient may have already occurred as a result of a delayed diagnosis of the medical condition. However, the embodiments herein are set forth to optimize the prediction and treatment of certain medical conditions by employing algorithms for comparing patient records and family trees.
Information about a patient can be stored as medical records in an electronic medical record (EMR) system, which can be a server device or other computing device connected on a network. When multiple patients of the same family have data in the EMR system, the EMR system can link the electronic medical records to form a family tree where the multiple patients and their respective information can be identified. Once a family tree has been created, the EMR system can provide notes and alerts regarding hereditary patterns that can affect a patient. A family tree can be one or more data files that can describe patients' medical histories, relationships (i.e., familial linkage), genetics, lifestyles (e.g., smoker, diet, habits, exercise routine, and/or any other lifestyle descriptors), and/or environments (e.g., location, and/or any other suitable environmental descriptors). When a patient's medical record is updated to include a disease or other condition, the EMR system can calculate a probability that a related person in the same family tree will have the same disease or condition and provide a notification to the related person, doctor, or entity responsible for the related person. Furthermore, the EMR system can access the family trees of other patients and filter the family trees in order to find family trees that are most similar according to certain algorithms. The EMR system can then make predictions about patients in the similar family trees and offer data regarding diagnosis and treatment. Furthermore, if a patient in one family tree is successfully treated according to a particular clinical pathway, recorded in the EMR system, a patient in a similar family tree can be notified of the successful clinical pathway in order that the other patient can take advantage of this for the better outcome.
Predictions regarding the occurrence of a disease for a patient can be based on calculations performed by the EMR system using EMR data related to the patient and individuals in the patients' family. The algorithm for predicting such occurrences can start with identifying a family tree of the patient, which can be stored by the EMR system or by another device that is accessible to the EMR system. If the patient is not associated with a family tree accessible to the EMR system, the EMR system can connect the patient to an existing family tree of a relative or create a new family tree. This will allow the EMR system to track diseases and event occurrences for the patient using data provided by the patient, a patient's relative, a doctor, a medical provider, or any other suitable source of medical data relates to the patient. When the EMR system is updated with this provided data, the data can be linked to the patient's relatives in the family tree, and each patient's relative and/or relative's doctor can receive a notification about the update. Such notifications can be handled by a thread or software running on the EMR system.
The ability of the EMR system to make predictions, diagnosis, and treatment recommendations can be extended outside of a patient's family tree to other family trees using a prediction engine running on the EMR system. The prediction engine can analyze patient data and code certain portions of data based on how they relate to particular diseases. Patient data can be coded according to certain clinical guidelines instead of using raw patient data. Certain metrics of patient data that are measured and fall within a particular range of values can be labeled with a code that is based on the range in which the data falls into. The number of codes can be less than a total number of possible values for the particular metric. For example, a metric for a patient's systolic blood pressure (SBP) can have a range of any positive numbers, and the codes can be “0” for 120 SBP or less, “1” for 120-139 SBP, “2” for 140-159 SBP, “3” for 160-179 SBP, and “4” for 180 or greater SBP. In some embodiments, each code and/or metric can be weighted for indicating the code's and/or metric's importance when predicting a patient's risk for a particular disease. For example, blood pressure can be of greater weight than a patient's height when predicting a diagnosis of cardiovascular disease (CVD). The EMR system can also create a distance mapping for identifying the patients in a family tree that have the most number of similar codes. The distance mapping can not only be used to predict diseases for other relatives in the family tree, but also be compared to distance mappings of other family trees in order to spot similarities that would help the EMR system predict disease occurrences in other families. Furthermore, codes for treatment outcomes can be added to the patient's data in order for the EMR system to also recommend treatments to patients who have not received certain treatments but who are associated with a family tree having a similar distance mapping.
The EMR database 102 can receive one or more of the familial linkage data 120, 126, 132. It should be noted that familial linkage data can be included in the EMRs 118, 124, and 130, respectively, or be separate from the EMRs 118, 124, and 130 in some embodiments. Each familial linkage data 120, 126, and 132 can provide information about the ancestral lineage 134 of each patient P1, P2, and PN, thereby allowing the EMR database 102 to build a family tree 104 from the familial linkage data 120, 126, and 132. In some embodiments ancestral lineage 134 can be derived from third party data, such as an ancestry database that is populated manually by patients. In other embodiments, the ancestral lineage 134 can be derived from the genetic data provided in the EMRs 118, 124, and 130. In yet other embodiments, familial linkage data can be provided by patients or doctors that are aware of the ancestral lineage 134 of patients (e.g., P1 is a parent of P2, and P2 is a parent of PN). By maintaining the family tree 104, the EMR database 102 can predict, diagnose, and help treat diseases that have hereditary dispositions. For example, if EMRs 118 indicate that P1 has a hereditary condition that skips a generation, the EMR database 102 can use this information to provide P3 with information regarding the hereditary condition along with a clinical pathway for treating the condition. Furthermore, if P1 suffers from a disease that is not presently known to be hereditary, the EMR database 102 can identify other family trees where multiple relatives are suffering from the same disease and calculate a risk of P2 or P3 suffering from the same disease. The EMR database 102 can then share the information about the risk of the disease, as well as offer treatment recommendations for the disease. The treatment information can be derived from accessing treatment information about the patients in the other family trees who also had the disease, but who had been treated since their diagnosis.
Using the data ranking 310, relevant information about the patients identified in the data ranking 310 can be used to provide further correlations between the input data 302 and the data ranking 310. Such relevant information can include past medical history and sequence of events that lead to the diagnosis of a heart attack. The prediction engine 304 can use the information about the patients identified in the data ranking 310 to create output data 312 that can be used to predict, diagnose, and/or treat the patient for a disease or condition, such as a heart attack. The output data 312 can include a personalized report that is anonymous as to which patients' data was used to help generate the output data 312. However, the output data 312 can identify information in the EMRs of the patients, which can be relatives or non-relatives of the patient identified in the input data 302.
Once the input data 402 has been converted into coded data 406 by the data converter 404, distance calculations can be performed by the prediction engine 408 using the coded data 406. The coded data 406 can include patient data from an existing patient database and/or data regarding a patient who is new to the system 400. Differences between coded data can be measured in order to find a patient or group of patients with similar codes. For example, for any parameter of medical information, codes can vary from −(M−1) to (M−1), where M is the total number of possible codes for a parameter (e.g., differences of SBPs from
D
i=Σn=1Nwn(1+|xn|)|x| (1)
The value wn can be an optional weight that is assigned to one or more parameters of medical information. The weight of a parameter can change based on the disease or condition that the medical information is being used to predict or diagnose. For example, codes for SBP can be weighted greater than the codes for gender of a patient when comparing patient information to determine a risk for heart disease. Furthermore, codes for age can be weighted greater than codes for TCL when comparing patient information to determine a risk for Alzheimer's. The patients having the lowest total coded distance “D” when compared can be considered the most similar patients and ranked accordingly. A probability of a particular event occurring can be calculated as:
The probability (p) can be equal to the total number of retrieved similar items (K) divided by the number of records in which the disease or event is present (L). In various embodiments, the value of K may be user-selected or selected automatically, e.g., based on one or more pre-defined thresholds. The total number of similar items can change depending on the particular event being considered and/or a threshold set for the coded distance between patients. For example, rarer medical events, or medical events that are less prevalent in a database accessible to the prediction engine 408, can have a higher threshold for the coded distance Di in order that more output data 412 can be provided for rarer diseases. Additionally, a lower threshold for coded distance Di can be used for more common events, or medical events that are more prevalent in a database accessible to the prediction engine 408. In this way, for the lower threshold, more codes of patients must be more similar in order for them to be ranked as similar patients for a particular medical event or condition. In some embodiments, treatment data can be included in the input data 402. Treatment data can be designated by at least two codes per treatment. For example, treatment for Alzheimer's can include shunt surgery, and a patient's medical information can indicate whether the patient underwent shunt surgery with a “0” for no, and a “1” for yes. In this way, when distance measurements are taken to find a group of patients that have the most similar medical information, the prediction engine 408 can also identify the patients who have been treated for a particular condition. If a treatment was successful, each of the similar patients can be notified that someone with a similar medical history has been successfully treated for their disease.
Initially, the prediction engine 504 can use the coded patient data of a patient in the input patient data 510 to find similar patients in a patient database 508. Two patients can be considered similar when their distance measurement is within a distance measurement threshold, as determined by the prediction engine 504 or other source. The prediction engine 504 can use the coded patient data of the input data 502 and compare it to the coded patient data of first patient data 512, second patient data 514, and/or N patients' data 516, where N is any real positive whole number. The patients from the patient database 508 can be ranked in a data ranking 506 according to their similarity to the coded patient data of the input data 502. Once a number of patients have been identified and filtered from the patient database 508, their patients' family tree data can be used to determine similarities in the family tree data in the input patient data 510 and the family tree data of the filtered patients. Similarities between patients in a family tree can be determined by using distance measurements between relatives. A patient identified in the data ranking 506 that is most similar to their relatives can be used to help the prediction engine 504 provide output data 516 regarding a patient identified in the input data 502, as well as the patient's relatives. The prediction engine 504 can provide output data 516 for alerting the input patient about medical risks gleaned from analyzing the patient database 508, and alerting relatives of the input patient regarding certain medical risks. When an input patient is different from their relatives according to the distance measurements, the prediction engine 504 can still find patients in the patient database 508 that are most similar to the input patient identified in the input data 502. The identified patients can then be filtered to determine which of the identified patients have relatives that are most similar to the relatives of the input patient. In this way, although the patients and relatives are different, similarities in medical information can be identified between the patients and relatives thereby allowing the prediction engine 504 to help predict, diagnose, and treat diseases of the patients and relatives.
Other techniques may be used to identify similar family trees as well. For example, in some embodiments, prediction engine 504 or another component may employ deep neural networks to analyze patients in the patient database 508 to identify relevant details (e.g., patient codes, etc.) across family trees and identify similar family trees. In other embodiments, Hidden Markov Models (HMM) may be employed to identify similar family trees. For example, a sequence of measurements of a patient may be used as input to the HMM. In yet other embodiments, DNA sequence matching techniques may be employed on DNA sequences associated with members of family trees to identify similar family trees. The complete DNA code in human cells may, in effect, tell the story of a biological family tree. The three most common types of DNA testing work differently by analyzing different parts of DNA code, e.g., Y-DNA, mtDNA and atDNA, any of which can be used to trace a biological family tree. Additionally or alternatively, any combination of DNA sequencing and other aforementioned techniques for identifying similar family trees, such as clinical measurements, may be used to identify similar family trees.
In some embodiments, once a similar family tree is identified, a clinical pathway may be identified using the similar family tree, e.g., using an HMM such as a second order HMM. Suppose that for each identified similar family tree, there are a sequence of clinical measurements, x=x1, x2, . . . , xN, and a corresponding clinical pathway sequence, y=y1, y2, . . . , yN. For a current family tree, a HMM may be employed to define the following, p(x1, x2, . . . , xN, y1, y2, . . . , yN), for any such clinical measurements and corresponding clinical pathways of a family tree. In some embodiments, the most likely, or “best,” clinical pathway for x may be determined using the following equations:
where q(x|y) and e(x|y) represent, respectively, transition and emission probabilities and may be estimated using various maximum likelihood estimation techniques.
Techniques described herein have been described in terms of predicting various ailments and identify treatment plans/preventative measures for existing patients. However, this is not meant to be limiting. In various embodiments, techniques described herein may be used for yet-unborn individuals. For example, in some embodiments, techniques described herein may be employed to automatically identify which vaccines should be provided to a new-born baby given their family tree and similar clinical pathways followed in similar family trees.
While several inventive embodiments have been described and illustrated herein, those of ordinary skill in the art will readily envision a variety of other means and/or structures for performing the function and/or obtaining the results and/or one or more of the advantages described herein, and each of such variations and/or modifications is deemed to be within the scope of the inventive embodiments described herein. More generally, those skilled in the art will readily appreciate that all parameters, dimensions, materials, and configurations described herein are meant to be exemplary and that the actual parameters, dimensions, materials, and/or configurations will depend upon the specific application or applications for which the inventive teachings is/are used. Those skilled in the art will recognize, or be able to ascertain using no more than routine experimentation, many equivalents to the specific inventive embodiments described herein. It is, therefore, to be understood that the foregoing embodiments are presented by way of example only and that, within the scope of the appended claims and equivalents thereto, inventive embodiments may be practiced otherwise than as specifically described and claimed. Inventive embodiments of the present disclosure are directed to each individual feature, system, article, material, kit, and/or method described herein. In addition, any combination of two or more such features, systems, articles, materials, kits, and/or methods, if such features, systems, articles, materials, kits, and/or methods are not mutually inconsistent, is included within the inventive scope of the present disclosure.
All definitions, as defined and used herein, should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and/or ordinary meanings of the defined terms.
The indefinite articles “a” and “an,” as used herein in the specification and in the claims, unless clearly indicated to the contrary, should be understood to mean “at least one.”
The phrase “and/or,” as used herein in the specification and in the claims, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and/or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and/or” clause, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, a reference to “A and/or B”, when used in conjunction with open-ended language such as “comprising” can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc.
As used herein in the specification and in the claims, “or” should be understood to have the same meaning as “and/or” as defined above. For example, when separating items in a list, “or” or “and/or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as “only one of” or “exactly one of,” or, when used in the claims, “consisting of,” will refer to the inclusion of exactly one element of a number or list of elements. In general, the term “or” as used herein shall only be interpreted as indicating exclusive alternatives (i.e. “one or the other but not both”) when preceded by terms of exclusivity, such as “either,” “one of,” “only one of,” or “exactly one of.” “Consisting essentially of,” when used in the claims, shall have its ordinary meaning as used in the field of patent law.
As used herein in the specification and in the claims, the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, “at least one of A and B” (or, equivalently, “at least one of A or B,” or, equivalently “at least one of A and/or B”) can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.
It should also be understood that, unless clearly indicated to the contrary, in any methods claimed herein that include more than one step or act, the order of the steps or acts of the method is not necessarily limited to the order in which the steps or acts of the method are recited.
In the claims, as well as in the specification above, all transitional phrases such as “comprising,” “including,” “carrying,” “having,” “containing,” “involving,” “holding,” “composed of,” and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases “consisting of” and “consisting essentially of” shall be closed or semi-closed transitional phrases, respectively, as set forth in the United States Patent Office Manual of Patent Examining Procedures, Section 2111.03. It should be understood that certain expressions and reference signs used in the claims pursuant to Rule 6.2(b) of the Patent Cooperation Treaty (“PCT”) do not limit the scope.
| Number | Date | Country | Kind |
|---|---|---|---|
| 16194146.3 | Oct 2016 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2017/076521 | 10/17/2017 | WO | 00 |
