When another disparate EHR system receives the unstructured concatenated uniquely labeled standardized electronic data strands disclosed herein, the disparate EHR system reads each unstructured concatenated uniquely labeled standardized electronic data strand, recognizes the A-I+FIC showing it is permanently bound, recognizes the FIC and enters it into its matching structured FIC labeled disparate electronic elemental part. After reading the unstructured data strand, the receiving disparate EHR system follows instructions from its provider as to which and how unstructured concatenated uniquely labeled standardized electronic data strands will be filed.

SCUTWORK provides a simple and inexpensive method for allowing interoperability among disparate medical record systems. Using the standard medical record to label the electronic files allows for the most beneficial SCUTWORK functions, including but not necessarily limited to, a “super medical record” that starts at birth and ends at death; immediate interoperability of the medical record for life-threatening emergencies; and the ability of providers to select specific types of records such as immunizations or a patient's white blood cell count over time. The ability to verify the existence and accountability of specific types of records helps avoid unnecessary duplication of services and will reduce if not eliminate the more than 25 billion dollars of medical waste a year by having access to the entire medical record when it is needed by the medical service provider.

Disparate EHR companies write code into their software to employ the disclosed SCUTWORK principles. SCUTWORK principles enable disparate EHR systems to transform their records from 100% structured data to 100% unstructured data and back again into 100% structured data. It does so without changing the basic structure or operation of any involved EHR. It does so without a third software program, a third party, third computer system, or Health Information Exchange, HIE. Moreover, as a first healthcare provider creates or updates an EHR of a patient, that data is structured data within that healthcare provider's EHR system. When the EHR information is stored on behalf of the patient, the disclosed principles via the SCUTWORK principles allow storing the patient's medical records as unstructured data. When any part or all of that medical record of the patient is accessed by a second healthcare provider, his/her SCUTWORK enable EHR system converts the stored unstructured data back into structured data that is compatible with the system/format of the second healthcare provider.

This simplifies electronic interoperability to only disparate EHRs with structured FIC standard labeling and strands of uniquely concatenated A-I+FIC standard electronic elemental parts with data and unstructured concatenated A-I+FIC standard electronic elemental parts with data strands. SCUTWORK enabled disparate EHRs eliminate all third-party software programs, third-party computers and Health Information Exchanges, HIEs. Although SCUTWORK provides techniques, processes, and quality monitoring, SCUTWORK does not write disparate health record software, nor does it provide a third software or computer system to allow for interoperability. These distinguishing features of SCUTWORK are not limited to only the health field; any professional field that uses uniformly standardized records can benefit from the principles provided by SCUTWORK.

Numerous embodiments and advantages associated with each such embodiment are discussed in further detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description that follows, by way of non-limiting examples of embodiments, makes reference to the noted drawings in which reference numerals represent the same parts throughout the several views of the drawings, and in which:

FIG. 1 illustrates a listing of an exemplary source standard medical record's personal registration FIC labeled elemental parts that may be used to standardize EHRs within the SCUTWORK framework.

FIG. 2 illustrates disparate EHR-1's and EHR-2's structured concatenated FIC labeled electronic elemental parts of personal registration with data fields, but no data, representing exemplary standardized personal registration information, in accordance with SCUTWORK principles disclosed herein.

FIG. 3 illustrates personal registration information of EHR-1 of FIG. 2 after data has been entered in each FIC labeled elemental part, resulting in the generation of the A-I label of a patient visit and its addition to the FIC labeled elemental parts to create structured concatenated A-I+FIC standard electronic elemental parts with data strands.

FIG. 4 illustrates how the structured concatenated A-I+FIC standard electronic elemental parts with data strands are extracted from EHR-1 of FIGS. 2 and 3 to create unstructured concatenated A-I+FIC standard electronic elemental parts with data, and are transferred to a portable storage device.

