This presentation provides an insight into the anatomy of an eHealth app and different approaches to building healthcare applications.

1. Dr Ian McNicoll
Anatomy of an eHealth
app

2. Anatomy of an app
User interface (the app itself)
Information model
Database

3. the ‘application’
The part of the software
that the user sees and
works with

4. the “persistence layer”
How and where the information is
physically stored or ‘saved’
in a local database, in the ‘cloud’
usually the app must know the
physical layout ‘schema’ of the
database to know how to retrieve the
information
e.g. exactly where patient ID ,
systolic and diastolic BP etc are
located in the database
The app must also understand
the database query language
SQL, mongoDB, Cassandra

5. the ‘information model’?
Any definition of the structure
and content of information that
should be collected or shared
A ‘minimal dataset’
A message or interface definition
Internally every application has
some kind of information model
Sharing information requires
developing shared information
models

6. the ‘information model’
Is used to manipulate
information in the computer’s
memory
Often written in a specific
program language
Generally locked-in to each
application
Not easily shareable

7. What is in an API?
Application Programming
Interface
how modern web apps talk to
each other
request/ receive some sort of
‘structured content’
https://ehrscape.code-4-health.org/rest/v1/
composition/12345-123?format=STRUCTURED

8. Information models power the web

9. Information models power the web

10. Mismatched clinical information models

11. Multiple information models
= high-cost, non-interoperable systems

12. Multiple information models
= high-cost, non-interoperable systems
app
app
app
app
app

13. Megasuite + feral apps
User interface
Information model
Database

14. Megasuite + feral apps
User interface
Information model
Database

15. Megasuite + feral apps
User interface
Information model
Database

16. Megasuite + feral apps
User interface
Information model
Database

17. Megasuite + feral apps
User interface
Information model
Database

18. Megasuite + feral apps
User interface
Information model
Database

19. Megasuite + feral apps
User interface
Information model
Database

20. Megasuite + feral apps
User interface
Information model
Database

21. idea 1
‘free the data’
In the future the organisation or company that
handles your health datastore will be separate from
the company or organisation that build your
applications.

22. openAPI - Closed platform
Third-party apps
Information model
Database

23. openAPI - Closed platform
Third-party apps
Information model
Database

24. openAPI - open Platform
Third-party apps
Vendor-neutral Information model
Technology-neutral datastore (CDR)

25. Defining an open Platform
Open Platform Principles
Any platform implementation that is truly to meet
the definition of being ‘open’ should comply with the
following principles:
• Be Open Standards Based
• Share Common Information Models
• Support Application Portability
• Be Federatable
• Be Vendor and Technology Neutral
• Support Open Data
• Provide Open APIs
http://www.woodcote-
consulting.com/defining-
an-open-platform/

26. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
Vendor-neutral Information model

27. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQL

28. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQL

29. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQL

30. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQL

31. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQL

32. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQL

33. The ‘bi-modal’ EHR?
Bimodal IT is the practice of managing
two separate, coherent modes of IT
delivery, one focused on stability and the
other on agility.
Mode 1 is traditional and sequential,
emphasizing safety and accuracy.
Mode 2 is exploratory and nonlinear,
emphasizing agility and speed.
open Platform
+
Legacy EPR
User interface
Information model
Database
Third-party apps
Vendor-neutral Information model
Technology-neutral datastore (CDR)