Monday, February 25, 2008

 

Yes, there is a "Biometric Markup Language"

I need to more strongly impress upon my Document Engineering students that whenever they encounter a case study in which information or messages are buzzing around they should look for an XML specification that defines them. In the recent post about “ Smart Fitness Machines" Michael Lee and Jim Miller write about an interesting application of biometric technology to identify users of fitness equipment so that information about workouts can be easily tracked. Jim optimistically says that “they claim it is "open," and the company, Fitlinxx has agreements with various equipment manufacturers, so they have apparently achieved some degree of interoperability."

I always say that "the best thing about XML is that ease with which you can create a new vocabulary” and that the worst thing “is the same as the best thing: the ease with which you can create a new vocabulary." So it never surprises me to find some XML vocabulary that purports to encode information models in any domain. But I guess my students can't yet imagine this unchecked proliferation of XML and so they didn’t look to find a relevant XML spec after reading about this clever new stuff in the fitness industry.

Two of the stops in the “ Scavenger Hunt" that the students are currently undertaking to get some familiarity with reference models and pattern repositories useful in document engineering are the Cover Pages list of XML applications and OASIS, the global standards organization where a great many of the XML vertical specifications are incubated. I've looked at the former many times, and I'm on the board of directors of the latter, so I'm familiar with the XML spec development underway there. And sure enough, at OASIS there's a Biometric Markup Language standard already in place ("Providing a standard way to describe information that verifies identity based on human characteristics such as DNA, fingerprints, iris scans, and hand geometry") that would be the spec that Fitlinxx would be using if it knew how to make good use of XML.

I'll have to give my "best/worst thing about XML" speech in my lecture this Wednesday when I start talking about “Models of Business Information.”

--Bob Glushko



 

Smart Fitness Machines

[Hitachi Fitness Machine Article]


Here's another incantation of a project that Joshua Gomez was considering for the Document Engineering course and I was considering last semester for the XML Foundations course.

I thought XML would be a good way to store people's workout data because workouts plans are usually highly structured. Joshua thought that RFIDs in a person's membership card would be a good way for a machine to keep track of workouts (i.e. weights, reps, etc).

In this case, Hitachi is using a finger-vein scanner for user identification.
It keeps track of a user's progress, displays it on an LCD, and changes the resistance of the weights accordingly, on its own.

I believe the current price tag of $17,000 per unit is too steep for most gyms to adopt this technology readily. This would be especially true for older gyms that already own working equipment. Perhaps another (more cost-effective) approach to this would be to develop some kind of add-on system that allows users to identify themselves (e.g. using RFID technology). An attached monitor would show the user their progress, and allow them to punch in new information. Of course, weights would have to be adjusted manually in this case, but come-on, you are at a gym... you shouldn't really be complaining about moving a pin from one weight to another.

-Michael Lee


Sunday, February 24, 2008

 

D-O-C-U-M-E-N-T vs U-N-C-E-O-M-D-M-D-M-T

Samuel Driessen recently asked a very sensible question about the D-O-C-U-M-E-N-T checklist that students in my Document Engineering course use to ensure a complete and consistent approach to analyzing case studies:

I was wondering if the order of the checklist mattered? E.g. shouldn't 'user types' be higher up than 'document types'?


The answer is "of course" … but let me explain. I teach Document Engineering as a set of analysis and design phases that yield implementable models of business processes and the documents they produce and consume to carry them out. We depict the sequence of these phases using a diagram that I often call the "snake" because the different activities are portrayed on it as a winding path that takes different modeling perspectives on some domain in order to understand it at conceptual and physical levels.



In practice different phases get more or less emphasis, depending on the management and strategy decisions that shape the project. Top-down or strategic efforts to align business organization and technology make the activities at the beginning of the path more essential. In contrast, bottom-up and more document-driven projects emphasize the phases near the end of the path. But the "snake" is a good view of the generic approach.

1. In the first phase, "Analyzing the Context of Use," business and task analysis techniques establish the context for a Document Engineering effort by identifying the requirements and rules that must be satisfied.

2. In the next phase, "Analyzing Business Processes and Patterns," we apply business process analysis to identify the information exchange patterns needed to carry out the desired processes, collaborations, and transactions in the context of use. These patterns identify documents that are needed, but only generally as the payload of the transactions. The complete specifications for the documents can't be determined without analyzing existing documents and other information sources.

3. During the next phase, "Document Analysis," we identify a representative set of documents or information sources (including people) and analyze them to harvest all the meaningful information components and business rules that apply.