FIG. 5 illustrates how the unstructured concatenated strands of A-I+FIC standard electronic elemental parts with data on the portable storage device are transferred to disparate EHR-2's system, read by EHR-2's system, matched to EHR-2's FIC standard labels, and inserted into EHR-2's structure to created structured concatenated A-I+FIC standard electronic elemental parts with data.

The above-referenced figures are provided herein for the purpose of illustration and description only and are not intended to define the limits of the disclosed principles.

DETAILED DESCRIPTION

In view of the foregoing, through one or more various aspects, embodiments and/or specific features, the present disclosure is intended to bring out one or more of the advantages that will be evident from the description. The present disclosure makes reference to one or more specific embodiments by way of illustration and example. It is understood, therefore, that the terminology, examples, drawings and embodiments are illustrative and are not intended to limit the scope of the disclosure.

The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Accordingly, new claims may be formulated during prosecution of this application (or an application claiming priority thereto) to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the appended claims.

The disclosed principles provide systems and methods that rely on labeling an electronic record with a standard medical record. This requires the source standard medical record (SMR) to be divided into elemental parts that become the standard for the division of all disparate electronic health records (EHRs) into elemental parts. The elemental parts of the SMR are labeled with a distinct field indicator code (FIC) for each part, and these become the universal standard for FIC labeling of all disparate EHR electronic elemental parts. The disparate EHR's standardized FIC labeled elemental parts are concatenated in the same manner, creating standardized concatenated FIC labeled electronic elemental parts for all disparate EHRs. The extraction of accountability individual fields from an EHR creates an accountability information identifier (A-I) uniquely labelling all data for any one patient service. As data is entered, the A-I is created and data+A-I are added to an appropriate FIC standard electronic elemental part. The combination of the A-I and FIC uniquely labels each and every concatenated electronic elemental part and the data therein. The portion of the EHR to be shared is selected by the provider, cut into unstructured uniquely labeled concatenated A-I+FIC standard electronic elemental parts with data, and stored as a separate file external to the EHR system. Using HIPAA compliant methods, the unstructured elemental data strands (each comprised of A-I+FIC+data) are transferred to a second different disparate EHR system enabled with SCUTWORK principles. The disparate EHR system reads the unstructured data, recognizes the standardized FIC labels, and matches and places each unstructured concatenated A-I+FIC standard electronic elemental parts with data into its standardized FIC structure.

The source SMR is derived from the best found examples of the standard medical records. SCUTWORK chooses which combination of electronic and paper source medical records to use. SCUTWORK combines these choices to create a complete standard medical record, or the source standard medical record. This source standard medical record becomes the standard structure for all EHRs deconstructed or reconstructed using the SCUTWORK principles.

To do this, the SCUTWORK principles divide the source standard medical into elemental parts. The source standard medical record is completely divided into elemental parts. Every elemental part is different from the other elemental parts.

The SCUTWORK principles create an FIC for each elemental part of the source standard medical record. FIG. 1 illustrates FIC labeled elemental parts of the personal registration information, 100, of the source standard medical record that may be used as part of the universal standard of the SCUTWORK framework. In FIG. 1, 101 illustrates the FIC for elemental part “Last Name”. The source SMR's FIC labeled elemental parts have no data fields and no data. The first data entered for any patient service is registration information. The registration information data represents accountability information. The accountability information in the registration data fields for any one service are used to create the A-I.

Each disparate EHR company uses the FIC labeled elemental parts derived from the source SMR as the universal standard from which to divide its electronic record into elemental parts, in accordance with the SCUTWORK principles. As such, each disparate EHR company uses the corresponding FIC of each of the source SMR's elemental parts to label each of its corresponding elemental parts. These FIC labeled electronic elemental parts have data fields but no data yet. As each EHR company has used the FIC labeled source SMR elemental parts to divide its record into FIC labeled electronic elemental parts, every EHR is divided into the same standardized FIC labeled electronic elemental parts. The choice to employ the disclosed SCUTWORK principles resides with each EHR company. Each EHR company must agree to follow SCUTWORK rules and agree with SCUTWORK terms to be allowed to write these methods and techniques into their software programs. The EHR company that agrees to these rules and terms is SCUTWORK enabled.

