Search My Blog & Website

Thursday, July 16, 2020

Telehealth Promises Higher Quality of Life for Rural America

It is not uncommon to find lesser access to healthcare capabilities in rural pockets of the world, and this holds true in the United States as well. A 2017 CDC report showed that death rates in rural America due to cancer are higher than urban communities. With recent changes to telehealth revenue models, and relaxed federal regulation, telehealth capabilities bring promise to areas that are hard to access service, as providers can extend their services into rural areas of states in which they are credentialed.

In June, the Federal Communications Commission (FCC) announced that it would be opening opportunities for healthcare providers to receive funding for infrastructure build-outs and improved access for patients. Funding can be used to provide clinical monitoring devices for patients's use at home, or telehealth software and hardware by providers.

Solo and small provider groups, along with large medical systems can extend their reach beyond their local zip codes. The playing field is not totally equal to all clinicians, but a specialist in Baltimore can certainly start providing telehealth services to residents in Western Maryland through the click of a mouse. The smaller practice can up with innovative billing models which still hold effective to the patient maybe even without using insurance, as they leverage lower overheads and direct personalized care. The larger provider groups benefit from the marketing economies of scale, more aggressive advertising, but are constrained by less flexible revenue models, large overhead, and the less than optimum agility to adopt solutions.

Many successful implementations have shown promise such as in the case of an oncology program in California which helped bring patients closer to caregivers especially during the brutal months of winter. The program reached accreditation by the commission on Cancer and has seen a growth of 8X over two years from 60 patients to 500 patients back in 2008.

The vendor and solution provider landscape is offering more innovation than a few years ago, and opportunities for easier access, higher value proposition and more personalized care with smarter revenue models cutting out the middle insurance broker are becoming more of a reality, especially in preventative and monitoring care. Generally speaking, patients adherence to long term is not strong, with closer engagement with their care providers the likelihood of adhering to guidelines and recommendations is much higher, leading to improved health outcomes.

Examples of telehealth solutions that are creating personalized experiences for patients through access to a stronger medical ecosystem are Siemens Healthineers, and Vianova. Standards groups such as Institute of Electrical and Electronics Engineers (IEEE) are actively working on interoperability standards for devices and data across solution providers. The IEEE P2933 work group focuses developing a framework for the clinical IoT data and device Interoperability with TIPPSS (Trust, Identity, Privacy, Protection, Safety, Security) principles. This includes wearable and other clinical IoT enabled devices and their interoperability with healthcare systems including Electronic Health Records (EHR), other clinical IoT devices, hospital devices, and future devices and connected healthcare systems.

#telehealth #patientmonitoring #P2933 #healthcare

Ayman Nassar is an industry expert in project and portfolio management with over 25 years experience in architecting business solutions through optimum alignment of technology and business to achieve meaningful results. He is also a member of IEEE P2933 helping bringing patients closer to improved quality of life through robust and seamless telehealth solutions. He can be reached at anassar@anassar.net or https://www.linkedin.com/in/aymannassar/

Tuesday, July 14, 2020

What is Your Telehealth Roadmap Strategy?

There is no doubt that COVID-19 has been a major catalyst in accelerating telehealth solutions. Many medical care institutions have had some flavor of telehealth prior to COVID-19. For some organizations the telehealth capability took the form of provider to provider consults. In other cases it could have been a simple portal where patients login and provide some basic information about their vitals and how they are feeling. COVID-19 however pushed the boundaries on every provider to find out ways to provide virtual encounters via video and audio remotely as both providers and patients have been quarantined and stay-home orders were in effect.



As healthcare organizations scrambled to deploy quick solutions which in some cases were not HIPAA compliant, and were far from fool-proof, leaders have to the realization of the need to operationalize the capability, as well as develop a vision for what it would look like over the short term, next 12-24 months. This need becomes of a higher need as regulations undergo some changes, compensation models innovation are occurring, and patients expect the service, not to mention potential subsequent COVID-19 waves as witnessed this morning in California as it re-enters into a State of Emergency.

So what are some considerations for a sound telehealth roadmap?

