Enterprise Content Management

Armedia Blog

Archive for the ‘Records Management’ Category

Is Your EMR Holding You Hostage?

January 31st, 2012 by dbock

Let’s take a look at “Nirvana Health System,” a hypothetical 1000 bed system in the City of Nirvana. The system has 7000 employees, 7 hospitals, more than 200 doctors on staff, with another 800 or so who independently perform services in the area.

Historically they and have done what all hospitals do, that is, they have purchased “commercial off the shelf systems” (also known as COTS) to run their business, manage patient care, and even market their services on-line. This approach largely met their needs for years, but now after a series of acquisitions, recent and looming changes to their reimbursement model, and myriad technology challenges that result from the shift from “hospital” to “Health System” they are now at a crossroads.  These systems may have performed fairly well independently, but they were never designed or intended to function as one. Meanwhile, the vendors who originally supplied the systems have run out of answers, and Nirvana is suffering the consequences.

Nirvana has successfully standardized on Epic, one of the tier one vendors, as the primary electronic medical records (EMR) vendor at the main hospital, but what they desire is a single view across the entire patient experience. Patients in Nirvana receive services without consideration for Nirvana Health’s desire for a comprehensive patient record. Most will likely receive some health services beyond the reach of EPIC, often simply by receiving care at a nearby doctor’s office which is a different medical records platform.

So why doesn’t Nirvana just demand that EPIC integrate with other EMR systems? No doubt Nirvana and countless others have. But for EPIC to do so would in essence counter act their own commercial interest. To do so effectively makes the patient record portable, and by extension the EMR system as well. Machiavellian principles of self-interest have proven themselves in healthcare information technology (HIT). The only way out for today’s Health Care Systems is to for them to wean themselves from reliance on any one software vendor for any critically required systems.

One way we recommend that Nirvana and others who face similar challenges introduce effective portability and reduce vendor lock-in is through adoption of standards across an array of disciplines, one specific recommendation would likely be for them to adopt a Service Oriented Architecture (SOA).  Still, SOA is largely a foreign concept to them, not to mention the notion of web services (WS) and enterprise services buses (ESB). It is important to note that SOA is not a product, but a philosophy. As described in OASIS SOA Reference Model’s definition, SOA is a model for “organizing and utilizing distributed capabilities”, and especially “capabilities that may be under the control of different ownership domains”. Nirvana will likely never fully control all the patient access points, certainly not soon enough to reach their stated timelines, and the SOA approach places a layer between the applications they rely on and the user experience they desire.

Success with a SOA initiative will require strong support by executive leaders at Nirvana, but will put in place the foundation upon which Nirvana and others like them will be able to address the requirements of today and the unforeseen challenges of tomorrow.  When Nirvana and others like them realize the cure they seek does not come from a pill they can buy, but rather from a new approach that removes their reliance on any vendor, they will prevail.

An Insider's Perspective: The CPSC Project

August 30th, 2011 by mseth

It was in the fall of 2010 when I got a call that began my engagement on one of the most interesting projects that I have worked on in recent times.

The situation, the project was with one of the leading product safety regulators in the world.  The international arm of the organization was leading an initiative to create a global information pool for product safety recall information in an effort to make product safety efforts across the world more coordinated and effective.  This would be a one stop, one shop view to “any recall – any where – any time” product safety recall information.

Armedia was asked to perform an initial assessment of what it would take a build a global recall information pool, build a roadmap for the process and structure the approach for the global consortium.  This was a pure play Information Technology (IT) strategy project where the focus was on creating an IT approach to meet a complex business situation.

What I loved about the project was the challenge of a highly unstructured business situation where the project sponsors understood the pain and knew the desirable outcome, but they had little understanding of what needed to be done.

Building an approach for an IT system in the area of product safety was a challenge, as I soon discovered.   Several factors contributed to the challenge, they included,  (a) plethora of legacy IT deployments, (b) changing data structures and data definitions over time, (c) different data structures and definitions across countries, and (d) project execution headwinds (Note: Our team ran into a situation of competing for attention amongst different priorities both within the organization and with 3rd parties outside, in this case the consortium of product safety organizations from other countries).

Sound familiar?

