Application-Level Security in Health IT Systems: A Roadmap

An investigative report titled "Health-care sector vulnerable to hackers, researchers say" published last month in the Washington Post on the state of cybersecurity reveals that:

"...health care is among the most vulnerable industries in the country, in part because it lags behind in addressing known problems."

When it comes to application-level security, the healthcare industry is indeed lagging when compared to other industries that handle consumer sensitive information. The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle cardholder information. The PCI DSS certification includes requirements for security code reviews, penetration testing, and compliance validation by an external Qualified Security Assessor (QSA).

This week, the Department of Health and Human Services (HHS) issued a final omnibus rule on the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules. The rules impose the following:

• Increased and tiered civil money penalty structure for security breaches depending on "reasonable diligence", "willful  neglect", and "timely correction". The penalty amount varies from $100 to $50,000 per violation with a maximum penalty of $1.5 million annually for all violations of an identical provision.
• Expansion of accountability and liability for Business Associates (BAs) and subcontractors.
• Increased privacy protections under the Genetic Information Nondiscrimination Act (GINA).

Furthermore, the Security and Privacy Tiger Team of the US Office of the National Coordinator (ONC) for health IT released a set of recommendations related to the Meaningful Use (MU) Stage 2 requirements for patients access to health record portals. The need for patient engagement as a prerequisite to a successful transformation of healthcare means that particular attention should be paid to the security needs of consumer-facing web applications.

Security in the Software Development Life Cycle (SDLC)

Unfortunately, security as a non-functional requirement, is often relegated to an afterthought in the software development life cycle (SDLC). As an afterthought, security is added to the software later or at the end of the development cycle. At that point, adding adequate security is difficult and costly, requiring significant rework. In some cases, penetration testing is not performed at all before the application is deployed into production.

This situation can be exacerbated by an interpretation of the Agile methodology that puts the emphasis on the early and frequent demonstrations to the customer of functional (as opposed to non-functional) features of the system under development.

Another issue is that developers and architects often over-rely on 3rd-party security infrastructure, as opposed to (1) developing a Threat Model for the application they are building and (2) creating a security implementation approach to address the Threat Model. 3rd-party security infrastructure can be helpful, but should serve the security implementation strategy as opposed to driving it. As Bruce Schneier, a well-known cryptographer and computer security specialist said in an article titled "Computer Security: Will We Ever Learn?":

"Security is a process, not a product. Products provide some protection, but the only way to effectively do business in an insecure world is to put processes in place that recognize the inherent insecurity in the products. The trick is to reduce your risk of exposure regardless of the products or patches."

Understanding Potential Security Vulnerabilities

Application Security is a mature discipline. Developers and architects should build a deep understanding of web application security vulnerabilities as opposed to completely relying on 3rd-party security infrastructure for addressing security concerns. The following are well documented bodies of knowledge on security vulnerabilities:

1. The OWASP Top 10 Web Application Security Risks (cheat sheets explaining each of those vulnerabilities and how to address them are available on the OWASP web site):
   
   A1: Injection
   A2: Cross-Site Scripting (XSS)
   A3: Broken Authentication and Session Management
   A4: Insecure Direct Object References
   A5: Cross-Site Request Forgery (CSRF)
   A6: Security Misconfiguration
   A7: Insecure Cryptographic Storage
   A8: Failure to Restrict URL Access
   A9: Insufficient Transport Layer Protection
   A10: Unvalidated Redirects and Forwards.
   
   
2. The CWE/SANS Top 25 Most Dangerous Software Errors, the result of collaboration between the SANS Institute, MITRE, and many top software security experts in the US and Europe.
3. Programming language-specific vulnerabilities such as those listed in the Cert Oracle Secure Coding Standard for Java.
4. Well-documented security vulnerabilities introduced by the use of 3rd-party open source application development frameworks.
5. The National Vulnerability Database
6. The Common Weakness Enumeration (CWE) which is currently maintained by the MITRE Corporation with support from the National Cyber Security Division (DHS). The diagram below  from the CWE web site shows a portion of the CWE hierarchical structure. Click on the image below to enlarge it. 
7. Obviously, developers should be on the lookout for new and emerging threats to web application security.

Application Threat Modelling

Armed with a deep understanding of potential vulnerabilities, developers and architects can build a Security Policy (who has what type of access to which resource in the system) and a Threat Model including:

• An analysis of the attack surface of the application.
• Identification of potential threats and attackers (both inside and outside the organization and its business associates and subcontractors) and their characteristics, tactics, and motivations. A threat categorization methodology such as STRIDE can be used. STRIDE defines the following threat categories: Spoofing of user identity, Tampering, Repudiation, Information disclosure (privacy breach or Data leak), Denial of Service (D.o.S.), and Elevation of privilege. 
• The consequences of those attacks for patients and the healthcare organization serving them.
• Countermeasures and a risk mitigation strategy. The Application Security Frame (ASF) defines the following categories of countermeasures:  Authentication, Authorization, Configuration Management, Data Protection in Storage and Transit, Data Validation/Parameter Validation, Error Handling and Exception Management, User and Session Management, Auditing and Logging.
• How the deployment environment will impact privacy and security. NIST and the Cloud Security Alliance (CSA) provide specific security guidance for cloud deployment.
• New software architectures like the Single Page Application (SPA) approach present new challenges in securing web applications. Single Page Applications are subject to common web application vulnerabilities like Cookie Snooping, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and JSON Injection. Security is mainly the responsibility of the server, although client-side frameworks like AngularJS also provide some features to enhance the security of Single Page Applications.

 

Developing a Security Implementation Strategy

To address the issues of secure software development in the context of Agile, the Software Assurance Forum for Excellence in Code (SAFECode) published a guide titled "Practical Security Stories and Tasks for Agile Development Environment".

Secure Coding Standards, Static Analysis, and Security Code Review

Many developers are aware of coding conventions (such as the Code Conventions for the Java Programming Language),  and the benefits of peer code reviews and static code analysis (using tools like Checkstyle, PMD, FindBugs, and Sonar). These practices should be expanded to cover secure coding as well. The following resources can help:

• The Cert Oracle Secure Coding Standard for Java.
• The OWASP Code Review Guide.
• The "Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today" published by the Software Assurance Forum for Excellence in Code (SAFECode)
• The Payment Card Industry Data Security Standard (PCI DSS) "Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified" is an example of secure code review requirements in an industry vertical.

There are secure code static analysis tools that can be particularly useful when used in combination with a secure code review process. If possible, the static code analysis should be integrated into the build and continuous integration process to provide specific secure code metrics as well as the evolution of those metrics over time.

Penetration Testing

Finally, the application should go through penetration testing before it is deployed into production. Application-level penetration testing should be done in addition to network-level penetration testing. OWASP provides a detailed Testing Guide and a number of open source and commercial penetration testing tools are available as well.

Visual Analytics for Clinical Decision Making

In my last post, I talked about the era of Big Data in medicine, Evidence-Based Practice (EBP),  Practice-Based Evidence (PBE), and the need for a human-centered approach to building intelligent health IT (iHIT) systems. In this post, I discuss Visual Analytics, an emerging discipline in Data Science. In a report titled "Illuminating the Path: The R&D Agenda for Visual Analytics" published in 2004 by the National Visualization and Analytics Center (NVAC), Visual Analytics is defined as "the science of analytical reasoning facilitated by visual interactive interfaces."

The goal of Visual Analytics is to obtain deep insight for effective understanding, reasoning, and decision making through the visual exploration of massive, complex, and often ambiguous data. As a multidisciplinary field, Visual Analytics combines several disciplines such as human perception and cognition, interactive graphic design, statistical computing, data mining, spatio-temporal data analysis, and even art.

In his book titled "Beautiful Evidence", Edward Tufte illustrates the fundamental principles of analytical design by using Charles Minard's famous map known as "Carte figurative des pertes successives en hommes de l'Armée Française dans la campagne de Russie 1812-1813" (Figurative Map of the successive losses in men of the French Army in the Russian Campaign 1812-1813). The map is a dramatic account of the heavy losses of the french army during Napoleon's Russian campaign of 1812. Edward Tuffe calls the map the "best statistical graphics ever". Click on the image below to enlarge it.

