Toward a Reference Architecture for Intelligent Systems in Clinical Care

A Software Architecture for Precision Medicine

Intelligent systems in clinical care leverage the latest innovations in machine learning, real-time data stream mining, visual analytics, natural language processing, ontologies, production rule systems, and cloud computing to provide clinicians with the best knowledge and information at the point of care for effective clinical decision making. In this post, I propose a unified open reference architecture that combines all these technologies into a hybrid cognitive system for clinical decision support. Indeed, truly intelligent systems are capable of reasoning. The goal is not to replace clinicians, but instead to provide them with cognitive support during clinical decision making. Furthermore, Intelligent Personal Assistants (IPAs) such as Apple's Siri, Google's Google Now, and Microsoft's Cortana have raised our expectations on how intelligent systems interact with users through voice and natural language.

In the strict sense of the term, a reference architecture should be abstracted away from concrete technology implementation. However in order to enable a better understanding of the proposed approach, I take liberty in explaining how available open source software can be used to realize the intent of the architecture. There is an urgent need for an open and interoperable architecture which can be deployed across devices and platforms. Unfortunately, this is not the case today with solutions like Apple's HealthKit and ResearchKit.

The specific open source software mentioned in this post can be substituted with other tools which provide similar capabilities. The following diagram is a depiction of the architecture (click to enlarge).

 

Clinical Data Sources

Clinical data sources are represented on the left of the architecture diagram. Examples include electronic medical record systems (EMR) commonly used in routine clinical care, clinical genome databases, genome variant knowledge bases, medical imaging databases, data from medical devices and wearable sensors, and unstructured data sources such as biomedical literature databases. The approach implements the Lambda Architecture enabling both batch and real-time data stream processing and mining.

Predictive Modeling, Real-Time Data Stream Mining, and Big Data Genomics

The back-end provides various tools and frameworks for advanced analytics and decision management. The analytics workbench includes tools for creating predictive models and data streaming mining. The decision management workbench includes a production rule system (providing seamless integration with clinical events and processes) and an ontology editor.

The incoming clinical data likely meet the Big Data criteria of volume, velocity, and variety (this is particularly true for physiological time series from wearable sensors). Therefore, specialized frameworks for large scale cluster computing like Apache Spark are used to analyze and process the data. Statistical computing and Machine Learning tools like R are used here as well. The goal is knowledge and patterns discovery using Machine Learning model builders like Decision Trees, k-Means Clustering, Logistic Regression, Support Vector Machines (SVMs), Bayesian Networks, Neural Networks, and the more recent Deep Learning techniques. The latter hold great promise in applications such as Natural Language Processing (NLP), medical image analysis, and speech recognition.

These Machine Learning algorithms can support diagnosis, prognosis, simulation, anomaly detection, care alerting, and care planning. For example, anomaly detection can be performed at scale using the k-means clustering machine learning algorithm in Apache Spark. In addition, Apache Spark allows the implementation of the Lambda Architecture and can also be used for genome Big Data analysis at scale.

In another post titled How Good is Your Crystal Ball?: Utility, Methodology, and Validity of Clinical Prediction Models, I discuss quantitative measures of performance for clinical prediction models.

Visual Analytics

Visual Analytics tools like D3.js, rCharts, ploty, googleVis, ggplot2, and ggvis can help obtain deep insight for effective understanding, reasoning, and decision making through the visual exploration of massive, complex, and often ambiguous data. Of particular interest is Visual Analytics of real-time data streams like physiological time series. 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. For example, similar to Minard's map of the Russian Campaign of 1812-1813 (see graphic below), Visual Analytics can help in comparing different interventions and care pathways and their respective clinical outcomes over a certain period of time by displaying causes, variables, comparisons, and explanations.

Production Rule System, Ontology Reasoning, and NLP

The architecture also includes a production rule engine and an ontology editor (Drools and Protégé respectively). This is done in order to leverage existing clinical domain knowledge available from clinical practice guidelines (CPGs) and biomedical ontologies like SNOMED CT.  This approach complements machine learning algorithms' probabilistic approach to clinical decision making under uncertainty. The production rule system can translate CPGs into executable rules which are fully integrated with clinical processes (workflows) and events. The ontologies can provide automated reasoning capabilities for decision support.

