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.

MedWeb 3.0 @ CAIS 2013

625 views

Published on

Prof. Luciana Cavalini, MD, PhD presents MedWeb 3.0 a startup based on Mulit-Level Healthcare Information Modelling (MLHIM) http://www.mlhim.org

Published in: Health & Medicine, Business
  • @lutricav

    'debate for the truth to emerge'

    Dear Mrs. Trical Cavalini, MD, PhD
    Professor, Department of Health Information Technologies
    Rio de Janeiro State University
    Coordinator, MLHIM Research Laboratory

    Please, if you want to argument in a discussion, you should read the whole discussion, you clearly missed some points which where mentioned in the follow up reactions.

    Please, if you want an open discussion, as you say you want, You should not accuse the discussion partner for using misleading arguments, but classify his arguments in a more neutral way.
    Do not let emotions set the tone.

    I suggest therefore that you read the complete discussion, and then write your comment with expression of respect for my arguments, which, of course, you are free to disagree with.

    Have a nice day,

    Bert Verhees
    - Not a Professor, but a developer with over twenty years of experience in implementing standards in health-care related software.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Mr. Verhees's first comments on #MLHIM are misleading. I think it would be important, for him to declare his conflict of interests that motivated his past support and now present (unsupported by evidence on the MLHIM specifications) criticism. I think it is important for the broad #HIT community to know that those conflicts of interest DO EXIST.

    Now let us go point by point:
    Misleading comment 1:
    There is no version 3 of the MLHIM specifications. But there will be someday. The current version of the MLHIM specifications is 2.4.2, the development version is 2.4.3. MedWeb 3.0 is an implementation of the MLHIM specifications in its current version. The name is related to the Web 3.0 aka. The #Semantic #Web, applied to #medicine and #healthcare, so we decided to include the 'Med' prefix and use the '3.0' tag.

    Misleading comment 2:
    Tim Cook already explained the versioning of the MLHIM specifications. Stating that versioning is a negative feature shows ignorance about the technical aspects of the specifications. When things change in the Reference Model, they require a new version and a new namespace. This gives the #specifications durability. Various versions can be used together. We just presented a paper at #FHIES 2013 (also on #SlideShare and #YouTube), where we proved the #semantic #interoperability of data instances, that were valid, in the same application, according to #CCDs developed for versions 2.4.1 and 2.4.2 of the MLHIM Reference Model.

    Misleading comment 3: MLHIM is a specification that makes use of the best of all standards (#HL7, #13606 and the #openEHR specifications). MLHIM overcomes the top-down approach adopted for the definition of any other #HIT #standard. In the #MLHIM ecosystem, any healthcare information system developer has the freedom to define the local implementation but still keeping the ability of sending semantically valid data extracts to any other system. It is a completely bottom-up approach for the achievement of #semantic #interoperability and the guarantee of #syntactic #integrity of #healthcare #information #systems.

    Misleading comment 4: MLHIM is much more than minimizing openEHR and including the concept of Exceptional Values from the #ISO 21090 standard. An overview of the #MLHIM specifications’ documents on www.mlhim.org is enough to clarify that. I have evidence that Mr. Verhees knows better than that; so his demeaning comment must have another purpose.

    Misleading comment 5: MLHIM is not just another Reference Model. It is a complete suite of specifications and tools that allow the development of a robust ecosystem of #semantically #interoperable healthcare applications. I dare any software company to implement it and not reach to the same conclusion.

    We would love to see Mr. Verhees’s other objections posted here. Nothing better than debate for the truth to emerge.

    Luciana Tricai Cavalini, MD, PhD
    Professor, Department of Health Information Technologies
    Rio de Janeiro State University
    Coordinator, MLHIM Research Laboratory
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Whether it is good or bad depends on the problem you are trying to solve. Yes, it is not a common pattern for XML Schema. It is unique to solve a unique problem. The benefits of using XML Schema vs. a domain specific language or writing my own schema language are obvious. Even if the development pattern is not common, the tools are available to do transformations and validation. Those will never be developed for DSLs like ADL.

    It isn't that my life depends on it. It is that it solves a problem that no one else has solved. It requires different thinking so I am not concerned that you find many 'experts' that do not like the approach. They probably do not fully understand the problem facing semantic interoperability in longitudinal healthcare records.

    CCDs allow for re-use of the complexTypes and they produce small instance data documents. These are easily manipulated with semantic web tools and are perfect for NoSQL databases like MarkLogic.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • @twcook

    Indeed, Tim, it was the UUID-thing which hindered me most. Not for my financiers, I never talked with them about this. It was my own choice to dislike it. I saw directly that it would became hard to work with.

    ELEMENTS with a none-semantical name, and also with a impossible to remember name (because the name is a UUID). I don't think many developers like that, and it is against the basic rules of programming: Give datatypes descriptive names.

    In your standard, no name at all is descriptive. One has to guess, or walk down inheritance-trees to find out what descriptive root there is for a specific datatype. Also using other tooling than you have will be impossible. Imagine someone wanting to create a CCD on a UUID-ed ELEMENT which has some meaning in your structures, he will has to type it over, or copy and paste it.

    By the way, it was confirmed by others, and also, experts on XML-databases explained that for every derived ELEMENT having another name, like you are forced to in your structure, makes XML-indexes slow and large, because they are forced to have many primary entries which are needed all to walk through when performing an XPath-query.

    It was really a bad solution, and I know the cause, it is because of a limitation of XML-Schema, and your intuition which told you that other schema-languages were not good enough.

    It was not a wise choice to do the UUID thing, you did it because you were forced to do so, because of external limitations, which came from other choices you had made. And now you grab it and hold it as if your life depends on it.

    It is not so, Tim, your life does not depend on it.
    You should reconsider what you have created, and throw away the shit in it, the UUID thing. You could, even, by the way, create your own XML Schema-language, if your objections against RelaxNG or Schematron are too large. Take the Apache XSD-validator, it is open source, and rebuild it, it are not many code-lines to change to have accepting the situations so you are not anymore forced to use the UUID's as ELEMENT (datatype) names.

    You did only do the half way, and that is why you are in trouble., which you will deny. That doesn't matter.

    Take my advice, and make some necessary choice.
    -----------------
    Sorry that I misunderstood your version-numbering, I think you should be glad I brought it up, so you have a reason to explain it.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • It isn't MLHIM 3.0. MedWeb 3.0 (reference Web 3.0 technologies) is based on MLHIM 2.4.x

    I haven't the time right now to comment on the painfully slow 'standards process'. What MLHIM offers is the option to move to a new version or not, as you choose. It is a bottom up environment, not top down.

    I realize the whole approach is difficult for many people to grasp. Interesting you say you didn't like when there are many posts saying how much you loved it, until your financiers and other developers didn't want to use UUIDs. Too bad for them.

    MLHIM is great, it works for us. Use it if you like, don't use it if you want to keep doing the same old things with HL7 and openEHR.

    Have a great day.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

MedWeb 3.0 @ CAIS 2013

  1. 1. WEB 3.0 AND HEALTHCARE: SEMANTIC INTEROPERABILITY AND STABILITY FOR MEDICAL APPLICATIONS Profa. Luciana Tricai Cavalini Departamento de Tecnologias de Informação em Saúde Faculdade de Ciências Médicas Universidade do Estado do Rio de Janeiro (UERJ)
  2. 2. Dynamics and Complexity of Healthcare WHY EVERYTHING ELSE IS COMPUTERIZED, BUT HEALTHCARE?
  3. 3.  Effective healthcare systems respond quickly to changes in demographic and epidemiological profiles of the population  These changes are often unexpected. Examples:  Zoom out: when there is an epidemic (or tsunami)  Zoom in: anytime the emergence of a large hospital  In paper-based healthcare systems, it takes weeks to to identify an epidemic (zoom out) or an outbreak of MARSA in a hospital (zoom in)  For decades, it has been promised that these problems will disappear with the computerization of healthcare services  The fact is that such promises have not been fulfilled yet. HEALTH INFORMATICS: PANACEIA OR PLACEBO? Why? Why is it so easy to computerize everything (banks, tax and fine collection, e-commerce) and it is so difficult in healthcare? (Shaw et al, 2002)
  4. 4.  Flooding the healthcare system with hardware (and the corresponding embedded software) has an insignificant effect on the improvement of individual population and health outcomes  No illusions: NOTHING will NEVER surpass the effect of the improvement in income, sanitation and immunization coverage  However, it takes millions or even billions to computerize, without planning, healthcare systems  There is not much critical mass in the technical areas of government (or private hospitals) on software quality for healthcare  Medical software is purchased or developed with the same software architecture adopted for video rental stores, gas stations or bank tellers E-HEALTH JUST BECAUSE? Trust me: it is not going to work. But why?
  5. 5.  Just for not to give the impression that the problem of medical informatics is merely the software quality:  Imagine the medical software with the best quality possible, based on traditional modeling, installed in Clinical C.  The patient goes to clinic C to make a preoperative catheterization, but the pacemaker surgery will be done at the Hospital H, which also has a similar software.  It does not matter how good both software are, the context of information collected in Clinic C is "trapped" in the data model defined in the code of the Software C, and the same for Software H ONE PARENTHESIS Back to the question: Why software modeling being used in all other economy sectors is not effective in healthcare?
  6. 6. WHY HEALTHCARE IS DIFFERENT? I had such ideas reading: Dawkins R. The greatest spectacle on Earth, pp. 204-5 (and Marx, of course). Evolution had millions of years to reach such complexity Human civilization starts just dozens of thousands of years ago Industrial systems are as simple as possible to maximize profit Biological systems are as complex as necessary to guarantee the survival of the species  Healthcare is the only sector of the economy that deals with biological production processes (created by nature)  All other sectors of the economy deal with industrial production processes (created by man)  Man-made production processes created by man are simpler than biological because:
  7. 7. Healthcare systems are much more complex than anything else in the world regarding 3 dimensions: Space Time Ontology DYNAMICS AND COMPLEXITY IN HEALTHCARE
  8. 8. Two cities can be neighbors and have completely different healthcare needs (e.g. Córdova and Saldán) Better said, two neighborhoods can be neighbors and have completely different healthcare needs! Better said, two buildings in the same street can be neighbors and have completely different healthcare needs! Better said, two people living together can have completely different healthcare needs! Better said, your heart and your feet DO HAVE completely different healthcare needs! Better said, two alleles that determine completely different diseases will have different genetic therapies in the future! SPATIAL COMPLEXITY (1)
  9. 9. Zooming Out...
  10. 10. SPATIAL COMPLEXITY (2)
  11. 11. TEMPORAL COMPLEXITY
  12. 12. TEMPORAL COMPLEXITY
  13. 13. TEMPORAL COMPLEXITY
  14. 14. TEMPORAL COMPLEXITY
  15. 15. TEMPORAL COMPLEXITY
  16. 16. TEMPORAL COMPLEXITY
  17. 17. TEMPORAL COMPLEXITY
  18. 18. TEMPORAL COMPLEXITY
  19. 19. Zooming In...
  20. 20. TEMPORAL COMPLEXITY
  21. 21. Unfortunately, the cute pictures are over.
  22. 22.  The largest medical terminology (SNOMED-CT) has more than 310,000 terms connected by over 1,000,000 links  This means that in medicine, there are about 310,000 concepts interconnected by millions of different forms  In practical terms, this means that deploying a "megalithic system" that all healthcare services could use would require deploying a system with a huge amount of tables with 310.000 fields and million of relationships among themselves ONTOLOGICAL COMPLEXITY Cavalini-Cook Conjecture: The probability of consensus between 2 or more experts regarding what would be the “maximum data model” for any given healthcare concept tends to zero
  23. 23.  This complexity makes a computer sience problem that does not exist (or it is not critical) in any other sector of human society to be very severe in healthcare.  This problem is: WHAT DOES THIS COMPLEXITY CAUSE?
  24. 24.  For common mortals:  Semantic interoperability is the ability to send an information extract from system A to system B, and from both to system C, and vice-versa, and so on, being all those information extracts semantically valid in all systems SEMANTIC INTEROPERABILITY All systems read and understand all information extracts from all other systems Syntactic integrity is also important: - Otherwise, the Semantic Web would have solved the problem of healthcare IT - That is not the case, because the Semantic Web marks up data instances - The syntax of each application is still incompatible to any other
  25. 25. - Cough - 3 months - Low fever Chest X-Ray - Nodule in right apex BAL: - TB Chest X-Ray - Nodule in right apex BAL: - TB - Cough - 3 months - Low fever - Cough - 3 months - Low fever Chest X-Ray - Nodule in right apex
  26. 26.  A person can be a member of several video rental stores. Your rental history at the video store A in no way affects the customer service one will receive at the video store B  In healthcare, everything is interconnected!  What happened when the patient was seen at the primary care setting is CRITICAL to define the treatment at the hospital  “Oh, but the patient can tell.“  But many patients are unconscious or under the influence of psychotropic drugs in the most critical moments of their lives, and families around are crying and not well informative either  “Oh, but you can print primary care report and re-type in the EMR“  “Oh, let us deploy a Bid System that works in both places" That (and similar things that work for other industries) have been tried in healthcare since 1961, with a cost of billions of dollars and euros, and nothing has worked WHY HEALTHCARE NEEDS SEMANTIC INTEROPERABILITY?
  27. 27.  Semantic interoperability is critical, but the time complexity brings an unavoidable problem even for self-contained systems  In healthcare, you define your data model today and it does not last six months, because the concepts are evolving quickly and new concepts appear every day  The average time for a medical software to be abandoned is 2 years and the dropout rate is 70% (source: CHAOS Report) ANOTHER PROBLEM: MAINTENANCE
  28. 28.  Many (very expensive!) things were and still have been proposed to solve the problem of semantic interoperability and reduce the maintenance costs of applications in biomedicine, with no clear results  Adding to that the fact that healthcare is the most conservative sector of society, the result is that healthcare is the only system that still relies entirely on paper  Lobbyists knock at the governments’ doors all the time, claiming that they have at hand the solution to the problems of e-health, and governments, afflicted with political pressure and complaints about the quality of the healthcare system, buy that and waste hundreds of millions of [currency]  Software companies do not want to develop healthcare products because it is complicated and customers are never satisfied CONSEQUENCE
  29. 29. To this moment, standards seem to be the solution for the technical problems in health informatics The two main Standard Development Organizations in health informatics are: Health Level 7 (HL7) International Standards Organization (ISO) SOLUTION: STANDARDS (?)
  30. 30. Health Level 7 Inc. is the enterprise that develops the HL7 standard since 1987 HL7 is a healthcare information exchange standard accredited by the American National Standards Institute (ANSI) There are two versions of HL7: HL7v2 HL7v3 HL7
  31. 31.  Despite the New Day… initiative, which presents several unresolved issues regarding intellectual property, the fact is that HL7 is still a commercial standard  The standardization of messages restricts the modeling of clinical concepts - most messages are directed to the administrative part of the systems  It has been created a Babel of initiatives around HL7 going in different directions - the solution has become part of the problem  There is not a single proven record of implementing EHRs based on the HL7v3 RIM  HL7 messages do not allow backward validation, because the RIM allows extensions HL7(V3): CHALLENGES
  32. 32. The slowness of the ISO process makes it irrelevant: more dynamic initiatives are adopted as de facto standards before becoming ISO (if that ever happens) The representativeness is based on the ability to participate in meetings, not on the actual market (producers or consumers) needs Consequence: low level of implementation of the ISO Standards ISO TC 215: CHALLENGES
  33. 33. THE BASIC PROBLEM IS...
  34. 34. THE BASIC PROBLEM IS...
  35. 35. THE BASIC PROBLEM IS...
  36. 36. A HELIOCENTRIC SPIN
  37. 37. A heliocentric standard for health informatics MULTILEVEL MODELING
  38. 38. MULTILEVEL MODELING PRINCIPLES Domain expert Concept library Domain vocabulary defines using Computer scientist Information model Schema defines expressed as A P P L I C A T I O N Data persistence instances
  39. 39. IN A SIMPLER WAY... Reference Model Domain Models Your application (GUI, DSS, BI etc)
  40. 40. In multilevel modeling, the context of the information does not get “incarcerated” in the software That is because the Reference Model it is composed by generic classes which contain as minimal context as possible The information context is contained, in an interchangeable format, in the Domain Models (archetypes or CCDs) Information collected at the point of care will have its context persisted forever: future changes in the software – keeping the Reference Model stable – will no longer affect the information content These information extracts, containing the original context, properly space and time referenced, can be shared by any application based on the same Reference Model BRINGING BACK THE CONTEXT
  41. 41. DOMAIN MODELING Archetypes (openEHR or ISO 13606) CCD (MLHIM) Concept Constraint Definition
  42. 42. 2013: “Spontaneous” convergence of openEHR towards MLHIM ISO 13606 future is uncertain 2009: MLHIM is launched Turn on the 21st century: Cook tries to harmonize TORCH to openEHR openEHR goes to ISO and negociates the 13606 Standard family Last years of the 20th century: Europe: GEHR project turns into openEHR US: Cook develops TORCH HISTORY
  43. 43. THE KEPLERIAN PROBLEM OF MULTILEVEL MODELING
  44. 44. A HELIOCENTRIC MODEL FOR A REAL WORLD
  45. 45. MULTILEVEL MODELING APPROACHES openEHR MLHIM 13606Models (Quasi) Maximalist Minimalist ReductionistApproach (Quasi) Maximum Any size (Uncertain) Data model No data receiving mhealth Any application Only message exchange Possible implementation Intense Minimal Intermediate RM residual context
  46. 46. KNOWLEDGE MODELING APPROACHES openEHR MLHIM 13606Models Archetype CCD ArchetypeStructure (More than) one Any number (Uncertain) # of structures / concept (Partially) top- down, consensus Bottom-up, merit (Uncertain) Governance model ADL XML Schema ADLLanguage
  47. 47. BUT THE SUN IS NOT THE CENTER OF THE UNIVERSE…
  48. 48. A social network for health and medicine
  49. 49. MEDWEB 3.0 IS... A social network for doctors and patients to share clinical, health and wellness information Patient can create they own customized profiles and share with their doctors The doctors can create costumized profiles for their patients Different personal and clinical profiles for clinics, hospitals and ambulances
  50. 50. MEDWEB 3.0 IS... Doctors can access the clinical profiles of their patients at any hospital They can share the clinical profiles to other doctors that take care of their patient They can access the clinical profiles other doctors created for their patients All those profiles are customized and shareable
  51. 51. MEDWEB 3.0 IS... Patients can share their customized profile to all their doctors They can check if the doctor already filled up their prescription They can share the blood pressure measured by their digital device They can share gym activity with their nutritionist and cardiologist
  52. 52. SOME MEDWEB 3.0 APPS Patient Profiler A MedWeb 3.0 app to create customized profiles for patients Clinical Profiler A MedWeb 3.0 app to create customized profiles for doctors
  53. 53. SOME MEDWEB 3.0 APPS Hospital Profiler An enterprise-level app to create clinical and patient profiles for hospitals Nurse Profiler Other healthcare professionals can create their own customized and shareable profiles for their patients
  54. 54. SOME MEDWEB 3.0 APPS Clinical Alerts Clinical Profiler Plugins for epidemics report, ICU vital signs monitoring, lab reminders Patient Alerts Patient Profiler Plugins for medication, physical activity, BP measurement alerts
  55. 55. SOME MEDWEB 3.0 APPS MedWeb 3.0 Stats Personalized reports for doctors about their patient’s data (% of diabetics, cure rates) Clinical Research Apps Clinical trial enrollment, genomics and proteomics data sharing, medical surveys
  56. 56. WHAT HAVE WE DONE SO FAR The complete informational infrastructure The Patient and Clinical Profiler Generator The Patient and Clinical Profile Repository
  57. 57. THANK YOU! lutricav@lampada.uerj.br Special thanks to: Tim Cook SADIO
  58. 58. https://www.facebook.com/mlhim2 http://gplus.to/MLHIMComm @mlhim2 https://www.youtube.com/user/MLHIMdotORG

×