Home Blog Page 775

Nurses’ HIPAA Phobia Does Exist: How to Address Its Hindrance to EHR Success – (Part II)

Ruth Penafiel
-
0
Nurses’ HIPAA Phobia Does Exist: How to Address Its Hindrance to EHR Success – (Part II)

This is Part II of the article “Nurses’ HIPAA Phobia Does Exist: How to Address Its Hindrance to EHR Success.” Part I can be found here.

Continuing on the topic of HIPAA phobia, I will now discuss the ways that it can be reduced.

Top 6 things to do to help reduce HIPAA phobia among nurses:

Whatever the reasons behind the HIPAA phobia among nurses, it’s a problem that needs to be addressed. Only after this is done can an EHR system be successfully implemented. Besides, nurses play a central role in the healthcare industry, more so in EHR adoption. Here’s what can be done to help reduce their HIPAA phobia:

1. Identify where the phobia is coming from.

The best way to create a tailor-fit solution is to conduct a survey on the knowledge, attitudes, and practices among nurses. Managers should not make the mistake of implementing an organization-wide solution if the root cause of the problem has not been identified, whether it is resistance to new technologies imposed by HIPAA or simply lack of awareness.

2. The best medicine for fears? Information.

Many of the causes behind HIPAA phobia have to do with the lack of information. Nurses should be given relevant information about HIPAA’s provisions and regulations. Once they realize that HIPAA isn’t as complex as it sounds, they’re bound to be more receptive to EHR implementation. Providing information to the nurses is mandated by HIPAA, a matter of legal compliance that must not be ignored.

3. Information on HIPAA-compliant practices must be simplified, and a rewards-based approach must be adopted.

Nurses must not be bombarded with too much information on HIPAA and EHR implementation. For instance, some compliance tips are to never leave medical records in public areas or to follow security systems for remote accessing of PHI. They can be in the form of flash cards, leaflets, or bulleted tips. It would also help if managers assess the retention of information by the nurses through a post-assessment evaluation and a rewarding of the top scorers.

4. The importance of ethical practices must be emphasized.

The HIPAA regulations were drafted with ethical considerations in mind. By instilling the importance of ethical practices in nurses, there’s little chance that they will violate the rules. At the core of HIPAA is protection of the privacy and safety of patient information, and nurses should always keep this in mind. For instance, it’s an ethical rule in healthcare practice not to disclose patient information ever – with or without HIPAA.

5. The nurses must undergo integrated EHR and HIPAA training.

Alleviating HIPAA phobia is closely tied to EHR implementation, and it’s difficult to imagine the latter succeeding while leaving the former behind. That’s why it’s an excellent idea to integrate a HIPAA awareness seminar with EHR implementation.

6. Nurses must be given a more active role in drafting HIPAA-compliant rules and regulations for the company.

Another great way for nurses to learn more about HIPAA is by giving them a more active role in crafting the rules and regulations of your company, with HIPAA compliance in mind. The nurses who participate in the decision-making process can be expected to cascade the information down to their colleagues, leading to a deeper understanding of what HIPAA is really all about. HIPAA, more than anything, is about effecting a culture change among nurses and making them more mindful of privacy regulations, like finding a private place to discuss patients or not using social media to discuss patient information. If they take an active part in drafting the rules, they will have a more active and working knowledge of HIPAA.

HIPAA phobia among your nurses does exist. The sooner this reality is confronted, the sooner strategies can be created to effectively solve the problem once and for all. And with these six tips, there’s a guarantee of the reduction – if not total eradication – of HIPAA phobia.

The best next step toward ensuring the effective implementation of these tips is to partner with EHR vendors who know what it takes to make such systems a success. This is not just a matter of choosing vendors offering cost-effective EHR solutions; it should mainly be about their experience and expertise in EHR systems that are HIPAA-compliant. Aside from that, the fact that expert EHR providers make use of state-of-the-art software and cloud-based management systems is something healthcare organizations should consider. Also, with EHR experts backing up decisions, healthcare providers will be more confident in making good use of their EHR systems.

Each effort toward full EHR implementation should be made in partnership with experienced, accessible, and highly-assistive vendors. Every practice should choose a vendor that can provide comprehensive pre-implementation training and integration assistance.

The MPAA Group can be that partner. MPAA is an EHR solutions provider whose primary goal is to help healthcare providers adopt cost-effective, highly secure, and efficient clinical data-management systems. For more information, visit http://www.mpaagroup.com.





