GeriMedica - axon launch event
27
-
Upload
michael-bischoff -
Category
Documents
-
view
81 -
download
2
Transcript of GeriMedica - axon launch event
● (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.