Visual Analytics is also an emerging discipline in healthcare informatics. For example, similar to Minard's map of the Russian Campaign of 1812-1813, Visual Analytics can help in comparing different interventions and care pathways and their respective clinical outcomes over a certain period of time through the vivid showing of causes, variables, comparisons, and explanations. This approach contrasts with the traditional display of clinical data in table rows that is so common in electronic health record (EHR) systems interfaces.

Another Visual Analytics technique called Visual Cluster Analysis can be particularly helpful in Comparative Effectiveness in clinical care settings where the goal is to compare the benefits and harms of different interventions for different subgroups (groups of patients sharing similar clinical characteristics such as age, gender, race, genetic profile, and comorbidities). Given a specific patient, Visual Cluster Analysis can help the clinician visually explore what works and what doesn't work for "similar patients".

You can find interesting examples of research projects and implementations in the proceedings of the Visual Analytics in Healthcare Workshop which has been held in conjunction with the IEEE VisWeek for the past three years. The 2013 Visual Analytics in Healthcare Summit (VHAC 2013) will be held in conjunction with the AMIA 2013 conference in Washington DC. There are a number of open source toolkits that can be used to implement Visual Analytics. Some of them are based on open web standards such as HTML5, CSS3, SVG, and Javascript. My favorite is D3.js. DC.js and Crossfilter are built on top of D3.js and facilitate the creation of interactive visualization of multivariate datasets in the browser.

Prediction for 2013: Intelligent Health IT Systems (iHIT) Go Mainstream

iHIT systems represent an evolution of clinical decision support (CDS) systems. Traditionally, CDS systems have provided functionalities such as Alerts and Reminders, Order Sets, Infobuttons, and Documentation Templates. iHIT systems go beyond these basic functionalities and are poised to go mainstream in 2013. This evolution is enabled by recent developments in both computing and healthcare. Notably in computing:

• The emergence of Big Data and massively parallel computing platforms like Hadoop.
• The entrance of the following disciplines into the mainstream of computing: Machine Learning (a branch of Artificial Intelligence), Statistical Computing, Visual Analytics, Natural Language Processing, Information Retrieval, Rule engines, and Semantic Web Technologies (like RDF, OWL, SPARQL, and SWRL). These disciplines have been around for many years, but have been largely confined into Academia, very large organizations, and niche markets.
• The availability of open source tools, platforms, and resources to support the technologies mentioned above. Examples include: R (a statistical engine), Apache Hadoop, Apache Mahout, Apache Jena, Apache Stanbol, Apache OpenNLP, and Apache UIMA. The number of books, courses, and conferences dedicated to these topics has increased dramatically over the last two years signalling an entrance into the mainstream.

In addition, the healthcare industry itself is currently going through a significant transformation from a business model based on the number of patients treated to a value-based payment model. The Accountable Care Organization (ACO) is an example of this new model. This model puts an increased emphasis on meeting certain quality and performance metrics driven by the latest scientific evidence (this is called Evidence Based Practice or EBP).

Although very costly, Randomized Control Trials (RCTs) are considered the strongest form of evidence in EBP. Despite their inherent methodological challenges (lack of randomization leading to possible bias and confounding), observational studies (using real world data) are increasingly recognized as complementary to RCTs and an important tool in clinical decision making and health policy. According to a report titled "Clinical Practice Guidelines (CPGs) We Can Trust"  published by the Institute Of Medicine (IoM):

"Randomized trials commonly have an under representation of important subgroups, including those with comorbidities, older persons, racial and ethnic minorities, and low-income, less educated, or low-literacy patients."

Investments into Comparative Effectiveness Research (CER) are increasing as well. CER, an emerging trend in Evidence Based Practice (EBP), has been defined by the Federal Coordinating Council for CER as "the conduct and synthesis of research comparing the benefits and harms of different interventions and strategies to prevent, diagnose, treat and monitor health conditions in 'real world' settings." CER is important not only for discovering what works and what doesn't work in practice, but also for an informed shared decision making process between the patient and her provider.

The use of predictive risk models for personalized medicine is becoming a common practice. These models can predict the health risks of patients based on their individual health profiles (including genetic profiles). These models often take the form of logistic regression models. Examples include models for predicting cardiovascular disease, ICU mortality, and hospital readmission (an important ACO performance measure).

Thanks to the Meaningful Use incentive program, adoption of electronic health record (EHR) systems by providers is rapidly increasing. This translates into the availability of huge amount of EHR data which can be harvested to provide Practice Based Evidence (PBE) necessary to close the evidence loop. PBE is the key to a learning health system. The Institute of Medicine (IOM) released a report last year titled "Digital Infrastructure for the Learning Health System: The Foundation for Continuous Improvement in Health and Health Care". The report describes a learning health system as:

"...delivery of best practice guidance at the point of choice, continuous learning and feedback in both health and health care, and seamless, ongoing communication among participants, all facilitated through the application of IT."

Both EBP and PBE will require not only rigorous scientific methodologies, but also a computing platform suitable for the era of Big Data in medicine. As Williams Osler (1849-1919) famously said:

"Medicine is a science of uncertainty and an art of probability."

Lastly, to be successful, the emergence of iHIT systems will require a human-centered design approach. This will be facilitated by the use of techniques that can enhance human cognitive abilities. Examples are: Electronic Checklists (an approach that originates from the aviation industry and has been proven to save lives in healthcare delivery as well) and Visual Analytics.

Happy New Year to You and Your Family!

A Journey into Software Excellence

I am back in the blogosphere after a seven month hiatus. It was about time I get my blogging act together. Software development has never been so much fun. In this post, I will share some thoughts on using tools, methods, and practices that can really help in your search for software excellence from the initial prototyping of the user interface to deployment.