Nurses’ HIPAA Phobia Does Exist: How to Address Its Hindrance to EHR Success (Part I)

Ruth Penafiel
-
0
Nurses’ HIPAA Phobia Does Exist: How to Address Its Hindrance to EHR Success (Part I)

HIPAA (Health Insurance Portability and Accountability Act) phobia is a rarely discussed term. But describing such a phobia is considered important to the digital health industry, since it addresses several reasons why not all healthcare organizations find success in the implementation of EHR. In this article, Ruth Peñafiel from Medical Practice Automation Associates describes some practical ways to tackle HIPAA phobia in order to ensure that the use of EHR by healthcare providers will be maximized to provide better healthcare to patients.

Let me start this article with this fact:

Nurses resistance of EHR adoption is common in health organizations, especially when most staff members are in their 40s to 60s. And because the dilemma proves to be so common, EHR resistance is often attributed to a generation gap without us realizing that perhaps another huge factor is at play – HIPAA phobia, or fear of possibly violating the Health Insurance Portability and Accountability Act.

A rarely discussed term, HIPAA phobia, according to the Department of Behavioral Health and Development Services in Virginia (and as the name suggests), is the fear of HIPAA regulations. Although perhaps not officially classifiable as a phobia, the fear of HIPAA violation is real and has somehow become one of the biggest hindrances to EHR adoption.

This topic is very relevant and important to the digital health industry since it addresses several problems as to why healthcare organizations find success in the implementation of EHR – or why not. Fears are a great deterrent to providing both effective patient healthcare and implementing the good use of EHR. What’s more, not all organizations are aware of why such fears arise. These posts tackle very practical ways how one can relieve – if not totally eliminate – the phobia. I believe that the industry must now find the root of the fear before appropriate solutions can be found to resolve the problem.

The Fear Is Justified

According to the U.S. Department of Health and Human Services, a nurse can be considered a HIPAA-covered entity when he or she transmits patient information electronically. Trouble can arise when when a nurse realizes the gravity and consequences of HIPAA violations.

One can argue that the cases of nurses getting prosecuted are rare, and that righteous practice can easily prevent the problem. With or without the privacy rules, ethical procedures should be maintained by all healthcare practitioners.

However, the fact remains that not all nurses are properly briefed on HIPAA-compliant EHR practices, nor do they undergo EHR training; hence, confusion and uncertainty are inevitable. It appears that pre-implementation training has become a mere prerogative of administrators rather than a legal obligation.

Thus, the question begs to be asked: Where does the fear come from? Is it the administration’s fault, or the vendor’s? The only clear answer is that the source of the fear is highly circumstantial.

Eliminating the Fear Can Be a Key to EHR Success

Patient-centricity is a buzzword in modern healthcare. It emphasizes the fact that the primary goal of healthcare is to achieve good patient outcomes. But patient-centricity should not mean that health practitioners themselves should be left out of the equation. After all, how can good patient outcomes possibly be achieved if healthcare providers themselves are not taken care of?

On the topic of EHR adoption, very few studies have been published about nursing practice and perception vis-à-vis the rules and regulations that cover electronic health records. In fact, it is highly possible that this discussion is first among the very limited discourse on how nurses feel threatened, and therefore develop EHR apprehension.

Part II of this article can be found here.




Blog post image designed by Freepik

Three Ways Your Analytics Platform Is Sabotaging Your Analytics (and how to fix it) Part II

Michael Simon
-
0
Three Ways Your Analytics Platform Is Sabotaging Your Analytics (and how to fix it) Part II

This is the second part of the article Three Ways Your Analytics Platform Is Sabotaging Your Analytics (and how to fix it). The first part of this article can be found here.

         3. Don’t Get Used; Use Your Measures

Measures. They’re in your statutory reporting requirements; they’re in your incentive program; they’re in your internal quality-improvement program. But if your analytics platform is locked into only certain standards, you lack the ability to expand, to ask new questions, and to test new ideas. If measures cannot be retrieved or calculated when you need them, then you’re working for the platform, and not the other way around. And if you can’t adjust the granularity or specificity of the measure – allowing your teams to focus on specific sets of facilities, providers, or patients – you just lost a major tool in coordinating your quality-improvement program.

