DETAILED ACTION
This is in response to US App. 18/587,216. Claims 1-15 have been examined.
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 . 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 (i.e., changing from AIA to pre-AIA ) 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.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-15 are rejected under 35 U.S.C. 102(a)(1) as being unpatentable by Aronson et al. (US 2008/0270438; included in IDS; hereafter Aronson).
Regarding Claim 1,
A computer-implemented method for processing electronic healthcare data, comprising:
receiving, at an intermediate data processing device, a data packet from a data source, said data packet being for transmission to a data consumer across a computer network and including electronic healthcare data, said intermediate data processing device being connected between the data source and the data consumer in the network [Aronson: 0050; FIG. 2 is a block diagram of an embodiment of the gateway 200 and a number of exemplary clients 204, 208, 210, 214, 218 and 220 communicating with the gateway 200; the gateway 200 is configured to receive messages, such as exemplary message 224; the messages may be medical (including genetic and genomic) laboratory test requests, laboratory test results and various types of acknowledgements, including confirmations and rejections (collectively "medical laboratory test messages"); 0052; for each received message, the gateway 200 uses information in the received message (or a translated version of the message) to identify an intended recipient client; 0058; the gateway 200 provides an interface 252, such as a secure web interface or an application service process (ASP), to the gateway 200; the interface 252 may include a provider portal 254 and a laboratory portal 258; through this interface 252, clients (such as provider 220 and laboratory 208) may access messages or lists of messages in the repository 250];
performing, by the intermediate data processing device, a validation process of the data packet by comparison of the data packet to a healthcare data packet scheme; acknowledging, to the data source, receipt of a valid data packet at the intermediate data processing device from the data source when the data packet has been validated by the validation process [Aronson: 0051; for each form, in which the gateway 200 is configured to receive messages, the gateway 200 includes an inbound translator 229 to translate received messages into the canonical form 228; the gateway 200 includes a database 230 that contains information about the clients 204-220 that are serviced by the gateway, including information about forms in which the clients send messages and forms in which the clients prefer to receive messages; 0053; for each form, in which the gateway 200 is configured to send messages, the gateway 200 includes an outbound translator 232; an outbound message router 239 uses information in the message and information in the database 230 to cause one or more appropriate outbound translators 232 to generate messages from the canonical form 228; for each receiver 234 and 238 specified in the database, the gateway 200 generates a message 240 and 244 translated from the canonical form message 228, according to the receiver's preferred form(s); 0058; via the interface 252, clients may view messages (such as laboratory reports) and acknowledge receiving the messages or reject the messages; if a client rejects or acknowledges receiving a message (such as a laboratory report), the gateway 200 generates an appropriate rejection or acknowledgement message and sends the message to the client that send the report, including translating the message by an appropriate outgoing translator 232, as described above; 0069; if a message syntax translator 304 detects a syntactical error in a message 406, the translator may issue an exception, as described below; detecting syntactical errors forms part of a message validation function that may be performed by the gateway 200; 0100; the validation component may be used to enforce a standard, such as by rejecting messages that contain non-standard codes or messages that do not conform to a particular protocol; 0101; the validation component may check message nomenclature that describes variants to ensure the nomenclature is used correctly or to otherwise validate the message nomenclature; 0105; if an exception occurs, an exception handler 268 (FIG. 2) may notify the sending client, such as via e-mail, pager or the like]; and
transmitting the data packet on to the data consumer when the data packet has been validated by the validation process [Aronson: 0053; the gateway sends the translated messages 240 and 244 to the designated receivers 234 and 238].
Regarding Claim 2,
further including transmitting, from the intermediate data processing device to the data source, an indication that the data packet was not validated when the validation process has failed to validate the data packet [Aronson: 0058; via the interface 252, clients may view messages (such as laboratory reports) and acknowledge receiving the messages or reject the messages; if a client rejects or acknowledges receiving a message (such as a laboratory report), the gateway 200 generates an appropriate rejection or acknowledgement message and sends the message to the client that send the report, including translating the message by an appropriate outgoing translator 232, as described above; 0069; if a message syntax translator 304 detects a syntactical error in a message 406, the translator may issue an exception, as described below; detecting syntactical errors forms part of a message validation function that may be performed by the gateway 200; 0105; if an exception occurs, an exception handler 268 (FIG. 2) may notify the sending client, such as via e-mail, pager or the like].
Regarding Claim 3,
wherein the intermediate data processing device is a data services module connected to the data source over a local area network connection [Aronson: 0099; the messages described herein may be communicated between clients 204-220 (FIG. 2) and the gateway 200 via any suitable electronic communication link (including, but not limited to, the Internet or a private local-area or wide-area network) using any suitable communication protocol (including, but not limited to, TCP, SOAP, SMTP (e-mail), FTP or HTTP)].
Regarding Claim 4,
wherein the data consumer is located in a different computer network to the data source [Aronson: 0099; the messages described herein may be communicated between clients 204-220 (FIG. 2) and the gateway 200 via any suitable electronic communication link (including, but not limited to, the Internet or a private local-area or wide-area network) using any suitable communication protocol (including, but not limited to, TCP, SOAP, SMTP (e-mail), FTP or HTTP)].
Regarding Claim 5,
wherein the validation process includes: determining whether all mandatory fields, as defined by the healthcare data packet scheme, are populated; and/or determining whether one or more data values within the data packet are compliant with the healthcare data packet scheme [Aronson: 0100; the validation component may be used to enforce a standard, such as by rejecting messages that contain non-standard codes or messages that do not conform to a particular protocol; 0101; the validation component may check message nomenclature that describes variants to ensure the nomenclature is used correctly or to otherwise validate the message nomenclature; in one embodiment, regular expressions are used to check the validity of message nomenclature; further validation may be performed by validating IDs in the message against external databases or files].
Regarding Claim 6,
wherein the healthcare data packet scheme is defined by the data consumer, and the data consumer shares the healthcare data packet scheme with the intermediate data processing device [Aronson: 0096; the sending client may also include information in the message to indicate a transaction type (also referred to as a "message type"); some transaction types (for example, "Results Complete" and "Results Confirm Response" messages) have been discussed above. Other transaction types include: "Laboratory Analysis Order," "Order Cancellation," "Order Hold," "Order Status Request," "Order Status Response," "Exception" (such as to indicate a problem with a laboratory analysis order or data) and "Results Nullify;" when the gateway 200 receives a message, the gateway parses the message to ascertain the message's type; 0097; the gateway 200 uses the contents of a received message's Receiving Facility and/or Receiving Application field and, in some cases, the transaction type to look up message processing information in the database 230; for example, the gateway 200 may search the database 230 for a client entry 600, 604, 608, etc. having a client ID field 610 whose contents match the Receiving Facility and/or Receiving Application field of the incoming message and having a transaction type field 614 whose contents match the received message's transaction type].
Regarding Claim 7,
further including a step of converting the data packet before performance of the validation process from a first format into a second format [Aronson: 0090; the gateway 200 uses the selected client entry 600-608 to select an incoming translator 229 to translate the incoming message into the canonical form 228 (FIG. 1); 0100; the validation component may be used to enforce a standard, such as by rejecting messages that contain non-standard codes or messages that do not conform to a particular protocol; 0018; the method may further include validating the contents of at least a portion of the received message, such as by validating a genetic code in at least a portion of the received message. The method may further include validating the contents of at least a portion of the representation of the received message, such as by validating a genetic code in at least a portion of the representation].
Regarding Claim 8,
wherein the data packet is transmitted from the intermediate data processing device to a data publisher located upstream of the data consumer, said data publisher publishing the data packet for consumption by the data consumer [Aronson: 0057; an embodiment of the gateway maintains a repository 250 that includes a message store 252, in which the gateway 200 stores copies of messages the gateway 200 sent or would have sent to these clients; 0058; the gateway 200 provides an interface 252, such as a secure web interface or an application service process (ASP), to the gateway 200; the interface 252 may include a provider portal 254 and a laboratory portal 258. Through this interface 252, clients (such as provider 220 and laboratory 208) may access messages or lists of messages in the repository 250].
Regarding Claim 9,
wherein upon receipt of the data packet by the data consumer, an acknowledgement of receipt from the data consumer is received by an events handler and stored [Aronson: 0058; via the interface 252, clients may view messages (such as laboratory reports) and acknowledge receiving the messages or reject the messages. If a client rejects or acknowledges receiving a message (such as a laboratory report), the gateway 200 generates an appropriate rejection or acknowledgement message and sends the message to the client that send the report].
Regarding Claim 10,
wherein the data packet includes routing information, indicating an intended consumer of the data packet [Aronson: 0095; messages sent by clients are addressed, such as in headers of the messages, to the gateway; however, the sending client fills in the Receiving Facility field with an identifier (ID) of the destination facility. Each facility has a unique ID. The sending client fills in the Receiving Application field with an identifier (ID) of an intended recipient application at the receiving facility], and
wherein performing the validation process by comparison of the data packet to the healthcare data packet scheme does not utilise the routing information [Aronson: 0098; through the client account management portal, clients may add, change and delete formats, codes and code translations that are to be used for messages destined to the clients; 0096; when the gateway 200 receives a message, the gateway parses the message to ascertain the message's type; the message type may be explicitly included in a fixed- or variable-location field of the message, or the message type may be determined by otherwise analyzing the message; 0097; the gateway 200 uses the contents of a received message's Receiving Facility and/or Receiving Application field and, in some cases, the transaction type to look up message processing information in the database 230].
Regarding Claims 11-12, which recite a system for managing healthcare data, having the same claim limitations as those in claims 1-2 above, the same rationale of rejection as presented in claims 1-2 is applicable.
Regarding Claims 13-14, which the same claim limitations as those in claims 1-2 above, the same rationale of rejection as presented in claims 1-2 is applicable.
Regarding Claim 15, which recites a computer-implemented method for processing electronic healthcare data, having the same claim limitations as those in claim 1 above, the same rationale of rejection as presented in claim 1 is applicable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See Korpmann (US 2004/0064343; included in IDS) [para. 0471].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD A WAQAS whose telephone number is (571)270-5642. The examiner can normally be reached 8:30 - 5:00 PM.
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, Marcus Smith can be reached at (571) 270-1096. 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.
SAAD A. WAQAS
Primary Examiner
Art Unit 2468
/Saad A. Waqas/Primary Examiner, Art Unit 2468