AUTOMATED TRANSFORMATION DOCUMENTATION OF MEDICAL DATA

Systems, methods, and storage media useful in a healthcare cloud computing platform to transform, deduplicate and store medical data from third-party databases to a patient's primary medical record in the healthcare cloud computing platform. Exemplary implementations may: load and read data from third-party databases, and determine if it is duplicative of what is in the patient's primary record. Other embodiments, provide a method for ranking medical data from two different third-party databases to determine which medical data should be written to the patient's primary medical record in the healthcare computing platform.

BACKGROUND

Provider and clinician burden is an ongoing issue across healthcare. Clinical data is being captured within more and more sources system. Clinicians are unable to access information from multiple sources when treating a patient. Clinicians have an incomplete picture of a patient's health history when utilizing a conventional electronic medical record. Third-party databases contain information for the patient not in the patient's conventional electronic medical record that is maintained with a single healthcare system or electronic health records (EHR) vendor.

SUMMARY

Embodiments of the present invention improve implementation and on-going costs of maintaining patient data from multiple disparate sources. Embodiments of the present invention allow medical data for an individual patient to be maintained in a cloud environment and allows for the scaling of the data on a national and international scale rather than patient data being maintained in separate, disparate databases and electronic health records.

Embodiments of the present invention are not limited to location and demographics of patients. Additionally, embodiments allow for consistent implementation and storage of accurate, non-duplicative medical data from multiple databases for individual patients in single longitudinal record for the individual patient maintained in a healthcare cloud computing environment.

Embodiments of the present invention allow for clinicians to retrieve and view the most up-to-date information for a patient being treated regardless of the EMR system being utilized. Embodiments of the present invention identify other venues of care and third-party databases as “trusted sources”. This allows for a flexible and elastic healthcare cloud computing platform that can be built to designate discrete clinical concepts to auto-write into the medical data being viewed for the individual patient, increasing efficiency and decreasing time spent by a clinician reviewing information.

In one embodiment, the aggregated and non-duplicative patient data is presented to providers and clinicians within their normal workflow, broken out by clinical concept. Medical data for patient(s) is auto-written and reconciled and resides within the record as discrete data retaining original author and source.

Medical data is presented to providers and clinicians within their normal workflow, broken out by clinical concept. The healthcare cloud computing platform includes medical data for individual patients across various internal and external sources giving a more complete view of an individual's health record. Embodiments of the present invention allow these large amounts of data to be normalized, deduplicated, ranked and written into the patient's primary record in seconds to minutes rather than taking days and weeks to collect and input into a patient's primary record.

DETAILED DESCRIPTION

The subject matter of the present invention is being described with specificity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described. As such, although the terms “step” and/or “block” can be used herein to connote different elements of system and/or methods, the terms should not be interpreted as implying any particular order and/or dependencies among or between various components and/or steps herein disclosed unless and except when the order of individual steps is explicitly described. The present disclosure will now be described more fully herein with reference to the accompanying drawings, which may not be drawn to scale and which are not to be construed as limiting. Indeed, the present invention can be embodied in many different forms and should not be construed as limited to the aspects set forth herein. Further, it will be apparent from this Detailed Description that the technological solutions disclosed herein are only a portion of those provided by the present invention. As such, the technological problems, solutions, advances, and improvements expressly referenced and explained herein should not be construed in a way that would limit the benefits, improvements, and/or practical application of the discussed aspects of the present invention.

The healthcare cloud computing platform of embodiments of the invention, advances interoperability between healthcare systems, public records, and electronic medical record vendors. The healthcare cloud computing platform allows for more accurate data to be added to an existing patient's electronic medical record by evaluating records from a third-party database using a state manager and normalization of records to a FHIR standard. The healthcare cloud computing platform removes duplicate records, does a side-by-side reconciliation of new records, and identifies trusted third-party database sources.

The healthcare cloud computing platform allows for automatic, without user intervention, seamless reconciliation of medical data for patients. The healthcare cloud computing platform is operable across various venues of care, including ambulatory, acute, emergency, and specialized care. The healthcare cloud computing platform is an immersive and efficient experience for clinicians to evaluate and view third-party patient health history, documents and results. It also reduces the need to review duplicate clinical data and removes unnecessary clinician interaction from trusted sources. Profile data is displayed in a side-by-side view that is more conducive and intuitive to cognitive comparison needed when evaluating subjective data. Graphical user interfaces of the healthcare cloud computing environment allow clinicians to view a third-party data that has been evaluated by the healthcare cloud computing environment along with data that is written to the patient's electronic medical record. The healthcare cloud computing platform of the present application provides providers and clinicians a more efficient experience with comprehensive patient records with a streamlined user experience.