And once they’re there, do you trust your measures? Trust goes beyond simply believing the numbers; rather, are they reliable and traceable? Do you know what standards are the bases for your measures, which data are being used to calculate the measures, and what granularity, filters, and caveats are being applied to the specific results? The proliferation of local measures, in addition to the national standards like HEDIS and MU, means that any one organization may have hundreds or thousands of measures. Is it clear what the measure is doing so you know if it’s still serving its purpose?

To get real power out of the reporting framework in your analytics platform, your measures must be available, useful, and transparent. You need to be able to get at the measures when you need them and in a form that’s useful to you, whether that’s a spreadsheet, a feed to a reporting system, or the tablets in the hands of your care coordinators. Your measures need to be useful to you, not just in satisfying others’ reporting requirements, but for your own needs, from the reports that fuel the morning huddles to the data that drive your quality-improvement program. And don’t forget the transparency. You should be able to find out where the data used for measure calculation came from, and even how the measure functions. It helps to have a readable measure syntax, but clear documentation explaining not just what the measure is but where it came from gives you considerable power over and confidence in your reporting process.

From our perspective as data aggregators and integrators, we see it as our job to ensure success through effective communication and productive tools. However, there are a number of ways for organizations to transform how they use their analytics, although the particulars – and likelihood of success – will greatly depend on the organization.

  • Data integration depends on many factors (ask any organization that has gone through such a transformation), but our experience suggests that the top three promoters for success are: a) Leadership, the presence of a champion or champions in the C-suite who have the vision and clarity of what integration will bring to their organization and willingness to promote the organizational changes and investment needed to bring integration to fruition. b) Training throughout the entire organization, to ensure that users understand the value and impact of integration and also to make sure that workflow reflects the assumptions and definitions of the integration process. c) Quality and Validation, defined both by implicit data quality as well as by user requirements such that end users, administrators, and executives will have confidence in outcomes.
  • Connectivity is dependent both on a transport mechanism and the datasets to be connected. The transport mechanism most obviously includes the specifications for the transport protocol, but also relies on the definition of the source and destination dataset schemas. When you look at the definition of your transport protocol, is it capable of properly reflecting the source data in a reliable way? Is there extensive and complete coverage of your use cases? Are the structure rules and constraints on your inbound and outbound feeds sufficiently exact for your analytic needs? This can be an extremely demanding process for any organization, especially those with multiple legacy systems and diverging contracts or incentive programs. Organizations with complex sets of feeds and connections may want to bring in additional assistance in this area; at the least, an outside resource without specific affiliations to particular vendors will help in providing an unbiased perspective on how to improve connectivity.
  • To ensure that their measures are available, useful, and transparent, organizations should focus on meeting at least the initial requirements of the points above – integration and connectivity. Organizations can start this process by identifying crucial weak links in system-system data flow, such as between clinical data sources and appointment-tracking or billing systems. Equally crucial are identifying weak links in human-interface data flow, such as how often data must be ported out of one system, manually manipulated, and transported by one or more individuals, then manually loaded or presented to another system for further analysis or distribution. (A good metric is how many Excel spreadsheets your organization generates, modifies, and consumes on a monthly basis.) By identifying these links and aligning them with the most actionable and impactful measures – for example, those that are most frequently and closely missed – an organization can begin its data transformation with an eye toward immediate improvement in measure performance and use, along with a plan for the long-term improvements in measure and reporting productivity discussed in the article.

Finally, these are some questions I would like to raise, and I am looking forward for your contributions.

  • How many crucial reports are transferred between systems, departments, and entities using spreadsheets? How many different people are responsible for manually gathering data for, assembling, and then distributing these reports? How much information is gathered from or captured into systems that require person-by-person access, such as an EHR? And how closely is the quality of this process monitored and understood?
  • When was the last time you said, “If only we knew…?” about some facet of your business? What was it you wanted to know? What could you have done if only you had been able to answer that question?
  • How much of your budget do you allocate to improving and integrating your data assets? How much of your revenue stream, profits, and general business workflow depend on these assets? How far apart are these numbers?
  • Are the IT tools used throughout your organization able to talk to one another? If so, when was the last time you checked to make sure that they are all receiving all the information they need to come to correct conclusions? If not, are there cases where some systems might become much more valuable if they could “know” what the other systems “know”?
  • How often do you find that you are “waiting” for results? For example, how long do you have to wait to find out how a provider group performed on some requirement on a given day? Can you know by the next morning, or does it take several days, weeks, or months? What difference would it make to your productivity and business efficacy if you could know the next day?

 