So we walk into the situation not knowing all the pieces of the puzzle and the Armedia team immediately began an assessment of the situation.  Quickly the team structured the analysis into the following topical areas:

  1. Strategic
  2. Governance and Oversight
  3. Functional Scope Definition
  4. Usability, Data Search, and Discovery
  5. Architecture
  6. Deployment and Execution
  7. Operations

Next came a deep dive into each area to develop specific recommendations and a roadmap at a granular level. Data categorizations, normalization and data definitions were all important areas of focus given the complexity of handling these items across different jurisdictions. I believe that our team’s recommendations around this area were excellent and well received by the international community, especially because our approach required minimal impact to current product safety operations, which was a key requirement by the sponsors.

We brought value in terms of providing structure and simplification for execution to what seemed at the outset to be a complex problem.  The Armedia report on “Considerations for Pursuing Global IT Interoperability for Publicly Available Product Recalls ” was published by the OECD (Organization of Economic Development) and has been accepted as the strategic guidance document by the international product safety working party set-up for the purpose of creating the global recall pool. The execution work on report recommendations has started and is currently underway.

This complex business issue was in need of a technology execution plan that was intentionally kept simple, and yet met the unique requirements of the customer. My team and myself guided our efforts in order to meet these criteria, and in the end the Armedia team successfully developed recommendations that provided both strategic and efficient solutions to this international IT challenge.

 

 

The Andy Fastow Subtext…

March 4th, 2010 by Jim Nasr

File this under: “what the …”, “huh?!”, “is this ECM related…”, or “let’s bear with it for a bit, it may go somewhere…”.

So for those of you who may not have heard: The Andy Fastow Story is a far-fetched, weird and wonderful fantasy about a man who single-handedly (well almost…with a little help from a few close golfing buddies: Jeff, Ken, Michael, Rick, Ben and David, amongst others) brings down a giant company, nay, a whole industry, tailspins an entire country into recession, causes the loss of tens of thousands of job and billions of dollars of people’s savings, illegally bags tens of millions of dollars for himself and his best buddy Michael, etc… In this little tale, our hero Andy is magically transformed from an Ordinary Joe to Financial Genius with the help of his friend, and self-anointed god, Jeff. Andy then gets to make up “Andy’s World”, where everything is always wonderful for him and all bad things in the real world are shoved into a box called LJM and then a bigger box called LJM2 (and a couple of broken down pales called Chewco and Raptor). In Andy’s World, Andy and Michael get to make up all the rules. Everybody is invited to play in Andy’s World—at a fee. Everybody will win a participation prize. Everybody will lose a whole helluva lot. Errr, except for Andy and Michael of course—they always win. Until one day, when a nosy stranger starts asking questions like “Andy, how do you do it? …like, can you teach me how to stick really bad things into an ordinary box just like yours and have them just disappear and make me loads of money just like you?” Well, one thing leads to another and this nasty thing called the SEC starts poking and prodding Andy’s World, bugging Andy and asking him the same kinds of stuff; except this SEC thing is scary and has some gnarly militia working for it. The nerve of the SEC questioning whether Andy is on the up and up! Of course, just like all good fantasies, after a bout of the uglies (a little public humiliation and a few years outside the comfort of Andy’s World—chilling in an institution near Colorado), our hero rises at the end and gets to fight another day (presumably with some of those millions he bagged earlier). Unfortunately his friends, well except Michael again, didn’t do so well: poor Ken died, Ben and Rick went to jail, David became known as the world’s most infamous shredder, and Jeff was vilified around the world and got blamed for everything bad in Andy’s World. Oh, and, like millions of people’s lives’ got permanently messed up.

Pretty good story, eh?! I’ve even heard some rumors that it’s loosely based on real life

Dilbert on Enron

Of course the moral of the Andy Fastow Story is that we don’t want another Andy Fastow story. Actually, no more stories at all of that genre. Sadly, it seems to be a trite plot prone to repeat. Who can forget the Bernie Ebbers or the Dennis Kozlowski Story? Or the Lehman and AIG Show? Don’t even start with Maddof! So many copycats, it’s hard to keep track.

