Ewout Kramer, Furore CIM-based CRUD storage. Architectural context CDR Service v3v2 ? MEPD KN ICIP...
-
Upload
caroline-ryan -
Category
Documents
-
view
217 -
download
0
Transcript of Ewout Kramer, Furore CIM-based CRUD storage. Architectural context CDR Service v3v2 ? MEPD KN ICIP...
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