1. With the rapid proliferation of mobile and desktop devices, adopt a Responsive Wed Design (RWD) strategy to reach the largest audience possible.
2. Create responsive sketches, wireframes, or mockups and apply usability guidelines during the initial prototyping. The NHS Common User Interface (CUI) Program is a good example of usability guidelines for healthcare IT applications. Usability.gov also has many interesting resources as well.
3. Perform usability testing to test your design ideas and obtain early feedback from future users of your product before actual development starts. Use metrics such as the System Usability Scale (SUS) to assess the results.
4. Carefuly select the right HTML5, CSS3, and Javascript libraries and frameworks. The Single Page Application (SPA) architecture is becoming popular and can provide a more fluid user experience.
5. Consider "Specification By Example" and Behaviour Driven Development (BDD) tools like Cucumber-JVM to create executable user stories.
6. Pattern languages like Domain Driven Design (DDD) can help you avoid a "Big Ball of Mud" in architecting your software. DDD concepts such as "Strategic Design", "Bounded Context", "Published Language", and "Anti-Corruption Layer" can help you put your architecture in the right perspective, particularly if there is a need to support industry interoperability standards such as HL7 and IHE. However, beware that the practice of DDD has evolved over the last 8 years and new lessons have been learned particularly in the area of "Aggregate" design. So keep up-to-date with new developments in the field in order to leverage the experience of the community. I also found the concept of "Hexagonal Architecture" very helpful in visualizing the complexity of an architecture from different angles.
7. Consider a peer review of the architecture using a methodology like the Architecture Tradeoff Analysis Method (ATAM).
8. Embrace Polyglot Persistence (the use of different persistence mechanisms such as relational, document, and graph databases within the same application). However, use the right application development framework to make this easy. Beware of the peculiarities of modeling data for NoSQL databases and remember that "Persistence Ignorance" is not always easy to achieve in practice.
9. Add a social dimension to your product by integrating the user experience with existing social networking sites that your users already belong to.
10. Make your application more intelligent through the use of techniques such as Machine Learning (e.g., a recommendation engine), ontologies and rule engines (e.g., automated reasoning), and Natural Language Processing (NLP) (e.g., automated question answering). As Richard Hamming said: "The purpose of computing is insight, not numbers".
11. To enhance the user experience, adopt HTML5, SVG, and Javascript-based graphing and data visualization techniques for data-intensive applications.
12. Consider the benefits of deploying the application to the cloud and if you decide to deploy to the cloud, factor that into your entire design and development process including the selection of development tools. Choosing the right Platform-as-a-Service (PaaS) provider can facilitate the process.
13. Create a Continuous Delivery pipeline based on the core concept of automated testing. Leverage tools like Git (Distributed Version Control), Gradle (build), Jenkins (Continuous Integration), and Artifactory. Continuous Delivery allows you to go to market faster and with confidence in the quality of your product. Save infrastructure costs by using these tools in the cloud during development.
14. Although there is still a place for manual testing, all tests should be automated as much as possible. In addition to the traditional unit tests (using tools like JUnit, TestNG, and Mockito), embrace automated cross-device, cross-browser, and cross-platform user interface (UI) testing using a tool like Selenium.
15. Web services and performance testing should also become part of your build and Continuous Delivery pipeline using tools like soapUI and JMeter respectively. Performance testing should not be an afterthought.
16. Adopt automated code quality inspection with tools like Sonar, Checkstyle, FindBugs, and PMD. This can supplement your peer code review process and can provide you with concrete code quality metrics in addition to automatically flagging bugs (including insecure code) in your code base.
17. Write secure code by carefully studying the OWASP Top Ten. Adopt OWASP guidelines related to security testing and secure code reviews. Perform penetration testing to find vulnerabilities in your application before it is too late.
18. Do your due diligence in protecting the privacy of your users data. Put the users in control of their privacy in your system by adopting standards such as OAuth2, OpenID Connect, and the User Managed Access (UMA) protocol of the Kantara Initiative. Consider increasing the strength of authentication using multi-factor authentication (e.g., two-factor authentication using the user's phone).
19. Invest in learning and training your development team. Software excellence can only be achieved by skilled professionals.
20. Relax, have fun, and remember that software excellence is a journey.

How to Add Arbitrary Metadata to Any Element of an HL7 CDA Document

There has been a lot of buzz lately about metadata tagging in the health IT community. In this blog, I describe an approach to annotating HL7 CDA documents (or any other XML documents) without actually editing the document that is being annotated. Metadata tagging is just an example of annotation. The underlying principle of this approach is that Anyone can say Anything about Anything (the AAA slogan) which is well know in the Semantic Web community. In other words, anyone (e.g., patient, care giver, physician, provider organization) should have the ability to add arbitrary metadata to any element of a CDA document. For the sake of "Separation of Concerns" which is a fundamental principle in software engineering, the metadata should be kept out of the CDA document. The benefits of keeping the metadata or annotations out of the CDA document include:

• Reuse of the same metadata by distinct elements from potentially multiple clinical documents.
• The ability to update the metadata without affecting the target CDA documents.
• The ability for any individual, organization, or community of interest (e.g., privacy or medical device manufacturers) to create a metadata vocabulary without going through the process of modifying the normative CDA specification (or one of its offsprings like the CCD, the C32, or the Consolidated CDA) or the XDS metadata specifications.

History and Current Status of Metadata Standards in Health IT

The CDA specification defines some metadata in the header of a CDA document. In addition, the XD* family of specifications (XDS, XDR, and XDM) also defines a comprehensive set of metadata to be used in cross enterprise document exchange. NIEM is being used currently in several health IT projects. In a previous post titled "Toward a Universal Exchange Language for Healthcare", I described how the NIEM metadata approach could be adapted to the healthcare domain.

The President's Council of Advisors on Science and Technology (PCAST) published a report in December 2010 entitled: "Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward". To describe the proposed approach to metadata tagging, the report provides an example based on the exchange of mammograms:

"The physician would be able to securely search for, retrieve, and display these privacy protected data elements in much the way that web surfers retrieve results from a search engine when they type in a simple query.

What enables this result is the metadata attached to each of these data elements (mammograms), which would include (i) enough identifying information about the patient to allow the data to be located (not necessarily a universal patient identifier), (ii) privacy protection information-who may access the mammograms, either identified or de­identified, and for what purposes, (iii) the provenance of the data-the date, time, type of equipment used, personnel (physician, nurse, or technician), and so forth."

The HIT Standards Committee (HITSC) Metadata Tiger Team made specific recommendations to the ONC in June 2011. These recommendations included the use of:

• Policy Pointers: URLs that point to external policy documents affecting the tagged data element.
• Content Metadata: the actual metadata with datatype (clinical category) and sensitivity (e.g., substance abuse and mental health).
• Use of the HL7 CDA R2 with headers.

Based on those recommendations, the ONC published a Notice of Proposed Rule Making (NPRM) in August 2011 to receive comments on proposed metadata standards.

The Data Segmentation Working Group of the ONC Standards and Interoperability Framework is currently working on metadata tagging for compliance with privacy policies and consent directives.

The Annotea Protocol

The capability to add arbitrary metadata to documents without modifying them has been available in the Semantic Web for at least a decade. Indeed, it is hard to talk about metadata without a reference to the Semantic Web. I will use the W3C Annotea Protocol (which is implemented by the Amaya open source project) to demonstrate this capability. I will also show that this approach does not require the use of the Resource Description Framework (RDF) format and related Semantic Web technologies like OWL and SPARQL. The approach can be adapted to alternative representation formats such as XML, JSON, or the Atom syndication format. Let's assume that I need to add metadata tags to the CDA document below. The CDA document has only one problem entry for substance abuse disorder (SNOMED CT code 66214007) and my goal is to attach privacy metatada prohibiting the disclosure of that information (the most relevant elements are highlighted in red):

<ClinicalDocument>
.....
<component>
<structuredBody>
<component>
<!--Problems-->
<section>
<templateId root="2.16.840.1.113883.3.88.11.83.103"
    assigningAuthorityName="HITSP/C83"/>
<templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.6"
    assigningAuthorityName="IHE PCC"/>
<templateId root="2.16.840.1.113883.10.20.1.11" assigningAuthorityName="HL7 CCD"/>
<!--Problems section template-->
<code code="11450-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
    displayName="Problem list"/>
<title>Problems</title>
<text>...</text>
<entry typeCode="DRIV">
<act classCode="ACT" moodCode="EVN">
    <templateId root="2.16.840.1.113883.3.88.11.83.7"
        assigningAuthorityName="HITSP C83"/>
    <templateId root="2.16.840.1.113883.10.20.1.27"
        assigningAuthorityName="CCD"/>
    <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.1"
        assigningAuthorityName="IHE PCC"/>
    <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.2"
        assigningAuthorityName="IHE PCC"/>
    <!-- Problem act template -->
    <id root="6a2fa88d-4174-4909-aece-db44b60a3abb"/>
    <code nullFlavor="NA"/>
    <statusCode code="completed"/>
    <effectiveTime>
        <low value="1950"/>
        <high nullFlavor="UNK"/>
    </effectiveTime>
    <performer typeCode="PRF">
        <assignedEntity>
            <id extension="PseudoMD-2" root="2.16.840.1.113883.3.72.5.2"/>
            <addr/>
            <telecom/>
        </assignedEntity>
    </performer>
    <entryRelationship typeCode="SUBJ" inversionInd="false">
        <observation classCode="OBS" moodCode="EVN">
            <templateId root="2.16.840.1.113883.10.20.1.28"
                assigningAuthorityName="CCD"/>
            <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"
                assigningAuthorityName="IHE PCC"/>
            <!--Problem observation template - NOT episode template-->
            <id root="d11275e7-67ae-11db-bd13-0800200c9a66"/>
            <code code="64572001" displayName="Condition"
                codeSystem="2.16.840.1.113883.6.96"
                codeSystemName="SNOMED-CT"/>
            <text>
                <reference value="#PROBSUMMARY_1"/>
            </text>
            <statusCode code="completed"/>
            <effectiveTime>
                <low value="1950"/>
            </effectiveTime>
            <value  displayName="Substance Abuse Disorder" code="66214007" codeSystemName="SNOMED" codeSystem="2.16.840.1.113883.6.96"/>
            <entryRelationship typeCode="REFR">
                <observation classCode="OBS" moodCode="EVN">
                    <templateId root="2.16.840.1.113883.10.20.1.50"/>
                    <!-- Problem status observation template -->
                    <code code="33999-4" codeSystem="2.16.840.1.113883.6.1"
                        displayName="Status"/>
                    <statusCode code="completed"/>
                    <value  code="55561003"
                        codeSystem="2.16.840.1.113883.6.96"
                        displayName="Active">
                        <originalText>
                        <reference value="#PROBSTATUS_1"/>
                        </originalText>
                    </value>
                </observation>
            </entryRelationship>
        </observation>
    </entryRelationship>
</act>
</entry>
</section>
</component>
</structuredBody>
</component>
</ClinicalDocument>



The following is a separate annotation document containing some metadata pointing to the Substance Abuse Disorder entry in the target CDA document:

<r:RDF xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:a="http://www.w3.org/2000/10/annotation-ns#"
    xmlns:d="http://purl.org/dc/elements/1.1/">
    <r:Description>
        <r:type r:resource="http://www.w3.org/2000/10/annotation-ns#Annotation"/>
        <r:type r:resource="http://www.w3.org/2000/10/annotationType#Metadata"/>
        <a:annotates r:resource="http://hospitalx.com/ehrs/cda.xml"/>

        <a:context>http://hospitalx.com/ehrs/cda.xml#xpointer(/ClinicalDocument/component/structuredBody/component[1]/section[1]/entry[1])</a:context>

        <d:title>Sample Metadata Tagging</d:title>
        <d:creator>Bob Smith</d:creator>
        <a:created>2011-10-14T12:10Z</a:created>
        <d:date>2011-10-14T12:10Z</d:date>
        <a:body>Do Not Disclose</a:body>
    </r:Description>
</r:RDF>

Please note a few interesting facts about the annotation document:

• As explained by the original specification: "The Annotea protocol works without modifying the original document; that is, there is no requirement that the user have write access to the Web page being annotated."
• The annotation itself has metadata using the well known Dublin Core metadata specification to specify who created this annotation and when.
• The document being annotated is cda.xml located at http://hospitalx.com/ehrs/cda.xml. This is described by the element <a:annotates r:resource="http://hospitalx.com/ehrs/cda.xml"/>.
• The specific element that is being annotated within the target CDA document is specified by the context element: <a:context>http://hospitalx.com/ehrs/cda.xml#xpointer(/ClinicalDocument/component/structuredBody/component[1]/section[1]/entry[1])</a:context> using XPointer, a specification described by the W3C as "the language to be used as the basis for a fragment identifier for any URI reference that locates a resource whose Internet media type is one of text/xml, application/xml, text/xml-external-parsed-entity, or application/xml-external-parsed-entity."
• The XPath expression /ClinicalDocument/component/structuredBody/component[1]/section[1]/entry[1] within the XPointer is used to target the entry element in the CDA document.
• Using XPath (1.0 or 2.0) allows us to address any element (or node) in an XML document. For example, this XPath //value[@code='66214007']/ancestor::entry will point to any entry element which contains a value element with an attribute code='66214007' (essentially targeting all entry elements which contain a Substance Abuse Observation). The combination of XPath, XPointer, and standard medical terminology codes gives the ability to attach any annotation or metadata to any element having interoperable semantics.
• The body element contains the actual annotation: <a:body>Do Not Disclose</a:body>. However, the body of the annotation can also be located outside of the annotation (e.g., in a shared metadata registry) in which case the body element will be marked up as in the following example: <a:body r:resource="http://metadataregistry.com/myconsentdirectives.xml"/>

Alternative Representations

 

As mentioned before, for those who for one reason or another don't want to use RDF and related Semantic Web technologies, the annotation can be easily converted to a pure XML (as opposed to RDF/XML), JSON, or Atom representation. The original Annotea Protocol describes a RESTful protocol which includes the following operations: posting, querying, downloading, updating, and deleting annotations. The Atom Publishing Protocol (APP) is a newer RESTful protocol that is well adapted to the Atom syndication format.

Processing Annotations with XPointer

How the annotations are processed and consumed is only limited by the requirements of a specific application and the imagination of the developers writing it. For example, an application can read both the annotation document and the target CDA document and overlay the annotations on top of the entries in the CDA document while displaying the latter in a web browser. Another example is the enforcement of privacy policies and preferences prior to exchanging the CDA document. The issue that will be raised is how to process the XPointer fragment identifiers. XPointer uses XPath which is a well established XML addressing mechanism supported by many XML processing APIs across programming languages. For those of you who use XSLT2 to process CDA documents, there is the open source XPointer Framework for XSLT2 for use with the Saxon XSLT2 engine.

Toward Intelligent Health IT (iHIT) Systems: Getting Out of the Box

In this post, I describe a new type of application that I refer to as iHIT. iHIT stands for Intelligent Health IT.

The Architecture of Traditional Health IT systems

Traditional software architectures for health IT systems typically include the following:

• Dependency Injection (DI)
  
  
• Object Relational Mapping (ORM)
  
  
• An architectural pattern for the presentation layer such as the Model View Controller (MVC) pattern
  
  
• HTML5, CSS3, and a JavaScript library like JQuery/Mobile
  
  
• Other architectural patterns including GoF Design Patterns, SOLID Principles, and Domain Driven Design (DDD)
  
  
• Structured Query Language (SQL)
  
  
• Enterprise Integration Patterns (EIPs) implemented through an Enterprise Service Bus (ESB) using HL7 messages as the "Published Language"
  
  
• REST or SOAP-based web services.
  

An entire generation of developers has been trained in these techniques. They represent proven best practices accumulated over several decades of object-oriented design and relational data management. Although pervasive in today's clinical systems, these applications lack basic intelligent features such as the ability to capture and execute expert knowledge, make inferences, or make predictions about the future based on the analysis of historical data. Some of these systems actually look like glorified data entry systems.

With the availability and explosion of medical knowledge and real world observational EHR data, these intelligent features will become important in assisting clinicians in the medical decision making process at the point of care by reducing their cognitive load.

Intelligent Health IT (iHIT) Systems

iHIT systems process huge quantities of both structured and unstructured data to provide clinicians with specific recommendations. iHIT systems play an important role in translating Comparative Effectiveness Research (CER) findings into clinical practice. Comparative effectiveness Research (CER), an emerging trend in Evidence Based Medicine (EBM), has been defined by the Federal Coordinating Council for CER as "the conduct and synthesis of research comparing the benefits and harms of different interventions and strategies to prevent, diagnose, treat and monitor health conditions in 'real world' settings." For example, based on the clinical profile of a patient, CER can help determine the best treatment option for breast cancer among the various options available such as: chemotherapy, radiation therapy, and surgery (Masectomy and Lumpectomy).

The following are examples of key characteristics displayed by iHIT systems:

• The ability to analyze patient data as well as very large historical observational data sets in order to make probability-based predictions about the future and recommend specific actions that can yield the best clinical outcomes given the clinical profile of a patient.
  
  
• The ability to capture and execute expert knowledge such as the medical knowledge contained in Clinical Practice Guidelines (CPGs). This includes the ability to mediate between different CPGs to arrive at a specific recommendation by merging and reconciling the medical knowledge in multiple CPGs as is the case with patients with comorbidities.
  
  
• The ability to perform automated reasoning by inferring new implicit clinical facts from existing explicit facts and by exploiting semantic relationships between concepts and entities.
  
  
• The ability to retrieve knowledge from unstructured data sources such as the biomedical research literature from sources like PubMed in order to answer clinical questions sometimes posed in natural language.
  
  
• The ability to learn over time (and hence become smarter) as the amount of processed data continues its exponential growth.
  
  
• Very fast response time to queries over very large data sets.
  

Sounds like Artificial Intelligence (AI)? I believe we are indeed witnessing the resurgence of AI and even the ideas of the Semantic Web in the healthcare industry. As healthcare costs and quality become national priorities for many countries around the world, the boundaries of computing will continue to be pushed further. Actually, some of the underlying principles of intelligent systems were originally developed decades and even centuries ago in the field of biomedical research. Williams Osler (1849-1919) famously said:

Medicine is a science of uncertainty and an art of probability.

Technologically advanced and competitive industries like financial services (e.g., credit eligibility and fraud detection), online retail (e.g., recommendation engine), and logistics (e.g., delivery route optimization) have adopted some of these technologies. Health IT developers now need to embrace them as well. This will require thinking out of the box.


The Ingredients of iHIT Systems

iHIT systems represent not one, but the integration of many different technologies. Mathematical Models, Statistical Analysis, and Machine Learning algorithms play an important role in iHIT systems. Examples include:

• Logistic Regression models
  
  
• Decision Trees
  
  
• Association Rules
  
  
• Bayesian Network
  
  
• Neural Networks
  
  
• Random Forests
  
  
• Time Series for temporal reasoning
  
  
• k-means Clustering
  
  
• Support Vector Machines (SVM)
  
  
• Probabilistic Graphical Models (PGMs) based on methods such as Bayesian networks and Markov Networks for making clinical decisions under uncertainty.
  

These algorithms can be used not only for making therapeutic predictions (e.g., the future hospitalization risk of a patient with Asthma), but also for dividing a population into subgroups based on the clinical profile of patients in order to achieve the best treatment outcomes.

Clinical Practice Guidelines (CPGs) are usually-based on Systematic Reviews (SRs) of Randomized Controlled Trials (RCTs) which are essentially scientific experiments. According to a report titled "Clinical Practice Guidelines (CPGs) We Can Trust" which was published last year by the Institute Of Medicine (IoM):

However, even when studies are considered to have high internal validity, they may not be generalizable to or valid for the patient population of guideline relevance. Randomized trials commonly have an under representation of important subgroups, including those with comorbidities, older persons, racial and ethnic minorities, and low-income, less educated, or low-literacy patients. Many RCTs and observational studies fail to include such "typical patients" in their samples; even when they do, there may not be sufficient numbers of such patients to assess them separately or the subgroups may not be properly analyzed for differences in outcomes.

On the other hand, observational studies using statistical analysis and machine learning algorithms operate on large real world observational data and can therefore provide feedback on the effectiveness of the actual use of different therapeutic interventions. Although very costly, RCTs are still considered the strongest form of evidence in EBM. Despite their inherent methodological challenges (lack of randomization leading to possible bias and confounding), observational studies are increasingly recognized as complementary to RCTs and an important tool in clinical decision making and health policy. iHIT systems play an important role in translating Comparative Effectiveness Research (CER) findings into clinical practice in the form of clinical decision support (CDS) interventions at the point of care.

iHIT systems also use business rules engines to capture and execute expert knowledge such as the medical knowledge contained in Clinical Practice Guidelines (CPGs). Examples include rules engines based on forward chaining inference, also known as production rule systems. These rules engines can be combined with Complex Event Processing (CEP) and Business Process Management (BPM) for intelligent decision making.

iHIT systems support ontologies such as those represented by the web ontology language (OWL) providing reasoning capabilities as well as the ability to navigate semantic relationships between concepts and entities.

More advanced iHIT systems have Natural Language Processing (NLP) and Automatic Speech Recognition (ASR) capabilities in order to answer clinical questions posed in natural language. They rely on Information Retrieval techniques like probabilistic methods for scoring the relevance of a document given a query and the application of supervised machine learning classification methods such as decision trees, Naive Bayes, K-Nearest Neighbors (kNN), and Support Vector Machines (SVM).

In some cases, the responsibilities of an iHIT system are performed by Intelligent Agents which are autonomous entities capable of observing the clinical environment and acting upon those observations.

For scalability and performance, iHIT systems often sit on NoSQL databases and run on massively parallel computing platforms like Apache Hadoop while leveraging the elasticity of the cloud.

Integrating these technologies is the main challenge posed by iHIT systems. An example is the integration between statistical and machine learning models, business rules, ontologies, and more traditional forms of computing such as object-oriented programming. Various solutions to these challenges have been proposed and implemented.

Human-Centered Design

Finally, iHIT systems fully embrace a human-centered design approach. They provide a seamless integration between automated decision logic and clinical workflows. They provide the clinician with detailed explanations of the rationale behind the actions they recommend. In addition, they use techniques like Visual Analytics to enhance human cognitive abilities in order to facilitate analytical reasoning over very large data sets.

The New Economics of Healthcare and What It Means for Health IT

Healthcare expenditures represented 17.6% of US GDP in 2009 and continue to rise. In a recently released report titled "Therapy or Surgery? A Prescription for Canada's Health Systems", Don Drummond, former chief economist at TD Bank warned that "assuming total program spending and revenues grow at the nominal GDP growth rate of 4 percent, healthcare would comprise 80 percent of the Ontario budget by 2030, up from 46 percent today."

To address quality and costs challenges, the concept of a value-based healthcare system is gaining significant ground. Articles on the subjects have recently appeared in prestigious publications such as the New England Journal of Medicine (NEJM) and Health Affairs. There is no clear consensus among industry experts that initiatives such as the Accountable Care Organization (ACO) and the Patient Centered Medical Home (PCMH) will lead to dramatic improvements in quality and costs reductions. However, everyone seems to agree that the ultimate goal of a healthcare system should be to maximize positive patient health outcomes per dollar spent.

Measuring Healthcare Value

Michael Porter is arguably the leading thinker on the subject of healthcare value. In an article titled "What Is Value in Health Care?" that appeared in the New England Journal of Medicine, he wrote:

"Value should always be defined around the customer, and in a well-functioning health care system, the creation of value for patients should determine the rewards for all other actors in the system."

Current process measures and the regulatory requirements to report them are necessary but not sufficient. It seems like the healthcare industry has escaped the business process reengineering and quality improvement movements that have permeated many industries in the nineties. Fortunately, thanks to the hard work of visionary leaders like Donald Berwick, former Administrator of the US Centers for Medicare & Medicaid Services (CMS) and co-founder of the Institute for Healthcare Improvement (IHI), quality measures reporting is now an essential component of incentive programs such as Meaningful Use and the ACO model. Healthcare transformation during the next few years will be focused on the migration from a paradigm based on the volume of services delivered to one that is based on measuring value (patient-centered outcomes) as well as the total costs incurred throughout the care cycle to achieve those outcomes.

Patient-centered outcome measures include essential metrics such as mortality, functional status, time to recovery, severity of side effects, and remission (e.g. depression remission at six and twelve months). These measures should take into account the values, goals, and wishes of the patient. Therefore patient-centered outcome should also include the patient's own evaluation of the care received. One important implication of this shift from fee-for-service to value is the growing importance of wellness, prevention, early screening, and disease and population management. In short, the elimination of waste and the optimization of healthcare delivery through the standardization of care pathways and treatment protocols based on the latest scientific evidence will become a top priority.


Measuring Healthcare Costs

The total costs incurred throughout the care cycle represent the assets used to achieve those outcomes such as: employees, consumables, facilities, medical devices, equipment, energy, and computing resources such as software and hardware. Measuring these costs would appear intuitive and straightforward at first. However, in the US healthcare system, Medicare reimbursement is based not on the actual usage of resources, but on so called relative value units (RVUs). Service charges are calculated based on formula that includes three RVUs: one for physician work, one for practice expense, and one for malpractice expense. Similar reimbursement schemes are used in other developed countries as well.

In an article titled "The Big Idea: How to Solve the Cost Crisis in Health Care", Michael Porter and Robert Kaplan proposed time-driven activity-based costing (TDABC) as a more accurate methodology for measuring costs in healthcare. Bundled Payment (using episodes of care as a basis for payment and value measurement) is emerging as a solution to contain healthcare costs.


Implications for Healthcare Information Technology

The trend toward bundle payments and other cost containment schemes will put an increasing pressure on providers to maximize the value of the assets involved in the care cycle. This will be achieved by optimizing the decision making process with software that can analyze large data sets and make specific and accurate recommendations faster than humanely possible.

In the clinical domain in particular, the following are examples of health IT solutions that will make a big difference in maximizing value for patients:

• Automated execution of Clinical Practice Guidelines (CPGs), Care Pathways (CPs), and treatment protocols using technologies such as business rules, predictive analytics, and Business Process Management (BPM).
  
  
• Creation of disease registries as well as secondary use of EHR data to track patient outcomes, compliance with CPGs, Comparative Effectiveness Research (CER), and Patient-Centered Outcome Research (PCOR). Advanced analytics will play an important role in providing important insights into clinical data on the effectiveness of various treatment options based on the clinical profile of a specific patient or subpopulation of patients. Personalized Medicine leveraging advances in genomics will play an important role here as well. This will require computing power to handle the large data sets involved in making clinical decisions based on genomic data.
  
  
• Applications of Knowledge Representation, Reasoning, Natural Language Processing (NLP), Speech Recognition, Information Retrieval, and Machine Learning to enable next generation Clinical Question Answering (CQA).
  
  
• Clinical Knowledge Management (CKM) to support a learning health system. The Institute of Medicine (IOM) released a report earlier this year titled "Digital Infrastructure for the Learning Health System: The Foundation for Continuous Improvement in Health and Health Care". The report describes the learning health system as:
  
  

  "delivery of best practice guidance at the point of choice, continuous learning and feedback in both health and health care, and seamless, ongoing communication among participants, all facilitated through the application of IT."

  
  
  
• Social Health Enterprise tools that allow clinicians to communicate and collaborate beyond email.
  
  
• Leveraging mobile devices and tablets to provide information and cognitive support to clinicians, patients, and care givers while enforcing strict security.
  
  
• Healthcare interoperability standards. As Doug Fridsma, Director of the Office of Standards and Interoperability puts it in a recent blog post: "standards are not optional". Standardization at the data, security, and transport level is necessary. However, care should be taken to ensure that these standards can be widely implemented by health IT vendors. Adopting healthcare profiles of cross-industry standards and creating Open Source reference implementations using the tools and techniques developers are familiar with (as was done by the ONC-sponsored Direct Project) can help meet that objective.
  
  On the other hand, over-standardization in areas that are going through a rapid rate of technological innovation could have a negative impact.
  
  
• Applications of human factors research to enable the effective use of technology in clinical settings. Examples include: implementation of usability guidelines to reduce alert fatigue in clinical decision support (CDS) and the use of speech recognition, checklists, simulation, Visual Analytics, and disease-specific documentation templates or Smart Forms.
  
  There are many lessons to be learned from other mission-critical industries that have adopted automation. Following several incidents and accidents related to the introduction of the "Glass Cockpit" about 25 years ago, human factors training known as Cockpit Resource Management (CRM) is now standard practice in the aviation industry.
  
  
• Lastly, Cloud Computing and Service-Oriented Architecture (SOA) will allow health enterprises to reduce costs and share computing resources while focusing on their core competency: medical care.
  

Thoughts on the Query Health Initiative

I have been following the Query Health Initiative of the ONC Standards and Interoperability Framework with great interest. The following are key goals of the Query Health Initiative:

• Identify standards and services for distributed population health queries to EHRs, HIEs, and other clinical data sources such as registries.
  
  
• Define a framework to allow partners to create their own distributed query networks (with or without intermediaries called "Network Data Partners"). I believe that the solution should not mandate a specific implementation in order to foster innovation in the field.
  
  
• Support a number of use cases such as quality measures reporting, public health surveillance, comparative effectiveness research (CER), and patient centered outcome research (PCOR).
  
  
• Support queries over a common and extensible Clinical Information Model (CIM).
  
  
• Support security, audit trails, privacy, patient consent directives, and other policy and legal requirements. Techniques such as the de-identification of data will be essential to maintaining privacy.
  
  
• Create a solution that can be implemented with a financially sustainable model. I think there are many lessons to be learned here from failed or struggling Health Information Exchange (HIE) initiatives.
  

The Query Health Initiative supports a distributed model as a opposed to a centralized model. This allows data to be kept in the originating systems and securely queried and aggregated.

Previous initiatives to create such a distributed query health network include:

• i2b2 (Informatics for Integrating Biology and the Bedside) and SHRINE (Shared Health Research Information Network) - a scalable informatics framework that will enable clinical researchers to use existing clinical data as well as genomic data for research and discovery.
  
  
• hQuery - an open source project by MITRE which leverages the ability of certified EHRs to produce C32 or CCR documents. hQuery is based on a MongoDB document database and uses JavaScript Map and Reduce functions.
  
  
• PopMedNet – a multi-purpose distributed networks for secondary use of EHR, administrative, claims, and registry data.
  

In addition, large health enterprises are investing considerable efforts and resources in building clinical data warehouses and analytics capabilities for their own internal needs. Examples are the Enterprise Data Trust at Mayo Clinic and the STRIDE (Stanford Translational Research Integrated Database Environment) project at Stanford University. These existing systems may have to eventually participate in distributed population health query networks. Most of these systems are based on SQL databases which have reached a high level of maturity in terms of scalability, performance, and the availability of data processing and analytics techniques and tools.

However, NoSQL and alternatives based on Big Data Analytics (e.g. Hadoop and Hive) are currently making significant inroads into the enterprise. Emerging NoSQL databases include key-value stores, document databases, graph databases, and triple stores such as those based on the SPARQL query language for RDF. In some cases, these NoSQL databases provide superior scalability when compared to SQL databases. They are increasingly popular with developers because they simplify the application development process by eliminating the need for Object Relational Mapping (ORM). For example, in document-oriented databases such as MongoDB (which is used in hQuery), objects are persisted as JSON documents.

So, I believe that the technical choices that are made for the Query Health Initiative should be grounded in that current reality of enterprise data management.

1. First, I think that queries should be formulated in a declarative as a opposed to a procedural manner. This rules out an approach based on JavaScript.
   
   
2. Second, I believe that queries should be formulated in an established query language. By established query language, I mean a standard like SQL, SPARQL, or XQuery that was design specifically for the purpose of querying data stores. This rules out standards such as the HL7 Health Quality Measures Format (HQMF) or any implementation of the HL7 CDA. In fact, quality measures reporting is just one of many use cases in Query Health. In my opinion, in a value-based healthcare system, patient-centered outcome measurement is even more important than quality measures which are essentially process measures and do not necessarily correlate with improved patient outcomes.
   
   By the way, I believe this same principle should extend to other ONC Standards and Interoperability efforts such as the Data Segmentation Initiative which is trying to define an interoperable approach to implementing privacy policies, consent directives, and authorizations. The Data Segmentation Initiative should embrace the approach taken by the OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) which consists in defining healthcare profiles for well established and recognized standards such as SAML, XACML, and WS-Trust. This contrasts with an approach that would consist in creating a CDA implementation for patient consent directives. This discussion on patient consent directives is relevant to the Query Health Initiative.
   
   i2b2 which is one of the projects considered by the Query Health Initiative uses SQL. i2b2 is a well engineered, robust, and proven architecture. The i2b2 data model is based on the "star schema" which has a central "fact" table where each row represents an observation about a patient. The current implementation of the clinical research chart (CRC) in i2b2 is based on the Oracle and Microsoft SQL Server databases.
   
   The maturity of SQL-based tools could be a deciding factor.
   
   