The answer to stop these stories, one presumes, is to put in place some controls. Tools that support the controls. And, a scary, ugly and expensive editing process affectionately called the threat of eDiscovery. Oh, and a whole bunch of government type people, lawyers, accountants, bankers and consultants. Now, surely there will never be another Andy Fastow Story. There will never be another Arthur Andersen willing to edit another Andy Fastow Story. In fact, we won’t even need to have any more authors or heroes for these kinds of stories. Our tools will auto-document happy stories where everyone wins and everyone is treated fairly. So, that’s where ECM comes in!

Unfortunately, it seems, again, that reality is just not complying with our carefully thought out plot. Dang! In spite of noise to the contrary, and HUGE vendor propaganda promoting the discovery of gold reincarnated in the all signing, all dancing eDiscovery products tied to ECM solutions, it seems there is a “fiction gap” between is and would-like to be. In fact, records management en-masse (which one would presume to be a precursor to eDiscovery products) is seemingly not much more than email archival these days. All this seems to point to the obvious. What’s the subtext here?

Perhaps the subtext is in the incentives and disincentives. eDiscovery, empirically, seems to be a dance. The goal really is not full discovery or going to court—that would be insanely expensive for most organizations—but a happy settlement, which would be less insanely expensive. Of course to get to the settlement, you still need some level of eDiscovery…to know what is insane and what is less insane! Now, what if eDiscovery were easier? ECM, records management, search and eDiscovery tools all working in unison. A nirvana to be sure. But, would that not potentially lead to greater exposure of being discovered? Would the disincentive of the lengthy, costly and archaic discovery process now be replaced with the incentive of protecting yourself through the same lengthy, costly and archaic discovery process?! Certainly the US government (through the FRCP; Federal Rules of Civil Procedure) doesn’t hope so. In fact, since the December 1, 2006 amendments to the FRCP, effectively dealing with eDiscovery is very much supposed to be on the legal and corporate roadmap of most organizations; moreover they have the burden of responsibility for adequately managing discoverable information at their own cost.

So, where does that leave us? In the spirit of Mr. Fastow and company, I suspect somewhere between pay now or pay later…which is to say, little evidence of much competence at this time. In my opinion, effective and somewhat efficient eDiscovery is directly tied to successful deployment of ECM—properly indexing, managing, storing, retrieving and archiving information, and a streamlined implementation of Records Management—identifying, classifying, retaining and disposing of formal records based on corporate and regulatory compliance policies. I’m sure the eDiscovery vendors would not entirely, or possibly at all, agree with some of these assertions. But then again they may have incentives not to…

What is a Record?

March 1st, 2010 by dmills

This is the first in a series of blogs entries that will address major records management issues in enterprise content management.

“What is a record?”     It is the fundamental question in records management. Without a clear answer to that question, one cannot determine record titles, develop and apply retention schedules, structure file plans or manage an “item” with software. The answer also makes the difference between establishing an “item” as a record, as opposed to being just a Word document, an email, a piece of paper in a file, or a map of a city.

The answer to the question begins with a definition. The primary definition for a “record” is stated in the ISO 15489: 2001 standard. It defines a record as

“…information created, received, and maintained as evidence and information by an organization or person, in pursuance of legal obligations or in the transaction of business.”

For the US federal government, the U.S. National Archives and Records Administration (NARA) is required by the Federal Records Act to use a slightly different and more explicit definition:

““records” include[s] all books, papers, maps, photographs, machine readable materials, or other documentary materials, regardless of physical form or characteristics, made or received by an agency of the United States Government under Federal law or in connection with the transaction of public business and preserved or appropriate for preservation by that agency or its legitimate successor as evidence of the organization, functions, policies, decisions, procedures, operations, or other activities of the Government or because of the informational value of data in them.”

Although this definition is slightly different than that in the ISO standard, NARA has incorporated the ISO definition into its regulatory guidance for federal agencies.

The result of these definitions is the segregation of items into “records” and “non-records” If an item does not meet the definition, it is not considered a record and, therefore, does not require any protection or preservation efforts – it may be disposed of when it usefulness for its owner ends.

If an item does meet the definition, it must also meet certain criteria to be considered a record. The criteria are designed to establish the trustworthiness of the potential record and are inherent to the definition. They are: authenticity, reliability, integrity, and usability. These criteria are defined as:

1. Authenticity: the record is a “true” item – an accurate representation of a transaction or activity, as purported by its creator at the time of creation