FIG. 2 illustrates two disparate electronic health records, EHR-1 300 and EHR-2 500, which have their registration information divided into concatenated FIC labeled elemental parts in accordance with the disclosed principles. In FIG. 2, 102 shows the structured concatenated Date of Birth FIC standard elemental parts of EHR-1 and EHR-2. 103 represents structure of the EHRs. Each EHR is composed of structured concatenated FIC standard elemental parts, but some EHRs will have different FIC labeled elemental part composition. Although every EHR will be composed of the same standardized FIC labeled elemental parts, the structure, shown by 103, and operations of each EHR within their respective originating computer systems will not be altered by the addition of FIC labels or the division into elemental parts as disclosed herein.

The registration information is entered before any other data for a specific patient service. The registration elemental parts provide accountability information needed to create the A-I for any one patient service. In exemplary embodiments, the minimal information needed to create the A-I is the patient personal information (e.g., name and DOB, etc.), provider information (e.g., provider name, facility name, location of service, etc.), and when the medical service was performed (e.g., date, time, etc.). This information comes from registration, and these data fields will be available with the first entry of data for any patient service. The combination of patient information, provider information, and date creates a unique A-I label for any one patient service. As data is entered for any one patient/health service, the A-I is generated and can be used to label each data entry for that patient service. All data entered during one patient service is labeled with the unique A-I identifying that patient service.

As data is entered into a concatenated FIC labeled elemental part, the unique A-I for that service is added to the data in each FIC. FIG. 3 illustrates personal registration information of EHR-1 after data has been entered in each concatenated FIC labeled elemental part, resulting in the generation of the A-I label of a patient visit and its addition to the FIC labeled elemental parts to create structured concatenated A-I+FIC standard electronic elemental parts with data, see 104. FIG. 3 shows that when the registration/accountability data is entered into EHR-1, the A-I is generated and added to each of the FIC labeled electronic elemental parts at the same time the data is entered into the elemental part. The A-I label that has been generated and added to FIC label 102 (which in this example is “First Name”), and 105 is the data in that FIC, “John.” Adding the A-I+data to the concatenated FIC labeled elemental parts produces data strands of concatenated A-I+FIC electronic elemental parts with data, an example being 104.

Key fields are extracted from the EHR from each of the types of information, and combined to create an accountability information identifier/code used as a label to tie extracted data fields to a specific EHR. The A-I label can be used as a fixed length header at the start of each extracted data set to allow identification of all data sets/files related to a specific EHR. Each A-I field may be a fixed length, so the resulting A-I code/label would also be of a fixed length which would make it easier to parse. A careful design of the field labeling may be done to include all potential data type fields so that no data is lost when being exchanged between disparate EHR systems. Each field could be separated by a unique character, such as an exclamation point, which would not appear within normal data (e.g., not a period), followed by a termination character to indicate the end of the A-I string, such as a tilde (~), as illustrated in FIG. 3.

Special circumstances occur when there is more than one type of FIC labeled electronic elemental part needed for a patient encounter/service. For example, in embodiments where there is data and time, an encounter that requires more than one blood pressure measurement would be uniquely identified and distinguished by the time. There are instances where more than one type of FIC labeled elemental part will be needed and generated. Most commonly, this will occur with multiple diagnoses and medications. To allow each A-I+FIC label to remain unique for diagnoses, the ICD 10 code for the specific diagnosis may be added to the A-I label. For medications, the National Drug Code may be used. The A-I label is a specific length, so a 15-digit A-I sequence is added for diagnosis and medications. When all or part of this is not needed, the additional characters may simply be filled with 0s.