Michael Simon, Ph.D., is a principal data scientist at Arcadia Healthcare Solutions, with experience in data analytics, process efficiency, and experimental design. Since joining Arcadia in 2011, Michael has focused on demonstrating and enhancing the value of client data through exploratory data analysis and advanced statistical methodologies, and on the analysis of healthcare data quality. Michael is a former National Science Foundation AAAS policy fellow and earned his doctorate in biology from Tufts University in Medford, Mass. He also holds a Bachelor of Arts degree in economics and a Bachelor of Science in electrical engineering from Rice University in Houston, Texas.

Three Ways Your Analytics Platform Is Sabotaging Your Analytics (and how to fix it) Part I

Michael Simon
-
0
Three Ways Your Analytics Platform Is Sabotaging Your Analytics (and how to fix it) Part I

Michael A. Simon, a principal data scientist at Arcadia Healthcare Solutions, argues that everyone needs an analytics solution for different reasons. The issue is that your analytics solution may be holding you back – such that it will leave you without some of the most important features you’re looking for. In this post, Michael describes the three crucial properties to embrace if you are thinking about introducing a new analytics platform into your health IT environment, or you’re wondering whether your current system is really bringing you all the power you thought it would.

Everyone needs an analytics solution today!

Your reasons may vary. It may be the federal mandates, or the proliferation of incentives (and penalties) dependent on a growing number of distinct measure sets, or the increasing complexity of managing an aging population with chronic diseases. Or maybe you just don’t want to be left out of the Big Data Boom.

No matter the specific reason, it is prudent to seek out a powerful and effective analytics solution. The market agrees, as thousands of companies pour in to what will be a $20 billion industry by 2020 (IQ4I Research & Consultancy).

The catch is that your analytics solution may be holding you back. Despite all the potential and big promises, many analytics systems will leave you without some of the most important features you’re looking for – the ability to understand your population’s health state, to identify points of risk and mounting utilization, or even the ability to simply have confidence in the results.

That’s why, if you’re thinking about introducing a new analytics platform into your health IT environment, or you’re wondering whether your current system is really bringing you all the power you thought it would, you should consider whether it embraces these three crucial properties:

  1. Don’t Separate; Integrate Your Data

If your system only offers you access to claims data, you get a view of the world as it was a month or two ago. Or three. Or more. Claims data are easy – structured, clean and orderly –  but claims data also lack many crucial elements like patient vitals, important details from encounter notes, and activities that don’t typically get a notation in a claim. Wondering whether the patient smokes, and whether he or she is being counseled to stop? Claims won’t tell you.

On the other hand, an EHR will tell you those things, and much more. It is a real-time, clinically rich and hugely powerful dataset.  Unfortunately, if you are only using EHR data, you are forced to operate solely within the boundaries of that EHR. Absent is the vast domain of events that occurred outside that realm, like urgent care or ED visits. How many of our patients actually went to a specialist for that eye exam? And how many are currently taking anti-psychotics but haven’t been seen in months? The EHR doesn’t know.

But a well-integrated system does. An integrated analytics platform brings together both clinical and claims data to create a more up-to-date view of the world, both within the ambulatory center and out into a world of disconnected inpatient and specialist facilities. An integrated system offers greater completeness. It combines knowledge of an unexpected urgent care visit with the patient’s vitals for the months and years preceding it and offers considerable intelligence at every level of the healthcare world, whether it’s a care team discussing an overall population health strategy or a physician preparing to see a longtime patient after an unexpected event. And the person is at the center: Any integrated analytics platform needs a powerful Master Person Index, so there’s never any doubt of whom you’re dealing with.

  1. Connect Completely and Confidently

If data are the fuel that fires up your analytic platform, what’s your pipeline? All of the fancy analytics, performance measurement and predictive scores go to waste if they’re not fed a high-quality, clinically rich dataset. Does your platform use a condensed extract like the Continuity of Care Document (CCD)? Specifications like CCD offer a compact and convenient way to exchange information between defined roles for explicit purposes, but they also impose severe limitations. Depending on vendor or configuration, the CCD could exclude many of the data elements your analytics system needs in order to answer your questions, resulting in your taking a severe hit in the data-quality department.