2. Reliability: the record can be relied upon to be a trusted source of the information it contains

3. Integrity: the record has not been and cannot be altered. It is complete in form and data

4. Usability: the record can be repeatedly retrieved throughout its lifecycle and used as an authoritative source of the information contained with in it.

If an item meets the definition, but fails to satisfy any one or more of the criterion of trustworthiness, the value of the item is suspect and cannot be considered a record. Thereafter, it is considered a non-record and can be disposed of at any time. Conversely, an item that meets all of the criteria of trustworthiness but does not meet the definition of a record, that item, too, is not a record. An example of this is a lunch menu for a nearby restaurant that is found in an employee’s desk. Although the menu may be a trustworthy representation of the restaurant’s bill of fare, if that restaurant is not connected to the employee’s organization, the menu is a non-record. (However, it could be a record for the restaurant.)

Often confusion arises in the application of the definition and criteria to an item when determining its records/non-record status. One major causes of this confusion surrounds the item’s media type. Another source of confusion is a failure to appreciate and evaluate the content and context of an item. Media type confusion arises from outdated perceptions of what a record have been. Until recently, many considered paper to be the only items that were records. The perception may have extended even to items preserved on microfilm or microfiche, but not much beyond that. The entire realm of electronic items was ignored. However, as ISO 15489 and the Federal Records Act make clear, any item, physical or electronic, can become a record if it is evidence of an entity’s business’ conduct and transactions. Therefore, potential record items include such things as paper documents, native electronic documents, scanned images of paper documents, structured data in a database, a chart, a photograph, a recording of voicemail, an instant message, a Twitter post, an email, or even, in the case of law enforcement, a gun, a knife, or DNA material. So long as the item meets the definition and satisfies the trustworthiness criteria, it becomes a record.

The confusion involving content and context is similar to that surrounding media type, as it concerns misinterpretations of how the definition and criteria are applied. One common misunderstanding is the assumption that all emails are records and should be preserved and protected as such. However, email itself is a media type, no different from a note, a letter, or a baseball bat. The factors that elevate an e-mail to record status are the content and the context of the email. At one end of the spectrum, an email between co-workers about where to have lunch, in most instances, would not be a record. At the other end, an email from a supervisor directing one of his/his employees to undertake certain job-related tasks clearly could be a record (assuming it also trustworthy). However, when context is applied with the content, it can change the status of the item. In the example of the email regarding lunch among co-workers, if business were conducted at the lunch, the email could become a record. If the is used by the organization to prove the time and date of the lunch for the Internal Revenue Service or other governmental entity, the email could become a record. Therefore, it is not the item itself that must be compared to the definition and criteria, but rather the content and context of the item in activity or transaction.

Any sound records management program is founded on the correct definition and trustworthiness criteria of a record. If the definition is absent, or is faulty, an organization’s entire records program can cause incorrect items to be treated as records. Every organization must, therefore, ensure that its record definition and the use of that definition are clear and unambiguous.

For more detail on this subject, please visit Armedia’s Resources page
and request the whitepaper entitled “Issues in Record Definition and Declaration.”

Other People of Case Management

February 7th, 2010 by James Bailey

A couple more roles although tangential come to mind – evidence administrator and records administrator.  Again, neither role may be primary to closing the case; however both can be critical in ensuring that the case is compliant. 

The case management system may not and probably should not be the evidence management system; however it should integrate with the evidence management system.  At a minimum, the case agent(s) need to understand the chain of custody of evidence associated with their case.  It would be better if it provided richer features like allowing the case agent to request evidence for charge out, reporting on state of evidence within case, electronic representation of evidence (i.e. picture) or etc.  The evidence administrator ensures that the evidence can be found when it is needed for whatever reason. 

The case management system should provide records management services. If deigned correctly, this will be transparent to the case agent.  As you clearly stated in “The People of Case Management”, the system has to make it easy for officers to document their investigation.  The records management system will ensure that the case adheres to the organization’s retention and disposition policies.  The records administrator maintains the file plan with its associated policies and enforces them during the lifecycle of the case. 

The evidence and records administrator supports the case agent by ensuring that physical and electronic material is tracked and available during the lifecycle of the case.