4. In the "Component Assembly" phase we develop a conceptual model that represents the original information sources as well as new sources and arrangements of information required by the people and processes involved in the business.

5. Finally we move from analysis to the task of designing new document models. In the "Document Assembly" phase, we assemble one or more document models from the component model. If possible we reuse conventional or standard patterns to make the model more general and robust.

6. The new conceptual models we have created for processes and documents can be viewed as specifications for generating code or configuring an application that creates or exchanges new documents. These models represent substantial investments in understanding a context and capturing its requirements in a rigorous way, and using these models to implement a solution in an automated or semiautomated manner exploits those investments to bridge the gap between knowing what to do and actually doing it. In the Implementation phase these conceptual models are encoded using a suitable syntax and schema language to support their physical implementation. This is most likely to be XML, but because of the technology-neutrality of the design phase, the document models can easily be implemented as EDI or ASN.1 messages if necessary.

Ideally, the checklist for analyzing case studies would be a mnemonic that would follow the order of activities in the "snake" diagram. But I couldn't think of one. So if we map the D-O-C-U-M-E-N-T checklist to the snake, it looks something like this:



So yes, Samuel, "user types" comes before "document types." But I couldn't think of a word that had U come before D that would help anyone remember that.

Ride the snake!

-Bob Glushko

Monday, February 18, 2008

 

Health Care Interoperability Dilemma

I’m currently reading through Dave McComb’s book, “Semantics in business systems” and finding certain chapters particularly meaningful to my master’s degree final project. Especially interesting is the section dealing with ‘Strategies for coping with integration’ on page 229. This is something I have been dealing with in the health care arena for a long time when developing internal applications, or integrating new proprietary systems. McComb discusses five approaches to system integration which include; Manual, big database, direct connect, point to point and message based. I certainly understand the semantic limitations of implementing some of these strategies (manual, big database, direct connect, and point to point), although I’m perplexed at the direction of both organizational and enterprise interoperability in health care given the current proprietary environment.

My final project, involving two other extremely talented iSchool colleagues (Jill Blue Lin and Katherine Ahern), is attempting to build a multi-device, clinical note entry and retrieval system for hospitals. Our focus is on prototyping some new technology involving voice and text menus, along with refining the process for note capture and retrieval. In the past few weeks, as our needs assessment has progressed, we have discovered how many clinical systems are tied into the note collection process. First, you need to have access to all the clinical staff information to associate a physician to a particular note. Then, it’s important to have access to ADT (Admission, Discharge and Transfer) messages, or the patient master table to associate a particular note to a patient. Finally, notes are closely tied to the hospital scheduling system. Administrators will often look at both scheduling and registration to find those patients that never had a note entered while at an outpatient clinic.

Given that all this information is critical in developing an application that’s meaningful to clinical note entry and retrieval, what’s the best way to proceed with integration? The problem with pursuing the majority of solutions discussed by McComb is that you’re duplicating the information that’s already available in a different system. Even the message broker solution (which is accomplished by HL7 engines in health care) provides the same messages to various systems to be stored independently. In addition, some added or edited information might not trigger a message to be generated. For example, a resident finishes a rotation with a particular hospital and is inactivated from the system. Should this edit not trigger and HL7 message and dependent application are not notified, there could be a variety of negative impacts (incorrect billing, compliance issues, etc).

What’s the next step for better integration? How can this issue of repetitive storage and asynchronous information be solved? Will the major vendors within the industry (GE, McKesson, EPIC, Siemens, Cerner, etc.) provide a web service or API for other companies to add value to their platform?


Wednesday, February 06, 2008

 

IT's own system of record - ERP4IT

Article: IT's own system of record - ERP4IT
Related article: EnterpriseResource Planning for IT

ERP4IT is a term used to define a broad-scale integrated management system of IT automation system that enables IT to manage itself. There exist solutions that provide pivotal insights into financials and customers (with ERP and CRM packages) but there is none that delivers an integrated system of record, by which IT (and the CIO) can gain holistic insight into the value, cost and quality of IT services. IT’s own internal systems and processes are often so fragmented, inefficient, and redundant, that there is a strong need to build an ERP system for IT. Enterprise information technology is so highly leveraged that any improvement in its management would have a multiplier effect on the enterprise’s effectiveness.

D-O-C-U-M-E-N-T Checklist:

D -- data types and document types

All services delivered to the business by its IT department.

O -- Organizational transactions and processes