NLP includes capabilities such as:

• Text classification, text clustering, document and passage retrieval, text summarization, and more advanced clinical question answering (CQA) capabilities which can be useful for satisfying clinicians' information needs at the point of care; and
• Named entity recognition (NER) for extracting concepts from clinical notes.

The data tier supports the efficient storage of large amounts of time series data and is implemented with tools like Cassandra and HBase. The system can run in the cloud, for example using the Amazon Elastic Compute Cloud (EC2). For real-time processing of distributed data streams, cloud-based solutions like Amazon Kinesis and Lambda can be used.

 

Clinical Decision Services

The clinical decision services provide intelligence at the point of care typically using deployed predictive models, clinical rules, text mining outputs, and ontology reasoners. For example, Machine Learning algorithms can be exported in predictive markup language (PMML) format for run-time scoring based on the clinical data of individual patients, enabling what is referred to as Personalized Medicine. Clinical decision services include:

• Diagnosis and prognosis
• Simulation
• Anomaly detection 
• Data visualization
• Information retrieval (e.g., clinical question answering)
• Alerts and reminders
• Support for care planning processes.

The clinical decision services can be deployed in the cloud as well. Other clinical systems can consume these services through a SOAP or REST-based web service interface (using the HL7 vMR and DSS specifications for interoperability) and single sign-on (SSO) standards like SAML2 and OpenID Connect.

Intelligent Personal Assistants (IPAs)

Clinical decision services can also be delivered to patients and clinicians through IPAs. IPAs can accept inputs in the form of voice, images, and user's context and respond in natural language. IPAs are also expanding to wearable technologies such as smart watches and glasses. The precision of speech recognition, natural language processing, and computer vision is improving rapidly with the adoption of Deep Learning techniques and tools. Accelerated hardware technologies like GPUs and FPGAs are improving the performance and reducing the cost of deploying these systems at scale.

Hexagonal, Reactive, and Secure Architecture

Intelligent Health IT systems are not just capable of discovering knowledge and patterns in data. They are also scalable, resilient, responsive, and secure. To achieve these objectives, several architectural patterns have emerged during the last few years:

• Domain Driven Design (DDD) puts the emphasis on the core domain and domain logic and recommends a layered architecture (typically user interface, application, domain, and infrastructure) with each layer having well defined responsibilities and interfaces for interacting with other layers. Models exist within "bounded contexts". These "bounded contexts" communicate with each other typically through messaging and web services using HL7 standards for interoperability.


• The Hexagonal Architecture defines "ports and adapters" as a way to design, develop, and test an application in a way that is independent of the various clients, devices, transport protocols (HTTP, REST, SOAP, MQTT, etc.), and even databases that could be used to consume its services in the future. This is particularly important in the era of the Internet of Things in healthcare.


• Microservices consist in decomposing large monolithic applications into smaller services following good old principles of service-oriented design and single responsibility to achieve modularity, maintainability, scalability, and ease of deployment (for example, using Docker).


• CQRS/ES: Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES) are two architectural patterns which consist in the use of event-driven messaging and an Event Store for separating commands (write-side) from queries (read-side) relying on the principle of Eventual Consistency. CQRS/ES can be implemented in combination with microservices to deliver new capabilities such as temporal queries, behavioral analysis, complex audit logs, and real-time notifications and alerts.


• Functional Programming: Functional Programming languages like Scala have several benefits that are particularly important for applying Machine Learning algorithms on large data sets. Like functions in mathematics, functions in Scala have no side effects. This provides referential transparency. Machine Learning algorithms are in fact based on Linear Algebra and Calculus. Scala supports high-order functions as well. Variables are immutable witch greatly simplifies concurrency. For all those reasons, Machine Learning libraries like Apache Mahout have embraced Scala, moving away from the Java MapReduce paradigm.


