Ewout Kramer, Furore

CIM-based CRUD storage

Architectural context

CDR

Service

v3 v2

?

MEPD

KN

ICIP

v3-R

v3-R

v2

AORTA v3

The nasty CS->RP route...

What we needed

• A generic way to store a Hl7v3 message in a pre-existing database based on RIM....

• It seemed simple, but in januari while discussing it we realized it merited to be a RIMBAA issue...

Object Trees & Nets

• Message: hierarchical

versus

• Storage: cyclic net

Example EHR - stored instances

Example “update” message

Merge away!

• Maybe not probable but a generic algorithm should handle it

• Still...we “feel” this interaction goes beyond its scope

• RMIMs are not designed to Update/Replace/Delete specific children & attributes

A generic merger needs...

• To understand intention of the interaction (activate/revise/record)

• Additional hints hidden in prose of implementation manuals/Ballot

• Know mapping to your EHR-model• Update context

Query Encounter, select

• Act with code “ENC”. With mood EVN.• Which clone in which interaction do you mean?• A_Encounter CMET• A certain template (collection of CIM’s?)

Domain-Driven Design by Eric Evans

“How do we know where an object made up of other objects begins and ends?”

“In any system with persistent storageof data, there must be a scope for a transaction that changes data and a way of maintaining the consistency of the data”

Scope of queries en updates

Aggregates

• Define small CIMs with tight/safe scope, context and semantics

• Define enough CIM’s to cover required domains and no more

• Map interactions to “service level” CRUD operations with these CIMs

Storage model

• Unit of storage– Lock, create, read, update, delete as a whole– CRUD-services

• Only the “root” is public• Explicit references to other data

– Feels like “identifiable” CMET stereotype• Scope of context conduction• Unit of documentation

Interpret interactions & disassemble!

Encounter

CareProv

Consent

Observation

Ass. Entity

Patient

Location

RelatedPsn

Organization

Person Place

We might end up with

Building blocks

• Explicit (CMET) and implicit re-use of structures– Every domain uses implicit picture of a full-fledged

“EHR” DMIM.

• At best, each domain consistently uses this “EHR” DMIM.– Only differ in domain constraints, clonenames

• Reverse-engineer this mega-DMIM, split into more generic “aggregates” which are the building blocks of a CDR.

E_Person universal

R_Patient

Patient Admin DMIM

Lots of overlap with Administrative Registries!

R_RelatedParty

E_ProductKind

E_Person – Storage model

R_Patient – Storage model