Excluding the special circumstances of the prior example, there is only one type of FIC label for each patient service. When more than one type of FIC label is needed for each patient service, the 15-digit A-I sequence may use pre-existing standard labeling to distinguish between the different type of FIC labels. In such embodiments, the A-I uniquely labels all data entry for a single patient service. When the A-I is bonded to the FIC, the A-I+FIC is unique as there is only one FIC for every patient visit and the A-I uniquely identifies each patient service. As above and for medical record parts using more than one type of FIC per service, the A-I also uniquely labels and distinguishes between different diagnoses and medications. The bonded A-I+FIC provides a unique label for every electronic elemental part for every service that is different from all other labels used by the same EHR, as well as all other disparate EHRs.

Rules within the SCUTWORK principles disclosed herein state that the A-I+FIC union is bonded and the concatenated A-I+FIC labeled electronic elemental parts with data strands are permanent. Thus, SCUTWORK rules prohibit modification of any concatenated A-I+FIC labeled elemental parts with data strands, and thus each of these results in a SCUTWORK defined unalterable data strand.

The provider chooses which portions of the EHR to copy, share with the patient, or export to another entity. The provider may choose which portions of the record to copy before, during, or after the patient service. FIG. 4 illustrates the exporting of unstructured concatenated A-I+FIC labeled electronic elemental parts with data to a portable storage device, in accordance with the disclosed principles. As illustrated in FIG. 4, portions of the record EHR-1 discussed above are selected, copied, and the structure cut to form unstructured data strands comprising concatenated A-I+FIC labeled electronic elemental parts with data therein. 106 shows the selected portion of the record and 107 shows the copied and cut unstructured elemental part strands. This file of unstructured concatenated A-I+FIC labeled electronic elemental parts with data strands can be transferred, shown by 108, to a portable storage device 109, or even just temporary file, and/or exported to distant storage electronic system using HIPAA approved methods. Using HIPAA approved methods, the data files can be stored on any type of storage device, including portable devices 109, that can be used to share data between non-connected EHR systems, as well as other forms of local, centralized, distributed, or cloud-based storage and access systems. Storing the data on portable memory devices allows ready access to a patient's medical records, and can be carried or worn by a patient with a known medical condition, so as to allow medical history information to be readily available even in emergency and life-critical situations. Adding smart card features to the portable memory device allows easier access to centralized and cloud-based storage of data sets too large to be included on the portable memory device, such as MRIs, CATs, angiograms, etc. By adding smart card features to the portable memory device, centralized storage and cloud-based operation allows access to medical records by all affiliated providers, and system enhancements and bug fixes can be made available remotely and at the same time to all organizations that use the system.

FIG. 5 illustrates importing, shown by 110, unstructured concatenated A-I+FIC labeled electronic elemental parts with data strands stored in the portable storage device 109 into EHR 2 500 of FIG. 2. The electronic records system associated with EHR-2 reads the imported data strands and matches the FIC labels to its own FIC standard labels in accordance with the SCUTWORK principles discussed above. The matched FIC standard labels allow the unstructured strands of elemental parts with data to be inserted into EHR-2's structure. Importantly, the structure of EHR-2 need not be the same as that of EHR-1, as illustrated by the “provider” name in EHR-2 being at the beginning of the health record, while the “provider” name stored in EHR-1 was in a different structure location within the health record. The provider of EHR-2 chooses how to manage the imported unstructured data strands. The unstructured data chosen is placed into EHR-2's structure using matching FIC labeled electronic elemental parts. In the illustrated example of FIG. 5, the receiving records system of EHR-2 is importing/employing all of the data strands from EHR-1 of FIG. 4 on the portable memory device to create new patient registration information; however, in other embodiments only some of the data from EHR-1 may be used.

Therefore, as disclosed herein and in accordance with the SCUTWORK principles, an EHR can be reconstructed from a set of data files stored as unstructured uniquely labeled data strands. The A-I code is used to identify all files associated with a specific original EHR/medical service or patient encounter. The FIC identifies the universal standardized elemental EHR part source field for the data in the file. This configuration allows for reconstruction of an EHR from a set of unstructured data files regardless of the structure and order of fields (i.e., formatting) used in a particular EHR computer system. The combination of the A-I code with the FIC allows a differently structured EHR computer system to correctly reconstruct a patient's EHR from the individual data files/strands created and saved in accordance with the disclosed principles.