Following are some of the organizational processes that can be automated: Operation, support and maintenance (functional); supporting IT processes (eg. Asset and change management); element management (technical); enterprise architecture.

C -- Context (types of products and services, industry, geography, regulatory considerations).

Out of the major resource areas in an organization, only information (i.e., IT) lacks comprehensively integrated vendor solutions like ERP and CRM. ERP4IT aims to bridge this gap.

The problem is so complex that a common framework is required to seek data about the data and process to manage the processing. Enterprise information technology is so highly leveraged that any improvement in its management should have a multiplier effect on the enterprise’s effectiveness.

U -- User types and special user requirements

The users include all IT personnel in an organization. Further, the CIO of a company stands to benefit strongly from this approach of having an ERP system for IT.

M -- Models, patterns, standards that apply or that are needed.

The Software Portfolio Management Facility, a draft specification by the Object Management Group (OMG) has with great relevance to the ERP for IT problem. However, these specs have taken a backseat in the OMG’s approval process, overshadowed by the current Unified Modeling Language (UML) revisions. Further, there are competing efforts by the Distributed Management Task Force, the Business Process Modeling Language [BPML] effort, and more academic work around ontologies. A standard for IT service management is U.K.’s Information Technology Infrastructure Library (ITIL).

E -- Enterprises and ecosystems (trading communities, standards bodies, other standards that help scope the case study).

Standards in this area are being chartered out by several bodies like the Object Management Group (OMG), the Distributed Management Task Force and UK’s IT Service Management Forum working on ITIL.

N -- The needs (business case) driving the enterprise(s).

IT needs a comprehensive system for IT management, governance and security within an organization. Despite its success building solutions for capabilities such as finance, supply chain, and human resources, IT’s own internal systems and processes often are fragmented, inefficient, and redundant.

Desire for more effective outsourcing in particular is driving the call for ERP4IT. However, no vendor currently offers a comprehensively integrated ERP suite for IT, and this provides an opening for standards-based approaches.

T -- Technology constraints and opportunities.

Managing IT is hard. This is because:

- the concept of information as a resource is relatively new- it is difficult to metamodel the IT problem domain.

- technical challenges such as establishing workable information models for the problem domain .

- IT budgets emphasize hardware and often aren’t directly tied to high-visibility, business-sponsored projects.

Another thing to be cautious about is to avoid making the mistakes that ERP has made in the past.

Labels: ,


Tuesday, February 05, 2008

 

RFID May Be Key To Finding Latest Mad Cow Case

[URL]
http://www.informationweek.com/shared/printableArticle.jhtml?articleID=192300040

[Summary]
The Canadian Government has been successful for detecting cows with “mad-cow disease” through the distribution of RFID tags and the management of information on livestock. The US also started to take steps to protect the food supply, and IBM and TekVet launched an RFID system to monitor the health of cattle. Their RFID sensor is attached to the ear of a cow and sends the health data wirelessly to stations on a cattleman’s ranch. Then, a satellite transmits the data to TekVek’s data center hosted by IBM to process the information.

As of 2007, the US Department of Agriculture started to set up a series of databases that allow the livestock industry to track information across the US. Data from birth date to doctor visits and vaccinations for numerous types of livestock, including more than 90 million cows, would reside in those databases. Designing the system also means pulling together a communication infrastructure that allows state and federal health officials to send requests for information through the system in the event of an outbreak. The information will be held by private industry and the government will only have access to the information if something happens.

D-O-C-U-M-E-N-T Checklist:

D -- data types and document types (paying special attention to the former when they are used across the latter as the "glue" to connect processes)

This article shows how to manage data on cows from birth date to doctor visits and vaccinations through RFID tags. Also, in the RFID tags, the result of detecting the change of body status is expressed in a data form (even if there is no specified expression for this data in this article).

O -- organizational transactions and processes (the "business processes", described coarsely like "drop shipment" or precisely like "PIP 3A4")

Processes for this tag system sequentially include storing cow data at the moment when the health status of cows is detected; sending the data to the IBM data center; retrieving the data by the government. This leads to the disappearance of papers and pencils for reporting cow data.

C -- context (types of products or services, industry, geography, regulatory considerations -- the ebXML "context dimensions" described in section 8.2 of Document Engineering)

The success of Canada to find cows with ‘mad-cow disease’ has motivated the US to take step to set up the RFID system. Detection of mad-cow disease is strategically important for the US because it can hold back the export of cows, which has been one of the sources of profit.