FIGS. 1A and 1Billustrate a system100configured to be useful in a computer healthcare system to consume clinical quality language queries in a programmatic manner, in accordance with one or more implementations. In some implementations, system100may include one or more healthcare cloud computing platforms102. Computing platform(s)102may be configured to communicate with one or more remote platforms104according to a client/server architecture, a peer-to-peer architecture, and/or other architectures. Remote platform(s)104may be configured to communicate with other remote platforms via computing platform(s)102and/or according to a client/server architecture, a peer-to-peer architecture, and/or other architectures. Users may access system100via remote platform(s)104.

A given remote platform104may include one or more processors configured to execute computer program modules. The computer program modules may be configured to enable an expert or user associated with the given remote platform104to interface with system100and/or external resource(s)120, and/or provide other functionality attributed herein to remote platform(s)104. By way of non-limiting example, a given remote platform104and/or a given computing platform102may include one or more of a server, a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a NetBook, a Smartphone, a gaming console, and/or other computing platforms.

External resources120may include sources of information outside of system100, external entities participating with system100, and/or other resources.

Computing platform(s)102may include electronic storage122, one or more processors124, and/or other components. Computing platform(s)102may include communication lines, or ports to enable the exchange of information with a network and/or other computing platforms. Illustration of computing platform(s)102inFIG. 1Ais not intended to be limiting. Computing platform(s)102may include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to computing platform(s)102. For example, computing platform(s)102may be implemented by a cloud of computing platforms operating together as computing platform(s)102.

Electronic storage122may comprise non-transitory storage media that electronically stores information. The electronic storage media of electronic storage122may include one or both of system storage that is provided integrally (i.e., substantially non-removable) with computing platform(s)102and/or removable storage that is removably connectable to computing platform(s)102via, for example, a port (e.g., a USB port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). Electronic storage122may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.), electrical charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drive, etc.), and/or other electronically readable storage media. Electronic storage122may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and/or other virtual storage resources). Electronic storage122may store software algorithms, information determined by processor(s)124, information received from computing platform(s)102, information received from remote platform(s)104, and/or other information that enables computing platform(s)102to function as described herein.

Processor(s)124may be configured to provide information processing capabilities in computing platform(s)102. As such, processor(s)124may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information. Although processor(s)124is shown inFIG. 1Aas a single entity, this is for illustrative purposes only. In some implementations, processor(s)124may include a plurality of processing units. These processing units may be physically located within the same device, or processor(s)124may represent processing functionality of a plurality of devices operating in coordination. Processor(s)124may be configured to execute modules106,108,110,112,114, and/or116, and/or other modules. Processor(s)124may be configured to execute modules106,108,110,112,114, and/or116, and/or other modules by software; hardware; firmware; some combination of software, hardware, and/or firmware; and/or other mechanisms for configuring processing capabilities on processor(s)124. As used herein, the term “module” may refer to any component or set of components that perform the functionality attributed to the module. This may include one or more physical processors during execution of processor readable instructions, the processor readable instructions, circuitry, hardware, storage media, or any other components.

It should be appreciated that although modules106,108,110,112,114, and/or116are illustrated inFIG. 1Aas being implemented within a single processing unit, in implementations in which processor(s)124includes multiple processing units, one or more of modules106,108,110,112,114, and/or116may be implemented remotely from the other modules. The description of the functionality provided by the different modules106,108,110,112,114, and/or116described below is for illustrative purposes, and is not intended to be limiting, as any of modules106,108,110,112,114, and/or116may provide more or less functionality than is described. For example, one or more of modules106,108,110,112,114, and/or116may be eliminated, and some or all of its functionality may be provided by other ones of modules106,108,110,112,114, and/or116. As another example, processor(s)124may be configured to execute one or more additional modules that may perform some or all of the functionality attributed below to one of modules106,108,110,112,114, and/or116.