Speaking of data quality, does your analytics platform ensure the accuracy of the data it takes in? Of course, it may never be able to tell you that the blood pressure entered should have been 130/70 and not 130/60. But what if it’s 40/70, or 12.6/70, or Yes/70? And what about making sure structured information are in a useful structure? If there are 71 different definitions of “smoker” in the system, analysis could get a little hampered.

What you need is a data pipeline, or connector, that is both complete and confidence-inspiring. A connector should have access to at least a Minimally Viable Dataset that supports basic reporting functions, population-level health analysis, and patient-level care management. Your connector should be transparent in how it handles the data-scrubbing process, and, like any good relationship, should be able to provide feedback on what your data look like and when there are deviations from your typical, “normal” mode of operations. And don’t forget the mappings: Your data should be mapped to appropriate standards (LOINC, CPT, NDC/RxNorm) once they pass through the connector, but there should also be knowledge about local customs and workflows and the ability to map those to understood clinical concepts so that any user can sit down at your analytic platform and spend time learning about people and health and not about how specific items are coded.

Michael Simon, Ph.D., is a principal data scientist at Arcadia Healthcare Solutions, with experience in data analytics, process efficiency, and experimental design. Since joining Arcadia in 2011, Michael has focused on demonstrating and enhancing the value of client data through exploratory data analysis and advanced statistical methodologies, and on the analysis of healthcare data quality. Michael is a former National Science Foundation AAAS policy fellow and earned his doctorate in biology from Tufts University in Medford, Mass. He also holds a Bachelor of Arts degree in economics and a Bachelor of Science in electrical engineering from Rice University in Houston, Texas.

Part II of this article can be found here.

The Differences between User Stories and Software Requirements Specification (SRS) – Interview with Per Lundholm

The Healthcare Guys
-
0
The Differences between User Stories and Software Requirements Specification (SRS) – Interview with Per Lundholm

This is the fourth post in the series in which I have interviewed several Agile experts to reveal the differences between user stories and software requirements and their application to regulated systems (i.e., health IT systems). You can find the previous post in this series here.

Today’s interviewee is Per Lundholm, a professional developer since 1980. He has been a member of Crisp since 2007. Per helps clients become agile both as coders and as coaches. He also enjoys learning new things, and he blogs both textually and in video.

Do you think that “user story” is just a fancy name for SRS?

No. It is a completely different thing.

How do you compare a user story with SRS?

A story is a hook for discussion and planning, while a specification leaves no room for discussion.

Do you think that user stories replace SRS?

In a sense they do, since requirement specifications as an idea is dead. Regulations still exist, of course, but that is a different thing.

Which of the two do you prefer working with?

I wouldn’t call them methods, but I see what you mean. User stories are by far the most productive way.

Which of the two methods do you recommend using for regulated systems (i.e., health IT systems, medical device software)?

User stories, and speaking from experience. Regulations are a fact of life like many other things. You just need to adhere to them, or your stories will not be accepted as done. The definition of “done” becomes more complicated, and you may need to have more steps in the life cycle of a user story. User stories put focus on what brings value to the user and things that we can affect, putting things that we can’t affect in the background.

Do you agree with Per? Comments and discussion are welcome.

The Differences between User Stories and Software Requirements Specification (SRS) – Interview with Ron Jeffries

The Healthcare Guys
-
0
The Differences between User Stories and Software Requirements Specification (SRS) – Interview with Ron Jeffries

As mentioned in our post The Difference between User Stories and Software Requirements Specification (SRS), we decided to interview some Agile experts on this topic in order to reveal some confusion that may be occurring in the industry. This will be a series of interviews, with one interview presented in each blog post.

The interviewee that we present now is Ron Jeffries, one of the 17 authors and signatories of the Agile Manifesto. He was the onsite XP coach for the original Extreme Programming project in 1996. He is the proprietor of http://ronjeffries.com and senior author of Extreme Programming Installed – the second XP book after Beck’s white book – and the author of Extreme Programming Adventures in C#.

Ron is a frequent speaker and trainer at Agile software-development conferences, including attending and speaking at all of conferences in the United States and some in Europe. He is a well-known independent consultant in XP and Agile methods.

Thus, I saw that Ron would be a great fit for the topic we are investigating. Without further ado, let us go ahead and see what Ron Jeffries had to tell us:

Do you think that “user story” is just a fancy name for SRS?