Accordingly, SCUTWORK techniques can be used by disparate EHR computing systems to create A-I labels and the FIC universal standard electronic elemental parts, all following a single, standardized set of rules under the SCUTWORK framework. The uniquely concatenated data strands of A-I+FIC standard elemental parts with data can be cut from their EHR structured string data tree and stored randomly (unconnected and unstructured) on a patient-secured storage medium. The SCUTWORK tool is used to cut the structured string data trees of conventional EHRs to produce randomly saved unstructured A-I-labeled data sets on the storage device, and to reorganize randomly saved A-I labeled data sets from the patient's storage device into its string data tree to reconstruct the EHR. A different, subsequent SCUTWORK-capable EHR system can then identify the storage medium's FIC standard elemental parts with data strands and place them into its string data tree. The disclosed principles permanently label every elemental data strand of the EHR using A-I accountability information combined with FIC, which then allows the SCUTWORK-labeled data strands/sets to be shared with any other SCUTWORK enabled EHR system. Stated another way, a SCUTWORK enabled system can identify the A-I+FIC of each data strand and reassemble the data in those strands into the different shaped data tree of a different EHR system.

Additionally, existing EHR systems can be updated to both export and import medical records using the SCUTWORK format and techniques by simply a software update. Once an EHR system is updated with SCUTWORK capabilities, there is no need to create conversion or exchange software to enable importing or exporting EHR records between two paired but incompatible EHR systems. One may initially think that updating a records system with SCUTWORK capabilities is the same thing as using conversion or exchange software, but it is not. Conversion software requires the capability to convert multiple EHR formats into the local system's format, whereas SCUTWORK does not. Also, conversion software works by reading a different EHR format and changing that disparate format into the unique format of the converting system, whereas SCUTWORK does not. Instead, SCUTWORK extracts data from any EHR format and provides it in a single, unstructured set of data strands, where those strands may be read by a SCUTWORK-enabled system and reassembled to any desired format. In short, conversion and exchange software take data in one format and converts it to another format, whereas SCUTWORK removes any data format by converting the information in an EHR into unstructured data strands that can later be placed into a particular format, when needed. In addition, SCUTWORK facilitates less expensive EHR systems so they can be utilized by small practices. Only systems that are not SCUTWORK enabled need to be modified. Existing systems can be updated. Relatively quick software development is all that is needed to add SCUTWORK functionality to existing EHR systems due to the simplicity of the concept.

Furthermore, the disclosed principles allow for the traditional technique of saving health records separately based on location; however, the disclosed principles provide for labeling all information produced with the identifying information regarding the professionals authoring the data. The provider, with patient permission, may select none, part, or all of the record to share using SCUTWORK principles. For example, SCUTWORK may label every part of the medical record with location, date, time, and the name of its author. Unique labeling of elemental data sets with such accountability information means the author responsible for the entry will be permanently recorded. All subsequent users of the information will have access to this information since it is permanently encoded in the A+I label of the data strands. This gives recognition of the entry of information to the author, who by allowing the information to be included in the SCUTWORK portable data storage device, gives permission for the patient to share this with other health providers, health plans, and health clearinghouses. This will improve the transparency and responsibility of the electronic health record.

Consequently, this can allow all records to be combined into one “super record” of medical events of a patient, regardless of the provider, event location, or procedure type. Patient data can be stored in the SCUTWORK format over a period of time, including a person's entire lifetime, to allow for storing a complete historical medical record. In this way, a provider allowed access by the patient can immediately see all services the patient has received his/her entire life, as well as when, by whom and where the service was performed. This allows all of the record to be discovered and for most, if not all, of the resources wasted by duplication of services to be eliminated.