• Reactive Architecture: The Reactive Manifesto makes the case for a new breed of applications called "Reactive Applications". According to the manifesto, the Reactive Application architecture allows developers to build "systems that are event-driven, scalable, resilient, and responsive."  Leading frameworks that support Reactive Programming include Akka and RxJava. The latter is a library for composing asynchronous and event-based programs using observable sequences. RxJava is a Java port (with a Scala adaptor) of the original Rx (Reactive Extensions) for .NET created by Erik Meijer.
  
  Based on the Actor Model and built in Scala, Akka is a framework for building highly concurrent, asynchronous, distributed, and fault tolerant event-driven applications on the JVM. Akka offers location transparency, fault tolerance, asynchronous message passing, and a non-deterministic share-nothing architecture. Akka Cluster provides a fault-tolerant decentralized peer-to-peer based cluster membership service with no single point of failure or single point of bottleneck.
  
  Also built with Scala, Apache Kafka is a scalable message broker which provides high-throughput, fault-tolerance, built-in partitioning, and replication  for processing real-time data streams. In the reference architecture, the ingestion layer is implemented with Akka and Apache Kafka.

• Web Application Security: special attention is given to security across all layers, notably the proper implementation of authentication, authorization, encryption, and audit logging. The implementation of security is also driven by deep knowledge of application security patterns, threat modeling, and enforcing security best practices (e.g., OWASP Top Ten and CWE/SANS Top 25 Most Dangerous Software Errors) as part of the continuous delivery process.

An Interface that Works across Devices and Platforms

The front-end uses a Mobile First approach and a Single Page Application (SPA) architecture with Javascript-based frameworks like AngularJS to create very responsive user experiences. It also allows us to bring the following software engineering best practices to the front-end:

• Dependency Injection
• Test-Driven Development (Jasmine, Karma, PhantomJS)
• Package Management (Bower or npm)
• Build system and Continuous Integration (Grunt or Gulp.js)
• Static Code Analysis (JSLint and JSHint), and 
• End-to-End Testing (Protractor). 

For mobile devices, Apache Cordova can be used to access native functions when desired. The main goal is to provide a user interface that works across devices and platforms such as iOS, Android, and Windows Phone.

Interoperability

Interoperability will always be a key requirement in clinical systems. Interoperability is needed between all players in the healthcare ecosystem including providers, payers, labs, knowledge artifact developers, quality measure developers, and public health agencies like the CDC. These standards exist today and are implementation-ready. However, only health IT buyers have the leverage to demand interoperability from their vendors.

Standards related to clinical decision support (CDS) include:

• The HL7 Fast Healthcare Interoperability Resources (FHIR)
• The HL7 virtual Medical Record (vMR)
• The HL7 Decision Support Services (DSS) specification
• The HL7 CDS Knowledge Artifact specification
• The DMG Predictive Model Markup Language (PMML) specification.

Overcoming Barriers to Adoption

In a previous post, I discussed a practical approach to addressing challenges to the adoption of clinical decision support (CDS) systems.

Single Sign-On (SSO) for Cloud-based SaaS Applications

Single Sign-On (SSO) is a key capability for Software as a Service (SaaS) applications particularly when there is a need to integrate with existing enterprise applications. In the enterprise world dominated by SOAP-based web services, security has been traditionally achieved with standards like WS-Security, WS-SecurityPolicy, WS-SecureConversation, WS-Trust, XML Encryption, XML Signatures, the WS-Security SAML Token Profile, and XACML.

During the last few years, the popularity of Web APIs, mobile technology, and Cloud-based software services has led to the emergence of light-weight security standards in support of the new REST/JSON paradigm with specifications like OAuth2 and OpenID Connect.

In this post, I discuss the state of the art in standards for SSO.

SAML2 Web SSO Profile

SAML2 Web SSO Profile (not to be confused with the WS-Security SAML Token Profile mentioned earlier) is not a new standard. It was approved as an OASIS standard in 2005. SAML2 Web SSO Profile is still today a force to reckon with when it comes to enabling SSO within the enterprise. In a post titled SAML vs OAuth: Which One Should I Use?, Anil Saldhana, former Lead Identity Management Architect at Red Hat offered the following suggestions:

• If your usecase involves SSO (when at least one actor or participant is an enterprise), then use SAML.
• If your usecase involves providing access (temporarily or permanent) to resources (such as accounts, pictures, files etc), then use OAuth.
• If you need to provide access to a partner or customer application to your portal, then use SAML.
• If your usecase requires a centralized identity source, then use SAML  (Identity provider).
• If your usecase involves mobile devices, then OAuth2 with some form of Bearer Tokens is appropriate.