3. Third, the adopted solution should leave the door open to innovation, by giving participants the choice of embracing alternative and emerging solutions such as SPARQL or UnSQL, a newly proposed query language for NoSQL document databases. Erik Meijer and Gavin Bierman from Microsoft Research wrote a paper titled "A co-Relational Model of Data for Large Shared Data Banks" where they propose a new common query language for both SQL and noSQL databases called coSQL.
   

In the era of Clinical Question Answering (CQA), Natural Language Processing (NLP) and ontologies will play a critical role in clinical data repositories. SPARQL-based queries when combined with the use of ontologies could offer significant advantages over traditional SQL-based systems (see my previous post titled "Why do we Need Ontologies in Healthcare Applications"). Furthermore, standard vocabularies (such as SNOMED CT) and value sets are essential components of clinical data repositories. These terminologies are often derived from ontologies, so a solution that integrate well with ontologies will be important. I believe that the CTS2 specification satisfies all the vocabulary and value set requirements for Query Health. CTS2 is also currently being implemented by commercial vocabulary tool vendors and various open source projects.

The W3C R2RML (RDB to RDF mapping language) specification allows existing applications to provide an RDF view other relational databases. The SPARQL 1.1 query language supports key Query Health requirements such as aggregates, grouping, and subqueries, while the SPARQL 1.1 Federation Extensions specification supports federated queries.

