Offline Data Entry

Just wondering if any work is being done in this area. That is, for situations where a medical practitioner is visiting patients out in the boonies with no internet, and wants to enter data on a laptop that can later be imported into OpenEMR. Or if not, if there is a desired existing standard for importing such discrete data.

I guess the Peace Corps work never became public, right? Though that may be too complex anyway.

1 Like

I know we had a group doing offline work in Haiti and I think we another group doing stuff in Mongolia, but I haven’t seen any code contributions.

I do want to throw out there that ONC is mandating we use the FHIR bulk $export operation for certification. They are kicking around with spec proposals to do a bulk $import operation with FHIR which would support integrating incremental changes into the existing dataset. I imagine ONC is going to mandate the $import be supported once the spec is finalized so whatever solution we arrive at I would hope would fall along similar architecture.

The spec proposal is here:

I will say we implemented all of the uuid mechanisms in order to support offline client application processing.

1 Like

Thanks Stephen. Right now I’m mostly interested in data format, not so much the API, and this is for use outside the US. I’m thinking patients would be selectively exported to a file from one OpenEMR instance and imported to another. Things will get interesting when there are conflicts between the source and target data.

I guess it may dovetail with the FHIR effort if I use HL7 XML or JSON resource types?

Also wasn’t there some MU requirement to give patients an electronic copy of their records? I wonder if that would also fit in here.

For ONC 2015 certification in 2021, Patients have to be granted access to their data records due to the interoperable FHIR requirements. ONC has mandated that means access via FHIR to the USCDI data set. In their federal guidelines they indicate they will at some point mandate all access to a patients data set save for things like psychological notes or other things that would put the patient’s health at risk.

If you use FHIR resource types for the data transmission and package them in the ndjson format you should be able to make it compatible w/ the bulk $import process.

I agree as far as the the problems that arise when dealing with conflicts between source and target data. The FHIR format allows a resource to have multiple versions of a record and the status of those records can be ‘proposed’ and I think I even saw somewhere that some had a ‘contested’ flag. So there are ways to work through these things but it will definitely be a ‘fun’ engineering project.

Hi Rod
Did you come right with this?

Hi Claire, no the project did not move forward.