I like to break down the strategy into two distinct areas; the first is what I call the foundational phase, the second is the deployment and roll-out phase. Telehealth capabilities are more than technology. The successful realization of telehealth capabilities requires addressing culture, business rules, workflows, technology security, data analytics and operational key performance indicators (KPIs) in the clinical, revenue cycle and supporting operations areas.

Setting the foundation is the main focus of the initial component of the roadmap, and involves these activities:

  1. Establishing a well-oiled enterprise portfolio management office. A group that can facilitate C-Suite discussions to define key business KPIs, and define approaches to track them on a daily basis, and view projects as investments translating delivered work into measurable value that can be translated into financial and operational metrics that the CFO and COO can appreciate and utilize. To maintain autonomy the group should have the empowerment to coach chiefs on thinking outside of their areas and think strategically. In some models the group would report to the CEO, or to all chiefs, but have autonomy to make decisions based on sound approaches and documented rules. Another common model is to have the group report to the CIO, as almost all solutions today are data-driven and technology enabled. Today's successful CIO's are those who speak in the language of the business and are empathetic with the needs of clinicians and their patients.
  2. Fostering and nurturing an organizational culture of accountability, patient value proposition and organizational mission. Unfortunately, not too uncommon is many organizations in the industry suffering inefficiencies. Examples of these inefficiencies are clinician controlled organizations which tend to prioritize physician convenience over patient care reflected in scheduling rules, availability, triaging rules, decision making, patient volume accountability and documentation maintenance. Another common inefficiency is tactical leadership in the C-Suite that fails to think strategically across the organization, unable to define heat maps, or poorly identifying existing and needed business capabilities and lack of prioritization of initiatives, losing track of meaningful KPIs and creating silos. Focus should be on business rule simplification, process streamlining, capability and asset inventory, architecture documentation, and change management and enablement processes.
  3. Investing in a strong supporting infrastructure represented in IT security, network and server technical capability, enterprise architecture, project management office, talent development, compliance and a legal support team. Unfortunately many healthcare organizations view their IT departments, legal team and HR recruiters as cost centers, rather than value development centers. Together these supporting teams can strategically build and support a strong value stream by weaving a strong strategy map in conjunction with the operational leaders of the organization, mainly in the clinical and revenue cycle sides. The formation of these guiding teams and the chiefs engagement directly with these teams is a key requirement for success. Chiefs shouldn't be immersed in fighting daily fires, leaving strategic growth initiatives to become second priority.

Next comes the deployment and roll-out phase which focuses on two main components

  1. Problem Definition and needs analysis coupled with a visioning exercise checking its alignment to the organization's mission has proven very powerful to validate the scope of the telehealth roadmap and it's capabilities.
  2. Solutioning and a strong market research of offerings, comparing off-the-shelf products and their fit to the healthcare organization's environment and configuration at a feature and use case level is the next value-add activity. This can be achieved through vendor presentations, RFPs, in person demos of well-defined use cases reflective of the organization's workflows. This piece of work should include integration concerns across vendors, and how the integration will address the organization's specific business rules and the level of adaptation of the technology to the changes in business and clinical operations.
  3. Building a strong partnership model internally and externally with key stakeholders and vendors to implement the solution and telehealth capabilities under the oversight of the guiding team, utilizing the enterprise portfolio team and project management office as the internal auditors of the roll-out, providing continuous feedback and opportunities for process improvement.
  4. Once these high level stages can be put into place, the problem of defining which telehealth model to deploy (virtual health, peer to peer consultations, third-party contracted services) becomes a simple task, followed by a more detailed definition of telehealth capabilities and types of clinical encounters and a roll-out plan across the various specialties or a big-bang approach.

In summary, before worrying about COTS vs inhouse implementation, or Electronic Health Record (EHR) and Practice Management (PM) embedded vs integrated solutions, or the features a doctor can perform, the organization needs to think strategically at a macro-level to build a solid foundation in an agile manner to ensure a valid business and revenue model. This will ensure a scalable roadmap that can be incrementally implemented providing value realization to both the organization and the patient, focusing on what matters and what makes the organization unique and well-positioned for longer term growth.

For more information on telehealth advisory services visit carefinitive at https://www.linkedin.com/company/68234600/admin/Ayman Nassar is an industry expert in project and portfolio management with over 25 years experience in architecting business solutions through optimum alignment of technology and business to achieve meaningful results. He can be reached at anassar@anassar.net or https://www.linkedin.com/in/aymannassar/

