Patent Application
20230207076
Patients make purchases of health-related services all the time, e.g., to purchase life insurance, disability insurance, or supplemental or secondary life insurance. Patients also file claims, e.g., for related injuries or automotive-related injuries. To process these purchases or claims, third-party entities such as life insurers and secondary/supplemental insurance organizations, insurance companies, and various third parties require access to the patient’s medical history or records.
Currently, it is the responsibility of the patient to get the patient’s medical history or records to these third-party entities. Often, the patient would have to prepare and submit a HIPAA authorization form for each doctor or health-service provider that is required by the third-party entity. The process is time-consuming, particularly on the part of the patient, and it is often incomplete. Because the responsibility is on the patient to identify all of his or her healthcare service providers, omissions can occur unintentionally, e.g., if the patient omits information inadvertently or if the patient did not believe certain information to be pertinent. In certain instances, omissions can be intentional. Similarly, life insurers, secondary/supplemental insurance organizations, insurance companies, and various third parties, when assessing the patient health to sell a health-related service, desire a complete medical history of the patient.
Efforts are being made to streamline the exchange of patient medical records. There are companies that are providing services for the retrieval of patient medical records. The process is still highly manual. The company would receive multiple facsimiles with HIPAA authorization forms from a patient. The company then contacts the medical provider using the information provided in the form to retrieve the patient medical records. The company then manually collates records and transmit the facsimiles of the records to the requestors. Electronic versions of the same are available.
A system and method are described for collecting and providing health-related information of a patient’s medical record or information from a plurality of health-service providers using a clinical data connector and clinical document collector. In some instances, all or a part of the collected information is received through a web application or web service (e.g., of a third-party requestor). The web application or web service is configured to receive consent from the patient for their medical records, e.g., for a reason/purpose of use of the medical records. In some embodiments, the web application or web service is configured to present a general consent form to the patient through a customer portal curated by the web application or web service to receive the authorization from the patient. The web application or web service then performs a verification of the identity of the patient using the provided information and transmits a request having the proof of validation and patient information to the clinical data connector. In some embodiments, the web application or web service operates with other verification services.
The clinical data connector searches and matches all records related to the patient using the provided patient information to identify service providers. In some embodiments, the clinical data connector generates a task that is serviced by the clinical document collector to interrogate the service provider’s databases, through an API, to determine if it has medical records of the patient. The clinical document collector then collects the medical records from the service provider’s databases, e.g., through the API.
In this workflow, the patient does not have to identify or provide all of this or her medical provider. The clinical data connector and clinical document collector can find by accessing networks of data and performing a patient match. In addition, the patient does not necessarily have to complete an individual HIPAA authorization form for each requested information or for each provider. The general consent form, as provided through the web application or web service, can serve as a proxy for the HIPPA authorization form, or it can be used to generate the HIPPA authorization forms to be provided to each provider from which the medical records are being retrieved. In addition, the clinical data connector and clinical document collector can parse through the provided medical records to populate a specific set of requested medical information.
In an aspect, a system is disclosed comprising at least one computing device having instructions stored thereon that executes a clinical data connector, and a clinical document collector configured to (a) receive a request for clinical documents or clinical information of a patient, the request having (i) a plurality of patient identifier, (ii) a plurality of patient demographic identifier, and (iii) a purpose of use code for the request, (b) verify the request and match a patient in a database using (i) and (ii); (c) retrieve a plurality of clinical documents or clinical information; and (d) transmit the plurality of clinical documents or clinical information a requester or designated third party receiver. The clinical data connector is configured by instructions to execute a plurality of operations in an order to retrieve the plurality of clinical documents or clinical information, wherein each operation creates a task for the clinical document collector and receives a plurality of clinical documents or clinical information from the clinical document collector. The clinical document collector is configured by instructions to execute a plurality of operations in an order to retrieve the plurality of clinical documents or clinical information, wherein each operation receive the task from the clinical data connector; retrieves the plurality of clinical documents or clinical information from the plurality of databases; and transmits the plurality of clinical documents or clinical information to the clinical data connector.
In some embodiments, the request for the clinical documents or clinical information is received from a customer portal application, wherein the customer portal application is configured by instructions to present and receive, via a graphical user interface, an executed general consent form from the patient.
In some embodiments, the request comprises an executed general consent form from the patient.
In some embodiments, the request from the customer portal application is through a SMART on FHIR API.
In some embodiments, the clinical document collector is configured by instructions to search a health exchange system for an available patient access list, wherein the available patient access list is used to create the task for the clinical document collector.
In some embodiments, the clinical data connector is configured to execute a state machine to track the retrieval of the plurality of clinical documents or clinical information.
In some embodiments, the clinical data connector is configured to poll the clinical document collector for a status request of each task, and wherein the reply of the status request include a link to a document store.
In some embodiments, the clinical data connector is configured to request the clinical document collector to request for the clinical documents or clinical information of the patient from the document store by sending a document request the document store using the link.
In some embodiments, the clinical data connector is configured to receive the request to initiate the operation for the retrieval of the clinical documents or clinical information of the patient from a third-party website or portal.
In another aspect, a non-transitory computer-readable medium is disclosed having instructions stored thereon that executes a clinical data connector, and a clinical document collector configured to (a) receive a request for clinical documents or clinical information of a patient, the request having (i) a plurality of patient identifier, (ii) a plurality of patient demographic identifier, and (iii) a purpose of use code for the request, (b) verify the request and match a patient in a database using (i) and (ii); (c) retrieve a plurality of clinical documents or clinical information; and (d) transmit the plurality of clinical documents or clinical information a requester or designated third party receiver. The clinical data connector is configured by instructions to execute a plurality of operations in an order to retrieve the plurality of clinical documents or clinical information, wherein each operation creates a task for the clinical document collector and receives a plurality of clinical documents or clinical information from the clinical document collector. The clinical document collector is configured by instructions to execute a plurality of operations in an order to retrieve the plurality of clinical documents or clinical information, wherein each operation receive the task from the clinical data connector; retrieves the plurality of clinical documents or clinical information from the plurality of databases; and transmits the plurality of clinical documents or clinical information to the clinical data connector.
In some embodiments, the request for the clinical documents or clinical information is received from a customer portal application, wherein the customer portal application is configured by instructions to present and receive, via a graphical user interface, an executed general consent form from the patient.
In some embodiments, the request comprises an executed general consent form from the patient.
In some embodiments, the request from the customer portal application is through a SMART on FHIR API.
In some embodiments, the clinical document collector is configured by instructions to search a health exchange system for an available patient access list, wherein the available patient access list is used to create the task for the clinical document collector.
In some embodiments, the clinical data connector is configured to execute a state machine to track the retrieval of the plurality of clinical documents or clinical information.
In some embodiments, the clinical data connector is configured to poll the clinical document collector for a status request of each task, and wherein the reply of the status request include a link to a document store.
In some embodiments, the clinical data connector is configured to request the clinical document collector to request for the clinical documents or clinical information of the patient from the document store by sending a document request the document store using the link.
In some embodiments, the clinical data connector is configured to receive the request to initiate the operation for the retrieval of the clinical documents or clinical information of the patient from a third-party website or portal.
In another aspect, a method is disclosed comprising (a) receiving at a clinical data connector a request for clinical documents or clinical information of a patient, the request having (i) a plurality of patient identifier, (ii) a plurality of patient demographic identifier, and (iii) a purpose of use code for the request, (b) verifying the request and match a patient in a database using (i) and (ii); c) retrieving a plurality of clinical documents or clinical information; and (d) transmitting the plurality of clinical documents or clinical information a requester or designated third party receiver. The clinical data connector is configured by instructions to execute a plurality of operations in an order to retrieve the plurality of clinical documents or clinical information, wherein each operation creates a task for the clinical document collector and receives a plurality of clinical documents or clinical information from the clinical document collector. The clinical document collector is configured by instructions to execute a plurality of operations in an order to retrieve the plurality of clinical documents or clinical information, wherein each operation receive the task from the clinical data connector; retrieves the plurality of clinical documents or clinical information from the plurality of databases; and transmits the plurality of clinical documents or clinical information to the clinical data connector.
In some embodiments, the request for the clinical documents or clinical information is received from a customer portal application, wherein the customer portal application is configured by instructions to present and receive, via a graphical user interface, an executed general consent form from the patient.
Additional advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description or may be learned by practice of the invention. The advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
The accompanying figures, which are incorporated herein and form part of the specification, illustrate systems and methods for updating and validating medical records. Together with the description, the figures further serve to explain the principles of the systems and method described herein and thereby enable a person skilled in the pertinent art to make and use the systems and methods for updating and validating medical records.
To facilitate the collecting and providing of the health-related information, the environment 100 includes a platform 102 that includes the clinical data connector 104 and the clinical document collector 106. In the example shown in
In some embodiments, the data sources (e.g., 110a, 110b, 110c) may employ application-specific interfaces 116 that are configured to service a request (e.g., 108) and to transfer of the data 112 to the requester or provided receiver. In some embodiments, data source 110 may provide a portal 118 for the servicing of a request 108 (shown as 108a).
The platform 102 can operate with a web application or service 120 shown executing on a computing device in
Individuals (e.g., patients) can enter the web application or services through a terminal 122, which launches an ID proofing process. The verification may employ the NIST IAL level 2 verification process. IAL2 requires identity proofing that can require a government-issued identification (e.g., driver’s licenses information) in which the issuing entity had employed two pieces of superior or strong evidence to issue (e.g., government document, comparison to biometric).
The web application or web service 120 can generate an identity token and connect to the platform 102 through to an API 126 (e.g., SMART on FHIR API) to share the identity token and verify that the individual was proofed. The identity token can include specific patient demographic data (e.g., name, date of birth, home address, phone number, email address, etc.). The platform 102 can extract the demographic information from the token and send it to an identity manager service 128, which can match the patient to one or more local and/or global database(s) (e.g., a health data exchange, e.g., the CommonWell Health Alliance) to locate the patient’s data. The health data exchange may include additional functions in a suite of interoperability services (e.g., with APIs that can embed directly into a given application).
Once data are found in the local and/or global database(s), clinical document collector 106 can generate a request for the patient data from the data sources (e.g., 110a, 110b, 110c). In some embodiments, the request is in the form of a consolidated-clinical document architecture (C-CDA) compliant message or document. The C-CDA is a standard having common architecture, coding, semantic framework, and markup language for the creation of electronic clinical documents. The records 112, e.g., as C-CDA documents, are then returned to the platform 102. The C-CDA record (e.g., 112) may be parsed using FHIR API. Clinical document collector 106 can return a set of full C-CDAs to the platform 102 and the clinical data connector 104 can parse the C-CDA documents and return individual FHIR resources. The APIs (e.g., 116, 126) may employ SMART and FHIR, e.g., managed by HL7.
Indeed, the entire process is electronic. Individuals (e.g., patients) do not have to identify providers in advance or remember portal credentials from a provider. The process can be made much more user-friendly and ensure that all of a patient’s data is pulled back and parsed into structured data within the customer’s system rather than just viewing copies.
In an example implementation, the individual (e.g., patient) can access the web application or service 120 directly. The web application or service 120 is configured to receive information about the recipient of the record from the patient.
In another example implementation, the individual (e.g., patient) can access the web application or service 120 by being directed there through a third-party portal 134. The third-party portal 134 can be a company’s website that sells health-related products and services of that company, e.g., life insurance, disability insurance, supplemental, secondary life insurance, and the like. In some embodiments, the third-party portal 134 can be a medical insurance provider’s website or claim processor to process a claim, e.g., medical insurance claim, disability insurance claim, worker compensation claim, bodily injury insurance claim, medical, legal damage claim, and the like.
When accessing a third-party portal 134, upon purchasing or providing information for the purchase of a health-related service or to process a claim provided by the company, the third-party portal 134 can direct the individual (e.g., patient) to web application or web service 120, e.g., as an external internet link. In other embodiments, the third-party portal 134 can execute a client service of the web application or web service 120, which provides the data to the web application or web service 120. In yet other embodiments, the third-party portal 134 can execute a compatible service to acquire the data from the individual (e.g., patient) and then provide the acquired data to the web application or web service 120. In yet other embodiments, the third-party portal 134 can execute a compatible service to acquire the data from the individual (e.g., patient) and then provide the acquired data to the clinical data connector 104.
In one example, the platform 102 may execute a SMART on FHIR application to which an individual/patient can validate their identity. The SMART on FHIR application can employ a third-party identity proofing service. SMART is an open-source, standards-based API that offers secure and universal access to EHRs. The SMART platform builds on the existing FHIR standard, hence known as “SMART on FHIR.” The application will then use the identity-proofed unique identifier to register the person with a connector FHIR server (e.g., 102). This, in turn, triggers an activity in the connector server (e.g., 102) to locate clinical documents belonging to that person and cache the results in a local data store.
Indeed, the request for HIPPA-related authorization includes a purpose-of-use indication and the user signature. This single HIPPA-related authorization release can be employed to generate a plurality of authorization releases with a plurality of data sources (e.g., 110a, 110b, 110c). In some embodiments, multiple HIPPA-related authorization releases may be presented and received, e.g., for each type of purpose of use.
Session 208 then transmits (220) via a POST message comprising a request for “SAML” authentication to a SMART-based API (222). Security Assertion Markup Language, or “SAML,” is a standardized protocol for an external application and/or service to determine a user is who they say they are. SAML employs single sign-on (SSO) technology to authenticate a user once and then communicate that authentication to multiple applications. The SMART-API 222 then performs validation (224) with the patient through the SMART UI (204) via SSO authentication. The patient also provides his or her demographic information through the SMART API 222 of the SMART UI 204 to send (228) a POST message comprising the user-provided demographic information to a state machine endpoint (230) of the connector FHIR server (232). Demographic information can include any identifying information about the person, such as name, DOB, address, phone, email, etc., that are available in a medical database to which the medical database can be queried to determine if a patient is present in that database.
Following an authentication session, the session 208 then initiates a new session for a state machine 236 at the connector FHIR server (232). The SMART API 222 then directs (238) the smart UI (204) to present a successful or failed session, and registration completes (240).
Upon initiating a new state machine session, the state machine (236) of the connector FHIR server (232) creates a new set of FHIR tasks to request documents from the collector service 244 (shown as “Collector FHIR Server”) collectively shown as 242.
The connector (232) then sends (310) a request to determine, e.g., from the health data exchange database, the number of data sources associated with the patient using the provided patient demographic data. Collector 244 invokes (312) a health data exchange patient-access pipeline (e.g., CommonWell patient-access pipeline) and returns (314) the list of available patient access as tasks to connector 232. One or more pipeline processors perform a series of activities to locate and retrieve clinical data for the specified patient. As events occur during this processing, the connector (232) updates the data in the task resource for that patient to reflect the current state of processing, including events listed in Table 1.
Because the API design provides a mechanism for the data consumers to retrieve the task from connector 232 at any time during and after processing (e.g., GET https://connector.chc.com/Task/15), the connector 232 may be obligated to return the current status and any additional information relevant to the processing of the request in the body of the Task resource that it returns in response to the request (e.g., errors and documents).
With the list of available patient access, the state machine 232 can initiate a set of asynchronous retrievals of documents from the data source databases (e.g., associated with 110a, 110b, 110c). In the example shown in
Table 2 shows an example task status request 320. The example is shown in JSON and includes a reference to the line number.
In reply to each GET task status request 320, the connector FHIR server (232) attempts to retrieve records from each of the data sources (e.g., 110a, 110b, 110c) and sends a current status of that request to the data sources as a RETURN task reply 322.
Once the document retrieval task is complete, the final status of the task includes a link to a document bundle and the data source identifier/address. Table 3 shows an example output of the final task status request.
With the list of links to the records, the state machine 232 can initiate a set of asynchronous retrievals of documents from the data source databases (e.g., associated with 110a, 110b, 110c). In the example shown in
Table 4 shows an example request for binary 328. Table 5 shows an example reply for binary 330.
In the document retrieval state 410, the state machine 400 transitions to an update database state 412 if there is no record to retrieve based on the task status. The state machine 400 initiates a set of sub-states 414 that each enters a collector document retrieval state 416 and an upload document state 418 to upload the retrieved files to a third-party system. Once all the documents are retrieved, the state machine 400 enters the success state 420.
Tables 6 and 7 respectively show a JSON message for the required data and for a request.
In Table 6, the identifier array may contain other identifiers but MUST include an identifier that has been issued by a NIST compliant identity validation service. In Table 7, the First Name is provided as the first element in the “given” array. The Middle Name(s) will be the next elements in the “given” array. Each given name will be in its own element. Additional data may be transmitted, including the Patient Last Name, the Patient Date of Birth, the Patient Postal Code, and the Service Date Range.
The Connector application includes event-driven processing pipelines. This architectural pattern provides for separation of concerns, component isolation, and for extending and updating the system to support new types of data sources and/or consumers, post-processing of CDA documents, as well as adjacent use cases for reporting and analytics.
The publicly accessible API for the Connector services supports the asynchronous, task-based workflow. In considering a technical approach, the design considers using the standard FHIR resource model for implementing an API.
In some embodiments, the connector is implemented according to a Da Vinci Clinical Data Exchange (CDex) Implementation Guide (IG). This design has considered the Da Vinci Clinical Data Exchange (CDex) implementation guide published by HL7, providing guidance on exchange methods, payloads, and search criteria for the exchange of clinical information between provider and other providers and/or payers.
Collector Request queue (602): an SQS queue receiving filtered TaskAccepted events (the triggering event for every data retrieval pipeline).
POST Task function (604): a sequence of functions responsible for retrieving a patient record from the Patient data store, extracting the NPI from the record and using a health data exchange REST-based Home Community ID lookup service (e.g., CommonWell’s REST ID lookup service) to retrieve a list of associated Home Community Identifiers. On success, publishes a CollectorTaskPending event.
Collector Pending queue (606): an SQS queue receiving filtered CollectorTaskPending events.
Get Task Status function (608): invokes a GET on the Task against the Collector FHIR API to retrieve the current version of the Task. The function then interrogates the status property: if the status is still in-progress, the function publishes a CollectorTaskPending event; if complete, the function publishes a CollectorTaskCompleted event.
Collector Completed queue (610): an SQS queue receiving filtered CollectorTaskCompleted events.
RetrieveAndStore function (612): retrieves the document from Collector and stores the result to the designated output folder.
Output folder (614): an S3 bucket to hold the retrieved documents.
The pipeline can back up events from the Connector topic to an Amazon S3 bucket, e.g., using an Amazon Kinesis Data Firehose stream.
POST [base/Task] (702): Initiates a request for retrieval of clinical documents for an identity-proofed individual. Table 8 shows information included in the request.
GET [base(see page 8)1/Binary/{id4}: Returns a retrieved document from the server using the link provided in the Task resource output property.
Numerous other general purpose or special purpose computing devices environments or configurations may be used. Examples of well-known computing devices, environments, and/or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, network personal computers (PCs), minicomputers, mainframe computers, embedded systems, distributed computing environments that include any of the above systems or devices, and the like.
Computer-executable instructions, such as program modules, being executed by a computer may be used. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Distributed computing environments may be used where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules and other data may be located in both local and remote computer storage media, including memory storage devices.
With reference to
Computing device 800 may have additional features/functionality. For example, computing device 800 may include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in
Computing device 800 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the device 800 and includes both volatile and non-volatile media, removable and non-removable media.
Computer storage media include volatile and non-volatile, and removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Memory 804, removable storage 808, and non-removable storage 810 are all examples of computer storage media. Computer storage media include, but are not limited to, RAM, ROM, electrically erasable program read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device 800. Any such computer storage media may be part of computing device 800.
Computing device 800 may contain communication connection(s) 812 that allow the device to communicate with other devices. Computing device 800 may also have input device(s) 814 such as a keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 816 such as a display, speakers, printer, etc., may also be included. All these devices are well known in the art and need not be discussed at length here.
It should be understood that the various techniques described herein may be implemented in connection with hardware components or software components or, where appropriate, with a combination of both. Illustrative types of hardware components that can be used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc. The methods and apparatus of the presently disclosed subject matter, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium where, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the presently disclosed subject matter.
Although exemplary implementations may refer to utilizing aspects of the presently disclosed subject matter in the context of one or more stand-alone computer systems, the subject matter is not so limited, but rather may be implemented in connection with any computing environment, such as a network or distributed computing environment. Still, further, aspects of the presently disclosed subject matter may be implemented in or across a plurality of processing chips or devices, and storage may similarly be effected across a plurality of devices. Such devices might include personal computers, network servers, and handheld devices, for example.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