Salesforce.com who is arguably the leader in cloud-based SaaS services supports SAML2 Web SSO Profile as one of its main SSO mechanisms (see the Salesforce Single Sign-On Implementation Guide). The Google Apps platform supports SAML2 Web SSO Profile as well.

Federal Identity, Credential, and Access Management (FICAM), a US Federal Government initiative has selected SAML2 Web SSO Profile for the purpose of Level of Assurance (LOA) 1 to 4 as defined by the NIST Special Publication 800-62-2 (see ICAM SAML 2.0 Web Browser SSO Profile). This is significant given the challenges associated with identity federation at the scale of a large organization like the US federal government.

SAML bindings specify underlying transport protocols including:

• HTTP Redirect Binding
• HTTP POST Binding
• HTTP Artifact Binding
• SAML SOAP Binding.

SAML profiles define how the SAML assertions, protocols, and bindings are combined to support particular usage scenarios. The Web Browser SSO Profile and the Single Logout Profile are the most commonly used profiles.

Identity Provider (idP) initiated SSO with POST binding is one the most popular implementations (see diagram below from the OASIS SAML Technical Overview for a typical authentication flow).

The SAML2 Web SSO ecosystem is very mature, cross-platform, and scalable. There are a number of open source implementations available as well. However, things are constantly changing in technology and identity federation is no exception. At the Cloud Identity Summit in 2012, Craig Burton, a well known analyst in the identity space declared:

 SAML is the Windows XP of Identity. No funding. No innovation. People still use it. But it has no future. There is no future for SAML. No one is putting money into SAML development. No one is writing new SAML code. SAML is dead.

 Craig Burton further clarified his remarks by saying:

SAML is dead does not mean SAML is bad. SAML is dead does not mean SAML isn’t useful. SAML is dead means SAML is not the future.

At the time, this provoked a storm in the Twitterverse because of the significant investments that have been made by enterprise customers to implement SAML2 for SSO. 

WS-Federation

There is an alternative to SAML2 Web SSO Profile called WS-Federation which is supported in Microsoft products like Active Directory Federation Services (ADFS), Windows Identity Foundation (WIF), and Azure Active Directory. Microsoft has been a strong promoter of WS-Federation and has implemented WS-Federation in several products. There is also a popular open source identity server on the .NET platform called Thinktecture IdentityServer v2 which also supports WS-Federation.

For enterprise SSO scenarios between business partners exclusively using Microsoft products and development environment, WS-Federation could be a serious contender. However, SAML2 is more widely supported and implemented outside of the Microsoft world. For example, Salesforce.com and Google Apps do not support WS-Federation for SSO. Note that Microsoft ADFS implements the SAML2 Web SSO Profile in addition to WS-Federation.

OpenID Connect

OpenID Connect is a simple identity layer on top of OAuth2. It has been ratified by the OpenID Foundation in February 2014 but has been in development for several years. Nat Sakimura's Dummy’s guide for the Difference between OAuth Authentication and OpenID is a good resource for understanding the difference between OpenID, OAuth2, and OpenID Connect. In particular, it explains why OAuth2 alone is not strictly an authentication standard. The following diagram from the OpenID Connect specification represents the components of the OpenID Connect stack (click to enlarge).

Also note that OAuth2 tokens can be JSON Web Token (JWT) or SAML assertions.

The following is the basic flow as defined in the OpenID Connect specification:

1. The RP (Client) sends a request to the OpenID Provider (OP).
2. The OP authenticates the End-User and obtains authorization.
3. The OP responds with an ID Token and usually an Access Token.
4. The RP can send a request with the Access Token to the UserInfo Endpoint.
5. The UserInfo Endpoint returns Claims about the End-User.

There are two subsets of the Core functionality with corresponding implementer’s guides:

• Basic Client Implementer’s Guide –for a web-based Relying Party (RP) using the OAuth code flow
• Implicit Client Implementer’s Guide – for a web-based Relying Party using the OAuth implicit flow