U -- user types and special user requirements (these are "people" user types)

The main user of this system would be the government, who has access to the system to monitor if something wrong in the livestock industry happens all over the country.

M -- models, patterns, or standards that apply or that are needed
The information of the RFID system flows from an RFID tag on a cow’s ear through ranch’s station and then a satellite to a data center. Data types on the health status, regardless of what kinds of RFID tags and database systems are, should be standardized in order to collect data with no data integrity problem from all over the country into the database system.

E -- enterprises and eco systems (e.g., trading communities, standards bodies, other frameworks that help scope the case study)

Data production, management and consumption are accomplished by different participants – ranches, private companies and the government (sometimes, ranches) – respectively.

N -- the needs (business case) driving the enterprise(s)

Because the mad-cow disease can give negative impression to customer outside the US as well as within the US, it is important to detect the disease before cows come into the market. Above all, it is the matter of our life, so it is undeniable to track the health information of cows in the most efficient way whatever way it is.

T -- technology constraints and opportunities (legacy or interoperability concerns from existing technologies or implementations; new or improved processes or outcomes enabled by technology)

Data semantic and type standardization are really important to gather data from different cows in different ranches. It would be effective to define and model standard markup language for cattle’s health information based on XML, so that the language can enable data to travel over heterogeneous system environments flawlessly.


Luke Rhee.

 

Microsoft Joins Data Portability Group To Develop Info-Sharing Standards

Article


Summary:

Microsoft announced that it joined DataPortability.org to enable web users to move personal data around web sites.

Today's web sites allow users to share data only with sites have direct business relationships. DataPortability.org, however, is suggesting standard rules to integrate existing open standards and protocols so that any web sites following the rules can share data with the data owner's permission. (Security and privacy are of great concerns here.) Other companies joined the working group includes Facebook, Google, and Plaxo.

The Microsoft's motivation is to benefit its 420M active users of Windows Live service by providing seamless foreign services (i.e., other web sites). Microsoft has also made an effort to enable users to move around web sites without entering passwords multiple times through an authentication gateway service called PassPort, though PassPort failed to be an industry standard.


D-O-C-U-M-E-N-T Checklist:

D - data types and document types

The data type the article talks about is virtually all kinds of user data stored in Microsoft's web sites which are not accessible in other web sites.



O - organizational transactions and processes


Almost no business transaction/process have been in this area.
Although Microsoft family web sites may share user data, it has been taken for granted that data stored in one site are not available in different sites. Therefore, users have to move their data explicitly and manually.



C - context


All services implemented in Microsoft's web sites are subject to the change.



U - user types and special user requirements


Every www user using Microsoft's web sites and other web sites joined DataPortability.org can benefit from the change. They will be able to access their data through different web sites.



M - models, patterns, or standards that apply or that are needed


First, web site should be reimplemented to be friendly to DataPortability.org's standard. (The standard should be able to incorporate different application-level protocols on which each site relies)
Secondly, a user authentication system, which can identify different identities in different websites same, is also required.
Third, security and privacy safeguards are essential.



E - enterprises and eco systems


The eco system includes all web sites participating in the DataPortability.org movement.



N - the needs driving the enterprise(s)


It is driven by the account incompatibility issue, which means a user needs to manage different accounts for different services. Therefore, user data stored in a site is not accessible by other sites.



T - technology constraints and opportunities


First, new sites should be implemented under the DataPortability.org's standard. It may restrict the degree of freedom when choosing an engineering technology.
Secondly, existing sites may be reimplemented when the standard is not compatible with the site.
But, there can be a synergy by sharing accounts on different sites. For example, user can reuse photos, which she posted on FaceBook, to print them out rather than upload over and over.



DK Moon

 

An E-voting Document Exchange Standard

Article: XML to the E-voting Rescue

The issue of accuracy and trust in election results, most visibly raised in the wake of the 2000 US presidential election, is global in scope, as exampled by the recent upheavals in Kenya. Now, OASIS has announced development of a new XML-based markup language that provides a standard syntax for election data exchanges. EML (Election Markup Language) is designed to handle document transactions at every phase of the election process, from voter registration and authentication to ballot casting, confirmation, tabulation, and auditing. The standard focuses on the interfaces between components of the election systems, but doesn't address system back ends, such as the voting machines themselves. This security issue aside, The EML initiative is a step toward providing open, standardized electronic voting systems.

D-O-C-U-M-E-N-T analysis:

