Design of the shared medical record

Hi Roger,

I’m copying this to the SHR community mailing list as I think you make some good point and I’d like to see what other think.

The core problem that the Shared Health Record (SHR) is trying to solve is that of continuity of care. We want a patient record to be accessible from any facilities that are part of the HIE. We don’t see the need to store a full copy of a patients record in the SHR, but rather a relevant subset of data. The most crucial data for the patient to be appropriately cared for. We would definitely want to support a standardized subset of data and are currently looking to CDA content modules to facilitate this.

We are planning on supporting unstructured data like images, narrative text or scanned documents as we acknowledge that these would be useful to store when fully structured information isn’t available.




On Wed, Sep 18, 2013 at 2:49 PM, wrote:

Dear Ryan,
In discussing this issue, the first question I have is, what problem(s) is/are the shared medical record designed to solve? I can see a number of possible objectives for the capability; limiting to routine medical uses (excluding studies): (1) backup of facility-based records; (2) continuity of care for a disease or condition across multiple facilities; (3) knowledge of the medical history of a new patient; (4) joining of lab tests and other diagnostic procedures performed outside the medical home with the patient record from the medical home; (5) case-based reporting for a disease or condition; (6) transfer of records from one medical home to another; (7) centralized lab-, pharmacy- or clinic-based surveillance; (8) centralized monitoring for compliance with standards of care. Of these, only (1) requires a full, permanent, individually-identified copy of the entire patient record as it appears in the home EMR.

 Many of the others (2, 5, 7, 8; 3, 6 to a lesser extent) require a standardization of information requirements and a harmonization of terms.  I think this is an effort that we have to push back to our clients; we can't just say "oh, just send us everything, we'll work it out."  Even in the narrow, standardized world of electronic lab reporting, that has not worked.  Pre-coordination (and recurring coordination and post-coorindation) is vital to the success of information exchange; this is what I have learned from Shaun Grannis.  Certainly for (5), a form-based model could work well, and a lot of the pre-coordination exists in the IDSR/World Health Law context to give immediately useful results.

 I think that OpenMRS, due to its roots in the standards and informatics community, has focussed more on fielding information than medical practice as a whole; admission notes and discharge notes are the coin of the realm.  I think your recent e-mail re the Note table was revealing, along with what I take as your perceived need to support scanned images of paper documents as well as radiology and other inherently image-based reports.  There is a lot to be gained by focusing on a visit-based system covering patient, facility, provider, date, diagnosis, note, discharge condition, and the availability of other types of results (lab, diagnostics, dispensing).  This could serve for functions (2) and (3), especially if (2) used a standardized dataset.  I think if we recapitulate our lessons learned, the first thing an EMR has to get right is patient registration; the second thing is basic visit/service delivery information; the third thing is fielded data for certain types of visits, typically related to a disease or condition which is funding the effort; the fourth thing is lab and pharmacy data delivery and integration.  The very last thing is patient-facing care in all its variety and workflows.

 Replying to your last reply, I don't think poor internet connectivity is a justification for a central permanent individually-identifiable data store.  At this point, connectivity is really the easiest thing to supply; when I was visiting MVP Ghana, they were installing a cell tower.  There are certainly lots of engineering-oriented NGOs who could supply us with appropriate solutions.  This is much cheaper and easier than training an entire bureaucracy about the importance of privacy and security of medical records.

Saludos, Roger

Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton