How does MyOSCAR file its records

I have described earlier that individual patient personal health record document is stored in MyOSCAR as individual file with a unique file identifier. The internal format of this file follows some variation of the CDA standard. The file is individually encrypted based on a unique key belonging to the patient. The idea is that even if an unauthorized individual is able to access these files, that person cannot have access to the information contained in these files.

In this discussion I shall elaborate on what is now, and what will be in the future, the way MyOSCAR organizes and stores these files in its Data Store server. The Access Control layer of MyOSCAR must understand the filing structure in order to retrieve individual patient's entire health history.

At the present moment, the organization of these files are stored in a relational database, i.e. when I want to look up which file contains a list of my blood pressure record, I should be able to find it quickly from the database which file contains the history (and maybe the content) of all my blood pressure record. In practice this is probably much more complicated than that. Let me elaborate.

MyOSCAR is designed based on the idea that each patient owns his own electronic medical record (EMR). In a classical EMR design, there are these fundamental principles and practices:

• Authentication and authorization - the system must contain information pertaining to the identity (username and password) of everyone given access to the EMR. The owner (or the administrator) of the EMR is the patient himself. Who else and what can be accessed are controlled by the patient and changes to the access profile and audit of all accesses are maintained by the EMR.
• All read and write accesses are timestamped and signed by the authorized user. Records are never deleted. They can be hidden from the viewer (or archived) but can be retrieved from the audit trail and used as medical evidence in court. The owner of the EMR has the option of being notified whenever a record is read or modified.
• There are records that are essentially free text and there are records that contain codified information (or meta-data). Both types of record are equally important and useful in different situations. Codified information must contain both the code and the coding system used (including the version information). Both types of information must contain as many process information as possible. These may include, the observer or the author, the observation date and time, the recording data and time, and other information that help readers understand the information, e.g. language.
• External information must be distinguishable from original internal information. This is because internal information is considered more reliable having authenticated the author and digitally signed at the time the information was stored. In contrast, external information is based on some level of trust between the sending agent and the receiving agent and can not be validated.
• If interpretation of previous stored data is required (e.g. via data mapping tool) the interpretation must be marked as interpreted data and the mapping information must be included in the documentation.

The typical data types in a primary care system may contain (but not limited to) these sections:

• Personal identification section - often known as the Demographic section, contains all the personal identification data such as name, date of birth, gender, contact information, insurance, next-of-kin etc. Any change to any of this data will be logged. Typically, this section should allow expanded fields as different jurisdiction may have specific requirements for identifying individual patient belonging to that jurisdiction.
• Patient summary section - this is sometimes called the Cumulative Patient Profile (CPP) or the more structured and HL7 compliant Continuity of Care Record (CCR). This section typically contains the most important and the latest summary of a patient's medical condition including medical alerts and drug allergies, major medical conditions, drug profile, immunization, and important psycho-social information that may play an important role in the health status of the patient. The storage area for this section includes fields that contain the actual data, as well as pointers to the other section of the EMR, e.g. drug profile.
• Disease Registry - if the patient has been identified by a health care professional, or a health care organization, as having the disease(s). Each disease typically includes the actual diagnostic code(s), e.g. ICD9. The identified disease(s) are assumed to meet all the inclusion and exclusion criteria for diagnosing the disease(s).
• Prevention, including immunization and other preventative procedures.
• Laboratory section - this can include records containing the original data format, e.g. HL7, and classification system, e.g. LOINC. It can also include files in PDF format as well as scanned images.
• Diagnostic Imaging section - this may include the actual images or the reports as read by the radiologists.
• Correspondences - may include electronic messages and faxes. These are typically internal, a copy of the prescription or an xray requisition; or from an external source such as the hospitals, consultants, and other caregivers. The format may be structured, e.g. HL7, or unstructured, e.g. scanned images.
• Measurements - typically discrete data elements, e.g. BP, weight. Each measurement must contain observer/author, timestamp for observation and timestamp of recording. If information is from an external source, or has been interpreted (see above) the information must be included.
• Medication - history of all prescribed drugs, almost always from an external source (e.g. family doctor or specialists). It can be from the patient's self-report, e.g. over-the-counter drugs, vitamins, herbs etc. It should also include a section of drug allergies or drug intolerance. It may also contain a medication administration record (MAR).

The entire patient record may reside in on MyOSCAR database server but in future it maybe scattered in different physical servers or even different MyOSCAR servers anywhere else on the Internet. If a patient wants to own a copy of the entire record, it should be possible to retrieve absolutely everything to be stored locally, in encrypted format. Alternatively, some form of patient summary can be downloaded or printed for portability.