Since each elemental medical procedure (such as, but not limited to, inoculations or blood pressure) are stored separately and labeled to identify the specific procedure, it is possible to scan through historical records to select these specific procedures in order to compile a comprehensive historical record. Thus, SCUTWORK enabled systems can select and import only the information needed from a group of SCUTWORK coded files, such as specific vaccination records. What information is included on the portable storage device will be the choice of the health care provider and patient. With SCUTWORK, the information from each of these electronic records could be kept separate or, as the provider chooses, they could be combined to make a super record.

For example, if the user wanted to see the patient's chronologic presentation of white blood cells, they could see a lifelong complete listing. A patient's entire life's vaccination history from all locations could be seen on one page using the deconstruction and reconstruction of data sets from EHRs provided by the disclosed principles. For example, searching for multiple occurrences of the same procedure, such as a pneumonia vaccine immunization over a period of years, would be relatively fast by searching an individual's SCUTWORK-created records for a particular procedure, such as a specific A-I having a Healthcare Common Procedure Coding System (HCPCS) HCPS code. The HCPS codes are a set of health care procedure codes based on the American Medical Association's Current Procedural Terminology (CPT). Individual medical services, procedures, equipment, etc. may be categorized and labeled by such a standard medical code within the SCUTWORK format. Using a standard medical coding system to identify specific types of SCUTWORK data files provides a fast and easy way to identify specific types of SCUTWORK health records.

Additionally, SCUTWORK-created unstructured data files may function with local, portable, or cloud storage of the SCUTWORK patient data records. SCUTWORK EHR data can be exported and stored on portable storage devices which can be carried by the patient. For the case of portable storage carried by the patient, SCUTWORK facilitates emergency access to the patient's data record at all times, since the patient can carry their own medical history with them, and there is no need to have access to an external database system to gain access to their medical records. For example, SCUTWORK-based patient portable storage devices can be created holding their medical records. The patient secured portable storage device allows the patient to choose what level of security they want for their health records. For example, for those who choose the same security as for their driver's license, credit cards, and social security number, then it could be kept without a password or code in their wallet for immediate access of the health record by health care workers in emergency circumstances. However, for those patients wishing high security then it could have a password and/or code limiting access to only those they consciously choose to share this information. For emergency situations, the patient-created security could be biometric, such as a fingerprint scan or a facial recognition scan, where the patient's portable records can still be accessed if the patient is unconscious or similarly incapacitated. The emergency personnel can use the device to immediately access the medical record and discover allergies, medications, and medical problems that could be potentially lifesaving.

Labeling data records in accordance with the SCUTWORK principles is not necessarily limited to the field of healthcare or patient health records. The disclosed SCUTWORK systems and methods are an electronic record Rosetta Stone for any standardized record keeping profession. This includes the fields of health care, finance, law enforcement, engineering, accounting, banking, and so on. The SCUTWORK labelling of exported data sets/files can be applied to other fields, such as but not limited to, engineering, architecture, banking, teaching, and construction. As such, SCUTWORK is designed for all standard record professions. Thus, SCUTWORK labeling can be applied to various fields that use similar standardized reporting where data interchange between incompatible systems is needed. Conventionally, when such standard record is made into an electronic record, all differently structured data electronic record versions will have similar record organization and formatting, but not similar structured electronic data organization. SCUTWORK uses a standard record to develop universal standard elemental parts, and labels each of those standard elemental parts. A SCUTWORK enabled disparate electronic record system uses FICs to uniquely label electronic elemental parts with data fields but no data. The standard FIC labeled elemental part of any electronic record is necessary for the application of an A-I label to be unique. The structured data of each different electronic record can be reduced to unstructured data (without being a complete patient record) in accordance with the disclosed principles. This labeled unstructured data can then be reorganized back into a different electronic record having the exact same information as the EHR from which the unstructured data was derived.

Based on the above, exemplary aspects in accordance with the disclosed principles may comprise one or more of the following principles:

An interoperable healthcare data exchange method for enabling transferring of Electronic Health Records (EHRs) between incompatible EHR computer systems, the method comprising:

- identifying a source standard medical record (SMR);
- identifying elemental parts of the source SMR;
- creating a Field Indicator Code (FIC) to identify each elemental part of the source SMR;