Anatomy of Standards

729 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
729
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Anatomy of Standards

  1. 1. Anatomy of Healthcare IT Specifications <ul><ul><li>Timothy W. Cook, MSc </li></ul></ul><ul><ul><li>Member, Architecture Review Board, </li></ul></ul><ul><ul><li>openEHR Foundation </li></ul></ul>
  2. 2. Open source… e-Health Proprietary software… Specifications
  3. 3. Specifications <ul><li>Formally Published </li></ul><ul><li>In Use </li></ul><ul><li>May or may not be formally accepted by a SDO. </li></ul>
  4. 4. Four Broad Types <ul><li>Concrete Purpose Specific </li></ul><ul><li>Concrete Generic Schema </li></ul><ul><li>Concrete Generic Schema + </li></ul><ul><li>Reusable formal clinical content models </li></ul>
  5. 5. Common Characteristics <ul><li>Modeling </li></ul><ul><li>Interoperability </li></ul><ul><li>Clinical Engagement </li></ul><ul><li>Economics </li></ul>
  6. 6. Concrete Purpose Specific Modeling <ul><li>every message schema has to be hand built; </li></ul><ul><li>generally limited re-use of elements between messages; </li></ul><ul><li>no reuse at all across implementation technologies, there is no way to use a message definition to generate GUI elements, service interface or other expressions; </li></ul>
  7. 7. Concrete Purpose Specific Interoperability <ul><li>functional interoperability is achieved (within the limits of local variations of message implementations) </li></ul><ul><li>semantic interoperability is possible depending on how tightly controlled the definitions and use of coding are </li></ul><ul><li>systems suffer from semantic incoherence from GUI to persistence layers, because their messages are developed and implemented separately from their GUI capture and display, persistence, and service interfaces </li></ul><ul><li>very limited support for querying </li></ul>
  8. 8. Concrete Purpose Specific Clinical Engagement <ul><li>usually difficult for clinicians to engage with in order to define content for each new message => messages only approximate requirements </li></ul>
  9. 9. Concrete Purpose Specific Economics <ul><li>inflexible; changed requirements => new message definitions </li></ul><ul><li>relatively low cost of use for a given message, since message structure fully mapped out - implemeters only have to generate prescribed content; no theoretical understanding required </li></ul><ul><li>scalable to some point but with a linear increasing cost and often NxN complexity characteristics </li></ul><ul><li>costs of system building borne separately </li></ul>
  10. 10. Examples <ul><li>EDIFACT </li></ul><ul><li>HL7v2 messages </li></ul><ul><li>HL7v3 messages (slightly more generic message production approach, but vastly higher development cost per message compared to HL7v2) </li></ul><ul><li>ASTM CCR message (one size fits all approach) </li></ul>
  11. 11. Concrete Generic Schema Modeling <ul><li>only a single schema required; much cheaper to implement at a basic level </li></ul><ul><li>however no controls on what how content is expressed in the structures defined by the schema; two implementers are most likely to develop two different configurations to express 'vital signs observations' </li></ul>
  12. 12. Concrete Generic Schema Interoperability <ul><li>functional interoperability guaranteed (single shared data schema) </li></ul><ul><li>semantic interoperability likely to be poor / chaotic / unmanaged </li></ul><ul><li>basic querying supported but only useful if content structures standardised </li></ul>
  13. 13. Concrete Generic Schema Clinical Engagement <ul><li>no direct way for clinicians to engage; clinical modelling usually done (badly) by software developers </li></ul>
  14. 14. Concrete Generic Schema Economics <ul><li>relatively cheap in limited local contexts </li></ul><ul><li>not scalable </li></ul><ul><li>some software re-use within systems </li></ul>
  15. 15. Examples <ul><li>EN13606-1 XSD on its own </li></ul><ul><li>HL7 CDAr2 XSD on its own (more or less, although it is only partly generic at the Entry level) </li></ul><ul><li>openEHR Reference Model expressed as an XSD or other similar format on its own </li></ul>
  16. 16. Concrete Generic Schema + Modeling <ul><ul><li>only a single schema required; much cheaper to implement at a basic level </li></ul></ul><ul><ul><li>however no controls on what how content is expressed in the structures defined by the schema; two implementers are most likely to develop two different configurations to express 'vital signs observations' </li></ul></ul>
  17. 17. Concrete Generic Schema + Interoperability <ul><li>+ semantic querying supported </li></ul>
  18. 18. Concrete Generic Schema + Clinical Engagement <ul><li>+ clinicians can directly engage and build content models for use with the schema </li></ul><ul><li>+ modeling governance framework required </li></ul><ul><li>+ separate modelling still required for many aspects of systems, particularly GUI and service interfaces content models for use with schema </li></ul>
  19. 19. Concrete Generic Schema + Economics(1)‏ <ul><li>higher costs of centralized / regional planning & governance </li></ul><ul><li>lower incremental costs (i.e. cost of deal with each new requirement) </li></ul><ul><li>higher implementation cost per site; some level of theoretical understanding required </li></ul><ul><li>reduced cost of systems due to some software re-use </li></ul>
  20. 20. Concrete Generic Schema + Economics(2)‏ <ul><li>highly scalable with a cost characteristic probably of a NlogN shape </li></ul><ul><li>possibility of concrete gains in preventative and personalized health due to ability to do true semantic querying through and across EHRs </li></ul>
  21. 21. Examples <ul><li>EN13606-1 + EN13606-2; caveat: EN13606-1 doesn't provide a direct basis for many useful clinical archetypes; no templates </li></ul><ul><li>HL7 CDAr2 + HL7 templates (schema specializations of CDA main schema; limited reuse) </li></ul><ul><li>openEHR RM XSD + archetypes + templates </li></ul>
  22. 22. Formal clinical content models Modeling <ul><li>Essentially the same as above </li></ul>
  23. 23. Formal clinical content models Interoperability <ul><li>Essentially the same as above. </li></ul>
  24. 24. Formal clinical content models Clinical Engagement <ul><li>+ getting towards single-source modeling - clinicians can model once and have their semantics appear everywhere. </li></ul>
  25. 25. Formal clinical content models Economics <ul><li>+ lower implementation cost per site - same as for using hand-built messages </li></ul><ul><li>+ significantly reduced costs of system due to pervasive re-use of generated artifacts </li></ul>
  26. 26. Examples <ul><li>openEHR abstract RM + archetypes + templates </li></ul>
  27. 27. Thank You <ul><li>Questions? </li></ul><ul><li>Contact: http://timothywayne.cook.googlepages.com/home </li></ul>

×