Computing platform(s)102may be configured by machine-readable instructions105. Machine-readable instructions105may include one or more instruction modules. The instruction modules may include computer program modules. The instruction modules may include one or more of record retrieval module106, state machine module108, deduplication module110, rules module112, ranking engine module114, and provenance module116, and/or other instruction modules.

Platform102may be Cerner HealtheIntent as shown inFIG. 1B. Platform102can ingest third-party clinical content/knowledge at scale to support an interoperable clinical knowledge management ecosystem. Platform102delivers knowledge-based products, such as quality measures, clinical pathways, and consumer engagement by integrating third-party intelligence into care delivery processes. Platform102comprises information from multiple EHR databases, such as multiple hospital systems.

Record retrieval module106is configured to read records from an external resource120or third party EMR104. Record retrieval module106discovers and consolidates clinical medical data for an individual found across health networks and third party EMRs. Record retrieval module106initiates an interoperability process by triggering the record querying process to retrieve external resources120. External resources120include third-parties, such as health information exchange (HIE), immunization registry, governmental healthcare registry, pharmaceutical registry, and third-party electronic medical record provider. Clinical medical data for individuals exists in a variety of different sources, such as National Exchange thru CommonWell and Carequality, state/regional HIEs, consumers, consumer devices, hospitals, ambulatory practices, pharmacy claims, and fill data from pharmacy databases, such as Surescripts, state vaccination registries, and other connected venues of care. Third party EMRs104are electronic medical records hosted by different vendors and separate from healthcare cloud computing platform102. External resources120and third party EMRs104are collectively known as third-party databases for this application and are disparate computing systems and EMR vendors from the healthcare cloud computing platform102.

The external resources120and third party EMRs104are maintained separate from the healthcare cloud computing platform. Registrations, admissions, transfers, and discharges from a healthcare facility can all be configured as triggers for record retrieval by module106. For ambulatory and clinic-based locations, record retrieval module106may also be triggered by upcoming scheduled appointments. Additional triggers may be built in and process on a regular basis, like nightly or weekly batch processing.

Record retrieval module106plugs into an external resource's existing connection or exchange technology. In one embodiment, record retrieval module106utilizes application program interfaces to access external resources/third-party databases120. The clinical data retrieved from external resources120is then sent to a healthcare cloud computing platform120, including but not limited to Healthe Intent—Longitudinal Record. Record retrieval module106queries and retrieves clinical data automatically, without user intervention, so that a clinician or provider has access to the information before seeing a patient.

The clinical healthcare data from the external resources120received by the healthcare cloud computing platform120is aggregated. The healthcare cloud computing platform120also consumes direct data sources, such as a clinical electronic medical record system, such as Cerner Millennium.

Generally, EMRs130ofFIG. 1B(sometimes referred to as electronic health records (EHRs)), may comprise data comprising electronic clinical documents, such as images, clinical notes, orders, summaries, reports, analyses, information received from clinical applications, and medical devices, or other types of electronic medical documentation relevant to a particular patient's condition and/or treatment. The patient data from EMR130may persist in a local copy of the patient's EMR or may be stored in a cloud computing environment such as healthcare cloud computing platform102. Electronic clinical documents may contain various types of information relevant to the condition and/or treatment of a particular patient and can include information relating to, for example, patient identification information, images, alert history, previously consumed neuropsychiatric drugs, culture results, patient-entered information, physical examinations, vital signs, past medical histories, surgical histories, family histories, histories of present illnesses, current and past medications, allergies, symptoms, past orders, completed orders, pending orders, tasks, lab results, other test results, patient encounters and/or visits, immunizations, physician comments, nurse comments, other caretaker comments, clinician assignments, and a host of other relevant clinical information. Further, in some embodiments, patient data stored in the EMR may include patient demographic data, such as age, sex, race, nationality, socioeconomic status, marital status, and employment status and history. This data may further include the patient's insurance information, such as the insurance provider and the type of plan. Additional patient data may include previous and current home and work addresses.

Other types of patient data stored in the EMR may include current patient data and historical patient data. In exemplary aspects, current patient data includes data relating to the patient's labs, vitals, diagnoses, and medications from a current encounter (e.g., a current admission to a healthcare facility, a current visit to an outpatient facility, or a current period of receiving home healthcare services). The current patient data may include a diagnosis and/or treatment (including medications administered or ordered and procedures performed or ordered). During the current encounter, the patient may be diagnosed or treated with a condition, such as asthma, cancer, or heart disease, for example. Current patient data may further include lab results (e.g., physiological data), including vital sign data, from the current encounter. Historical patient data may include information about the patient's past encounters at the current healthcare facility or other healthcare facilities, past encounters at a post-acute care facility, etc. In some embodiments, historical patient data includes previous diagnoses, medications, and lab results.

