Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

1 1 anatomy of an app

18 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

1 1 anatomy of an app

  1. 1. Dr Ian McNicoll Anatomy of an eHealth app
  2. 2. Anatomy of an app User interface (the app itself) Information model Database
  3. 3. the ‘application’ The part of the software that the user sees and works with
  4. 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. 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. 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. 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. 8. Information models power the web
  9. 9. Information models power the web
  10. 10. Mismatched clinical information models
  11. 11. Multiple information models = high-cost, non-interoperable systems
  12. 12. Multiple information models = high-cost, non-interoperable systems app app app app app
  13. 13. Megasuite + feral apps User interface Information model Database
  14. 14. Megasuite + feral apps User interface Information model Database
  15. 15. Megasuite + feral apps User interface Information model Database
  16. 16. Megasuite + feral apps User interface Information model Database
  17. 17. Megasuite + feral apps User interface Information model Database
  18. 18. Megasuite + feral apps User interface Information model Database
  19. 19. Megasuite + feral apps User interface Information model Database
  20. 20. Megasuite + feral apps User interface Information model Database
  21. 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. 22. openAPI - Closed platform Third-party apps Information model Database
  23. 23. openAPI - Closed platform Third-party apps Information model Database
  24. 24. openAPI - open Platform Third-party apps Vendor-neutral Information model Technology-neutral datastore (CDR)
  25. 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. 26. open platform architecture Third-party apps Technology-neutral datastore (CDR) Vendor-neutral Information model
  27. 27. open platform architecture Third-party apps Technology-neutral datastore (CDR) openEHR Rest API + AQL
  28. 28. open platform architecture Third-party apps Technology-neutral datastore (CDR) openEHR Rest API + AQL
  29. 29. open platform architecture Third-party apps Technology-neutral datastore (CDR) openEHR Rest API + AQL
  30. 30. open platform architecture Third-party apps Technology-neutral datastore (CDR) openEHR Rest API + AQL
  31. 31. open platform architecture Third-party apps Technology-neutral datastore (CDR) openEHR Rest API + AQL
  32. 32. open platform architecture Third-party apps Technology-neutral datastore (CDR) openEHR Rest API + AQL
  33. 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)

×