D -- Data types and document types (paying special attention to the former when they are used as the glue across the latter to hold processes together).

There are a number of document types involved in the election process, including the candidates list, voter registration, election role, ballot, result, and audit log. Important data types include the candidate id and voter id, which must pass from one document to the next. The candidate id is part of the final output—the result, but the the voter id must disappear at the point where a ballot instance is created.

O -- Organizational transactions and processes (the business processes described coarsely as drop shipments or precisely as “PIP 3A4”).

There are a number of transactions involved in an election, such as listing nominated candidates on a ballot, registering voters, verifying voter eligibility, recording votes, counting votes, and auditing the results. Developing a single unifying standard that can be applied to a wide variety of elections--local and national, governmental and institutional--strengthens the integrity of elections in general. For example, if an emerging nation is able to say that an election was conducted according to a verifiable international standard, the results of that election gain credibility.

C -- Context (types of products and services, industry, geography, regulatory considerations).

EML was developed in the context of global concern over election auditability and of increasing use of electronic voting machines. Therefore, an important objective of EML was to achieve interoperability with a wide variety of election practices, systems and hardware.

U -- User types and special user requirements (these are “people” user types).

The users of an EML-based voting system are the voters and the election officials. Voters must be identifiable as eligible and allowed to vote only once. In addition, it must be impossible to identify them with their particular votes. Election officials must be able to prove that an election has been conducted properly.

M -- Models, patterns, standards that apply or that are needed.

EML is a standard for building an election process. Creating an election process that uses EML also ensures that it meets the EML standard for validity. An important caveat is that, since EML focuses on data exchange between components of the election system, the internal workings of voting machines are beyond its scope. However, the document exchange process is handled by EML, ensuring that all ballots can be accounted for. This eliminates one source of error or tampering.

E -- Enterprises and ecosystems (trading communities, standards bodies, other standards that help scope the case study).

In developing EML, OASIS has collaborated with hardware and software suppliers, including EDS, IBM, Oracle, and Sun Microsystems, and international government agencies, such as the Council of Europe. Governments have a clear interest in promoting trust in the electoral systems. An important benefit for suppliers is the cost saving achieved through standardization.

N -- The needs (business case) driving the enterprise(s).

Elections are central to democracy and political stability. In recent years, paperless “electronic” voting has emerged as a successor to error-prone paper-based voting systems. However, the possibility of undetectable error or tampering in current “touch screen” voting systems removes the elements of auditability and trust that are crucial to the election process.

T -- Technology constraints and opportunities.

One of the major objections to current electronic voting systems is that their code is proprietary and secret, making audits a challenge. The use of an open standard like XML simplifies election auditing. The fact that XML is human-readable means that the results of an audit are more likely to be trusted.

- Jim Miller


 

Paperless International Shipping

Article:

UPS Goes Paperless for Global Shipments and Returns

Summary:

This article describes UPS’s plan to go paperless for global shipments and returns. Besides reducing the 86+ million pieces of paper they go through each year, UPS wants their new system to reduce the work customers need to do to ship something overseas. Customs clearance and international returns are two main problems UPS wants to address.

By automating many of the processes needed to initiate a shipment or return to clear customs, mistakes are reduced and shipments are delivered faster. Furthermore, the number of personnel dedicated to global shipping services can also be reduced – which is great for smaller businesses.

UPS claims that their new service is easy to implement into existing electronic shipping systems. Once installed, the customer has to register their company letterhead and create a digital signature. Third world sites with primitive systems will continue to use printed materials, but should not affect the new system.


D-O-C-U-M-E-N-T Checklist:

D -- data types and document types

This article talks about reducing the paperwork to send shipments overseas and receive customer-return shipments. Since UPS processes more than 86 million piece of paper each year, going paperless will save time and money. They hope that their automated, paperless system will help tackle problems related to customs clearance and international returns.

O -- organizational transactions and processes

The overall processes of getting a shipment from point-A to point-B does not change much. Instead, through automation, transactions are easier to initiate and modify, coupled with improved error-checking. Additionally, the difficulty in creating documents for return shipments is reduced.

C -- context

The context of the article is that shipment overseas is difficult, especially with the documentation needed to get items from one place to another.

In this case, all of UPS international shipments are affected by the new system. UPS claims it will be “relatively easy to install the services” and will “go to customer sites to … [integrate the new system] for them.”

Customers with incompatible, primitive systems will continue to use paper, but should not affect the new system.

U -- user types and special user requirements

The users of the system are the shippers, recipients, and return-shipment customers.