Further, this patient data may be received from different sources thus constituting the patient's longitudinal record132. In other embodiments, data relating to the patient's current condition and/or patient demographics may be received directly from a user, such as the patient or a care provider, inputting such information into a user device. Patient data for the longitudinal record132may come from the patient's EMR130, data from third party EMRs104for the patient, external resources120. Some current patient data, such as patient variable values, may be received from one or more sensors or monitoring devices or directly from a laboratory running the laboratory procedures. Additionally, historical patient information may be received from the patient's EMR and/or from insurance claims data for the patient. For example, data from in-home care services, hospitals, or any healthcare facility may be received. In an alternative embodiment, the patient's history may be received directly from the patient, such as during registration when admitted to a care facility for the current encounter or starting the current care services (such as with in-home care services).

Medical data elements may include patient condition, orders, patient demographic information (age, gender, height, weight), vital signs, test results, images, medications, medication administration, tasks, facility information, and caregiver information. The database record store122includes medical data elements from a variety of electronic health records, such medical data elements directly from the patient's EMR, such as Cerner Millennium, and utilizing the modules106,108,110,112,114, and116data that has been transferred and consumed by the healthcare cloud computing resource102from external resources120and third party EHRs104, such third-party databases (flat files, CCD and HL7) as shown inFIG. 1B.

The healthcare cloud computing platform, utilizing state machine module108, deduplication module110, rules module112, ranking engine module114, and provenance module116, assembles the data collected from different sources into a single longitudinal record132for any given patient and is stored in electronic storage122of healthcare cloud computing platform102. Once assembled into a longitudinal record132, the aggregated data is available for analytics and for provider and clinician workflows using an EMR format, such as Cerner Millennium.

State machine module108processes medical data received from external resources120. State machine module108reads the new data received from external source(s)120and normalizes the data utilizing FHIR standards. State machine module108uses state transformation to read and transform data from external resource(s)120. State machine module108performs parallel reads and transformations such that information for multiple patients and/or from multiple resources can be performed efficiently.

State machine module108has state machine definitions and only after one definition is completed will the next occur. State machine definitions may be based on medical concept, where each medical concept has multiple medical properties defined to be evaluated. For example, a medical concept includes one or more of the healthcare organization, practitioner, encounters, problems, encounter diagnosis, allergies, medications, immunizations, procedures vials general lab results, CCD, clinical notes, pathology documents, cardiology documents, radiology documents, and microbiology documents.

The medical properties included for each medical concept may include patient name identifiers, comparison lists, values, systems, medical coding, text data, date of onset, date of documentation, condition type, and diagnosis coding. For example, for the medical concept Allergies, described below, the following medical properties would be read and transformed by state manager module108.

In one embodiment, the state machine definitions are object fields that are defined by JavaScript Object Notation (Json). This structure of state machine modules108allows for additional medical concepts with corresponding medical properties to be added to the state manager module108. In one embodiment, state machine module performs simultaneous parallel reads and transformations of medical data for multiple patients from the third-party database are performed by the healthcare cloud computing platform102. In another embodiment, state machine module108performs parallel reads and transformations of medical data for an individual patient from multiple third-party databases utilizing state transformation. For example, a parallel read and transformation of different medical records for an individual patient are performed simultaneously. Medical Records1and3are read from the external resources120and third party EHR104(HIE1and third party EMR2) and converted using state manager module108. The medical data from external resources120and third party EMR2is read for the Allergy concept, described above, and are converted from the multiple medical properties for the Allergy medical concept into Fast Healthcare Interoperability Resources (FHIR) under the HL7 standards. If needed, the medical records2and4from the primary record (130or132), EMR1, such as Cerner Millennium or Longitudinal Record, for the patient, is read and normalized as well.