The Translational Medicine Ontology is designed as a unifying ontology for the integration of EHR, genomic, treatment, drug, and other types of clinical data. This allows the creation of knowledge bases that can be queried with SPARQL to answer important questions related to clinical research as well as patient care. If you are interested in this topic, I highly recommend these two papers:

• The Translational Medicine Ontology and knowledge Base: driving personalized medicine by bridging the gap between bench and bedside
  
  
• A journey to Semantic Web query federation in the life sciences.
  

Why Do We Need Ontologies in Healthcare Applications

There is an ongoing thread in the HL7 mailing list about "what can OWL do?" in the wake of Grahame Grieve's recent post titled: "HL7 needs a fresh look because V3 has failed".

This post is my answer to "what can OWL do?".


Ontology vs. Information Model

Ontologies are our conceptualization (understanding) of the world while information models (of data structures) describe and constrain how the data is stored and transmitted in messages. Thomas Gruber popularized the notion of ontology in the nineties when he wrote in a paper titled "A Translation Approach to Portable Ontology Specifications":

A conceptualization is an abstract, simplified view of the world that we wish to represent for some purpose. Every knowledge base, knowledge-based system, or knowledge-level agent is committed to some conceptualization, explicitly or implicitly.

An ontology is an explicit specification of a conceptualization. The term is borrowed from philosophy, where an ontology is a systematic account of Existence. For knowledge-based systems, what "exists" is exactly that which can be represented.

