ewout kramer, furore fine-grained repository models or spm’s, or
TRANSCRIPT
Ewout Kramer, Furore
Fine-grained repository modelsor SPM’s, or...
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 v2+v3+transaction+CDA in a pre-existing RIM graph
• NB: not OLAP (“stacks”) but immediate integration!
Example EHR - stored instances
Example “update” message
Merge away!
• Maybe not probable but a generic algorithm should handle it
• We “feel” this interaction goes beyond its scope
• Messages are not designed for CRUD. E.g. manage 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
As time went on...
Domain-Driven Design by Eric Evans
• I am not smart enough
• Something is wrong, another approach is needed
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 information 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 boundaries/references to other data• Scope of context conduction• Unit of documentation
Interpret interactions & disassemble!
Encounter
CareProv
Consent
Observation
Ass. Entity
Patient
Location
RelatedPsn
Organization
Person Place
Resolve Context
Map to EHR-structure: info + term
Disassemble
Links between blocks
We might end up with
They reflect your EHR
• These blocks store data in your EHR-DMIM• You map national/external interactions to it• Might live longer than ballot spec
• Why? It is no use to include the whole model if you, your developers and your users don’t know about it and can’t interpret it.
E_ProductKind
This is a CMET!
Finding 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.
• Reverse-engineer this mega-DMIM, add your domain knowledge & requirements & split into more generic blocks
E_Person universal
R_RelatedParty
R_Patient
Patient Admin DMIM
Lots of overlap with Administrative Registries!
How to define aggregates
• Strive for high cohesion
• Decide which data is contained and which referenced
• Decide navigability (who references who)
• Storage/granularity considerations
E_Person – Storage model
R_Patient – Storage model
E_Person – “Group membership”
• What would you make the root class?• What is referenced, what is contained?• What would you do for workinglists?
E_Group storage
A_StatementCollector