Shippers must have infrastructure that can communicate with electronic shipping systems and be compatible with the UPS system. They must go through an initial registration process to provide a company letterhead and electronic signature.

M -- models, patterns, or standards that apply or that are needed

Since UPS says it will be easy to incorporate the new UPS paperless system into existing electronic shipping systems, there is likely some interoperability involved. It must work with the existing electronic shipping systems, interact with customs information, and provide tracking information.

Since UBL is a rising standard for documents including purchase orders and invoices providing strong data types and validation, it would be a good system to compare to.


E -- enterprises and eco systems

The ecosystem consists of UPS (transportation and distribution), customs, customers/recipients, and the small to large businesses that utilize its service. These groups need to communicate information reliably and efficiently to make sure the package gets to the correct location in a timely manner.


N -- the needs (business case) driving the enterprise(s)

Going to a paperless system (or near paperless system in the case of third world countries) will expedite shipping and delivery since less time will be used to fill out paperwork manually.

Filling out multiple pages of forms can be difficult to ship overseas. Another difficulty is the paperwork associated with return shipments. Automating many of these processes through paperless forms will help to “clear customs, reduce mistakes, and accelerate shipments.”

Improved shipping and returns will lead to more “purchase[s] over the Web.”

T -- technology constraints and opportunities

Constraints may include systems that may be incompatible with the UPS paperless system. Opportunity could include higher sales/shipments because of the reduced time spent on invoicing manually. It would also be easier to get up-to-date status updates and track shipments. Searching through invoices should also be easier since they are all under one system.


-Michael Lee


 

Electronic Document Management in Government Agencies

Article: "The Promise of Paperless (The long-promised benefits of document management are coming to fruition)".

This article outlines several recent government initiatives aimed at facilitating the exchange of information and improving collaboration among various government agencies. By converting their paper-based document repositories into electronic format that can be easily queried and shared among multiple users, a number of state and local government organizations have achieved significant improvements in process efficiency and operational costs. In Hillsborough County, Fla., the Planning and Growth Management Department began using an electronic document management system to keep track of all the documents associated with the development of land (e.g., building permits and construction plans). Typically, an application for a new development project has to be reviewed by multiple divisions inside and outside the agency and if a paper document is being reviewed in one division, then another division cannot review the information at the same time. In contrast, applications submitted in electronic format can be easily reviewed by multiple parties simultaneously, which leads to reduced application turnaround time and improved service.

As another example, the Coroner's Office in Kane County, Ill., has recently replaced handwritten and typed documents with an electronic document management infrastructure (COAS). Previously, case information had to be entered manually multiple times on approximately 60 different forms and COAS helped eliminate this redundancy and simplify the data entry process. The organization reports a 50% reduction in the time spent on cases as a direct result of implementing COAS.

D-O-C-U-M-E-N-T Checklist:

D - Data types and document types
Government organizations tend to maintain large collections of documents that pertain to their activities and purpose. Some agencies manage a very broad and diverse set of document types that range from vehicle registration records to construction permits and court transcripts.

O - Organizational transactions and processes
Some familiar examples of “document-heavy” government processes and transactions include processing vehicle registration applications and the oversight of land development projects.

C - Context
Many government agencies are accumulating large volumes of data and are facing increasing challenges in managing and sharing their documents. Electronic document management systems are being implemented to reduce the amount of paperwork, facilitate collaboration, eliminate redundancy, and improve process efficiency.

U - User types and special user requirements
The primary “users” of electronic document management systems are government employees or their respective departments.

M - Models, patterns, or standards that apply or that are needed
A key requirement for an electronic document management is the ability to share information in a way that enables multiple authorized users to access and operate on the data simultaneously. This feature is essential to achieving process efficiency when a document must be reviewed by multiple cooperating departments.

E - Enterprises and eco systems
The ecosystem consists of a large group of government agencies that need to collaborate and exchange information in an efficient, reliable, and secure manner.

N - The needs (business case) driving the enterprise(s)
The push towards paperless document management is primary driven by the need to reduce operational costs and improve efficiency due to budgetary constraints.

T - Technology constraints and opportunities
One important constraint is the issue of migration from legacy systems – all existing documents must be scanned (or imported by other means) into an electronic repository. At the same time, electronic document management enables content-based search, which can be seen as an important opportunity to improve process efficiency.

Andrey Ermolinskiy


Monday, February 04, 2008

 

Electronic pedigrees coming to California