No, they are quite different. User stories are small descriptions of single features, usually the smaller the better. SRS has no standard definition that I’m aware of, but generally refers to the set of all requirements, not to a single one. Even a single requirement spec is usually much much larger than a story.

How do you compare a user story with SRS?

I wouldn’t. I don’t see the need to do so. You may see a need, of course.

Do you think that user stories replace SRS?

Certainly, products large and small can be and have been built without doing anything I’d call SRS. So the answer is clearly yes – user stories can replace SRS.

Which of the two do you prefer working with?

Stories. They are small, simple, and easy to use. Because they are focused more on conversation than on writing, they are far more collaborative. According to my explanation of stories, they explicitly include acceptance criteria and are also concrete enough for any purpose. Search for “Card, Conversation, Confirmation” for more on that thought.

Which of the two methods do you recommend using for regulated systems (i.e., health IT systems, medical device software)?

I would use stories for everything at the team level. There might be some higher-level SRS that is parsed out into stories. There is some good work being done with regulated systems and every reason to believe that a lot of the mechanism that big organizations have built up could be trimmed down a lot. This might be seen as more of a job for Lean than for Agile.

Do you agree with Ron Jeffries? Comments and discussion are welcome.

The next post in this series where I interviewed Johanna Rothman can be found here.

Electronic Health Records Can Kill!

The Healthcare Guys
-
0

Technology is playing a vital role in our lives. It is reaching into every field – even the critical ones, the ones on which our lives depend. Take healthcare for instance. By June 2014, funding for digital healthcare technology companies reached $2.3 billion, exceeding the entire total of 2013.

At the top of the list of these technologies are the EHRs (electronic health records), in which patient information (medical history, medications) is recorded.

Since the Obama administration began encouraging providers to adopt EHRs, usage of such systems has increased dramatically. At the end of 2013, 50 percent of doctor’s offices and 80 percent of eligible hospitals had EHRs.

Fatal mistakes

There are some EHR issues that can hurt, or even kill. Jenny was killed by what was considered a bad UX (user experience) design, which I believe occurred in an EHR system in which three experienced nurses (more than 10 years of experience) missed a very critical piece of information, causing Jenny to miss her hydration for two shifts. This happened because the nurses were trying to figure out the software. Distracted, they overlooked that critical piece of information and care.

The hard truth is that UX issues in EHRs seem to be underevaluated. Ask yourself why you still see old systems in hospitals? Is it lack of new technology? The issue here is that when healthcare organizations decided to acquire EHR systems – priced in the millions – and those systems had poor usability, such organizations have been stuck! In other words, healthcare organizations will be burdened with poor usability for the life of those systems. And poor usability can mean compromising of patient safety.

Need more proof? Take a look at Scot Silverstein’s 84-year-old mother’s incident, caused by EHRs.

EHRs are prone to error

EHRs are being increasingly adopted. Doctors are now able to access all of the patient’s medical information online. This implies that the quality of healthcare should improve, right? I’m afraid that recent evidence shows that EHRs may prompt safety concerns when some network outage occurs. The fact that EHR problems are often complex and not easy to prevent led the Pennsylvania Patient Safety Authority to call attention to how EHRs can impact safety.

This study, The Role of the Electronic Health Record in Patient Safety Events, was performed to inform the field about the various types of EHR-related errors and, at the same time, serve as a basis for further study. Explored were 3,099 EHR technology-related reports. The majority involved errors in human data entry, such as entry of wrong data or the failure to enter data, and a few reports indicated technical failures on the part of the system itself,

Toward safer EHRs

Many issues that may arise from EHRs and affect patient safety are mentioned in this report. If we focus on data-entry issues, since those represent the majority of EHR-related errors, the following actions can be taken in order to avoid such errors and increase patient safety:

  • For EHR certification, usability concerns have to be taken into account – how the system can be used without confusion.
  • It should be stated clearly what the vendor’s EHR systems is able – and not able – to do.
  • The healthcare organization should implement policies and strategies for appropriate EHR use.
  • The healthcare organization should ensure that all users of the EHR system receive thorough training.
  • An internal report system that identifies issues related to EHR usage must be implemented.
  • Critical areas in the system that lead to risk factors must be well-identified, and access to such areas should be restricted.

An organization using an EHR system has to raise awareness of how critical such systems can be to the patient’s life, and have a team dedicated to training the staff on addressing any issues that may occur.

In conclusion

