Hi all.
Sadly, I won’t be able to attend the out-of-cycle CR meeting
tomorrow. I would like to put a few ideas “on the radar”, tho.
Idea #1 – there are good “architectural” reasons to keep
separate the CR and the SHR.
One of the reasons for favouring separation is related to
the quite distinct roles these two architectural elements play and the very
different ways one would typically communicate with them. The CR’s role is to support
resolution of local to enterprise identifiers and to associate the definitive “golden” demographic data with the definitive (enterprise, or “golden”) client ID. You would tend to communicate with the CR
using messages – and the message you would most often do (every transaction!) and
the one the CR should be optimized for is: “find the golden information for
this client”. By contrast, SHRs hold data provided about the patient that is
related to care events. These often come in encounter-at-a-time chunks
(referral notes, discharge summaries, care encounter notes, prescriptions, lab
results, etc.) that are often communicated as documents. The gist: we will want to
optimize the CR and the SHR for different traffic patterns.
Another important reason to keep the CR and SHR separated is
to afford us “privacy and security in depth”. This is a design pattern that
makes it harder to breach a system. The CR contains demographic data associated
with the golden ID and cross-referenced to the (possibly) many local IDs. By design,
the CR does not hold PHI (personal health information). The SHR holds PHI. It need not, however, contain
demographic data. The SHR can maintain the PHI with an ID reference to the CR;
it need not replicate that data. The gist: it is best practice to segregate
demographic from clinical data as a “privacy in depth” design pattern.
Idea #2 – if you don’t find the architectural reasons
compelling, it changes not at all that the interfaces should be separate for
each use case (CR and SHR).
A single application can play the “role” of multiple
architectural elements. To play each role, the application just needs to expose
the appropriate standards-based interfaces. Let’s use OpenMRS as an example. If
we wanted to use OpenMRS’s client information as a CR, then OpenMRS could do so
by exposing the interfaces needed to do the PIX (patient identity
cross-referencing) and PDQ (patient demographic query) transaction sets. This way, any point of service system that needs to resolve a client’s “golden ID” just uses the standard interface to do so (and cares not at all what application is on the other end of the interface). Similarly,
to use OpenMRS as an SHR, we need to expose the OpenMRS database using the XDS
(cross-enterprise data sharing) interface and its many options and content
profiles. As we have been finding, OpenMRS (with some important modifications) seems
quite able to store and retrieve clinical content using XDS transactions.
Here’s a sobering thought, tho, when considering this option.
An application that is designed to be an EMR is, usually, not well suited to
being an HIE-level repository or registry. EMRs focus on individual usability and quite often are “tuned” to
optimize for end-user response as measured by a person interacting with a UI. HIE
elements, on the other hand, focus on ecosystem performance and are “tuned” to
support high-volume, UI-less, transaction traffic across the aggregate
community of all the end-user applications (EMRs, or lab systems, or
pharmacy systems, or mHealth applications, etc.). As an example of this scale –
the HIE for the province I live in (Ontario, Canada) needs to support over
300,000 clinicians using over 13,000 different point of service systems to track
the care of 12.5M clients. At this kind of scale, ecosystem architecture tuned
for transaction throughput is a must-have.
I’ll be sorry to miss tomorrow’s discussions but look
forward to seeing the notes.
Warmest regards,
Derek.