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