Exemplary reference database136ofFIG. 1Bfor Fast Healthcare Interoperability Resources (FHIR) under the HL7 standards shown inFIG. 8.FIG. 9is an exemplary medical concept using FHIR standards and the multiple medical properties for the exemplary medical concept using the FHIR standards and structure. The exemplary medical concept with multiple FHIR medical properties may be applied to multiple different medical concepts further described in this specification. This allows for medical concepts and the multiple FHIR medical properties for the medical concepts to be elastic and flexible based on user preference and as additional information becomes known or desired about a particular medical concept. In one embodiment, the medical concepts and multiple FHIR medical properties for the concept are built using YAML Ain't Markup Language (YAML) and Spring Expression Language (SPEL). YAML is a human-readable data-serialization language used for configuration files and in applications where data is being stored or transmitted. SPEL is powerful expression language that supports querying and manipulating an object graph at runtime. SPEL syntax provides method invocation and basic string templating functionality. YAML and SPEL give context to the medical concepts and medical properties and rules. This allows for a medical concept and rule developer, who may be less experienced in computer programming, to build the medical concepts, medical properties and rules using libraries of code compare medical properties normalized to FHIR without having to write brand new code allowing for many medical concepts, medical properties and rules to be built and executing using healthcare cloud computing platform102. A developer can access a FHIR type utilizing YAML and define rules without writing code and use SPEL expressions to compare the FHIR types without writing additional code.

After a developer has defined the medical concepts, medical properties and rules, when triggered, medical records1and3(and2and4, if needed) for the patient are read and converted accordingly to FHIR medical properties for the allergy medical concept. The medical properties for the exemplary allergy medical concept include provider identifier, clinical status, verification status, type, criticality, text, patient, onset date, patient reference, and last occurrence. Each of these medical properties include multiple subproperties according to FHIR standards. For example, medical property type “allergy” includes a subproperty for “category”. In this instance, the subproperty for type “allergy” is “food”. Medical data from external resources120and third party EMRs104is read and transformed by state machine module108for a medical concept and its properties and subproperties providing an accurate and systemic way to read and normalize medical data from multiple resources and allows the normalized medical data to be compared and interrogated as described in more detail with respect to embodiments of the invention.

Referring again toFIG. 1A, the medical concepts and associate medical properties read and normalized by the state machine module108is stored in provenance module116as being normalized and read. This provides historically documentations of what third-party databases (and patient documents) have been read and normalized by state machine module108. Data provenance captures source/history information.

When the record retrieval module106is triggered, it pulls the patient's record (130or132) from electronic storage122and reads and normalized data from external resources120that has been processed by state machine module108.

Deduplication module110compares read and normalized data for the patient from the one or more external resource(s)120to data from the patient's record (130or132) to identify new data not found in the patient's primary record (130or132). In one embodiment, initially the read and normalized data for the patient from one or more external resource(s)120is compared to data in the patient's EHR from an EHR system, such as Cerner Millennium, to create a longitudinal record132for a patient that has data from a primary EHR system130, third party EHRs104and other external resources120. Once a longitudinal record132exists or is created by the healthcare cloud computing platform102, new data from one or more external resource(s)120is compared to the data for the patient in the patient's longitudinal record132. This allows for a central repository of all data for a patient across multiple EHR systems104,130and external resource(s)120.

The deduplication module110accesses rules to determine whether data for a patient from an external resource120is duplicative of data already in the patient's record (130or132) module110receives the data from external resource120that has been read and normalized by state machine module108. Deduplication module110accesses the patient's primary record (130or132). In some instances, the data in patient's EMR record122or longitudinal record132has been normalized according to FHIR standards.

Deduplication module110applies the rules from rules module112and compares the external resource120data for the patient to the data in the patient's record (130or132) to determine if the data from the external resource120is duplicative of that which is already in the patient's record (130or132). In one embodiment, for a medical concept, each of the medical properties for the medical concept are compared to determine if they are duplicates. For example, the deduplication module110compares the medical properties for the medical concept “allergy” for each of Medical Record1and Medical Record2. In this example, Medical Record1(HIE1) is a record for the patient from an external resource120regional HIE and Medical Record2(EMR1) is the primary record for the patient (130or132).

With reference toFIG. 3, for the medical concept “allergy” the deduplication module110applies rules from rules module112to determine whether an allergy from an external record120is duplicative of an allergy in the patient's record (130or132) by comparing the medical properties “patient”, “coding”, “text”, and “date of “onset” from the external record120and patient's EMR to determine if they match when normalized to FHIR standards. As can be seen, the medical properties of “patient”, “coding”, and “date of onset” match but the “text” property does not match between Medical Record1(HIE1) and Medical Record2(EMR1). Thus, based on the rule set112for the allergy concept, the deduplication module110would determine that Medical Record1(HIE) is not duplicative of allergies already in the patient's primary record (130or132) because all medical properties do not match.

Thus, provenance module116will store that the HIE1and EMR1have been read, normalized and compared with one another to determine if they are duplicative. With reference toFIG. 1B, since the deduplication module110has determined that the allergy in HIE1is not duplicative data in patient's primary record EMR1, the allergy from HIE1is written into the patient's longitudinal record132. As such, both the allergies from both HIE1and EMR1will persist in the patient's long term medical record132.

The deduplication module110determines that the clinical data for the patient from external resource HIE1(120) is new and not duplicative what is already in the patient's record132, and will be displayed to a clinician in within the standard workflow of the EMR/Longitudinal record132as being part of the patient's record. In one embodiment, the clinical data added to the patient's longitudinal record132from an external resource is flagged and identified as “new” to a clinician if it is new to the system and/or the clinician has not seen the new data from the external resource previously.

In another embodiment, the clinical data from an external resource120that has been identified as new for the patient's longitudinal record132will be posted to a clinician and identified as new. The clinician will can review the clinical data from the external resource120and select to post or write the data to the patient's longitudinal record132.

With continued reference toFIG. 3, in another example, the medical properties of “patient”, “coding”, “text”, and “date of onset” match between Medical Record3(HIE2) and Medical Record4(EMR1). Thus, based on the rule set112for the allergy concept, the deduplication module110would determine that HIE2is duplicative of an allergy already in the patient's primary record (EMR1) because all medical properties match.

Thus, provenance module116will store for HIE2and EMR1that medical concept and its properties have been read, normalized and compared with one another to determine if they are duplicative. The provenance module116will store that the HIE2peanut allergy is related to the patient's primary record (EMR1) peanut allergy and provide a link or pointer to HIE2data. The provenance module stores historical data regarding what external records120, EHR records130and third party EHR records have been read, normalized and compared and the outcome of the comparison for a given medical concept. However, the patient's longitudinal record132is the official record for the patient.

With Reference toFIG. 1B, since the deduplication module110has determined that the allergy in third party EMR2is duplicative of data in patient's primary record EMR1, the allergy from patient's primary record EMR1is maintained for the patient and the allergy from third party EMR2is not written into the patient's longitudinal record132. The allergy from the patient's primary record EMR1will persist in the patient's long term medical record132. The allergy from the EMR2will be stored in the provenance module116and will be accessible to the clinician if the clinician chooses to review external records120and third party EMR records104reviewed by the deduplication module110. In one embodiment, the clinician user, while view the patient's primary record (130or132) can drill down on the allergy of EMR1to see if there are an related external records120or third party EMR records104stored by the provenance module110. However, the allergy from the EMR1will be the primary allergy for the patient in the patient's longitudinal record132.

As described above, rules module112contains rules for applying to deduplication as well as ranking rules. While rules for deduplication determine whether an external resource120is duplicative of data already in the patient's primary record (130or132), ranking rules are applied when comparing clinical data for a patient that has been obtained from two outside resources such as external resources120and third party EHRs104.

Ranking engine module114accesses the data read and normalized for two resources from outside the patient's primary record (130or132) for the patient. Accessing ranking rules112and trust repository138, the ranking engine module114, compares medical properties for a medical concept from the two outside resources. For example, with reference toFIG. 6, ranking engine module114is depicted to determine whether to write and store Allergy1from a first outside resource or Allergy2from a second outside resource to the patient's primary record (132). For example, Allergy1and Allergy2have been determined to be the same using the logic of deduplication module110, and now they are ranked using rules from rules engine module114. Rules engine module114has ranking rules and weights to apply to medical properties based on the medical concept. For example for the allergy medical concept ofFIGS. 6 and 7, the ranking rules look to the medical properties of onset date and time (Rule1), clinical status (Rule2) and verification status (Rule3) to determine which of the allergies to write to the patient's primary record (132). Each of rules1,2and3has equal weighting of 0.33 for medical concept allergy. The occurrence (or number of occurrences) of the medical property in the outside resource is multiplied by the weighting factor. For example, the oldest onset allergy wins Rule1. Rule2provides weighted criteria based on four clinical statuses (resolved, inactive, active and null). Rule3provides weighted criteria based on five possible verification statuses (entered in error, refuted, confirmed, unconfirmed and null). The outcomes of each of the rules is summed and the highest value is the winner. Thus, for comparing allergy1and allergy2, allergy1is the winner with 0.66 sum and is written to the patient's primary record (132). The comparison and related data is for both allergy1and allergy2is written to provenance module116for later viewing if requested.