NIEM as it relates to Case Management

January 19th, 2010 by James Bailey

As it relates to Case Management, NIEM is very important.  The need for sharing information is vital for the war on terrorism as well as combating domestic crimes (i.e. drugs, sexual perpetrators and etc.).  Law Enforcement agencies have to be able to share case related data and NIEM sets the framework for accomplishing that.  Given that each agency has its own Case Management system that supports its business processes, security model, data structure and etc., there needs to be a common language/schema for these systems to export and import pieces or the entire case.  NIEM is that standard.

As my colleague has clearly stated in his blog, My name is NIEM, NIEM is not a silver bullet.  There are many issues to resolve:

  1. Security of information once export from system.
  2. Sharing of information between civilian and intelligence agencies – What if it contains data about US citizen?  How do we share with our international partners?
  3. What if one system does not support all data elements and during the import data is lost?  Agency could be making decisions based on limited information.
  4. When does the imported data become stale?  What if the case is active and new information contradicts the export data that has been shared?
  5. Given the limited budgets of local and state law enforcements, how do they participate in collaborating to combat crime?
  6. How do we combat data overload once data is being shared throughout the community?

These issues/concerns must and will be addressed because the alternative is not acceptable.  Our enemy wins when we allow distractions to take our eyes off accomplishing this goal of information sharing amongst the community.  As I review current and future procurements, I am glad to see the FBI, DHS and others make this a core element of their system.

My name is NIEM!

January 13th, 2010 by Jim Nasr

Those of you with affinity to old British pop culture or the unforgettable Madness of 80s fame (ahem: “my house in the middle of my street…”) will probably remember the infamous ”my name is Michael Caine” circular. Long before Rick Astley Rickrolling, poor old Michael was flavor-du-jour of everyman comedians looking for a quick, omnipresent quip. Well, forget all of that. These days, my name is NIEM!

NIEM which stands for the, inevitably, not so sexy sounding National Information Exchange Model is a formal information exchange schema developed by the US government (specifically DOJ and DHS) to further information sharing across Federal, and in time, State and Local government agencies and their business constituents. NIEM builds on from the much more bulky Global Justice XML Data Model (GJXDM) model; an off-shoot of post 9/11 information sharing initiatives. The idea of NIEM (currently in version 2.1) is to provide a consistent, non-redundant, open standards based XML schema that has some well defined entities and activities for improved inter-agency communication and information sharing.

All good…but what’s new, eh? Well, I think what is new is the fact that NIEM seems to be much more than just another academic exercise. Since its infancy in 2005, there have been multiple live and pilot projects (particularly around criminal investigation related content) at many Federal and State agencies, a set of open source tools have been developed and continue to grow, and the government (including Fed CIO, Vivek Kundra) seem more than ever to be pushing the standard and making it a part of the overall US government strategy for information sharing–see data.gov.

So, how does this apply to content management? Well, as with 21CFR11, 5015 2&4, SOX and most your other garden variety compliance oriented standards, there is an opportunity. An opportunity to become compliant (read: running afoul of the government is not a good thing if you want to work with them). And, an opportunity to be productive (read: information transparency and efficient content sharing can lead to some bottom line savings and possibly…and this is where you need to put your salesforce.com hat on…new revenue development channels).

As far as ECM goes, it seems to me that minimally NIEM would have an obvious play along the lines of Case Management (particularly for investigative records) and, in a larger context, Records Management. Empirically though it’s not there yet. Case Management is still quite immature as an offering. Though there are, of course, many solutions out there, most are heavily bespoke or still based on legacy structured data and structured data management systems. In a world of exploding DOC, PPT, PDF, MP3, FLV, et al content sources the days of pure structured content solutions are numbered. As for Records Management, despite hype to the contrary, it seems we are still very much focused on eDiscovery related records management–hail Email Archival!! I think there is change afoot though, with greater investment than ever–at least by the government–in Case Management, Records Management and information sharing initiatives.

NIEM, of course, is not nor will ever be a silver bullet. Ultimately, it’s a suggested structure for content storage and exchange. However, as with the neighbor’s grass, you could always bemoan the greener pastures…only to realize in time that with a little spade work your own grass aint half bad. NIEM can be that spade…

