REVISED ELECTRONIC MEDICAL RECORD DATA MODEL

By M W MAIR, Ophthalmic Surgeon, Timaru, New Zealand

This is a response to The Electronic Medical Record Data Model posted by the NZHIF. The model for discussion is found at:http://fims-www.massey.ac.nz/~jpastor/emr/emr_model/sld001.htm

It sets out the objects and some relationships between them for the proposed national EMR system.

At a meeting between myself (representing the Association of Salaried Medical Specialists), Ashwin Patel (representing the Royal New Zealand College of General Practitioners) and the Chairman of the NZHIF Jose Pastor Urban some simplification of the model was proposed which I have represented diagrammatically below.

In the re-arranged model, the ‘Assessment/Management’ unit or Encounter is seen as the central class. The other objects have symmetrical or asymmetrical relationships with it. The ‘Medical’ Objects themselves are grossly classified into ‘Assessment’ Objects and ‘Management’ Objects, which is a further simplification of the SOAP unit (Subjective/Objective/Assessment/Plan). It was envisaged that ALL contacts

ENCOUNTERAssessment

Management

Donor

NPIHealth Care user

Address Contact Demography

Medical Warning

Pharmacy referral Waiting time event

Assessment ObjectsEG. General HistoryFamily HistoryExaminationDiagnosis….The ‘S O A (subjectiveObjective/AssessmentPart of the SOAP unit

Management ObjectsEG ProceduresPharmaceutical,The ‘P’ or Plan part of the ‘ S O A P’ unit.

between Healthcare Providers and clients could be modeled in this way including In Patient contacts.

A stack of such encounters with a particular provider or organization would constitute an ‘Episode of Care’.

A stack of such encounters which was coterminous with the Natural History of a disease process would constitute a ‘Disease Course’. A ‘Disease Course’ and an ‘Episode of Care’ would often be coterminous.

Diagram of Two Episodes of Care, One Disease Course

Episode of Care

Episode of Care Assessment Objects Disease Course Management Objects

A three dimensional diagram of the progression of ‘Encounters’ into ‘Episodes of care’ and ‘Disease Courses’ is shown above. This picture does not show all the Administrative Objects (such as demographic details, NPI etc.) which are ‘hung off’ each encounter, for simplicity. It shows within the ‘Assessment’ and ‘Management’ sections of each ‘Encounter’ an undifferentiated “heap” of medical object instances. These are the raw data, collected at each encounter. They are structured into screens and protocols by the end users software, and the ‘Standard’ does not dictate how those structures should be.

Summary

We have been able to agree on a simple structure for the New Zealand Medical Record Data Model which is diagrammed above.

1.The Objects in the Term Dictionary form a currency for transactions, and serve more than one purpose. They contain (as Object Instances) the data collected during ‘Encounters’; they can be used for epidemiological research; they can be used for accounting and audit.

2.The Standard would specify a common format for objects, which can be shared between different languages eg C++, Smalltalk, Fox 5, etc, and suggests that the medical objects are segregated into ‘Assessment’ objects and ‘Management’ objects. This means that there will be a dated cluster of object instances corresponding to each encounter.

3.The Standard itself should not further structure the data, this being left to the Software Providers, which will continue to compete both within and between market niches.

4. Just three levels of client engagement with the Health Sector are envisaged: The ‘Encounter’, the ‘Episode of Care’, the ‘Disease Course.’

Agreement about this data model would then permit further agreement on conventions governing encryption, transmission, security etc. which must be in place before a National System comes into use. An agreed minimal structure as outline above is a prerequisite for such a viable National system.

M. W. MairPOB 319 Timarueyetech@es.co.nzMonday, December 22, 1997