If used properly, EHRs can enhance patient welfare, since his or her information is easily accessible. However, if EHR safety concerns are not seriously taken into account, catastrophes can occur.




The Differences between User Stories and Software Requirements Specification (SRS) – Interview with Christiaan Verwijs

The Healthcare Guys
-
0
The Differences between User Stories and Software Requirements Specification (SRS) – Interview with Christiaan Verwijs

This is the third post in the series in which I have interviewed several Agile experts to reveal the differences between user stories and software requirements and their application to regulated systems (i.e., health IT systems). You can find the previous post of this series here.

Today’s interviewee is Christiaan Verwijs. Christiaan is the founder of Agilistic, a company that specializes in helping small businesses and startups on their journey toward Agile software development. He has been working with Scrum for more than three years, for a variety of companies and with a diverse group of teams. He enjoys writing about his Agile adventures in his personal blog: http://www.christiaanverwijs.nl

Do you think that “user story” is just a fancy name for SRS?

The concept of a user story must be understood within the context of Agile software development. For me, a user story is mostly a vehicle to facilitate discussion and collaboration within the team. Some liken user stories to “unrealized product options,” and I like that idea. A user story is the simplest way to describe such options from the user’s point of view, “simplest” in the sense that it provides the team with just enough information to get started, test assumptions, and delivers something of value at the end of the sprint that can be reviewed. In a sense, you could describe a user story as a requirement. But it’s mostly just a “product option” that is either more or less desirable to the product owner.

How do you compare a user story with SRS?

User stories are a form of specification, but a very limited one – by design. Within the context of Agile software development, we accept that projects are subject to frequent change and mistakes (in estimation, in assumptions, etc.). Instead of spending a lot of time on writing thorough specifications, we prefer to work with the least-extensive specifications to get us started. The problem with SRS is that they are mostly a bunch of assumptions about what users want, how functionality should work, and how to technically implement it. Until you’ve built the actual software and shown it to actual users, it’s all just speculation. And if your assumptions turn out to be wrong (as they often are), you have wasted a lot of time on specification. This makes it an expensive failure. Instead, I prefer to work with a method where I can fail early and quickly. Mistakes are less costly this way. And the best way to do this is by frequently delivering and reviewing (real) working software. So instead of focusing on specifications, we focus on building working software.

This does not mean that you can’t extend user stories with more information, like acceptance criteria. For me, this is usually just a short checklist of what a user story must do. Like, “It must work in IE8,” or “The email uses the styling of [Brand X].” They can help to address nonfunctional requirements. Although I’m perfectly happy with backlogs that are not 100 percent made up of user stories. Nowhere in the Scrum Guide does it say that user stories are required or even needed. I prefer to write the acceptance criteria during sprint planning or when preparing the next sprint – just-in-time specification, in a sense. But very minimal, as I want to focus on writing working software instead of documents.

Do you think that user stories replace “SRS”?

User stories serve a different need. They are not supposed to replace SRS. They are supposed to be part of a different way to build software. Instead of a planned approach, it suits an approach based on collaborative discovery.

Which of the two do you prefer working with?

User stories. But not because of the stories themselves, but the different process they are a part of. I’m currently working on a large project with a team of six developers. We’ve completed about eight sprints now and have seen a major shift in what we’re building and how we’re building it. When we started the project, we had a lot of ideas and quite a detailed backlog (with user stories, but still). After only a few months, we’ve dropped a lot of supposed core features and replaced them with very different solutions that we discovered as we progressed. I really enjoy this approach because it fits with the discovery process and the unexpected stuff that happens in all projects. If we would’ve had to write software requirements, we would’ve spent months on that. And we would’ve still run into the same unexpected and unpredicted issues. It was a lot less painful to drop a few lightly detailed user stories than a bunch of specification documents.

Which of the two methods do you recommend using for regulated systems (i.e., health IT systems, medical device software)?

As for regulated systems, you may need more specifications on the software that you’ve written. But I’m not sure if you really need more specifications before you start building software. After all, why would the problems that non-health-IT projects are facing – constant change, different interpretations, difficulty with estimation – not affect these kinds of projects? This software is equally vulnerable to incorrect assumptions. Maybe even more so. What you will need is to very carefully describe how the software works and what happens under what conditions. I think that this kind of specification can be in the form of documentation, but I would actually prefer batteries of exhaustive automated tests – unit, regression, etc. This way, your “documentation” stays up-to-date as tests are adjusted when bugs are fixed, new features are implemented, etc.