Article: RFID Strategy -- Pharmaceutical E-Pedigree -- Biggest Supply Chain Topic of 2008

An e-pedigree is an electronic, auditable chain-of-custody record for pharmaceuticals from the point of manufacture to the point of sale. Paper-based pedigrees have been required since the passage of the Federal Prescription Drug Marketing Act of 1987 (PDMA). Although the FDA requirements for e-pedigree are stalled in federal court, individual states have moved forward with enacting their own legislation for compliance.

California has spearheaded the effort by passing new laws expanding the state standards. Effective January 1, 2009, all pedigrees will be required to include a serialization number. While products are currently identified on a general level by manufacturing lot numbers, the serialization number is unique to the item-level (shipping pallet of aspirin vs. each individual bottle). This is presenting companies with new challenges in maintaining a valid pedigree as the products are transported through the supply chain. Given California's large market size, this legislation may set a precedent for other areas of the nation.

D -- data types and document types

California is requiring each saleable unit to be identified with a unique serial number. Products are currently identified by the pallet-load using the manufacturing lot number, date, and purchase order information.

O -- organizational transactions and processes

The entire supply chain is affected by this change. Each saleable unit must be identified and recorded at every stage as it moves from the supplier to the customer.

C -- context

All pharmaceutical products for sale in California are affected. Companies may choose to adopt the processes developed for all products, regardless of their destination.

U -- user types and special user requirements

Manufacturers must generate serial numbers and make each unit identifiable by any entity which will accept custody of the pharmaceuticals. The California legislation does not specify the exact form of the electronic record or the technology so the data may be stored in RFID, barcodes, or other formats.

M -- models, patterns, or standards that apply or that are needed

One possible solution is to utilize a Global Trade Identification Number (GTIN) mapped into a 96-bit encodable EPC ID number. The global standard developed by EPCglobal, ratified January 5, 2007 contains two XML schemas available: the electronic pedigree format for use with open document-based pedigree laws and the standard electronic envelope format for use in document exchange between supply chain partners.

E -- enterprises and eco systems

EPCglobal is a non-profit consortium developing standards for Electronic Product Codes.

N -- the needs (business case) driving the enterprise(s)

California has mandated January 1, 2009 compliance; companies not in compliance must leave the market. FDA mandated requirements are on hold due to pending lawsuits.

T -- technology constraints and opportunities

Besides compliance with California law, companies will have the opportunity of improving their SCM with increased visibility, velocity of data, and business intelligence. Companies can also benefit during product recalls by returning only the affected units instead of returning a seller's entire inventory.

The California deadline may be pushed back to allow companies more time to implement the new processes. There are numerous technological hurdles including capturing the serial numbers at each point in the supply chain and modifying current systems to record the data.

Yu-Tin


Sunday, February 03, 2008

 

Microsoft's vision on health care

Related Article: "The vault is open" - Microsoft makes its big move into health care
http://www.economist.com/business/displaystory.cfm?story_id=9916512

Summary: Microsoft outlined a grand vision, Health Vault, an online personal health information database on which doctors can post electronic medical records such as "scans, lab results, test results, visit minute" and people can view all those health records and share information with health care providers and insurance companies. MS is arguing that storing health data on the internet is as secure as storing it in a bank, but there are all kinds of privacy and security questions remaining. Use of this system will be free both for the users, doctors and also for the vendors. In the meantime, MS's business model depends on targeted search.

"D-O-C-U-M-E-N-T" Checklist

D - Customers' health data, ranging from doctors' reports, scans, lab results, test results, visit minutes (these are from doctors) to daily measurements of weight or blood pressure, everything in digital form.

O - Basic idea of 'Health Vault' is to enable users to access to their personal health information records any time, anywhere, via the internet. Both individuals and doctors can post the health data, and by owner's grant, certain people have access to those information, such as an insurance company.

C - It's web-based service. Centralized health database has obvious benefits as well as scary problems. Efforts are underway to develop online patient databases to track physician and hospital performance, and the state could greatly benefit from these, but in order to attract any users in the first place, Microsoft has promised to enforce strict privacy rules. There are concerns over data security and privacy, coupled with difficulty in striking partnership deals.

U - Consumers will be able to post & view information, as well as myriad health care providers and insurance companies. Health care providers (medical offices and hospitals) who signed up for the service could easily send test results in digital form to the vault, and patients could authorize them in turn to have access to various, carefully circumscribed bits of their personal data.

