Apple’s SDK brouhaha explained for non-developers

So what’s up with Apple this week? In short, they are now the dominant platform in a space, and they intend to maintain that dominant position for as long as possible by preventing the ability to write an application once and run it anywhere. Apple’s tactics for maintaining their dominance are: bullying and complexity. They’re the same tactics use by every computer platform dominator (e.g., IBM, AT&T, and Microsoft) before them. All of this has happened before, and it will happen again. Click here for Brent Noorda's take on Apple’s SDK brouhaha.

An update (5/4/2010):

The Federal Trade Commission and the Department of Justice are exploring whether to open an antitrust inquiry into Apple over its recent actions restricting developers writing apps for its iPhone operating system.

The basis for a potential antitrust probe stems from Apple’s recent changes to its iPhone software developer kit. The changes, which were quietly rolled out during the announcement of the company’s new iPhone 4.0 operating system, made it clear that Apple would no longer allow apps into the iTunes iPhone and iPad store that are built using third-party programs.

The sudden changes to Apple’s rules came just days before Adobe was set to showcase its newest software update to its Flash authoring tools. The feature, called Packager for iPhone, would make it easy for developers to produce iPhone applications using Adobe’s software.

Decision Makers Are Not Always "Insiders"

Over the past year or so, this blog has bandied about terms like interoperability, open-source, disambiguation, security and databases. All of this has been from the points of view shared by most "insiders" concerned with the introduction of electronic health records (EHR) systems into their local, regional or even national computer networks. I'm talking about individuals (including me) who typically follow other blogs like http://i2b2-zak.blogspot.com and http://geekdoctor.blogspot.com.

However, there are many more individuals who follow (and whose thinking is influenced by) publications like The Wall Street Journal and The New York Times. What they read is reports like "In a paper published last year, Alessandro Acquisti and Ralph Gross (two researchers from Carnegie Mellon University) reported that they could accurately predict the full, nine-digit Social Security numbers for 8.5 percent of the people born in the United States between 1989 and 2003 — nearly five million individuals." that I believe are sometimes more likely to influence their thinking than are the reports that you and I read in the blogs (and other publications) written by "insiders." So, with this last thought in mind, I place the following links to a few recent articles read by many of the decision makers out there.

http://www.nytimes.com/2009/11/16/business/16records.html?_r=1&scp=4&sq=electronic%20health%20records&st=cse

http://www.nytimes.com/2010/03/17/technology/17privacy.html

http://www.nytimes.com/2010/04/13/opinion/l13privacy.html

http://online.wsj.com/article/SB10001424052748704259304575043572008622004.html

http://online.wsj.com/article/SB10001424052748703625304575116512173339800.html

http://online.wsj.com/article/SB10001424052748703580904575132111888664060.html?KEYWORDS=electronic+health+records

This is not meant to be a representative sample. Just a reminder that you and I may or may not be speaking the same language as the general public, which counts among its numbers many high-ranking decision makers. So, what else is new?

How Green Is My iPad? & Who Were The Luddites?

How Green Is My iPad?

Click here for a discussion which ends with the assertion "All in all, the most ecologically virtuous way to read a book starts by walking to your local library."

Who Were The Luddites?

Machine smashers of the 19th century or members of a fascinating social movement with visionary insights into the unfolding drama of industrialization?

The impact of today's technologies on social relations and the planet itself is becoming an intriguing field of inquiry. However so far the discussion of nuclear power, biotechnology, deforestation, automobiles or computers is pretty much dominated by industry and government who want us to take all this for granted.

In this context it is inspiring to remember the Luddites who questioned industrial civilization at its very beginning in England during the introduction of mechanized textile mills. They knew that the power-looms that they selectively destroyed were not just a technology but would create a whole new set of relations: Factory work, child labor, and the demise of artisan and skilled labor. They anticipated that the new machines, that they themselves had helped build, were not the promised tool to help them in their work but would eventually become part of a machine culture with power over human life and even human consciousness.

Click on the links below for a two part talk given by Iain Boal, an independent scholar and historian of technology. He taught a course on the Luddites at Stanford University.

Note: During the introduction, you'll hear the term Time of Useful Consciousness. This is an aeronautical term. It's the time between the onset of oxygen deficiency and the loss of consciousness, the brief moments in which a pilot may save the plane.

Part 1: http://WaldenITech.com/Luddites1.mp3

Part 2: http://WaldenITech.com/Luddites2.mp3

Note: The download of these audio files could take several minutes, depending on the speed of your connection and other resources.

Does the Semantic Web need Ontologies?

The answer to the question "Does the Semantic Web need Ontologies?" is "yes" according to most but "no" according to some. For a discussion of this question, click here for the view of one individual who is convinced that ontologies are a luxury, not a necessity, plus the comments of others.

Business Process Management and Service Oriented Architecture

Business Process Management (BPM) is used to model, simulate, automate, manage, and monitor processes, in order to coordinate operations with dynamic business priorities.

With BPM, workflows (both human and automated) are determined in real-time by events and/or outcomes within the process, and effective knowledge transfer is made possible as processes become well-documented business artifacts on which staff members can be trained.

To enjoy the full benefits of BPM, processes must integrate with existing applications and systems (e.g., hospital EHR and EMR, to name a couple of areas currently being funded by the Obama administration in the U.S.). This is where Service Oriented Architecture (SOA) - the subject of earlier posts - comes in. BPM and SOA are a natural match. There are links to a few of my early articles on SOA, in the bibliography at the bottom of this blog.

In preparation for my next post to this blog, I'd like to cite the following book:



This book shows the reader how to fill the semantic gap between the process model and the applications:

Modeling business processes for SOA and developing end-to-end IT support has become one of the top IT priorities. The SOA approach is based on services and on processes. Processes are focused on composition of services and in that sense services become process activities.

