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