When people ask me to explain how ontologies are relevant to healthcare, I often use this quote from a report titled "Semantic Interoperability Deployment and Research Roadmap" by Alan Rector, an authority in the field of biomedical ontologies:

Ontologies are about the things being represented – patients, their diseases. They are about what is always true, whether or not it is known to the clinician. For example, all patients have a body temperature (possibly ambient if they are dead); however, the body temperature may not be known or recorded. It makes no sense to talk about a patient with a "missing" body temperature.

Data structures are about the artefacts in which information is recorded. Not every data structure about a patient need include a field for body temperature, and even if it does, that field may be missing for any given patient. It makes perfect sense to speak about a patient record with missing data for body temperature.

Hence, at the practical level, ontologies can help us verify the soundness of statements in messages based on our conceptualization of the world. Information models in healthcare often take the form of an XML schema, a Schematron schema, or a relational database schema. One distinguishing characteristic of ontologies is that they are based on an Open World Assumption (OWA) which is based on the AAA slogan or Anyone can say Anything about Any topic. Statements that are not included in an ontology are considered unknown as opposed to false. In contrast, information models of data structures such as XML messages and relational databases are based on a Closed World Assumption (CWA) which holds that any statement that is not known to the message or database to be true is false (this is also referred to as "negation as failure" or NF).