Retention Policy Consolidation

June 28th, 2009 by cschassler

One of the often overlooked challenges of electronic records management is the control and maintenance of retention policies.  This is particularly difficult if you are faced with a large number of members in your organization’s different record series categories.  Managed separately this means one retention policy for each individual record type.  If you only have a few different types of records to manage this is not such a big problem but it is especially difficult when you are dealing with hundreds of different types.  Additional complication comes in when you are managing permanent records that need to be archived to another organization such as NARA (National Archives and Records Administration). 

Careful consideration should be taken when creating an electronic retention policy design because trying to manage and control hundreds of retention policies that can have the tendency to change can become unmanageable very quickly.  The support and maintenance cost along with the compliance risk can eliminate your ROI and create a solution that fails to meet the goals for which it was designed.

One way to simplify and try to reduce the overhead associated with managing so many different policies is to group schedules together within your series according to their function or another applicable categorization scheme and their dispositions. 

The following basic strategy is an example of how this can be accomplished:

  • Create “buckets” representing the high-level record series areas.
  • Group record series members within the “bucket” into categories based on function and comparable disposition schedules.
  • Define and assign a common disposition strategy to each functional area that is representative and compliant for all record series members.

This concept is probably better understood using a simple example, lets use the following scenario as an illustration:

  • You have 5 different high-level record series groups.
  • Each series group has 100 individual members.
  • The schedule for each member ranges from temporary dispositions of 1 month to 10 years to permanent records with a duration of 25 years or more.
  • Each of the record series contain members that share a common purpose or function.

Using this example some basic consolidation steps would be:

  1. Define each high-level record series group as a separate “bucket”.
  2. Within each bucket you can create categories based on function such as whether the members are administrative, case related, procedural, etc.
  3. Within each of these sub-groups you would start to combine your applicable members based on corresponding disposition schedules.  For example, within a record series “bucket” if you have 25 members that are administrative records and they have temporary dispositions with durations ranging from 3 months to 5 years you can create a single retention policy with a disposition strategy of destroy/delete after 5 years and include each of these members under the policy.  By doing this you only need a single policy that can apply to 25 members instead of having 25 separate retention policies.
  4. Follow a similar process for each high-level record series and you can turn, what was in the case of our example, 500 individual retention policies into a number that is much more manageable making it easier to control and disposition your formal records.

Some items to take into consideration when consolidating retention policies are:

  • Work with your records managers and any outside agency, such as NARA, you archive records to before implementation, make sure you have their buy-in for the initiative.
  • Identify the special record series members and handle them separately with their own policy as needed to help reduce compliance risk.
  • When grouping record series members within a retention policy based on disposition schedules be wary of regulations that can be applied, it is generally best practice to only hold certain records for as long as necessary and no longer.
  • Designing an automated process for declaring formal records which will reduce workload and provide a better user experience for your records contributors/managers.  If you have or choose to implement an automated formal records declaration process you can provide more flexibility and room for growth by using an XML file or table to map the individual record series members to their applicable location in the formal file plan where the retention policy has been applied.
  • Consider structuring/restructuring your formal file plan after the consolidation strategy and apply your retention policies at the applicable level and allow the policy to be inherited by all formal records within that section of the file plan.

This information is an example of how retention policies can be simplified but in practice it is best to err on the side of caution.  Make sure you have the right people involved and do not put yourself at risk.  The goal is to reduce your overhead while minimizing risk and maintaining compliance.  You probably made a significant investment in your electronic records management solution and you need to be sure to keep the protection and savings that a solid design provides.

Electronic Health Records – Possible or Not?

March 17th, 2009 by cschassler

There have been a large number of articles published regarding electronic health records.  I wanted to share my thoughts given that this is an area that I believe has a tremendous amount of potential.  This topic is nothing new, it has been discussed, tried, abandoned, and retried a number of times.  Things are different now though in some important ways.  For starters it has a great deal of federal attention, President Obama campaigned on the subject and he has justified it as a big step in helping to improve the economy.  Secondly, the tools needed to facilitate this type of system are a lot more powerful.  Handling large amounts of unstructured data and classifying, tagging, and searching has all become relatively easy. (more…)

Copyright © 2002–2011, Armedia. All Rights Reserved.