M - Standardization of health-information in digital form is critical for interoperability. Currently, Health Vault's business model centers on advertising, particularly search-related advertising. Use of this system is free both for the individuals that sign up for them and for the vendors and doctors that provide services.

E - Health Vault is the name of MS's new health-information product, storing records online. In conjunction with this, MS is also launching Health Vault Search, a secure version of its health care search engine.

N - It is a general belief that centralized health care information system will lower the overall U.S. healthcare cost, and also that centralized health database represents the single most profitable social media endeavor imaginable, which is why many IT companies are trying (have tried) to this. It's also a blue ocean market since most consumers don't have electronic access to their health records.

T - (Constraint) Storing records online is not secure - nothing is secure on the web. (Opportunity) Health Vault's search engine would work better than those of rival sites if it could examine users' health records and past queries, and thus provide the responses that are most relevant to each individual's situation.

-Eun Kyoung Choe

Labels: , ,


Friday, February 01, 2008

 

Scamming an Automated Process

The first assignment in my Document Engineering course this semester is to analyze a news story or "mini-case study" using the
"D-O-C-U-M-E-N-T"
checklist I devised a year ago to ensure consistency and completeness in the review.

I'm going to use the checklist myself to set an example for the students. My story is from last August and concerns a scam by two South Carolina women who took advantage of a US Defense Department automated procurement and payment system to defraud the government out of over 20 million dollars.

The original news story was probably this press release from the Department of Justice but I first read about it in The Economist when it was reported in a story called "Creative Billing."

D -- data types and document types (paying special attention to the former when they are used across the latter as the "glue" to connect processes)

The story revolves around invoices for shipping costs. The invoices were for staggering amounts of money – the article mentions 4 of them, one for $998,798 and three others all greater than $400,000. The goods that were shipped cost almost nothing; the nearly million dollar shipping bill was for sending two 19-cent lock-washers to Iraq.

O -- organizational transactions and processes (the "business processes", described coarsely like "drop shipment" or precisely like "PIP 3A4")

The scam worked because the Defense Department used an automated purchasing and payment system that paid invoices automatically. It isn't a bad process to pay on receipt of the bills once they are reconciled with orders, but there should have been some better auditing of the numbers.

C -- context (types of products or services, industry, geography, regulatory considerations -- the ebXML "context dimensions" described in section 8.2 of Document Engineering)

The context of this story is the war in Afghanistan and Iraq, and the concern that Defense Department bureaucracy might slow the resupply of items needed by the army. The DOD has gotten lots of bad press about soldiers not having the right body armor and equipment (like the famous "Hillbilly Armor" episode when a soldier criticized =Defense Secretary Rumsfeld), and it is easy to understand why the purchasing and payment people at the DOD would try to speed up their processes so they’d not get blamed.


U -- user types and special user requirements (these are "people" user types)

The most central "users" of the system in this story were its "abusers," twin sisters Charlene Corley and Darlene Wooten, whose company committed the fraud by submitting the fake shipping bills totaling $20.5 million. Charlene will be spending 40 years in prison, but not with Darlene as a cellmate because Darlene killed herself when the government was closing in on them.

M -- models, patterns, or standards that apply or that are needed

The story reports that "the Pentagon has tightened its payment procedures in response to the sisters' scam." The business rules that they were following were simply too weak – the disparity between the cost of the goods and their supposed shipping costs should have triggered an audit.

E -- enterprises and eco systems (e.g., trading communities, standards bodies, other frameworks that help scope the case study)

The company had the clever name of “C & D Distributors” because those are Charlene's and Darlene's initials. It is hard to believe that this is the only case of fraud because thousands of firms must have used the Pentagon's purchasing and payment system.

N -- the needs (business case) driving the enterprise(s)

Wars are expensive to fight… and you'd hate to have to stop chasing the bad guys around Falluja because you're out of machine screws and lock washers. But it is more interesting to look at the needs that were driving the twin sisters to steal from the government. Because Charlene and Darlene were from South Carolina, the Economist used the popular Southern phrase that they were in "high cotton" after buying four beach houses, ten cars, boats and lots of jewelry.

T -- technology constraints and opportunities (legacy or interoperability concerns from existing technologies or implementations; new or improved processes or outcomes enabled by technology)

There was little mention of the technology used by the government. It would be great if the Defense Department would follow the lead of the Danish government, which requires all invoices to be submitted electronically using the Universal Business Language standard. That story is in the reading list for my lecture this coming Monday.


-Bob Glushko

This page is powered by Blogger. Isn't yours?