Similar to deduplication module110, ranking engine module may either stage the winning outside resource record data for clinician review and verification before being entered into the patient's primary record (132). Staged data will require a provider or clinician to review and subsequently add the data to the patient's primary record (132). In another embodiment, the winning outside resource data may be directly written into the patient's primary record (132) which in some instances is the legal record.

Outside resource clinical data may be written into the record if it is determined to be from a trusted source138. Healthcare organizations using the healthcare cloud computing platform102can identify outside sources (120or104) of patient data are deemed reliable and opt to directly write data from these outside sources (120or104). In addition, healthcare organizations can adjust trusted sources per medical concept. Directly written clinical data will automatically be written to the patient's primary legal record (132) without a clinical user's interaction.

FIGS. 2, 4 and 5illustrates a methods useful in a healthcare cloud computing platform102, in accordance with one or more implementations. With reference toFIG. 2, operations of method200presented below are intended to be illustrative. In some implementations, method200may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Additionally, the order in which the operations of method200are illustrated inFIGS. 2and described below is not necessarily limiting.

FIG. 2illustrates method200, in accordance with one or more implementations. An operation205may include receiving a trigger to begin method of claim200. Method200may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to state machine module108, in accordance with one or more implementations.

An operation210may include looking up and identifying a patient to perform method200. Operation210may read and normalize a patient identification from one or more outside patient records. For example, utilizing the example above with respect to Medical Records1and3, patient information may be read, normalized and then compared to the master patient index134ofFIG. 1Bat operation215. For example, “patient”: {“reference”: “Patient/23456342”} from Medical Records1and3, may be determined to be patient “Jane Doe” in the patient's primary medical record (EMR1) (130or132) from healthcare cloud computing platform102.