Experience has shown that the implementation and optimization of processes are the most important factors in the success of SOA projects. SOA is so valuable to businesses because it enables process optimization. In order to optimize processes, we need to know which processes are relevant and we have to understand them – something that cannot be done without business process modeling. There is a major problem with this approach – a semantic gap between the process model and the applications.

This book will show you how to fill this gap. It describes a pragmatic approach to business process modeling using the Business Process Modeling Notation (BPMN) and the automatic mapping of BPMN to the Business Process Execution Language (BPEL), which is the de-facto standard for executing business processes in SOA. The book will also cover related technologies like Business Rules Management and Business Activity Monitoring which play a pivotal role in achieving closed loop Business Process Management.

From http://www.packtpub.com/business-process-driven-SOA-using-BPMN-and-BPEL/book

Interoperability Between Oracle and Microsoft Technologies, Using RESTful Web Services - BPEL

A guide to developing REST Web services using the Jersey framework and Oracle JDeveloper 11g follows.

RESTful Web services are the latest revolution in the development of Web applications and distributed programming for integrating a great number of enterprise applications running on different platforms. Representational state transfer (REST) is the architectural principle for defining and addressing Web resources without using the heavy SOAP stack of protocols (WS-* stack). From the REST perspective, every Web application is a service; thus it's very easy to develop Web services with basic Web technologies such as HTTP, the URI naming standard, and XML and JSON parsers.

For a detailed account of how to create RESTful Web services by using Oracle technologies such as Oracle JDeveloper 11g, the Jersey framework (the reference implementation of the JAX-RS [JSR 311] specification), and Oracle WebLogic Server as well as how to consume the Web service by using Microsoft technologies such as Visual Studio .NET 2008 and the .NET 3.5 framework, click here.

Building a Web Services Network with BPEL - Caveat Emptor

Buoyed by maturing Web service standards, more and more organizations are using Web services in a collaborative environment. BPEL is fast becoming the platform for orchestrating these Web services for inter-enterprise collaboration. As discussed in earlier posts in this blog, BPEL offers the compelling benefits of a standards-based approach and loosely-coupled process integration to companies building an online marketplace or collaborative network.

Yet the exciting new capabilities offered by Web services carry some risk. In many cases, partner relationships break down or integration costs skyrocket if certain technical and administrative challenges are not addressed at design time:

* Partners must agree well in advance to conduct business according to specific criteria. Transport protocol, purpose of the interaction, message format, and business constraints have to be communicated clearly.

* Joining the network has to be an easy process; collaborative networks become successful mainly through growth.

* Users must easily find business services at runtime, or the promise of services-oriented architecture (SOA) is largely lost. (Service repositories are useful for this purpose.) If developers cannot readily find and reuse services, the services essentially don't exist.

* Partners should have the ability to monitor Web services in real-time. End users should be able to track the progress of a specific order, and trading partners diagnose a specific bottleneck within a business process.

These challenges are exacerbated when a collaborative network operates in a hosted environment. In that model, partners expose the functionality provided by their legacy applications into a Web service. This Web service is published into a centralized repository. The host is responsible for orchestrating the complex business processes, which in turn, leverage partner Web services.

Front-end Web Application for use in the Human Workflow used to Disambiguate IDs in an Electronic Healthcare Record (or other) Automated System

From December 14, 2009 post:

Disambiguation is a process through which multiple potential identification matches are further parsed until the patient can be matched with his or her data with sufficient certainty to allow for the delivery of a health service with reasonable confidence. The complexity of disambiguation varies according to factors such as the number of potential matches and the type of information available for further analyses. When sufficient digital data are not available to further differentiate potential matches, automated disambiguation may not be possible and may require human involvement.

Disambiguation entails implementing significant new workflows and may require substantial time and resources. When human involvement is required, many of the potential benefits of automation are lost. For example, at the point of care, disambiguation is often done by asking the patient further questions regarding personal characteristics and/or health care history. In some situation, disambiguation may not be possible, as when the patient is not present and information needed to further facilitate matching may not be accessible.

From December 7, 2009 post:

Disambiguation of IDs is the process of resolving multiple potential matches into a match with the correct person. In general, statistical matching algorithms are likely to require substantially more-frequent disambiguation compared to that required by a system that uses theoretically perfect universal IDs; often, disambiguation is done by human intervention. Such disambiguation imposes significant costs and operational inefficiencies, particularly if, for example, a physician must resolve the ambiguities.

Note 1: Many of the efficiency and safety benefits theoretically possible with health information technology (HIT) systems depend on eliminating such human involvement and its concomitant slowness, expense, and propensity for error.

Note 2: What follows applies to IDs in general, even though I’ve chosen the healthcare industry for much of this discussion.

When the business process can’t be completed by automation alone, the business process incorporates human workflow. Manual disambiguation of an uncertain ID is one such human task. The form shown in the figure below illustrates a Web app created with Visual Studio 2010 [Beta 2] that a user employs to carry out part of a human workflow.

Please note: This post is presented in early draft form.



Communication between the client (user interface shown in the figure above) and the application services is performed by using proxy classes that run in the client and that represent the application service. In practice, a Web reference is a generated proxy class that locally represents the exposed functionality of an XML Web service. The proxy class defines methods that represent the actual methods exposed by an XML Web service. When your application creates an instance of the proxy class, your application can call the XML Web service methods as if the XML Web service were a locally available component.

At design time, the proxy class enables you to use statement completion for the XML Web service methods. At run time, a call to a method of the proxy object is processed and encoded as a SOAP request message. If the XML Web service does not support SOAP, the proxy class uses HTTP GET and POST. The message is then sent to the target Web Service for processing. If the service description defines a response message, the proxy object processes this message and returns a response to your application.

Note: To make XML Web services outside a firewall available to the Web browser, when creating the Web reference in Visual Studio, you must explicitly specify the address and port of your network's proxy server.

{ click the figures for a larger view }

Click here for more on Microsoft Visual Studio 2010

Click here for more on Oracle BPEL and Human Workflow

Note: If patients cannot be unambiguously identified via a computer-based process, machine-level interoperability will be hampered significantly.

Human Workflow -- Business Processes -- Service Component Architecture -- SOA -- EHR

The immediate goal of this blog is to suggest a solution for the building of state-of-the-art electronic healthcare record (EHR) systems suitable for both organizations that have already invested in a computerized infrastructure and those that have not. There are many vendors proving tools for such endeavors. Here, I have chosen one of the market leaders - Oracle - to illustrate a solution. Since the Oracle tools that I show below are standards based, the concepts will carry over to the tools provided by many of the other vendors. I'll discuss the design of a system that automates business processes when that makes sense, hands off tasks to humans where they can do the job better (according to some criterion) and that can interoperate with heterogeneous systems (local and remote) efficiently and securely. While the language that I use will sometimes be that found in the EHR literature, the solutions discussed will be widely applicable. Please note: This post is still presented in draft form.

Service Component Architecture within SOA Composite Applications

Service Component Architecture (SCA) provides a model for assembling distributed groups of service components into an application, enabling you to describe the details of a service and how services and service components interact. Composite applications are used to group service components and wires are used to connect service components. SCA helps to remove middleware concerns from the programming code by applying infrastructure declaratively to composites, including security and transactions.

An SOA composite is an assembly of services, service components, and references designed and deployed in a single application. Wiring between the services, service components, and references enable message communication. The details for a composite are stored in the composite.xml file.

Services (shown at left in figure below), such as a web services or JCA adapters, providing an entry point to the SOA composite application.

References (shown at right in figure below) send messages to external services in the outside world, such as web services and JCA adapters.



The figure below provides an example of a composite that includes an inbound service binding component, a BPEL process service component, a business rules service component, and two outbound reference binding components.



You can invoke other deployed SOA composite applications from your SOA composite application. The other applications must be deployed.









The component palette shown to the right in figure below provides the various resources that you can use in a SOA composite. It contains the following service components and adapters:

Service components

Displays the BPEL Process, business rule, human task, and mediator service that can be dragged and dropped into the designer.

Service adapters

Displays the JCA adapter (AQ, file, FTP, Database, JMS, MQ, Oracle Applications, Oracle BAM, and EJB Service), B2B binding component, SDO binding component, and web service binding component that can be dragged into the left or right swimlanes.



You add a service binding component to act as the entry point (ep) to the SOA composite application from the outside world.

You can also automatically create a service binding component by selecting "Expose as a SOAP Service" when you create a service component.

However, you cannot invoke a representational state transfer (REST) service from the SOA Composite Editor.



Activities (in the figure below) are the building blocks of a BPEL process service component. Oracle BPEL Designer includes a set of activities that you drag into a BPEL process service component. You then double-click an activity to define its attributes (property values). Activities enable you to perform specific tasks within a BPEL process service component.

A partner link (in the figure below) enables you to define the external services with which the BPEL process service component is to interact. You can define partner links as services or references (for example, through a JCA adapter) in the SOA Composite Editor or within a BPEL process service component in Oracle BPEL Designer.

The method by which you create partner links within the BPEL process in Oracle BPEL Designer impacts how the partner link displays (above) in the SOA Composite Editor. The WSDL file can be on the local operating system or hosted remotely (in which case you need a URL for the WSDL).

Adapters enable you to integrate the BPEL process service component (and, therefore, the SOA composite application as a whole) with access to file systems, FTP servers, database tables, database queues, sockets, Java Message Services (JMS), MQ, and Oracle E-Business Suite.

You can configure BPEL process monitors in Oracle BPEL Designer by selecting Monitor from the dropdown list above the Designer window. BPEL process monitors can send data to Oracle BAM for analysis and graphical display through the Oracle BAM adapter (shown in the Service Adapters section at the right of the figure below).



Oracle User Messaging Service

Oracle User Messaging Service provides a common service responsible for sending out messages from applications to devices. It also routes incoming messages from devices to applications.

You can easily send outgoing notifications from a BPEL process flow or invoke outgoing and incoming messages for tasks assigned to users from a human task.




{ Click on any of these images for a larger view }

Counter-Intuitive Considerations -- When You're Automating a Business Process That Includes A Human Workflow

This blog is currently addressing business processes, human workflows, etc. However, at the very bottom of this page appears my bibliography [partial] with prior articles on topics like cost benefit analysis, six sigma, service level agreements, etc

To reconcile these two, sometimes opposed approaches to system design, I recommend the following talk (in a one-hour video) by John Seddon, an occupational psychologist. Just click on the image below to watch his January 03, 2010 presentation.



In the course of his talk, Seddon refers to the 2008 Wiley book



Customer service, often a human task, they assert, is only needed when an organization does something wrong -- eliminating the need for service is the best way to satisfy customers. To be successful, organizations need to treat service as a data point of dysfunction and figure what they need to do to eliminate the demand.

You decide!

Security Problems on Flash Drives

Kingston, known as one of the giants in portable memory, has recently confirmed a security problem with some of their DataTraveler series. The problem centers on the fact that even if encryption is used, it is possible to gain access to the data on the device.

In a statement, a company spokesperson said that someone with physical access to the flash drive could access the encrypted data, given the will to do so and the skill needed. The spokesperson went on to mention that the encryption used is sound, only that “there is a small loophole regarding the processing of the password.”

While the data on the drive is indeed encrypted using 256-bit AES encryption, there’s a huge failure in the authentication program. When the correct password is supplied by the user, the authentication program always send the same character string to the drive to decrypt the data no matter what the password used. This character string is the same for not only Kingston USB flash drives but those of SanDisk and Verbatim as well.

Cracking the drives is therefore quite an easy process. The folks at the security firm SySS wrote an application that always sent the appropriate string to the drive, irrespective of the password entered, and therefore gained immediate access to all the data on the drive.

These drives are sold as meeting security standards making them suitable for use with sensitive US Government data (unclassified rating) and have a FIPS 140-2 Level 2 certificate issued by the US National Institute of Standards and Technology (NIST) and companies like CapMed (Newtown, Pa.) -- to name one -- are putting personal health records on USB drives.

If you're using one of these USB stick from Kingston, SanDisk or Verbatim, you may want to get in touch with them.

An Update on the BPEL4People & WS-Human Task Standards

The BPEL specification focuses on business processes, the activities of which are assumed to be interactions with Web services with no additional prerequisite behavior. But the spectrum of activities that make up general purpose business processes is much broader. People often participate in the execution of business processes introducing new aspects, such as human interaction patterns. Workflow tools already cater for the orchestration of user interactions.

User interactions range from simple scenarios, such as manual approval, to complex scenarios where data is entered by the user. Imagine a bank’s personal loan process. This process is made available on the internet site of the bank using a web interface. Customers can use this interface to enter the data for their loan approval request and to start the approval process. The process performs some checks, and eventually informs the customer whether his or her personal loan request has been approved or rejected. Processing is often automatic and does not require any human involvement. However, there are cases that require bank staff to be involved. An example of such a case is if the online check of a customer’s creditworthiness returns an ambiguous result. In this case, instead of declining the request automatically, a bank clerk could check the request and determine whether to approve or decline it. Another example would be if a request exceeds the amount of money that can be approved automatically. In this case, a manual approval step is required, in which a member of the “approvers” group either approves or declines the request.

User interactions in business processes are not limited to approval steps. They also may involve data. An example of a user interaction that involves data is when an e-mail from an employer is manually attached to the process instance, or when the summary of an interview with an applicant is keyed into the process via a simple form or custom-built application.

To support a broad range of scenarios that involve people within business processes, a BPEL extension is required.

BPEL4People is defined in a way that it is layered on top of the BPEL language so that its features can be composed with the BPEL core features whenever needed. We envisage that additional BPEL extensions may be introduced which may use the BPEL4People extension introduced here.

BPEL4People is the WS-BPEL Extension for People as proposed in a joint white paper by IBM and SAP in July 2005.

In June 2007, Active Endpoints, Adobe, BEA, IBM, Oracle and SAP published the BPEL4People and WS-HumanTask specifications as a follow-up to the whitepaper, describing how human interaction in BPEL processes can be performed.

The OASIS WS-BPEL Extension for People (BPEL4People) Tecnical Committee is working on standardizing the BPEL4People and WS-HumanTask specifications.

Click here for a very engaging podcast that describes the inner workings of Technical Committee’s (something you usually don’t hear much about), describes the work the OASIS TC has recently accomplished and articulates the grand vision for business process management (BPM) and workflow that the committee has been working on.

I strongly encourage you to listen to this podcast. You’ll hear how some the of most important thought-leaders in the IT world, including IBM, SAP, Oracle, Microsoft, TIBCO and Active Endpoints are discussing BPEL and BPEL4People.

SOA, Web Services, BPEL, Human Workflow, User Interaction and Healthcare Systems

Lack of integration among legacy healthcare systems and applications means a continued reliance on manual processes that can introduce high risk errors into critical medical data. And isolated systems can compromise a provider's ability to follow an individual patient's care seamlessly from intake to treatment to aftercare.

While healthcare providers recognize that integration can help them achieve better service levels, many have been reluctant to proceed because of the critical nature of healthcare systems. But the approach to integration need not be a radical one of system rip and replace, nor does it have to precede through the development of system-by-system integration solutions.

Service Oriented Architecture (SOA) is a standards-based approach to integrating IT resources that can enable you to leverage existing assets, while at the same time building an infrastructure that can rapidly respond to new organizational challenges and deliver new dynamic applications. The SOA approach can help free application functionality from its underlying IT architecture and make existing and new services available for consumption over the network.

To derive a new value from existing services and go beyond simple point-to-point integration, you will need to combine and orchestrate these services in a business process. You will want to connect them in a coordinated manner, for example, have the result(s) from one service be the input to another service and have branching logic based on the outcome. Of course, you can use Java, C#, or another programming environment to call the services and manage the processes and data, but there is an easier, declarative way.

BPEL

An important standard in the SOA world is BPEL, or Business Process Execution Language, which serves as the glue to tie SOA-based services (Web services) together into business processes -- at least the portions that can be automated. The resulting BPEL process can itself be exposed as a Web service, and therefore, be included in other business processes.

The BPEL standard says nothing about how people interact with it, but BPEL in the Oracle Inc. BPEL Process Manager (to be discussed in my next post) includes a Human Workflow component (shown in the figure below) that provides support for human interaction with processes.



BPEL and User Interaction

I began an introduction to BPEL and human workflow towards the bottom of my December 14 post. Click here for a good deal more on this topic.

Humans can be involved in business processes as a special kind of implementation of an activity. To facilitate this, a new BPEL activity type called human task is required. From the point of view of the BPEL business process, a human task is a basic activity, which is not implemented by a piece of software, but realized by an action performed by a human being. In the drag-and-drop design pallet shown in the figure above, the actor of a human activity can be introduced into a BPEL process by using your mouse. A human activity can be associated with different groups of people, one for each generic human role.

People dealing with business processes do so by using a user interface. When human activities are used, the input data and output data must be rendered in a way that the user can interpret. More on this in upcoming posts.

Human resolution or disambiguation -- Integrating human workflow in BPEL processes -- Errors in statistical matching of attributes to an individual

To locate health records, statistical matching attempts to string together enough identifying information about an individual to substitute for a unique personal identifier. It involves matching attributes, such as last name, first name, birth date, address or zip code, and gender, and it may use medical-record numbers and all or part of the Social Security number.

The problem with personal attribute keys such as name and address is that they are usually not unique to the individual, change over time, and are often entered into different systems in different formats. And data-entry errors, such as misspellings, add to the difficulties with this type of key. Repeated collection, distribution, storage, and use of these data also represent an important identity-theft risk.

Statistical matching can attempt to correct for some of these changes and errors: The most straightforward process is to tag all of the near matches for human resolution, or disambiguation. Such disambiguation imposes significant costs and operational inefficiencies, particularly if the physician must resolve the ambiguities. Advanced approaches “score” matches on “closeness” to the input set. Those with a high score may be accepted as a match. However, all such efforts are subject to the probabilistic errors inherent in statistical matching systems.

As discussed in earlier posts, there are two types of errors - false positives, in which two different persons’ records are declared to be a match, which can lead to such errors as the wrong patient’s health data being obtained; and false negatives, in which two records for the same person are thought to relate to different people, leading to such consequences as some of the patient’s data being excluded. Both of these errors can lead to serious medical errors, waste (e.g., repeats of tests or the wrong tests), and considerable deviation from the promises of continuity and quality of care postulated for a connected digital health care system.

Disambiguation is a process through which multiple potential identification matches are further parsed until the patient can be matched with his or her data with sufficient certainty to allow for the delivery of a health service with reasonable confidence. The complexity of disambiguation varies according to factors such as the number of potential matches and the type of information available for further analyses. When sufficient digital data are not available to further differentiate potential matches, automated disambiguation may not be possible and may require human involvement. This last case will be the focus of the rest of this post and my next post.

Disambiguation entails implementing significant new workflows and may require substantial time and resources. When human involvement is required, many of the potential benefits of automation are lost. For example, at the point of care, disambiguation is often done by asking the patient further questions regarding personal characteristics and/or health care history. In some situation, disambiguation may not be possible, as when the patient is not present and information needed to further facilitate matching may not be accessible.

I will show how one vendor, Oracle, implements human tasks that can provide workflows such as those identified above. However, these Oracle services can be accessed by applications created with development tools from other vendors (my discussion will use Microsoft Visual Studio).

Introduction to BPEL and Human Workflow

Business Process Execution Language (BPEL), one of the key technologies for Service Oriented Architecture (SOA), has become the accepted mechanism for defining and executing business processes in a common vendor-neutral way. Apropos of this discussion, business processes often require human interactions as well.

User Interaction in Business Processes

BPEL business processes are defined as collections of activities that invoke services. BPEL doesn't make a distinction between services provided by applications and other interactions, such as human interactions. And that's important since real-world business processes often integrate not only systems and services but also users. User interactions in business processes can be simple, such as approving certain tasks or decisions, or complex, such as delegation, renewal, escalation, nomination, or chained execution . . . and matching an ID with an individual.

Task approval is the simplest and probably the most common user interaction. In a business process for opening a new account, a user interaction might be required to decide whether the user is allowed to open the account. If the situation is more complex, a business process might require several users to make approvals, either in sequence or in parallel. In sequential scenarios, the next user often wants to see the decision made by the previous user. Sometimes, particularly in parallel user interactions, users aren't allowed to see the other users' decisions. This improves the decision potential. Sometimes one user doesn't even know which other users are involved - or whether any other users are involved at all.

A common scenario for involving more than one user is workflow with escalation. Escalation is typically used in situations where an activity doesn't fulfill a time constraint. In such a case, a notification is sent to one or more users. Escalations can be chained, going first to the first-line employees and advancing to senior staff if the activity isn't fulfilled.

Sometimes it's difficult or impossible to define in advance which user should perform an interaction. In this case, a supervisor might manually nominate the task to other employees; the nomination can also be made by a group of users or by a decision-support system.

In other scenarios, a business process may require a single user to perform several steps that can be defined in advance or during the execution of the process instance. Even more complex processes might require that one workflow is continued with another workflow.

User interactions aren't limited to approvals; they can also include data entries or process management issues, such as process initiation, suspension, and exception management. This is particularly true in long-running business processes, where, for example, user exception handling can prevent costly process termination and related compensation for those activities that have already been successfully completed.

As a best practice for human workflows, it's usually not wise to associate human interactions directly with specific users; it's better to connect tasks to roles and then associate those roles with individual users. This gives business processes greater flexibility, letting any user with a certain role interact with the process and enabling changes to users and roles to be made dynamically.

BPEL and User Interaction

So far we've seen that user interaction in business processes can get quite complex. Several vendors today have created workflow services that leverage the rich BPEL support for asynchronous services. In this fashion, people and manual tasks become just another asynchronous service from the perspective of the orchestrating process and the BPEL processes stay 100% standard.

In my next post, I’ll talk about some of the specifics of how you might implement a BPEL process that includes human workflow/tasks for disambiguation using tools such as Oracles JDeveloper and Microsoft Visual Studio. The next two figures are meant to give you a preview of that discussion.

{ click the figures for a larger view }


Click here for more on Microsoft Visual Studio 2010

Click here for more on Oracle BPEL and Human Workflow

EHR, interoperability, etc. -- Informatics set to music

Human Resolution or Disambiguation -- False Positive and False Negative Identification: Heath Care and Information Technology Perspectives

Disambiguation of IDs is the process of resolving multiple potential matches into a match with the correct person. In general, statistical matching algorithms are likely to require substantially more-frequent disambiguation compared to that required by a system that uses theoretically perfect universal IDs; often, disambiguation is done by human intervention. Such disambiguation imposes significant costs and operational inefficiencies, particularly if, for example, a physician must resolve the ambiguities.