The OWA principle recognizes that our understanding of the world is incomplete, evolving, and that new knowledge can be discovered and added at any time. To return to Alan Rector's example, one cannot assume that because there is no mention of a patient's body temperature in an electronic health record message, that the patient does not have a body temperature. Another distinguishing characteristic of ontologies is the Nonunique Naming Assumption as opposed to the Unique Name Assumption (UNA) in CWA-based systems. People do use different labels to represent the same concept. This discussion of OWA vs. CWA is not just academic. The reality is that data about a patient can exist in multiple systems, organizations, jurisdictions, and even countries using different vocabularies and XML data structures. Concepts such as longitudinal or lifelong health record and medication reconciliation will soon reveal the limits of healthcare systems based on a CWA.

OWL2, a W3C Recommendation, is an expressive ontology language and provides reasoning and inferencing capabilities to software applications. Logical axioms specify restrictions through property domains and ranges. OWL2 also support negation and disjunction. OWL2 reasoning capabilites can be enhanced with a rule language such as the Semantic Web Rule Language (SWRL). Given the complexity and scale of medical knowledge today, the use of ontology-based reasoning will become essential in applications such as medical terminologies, clinical knowledge management for automated decision support, and even automatically verifying the accuracy of messages exchanged between healthcare applications.

Unfortunately, ontologies are not widely used in software engineering today. They are not well understood by the majority of developers. Undergraduate computer science programs don't usually teach ontologies. There is an urgent need to educate a new generation of ontology-savvy healthcare application developers.


Model Consistency

For obvious reasons, healthcare applications require a high degree of model quality and consistency. This is not always possible or easy to do with traditional approaches such as object-oriented design (the HL7 RIM is based on the UML) and data structures such as XML and relational database schemas.