Do you agree with Christiaan? Comments and discussion are welcome.

You can find the next post in this series, where I interviewed Per Lundholm, here.

The Differences between User Stories and Software Requirements Specification (SRS) – Interview with Johanna Rothman

The Healthcare Guys
-
0
The Differences between User Stories and Software Requirements Specification (SRS) – Interview with Johanna Rothman

This is the second post in the series in which I have interviewed several Agile experts in order to reveal the differences between user stories and software requirements and their application to regulated systems (i.e., health IT systems). You can find the previous post of this series here.

Today’s interviewee is Johanna Rothman, known as the “Pragmatic Manager.” Johanna provides frank advice for your tough problems. She helps leaders see problems, seize opportunities, and remove impediments. Johanna is working on a book about Agile program management. Johanna writes columns for StickyMinds and ProjectManagement.com, writes two blogs on her jrothman.com website, and blogs on createadaptablelife.com.

Do you think that “user story” is just a fancy name for SRS?

No. User stories are often very different from an SRS.

A user story is a single scenario. An SRS is often a collection of requirements. You might have user stories in an SRS, but why would you? You rank each story in a backlog, and as you proceed, you get feedback on the story as you complete it.

In an SRS, you attempt to create all the requirements, often as functional/non-functional requirements.

The problem is that customers want features, stories. They don’t want functional or non-functional requirements. You need to explain these requirements in stories.

How do you compare a user story” with SRS?

An SRS is often written in the passive voice (like I just did). It’s often too long. It’s difficult to see the value, or the ranking of the requirements. If people rank the requirements, they often use buckets, as in “must,” “could,” “would,” or something like that. When we write user stories, we talk about a specific user, so we write the story in an active voice. We see the value. We can compare the value of one story against the other.

Do you think that user stories replace SRS?

For me, they do. Why wouldn’t they?

As you complete a story, you get feedback. With that feedback, you can decide which story to do next. You can change.

What I see most often is that product managers/product owners don’t require everything they think they do in an SRS if they use user stories and rank them.

Which of the two do you prefer working with?

I prefer user stories, even if I’m not using Agile. That way, I always see the value and the actor in the requirements. I can easily rank the requirements.

Which of the two methods do you recommend using for regulated systems (i.e., health IT systems, medical device software)?

User stories. They explain who the requirement is for, and the story around each requirement, in addition to acceptance criteria.

Do you agree with Johanna? Comments and discussion are welcome.

You can see the next post in this series, where I interviewed Christiaan Verwijs, here.

The Differences between User Stories and Software Requirements Specification (SRS) – Interview with Dr. Alistair Cockburn

The Healthcare Guys
-
0
The Differences between User Stories and Software Requirements Specification (SRS) – Interview with Dr. Alistair Cockburn

This is the fifth post in the series in which I have interviewed several Agile experts to reveal the differences between user stories and software requirements and their application in regulated systems (i.e. health IT systems). You can find the previous post in this series here.

Today’s interview is with Dr. Alistair Cockburn, one of the original creators of the Agile Software Development movement and co-author of “The Agile Manifesto.” He was voted as one of the “All-Time Top 150 i-Technology Heroes” for his pioneering work in the software field. Besides being an internationally renowned IT strategist and author of the Jolt award-winning books “Agile Software Development” and “Writing Effective Use Cases,” he is an expert on agile development, use cases, process design, project management, and object-oriented design.

In 2003 he created the Agile Development Conference; in 2005 he co-founded the Agile Project Leadership Network; and in 2010 he co-founded the International Consortium for Agile. Many of his articles, talks, poems, and blogs are online at http://alistair.cockburn.us.

Do you think that “user story” is just a fancy name for SRS?

No, but close.

How do you compare a user story with SRS?

A story must be end-user visible, something that an end user declares is valuable to him/her, and implementable in one sprint. SRS does not have those characteristics.

Do you think that user stories replace SRS?

Yes.

Which of the two do you prefer working with?

Neither. Use cases + user stories works well.

Which of the two methods do you recommend using for regulated systems (i.e., health IT systems, medical device software)?

I do not recommend user stories for regulated systems. I do not recommend SRS ever.

Do you agree with Dr. Cockburn? Comments and discussion are welcome.

You can find the post in which I interviewed Jean Pierre Berchez here.

1...774775776Page 775 of 776