Note 1: Many of the efficiency and safety benefits theoretically possible with health information technology (HIT) systems depend on eliminating such human involvement and its concomitant slowness, expense, and propensity for error.

Note 2: What follows applies to IDs in general, even though I’ve chosen the healthcare industry for much of this discussion.

Disambiguation sometimes entails implementing significant new workflows that may require substantial time and resources. When human involvement is required, many of the potential benefits of automation are lost. For example, at the point of care, disambiguation is often done by asking the patient further questions regarding personal characteristics and/or health care history.

The potential for error in the statistical matching methods (see my December 1 post on unique patient IDs) has important safety implications, which are a chief concern for many in the health care profession. Two types of errors are involved in statistical matching: false positives, in which there is a link to the wrong patient’s records, and false negatives, in which not all of a patient’s records are found. A graphic representation of these types of errors and of how they relate to the probabilities and threshold for matching is shown in the figure below.



The horizontal scale shows the score of a particular match. As more and more attributes match and as the match is weighted by its score, or value, the higher is the probability that the patient is correctly matched to that record. A low score indicates a low probability of match (and a high probability that it does not match). It is possible to use a threshold above which the record is assumed to match and below which it is not assumed to match, which leads to the shaded areas above and below the threshold.

The area shaded to the right of the threshold is the region corresponding to false positives, or picking up the wrong patient’s records. The shaded area to the left of the threshold is the region of false negatives, or the records of the patient that are not picked up because of some non-matching personal attributes. Setting a balance between the two types of errors involves tuning.

Another approach illustrated in this figure is to define a region of ambiguity within which possible matches are tagged for human resolution, or disambiguation. Whether matching uses a single threshold or two thresholds, it is not possible to avoid encountering false-positive and false-negative matches. Adjusting the threshold or thresholds can result in a different proportion of false-positive and false-negative errors, but cannot be used to eliminate them because they result from the inherent characteristics of the population that lead to the two S-shaped curves.

As stated above, many end-to-end business processes require human interactions with the process.

Task Assignment and Routing

Human workflow supports declarative assignment and routing of tasks. In the simplest case, a task is assigned to a single participant (user or group). However, there are many situations in which more detailed task assignment and routing is necessary (for example, when a task must be approved by a management chain or worked and voted on by a set of people in parallel, as shown in the figure below). I’ve chosen tools in the Oracle SOA Suite to illustrate (in the figures below) human workflow that can provide declarative pattern-based support for such scenarios.





I’ll briefly elaborate here with an introduction to human workflow and continue the discussion in my next post, where I'll talk about how you might implement such a system.

Participant Type

In simple cases, a participant maps to a user, group, or role. However, workflow supports declarative patterns for common routing scenarios such as management chain and group vote. The following participant types are available:

Single approver

This is the simple case where a participant maps to a user, group, or role. Since at least one human being is involved, much more than his or her looking at a monitor screen and clicking with a mouse is involved.

For example, a vacation request is assigned to a manager. The manager must act on the request task three days before the vacation starts. If the manager formally approves or rejects the request, the employee is notified with the decision. If the manager does not act on the task, the request is treated as rejected. Notification actions similar to the formal rejection are taken.

Parallel

This participant indicates that a set of people must work in parallel. This pattern is commonly used for voting.

For example, multiple users in a hiring situation must vote to hire or reject an applicant. You specify the voting percentage that is needed for the outcome to take effect, such as a majority vote or a unanimous vote.



Serial

This participant indicates that a set of users must work in sequence. While working in sequence can be specified in the routing policy by using multiple participants in sequence, this pattern is useful when the set of people is dynamic. The most common scenario for this is management chain escalation, which is done by specifying that the list is based on a management chain within the specification of this pattern. More on routing later.

FYI (For Your Information)

This participant also maps to a single user, group, or role, just as in single approver. However, this pattern indicates that the participant just receives a notification task and the business process does not wait for the participant's response. FYI participants cannot directly impact the outcome of a task, but in some cases can provide comments or add attachments.

Readers who are interested in learning more about the subject of human resolution or disambiguation in an otherwise automated system might look at the following two books, while waiting for my next post.

Costs and Benefits of a Unique Patient Identifier for The U.S. Health Care System

In the healthcare industry, misidentification errors are not restricted to diagnostics and therapeutics but also may affect documentation. So, my earlier posts on semantics, ontologies, interoperability and the like notwithstanding, all is for naught when a given document doesn't provide information about a given patient. A chain is only as strong as its weakest link and patient identification is usually the first link in the healthcare chain.

Complicating the issue, not everybody can participate to the same degree or in the same way in the process of identifying a patient uniquely. Neonatal and senile patients are two groups where health providers and technology are on their own, when it comes to identifying the patient. Naturally, readers of this post fall into neither of these groups.

See, for example, Patient Misidentification in the Neonatal Intensive Care Unit: Quantification of Risk at

http://pediatrics.aappublications.org/cgi/reprint/117/1/e43.pdf

which provides a rather thorough study of errors in the first of these three groups.

The information that is used routinely for patient identification is frequently similar but often not recognizably unique.

In my November 20, 2009 post, Biometric and Other Identification Technologies, I discuss some leading technologies.

Although widely touted as “great” in security circles, all biometric devices (i.e., fingerprint, palm outline, iris, retina, et al) used for unique identification produce false positives and false negatives.



For example, an episode of Fox's "24" last season showed a White House visitor placing her thumb on a fingerprint scanner, a type of screening that is not typically used at the White House.

Fingerprint: false positives or negatives with scars, calluses, cracks in the skin, dirt, household cleaners and other variables.