Thursday, June 21, 2018

Speak Up

Ever been in a meeting when someone is presenting a topic, or making a statement and then the discussion goes on, towards the end the facilitator asks if there are any questions or comments, and its all silence. Ten minutes after the meeting is over the complaints starting roaming around on emails and phone calls. People whining and complaining about that idea that was thrown out there, or that comment that was made in the meeting. Sounds familiar? So how does a project manger handle office rumors, perceptions, she said, he dictated. It's simpler than it seems, just speak up.

Speak up on calls, that is why we have them. to share your points and opinions and be heard. Otherwise keep your peace forever and do not complain off-line.

Thursday, April 05, 2018

A Framework for Enterprise Portfolio Management

It's all about chosen the right set of initiatives and project to deliver the needed value at the right time and with the right investment. In Systems Architecture lingo its the optimum validated design, in stock manager lingo it a balanced nest. In the early 2000s I wrote extensively on value proposition and value management, the diagram below illustrate the position of value management across the grand scheme of things. Enjoy


Monday, March 26, 2018

ETL Move to Production Considerations


Extract, Transport and Load (ETL) work is a common method to connect systems using manual or scheduled batch jobs. Blow are common items worth considering when building an ETL and turning it over to your operations team. We holding knowledge transfer meetings the items below are usually of most importance.

 

Functional description

Batch / Automated Job Names

Frequency / Timings of Batch Jobs

Potential Errors

Error Handling

Exception Handling

Escalation Path

Diagrams

Interface Names

Server / System Names

ETL Tool Version / Vendor Support

Security Parameters

Wednesday, February 07, 2018

Project Governance Transitioning

