@gerimedica

gerimedica

info@gerimedica.nl

Axon 3.0 Launch event

GeriMedica

● (re)Architect ● Little over 2 years on the project● Writes code● Kills (technical) problems● Evolves the software to meet current and (near) future requirements

Michael Bischoff

Pretty much your typical software architect...

GeriMedica

“Aims to improve healthcare through technology and sharing knowledge”

GeriMedica - Profile

● Is a spin-off from the VUmc and was started with the backing of 3 health care institutions

○ geriatricians creating software for geriatricians

● Our main product is Ysis○ an electronic health record application

● Based in Amsterdam● We believe in best of breed, not in ‘suites’

○ Focus on what you're good at

● Focus on treatment and long term care○ Nursing homes○ Homes for mentally disabled

GeriMedica - Market

● Focus on ○ Long term care○ Treatment○ Multidisciplinary teams

● Market leader in the Netherlands ○ 20000 out of 70000 treatment spaces

● Long running contracts ○ typically 4 years

Ysis - Electronic Health Record Application

● Non-public○ Treatment team members login,

multiple disciplines

● Web application○ Available on a variety of devices○ Mobile clients on Android, IOS

● Software as a service○ Managing the infrastructure and

hardware○ The software is always up to date

Ysis

Ysis is used by over 55 health care institutions in the NetherlandsInsert picture of

map of netherlands

Ysis

Ysis is used by over 55 health care institutions in the Netherlands

Which have many locations...

More Stats..

On an average weekday:

● 60 000 Electronic Health Records are accessed● 12 000 (non-unique) logins occur● We process between 300 000 and 400 000 SOAP messages● Over 4 000 care activities registered

Axon stats

● 450 000 and 550 000 commands a day○ Around 5-6 a second

● Over 130 million events, over 156 GB

Some components we use:

GWT

SWIFT

Why Axon?

● CQRS○ Scalability○ Flexibility

● EventStore○ Traceability

■ Recording of all activity○ Security

■ Audit trail

Axon Implementation

● Event Sourcing○ We don’t cache aggregates, they are loaded ‘on the fly’○ Aggregates are snapshotted

● We run on two axon nodes○ Primary for failover reasons○ Synchronises on the database ○ ‘Optimistic locking’ is solved through retries

● Event Store in SQL database● Running in production since October 2010

Research Data

● Traditionally done through questionnaires○ Inaccurate

■ People lie○ Time consuming

■ Limit’s parameters■ Takes away time from the patients

● Eventstore○ Truthful○ Non-intrusive○ Detailed

■ All modifications are recorded● Access as well

■ Lot’s of time based information

Research Data

Why (still) Axon? - Integrations

We believe in best of breed.

The inverse also holds, given capacity and focus you can’t be the best at everything.

-> So we integrate with others

“You don’t need any other software, our product can do it all”

- the existing players

Ysis Integration with:

● Systems for care● National system to check for Insurance● Electronic Prescription Systems● Labs● Administrative systems● Financial systems● Business intelligence systems● Planning systems

Implementations - Integrations

You didn’t think these systems have some standard for exchange of information...

● We have over 25 different implementations○ Which need to support multiple versions (for on-site software)

● We have over 110 actively monitored integrations running on production○ Add acceptance, staging and legacy integrations

How do you tackle this?

Well, don’t:

● Directly expose your (axon) events to the outside world○ Leaking implementation details

● (Use events as) delta’s to save bandwidth○ Diverging datasets

Push / Pull

● Pull or ‘polling’ (or ‘batch’)○ Not (near) real time○ Bandwidth

● Push○ Near real time

■ if the other party supports it○ you’re shoehorning your model into an interface you're not familiar with

■ If you’re lucky and have the data

Notify-Grab

● Interpretation○ When grabbing you’re shoehorning their exposed model into your own.

■ Only grab what you need

● Control○ The notified party can choose to:

■ Delay processing because it’s system is experiencing load (back pressure)■ Aggregate notifications to avoid multiple calls

○ You can ‘self-service’■ You can ‘fix’ things without having to coordinate with the other party■ You can also notify yourself to force synchronization or bootstrap new entities

● Efficiency ○ Queueing / ‘guaranteed’ delivery is cheaper -> Notifies are small○ You typically only communicate about changed entities

Axon Helps ...

● Axon events are natural triggers for notifications○ We know what is modified○ We know when it is modified

● Commands provide a single point of entry○ Validation is centralised

● Troubleshooting is easier because we can check the events○ We can also log these + command logging + application logging in Graylog

To Conclude

….possible using the Axon eventstore

Dataset

Academia

+Healthcare Institutions

InsightsPolicy validationImproved practices

To Conclude

Mature.

Complements other technologies.

Provides flexibility.

Performs.

@gerimedica

gerimedica

info@gerimedica.nl

Questions?