Retina scan: susceptible to diseases such as glaucoma.



At the same time, non-biometric technologies have their own sources of error.



For a widely discussed examination of the costs and benefits of a unique patient identifier for the U.S. health care system, see

http://www.rand.org/pubs/monographs/2008/RAND_MG753.pdf

This recent study says using unique patient identification numbers for U.S. citizens would reduce medical errors, make electronic health records simpler and protect privacy.

The study says that despite a potential cost of $11 billion to create unique patient ID numbers, the effort "would likely return even more in benefits to the nation's health care system."

Most health care systems use statistical matching to find EHRs, according to the study by RAND Health, a research division of the RAND Corp. Statistical matching looks for demographic information, including names, birth dates and all or part of Social Security numbers.

See my November 17, 2009 post, Unique Patient Identification Numbers, Electronic Heath Records (EHR), Electronic Medical Records (EMR), and Social Security Numbers (SSN).

RAND researchers, who reviewed past studies, said that method causes errors or incomplete results about 8% of the time and leaves patients more exposed to privacy breaches.

"Assuming every health care system would have these [ID] numbers, then you'd be more likely to pick up all of the person's information," said Richard Hillestad, PhD, the study's lead author. "It would certainly make a lot of things easier."Using demographic information to locate EHRs causes errors or incomplete results about 8% of the time.

But critics expressed concerns.

"It's an absolutely terrible idea," said Deborah Peel, MD, a psychiatrist and chair of the Patient Privacy Rights Foundation, a watchdog group based in Austin, Texas. "Any database that has these numbers is bound to be a treasure trove for identity thieves."

The study was funded by a group of health information technology and IT companies, but Hillestad said that didn't influence the outcome. Dr. Peel is skeptical. "The combination [of data] is really deadly," she said. "That's why I say this is a data miner's dream."

The American Medical Association advocates prohibiting the sale and exchange of personally identifiable health information for commercial purposes without a patient's consent. The AMA also advocated in 1999 in favor of legislative action to repeal the portion of the Health Insurance Portability and Accountability Act of 1996 that mandated use of a unique patient identifier.

Hillestad said privacy is a big issue, but touted the ID numbers as a security boost.

"You're not sending all of the name and demographic information through the line to get connected," he said. "[Privacy] would depend on how much you protect the numbers."

Ontology-Based Software Application Development -- Java and .NET

Consider the following scenario: A programmer needs to read data from a database via the JDBC interface. The system administrator of the organization provides user name and password, which obviously need to be used in the process. Then, the programmer

1. Searches the entire API for a method call (or calls), which takes a database user name as an input parameter.

2. Has to understand how various API calls should be sequenced in order to go from the connection information all the way to actually receiving data from the database.

If the APIs are not semantically rich (i.e., they contain only syntactic information, which the programmers have to read and interpret), understanding, learning and using an API can be a very time consuming task.

For a discussion of how the application of ideas from the areas of "Knowledge Management" and "Knowledge Representation" -- The enrichment of purely syntactic information of APIs with semantic information -- will allow the computer to perform certain tasks that normally the human programmer has to perform, see

http://www.aifb.uni-karlsruhe.de/WBS/aeb/smartapi/smartapi.pdf

A similar semantification of Web services (Ontology-enabled Services) is being widely discussed and implemented today.




See, for example,

http://www.cs.vu.nl/~maksym/pap/Onto-SOA-WAI.pdf

and

http://www.computer.org/portal/web/csdl/doi/10.1109/AICT-ICIW.2006.141

A number of my earlier post have been about Protégé , the popular ontology development tool, and OWL, one of the main ontology languages. To continue that discussion, see

http://www.sandsoft.com/edoc2004/KnublauchMDSW2004.pdf

which discusses a realistic application scenario -- some initial thoughts on a software architecture and a development methodology for Web services and agents for the Semantic Web. Their architecture is driven by formal domain models (ontologies).

Central to their design is Jena, a Java framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL, SPARQL and includes a rule-based inference engine.

Jena is open source and grown out of work with the HP Labs Semantic Web Programme.

For more on Jena, see

http://jena.sourceforge.net/documentation.html

Jena is a programming toolkit that uses the Java programming language. While there are a few command-line tools to help you perform some key tasks using Jena, mostly you use Jena by writing Java programs.

But, .NET developers have similar resources. See, for example

http://www.ic.uff.br/~esteban/files/sbgames09_Alex.pdf

for a development environment using Microsoft Visual Studio, the base language C#, and the graphical library XNA. Protégé has been used for designing the ontology, and the application uses the OwlDotNetApi library.

This 2009 work demonstrates a step-by-step implementation, from the definition of an ontological knowledge base to the implementation of the main classes of a strategy game. It aims at serving as a basic reference for developers interested in starting .NET development of ontology-based applications.

Biometric and Other Identification Technologies

In my November 17 post, I began a discussion of the [proposed] unique patient identification numbers by looking at a de facto proxy, the Social Security number (SSN). In the present post, I will continue with a look at a few of the technologies available for getting information such as someone's identification into or out of a computerized system such as, but not limited to, those used to implement electronic health records (EHR).

Biometric Applications

Biometric verification is a technology which uses unique characteristic features of an individual to automatically identify a person. There are several biometric technologies including fingerprint, hand geometry, and retinal scan. Each of these verification techniques claims to provide positive identification of individuals. What's more, these forms of ID cannot be transferred, forgotten or lost. Anywhere personal identification is required (such as PIN numbers at financial institutions), biometric verification can be used.

