adunsulag
commented
1 year ago Relevant PR is here: https://github.com/openemr/openemr/pull/6939
@bradymiller @sjpadgett @stephenwaite I think I have the main components of the data exporter for b10 built. I think the main traversal algorithm appears to be working well. You can export on a single patient, or export on the entire patient population. I've got about 85 of the 120ish tables exporting now with their foreign keys identified by the schemaspy tool. I'll be doing a bunch of testing to make sure that everything is exporting properly.
I do need to add in a mechanism to hold back some data on certain fields for a given table. The rudiments are there, but I need to go in and add in the specific column selection for things like the user table, x12 partners table, etc so that we aren't giving confidential data / employee data out as part of the export.
I also need to change up the save location for the exported zip. Right now the csv and zip files get written out to the module directory. We need to store them similar to how we handle our bulk fhir exports using the Document class so that the files get written out to CouchDB or to the filesystem. My only concern is how to handle a situation where we could potentially have GBs of data in the zip file as part of the patient documents being exported.
That leads to my next piece. I'm looking at adding in a configurable limit to allow chunks of patients to be exported. One chunk could default to 250/500 but let the administrator choose a different number. The system would then create multiple zip files to export.
I do wonder though how to handle large files stored for a patient. If for example a patient has GBs of documents stored, the zip files could be huge. Generating those zip files (and encrypting them if file storage encryption is enabled) could be massive and exceed a zip file's limitations. One idea would be to export the documents one at a time, keeping track of how many patients have been succesfully exported. If we reach the maximum size (1-2GB) for the patient documents we would then break up the zip file at that point even if the administrator chose a higher # of patients to export. As a minimum I think I'd want to say that we won't break a single patient up into multiple zip files, rather we will export an entire patient's documents into one zip and move on to the next one. I believe the documents table actually stores the file sizes so we should be able to do this analysis ahead of time instead of exporting the files as we go.
I'll also do a synthea import of a few hundred/thousand patients ccdas and do some testing that way to make sure things are working.
At that point the rest of the work is just adding documentation comments on all of the main tables and if we have enough time on the individual columns. I'll also need to write an overall breakdown of the zip file on the main EHI export page. Fortunately the schemaspy templates allow us to customize everything.
mdsupport
sjpadgett
We need to implement the following ONC 2015 Certification (b)(10) Electronic Health Information Export. https://www.healthit.gov/test-method/electronic-health-information-export
The requirements for this are as follows:
(b)(10)(i)(A) - Enable a user to timely create an export file(s) with all of a single patient’s electronic health information stored at the time of certification by the product, of which the Health IT Module is a part. (b)(10)(i)(B) - A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate. (b)(10)(i)(C) - Limit the ability of users who can create export file(s) in at least one of these two ways: (1) To a specific set of identified users (2) As a system administrative function [Feature should implement option 2]. (b)(10)(i)(D) - The export files(s) created must be electronic and in a computable format. (b)(10)(i)(E) - The publicly accessible hyperlink of the export’s format must be included with the exported file(s). (b)(10)(ii) - Create an export of all the electronic health information that can be stored at the time of certification by product of which the Health IT Module is a part.
For purposes of Electronic Health Information the information exported by this feature should follow the ONC definition given which is: EHI means “electronic protected health information” (ePHI) as defined in 45 CFR 160.103 to the extent that it would be included in a designated record set as defined in 45 CFR 164.501, regardless of whether the group of records are used or maintained by or for a covered entity. But EHI does not include psychotherapy notes as defined in 45 CFR 164.501 or information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding.
The regulation text for 45 CFR 160.103 defines "health information" as the following: Health information means any information, including genetic information, whether oral or recorded in any form or medium, that: (1) Is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual.
The regulation text for 45 CFR 160.103 defines "protected health information" as the following: Protected health information means individually identifiable health information: (1) Except as provided in paragraph (2) of this definition, that is: (i) Transmitted by electronic media; (ii) Maintained in electronic media; or (iii) Transmitted or maintained in any other form or medium. (2) Protected health information excludes individually identifiable health information: (i) In education records covered by the Family Educational Rights and Privacy Act, as amended, 20 U.S.C. 1232g; (ii) In records described at 20 U.S.C. 1232g(a)(4)(B)(iv); (iii) In employment records held by a covered entity in its role as employer; and (iv) Regarding a person who has been deceased for more than 50 years.
As far as I know OpenEMR does not have a way currently of distinguishing notes that are specific to psychotherapy notes and which are to be excluded from the export. Users wanting to keep their psychotherapy notes confidential that are stored inside of OpenEMR will need to use a different mechanism than this export.
OpenEMR does not have a way of marking records as education records.
We will need to make sure that employee records and other confidential information does not inadvertently get sent out as part of this feature. Only administrators should be allowed to execute the export.