DETAILED ACTION
The present office action represents a final action on the merits.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
This application claims the priority date of February 16, 2023.
Status of Claims
Claims 1-20 are amended and 1-20 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 10-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 10 is an independent claim and line 3 recites “the communication unit”. There is insufficient antecedent basis for this limitation. Examiner is interpreting “the communication unit” as “a communication unit”. Dependent claims 11-18 depend on claim 10 and there is insufficient antecedent basis for the limitation. Appropriate action is requested.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-9 are drawn to a method for correcting HL7 observation value types using regular expressions, which is within the four statutory categories (i.e., process). Claims 10-18 are drawn to a computing system for correcting HL7 observation value types using regular expressions, which is within the four statutory categories (i.e., machine). Claims 19-20 are drawn to a non-transitory computer-readable medium having instructions stored thereon for correcting HL7 observation value types using regular expressions, which is within the four statutory categories (i.e., machine).
Claims 1-9 recite a computer-implemented method for improving electronic data communication via a Health Level Seven International (HL7) standard, the computer- implemented method comprising:
receiving, by an HL7 interface engine implemented by one or more processors of a first a computing system and from a second computing system, as part of a clinical data acquisition flow through the HL7 interface engine, a medical coding string including a medical observation code, an initial data type, and an observation value;
determining, by a module implemented by the one or more processors and configured to interface with the HL7 interface engine, that the initial data type is not valid for the medical observation code, the module comprising one or more software units stored in one or more storage devices of the first computing system;
determining, by the module, a set of acceptable data types for the medical observation code using the medical observation code;
checking, by the module, a validity of the observation value with respect to each member of the set of acceptable data types for the medical observation code;
determining, by the module, that the observation value is valid for only a single acceptable data type of the set of acceptable data types for the medical observation code;
based on the determining that the observation value is valid for only the single acceptable data type, replacing, by the module, the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string; and
providing, by the HL7 interface engine, the updated medical coding string to at least one of a clinical repository, an analytics entity, or a utilization management entity as part of the clinical data acquisition flow through the HL7 interface engine.
Claims 10-18 recite a first computing system for improving electronic data communication via a Health Level Seven International (HL7) standard, the first computing system comprising:
one or more processors implemented in circuitry and in communication with the communication unit;
one or more memories storing processor-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
receiving, via an HL7 interface engine implemented by the one or more processors and from a second computing system, a medical coding string as part of a clinical data acquisition flow through the HL7 interface, the medical coding string including a medical observation code, an initial data type, and an observation value;
determining, using a module implemented by the one or more processors and configured to interface with the HL7 interface engine, that the initial data type is not valid for the medical observation code, the module comprising one or more software units stored in the one or more memories of the first computing system;
determining, using the module, a set of acceptable data types for the medical observation code using the medical observation code;
checking, using the module, a validity of the observation value with respect to each member of the set of acceptable data types for the medical observation code;
determining, using the module, that the observation value is valid for only a single acceptable data type of the set of acceptable data types for the medical observation code;
based on the determining that the observation value is valid for only the single acceptable data type, replacing, using the module, the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string; and
providing, by the HL7 interface engine, the updated medical coding string to at least one of a clinical repository, an analytics entity, or a utilization management entity as part of the clinical data acquisition flow through the HL7 interface engine.
Claims 19-20 recite a non-transitory computer-readable storage media having processor-executable instructions stored thereon for improving electronic data communication via a Health Level Seven International (HL7) standard that, when executed by one or more processors of a first computing system, cause the one or more processors to:
receive, using an HL7 interface engine implemented by the one or more processors and from a second computing system, as part of a clinical data acquisition flow through the HL7 interface engine, a medical coding string including a medical observation code, an initial data type, and an observation value;
determine, using a module implemented by the one or more processors and configured to interface with the HL7 interface engine, that the initial data type is not valid for the medical observation code, the module comprising one or more software units stored in one or more storage devices of the first computing system;
determine, using the module, a set of acceptable data types for the medical observation code using the medical observation code;
check, using the module, a validity of the observation value with respect to each member of the set of acceptable data types for the medical observation code;
determine, using the module, that the observation value is valid for only a single acceptable data type of the set of acceptable data types for the medical observation code;
based on the determining that the observation value is valid for only the single acceptable data type, replace, using the module, the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string; and
provide, using the HL7 interface engine, the updated medical coding string to at least one of a clinical repository, an analytics entity, or a utilization management entity as part of the clinical data acquisition flow through the HL7 interface engine.
The bolded limitations, given the broadest reasonable interpretation, cover a certain method of organizing human activity, but for the recitation of generic computer components (e.g., receiving patient information; managing patient information, in this correcting HL7 observation value types using regular expressions). The underlined limitations are not part of the identified abstract idea (the method of organizing human activity) and are deemed “additional elements,” and will be discussed in further detail below.
Dependent claims 2-9, 11-18, and 20 are similarly rejected because they either further define/narrow the abstract idea and/or do not further limit the claim to a practical application or provide as inventive concept such that the claims are subject matter eligible even when considered individually or as an ordered combination. These limitations only serve to further limit the abstract idea, and hence are nonetheless directed towards fundamentally the same abstract idea as independent claims 1, 10, and 19.
The dependent claims recite additional limitations, but these only serve to further limit the abstract idea, and hence are nonetheless directed towards fundamentally the same abstract idea as independent claims 1, 10 and 19.
The additional elements from independent claims 1 include:
one or more software units stored in one or more storage devices of the first computing system (apply it, MPEP 2106.05(f)).
The additional elements from independent claims 1, 10, and 19 include:
a first computing system (apply it, MPEP 2106.05(f)).
an HL7 interface engine (apply it, MPEP 2106.05(f)).
a second computing system (apply it, MPEP 2106.05(f)).
one or more processors (apply it, MPEP 2106.05(f)).
a module (apply it, MPEP 2106.05(f)).
the module comprising one or more software units stored in the one or more memories of the first computing system (apply it, MPEP 2106.05(f)).
The additional elements from independent claims 10 include:
one or more memories storing processor-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising (apply it, MPEP 2106.05(f)).
The additional elements in claim 19 include:
a non-transitory computer-readable storage media having processor-executable instructions stored thereon for improving electronic data communication via a Health Level Seven International (HL7) standard that, when executed by one or more processors of a first computing system, cause the one or more processors to (apply it, MPEP 2106.05(f)).
These additional elements, in the independent claims are not integrated into a practical application because the additional elements (i.e., the limitations not identified as part of the abstract idea) amount to no more than limitations which:
amount to mere instructions to apply an exception – for example, the recitation of “computing system”, “communication unit”, “HL7 interface engine”, “module”, and “one or more processors”, which amounts to merely invoking a computer as a tool to perform the abstract idea e.g., see Specification Paragraphs [0028], [0090], and [0051]-[0060] (See MPEP 2106.05(f)).
Furthermore, the claims do not include additional elements that are sufficient to amount to “significantly more” than the judicial exception because, the additional elements (i.e., the elements other than the abstract idea) amount to no more than limitations which:
amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields, as demonstrated by:
The Specification discloses that the additional elements are well-understood, routine, and conventional in nature (i.e., the Specification Paragraphs [0028], [0090], and [0051]-[0060] discloses that the additional elements (i.e., computing system, communication unit, a module, and one or more processors that are well understood routine, and conventional activities previously known to the pertinent industry (i.e., healthcare, correcting HL7 observation value types using regular expressions).
Dependent claims 2-9, 11-18 and 20 include other limitations, but none of these functions are deemed significantly more than the abstract idea because the additional elements recited in the aforementioned dependent claims similarly represent no more than systems, and methods to improve the transfer of medical coding information between clinical systems.
Thus, taken alone, the additional elements do not amount to “significantly more” than the above identified abstract idea. Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually, and there is no indication that the combination of elements improves any other technology, and their collective functions merely provide conventional computer implementation.
The application, is an attempt to organize human activity, using systems, and methods to improve the transfer of medical coding information between clinical systems. The inventive concept is the method for correcting HL7 observation value types using regular expressions, which is not patentable. Therefore, whether taken individually or as an ordered combination, claims 1-20 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 6-7, 10, 12, 15-16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mar-Yohana (U.S. Pub. No. 2023/0223119 A1) in view of Bess (U.S. Pub. No. 2020/0066392 A1) and Rai (U.S. Pub. No. 2024/0242799 A1).
Regarding claim 1, Mar-Yohana discloses a computer-implemented method, the computer- implemented method comprising (Paragraphs [0206] discuss computerized method for analyzing healthcare data.):
receiving, by a first computing system and from a second computing system, a medical coding string including a medical observation code, an initial data type, and an observation value (Examiner notes that the prior art does not explicitly state “first” or “second”, however, it references multiple systems.) (Paragraphs [0048], [0162]-[0165], [0187]-[0188] discuss analyzing patient electronic healthcare data and hardware to allow the platform to communicate with other systems via application programmable interfaces (APIs) creates a common representation of health data collected from all sources retrieved directly from other systems via API, the system assigns clinical diagnostic codes to all medical data, the standardized clinical codes that are assigned to all user health data can be used by the AI to more easily classify the data by code category.);
determining, by a module implemented by the one or more processors, that the initial data type is not valid for the medical observation code, the module comprising one or more software units stored in one or more storage devices of the first computing system (Paragraphs [0045], [0087], [0162]-[0165], [0188]-[0189] discuss the platform is a combination of software and hardware designed to provide a service that users can access through the internet web browsers and mobile devices, the system assigns clinical diagnostic codes to all medical data and any data that is not matched to a harmonized numeric unit profile is rejected.);
determining, by the module, data types for the medical observation code using the medical observation code (Paragraphs [0156], [0162]-[0165], and [0188] discuss the platform of the invention can automatically parse this data within the records and maps the data into the appropriate features, modules, and sections, for example using the platform's automated clinical data mapping capability and the system assigns clinical diagnostic codes to all medical data, and as data is collected it is matched to a harmonized numeric unit profile to make sure it is correct for the specific data type).);
checking, by the module, a validity of the observation value with respect to each member of the set of data types the medical observation code (Paragraphs [0160] and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and as data is collected it is matched to a harmonized numeric unit profile to make sure it is correct for the specific data type.);
determining, by the module, that the observation value is valid for data type of the data types for the medical observation code (Paragraphs [0160] and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and as data is collected from all sources it is matched to a harmonized numeric unit profile to ensures that the data and its related unit of measure matches the healthcare data standards for that specific data type.);
based on the determining that the observation value is valid for only the data type, to create a medical coding string (Paragraphs [0061] and [0188] discuss as data is collected from all sources it is matched to a harmonized numeric unit profile to ensures that the data and its related unit of measure matches the healthcare data standards for that specific data type, and automated mapping using standard clinical codes.).
Mar-Yohana does not explicitly disclose:
improving electronic data communication via a Health Level Seven International (HL7) standard;
receiving, by an HL7 interface engine implemented by one or more processors of a first computing system and from a second computing system, as part of a clinical data acquisition flow through the HL7 interface engine;
configured to interface with the HL7 interface engine;
set of acceptable data types for the medical observation code;
that the observation value is valid for only a single acceptable data type of the set of acceptable data types for the medical observation code;
replacing, by the module, the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string; and
providing, by the HL7 interface engine, the updated medical coding string to at least one of a clinical repository, an analytics entity, or a utilization management entity as part of the clinical data acquisition flow through the HL7 interface engine.
Bess teaches:
improving electronic data communication via a Health Level Seven International (HL7) standard (Abstract and Paragraphs [0033]-[0034] discuss HL7 communications that can involve custom communication interfaces which are used to parse and translate HL7 messages.);
receiving, by an HL7 interface engine implemented by one or more processors of a first computing system and from a second computing system, as part of a clinical data acquisition flow through the HL7 interface engine (Paragraphs [0032]-[0036] discuss receives patient electronic medical records (EMRs) for a plurality of healthcare entities by communicating using an HL7 communications that utilize custom interfaces that are used to parse the HL7 communications from different healthcare entities.);
configured to interface with the HL7 interface engine (Paragraphs [0041]-[0042] discuss the EHS can be instantiated in a cloud computing environment including servers with processors, memory and communication interfaces, using an HL7 compliant communication.);
providing, by the HL7 interface engine, the updated medical coding string to at least one of a clinical repository, an analytics entity, or a utilization management entity as part of the clinical data acquisition flow through the HL7 interface engine (Paragraph [0036] discusses classified data types can be used to develop a custom mapping that describes the format of the HL7 messages from the particular healthcare information source. The custom mapping can be implemented in a custom communication interface at the HCS associated with the particular healthcare information source. Data parsed from HL7 messages using the custom mapping can be used to update patient electronic medical records maintained at the HCS.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include, improving electronic data communication via a Health Level Seven International (HL7) standard, receiving, by an HL7 interface engine implemented by one or more processors of a first computing system and from a second computing system, as part of a clinical data acquisition flow through the HL7 interface engine, configured to interface with the HL7 interface engine, and providing, by the HL7 interface engine, the updated medical coding string to at least one of a clinical repository, an analytics entity, or a utilization management entity as part of the clinical data acquisition flow through the HL7 interface engine, as taught by Bess, in order to simplify the communication integration of healthcare providers into an electronic healthcare information network. (Bess Paragraph [0003]).
Rai teaches:
set of acceptable data types for the medical observation code (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.);
that the observation value is valid for only a single acceptable data type of the set of acceptable data types for the medical observation code (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.);
replacing, by the module, the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string (Paragraphs [0037] and [0053] discuss the patient is re-diagnosed with a lump that is not breast cancer, so the not breast cancer diagnosis would replace the breast cancer diagnosis). The second diagnosis may be detected as a replacement for the first diagnosis based on ontology codes, dates, medical provider notes (e.g., included in the document), treatment plans, and/or otherwise detected and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include set of acceptable data types for the medical observation code, that the observation value is valid for only a single acceptable data type of the set of acceptable data types for the medical observation code and replacing, by the module, the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Regarding claim 3, Mar-Yohana discloses wherein determining that the initial data type is not valid for the medical observation code includes determining, by the module, that the initial data type is not one of the set of acceptable data types for the medical observation code (Paragraphs [0087], [0160], [0162]-[0165], [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and the system assigns clinical diagnostic codes to all medical data using International Classification of Diseases standard code set, the standardized clinical codes that are assigned to all user health data can be used by the AI to more easily classify the data by code category, any data that is not matched to a harmonized numeric unit profile is rejected.).
Mar-Yohana does not explicitly disclose:
the set of acceptable data types for the medical observation code.
Rai teaches:
the set of acceptable data types for the medical observation code (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include the set of acceptable data types for the medical observation code, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Regarding claim 6, Mar-Yohana discloses wherein the data types only has a data type and wherein determining that the observation value is valid for a data type includes determining, by the module, that the observation value satisfies the data type (Paragraphs [0087], [0160], [0162]-[0165], [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and the system assigns clinical diagnostic codes to all medical data and any data that is not matched to a harmonized numeric unit profile is rejected.).
Mar-Yohana does not explicitly disclose:
the set of acceptable data types
a single data type and a single acceptable data type includes determining, that the observation value satisfies the single data type.
Rai teaches:
the set of acceptable data types (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.);
a single data type and a single acceptable data type includes determining, that the observation value satisfies the single data type (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include a single data type and a single acceptable data type includes determining, that the observation value satisfies the single data type, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Regarding claim 7, Mar-Yohana discloses wherein the data types has data types and wherein determining that the observation value is valid for a data type includes determining, by the module, that the observation value satisfies the data type but does not satisfy any other data type of the data types (Paragraphs [0087], [0160], [0162]-[0165], [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and the system assigns clinical diagnostic codes to all medical data, the standardized clinical codes that are assigned to all user health data can be used by the AI to more easily classify the data by code category; and the data and its related unit of measure matches the healthcare data standards used in the platform of the invention for that specific data type, and any data that is not matched to a harmonized numeric unit profile is rejected.).
Mar-Yohana does not explicitly disclose:
the set of acceptable data types has multiple data types and a single acceptable data type includes determining, the observation value satisfies the single acceptable data type but does not satisfy any other data type of the set of acceptable data types.
Rai teaches:
the set of acceptable data types has multiple data types and a single acceptable data type includes determining, the observation value satisfies the single acceptable data type but does not satisfy any other data type of the set of acceptable data types (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include the set of acceptable data types has multiple data types and a single acceptable data type includes determining, the observation value satisfies the single acceptable data type but does not satisfy any other data type of the set of acceptable data types, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Regarding claim 10, Mar-Yohana discloses a first computing system for improving electronic data communication, the first computing system comprising (Paragraphs [0045] and [0048] discuss the platform includes a system and hardware to allow the platform to communicate with systems and a computer network.):
one or more processors implemented in circuitry and in communication with the communication unit (Paragraph [0048] discusses servers that run the Personal Health Management System (PHMS) software application and provide computing microprocessors, data storage servers, and hardware to allow the platform to communicate with other systems.):
receiving, via an interface engine implemented by the one or more processors and from a second computing system, a medical coding string including a medical observation code, an initial data type, and an observation value (Paragraphs [0048], [0162]-[0165], [0187]-[0188] discuss analyzing patient electronic healthcare data and hardware to allow the platform to communicate with other systems via application programmable interfaces (APIs) creates a common representation of health data collected from all sources retrieved directly from other systems via API, the system assigns clinical diagnostic codes to all medical data using International Classification of Diseases standard code set, the standardized clinical codes that are assigned to all user health data can be used by the AI to more easily classify the data by code category.);
determining, using a module implemented by the one or more processors, that the initial data type is not valid for the medical observation code, the module comprising one or more software units stored in the one or more memories of the first computing system (Paragraphs [0045], [0087], [0162]-[0165], [0188]-[0189] discuss the platform is a combination of software and hardware designed to provide a service that users can access through the internet web browsers and mobile devices, the system assigns clinical diagnostic codes to all medical data and any data that is not matched to a harmonized numeric unit profile is rejected.);
determining, using the module, data types for the medical observation code using the medical observation code (Paragraphs [0156], [0162]-[0165], and [0188] discuss the platform of the invention can automatically parse this data within the records and maps the data into the appropriate features, modules, and sections, for example using the platform's automated clinical data mapping capability and the system assigns clinical diagnostic codes to all medical data using International Classification of Diseases standard code set, and as data is collected it is matched to a harmonized numeric unit profile to make sure it is correct for the specific data type).);
checking, using the module, a validity of the observation value with respect to each member of the data types for the medical observation code (Paragraphs [0160] and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and as data is collected it is matched to a harmonized numeric unit profile to make sure it is correct for the specific data type.);
determining, using the module, that the observation value is valid for acceptable data type of the data types for the medical observation code (Paragraphs [0160] and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and as data is collected from all sources it is matched to a harmonized numeric unit profile to ensures that the data and its related unit of measure matches the healthcare data standards for that specific data type.);
based on the determining that the observation value is valid for only the acceptable data type, to create an updated medical coding string (Paragraphs [0061] and [0188] discuss as data is collected from all sources it is matched to a harmonized numeric unit profile to ensures that the data and its related unit of measure matches the healthcare data standards for that specific data type, and automated mapping using standard clinical codes.).
Mar-Yohana does not explicitly disclose:
improving electronic data communication via a Health Level Seven International (HL7) standard;
one or more memories storing processor-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising;
receiving, via an HL7 interface engine implemented by the one or more processors and from a second computing system, a medical coding string as part of a clinical data acquisition flow through the HL7 interface;
configured to interface with the HL7 interface engine;
set of acceptable data types for the medical observation code
that the observation value is valid for only a single acceptable data type of the set of acceptable data types for the medical observation code;
replacing, using the module, the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string;
providing, by the HL7 interface engine, the updated medical coding string to at least one of a clinical repository, an analytics entity, or a utilization management entity as part of the clinical data acquisition flow through the HL7 interface engine.
Bess teaches:
improving electronic data communication via a Health Level Seven International (HL7) standard (Abstract and Paragraphs [0033]-[0034] discuss HL7 communications between disparate healthcare organizations. The communications can involve custom communication interfaces which are used to parse and translate HL7 messages.);
receiving, by an HL7 interface engine implemented by one or more processors of a first computing system and from a second computing system, as part of a clinical data acquisition flow through the HL7 interface engine (Paragraphs [0032]-[0036] discuss receives patient electronic medical records (EMRs) for a plurality of healthcare entities by communicating using an HL7 communications; the HL7 communications can utilize custom interfaces that are used to parse the HL7 communications from different healthcare entities.);
configured to interface with the HL7 interface engine (Paragraphs [0041]-[0042] discuss the EHS can be instantiated in a cloud computing environment including servers with processors, memory and communication interfaces, using an HL7 compliant communication.);
providing, by the HL7 interface engine, the updated medical coding string to at least one of a clinical repository, an analytics entity, or a utilization management entity as part of the clinical data acquisition flow through the HL7 interface engine (Paragraph [0036] discusses classified data types can be used to develop a custom mapping that describes the format of the HL7 messages from the particular healthcare information source. The custom mapping can be implemented in a custom communication interface at the HCS associated with the particular healthcare information source. Data parsed from HL7 messages using the custom mapping can be used to update patient electronic medical records maintained at the HCS.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include, improving electronic data communication via a Health Level Seven International (HL7) standard, receiving, by an HL7 interface engine implemented by one or more processors of a first computing system and from a second computing system, as part of a clinical data acquisition flow through the HL7 interface engine, configured to interface with the HL7 interface engine, and providing, by the HL7 interface engine, the updated medical coding string to at least one of a clinical repository, an analytics entity, or a utilization management entity as part of the clinical data acquisition flow through the HL7 interface engine, as taught by Bess, in order to simplify the communication integration of healthcare providers into an electronic healthcare information network. (Bess Paragraph [0003]).
Rai teaches:
set of acceptable data types for the medical observation code (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.);
that the observation value is valid for only a single acceptable data type of the set of acceptable data types for the medical observation code (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.);
replacing, by the module, the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string (Paragraphs [0037] and [0053] discuss the patient is re-diagnosed with a lump that is not breast cancer, so the not breast cancer diagnosis would replace the breast cancer diagnosis). The second diagnosis may be detected as a replacement for the first diagnosis based on ontology codes, dates, medical provider notes (e.g., included in the document), treatment plans, and/or otherwise detected and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include set of acceptable data types for the medical observation code, that the observation value is valid for only a single acceptable data type of the set of acceptable data types for the medical observation code and replacing, by the module, the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Regarding claim 12, Mar-Yohana discloses wherein the one or more processors are further configured to determine, using the module, that the initial data type is not one of the data types for the medical observation code as part of determining that the initial data type is not valid for the medical observation code (Paragraphs [0048], [0087], [0160], [0162]-[0165], and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and servers that run the Personal Health Management System (PHMS) software application and provide computing microprocessors, data storage servers, and hardware to allow the platform to communicate with other systems and the system assigns clinical diagnostic codes to all medical data and the data and its related unit of measure matches the healthcare data standards used in the platform of the invention for that specific data type and any data that is not matched to a harmonized numeric unit profile is rejected.).
Mar-Yohana does not explicitly disclose:
the set of acceptable data types for the medical observation code.
Rai teaches:
the set of acceptable data types for the medical observation code (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include the set of acceptable data types for the medical observation code, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Regarding claim 15, Mar-Yohana discloses wherein the data types only has a data type and wherein the one or more processors are further configured to, as part of determining that the observation value is valid for the data type, determine, using the module, that the observation value satisfies the data type (Paragraphs [0048], [0087], [0160], [0162]-[0165], and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and servers that run the Personal Health Management System (PHMS) software application and provide computing microprocessors, data storage servers, and hardware to allow the platform to communicate with other systems and the system assigns clinical diagnostic codes to all medical data and any data that is not matched to a harmonized numeric unit profile is rejected.).
Mar-Yohana does not explicitly disclose:
the set of acceptable data types only has a single data type and the single acceptable data type, determine, that the observation value satisfies the single data type.
Rai teaches:
the set of acceptable data types only has a single data type and a single acceptable data type, configured to determine that the observation value satisfies the single data type (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include the set of acceptable data types only has a single data type and a single acceptable data type, configured to determine that the observation value satisfies the single data type, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Regarding claim 16, Mar-Yohana discloses wherein the acceptable data types has multiple data types and wherein the one or more processors are further configured to, as part of determining that the observation value is valid for a data type, determine, using the module, that the observation value satisfies the data type but does not satisfy any other data type of data types (Paragraphs [0048], [0087], [0160], [0162]-[0165], and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and the servers that run the Personal Health Management System (PHMS) software application and provide computing microprocessors, data storage servers, and hardware to allow the platform to communicate with other systems and system assigns clinical diagnostic codes to all medical data, the standardized clinical codes that are assigned to all user health data can be used by the AI to more easily classify the data by code category; and the data and its related unit of measure matches the healthcare data standards used in the platform of the invention for that specific data type, and any data that is not matched to a harmonized numeric unit profile is rejected.).
Mar-Yohana does not explicitly disclose:
the set of acceptable data types has multiple data types and a single acceptable data type, determine, that the observation value satisfies the single acceptable data type but does not satisfy any other data type of the set of acceptable data types.
Rai teaches:
the set of acceptable data types has multiple data types and a single acceptable data type, configured to determine that the observation value satisfies the single acceptable data type but does not satisfy any other data type of the set of acceptable data types (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include the set of acceptable data types has multiple data types and a single acceptable data type, configured to determine that the observation value satisfies the single acceptable data type but does not satisfy any other data type of the set of acceptable data types, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Regarding claim 19, Mar-Yohana discloses:
receive, by the one or more processors and from a second computing system, a medical coding string including a medical observation code, an initial data type, and an observation value (Paragraphs [0048], [0162]-[0165], [0188], [0190], and [0206] discuss a computerized method for analyzing patient electronic healthcare data and hardware to allow the platform to communicate with other systems via application programmable interfaces (APIs) and the system assigns clinical diagnostic codes to all medical data, the standardized clinical codes that are assigned to all user health data can be used by the AI to more easily classify the data by code category.);
determine, using a module implemented by the one or more processors, that the initial data type is not valid for the medical observation code, the module comprising one or more software units stored in one or more storage devices of the first computing system (Paragraphs [0045], [0087], [0162]-[0165], [0188]-[0189] discuss the platform is a combination of software and hardware designed to provide a service that users can access through the internet web browsers and mobile devices, the system assigns clinical diagnostic codes to all medical data and any data that is not matched to a harmonized numeric unit profile is rejected.);
determine, using the module, data types for the medical observation code using the medical observation code (Paragraphs [0160], [0162]-[0165], and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and the system assigns clinical diagnostic codes to all medical data using International Classification of Diseases standard code set, and as data is collected it is matched to a harmonized numeric unit profile to make sure it is correct for the specific data type).);
check, using the module, a validity of the observation value with respect to each member of the data types for the medical observation code (Paragraphs [0160] and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and as data is collected it is matched to a harmonized numeric unit profile to make sure it is correct for the specific data type.);
determine, using the module, that the observation value is valid for only a data type of the data types for the medical observation code (Paragraphs [0160] and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and as data is collected from all sources it is matched to a harmonized numeric unit profile to ensures that the data and its related unit of measure matches the healthcare data standards for that specific data type.);
based on the determining that the observation value is valid for only the data type, create medical coding string (Paragraphs [0061] and [0188] discuss as data is collected from all sources it is matched to a harmonized numeric unit profile to ensures that the data and its related unit of measure matches the healthcare data standards for that specific data type, and automated mapping using standard clinical codes.).
Mar-Yohana does not explicitly disclose:
one or more non-transitory computer-readable storage media having processor-executable instructions stored thereon for improving electronic data communication via a Health Level Seven International (HL7) standard that, when executed by one or more processors of a first computing system, cause the one or more processors to;
receive, using an HL7 interface engine implemented by the one or more processors and from a second computing system, as part of a clinical data acquisition flow through the HL7 interface engine;
configured to interface with the HL7 interface engine;
set of acceptable data types for the medical observation code;
that the observation value is valid for only a single acceptable data type of the set of acceptable data types for the medical observation code;
replace, using the module, the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string;
provide, using the HL7 interface engine, the updated medical coding string to at least one of a clinical repository, an analytics entity, or a utilization management entity as part of the clinical data acquisition flow through the HL7 interface engine.
Bess teaches:
improving electronic data communication via a Health Level Seven International (HL7) standard (Abstract and Paragraphs [0033]-[0034] discuss HL7 communications between disparate healthcare organizations that can involve custom communication interfaces which are used to parse and translate HL7 messages.);
receive, using an HL7 interface engine implemented by the one or more processors and from a second computing system, as part of a clinical data acquisition flow through the HL7 interface engine (Paragraphs [0032]-[0036] discuss receives patient electronic medical records (EMRs) for a plurality of healthcare entities by communicating using an HL7 communications that utilize custom interfaces that are used to parse the HL7 communications from different healthcare entities.);
configured to interface with the HL7 interface engine (Paragraphs [0041]-[0042] discuss the EHS can be instantiated in a cloud computing environment including servers with processors, memory and communication interfaces, using an HL7 compliant communication.);
provide, using the HL7 interface engine, the updated medical coding string to at least one of a clinical repository, an analytics entity, or a utilization management entity as part of the clinical data acquisition flow through the HL7 interface engine (Paragraph [0036] discusses classified data types can be used to develop a custom mapping that describes the format of the HL7 messages from the particular healthcare information source. The custom mapping can be implemented in a custom communication interface at the HCS associated with the particular healthcare information source. Data parsed from HL7 messages using the custom mapping can be used to update patient electronic medical records maintained at the HCS.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include, improving electronic data communication via a Health Level Seven International (HL7) standard, receive, using an HL7 interface engine implemented by the one or more processors and from a second computing system, as part of a clinical data acquisition flow through the HL7 interface engine, configured to interface with the HL7 interface engine, and provide, using the HL7 interface engine, the updated medical coding string to at least one of a clinical repository, an analytics entity, or a utilization management entity as part of the clinical data acquisition flow through the HL7 interface engine, as taught by Bess, in order to simplify the communication integration of healthcare providers into an electronic healthcare information network. (Bess Paragraph [0003]).
Rai teaches:
one or more non-transitory computer-readable storage media having processor-executable instructions stored thereon that, when executed by one or more processors of a first computing system, cause the one or more processors to (Paragraph [0132] discusses a non-transitory computer useable or readable medium having control logic that is executed by one or more processing devices.).
set of acceptable data types for the medical observation code (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.);
that the observation value is valid for only a single acceptable data type of the set of acceptable data types for the medical observation code (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.);
replace the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string (Paragraphs [0037] and [0053] discuss the patient is re-diagnosed with a lump that is not breast cancer, so the not breast cancer diagnosis would replace the breast cancer diagnosis). The second diagnosis may be detected as a replacement for the first diagnosis based on ontology codes, dates, medical provider notes (e.g., included in the document), treatment plans, and/or otherwise detected and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include one or more non-transitory computer-readable storage media having processor-executable instructions stored thereon that, when executed by one or more processors of a first computing system, cause the one or more processors to, set of acceptable data types for the medical observation code, that the observation value is valid for only a single acceptable data type of the set of acceptable data types for the medical observation code, and replace the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Claims 2, 8, 11, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mar-Yohana in view of Bess and Rai and in further view of Cohen (U.S. Pub. No. 2007/0016610 A1).
Regarding claim 2, Mar-Yohana discloses wherein the data type is a data type, further comprising determining, by the module, the observation value to follow the data type (Paragraphs [0160] and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and as data is collected from all sources it is matched to a harmonized numeric unit profile, which ensures that the data and its related unit of measure matches the healthcare data standards used in the platform of the invention for that specific data type.).
Mar-Yohana does not explicitly disclose:
the single acceptable data type is a data type a compound data type, further comprising parsing, by the computing system, the observation value to follow the compound data type.
Rai teaches:
the single acceptable data type (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include a single data type and a single acceptable data type includes determining, that the observation value satisfies the single data type, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Cohen teaches:
a compound data type, further comprising parsing, by the computing system, the observation value to follow the compound data type (Paragraphs [0024] and [0029] discuss mapping simple HL7 data types to new relational database distinct types and compound HL7 data types to relational tables and incoming communication messages that comply with the object model are parsed and shredded in accordance with the shredding rules.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include a compound data type, further comprising parsing, by the computing system, the observation value to follow the compound data type, as taught by Cohen, in order to preserve the relationships between the different data items in the message and documents. (Cohen Paragraph [0017]).
Regarding claims 8 and 17, Mar-Yohana does not explicitly disclose wherein the medical coding string uses an HL7 format.
Cohen teaches:
wherein the medical coding string uses an HL7 format (Paragraphs [0024], [0029] discuss mapping simple HL7 data types to new relational database distinct types and compound HL7 data types to relational tables.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include wherein the medical coding string uses an HL7 format, as taught by Cohen, in order to preserve the relationships between the different data items in the message and documents. (Cohen Paragraph [0017]).
Regarding claim 11, Mar-Yohana discloses wherein the data type is a data type, wherein the one or more processors, using the module, the observation value to follow the data type (Paragraphs [0048], [0160], and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and servers that run the Personal Health Management System (PHMS) software application and provide computing microprocessors, data storage servers, and hardware to allow the platform to communicate with other systems and as data is collected from all sources it is matched to a harmonized numeric unit profile, which ensures that the data and its related unit of measure matches the healthcare data standards used in the platform of the invention for that specific data type.).
Mar-Yohana does not explicitly disclose:
single acceptable data type is a compound data type, further configured to parse, using the module, the observation value to follow the compound data type.
Rai teaches:
the single acceptable data type (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include a single data type includes determining, that the observation value satisfies the single data type, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Cohen teaches:
a compound data type, further configured to parse the observation value to follow the compound data type (Paragraphs [0024] and [0029] discuss mapping simple HL7 data types to new relational database distinct types and compound HL7 data types to relational tables and incoming communication messages that comply with the object model are parsed and shredded in accordance with the shredding rules.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include a compound data type, further configured to parse the observation value to follow the compound data type, as taught by Cohen, in order to preserve the relationships between the different data items in the message and documents. (Cohen Paragraph [0017]).
Regarding claim 20, Mar-Yohana discloses wherein the data type is a data type, using the module, the observation value to follow the data type (Paragraphs [0048], [0160], and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and servers that run the Personal Health Management System (PHMS) software application and provide computing microprocessors, data storage servers, and hardware to allow the platform to communicate with other systems and as data is collected from all sources it is matched to a harmonized numeric unit profile, which ensures that the data and its related unit of measure matches the healthcare data standards used in the platform of the invention for that specific data type.).
Mar-Yohana does not explicitly disclose:
single acceptable data type is a compound data type, further comprising instructions that, when executed, cause one or more processors to parse, the observation value to follow the compound data type.
Rai teaches:
the single acceptable data type, further comprising instructions that, when executed, cause one or more processors (Paragraphs [0053], [0066], and [0132] discuss a non-transitory computer useable or readable medium having control logic that is executed by one or more processing devices and an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include, single acceptable data type is a compound data type, further comprising instructions that, when executed, cause one or more processors to parse, the observation value to follow the compound data type, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Cohen teaches:
a compound data type, further comprising parsing, by the computing system, the observation value to follow the compound data type (Paragraphs [0024], [0029] discuss mapping simple HL7 data types to new relational database distinct types and compound HL7 data types to relational tables and incoming communication messages that comply with the object model are parsed and shredded in accordance with the shredding rules. Data items are extracted from these communication messages and stored in the relational database, in accordance with the relational schema.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include a compound data type, further comprising parsing, by the computing system, the observation value to follow the compound data type, as taught by Cohen, in order to preserve the relationships between the different data items in the message and documents. (Cohen Paragraph [0017]).
Claims 4-5 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Mar-Yohana in view of Bess and Rai and in further view of Hartman (U.S. Pub. No. 2023/0081372 A1).
Regarding claim 4, Mar-Yohana discloses wherein checking the validity of the observation value with respect to each member of the set of acceptable data types for the medical observation code includes (Paragraph [0188] discusses as data is collected from all sources it is matched to a harmonized numeric unit profile, which ensures that the data and its related unit of measure matches the healthcare data standards used in the platform of the invention for that specific data type.);
obtaining, by the module, a value for each member of the set of data types (Paragraphs [0160], [0162]-[0165], and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and the system assigns clinical diagnostic codes to all medical data and as data is collected it is matched to a harmonized numeric unit profile to make sure it is correct for the specific data type); and
for each member of the set of data types, checking, by the module, the observation value to determine if the observation value satisfies the value for that member (Paragraphs [0160], [0162]-[0165], and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and the system assigns clinical diagnostic codes to all medical data and as data is collected it is matched to a harmonized numeric unit profile to make sure it is correct for the specific data type).
Mar-Yohana does not explicitly disclose:
set of acceptable data types;
obtaining, by the module, a regular expression (regex) for each member of the set of acceptable data types; and
for each member of the set of acceptable data types, checking, by the computing system, the observation value to determine if the observation value satisfies the regular expression for that member.
Rai teaches:
set of acceptable data types (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include, set of acceptable data types, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Hartman teaches:
obtaining, by the computing system, a regular expression (regex) for each member of the set of acceptable data types (Paragraphs [0063], [0066]-[0067] discuss clinical notes and data from a database are classified and looks at the categorical values of the type of data and a regular expression, or regex, processing algorithm is performed on the clinical notes to extract the most salient and useful content.); and
for each member of the set of acceptable data types, checking, by the computing system, the observation value to determine if the observation value satisfies the regular expression for that member (Paragraphs [0066]-[0067] discuss regexes use pattern matching rules to match and format data and once the clinical notes have undergone regex processing, related structured data, such as the admission diagnosis, patient age, note date and time, is appended to the textual portion of the clinical note, for example, if an original clinical note states: “Patient is a 47 year old white male with a history of epilepsy who presents to Weill Cornell Medicine.”, then structured data may be added at the beginning of the note to help with processing. Continuing the example, the edited note may read: “Admit Diagnosis: Epilepsy; Age: 47; Note Date: Jul. 21, 2022, Note Text: Patient is a 47 year old white male with a history of epilepsy who presents to Weill Cornell Medicine . . . ”.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include, obtaining, by the computing system, a regular expression (regex) for each member of the set of acceptable data types and for each member of the set of acceptable data types, checking, by the computing system, the observation value to determine if the observation value satisfies the regular expression for that member, as taught by Hartman, in order to automatically create patient summaries using electronic health record content to reduce the time that a physician spends using a computer, reducing costs and freeing up time to treat patients. (Hartman Paragraph [0002]).
Regarding claim 5, Mar-Yohana discloses wherein determining that the observation value is valid for only the data type includes determining, by the module, data type satisfies the observation value (Paragraphs [0160] and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and as data is collected from all sources it is matched to a harmonized numeric unit profile, which ensures that the data and its related unit of measure matches the healthcare data standards used in the platform of the invention for that specific data type.).
Mar-Yohana does not explicitly disclose:
the single acceptable data type includes determining, by the module, that the regular expression for the single acceptable data type satisfies the observation value
Rai teaches:
the single acceptable data type (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include, a single acceptable data type, includes determining, that the observation value satisfies the single acceptable data type, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Hartman teaches:
the regular expression for the single acceptable data type satisfies the observation value (Paragraphs [0066]-[0067] discuss regexes use pattern matching rules to match and format data and once the clinical notes have undergone regex processing, related structured data, such as the admission diagnosis, patient age, note date and time, is appended to the textual portion of the clinical note, for example, if an original clinical note states: “Patient is a 47 year old white male with a history of epilepsy who presents to Weill Cornell Medicine.”, then structured data may be added at the beginning of the note to help with processing. Continuing the example, the edited note may read: “Admit Diagnosis: Epilepsy; Age: 47; Note Date: Jul. 21, 2022, Note Text: Patient is a 47 year old white male with a history of epilepsy who presents to Weill Cornell Medicine . . . ”.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include, the regular expression for the single acceptable data type satisfies the observation value, as taught by Hartman, in order to automatically create patient summaries using electronic health record content to reduce the time that a physician spends using a computer, reducing costs and freeing up time to treat patients. (Hartman Paragraph [0002]).
Regarding claim 13, Mar-Yohana discloses wherein the one or more processors are further configured to, as part of checking the validity of the observation value with respect to each member of the set of acceptable data types for the medical observation code (Paragraphs [0048] and [0188] discuss servers that run the Personal Health Management System (PHMS) software application and provide computing microprocessors, data storage servers, and hardware to allow the platform to communicate with other systems and as data is collected from all sources it is matched to a harmonized numeric unit profile, which ensures that the data and its related unit of measure matches the healthcare data standards used in the platform of the invention for that specific data type.):
obtain, using the module, a value for each member of the set of data types (Paragraphs [0160], [0162]-[0165], and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and the system assigns clinical diagnostic codes to all medical data and as data is collected it is matched to a harmonized numeric unit profile to make sure it is correct for the specific data type); and
for each data types, check, using the module, the observation value to determine if the observation value satisfies the value for that member (Paragraphs [0160], [0162]-[0165], and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and the system assigns clinical diagnostic codes to all medical data and as data is collected it is matched to a harmonized numeric unit profile to make sure it is correct for the specific data type).
Mar-Yohana does not explicitly disclose:
set of acceptable data types for the medical observation code
obtain, using the module, a regular expression (regex) for each member of the set of acceptable data types; and
for each member of the set of acceptable data types, check, using the module, the observation value to determine if the observation value satisfies the regular expression for that member.
Rai teaches:
set of acceptable data types for the medical observation code (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., for example, a lung cancer ontology may include a curated list of standard medical codes that are related to lung cancer, such as medical codes for cancer treatments, medications, diagnoses, and/or symptoms and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include the single acceptable data type, further comprising instructions that, when executed, cause one or more processors, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Hartman teaches:
obtain, using the module, a regular expression (regex) for each member of the set of acceptable data types (Paragraphs [0063], [0066]-[0067] discuss clinical notes and data from a database are classified and looks at the categorical values of the type of data and a regular expression, or regex, processing algorithm is performed on the clinical notes to extract the most salient and useful content.); and
for each member of the set of acceptable data types, check, using the module, the observation value to determine if the observation value satisfies the regular expression for that member (Paragraphs [0066]-[0067] discuss regexes use pattern matching rules to match and format data and once the clinical notes have undergone regex processing, related structured data, such as the admission diagnosis, patient age, note date and time, is appended to the textual portion of the clinical note, for example, if an original clinical note states: “Patient is a 47 year old white male with a history of epilepsy who presents to Weill Cornell Medicine.”, then structured data may be added at the beginning of the note to help with processing. Continuing the example, the edited note may read: “Admit Diagnosis: Epilepsy; Age: 47; Note Date: Jul. 21, 2022, Note Text: Patient is a 47 year old white male with a history of epilepsy who presents to Weill Cornell Medicine . . . ”.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include, obtaining, by the computing system, a regular expression (regex) for each member of the set of acceptable data types and for each member of the set of acceptable data types, checking, by the computing system, the observation value to determine if the observation value satisfies the regular expression for that member, as taught by Hartman, in order to automatically create patient summaries using electronic health record content to reduce the time that a physician spends using a computer, reducing costs and freeing up time to treat patients. (Hartman Paragraph [0002]).
Regarding claim 14, Mar-Yohana discloses wherein the one or more processors are further configured to, as part of determining that the observation value is valid for only the data type, determine, using the module, the data type satisfies the observation value (Paragraphs [0048], [0160], and [0188] discuss the platform can read, validate, and load the data into the appropriate features, modules, and sections and servers that run the Personal Health Management System (PHMS) software application and provide computing microprocessors, data storage servers, and hardware to allow the platform to communicate with other systems and as data is collected from all sources it is matched to a harmonized numeric unit profile, which ensures that the data and its related unit of measure matches the healthcare data standards used in the platform of the invention for that specific data type.).
Mar-Yohana does not explicitly disclose:
the single acceptable data type determine, using the module, that the regular expression for the single acceptable data type satisfies the observation value
Rai teaches:
the single acceptable data type (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc., and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include a single acceptable data type, includes determining, that the observation value satisfies the single acceptable data type, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Hartman teaches:
the regular expression for the single acceptable data type satisfies the observation value (Paragraphs [0066]-[0067] discuss regexes use pattern matching rules to match and format data and once the clinical notes have undergone regex processing, related structured data, such as the admission diagnosis, patient age, note date and time, is appended to the textual portion of the clinical note, for example, if an original clinical note states: “Patient is a 47 year old white male with a history of epilepsy who presents to Weill Cornell Medicine.”, then structured data may be added at the beginning of the note to help with processing. Continuing the example, the edited note may read: “Admit Diagnosis: Epilepsy; Age: 47; Note Date: Jul. 21, 2022, Note Text: Patient is a 47 year old white male with a history of epilepsy who presents to Weill Cornell Medicine . . . ”.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include the regular expression for the single acceptable data type satisfies the observation value, as taught by Hartman, in order to automatically create patient summaries using electronic health record content to reduce the time that a physician spends using a computer, reducing costs and freeing up time to treat patients. (Hartman Paragraph [0002]).
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mar-Yohana in view of Bess and Rai and in further view of Lau (U.S. Pub. No. 2002/0198739 A1).
Regarding claims 9 and 18, Mar-Yohana does not explicitly disclose wherein the medical observation code is a LOINC (Logical Observation Identifiers Names and Codes) code with associated scale type associated with the set of acceptable data types.
Lau teaches:
wherein the medical observation code is a LOINC (Logical Observation Identifiers Names and Codes) code with associated scale type associated with the set of acceptable data types (Paragraphs [0048] and [0059] discuss Logical Observation Identifier Names and Codes (LOINC) is an example of a standard for laboratory result names. In LOINC, laboratory results are named using to six attributes: components or analytes such as sodium or glucose; properties such as substance concentration or mass rate; time such as random or 24 hours; system or specimen or sample such as serum or urine; scale or precision such as quantitative or ordinal; and method such as electrophoresis or immune blot. Each combination of each attribute constitutes a unique laboratory result and is given a unique LOINC identifier and the data type of the columns identifying the result name, data type, and unit columns are used to derive the property and scale attributes. For example, if the data type is a number, then the scale attribute is quantitative.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include wherein the medical observation code is a LOINC (Logical Observation Identifiers Names and Codes) code with associated scale type associated with the set of acceptable data types, as taught by Lau, in order to automatically create patient summaries using electronic health record content to reduce the time that a physician spends using a computer, reducing costs and freeing up time to treat patients. (Lau Paragraph [0002]).
Rai teaches:
set of acceptable data types (Paragraphs [0053] and [0066] discuss an ontology code may be associated with one or more terminology codes (also referred to herein as medical codes) are well established and may be a curated list of terminology codes that share some commonality, such as being related to the same illness, being related to the same type of attribute, etc. and each attribute may be associated with a set of properties (observed or inferred) extracted from the patient medical data may be: text strings, numerical values, data values, and/or be another datatype.).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Mar-Yohana to include set of acceptable data types, as taught by Rai, in order to improve the analysis of patient data. (Rai Paragraph [0003]).
Response to Arguments
Applicant’s arguments filed June 30, 2025 have been fully considered.
Rejections under 35 U.S.C. 101:
With respect to claim 1 and the Prong 1 35 U.S.C. 101 rejection, Applicant’s amendment fails to overcome the previous rejection. Claim 1 as amended recites an abstract idea, a method of organizing human activity. See MPEP 2106.04(a)(2)(II)(C) Managing Personal Behavior or Relationships or Interactions Between People. Applicant argues amended claim 1 “is not a method of organizing human activity, as the Office suggests,6 since the quoted claim language recites functions performed by particular computer components in processing and correcting medical data. Rather, amended claim 1, as a whole, is generally directed to an improvement in electronic data communication via a Health Level Seven International (HL7) standard between the "first computing system" and the "second computing system," and more particularly, to an error correction technique (applied by the "first computing system") to a "medical coding string" (received from the "second computing system") to generate an "updated medical coding string.".” (Remarks, page 11). Applicant also states, “As amended claim 1 claims the functions of particular components implemented by processors of a computing system, claim 1 is therefore not directed towards a "certain method of organizing human activity... that is performed in a human mind,"' or other method of organizing human activity.” (Remarks, page 12). Applicant also states, “Often, the wrong data type is provided on observations due to software defects, configuration errors, or misunderstandings about how to properly implement the HL7 standards. For example, a systolic blood pressure observation with a value of "120" might be submitted as a data type of string rather than as a number. This may prevent the easy use of this observation by a receiving organization. Some observations have incorrect data type. The error of using a "string" data type for quantitative observations is the most common error. Such erroneous strings are still human readable but might not be interpreted correctly by computers.' Amended claim 1 directed towards modifying erroneous strings or other data structures that humans are capable of interpreting but that computers are incapable of doing so.” (Remarks page 12). Automating a process previously done by people and solving a formatting problem with particular computer components that implement a "clinical data acquisition flow" is not a technical problem rooted in the technology. The use of an error correction technique and updating the medical coding string is directed to the abstract idea.
When evaluating a claim to determine whether it recites an abstract idea, examiners should keep in mind that while "all inventions at some level embody, use, reflect, rest upon, or apply laws of nature, natural phenomenon, or abstract ideas", not all claims recite an abstract idea. See Alice Corp. Pty. Ltd. v. CLS Bank, Int’l, 573 U.S. 208, 217, 110 USPQ2d 1976, 1980-81 (2014) (citing Mayo Collaborative Servs. v. Prometheus Labs. Inc., 566 US 66, 71, 101 USPQ2d 1961, 1965 (2012)). The Step 2A Prong One analysis articulated in MPEP 2106.04 accounts for this cautionary principle by requiring a claim to recite (i.e., set forth or describe) an abstract idea in Prong One before proceeding to the Prong Two inquiry about whether the claim is directed to that idea, thereby separating claims reciting abstract ideas from those that are merely based on or involve an abstract idea.
While practical application is a way to overcome the Prong 2 35 U.S.C. 101 rejection, here, claim 1 fails to integrate the recited judicial exception into a practical application. Applicant states, “Like Example 42 of the 2019 PEG, these features do not merely link any alleged judicial exception to a technical field, but instead provide a specific improvement in replacing medical string data types with acceptable data type to enable consumption by other computing systems.” (Remarks, page 14). Examiner respectfully disagrees. The Application is distinguishable from Example 42. The Application relates to correcting HL7 observation value types using regular expressions and is completely different from the application discussed in Example 42. Further, the additional elements, the “computing system”, “communication unit”, “a network”, and “one or more processors”, do not result in a practical application as it is recited at an apply it level, as stated above. All components in the claims are being used for their intended purpose and as written do not result in a practical application or significantly more than the abstract idea. For the reasons stated above, claims 10 and 19 similarly fail to overcome the 35 U.S.C. 101 rejection. Here, there is no improvement to “the computing system”, “communication unit”, “a network”, and “one or more processors” or any of the devices. Applicant’s claims are directed to automating a process previously done by a person. Here, the improvement is to the abstract idea – correcting HL7 observation value types using regular expressions; therefore, Applicant’s amendment fails to overcome the rejection. For the reasons stated above, claim similarly fails to overcome the 35 U.S.C. 101 rejection.
Claim Interpretation under 35 U.S.C. 112(f):
Examiner notes that Applicant’s amendment, overcomes the previous invocation of 35 U.S.C. § 112(f).
Rejections under 35 U.S.C. 103:
Applicant argues the amendments overcome the previous rejection. Regarding the prior art rejection, Applicant argues “Mar-Yohana in view of Rai fails to teach or suggest "replacing, by the module, the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string," as recited by amended claim 1 (emphasis added)… Rai describes correcting outdated patient medical data using updated patient records. The verifying and correcting of patient records using updated patient records is not "replacing... the initial data type in the medical coding string with the single acceptable data type," as recited by amended claim 1 (emphasis added).” (Remarks, pages 16-17). Applicant states, “Mar-Yohana in view of Rai fails to teach or suggest "based on the determination that the observation value is valid for only the single acceptable data type, replacing... the initial data type in the medical coding string with the single acceptable data type to create an updated medical coding string," as recited by amended claim 1 (emphasis added).” (Remarks, 17). Examiner respectfully disagrees. Applicant is interpreting the claims more narrowly than actually written and what is acceptable is very board. Rai discusses the patient is re-diagnosed with a lump that is not breast cancer, so the re-diagnosis would replace the initial breast cancer diagnosis. The second diagnosis may be detected as a replacement for the first diagnosis based on ontology codes. Examiner notes that Applicant’s arguments regarding the amendments are well taken. Further, Applicant’s arguments with respect to claim 1 have been considered and the Examiner’s rejection has been updated to address Applicant’s claim 1, 10, and 19 amendments.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAWN TRINAH HAYNES whose telephone number is (571)270-5994. The examiner can normally be reached M-F 7:30-5:15PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jason Dunham can be reached on (571)272-8109. The fax phone number for the organization where this application or proceeding is assigned is (571)273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at (866)217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call (800)786-9199 (IN USA OR CANADA) or (571)272-1000.
/DAWN T. HAYNES/
Art Unit 3686
/RACHELLE L REICHERT/Primary Examiner, Art Unit 3686
Prosecution Insights