The hardware needed for biometric verification is frequently installed at the entrance of a building or secured area and are the "keys" for entry. Fingerprint verifiers, for example, generally allow any finger on either hand to be used for positive identification. Usually an alternate finger is also chosen as a backup in case of injury (cut, scrape, etc.) to the first. Multiple fingerprint templates can be stored locally inside the fingerprint terminal or through a network on a host computer (e.g., in a database). Most vendors also include software that supports common security access features such as unauthorized overtime or early clocking in. In addition, many of these systems can be integrated with existing software packages. Therefore, usually, separate systems do not have to be maintained in order to record and restrict access.

Biometric applications are highly specialized and costly to install when compared to card recognition and other access systems. In addition, if a biometric unit such as a terminal goes down, the manufacturer is often the only source for replacement or repair. With other technologies, such as magnetic stripe, input devices are readily available and can be purchased from a variety of vendors. Biometric Identification, however, does have its benefit. When ultimate security is vital, biometric identification is sometimes proven to be the best solution. But, caveat emptor: as shown later in this post, errors do occur.

Voice Recognition

Although technically, voice recognition is part of biometric verification, its widest application is to convert speech into text and not principally for security or access control. Voice recognition has many advantages, most notably allowing people to keep their eyes and hands free while "voicing instructions" to the computer. Voice recognition is used in many professional fields including healthcare.

For a discussion of using the human voice for verification, see my article "Speech Authentication Strategies, Risk Mitigation, and Business Metrics" in the bibliography at the bottom of this blog.

http://www.developer.com/security/article.php/3684921/Speech-Authentication-Strategies-Risk-Mitigation-and-Business-Metrics.htm

For readers with a background in mathematics and statistics, see the papers

"Comparing Human and Automatic Face Recognition Performance" at

http://myslu.stlawu.edu/~msch/biometrics/papers/adler-schuckers-Human-Automatic-FR.pdf

and

"Statistical Evaluation and Estimation of Biometric-based Classification" at

http://myslu.stlawu.edu/~msch/biometrics/papers/SchuckersTIFSCorrelationStructurev3.pdf

Among the topics discussed here are

(1) false accept rate
(2) false reject rate
(3) false match rate
(4) false non-match rate
(5) biometric authentication,
(6) effective sample size
(7) confidence intervals

Note 1: A video in the right-hand column of this blog presents a brief introduction to confidence intervals.

Note 2: If 99.9% were good enough

• There would be a major plane crash every 3 days
• 12 babies would be given to the wrong parents each day
• There would be 37,000 ATM errors every hour

Nonetheless, technology-based systems in use today do yield the expected outcome less than 100% of the time.

So, it's important that you understand that, like their human counterparts, technologically-based methods are error prone. At the same time, it's also important that you know the cost of these errors to you (and those you serve) in the methodology you choose to use.

Optical laser Cards

These cutting-edge cards transform CD-ROM technology into a credit card form, capable of securely storing megabytes of personal information. For example, a patient ID card could hold an image, health care history, vaccination record, X-rays and more.

Card Based Access System

Controlling entry security to your facility (or computer system) is of vital importance, whether your facility is a high security area such as a hospital, airport, or bank, or even if it is an everyday situation such as an insurance office, school, or department store.

Visual Identification

The simplest access control systems use portrait ID or membership cards, which rely on a receptionist or colleagues at work to recognize interlopers by the absence of a valid, matching portrait card. Such systems require the printing of clear, easily visible, portrait cards. Unfortunately however, that alone is not enough, because with current PC and scanner technology, creating fake or counterfeit cards is all too easy.

Even simple door entry control systems need to use an anti-counterfeiting system which provides an overall security "watermark" feature which is proof against all attempts to copy it.
This type of access control is extremely cost-effective, and it may be all that many facilities need to achieve the security level they require.

Swipe Card Door Access Control Systems

If you need controlled access without relying on the presence of guards or reception staff, you may need to add swipe card readers and electronic locks to your controlled entrances. A higher level of security can be achieved by using mag-stripe readers.

Proximity Cards / Prox Card Access Control Systems

Proximity Cards, or "Prox" as they are often called, are standard size plastic ID cards which contain a coil antenna and a pre-programmed micro chip containing a unique code. When the prox card is within a foot or so of the Prox reader, the radio signal from the reader is picked up by the card antenna and used to power-up the micro chip which then replies with its own unique code.

The reader and its associated processor compare the code with a list of authorized entrants, and if it's OK, the door is opened and a record of entry is logged.

Prox cards must always be "personalized" with a portrait ID to eliminate the misuse of "loaned" or stolen cards.

Reference Books

For a good summary of the sources of problems (errors) and biometric performance, see



This book includes very readable material on

(1) Legal aspects of biometric technologies
(2) Selected technology error rates
(3) Resistance of the system to forgeries
(4) RFID applications
(5) Economics

and much else.

For a comprehensive introduction to RFID, see



Click here for a preview look at this book.

RFID and Bar Codes

For a discussion of the pros and cons of using RFID and bar codes for the identification of patients, staff and medications, in different use cases, see

http://geekdoctor.blogspot.com/2007/11/bar-codes-rfid-and-patient-safety.html

You will find there a summary of early work at Beth Israel Deaconess Medical Center in Boston to establish positive patient identification:

"For identification of most patients, we believe linear and two dimensional bar codes on wrist bands is robust, cost effective and standardized. For staff badges, linear bar codes work well. For NICU babies passive RFID enables scanning of swaddled infants without disturbing them.

For identification of medications, we believe linear bar codes of NDC numbers on heat sealable plastic bags provides a practical means to positively identification medications.

For identification of equipment, specifically for tracking location in real time, active RFID works well. Because of the size and expense of tags, we do not believe active RFID should be used for patient identification at this time.

Thus, a combination of bar codes, passive RFID and active RFID is working well in our various pilots. No one technology meets the needs of all use cases. Although we favor bar codes over passive RFID in the short term, we do expect to eventually replace bar codes with RFID once the technology is more robust, standardized and cost effective."