Ocassionally project managers transition out from a project due to relocation to another business area, termination or incompatiable skill set. So what are some of the items that the new project manager needs to check and receive from the departing project manager? The list below is what I have found the most important artifacts to enable a smooth transition.
  • Project charter
  • Latest status report
  • Open items punch list / issue list
  • Progress Map (where does the project fit on the lifecycle of a typical project)
  • Team / Stakeholder roster
  • Approvals Matrix (list of approvers and evidence of approvals
 
Both departing and onboarding project managers should schedule a meeting to review these pieces of information, and then a followup meeting with the stakeholder to ensure all expectations are clear.

Thursday, December 07, 2017

Software Transition Plan

Building a system is one thing and turning it over to production for the end users to reap it's utility is a totally different beast. Transitioning products to production involves training, documentation, support knowledge transfer, operational procedures, production readiness and end of life disposal. It is a complex process and requires good governance and leadership. A well known systems hueristic emphasizes that systems are least stable when transitioning from one governance mode to another.


Each of the areas above could require a detailed plan or set of checklists to ensure all needed actions have been considered. In this post we will focus on software products, and list below key items that should be included in a transition plan.


Training should cover all required functions by the end user, and should include special cases. emphasis should be on how to process business rules, verify transactions, run reports and review output. common artifacts used are handouts, videos, training web pages, online webinars, in person train the trainer sessions.


Documentation includes defect logs, knowledge base tip sheets, escalation procedures, notification requirements, schedules for batch jobs, lists of interfaces, details of interfaces, expected outcomes, lists of vendors, data sheets, user guides, admin guides, support levels and contacts. Requirements documents and functional specifications should also be shared with the operatonal support team for reference, manitenance and operational support puproses.


Support knowledge transfer usually takes place in progrsssive iterations in the form of meetings between the project development team and the operational transition team, it is a series of engagements of experts to transfer knowledge, review details of the software and identify all the transition requirements including the development of a transition plan and its execution.


Operational procedures are covered in the documentation above and also include run books, special processes for data archiving, licenses renewals, IT business functions and upport such as security audits, threat analysis and similar processes.


Production readiness covers the setup and installation of the software, user configuration, secuity profiles, smoke testing, functional spot checking, final hardware configuration and monirtoring systems (reportsing / dashboards) setup.


Finally end of life support should be considered at time of transition to ensure the user population understands how to dispose of the software at end of life, how to extract data and migrate into industry standard formats as needed.


The links below provide some more details and templates


https://www.projectmanagement.com/content/processes/10352.cfm


https://www.projectmanagement.com/content/processes/10350.cfm 

Monday, October 23, 2017

Performance Challenges on the Cloud

 
 
A typical cloud implementation could have hundreds of CPUs running in parallel. Some cloud solutions could be like an S-class Mercedes, however to leverage its muscles, it needs to be configured and fine tuned to reflect an efficient model. Examples of factors affecting a cloud implementation performance would be the number of Key Figures in an Integrated Business Planning (IBP) solution. The more Key Figures the higher the demand on the system and lower the performance.
 
Examples of common cloud performance challenges I have seen on SAP and Salesforce implementations are:
  • Slow login time which is usually driven by network latency, demand on the enterprise SSO or other security system, firewall settings, or network device configurations.
  • Dropped connections could be difficult to troubleshoot. On one implementation SAP users would receive a dropped connection error on an intermittent basis after about 30 minutes of being active on the system. Two weeks of troubleshooting uncovered the root cause of the issue was not due to the SAP cloud, but a misconfigured load balancer group of servers at one of the client's data centers.
  • Initial load of templates, views and report runs are common issues when customers process large amounts of data. On a healthcare SFDC implementation the customer had a Contacts view for all its members, a whopping 1.5 million records. Obviously loading the view would take a few minutes of its agents staring at their screen. Educating the client on customizing the views to show members in a particular region, or who match certain filter criteria allowed them to view smaller data sets which were also more meaningful to their work.
  • Refresh time is also a factor of the amount of data being retrieved, the browser
  • Simulations
  • Long running queries
 
Vendors constantly monitor their cloud operations checking memory utilization, background jobs status, CPU utilization, table sizes, system activities, and other performance KPIs to ensure optimum performance for their customers.



SAP key figure calculations can reach 10 million rows per second for its IBP solution in some implementations. Some factors that can affect that metric are data aggregations, projection, joins and uinions. In general loading a Planning View is dependent on the slowest Key Figure atomic calculation speed and the volume of data it processes. Using filters can sometimes be effective if it reduces the number of stored Key Figures that are defined as inputs to a calculation chain. However if filters do not affect the number of key figures and only affects data size the impact on performance might be minimal.


 

Wednesday, October 04, 2017

Are You Asking Your Engineer to Do the Impossible?

It is important for engineers building systems to understand how the organization will support the utility of their end product. I was asked to weigh in on a dispute between an IT vendor and a large multinational corporation. The vendor claims the IT security work has been delivered and they installed the systems and built the infrastructure needed. The IT sponsor at the corporation claims the implementation is not working.




 
Upon closer observation and after discussions with the technical team members I was able to identify the root cause of this confusion. Both entities were correct, the vendor indeed did deliver the work per technical spec, and indeed it was not serving the business objective the sponsor expected.


In a nutshell, the technical implementation was done correctly. However the way it was used by end users was not what both parties had envisioned causing certain portions of the solution to go out of sync with other components in the system, causing configuration errors yielding diluted value of the implementation. What was missing was an organizational policy that guides end users to follow certain process changes. Once the end users would follow the new organizational policy, and back doors were no longer allowed, the system components would be in sync and operate correctly.
 
The summary of this experience is that for a technology implementation to work properly the following need to occur in advance.
  • Clearly articulate the updated operational process flow
  • Ensure governance and policies support the new process flow
  • Develop controls in the IT implementation to to enforce the policy
Without the three components the net realized value and user experience will be suboptimal. This is of course assuming all other standard best practices of system development have been followed from concept to deployment.

Wednesday, September 13, 2017

Closing on Poorly Contracted Projects

I was once asked to help with a large transformation program at a fortune 500 product development company. They had outsourced several IT security transformation projects to a vendor. The contract was very poorly written, more assumptions than deliverable were listed, the deliverables listed were not measurable and there was too much loose information. The projects which were supposed to take six months each ended up taking three years.
 
I was faced with one of two options, spending dozens of hours sifting through project change requests, meeting minutes and status updates for three years' worth of work, or some up with an agile, fair, and meaningful approach to close on the three. Luckily, I was provided a punch list that a former project manager in the past had felt was all the work items missing. The punch list helped me make the decision to choose the latter option and follow an agile approach to close out on the project. I followed some simple steps;
 
  1. Setup weekly punch list calls
  2. Defined my role and the objective of the effort
  3. Went through the list each week
  4. Compared to the original contract
  5. Identified any gaps
 
These five steps might seem straight forward, which they are, except when you have two teams, one representing the client always asking for additional items which are mainly operational enhancements and not project deliverables; and another team which is the operational team on the vendor side fulfilling these requests, not realizing that they are also playing a role as the project vendor team. This is the crux of the complexity. It is not that the projects were not closed out, and not in production, they were indeed open projects, but the work delivered is well in production use for years, with new teams on board from both sides and now people are not considering the original baseline or expectations, they are comparing with the day before. It was a continuous bleeding scar for both companies.
 
So the trick in closing these projects in addition to the agile process above was assertiveness, clarity, separation of duties and the ability to act as a mediator and setting a clear measurable deliverable for each open item, with the confidence to act as a business analyst or contract manager specifying the measurable deliverable as needed on the go.

When its Time to Close a Project, Close it

It's in the best interest of the project, its sponsor, the team and the business to close a project when work is delivered and value is realized. I have come across several instances where the client feels the urge to keep the project open for one reason or another. Here are common cases where project teams keep the project open.
 



  • Waiting for a new feature in a future COTS product release
  • Few minor defects not fuly resolved
  • Extra funds are available
  • It will be hard to get approvals for a new project
  • No guarantees that team members will be available in the future
 
None of these reasons are legitimate reasons to keep a project open. Open projects are like potholes, they only accumulate trouble until they get out of control and then need a complete removal and replacement with a new project. If the business value has been delivered, close it, move on and start a new one if needed when the time comes.
 

What is an IOT Platform

IOT Platforms come in different flavors and capabilities. IDC defines an IOT platform as follows:


 
  • connects to and manages IOT endpoints
  • ingest and process IOT data
  • visualize and present IOT data
  • builds and hosts IOT applications
  • integrates IOT data into existing applications
 
Do you have a different definition?





Sunday, August 13, 2017

I Received PMI Agile Certification This Week

This week I sat for the PMI-ACP exam and passed. It is a 3 hr 120 question examinations touching on several areas of the agile practice. As Certified Scrum Master, it required minimal preparation.


Sunday, August 06, 2017

Do Not Shortcut the Instruments or Tools to Realize the End Product

This weekend I invited a close friend of mine to visit a nonprofit leadership center I oversee to give us some advice. He is a seasoned executive at a large retailer and supervises dozens of stores around the region. As head of the institute, and the main instructor my attention is usually drawn to compliance, curriculum and the overall performance of the organization. As he walked in he joined the trailing part of a financial reporting meeting and offered a couple of suggestions for a new program, we then proceeded outdoors to take a holistic view of the organization from outside. What comes next was very interesting.

He pointed out weeds on the sidewalk, and some stains on the building trim. Then he pointed out a few items that are not obvious to someone like myself who mostly focuses on the results and end deliverable. In other words he was able to make me realize that sometimes we get so entrenched in the mission or objective of the project; or we are operating on an agile framework delivering the next generation product while in the process the tools and artifacts used to get there are sub-quality.

Quite often on complex technology projects the team is busy delivering product value and checking off the deliverable list, while in the process they neglect the tools and instruments used to achieve those deliverables. For example the engineering team might produce a set of technical documents, however the document might not be totally polished like one that is being presented to the end user; margins might be inconsistent, different fonts on the same page, figures not numbered.

Agile project management should not mean producing internal PMO artifacts that have mismatched fonts or different font sizes, margins that look off, or a document that is lacking a table of contents. While it is true the client will never see these documents, and its only for the purposes of planning, but the fact that an instrument overall quality and aesthetics will eventually reflect the end product.

The lesson I learned is that a good balance across all areas of a project or organization is required. It is not enough to have a quality product, even if it sells well. The process in achieving the product also needs to be totally shiny and attractive even though the client is not paying for it.

Thursday, August 03, 2017

Common Project Initiation Check Points

Businesses initiate projects differently, some places have long cumbersome tasks that need to be completed prior to kick-off a project. Others might be simpler. I share some common tasks that usually are required for a new PM to get through before she can have that first team kick-off.


Sponsor Funding Approval

This could also be referred to as appropriation request approval, budget allocation approval, capital investment approval or charter approval. Basically the sponsor signs off on a document that he has the available needs funds and specifies the total dollar amount of these funds. Some organization have set times when approvals are made and sent to the IT/PMO organization, in other cases it might be on an ad-hoc ongoing basis, where requests are queued up and processed by the IT/PMO organization at specific dates of the month or the quarter.


Resource Allocation Approval

This approval usually is made by the organization which is delivering the work. If it is an IT project then the IT group that will actually design, build and test the product or system being developed as part of the project charter. The fact that funding is available by the sponsor does not guarantee that the delivering organization has the capacity to work on the project during the period wished by the sponsor.


Technical Dependency Approval

This approval is usually obtained from the technical center of excellence, for example the enterprise architecture group, cloud center of excellence, security standards group or the group that is technically governing the organization's standards. A business might have the funds through a sponsoring organization to fund a project, and the delivering organization might have the resources (team, tools and supplies) to deliver, but there might be a major technical dependency preventing the feasibility of the project. For example in the case of an IoT enablement project, there might be a security identity management architectural pending problem, which the project requires resolution prior to going live. Another example in the transportation sector could be getting approval for use of certain material in paving roads to meet certain standards which has not been obtained yet.


Vendor Statement of Work Approval

Many projects depend on a third-party vendor to deliver the project. In order to initiate the vendor SOW process, all the above approvals might need to be secured. Other items that are common as well, are charge numbers by the Finance organization, Project ID number by the PMO and even in some cases names of lead resources such as the Project Manager, the Technical Lead and the Quality Lead.


Delivering Organization Statement of Work

The delivering organization usually would like to provide the sponsor with an internal SOW or charter that specifies the scope of work being delivered and any assumptions, dependencies and high level roles and responsibilities. This is different than the sponsoring organization
statement of work or charter which is discussed above and is mostly a guarantee that money is available to execute. The delivering organization is the one responsible for ensuring the project is delivered per specs. In some case the delivering organization does the work, or might outsource it to a third-party-vendor as discussed above. The delivering organization charter is the agreement between that organization and the sponsor. Whereas the Vendor Statement of Work is the contract between the delivering organization (prime contractor) and the third party vendor or organization (subcontractor)








In summary there are many organizational check-points that a project manager should be aware of when kick-off a project at a client or even internally for the employer. In large businesses, these approval points and processes are not always, or usually not in sync, and some might need to be in parallel.







Monday, July 24, 2017

The Most Important and Most Neglected - Business Rules

Over the years the most important issue I have seen neglected on a transofrmation project is an honest thoughtful discussion on Business Rules. What should the process look like under the different conditions. Business rules come in all forms and levels of complexity. I share a few examples below for the purpose of clarity.
 
A healthcare provider member who wishes to renew her policy for her 7 year old child and 19 year old college student. The business requirement can have different rules, here are some:
  • Rule A: Income Level: Family is low income and hence have an extra 10 day grace period
  • Rule B: Residence: Family lives in rural counties of the state and hence is eligible for a 45 renewal window, versus same family living in the major cities of the state which has only a 30 day window for renewal.
  • Rule C: Age: 19 year old child reached his 19th birthday less than 90 days prior to his policy expiration is treated differently than more than 90 days prior to expeiration date.
 
An example from the supply chain vertical related to demand forecasting and planning could be dependent on order cancellation business rules, for example:
  • Rule A: Orders returned due to defective items that are reordered on the same order, should not be removed from demand
  • Rule B: Orders returned due to defective items and are reordered on a new order, should be removed from the demand of the month of order, and reapplied to the month of the new order.
 
Projects of all sizes usually neglect business rules when designing and delivering a system. Business rules are the most important part of the process, for indeed that is where decisions are made. Decisions are where the bug are found in the system. Poorly thought through business rules automatically equates to bugs, miscalculations, data quality issues, rework, frustration and utlimately redsign and worse sometime a compelte overhaul of the architecture