OpenID Connect is particularly well-suited for modern applications which offer RESTful Web APIs,  support JSON payloads, run on mobile devices, and are deployed to the Cloud. Despite being a relatively new standard, OpenID Connect also boasts an impressive list of implementations across platforms. It is already supported by big players like Google, Microsoft, PayPal, and Salesforce.  In particular, Google is consolidating all federated sign-in support onto the OpenID Connect standard. Open Source OpenID Connect Identity Providers include the Java-based OpenAM and the .Net-based Thinktecture Identity Server v3.

From WS* to JW* and JOSE

As can be seen from the diagram above, a complete identity federation ecosystem based on OpenID Connect will also require standards for representing security assertions, digital signatures, encryption, and cryptographic keys. These standards include:

• JSON Web Token (JWT)
• JSON Web Signature (JWS)
• JSON Web Encryption (JWE)
• JSON Web Key (JWK)
• JSON Web Algorithms (JWA).

There is a new acronym for these emerging JSON-based identity and security protocols: JOSE which stands for Javascript Object Signing and Encryption. It is also the name of the IETF Working Group developing JWS, JWE, and JWK. A Java-based open source implementation called jose4j is available.

Access Control with the User Managed Access (UMA)

According to the UMA Core specification,

User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy.

In the UMA protocol, OpenID Connect provides federated SSO and is also used to convey user claims to the authorization server. In a previous post titled Patient Privacy at Web Scale, I discussed the application of UMA to the challenges of patient privacy.

Essential IT Capabilities Of An Accountable Care Organization (ACO)

The Certification Commission for Health Information Technology (CCHIT) recently published a document entitled A Health IT Framework for Accountable Care. The document identifies the following key processes and functions necessary to meet the objectives of an ACO:

• Care Coordination
• Cohort Management
• Patient and Caregiver Relationship Management
• Clinician Engagement
• Financial Management
• Reporting
• Knowledge Management.

The key to success is a shift to a data-driven healthcare delivery. The following is my assessment of the most critical IT capabilities for ACO success:

• Comprehensive and standardized care documentation in the form of electronic health records including as a minimum: patients' signs and symptoms, diagnostic tests, diagnoses, allergies, social and familiy history, medications, lab results, care plans, interventions, and actual outcomes. Disease-specific Documentation Templates can support the effective use of automated Clinical Decision Support (CDS). Comprehensive electronic documentation is the foundation of accountability and quality improvement.


• Care coordination through the secure electronic exchange and the collaborative authoring of the patient's medical record and care plan (this is referred to as clinical information reconciliation in the CCHIT Framework). This also requires health IT interoperability standards that are easy to use and designed following rigorous and well-defined software engineering practices. Unfortunately, this has not always been the case, resulting in standards that are actually obstacles to interoperability as opposed to enablers of interoperability. Case Management tools used by Medical Homes (a concept popularized by the Patient-Centered Medical Home model) can greatly facilitate collaboration and Care Coordination.


• Patients' access to and ownership of their electronic health records including the ability to edit, correct, and update their records. Patient portals can be used to increase patients' health literacy with health education resources. Decision aids comparing the benefits and harms of various interventions (Comparative Effectiveness Research) should be available to patients. Patients' health behavior change remains one of the greatest challenges in Healthcare Transformation. mHealth tools have demonstrated their ability to support Patient Activation.


• Secure communication between patients and their providers. Patients should have the ability to specify with whom, for what purpose, and the kind of medical information they want to share. Patients should have access to an audit trail of all access events to their medical records just as consumers of financial services can obtain their credit record and determine who has inquired about their credit score.


• Clinical Decision Support (CDS) as well as other forms of cognitive aids such as Electronic Checklists, Data Visualization, Order Sets, Infobuttons, and more advanced Clinical Question Answering (CQA) capabilities (see my previous post entitled Automated Clinical Question Answering: The Next Frontier in Healthcare Informatics). The unaided mind (as Dr. Lawrence Weed, the father of the Problem-Oriented Medical Record calls it) is no longer able to cope with the large amounts of data and knowledge required in clinical decision making today. CDS should be used to implement clinical practice guidelines (CPGs) and other forms of Evidence-Based Medicine (EBM).
  
  However, the delivery of care should also take into account the unique clinical characteristics of individual patients (e.g., co-morbidities and social history) as well as their preferences, wishes, and values. Standardized Clinical Assessment And Management Plans (SCAMPs) promote care standardization while taking into account patient preferences and the professional judgment of the clinician. CDS should be well integrated with clinical workflows (see my my previous post entitled Addressing Challenges to the Adoption of Clinical Decision Support (CDS) Systems).