An operation220may include looking up and identifying the organization for each record being analyzed. Operation220may read and normalize an organization from one or more outside patient records (HIE and third party HER). For example, utilizing the example above with respect to Medical Records1and3, organization information may be read, normalized and then compared to trust138ofFIG. 1B. For example, from Medical Record1the organization is determined to be {“system”: “system”: “http://www.examplehie.com”, “value”: “49476534”. Healthcare cloud computing platform102compares this information to trust138and determines Medical Record1comes from trusted HIE1. From Medical Record3, the organization is determined to be “identifier”: [{“system”: “http://acme.com/ids/patients/risks”, “value”: “49476534”} ] and compares this information to trust138. It is determined that Medical Record3comes from an untrusted third party EHR.

Operation255reads the medical concept that is going read, normalized and evaluated by state machine module108. After reading the medical concept, the medical properties and clinical data from the patient's primary medical record (130or132) is accessed at operation260. If needed, the data from the patient's primary medical record (130or132) is read and normalized by state machine module108as described below for trusted HIE1and untrusted third party EHR.

State machine module108initiates multiple operations to begin reading and normalizing data from multiple medical records according to the rules defined in rules engine module112for a medical concept. State machine module108creates multiple queues and states to be processed for multiple medical records and medical concepts. The multiple states include record retrieval, record normalization, patient lookup, organization lookup, and state completion. The state machine108has defined state machine definitions (Json). States are completed in order. For example, the first state must be completed before moving to a second state. The states are completed in parallel by state workers. This provides the piping or backbone to process business logic (rules) for multiple records and multiple medical records in parallel in a timely and efficient manner. The state machine module108and rules module112are maintained separately such that additional medical concepts, medical properties and business logic and rules may be added or deleted from rules module112without impacting the processing performed by state machine module108.

Operations225and230identify the medical concept and defined medical properties to be read for. The identification of the medical concept to be read for may be provided by the healthcare cloud computing platform102. For example, the healthcare cloud computing platform102may have standing instructions to read all medical records for the medical concept “allergies”. Alternatively, based on the type of external resource120or third party EMR104, the medical cloud computing platform102may be instructed to read for only particular medical concepts. For example, the healthcare cloud computing platform may be instructed to only read an immunization registry external resource120for the allergy medical concept.

Operations235and240normalize the medical concept, in this example, allergies. Operations245and250read the medical property “type” for the medical concept and operations265and270normalize “type”. Operations275and280read the medical property “coding” for the medical concept and operations290and285normalize “coding”. Operations295and296read the medical property “text” and operations297and298normalize “text”. In these examples, the medical concepts and medical properties normalized in a FHIR standard as shown in Medical records1and3above.

Operation260accesses the normalized medical data for the medical concept and defined medical properties from the patient's primary record (130or132) to be compared with the data from outside resources read and normalized by state machine module108.

Operation299stores data (or links) for external records120and third party EHRs104in a module that is the same or similar to provenance module116. Operation299further stores that outside records have been read and normalize so that in the future the state machine module108knows that an outside record has been processed by the state machine module108to avoid having to read and normalize the data again. Operation299further stores that the outside record120or104has been read and normalized for an identified patient and organization and an identification that the outside record it is related to a medical concept or property in the patient's primary record (130or132). For example, operation299would store that Record3from EMR2was read and normalized and related to medical concepts and medical elements of Record4of the patient's primary medical record (EMR1) (130or132).

FIG. 4illustrates method400, in accordance with one or more implementations. An operation405accesses duplication rules for method400. Method400may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to deduplication module110and accessing rules from a module that is the same as or similar to rules module112, in accordance with one or more implementations. Operation410accesses the medical properties for a medical concept that have been read and normalized by state machine module108. The rules to determine whether or not a medical record is duplicative or contains duplicate data to another medical record for a patient are stored in rules module112.

Exemplary rules typically include conditional statements, conditional expressions and conditional constructs are features of a programming language. Different computations or actions are performed depending on whether a programmer-specified boolean condition evaluates to true or false. Rules may be achieved by selectively altering the control flow based on some condition.

As described above when discussing the healthcare cloud computing platform, a developer may define particular conditional expressions and constructs for a particular medical concept. For example, the rule set for a medical concept may compare identifiers between normalized data from two different medical records for a patient. It will be appreciated that the identifiers may be a single value, nested values or a list of values. An exemplary conditional rule to determine if a medical record is duplicative or contains duplicate data to another medical record for a patient is shown inFIG. 3.

Operator420determines if the medical properties for two different records indicate they are the same as another record. When operator420determines that the medical properties of a first record and a second record satisfy the conditional rule set, the data in the first and second record is deemed to be the same. If operator425determines that the medical property as the patient's primary record (130or132), operator430keeps the data in the patient's primary record (130or132) and operator435stores the outside record information and review in provenance module116.

When operator420determines that the medical properties of a first record and a second record satisfies the conditional rule set, the data in the first and second record is deemed to be the same. Operator425determines that neither the first nor the second record are not the primary medical record (130or135) for the patient and thus operator440will apply the logic rules for ranking the records using ranking engine module114.

Operator420determines if the medical properties for two different records indicate they are indeed different and not duplicative. When operator420determines that the medical properties of a first record and a second record do not satisfy the conditional rule set, the data in the first and second record is deemed to be different. Operator445writes medical record data not in the patient's primary record (132). In one embodiment, data from the two different records may not be in the patient's primary record and the data is stored in the patient's primary medical record (132). Additionally, operator450stores the evaluation of each record in provenance module116.

FIG. 5illustrates method500, in accordance with one or more implementations. An operation505accesses ranking rules for method500. Method500may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to ranking engine module114and accessing rules from a module that is the same as or similar to rules module112, in accordance with one or more implementations. Operator510accesses the medical properties for a medical concept that have been read and normalized by state machine module108. The rules to determine to rank two outside medical records that have been deemed to be the same by deduplication module110for a patient are stored in rules module112.

Exemplary rules typically include conditional statements, conditional expressions and conditional constructs are features of a programming language. In one embodiment, weights are assigned to different medical properties to rank the records as being more complete or accurate. Exemplary ranking rules for the ranking engine module114are shown inFIGS. 6 and 7. Operator515applies the ranking rules for the identified medical concept and operator520write the medical data for the patient that ranks the highest is written into the patient's primary record (130or132). The lower ranking record and its evaluation is or links are stored by operator525in provenance module116.