A clear and clean separation of concerns is needed between the semantic model (the ontology) and the information model (the model of how the data is structured in an XML message or the health application's data store). The ontology can be used to verify that the content of a message is accurate in regard to our conceptualization of the world, while the information model is used to validate the data structure in the data stores and XML messages exchanged with other applications.

The HL7 RIM is definitely not an ontology and has been plagued by consistency issues. Futhermore, a consequence of the RIM model refinement process that is used to derive XML message exchange schemas from the RIM is that data structure concerns have leaked into what was touted as the semantic model. This lack of separation of concerns has led to an unwieldy information model and very complex XML message structures (in the CDA and other V3 messages) that are difficult to learn and implement in software applications. The GreenCDA is a possible answer to the message structure simplification challenge (see my previous post on the Greening of the HL7 CDA). However, it is not enough to solve the semantic interoperability challenge.


Ontologies and Medical Terminologies

In a paper titled "Why Do It the Hard Way? The Case for an Expressive Description Logic for SNOMED", Alan Rector and Sebastian Brandt argued in favour of using the OWL ontology language for SNOMED which is currently based on a Description Logic semantics known as EL++. The availability of computing power (particularly the elasticity and massive scalability of the cloud), reasoners, and tools have now made such a migration possible.

In a recent paper published in the Journal of the American Medical Informatics Association (JAMIA) and titled "Getting the foot out of the pelvis: modeling problems affecting use of SNOMED CT hierarchies in practical applications" (subscription required), Alan Rector, Sam Brandt, and Thomas Schneider used an OWL representation of SNOMED CT to unearth errors in SNOMED CT hierarchies for such common conditions as myocardial infarction, diabetes, and hypertension. This has significant practical implications for the use and interpretation of SNOMED codes in electronic health records (EHRs), post-coordination, and queries in software applications.

ICD-11 is being developed using OWL to allow consistency checking and linking to other biomedical terminologies and ontologies.

In addition to OWL, the Simple Knowledge Organization System (SKOS) specification can also used to represent thesauri, classification schemes, taxonomies, controlled vocabularies, and other concept schemes.


Overlap between the HL7 RIM and SNOMED CT

HL7 V3 messages like the CDA typically carry codes from SNOMED CT and other terminologies such as CPT, ICD9, and LOINC. However in certain cases such as family history, an observation can be expressed through a single SNOMED CT code or by using the RIM. To ensure model consistency, HL7 has released an implementation guide on using SNOMED CT in HL7 Version 3 documents such as the HL7 CDA (I refer to this implementation guide as Terminfo). In addition, HITSP C80 specifies vocabularies and terminologies to be used in various sections of a C32 document.

However, these guidelines have been difficult to enforce in practice due to the lack of automated validation tools. In a paper recently published in the Journal of Biomedical Semantics titled "Semantic validation of the use of SNOMED CT in HL7 clinical documents", Stijn Heymans, Matthew McKennirey, and Joshua Phillips described an approach using OWL ontologies to automatically validate Terminfo guidelines. The approach consisted in using the OWL representation of SNOMED CT, lifting (with XSLT) CDA XML instances into OWL individuals based on a CDA OWL ontology, and by expressing Terminfo guidelines as OWL integrity constraints. The latter were validated with the Pellet Integrity Constraint validator or Pellet-ICV.


Clarifying the relationship ("interface") between Ontologies, Coding Systems, and Information Models

I mentioned the need for a clean separation of concerns between the ontology and the information model. So what is the relationship between ontologies, coding systems (like SNOMED CT), and information models? I have long been intrigued by that question. In a paper titled "Binding Ontologies & Coding systems to Electronic Health Records and Messages", Alan Rector, Rahil Qamar, and Tom Marley write:

We contend that codes are also data structures – or more precisely symbols to be used in data structures – and that the model of codes is also at the level of the information model.

Although coding systems are derived from ontologies, we also need a separation of concerns between the coding system and the ontology. Remember that ontologies are based on an "Open World Assumption" (which means essentially that Anyone can say Anything about Any topic or the AAA slogan). Coding systems in contrast contain an enumerated list of codes to choose from.

In the same paper, the authors propose a code binding interface based on OWL DL between the model of meaning (i.e., the ontology), the model of codes (i.e., the terminology) and the information model.

To summarize our findings so far:

1. We first create an ontology to describe our conceptualization (or understanding) of the world.
2. We derive an enumerated list of codes called code system (itself a data structure) from the ontology.
3. We used the codes in EHR applications databases and messages which are data structures.
4. We can validate the binding between the ontology, the information model, and the code system (using the approach proposed by Alan Rector, Rahil Qamar, and Tom Marley).

Ontology Alignment

An ontology represents a specific world view that reflects the perspective of its origin (application, domain, people, or organization). Alignment consists in mapping concepts across ontologies. For example, in translational medicine, there could be a need to map an ontology used in biomedical research to an ontology used for clinical purposes. Several techniques can be used to achieve Ontology Alignment between two ontologies including:

• Mapping each ontology to a third shared ontology called a foundational ontology
• Mapping the two ontologies directly.

OWL facilitates ontology alignment through constructs such as owl:sameAs, owl:equivalentClass, and owl:equivalentProperty. These OWL constructs can be enhanced with a rule-based mapping using SWRL or RIF constructs. XSLT and SPARQL can also be useful in Ontology Alignment.


Clinical Knowledge Management (CKM)

Ontologies as knowledge representation formalism are well suited for modeling the medical knowledge contained in Clinical Practice Guidelines (CPGs) and Care Pathways (CPs). This enables automated reasoning and the execution of those guidelines based on patient data at the point of care.

Several ontology-based approaches to modelling CPGs and CPs have been proposed in the past including PROforma, HELEN, EON, GLIF, and SAGE. However, the lack of tooling has been a major impediment to a wide adoption of those standards. OWL has the advantage of being a widely implemented W3C Recommendation with available open source as well as commercial tools.


Ontologies and Enterprise Master Data Management (MDM)

As healthcare enterprises become larger and integrated (through the ACO model for example), there will be the need to consistently define and manage core business entities such as "patient", "provider", "payor", "care delivery", and "claim" across systems and business processes (e.g. research, clinical, reporting, and financial). The goal of Master Data Management (MDM) is to address those challenges.

One area of particular interest to MDM is the naming, meaning, equivalency, and relationships between those core business entities. Ontology constructs such as owl:sameAs, owl:equivalentClass, and owl:equivalentProperty can help establish common semantics across the enterprise when the same business entity is called by different names in different systems and business processes.


Linked Open Data (LOD)

Ontologies can help in building silo-busting applications that need to link data items (datum) to other data items (as opposed to web page to web page) over the web in order to perform entity correlation (or entity resolution). A datum can be a row in a relational database and technologies exist to provide an RDF view over a relational database table (see the R2RML: RDB to RDF Mapping Language). The RDF view itself can be defined in terms of an OWL ontology or RDFS vocabulary. Hence, LOD can integrate data across health applications and organizations by providing a semantic layer on top of existing applications.

The Linked Data design pattern is based on an open world assumption, uses dereferenceable HTTP URIs for identifying and accessing data items, RDF for describing metadada about those items, and semantic links to describe the relationships between those items. Other standards used in LOD applications include RDFS (for describing RDF vocabularies) and SQARQL (for querying RDF graphs). A practical application of LOD in healthcare is the Clinical Quality Linked Data project on health.data.gov.


Metadata and the PCAST Report

The Office of the National Coordination for Health Information Technology (ONC) recently released an Advance Notice of Proposed Rulemaking (ANPRM) on Metadata Standards to Support Nationwide Electronic Health Information Exchange. The ANPRM was driven by the PCAST Report released in December 2010.

Specifically, the ANPRM called for public comments on patient identity, provenance, and privacy. There are existing ontologies related to identity, provenance, and privacy that can be at least partially reused (ontology reuse is a recommended best practice to avoid the difficulties of ontology alignment). An example is the Provenance Vocabulary Core Ontology. Modeling metadata in healthcare using ontologies will enable reasoning, data integration through Linked Open Data mechanisms, and federated SPARQL queries. Please note that metadata expressed in XML syntax can be lifted into RDF (using techniques like XSLT or XQuery) to provide the same benefits.

Service-Oriented Clinical Decision Support in the Cloud

This is the presentation I gave today at the 2011 SOA In Healthcare Conference in Herdnon, VA.

Service-Oriented CDS in the Cloud

View more presentations from Joel Amoussou

How Checklists Can Enhance Clinical Decision Support (CDS)

I have been reading "The Checklist Manifesto", a book written by Dr. Atul Gawande on the effectiveness of checklists in healthcare delivery. Another paper recently published in the Milbank Quarterly entitled "Counterheroism, Common Knowledge, and Ergonomics: Concepts from Aviation That Could Improve Patient Safety" suggests that beyond checklists, proven aviation safety practices such as Cockpit Resource Management (CRM), Joint safety briefings, and first-names-only rules could help improve patient safety.

I first became aware of the importance of checklists while I was being trained as a Flight Engineer. I spent a lot of time studying them carefully as an aviation student. Checklists are used during normal, abnormal, and emergency situations and pilots go through practical exercises in flight simulators to use them correctly. Let's not mince words: aviation as we know it today would not be possible without checklists.

In a study entitled "Missed and Delayed Diagnoses in the Emergency Department: A Study of Closed Malpractice Claims From 4 Liability Insurers", researchers found that:

The leading breakdowns in the diagnostic process were failure to order an appropriate diagnostic test (58% of errors), failure to perform an adequate medical history or physical examination (42%), incorrect interpretation of a diagnostic test (37%), and failure to order an appropriate consultation (33%). The leading contributing factors to the missed diagnoses were cognitive factors (96%), patient-related factors (34%), lack of appropriate supervision (30%), inadequate handoffs (24%), and excessive workload (23%).

Checklists can serve as cognitive aid in helping clinicians do their job safely. While the idea of using checklists and standard operating procedures has been fully embraced and adopted by aviation professionals for more than 70 years, it is only now making inroads into the field of medicine particularly in high pressure environments like intensive care units. The use of checklists in medicine has already shown the potential to save patients live and reduce human errors. However, the main challenge remains the acceptance of checklists by clinicians concerned about "Cookbook Medicine".

Checklists are just cognitive aids and the presence of an experienced and competent professional will always make a big difference in critical situations. As Captain Sullenberger (the airline pilot who successfully ditched US Airways Flight 1549 in the Hudson River in New York City, on January 15, 2009) said, "One way of looking at this might be that for 42 years, I've been making small, regular deposits in this bank of experience: education and training. And on January 15 the balance was sufficient so that I could make a very large withdrawal."

On modern airplanes, Electronic Centralised Aircraft Monitor (ECAM) systems or Engine Indicating and Crew Alerting Systems (EICAS) monitor aircraft systems and engines and displays messages in case of failure, as well as recommended remedial actions in the form of checklists. The National Transportation Safety Board (NTSB) accident report on US Airways Flight 1549 indicates that the First Officer "was able to promptly locate the [Engine Dual Failure checklist] procedure listed on the back cover of the [Quick Reference Handbook] QRH, turn to the appropriate page, and start executing the checklist."

In medicine, factors such as comorbidity can complicate the design of effective CDS. However, with the explosion of medical knowledge and evidence-based guidelines, CDS will become an essential tool in healthcare delivery. The design, development, implementation, and use of CDS is knowledge-intensive and require an effective collaborative knowledge management strategy. The challenge will be to integrate checklists into the different CDS modalities such as context-sensitive Infobuttons, order sets, alerts, reminders, data entry and visualization, and clinical workflows.

For example, the evaluation results (in the form of recommendations) of a CDS rule can be presented to the clinician as an electronic checklist. This in turn can be tied directly to quality measures in the era of Meaningful Use, Pay-For-Performance, and Accountable Care Organizations (ACOs). An interesting example would be a checklist that prompts clinicians to generate detailed discharge instructions to satisfy quality measures for patients with heart failure or acute myocardial infection.

There is an important Human Factors aspect to the design and use of cockpit checklists and flight-deck procedures. This has been the subject of advanced research at NASA Ames Research Center more than twenty years ago and the results have been widely disseminated and implemented in the aviation industry.

In an article entitled "The Checklist" published in the New Yorker, Atul Gawande wrote:

"But consider: there are hundreds, perhaps thousands, of things doctors do that are at least as dangerous and prone to human failure as putting central lines into I.C.U. patients. It’s true of cardiac care, stroke treatment, H.I.V. treatment, and surgery of all kinds. It’s also true of diagnosis, whether one is trying to identify cancer or infection or a heart attack. All have steps that are worth putting on a checklist and testing in routine care. The question—still unanswered—is whether medical culture will embrace the opportunity."

Peter Pronovost, an intensivist at Johns Hopkins Hospital and pioneer in the use of checklist in medicine, implemented a checklist at 127 Michigan intensive care units (ICUs) to reduce catheter-related blood stream infections (CRBSI). The project was so successful that it is estimated that it could significantly reduce the 28,000 deaths and 3 billion dollars in costs caused by these hospital-acquired infections.

The HL7 Clinical Decision Support (CDS) workgroup is working on standards for the vMR (Virtual Medical Record), Infobuttons, and Order Sets. There is also an effort at the OMG to publish a Clinical Decision Support Services specification for service-oriented CDS capabilities. The Flight Operation Interests Group (FOIG) of the Air Transport Association (ATA) is developing a data model and XML Schema for flight deck procedures and checklists. Developing a shareable content model for checklists in medicine could be an interesting idea.