• Predictive risk modeling to identity at-risk populations and provide them with pro-active care including early screening and prevention. For example, predictive risk modeling can help identify patients at risk of hospital re-admission, an important ACO quality measure.


• Outcomes measurement with an emphasis on patient outcomes in addition to existing process measures. Examples of patient outcome measures include: mortality, functional status, and time to recovery.


• Clinical Knowledge Management (CKM) to disseminate knowledge throughout the system in order to support a learning health system. The Institute of Medicine (IOM) released a report 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."



• 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), Checklists, and Visual Analytics. 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.

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.

Secure Cloud Computing for the Health Enterprise

Some thoughts on securing healthcare applications in the cloud.

Secure Cloud Computing for the Health Enterprise

View more presentations from Joel Amoussou.

Patient Consent: State of the Union

The viability and sustainability of an electronic health information exchange (HIE) largely depends on the trust and desire of patients to participate in the exchange. What are the laws, regulations, standards, practices, and current directions in the field of patients' privacy consents?

State and Federal Laws

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) does not require patient consent and authorization for the exchange of health information among healthcare providers for the purpose of medical care. The patient consent is implied by her general consent to be treated.

Some states have adopted heightened laws (higher than those imposed by HIPAA) that require explicit patient consent and authorization for specially-protected health information such as sexually transmitted diseases, human immunodeficiency virus tests, viral hepatitis, genetic information, substance abuse, mental health, and developmental disabilities.


Building Trust

The lack of patient trust can be a significant barrier to the implementation of a HIE. Therefore, a common practice in HIEs is to offer individual patients the opportunity to opt-out of exchanging their health information even if patient consent is not required by existing laws and regulations. Patients are notified and informed of their consent options through an outreach program.


Consent Requirements

The HHS Office of the National Coordinator (ONC) releases a Consumer Preferences Requirements Document in October 2009. The document describes consent stakeholders, functional needs, policy implications, scenarios, and processes including HIEs.


Consent Options

The ONC released a whitepaper in March 2010 entitled "Consumer Consent Options for Electronic Health Information Exchange: Policy Considerations and Analysis". The whitepaper identified the following consent options:

• No consent. Health information of patients is automatically included—patients cannot opt out;
  
  
• Opt-out. Default is for health information of patients to be included automatically, but the patient can opt out completely;
  
  
• Opt-out with exceptions. Default is for health information of patients to be included, but the patient can opt out completely or allow only select data to be included;
  
  
• Opt-in. Default is that no patient health information is included; patients must actively express consent to be included, but if they do so then their information must be all in or all out; and
  
  
• Opt-in with restrictions. Default is that no patient health information is made available, but the patient may allow a subset of select data to be included.
  

The granularity of patient consent preference can be based on the type of data, healthcare provider, time range, and intended use.


Standardization

The IHE Basic Patient Privacy Consents (BPPC) provides a mechanism to record and enforce patient consents. It complements the IHE Cross-Enterprise Document Sharing (XDS) standard by specifying how an XDS affinity domain can create privacy policies and enforce those policies through the access control mechanisms of an XDS Actor such as an EHR system. Patient consent is captured in an HL7 Clinical Document Architecture (CDA) document using a scanned document (wet signature on paper) or a digital signature.

HL7 is working on a set of specifications for the creation and use of privacy consent directives.

The Nationwide Health Information Network (NHIN) Access Consent Policies Specification is based on the eXtended Access Control Markup Language (XACML), an OASIS standard.


Health Record Banks (HRBs)

An emerging pattern is to include a Health Record Bank (HRB) containing Personal Health Records (PHRs) as a participating node in the HIE. The HRB is accessible to patients via a web portal and allows patients to exercise fine-grained control over the exchange of their health records within the HIE through a consent configuration interface.

UPDATE: On Thursday, July 8, 2010, the Department of Health and Human Services (HHS) announced proposed modifications to the HIPAA Privacy & Security Rules.